Battery percentage by voltage

[jasin755]

Issue details Mission planner calculate remaining battery percentage by used mAh and capacity. It is the worst solution ever. Why?

When you connect discharged battery you will see 100% == CRASH/FAILSAFE When you modify params and reboot system you will see 100% == CRASH/FAILSAFE When you have many batteries with different capacity and you will forget change capacity == CRASH/FAILSAFE Capacity of old batteries can be smaller == CRASH/FAILSAFE When you have something like 12S10P and you loss 1S or 1P the voltage or capacity will be lower == CRASH/FAILSAFE Version All

Platform [ ] All [ ] AntennaTracker [x] Copter [ ] Plane [ ] Rover [ ] Sub

Airframe type Octocopter

Hardware type Cube black

[khancyr]

Hello,

Current counting is the only wait to know the state of a battery, voltage on onload battery cannot be trust at all, so a percent on voltage means nothing. All examples you are citing are process issues and not issue with the code. We are also sending the voltage reading and our failsafe system can be use with voltage boundary too, so I don't think there is room from improvement on this subject on the autopilot part. Without smartbattery only current counting is reliable.

[jasin755]

On the most LiPols is it trust. I thing it can be possible turn on/off measurement by voltage. Simple when voltage is 3.5V per cell, battery is always discharged. When voltage is 4.2V battery is always charged.

[jasin755]

Or it can be more sophisticated. When you connect battery percentage will calculated by voltage and next measurement will be calculate by old way (amp + capacity).

[Pedals2Paddles]

IMO it is not the worst solution ever. It would seem that you know exactly what the operating constraints are and how to avoid user error. You have to set the battery's current capacity, whether that is fully charged or something else. There is no magical way to get better information about the battery unless it is one of the few "smart battery" systems out there. If you don't like the MAH capacity monitoring and failsafe, simply turn those parameters off. Lots of people fly with just voltage monitoring.

There is no consistent, repeatable, reliable, and universal correlation between battery voltage and percent remaining. It's been suggested, tried, and proven unreliable on multiple occasions.

You're certainly welcome to only use the battery total voltage monitor, which many people do.

[jasin755]

"... which many people do." Yes It do the most people because it is only safe how to determine if I need to land or not. All other autopilot do it (DJI, PX4, Betaflight, iNav). Ardupilot is only one autopilot which do it in strange way.

[n1ente]

We are facing the same situation with our fleet of copter and its swarming GCS, and we prefer to use voltage monitoring too. Our idea is to use 2 different "scale" factor, because I guess we need a "not armed scale" (before take off), in our case 8.2 v - to something like 7 v . 8.2 v is full charge battery and 7v means it needs to land for battery failsafe in less than 1 minuts flying. This because as soon as we are flying the voltage sag bring us immediatly to the wider "flying voltage scale" from 8.2 v to 5.8 v. Where 8.2 v is full charge battery and 5.8 is going to call the battery failsafe.

[jasin755]

Nice solution by PX4.

[khancyr]

@jasin755 your screenshot only display QGC parameter handling not PX4 stuff. They don't use voltage for percent if the current counting is enable ... The voltage scaling is wrong in all case as it depend on chemistry, battery health, temperature, current load, sensing, etc. If you can bring a mathematical law that bring us voltage-percentage scaling, we would be happy, other IMHO we won't provide non reliable information. Even on MP the voltage is display, so maybe it is better to change MP side to switch to fake calculated percent base on the battery monitor backend.

[jasin755]

Battery capacity it depend on chemistry, battery health, temperature and current load too. There is no different.

[Pedals2Paddles]

Declaring that monitoring battery capacity based on MAH is strange and unsafe is blatantly untrue. As with any other user setting, it is as as safe and accurate as the you the user sets it. If you do not want incorrect MAH values to be used in the MAH/% remaining data, I strongly suggest you enter the correct MAH capacity for the battery you are using. If you fly with an incorrect BATT_CAPACITY parameter, you made a mistake, not ArduPilot.

DJI uses smart batteries that monitor their own capacity and report that data to the autopilot. Just like the Solo and and any other vehicle that uses smart batteries.

If other autopilot firmware blindly uses voltage-percentage calculations, that is a flaw rather than a feature because it doesn't work. ArduPilot does not create features that only sort of work sometimes for some people if you don't mind kind of bad data. One of the great things about ArduPilot IMO.

BTW, if you actually read beyond that screenshot in the PX4 manual, you will see they utilize the MAH along with the inaccurate voltage scaled percentage. Why? Because simply scaling voltage doesn't work.

And no, ArduPilot is not the only autopilot that uses MAH for battery monitoring.

[jasin755]

I don't have problem with correct mAh. I can set it. But when I unplug battery (e.g. reboot autopilot). The state of percentage usage will be reseted or when I plug half-discharged battery, percentage will be 100%. This are big problems.

[Pedals2Paddles]

If you're not updating the MAH capacity when you reboot or plug in a discharged battery, then you're not using it correctly. That's my point. If you have a 5000mah battery that's been discharged down to 2000mah, then you need to manually change the capacity parameter to reflect 2000mah instead of 5000.

If you must use partially discharged batteries, then your best bet is to simply monitor the voltage only, and use the low/critical voltage settings. This is the way it's been done for probably 40 years in RC aviation and still works today. That is more accurate and responsible than fabricated voltage scaling percentages IMO.

[auturgy]

Let’s not just get defensive. There are clearly things ArduPilot can be doing better here - either in the flight code or how it’s presented in the GCS. Regardless of the known inaccuracy and unrepeatability of % based on voltage, reporting 100% when we can with confidence know that to be untrue is worse. Perhaps 2 simple dot-point lists that describe the existing and desired behaviours will allow people to take a step back and properly consider this.

On 27 Nov 2019, at 2:56 am, Matt notifications@github.com wrote:

 If you're not updating the MAH capacity when you reboot or plug in a discharged battery, then you're not using it correctly. That's my point. If you have a 5000mah battery that's been discharged down to 2000mah, then you need to manually change the capacity parameter to reflect 2000mah instead of 5000.

If you must use partially discharged batteries, then your best bet is to simply monitor the voltage only, and use the low/critical voltage settings. This is the way it's been done for probably 40 years in RC aviation and still works today. That is more accurate and responsible than fabricated voltage scaling percentages IMO.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[jasin755]

I am trying to summarize it:

• Nobody wants to know super accuracy % of battery (on copters). Important is if you have cca 1/4, 2/4 etc.. of capacity. If it would show 61% or 73% is not important
• If battery is damaged, voltage always drop down (in serial and parallel connection). It is signal that is something wrong and you should land.
• You can connect not fully charged battery

Finally: The major function of % shoud be safety not accuracy.

[Pedals2Paddles]

How do you present information to the operator that is both safe and inaccurately random though? IMO, giving the operator a percentage that is known guaranteed to be wrong and arbitrary... and with no way to know how wrong or which direction it is wrong... is just making it less safe.

I'm not visualizing a way to make it more specific / less arbitrary in the code that isn't a massive pile of really ugly parameters. Even if we were to make that huge pile of parameters so you could develop a table of voltages that correspond to percentages, you just circle right back to the same problem that exists with the MAH parameters. It requires you the user to properly enter a bunch of parameter values that apply only to one specific battery at that time. If you use a different battery, or even the same battery 2 months later, it will all be wrong again.

I'm not trying to be a pessimist, and I'm certainly not suggesting that the current MAH method is wonderful. Unfortunately I just don't think that batteries being what they are allow for this to be a thing.

[jasin755]

http://docs.px4.io/master/en/config/battery.html?fbclid=IwAR2LS7e1i7BT_Yo_4X9WqDhcu0Cty2Y7aU1HXB2yEQhdqSC0UpXgB13rFo8

Section "Voltage-based Estimation Fused with Current Integration"

[IamPete1]

You can do this via scripting. https://github.com/ArduPilot/ardupilot/issues/1434#issuecomment-894861690

[David-OConnor]

@jasin755 your screenshot only display QGC parameter handling not PX4 stuff. They don't use voltage for percent if the current counting is enable ... The voltage scaling is wrong in all case as it depend on chemistry, battery health, temperature, current load, sensing, etc. If you can bring a mathematical law that bring us voltage-percentage scaling, we would be happy, other IMHO we won't provide non reliable information. Even on MP the voltage is display, so maybe it is better to change MP side to switch to fake calculated percent base on the battery monitor backend.

Perfect is the enemy of good enough.

[lthall]

This is one of the "features" that come up over and over again because people simply don't understand how batteries work or how they integrate with a multirotor system.

Facts:

1. LiPo batteries have a very non linear voltage vs remaining capacity curve.
2. LiPo batteries curve change significantly. Not just type to type but the same battery changes significantly over the lifetime of the battery.

These basic facts mean that no matter how well you match your new battery voltage curve, over time it will read empty when at 40% capacity. You will see similar errors changing cell types, even if you are using standard LiPo's. Readings that can be as inaccurate as 40% are not useful.

It is a real problem advising people what their minimum voltage failsafe's should be set to. I have spent a lot of time looking at the discharge curves of LiPo batteries to provide solid advice to clients. I aim for a 30% and 20% failsafe. A volt can make the difference between 5% and 50%. Different packs, all standard LiPo's, use voltage limits with up to 1.5V difference to achieve the same outcome.

There has been lots of time spent trying to provide this capability but it has been proven over and over again that the only way to reliably measure remaining capacity, is to measure current. This is supported by the way the chemistry of batteries works. The only way to measure capacity based on voltage is to accurately characterise the battery (V vs capacity) you are using and update that continuously over the life of the battery. This is simply not practical.

To address battery management challenges we have:

1. Integrated current. The primary measure of used capacity.
2. Low battery failsafe. This should be used as a backup. The first warning to the pilot they didn't put a full battery on the aircraft or have lost a cell.
3. Critical battery failsafe. This should be used as a backup. The second warning to the pilot they didn't put a full battery on the aircraft or have lost a cell.
4. Minimum arming battery voltage.
5. We can pass raw or current compensated battery voltage to the ground station.
6. Lua scripting that lets you add any other rules and feedback via message that you want.

The only reason this feature request is left open is in the hope that we may one day find a solution to this problem, however unlikely.

[David-OConnor]

LiPo batteries have a very non linear voltage vs remaining capacity curve.

Polynomial/LUT.

I trust voltage for LiPos more than integrating current, due to accumulating integration errors; especially given the low-resistance shunts used to measure these relatively high currents, and the potential of shunt heating unless you use a giant one. (ie one bigger than the ones you see on ESCs and small power monitors)

Voltage, like integrated current, is valuable information; a rough proxy, but much more valuable than not having it, or incorrectly displaying 100%. It is not precise, but is reasonably accurate; if cell voltage drops to 3.6 volts, you can reliably assume the battery is almost dead. If it's at 4.2, you can reliably assume it's full. If it's 4.0, you can reliably assume you're somewhere in the mid range of life. It's much easier to test if the voltage reading is accurate than the current one, and voltage readings are easier to perform than current. (Voltage: Divider -> ADC. Current: Giant shunt or hall effect, but likely whatever is on your ESC; voltage-to-current conversion that varies by ESC etc).

There's a reason PX4, Betaflight, and DJI use voltage. As Jasin pointed out, the best approach is to fuse multiple approaches.

Not making displayed voltage available is dangerous.

[lthall]

We provide voltage. So you can do what you suggest.

• 4.2 x cells is charged
• 3.6 x cells you need to be landing
• Between 4 and 3.8 it is anybody's guess because the curve is very flat.

So yes, voltage is important for telling you that you put fully charged batteries on the aircraft or that you messed up and need to land asap. But converting that to a percentage suggests that it is also useful for telling you how much longer you can fly with a level of confidence. This is misleading.

Not making displayed voltage available is dangerous.

We have always send voltage down for display and it has always been displayed on mission planner. I don't know why you would even suggest this.

There's a reason PX4, Betaflight, and DJI use voltage. As Jasin pointed out, the best approach is to fuse multiple approaches.

Ardupilot "use voltage" too. And for anybody that doesn't have a good current measurement, voltage is all you have. The discussion here is about using voltage to predict remaining energy stored and displaying this as a percentage of maximum battery energy.

Calibration of the current sensor is challenging as you say. For our commercial aircraft we calibrate each sensor directly and this will be the case for any decent CAN based current sensor. When I was doing this for fun I would calibrate to be the same as what the battery charger put back into the battery after the flight. Both work very well and give extremely reliable and accurate estimates of remaining flight time.

• PX4 has will make a guess at the initial charge state ( but then uses current integration).
• DJI uses smart batteries and that is current integration.
• For a long time most betaflight boards didn't have a current source so could not use current integration. I don't know what options it offers now.

Basic state of play here:

• This feature is all about using voltage to estimate remaining battery capacity. There is currently no reliable algorithm that doesn't place unreasonable restrictions on the user or is unacceptably inaccurate.
• As developers we won't provide information to the user that we know is not accurate. If other autopilots have lower standards you are free to use them.
• We expect users to be competent enough to know what battery voltage they should be landing at and provide automated features to make this easy to monitor accurately.
• We expect users to be competent enough to set up their current sensor if they wish to use it. If set up properly it is extremely accurate and reliable.
• We provide both current based and voltage based battery failsafes.

[IamPete1]

We now have a scripting example and python tool to find and use a polynomial.

Instructions: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Scripting/applets/BattEstimate.md

Script: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Scripting/applets/BattEstimate.lua