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

sensors: baro aggregator limit publication rate with new parameter SENS_BARO_RATE #15309

Merged
merged 4 commits into from
Jul 17, 2020

Conversation

dagar
Copy link
Member

@dagar dagar commented Jul 12, 2020

@priseborough as discussed, this is a simple change to the barometer aggregator in the sensors hub (sensors/vehicle_air_data) that limits the publication rate of vehicle_air_data (primary baro static pressure, altitude, temperature) to something reasonable (SENS_BARO_RATE default is 20 Hz). If the underlying data exceeds the limit then it's accumulated and averaged until the next allowed publication.

This is a small optimization to limit sending unnecessary data to the estimator. Saves a small amount of work per ekf2 instance, logging, and helps with replay logging. In cases where the sensor_baro publication rate is relatively high (nearly 100 Hz with the ms5611) it reduces the nominal default logging rate (estimator replay enabled) by 8%.

The will be done for magnetometer and airspeed as well.

dagar added 3 commits July 12, 2020 11:00
 - don't bother running baro aggregator if SYS_HAS_BARO disabled
 - the timestamp is uORB message publication metadata
 - controllers shouldn't be accessing raw sensor data directly
@dagar dagar force-pushed the pr-sensors_baro_limit branch from c96573a to a7f1a30 Compare July 12, 2020 15:10
@dagar
Copy link
Member Author

dagar commented Jul 12, 2020

Similar to the other sensors I've added a separate timestamp_sample to the sensor_baro message. The difference is very small, but this gets us in the habit of using timestamp as uORB metadata and working towards eventually having it populated automated at publication time.

While looking at sensor_baro usage across the code base I found and fixed a simple case in the FW position controller where the first baro was used directly.

@dagar
Copy link
Member Author

dagar commented Jul 13, 2020

Screen Shot 2020-07-12 at 8 36 28 PM

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

Successfully merging this pull request may close these issues.

2 participants