feat(uavcan): support for new Continious, Periodic and Cell Battery messages - #27464
feat(uavcan): support for new Continious, Periodic and Cell Battery messages#27464Claudio-Chies wants to merge 4 commits into
Conversation
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 5352 byte (0.25 %)]px4_fmu-v6x [Total VM Diff: 5376 byte (0.26 %)]Updated: 2026-06-02T09:25:06 |
b261478 to
7011dd1
Compare
There was a problem hiding this comment.
Note that MAVLink follows the same model - BATTERY_INFO is the slow message, BATTERY_STATUS_V2 is the fast message - planned to go in very soon #25347
The battery RFC stripped out the cell information message from BATTERY_STATUS when inventing BATTERY_STATUS_V2 as "diagnostic" - there's a proposal that it be retained in a separate message, but no one has defined its form.
EDIT, I guess my point is that it is worth looking at the form of the messages because BATTERY_STATUS_V2 can still change, and if there are significant differences we should look at them now.
7011dd1 to
ff9cb4a
Compare
|
@dakejahl i've also added CI tests for the can battery driver. open for discussion if this adds too much clutter, which i guess it might be the case. |
dakejahl
left a comment
There was a problem hiding this comment.
If we're going to add tests shouldn't they cover the callbacks? Maybe not necessary or that useful for this module though 🤷
|
@dakejahl which callbacks do you mean? i am testing the callbacks of the three messages which i'm implementing by comparing against the uorb messages. |
…ellVoltageDelta function
Summary
Add UAVCAN bridge support for the multi-message smart-battery protocol (
BatteryContinuous/BatteryPeriodic/BatteryCells) and a host-runnable gtest harness that exercises the UAVCAN→uORB path end-to-end through libuavcan's loopback transport.Problem
PX4's UAVCAN battery bridge only understood the legacy
BatteryInfo/BatteryInfoAuxandCBATmessages. Newer style smart batteries split their data across aBatteryContinuous(high-rate) +BatteryPeriodic(low-rate) +BatteryCellstrio, which the bridge ignored. Separately, the bridge had no automated testcoverage at all: verifying a change meant wiring real hardware on a CAN bus and watching
listener battery_status. The driver is also gated onPLATFORM_NUTTX, so it isn't compiled in thepx4_sitl_testbuild thatmake testsuses, leaving no path to test it in CI.Solution
Add a
BatteryDataType::Multimode that claims a node on the first multi-message frame and suppresses the legacyBatteryInfo/BatteryInfoAux/CBAThandlers for that node to avoid double-publishing.BatteryContinuousmaps voltage/current/SoC/temperature/fault flags and charging state;
BatteryPeriodicmaps cell count,
nominal voltage, capacity (with
full_charge_capacity→design_capacity→BAT${i}_CAPACITYparam fallback), cycle count, SoH and serial number intobattery_info;BatteryCellsfills per-cell voltages and
max_cell_voltage_delta. The delta computation is extracted into a reusable staticFor testing, a
BUILD_TESTING-gated standalone CMake target (src/drivers/uavcan/sensors/test/) compiles libuavcan core + DSDL + the bridge sources withoutCONFIG_DRIVERS_UAVCAN, so the bridge links into a functional gtest. A genericUavcanBridgeTestFixturespins N loopback-paired libuavcan nodes — index 0 hosts thebridge, the rest publish synthetic frames — and is reusable for other UAVCAN sensor bridges.
BatteryBridgeTestcovers field mapping,battery_infoserial-number/id propagation, multi-instance separation, capacity param fallback, and edge cases (zero nominal voltage → NaN, missing capacity,UINT*_MAX"not provided"sentinels, charging/fault flag handling). Runs under the existing
make tests/checks.ymljob — no new CI workflow.Related PR