I tried following today on 2.0.49 firmware with APM Planner 1.0.86. As you can see from the video, there was obvious lag in the command around 1/2 seconds. The other thing the quad was doing it was not coming to stabilize position when I centered the joystick. This is because of the uneven cushion I placed above table. The settings are
Joystick: Saitek Cyborg
Telemetry: 900Mhz xbees @ 57600bps link speed
frame gaui 500X
Joystick is pretty slow to respond. When I checked in windows game controller I found out that in game controller calibration looking at the raw data the joystick response is slow. So its a windows + PC issue
Comments
I meant application specific compression, like Mike described.
Using XBee in API mode would also allow to leverage the capabilities of XBee, which are currently unused. Like having retransmitters, for example, greatly extending telemetry range.
Yeah forget general compression algos - this is so application specific you will get much better mileage out of custom compression - like you say doing deltas on repeated packets etc
Mavlink is pretty asymmetrical in it's bandwith demands however - so unless the Xbees are not truely duplex, then compression wont help the uplink performance much.
I do like the idea of mapping Mavlink network to the XBee API - sounds interesting. Are there any other GCS systems doing this? Mavlink is designed to control multiple UAVs...
@Andrew
Yep, that's right. Data can actually get changed, as I guess packets might get delivered in a different order, but that's irrelevant. Delays can actually be much longer, I've seen delays in seconds. Indeed, time stamping can be used to solve this issue. But I found it to be too much hassle, I ended up feeding joystick output to futaba student link.
@Andrew
If the Xbee does retransmits, I hope it also does packet ordering. Because if packets arrive out-of-order, it can make flight control very difficult. From my work in the telecom industry, that's one of the most difficult issues for voice transmission over IP networks. Either use UDP and get dropped packets, or TCP and get latency due to having to ensure that packets are delivered in order.
From a flight control point of view, I'd rather loose packets, and go into a failsafe mode than, live with latency which makes the craft operate unpredictably.
@Simon - I started with the old standby of lzo, before I realized how much of a pain that might be on arduino, but then I realized that with such as well defined protocol, there are lots of areas we can optimize even without stageful techniques... and with a pair of mini-s observing/compressing the flow, we can maybe get even more. It seems like maybe this would even be better than lzo on mavlink data? In any case, I have't found much on a good lzo algorithm that fits on a mini, for good reason, I gather. Building a data dictionary is limited, local cached tokens at least for a generic data algorithm, since memory is not trivial, but a small mavlink-specific state table is easily do-able, and I believe that beyond encoding we will find a lot of redundant data passes.... the same values.
In the case of Xbee, when you consider the layers, you have a radio id and also in MAVlink, you have a duplicate sysid (or, it could be the same) and both are sent over the radio. Yes, its only one byte. But it is one byte for every message, 1/6th of the header. I don't know if that would get padded, as with many transport protocols, but usually radio data link does not pad this way. So that is another technique, besides these other two, to reduce the total quantity of data sent. But I don't know at what point you need to start bursting....I assume you would need to, but I haven't given it much throughout since the Xbee either can help or cannot, and my experience with Xbee is limited to a few sessions of fooling around with the pros and my digimesh modules
@Mike
I too like the data encoding and compression to reduce bandwidth requirements. However, I'm not sure what putting telemetry on I2C will achieve? Will we have to get yet another I2C wireless device to transmit that data? There's only so much money and usable frequencies that we can have for telemetry, control, and video downlinking.
Right so we are using the Xbee in emulated serial - and the xbee is using it's proprietary transport to ensure delivery as much as possible. This could include queueing and retransmits - which would not change the data at all (Unless there is a huge link interruption and the queue tops out) but does change the timeliness of the data - in other words you could have regular 50ms Joystick control packets, then nothing for 200ms - then a sudden splurge of 4 backed up packets.
I'm not sure how irregularly times joystick control packets are treated in the APM. There are techniques that can mitigate some problems - and time stamping of the packets would possibly help.
But all of this is speculation until someone does the end to end tests that determine where the link latency is. Sounds like there is scope for some quick wins in the planner code.
@Mike - Nice idea regarding data compression with a dedicated arduino mini.
after that, I figured I might try to push the telemetry over i2c, free up the TTL for something else. But I'm so far behind in my projects I don't know when I will ever get back to it.
@Andrew Radford
XBee has quite complicated system, allowing to build a network with multiple nodes, retransmitters, packets traversing the network in a search of their destination, etc (I never built such network, but this is how it is supposed to be in theory). There are two ways to interface with XBee: API and serial. API gives an access to the entire XBee network and all its features. Serial uses all those features to emulate serial link. Esentially it groups bytes transmitted over emulated serial interface in a packet and sends this packet to a destination, then utilizes internal network mechanism to try its best to deliver the packet. So the stack of protocols here would go: XBee network layer (packetized), emulated serial (data stream), MAVLink (packetized). There are some configuration parameters which can be relevant here.
-
5
-
6
-
7
-
8
-
9
of 12 Next