reg.drone.service.battery.Parameters.0.2 is missing the nominal cell voltage about public_regulated_data_types

[pavel-kirienko]

I think you are approaching the question with the mindset that the energy estimate is necessarily derived from the electric charge, but this is a mere detail of your specific implementation. If you look at it from the standpoint of the specification rather than your implementation, you might see that the ambiguity you mentioned here might not exist:

Since Source1.0 isn't specific here, the implementer is free interpret the way they like and they could also use the nominal voltage or current voltage.

If your battery controller does not support energy estimation natively and you want to approximate it from the electric charge and a constant voltage, then the nominal battery voltage is expected to produce the best approximation if you consider the voltage discharge curve of a li-ion battery:

As for the PX4: the electric charge estimate cannot be used for predicting the endurance of the system since it is not representative of the amount of available energy (e.g., if you consider the propulsion system of an electric vehicle like a UAV, at constant power the discharge current will increase near the end due to voltage drop, which cannot be accounted for by the charge-based method). There is an additional implicit conversion to energy that takes place somewhere between the flight stack and the higher-level system (e.g., the human operator), so in your case the conversion chain is:

• Your BMS derives energy from charge.
• PX4 converts energy back into charge.
• The endurance predictor crudely approximates energy from charge again.

DS-015 offers a superior approach but it is understood that it has to be adapted to legacy systems. As is the case with forward conversion from charge to energy, the reverse can be accomplished using a constant voltage, in which case the nominal voltage is expected to produce the best approximation as I mentioned above.

[pavel-kirienko]

The energy specification does not say anything about voltages and it should not be expected to. It requires only that the node is to publish its best guess energy estimates:

https://github.com/UAVCAN/public_regulated_data_types/blob/53a7dbbf85554e11517c13ad91b9efb871599ad1/reg/drone/service/battery/_.0.1.uavcan#L47

Then it is up to the implementer to use the correct method of energy estimation. These are the respective definitions of energy and full energy:

A pessimistic estimate of the amount of energy that can be reclaimed from the source in its current state.

A pessimistic estimate of the amount of energy that can be reclaimed from a fresh source (fully fueled generator or a fully charged battery) under the current conditions (SoH, temperature, load profile, etc).

Questions of voltage or charge estimation are outside of their scope.

Then, the state of charge, understood narrowly as the amount of retrievable energy normalized into [0, 1], is found as energy/full_energy, without the need to obtain the electric charge. If this method is believed to produce an unreliable estimate, then the implementation is, by the definitions given above, defective.

[PetervdPerk-NXP]

Hi Pavel,

Let me sketch the problem me and @cisvanmierlo is facing here.
We're implementing the DS-015 reg.drone.service.battery energy_source subject which is defined in reg.drone.service.electricity.SourceTS.

Our BMS reports full and remaining capacity in Ah, thus for SourceTS we've to convert it to Joule. To convert Ah to Joule we've to use the following formula:

Problem here is to pick which value for V? We could be extremely pessimistic and take minimum cell voltage for a LiPo e.g.

But in reality you would rather give a better approximation of the energy available in the battery. Since Source1.0 isn't specific here, the implementer is free interpret the way they like and they could also use the nominal voltage or current voltage.

So on the other we've got a PX4 flight controller that has to decode SourceTS and convert it back to Ah, since it doesn't use Joule see
https://github.com/PX4/PX4-Autopilot/blob/master/msg/battery_status.msg#L7

To convert Joule back to Ah we're missing the voltage V used by the BMS to convert it's Ah to Joule. And thus we might suffer from loss of precision due to incorrect conversion (because we simply don't know what was used to calculate Joule). @cisvanmierlo is asking if it would be possible clarify/strengthen the Joule definition to minimize the error caused by the conversion.

Regarding state of charge, energy and full_energy in SourceTS are allowed to be calculated with different voltages thus you might end up with following situation.

And thus we can't divide them to get a retrievable energy normalized into [0, 1] because V differs.

[PetervdPerk-NXP]

Hi Pavel,

Thanks for the explanation, now it makes sense to use Joule over Ah since in fact it's superior. I will ask the our BMS team if we can provide the energy estimate directly in J instead of converting it from Ah. (maybe this is caused by the requirement that PX4 requires Ah instead of J, who knows. will be investigated further)

Regarding the PX4 UAVCANv1 implementation I will convert J then to Ah using the nominal voltage. One question though how do we determine the nominal voltage from the PX4 side? Since it's not available in one of the reg.drone.service.battery messages. reg.drone.service.battery.parameters provides cell min/max and charge voltage but not the nominal pack voltage. Roughly speaking you could determine it from battery chemistry type but that reduces flexibility.

Would it be something to add the nominal voltage to reg.drone.service.battery.parameters?

About the fact that PX4 uses Ah instead of J, we could use your post above to showcase that J is superior then Ah. And probably we should inform the Dronecode Smart Battery DS-013 workgroup as well.

[pavel-kirienko]

Would it be something to add the nominal voltage to reg.drone.service.battery.parameters?

This is an omission on our part. I was under the impression that this field is present in the Parameters type but I now see that it is not. Would you volunteer to define Parameters.0.3 with the new field added at the end? v0.2 should be @deprecated then.

@echoGee @kyle-pawlowski @AlexKlimaj please speak up if there are objections.

About the fact that PX4 uses Ah instead of J, we could use your post above to showcase that J is superior then Ah. And probably we should inform the Dronecode Smart Battery DS-013 workgroup as well.

I actually spoke about it before and the same reasoning is given in the docs so the idea is not new, but surely it won't hurt to point the other work groups' attention to it again.

[echoGee]

Would it be something to add the nominal voltage to reg.drone.service.battery.parameters?

This is an omission on our part. I was under the impression that this field is present in the Parameters type but I now see that it is not. Would you volunteer to define Parameters.0.3 with the new field added at the end? v0.2 should be @deprecated then.

@echoGee @kyle-pawlowski @AlexKlimaj please speak up if there are objections.

About the fact that PX4 uses Ah instead of J, we could use your post above to showcase that J is superior then Ah. And probably we should inform the Dronecode Smart Battery DS-013 workgroup as well.

I actually spoke about it before and the same reasoning is given in the docs so the idea is not new, but surely it won't hurt to point the other work groups' attention to it again.

Nominal voltage would be one thing to add and is often used on specifications etc. However, the challenge here is:

• that the voltages vary(a lot, lik ) for higher cell counts. Check https://rotoye.com/modelling-the-behavior-of-a-battery/ for an approximate voltage ranges for different cell counts. Its like 16v variation from 0-100% for a 12S pack.
• Understanding how the voltage nominal will be interpreted by a user. This is often a mid voltage or a min voltage that battery specs refer to. Maybe an accurate definition of nominal volt could be arrived at. But, I'm not sure what that definition could be. It could be the mid voltage at 1C drain or mid voltage at 0.1C drain or some arbitrary agreed upon value.

[PetervdPerk-NXP]

Hi @echoGee so for me the nominal voltage is defined as

The average voltage(not per-cell) the battery outputs when charged to depletion under room temperature.

Which is typically the notion manufacturers use to put a voltage number on the battery pack.
I've added this as well to the PR #113 but I can expand the definition if necessary.

Regarding min and max voltages the parameter message already includes these
https://github.com/UAVCAN/public_regulated_data_types/blob/cd600d8db7f803afbda59834b34ef7c8259f8e92/reg/drone/service/battery/Parameters.0.3.uavcan#L27

And the maximum and minimum pack voltage can be calculated by multiplying with the cell count.
https://github.com/UAVCAN/public_regulated_data_types/blob/cd600d8db7f803afbda59834b34ef7c8259f8e92/reg/drone/service/battery/Parameters.0.3.uavcan#L58

[echoGee]

I didn't follow what charged to depletion is. Could you rephrase ?

[PetervdPerk-NXP]

Sorry that was a bit vague, but I mean from fully charged to depletion (just above critical voltage to not damage the battery).

Just a footnote, batteries isn't my ballpark at all, but various literature use this definition of nominal voltage.

https://batteryuniversity.com/learn/article/confusion_with_voltages
https://en.wikipedia.org/wiki/Lithium-ion_battery#Battery_life
https://www.linkedin.com/pulse/confusion-nominal-voltage-especially-nmc-cells-36v-37v-yadav/?trk=related_artice_Confusion%20with%20Nominal%20voltage%20especially%20in%20NMC%20cells%3A%203.6V%20or%203.7V%3F_article-card_title

[echoGee]

I see the definition _Nominal Cell Voltage - The average voltage a cell outputs when charged. _ in multiple different places. But I am not sure how the average is obtained. Maybe taking the area under the discharge curve and dividing by SOC ? But what does that signify in practice ? Could the nominal be used to obtain the power in (Energy =voltage*ah) relation? Not sure.

Taking this graph for example, its hard to perceive what the nominal voltage would refer to.

More I think about it, more it seems to make sense to add resting voltage at 50% SOC (for 0.1C drain at a particular temperature?) as a parameter to note. This number along with min and max voltage of cell would give a decent estimate of the battery voltage range. It's easy to obtain this value and repeatable(and useful?) for all types of battery chemistry?

I feel like the nominal, min and max is really used by a user to one, find that the electronics connected to the battery survive this range, and two, to get a mental model of the ranges of operation.

[dimracer]

As far as I know the EV battery vendors are defining the Nominal Voltage (V) – The reported or reference voltage of the battery, also sometimes thought of as the “normal” voltage of the battery. Each manufacturer defines this reference or "normal" voltage in its own way. But most often they define it as the voltage of a fully charged battery, because it is this voltage that must be nominal for all devices connected to the HV bus.

[pavel-kirienko]

Let me add also that the Smart Battery Data Specification introduces the term "design voltage" but provides no sensible definition of it. Overall, I think we can agree at this point that the industry lacks any agreed-upon rigorous definition of "nominal voltage"; given that, I recommend that we desist from fixing this problem and let the market self-regulate.

[echoGee]

If so, I'd recommend either

• leaving the nominal voltage out of the parameter list, so as to not add a field which even the specifier group is not sure of, OR
• specifying an agreed upon xxx voltage parameter which is helpful parameter which is defined clearly. Maybe it will be picked up as a standard later.

[pavel-kirienko]

I just messaged [email protected]. Let's see if they can help.

[LorenzMeier]

I'm a little bit concerned of the academic direction the discussion is taking here. I'm holding off on engaging because it feels this is already into the weeds, what I would like to make clear though is that we might end up re-doing the message as the result of it.

[pavel-kirienko]

Merged #113 to unblock Peter

[pavel-kirienko]

I just messaged [email protected]. Let's see if they can help.

@PetervdPerk-NXP @echoGee Response just arrived:

Design Voltage should be taken as the maximum voltage when fully charged. Looking at Section 5 and the last paragraph at the bottom of page 11 is says that “By specifying Voltage() in terms of DesignVoltage() rather than in absolute numerical values, the Smart Battery can supply useful data values while still retaining adequate dynamic range.”. This means that the when reporting Voltage the result is essentially the ADC reading in LSBs where the LSB is the Design Voltage divided by the ADC range (e.g. 1024 for a 10-bit ADC).

This means that our definition is incompatible with that of the SBS Specification. I am going to amend the comments in the data type definition.