add: Battery_Status_V2 MAVLink stream

[Sayshara]

Solved Problem

Initial implementation for new mavlink message stream BATTERY_STATUS_V2.
It's base on BatteryStatus.msg, in a future we need to split this msg according to:
mavlink/rfcs#19
dronecan/DSDL#7
mavlink/mavlink#1846

Best to use similar structure to dsdl format of the battery messages (20004.BatteryInfoAux.uavcan, 20010.BatteryContinuous.uavcan, 20011.BatteryPeriodic.uavcan, 20012.BatteryCells.uavcan). Another question is why this is on ardupilot side, not common dsdl.

Solution

• added new stream for mavlink.

Changelog Entry

Alternatives

• On MAVLink side still missing kind of BATTERY_CELL_VOLTAGES.

Test coverage

Context

[hamishwillee]

@MaEtUgR What's the normal way we handle the case where we are migrating between messages for the MAVLINK_MODE_NORMAL case (where it is OTA).

My guess is that we'd initially stream both like this, but we might also update QGC to request the message type it wants and set the other not to stream?

[hamishwillee]

Did you test against QGC, and does QGC implement this?
If not, we might be able to make changes if needed.

---

Best to use similar structure to dsdl format of the battery messages (20004.BatteryInfoAux.uavcan, 20010.BatteryContinuous.uavcan, 20011.BatteryPeriodic.uavcan, 20012.BatteryCells.uavcan). Another question is why this is on ardupilot side, not common dsdl.

FWIW

We try match the most common definitions. I looked at all of them when we designed this message.

One thing I would consider is modifying this more like https://mavlink.io/en/messages/common.html#FUEL_STATUS
Specifically, it does a better job of reporting the level

The reported consumed_fuel and remaining_fuel must only be supplied if measured: they must not be inferred from the maximum_fuel and the other value. A recipient can assume that if these fields are supplied they are accurate. If not provided, the recipient can infer remaining_fuel from maximum_fuel and consumed_fuel on the assumption that the fuel was initially at its maximum (this is what battery monitors assume). Note however that this is an assumption, and the UI should prompt the user appropriately (i.e. notify user that they should fill the tank before boot).

maximum_fuel	float			Capacity when full. Must be provided.
consumed_fuel	float		invalid:NaN	Consumed fuel (measured). This value should not be inferred: if not measured set to NaN. NaN: field not provided.
remaining_fuel	float		invalid:NaN	Remaining fuel until empty (measured). The value should not be inferred: if not measured set to NaN. NaN: field not provided.

In other words the recipient knows what is measured and what is inferred in all cases and can tell that it is working with a system that trusts the values it outputs. This is better than what the battery message does, which is assume the battery was initially full, and use the consumed charge or battery voltage to work out what was consumed - then estimate the remaining.

Not sure we can though, because the approach comes from power modules, and I'm not sure we can "know" internally or from other sources what was calculated and what is measured.

[Sayshara]

Did you test against QGC, and does QGC implement this?
If not, we might be able to make changes if needed.

Tested, but Battery_Status_V2 is not implemented in QGC.

One thing I would consider is modifying this more like https://mavlink.io/en/messages/common.html#FUEL_STATUS
...

Changed the way of calculating capacity_remaining, now is based on remaining_capacity_wh/nominal_voltage. I'm not sure if this is the way which we should use, before was just remaining * capacity.

[hamishwillee]

Changed the way of calculating capacity_remaining, now is based on remaining_capacity_wh/nominal_voltage. I'm not sure if this is the way which we should use, before was just remaining * capacity.

Sorry, that was a side-note. This should match what it says on the mavlink spec, and we need to discuss with others if we want to modify the spec.

I commented because the way that the fuel spec does it works well because you can measure fuel in different ways. It needs more thinking to make a change like this for batteries though, since so many things assume certain behaviour. Upshot, revert please if the change doesn't match the spec.

[Sayshara]

Changed the way of calculating capacity_remaining, now is based on remaining_capacity_wh/nominal_voltage. I'm not sure if this is the way which we should use, before was just remaining * capacity.

Sorry, that was a side-note. This should match what it says on the mavlink spec, and we need to discuss with others if we want to modify the spec.

I commented because the way that the fuel spec does it works well because you can measure fuel in different ways. It needs more thinking to make a change like this for batteries though, since so many things assume certain behaviour. Upshot, revert please if the change doesn't match the spec.

I think after that change it's directly converts actual remaining energy to charge capacity using basic electrical relationship: https://www.inchcalculator.com/wh-to-ah-calculator/. The remaining * capacity approach would be more appropriate when only percentage-based remaining capacity is available. It's still according to mavlink spec.

Of course we could add different behavior depends on MAV_BATTERY_STATUS_FLAGS_CAPACITY_RELATIVE_TO_FULL, but this flag is not available yet in the code. Next PR I will add BatteryContinous/Periodic/Cells.

[hamishwillee]

1. There are lots of build errors. That's because MAVLINK_MSG_ID_BATTERY_STATUS_V2 is not being found. I think that is intended for non-SITL boards https://docs.px4.io/main/en/mavlink/#px4-and-mavlink but not sure how this is normally handled.

2. The changes look good to me, but I'm not a real programmer.

3. Of course we could add different behavior depends on MAV_BATTERY_STATUS_FLAGS_CAPACITY_RELATIVE_TO_FULL, but this flag is not available yet in the code.

   I don't think we need to change the behaviour here to compensate for MAV_BATTERY_STATUS_FLAGS_CAPACITY_RELATIVE_TO_FULL. This is something a smart battery would set to allow a GCS to know that the value for remaining capacity can be trusted, and internally you might use this also.

4. Next PR I will add BatteryContinous/Periodic/Cells.
   I'm not sure what these are. But you shouldn't add anything for cells until the new mavlink message is fully defined (that needs to be completed in the RFC and signed off).

   What I would look at next is perhaps moving some of the fields in https://docs.px4.io/main/en/msg_docs/BatteryStatus.html (the dynamic topic) to https://docs.px4.io/main/en/msg_docs/BatteryInfo.html (the static info) - at the moment the battery status has most of the fields.
   This would require updates to all the battery messages and the drivers that set the values.

   When you have a plan, consult @MaEtUgR to confirm he is happy with it please.

   Noe, I've pinged @MaEtUgR to look at this - he is currently on holiday though.