FAILSAFE - RTH

[MaxMihawk]

Current Behavior

Dangerous behavior. Failsafe RTH / RTH ends up in a crash. The compass seems to have an error. Getting back control doesn´t work. Even a disarm doesn´t change anything.

Steps to Reproduce

1. Use Failsafe RTH
2. Diarm (3. if you want the full schnetzmachine mode, you need a compass error too)

Expected behavior

A disarm should end in a quad drop. Something that handles a compass error without having the risk of a crazy flying uncontrolable schnetzmachine would be nice too.

Suggested solution(s)

If the compass does not change but the gyro says something else, maybe their is something wrong. Is a plausibility check with the gyro or gps possible?

Additional context

If you see this video, keep in mind... after the RTH starts, i don´t control anything on the RC. This is full autonomous INAV flying behavior (with a not 100% working compass): https://youtu.be/2cafmbl2WLE

After the quad moves from HOME point, I switched failsafe of to normal mode (and checked all switches to be on normal mode). It doesn´t change anything, so I hit the arm switch to disarm. And the quad keeps flying and change direction, and keeps flying and change direction again.... and luckily crashes in the end. This could get horrible wrong.

---

• FC Board name and vendor: MAMBA F405 MK2
• INAV version string: 2.3.0 (stable)
• GPS/Compass: BN-880Q (=QMC5883)
• Baro: BMP280

[issue-label-bot[bot]]

Issue Label Bot is not confident enough to auto-label this issue. See dashboard for more details.

[hali9]

I had this behavior when the motherboard produced a lot of electrical interference. But I used RTH (not failsafe) and I could turn off RTH at any time. If you use the switch to trigger failsafe and you have the failsafe set to RTH, then after turning the switch off you must move the sticks to take control. Failsafe ignore arm switch, so it is intendent behaviour. Failsafe ignore also all aux channel, aux are frozen in last trusted position.

If the compass does not change but the gyro says something else, maybe their is something wrong. Is a plausibility check with the gyro or gps possible?

There is a sanity cheking, see nav_rth_abort_thresholdbut default is 500m. So Your quad should emergency landing about 500m from place when start RTH.

Maybe put blackbox log if You have.

[MaxMihawk]

Thank you very much for your answer. I put several switches to on and off and used the sticks, so I fumbled arround and you may be right. The logfile has a bad resolution and ends at the disarm... If the disarm was the first or the last on, i can´t tell you (I disarmed definitly several times). The flight ends for the FC with an "battery disconnect" in the crash.

Find the blackblox log attached (it was 13% resolution i think).

blackbox_log_2020-01-12_125740.TXT

PS: If the aux channels are frozen at the moment of failsafe, thats why i can´t find alle the stick commands in the log file after RTH? I switched althold / poshold back to normal too and can´t find it in the logs.

[stronnag]

you need to fix the compass, it reads c. 170°regardless of the actual direction of the craft. iNav tuning 101. https://github.com/iNavFlight/inav/wiki/GPS--and-Compass-setup

At least for the first part of the flight. Then it's somewhat random.

[MaxMihawk]

@stronnag Yes, my compass has a problem. Can you tell me, where the interference is coming from? I´ve still not found 100% clear which signal is disturbing it in the blackbox log.

[stronnag]

There can be a number of causes (including):

• Current (cables near compass)
• Excessive vibration

At a guess, it's current related, the ever-increasing circles in (green) PH mode are typical of such mag problems, self-inducing to some degree, as the oscillations increase, the FC uses more throttle trying to counter it, causing more interference. Rinse, repeat, rescue the quad from a tree.

[stronnag]

The sensor failure happens at the very end, most probably as a result of impact with the tree; it's not reported during the flight:

$ inav_hw_status.rb -i2 blackbox_log_2020-01-12_125740.TXT 
Using states for 2.0.0
iNav version = 2.3.0 (states eq 2.0.0)
00:0.00 (0.000s) HW Status change (155 341) status: OK
gyro    OK
acc OK
mag OK
baro    OK
gps OK
rangef  none
pitot   none

03:13.29 (193.293s) HW Status change (175 373) status: Failure
gyro    OK
acc OK
mag unhealthy
baro    OK
gps OK
rangef  none
pitot   none

03:14.08 (194.081s) HW Status change (275 629) status: Failure
gyro    OK
acc OK
mag unhealthy
baro    OK
gps unavailable
rangef  none
pitot   none

[MaxMihawk]

The GPS was disconnected after crash.

The GPS / mag is on top of the quad. Beyond their comes plastic, then carbon, then the VTX, then the FC, then the 4in1 ESC, then Carbon, then the battery. I think, it has to be current too. But their are so much distance and other components between. The nearest radiation unit is the vtx and i thought it´s sending nearly constant signal. So the mag should be irritated from the beginning. So it has to be the wiring, right?

Thx for the analysis.

PS: How you get the map view?

[MaxMihawk]

It can´t be the wiring, because I2C is a bus and the same wires containing the information of the baro. The baro is changing altitude while the mag is locked. If the mag is connected and healthy, their is a big magnetic field beyond the sensor (in some cases) or their is a bug. I´ll change position as much as i can and then i try again.

I still don´t understand the acceleration of the quad, after it arrives at the home coordinates.

[stronnag]

PS: How you get the map view?

mwp, blackbox replay mode.

It can´t be the wiring, because I2C is a bus and the same wires containing the information of the baro. The baro is changing altitude while the mag is locked. If the mag is connected and healthy, their is a big magnetic field beyond the sensor (in some cases) or their is a bug. I´ll change position as much as i can and then i try again.

mwp also has a naive compass anomaly detector; when that fires, as it does replaying your log, there is a problem. From experience of > 1000 RTHs, I'd be surprised if it's an iNav bug. Here you can see (red box) a > 80° difference from the compass and GPS indications of "heading"; from the track it appears that the GPS is correct and something is causing erroneous compass values.

[brainbubblersbest]

You should try free mag alignment as described in INAV Wiki. After Calibration, Values in Sensor Tab must match at every axis in relation to the Ground, if you flip that axis. BN880 has cw270Flip Alignment.

eg; Quad flat on Table If Z - has Value -50 (can vary) and you Turn Quad Headover this must change to near +50. same with X and Y. +50 if Front heading in the Sky -50 if tail heading to the sky than with leftside up, right side up

If max Values are Reached with the Axis is not straight up, (light tilted to side) Than you can try with edit the pitch and roll values a bit, (reduce at 50 or add 50 for 5degree) than recalibrate and go to sensors tab and retry.

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[stale[bot]]

Automatically closing as inactive.