The initialization code is redundant and incomplete (only the first sensor
is done). I verified that all drivers already set this on startup.
For the mags, they all set their maximum supported update rate.
For the baro, the call can silently fail, as for example the MS5611 which
does not support 150Hz update. But it also sets the maximum in
initialization.
Tested on Pixhawk & pixracer.
This does the following if given:
- don't initialize the sensors (the sensor drivers are not started)
- publish sensor_combined even in hil mode
- do not apply or publish thermal corrections
If a single sensor is fitted, the calculation is not performed and zero values are published.
If dual IMU's are fitted, the vector length difference between the primary IMU and the second sensor is output for the angular rates and accelerations. The vector difference is low pass filtered before the length is taken.
If three IMU's are fitted, the vector length is calculated for both alternative sensors and and the maximum values output.
Fourth and subsequent IMU's are ignored.
This saves ~1.1KB of RAM for systems with only 1 sensor of each type.
If there are more sensors, they will be dynamically added, such that
failover still works.
The reason for this change is that RPi2 and RPi3 are compatible, and
hopefully all differences coming up can be resolved without ifdefs but
at runtime.
This fixes a bug with following setup:
- two (or N > 1) connected gyros
- ekf2 enabled
In this case, sensors would publish with the combined rate of the gyros,
but with N following messages having the same gyro data & timestamp.
Apparently ekf2 cannot handle this, the other estimators can.
We may want to rethink what the proper solution is here.
Reason: the value is easier to read & handle (for example plotting). In
most places the value is needed, not the integral.
Note that this breaks the replay format for sdlog2 replay
- voting is now at a central place instead of duplicated within the
estimators
-> this also means that estimators that did not do voting so far,
now have voting, like ekf2
- estimators requiring more than that can still subscribe to the raw
sensors
- allows sensors_combined to be 3 times smaller
- reduces logger, memcpy (cache) & RAM overhead
- all modules requiring only 1 or 2 sensor values now automatically get
the voted result
- this also adds voting to baro
Decreases the message size from 780 to 280 bytes.
In particular, all modules using sensor_combined must use the integral now.
The sensor value can easily be reconstructed by dividing with dt.
Voters now need to be moved into sensors module, because error count and
priority is removed from the topic.
Any module that requires additional data from a sensor can subscribe to
the raw sensor topics.
At two places, values are set to zero instead of subscribing to the raw
sensors (with the assumption that no one reads them):
- mavlink mavlink_highres_imu_t::abs_pressure
- sdlog2: sensor temperatures
These are not really used. differential_pressure is just copied from the
topic with the same name.
for sdlog2 we assume no one needs the diff pressure fields and set it to 0.
We plan to switch to the new logger soon anyway.
* mavlink receiver: added handling of battery status
handle incoming battery status messages in order to support external
battery monitoring
Signed-off-by: Roman <bapstr@ethz.ch>
* sensor params: added parameter for battery monitoring source
Signed-off-by: Roman <bapstr@ethz.ch>
* sensors: only publish battery status if we don't have external battery
monitoring activated
Signed-off-by: Roman <bapstr@ethz.ch>
davidaroyer