Fly-away when failsafe with RTH set and allow_bypass

[chakflying]

Current Behavior

Seems unfortunate that #8673 got ignored, but luckily I have managed to reproduce it, with blackbox log and bloody fingers to prove it! Since the reproduction steps are not exactly the same, I'm opening a new issue.

Steps to Reproduce

1. I have RTH set in failsafe.
2. I am testing and tuning the PID values indoors, by arming with the stick command override.
3. An issue with the transmitter (most likely caused by low battery) caused the RC link to disconnect.
4. The quad was close to the ground, but starts flying backwards toward a wall, getting stuck at a corner, motors started smoking.
5. I managed to pull the quad back from the wall while cutting myself.

Expected behavior

System to fully and immediately disarm when failsafe occurs without GPS fix, even when RTH is set.

Suggested solution(s)

I'm not familiar with the system enough to make such a suggestion.

Additional context

CLI Dump:
https://pastebin.com/eZpQSs26

Blackbox log:
blackbox_log_2023-07-26_183035.TXT

---

• FC Board name and vendor: MAMBAH743 (MK4)
• INAV version string: INAV/MAMBAH743 6.1.0 Apr 21 2023 / 17:37:50 (2d7a057d)
• GNSS: MATEKSYS M10-5883
• Frame: Diatone Roma F5

[breadoven]

Well the drone did the same as discussed in #8673, i.e. it went into an Emergency Landing. However, for some reason it then lost control after 5s or so and powered up. 3s later it's shown as disarmed ... but the motors keep running. Not sure why this is, would need further checking. Although I note it's a H743 board.

[breadoven]

Checking again it simply went into an Emergency Landing because there's no Home Fix. After this the Emergency Landing will just continue until a landing is detected which probably would never happen because the landing detector wouldn't have been activated given the drone never took off. It powered up because the actual vertical velocity exceeded the target descent rate, I can only assume because of ground affect and vibration affecting the vertical position estimation.

One solution might be to simply force a Failsafe disarm if the landing detector hasn't been started by an actual takeoff, i.e. if Failsafe before take off -> disarm immediately.

[chakflying]

Thinking about this, the "disarm" command later is probably because the transmitter recovered from the momentary disconnect, and successfully transmitted the "disarm" switch position. The "rxUpdateRate" in the log also support this.

Does this Emergency Landing feature somehow has the ability to override a disarm command? Seems extremely undesirable and unsafe.

[breadoven]

Disarm is blocked when in failsafe to avoid unintentional disarm due to unpredictable channel behaviour. So nothing to do with the emergency landing just the fact it was in failsafe.

[lida2003]

Expected behavior

System to fully and immediately disarm when failsafe occurs without GPS fix, even when RTH is set.

I think immediately landing is OK to accept, but how to detect landed is what should be really, seriously discussed.

I suspect that current way of GbumpDetection can't recognize above landed fact due to following items:

1. Might be the quad is just milimeters above the ground (or close to the ground). The impact can't make z component larger than 2G.
2. As ground effect, the baro gives a positive altitude, which is ~2 or 3.3 meters height (NOT landed)

So it was never known it have been grounded (on the ground).

static bool isLandingGbumpDetected(timeMs_t currentTimeMs)
{
    /* Detection based on G bump at touchdown, falling Baro altitude and throttle below hover.
     * G bump trigger: > 2g then falling back below 1g in < 0.1s.
     * Baro trigger: rate must be -ve at initial trigger g and < -2 m/s when g falls back below 1g
     * Throttle trigger: must be below hover throttle with lower threshold for manual throttle control */

    static timeMs_t gSpikeDetectTimeMs = 0;
    float baroAltRate = updateBaroAltitudeRate(0, false);

    if (!gSpikeDetectTimeMs && acc.accADCf[Z] > 2.0f && baroAltRate < 0.0f) {
        gSpikeDetectTimeMs = currentTimeMs;
    } else if (gSpikeDetectTimeMs) {
        if (currentTimeMs < gSpikeDetectTimeMs + 100) {
            if (acc.accADCf[Z] < 1.0f && baroAltRate < -200.0f) {
                const uint16_t idleThrottle = getThrottleIdleValue();
                const uint16_t hoverThrottleRange = currentBatteryProfile->nav.mc.hover_throttle - idleThrottle;
                return rcCommand[THROTTLE] < idleThrottle + ((navigationInAutomaticThrottleMode() ? 0.8 : 0.5) * hoverThrottleRange);
            }
        } else if (acc.accADCf[Z] <= 1.0f) {
            gSpikeDetectTimeMs = 0;
        }
    }

    return false;
}

What I have found the event of landing to landed Gbump detection needs 4 requirements:

a) !gSpikeDetectTimeMs && acc.accADCf[Z] > 2.0f && baroAltRate < 0.0f
b) gSpikeDetectTimeMs && currentTimeMs < gSpikeDetectTimeMs + 100
c) acc.accADCf[Z] < 1.0f && baroAltRate < -200.0f
d) rcCommand[THROTTLE] < idleThrottle + ((navigationInAutomaticThrottleMode() ? 0.8 : 0.5) * hoverThrottleRange)

Also there is a comment, but I still really didn't get the idea. I hope someone with the knowledge can give me a light on this:

1. Why z component is below 1G when landed in bullet c)? In physics, it's equal to 1G. Or acc.accADCf[Z] <= 1.0f is more appropriate?
2. Why baroAltRate < -200.0f then moment landed in bullet c)? If it's touch down, the rate will be 0, right???
3. The moment touch donw, why z component is larger than 2G in bullet a)? Any theroy or just experience?

[breadoven]

The landing G bump detection parameters are based on tested values that most reliably verify that the quad has touched down. They are not based on theoretical values. Also ground effect when landing would normally cause the Baro altitude to reduce not increase ... due to the fact the pressure at the sensor increases.

Landing detection doesn't only use G bump detection it also looks at other factors if the G bump wasn't significant enough to trigger it. However, this is irrelevant in this case because landing detection only becomes active after the craft has been detected as having taken off which probably didn't happen here so landing detection was never a possibility.

[lida2003]

The landing G bump detection parameters are based on tested values that most reliably verify that the quad has touched down. They are not based on theoretical values.

OK

Also ground effect when landing would normally cause the Baro altitude to reduce not increase ...
due to the fact the pressure at the sensor increases.

So it's indeed take off. Just check log at 00:21.225 baro 1.0m.

Landing detection doesn't only use G bump detection it also looks at other factors

Humm... Ok Maybe we have to see what other factors in isMulticopterLandingDetected. Good point.

if the G bump wasn't significant enough to trigger it. However, this is irrelevant in this case because landing detection only becomes active after the craft has been detected as having taken off which probably didn't happen here so landing detection was never a possibility.

Is there any flag to indicate if the quad is take off or NOT?