Emergency landing "resets" when barometer altitude reads 0m, BAD on downward sloping terrain: will never land

[rmaia3d]

Current Behavior

When flying without a GPS lock and a radio failsafe happens, instead of engaging RTH mode, Inav enters into emergency landing mode. That's ok, because without GPS lock it's really hard to know how to return to home.

However, the problem is that once the barometer altitude "reads" 0m and a landing hasn't yet been detected, Inav punches the throttle for a climbout before trying to land again.

This is VERY BAD if flying over downward sloping terrain, as the ground will never be reached in the landing mode, because it will be in a negative altitude with relation to the home altitude.

In simpler terms, "emergency landing mode" doesn't land the model. It keeps the model flying indefinitely.

This happened to me yesterday, on Inav 7.0.0RC2. My GPS was having trouble getting a lock, but since I just wanted to do some PID tuning and keep it nearby, I bypassed the no-gps arming lock and flew. Midway through the flight I had a radio failsafe and it entered into emergency landing mode. The quad was less than 300m from me, over an open field, so I didn't worry. I would just walk over there and pick it up once it landed. But since the field was downward sloping, it never landed. Instead, it entered into that ping-pong between 0m and 40ish meters (baro altitude) until the battery ran out, while drifting with the wind. The quad ended up in a patch of trees around 2km from the takeoff point.

Steps to Reproduce

1. Set failsafe to RTH mode
2. Fly without a GPS lock
3. Enter radio failsafe over a downward sloping terrain
4. Watch helplessly as the quad ping-pongs being blown away by the wind until the battery is drained and it finally doesn't have enough power to climb and ends up crashing or hitting some obstacle.

Expected behavior

When in emergency landing mode, it should descend until a landing is detected (or some obstacle is hit), regardless if the landing will occur in a negative altitude relative to the takeoff. Relying on baro altitude for "ground detection" is not the best idea, specially if the area is downward sloping. Also, baro altitude can drift a little during the flight, so it isn't reliable or precise enough to detect ground.

Suggested solution(s)

Remove the check for "0 baro altitude" when in emergency mode. Let it descend until the accelerometer based landing detection triggers.

• FC Board name and vendor: Matek F405 miniTE
• INAV version string: Inav 7.0.0 RC2 (though I don't think this behaviour is specific to an inav version)

[MrD-RC]

Without LiDAR, what you’re asking is impossible. The ground level is unknown, as the baro is 0 set at the altitude when you arm.

A quad could potentially just lower until it hits a bump. But for other platforms that would not be good. Depending on the terrain, it could be gliding down for a long time. I see this as an edge case as the GPS failed. I which case the correct action should have been to return home and fix the issue.

[rmaia3d]

Exactly! The ground level is unknown, that's the reason why it's a VERY BAD idea to try to guess it from the barometer.

Emergency landing is that, emergency. It should descend until it hits a bump, regardless of the altitude. It is not impossible, it's just common sense.

Please elaborate more on why it woudn't be good for other platforms. Do you really think the ping-pong behavior is better and acceptable under these circunstances?

[sensei-hacker]

@rmaia3d I'm testing a fix for this. If I give you a target file, would you be able to test as well?

[sensei-hacker]

A quad could potentially just lower until it hits a bump. But for other platforms that would not be good.

What would you think an airplane or other platform should do during Emergency Landing, after it gets close to the home altitude? Given that we're in emergency landing state - RTH is probably not possible.

What I just coded is after it nears the home altitude, while performing an emergency landing, it continues to descend gently.

footnote - "approaches" the home altitude because the baro isn't perfect - "0 meters" might actually be 1 meter.

[MrD-RC]

Exactly! The ground level is unknown, that's the reason why it's a VERY BAD idea to try to guess it from the barometer.

Emergency landing is that, emergency. It should descend until it hits a bump, regardless of the altitude. It is not impossible, it's just common sense.

Please elaborate more on why it woudn't be good for other platforms. Do you really think the ping-pong behavior is better and acceptable under these circunstances?

Personally, I don’t think anyone needs to get in to that circumstance. You choose to continue to fly after you developed a GPS issue. I agree it needs to land. But this whole situation was avoidable.

With fixed wing, it’s not the same as with a quad. There is protential for it for it to glide for miles before actually reaching the ground. A circular decent, without knowing the ground height can also end badly.

[rmaia3d]

Exactly! The ground level is unknown, that's the reason why it's a VERY BAD idea to try to guess it from the barometer.
Emergency landing is that, emergency. It should descend until it hits a bump, regardless of the altitude. It is not impossible, it's just common sense.
Please elaborate more on why it woudn't be good for other platforms. Do you really think the ping-pong behavior is better and acceptable under these circunstances?

Personally, I don’t think anyone needs to get in to that circumstance. You choose to continue to fly after you developed a GPS issue. I agree it needs to land. But this whole situation was avoidable.

With fixed wing, it’s not the same as with a quad. There is protential for it for it to glide for miles before actually reaching the ground. A circular decent, without knowing the ground height can also end badly.

Avoidable or not is not the issue here. The issue is that "emergency landing" mode doesn't work as it should. It doesn't land the model.

Doesn't matter the reasons that made emergency landing mode engage. Once engaged, it should bring the model down. Period. It should not try to outsmart itself and try to guess where the ground is based on unreliable data and flawed assumptions.

This is a DVR excerpt from the flight in question. Do you REALLY think that this is acceptable behavior? Do you really think emergency landing mode should keep flying the model indefinitely like this? Really?

https://youtu.be/OYLoO0Xz-sk

[rmaia3d]

What I just coded is after it nears the home altitude, while performing an emergency landing, it continues to descend gently.

footnote - "approaches" the home altitude because the baro isn't perfect - "0 meters" might actually be 1 meter.

Yes, that's exactly how I believe it should work. It should keep descending until a sizable bump is detected meaning it hit something (which could either be the ground or an obstacle). The barometer data could be considered as a guide to when to reduce descent rate, but never as a "hard floor" which stops the model from descending. It's an emergency, it's a controlled crash anyway.

As for testing, I really don't know how it could be done "safely" (meaning there's a way to regain control and abort the test if it starts ping-ponging) in the real world. Probably better to test in SITL first, not?

[sensei-hacker]

It's an emergency, it's a controlled crash anyway.

As for testing, I really don't know how it could be done "safely" (meaning there's a way to regain control and abort the test if it starts ping-ponging) in the real world. Probably better to test in SITL first, not?

Yeah I'll be testing with HITL.
After HITL, perhaps it could be tested by putting a metal soup can over the TX antenna, while the aircraft isn't that far away. (With TX power set you a reasonably low level). If you want to regain control, toss the soup can. :)

[breadoven]

The way it should work is you descend at the emergency landing descent rate until close to takeoff (the emergency descent speed as a distance + 5m). After this the descent rate is supposed to ramp down to 1 m/s at 5 m and after this remain in a 1 m/s descent as you descend further.

Not sure why it's doing the ping pong thing instead. There's a constraint on the desired descent rate that limits it between 1 m/s and the absolute value of the emergency descent speed setting with the direction fixed by the demanded descent rate direction which in this case is -ve the emergency landing descent speed setting. So it should have just continued to descend at 1m/s below takeoff altitude. I did test it on multirotor and it seemed to work OK but then I probably didn't test it below takeoff altitude.

A log would be useful ... check navTgtVel[2] and navTgtPos[2].

#9471 should fix this if it's a bug. It does a similar thing, fixes the descent rate at 1m/s when within 5m of takeoff altitude.

Edit:
Actually looking at the video I think this is a control problem caused by the sluggish response of the altitude measurement. When it descends to 10m it applies power to slow down to 1m/s. However, the estimated vertical speed value doesn't respond for some time so the power is applied for too long causing a climb rather than a slow down. By the time the vertical speed has reacted the quad is climbing at which point power is cut and it descends again. Even when climbing rapidly the vertical velocity never goes +ve, it's always <=0. This lag messes up the control logic. I'd expect the vertical velocity to react faster than that so not sure what the issue is this case.

[rmaia3d]

The way it should work is you descend at the emergency landing descent rate until close to takeoff (the emergency descent speed as a distance + 5m). After this the descent rate is supposed to ramp down to 1 m/s at 5 m and after this remain in a 1 m/s descent as you descend further.

Yes, that's exactly how I think it should work. Using the baro data as a guideline to reduce vertical speed is perfectly aceptable (IMO), but it should never be used as a ground detection feature. Even if slowed down, the descent should continue until a physical bump is detected by the accelerometers, regardless of altitude. It could use the same logic already implemented for the "disarm on landing" feature.

A log would be useful ... check navTgtVel[2] and navTgtPos[2].

Unfortunately the FC (Matek F405 mini-TE) only has a small (16Mb) onboard flash chip and no SD slot, so this flight wasn't logged.

Edit: Actually looking at the video I think this is a control problem caused by the sluggish response of the altitude measurement. When it descends to 10m it applies power to slow down to 1m/s. However, the estimated vertical speed value doesn't respond for some time so the power is applied for too long causing a climb rather than a slow down. By the time the vertical speed has reacted the quad is climbing at which point power is cut and it descends again. Even when climbing rapidly the vertical velocity never goes +ve, it's always <=0. This lag messes up the control logic. I'd expect the vertical velocity to react faster than that so not sure what the issue is this case.

Very interesting observation!! I didn't notice this beforehand. A lag like that could defenitely mess up the control logic, you are completely right!

Let's assume this was the problem. How could the control logic be made more robust to this kind of lag?

Edit:

I looked again at the video and even though the vertical velocity OSD field never goes above 0, specially on the climbs, the interesting thing is that the Altitude field does exhibit positive deltas while climbing. If the vertical velocity was simply a difference between altitude at a previous timestamp and altitude "now", it would display correctly. However, since it didn't, that leads me to question how is that vertical velocity calculated? Would it be trying to integrate GPS data as well, which being essentially invalid, did throw off the calculation?