Glossary

Fictionlab > Glossary > ROS_DOMAIN_ID

ROS_DOMAIN_ID

ROS_DOMAIN_ID – definition

ROS_DOMAIN_ID is a ROS 2 environment variable that selects the DDS domain used by a process. In ROS 2 systems using DDS-based middleware, nodes normally discover and communicate only with participants configured for the same domain ID. It is therefore a practical mechanism for separating independent ROS 2 graphs that share one Ethernet or Wi-Fi network.

For a mobile robot, a domain ID can isolate the ROS 2 network of one UGV from other robots, developer laptops, simulation workstations, or test rigs. For example, a Leo Rover running navigation in a laboratory can use domain 20, while another Leo Rover on the same Wi-Fi network uses domain 21. Their nodes will not normally discover each other or exchange ROS 2 topics, services, actions, or parameters.

The default ROS 2 domain ID is 0. ROS 2 documentation specifies the valid range as 0 to 232, although practical availability also depends on the DDS implementation, operating system UDP port range, participant count, and local network configuration.

How ROS_DOMAIN_ID works in ROS 2

ROS 2 uses the ROS Middleware Interface (RMW) layer to communicate through a selected middleware implementation. Common implementations include Fast DDS, Cyclone DDS, and Connext DDS. In DDS-based deployments, ROS_DOMAIN_ID is passed to the middleware as the DDS Domain ID.

Each ROS 2 process reads the variable when it starts. Changing the value in a terminal does not move already running nodes to another domain. All nodes that must communicate must use the same domain ID and must also be able to exchange DDS discovery traffic through the selected network interfaces.

# Run a ROS 2 node in DDS domain 20
export ROS_DOMAIN_ID=20

ros2 launch nav2_bringup bringup_launch.py

A separate terminal can be assigned to another domain for isolation testing.

# This terminal will not discover nodes in domain 20
export ROS_DOMAIN_ID=21

ros2 node list

Domain separation is not an access-control mechanism. It does not encrypt traffic, authenticate nodes, or prevent a host from deliberately joining the selected DDS domain. ROS 2 security is defined separately through SROS 2 and DDS Security mechanisms.

DDS domain IDs, discovery, and UDP ports

DDS implementations commonly use DDSI-RTPS over UDP. The domain ID contributes to the UDP port calculation used for discovery and user data. This matters when several robots, containers, or simulation instances run on one computer or subnet.

ROS 2 documentation describes the default RTPS port mapping using a port base of 7400 and a domain gain of 250. A simplified discovery multicast port formula is:

discovery_multicast_port = 7400 + (250 × domain_id)

For domain 20, this gives port 12400. Additional ports are allocated for participant discovery and user-data communication. The exact ports also depend on the DDS participant index and the implementation configuration. Firewall rules must therefore permit the required UDP traffic, not only a single fixed port.

Parameter Meaning Operational relevance for UGV systems
0 Default ROS 2 domain ID Convenient for a single isolated robot, but may cause unintended discovery on shared networks.
0-232 ROS 2 documented domain ID range Use a planned allocation scheme across robots, workstations, and test environments.
250 Default DDSI-RTPS domain gain in the ROS 2 port mapping guidance Domain selection affects UDP port allocation and may interact with host ephemeral-port ranges.
7400 Default DDSI-RTPS port base in the ROS 2 guidance Relevant when configuring host firewalls, VLAN policies, or container networking.

Using ROS_DOMAIN_ID on Leo Rover and Raph Rover

Leo Rover can run ROS 2 on its built-in Raspberry Pi compute unit. A separate domain ID is useful when multiple Leo Rover platforms operate in the same teaching laboratory, test hall, or field network. It prevents a navigation stack on one rover from discovering topics such as /cmd_vel, /scan, /odom, or /tf published by another rover.

Raph Rover can use the same approach when it carries a larger compute payload, additional sensors, or an external autonomy computer. The domain ID should be configured consistently on the onboard computer, remote teleoperation workstation, and any companion computer that must participate in the same ROS 2 graph.

A simple allocation plan should be documented before deployment. The following example reserves one DDS domain per robot or test environment.

ros_domain_allocation:
  leo_rover_lab_01: 20
  leo_rover_lab_02: 21
  raph_rover_field_test: 30
  simulation_ci: 40

For persistent configuration on Ubuntu-based robot computers, the variable can be placed in a systemd service definition. This avoids accidental startup in the default domain after a reboot.

[Service]
Environment=ROS_DOMAIN_ID=20
ExecStart=/usr/bin/bash -lc 'source /opt/ros/humble/setup.bash && ros2 launch my_robot bringup.launch.py'

Containers, remote workstations, and simulation

Docker containers require explicit network planning. A container may have the correct ROS_DOMAIN_ID but still fail to discover robot nodes if multicast traffic is blocked by Docker bridge networking, Wi-Fi isolation, VPN routing, or host firewall rules. Host networking is often used for local DDS testing, but it should be assessed against the security and network policy of the deployment.

Domain IDs are also useful for separating simulation from physical hardware. A Gazebo, RViz, Nav2, or SLAM test running on a developer workstation can use a different domain from a physical Leo Rover. This reduces the risk that a simulated publisher sends commands to a real robot because both systems expose identically named topics.

ROS 1 and ROS 2 differences

ROS_DOMAIN_ID is a ROS 2 concept. ROS 1 uses a central ROS Master and typically groups nodes through ROS_MASTER_URI, together with network variables such as ROS_IP or ROS_HOSTNAME. A ROS 1 node does not join a DDS domain by setting ROS_DOMAIN_ID.

In mixed ROS 1 and ROS 2 environments, the ROS 1-ROS 2 bridge is a separate process. Its ROS 2 side must use the intended domain ID, while its ROS 1 side must be configured for the correct ROS Master.

Normative references and technical sources

The following primary sources define the relevant ROS 2 and DDS concepts. Port calculations and domain ID limits should be verified against the deployed ROS 2 distribution and RMW implementation.

See also