Plane: Improving "is_flying" prediction

[magicrub]

I'd like to hear suggestions on how to make the Plane "is_flying" flag to be as reliable as possible. Here's what it is today in v3.3.0, how can we improve it? Lets brainstorm!

True (we think we are flying) when: airspeedMovement = (airspeed >= 5) gpsMovement = (gps.status() == NO_GPS) || (gps.status() == NO_FIX) || (gps.ground_speed() >= 5)

while armed: airspeedMovement || gpsMovement while disarmed: airspeedMovement && gpsMovement

possible enhancements:

• AHRS stall detection integration
• EKF/DCM state models may have some insight

Land mines:

• what happens when you have spotty GPS?
• what happens before/after you land and it's very windy fooling your airspeed?

On my own fork I'm using the airspeed value of 7m/s since 5m/s can easily happen with an uncalibrated airspeed. It can happen at 7 too, just not very often.

Discuss!

[magicrub]

Other ideas: @tridge added: (auto flight_stage == landing_approach) && (sink_rate > 0.2)

Another simplistic idea is: (airspeedMovement + gpsMovement) >= ??? m/s

[R-Lefebvre]

How about:

After Arming If throttle is above zero Airspeed increases from where it was when throttle was at zero GPS speed increases from where it was when throttle was at zero And altitude increases from where it was at arming

[magicrub]

Good idea(s) @R-Lefebvre. Stuff like that is generally hard to track, I'd like to make it as stateless as possible but if adding memory like this helps then so be it.

[Jman841]

I would also like to see this improved. A few days ago with one of our planes we had an auto landing where the motors kicked on after the plane had landed. This was caused by the altitude estimation drift in the barometer thinking the plane was still 10m above the ground even though it had touched down, and, it seeing increased wind speed due to it being a rather windy day and landing into the wind.

We also had an ESC Failure recently where the pixhawk was putting out 100% and the motor was not doing anything. If using "Airspeed increases from where it was when throttle was zero" in the case of an ESC or motor failure the plane will think it is landed and may turn off stall prevention and make things much worse. Luckily our ESC kicked back on when switching to RTL since throttle went back to 0 before coming back up, but, it may be risky if it thought it was landed?

maybe make the "Is landed" parameter much more sensitive if the next waypoint is "Land"?

Maybe look for an Accel sensor spike, but, only if "Land" is the next waypoint or if altitude is below say 10m or something so it can't be accidentally triggered from turbulence?

[magicrub]

Hi Jman841,

we had an auto landing where the motors kicked on after the plane had landed After a land it will inhibit the motor on flare at the end of a LAND command. Also, there's a LAND_DISARMDELAY param which will allow an auto-disarm after it lands to inhibit this even further. I use the value 2 so it disarms right after a land.

"Airspeed increases from where it was when throttle was zero" Not sure what you're talking about here.

maybe make the "Is landed" parameter much more sensitive if the next waypoint is "Land"? This is actually the only place it can get set!

if altitude is below say 10m or something This is taken care of with the flare which kills the motor. It seems like you're not using the landing command correctly. Can you start a new thread asking about this and include an example mission you have? Lets not clog up this brain-storming thread.

-TomP

On Sun, Jul 5, 2015 at 8:58 PM, Jman841 notifications@github.com wrote:

I would also like to see this improved. A few days ago with one of our planes we had an auto landing where the motors kicked on after the plane had landed. This was caused by the altitude estimation drift in the barometer thinking the plane was still 10m above the ground even though it had touched down, and, it seeing increased wind speed due to it being a rather windy day and landing into the wind.

We also had an ESC Failure recently where the pixhawk was putting out 100% and the motor was not doing anything. If using "Airspeed increases from where it was when throttle was zero" in the case of an ESC or motor failure the plane will think it is landed and may turn off stall prevention and make things much worse. Luckily our ESC kicked back on when switching to RTL since throttle went back to 0 before coming back up, but, it may be risky if it thought it was landed?

maybe make the "Is landed" parameter much more sensitive if the next waypoint is "Land"?

Maybe look for an Accel sensor spike, but, only if "Land" is the next waypoint or if altitude is below say 10m or something so it can't be accidentally triggered from turbulence?

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/2498#issuecomment-118707376 .

[Jman841]

Tom,

Sorry if that was confusing. The issue is the "flare" altitude is set at 3 meters for this plane. Since the planes baro had drifted, it "landed" early of the land point thinking it was over 3 meters. The issue is the "is flying" prediction incorrectly predicted that it was still in the air and needed to go farther forward before initiated the final stage of the land command. This caused the dangerous situation of the motors turning on after the plane was on the ground.

The "airspeed increased after throttle is above 0" is in regards to Robs suggestion. If the power system is not working correctly this could possibly give a false negative for the "is flying" parameter since the autopilot would be requesting power and it would not see an increase in velocity. If that parameter is only activated during the land sequence, it should not be much of an issue however.

[pepevalbe]

Hi all. I think we should also use plane's altitude in the prediction. If relative altitude is high enough (10m? 20m?) we can say plane is flying even if gps.ground_speed is close 0.

As is_flying is implemented right now, crash detection would give a false positive when the plane is "hovering" because of high winds and airspeed is not available.

[magicrub]

@Jaman841, Lidar is your friend, I suggest you equip it. Works great for me on my long flights. I also have a "crash detection" scheme on my fork that I'll be pushing soon which will auto-disarm for you. I had one here https://github.com/diydrones/ardupilot/pull/2404 but closed it because I've re-written it and am still flight testing it. It is in part based on the "is_flying" flag but with other considerations too. However, if is_flying is lying to me then it causes problems which is yet another reason why I'd like to make it more complex by taking in additional considerations into it's decision to be smarter.

@pepevalbe, Using the altitude is not as useful as you think. What happens if the plane runs into a huge tree or a mountain? I've also flown in high winds where a plane was flying backwards while trying to land. I would hate to see he motor turn off during that! As it is implemented now, the high airspeed is what kept is_flying "true" during its' hover via my pitot tube airspeed sensor. I highly suggest you fly with one.

Do you guys fly without a pitot tube?

-TomP

On Mon, Jul 6, 2015 at 4:50 AM, pepevalbe notifications@github.com wrote:

Hi all. I think we should also use plane's altitude in the prediction. If relative altitude is high enough (10m? 20m?) we can say plane is flying even if gps.ground_speed is close 0.

As is_flying is implemented right now, crash detection would give a false positive when the plane is "hovering" because of high winds and airspeed is not available.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/2498#issuecomment-118830638 .

[pepevalbe]

I fly with a pilot tube so it would also work for me.

I didn't mean that relative altitude should be enough to say that plane is flying but it could somehow be used in the calculations. The higher the relative altitude is the more chances the plane is flying.

[magicrub]

AGL is a relative thing with aircraft. If you don't fly with the terrain map, like me, then you don't know if you just climbed a hill.

On Mon, Jul 6, 2015 at 11:52 PM, pepevalbe notifications@github.com wrote:

I fly with a pilot tube so it would also work for me.

I didn't mean that relative altitude should be enough to say that plane is flying but it could somehow be use in the calculations. The higher the relative altitude is the more chances the plane is flying.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/2498#issuecomment-119091954 .

[magicrub]

here's an idea from @WickedShell http://www.cas.manchester.ac.uk/restools/instruments/meteorology/sonic/

[WickedShell]

I mean its impractical I just think they're cool sensors....

[magicrub]

Here's a "now" idea for an is_flying() makeover with crash detection to hold us over while we continue to wait and ponder integrated EKF/AHRS solutions. Everyone, especially you @tridge!, please take a look and comment. https://github.com/Airphrame/ardupilot/commit/986325ac45d740e3d545bba82233ea7de5e5cdf7

[magicrub]

Pull Request pending with a complete makeover https://github.com/diydrones/ardupilot/pull/2607

[magicrub]

@R-Lefebvre I was thinking about your suggestions but they can't work in a linux-reboot environment. The idea of making it stateless allows in-flight reboots. That is a minimum requirement I need to meet.

[magicrub]

Same goes for any relative altitude stuff. If you reboot in the sky then your current altitude is "the ground" which makes it complicated if you're trying to reference from there since you'll most likely being heading into negative AGL after a reboot. I know this is sort of a silly thing because after a reboot you are disarmed so a crash is eminent. I just want to make sure the flag at least is accurately telling you that you're flying as you smash into the ground :)

[magicrub]

fixed via https://github.com/diydrones/ardupilot/pull/2607