Plane: Climb before turn on RTL

[JeyPi]

Before I write anything let me point out that other people were requesting this RTL behavior change in a more or less similar way.
My today's FPV experience:
I took off from a spot 280 meters AMSL (altitude above mean sea level)
I was remotely landing the plane while in the stabilized mode at an RC field that was a 1000 meters away from me and a bit lower - 240 AMSL.
I was gliding in for landing. All was great. I had a perfect video link to make a nice landing. Just before the touch down, the plane lost RC link and the RTL mode kicked in. I was no longer in control. The ardupilot software executed an immediate right turn towards the Take off position without any climb. Just a turn. That of course was followed by a crash as the plane was so low and the tip of the wing touched the ground. My RTL altitude was set to 100 meters.
I suggest the code should be adjusted to climb the plane to a safe altitude before turning to the home position. I understand this could not suite to all platforms so at least this behavior could be user pick able.
The only data that survived was the camera footage. The flight deck SDcard was destroyed.

Video of the event here

As you can see, the only thing needed for a happy ending, was a little climb before the turn and the plane would had been saved. Can someone make this a priority before other people crash their planes during a low altitude RTL triggering?

[Naterater]

I agree with this request. Here is another recent case of a crash that may have been saved by RTL climbing BEFORE turning: https://discuss.ardupilot.org/t/rtl-does-not-stop-decending/29573

Another semi-related issue is when a pitch and roll are commanded at the same time as can happen in RTL: #8064. Many planes can hit pitch max and roll max individually just fine. When both are commanded at the same time, it's a dangerous time with a very high potential for stalls/spins.

[magicrub]

I've flagged it for a topic on today's dev call

[magicrub]

@JeyPi Thank you for the video. That is a very compelling example.

[JeyPi]

Thanks a lot for working on it. I am happy already that it is being discussed.

[Naterater]

I have two suggestions for implementing this behavior.

• Climb wings-level to a minimum altitude before commanding turns (think of a go-around near landing touchdown) or
• Hold any turns until a minimum positive rate of climb has been achieved for a minimum time.

[Rolf-G]

Sorry @Naterater, but climbing to a minimum altitude before commanding turns in combination with maladjusted TECS-parameters and not performed autotune does not solve the problem.
A poorly set autopilot leads also at low altitude and high descendrates to a CFIT, the impact takes place straight ahead and not while turning. Ok, the damage to the plane may be less - but that's all.

Another disadvantage of your suggestion: Pilots in the mountains have the disadvantage that the aircraft does not dodge in time in front of a vertical rock face.

My Planes are immediatly climbing and turning simultaneously if RTL is trigggered due to well adjusted TECS/Autotune Parameters. You can test the quality of your TECS-Parameters by changing quickly between climb and descend in FBWB-Mode.

Regards Rolf

[JeyPi]

That is what I mean. There will always be positive as well as negative thoughts to a suggestion.
I am definitely for climbing to a minimum altitude before commanding turns. I am aware that being low in front of an obstacle would mean hitting the obstacle in case the RTL is triggered, but at least it is predictable. (I would know if I am far and low, I need to have some free space in front of the plane)
Flying low in between the hills commanding RTL while climbing and turning at the same time could not save the plane either. In my case, when the RTL triggered while landing the plane, climbing before turning would save it.

[Rolf-G]

Unfortunately, you have no logfile and I do not know how you have programmed radio failure: Throttle failsafe ? According to the subtitles of your video, RTL (or CIRCLE ????) was almost triggered on the ground but RC loss have happened 4 seconds before?
If you have throttle failsafe enabled, what are your values for FS_SHORT_ACTN and FS_SHORT_TIMEOUT ?

[Naterater]

@Rolf-G, the bigger problem brought up here (that is also a safety problem) failsafes command multiple actions at once. I've had stalls due to climbing turns when RTL engaged, and I have a very well tuned airframe. The plane here was not tuned improperly, and it crashed because of unpredictable RTL behavior near the ground.

Speaking of improperly tuned planes, we should definitely not be commanding a maximum bank angle turn and a simultaneous pitch up. That's just begging for the plane to stall, spin, roll over and lose all control. For 99% of planes, altitude is far more important than heading. If there are obstacles ahead, RTL is NOT the mode that should be entered. FBWA or manual would be much better.

Being in the mountains and not being able to climb straight-ahead is a corner case and definitely not going to harm most users. My suggestion would probably use parameters with values 0 or -1 for traditional behavior.

The final problem as placed in this initial post, is that planes are probably very close to stall speed during landing. I'm sure that most planes will enter into RTL just fine during cruise, but that doesn't matter here.

[Rolf-G]

Hi Nathan,
I agree with you in principle, but we should distinguish a go-around procedure from an RTL procedure. JeyPi's crash landing is in my opinion a go-around problem.

[Naterater]

Maybe call it "recover" AKA wings-level then climb to an altitude or for a period of time. Followed by RTL? It actually sounds like takeoff mode might work better...

For the original post here, takeoff mode would probably be the most appropriate followed by RTL. Any time the land has started, a takeoff should be commanded before RTL.

[magicrub]

Without posting your params how do you/we know it RTL'd instead of going into LOITER? Is that your failsafe behavior? How do we know you didn't trigger RTL manually? If you did trigger it manually, would we want an intentional RTL mode-change to pitch up like you propose?

There are lots of interesting corner cases not being considered here.

This RTL didn't know/care what your altitude was. Using the terrain library would have given it the knowledge of it's altitude to behave better but the current RTL logic would have caused the same behavior. Knowing how close to the ground is helpful since it could have climbed to RTL altitude. What I'm getting at is:

• if you were 120m up would you want any RTL to pitch up and climb X meters before turning? Now you're violating airspace.
• in a battery failsafe event it is usually not very happy with a sudden pitch up and climb (high current) behavior. However, I certainly admit that it's better to strain the battery a little than to crash.
• how about fence breech? holding heading and throttleing/pitching up is obviously not preferred.

Sooo.. tough call on how this can be improved in a universal way. I'm thinking that this behavior can onyl happen in a subset of scenarios.

Also, this AUTO abort landing behavior is slightly related: #7052

[JeyPi]

I see a lot of thoughts is coming up.
1 - I have no log but when it happened I had my FPV video glasses on with telemetry. Trough the telemetry I know the RTL was triggered. I also know it was not triggered manually - that is for sure.
2 - My fail safe setting in case of an RC signal lost is to RTL - not Loiter or Circle or what ever others suggested. This is the only reasonable setting if we do not fly Auto.
3 - I was flying the plane manually in the stabilised mode. The software was not auto landing the plane. (It did not know it was going to be landed) Nathan suggested in such a case when a plane is low, and a fail-safe is triggered because of an RC signal lost a plane should enter a different mode than RTL. I do not agree. It can only be RTL or Auto as the pilot is no longer in command of the plane.
(lets give the fail-safe situation an abbreviation. When RC link is lost and RTL is triggered as the set fail-safe procedure, write it like this: RTL-RSL)
4 - My plane uses an Airspeed sensor and is tuned well. I was testing how quickly it was able to change altitude in Auto mode. The plane had a strong motor and a 10m/s positive climb was performed perfectly. No stalling no hesitating at all.

The problem with RTL now is also this:
Suggest you set RTL altitude to a 100m . Your fail-safe is set to RTL in case the RC is lost.
You are at an RC field testing the low altitude RTL, where the distance between the plane and the HP is max 400 m? The plane is at 2 meters height and you switch the RTL on. It would turn in to the direction of the HP (home position) and climb like crazy untill the 100 meters is reached.
Now do the same but the distance between the HP and the plane is 3 km. What would happen?
The software takes the 100m altitude and the distance the plane needs to go to reach the HP and puts the rate of climb and the HP distance to be flown into a relation.
That simply means the plane will be climbing the whole 3km distance so to reach the set height exactly at the HP. This results in a poor climb rate close to the grounnd when RC lost occurs and RTL is triggered far from the HP.

Now how the new behaviour should work:
We already set the RTL altitude.
If RTL is triggered and the plane is below this altitude, climb, before turning to HP
If it is above, do not climb only turn to HP
It is just the same what copter software does.
If there are people who do not like the plane to climb before turning (like Rolf-G) make it selectable so they do not have to use the new behaviour.

Now the importance of a log of this event is not such a big deal. This situation is to be easily reproduced.
Here you go:
Take your FPV gear.
Set your fail-safe to RTL in case of an RC lost. RTL altitude 100m
Fly your plane in stabilised or manual mode as far as the FPV and RC signal can handle.
Go as low as my plane was (2 meters above ground)
Switch off your TX or trigger RTL manually.
If your wing is of 4m span - this would be followed by a crasch.
The plane would turn immediately and the tip of the wing would hit the ground.

[magicrub]

This was discussed in the devcall. We are considering a few options:

• pull up X meters before any turns, limited to just a couple seconds. default would be something small, like 2 meters and 2 seconds.
• make this optional (not sure if default is enabled or disabled)

[JeyPi]

Two meters might not be enough.
I would suggest at least 20. Default enabled.
20 is not much and can be reached quickly.
Also I would do something about the RTL altitude, to reach it as soon as possible and not just gradually along the way to HM

[JeyPi]

Has there been any development?

[RMFPV]

This is very important improvement. please add it. Better to make desired climb alt as adjusted param in meters that will be added to current alt.

[tridge]

I've finally implemented this here:
I've finally implemented this in #14371
sorry it took so long

[JeyPi]

It work just perfectly.
Exactly as I was hoping. Thanks a lot