Joystick manual control idle rate

I’m using QGroundControl to manually teleoperate a prototype underwater vehicle over MAVLink. I’ve got it all working pretty well, but it seems like the manual control MAVLink messages go out at a variable rate (nice!) but at a fairly slow rate (maybe 4Hz) when the joystick is idle. I’ve been hoping to find a setting for increasing this idle rate so that there’s a little less latency when resuming control for the first time, because it’s noticeable. But I don’t see anything in the QGC settings or the joystick pane.

There’s also some irregularity in MAVlink manual control packet timing, with some noticeable substantial dropouts. Still less than a second (I will quantify eventually). This happens whether or not I’m streaming video over the same link as the UDP MAVLink packets (from QGC on Ubuntu to Raspberry Pi running MAVProxy with a 115,200 bps connection to my robot motion controller).

Are there some things I can do to improve these issues? Some requests I can make from the robot to tell QGC to send manual control messages more frequently?

Thanks,
Dan

Hi Dan,

Some of this came up during this PR that extended the QGC thumbsticks to control a gimbal. https://github.com/mavlink/qgroundcontrol/pull/6138

Longer term I think we need some mechanism to automatically scale the transmission rate. Any ideas?

I suppose my ideal transmission rate would start at a user-chosen minimum value and immediately spike up to the maximum (25Hz is fine) when control inputs start. This is pretty much what happens now, except I’d set the idle rate maybe at 10Hz in my particular application.

I’d also probably make the transmission rate decay slowly decay back to the minimum (over a few seconds, maybe with a user-selectable rate), rather than dropping back abruptly.

The user-chosen minimum rate would allow the user to balance the absolute worst-case latency with the available MAVLink command bandwidth. The slow decay would keep the controller responsive during short pauses in user input.

I also still need to diagnose the longer-term dropouts I’m seeing. If that’s because of other tasks in QGroundControl taking priority over manual control commands, that could also use some improvement, but I’m not sure yet that the issue doesn’t lie in MAVProxy on my Raspberry Pi or other network issues.

I wanted to update this. It appears that the lag issues that were troubling me were entirely my fault. I needed to increase the size of the UART buffer in my vehicle controller to avoid missed packets.