I’m not using ROS myself, but I understand that ROS 2 relies on DDS as its middleware, so I thought this community might be a good place to ask.
I’m working on a UAV system that includes a secondary datalink between the drone and the ground segment, used for control/status messages. The drone flies up to 35 km away and communicates over an RF-based datalink with an estimated bandwidth of around 2 Mbps, though the link is prone to occasional disconnections and packet loss due to the nature of the environment.
I’m considering whether DDS is a suitable protocol for this kind of scenario, or if its overhead and discovery/heartbeat mechanisms might cause issues in a lossy or intermittent RF link.
Has anyone here tried using DDS over real-world RF communication (not simulated Wi-Fi or Ethernet), and can share experiences or advice?
It works really bad even over wifi. You can find lots of evidence here on the forum.
The basic problem is that it uses UDP to send messages, and if you send large messages, the probability of delivering all fragments of a message drops exponentially with the number of fragments. DDS has a reliability setting which can resend undelivered messages, but these are again sent over UDP.
So as long as your packets fit into one IP packet (usually 1200-1500 bytes), it should be possible to use DDS. If you have larger messages, the I wouldn’t do it and I’d switch to TCP instead. You can have a look at the Zenoh backend which uses TCP for messages by default.
Also, for DDS discovery to work, you’ll need working multicast over the link.
Please don’t make generic statements about a mature technology with hundreds if not thousands of users in environments far more extreme than your average robot based on a single observation.
(yes, I realise there is “lots of evidence here on the forum”, but that still is all based on one/a (very) small set of plugins using DDS as a stand-in for a pub-sub transport layer – which is not what DDS really is)
Is DDS a panacea: no.
Can it be used with less-than-perfect transports: yes.
Does that require someone with (extensive) experience and insight into how DDS is supposed to work: yes.
Do we have (many of) those people in the ROS community: no – unfortunately.
Does that mean DDS as a whole is fundamentally broken warranting blanket statements like the above? No, doesn’t seem like it does.
@Santana27: I would perhaps consider reaching out to some DDS vendors directly. There are quite a few open-source implementations available these days where the authors/maintainers are responsive and would probably not be unwilling to discuss your question.
Board members here are more likely to be just users of DDS, comfortably abstracted away behind the interfaces RMWs offer (ie: a plugin definition for ROS 2 compatible transports). There are probably users with extensive experience with DDS, but I’m not sure they’d frequent ROS Discourse.
I agree my post was too over-simplifying and over-generalizing.
Do you know how many of these are wireless / with high packet loss? So far I understood DDS as something that was (pre-ROS 2) run mostly in industrial applications over wired connections and usually with small(ish) packets. The baby problems ROS 2 DDS RMWs had when people started using them over Wifi would suggest that there is (was) a big problem with wireless transport and it took the DDS vendors a few years until they came with some kinds of solutions.
I think the DDS vendors speak for themselves. If the problems I mention were only user-generated / misconfiguration, the vendors would not come with the extras that try to mitigate the problems. The sole fact that they invested lots of effort into solving the problems is a good enough sign for me that the problems found by ROS community were real. See for example ROS 2 Easy Mode, Discovery Server and others.
We have experience with DDS on Tactical Radios with as low as 2400 bps. This is currently in production for real defense systems.
To achieve that, we use specific transport plugins for these scenarios to compress the data and save some headers. We also use static discovery to avoid most of the discovery messages at startup.
2 Mbps is more than enough to run DDS, and probably you can use Fast DDS with the default settings.
That would be a few 100s km, right. But I know that the length of the wire on my loopback device is zero and DDS RMWs keep losing data even there, while Zenoh RMW Just Works ™.
And what Doamin ID does JSC use? I hope they go with the default of sharing topics to anyone who’s interested (and even to those who aren’t)
