Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lib/battery: fix duplicate uORB publish and minor cleanup #15880

Merged
merged 1 commit into from
Oct 5, 2020

Conversation

dagar
Copy link
Member

@dagar dagar commented Oct 4, 2020

While debugging I noticed battery_status was publishing at 200 Hz.

@dagar dagar added the bug label Oct 4, 2020
@dagar dagar force-pushed the pr-battery_duplicate_publish_fix branch from fe92145 to abf84b1 Compare October 5, 2020 02:29
@dagar
Copy link
Member Author

dagar commented Oct 5, 2020

We need to be careful that the pub freq matches the configured filter freq.

Yes I'm pretty sure that's wrong for most of the cases outside of the typical NuttX boards. Maybe we could add an update method to AlphaFilter that passes the timestamp or dt.

FYI @MaEtUgR

@dagar dagar force-pushed the pr-battery_duplicate_publish_fix branch from abf84b1 to 35502d9 Compare October 5, 2020 14:13
@dagar
Copy link
Member Author

dagar commented Oct 5, 2020

Screenshot from 2020-10-05 11-00-58

@dagar dagar merged commit 016ee6e into master Oct 5, 2020
@dagar dagar deleted the pr-battery_duplicate_publish_fix branch October 5, 2020 15:02
@MaEtUgR
Copy link
Member

MaEtUgR commented Oct 12, 2020

Maybe we could add an update method to AlphaFilter that passes the timestamp or dt.

The Alpha filter has an update function setParameters() but in #14551 I was explicitly asked to not measure dt on every loop iteration for performance reasons. My conclusion was that battery update frequency needs to defined compile-time and that's why it's passed to the Battery class constructor.

@dagar
Copy link
Member Author

dagar commented Oct 12, 2020

My conclusion was that battery update frequency needs to defined compile-time and that's why it's passed to the Battery class constructor.

That's mostly true (probably all the NuttX boards you've used), but like quite a few other things in PX4 it unfortunately isn't that simple. I faced similar problems with drivers and the sensors pipeline, ultimately deciding to gut all the fixed rates we thought we knew and actually measure it in the consumer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants