battery_status.msg: remove unused fields

[sfuhrer]

Solved Problem

All these fields in the battery message aren't filled or used anywhere in PX4, so I don't see why they should be in the mainline PX4. Seemed to been introduced as they get published by some power module over UAVCAN. Do we need to have battery_status in sync with the UAVCAN message?
I find all these empty fields quite annoying when debugging battery stuff, as they distract form the important ones. And it's empty weight in the log files.

[hamishwillee]

@sfuhrer From @dagar in #22875 (comment) when I recently updated the BATTERY_INFO message:

... the bigger problem I see is how badly we've overloaded BatteryStatus.msg to try to cover everything from simple ADC voltage to digital power monitors to proper smart batteries. What's actually populated is a mess. I think it really needs to be split probably capturing the different classes of battery at a minimum.

So what would be good to do is to split this up. Ultimately we'd like to be able to stream this out on two MAVLink messages:

• https://mavlink.io/en/messages/development.html#BATTERY_STATUS_V2 (high rate)
• https://mavlink.io/en/messages/common.html#BATTERY_INFO

Any chance that can have that kind of update/split of the uorb topics (and yes, still deleting anything else)?

[MaEtUgR]

I'm all with you. I also want to remove them. The problem is they are actually "used" at the moment at least for logging UAVCAN stuff.

[sfuhrer]

@MaEtUgR @hamishwillee I brought back the fields that are actually getting filled by PX4 in the battery module. Could this already get in like that as an intermediate clean up?

So what would be good to do is to split this up. Ultimately we'd like to be able to stream this out on two MAVLink messages: BATTERY_STATUS_V2, BATTERY_INFO
Any chance that can have that kind of update/split of the uorb topics (and yes, still deleting anything else)?

So we would need the uORB topic to act as middle layer between the UAVCAN message and MAVLink? Then yes, I guess that could work, though I would first really make sure we need all these fields.

[hamishwillee]

@sfuhrer Not my call on this but ...

@MaEtUgR @hamishwillee I brought back the fields that are actually getting filled by PX4 in the battery module. Could this already get in like that as an intermediate clean up?

This deletes the following.

float32 average_power # The average power of the current discharge
float32 available_energy # The predicted charge or energy remaining in the battery
float32 design_capacity # The design capacity of the battery
uint16 average_time_to_full # The predicted remaining time until the battery reaches full charge, in minutes

The design_capacity does need to be exported but can be inferred from state_of_health and the current capacity.
The available_energy can presumably be inferred from remaining_capacity_wh - we do need remaining capacity in Ah to be calculatable.
Average power and average time to full are not published by MAVLink. They might be useful I guess, since easier to integrate on the FC than from received values. But I personally am not invested :-)

So we would need the uORB topic to act as middle layer between the UAVCAN message and MAVLink? Then yes, I guess that could work, though I would first really make sure we need all these fields.

Yes, that is the intent. Essentially we have synced UAVCAN and MAVLink messages - or at least very close. There are a few extra fields on MAVLink that UAVCAN weren't interested in, but we kept because the current BATTERY_STATUS uses them.

In summary, I'm OK with these changes, but I'd love to see two uORB topics and an implementation of BATTERY_STATUS_V2. I'll do it myself at some point if no one else does.

[MaEtUgR]

These fields are useless and not even filled or logged.
I think we can remove more of the other fields on top. A lot were just added because either SMBUS or DroneCAN or Cyphal have them defined but we only log them and only if you use either of these systems and they contain useful information. It's mostly a waste in my eyes.