Very high latency with telemetry joystick control on Matek but not Pixhawk

I had a Pixhawk 1 running ArduCopter 4.0.3 flying happily with a gamepad joystick, sik radio, and QGroundControl - no RC transmitter needed.

Now I have the same setup with a Matek F405-CTR and ArduCopter 4.0.5. It seems to switch modes and arm fine, but once armed I get up to 2 seconds of control latency, which is completely unflyable.

Radio settings:

  • Mavlink: low latency
  • Packet size: 33
  • Baud: 57600
  • Air speed: 128kb
  • Error correction: yes
  • RTS/CTS: no

ArduCopter settings:

  • Serial protocol: Mavlink 2

I know control by joystick is not ideal in general, but why do I have issues with the Matek, but not the Pixhawk? As I understand it the Pixhawk 1 and Matek F405 use a similar class of processor. My only guess is the Matek is queuing the RC override messages instead of processing them as interrupts, but I have no idea how to verify this or fix it.

Following up here.

It seems like the latency was a perceptual effect caused by a poorly tuned copter. I was testing the quad light - super light… 15% thrust to hover. It turns out even in learn-hover mode, Arducopter struggles to figure out such a lower hover thrust, so whenever I request a small change in altitude it rockets up and takes a second or two to slow down.

Once I weighed the quad down, I found I still had severe oscillations that were making the whole quad generally unpredictable and unresponsive. I halved my P/I gains and managed to get it flying well enough to autotune safely. After that it’s been rock solid.

Again this had nothing to do with radio latency. Just gravity failing to supply sufficient downward force.