Servers by jDrones

Faulty RC signals - Emergency stop

frsky
pixhawk-cube
(Agising) #1

Summary:
During a flight five RCIN channels changed values during 1 sample triggering emergency stop. Luckily system quickly recovered, but now I’m grounded and I need to get up again soon.

Setup:
Hexacopter
Pixhawk 2.1 Cube running ardupilot 3.6.8 stable
Raspberry pi companion computer connected to serial 0
FrSky RX8R, only connection is Pixhawk RCIN (RX8R powered through this interface)
Taranis X9DPlus

Fail safe settings:
I cannot say for sure, but the intention was to set up XR8R for no pulses (no pulses selected in TX prior to bind, bind, power off TX+RX, power RX brief push on RX when TX off, finally power off RX+TX). I have found no way to verify that these are the actual settings.
On ardupilot I had FS_THR_ENABLE set to 0 (no action) during this flight for different reasons.

Normally this setup works as intended, I tested it the same day by switching off the TX during flight.

Unfortunately I had not set up RSSI logging, but I have corrected this now. There are RSSI logs and RXbat logs from TX memory card though and they are fine.

The problem:
Hexacopter is flown by Raspberry via dronekit-python. It flies ‘goto’-commands in guided mode. All of a sudden, 350m away, it drops altitude and then recovers. The ArduPilot log reveals that the five of the interpreted signals from the receiver makes a step for one sample. One of the channels is set up for emergency stop and this was triggered and then recovered.

Affected channels:
Channel/function | Value before and after event | Value during 1 sample
CH3/thr: | 1502 | 874
CH5/flight mode: | 1903 | 2085
CH7/RTL: | 997 | 1408
CH8/Emergency stop: | 1487 | 2019
CH9/gimbal pan: | 1872 | 1016

We are desperately trying to reproduce the issue on ground but no luck.
In one test on a twin system (same, same) we powered the RX from other source and it was still operational at 2.5V.

Screenshot:


ArduPilot log:

(James Pattison) #2

I haven’t checked the log, but which specific firmware version (I know you’ve said 3.6.8 stable, just double checking)?
The symptoms sound similar to an issue that was identified and resolved some time ago (https://github.com/ArduPilot/ardupilot/pull/10216)

(Agising) #3

Thank you,
My version is 3.6.8 (2f409678)

If I understand correctly, the out-of-range during recovery should be interpreted as 874. This is indeed the value of ch3/thr, but I think I suffered from ch8 going to 2019. Indeed, this is also out of range, but if it was interpreted as 874 it should not trigger the emergency stop that is set to 1800 (default CH8_OPT trigger value).

36

(Joel Nordahl) #4

This is not a solution to the problem, but one way would be to put emergency stop on two channels, so a combination would trigger emergency stop and not just one channel. Here comes the big but… But I’m not sure if that’s possible in ArduPilot? Maybe someone that know the code could answer that?