ROS 2 Domain ID

A ROS 2 Domain ID is a simple integer (0-232) that creates a logical partition on a network. Nodes sharing the same Domain ID can discover and communicate with each other, forming a single ROS Graph. Nodes with different IDs are completely invisible to one another, as if they were on separate physical networks. This segmentation is enforced at the Data Distribution Service (DDS) middleware layer, which handles all discovery and data exchange.

• Default Value: The default domain ID is 0 (ROS_DOMAIN_ID=0).
• Range: Valid IDs range from 0 to 232 (as defined by the DDS RTPS protocol).
• Isolation Principle: No discovery packets, topics, services, or actions are transmitted between domains.

The domain ID for a ROS 2 node is set exclusively through the ROS_DOMAIN_ID environment variable. This variable must be set before the node process is launched and is read during the node's initialization. The value is not a node parameter and cannot be changed at runtime.

• Setting the Variable: export ROS_DOMAIN_ID=42
• Process-Specific: Each terminal/session can have its own ROS_DOMAIN_ID, allowing a single machine to host nodes in multiple domains.
• Launch File Integration: The variable is typically set in shell scripts or within launch files using the env argument to configure entire subprocess trees.

The core purpose is to run multiple independent ROS 2 systems on the same physical network without interference. This is critical for:

• Development and Testing: Isolating a developer's experimental robot graph from the production system running on the same lab network.
• Multi-Robot Fleets: Operating several identical robots in the same space, where each robot must only communicate with its own onboard nodes.
• Simulation vs. Reality: Running a high-fidelity simulation (in one domain) alongside a physical robot (in another) on the same workstation without cross-talk.
• Security Sandboxing: Containing systems to prevent accidental or malicious command of physical hardware.

Domain ID isolation is implemented by the underlying DDS implementation. The ID modifies the multicast addresses and ports used for node discovery and data traffic.

• Multicast Groups: DDS uses specific IP multicast groups (e.g., 239.255.0.1) for discovery. The Domain ID alters the final octet of this address.
• Port Calculation: Data ports are also offset by the domain ID, ensuring complete network stack separation.
• Implication: For domains to function correctly, the network infrastructure must support and route the required multicast traffic, which can be a consideration in restricted enterprise environments.

While powerful for isolation, Domain IDs have specific constraints:

• No Inter-Domain Communication: By design, there is no built-in ROS mechanism for communication across domains. Bridging requires external tools like a custom ROS Bridge or shared non-ROS interfaces (e.g., sockets).
• Not a Security Feature: Domain isolation is a logical convenience, not a security boundary. It prevents accidental communication but does not provide authentication or encryption. For secure systems, SROS2 (ROS 2 Security) must be used in conjunction.
• System-Wide Setting: All nodes that need to communicate must be launched with the exact same environment variable value; a single typo (ROS_DOMAIN_ID=10 vs. ROS_DOMAIN_ID=11) creates two isolated systems.

Effective use of Domain IDs involves deliberate system architecture:

• Standardize IDs: Document and standardize domain IDs across teams (e.g., 0 for production, 1-10 for developer sandboxes, 42 for simulation).
• Use in CI/CD Pipelines: Set unique domain IDs for each parallel automated test run to prevent interference between simultaneous robot simulations.
• Combine with Namespaces: For complex multi-robot systems, use Domain IDs for physical robot isolation, and ROS namespaces (/robot1, /robot2) for logical organization within a single robot's graph.
• Verify with CLI Tools: Use ros2 topic list and ros2 node list to confirm node visibility is constrained to the intended domain.

The ROS Graph is the runtime network representation of all communicating entities in a ROS system. It is a peer-to-peer graph of nodes, connected by topics, services, and actions. The Domain ID acts as a fundamental isolation boundary for the entire graph.

• Graph Discovery: Tools like rqt_graph and ros2 topic list only show entities within the same domain.
• Segmentation: Setting different ROS_DOMAIN_ID values creates completely separate, non-intersecting ROS graphs, even on the same physical network.
• Use Case: This allows multiple independent robots or development teams to operate on the same network hardware without interference.

A ROS Bridge, specifically the ros1_bridge, is a bidirectional gateway that translates messages and services between ROS 1 (roscore) and ROS 2 (DDS) networks. It operates within the domain paradigm of ROS 2.

• Function: It runs as a ROS 2 node that discovers data on one middleware system and republishes it on the other.
• Domain Context: The ROS 2 side of the bridge obeys the ROS_DOMAIN_ID setting. The ROS 1 side connects to a specified ROS Master.
• Primary Use: Facilitates incremental migration from ROS 1 to ROS 2 by allowing components from both versions to coexist and communicate.