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.
2 Likes
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.
1 Like
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.
Is that correct? Something else?
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.
@Pedals2Paddles good plan. Can’t wait to test first results 
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:
Children of the magenta…
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.
1 Like
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 
“Having an entry in the ground station for the current winds aloft and speed” would be a great idea.
We fly measurement circles around objects of 500m diameters at times, and there I can see that wind is a considerable factor, and that this definitely affects the “coming home time”.
While having a say in RTH decisions by the software may be desirable from a pilot’s perspective, in automated missions, I would prefer having an automated reaction (for a battery fail safe situation) at least as an option.
Another good reason to be able to add wind data (maybe even coming from an automated station on site) before take-off, would be to have an estimated distance on hand in case of a fly-away/ loss of control/ loss of link. When operation in or nearby controlled airspace, I need to be able to notify the next tower of a drone gone rogue. And the better the data, the more helpful this information is to them.
So as you consider fitting parameters, it would be great if the above scenario could be factored in as well, at least in future iterations.
Does the firmware not compute distance from launch at all times? Or is that done in the ground station software? I’d have to look at the MavLink messages. I use Tower in the field and in the upper bar of Tower it shows how far the aircraft is from the launch point at all times. I don’t know if that is coming from MavLink or if Tower is calculating that?
I was sure it was done in the firmware because there is a distance to next waypoint in the MavLink messages. But now I’m not sure about distance to launch point.
Distance from home is always known by the vehicle and communicated to the GCS
The distance from launch should be known and displayed, correct. Yet a benefit of being able to factor in wind data I would see in being able to inform the tower/ other airspace users of a well founded estimation of projected distance a rogue drone could travel.
An example to illustrate:
Say, I know a multicopter with a given set of batteries can last 12 mins before it goes down.
I am 4 mins into an automated mission, and something goes wrong - drone heads straight off NW (to “another home”), at 10m/ sec with control loss.
That leaves 4,8 km from where it last was where it could pose a problem, and 8 mins of rogue flight. (Of course I use geo-fencing to ideally avoid that, but…)
Being able to see this data at a glance - with the wind (speed/ direction) factored in - would seem to be a helpful thing in an already slightly stressful situation… The computer would be far faster in it’s calculation, even taking actual remaining battery into account.
(This scenario is not as far-fetched as it might seem. I had been advised to be aware of these types or risk, the necessary calculations and the need to advise nearby towers during a certification day by a very reputable UK CAA-accredited entity also doing manned flight training)
Guys, to be honest integrating wind into this is probably not going to be something I have the bandwidth for. I’m not saying it wouldn’t be useful. But it makes it a lot more complex than I am capable of coding. And it also makes a failsafe far more complicated than I believe it should be.
Estimating a fly-away and communicating information to the FAA is not even on my radar, but that does sound neat.
It is the same here in the US. Flying in an airport control zone, or within the 5 mile radius of a non-tower controlled airport, we are required to be in contact via UNICOM or Approach Control at all times during the flight, notify start and end of the flight, and position, heading and altitude of the aircraft as required, via radio. This is only allowed for Part 61 certificated commercial pilots, Part 107 pilots are not allowed to fly there unless given express permission by the airport or approach authority ahead of time.
Matt, not a big deal. Getting the fuel burn time/distance thing right is primary, which would be a huge improvement over how it works now. The wind calculations can always be added later when we get time to look at how to implement it. The thing with ArduPIlot is that it uses GPS ground speed for flight planning so the time over distance will be pretty close. Only the fuel burn will be off, say in the instance of a headwind during RTL or failsafe. But that can be compensated for in testing by setting a time “safety buffer” when the warning, failsafe, whatever, is activated. It’s far better to have your aircraft return with 30% fuel left in the tanks than to have it crashed a 1/4 mile from home because it ran out of fuel. Anybody that would attempt to cut it to the last minute is going to run out at some point, wind or no. Despite all the regulations on it in real-world full-size, it remains the primary cause of off-airport forced landings in general aviation.
This C-180 crash landed in my soybean field 3 miles from the airport. Fuel tanks were bone dry.
https://photos.app.goo.gl/ovA2ibY7Y3fnQfdH3
Think we can come up with tools for our RC aircraft to make it better because our worst fear flying auto flights is having it go down because it ran out of fuel (or battery).