RC_Channel: add RC_OPTIONS bit to clear RC override by RC input change #19844

tatsuy · 2022-01-21T01:06:50Z

This PR introduces a new option to clear the RC override, allowing the pilot to regain control by operating roll, pitch, throttle, or yaw during an RC override situation. While this functionality was previously possible using RCx_OPTION(46), the new option provides a more direct and safer method for pilots to cancel overrides using basic RC inputs.

The following settings are required
RC_OPTIONS=16384 // it allows to clear overrides by Roll/Pitch/Throttle/Yaw
RCx_OPTION=46 // (RC Override Enable) Re-enable RC overrides

I tested this on copter SITL.

muramura · 2022-01-22T06:59:00Z

It is NG for the FC to not get permission from the CC.
It is also not for the FC to take control of the CC without permission.
When the FC cannot get a heartbeat from the CC, it is OK.
If the CC is the primary, the FC is the limbs.
When the CC is connected, the FC is a limb.

FC and CC should have a handshake procedure of "YOU HAVE" and "I HAVE".

PX4 has handshake in FC and MC.
PX4 has an OFFBOARD mode.
The ArduPilot needs to implement this OFFBOARD mode equivalent.

tatsuy · 2022-01-23T04:36:09Z

@muramura
In this PR, the AP's permission to clear Override can be set in RC_OPTIONS.

rmackay9 · 2022-02-03T03:46:08Z

Txs for this. In general I think it is good practice for the pilot holding an RC to be able to take control away from a companion computer easily. It makes sense to make it easy for a pilot to do that by simply moving the sticks.

libraries/RC_Channel/RC_Channel.cpp

libraries/RC_Channel/RC_Channel.h

libraries/RC_Channel/RC_Channels.cpp

tatsuy · 2022-02-03T08:32:40Z

@rmackay9 Thank you for your reviews.
I've added a commit to make the changes easier to understand, but I'm going to squash it eventually.

libraries/RC_Channel/RC_Channel.cpp

libraries/RC_Channel/RC_Channels_VarInfo.h

libraries/RC_Channel/RC_Channel.h

tatsuy · 2022-11-08T07:49:52Z

@rmackay9
I have used this with real rover.
It works well and it's useful.
Can you check this again?

peterbarker · 2024-07-25T05:28:54Z

This sounds like a good idea to me.

@tatsuy did you want to rebase this?

tatsuy · 2024-07-30T06:31:48Z

@peterbarker Thank you for your feedback. I have rebased.

libraries/RC_Channel/RC_Channel.cpp

libraries/RC_Channel/RC_Channel.h

libraries/RC_Channel/RC_Channels.cpp

peterbarker · 2024-09-04T11:54:58Z

libraries/RC_Channel/RC_Channels.cpp

@@ -89,6 +90,20 @@ bool RC_Channels::read_input(void)
        success |= channel(i)->update();
    }

+    // check if clear overrides by RC is allowed by RC_OPTIONS and any change in RC input during RC overrides
+    if (rc().clear_overrides_by_rc() && has_active_overrides() &&
+        (channel(AP::rcmap()->roll() - 1)->rc_in_changed ||


Why don't we just check to see if any of them are outside their deadzones - with the exception of throttle, which we eithre don't check or do check for a change...

... and maybe just have a uint16_t last_throttle rather than the rc_in_changed infrastructure.

We should probably also very that RC input is actually valid before checking any channel value!

I've modified the logic so that channels other than throttle are simply checked for being outside their deadzones.
For throttle, the value when the override is activated is stored in override_start_throttle, and any change beyond the deadzone is now checked.

tatsuy · 2024-09-24T08:07:45Z

@peterbarker Thank you for the review.
I have made the necessary changes based on your feedback.
I also confirmed the changes through SITL testing. Could you please review the updates again?