I’m interested in using a joystick connected to QGC as my primary means of control. It works fairly well except that it suffers from from some pretty bad latency. After further investigation I have found that this is due to collision avoidance in the 802.15.4 protocol that the radios use. Basically, only one of the two radios can be transmitting at once, so if the ground station detects that the drone is transmitting then it will wait for a moment of silence before sending its Manual Control packet. This would be fine if each of the two radios only intermittently transmitted, but it seems that the pixracer is constantly transmitting. I’ve managed to reduce this problem by tweaking the settings on the radio but I still occasionally get gaps in the Manual Control packets that last ~720ms. There are many ways that this problem could be solved but most of them would involve significant modifications to the way that MAVLink transmissions are handled by the firmware. I think the simplest solution would be to just reduce the amount of the information that the pixracer is broadcasting. From looking at the MAVLink inspector (image attached) it looks to me like at least half of the information being broadcasted is not necessary for normal operation.
Does anyone know what can be done to configure the pixracer for more “lean” transmissions? It seems, for logging purposes, like QGC should have the ability to request/unrequest certain types of information from the FMU.
Thanks! That will definitely get me started. A better option than just reducing traffic would probably be to use some sort of data flow control. Like this: https://en.wikipedia.org/wiki/Flow_control_(data)#Sliding_Window
Are there any plans to implement something like this?
Not that I’m aware of. Would you be interested in figuring out how that could work within the existing mavlink spec (http://mavlink.org/messages/common) or extending it, and implementing something similar? Most mavlink messages are not acknowledged.
Here’s the existing rate limiting in the PX4 mavlink module.
Hi @Nick_Anthony and @dagar
Great somebody else is looking in that topic. I’m also often using direct joystick input over mavlink and experienced similar outtakes (or latency) as Nick mentioned above. Depending on the radio module, its configuration and communication load I could measure the gap between two joystick inputs being up to 1600ms (instead of 50ms).
I’ll get you posted if I get a good solution.
@makrebs, which radio modules have you tested with? So far I have only been using Xbee pro Series 1 using the transparent 802.15.4 firmware.
Something that might work would be:
1: The GCS begins transmitting the manual_control packets.
2: The MAV briefly holds off from transmitting and syncs to the incoming manual_control packets.
3:Once synced, the MAV begins transmitting but makes sure to stay silent when a manual_control packet is expected. Once the packet is received it begins transmitting again until the next packet is expected. This will prevent packet collision which I believe is responsible for the latency.
This would only benefit half-duplex radio systems (which I believe most of them are). It could be an option that is enabled by a parameter.
I don’t think a custom handshake system is THE solution for the issue. For example, there are options like Random Delay after a data collision that can be specified for the modules independently. This allows to give higher priority to the joystick uplink than the telemetry downlink.
I mainly use the Laird RM024 module.
The Xbee pro modules that I use also use csma (random delay to avoid collision). I have configured the joystick transmitter to prefer lower delays while the MAV transmitter is fine with larger delays. However, I still get reports of “Manual Control Lost” that last between 500-700 ms.
I started trying out SIK radios since that seems to be the most commonly used. They have version 1.9 on them but so far they don’t seem to work much better. MANUAL_CONTROL packets are dropped less often but when they are dropped it is usually for >2 seconds.
The firmware has a “low latency” mode but as far as I can tell from the documentation this only works for RC_OVERRIDE packets, which (as far as I can tell) are not preferred by QGroundControl/Px4.
I’d like to edit the firmware to treat MANUAL_CONTROL with the same high priority that it treats RC_OVERRIDE. Does anyone know if this is the official repository?: https://github.com/ArduPilot/SiK
Unfortunately it looks like “low latency” mode was removed from the code a few months ago. There are still a few relevant #defines and variable hanging around but nothing functional.
