Failsafe updates for radio, GCS, and battery... plus new FS_OPTIONS parameter

ArduCopter 4.0 Failsafe Refactoring

The radio, GCS, and battery failsafe handling in ArduCopter 4.0 has received a significant enhancement. Numerous additional options and capabilities have been added to meet a variety of use-cases. The autotest system has also been significantly enhanced to always verify that all failsafe logic and actions are working as intended. All of this was merged into master through this PR on Saturday 11/2/2019. Randy will be backporting it to be part of the Copter 4.0-RC2 release.

FS_OPTIONS: New Parameter

A new parameter FS_OPTIONS has been added been added. This is a bitmask parameter, which allows the operator select one or more options that alter the basic failsafe logic. The default value is 0, which disables all options. There are many new options not previously available in prior versions.
This new FS_OPTIONS parameter now also handles the ability to continue in an auto mode mission after a radio or GCS failsafe, previously set with FS_THR_ENABLE=2 or FS_GCS_ENABLE=2. If you used this setting to fly auto mode missions beyond RC/GCS range, be sure to read this!

In the Mission Planner full parameter list or full parameter tree, the handy checkbox popup window is an easy what to set this (and any other bitmask) parameter. Be sure to go to Help > Check Beta Updates to pull the latest parameter definitions first while connected to the internet.

The FS_OPTIONS parameter details can also be found in the ArduCopter Parameters wiki page.

Option Description Bitmask Value
Continue if in auto mode on RC failsafe Allow an auto mode mission to continue when the RC signal is lost. This option replaces the FS_THR_ENABLE=2 setting. Anyone with an old setting of 2 will automatically be converted to this new FS_OPTIONS bit when ArduCoper 4.0 firmware is installed. 1
Continue if in auto mode on GCS failsafe Allow an auto mode mission to continue when the GCS telemetry signal is lost. This option replaces the FS_GCS_ENABLE=2 setting. Anyone with an old setting of 2 will automatically be converted to this new FS_OPTIONS bit when ArduCoper 4.0 firmware is installed. 2
Continue if in guided mode on RC failsafe Allow guided mode to continue when the RC signal is lost. If you are in guided mode, and lose RC signal, you can keep operating in guided mode uninterrupted. In the interest of safety, you must have the GCS Failsafe enabled to do this. (FS_GCS_ENABLE) 4
Continue if landing on any failsafe Allow the copter to continue landing while in land mode or a landing phase. If you are in land mode, or the landing phase of an RTL, or the landing phase of a mission, and the RC, GCS, or Battery failsafe activate, the copter will continue landing. This saves time and battery power if desired. 8
Continue in pilot control on GCS failsafe Allow the operator to continue flying in pilot controlled modes when the GCS telemetry signal is lost. If you are operating in any pilot controlled mode (Stabilize, Alt Hold, Loiter, Acro, Drift, etc), and the GCS telemetry signal is lost, the GCS failsafe actions will not trigger and you can continue flying uninterrupted. 16

GCS Failsafe Enhancements

Prior to ArduCopter 4.0, the GCS failsafe had minimal implementation, only having any impact in Guided Mode. Now in ArduCopter 4.0, the GCS Failsafe operates in all modes per the settings of parameter FS_GCS_ENABLE. This is a major safety enhancement for operators that must have a link at all times. This is also useful for those with a critical companion computer that must always have a link. The GCS failsafe settings have been expanded to now work in the same manner as the radio failsafe settings. The GCS Failsafe also makes use of the above new FS_OPTIONS parameter settings. Note, if you enter an invalid parameter value in the FS_GCS_ENABLE parameter, it will RTL in the interest of safety. The ArduCopter Parameters wiki page now reflects these updates.

Autotest Enhancements

The ArduPilot autotest system has been extended to cover all logic and actions of the radio, GCS, and battery failsafe. In previous versions, the autotest scripts only covered one aspect of the radio and battery failsafe, and no aspects of the GCS failsafe. This enhancement will ensure these critical safety systems are not compromised by ongoing firmware modifications.

Wiki Updates

The wiki pagaes for radio failsafe, GCS failsafe, and battery failsafe will be updated once this PR is merged in shortly.


This is awesome Matt! I have always wanted to ask for a radio fail safe mode of “yaw left/right in a full circle and see if you regain signal” mode. I feel like I can legitimately ask for this and the structure is in place to support it.


This condition from radio FS logic is not very clear for me:

When a radio failsafe is triggered…

  • If the copter is armed in Stabilize or Acro modes, and the throttle input is at minimum, the copter will immediately disarm.

What is throttle input here? RC channel input? But it’s a RC link lost case.
Does that mean Armed and not flying? But then this bullet just duplicates previous one.

Yes. What was the throttle channel at the failsafe occured. In this case, it is if the throttle channel is at it’s minimum when the failsafe occurred.

That is hopefully what the circumstance would be. But landing detection isn’t necessarily in play with those modes, so “if landed” can’t be a factor. Also in those modes, you could be airborne and falling out of the sky too since minimum throttle input takes the motors to min spin, no stabilization. In either of these cases, disarming is the action.

That is actually how it’s always been and wasn’t changed.

Yes, sure. Just wasn’t aware of that behavior. Can’t imagine the case anyone would need this…

IMHO ideally there should be no hidden/hardcoded logic for specific cases. Every FS case should be in FS_OPTIONS so user could clearly see in what case to expect what.

It is not a hidden setting. It has always been in the wiki documentation. I simply reformatted the layout of the wiki. I didn’t just add that note.

That would be a major safety issue that users would encounter anytime they are in stabilize or acro mode on the ground. If that was not hard coded logic, you would have no way to stop the motors. It would just sit there on the ground running until the battery died, or until you stuck your hand around the propellers to disconnect the power. There is definitely no use case for that being a selectable option.

Sorry if I was unclear, there is no problem with wiki article nor old nor new version.
I mean the “immidiate disarm even if in air on RC FS if throttle is zero” logic is unobvious (till you read the wiki carefully :slight_smile: )
I re-read your message and realized we cannot always rely on landing detector in stab or acro so that kind of protection was added. Anyway this is not related to the subj topic.
Thank you again.

1 Like

Another Failsafe update request:
Can we get a timeout parameter for RC or GCS Fail-safes in Auto mode? Essentially if the drone is in Auto Mode, we don’t want it to RTL due to momentary (millisecond) loss of RC/GCS but only if link lost for like couple of seconds or more.