RC_Channel: input value watchdog

[SergeyBokhantsev]

Impl. for #5375
Personally I've never faced such issues but there is a real risk exists taking into account RC receivers are complex devices and some Vendors does publish not very stable firmware.

It is supposed that user will set the TIMEOUT parameter for one or several channels so they will be monitored. And if any of the monitored channels got stuck with the exact same value then Radio FS should kick in.

[WickedShell]

I don't see how this is actually useful, requires you to be moving every channel constantly, even your switches/flight mode channel/things you aren't mixing.

[SergeyBokhantsev]

@WickedShell, thanks for taking a look. This is the optional safety feature that can be useful for someone; but unfortunately I don't see a way to make it good for everyone.
You don't need to move every channel constantly unless you have enabled the watchdog for every your channel. Normally you need to enable watchdog for a single channels only.
Here are the use cases:

1. If you're flying in a racing style then you could set a 20 seconds timeout on your pitch/roll channel.
2. If you flying smooth/auto missions then may be you're controlling your yaw or camera tilt etc. So you could set a 120 seconds timeout to the corresponding channel.
3. Some radios when rc link is alive provides a small noise, so the channels looks like
   
   So you could set a short timeout for one of such channel.

I understand the current solution is not ideal. Any ideas of how that could be improved further are really welcome!

[peterbarker]

How about a simpler solution - no channel mask, just checking that we have seen at least one channel change value in the last seconds. Any channel specified as an RSSI channel would be ignored for this check.

This would catch the case where someone has not set up throttle failsafe appropriately and their receiver reverts its outputs to the bind values, but without a tell-tale throttle value.

I'm marking as devcall so we can decide whether any such feature is desired...

[lvale]

So, during a mission where you take off manually and you can be looking at the grass grow this could kick in if misconfigured......I know setting to zero disables it.....but.....

[peterbarker]

On Fri, 12 Apr 2019, Luis Vale Gonçalves wrote: So, during a mission where you take off manually and you can be looking at the grass grow this could kick in if misconfigured......I know setting to zero disables it.....but.....

It's relying on the small amount of noise you usually see on RC input. Yes, that's a problem if you happen to have a very clean RC signal somehow. Having your RC transmitter able to produce a sine wave on a channel would be ideal.... but if you're able to set that up you're probably able to set up a throttle failsafe properly ('though this scheme also helps if the receiver malfunctions in that case).

[WickedShell]

It's relying on the small amount of noise you usually see on RC input. Yes, that's a problem if you happen to have a very clean RC signal somehow.

Clean RC is easy...

If you zoom in on those flat sections it really does stay perfectly undisturbed, and the RC transmitter is powered on/connected. Clean RC is trivial to get if you use any of the digital input protocols and are flying autonomously (heck even Cruise is easy to be idle that long).

I won't block, but it certainly has to be an off by default feature. I still don't like it, as it seems to just be trying to accommodate badly setup receivers/unsafe ones.

[lvale]

as it seems to just be trying to accommodate badly setup receivers/unsafe ones.

I agree with @WickedShell

If we start going after every marginal setup it's never going to end.

[proficnc]

Modern RC’s are locked it, this is not a great option sorry.

[tridge]

I don't like this - it is so dependent on equipment (and depends on bad equipment!), and is bound to produce false positives