RTH it only works if no sticks commands are given?

[robustini]

Current Behavior

Today I found that if I am flying for example in Angle with a copter and I activate the RTH instead of carrying out the procedure that I expect, it starts to descend as if it wanted to land. If I perform the same operation from Position Hold without touching the sticks, ie with the drone in hovering, it does everything correctly. It's normal? I don't think so, if that were the case it would be of little use. I have not tested from Acro, the mode in which I normally fly in FPV, in this tests I was in VLOS.

Steps to Reproduce

1. Fly in Angle at a suitable speed, for example 5 m/s
2. Switch to RTH

Expected behavior

Maybe what I found will happen.

• FC Board name and vendor: ZEEZF7V2
• INAV version string: 3.0.0

MARK4_INAV_3.0.0.txt

blackbox_log_2021-06-04_173124.zip

[wx4cb]

my only guess would be that when you hit RTH while moving it immediately senses your stick positions which will cancel it

[stronnag]

Your machine is in emergency landing mode, most likely due to significant magnetic interference when the craft moves at greater than c. 3m/s meaning that FC canniot determine a safe way home.

[robustini]

Your machine is in emergency landing mode, most likely due to significant magnetic interference when the craft moves at greater than c. 3m/s meaning that FC canniot determine a safe way home.

Thanks for the analysis, I will try to understand what is disturbing the magnetometer, although this is strange because it should be disturbed even when performing RTH correctly.

[stronnag]

This is really not expected, occurs every RTH attempt. Usually symptomatic of a sensor issue; I've not delved deeper than automated tool analysis though/

$ inav_states.rb --index 4 /tmp/blackbox_log_2021-06-04_173124.TXT 
3.0.0 using states for 2.7.0
blackbox_log_2021-06-04_173124.TXT: INAV 3.0.0 (0c541744) ZEEZF7V2
Iteration   Time(s) Elapsed(s)  State   FltMode
        0     58.8  (   0.0)    nav_state_undefined (0)  ARM|ANGLE|LEDLOW|BLACKBOX  
    67936     93.6  (  34.8)    nav_state_poshold_3d_in_progress (7)     ARM|NAVPOSHOLD|LEDLOW|BLACKBOX 
    68768     94.0  (  35.2)    nav_state_idle (1)   ARM|ANGLE|LEDLOW|BLACKBOX  
   105600    112.9  (  54.0)    nav_state_rth_climb_to_safe_alt (9)  ARM|ANGLE|NAVRTH|LEDLOW|BLACKBOX   
   108736    114.5  (  55.6)    nav_state_emergency_landing_in_progress (23)     ARM|ANGLE|NAVRTH|LEDLOW|BLACKBOX   
   112256    116.3  (  57.4)    nav_state_idle (1)   ARM|ANGLE|LEDLOW|BLACKBOX  
   119552    120.0  (  61.2)    nav_state_rth_climb_to_safe_alt (9)  ARM|ANGLE|NAVRTH|LEDLOW|BLACKBOX   
   122287    121.4  (  62.6)    nav_state_emergency_landing_in_progress (23)     ARM|ANGLE|NAVRTH|LEDLOW|BLACKBOX   
   127232    123.9  (  65.1)    nav_state_idle (1)   ARM|ANGLE|LEDLOW|BLACKBOX  
   158976    140.2  (  81.3)    nav_state_rth_climb_to_safe_alt (9)  ARM|ANGLE|NAVRTH|LEDLOW|BLACKBOX   
   160362    140.9  (  82.1)    end of log
Disarmed by: SWITCH

$ inav_states.rb --index 5 /tmp/blackbox_log_2021-06-04_173124.TXT 
3.0.0 using states for 2.7.0
blackbox_log_2021-06-04_173124.TXT: INAV 3.0.0 (0c541744) ZEEZF7V2
Iteration   Time(s) Elapsed(s)  State   FltMode
        0     46.4  (   0.0)    nav_state_undefined (0)  ARM|LEDLOW|BLACKBOX    
    13280     53.2  (   6.8)    nav_state_althold_in_progress (3)    ARM|NAVALTHOLD|LEDLOW|BLACKBOX 
    14368     53.8  (   7.3)    nav_state_idle (1)   ARM|ANGLE|LEDLOW|BLACKBOX  
    54816     74.5  (  28.0)    nav_state_rth_climb_to_safe_alt (9)  ARM|ANGLE|NAVRTH|LEDLOW|BLACKBOX   
    56933     75.6  (  29.1)    nav_state_emergency_landing_in_progress (23)     ARM|ANGLE|NAVRTH|LEDLOW|BLACKBOX   
    60160     77.2  (  30.8)    nav_state_idle (1)   ARM|ANGLE|LEDLOW|BLACKBOX  
    62784     78.5  (  32.1)    nav_state_poshold_3d_in_progress (7)     ARM|NAVPOSHOLD|LEDLOW|BLACKBOX 
   117440    106.5  (  60.1)    nav_state_rth_climb_to_safe_alt (9)  ARM|NAVRTH|NAVPOSHOLD|LEDLOW|BLACKBOX  
   124453    110.1  (  63.7)    nav_state_rth_head_home (10)     ARM|NAVRTH|NAVPOSHOLD|LEDLOW|BLACKBOX  
   134511    115.3  (  68.9)    nav_state_rth_hover_prior_to_landing (11)    ARM|NAVRTH|NAVPOSHOLD|LEDLOW|BLACKBOX  
   138457    117.3  (  70.9)    nav_state_rth_landing (12)   ARM|NAVRTH|NAVPOSHOLD|LEDLOW|BLACKBOX  
   172320    134.7  (  88.2)    nav_state_poshold_3d_in_progress (7)     ARM|NAVPOSHOLD|LEDLOW|BLACKBOX 
   207520    152.7  ( 106.2)    nav_state_rth_climb_to_safe_alt (9)  ARM|NAVRTH|NAVPOSHOLD|LEDLOW|BLACKBOX  
   209391    153.6  ( 107.2)    nav_state_emergency_landing_in_progress (23)     ARM|NAVRTH|NAVPOSHOLD|LEDLOW|BLACKBOX  
   216549    157.3  ( 110.9)    end of log
Disarmed by: SWITCH

p.s Where there are multiple flights in a log, it helps to state which are relevant to the issue, otherwise one has to guess.

[robustini]

p.s Where there are multiple flights in a log, it helps to state which are relevant to the issue, otherwise one has to guess.

Flight 5/5 you can see both the RTH attempt from Angle gone bad and the good one at 01:00.01 triggered in Position Hold. Flight 4/5 only RTH bad attempt.

[robustini]

my only guess would be that when you hit RTH while moving it immediately senses your stick positions which will cancel it

This thing might be the more plausible one, rather than interference to the mag. The log is not mine, but from a friend who is not very experienced, and I see that the throttle moves it too much once RTH is activated. Obviously, in an emergency, the RTH should completely ignore the sticks, so to test them I put them at fixed values in the tx when RTH activates, but it is not an elegant solution. But there is definitely a deadband in the code, maybe it's too sensitive. The yellow line is the throttle input, it activates RTH at 1200 and changes up to 1285. Is there the possibility to exclude in the code or in the parameters the control of the sticks during RTH? In Ardupilot the sticks are completely ignored during RTL, whether it has been activated by the user but also by the failsafe. In some DJIs it leaves only the YAW sticks active during RTL. @DzikuVx how does INAV behave instead in case of multirotor during RTH? I'm looking at navigation_multicopter.c now.

[stronnag]

Well you can trust unsubstantuated theory, or you can trust the log. The log clearly shows emergency landing (on multiple occasions). Emergency landing is caused by:

• Sensor issue
• Exceeding the configured nav_rth_abort_threshold (default 50000cm (500m)).

So lets check the settings:

set nav_rth_abort_threshold = 500

500cm (5m). Looks like mis-configuration to me; rather than some stick phenonema.

[breadoven]

Not aware stick movements will cause RTH to cancel/land, only modify its behaviour in pitch, roll and yaw (throttle also ? seems unlikely). Did wonder if it's to do with the RTH altitude control stick override but again that just modifies the RTH altitude behaviour, doesn't cancel it (and it's off by default so would need to have been switched on).

3 things will cause an emergency landing in the RTH climb phase: Invalid heading Invalid position RTH sanity check Or a bug of course ...

And it appears in the log above (at 209391) that emergency landing happened with RTH from Poshold dismissing the static stick theory.

What do the OSD heading and GPS satellite fields show when this happens ? Wouldn't the heading turn to dashes if invalid due to Mag problems ? And the satellite field should flash if there's a fix problem.

[stronnag]

User configuration error ?

[robustini]

User configuration error ?

In all likelihood it was set nav_rth_abort_threshold too small value.

[stronnag]

Thanks, knowing the resolution helps stock the experience bank for similar questions in future.