If a LiDAR cloud is available on the acquisition computer but disappears on another ROS 2 computer, separate sensor reception from middleware discovery. First prove that the intended local ROS publisher produces messages, then compare the effective environment, ROS domain and discovery configuration of the actual processes on both hosts. A working sensor cable does not prove that remote ROS participants can find each other.
This guide addresses ROS 2 LiDAR remote discovery after local acquisition works. If the driver itself receives nothing, start with the viewer-versus-driver diagnostic. If the local publisher is intermittent, use the publish-rate workflow before treating the remote computer as the failing boundary.
The official Jazzy discovery overview describes how middleware participants advertise themselves within a ROS domain. Discovery and compatible message delivery are related but distinct checks. Preserve evidence for each instead of deciding that every empty remote topic list means the LiDAR hardware stopped working.
Freeze the two actual process environments
Record the ROS distribution, workspace overlays, package versions, launch configuration, middleware implementation and network placement on both computers. Include whether the process runs in an interactive terminal, a service, a container or another managed environment. An environment value printed in a new shell does not establish what an already-running service inherited at startup.
The ROS 2 environment tutorial explains how setup files and overlays determine the working environment. Preserve the launch method and its effective settings. If a test is moved from a terminal to a service, treat that as a changed deployment condition rather than assuming the earlier shell configuration still applies.
Identify the specific local publisher and remote subscriber. Record resolved topic names, namespaces and message types. A similarly named cloud from another robot can make a diagnostic look successful while the intended sensor remains absent. Keep robot identity and network identity visible in the notes without publishing private network details in an external support request.
Compare the ROS domain used by each process
The official domain-ID reference explains that domains create logical separation on a physical network. Compare the effective ROS_DOMAIN_ID of the intended participants. Matching physical connectivity and similar topic names do not overcome a domain mismatch.
Use the domain assignment established by the project rather than choosing a convenient number in isolation. Other robots or applications may deliberately use a different domain. Document the expected assignment, the actual values and where they are configured. Do not change a shared deployment merely to make one diagnostic terminal show more nodes.
After correcting an authorized configuration, restart only the affected diagnostic or application processes through the team’s normal procedure so they use the intended environment. Keep the original values in the test record. A new terminal and an old service can otherwise continue to disagree even though the configuration file now looks correct.
Check supported discovery range and peer configuration
Inspect the discovery mechanism applicable to the installed middleware and release. The Jazzy improved-discovery tutorial describes discovery-range settings and explicit peers, while also identifying middleware exceptions. Do not assume that an environment variable has an effect merely because another ROS application uses it.
A localhost-limited configuration can be intentional for isolation. Confirm whether the robot is supposed to communicate with the second computer and which network boundary is approved. Where explicit peers or another supported discovery arrangement are required, use the deployment’s documented addresses and policies. Avoid turning a narrow connectivity test into unrestricted exposure of an operational robot graph.
Record the route and relevant network controls with the network owner. A working ping is one observation about reachability, not a full ROS discovery acceptance test. Keep multicast or unicast behavior, interface selection and any container or virtual-network boundary in the investigation. Request a scoped review rather than disabling a firewall or weakening isolation as a generic troubleshooting step.
Keep middleware and diagnostic-tool state consistent
The multiple-RMW guide explains selection of middleware implementations and warns about diagnostic daemon state when changing implementations. Record the RMW implementation actually used by the application and the command-line tools. Do not infer it solely from what was installed on the disk.
If the team deliberately changes middleware for a controlled test, keep the comparison reproducible. Confirm installed support, effective process settings and the relevant daemon behavior described by the official documentation. Do not interpret a stale command-line graph view as direct proof of sensor failure. Preserve the test-tool state as part of the evidence.
Begin with a small supported two-host communication test in the same intended environment. This can distinguish a general discovery boundary from a problem specific to the LiDAR application. A successful small test is useful, but it does not establish that a larger point-cloud payload meets the application’s throughput or latency requirements.
Separate graph visibility from subscriber delivery
Once the remote participant can identify the intended publisher, inspect the endpoints used by the actual subscriber. The Jazzy QoS reference describes compatibility between offered and requested policies. Seeing a topic in a graph is not the same result as receiving its messages through a particular subscription.
Compare reliability, durability and other applicable policies at both endpoints. Record their effective values and the receiving application’s requirements before changing them. A diagnostic subscriber with one profile can receive data while another consumer with a different profile cannot. Avoid describing that result as random networking until the endpoint configurations have been compared.
When messages arrive but a downstream paired callback remains silent, move to the message-filter matching diagnostic. If the acquisition computer itself loses complete sensor datagrams, the IP reassembly workflow addresses that earlier boundary. Neither condition is repaired merely by making the remote graph visible.
| Observed boundary | Evidence to retain | Next question |
|---|---|---|
| Local publisher absent | Driver and local output observations | Did acquisition and publication succeed? |
| Local output exists, remote graph absent | Two process environments and domain/discovery settings | Can the intended participants discover each other? |
| Remote graph exists, consumer receives nothing | Resolved topic, type and endpoint policies | Is that subscription compatible and progressing? |
| Remote data arrives but application fails | Receive counters and downstream errors | Which later processing boundary differs? |
Close with an application-level two-host test
Repeat the test with the intended sensor mode, workload and receiving application. Preserve local publication and remote reception observations over the same identified interval. Test relevant startup sequences and reconnect conditions through the project’s normal deployment process. Do not extrapolate fleet reliability from one successful terminal command.
Keep configuration changes, observed outcomes and remaining limitations together. Include the original and effective settings, installed versions, network context and the exact consumer tested. The support-bundle checklist helps another engineer reproduce the boundary without guessing which computer or process supplied a screenshot.
Frequently asked questions
Does using the same Wi-Fi prove two ROS nodes share a domain?
No. Physical connectivity does not establish the effective domain, discovery range or compatible endpoint configuration. Check those settings in the actual processes.
Should we switch middleware whenever a cloud is missing?
No. Establish the failing boundary first. A supported middleware comparison can be a controlled test, but changing several layers at once makes the result harder to interpret and may introduce different behavior.
What is a useful acceptance result?
The intended remote application receives the correct LiDAR stream under the documented configuration and required operating conditions. For ROS 2 LiDAR remote discovery, that result joins graph evidence with real data reception and preserves the limits of what was tested.
