Singapore ROS 2 workshops: check domain and node discovery before QoS

The problem

Two environments in your ROS 2 learning exercise do not show the same nodes, and you need to prepare a useful peer-session question without assuming that the missing reading is a QoS fault.

Check which nodes each environment can discover

Before comparing a publisher's and subscriber's QoS policies, record whether the exercise environments discover the expected nodes at all. In the official ROS 2 Jazzy documentation, discovery advertises nodes within the same ROS domain; the domain documentation describes separation between different domain IDs in the default DDS-based communication model. A missing sensor reading does not tell you which condition is wrong. Start with the domain assignments and visible node names, then keep endpoint compatibility and actual message delivery as separate questions. Jazzy is the pinned example here, an older supported distribution at the source check; use the documentation and setup appropriate to your actual exercise.

• ROS 2 Jazzy: The ROS_DOMAIN_ID ↗ · Source checked 21 October 2026
• ROS 2 Jazzy: Discovery ↗ · Source checked 21 October 2026

Write one row for each environment

Make a comparison with these fields: environment or terminal; ROS distribution; middleware when identified; domain assignment for the running exercise; expected node names; observed node names; and observation time. Record where the assignment came from, such as the supplied exercise setup, instead of inferring it from a window title. ROS_DOMAIN_ID is the environment variable named by the official documentation. The documented default is 0, but an unknown effective setting stays unknown: a default description does not inspect your running process. A newly opened shell's value does not establish the setting an earlier process started with. Keep a terminal on the host, a container and a second computer as distinct rows when they are distinct exercise environments. This gives a facilitator a specific discrepancy to examine.

• ROS 2 Jazzy: The ROS_DOMAIN_ID ↗ · Source checked 21 October 2026

Collect names from an agreed practice example

In a supplied nonproduction exercise you are permitted to inspect, the official beginner tutorial uses ros2 node list to obtain active node names and ros2 node info followed by a node name to inspect that node's interfaces. Copy the observed names into the row for the environment where you ran the command. For a node actually returned by the exercise, keep the relevant publisher or subscription information beside its name. Record the command and output rather than saying only that the network works. These observations help describe the graph; they do not demonstrate that a particular message arrived. Follow the exercise's terminal setup and ask the facilitator about an unexplained result. This worksheet requires no physical robot operation or changes to a network's security settings.

• ROS 2 Jazzy: Understanding nodes ↗ · Source checked 21 October 2026

Work through a fictional domain mismatch

All names and observations in this example are invented. In a stipulated Jazzy DDS exercise, environment A runs a node named /camera_demo with domain ID 7; environment B runs /viewer_demo with domain ID 8. Each environment's supplied observation lists its own node and does not list the other. The domain rows expose a documented separation condition before anyone inspects a reliability policy. A useful question is whether this separation is intentional in the exercise and what the agreed shared setup should be. The example provides no reason to change an operating robot or choose an arbitrary domain number. Nor does it establish that domain separation is the only explanation for an actual installation's symptom. Bring the comparison to the person responsible for the practice setup.

Treat matching domain IDs as one completed check

Now use a second invented record: the exercise's responsible facilitator confirms that both environments use domain 7, but no later node-list observation is supplied. The assignment row now matches; discovery remains unobserved. If a later permitted check lists both expected nodes, record that new observation with its time and environment. Successful discovery still does not establish that the required endpoint pair has compatible policies or that a message was delivered. The official discovery page separately notes compatible QoS as a connection requirement. Use the existing publisher/subscription guide for the offer-versus-request comparison once that is the question. Keep network, middleware and other unresolved setup conditions with the relevant technical investigation rather than treating equal IDs as a complete fix.

• ROS 2 Jazzy: Discovery ↗ · Source checked 21 October 2026

• Compare publisher offers with subscription QoS requests →

Choose a session that exposes the missing evidence

Use the comparison to assess a Singapore ROS 2 workshop or peer discussion. Look for a named distribution, practice environment and participant task that lets you inspect node discovery. A demonstration of a moving robot may be interesting while providing none of those observations. A focused participation question is: “I have two permitted exercise environments with these domain and node-list records. Does the activity let participants examine discovery, and what setup should I prepare?” Confirm whether the session uses a supplied example or accepts yours. A written fictional record can support reasoning when an outside project cannot be shared. Use the hardware integration guide for the separate equipment and material arrangement.

• Prepare an integration question and suitable materials →

Leave with a changed observation, not a guessed repair

Save the initial rows, the setup clarification or permitted observation obtained, and the question still open. For example: “The domains were confirmed equal; both node names were later listed in environment A; delivery to the intended subscription was not examined.” That is more useful than “ROS networking fixed” because it tells the next person exactly where the evidence stops. Search Boardzip for ROS 2 candidates using the remaining question, then check the actual programme and joining terms. If no verified listing offers the exercise, keep the comparison ready for an appropriate session rather than treating an unrelated demo as completed troubleshooting.