Unconfigured DDS considered harmful to Networks

ROS ROS General
, ,
22

Hi, I fully agree with @tylerjw concerns.
This is similar to what we do internally.

The default ROS 2 settings are definitely unusable for networks with large number of robots.

Someone asked about LOCALHOST_ONLY.
The problem with that is that then a remote machine is not able to communicate with a robot (e.g. running ros2 topic list).
That’s why we also use DDS configuration files.
Both CycloneDDS and Fast-DDS allow to disable multicast discovery, while at the same time allowing unicast discovery from a remote machine.
This means that the debug station simply needs to know the IP address of the robot and then it will be able to communicate with it.

23

@alsora would you mind sharing your DDS config files here so that we can compile a better default for the community to reference?

So I have been testing on Humble and NetworkInterfaceAddress is now deprecated. Reading the documentation this is how I think one might update the configuration @tylerjw included in his first post, but I have done very limited testing with these setting.

<?xml version="1.0" encoding="UTF-8" ?>
<CycloneDDS xmlns="https://cdds.io/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd">
  <Domain id="any">
    <General>
      <Interfaces>
        <NetworkInterface name="lo"/>
      </Interfaces>
      <AllowMulticast>false</AllowMulticast>
    </General>
    <Discovery>
      <ParticipantIndex>auto</ParticipantIndex>
      <Peers>
        <Peer Address="localhost"/>
      </Peers>
      <MaxAutoParticipantIndex>120</MaxAutoParticipantIndex>
    </Discovery>
  </Domain>
</CycloneDDS>
24

Hi @Marq_Razz ,

This is the Fast-DDS configuration that I’m currently using with ROS 2 Galactic and Fast-DDS 2.3.3.
It’s made of two slightly different XMLs, one for the robot and one for the laptop.

The advantage of this approach is that the robot can be configured in an extremely generic way, because it does not need to know in advance the IP address of the remote machines it will interact with.
On the other hand on the laptop, where it’s usually easier to interact/change configurations and it is expected that you always know the IP address of the robot you want to communicate with, the IP address is specified.

Robot XML

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <participant profile_name="disable_multicast" is_default_profile="true">
        <rtps>
            <builtin>
                <metatrafficUnicastLocatorList>
                    <locator/>
                </metatrafficUnicastLocatorList>
                <initialPeersList>
                    <locator>
                        <udpv4>
                            <address>127.0.0.1</address>
                        </udpv4>
                    </locator>
                </initialPeersList>
            </builtin>
        </rtps>
    </participant>
</profiles>

Laptop XML (NOTE: $ROBOT_IP must be manually replaced, it’s not an env variable Add support for XML environmental variables parsing [10697] by mauropasse · Pull Request #1517 · eProsima/Fast-DDS · GitHub)

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <participant profile_name="unicast_connection" is_default_profile="true">
        <rtps>
            <builtin>
                <metatrafficUnicastLocatorList>
                    <locator/>
                </metatrafficUnicastLocatorList>
                <initialPeersList>
                    <locator>
                        <udpv4>
                            <address>$ROBOT_IP</address>
                        </udpv4>
                    </locator>
                </initialPeersList>
            </builtin>
        </rtps>
    </participant>
</profiles>

I don’t have the CycloneDDS profile at hand, but it’s relatively similar in the scope.

@wjwwood what about bringing this topic to the Middleware WG next week?

2 Likes
25

Sure, can someone add it to the agenda? I’m not sure exactly what to put down for the agenda item, maybe just a general discussion? Is there a proposal?

26

@tomoyafujita responded to my feature request suggesting there be a discussion around vendor-agnostic general configuration. I requested a way to vendor-agnostic configure max participants as easy as you can configure the network adapter and multicast via ROS_LOCALHOST_ONLY

My Q is how far can we take “vendor-agnostic general configuration” before some of the variables conflict with each other (configuring localhost and max participants are thankfully orthogonal) and things get more complicated.

So I guess my Qs for a discussion would be

  • How far can we generalize DDS settings in a vendor agnostic way?
  • What should the format for ^ be (e.g. environment variables? a vendor agnostic xml file? either/both?)
  • How do we handle conflicting settings (e.g. just pass them onto the vendor and let them deal with it? or have some logic at this agnostic level to detect if LOCALHOST_ONLY and a multicast tweak are both used)?
  • How do the vendor-agnostic settings apply to non-DDS middlewares?
  • What should documentation look like for (1) abstracted DDS settings, (2) DDS vendor specific settings, and (3) non DDS vendor settings?
27

One more for your list is:

  • How do the vendor-agnostic settings apply to non-DDS middlewares?
3 Likes
28

My apologies if my question here is incorrect.Very much a ROS2 novice and trying to learn.

In regard to the DDS issue causing network problems with many robots, is this particular issue resolved with the eProsima FastDDS Discovery server, and FastDDS router? It seems like with those two server types, DDS topics that are meant to be subscribed/published to from external entities are discovered. It appears to me, that dds discovery would only occur through these DDS Discovery/Router servers, otherwise, topics that are utilized by publishers/subscribers that are on the same host/robot/entity keep DDS messages locally.

Perhaps, I am wrong, and configuring the use of a DDS discovery/router does not filter out the multicast messages? Any clarification would be helpful here. I would also be willing to help in documenting this (as it would help me better understand the implications of DDS with multiple ROS2 robots on networks that could be limited.)

Cheers.

29

Hi @RockStarArtist,

First we have to distinguish two things here, Fast DDS Discovery Server and DDS Router, as they have very different purposes.

The first one, Fast DDS Discovery Server allows you to change the default mechanism of entity discovery based on multicast discovery to a client-server architecture based on unicast discovery.

So yes, all multicast traffic is removed with the Discovery Server.

In addition, the latest released version of the Discovery Server allows you to reduce up to 93% of the discovery traffic by discovering only Publishers and Subscribers that belong to the same topic. Here is a link to another post in this forum where we presented these results.

On the other hand you have the DDS Router whose purpose is to connect DDS networks in a simple way and with a very basic configuration. In this case, the DDS Router will not interfere in your local or isolated DDS network, since the only thing it will do is to relay the data from one DDS network to another. What it enables is to decide which topics it will forward in order to avoid unnecessary or redundant information from one network to another (allowlist/blocklist feature). Here is an example of how to configure it to connect two DDS networks and another example of how to perform a DDS Domain change within the same network.

I hope this clears up your doubts.

Cheers.

3 Likes
30

Thank you so much for the clarification @rsanchez !