Closed RDaneelOlivav closed 1 year ago
Thanks for the question and for looking into the FreeFleet design and current implementation.
We decided to use a separate DDS domain between the robots and the FreeFleet server because of the scaling challenges that DDS has, particularly on large wireless networks. DDS shares discovery information about every topic on every ROS node with every other ROS node. This is fine on localhost or wired Ethernet segments, but it's not great when many wireless links are involved, with many nodes and many topics to discover. Having a separate DDS domain just for the client-server FreeFleet information, with a hand-crafted, very small number of topics, can make a huge difference in performance on a large wireless network. Then, on the server side, the data are transferred to/from the "regular" ROS 2 DDS domain used by the rest of the system, which is typically on a hard-wired Ethernet network.
I hope this helps explain why the FreeFleet client-server comms are currently running on a separate DDS domain. We are also considering trying other middlewares for this role that are friendly to large WiFi networks, such as Zenoh. Cheers
Wow, thanks a lot it really answered my question! It even sheds light into ROS2 issues we have currently ;). Thanks a lot
Hi,
Looking at the code, I can't help noticing that the server and client don't have connected topics anywhere, nor services or actions. Why this design choice of using DDS communication directly, bypassing all the ROS2 systems?
Is there any technical explanation I'm not aware of? Wouldnt it be more transparent if they used topics to send the information between them?
Thanks in advance