3.2. Change ROS 2 Domain to Discovery Server¶

Background
- DDS Discovery Mechanisms
Prerequisites
Deploy ROS 2 nodes
Deploy ROS 2 Router
- Running ROS 2 Router
Alternative deployment: ROS 2 Router as DS Server

3.2.1. Background¶

eProsima ROS 2 Router, a.k.a DDS Router, is an end-user software application that enables the connection of distributed ROS 2 networks (see ROS 2 Router documentation here). That is, ROS 2 nodes such as publishers and subscriptions, or clients and services, deployed in one geographic location and using a dedicated local network will be able to communicate with other ROS 2 nodes deployed in different geographic areas on their own dedicated local networks as if they were all on the same network through the use of ROS 2 Router.

This tutorial explains how to connect ROS 2 nodes using Simple Discovery with other nodes that are connected via Discovery Server. These entities are unable to discover each other if using different discovery mechanisms, and thus they will not communicate to each other. Using the ROS 2 Router as a bridge between these 2 discovery mechanisms, every node will be able to communicate with any other node independently of the Domain where they are deployed or the Discovery Server to which they connect.

As already mentioned, the approach of this tutorial is straightforward and is illustrated in the following figure:

../../../../_images/change_domain_client.png

This tutorial will use the demo_nodes_cpp package, available in the Vulcanexus Desktop distribution. First, a ROS 2 talker is launched and then a listener node connected to a discovery server. talker will be executed normally and will use Simple Discovery while listener will use Fast DDS Discovery Server Environment Variable to connect with the Discovery Server. This will prevent the two from communicating. At this point, the ROS 2 Router will be deployed as a bridge between the two discovery mechanisms and will enable the talker-listener communication.

3.2.1.1. DDS Discovery Mechanisms¶

The DDS protocol define different Discovery Mechanisms in order to DDS Participants discover each other automatically. This mechanism can be configured by the user.

3.2.1.1.1. Simple Discovery¶

This mechanism is the standard behavior of DDS and it uses multicast capabilities so every Node discovers any other node in the network and all its Endpoints. This is the mechanism used by default in ROS 2. Nodes can be isolated by using different Domain Ids. Please, check the following tutorial to know how to communicate ROS 2 Nodes in different Domain Ids.

3.2.1.1.2. Discovery Server¶

Some networks do not support multicast, or are so big that discovering the whole network implies high amount of time. In this cases, a new Discovery Mechanism specific of Fast DDS can be used, called Discovery Server Discovery Mechanism. This mechanisms uses a Server or network of Servers that centralize the discovery traffic and distributes it to only the required entities, while the communication still occurs Peer to Peer. In order to know more about Discovery Server, please refer to Fast DDS Documentation or check this tutorial about how to configure and use Discovery Server.

3.2.2. Prerequisites¶

It is required to have previously installed Vulcanexus using one of the following installation methods:

3.2.3. Deploy ROS 2 nodes¶

First let’s run the ROS 2 Discovery Server and afterwards the talker and listener nodes.

3.2.3.1. Environment setup¶

Setup the Vulcanexus environment to have the demo_nodes_cpp package available. For this, there are two possible options:

Running the Vulcanexus Docker image.

Run the Vulcanexus Docker image with:
```
docker run -it ubuntu-vulcanexus:humble-desktop
```
Then, within the container, source the Vulcanexus installation with:
```
source /opt/vulcanexus/humble/setup.bash
```
Setting up the development environment on the local host. For this second option, it is necessary to have installed the vucanexus-humble-desktop package, since this is the one that includes all the simulation tools, demos and tutorials.

Source the following file to setup the Vulcanexus environment:
```
source /opt/vulcanexus/humble/setup.bash
```

3.2.3.2. Running ROS 2 Discovery Server¶

In order to run the Discovery Server use the Fast DDS CLI. Take care of using the public IP of the machine hosting the Discovery Server and an available port.

fastdds discovery --server-id 0 --ip-address 127.0.0.1 --port 11666

Note

The IP used in this tutorial is localhost and thus it will only work if all the commands are executed in the same host.

3.2.3.3. Running ROS 2 nodes¶

Once the environment has been setup using one of the above options, run the ROS 2 talker node in one terminal.

ros2 run demo_nodes_cpp talker

Then, on another terminal, run the ROS 2 listener node in ROS 2 using ROS_DISCOVERY_SERVER environment variable to connect it with the server. The IP and port must match with the ones set in the server (check here).

ROS_DISCOVERY_SERVER="127.0.0.1:11666" ros2 run demo_nodes_cpp listener

At this point, the listener should not receive any data. If not, please go again through the previous steps.

3.2.4. Deploy ROS 2 Router¶

Then, create the ROS 2 Router configuration file as the one shown below. The IP and port of the connection of the ROS 2 Router participant configured in this configuration file must match with the ones set in the server (check here).

Note

There is an available configuration file in DDS Router repository.

Note

If deploying Vulcanexus from the Docker image, note that you will need to have a configuration file (config.yaml) for the ROS 2 Router Edge accessible from your Docker container. This can be achieved by mounting a shared volume when launching the container, by copying the file from the local host to the container in case it is already running, or by editing a file from the Docker container itself.

version: v3.1

participants:

  - name: ROS_2_Domain_0
    kind: simple
    domain: 0

  - name: ROS_2_DS_Client
    kind: discovery-server

    discovery-server-guid:
      ros-discovery-server: true
      id: 1

    connection-addresses:
      - discovery-server-guid:
          ros-discovery-server: true
          id: 0
        addresses:
          - domain: localhost
            port: 11666

This configuration defines 2 different Router Participants, internal “interfaces” for the ROS 2 Router. One Participant is created in Domain Id 0, while the other will connect as a client to the already running Discovery Server. Topics, Data Types, Quality of Services and order of messages will be respected when redirecting the data.

3.2.4.1. Running ROS 2 Router¶

Now, run the ROS 2 Router with the configuration file created as an argument.

ddsrouter --config-path <path/to/file>/simple_ds_bridge.yaml

At this point you should see some information like the one shown below. This indicates that the ROS 2 Router has started correctly and it is currently running.

Starting DDS Router Tool execution.
DDS Router running.

In order to close the execution, just press Ctrl + C or send a signal (SIGINT 2 or SIGTERM 15) to close it.

3.2.5. Alternative deployment: ROS 2 Router as DS Server¶

The ROS 2 Router can also work as the Discovery Server itself, working as a reliable stable node in the network that distribute discovery traffic and communicate multiple networks. Just adding listening-addresses to a discovery server ROS 2 Router Participant will make it behave as a Discovery Server. In the following figure shows this specific use case and the configuration required for communicating a ROS 2 Domain with a Discovery Server network established by the ROS 2 Router.

../../../../_images/change_domain_server.png

version: v3.1

participants:

  - name: ROS_2_Domain_0
    kind: simple
    domain: 0

  - name: ROS_2_DS_Server
    kind: discovery-server

    discovery-server-guid:
      ros-discovery-server: true
      id: 0

    listening-addresses:
      - domain: localhost
        port: 11666