[DS-015] Suggestion to include all the individual cell voltages of the pack on the bms status about public_regulated_data_types HOT 9 CLOSED

Some more notes from the slack rant.
Individual cell voltages are a really good indicator of the battery health. The cell voltages might be pretty useless on a daily basis for the user. But when you have an incident on one of the 100s of batteries users may have in the future, they are useful.
I would suggest adding individual cell level voltage to the spec, since the it provides data points to predict failure cases before they actually happen. On the other hand, for a hobbyist all the individual cell voltages would be pretty superfluous.

The other ideology is to have the BMS do some of this cell failure analysis. But it imaginable that it would be extremely hard to associate the data in BMS to a specific flight profile easily. For example, if the battery was flown on a specific "cold/hot" day, and experienced issues, it would be hard to look at flight logs and find out if it was a battery issue if half of the data(such as cell voltages) are in the battery. So we'd have to go back, retrieve that data and associate it with the flight logs.

This is a cell voltage for a battery thats drained. Its a fairly new battery. Towards the end the voltages of the cells diverge. A min and max would show a range of voltages, but it would hide if most of the cells are doing that or if its one cell. This would obfuscate, in a bad way, whether the battery SOC is lower than expected or the particular cell is behaving off-nominal

from public_regulated_data_types.

I think, that the individual cell voltages should certainly be available for research purposes. However, the publication of these messages should be optional. In the common application, it is sufficient to supplement the cell_voltage_min_max array with the "max" and "min" cell numbers. Specifying a cell number will identify a potentially "bad" cell.
In other cases, the value of SOH may well be sufficient. But in any case, in order to fully understand the state of the battery in case of such a need, individual cell voltages are required.

from public_regulated_data_types.

Okay. May I suggest we amend the battery service specification with a new, optional subject of type uavcan.primitive.array.Real16.1.0 where the battery cell voltages are to be published?

 #   SUBJECT                 TYPE                                            TYP. RATE [Hz]
 #   energy_source           reg.drone.physics.electricity.SourceTs          1...100
 #   battery_status          reg.drone.service.battery.Status                ~1
 #   battery_parameters      reg.drone.service.battery.Parameters            ~0.2
+#   battery_cell_voltage    uavcan.primitive.array.Real16.1.0               1
 #

from public_regulated_data_types.

I think, that the individual cell voltages should certainly be available for research purposes. However, the publication of these messages should be optional. In the common application, it is sufficient to supplement the cell_voltage_min_max array with the "max" and "min" cell numbers. Specifying a cell number will identify a potentially "bad" cell.
In other cases, the value of SOH may well be sufficient. But in any case, in order to fully understand the state of the battery in case of such a need, individual cell voltages are required.

@dimracer Few thoughts about the comment:

1. I believe that the battery behavior has not been modelled to a good certainty that voltages are only needed during the research phase and not the typical "drone-delivery" operations, yet.
2. For example, though there is a definition for SOH, it is not a complete specification. SOH mentions about a log book method for determining battery health due to this complications.
3. SOH vary based on age, the existing current draw, operating temperature etc. So even if you have an SOH, it would be a matrix which depends on these parameters(or more). This would be too complex to handle from a uavcan perspective. Due to the wider ranges at which drone power requirements change (reasons being varying payload, polynomial reduction of propeller efficiency at higher wing loading, electrical resistance of battery/motor etc) the approximation of SOH to a single value would also be challenging. This is a bit different from the automotive bms setup where the ranges of power draw are as varying.

@pavel-kirienko Regarding the thought of adding a cell_voltage_min_max and an optional battery_cell_voltage uavcan.primitive.array.Real16.1.0 1 :

• 'cell_voltage_min_max' seems like an comforting data, but with reduce actional information. _We would see a min and max diverging at some cases during the flight. But the user would have to recreate the flight with the optional uavcan.primitive.array.Real16.1.0 to understand what is happening _
• Since UAVCAN is a standard that is looked up by its adopters , a cell_voltage_min_max might send a conflicting message that min_max may be enough for a typical operation?
• I personally like to keep data minimal and believe that the BMS system should abstract away these voltage details that are sent to autopilot. But the battery models that are implemented are not advanced enough in my opinion to do this currently.

from public_regulated_data_types.

@echoGee I agree with your reasoning here. Based on your inputs, I suggest we create reg.drone.service.battery.Status.0.2 with the following differences compared to the current v0.1:

• Field uavcan.si.unit.voltage.Scalar.1.0[2] cell_voltage_min_max is replaced with void64 (to retain wire compatibility with v0.1).
• The extent is enlarged up to 600 bytes.
• At the end of the definition we add:

uint8 MAX_CELLS = 255
float16[<=MAX_CELLS] cell_voltages  # [volt]

• Parameters.0.2 is to be released with the cell count replaced with void16. This is because the cell count will be deducible from the Status message.

• Parameters.0.1 and Status.0.1 are to be @deprecated.

If you agree, please feel free to send a pull request.

from public_regulated_data_types.

I think we can do that. Would need a bit more reading/understanding to do what you suggested.

from public_regulated_data_types.

@pavel-kirienko : What do you think of this : https://github.com/rotoye/public_regulated_data_types/commits/master ?

from public_regulated_data_types.

@echoGee at a first glance it looks good except that there is one misleading comment:

- @extent 600 * 8  # Single-frame transfer over CAN FD.
+ @extent 600 * 8

Do send a pull request and I will give it another look.

from public_regulated_data_types.

Added a PR #105

from public_regulated_data_types.