Expected mode after failsafe recovery?

ArduPlane
1

I just had the hardest crash of my RC history to date, due to what I would consider an inconsistency in the flight mode state after failsafe recovery. I had to write off a brand new plane, brand new flight controller board, lipo battery and SD card.

I noticed a long time ago that even after radio signal is recovered, the flight mode remains in RTL until the mode switch is changed to intentionally select something else. I quite like that behavior because

  • it avoids having control suddenly returned to me at an unknown time
  • it alerts me to the fact that signal was lost, if I happened to not be watching my monitor

Not long ago I trusted this behavior fully when I sent a plane out over the open ocean in cruise mode to deliberately lose signal for a radio range test, and it came back just fine. So I thought I had everything sussed out.

However today I discovered that if you change the mode switch during the failsafe period, upon recovery the ‘new’ mode is applied immediately. For example:
Mode1 -> Failsafe -> Recovery … results in RTL
Mode1 -> Failsafe -> Mode2 -> Recovery … results in Mode2

Is this intentional, and if so what is the logic behind it? Somehow all this time I had never noticed this, despite countless confirmations of failsafe/RTL behavior while setting things up at the bench. If ‘Mode2’ is a mode that requires human attention you could be screwed if you thought it would stay in RTL, as I did today.

It’s somewhat ironic that I was actually in the process of making a video that would have been titled “How much I trust Ardupilot” wherein I switch the radio off during the maiden flight of a fresh plane and FC setup. After doing an autotune the plane was flying beautifully in FBWA and the failsafe/RTL test worked nicely. Unfortunately my radio has an annoying ‘feature’ where it forces you to put all switches to a certain position after turning it on before it will do anything else, so when turned on again the flight mode switch was in manual, but I did not worry about it due to seeing the mode remaining in RTL so many times in my checks.

Needless to say the planned video is cancelled, but here is the crash for your viewing pleasure: https://youtu.be/2uAvMSvlYvU

Of course I could have just switched back into FBWA (or simply fly it in manual) but as is too often the case in the panic of the moment I didn’t realize what was happening until too late.

2

Hi Chris,
Sorry for your crash!
I’m afraid what you describe is expected behavior, and the logic is that “last command wins”. If we get a valid command from a user to change mode then we obey that command. In this case we have valid RC control input, and the mode switch indicates Mode2, so we change to Mode2. If we didn’t do that then it would have helped for your situation, but it will also cause confusion in other situations where the user sees they have changed mode switch but the mode hasn’t taken effect.
Which RC radio do you use btw? My radio (a taranis) also has the feature where it wants switches in a particular position, but you can override that by pressing “enter” when the error message comes up to continue anyway.
I’d be open to suggestions on other ways to handle this situation. How could we prevent this crash without compromising pilot control?
Cheers, Tridge

3

How about this: when RTLing from an RC failsafe, it does not change modes until it sees a CHANGE in commanded flightmode from the RC system. As in, when it first regains RC control, it doesn’t exit RTL, no matter what mode the RC is commanding. But if you flip your mode switch, THEN it changes.

In short, it would only allow the flightmode change if you have a working RC link during the change.
Note that the “set flightmode” button in your GCS should still override this if telemetry is working.

4

that is how it works now. In the case of the flight that was described there was a change to MANUAL on the RC transmitter after the failsafe began.

5

Hmm, I’m not sure that my idea got across correctly.

If I’d reading accurately, the problem is:

  1. Plane enters failsafe from no RC
  2. While plane is in failsafe, the mode switch is changed
  3. When RC returns, arduplane sees the new flightmode switch position and changes modes, which led to a crash.

The key point is that the mode switch change happened BEFORE the RC signal was recovered. A solution to this would be to disregard the mode switch position when RC signal is regained. So, in Chris’s format:
Mode1 ->; Failsafe ->; Mode2 ->; Recovery … results in RTL. The plane doesn’t exit RTL until it sees the mode switch change from one PWM value to another, regardless of where the switch was before failsafe happened.

6

Although I could see this as an option for specific users, I generally do not agree with that logic. The smartest way to avoid this failure is to not switch modes until you are sure that you have positive control of the aircraft. I think the RC mode switch must be honored whenever possible. Maybe this needs to be documented better to avoid it happening again.

7

I haven’t looked at any source code but I would imagine it’s hard to tell the difference between a switch position change caused by recovering from failsafe, and a ‘normal’ switch change. At least that would make sense if the current behavior was more due to difficulty of implementation rather than intentional, which is why I was wondering if it was the expected behavior.

I agree with “the RC mode switch must be honored whenever possible”, and I’d add that more consistency is better. Putting those two together, it might be more predictable if the current switch mode was always applied to after failsafe recovery, even if no switches were touched during the failsafe. That is, for my two cases from above would be like:
Mode1 -> Failsafe -> Recovery … results in Mode1
Mode1 -> Failsafe -> Mode2 -> Recovery … results in Mode2

That’s actually what I expected the first time I used Ardupilot, coming from iNav etc. It also seems more consistent with the simple explanation of “last command wins”, and with short failsafe behavior. In the early days I sometimes saw the short failsafe on my OSD and since it returned to the previous mode when signal improved I initially assumed that the long failsafe would as well.

Having said that though, this is probably not something that should be changed lightly, as I mentioned above I had come to depend on the current behavior and no doubt many others have too. I did a flight with the replacement plane today doing the same silly test and now that I’m ready for this there was no problem. Perhaps a mention in the docs might help though.

I use a FlySky radio, they’re pretty basic compared to most others out there.