[2.4-5.0RC2]Linear Descent RTH causes rapid climb at home point

[b14ckyy]

Current Behavior

With RTH set to AT LEAST LINEAR DESCENT and arriving altitude is much higher than Home Altitude, it causes a rapid climb for some time.

Steps to Reproduce

1. Activate RTH with AT LEAST LINEAR DESCENT active and RTH Altitude set to 100m and rth_home_altitude set to 30m
2. Fly at a high altitude but relative near the home point. For example 200 Altitude and 200m away
3. hit RTH
4. Wait till plane arrives
5. At a descent rate of max 5m/s it should arrive at about 170m RESULT: Plane suddenly climbs when home point is reached

Expected behavior

RTH should start the home loiter and continue the descent till it reaches rth_home_altitude

Suggested solution(s)

Maybe a bug? Not tested if it is fixed in 2.5 RC-1

Additional context

I have seen the exact same behavior on 2 planes yesterday. One flight showed a 300m climb before the descent started. Both on 2.4. Dart 250G with Matek F411WSE and AR Wing with Matek F405SE. I can share a log of both flights (Blackbox for AR Wing and OpenTX log for 250G) but need to share it private due to obvious reasons. Also FPV recording available if needed.

Update: Might need a much higher altitude to test as mentioned above. As I said for obvious reasons I can't attach logs here.

---

Dart 250G Dump: INAV_2.4.0_cli_Serenity_20200515_192143.txt

AR Wing Dump: INAV_2.4.0_cli_Miranda_20200515_192422.txt

[b14ckyy]

Reproduced it again on the Dart 250G yesterday. Here is a DVR of it: https://youtu.be/JA85-ezHWyI

[CertainBot]

Can you test it on 2.5 RC2? Not of much interest if its on 2.4 although I don't think it has been touched since.

[b14ckyy]

I'll check that on my 250G as I have updated it to RC2 recently. Weather is not good unfortunately.

[b14ckyy]

Finally I flew again yesterday and issue is still reproducible with INAV 2.5.1: https://youtu.be/1vC04-Jz3bM

[digitalentity]

@b14ckyy please collect a blackbox log. DVR is not really in debugging the complicated under the hood logic

[b14ckyy]

Here you go. At 59:25 the plane hit the home position at 665m altitude after a Linear descent to home. Target RTH Altitude is 100m with a final home altitude during circle of 30m. Instead of descending it climbed out to 796m while circling before starting the descent. This is a log from my AR Wing on INAV 2.4 as my Dart 250G has no Blackbox device but the behavior is exactly the same. LOG00018.zip

[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.

[b14ckyy]

any update on that? it still happens. Will test with a 2.6 snapshot some time too.

[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.

[avsaase]

I noticed this problem yesterday on 2.6. It was with a fc that doesn't have a blackbox, so I will try to reproduce it with another one.

[jmxp69]

I have a similar problem on Matek F722WPX with v2.6 using At Least Linear Descent. Return to home is set to 300' Home Altitude is 220'. Plane flies home at 300', near loiter circle it descends through 220' to 200' then climbs back to 220'

[b14ckyy]

I have a similar problem on Matek F722WPX with v2.6 using At Least Linear Descent. Return to home is set to 300' Home Altitude is 220'. Plane flies home at 300', near loiter circle it descends through 220' to 200' then climbs back to 220'

this is a different story. It just overshoots. This is a tuning issue and not related to the mentioned problem above.

[jmxp69]

I’d love to know what the tuning issue is.

[b14ckyy]

I’d love to know what the tuning issue is.

Board alignment not tuned correctly Too fast descent (auto climb rate too high for the plane) too little navigation pitch angle causing the Altitude PID controller to overshoot Or just disturbed Barometer by airflow

can have many issues but not part of that ticket.

[jmxp69]

Board alignment averages 0 after tuning in angle mode with alt hold and throttle set to ~1400ms. Board sits on FC deck of nano talon with a wind break of a cover directly in front of it. Short of wrapping it in plastic I don't know what else one would be expected to do to eliminate airflow. Max Nav Climb Rate is 500cm/s (I believe that's the default) Max Dive Angle is 10 degrees Max Climb Angle is 50 degrees

The plane flies relatively flat on 3crs and rth, when it starts the descent to rth altitude in overshoots then climbs back up. Why doesn't the board start to pull pitch before getting to RTH altitude? It just shoots by...

[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.

[b14ckyy]

This is btw still present on 5.0 RC2. Just tested today with a fresh setup on my Dart 250G

[b14ckyy]

Update: Also easily reproducible in the X-Plane HITL Simulator. https://www.youtube.com/watch?v=Hrg9XxCKO78

RTH Phase starts at 5:40 in the log LOG00011.TXT

[breadoven]

Having looked at this it seems to be a result of PID response/control smoothing and the following FIXME: https://github.com/iNavFlight/inav/blob/4f49dfb6217ea17aa5a0d6291d5f511f6e340890/src/main/navigation/navigation.c#L2915 The initial descent rate toward home is likely at a higher rate than the nav_auto_climb_rate setting used to descend to the RTH Home altitude. This causes the PID controller to over correct the pitch down to slow the descent rate resulting in pitch up which causes a climb. This is in spite of the Nav system correctly calling for a descent and reducing the Desired Z position. However, the Actual Z position increases, since it's pitched up and climbing, until there's a 5m difference between them and the FIXME limit above kicks in and actually starts to increase the Desired Z value with a 5 meter offset to the Actual Z value.

Not sure what causes this feedback loop to fizzle out causing it to start descending, possibly just the speed dropping off. Problem seems to be worse the faster you arrive at Home.

[b14ckyy]

@breadoven we are talking about even hundreds of meters of climb when arriving home, in extreme cases. This looks like more than a PID Windup to me. shouldn't the linear descent be limited by the nav_auto_climb_rate anyway?

[breadoven]

RTH On Route uses a proportional descent based on ratio of distance travelled. In this case you would have a very steep descent angle that would be limited by nav_fw_dive_angle so descent rate would probably always be higher than nav_auto_climb_rate (which is only used for loiter altitude change).

Fixing that FIXME would help here especially since it's a potential source of runaway, Might also help if the altitude controller is reset when home is reached rather than just resetting the Desired Z which is what it does now.

[b14ckyy]

OK you are the expert here. just for reference another quick example. And yes you are right the descent was at 10m/s but the nav_auto_climb_rate is actually set to 7m/s. https://youtu.be/jb5Urem8oS8

[breadoven]

I tested a change that disconnects target altitude change from actual altitude change which seems to work. If actual altitude is moving in the wrong direction relative to the target altitude by more than 5m then the target altitude is simply held until the actual altitude catches up. Currently the target altitude starts tracking the actual altitude in this situation which sends the target altitude off in the wrong direction. PR to follow.

[b14ckyy]

great news! Although this is a very rare occurrency and basically only affects some cloud surfers usually who tend to fly right above themselves, its nice if this gets fixed :)

@breadoven is there a specific reason why the plane uses nav_fw_dive_angle instead of nav_auto_climb_rate while in the RTH linear descent? Is that the same for waypoint missions? I think for WP mission climb paths it uses nav_auto_climb_rate but not sure about descents.

[breadoven]

nav_auto_climb_rate is only used for Nav loiter altitude changes.

You still get a bit of a bounce back climb when the RTH Loiter Above Home phase is triggered but it unwinds within a few seconds and then starts descending, guessing this is PID related. Least it does with my HITL setup. See how it behaves in your case.

[b14ckyy]

yeah should be the same then in real flight. INAV always levels off first when the loiter starts and then starts the nav descent when the loiter is stabilized. its the same when I enable LOITER while in a descent manually. I have 2 weeks of holidays starting next week. Hope I get some nice days to test stuff.