ROS 2 Discovery Exercises: What to Record When Two Machines Cannot See Each Other

Two learners can start the same ROS 2 example and still see different results when they compare their terminals. One computer may show a publisher, while another shows no matching node at all. Before changing application code, make a small observation record: which process ran, where it ran, what environment it inherited, and what the other participant actually observed. This article describes a training exercise, not a production network configuration.

Start with the question of discovery

Discovery is the process by which communication participants become aware of one another. Seeing a node is a different observation from receiving a particular message. A node can be present while a topic, type, quality-of-service setting or application state prevents the intended exchange. Conversely, an empty list does not by itself prove that the remote program crashed. Record the observation without converting it immediately into a diagnosis.

The ROS 2 documentation describes different middleware implementations, including DDS-based choices and Zenoh. Discovery and transport details depend on the selected implementation and its configuration. A classroom note should name the ROS distribution and middleware used, rather than assuming every implementation behaves identically.

Build a minimal comparison between terminals

For a controlled exercise, use a publisher and subscriber from the official example packages available for your installed distribution. First run them on one computer using the same documented setup, then observe their names and communication. Add a second computer only after the local example works. Record the time, each machine's role, the command or launch file used, and whether the expected output appeared. Avoid treating a copied screenshot as proof that a currently running process is healthy.

Keep the test environment separate from equipment that could move or affect production. Use a harmless demonstration topic and a network approved for the exercise. When moving from a laptop to a robot, involve the responsible system owner: the network topology, safety procedures and authorization are outside the scope of this simple demonstration.

Check the domain and discovery range

ROS 2 can use a domain identifier to separate groups of participants. The official ROS 2 environment guide explains the domain setting as part of configuring a learning environment. Check the actual value inherited by each process, not merely the value typed in an unrelated terminal. Restarting a process with a changed environment is different from changing a shell after that process has already started.

Also record whether the system is configured to discover participants only on the local host, across a subnet, or through another supported arrangement. These choices are distribution and middleware dependent. If one exercise uses local-only discovery, a second machine may not participate even though both computers appear connected to the same network. Use the documentation for the installed version before altering the configuration.

Separate environment differences from network evidence

A useful comparison includes the distribution, operating system, sourced workspace, middleware selection and relevant environment variables. Record whether a setting was absent, explicitly set or unknown. Do not paste passwords, private keys, access tokens or unrelated internal addresses into a public forum. The system administrator can help collect sensitive network details through an approved channel.

If a local test succeeds but the two-machine test fails, that observation narrows the exercise; it does not identify a single cause. Wireless isolation, firewall policy, virtual machines and middleware configuration are examples of areas a network owner may need to examine. Do not disable firewalls or expose a robot network simply to make a tutorial pass. Document the result and request an approved test route instead.

Record outcomes without claiming a fix

A learning log might contain four rows: local publisher started; local subscriber received messages; second machine started with a recorded domain; second machine did or did not discover the publisher. Include the version and the time of each run, and mark an unobserved result as unknown. If one setting changes, repeat the same harmless test and write down the new observation. A successful trial establishes what happened under those test conditions; it does not establish reliability for every network or future deployment.

When troubleshooting progresses to message compatibility, record the topic name, interface type and quality-of-service settings separately. Discovery alone is not an end-to-end application test. An instructor can also ask learners to compare the output from each machine side by side and explain which observations are facts and which remain hypotheses. This makes the exercise useful even when the cause requires specialist help. For related learning context, see our notes on reproducing a ROS tutorial environment and separating logs from recorded communication data, or browse the learning resources.