ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Communication in ROS and ROS2

asked 2018-09-21 09:45:42 -0500

aks gravatar image

ROS uses either TCP/ IP or UDP communication protocol. Different ROS nodes can be run on different machines with different network (not same subnet mask) only with one master provided that each machine can communicate bidirectionally.

Now ROS2 uses DDS for communication. In DDS language, different ROS2 nodes can interact with each other only if they belong to the same domain participant i.e. they are in the same network.

Does that mean, that ROS nodes can communicate with each other even if they are in different network whereas ROS2 nodes can only communicate if they are in the same network ?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-09-21 10:48:55 -0500

gvdhoorn gravatar image

updated 2018-09-21 10:50:57 -0500

The "domain participant ID" is just a number that allows you to configure a sort of "virtual network" or "virtual overlay" which makes DDS participants that do not use the same number ignore each other, it does not influence the networking component of DDS. See Part 2: Core Concepts > Working with DDS Domains > DomainParticipants > Choosing a Domain ID and Creating Multiple DDS Domains for the RTI explanation of this.

What you are referring to ("only in the same network") is actually due to the fact that in the default configuration many (all?) DDS implementations use (UDP) broadcast traffic for peer discovery.

By default, many routers and gateways are configured to not pass on broadcast traffic from their own network to other networks they are connected to and additionally, the DDS implementation may only broadcast to the local subnet (ie: all IPs in the same range).

But that is not an inherent issue with DDS, nor with ROS2. It's a configuration issue (and many DDS implementations support either discovery with a pre-defined list of participants or a unicast discovery, or even both), and even if the specific middleware doesn't support changing it, there are various networking techniques that can be used to bridge two (or more) network segments in such a way that broadcast traffic is allowed to flow between them.

edit flag offensive delete link more


Does that mean, if I use only Unicasting for peer discovery, I cann connect to a compatible DDS participant in any network ?

And that the settings for multicasting can also be configured for the same behaviour?

aks gravatar image aks  ( 2018-09-21 11:36:29 -0500 )edit

In theory: yes, that should work.

In practice: internetworking is never easy and can give you interesting problems..

But lots of other techniques can be used as well. There is no need to resort to unicast exclusively.

gvdhoorn gravatar image gvdhoorn  ( 2018-09-21 11:41:44 -0500 )edit

Yes, but multicasting is not allowed by most of the Work networks + there is additional overhead of firewalls which could get very tricky.

aks gravatar image aks  ( 2018-09-21 11:43:18 -0500 )edit

Note: I wrote broadcast, not multicast. Those are two different things.

If broadcasting is prohibited in a network then a lot of things will stop working.

gvdhoorn gravatar image gvdhoorn  ( 2018-09-21 13:17:46 -0500 )edit

Question Tools

1 follower


Asked: 2018-09-21 09:45:42 -0500

Seen: 2,096 times

Last updated: Sep 21 '18