If LiDAR navigation fails after a node restart, verify the sensor stream and the navigation lifecycle independently. A new process may exist while its managed node remains unconfigured or inactive. Conversely, Nav2 can be active while the LiDAR driver has returned with the wrong topic, frame, clock settings, or effective configuration.
Build a recovery record around the first boundary that fails: process, device connection, message publication, subscription, transforms, managed-node state, or final command path. Restarting the entire stack repeatedly may hide that boundary. Preserve the original failure and compare one controlled restart with a known working baseline.
The viewer-versus-driver diagnostic helps establish sensor communication. This checklist concerns the next recovery decision: whether a restored driver is accompanied by a properly configured and activated navigation stack, rather than only a visible point cloud.
Identify what actually restarted
Record whether the event restarted the sensor, its driver process, a container, a composed-node container, one lifecycle server, the lifecycle manager, or the whole computer. These events have different scopes. A process supervisor restarting a container may affect several components even when the visible symptom names only the LiDAR driver.
Save deployment versions, launch files, component composition, namespaces, environment variables, configuration paths, and supervisor settings. Record the old and new process identities and the exact event time using an identified clock. Keep hardware power loss separate from a software process exit, because a device can retain state across one and reset across the other.
Do not assume every sensor driver is a ROS managed node. The ROS 2 managed-node design defines lifecycle states and transitions for nodes that implement that model. Determine which components participate and which are ordinary processes with their own startup and recovery behavior.
Inspect lifecycle state instead of inferring it from discovery
A node appearing in discovery does not establish that its application work is active. Record each managed node’s observed state, the expected state, and the transition that should have produced it. Include failed transition responses and the associated logs. Keep the robot stationary through the normal commissioning procedure while investigating recovery.
The official managed-node demonstration provides the lifecycle context and command-line tools. For a known managed node, a read-only check such as ros2 lifecycle get /MANAGED_NODE can be part of the record; replace the placeholder with the resolved node name in the correct namespace.
Separate unconfigured, inactive, active, and error outcomes in the worksheet. Do not issue transitions merely to clear a symptom before saving the original state. A failed configuration may identify a missing dependency, parameter, plugin, or device access problem that disappears from view after another broad restart.
| Recovered layer | What it proves | What still needs checking |
|---|---|---|
| Process exists | The supervisor or launch mechanism created a process | Configuration, device connection and node state |
| LiDAR publishes | The driver emits messages on an observed topic | Required consumers, timestamps and frames |
| Lifecycle server is active | Its activation transition completed | Required inputs and application behavior |
| Manager reconnects | The managed-server connection path recovered | Complete stack activation and acceptance tests |
| Velocity reaches the base | The observed command path is connected | Authorized controlled motion and task-level acceptance |
Check manager ownership, bonds and respawn separately
The Nav2 Lifecycle Manager reference describes ordered managed nodes, startup activation, bond monitoring, and reconnection options. Verify the running manager’s node list and namespace. A server omitted from that list is not brought under that manager merely because it uses a familiar Nav2 name.
Reconnection is not process creation. The documentation explains that a launch mechanism or an external watchdog must bring the failed server back. Record that mechanism and its scope before expecting the manager to reconnect. Preserve the configured recovery interval and what happens after it expires rather than assuming attempts continue indefinitely.
The versioned Lifecycle Manager implementation shows bond-failure handling and the subsequent reconnection check. Match it to the installed revision when interpreting a recovery log. A server returning after the reconnection window may require a different documented recovery action from one that returns inside it.
Keep bond monitoring enabled according to the deployment design. Suppressing health checks can remove an error message without restoring a failed server. If an interval is unsuitable for the actual startup behavior, document the measured reason, the proposed change, and the required acceptance evidence before changing the deployment.
Compare the recovered driver’s effective output
Check model, firmware, driver revision, loaded configuration, resolved topic, message type, frame ID, timestamp meaning, and effective parameters after restart. Environment-dependent paths and workspace overlays can cause a restarted process to load a different build or file from the original session. Save the path actually used.
Confirm the intended subscriber connects to the recovered publisher. Use the QoS mismatch checklist when a new endpoint exists but a consumer remains silent. A visualization receiving data does not establish that the navigation subscriber uses compatible policies or the same remapped topic.
Then inspect static and dynamic transforms at the required message times. A broadcaster restarted later than a consumer can change the availability of history during startup. The TF extrapolation diagnostic separates clock mismatch, transform delay, and missing history so that lifecycle recovery is not blamed for an unrelated frame-time problem.
Make startup order and dependencies explicit
The official Nav2 navigation launch source is a useful versioned example of server composition and lifecycle-manager configuration. Compare it with the actual launch arrangement rather than treating it as an exact description of a custom robot. Include any separately launched sensor, localization, or command-arbitration components.
Write a dependency sequence: device ready, driver configured, expected messages available, required transforms available, managed servers configured, servers activated, then application acceptance. Mark which conditions are actively checked and which are merely assumed after a fixed sleep. A delay can conceal a race on one computer while failing under a different load.
Use the Nav2 observation-pipeline checks once the stack is active. Activation alone does not demonstrate that obstacle data reaches the intended processing path. Keep task-level evidence separate from the manager reporting a successful transition.
Validate a bounded restart matrix
Start with stationary signal-path tests and one controlled event at a time. Include the particular event that caused the original incident, plus required cold-start and supervised restart cases. Record pre-event state, expected response, actual transition sequence, source recovery, command behavior, and the decision to continue or stop.
Include a case where the process does not return, so the deployment’s failure behavior is checked rather than only its successful reconnection. Any physical motion trial needs the team’s approved clear test area and independent stop arrangement. Do not use a person as an obstacle or equate one successful restart with a qualified recovery design.
Retain the failing and passing configurations, logs, state observations, and acceptance criteria. Share a reproducible support bundle when the first missing boundary remains unknown. Describe observations rather than labelling every stopped robot a lifecycle-manager defect.
Does enabling respawn guarantee navigation resumes?
No. It addresses process creation in the applicable launch arrangement. Configuration, managed-node transitions, sensing, transforms, and the final command path still need evidence.
Should I restart all nodes when only one subscriber is silent?
First preserve the symptom and inspect its connection and input requirements. A broad restart can be a documented recovery action, but it is weak evidence about the cause of a narrowly observed failure.
