Path planning for autonomous robots is one of those problems that appears solved when you run it in a simulation with perfect maps and no dynamic obstacles, and becomes genuinely difficult the moment you move to the real world. Real environments have people walking through them, floors with irregular surfaces, narrow passages that are technically navigable but require careful manoeuvre, and sensor noise that makes the robot uncertain about where it actually is.

This article covers path planning in ROS2 with Nav2 — the standard navigation stack for mobile robots — focusing on the configuration decisions that determine whether the robot navigates confidently in a real environment or spends most of its time stopping, replanning, and triggering recovery behaviours. The patterns here come from deploying mobile robots in warehouse and facility management applications.

Nav2 is a behaviours-tree-based navigation system built on ROS2. It coordinates three main components: a costmap (a 2D or 3D representation of the environment with obstacle inflation), a global planner (finds a collision-free path from current position to goal), and a local controller (executes the path by generating velocity commands while responding to dynamic obstacles). A behaviour tree orchestrates these components, handles recovery behaviours when navigation fails, and provides the extensibility to add custom navigation logic.

The separation between global planner and local controller is important. The global planner operates on a static or slowly-updated global map — it finds the optimal high-level path from A to B. The local controller operates on a frequently-updated local costmap and generates the actual velocity commands, deviating from the global path to avoid people and objects that appear after the global plan was generated. Tuning these two components independently, for their different roles, is key to getting good navigation performance.

Lifecycle management in ROS2 Nav2 separates the system into configured, active, and inactive states. This matters for production deployments where the navigation stack needs to be safely shut down, reconfigured, and restarted without full process restart. Use the lifecycle manager service to manage state transitions — it handles the correct ordering of component activation and shutdown that prevents race conditions.

Costmap Configuration

The global costmap should be configured with a modest inflation radius around obstacles — the distance from obstacles that is marked as high-cost but still navigable. The inflation radius needs to be set relative to the robot's footprint: at minimum, the inflation radius should equal the robot's maximum inscribed radius plus a safety margin. Too small an inflation radius causes the planner to generate paths that pass too close to obstacles, requiring tight manoeuvring by the local controller. Too large an inflation radius closes off narrow passages unnecessarily.

The local costmap update rate determines how quickly the robot reacts to dynamic obstacles. A low update rate (1 Hz) means the robot is slow to notice an obstacle that has appeared in its path. A high update rate (15+ Hz) imposes CPU load and may cause sensor processing backpressure. For a mobile robot navigating at typical indoor speeds (0.5–1.0 m/s), a local costmap update rate of 5–10 Hz provides reasonable responsiveness without excessive load.

Sensor layer configuration determines which sensors contribute to obstacle detection. LiDAR-based obstacle layers are the most reliable for structured environments — a 2D LiDAR at sensor height detects legs, furniture, and large obstacles accurately. Combining a floor-level LiDAR with a 3D sensor (depth camera or 3D LiDAR) adds detection of obstacles that fall above or below the 2D scan plane. The cost of additional sensors must be weighed against the navigational scenarios that the sensor layer enables.

 

Costmap Parameter Tuning Guide

  • Inflation radius: robot inscribed radius + 0.1 to 0.2 m safety margin
  • Local costmap size: 4–6 m square, sufficient for short-horizon planning
  • Update frequency: 5–10 Hz for local costmap, 1–2 Hz for global costmap
  • Obstacle marking: raytrace to clear marks when obstacles move away
  • Footprint: exact robot polygon for accurate collision checking

Global Planner and Local Controller Tuning

NavFn (Dijkstra-based) and Smac Planner are the two primary global planners in Nav2. NavFn is simpler and more reliable for standard 2D environments. Smac Planner supports kinematic constraints (minimum turning radius for car-like robots, smooth path curvature) and should be used for non-holonomic robots where NavFn's path quality causes the local controller to deviate significantly from the planned path. For differential-drive robots in warehouse environments, NavFn with a well-configured costmap is typically sufficient.

The DWB (Dynamic Window Approach) local controller generates velocity commands by sampling the robot's velocity space and evaluating candidate trajectories against a set of configurable critic functions. The balance between the path-following critic (stay close to the global path) and the obstacle avoidance critic (maintain clearance from obstacles) determines how aggressively the robot deviates from the planned path when obstacles appear. In environments with people, favour obstacle avoidance over strict path-following to prevent the robot from standing still waiting for a person to move.

Velocity and acceleration limits require careful calibration against the robot's actual mechanical capabilities and the environment's requirements. Maximum linear velocity should be set to a value where the robot can reliably stop before an obstacle at maximum detection range. Acceleration limits should allow the robot to reach cruising speed without jerk that destabilises the base. Test these values in the actual deployment environment — the friction characteristics of different floor surfaces significantly affect the safe limits.

Recovery Behaviours

Recovery behaviours are what the robot does when normal navigation fails: when the planned path is blocked, when the robot gets stuck, or when localisation uncertainty rises above acceptable thresholds. Nav2 provides a set of default recovery behaviours — spin, backup, wait, clear costmap — that handle the most common failure modes. The behaviour tree that orchestrates these recoveries determines in what order they are attempted and when navigation is declared failed.

The most common navigation failure in real environments is the robot stopping because its path is temporarily blocked by a person who pauses, then moves. The default wait recovery — stopping and waiting for the obstacle to clear — handles this correctly in most cases. The timeout for this behaviour needs to be set based on your environment: too short and the robot frequently declares navigation failures for transient obstructions, too long and the robot blocks traffic itself while waiting.

Stuck detection is a failure mode that recovery behaviours must handle. A robot whose velocity commands are being generated but whose actual movement is zero — stuck against an obstacle or in a localisation error — should trigger a recovery sequence, not continue sending unhelpful velocity commands. Monitoring the discrepancy between commanded and actual velocity, and triggering recovery when this persists beyond a threshold, prevents robots from silently getting more stuck while appearing to be navigating.

Real Environment Challenges

SLAM (simultaneous localisation and mapping) in dynamic environments degrades when the environment changes significantly between mapping and deployment. A warehouse rearranged since the map was created will have obstacles in places the map does not reflect, and the localisation system will accumulate errors as it tries to reconcile sensor observations with the stored map. For environments that change regularly, a map update process — re-running SLAM periodically and updating the navigation map — is required rather than a one-time mapping exercise.

Lift doors, narrow gates, and ramps are the specific geometry challenges that trip up navigation systems tuned for open environments. The navigation stack needs to know which passages are navigable and the robot needs explicit route planning that handles the additional constraints of tight passages. For complex facilities, hybrid approaches — predefined waypoint routes through challenging sections, autonomous free navigation in open areas — provide more reliable deployment behaviour than attempting fully autonomous navigation everywhere.

The gap between acceptable simulation performance and reliable real-world performance for autonomous navigation is usually not a software issue — it is a sensor coverage issue. Invest in sensor placement and calibration before investing in algorithm tuning. A well-calibrated sensor suite gives the navigation stack the data it needs to navigate correctly. A poorly calibrated or partially occluded sensor suite produces navigation failures that no amount of algorithm tuning will reliably prevent.