Handling switch from AUTO when in RC failsafe

[peterbarker]

Bug report

Issue details

The first option in FS_OPTIONS allows a user to ignore RC failsafe when in auto mode. This was intended for short-range RC when doing missions at long range - i.e. a problem which would resolve once the vehicle came closer. Problem is that we have ignored the FS action when we lost RC - so when the user changes modes (e.g. via a GCS command), we still don't have RC input. That allows you to be in a mode which is not designed to be in with no RC - acro, in particular, fares poorly.

https://github.com/ArduPilot/ardupilot/pull/27450 fixes a bug in loiter where state was not being updated appropriately.

But we shouldn't really be in loiter without RC input.

So, do we:

• deny the change to LOITER?
• re-raise the failsafe action which would have been undertaken had we not been supressing it in AUTO?
• do something else?

Version master

Platform [ ] All [ ] AntennaTracker [ x ] Copter [ ] Plane [ ] Rover [ ] Submarine

Airframe type Any

Hardware type SITL / all

Logs n/a

[khancyr]

I would say that this is a config error so the "safe" behavior is RTL to prevent user to set any mode that need radio when radio is down

[rmackay9]

I'm sure this will be an interesting discussion.

There's another option which is to try and safely do what the operator asked for when possible.

Remember one of our golden rules is to do what the operator asked for unless it's very clearly unsafe. In the case that led to the discovery of the bug, the user probably really wanted Brake mode but that's not a mode they were familiar with so they picked Loiter and assumed the vehicle would stop (which is will once the bug is fixed). So it's actually safe for us to let the user back into Loiter mode.

For modes with a manual throttle (Stabilize, Acro) it's clearly not safe so our choice is to either deny entry to the mode or trigger the failsafe action. The danger of denying the mode change is that it could delay a user from aborting a fly-away. So perhaps the user is panicing, the vehicle is drifting off toward a kindergarten or airport and they just want to bring it down, they might pick stabilize and denying that will delay the correct action which is to somehow send the terminate command.

So I think my current vote is we deny entry for modes with manual throttle (need to consider Drift mode here which is a mix) and for the rest we try and make them safe.

[khancyr]

Agree. I think we got too much case of newcomer error switching from Auto/Guided to some manual mode without working radio or radio with throttle low. This lead to instant crash without way to recover. So our guard should be to prevent such case to happens as that is a critical failure case.

So we can implement the deny with clear feedback to GCS or any telemetry system why it is happening. Then chose behavior between, brake, rtl ,land.

A simple stop could be a solution, but I find it more stressfull to see the drone stuck from far and not have a radio to send it some commands. That is why I propose RTL if it is possible, worth case would be a trigger to land. From a regulation point of view in Europe , that is acceptable as it should have been covered in the flight plan risk. For a standard user, well, most regulation would prevent flight in risky area so a landing (maybe enforce a really slow one ? to give time to run to the drone and warn whatever is under ?) is better than no control or freefall/parachute and would cover the user against the lost of control issue : drone did the landing as expected (insurance case)

[LupusTheCanine]

IMHO autopilot should deny entering mode it isn't ready to operate in like entering GPS modes without valid GPS position we should deny pilot control modes if we don't have valid RC signal through RC or Mavlink.

[rmackay9]

We discussed this at length on the call and PeterB will come up with a patch. We agreed we would allow the user to enter Loiter and PosHold modes even during RC failsafe but not for other manual modes.

[peterbarker]

Found this old implementation from @MattKear which went the other way and defererd the failsafe! https://github.com/ArduPilot/ardupilot/pull/18061

[MattKear]

@peterbarker would you like me to bring that PR back to life? Or is the general consensus that a different approach should be taken?

[rmackay9]

I think we should go with the solution discussed on the more recent dev call. E.g. allow the user to enter Loiter or PosHold but not other pilot controlled modes.