Investigation: Support upcoming MAVLink BATTERY_STATUS_V2 (369) message

[hunt0r]

Feature request

The goal of this issue is to align on how ArduPilot will support the (currently in-development) MAVLink message BATTERY_STATUS_V2 (369).

(If recording this discussion as context isn't a sanctioned use of AP github issues, please just close this issue.)

Platform

• All
• AntennaTracker
• Copter
• Plane
• Rover
• Submarine

Additional context

(This work began as a DM between @hunt0r and @peterbarker . I've tried to recreate any important context from that here for future reference.)

mavlink/rfcs#19 is a related RFC regarding battery stuff in MAVLink.

[hunt0r]

Initial direction:

• Get the current upstream concept of the message (possibly still in PR?) on top of ArduPilot's master mavlink branch.
• Create AP_MAVLINK_BATTERY_STATUS_V2_ENABLED to gate all of the new code.
• Add an ap_message ID.
• Add it to the mapping in GCS_Common which allows you to start streaming a message.
• Add it into send_message somewhere (there's a switch on the message ID).

Test it by using MAVProxy to request a message instance (or a stream, if that's supported).

[hunt0r]

These design points were encountered in my first-draft solution. I've listed them here for convenience & clarity. No problem at all if we want to reverse any/all of these design decisions!

[Design point]
BATTERY_STATUS has a round-robin style reporting, with a private index to track the round-robin progress.
In order to keep V2 quite independent, a similar private index is created for it.
(In the future, we might want to more closely couple these two sources of similar---perhaps identical---information.)

[Design point]
This work does not add BATTERY_STATUS_V2 to the SRx_EXTRA3 message group, which contains BATTERY_STATUS.

[Design point]
Supporting BATTERY_INFO is not in scope for this project.

[hunt0r]

Draft solution updated since mavlink/mavlink#2503 landed.

[peterbarker]

Hunt0r to carefully study the new message and try to compact it as much as possible.

And lint the wording on the descriptive text on both the message and fields.

[hunt0r]

How to shave 1 byte from (id, temp):
Assuming 128 battery IDs and -100 to +250 deg C with 1deg resolution is enough: 16 bytes will encode these rather than 24.
(7 bytes for ID, 9 bytes for temperature)

[hunt0r]

(Voltage & Current: These seem natural to squeeze tighter, IDK what ArduPilot considers the 'requirement' truth.)

[hunt0r]

Side question: Is there any concern about the definition of "power on" when discussing a payload battery?
How about a propulsion battery?
(Seems safe to assume an avionics battery must be on for battery reporting.)

[hunt0r]

Pre-read: The governing RFC. Linked for convenience.

The key focus for myself and @peterbarker (and whoever else joins the discussion):
capacity_consumed, capacity_remaining, and state_of_charge in context of the various possibilities for BATTERY_INFO. Most importantly design_capacity and full_charge_capacity although a few others (nominal_voltage, maybe even battery_type) may also impact those definitions.

To me, it looks like there is both redundancy (so opportunity for reduced size) and ambiguity (opportunity for increased clarity).

Starting question: What does state_of_charge contribute that is not evident/calculable from the other two + BATTERY_INFO?
Recommendation: Bisect our discussion space on STATUS_FLAGS_CAP_RELATIVE_TO_FULL.

[hunt0r]

A minor focus: With several flags detailing "why" a battery is not-ready / not-suitable-to-fly, should we be reducing bits to eliminate redundancy?

[hunt0r]

(In my and Peter's last discussion, time_remaining was discussed. Linking here to a relevant similar early discussion.)

[hunt0r]

One still-open question is probably relevant to us, reproduced here for convenience:

Possible removal of capacity_remaining:
The argument was that this is always a synthesize value from full battery capacity and capacity consumed, so this is redundant/wasted bytes. However if you don't have a smart battery then SMART_BATTERY_INFO is optional, and all the recipient will get is this message. Therefore this is the only way that an emitter can effectively give the GCS an estimate of full battery capacity, and that is a useful thing.
Also it is minimal churn on existing consumers of the BATTERY_STATUS.

[hunt0r]

Another minor question: If battery "cells" can be in parallel (and I would guess they can) are some bad assumptions currently buried in the wording?

[LupusTheCanine]

Another minor question: If battery "cells" can be in parallel (and I would guess they can) are some bad assumptions currently buried in the wording?

You can't really have different voltages in parallel cells unless you run separate series strings (which makes cell matching more problematic as you have to match all cell blocks), which IMHO should be treated as separate batteries.