Nav2 Planning and Control: A Path Returned Is Not a Path Followed

A mobile robot can receive a planned path and still fail to follow it in its local environment. In a Nav2 learning exercise, path planning and path following are related but separate responsibilities. Recording which stage produced a result, which component reported an error and what conditions were present makes the experiment easier to understand.

Identify the requested outcome

A navigation task may ask the system to find a route to a goal and then generate control commands to follow it. The Nav2 project's navigation plugin setup guide describes planner and controller plugins as distinct parts of the system. The linked Rolling documentation changes over time; use the guide for the installed Nav2 release and the selected plugins.

A path is a representation of a route, not proof that a physical robot has traversed it. Conversely, a controller's output should be interpreted with the robot, local environment and the rest of the system. A tutorial result from a simulated map is not evidence that a real site is safe or that every obstacle can be avoided.

Record the planner's input and result

For a learning test, note the start and goal, the relevant frames, the map or environment representation, the planner plugin and its configuration. Record whether a path was returned and what the application reported. If no path is available, preserve the error and the state of the inputs before changing settings. A failure to produce a route is different from a controller failing to follow an existing route.

Different planner plugins can make different assumptions about the robot and environment. A geometrically short line on a grid is not automatically feasible for every robot. Check the plugin's documented capabilities and the model used in the experiment before comparing outputs.

Observe what the controller receives

The Nav2 controller server documentation describes handling a path and configured plugins, and notes that the server hosts a local costmap. Record which path and controller plugin were used, the relevant configuration and the result of the follow-path request. A path being available does not establish that the local conditions or robot state allowed it to be followed.

In a hypothetical simulation, a route is computed in an empty map but a new obstacle appears before the robot reaches it. The team should record the planner result, the local observation and the controller or navigation outcome separately. This scenario illustrates a diagnostic boundary; it is not a guarantee about how a particular deployment handles obstacles.

Check the surrounding navigation context

Localization, coordinate transforms, sensor data, costmaps, behavior logic and controller configuration can all affect the task. If a robot does not move as expected, do not assume the planner alone is responsible. Identify the first stage where the observed result differs from the expected result, preserve logs and inspect the relevant configuration. The precise diagnostics depend on the Nav2 version and plugins.

Keep the local and global environment representations distinct when documenting the experiment. A stale or incomplete local observation can affect a controller differently from an incorrect global map. Note the time of the test and any changes to the scene rather than comparing screenshots without their context.

Also record whether the navigation request was accepted and how it ended. A goal can be canceled, fail or remain in progress for reasons that require application-specific investigation. Store the action result, relevant log messages and the component versions together. If a behavior tree or application retries a step, note the attempts separately so that an earlier failure is not hidden by a later success.

When comparing two controllers, use the same documented robot model, environment and task where possible. Explain any differences in plugin configuration and record the observed outputs rather than judging only the smoothness of an animation. If the experiment changes the map and the controller at the same time, it cannot isolate which change affected the outcome. A useful learning report states that limitation.

Use a controlled learning exercise

Run an isolated simulation from a documented initial state, save the map and configuration, and record both the planned path and the final task result. Include the robot model and sensor assumptions used in the test. If changing a parameter, change one supported setting at a time and repeat the same scenario. Report when a comparison cannot isolate a single cause, and avoid presenting a successful simulation as a physical safety certification.