A battery is considered connected when a) V > BOARD_ADC_OPEN_CIRCUIT_V
and if BOARD_ADC_OPEN_CIRCUIT_V > BOARD_VALID_UV connected
is further qualifed by the Valid signal.
When trying to move the selected power source to the first publication instance
on systems where there is only one power source, the compiler issued the warning
```
../src/modules/sensors/sensors.cpp:512:54: error: array subscript is outside array bounds [-Werror=array-bounds]
tmp_h = _battery_pub[_battery_pub_intance0ndx];
```
because it could not verify that _battery_pub_intance0ndx would always be 0.
Wrap the block between `#if BOARD_NUMBER_BRICKS > 1 [...] #endif`
to ensure no out of bound subscript and to remove the warning.
Remove unused _battery_pub_intance0ndx variable when nb bricks = 1
Both PX4Test and Beat noted if only Brick to was connected
battery_status Intance 0 voltage was 0V for Brick2
The priority selection logic is run prior to the subscription
creation and only updated the priority on a change. Before the
subscriotions were created.
_battery_pub_intance0ndx is suposed track the location in
the _battery_pub array that is instance 0. It is then used
to associate (move) instance 0 with (to) the lowest brick
(highest priority in HW) brick that is selected in HW.
The Bug was that before the subscriptions are created,
_battery_pub_intance0ndx set to 1. And then and never updated.
The fix was to only run the priority selection logic once
the subscriptions are created.
This change implements the publishing of batery_status messages
for each brick on the system, using multi-pub.
Backward compatiblity is achived by always publishing the
batery_status of the bick that has been selected by the HW
Power Controller (PC) on instance 0.
The batery_status.system_source will be true in one and
only one batery_status publication when a valid bit is
set in system_power.brick_valid. However, if USB is connected,
and both brikcs are not providing voltages to the PC
that are in the Under/Over Voltage Window (set in HW)
the system_source may be false in all publications.
This PR is preliminary ground work for FMUv5.
PX4 does not use the NuttX adc driver. But used the same format
for the data returned by the nuttx ADC driver.
There was a fixme:in src/platforms/px4_adc.h "this needs to be
a px4_adc_msg_s type" With this PR the need for
src/platforms/px4_adc.h goes away as the driver drv_adc.h now
describes the px4_adc_msg_t.
This ensures that the massive (several hundred params if temperature compensation is enabled) param load is not done in flight. We also lower the priority to ensure that attitude controllers and estimators which might consume sensor data directly execute immediately, which should reduce their latency.
Note that Type buf_adc[i].am_data = int32_t, but everything else are floats. Suggest (float)(buf_adc[i].am_data), precisely as was done a few lines later for the voltage.
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.
David Sidrane