Unconfigured DDS considered harmful to Networks

Next Generation ROS
, ,
#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?

1 Like
#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