search

PX4 / PX4-Autopilot

PX4 Autopilot Software
https://px4.io
BSD 3-Clause "New" or "Revised" License
8.2k stars 13.37k forks source link

RC PPM Failsafe Failure and RSSI Freeze #16594

Open ryanjAA opened 3 years ago

ryanjAA commented 3 years ago

When using a PPM receiver with an autopilot that does not have an i/o coprocessor the RC Update Module isn't handling PPM RC Failsafe or RSSI correctly.

This was tested on an MRO Control Zero F7 but the issue should effect more than just this board given the PPM and RSSI boilerplate.

When a PPM receiver is connected and the connection is lost the autopilot goes into RC Scan State Mode (in the RC Update Module) to determine what is connected (even though the receiver is already connected).

The main issue with this is that PPM receivers don't go into RC Failsafe. It looks to be an issue with the RC Update Module and how it is handled at the module level for non I/O coprocessor autopilots.

Tested with an X8R (SBUS) and a Dragonlink (PPM) as well as a Dragonlink set to SBUS as the output. SBUS worked as intended. See screenshots below.

SBUS Receiver Connected (X8R):

105082073-ab26ca00-5a58-11eb-9393-1191dc183dd9

SBUS Connection lost (by turning off the transmitter) - Failsafe is True:

105082119-ba0d7c80-5a58-11eb-8eea-16536f1a56c6

Dragonlink Connected (as PPM output):

105082182-cd204c80-5a58-11eb-8ec9-f5f7fca2cb88

Dragonlink Connection Lost (with PPM output and Transmitter Power Removed). Note Scan state:

105082308-fa6cfa80-5a58-11eb-93a9-7f30a8cee1a4

Another view of the Dragonlink (as PPM) but with no connection and going through RC Scan State.

105082406-225c5e00-5a59-11eb-8199-dcdf0ccafff3
dagar commented 3 years ago

FYI the actual failsafe is handled downstream based on manual_control_setpoint timeout.

ryanjAA commented 3 years ago

Awesome - Thanks for the heads up.

But then also why is the RC Scan state scanning through?

I suppose the issue is the same but the location is different than my assumption.

I will rename.

dagar commented 3 years ago

But then also why is the RC Scan state scanning through?

It happens when the rc_input driver hasn't seen any signal for more than a second.

https://github.com/PX4/PX4-Autopilot/blob/386b56fbce20f7e92931893a682285558d32bb4b/src/drivers/rc_input/RCInput.cpp#L625-L627

I don't think it's really a problem, but a couple options that come to mind.

  1. disallow scanning and re-entering scan state when armed
    • you can regain existing RC, but nothing new
    • this might also prevent some rare false positives where garbage is successfully decoded as a single valid packet of some kind
  2. adding a parameter to explicitly configure the RC protocol or a bitmask to limit the options
ryanjAA commented 3 years ago

It only happens with a PPM receiver though. When using an SBUS receiver it goes into RC failsafe (and the RSSI signal drops to zero so that should at least be fixed on the PPM RSSI output) but it's a problem if you're relying on RC failsafe unless you are saying that because it gives you a "Manual Control lost" message in QGC it would still initiate an RC failsafe it is just not saying it and running through the scan.

ryanjAA commented 3 years ago

Practically speaking only two things really matter to the user in my head, that a RC failsafe and therefor RTL (if set up that way) would occur on loss of signal and that the RC RSSI signal reflects what is actually happening so they don't think they have 78% signal but it nothing is working.

When I disconnected the transmitter on the PPM receiver at ~90% signal it stayed at 90% and went into scan mode. When I do it with the SBUS receiver it drops to zero.

Also, when I test this on a Pixhawk 1 the PPM receiver RSSI drops to zero as it should, I will test if it starts scanning though as well and says it is in RC Failsafe.