ArduPilot Failsafe uniformization

ArduPilot failsafe
document from RFC opened at drone discuss

Proposal for a common method of interpreting failsafe actions between vehicles controlled by ArduPilot.

First, which events that happen on the vehicle should trigger a failsafe event:

Fuel/Battery status

Loss of RC radio link

Loss of GCS communication

Vehicle moving outside predetermined area (fence)

Vehicle moving inside predetermined area (no-fly zone)
`
Event on the vehicle code that would trigger a MAVLINK_SEVERITY_EMERGENCY message

GPS/EKF failsafe

Terrain following database bad status
Motor failure (see https://github.com/diydrones/ardupilot/issues/3456)

Then, which actions should occur and when, if an event is triggered.

Not all events should imply a flight termination, and some events don’t require an immediate action. Also, some events might occur almost simultaneously and/or sequentially so, the failsafe routine must be able to categorize the actions.

Fuel/Battery status: We monitor the Fuel/Battery and the user should preset appropriate values on which specific actions would be triggered.

So a first level event would be fuel/battery capacity remaining to execute a RTL.

Second level event would be fuel/battery capacity remaining to Land at current position.

Third level event complete fuel/battery depletion

Loss of RC radio link, where we monitor the status of a specific radio channel (usually throttle)

Short term loss of control link

Long term loss of control link

Regaining control link after long term loss of control link

Regaining control link after short term loss of control link

Loss of GCS radio link, where we monitor the Mavlink heartbeat

Short term loss of GCS link

Long term loss of GCS link

Regaining GCS link after long term loss

Regaining GCS link after short term loss

Vehicle moving outside predetermined area (fence)

Vehicle approaching fence
Vehicle speed and direction will require an acceleration that would exceed pre-determined max acceleration.

Vehicle breaching fence



Vehicle moving inside predetermined area (no-fly zone)

Vehicle approaching no-fly zone
Vehicle speed and direction will require an acceleration that would exceed pre-determined max acceleration.

Vehicle breaching no-fly zone.

Event on the vehicle code that would trigger a MAVLINK_SEVERITY_EMERGENCY message

Currently there are no events that trigger this message but would lead to an immediate flight termination

Specific SYS_STATUS flag/flags that require a failsafe action (GPS/EKF failsafe?)

Currently on Copter, the actions for EKF failsafe are Land, Alt Hold, or forcible LAND even on Stabilize.

I believe Plane switches to DCM when EKF fails, so it wouldn’t be registered as a failsafe action.

Terrain following database bad status

```
If the terrain database is not present for the current location. Should follow what Plane does.
```

Now we must consider appropriate failsafe responses. These responses would be current or future actions and would be invoked. The responses should be ordered in a way that the most severe response would be Immediate Flight Termination, and the least severe would be “ignore event, continue current action”.

Ignore, continue current action
Switch to Stabilize, Manual or FBWA mode
Stop movement, enter Loiter or Altitude Hold mode (Circle?)
Go to nearest Rally Point or Home
Go to nearest Rally Point or Home AND Land
Land at current location
Terminate flight. Deploy parachute and landing gear
Terminate flight immediately (Kill switch)

The above actions are prioritised, so if a subsequent event happens that requires a less important action, it should be ignored, and if a more important response is required than it should be obeyed.

Now, what happens if a failsafe event is cleared (regain RC link, GCS link, clear fuel/battery status)

If the current failsafe action leads to movement from the vehicle (move to nearest Rally Point or Home or higher priority action) then the action should be cancelled and the vehicle enter the least disruptive action (Stop movement, enter Loiter or Altitude Hold mode (Circle?))

All higher priority actions are not to be interrupted until completion (ie if the Action is “kill” the vehicle, than invoking that action means that there is no way out…)

Just like we have today on Copter the Kill switch, where the human operator has a 5 seconds “oops window” to revert that action, also all failsafe could be overriden within the first x seconds after the event, and resume control (obviously that only applies when there is control either via RC or GCS)

Start by reading the RFC referenced in the issue and comparing the current Copter and Plane failsafe behavior, including EKF and terrain-status handling. The issue does not name implementation files or tests; done would require an agreed cross-vehicle event/action design and a clearly scoped implementation plan.

Written by the indexing model from the issue text.