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.
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.
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.
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.
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?
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.
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
Another thing I just thought of is an auto-learn for the information is needs. ArduCopter already can auto-learn it’s hover throttle level. So it seems like I could have it auto learn the power consumption rate required to climb, cruise, and descend in RTL too. Then there would be no need to interpolate logs to figure out values to hand-enter.
Yep, that should be easy enough to do. The actual power is simply amps x volts with DC. That calculation is trivial. I don’t know how accurate the PM is, but it should be “close enough” to come up with a linear fuel-remaining estimation and do a distance/time on remaining fuel, which would be awesome.
So the system looks at the situation and we’re 10km from home. The system knows the best cruise efficiency is 40 km/hr, no wind, so it’s going to take 15 minutes to get back home. And it does this calculation continuously in a loop, always keeping track of it. Just like flying and filing a flight plan for a real full-sized aircraft, you could even have an entry in the ground station for the current winds aloft and speed, which is standard calculations and data for real-world flight plans. And the ground station uploads that to the flight controller during pre-flight so it can use it in its calcs.
All this time it knows how many minutes of fuel we have left remaining, and when the point of no return is reached with say a 3 minute cushion it sets off an alarm on the ground station, signifying to the pilot that he or she has a decision to make.
I take all this from the real world of flying manned aircraft. When filing a flight plan fuel is not put on the flight plan as gallons. It is expressed in hours and minutes of flight time. And the fuel burn for that aircraft is a constant, taken from the flight manual. It is based on what cruise power setting you are using, airspeed, and density altitude. It is all tested parameters required for certification of the aircraft. I don’t see that RC ones, flying scale cross-country flights, should be any different. And in my experience, they aren’t.
It would be nice to be able to have manually entered parameters for liquid-fueled aircraft, which I primarily fly. It would work with those too. All you need is params for “units” of fuel onboard (can be watt-hours for electric, gallons for gas), what the fuel burn is per minute, and set the RTL speed to your best cruise efficiency. That’s the only three things required to know - the software could do all the calculations from there.
While you could do a “learning” thing with electrics, I would view that as more “hand holding” and room for error. I prefer real-world tested parameters, just like full-sized manned aircraft use. And the testing to come up with those numbers is not real complicated and should be part of your build anyway for a cross-country aircraft. I do it by flying them under controlled conditions in figure 8 loops about 1.5km end to end at various speeds to measure and determine best cruise speed vs flight time and fuel burn, both upwind and downwind. Crosswinds will affect a multi due to frame angle required to counter it. Crosswinds do not affect helicopters and fixed-wing airplanes significantly. Heli’s simply lean into the wind and fly with no loss in efficiency, adusting the cyclic pitch as necessary for heading and roll/pitch attitude. Fixed-wings “crab” into the wind with just a very slight loss in efficiency. Multi’s burn up more power with three thrust vectors and combined frame angle countering the crosswind, angle required to maintain forward flight, and vertical for altitude.They do not go into ETL like helicopters do because the blades in the back are working in turbulent air and tip vortices off the blades in front. And they do not have CCPM capability, requiring radical frame angle to go anywhere. So the calculations for multi’s get considerably more complicated when using winds aloft conditions. You can try to “learn” it for a multi, but unless the learning routine knows what the wind conditions were at the time of “learning”, the values it learned may not be accurate.
I’ve been going to do something like this for a very long time. If you put something together please merge it with your GitHub repository, as I would like to merge it with mine and test it on both electric and gas helicopters.
Been watching this thread with interest and picked up on the winds aloft issue… Here are my thoughts:
The DIRECTION of wind would be a big variable in RTL. For example, if you had a 15kt headwind going out, that would be a 15kt tailwind coming home (unless you come home from a different direction, but for simplicity I am using a straight out-straight hom scenario). Essentially, they would cancel each other out, but more fuel would be used going than coming. That would skew any calculations we made in flight and render them inaccurate. So here is a thought that could help…ignore if I’m full of crap
Why not, as part of the calculations, have the copter take off, go up to operating altitude, and do a quick estimate of wind speed and direction, then plug that estimate into the other calculations. It would be one of the variables. How to do the estimate?
Well, once operating altitude is reached, tilt the copter into the 4 cardinal directions (North, East, West South) or for more precision use 8 directions. Then, depending on how much tilt was required to hold that position, calculate which direction needed the most tilt. Most tilt = wind direction. Also, the amount of tilt would be used to estimate wind speed.
Since more “fuel” is burned going into the wind, it isn’t a direct linear return to land calculation that would tell you how to return with the required amount of fuel on board, because if you want to begin your return when 50% of fuel remains, it took more power to go than to return, and if you used a strict linear equation, you would actually be shorting yourself and have a higher percentage of fuel remaining when you land than you initially wanted. This is good from a safety point of view, but again, if your target is to have an exact percentage remaining, then you have to be able to dynamically change the RTL set point while in flight, OR do an initial estimate for that set point when you calculate the wind speed and direction at the beginning of your flight.
I like the idea to do the auto learning, but I also agree with @ChrisOlson that power consumption in a steady-state flying mode will be always more or less the same (for the same copter).
My concern is that learning of climb, RTL may be tricky.
Anyway, looks like we’re going to lost in discussion because we’re talking about how to do a thing, but it’s unclear what we’re want to get.
That are the goals (as they looks from my side): Estimator
To see how long (in minutes) I can fly with current speed. I.e. just battery_remaining / actual_consumption
To see how far (in minutes or/and in meters) I can fly away from home (with current speed) before I will reach point of no return. Point of no return must be calculated here with an assumption that return will be performed in RTL mode.
Failsafe
To alarm when point of no return is close
To enable RTL once point of no return reached. But this feature must be optional.
I agree. This has become far more complicated that I was originally planning. But I think breaking it out into three new components is probably the best and most robust approach:
Add live watthour consumption rate and running total of watthours consumed. Similar to the existing live and running total MAH we already have. This will use ArduPilot’s new resting voltage live calculation rather than the traditional loaded sagging voltage. This should provide a far more accurate measure of fuel consumption. I think a new parameter for full charger watthour capacity is needed so it knows what constitutes full. For the smart batteries, I can have it auto-fill that.
Add estimator. Basically as described by @sergbokh. Use the above watt information, distance, altitude, home location, WP_NAV and RTL settings to monitor time and watts to home. Optional GCS notification when you’re nearing bingo fuel.
Integrate with battery failsafe. Failsafe action triggers when bingo fuel is reached.
I think this is spot-on for what we are trying to do. It would achieve the desired result. I have some thoughts on how to do it, but I want to think those thru thoroughly before outlining them here. I would like to see this work in Copter for both helicopters and multi’s both electric and combustion engine. And the two types of aircraft in Copters are significantly different in that helicopters are like airplanes - they have a most efficient airspeed. Multi-rotors are a special use case that are hovering machines, and any airspeed at all makes them less efficient.
I need to look back thru my notes and figures on all the testing I have done on quadrotors, tricopters and helicopters to make sure that the numbers and method I present on how to calculate it is accurate.
I do know that it is not as complicated as you think.
Yes, but not to confuse: You either can configure this parameter basing on your charger indication (but this requires both charger and current sensor are calibrated precisely).
Or you can just do a test fly to dry out your battery and then see in logs what is the summary watt-hours used. This value will be more accurate for the estimation task.
That fact does complicate calculations because there is a curve dependency for the efficiency. Especial for combustion engines where the current fuel flow is unknown…
I think “Power” and “Energy(Work)” can be very confusing.
Power = Enery per unit-time
Power Unit = Watt (Joule per second)
Energy Unit = Joule, Calorie, Watt-hour (energy over time multiplied by time = energy)
Energy describes battery capacity.
Power describes aircraft’s consumption.
A 10,000 Wh (Watt hour) battery can theoretically runs a 1,000 Watt motor for 10 hours or a 100 kW motor for 6 minutes.
That happens to be the exact principle I refer to. And it is the same for electric or liquid fuel, except for liquid fuel it is a measurement of volume, and the engine burns a certain about of volume per unit of time.
I actually have notes from my testing of various types of aircraft, flying both upwind and downwind, and crosswind. I will review all that this evening and see if I can come up with an efficiency scaling factor that can be used for winds aloft calculations. The problem comes in where ArduPilot flight-plans in GPS ground-speed units. The efficiency of aircraft is based on airspeed units. If you have a solution to upload the winds aloft figure (speed and direction) during pre-flight, I know it will work. Because I do it all the time using my ancient Kane Aero slide-rule Dead Reckoning Computer. These days youngster pilots use phone apps or dedicated electronic units. But us old-timers that been in aviation for 30+ years still use these things. And they work every time, and just use simple vector math:
Matt, what I see in my notes with my 600mm quadrotor is that I get a 5.8% increase in power consumption from hover to 10 m/s. Actually, 0-3 m/s does not make much difference. And more difference from 3 - 10 m/s.
With the 600 electric helicopter, 13 m/s most efficient cruise, power consumption drops by 7.7% from what it is in hover. This would be a negative scaling factor of -0.6% per m/s of airspeed using linear values (which I think are “close enough”). Faster than 13 m/s it appears to increase at about the same rate as a multi-rotor, reaching parity with hover power at about 19 m/s airspeed. I think helicopter pilots would have to take this into account flying at high speeds.
I think efficiency scaling could be done with a user-entered value, making it default of 0.6% (per m/s increase in airspeed) for multi’s, depending on other folks may have for values from their aircraft. And helicopter pilots could enter a value based on testing of their aircraft. With electrics it’s really simple. Hover it, then fly it at 10m/s. Look at the logs and see what you got for voltage and current in the two extremes. The difference in percentage, divided by 10 is the scaling factor.
Altitude:
I don’t think it makes any significant difference. The adage is that what goes up, must come down. In real world flight planning for climb to cruise there is tested and certified values for climb power settings and airspeed. That kind of testing is not done for RC because our altitude is usually limited ~120m over terrain. In a RTL situation I think the increased power consumption from current to RTL altitude is pretty much a wash with the reduced power when the aircraft descends to landing during the final stages of RTL. I have not actually tested this, but that is my gut instinct. The only way altitude could make any difference is with an aircraft (such as fixed-wing) that has a fairly decent glide ratio. Which does not really apply to rotary wing. My logs show equal parity between increased power consumption in climb to altitude vs reduced power consumption on the way back down. Thoughts?
We need a “buffer”. In real world for VFR flight planning in the US, FAR 91.151 stipulates that no pilot may begin a flight unless consideration of wind and weather will allow the flight to reach the planned destination with enough fuel to cruise for 30 minutes at a normal power setting, or 45 minutes at night. I think for RC aircraft it should be no different. But should be user settable. So if the user wants a 2 minute reserve when the warning goes off, he/she can set a param for that.
And finally we need a wind speed and direction calculation.
For headwinds, the flight planned ground speed plus the wind speed is actual airspeed. And power consumption goes up by the airspeed scaling factor. For tailwinds it is the other way around. For a headwind that is, for instance, 45 degrees off the nose, the actual headwind speed is 1/2 of the actual. It is vector math.
I do not think that tipping the machine in various directions to “learn” windspeed is going to work because the amount of tip will vary with the design, size of props, disc loading, length of arms on a multi, etc… My thoughts are that it needs to be part of pre-flight on the ground station. Enter the wind direction and speed. Most everybody is able to estimate wind speed and direction, and it does not change appreciably below 150m above ground. The wind becomes “cleaner” and more steady at higher off the ground because you have ground roll and turbulence that causes gusts. But the peak wind gusts on the ground are usually what you have aloft at less than ~150 meters altitude. Pilots have been using wind socks at airports to estimate wind speed and direction virtually since aviation was invented. The bad part about this is that it would require some mods to the ground station applications to be able to enter it during pre-flight. But for testing, params could be made and set manually for it to see how it all works.
So, while I hate to add more params, this is the list of params I think would be needed:
Power - set to the hover power in watts (or fuel consumption/hr for liquid fuel).
Fuel - set to watt-hour (or units of volume for liquid fuel). Watt-hours for all batteries is cell nominal voltage x number of cells x rated amp-hour capacity. Cell nominal voltage for all LiPo’s is 3.7
Fuel Reserve - set to the time in minutes that the user desires for a “safety buffer” to calculated zero fuel remaining when the low fuel/vs distance warning (or auto RTL) goes off.
Power Scaling Factor - set to the percentage increase/decrease in fuel consumption for your aircraft for every m/s increase in airspeed. Can be either negative or positive, depending on aircraft type.
Wind Direction - set to the approximate direction the wind is coming from in degrees
Wind Speed - set to the approximate wind speed in m/s - used for airspeed calculations based off the current GPS ground speed.
The RTL speed should always be set to the most efficient cruise for the aircraft. Even multi’s have a speed where they will cover the most distance for the energy used. Since the calculations know what it is (as long as it’s not zero, in which case it will use the WPNAV_SPEED), and can take the wind and power scaling factor into account, it doesn’t really matter what it’s set to. If it’s 5 m/s it’s going to take longer for the aircraft to get home than 10 m/s, and the calculations are going to come up with the warning much earlier. It can always be “tweaked”. The main thing we don’t want is overly discharged and puffed batteries, or aircraft crashing because they run out of fuel. I do think a much closer estimation can be made using energy and power with time over distance vs the current system of mAh and voltage.
So that’s my thoughts on how I would do it - a lot of them taken from flying full-size aircraft. It would be interesting to hear some more thoughts on how to improve it.
I assume the remaining time and battery/fuel will be displayed on GCS. IMO it’s fair to have different accuracy based on data known like 5:30±1:00, 1km±200m.
Simplest way for basic users might be to enter flight time then deduct/add using current reading.
Just one more technical note (may be it is obvious thought):
I suppose that sampling rate of voltage and current readings are relative high in the ardupilot.
So there will be a short peaks of power.
These peaks must be accounted when calculating battery remaining energy (nothing special here).
But, the peaks must not affect on estimation. I.e. estimator must calculate the average power for last 2-5 seconds and do the estimation basing on that average value.
Otherwise any momentary peak could trigger failsafe
