../_images/tiagopro-icon.png ../_images/tiago-head-icon.png ../_images/kangaroo-icon.png ../_images/tiago-icon.png ../_images/triago-icon.png ../_images/ari-icon.png ../_images/talos-icon.png ../_images/mobile-bases-icon.png

Set up ROS 2 communication with the robot

🏁 Goal of this guide

By the end of this guide, you will know how to set up ROS 2 communication between your developer computer and the robot using the pal connection command-line tool.

In ROS 2 it is possible to set up remote communication between a robot and the PAL OS Docker image (or another development environment). For this communication to be successful, the only requirement is that the robot and the development computer have an IP route between them (this can be easily checked with a standard ping command), either by cable or wireless.

Cyclone DDS is the default networking layer (so-called RMW) in ROS 2 Humble. In its default configuration, it uses multicast for node discovery, making it unreliable in most network configurations.

PAL provides a custom configuration to avoid the issue. This configuration sets up explicit peer-to-peer discovery using unicast traffic. The pal connection command-line tool handle this configuration for you.

Pre-requisites

Connect to the robot

To connect to a robot use the PAL Connection CLI from inside a PAL OS Docker image.

pal connection start [robot_address] [network_interface] [ros_domain_id]

All the arguments are optional, meaning the CLI will ask for them when needed and properly fail or give warning on incorrect input. You can pass directly the arguments you already know to avoid being prompted for them, but they must be provided in the order you see above. For example, you can provide only the robot address and you will be prompted for the remaining arguments, but you cannot provide only the ROS_DOMAIN_ID.

Important

At the moment the PAL connection CLI is not compatible with Ubuntu 24. Please use the steps in section PAL Connection Script to connect to the robot.

The CLI tool makes Cyclone DDS connection deterministic, meaning that if it doesn’t fail, a successful connection is always established.

The arguments that the CLI is expecting are:

  • robot_address: The IP address or the DNS-solvable hostname of the robot.

    The hostname must be resolvable from your development environment, which depends on the network DNS configuration. If you haven’t configured explicitly the DNS to handle this, you probably should use the IP of the robot directly.

  • network_interface: The specific network interface to use for the connection. You can check all the interfaces with ip a.

    Please note that you have to choose the network interface that has connectivity with the robot. Check if you are connected to the network through cable or wifi and adapt the interface accordingly. Typically, the wifi interface is called something like wlan0 or wlo1 and the cable interface like enp3s0. In case you are in doubt, you can simply leave it blank and the CLI will choose the fastest interface automatically.

    The connection script will ensure that the robot is reachable by the hostname or IP you specified through the selected interface. If you receive an error message like:

    [ERROR] - There is no connectivity to [robot_address] through [network_interface]

    Please check the robot is on and properly connected to the network. This error means that your PC is unable to ping the robot.

  • ros_domain_id: The ROS_DOMAIN_ID the robot is currently using. The CLI will automatically check if this is the ID that the nodes in the robot are indeed using. If that not the case, you will get an error like:

    [WARNING] - There is not any ROS 2 node in [robot_address] using ROS_DOMAIN_ID=[ros_domain_id]. No topics will be visible

    This means that there isn’t any node in the robot using the ROS_DOMAIN_ID you specified. This is only a warning because it could also mean that the nodes of the robot are stopped (maybe the robot is still booting up) and the connection would work upon starting them.

    If after ensuring there are nodes running in the robot you still get this error (and thus the topic list is empty), please check the ROS_DOMAIN_ID under /etc/ros_domain_id in the robot.

After a successful connection the terminal should look like the image below.

../_images/cyclone_proper_connection.png

This means a Cyclone connection has been successfully established with your robot. You can now for example see the topics in your development environment with ros2 topic list.

Important

The script ensures a connection that is specific to this bash session. If you want to see the topics in another bash session, the connection script has to be run again in the new session.

Important

Please ensure ROS_LOCALHOST_ONLY environment variable is NOT set, especially that it is not in your .bashrc file. Everything is handled by the config package and this environment variable can lead to connection and simulation issues.

Disconnecting from the robot

To disconnect from the robot, you can simply run exit in the bash session where you ran the pal connection tool. This will stop the Cyclone connection and you will no longer be able to see the topics.

PAL Connection Script

The PAL Connection CLI is a wrapper around the PAL connection script. The connection script can be run directly with the ROS 2 command below. This is useful when using Ubuntu 24 as this is not supported yet by the pal connection command-line tool.

ros2 run cyclone_dev_cfg pal_connect.sh [network_interface] [robot_address]

Once the connection is established please ensure the ROS_DOMAIN_ID is set correctly.

Troubleshooting

If you can not connect to the robot from your Docker image and/or can not see the ROS topics, follow the steps below to troubleshoot the connection.

Important

Without the pal connection CLI, the topics are not accessible from outside the robot even if you set the same ROS_DOMAIN_ID in the development PC. If you haven’t configured properly your container, you will be unable to see any topics! This will be the case even if you are directly plugged into the robot. This is not the default behavior of ROS 2 Humble that you may find in the documentation, so please be extremely mindful when changing connection settings and always refer to this documentation.

  1. Check that you can ping the robot: ping <your_robot_ip>

  2. If the ping is unsuccessful, please check the robot IP on the robot using ip a. You should be able to see an IP under the appropriate network interface (normally, wlan0). Write down the IP, and try to ping it again from your development environment.

  3. If the normal ping was successful but you cannot yet see the topics, first wait a few seconds (up to a minute), and try again eg ros2 topic list. The initial node discovery can sometimes take longer.

  4. Otherwise, try a DDS ping:

    • On the robot: ddsperf sanity

    • On the development environment: ddsperf sanity

  5. If you don’t see a connection being established, but the normal ping was successful, please ensure the configuration packages are properly installed. Also, ensure the environment variable ROS_LOCALHOST_ONLY is not set, as it can interfere with the connection script. You can unset it with: unset ROS_LOCALHOST_ONLY. Ensure it is not being set in your .bashrc file.

  6. If you still cannot see a successful DDS ping, ensure the robot is using the appropriate network interface for DDS communication. You can view and edit it by executing sudo vim $CYCLONEDDS_URI on the robot and assigning the highest priority to the needed interface. Generally, there are two cases:

    • Direct connection through cable: Disable WiFi on the robot using sudo ip link set wlan0 down or change the br0 to have the highest priority.

    • WiFi: This should work out of the box, both through hotspot and over the network (including using VPN). However, if the WiFi connection is not fast enough, topics may take a while (even up to 1 minute) to appear.

  7. If a connection was established (you were able to see a DDS discovery in both the robot and your PC), but you still don’t see the topics, the issue might be that the ROS_DOMAIN_ID is not matching.

  8. If a connection was established (you were able to see a DDS discovery in both the robot and your PC), but you still don’t see the topics after a little while, you can try stopping the ROS 2 daemon: ros2 daemon stop.

  9. If during the use of the PAL Connection CLI you get a permission error, it might be the case that you are using Ubuntu 24. This is a known issue and you can use the steps in section PAL Connection Script to connect to the robot.

Frequently Asked Questions

See also