Thoughts on distance/altitude based intelligent battery failsafe

ArduCopter Copter 3.5
1

I started working on a distance based intelligent battery failsafe for copter over the weekend. Rather than triggering the failsafe at a specific MAH remaining, the failsafe is triggered dynamically based on altitude and distance from home so it is landing at a specific % remaining. This will give you more flight time when you’re in close to home, make flying further from home safer, and probably help reduce LiPo abuse.

3DR did something like this for their commercial site scan solos. This will be similar but much more accurate and not solo specific.

Basic process

  • Skip all this and revert to existing basic MAH failsafe if copter position is bad, home position not set, or the required parameters are not set to begin with.
  • Read copter altitude and distance from home
  • Read parameters for RTL altitudes, climb rates, descent rates, and cruise speeds
  • Read new parameters for climb MAH, cruise MAH, descent MAH. and desired % remaining on landing
  • Calculate distance, time, and MAH required to climb up to RTL altitude (skip if FS is land only)
  • Calculate distance, time, and MAH required to cruise home (skip if FS is land only)
  • Calculate distance, time, and MAH required to descend to a landing
  • Sum total MAH required to RTL + % Battery remaining on landing = new live battery failsafe MAH point.

Parameters to make this all work

  • BATT_FS_RESERVE is the % remaining the copter will have when it lands, or at least close to it anyway.
  • BATT_FS_CURR_CLM is the MAH rate used in a climb
  • BATT_FS_CURR_DES is the MAH rate used in a descent
  • BATT_FS_CURR_CRS is the MAH rare used in cruise

I wish there was a way to do this without making a bunch of new parameters, and I really don’t want to go parameter happy with every patch. But I don’t see a consistent and reliable way to do it.

I thought above having these MAH values calculate automatically in flight, kind of like how ArduCopter calculates hover power in flight. It would probably work. However I don’t think a failsafe function should be variable and ever changing like that. Failsafes need to be consistent and repeatable,

I also thought about a single parameter for hover current, which could also easily be calculated automatically at the same time as hover throttle. Then climb, cruise, and descent MAH could be interpolated as a % above and below hover. This would also probably work. But I don’t know how accurate it would be. I can tell you my solo climbs 10-12% higher than hover power, and descends at 10-12% lower than hover power. But that is probably not universal across every copter.

Anyway, that’s where I am at with this now. Open to suggestions and comments.

6 Likes
2

That’s a major feature that deserves attention.
Please consider adding estimated windspeed (based on knowing typical lean angle at a given speed) - as strong headwind will thow off anything for certain airframes.

Also, when we have no (or bad) information about remaining charge, (or dumb-battery) it would be very good to calculate a cell voltage, and use that as well as a coarse way of failproofing the data.

So 3.5v/cell cannot be threated as 60% SOC regardless the smart, or expected capacity.

That said, the existing mah failsafe, if not used with a smart battery, is not a very good idea, and voltage is a safer bet.

3

I was thinking it would be great if it knew it was flying home with a headwind and bump the cruise MAH value up by 10% or so. But estimating wind speed and wind direction is going to be orders of magnitude over my head. And I think it may be more complicated that it’s worth. Or at least more complicated than a failsafe should be?

I will add a check to verify the battery’s capacity is set and that the reported current draw is greater than zero. That way it won’t be trying to use non-existent consumption data.

Are you suggesting interpolating battery voltage into a % remaining? As both a cross-check of reported MAH remaining and as an alternative to MAH? Is it an accurate assumption to say that a LiPo cell with a range of 3 to 4.2 volts is actually 50% exhausted when it is at 3.6 volts for example? That is the half way between 3 and 4.2. But is that really 50% capacity? Is that kind of interpolation is accurate?

4

No. 50% is storage voltage - 3.85VPC for LiPo chemistry. But that’s at rest, after the battery recovers and cools. Under load it is considerably below that and depends on the C rating of the battery, and the age/number of cycles, as to how much it sags. With my electric helicopers I don’t use the battery failsafe at all because it don’t work and have the ESC programmed to do it instead. On a heli it cuts power back if you run out of fuel and makes landing possible in an emergency to save the batteries. Since your aircraft uses power based on watts, not mAh, I use watt-hours, measure the watts required with my Doc Wattson power meter, and calculate the watt-hour capacity of my packs with 3.7 x number of cells x amp-hours capacity.

An example, with my Trex 600, the batteries are 222 watt-hours capacity (two 6S 5000’s). The helicopter burns 10.6 watt-hours per minute of flight time. Flight time in hover is 20 minutes 50 seconds. In cruise flight it’s 23 minutes even. I have an alarm in the RC radio set that sounds at 17 minutes 30 seconds from the time I throw the governor switch and start it. Works every time. When the alarm goes off I know I got three minutes to land if I’m hovering, and 5 minutes to get home and land if I’m on an Auto Mission.

My methodolgy comes from being a commercial pilot, and the old adage that “fuel burns by the clock, not by the gauge”.

5

Very valuable feature. My 2 cents:

  1. The feature must support two modes:
    a) estimate-and-report mode; to report via mavlink how close are you to the point of no-return. FS must not be triggered. This will be useful for FPV long-range flying etc.
    b) estimate-and-FS; same as previous but FS must be triggered.

  2. There must be support for different battery capacity estimating strategy (by MAH used, by voltage, by fly time). For me the simple MAH used works well all the time. But that depends on the flying style and could not work for racers etc. That strategies number can be extended.

  3. What will be the FS behavior once triggered? Can it be interrupted by operator? Will it be re-engaged again right after cancelling?

  4. To estimate correctly that feature must know how exactly RTL will be performed from current position and altitude. So will be that logic somehow shared or will it copy-pasted?

  5. Wind estimation looks overhead for the first iteration. Also it can vary on different height and time.

6

The failsafe action will not change from how it responds today. It will do whatever FS_BATT_ENABLE is set for (nothing, land, or RTL). This is not creating a new failsafe action or response. This is just a new more useful way to trigger the existing MAH based alarm and failsafe. Rather than triggering at a fixed MAH remaining, it can dynamically determine what that MAH remaining point should be.

The existing voltage based alarm and failsafe is unchanged and I don’t intend to change it. Predicting voltage and interpolating % remaining based on voltage in manner that is consistent and repeatable across vehicles and batteries is way over my head. And I’m not sure it’s even practical at all. The current voltage based alarm and failsafe will remain unchanged in this modification.

The estimate-and-report is kind of already there. If you have FS_BATT_ENABLE set for disabled (0), the existing MAH and voltage triggers will still activate the alarms and notify the operator, but will not take any automated action. That would continue to happen here. But it is somewhat crude.

This has given me some ideas to work through. It would be more of a total rework of battery based alarms and failsafes. But it would make it more robust.

I also like the idea of a flight time warning!

7

The reason mAh doesn’t work is because it’s not a direct measure of energy consumption. The battery’s capacity is based on its discharge rate. If you have a 35C pack and discharge it at 1 amp over a long period of time you get way more mAh out of it than you do if you discharge the same pack at 20 amps. At higher discharge rates some of the battery’s energy is converted to heat in the LiPo chemistry, and wasted.

Electrical energy is measured in watts. It takes a specific amount of watts to fly an electric aircraft - roughly 100 watts/kg of takeoff weight for helicopters, 110 watts/kg for quadrotors, 112 watts/kg for hex, etc… Watt-hours is energy over time and is the basis for how you are charged for electrical energy usage from your utility company. Watt is power, watt-hours is power over time, same as horsepower-hours in imperial units.

Every battery has a specific amount of watt-hours of energy stored in it, despite the discharge rate or voltage as it sags under load. And those watt-hours are used based on energy consumption of the aircraft, just like it is with your utility power meter on your house. So if you are flying and your distance from home is 3 minutes at the RTL speed, and you have 4 minutes of fuel (watt-hours) left, you can make it home with one minute reserve to land.

It’s actually quite simple. The major problem is that ArduPilot is using an arbitrary relative value (mAh) instead of measuring power over time (watt-hours), which is how electrical energy is measured in every other application that I know of in EV’s, including Tesla cars and electric forklifts and lift trucks. Even my Doc Wattson RC power meter shows power in watts, and energy consumption in kWh on the screen because it is independent of voltage sag under load.

8

@ChrisOlson It is unclear for me what is the difference between estimating by Watts or by MAHs for the subj task?

Ain’t the same is true for the Watts as well?

9

Is MAH perfect? No. But it’s what we have. And the sensors in use today are hardly perfect either. So I’m not sure expecting a precision watt-hour battery measurement is practical today. I’m all for new and more accurate power management. But I’m not sure we’re there yet.

10

No. With lithium polymer technology you have more mAh in the first 50% than you have in the second 50% due to voltage drop as the battery discharges, and the fact that you cannot discharge it much below 3.5vpc without risking damage to the battery, meaning some of the battery’s capacity must remain unused.

Watt-hours of usable capacity always remains the same, despite voltage. With the battery fully charged at a specific watts output, the voltage will be higher the amps lower. As the battery discharges amps will be higher voltage lower. If a battery has a specific energy capacity of 100 watt-hours, at 50% of the watt-hours used, you have 50 watt-hours left. Every time.

It is very simple to calculate. Simply measure the power required to hover or fly your aircraft with a good-quality RC power meter. With the batteries fully charged, hover or fly it to fully discharged (low battery cutout so battery is no lower than 3.5vpc at rest after recovery). The watts times the time is the watt-hour capacity of the battery pack.

Now, when you fly, if you have 200 watt-hours capacity and have used 100 watt-hours of it, you are exactly at 50% fuel left, where using mAh will show more than 50% left. Like Matt said, the current sensors used on the ArduPilot system are not very good, or very accurate. And that’s why I don’t use them and use measured capacity and consumption over time instead, with a timer. I fly piston helicopters as well, and the same methodology is applied to fuel left in the tank, and remaining flight time, with a piston engine. In all aircraft, fuel burns by the clock, not by the gauges.

I’ve been working with a friend who does coding to test various things for helicopters, and it would be trivial to convert ArduCopter’s system of using mAh to watt-hours, and enter measured values into params for power and capacity. But due to the inaccuracy of the current sensor and a decent power meter not being available, it wouldn’t be worth it. A simple timer, after actually measuring my aircraft’s performance and fuel capacity, has worked fine for me over hundreds of flights, with both piston and electric, without using ArduCopter’s battery failsafe at all.

For many folks, ArduCopter’s system of using mAh is “good enough”. For me, it’s not and I certainly do not trust it to engage any sort of “failsafe” with the quality of the sensors currently available or being used in the system. I do not even trust the shunt and little board to handle the 3-5kW that a big helicopter can draw at full power and collective pitch running on 12S power. I feel the system was designed for smaller drones that do not draw much over 20% of the shunt’s maximum current rating, and even the higher-rated boards are not that great.

This thread caught my eye because I have had the thought of coding a warning timer into the ArduCopter system for flight time that works with both piston and electric helicopters, using measured values to do the calculations. And while it would never make it into the mainstream code, I can run it in my own custom branch for helicopters.

11

Ok, I got your point now. It’s all about linearity of the capacity value during discharge. Thus it will be easier to estimate.

So to account Watt-hours used we should continuously multiply current Amps with current Voltage, right?

Why there are so many doubts in a sensors accuracy? Are they so bad? In what way is this expressed?
Looking into my logs I see that my Amps and Volts values are more or less adequate all the time.

12

The cheap shunt style power modules that most people use are only really useful in a narrow range from the calibrated point. So if you calibrate it to be accurate at hover power, it will not be very accurate at low or high power. And ArduPilot cannot control how the user calibrates it.

The accuracy of this information output is also hampered by the accuracy of information input. You can get very accurate power modules. But it’s all moot if the full charge capacity of the battery entered manually by the operator is not accurate. And it usually isn’t since we’re not talking about high precision batteries and charging instruments here. I think it is safe to say the MAH entered by most operators can be +/- 100-200mah from reality. Smart batteries make this remarkably better, but even they aren’t perfection.

So given all this, I think we have to work with the fact that power management on a typical ArduPilot equipped copter is what it is. Volts and MAH. The latter of which will always be a bit fuzzy.

13

That’s the idea. You’re anyway going to use fuzzy MAH readings. Additionally to that fuzziness MAHs are not linear over the time. That does increase the estimation error. But the error could be decreased if to estimate Watts used. Simply Amps * Volts * quantity Time.

Of course battery Watts-hour capacity must be measured initially. This could be done just like we measuring MAHs: by hovering to cut-off voltage and reading the logs.

14

What I had thoughts of doing for myself (not to PR to master) was to have a param to enter the power in watts required to hover my electric helicopter at normal takeoff weight (worst case scenario because the heli gets more efficient in cruise). Another param with measured watt-hour capacity of my battery packs. With this system, when it says I have 50% remaining, I have actual 50%. I can fly to zero fuel remaining and not have to worry about a minimum mAh capacity, minimum voltage, etc. And just have it report to the ground station the capacity remaining in watt-hours instead of mAh, without modifying the ground station software at all.

With that system, the distance from home is always known, the RTL flight speed is known, the remaining flight time in linear values is known, and an alarm could go off to warn that there is now just enough fuel to make it back, with say 1 minute reserve. I don’t know that I’d actually set off a “failsafe” system because I don’t like those. The decision is the pilot’s alone - either hit that RTL flight mode now and get the aircraft back home, or risk that I can fly the rest of the mission at programmed speed and make it.

I am not the type of pilot that likes a lot of “hand holding” from the software, and the software doing things automatically that I as the pilot did not specifically tell it to do. And I suspect that comes from 31 years of being a commercial pilot, and my training to make decisions based on the information I have, and not letting computers make those decisions for me. The computers can give me the information, but I as the pilot want control of the outcome.

15

Fully agree here.

I believe this task could be spitted into the two phases:

  • Make the estimator, test and ensure it gives the appropriate accuracy and linearity. This could take a time. The good estimator itself will be a valuable feature for pilots.
  • Then having an accurate estimator we can make a reliable intelligent battery FS. Otherwise there is a risk to have a new not very usable feature (may be just a bit better that current failsafe by MAH).

Finally one more point for using Watts-hour units: there is a lot of people using li-ion batteries with wider operation voltage range: from 4.2 to 2.5 volts(!). That means that MAHs non-linearity much worse in that case.

16

Yes, that is true. And measured watt-hours makes more sense there.

What I am looking at is a system that works with piston (combustion engine) aircraft as well as electric. I use the timers for each model I fly right now, in the radio. When I load that model into the main menu the custom timer for that aircraft is there, pre-set based on the flight testing I have done with it. The reason I would like it in the ArduPilot software instead of just a simple radio timer is because it is in the logs with the calculations being done in the software. And it provides the capability to do the distance/time/remaining fuel calcs for a warning system for low fuel, based on distance from home.

Everybody flying pistons uses the timer right now, based on fuel capacity and burn in flight. I do not know why such a timer system was never put into ArduPilot for non-electric aircraft. I suspect it is because it was originally designed for electrics and nobody took the time to do it. But the principles are the same once you make the conversions to actual power and energy with electric, similar to liquid fuels.

17

I do not know a lot about those so-called “intelligent” flight batteries. I had a DJI Phantom 3 some time back that had one. It seemed to work quite well, although other people reported problems with them. I think the Solo has one as well and have not heard many reports on how well those work.

The DJI one I had would calculate the actual battery capacity based on discharge/charge cycles, number of cycles, and age. There was a calibration procedure the pilot had to go thru now and then, which if I remember correctly, involved discharging the battery to a deeper level so the onboard processor could re-calculate the capacity better. In theory, that could be done in the ArduPilot software with an appropriate battery management unit (hardware) that plugs into the balance plug to monitor individual cell voltage, and the appropriate software to interact with the hardware - allowing the use of much cheaper “non-intelligent” batteries. But I don’t see that happening until somebody invents the hardware for it.

18

I wonder if logging live and total watt might be simpler than it sounds. ArduPilot already monitors live current flow and live volts. ArduPilot also interpolates resting voltage and apparently does it quite well. It isn’t used for anything yet, but it is there. If we did resting voltage x current, that would gives us a pretty good watt measurement, wouldn’t it? Total watts-hours used can be calculated and used just like total mah already is. So that covers measuring “fuel used”.

Watt-hour capacity would again be somewhat fuzzy for non-smart batteries. a 4S 5000mah pack would be 84 watts, right?

19

I believe so. Should be pretty easy.

Hard to say what will be the error. I still believe error will not be very big, thus will be usable. Because estimating by MAHs are usable for me. Estimating by Watts anyway should be more accurate.

It depends on vehicle and fly style, I think. Because same as with MAHs: bigger discharge current means less Watts battery will give. And wise versa.
Measuring consumption in hower should give some median value for your copter.

20

Sergey is correct. At higher discharge rates more of the battery’s energy is converted to heat and lost. However, for a particular vehicle design, the discharge rate is fairly constant over a flight with a mix of hovering and forward flight. That’s why I measure it with my Doc Wattson power meter and know what it actually is. I can put the meter inline and fly it and it logs the kWh. And I use that for doing my calculations on setting my timers. That way I know exactly what I have with no guessing, no error.

I have no affiliation with this company at all. But their meter is one of the most useful tools for electric RC builders that there is for measuring power consumption, actual power, and determining efficiency of a build design. Unlike the PM’s used on Pixhawk, these meters have very sophisticated electronics and are accurate over the full range within 2% on current and 1% on voltage.
http://www.rc-electronics-usa.com/ammeters/r102-amp-hour-specs.html