DDS for UAV telemetry

[vooon]

Hello. I'm sorry, because this issue is little off-topic, but you know RTPS spec.

We are working on next generation of UAV telemetry protocol, so i would like to know does RTPS are good solution on low bandwidth connections (~5 KiB/s - for common modems)?
Also that task require serial transport, but you are already planned it.

[codebot]

This is really interesting! So generally speaking, RTPS is extremely flexible and you can use whatever serialization you want; there is a field in the message headers where you specify the payload serialization scheme.

That being said, the spec calls out CDR (either big- or little-endian) as the most common serialization scheme, and defines constants to indicate CDR with either byte ordering. CDR itself is very compact; with integer fields like in the low_bandwidth spreadsheet referenced on that issue, it's just like having a (memory-aligned) struct. I hand-crafted a serializer for the ROS2 IMU message to make sure I was understanding that correctly:

https://github.com/ros2/freertps/blob/master/apps/imu/imu.c

once the variable-length string "frame ID" in the ROS2 header is serialized using CDR (by just prepending a length field and padding to the end for 32-bit alignment), the "serialization" is just a memcpy:

https://github.com/ros2/freertps/blob/master/apps/imu/imu.c#L83

So CDR itself seems like a reasonable candidate for low-bandwidth comms, since CDR isn't really adding anything to the size. However, the RTPS headers do add a decent amount of overhead. I think that those headers are necessary for the original design goals of RTPS: an extremely flexible publish-subscribe system that can be globally routed over the Internet (hence the framing with UDP/IP, the very long ID fields, etc.). To try to understand the amount of overhead better, a few weeks ago I made a spreadsheet showing the various protocol stackups when using RTPS over UDPv4, and as you can see, there are quite a few fields before and after the cyan data payload. Maybe some of that is unnecessary (e.g., perhaps you don't need the heartbeat submessage for best-effort senders?) but I'm not quite sure yet.

Anyway, I think for really low-bandwidth connections, we'd want to define a mapping of RTPS onto this domain that gets rid of a lot of the fields that aren't necessary for low-bandwidth local-link messaging such as point-to-point radios, short inter-board UART links, rs485, full-speed USB, and so on. I think with a bit of trial and error design hacking, we could get the header down to just a few bytes, and if the application required or wanted global routing (i.e., a microcontroller talking over UART to a nearby POSIX machine with an Ethernet interface), a generic "gateway" program could "inflate" these super-abbreviated headers into the full RTPS/UDPv4 headers, copy the CDR payload into the message, and re-transmit to the LAN/WAN. Going the other direction could be done similarly (i.e., the POSIX gateway would condense the RTPS/UDPv4 headers into the bare minimum needed for the small-microcontroller client and forward the payload over the low-bandwidth local link).

This is definitely on our roadmap, since many (most?) microcontroller applications don't have Ethernet, and we want a principled, generic way to communicate with all of them. I don't have a specific target date though, since we're still working on cleaning up the FreeRTPS core and its integration with ROS2 messaging, so that instead of hand-crafting serializers like in that hacky IMU demo, we'll auto-generate them in a way that is conscious of memory-constrained, all-static systems, etc.

Cheers

[vooon]

Thank you!

You are right, headers require too much space, but i hope that it might be reduced under to ~24 bytes.
But CDR is good, almost same as plain packed struct.