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.
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.