Understanding the Domain IDs

The CPM Lab separates its components into two ROS2 domains:

• The lab domain (ROS_DOMAIN_ID=21, formerly called the realtime domain) is responsible for the control and perception of the muCars and provides all logging and debug functionality for the user. It contains all components required to operate the CPM Lab and the muCars: the control flow, the Control Center, the IPS, the map server and the vehicle controllers.

• The planner domain (ROS_DOMAIN_ID=1, formerly called the triggered domain) runs the experiments. It is only active while an experiment is deployed and is not required for operating the CPM Lab or the muCars. It usually contains the motion planner, which generates the commands for the vehicles.

        ---
config:
  layout: elk
  startOnLoad: false

---
flowchart LR
   BRIDGE[Bridge]
   subgraph D1["Planner domain, ID 1 (1 Hz - 50 Hz)"]
      DOTS[...]
      MN[Motion Planner N]
      M1[Motion Planner 1]
   end

   subgraph D21["Lab domain, ID 21 (50 Hz)"]
      CC[Control Center]
      V1[Vehicle 1]
      IPS[Indoor Positioning System]
      DOTS1[...]
      VN[Vehicle N]
   end

   D1 <--> BRIDGE
   BRIDGE <--> D21

   style DOTS fill:transparent,stroke:transparent,color:#111
   style DOTS1 fill:transparent,stroke:transparent,color:#111
    

ROS domains and bridge communication

The two domains communicate with each other using the bridge component. This component does not simply bridge the two domains but also acts as a safeguard and synchronisation layer. It prevents an experiment from starting when not all conditions for a successful experiment are met and ensures that the planner domain is constantly updated with the state of the lab domain. If during an experiment the bridge detects a critical error in the lab domain it will immediately stop the experiment and prevent any further damage to the muCars or the CPM Lab.

Note

Only the topics explicitly forwarded by the bridge are visible across domains. Any message or log output published on a topic that the bridge does not forward, including ROS 2 log messages (/rosout), stays within its own domain and is not visible from the other domain. This means that, for example, log output from a motion planner running in the planner domain (ROS_DOMAIN_ID 1) will not appear in a terminal that is set to the lab domain (ROS_DOMAIN_ID 21), and vice versa. To inspect such output you must either set ROS_DOMAIN_ID to the matching domain in your terminal or use a dedicated logging tool running inside that domain.

The update rate of the bridge can be adjusted in the deploy widget of the control center. The period cannot be faster than 20ms because this is the update rate of the lab domain. The default update rate is 400ms which is a good starting point for most experiments. If the experiment requires a faster update rate, it can be adjusted accordingly. However, it is important to note that a faster update rate may increase the load on the system and may require more powerful hardware to run the experiment smoothly.

Changing the Domain IDs

The domain IDs of the lab and planner domains can be changed by setting the ROS_DOMAIN_ID environment variable before starting the components. When using the control flow the lab domain should always use ROS_DOMAIN_ID=21 and the planner domain should always use ROS_DOMAIN_ID=1. The control flow starts the bridge and the internal motion planner in domain 1 and shows a warning in the Control Center if it is not running in domain 21.

Changing the domain ID in the terminal can be done by running the following command before starting any components:

export ROS_DOMAIN_ID=<domain-id>
ros2 launch <package> <launch-file>

Note

On Linux, domain IDs between 0 and 101 are safe to use without conflicting with the kernel’s ephemeral port range (32768–60999). The CPM Lab uses IDs 1 and 21, both of which fall within this safe range. For more details on how domain IDs map to UDP ports and platform-specific constraints, refer to the official ROS 2 documentation on domain IDs.