RC_CHANNELS stuck and not following /sys/kernel/rcio/rcin/ch*

ArduCopter Copter 4.5
1

Hello all! I think this is the right category, sorry if I got it wrong.

In short: RC_CHANNELS in mavlink data shows no response to transmitter inputs. but I know a signal is being received by the Navio since I can see a response to transmitter input (throttle) here:

# high
pi@navio:~ $ cat /sys/kernel/rcio/rcin/ch2
2006

# low
pi@navio:~ $ cat /sys/kernel/rcio/rcin/ch2
990

# middle
pi@navio:~ $ cat /sys/kernel/rcio/rcin/ch2
1549

So the signal is getting to the board and to the CPU. but, RC_CHANNELS and RC_CHANNELS_RAW don’t move at all:

image
image792Ă—1248 105 KB

I’ve been all over the Arducopter documentation, especially this page, which says:

For all protocols above, ArduPilot auto-detects the protocol of the RC receiver system.

Makes it sound like this should “just work,” although I wouldn’t be surprised if there were a parameter I had to set somewhere.

Protocol in use: SBUS. Failsafe: No Pulses. Rate: F1000 (-104dBm)
FC: Navio2 with RPi 3B as companion. Have followed the simple setup directions here and here
This happened in arducopter 4.0.3, and continues to happen after upgrade to v4.5.1.

Any thoughts? Is there a broken link between the /sys/* file descriptors and whatever Arducopter is reading from? Is there a config value to set somewhere, or a debug log to look at to figure out where the SBUS input is getting lost? Where does Arducopter read RC input from, if not these file descriptors?

Thanks!

2

Following for insight. Might be having a similar problem.

3

A quick followup - QGroundControl appears to be the culprit, sending rc input overrides which clobber those from the receiver. Switched to mavproxy and everything works. Will add more info when I have it.

1 Like
4

Indeed - Virtual Joystick was enabled in QGC - not sure if I did that or it was the default, but that was silently drowning out rc input.