search

open-rmf / free_fleet

A free fleet management system.
Apache License 2.0
156 stars 65 forks source link

Why are the Server and the Clients Talking through DDS directly an dnot through stndard ROS2 topic/service/actions? #118

Closed RDaneelOlivav closed 1 year ago

RDaneelOlivav commented 2 years ago

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

codebot commented 2 years 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

RDaneelOlivav commented 2 years ago

Wow, thanks a lot it really answered my question! It even sheds light into ROS2 issues we have currently ;). Thanks a lot