Flyaway because of no receiver loss failsafe

At the weekend I had a fly away incident because the X8R detached from its mount causing a loss of communication with the TX, but radio failsafe is only triggered if the TX stops transmitting, correct?

Is there really no failsafe in the event of the RX becoming disconnected or detached in flight? This thread says that receiver failure is likely caused by power failure and the craft is crashing anyway, so this sort of failsafe is not needed.

Clearly my recent experience suggests that receiver failure failsafe is very much needed.

1 Like

I fly mostly fixed wings, and I did this very test on one of my aircrafts, because I placed the receiver on a wing which was removable, so it was connected with a plug embedded on the joint with the frame.

Anyways, That embedded plug with the connections from my receiver really bugged me and I thought there might be this possibility, so I was afraid that the embedded plug failed, so the flight controller would stop to receive any kind of signal from the receiver. I did the test several times, unplugging it once armed, and it entered on fail safe as espected (circle and then RTL for arduplane). I was using it in ppm mode, maybe in serial mode is different.

Are you sure everything was all right? Maybe it didn’t get 3D lock still, or any magnetometer issue could’ve caused the flyaway instead of a correct RTL.

Regards.

Radio FS and bat FS where both set and checked with GPS lock. Each FS worked perfectly. It never occurred that the radio FS was reliant on the RX sending a min thr signal to the Pixhawk to activate radio FS. Perhaps Plane is different, but I’ve checked again on a second Pixhawk and pulling the serial connection doesn’t trigger radio FS, even though (presumably) the Pix receives the same min thr state. What does happen, and perhaps more worryingly, is it locks the last known stick position, confirmed with the ch3_in and ch3_out, and also supports the behaviour of the fly away which was to continue to ascend.

Lloyd

You need to set the X8R up for “No Pulses” failsafe.That’s what I do anyway.There are other alternatives.

1 Like

If you physically remove the receiver from the pixhawk, or physically power it off, so the pixhawk receives nothing, that will engage the failsafe just like the low value does.

If that is true for Copter, then there is a problem with our setup, as that is not what happens when the RX is disconnected. I’d appreciate any help diagnosing this issue you can give.

Taranis is set to no pulses. Failsafe works in testing for radio and bat. Failsafe failed when the RX was disconnected.

@l3db6h What are your settings for the FS_THR_ENABLE and FS_THR_VALUE parameters?

@hsteinhaus
FS_THR_ENABLE = 1
FS_THR_VALUE = 884 (min thr value = 874)

How is your receiver connected to the Pixhawk? When I disconnect my receiver, that is connected via S-Bus, I definitely get a failsafe event. Just tested with master f2131ed a few minutes ago. I have similar FS_THR settings.

I think you need the failsafe value to be around 10 points below low throttle value and not 10 points above it.

[quote]Set the “FS Pwm” value to be:

at least 10 PWM higher than your Channel 3’s PWM value when the throttle stick is fully down and the transmitter is off

at least 10 lower than your channel 3’s PWM value when the throttle stick is fully down and the transmitter is on
[/quote]

If the Taranis is set to “No pulse”, then radio loss (Turn transmitter off or disconnect rx) should have triggered failsafe regardless of the value of FS_THR_VALUE.

Lloyd, sorry for your loss. Something is strange: If your Taranis was set to “No pulses” and you had FS_THR_VALUE set to higher than min pwm throttle signal like you indicated then you should not have even been able to arm in the first place and take-off, since arming at min PWM would have triggered the radio failsafe (set higher). Also unless disabled radio pre-arm check would have failed.

(If radio pre-arm check was disabled then you would have had to raise throttle first to clear radio failsafe, then get just above min failsafe pwm to be able to arm and take-off. It is technically possible (tried it) if min failsafe is just within the pwm band that will allow yaw stick to arm, but unlikely you did this? Also as others have said disconnected SBUS cable is same as turning off radio which means no pulse in your case => triggering failsafe.)

Are you sure failsafe should have triggered in the first place and issue wasn’t due to something else? Log analysis should shed light on this (check throttle RCIN). Does it flatten at 875 or so? (Taranis no pulse typical). Double checking http://ardupilot.org/copter/docs/radio-failsafe.html#radio-failsafe might also help. Everything can be tested on the bench.

Thank you for all your suggestions, but this is getting quite mysterious now. On the bench, the radio failsafe works when turning the TX off. I tested twice by pulling the servo lead for the RX (trying to simulate the events prior to the flyaway) and the Pix just disarmed both times. This isn’t what’s meant to happen but crashing to the ground would have been preferable to the flyaway.

Later the same day I tried pulling the RX servo lead and the Pix went into LAND mode. So it seems it works now, but there’s no reason I can see for it not working before or during the flyaway.

Added to this, yesterday’s testing in the field revealed that neither circle nor polygon geofence has any effect when in LOITER mode, with the multirotor just passing through the fence. Neither does the battery failsafe work in the field. This is with a pass on all prearm checks.

@Jagger That is how I have my radio FS is set

From the original post link - The only reason for a crash if the RX falls off is if the FC is powered through the RX.With redundant power supply it shouldn’t happen, nor if the RX is powered from the FC.It’s a weird one for sure.

I’m with Oliver.A log should have the evidence.

I confirm it happened to me a flyaway for the exact same reasons (i was running arducopter 3.4 at that time) : my RX was partly disconnected probably due to vibrations and the copter kept the last recorded signal from my TX
Fortunately i had set a Geofence that detected the breach and triggered RTL automatically
That was close from loosing it all…
I changed the cable connectors and everything worked fine again
I did not test it on recent versions of arducopter :slight_smile:

Did you figure out why the radio FS didn’t work that time? Mine works now but I’m very wary of it, especially as geofence isn’t working.

As others have said above, if the failsafe is enabled it should trigger a failsafe when the receiver loses power or is disconnected from the flight controller. That behaviour hasn’t changed for many versions Copter so I’d very much like to see the logs from this report and from Guillaume’s.

I’ve just tested now with AC3.5-rc5 and it’s working as expected. I remove the receiver, it triggers the failsafe.

As a side note, @l3db6h you say it disarmed immediately during testing - it did this because when a radio failsafe triggers while the vehicle thinks it’s landed it will immediately disarm. It wouldn’t have immediately disarmed if it thought it was flying. I suspect during the test, Copter thought it was landed before the receiver was disconnected (the way it determines if it’s landed or not is a bit involved so I won’t go into it here).

In that case the radio failsafe must have been disabled. I haven’t recovered the model so I can’t access the dataflash logs and I’m not sure where to find that information in the telemetry logs.

Re the radio failsafe not working on the bench, you’re right, I had moved the model after arming, but only to move it out of the way. A happy coincidence!

Thanks for your help @rmackay9, I always appreciate input from the developers.

Please upload your tlog. We can extract the parameters and see what your failsafe settings were and what it was reporting at the time.