My biggest issue, is that dds needs udp communication, where in my PC, my network adapter is controlled by a firewall, it’s not stable and I always think it’s the firewall which blocks the dds communicatin.
So when developing applications locally on one PC, I really need some non-dds middleware, like shared memory.
I guess there are multiple reasons involved around this topic.
From out point the most prominent one is, that the default DDS (FastDDS) was broken, the last time we tested it with Iron. I just retested it, with Jazzy, still broken.
There is some concurrency issue going on with the FastDDS RMW implementation that leads to service and topic discovery not working reliable.
On the other hand we found the CycloneDDS RMW implementation to just work.
Once we switched to CycloneDDS, we found, that it outperforms the ROS1 network solution. We have way less jitter and latency in our multi process topic connections, and the establishing of topic connections is also faster.
We have machines at customers running 24/7 and and can confidently say CycloneDDS work without flaws.
One second issue that often comes up together with DDS is, that by default it connects to the whole network. So you either have to fiddle around with the ROS_DOMAIN_ID or configure the DDS, to only run on localhost.
P.S.: This is the magic configuration that works for us :
I’m not handling tons of camera data or something challenging, though.
@AndyZe You should try handling average amounts of robot data before asking “what’s all the fuss about?” The official Turtlebot 4 can’t even send pointclouds over a network properly.
Personally though, my main issue is the extra overhead which is enormous on embedded platforms. A Pi 4 is an extremely capable ROS 1 platform, on ROS 2 it can barely do anything because each node needs most of a core for message RMW conversion. And it wouldn’t be so bad if it wasn’t the worst at high frequency data which is extremely common.
the default DDS (FastDDS) was broken, the last time we tested it with Iron. I just retested it, with Jazzy, still broken.
I can corroborate that, but more accurately: Simple discovery might work on localhost in some cases, the discovery server can be made to work on a local network if configured extensively. Cyclone works in most situations, but floods the network and takes a metric ass ton of system resources to run compared to ros_comm. The aforementioned Turtlebot does not have enough memory to run it on the embedded side.
The official Turtlebot 4 can’t even send pointclouds over a network properly.