Path planning

Path planning – definition

Path planning is the process of computing a collision-free route for a mobile robot from a start pose to a goal pose under kinematic, geometric, and environmental constraints. In mobile robotics, the output is usually a path, meaning an ordered set of poses in a map or local frame. A separate controller or trajectory generator then turns that path into time-dependent velocity commands.

In ROS and ROS 2 navigation stacks, path planning is part of autonomous navigation. It operates on map data, robot footprint geometry, obstacle information, and a goal pose. For UGV platforms such as Leo Rover and Raph Rover, path planning must account for differential-drive or skid-steer motion, wheel slip on outdoor terrain, map uncertainty, and limited onboard compute. A planner that works well in a clean indoor grid map may fail on grass, gravel, or partially observable terrain.

From a systems perspective, path planning sits between perception and control. Perception produces occupancy grids, costmaps, or traversability maps. The planner searches that representation for a feasible route. The controller follows the route using velocity commands, typically published as geometry_msgs/msg/Twist in ROS 2. This separation is standard in the ROS 2 Navigation stack, commonly called Nav2.

How path planning works in ROS 2

In ROS 2, path planning is typically implemented through Nav2. Nav2 separates global planning, local control, recovery behaviors, and behavior tree orchestration. The planner server computes a global path, while the controller server tracks that path and reacts to short-term obstacles.

The planner usually consumes a 2D costmap built from sensor data and static map layers. The result is a path published as nav_msgs/msg/Path. The target pose is commonly sent through RViz or an action interface using nav2_msgs/action/NavigateToPose.

Component	Typical ROS 2 interface	Purpose
Goal input	`nav2_msgs/action/NavigateToPose`	Requests navigation to a target pose
Global planner output	`nav_msgs/msg/Path`	Provides path in map frame
Velocity command	`geometry_msgs/msg/Twist` or `geometry_msgs/msg/TwistStamped`	Controls robot motion
Robot pose transform	TF2: `map -> odom -> base_link`	Maintains localization and motion frames
Obstacle source	`sensor_msgs/msg/LaserScan`, `sensor_msgs/msg/PointCloud2`	Updates local and global costmaps

For frame conventions, ROS uses REP 105 for coordinate frames such as base_link, odom, and map. Message and package conventions are defined across REP documents and ROS interface specifications. In practice, a valid planning stack depends on correct TF, synchronized sensor timestamps, and an accurate robot footprint.

planner_server:
  ros__parameters:
    expected_planner_frequency: 1.0
    planner_plugins: ["GridBased"]
    GridBased:
      plugin: "nav2_navfn_planner::NavfnPlanner"
      tolerance: 0.25
      use_astar: true
      allow_unknown: true

global_costmap:
  global_costmap:
    ros__parameters:
      global_frame: map
      robot_base_frame: base_link
      resolution: 0.05
      track_unknown_space: true
      robot_radius: 0.22

Common algorithms and planner variants

Path planning algorithms differ in map representation, optimality guarantees, runtime, and suitability for dynamic environments. In UGV systems, the most common distinction is between global planners and local planners. The former finds a route through the known map. The latter adapts motion in the presence of nearby obstacles and motion limits.

In ROS 2 Nav2, several planner plugins are available. Their practical behavior depends on costmap quality and parameter tuning.

Dijkstra – graph search with complete shortest-path expansion on weighted grids. Reliable but may be slower than heuristic search.
A* – heuristic graph search. Often preferred on occupancy grids because it reduces search effort while preserving optimality under admissible heuristics.
NavFn – classical grid-based planner in ROS lineage. Suitable for static or slowly changing maps.
Smac Planner – supports 2D, Hybrid-A*, and lattice-based planning. More suitable when kinematic feasibility matters.
Sampling-based methods such as RRT or RRT* – used more often in research stacks than in standard Nav2 deployments. Useful in high-dimensional spaces, less common for 2D differential-drive UGV navigation.

For Leo Rover and Raph Rover, a plain 2D grid planner is often sufficient at the global level if the terrain is moderate and the robot is represented by a circular or polygon footprint. If the mission includes narrow passages, steep turns, or trailer-like payload behavior, a kinematically informed planner becomes more appropriate.

Key parameters and metrics

Planner quality is not defined by a single number. The path must be feasible for the robot, safe with respect to obstacles, and stable enough for the controller to follow. In ROS 2 deployments, several measurable parameters directly affect performance.

Costmap resolution – often 0.03 m to 0.10 m per cell for small UGVs. Finer grids improve obstacle detail but increase CPU and memory use.
Planner frequency – global planning commonly runs around 0.5 Hz to 2 Hz, while local control runs much faster, often 10 Hz to 30 Hz.
Robot footprint – polygon or radius model used for collision checking. An inaccurate footprint causes unsafe plans or unnecessary conservatism.
Inflation radius – expands obstacle costs around occupied cells. This encodes safety margin and affects path smoothness.
Path length – total geometric distance of the planned route.
Clearance – minimum distance to obstacles along the route.
Replanning latency – time needed to update the path after map changes.

A useful simplification is to distinguish between path and trajectory. A path is geometric. A trajectory is time-parameterized. For differential-drive and skid-steer UGVs, the controller enforces dynamic limits such as:

|v| ≤ v_max
|ω| ≤ ω_max

where v is linear velocity and ω is angular velocity. If the path contains curvature that exceeds controller or traction limits, tracking error grows even if the path is collision-free.

Sensor and map dependencies

Path planning quality depends on environment representation. The planner itself does not detect obstacles. It trusts the map and costmap layers generated upstream. This is why the same planner may behave very differently with LiDAR, depth cameras, or GPS-based navigation.

Typical sensor inputs for UGV path planning include the following:

2D LiDAR – efficient for local obstacle detection and occupancy grid updates.
Depth camera – useful for near-field obstacle detection, but sensitive to lighting and surface properties.
IMU and wheel odometry – provide short-term motion estimates for local consistency.
SLAM or localization source – provides pose in the map frame.
GNSS / RTK – useful in large outdoor areas, but usually insufficient alone for local obstacle avoidance.

On Leo Rover, a common research setup combines wheel odometry, IMU, and a LiDAR or depth sensor with Nav2 on ROS 2 Humble or newer. Because Leo Rover commonly uses a Raspberry Pi-class compute unit, planner choice and map resolution should match the available CPU budget. On Raph Rover, the larger payload capacity allows heavier sensor stacks and more powerful compute, which is relevant for outdoor planning with denser costmaps or multi-sensor fusion.

Use cases with Leo Rover and Raph Rover

On Leo Rover, path planning is often used in lab navigation, campus mapping, and outdoor prototype missions. The robot is a four-wheel UGV with IP54 protection, but it is not an autonomous vehicle out of the box. A usable navigation setup requires integration of localization, obstacle sensing, TF, and Nav2 configuration.

Typical Leo Rover path planning tasks include waypoint navigation in a known map, repeated route execution in research experiments, and testing planner behavior under constrained compute. The robot footprint, wheelbase behavior on uneven terrain, and local obstacle sensing must be tuned carefully.

On Raph Rover, planning is more often tied to heavier payloads, longer-range sensing, and field robotics. Examples include inspection routes, construction-site traversal, or agricultural row navigation. In these cases, the main issue is not just shortest path. It is path robustness under partial observability, changing terrain, and larger stopping distances.

Limitations and trade-offs

No planner is universally best. Grid planners are simple and reproducible, but they depend heavily on costmap quality. Kinematically aware planners generate more realistic routes, but usually require more tuning and compute. Outdoor terrain adds another problem: occupancy does not equal traversability. A cell can be obstacle-free yet unsafe because of slope, mud, or wheel slip.

For this reason, path planning on UGVs should be treated as one layer in a larger autonomy stack. In ROS 2, that usually means combining planning with reliable localization, costmap filtering, controller tuning, and safety fallbacks.

Normative references and standards

The most relevant technical references for this topic are ROS 2 Nav2 documentation, ROS message definitions, and REP standards for frames and robot descriptions. For coordinate frame semantics, REP 105 is the primary ROS reference. For robot geometry and description conventions, URDF and TF2 documentation are directly relevant. For message interfaces, see the ROS 2 interface definitions for nav_msgs/Path, geometry_msgs/Twist, and navigation actions in Nav2.

When comparing ROS 1 and ROS 2, the architectural concept is similar, but implementation details differ. ROS 1 commonly used the move_base stack. ROS 2 uses Nav2 with lifecycle nodes, behavior trees, and a different plugin architecture. For new Leo Rover and Raph Rover integrations, ROS 2 Humble or newer is the relevant baseline.