RC_Channel: improved handling of RC overrides during RC failsafe

[jeff567]

Feature request

Is your feature request related to a problem? Please describe. The user may set an RC aux channel to be "RC Override Enable," such that the pilot has the ability to choose when the flight controller accepts or rejects RC override messages.

As currently implemented, if the user sets the aux switch to enable RC overrides, and the RC link is subsequently lost, RC override messages continue to be accepted. There is also no way to know the RC link was lost (if the lost link behavior is No Pulses). This can be problematic if some channels are being overridden, and others are getting input from the RC. During a no pulses RC failsafe, the RC channels that are not being overridden hold their previous values.

Describe the solution you'd like Assigning an RC aux channel to RC Override Enable suggests the flight controller needs pilot approval to accept RC overrides. If the RC link is lost, the flight contoller should reject RC overrides, even if the RC Override Enable switch postion was high when the RC was last connected.

I was going to submit a PR based on this patch which does that: https://github.com/ArduPilot/ardupilot/commit/431d24265b1dc624384168af10f92ce16a6f34f6

But I noticed some discussion in a previous pull request that suggested the default behavior should be accept RC overrides if the RC link is lost.

To me, the follwing would make more sense:

• If an RC channel is set to RC Override Enable, always reject overrides if the RC link is lost (since the RC Override Enable channel cannot be checked)
• If no RC Override Enable channel is set, always accept RC override messages regardless of the RC connection status.

Describe alternatives you've considered Perhaps an additional FS_OPTIONS bit that specified how RC overrides should be handled if the RC link is lost.

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

Additional context https://discuss.ardupilot.org/t/detect-rc-failsafe-while-sending-rc-override-messages/89787

[peterbarker]

@jeff567 what are you using the RC overrides for? I'm guessing, "not what they're meant for" :-)

The purpose of that switch is to give someone holding a transmitter the option of regaining control when something goes wrong with a GCS. If the RC transmitter goes away you really do want to give the GCS operator every chance of controlling the vehicle, thus our current behaviour for that switch.

We could potentially add more functionality, but I'm guessing that you might be using RC input when you really want guided-mode-commands or similar.....

[jeff567]

I admit, I was using this for a pretty specific application. While a user flies the drone in loiter mode, a companion computer would occasionally override the RC channel for yaw to align the drone to a specific heading. We also have a more automated mode that takes no user input and uses guided mode commands, but when allowing a user to control other inputs with occasional yaw overrides, the RC override route seemed most straightforward.

For my specific application, it could be problematic that a user can allow RC overrides with a switch, but then if the RC signal is lost, no RC failsafe occurs. For example, user allows RC overrides with switch -> companion computer sends RC overrides for yaw channel -> RC Link is lost (yaw overrides continue and last known RC inputs are held constant) -> flyaway occurs

If the RC overrides are coming from a GCS rather than a companion computer (which I suppose is the intended use case), then I agree the current implementation makes sense.