Copter: RC_OVERRIDE_TIME not working

[nex-robotics]

Bug report

Issue details

RC_OVERRIDE_TIME parameter according to definition says.. "Timeout after which RC overrides will no longer be used, and RC input will resume, 0 will disable RC overrides, -1 will never timeout, and continue using overrides until they are disabled" However, even after setting the parameter RC_OVERRIDE_TIME in mission planner to value between 2 to 120, the failsafe is always triggered after 1 second. The RC_OVERRIDE_TIME failsafe is always triggered after 1 second after disconnecting Joystick, irrespective of the value set (between 2 to 120) through mission planner.

Version All versions of Copter firmware

Platform [ * ] Copter

Airframe type quad X

Hardware type Pixhawk

Logs

[rmackay9]

I only became aware of this parameter a few weeks ago after a discussion with @WickedShell. I think it was added but the Copter portion was not implemented so I've marked this as an "enhancement". I think we should certainly support it though.

[WickedShell]

This parameter will only affect how long to use the overrides in the situation where you have new input of some form. IE this controls what the RC library will report when polling for what the current input is. If the RC receiver is triggering decoding then this parameter works as described. If you have no RC receiver active then you will fall into the normal no input failsafe, which on copter has a hard coded timeout you can't work around (and the hard coded value is different if overrides are on or off).

[rmackay9]

@WickedShell, I'm afraid I don't understand what you mean so perhaps we can discuss at some point.

[nex-robotics]

@WickedShell, @rmackay9, Is it possible to have RC override as primary control and have an RC override timeout which still works when RC input from RC receiver is non existent?

[WickedShell]

Not really with the current architecture. Both plane and copter include features to ensure that we don't use frozen/lost link inputs for to long, which will always kick in relatively quickly, which means that you have to ensure you get your overrides in at this frequency or higher. But to be fair if you can't get overrides into the vehicle at quite a bit better then 1Hz you really shouldn't be using them to control the vehicle flight any ways.

[nex-robotics]

@WickedShell We are using our copter mostly for long range flights with clear surroundings where operator intervention is at minimum. It also has on-board obstacle avoidance to take care of any dynamic obstacles and mostly operator is not burdened with this task. Therefore, having fast link inputs (better than 1Hz) is not required in our case. We want to avoid return to home if the vehicle temporarily looses link for few seconds. We can always recompile the firmware and achieve this. However, we thought better to have this working in released firmware if possible.

[WickedShell]

@nex-robotics What are you trying to do with the overrides then? At this point when you are doing long range flights and are trying to take corrective action guided is usually the better option, as you can specify a controlled position to go to, and link hints won't cause the vehicle to drift.

[nex-robotics]

@WickedShell Ideally, we want to have a controller similar to RC but without the requirement of additional link for RC. The next best alternative of doing this seems to be using Joystick connected to ground station. The joystick based control (where joystick is physically connected to ground station) uses RC override for sending control inputs. We faced problems while in auto mode. When link drops for more than one second, the vehicle goes in RTL. We can always choose continue mission on link lost. However, a better option would be longer timeout that can be configured. This still gives us safety of RTL on serious link loss happening for longer time. Using Guided mode is a great option, but we want users to be in greater control with a joystick at hand for controlling movements of vehicle.

[WickedShell]

The point I'm trying to get to though is that if you don't have RC input for more then a second letting the vehicle continue to lean at a commanded angle from the sticks is very unsafe. Guided and similar modes work well for this.

If you want a longer timeout after the input is reset to neutral that's a different conversation (and quite reasonable), the OVERRIDE_TIME thing, simply has to do with how long to use packets, and it's primarily of use when you have an RC receiver connected as well as overrides. Plane does this via the short and long failsafe system (which has it's own limitations, mostly that it uses the same times/actions for RC and GCS failsafes, but you can at least select these as the user).

[rrr6399]

I fly with no RC receiver often and only update the RC Overrides when something changes. I usually fly the copter in Loiter or Auto so you shouldn't need to continue to update the overrides if nothing has changed. There is already a FS based on the GCS heartbeat so I don't think there needs to be another timeout. Also, I may also just override the yaw control and leave all the other settings at trim using the IGNORE OVERRIDE for the other channels. I have been setting the RC_OVERRIDE_TIME=-1.

Should this approach not be working?

[WickedShell]

@rrr6399 updating RC overrides only when something changes is completely unsafe unless you update continuously until you see from the downlink that it's received the last thing you sent. I've seen numerous vehicle have serious problems (including crashing) due to only sending when something changed, but the something changed packet got lost. If you monitor the downlinked input packets you can move to closed loop control which becomes safe, but if you are operating open loop then I'd deem this to be unsafe, and relying on pilots to have itchy fingers/constantly change stuff when they are touching the controls, which is not always a good assumption (particularly goes wrong when they put in stick limits and hold it).

Copter handles the RC input/fail safes a bit differently then plane so I'm afraid I can't give a good summary on if that's a good/bad idea/not supposed to be working. (I'd need to spend a good chunk of time just reading through copter code again to get there)

[rrr6399]

@WickedShell thanks for the response.

I send the override command three times for every change, which has proven to be reliable for my use case and setup. We are only doing small tweaks (flight mode change, yaw and eventually gimbal commands) with the Joy Stick or using it to do perform auto-tune or yaw control for nearby flights. (If you look at a lot of the GCSes, they tend to send commands at least three lucky times to overcome telemetry issues since MAVLink lacks ACKS for many commands.)

Most of the time for our use case, the overrides are done to simply initialize the 4 channels to trim values when a receiver isn't present since the current default values of 0 can cause a catastrophic wildly spinning copter on auto takeoff or a rolling, pitching, spinning copter on landing or when in loiter.

I like the idea of a closed loop check and I may do that for extra reliability. I have resorted to doing that when downloading the 800 parameters since that process can be very error prone over the current low costs links.

I have thought about adding a timer to continuously send RC overrides of the current joy stick state if anything to eliminate the need to set the RC_OVERRIDE_TIME=-1 even though it wastes a bit of bandwidth. (It gets a little more complicated when we have to detect that the RC is turned back on and then release the overrides.)

[rmackay9]

I think we should close this because RC_OVERRIDE_TIME is working as designed now. Perhaps we should create a new issue which allows users to specify the RC failsafe timeout.

Edit: here's the new issue: https://github.com/ArduPilot/ardupilot/issues/13591

[ilyxas]

Hi, Let say ArduPilot 4.1.5 with RC_OVERRIDE_TIME IS 30 SEC What happen if I:

1. Set mode FBWA
2. Command RC_Override_channel for some time with CH1 CH2 CH3 Values.
3. Set mode MANUAL from RC Controller
4. Set mode FBWA back

Does the switch between modes reset RC_OVERRIDE_TIME timer? What values shall i expect in channels?

Thanks!

[iNotMario]

This parameter might need work... As @WickedShell has indicated, this parameter doesn't do what you might think without a regular RC input.

The following [copter] situation will result in dangerous (albeit definable) behavior: 1) Use Mavlink RC Overrides without any RC Input (eg, no sbus) 2) Have LAND_REPOSITION enabled, and Throttle Failsafe to RTL 3) Stop sending overrides while RC Overrides has Roll or Pitch not centered.

The following will happen: 1) The copter will initiate a throttle failsafe. 2) The copter will RTL correctly until landing phase. 3) While landing, it will drift according to the last received Roll/Pitch overrides.

[rmackay9]

@iNotMario,

Thanks for this report. Could you report this in the Copter-4.5 support forums here?

From inspection of the code I don't see a bug that would lead to the scenario described because inside the land controller it protects against consuming the roll/pitch input during a throttle failsafe.

Of course I may very well have missed something though. I just want to confirm that you've definitely tested this (ideally in SITL) to confirm this issue?

[iNotMario]

You're right -- My mistake. The reported failsafe was GCS failsafe - not throttle failsafe. Throttle failsafe was not turned on as it's always GCS controlled. Got two configs mixed up in my analysis.

That would explain why that segment of code would still be consuming it. Looks like using a throttle failsafe instead of a GCS failsafe would have prevented the issue.

So the scenario is slightly different. Everything is the same except for the type of failsafe - it's GCS failsafe without throttle failsafe. Plus it requires a few FS_OPTIONS to get the GCS failsafe to trigger during pilot modes! So a bit more exotic than i had originally thought. It does still exemplify an issue with the parameter.

[rmackay9]

Hi @iNotMario,

I think if the RC/throttle failsafe is disabled then all kinds of problems will appear with various flight modes continuing to consume the RC inputs when they shouldn't.

I understand that there can be confusion between GCS failsafe and RC failsafe when the RC packets are going over the telemetry link but the GCS failsafe is not there to act as an RC Failsafe. We already have an RC failsafe and it really shouldn't be disabled (it's enabled by default).

Apologies if I'm misunderstanding something.

[iNotMario]

I think you understood fine. My own misunderstanding is what got me here! Clearly if the RC Failsafe had been turned on, it wouldn't be a problem.

FYI, the RC Failsafe was disabled for a reason earlier mentioned in this thread -- it's a bit sensitive for higher latency links. So my silly solution was to use the GCS failsafe -- which has a nice pretty timer -- and combining it with FS_OPTIONS to make it act more like an RC failsafe.

But alas, the landing mode still consumes RC inputs during a GCS Failsafe (rightly so, probably) exposing the problem that WickedShell noted when no RC is connected.

Big thanks for looking. Settled some confusion on my part on the need for both failsafe.

[iNotMario]

Hello Again,

I have verified that the RC_Failsafe resolves this issue. (I did also reproduce my original issue, so everything works as one would think - knowing the fact that a RC Failsafe does more than simply change the flight mode [aka suppress RC reads in some code regions])

Would it be reasonable to propose a new FS_THR_ENABLE value that would enable the failsafe itself, but never directly affecting the mode of the copter? It seems to me this would be fairly simple to implement, and provide a simple blocking mechanism against invalid RC data when we otherwise don't want an RC Failsafe to ever change the flight mode on it's own.

If that seems like it would be a reasonable proposal, i can probably set up a pull request. I just don't want to bother if nobody sees value in it.

[rmackay9]

Hi @iNotMario,

Txs for the feedback.

Adding an FS_THR_ENABLE, "ReportOnly" option is reasonable and we have this for other failsafes. I wonder what is the use case though? We already have the ability to not trigger the mode change when the vehicle is in Auto or Guided mode (see FS_OPTIONS) so the only time that the mode change will occur is when the vehicle is in a manually controlled mode. And why would you want the vehicle to stay in a manually controlled mode with not RC input (where RC input covers both the normal RC and joysticks).