RTH Trackback

[breadoven]

Adds option to back track on arrival route when RTH is triggered. Improves likelihood of recovering Rx signal if loss caused by line of sight obstruction whilst reducing the risk of flying into the obstruction compared to normal RTH heading directly back home.

When triggered the craft returns along the trackback route until the end is reached at which point it reverts to normal RTH heading directly home. It doesn't perform the RTH climb phase but instead uses the track point altitude but with altitude never allowed below the altitude of the start point so it can climb but never descend below the start point.

Currently allows 50 trackback points with a maximum trackback distance of 2000m. Distance can be set by user. Also includes a usage mode setting, OFF, ON and FS. ON works for normal and failsafe RTH, FS is for Failsafe RTH only.

Trackback points are recorded based on distance, altitude and course change from the last point. Course change points are logged at 45 degrees increments with a minimum distance of 10m between points. Altitude points are logged at 10m increments. Distance based points are logged at 100m increments if no course or altitude points have been logged within that distance. If no reliable course is available due to low ground speed only altitude and distance based points are logged with the distance increment reduced to 20m. Currently recording only starts when > 50m from home. Once the trackback points array is full new points cyclically overwrite from the start of the array. Should be noted the desired distance is only approximate since it's affected by the number of points recorded due to altitude and course changes. The more altitude/course change points recorded the lower the actual trackback distance will be, possibly by up to 10 - 20% (needs testing).

PR also includes change to Safehomes to "fix" issue noticed during testing which caused RTH to fly to Safehome if RTH triggered when less than nav_min_rth_distance from home. Not sure this as intended/desirable ? Change can be removed if it is.

Ground and flight tested on a fixed wing and multirotor, recording and tracking back as expected. Also tested by analysing flight log tracks and applying the recording criteria above to produce a trackback track. The 2 tracks compare well when overlaid even with tight manoeuvring which is where most accuracy is lost.

Related to #7930.

[MrD-RC]

Only thing that I would question is the altitude. Once it reaches the end of the track back, shouldn't it also use the standard RTH altitude settings?

[breadoven]

Only thing that I would question is the altitude. Once it reaches the end of the track back, shouldn't it also use the standard RTH altitude settings?

When it reaches the end of the track back it switches to the full normal RTH procedure so all the normal RTH settings including altitude apply.

[DzikuVx]

@breadoven it would be amazing to have this this as an option for RTH too, not only failsafe

[DzikuVx]

and BTW, I love this thing!

[MrD-RC]

Only thing that I would question is the altitude. Once it reaches the end of the track back, shouldn't it also use the standard RTH altitude settings?

When it reaches the end of the track back it switches to the full normal RTH procedure so all the normal RTH settings including altitude apply.

Awesome. Thanks for confirming that.

[Jetrell]

Ground tested, recording and tracking back as expected. Still needs flight testing though. Also tested by analysing flight log tracks and applying the recording criteria above to produce a trackback track. The 2 tracks compare well when overlaid even with tight manoeuvring which is where most accuracy is lost. The 90 degree course change limit seems a good compromise.

@breadoven. Firstly, thanks for the time you have put in to writing this feature. 👍 Its great!

I got the chance to test it out on a fixed wing today.
So I have some preliminary info to report. I set nav_rth_trackback_distance = 800
I traveled out between 700 - 1000m, using fence lines as markers, and turned off the Transmitter, establishing 'RC RX link lost' FS.
The plane would turn around and proceed with RTH back tracking to what I guess would be the first trackback point.. But then got disorientated, and started to fly around in a loiter type circuit, while holding altitude.
I tested it 3 times in one flight and once in another flight with the same result.
Hope this info may help to finding any possible cause.

The HDOP was at 0.9, with 22 Sats. It was a little windy, which did effect a mission I later loaded the WP's for.
I didn't load them before these tests. Because I was unsure if the 50 track points where part of the 120 total available, and how that would effect the trackback function?

If my F765-WSE data logger would work correctly I would give you logs... but alas it doesn't.

[breadoven]

Ground tested, recording and tracking back as expected. Still needs flight testing though. Also tested by analysing flight log tracks and applying the recording criteria above to produce a trackback track. The 2 tracks compare well when overlaid even with tight manoeuvring which is where most accuracy is lost. The 90 degree course change limit seems a good compromise.

@breadoven. Firstly, thanks for the time you have put in to writing this feature. 👍 Its great!

I got the chance to test it out on a fixed wing today. So I have some preliminary info to report. I set nav_rth_trackback_distance = 800 I traveled out between 700 - 1000m, using fence lines as markers, and turned off the Transmitter, establishing 'RC RX link lost' FS. The plane would turn around and proceed with RTH back tracking to what I guess would be the first trackback point.. But then got disorientated, and started to fly around in a loiter type circuit, while holding altitude. I tested it 3 times in one flight and once in another flight with the same result. Hope this info may help to finding any possible cause.

The HDOP was at 0.9, with 22 Sats. It was a little windy, which did effect a mission I later loaded the WP's for. I didn't load them before these tests. Because I was unsure if the 50 track points where part of the 120 total available, and how that would effect the trackback function?

If my F765-WSE data logger would work correctly I would give you logs... but alas it doesn't.

Yeah, I tested it last night and it did the same. I was almost expecting it given RTH only uses loiter waypoints (spiral climb position and Home) but I was more interested in seeing how well it recorded track points than actually used them. I've fixed the reason it just loiters at the first trackpoint and also changed the trackpoint arrival detection so it's the same as WP Missions so hopefully it should actually try and follow the track next time I test.

[breadoven]

@DzikuVx @stronnag There's an issue bumping up the Nav Config template version from 15 to 16. Seems to be a Bits issue causing an overflow error. Any solution ?

inav/src/main/navigation/navigation.c

Line 103 in 885d643

PG_REGISTER_WITH_RESET_TEMPLATE(navConfig_t, navConfig, PG_NAV_CONFIG, 15);

[stronnag]

Start again at zero, it's a 0-0xf bitfield (4bit, nibble).
We've done this before, it works OK.

[Kealper]

@breadoven it would be amazing to have this this as an option for RTH too, not only failsafe

This is what I was thinking as well, having at least a CLI option/checkbox in Configurator that tells it to activate trackback on regular RTH as well as a real failsafe. I could see that bailing myself out of hairy situations quite often, since I tend to lose video well before I lose the RC link, so most of my returns are from me manually activating RTH mode after I determine I'm likely not getting video back.

[MrD-RC]

+1 for also having this as an option on regular RTH.

[breadoven]

I've already added normal RTH with ability to cancel the trackback using the ROLL stick RTH override so it reverts to normal RTH mode.

Currently trying to improve track point logging so it only records points when it needs to rather than based on fixed distance increments which results in too many points when not required. Plane tends to roll around like a drunken sailor trying to tag all the points which works but not very efficient. Only really needs to log points when you're changing course or altitude. Course changes are easy enough on a plane, not so much on a multirotor when flying slowly.

[breadoven]

Results from flight testing on a fixed wing. Only 10 points used giving a flight distance of around 500m so 50 points would be good for 2.5 km perhaps.

Blue = flight before RTH. Yellow = recorded track points

Blue = flight before RTH. Yellow = recorded track points, Orange = RTH trackback route flown

Trying to follow track points that are relatively close together obviously causes problems for a 2.4m motor glider or maybe just shows it isn't tuned very well.

For fixed wing I don't suppose anyone looked at trying to follow a curve interpolated from 3 points by any chance ? Bit like the virtual path used for position hold but a 3 point curve instead.

[Jetrell]

For fixed wing I don't suppose anyone looked at trying to follow a curve interpolated from 3 points by any chance ? Bit like the virtual path used for position hold but a 3 point curve instead.

I tried it once.. It was certainly not fluid or rounded.

Based on my experiences of fixedwing WP navigation, under various wind conditions, and short distances between points.
Your trackback overshoot results aren't any different from what I have come to expect from iNav's use of bad IMU data (acquired when turning), being used to assist GPS and Baro data for fixedwing navigation.

Still, great work mate 👍

[DzikuVx]

As this seems to be super useful killer feature, and also quite massive, let's plan it for 6.0. WDYT @breadoven ?

[breadoven]

As this seems to be super useful killer feature, and also quite massive, let's plan it for 6.0. WDYT @breadoven ?

Well it's been tested on FW and MR and seems to work as expected so could be 5.0 if due by end May. Needs a bit more testing just to double check things. Maybe @Jetrell can give it a try.

One question is whether it's worth logging trackback at low speed below 3 m/s when the GPS course is unreliable. I've changed it to just revert to distance based logging every 20m from the last point at low speed but you could just not bother logging points at all (changes not committed yet). Probably just leave it like this since it only really affects MRs which probably wouldn't use Trackback anyway unless going longer distances in which case they'd be flying fast enough for a reliable course.

[breadoven]

Updated to default to distance based trackpoint logging when speed below 3 m/s. So course changes only considered at higher speeds when GPS course is reliable.

[Jetrell]

The tests today were in windy conditions. Which I believe is good, because it shows the inadequacies of the navigation code, especially for fixed wing use. Which I will state.. Is no reflection on @breadovens work in this PR... Its been like this from the beginning.

I tested both a multicopter and a fixedwing.
Both performed as I expected... _Considering the wind, MC was above my expectations in its trackback ability. And only showed course deviation, when it lack throttle to penetrate into the wind.

This image was typical of all the MC course trackback tests, which I was very impressed by. The quads average speed was 30km/h, with equivalent gusty winds.

While FW performance was as average as I expected... All this being based on how poorly WP missions and Loiter are handled by iNav in the wind.
It generally gets lost in windy conditions the most. Because iNav doesn't have the ability to correctly detect when the plane is rapidly approaching the target with a tail wind, and will over shoot... Or finding it hard to approach the target with a headwind, and continuously falling short. This causes the plane to re-attempt to hit the target again in some circumstances, which often gets worse with a second attempt.
While with no wind, it works relatively well.

@breadoven Somethings I noticed.

• I only tried a few times, and I couldn't get RTH override to work with the stick. I had nav_rth_alt_control_override enabled (wasn't sure if this was required?) And my normal RTH altitude mode is EXTRA.
• I noticed that you are using nav_mc_wp_slowdown for MC trackback.. regardless of it being disabled for normal WP use.. This was causing it to slow/brake at some logging points and practically cruise through others. Is this by design?
• I vaguely remember, if I was in FW (3D)Cruise mode, when RTH trackback was enabled. Exiting RTH trackback, to Cruise wouldn't disable the trackback. I had to switch out of Cruise.

My view on this feature.. Besides the above mentioned things. I think it works as well as it can, with all things considered.

[breadoven]

I only tried a few times, and I couldn't get RTH override to work with the stick. I had nav_rth_alt_control_override enabled (wasn't sure if this was required?) And my normal RTH altitude mode is EXTRA.

It worked last time I tried it and I haven't changed anything affecting it since so it should have worked. It's Right Roll to exit to normal RTH.

I noticed that you are using nav_mc_wp_slowdown for MC trackback.. regardless of it being disabled for normal WP use.. This was causing it to slow/brake at some logging points and practically cruise through others. Is this by design?

nav_mc_wp_slowdown only applies if in WP Mode, doesn't affect Trackback. I think the reason it slows down at some points and not others is because it's setting too many track points at the same location so it slows down negotiating them, trackpoint congestion basically. I noticed this yesterday when testing and changed an obvious error that should stop it doing this.

I vaguely remember, if I was in FW (3D)Cruise mode, when RTH trackback was enabled. Exiting RTH trackback, to Cruise wouldn't disable the trackback. I had to switch out of Cruise.

Not sure how it could do that. I assume when you say exited Trackback you mean you turned RTH off (normal RTH not FS RTH) ? Trackback can only remain active if RTH is active. I'll check it though next test.

The issue of wandering WP directional control on FW is something that needs looking at separately. Might just try big changes to the XY position PIDS to see if that helps. I made changes before which did result in straighter tracks between WPs but it still takes too long to settle down after turns, weaving back and fore side to side. When the WPs are closer together you're permanently in the weaving phase resulting in snaking tracks.

I did realise there is something I missed which is RTH at the end of a WP mission. With Trackback enabled it will try and back track rather than head directly home, i.e. run the mission in reverse. I've fixed this now, but something to be aware of until I commit the changes.

[Jetrell]

I assume when you say exited Trackback you mean you turned RTH off (normal RTH not FS RTH) ?

Yes, turned off RTH switch, - nav_rth_trackback = ON Normal and Failsafe

Once the weather gets better. I can go out and re-test some things. Just in case I didn't hold Right Roll long enough to exit trackback.

Over the years I've tried many changes to the navigation settings in flight.

I've made alterations to nav_mc_xy_p and nav_mc_xy_v -pid. I settled on a MC adjustment for xy_velocity, that greatly improved position targeting, over the default.... This was with a small agile 3" quad. And with these settings, it will get within 1m of the target every time. Even at speeds around 60km/h. While it would miss the target 8 times in 10, with defaults.
nav_mc_pos_xy_p = 67
nav_mc_vel_xy_p = 43
nav_mc_vel_xy_d = 96

While I haven't found nav_fw_pos_xy -pid to make a significant difference to FW navigation, due to WeatherVaning in cross- winds... Its degree of fixedwing tune-ability is on par with nav_fw_pos_z.. That always overshoots descending target altitudes by 10m+, regardless of what its PID controller is set too, then rebounds back to target.

[MrD-RC]

This is an awesome feature. Thank you @breadoven for working on this, and @Jetrell for the testing.

[b14ckyy]

One of the public test pilots had an Idea that could maybe be an option for scenario 3. Could you make the Trackback respect nav_rth_alt_control_override?
this would at least allow the use of RTH trackback if the pilot enables RTH during a video loss. The Plane would track back into video signal and then the pilot can switch to direct RTH by holding the roll to one side for 1s.
For a Failsafe the pilot still needs to manually switch to RTH and end the failsafe but that should be fine.

[breadoven]

Trackback can already be overridden using nav_rth_alt_control_override ROLL stick, will switch to normal RTH. Trackback needs documenting somewhere now 6.0.0 preview is released.

[kasatka60]

Is it possible to write/read a track on a microsd? To increase the number of points.

[b14ckyy]

@kasatka60 not possible currently with the existing implementation of the SD file systems AFAIK. Maybe in the future. Isn't 2000m trackback enough to regain control?

[kasatka60]

Suddenly 2 megabytes will soon become small.

[blind-oracle]

@kasatka60 It's 2km of backtrack distance, not 2mb

[cmanley]

This is a great feature. I have 2 suggestions though:

1. It would be nice to have an altitude margin setting to add to the track points for those who like to fly low over sloping/hilly terrain and failsafe when going out of line of sight or simply want to RTH without risking flying into the ground. This will be a nice addition to the minimum RTH altitude for those who don't fly over flat countrysides.
2. Pawel explained in one of his videos that a fixed length table is used to track the track points and that this forms the limitation of the trackback distance. Can't this be changed so that as the table becomes full, every second recorded point is discarded and the altitudes of the kept points are set to whatever the max is of themselves and the adjacent discarded points? That way the track will not be limited in either distance or time, but effectively become less precise over time/distance.
   2b. ... and if someone really wants to go crazy with mathematics, then a course smoothing algorithm can be applied to the track points (similar to the selection feather effect in GIMP or Photoshop).

[blind-oracle]

@breadoven Today I went to test the feature and had some unexpected results - my quad disarmed mid-flight during RTH Trackback. Not sure it's related to Traceback since the Disarmed by: LANDING, so maybe something in the landing detection code is bad (or in combination with Trackback). But anyway, maybe it's worth having a look.

Also I wonder if nav_rth_abort_threshold might have kicked in since the disarm happened around 500m from home and that's the default value of nav_rth_abort_threshold. And the distance from home was increasing during Trackback.

Blackbox log and last 10 seconds of DVR are attached.

LOG00025.zip
https://user-images.githubusercontent.com/592248/220181167-7fd447af-bc84-4561-bc95-9d27c617f4ab.mp4

[stronnag]

$ inav_states.rb LOG00025.TXT 
INAV 6.0.0, states from 5.0.0
LOG00025.TXT: INAV 6.0.0 (92b237e5) KAKUTEF7HDV
Iteration	Time(s)	Elapsed(s)	State	FltMode	navFlag
        0	 103.4	(   0.0)	nav_state_undefined (0)	ARM|ANGLE	
    65472	 138.5	(  35.0)	nav_state_althold_in_progress (3)	ARM|ANGLE|NAVALTHOLD		
    69664	 140.7	(  37.3)	nav_state_poshold_3d_in_progress (7)	ARM|ANGLE|NAVPOSHOLD		
   109152	 161.9	(  58.5)	nav_state_althold_in_progress (3)	ARM|ANGLE|NAVALTHOLD		
   109344	 162.0	(  58.6)	nav_state_idle (1)	ARM|ANGLE	
   453248	 346.3	( 242.9)	nav_state_althold_in_progress (3)	ARM|NAVALTHOLD		
   453664	 346.6	( 243.1)	nav_state_poshold_3d_in_progress (7)	ARM|NAVPOSHOLD		
   478048	 359.7	( 256.2)	nav_state_idle (1)	ARM		
  1061284	 672.1	( 568.7)	FAILSAFE=>RETURN_TO_HOME (1500,1500,1500,1348);(1,1)
  1061284	 672.1	( 568.7)	nav_state_rth_trackback (38)	ARM|FAILSAFE		
  1350922	 828.0	( 724.5)	end of log

• Poor correlation between CoG and heading
• Landing at c. 500m from home ... Huum

[blind-oracle]

@stronnag

Poor correlation between CoG and heading

This tells us about bad compass calibration and/or magnetic interference? PosHold seems to work fine and I had no problems with normal RTH before (though in INAV 5.1).

Landing at c. 500m from home ... Huum

Yeah... I wonder how it decided to do that and how landing detection came to conclusion that we've landed :)

[stronnag]

Indeed, most of the time mag v. CoG looks OK, then it has a bad day (for example here), and it goes down hill from there.

[b14ckyy]

1. yes

2. probably. I think I talked about that with breadoven a long time ago when I realized that if a failsafe happens while flying towards home, the trackack would move the craft away from home. I thought I tested this as well a few months ago and it did not trigger the rth_abort_threshold. But if its 500m for you it seems to do now.
   That's why we have RCs :D

[blind-oracle]

@b14ckyy

Hmm... How can I check that this actually kicked in?

I have a few doubts:

• Distance was around 530m when it was disarmed, not 500. But if the code has some leeway on that then maybe it's ok
• Disarm reason LANDING seems strange
• Docs tell us that nav_rth_abort_threshold should initiate emergency landing and not disarm. Either the docs are outdated, or it did initiate it and immediately detected that it has landed and disarmed :)

[stronnag]

mwp has a naive compass anomaly detector, which kicks in a few times (from the mwp replay log)

19:24:36.368578 New LTM Mode Angle (2) 1 58s 47.361466 8.580258 0 0
19:24:41.463340 New LTM Mode Acro (1) 1 63s 47.361467 8.580276 0 0
19:25:05.229338  ****** Heading anomaly detected 108 54 83
19:25:27.294362  ****** Heading anomaly detected 298 0 105
19:26:26.706478  ****** Heading anomaly detected 260 317 164

Where the 3 numbers are mag heading, CoG and (AFAIK) duration since armed in seconds, and a mag anomaly is declared if heading / Cog differ by 45⁰ over 3s.

PH is not a great test, as it may not stress the power train, OTOH the observed 7A is pretty conservative.

[breadoven]

@breadoven Today I went to test the feature and had some unexpected results - my quad disarmed mid-flight during RTH Trackback. Not sure it's related to Traceback since the Disarmed by: LANDING, so maybe something in the landing detection code is bad (or in combination with Trackback). But anyway, maybe it's worth having a look.

Also I wonder if nav_rth_abort_threshold might have kicked in since the disarm happened around 500m from home and that's the default value of nav_rth_abort_threshold. And the distance from home was increasing during Trackback.

Blackbox log and last 10 seconds of DVR are attached.

LOG00025.zip https://user-images.githubusercontent.com/592248/220181167-7fd447af-bc84-4561-bc95-9d27c617f4ab.mp4

Ah, sorry to hear that. Looking at the log it appears it did indeed think it had landed, hence the disarm. When in failsafe it's always trying to detect a landing. In these circumstances it looks for rotational and translational movement to decide if it has landed. It seems to have gone into a stable hover with almost no vertical or horizontal velocity and little rotational movement, stable enough in fact to have triggered a landing. Not sure why it would have hovered in Trackback. Was it hesitating and hovering at each turn point ?

There was a change made to make landing detection more reliable/faster but that may have increased the probability of a false trigger. It's a bit of a trade off. Either way landing detection during Failsafe needs rechecking to see what can be done to avoid this problem.

[blind-oracle]

@breadoven

Not sure why it would have hovered in Trackback. Was it hesitating and hovering at each turn point?

Yes, it seemed that way. I can upload longer DVR somewhere.

But essentially when it reaches some waypoint it breaks quite hard to 0kph, loiters for around 10sec and then moves forward. Then the same scenario on the next point. On some waypoints it spent almost zero time and moved to next one instantly.

but that may have increased the probability of a false trigger.

Yeah, I've read that in release notes and now noted to decrease the sensitivity of landing detection. I wonder if that can be disabled completely somehow...

@stronnag

PH is not a great test, as it may not stress the power train, OTOH the observed 7A is pretty conservative.

Yes, the current is rather low and mag is moved back quite, never had real problems with it in ~2 years. So I'd guess even if it's wrong then it's not that critical. RTH always brought it home.

[stronnag]

Note: This is really .mkv but stupid GH doesn't like that. OTOH, any sensible media player uses the metadata vice some arbitrary "extension' (even GH's it seems :).

Anyway. Perhaps interesting (a) the way the RTH 'pauses' a few times, like "is this really right' and (b) it follows the predominant flight path rather than just going home. Almost like it runs out of trackback points and thinks "wtf, I'd better stop here". But I speculate.

Wayfarer_2023-02-20_200850.mp4

[stronnag]

I rather think this is trackback problem rather than mag v. CoG.

[breadoven]

Looking at the log it's hesitating at some waypoints because it didn't get close enough to tag the waypoint on arrival so it stops and hovers toward the waypoint until it is within the nav_wp_radius. I'm guessing this is set at 100cm ? Perhaps not helped by nav_mc_wp_slowdown being set to ON (default) (I'm guessing ?) since this will likely cause the MR to stop at waypoints until nav_wp_radius is achieved. If nav_mc_wp_slowdown is OFF the MR will tend to fly past the waypoint and tag it without needing to come within the nav_wp_radius distance (it tags it based on relative bearing to the waypoint instead, i.e. it knows it's flown past).

I think the issue here is probably to do with the fact that when in Failsafe there's a risk that if the MR hovers at a waypoint it may be stable enough to cause a false landing trigger. Trackback is tracking numerous waypoints whereas normal RTH only has to track 1 waypoint, the home point, so the risk of this happening during Trackback is increased although it could also happen at the home point if the MR hovers to move within the nav_wp_radius.

Either way this needs a fix. looking at the landing detection method again it seems that throttle position is not taken into account during Failsafe landing detection which might be a mistake. I think it was done this way to try and ensure landing detection would still work after a crash landing during Failsafe when the throttle position is unknown (controlled by Failsafe) so there was at least some chance the motors could be disarmed. It might be better to only detect a landing if the throttle is low or at least some margin below hover throttle. That would have prevented this accident happening at least. I guess the other option is to provide a setting to allow the user to decide what level of landing detection is required, only RTH final landing or also during manual/Failsafe control.

[Jetrell]

It might be better to only detect a landing if the throttle is low or at least some margin below hover throttle.

I think it was done this way to try and ensure landing detection would still work after a crash landing during Failsafe when the throttle position is unknown (controlled by Failsafe) so there was at least some chance the motors could be disarmed.
That sounds like a good idea.

Detecting a crash in failsafe and disarming the FC/ESC's if a motor is stalled, to prevent the craft catching on fire, or setting a field on fire. Was one of the landing detectors major advantages IMO.. I've seen this happen once.
Perhaps G-shock detection could be used in the case of a crash ?

FYI Back when I did the original testing of Trackback on multi rotors. These were my settings on the quads.
nav_wp_radius = 300
nav_mc_wp_slowdown = OFF
Back last May, I also notice the slowdown at some track markers as well.
#7988 (comment)

Also, the landing detector wasn't as sensitive back then.
I noticed that its sensitivity increased considerably after #8427 default.
But due to my test quads only being 3" and 6" machines. I haven't had any false detection's.
@blind-oracle From your video clip, I assume your quad is larger? With greater hover stability.

[blind-oracle]

@Jetrell

Perhaps G-shock detection could be used in the case of a crash ?

That's exactly what I wondered - why do we have a landing detection mid-flight? When the craft didn't reach the landing area yet. That should be two different protocols:

• Navigation phase: high-G impact -> crash -> disarm
• Landing phase: small-G impact and stationary position (normal landing detection) -> landed -> disarm

Will try larger waypoints and disabling slowdown to see if that helps. At least now I'll know that if it hovers during failsafe - it's dangerous and it's time to take control.

From your video clip, I assume your quad is larger? With greater hover stability.

Not really big. It's Chimera 7" frame with 7.5" props.

[breadoven]

FYI Back when I did the original testing of Trackback on multi rotors. These were my settings on the quads. nav_wp_radius = 300 nav_mc_wp_slowdown = OFF Back last May, I also notice the slowdown at some track markers as well. #7988 (comment)

I need to check nav_mc_wp_slowdown again. I'm thinking on afterthought it only applies during WP mode, so wouldn't have helped in this case. If that's true then it needs to apply during Trackback to avoid this hesitation at trackpoints.

Also, the landing detector wasn't as sensitive back then. I noticed that its sensitivity increased considerably after #8427 default. But due to my test quads only being 3" and 6" machines. I haven't had any false detection's. @blind-oracle From your video clip, I assume your quad is larger? With greater hover stability.

The gyro average movement threshold was changed in #8427 from 2 to 4 deg/s to reduce sensitivity to "Airmode ground jitter". The quad in this case had average gyro rates around 2 deg/s when hovering at the 6th or so Trackback point. With the old gyro threshold it probably wouldn't have triggered a landing, but with 4 deg/s it did.

That's exactly what I wondered - why do we have a landing detection mid-flight? When the craft didn't reach the landing area yet. That should be two different protocols:
Navigation phase: high-G impact -> crash -> disarm
Landing phase: small-G impact and stationary position (normal landing detection) -> landed -> disarm

Landing detection works during Autonomous flight and also Manual flight. Detection during Autonomous flight it is only active during landing phases. During Manual flight detection is only active when the throttle is fully low. The only exception to this is Failsafe when landing detection is always active except during WP mode (to avoid false triggers during hold/hover WPs). You could also make it inactive during Trackback but Trackback doesn't guarantee you won't fly into things unlike WP missions where this shouldn't happen if planned properly.

I did think about adding a crash G detection level to #8744. Just a question of deciding what G limit to use, i.e. how big an impact should it detect.

The other thing that needs to be mentioned here is ... don't use Failsafe mode to trigger a RTH. That's not what Failsafe mode is for. It's really only intended to be used to test the Failsafe setup after which it shouldn't be used because it changes the behaviour of functions/modes including RTH in unexpected ways. RTH mode itself should always be used to initiate a RTH. This is covered in the Failsafe Wiki https://github.com/iNavFlight/inav/wiki/Failsafe.

[breadoven]

Having checked nav_mc_wp_slowdown it won't help in this case since it only applies during WP mode. I'll look at using it during Trackback also.

[blind-oracle]

@breadoven

Detection during Autonomous flight it is only active during landing phases.

Hmm I wonder why it disarmed on me then when it was hovering and was still in autonomous phase?

The other thing that needs to be mentioned here is ... don't use Failsafe mode to trigger a RTH. That's not what Failsafe mode is for.

Well.. thing is that the Trackback is really useful exactly during a failsafe event to get back the control of the drone and not hitting e.g. a mountain. That's why I'm using a failsafe switch to test it. I'm occasionally having these blackouts during mountain surfing when I lose the video so I quickly flip FAILSAFE and wait for it to get back to a line of sight. I can of course flip an RTH mode, but I want the drone to behave the same even when I lose the RC link.

And if the behaviour in RTH-mode-initiated and Failsafe initiated is different - testing in RTH-mode is not what I want I guess.

[Jetrell]

I did think about adding a crash G detection level to #8744. Just a question of deciding what G limit to use, i.e. how big an impact should it detect.

I went through many multicopter and fixed wing logs. To analyze the max G-forces encountered.
The highest Z axis punch-out acceleration I seen on one of my race quads, was 6.9G vertical.
The maximum I seen in a crash was 10.8 on the X axis and 9.6 on the Z axis.

While on a fixed wing, it was typical to see between 8G and 9.5G on the Z and X axis, during a hard stop, belly-flop landing.
And seeing the Z axis go no lower than -2.3G on a bad bounce landing.

Besides the deceleration G-forces applied in a crash.. I imagine its highly likely that the craft would also experience a high rate of gyroscopic motion, as energy is transferred from one axis to the next as it tumbles or crumbles.

[blind-oracle]

@breadoven

Having checked nav_mc_wp_slowdown it won't help in this case since it only applies during WP mode.

Would having nav_disarm_on_landing = OFF as a temporary workaround help? If the code decides that it has landed mid-RTH then it would not probably disarm the craft like it did on me, do I get it right?

[breadoven]

@breadoven

Having checked nav_mc_wp_slowdown it won't help in this case since it only applies during WP mode.

Would having nav_disarm_on_landing = OFF as a temporary workaround help? If the code decides that it has landed mid-RTH then it would not probably disarm the craft like it did on me, do I get it right?

It won't disarm but it will reset PID accumulators. Not entirely sure what affect that has, never tried it. I'm assuming it will become less stable but continue to fly @DzikuVx ?.