Skip to main content
Version: ROS 2 Jazzy

Cyclone ROS Middleware

Setting up the Cyclone Profile XML for Remote Computer Communication​

For communication between a Cyclone DDS robot and one remote computer, configure a profile XML on each machine. The profiles below disable multicast and use explicit peer addresses. For general middleware configuration, see the Clearpath system configuration documentation.

Install the Cyclone DDS ROS middleware package on both the robot and the remote computer:

sudo apt update
sudo apt install ros-jazzy-rmw-cyclonedds-cpp

Create a directory for the profile on each machine:

On the robot:

mkdir -p /home/robot/.cyclone

On the remote computer:

mkdir -p "$HOME/.cyclone"

Choose the matching wired or wireless instructions in each tab. Replace the interface names and peer addresses with values for your network, then save each XML profile to its corresponding path: /home/robot/.cyclone/profile.xml on the robot and $HOME/.cyclone/profile.xml on the remote computer.

  1. If using a wired connection using the robot's ethernet port:

    a. Set the remote computer's static IP in the range 192.168.131.100 - 192.168.131.255.

    b. Replace the REMOTE_IP with the static IP assigned in the previous step.

    c. The ROBOT_INTERFACE should then be replaced with br0, the robot's bridged interface.

  2. If using a wireless connection using a WiFi router:

    a. Connect both the robot and remote computer to the router. Confirm each has an assigned IP address.

    b. Replace REMOTE_IP with the remote computer's router-assigned IP. Find it by running ip a on the remote computer.

    c. Replace ROBOT_INTERFACE with the robot's Wi-Fi interface. It is often wlp2s0, but check the interface name with ip a on the robot. It may be named wlp3s0 instead.

<?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 autodetermine="false" name="ROBOT_INTERFACE" />
</Interfaces>
<AllowMulticast>false</AllowMulticast>
<MaxMessageSize>65500B</MaxMessageSize>
</General>
<Discovery>
<EnableTopicDiscoveryEndpoints>true</EnableTopicDiscoveryEndpoints>
<ParticipantIndex>auto</ParticipantIndex>
<MaxAutoParticipantIndex>50</MaxAutoParticipantIndex>
<Peers>
<Peer Address="REMOTE_IP"/>
<Peer Address="127.0.0.1"/>
</Peers>
</Discovery>
<Internal>
<Watermarks>
<WhcHigh>500kB</WhcHigh>
</Watermarks>
</Internal>
</Domain>
</CycloneDDS>

Configure robot.yaml​

After creating both profile XML files, configure Cyclone DDS in each machine's robot.yaml. Use the same ROS domain ID on the robot and remote computer. Keep these settings inside each file's existing system: mapping; do not add a duplicate top-level system: key.

Robot /etc/clearpath/robot.yaml:

system:
ros2:
namespace: a300_00001
domain_id: 26
middleware:
implementation: rmw_cyclonedds_cpp
bash:
env:
CYCLONEDDS_URI: /home/robot/.cyclone/profile.xml

Remote computer ~/clearpath/robot.yaml:

system:
ros2:
namespace: a300_00001
domain_id: 26
middleware:
implementation: rmw_cyclonedds_cpp
bash:
env:
CYCLONEDDS_URI: /home/USER/.cyclone/profile.xml

Replace USER with the remote computer's Linux username. Both CYCLONEDDS_URI values must be absolute paths to existing profile files. A ~ shortcut is not expanded in a robot.yaml value.

Apply the configuration on each machine. On the robot, restart the Clearpath service so it regenerates its configuration:

sudo systemctl restart clearpath-robot

On the remote computer, regenerate and source the offboard setup:

source /opt/ros/jazzy/setup.bash
ros2 run clearpath_generator_common generate_bash -s ~/clearpath/
source ~/clearpath/setup.bash

After generation, confirm the profile path is present in the generated setup on each machine:

grep CYCLONEDDS_URI /etc/clearpath/setup.bash
grep CYCLONEDDS_URI ~/clearpath/setup.bash

Verify communication​

On the robot, source the generated setup and confirm that Cyclone DDS is selected and the profile path is correct:

source /etc/clearpath/setup.bash
echo "$RMW_IMPLEMENTATION"
echo "$ROS_DOMAIN_ID"
echo "$CYCLONEDDS_URI"
ros2 daemon stop
ros2 topic list

On the remote computer, source its offboard setup and check the same values:

source ~/clearpath/setup.bash
echo "$RMW_IMPLEMENTATION"
echo "$ROS_DOMAIN_ID"
echo "$CYCLONEDDS_URI"
ros2 daemon stop
ros2 topic list

Both hosts should report rmw_cyclonedds_cpp, the same domain ID, and their own profile path in CYCLONEDDS_URI. The remote topic list should include the robot's namespace. For example, an A300 with namespace a300_00001 may show:

/a300_00001/platform/odom/filtered
/a300_00001/platform/motors/status
/a300_00001/sensors/imu_0/data
/parameter_events
/rosout

Verify that data is arriving by echoing a known active topic:

ros2 topic echo /a300_00001/platform/odom/filtered

Replace the example namespace and topic with values from your robot. The available topics depend on its configuration and running nodes.

Multi-Robot Setups​

Cyclone DDS does not use the Zenoh router model described in the Zenoh guide. With the profiles below, multicast discovery is disabled, so each Cyclone DDS participant must have peer entries for the other hosts it needs to discover. Participants communicate directly over the network; there is no central Cyclone DDS hub.

Robot-to-Robot Communication​

To exchange ROS topics between robots:

  1. Set the same domain_id on every robot and give each robot a unique ROS namespace.

  2. In each robot's Cyclone profile, list every other robot's reachable IP address in <Peers>. Do not list that robot's own address. For three robots, the peer entries are:

    <!-- Robot 1 profile -->
    <Peers>
    <Peer Address="ROBOT_2_IP"/>
    <Peer Address="ROBOT_3_IP"/>
    <Peer Address="127.0.0.1"/>
    </Peers>

    Robot 2 and robot 3 profiles should list the other two robots' addresses in the same way. Keep each profile's <NetworkInterface> set to that robot's interface, as described in the profile examples above.

  3. Set CYCLONEDDS_URI in each robot's robot.yaml to its own profile file, as shown in Configure robot.yaml. Make sure each file exists and the path is absolute.

  4. Restart clearpath-robot on each robot so the generated setup uses the new profile.

Viewing a Fleet from One Computer​

An offboard computer can discover multiple robots directly by using one Cyclone profile whose <Peers> list contains every robot's reachable IP address:

<Peers>
<Peer Address="ROBOT_1_IP"/>
<Peer Address="ROBOT_2_IP"/>
<Peer Address="127.0.0.1"/>
</Peers>

Set the offboard robot.yaml to rmw_cyclonedds_cpp, the same domain_id as the robots, and CYCLONEDDS_URI pointing to this profile. Generate and source its setup using the offboard commands above. Ensure the remote profile's <NetworkInterface> names the interface used to reach the robots.

Verify the graph from the offboard computer after sourcing its setup:

ros2 daemon stop
ros2 topic list

Topics should appear under each robot's unique namespace, for example /a300_00001/ and /a300_00002/. Echo one active topic from each robot to verify data flow:

ros2 topic echo /a300_00001/platform/odom/filtered
ros2 topic echo /a300_00002/platform/odom/filtered

Run one ros2 topic echo command at a time. For isolation, use different domain IDs; namespaces distinguish names but do not isolate ROS communication. For network interface and peer XML examples, refer to the profile tabs at the top of this page.

Troubleshooting​

  • The topic list is stale or only shows built-in topics after changing the Cyclone setup. Source the generated setup in the current terminal, stop the ROS 2 daemon, then query the graph again. The daemon may have been started earlier with a different middleware or profile:

    source /etc/clearpath/setup.bash  # use ~/clearpath/setup.bash on the offboard computer
    ros2 daemon stop
    ros2 topic list
  • Only /parameter_events and /rosout appear. Confirm each host reports RMW_IMPLEMENTATION=rmw_cyclonedds_cpp, matching ROS_DOMAIN_ID values, and a CYCLONEDDS_URI path to a profile that exists on that host. Stop and retry the ROS 2 daemon after correcting the environment.

  • CYCLONEDDS_URI is empty after sourcing setup. Check that CYCLONEDDS_URI is under system.bash.env in that host's robot.yaml, regenerate the setup, and source it again. The profile path must exist and be readable by the user running the ROS processes.

  • A robot or remote computer is missing from the graph. Check that each participant's peer list contains the other reachable hosts, each profile names the correct local interface, and all participants use the same domain ID. Confirm IP reachability and firewall rules permit Cyclone DDS traffic. Cyclone DDS does not use Zenoh's TCP port 7447.

  • Topics are listed but no messages arrive. Confirm the selected topic is actively published on the robot, then check its namespace and message type on both hosts. Try another known active topic before changing the discovery profile.