Engine burned after RTH procedure started

[Macianno]

Current Behavior

After crash and lost rx signal, failsafe RTH procedure starts engines and try to fly back home, but it is not possible because quad is stuck in bushes or other crops - this is a reason of rx signal lost. It tries to fly so long until engine(s) are burned. It happen to me third time today and every time when it happen crash is safe for a quad hardware (soft crash in the crops or bushes), but when RTH procedure starts, engine burn occurs. There is blackbox log from my last flight

LOG00015.TXT

Steps to Reproduce

1. Set failsafe mode to RTH.
2. Fly normally, then fall on the crops, bush or on the ground but upside down. Props can rotate, but with big load.
3. Turn off transmitter
4. FC try to come back home but it is impossible because quad is locked somewhere in the bush, crop field or it is upside down.

Expected behavior

I like to have RTH procedure when I lost rx signal in the air, but quad should stay where it is after crash.

Suggested solution(s)

Add crash detection or engine lock protection.

Additional context

I already tried to find solution for this on github but all issues was marked as closed without any solution that I can understand. There is a dump file attached: https://pastebin.com/EBVwrwvc.

---

• FC Board name and vendor: SpeedyBee F7 v3 stack with BL32 4-in-1 50A ESC
• INAV version string:

version

INAV/SPEEDYBEEF7V3 7.1.2 Jun 1 2024 / 00:54:34 (4e1e59e)

GCC-10.3.1 20210824 (release)

Best regards,
Maciek

[Macianno]

There is another blackbox log from June. There was a problem with GPS - it lost fix during the flight, then in position hold quad drifted unfortunatelly to the sun (I can not land without googles because I couldn't see the quad), so I triggered FS and RTH with the switch, but FC was thinking that is already on the spot so it started landing procedure. When quad hit the ground with bean crops, then just turn upside down, I lost RX connection just before crash. I do not know why it add more power to the engines when it already landed.

iNav configuration from this flight (dump file): https://pastebin.com/DzhrrHTC
LOG00030.TXT
DVR link: https://drive.google.com/file/d/12GNzWe-Rhrz2plk8hlPhOJHWRsBkcVMT/view?usp=sharing

DVR description:
I flew as usual until 3:00...
3:03 I lost GPS fix
3:11 GPS fix back, but home position reset and stay 0m distance since this.
3:56 PosHold activated and I take off my googles to land. Quad drifted with the wind in the sun direction while I trying to find it on the sky.
4:38 I tried to land with Line-of-Sight but I can not saw the quad, sun blinded me... quad is already far away from place what I expected.
4:44 I turn on FS by switch and quad started landing procedure but it was far
4:48 I started to loosing rx and video signal...
The rest you can see on the blackbox log.

I hope it helps to understand what happen... I already burned 4 engines with that issue.

[MrD-RC]

so I triggered FS and RTH with the switch

You should not trigger FS with a switch. That mode is only there to test the failsafe procedure. You should only use the RTH mode to return home.

[Macianno]

so I triggered FS and RTH with the switch

You should not trigger FS with a switch. That mode is only there to test the failsafe procedure. You should only use the RTH mode to return home.

Yes, I understand this. I just found that both engine burns happened when failsafe RTH started.

[breadoven]

INAV 8 includes inverted disarm for multirotors which would at least help to avoid problems if crashed upside down. Landing G bump detection is also available from 7.0 which wasn't enabled in your case, set by nav_landing_bump_detection. This probably would have detected an emergency/crash landing into bushes so long as it landed upright. It would need something else though to detect that you're in RTH but stuck and not actually moving back home.

The lost GPS signal home reset issue is a bit odd. I thought it was something to do with large altitudes causing some sort of overflow in the code but that's not the case here, altitudes are low. I did notice however that the flight odometer reset from 2.80km back to a frozen odo reading of 2.14 km which corresponds to the odo reading when the previous loss of GPS lock occurred. Might help to work out what's causing this.

[Macianno]

Thank you @breadoven for your observation. I will finish rebuilding my quad today and set nav_landing_bump_detection = ON. Do I understand correct, that this work only when quad fall flat on the ground? I mean: Is this detect G-force peak in Z-axis or also could work when quad hit the ground on front or side?

It would need something else though to detect that you're in RTH but stuck and not actually moving back home.

In my cases is enough just to stay on the ground after crash and do not start RTH. It is different to detect that quad stuck somewhere during RTH flight, ie. tree on the way and different when quad is already crashed/stucked before RTH starts.

The lost GPS signal home reset issue is a bit odd...

Maybe it is good to talk about more in this issue: Zero distance after Gps lost and restore #10360. My observation about GPS lock is that one day it get about 17 satellites and another just 7 is max in the same flying spot. But it is true, as other observed, that since iNav 7 comes, gps lock with less satellites and do this slower generally. I had more than 20 locked even in my house on the bench before. It still fix like that when I connect with GPS with u-Center software. I use FLYWOO GOKU GM10 Pro V3 GPS with compass. I also found that this day (26 june 2024) was unusual solar flares activity. Could that affect GPS signal? I flew 12 packs that day with very good gps fix. This what I described above (with gps issues) was a last one around 7PM CEST.

[breadoven]

G bump detection only works in the Z axis and only at low horizontal speeds so it may not work if you descend upright but with groundspeed.

The GPS home reset issue really needs a log to understand what's happening because it's pretty strange. It's hard to explain the Trip Distance behaviour in your flight. Given how the code works it shouldn't be possible for the Trip Distance to suddenly reduce then freeze given that Altitude and Ground speed continued to work.

[Macianno]

My engine is rewinded now, quad fixed, checked and programmed again. I hope there will be same amount of starts and safe landings ;) Thank you for your time.

The GPS home reset issue really needs a log to understand what's happening because it's pretty strange.

Let' contiunue in gps thread: Zero distance after Gps lost and restore #10360. I uploaded log from flight described above there. If I can help with some tests, just let me know...

[b14ckyy]

@breadoven
I wonder of a disarm trigger would help that detects a Vertical/Horizontal speed error getting too big within a certain time frame, when Failsafe is active, would be enough to detect a stuck quad? For a plane its easy.... if the speed is close to 0 its stuck or crashed. Although blocked motors with bad ESC settings and no proper block-detection, can burn up within 1-2 seconds. Probably nothing we can do about that.

checking for movement or altitude changes to be close to 0 is no option as the quad could hang in a swinging branch. Speed error buildup could work as a trigger.

[Macianno]

What I observed in my crashes: When I hit hard, I can manage manually throttle down and disarm quite fast then. In this situation there is no failsafe. When I hit a bush with full throttle, quad cut some branches and stop - just props need to be replaced. Issue when engine(s) become burned is then, when failsafe (RTH) try to move the quad and it can not move - all engines can rotate but props are braked by something, so engines load is very high and still running. Quad is screaming quite a long time, before engine is burned. Just few seconds before burning ACC readings are very stable and speed is also close to zero.
Strange thing what I observed in LOG0015.txt (in first post of this issue) are the Baro readings increase when engines started by RTH and blackbox analyzer's craft display looks like it is in normal position, but in real it was upside down and totally not moving, just digging a mud with props. After 1 second blackbox recording stops (i do not know why) and I just stay close and think how I can disconnect battery, but it was impossible with rotating props. I can not disarm until the end.