PX4-Autopilot: Critical RC Loss Failsafe Bug, Potenial Vehicle Lost
Describe the bug Hello, I’m using PX4 latest Firmware in Pixhawk 2.1 (Cube). Geometry is generic Quadrotor X geometry. My communication system is depending on RF modules(Long range ~900MHz) between Vehicle and RC. I’m feeding Pixhawk RC_IN with RF PPM signal out which is on RC. Radio Controller’s (FrSky Taranis X9D) PPM frame length is 22.5 ms and it has 8 channels. Failsafe action was RTL.
Yesterday, I was trying failsafe actions. While I was trying RC Loss failsafe, I just power off RC by manual and failsafe action wasn’t triggered. Then, Vehicle just fell down.
I just examined log data. I explored PPM signal didn’t cut off by RF.
PX4 thought PPM signal wasn’t cut off. RF is sending continuously PPM signal which has 12 channels when RX-TX communication is lost. Channels have 1 ms frame length and PPM frame length is 24ms which has to be 22.5ms.
The problem is that RF module sends PPM signal even RC signal is lost. It also send 1ms signal which is meaning lowest signal strength for channels. So, failsafe action isn’t triggered by itself which causes vehicle fall.
To Reproduce Steps to reproduce the behavior:
- Drone switched on.
- RC switched on.
- Took off with any mode.
- Cut off RC power.
- See error.
Expected behavior When RC signal lost, failsafe should be triggered independently of RF PPM signal. Also, number of channels and frame length shouldn’t be change itself when vehicle is armed.
Log Files and Screenshots
When RC signal is normal.
When RC signal is went off.
RC frame and channel info.
Possible solutions:
For my case, I just changed this line:
https://github.com/PX4/Firmware/blob/528d2f61a0ac30daa100f06de0cc78dcc072e43e/src/modules/sensors/rc_update.cpp#L230
To this:
if (rc_input.rc_lost || rc_input.rc_failsafe || rc_input.channel_count > 8)
It works but I know it is dirty solution.
Solution 1: We should change line which is constrain value of this message: https://github.com/PX4/Firmware/blob/cc68775defa8432560bd7bb90a038d9e7c0fa8c9/msg/input_rc.msg#L22 And the number of channel should change by only calibrating RC. When number of channels is changed on armed state, failsafe should be triggered.
Solution 2: PPM frame length also has constraint value by RC. When PPM frame length changes unexpectedly, failsafe should be triggered.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 25 (24 by maintainers)
Oh man, if someone goes to the trouble to do all of that, it must certainly be intentional and should also be acted upon… I have been flying rc for 3 decades now and can state with certainty that those signal commands do no happen by accident.
Ok, so you’re suggesting that we add a check like this?
If number of channels == 12 and all channels == 1000 PWM then RC lost -> failsafe?
As opposed to trying to detect an RC cutoff from an incorrectly setup radio Is there a way to maybe include an RC cutoff test procedure in QGC similar to sensor calibration? Have a flag for a radio/aircraft pair that alerts the operator that RC cutoff hasn’t been tested?
Or just a parameter and annoying notification like the VT_ROLL_DIR_V19 or whatever that you have to manually set to get the warning off.
Ok @bozkurthan I think that check is good.
@dlwalter actually I have same radio. But how we can avoid from this issue. Failsafe test procedure is plausible. But after that there should be some structure for this issue.
@julianoes RC_FAILS THR for only unreliable PWM output. As @dlwalter mentioned we have valid signal from RFD900. Maybe we can add RC_FAILS_CH_THR (which means threshold for channels) to avoid this issue. Furthermore it should be configurable for RC types (e.g. RFD900 radios send 12 chs and 1000 pwm per ch). When we choose RC type, failsafe scenario can be change by itself. Also, we have type of RC in message system which detected by driver module.
https://github.com/PX4/Firmware/blob/12fcddd288911a32060b7fd2a52c22ab65290535/msg/input_rc.msg#L3-L17
I ran into a similar issue with our RFD900 radios - RFDesign’s windows GUI tool was not programming the failsafe signal correctly and instead all 12 channels would just output 1000us - which would correspond to low throttle, full roll, roll pitch, and disarm.
https://discuss.px4.io/t/rfd900x-failsafe-ppm-not-programmed-correctly/10364/3
I recommend everyone tests their aircraft behavior in a strapdown test and cut off ground radios to see if it is appropriately detecting an RC loss.
I think the problem is probably a receiver configuration issue - PX4 cannot trigger a failsafe if it is still getting what looks like a valid PWM signal.
@julianoes this has come up before but docs have not be updated (probably need to update here). Do you know what a receiver should output when the transmitter stops, and how is this configured? - e.g. for the main receivers we support https://docs.px4.io/master/en/getting_started/rc_transmitter_receiver.html#compatible_receivers If not, who would be best person to ask. [And of course I am assuming I’m not completely wrong about the cause!]