Costmap

Costmap – definition

A costmap is a two-dimensional grid used by a mobile robot to represent the traversability of space around or ahead of the vehicle. Each grid cell stores a navigation cost rather than only an occupied or free state. A path planner and a local controller use these costs to avoid obstacles, preserve clearance from walls, and select feasible routes.

In ROS 2, the term usually refers to the nav2_costmap_2d component in the Navigation2 (Nav2) stack. It maintains a grid in a selected coordinate frame and combines information from maps, range sensors, point clouds, and robot footprint geometry. A costmap is not a SLAM map. SLAM estimates the robot pose and can build an occupancy map, while a costmap converts map and sensor data into planner-specific navigation costs.

For a UGV such as Leo Rover or Raph Rover, a costmap is a core input to autonomous navigation. It enables the robot to treat a detected pallet, wall, crop row, trench boundary, or temporary construction obstacle as an area to avoid. A working autonomous-navigation system requires sensor integration, a TF tree, localization or SLAM, and a configured ROS 2 navigation stack.

Cost values and grid representation

The Nav2 costmap implementation stores one unsigned 8-bit cost per cell. The grid resolution determines the physical size represented by one cell. For example, a resolution of 0.05 metres represents each cell as a 5 cm by 5 cm square. Smaller cells improve obstacle detail but increase memory use and CPU load because the number of cells grows with the mapped area.

Nav2 defines several reserved cost values in its cost_values.hpp interface. These values are important when inspecting a costmap in RViz or debugging planner behaviour.

Cost value	Nav2 constant	Meaning
0	`FREE_SPACE`	Known traversable space.
253	`INSCRIBED_INFLATED_OBSTACLE`	Space within the robot’s inscribed radius around an obstacle.
254	`LETHAL_OBSTACLE`	An occupied cell that the robot must not traverse.
255	`NO_INFORMATION`	Unknown space, subject to the configured unknown-space policy.

Source: Nav2 cost value definitions. Intermediate values normally represent inflated costs. Their purpose is to make a planner prefer routes with greater clearance, even where several routes are collision-free.

Global and local costmaps in ROS 2

Nav2 commonly uses two costmaps because global route planning and short-horizon collision avoidance need different spatial and temporal properties. The global costmap is commonly fixed in the map frame. The local costmap commonly rolls with the robot in the odom frame.

Global costmap supports route planners such as NavFn, Smac Planner, or Theta*. It can include a static occupancy map generated by SLAM or loaded through a map server.
Local costmap supports controllers such as DWB or Regulated Pure Pursuit. It prioritises recent sensor observations and detects obstacles that may not exist in the static map.
Rolling window keeps a local grid centred on the robot. This limits computation on embedded computers and is useful for outdoor UGV operation.

The coordinate-frame convention follows REP 105. The map frame provides a globally stable reference, while odom provides locally continuous odometry. The transform chain usually includes map → odom → base_link. A missing, delayed, or inconsistent transform can prevent a costmap from accepting sensor observations.

Source: ROS REP 105 – Coordinate Frames for Mobile Platforms and Nav2 costmap configuration documentation.

Costmap layers and sensor integration

Nav2 constructs a costmap by applying layers. Each layer updates the master grid using a defined type of environmental information. Layer selection depends on the operating environment and available sensors.

Static layer imports an occupancy grid, usually from map_server or a SLAM system.
Obstacle layer marks and clears obstacles from sensor_msgs/msg/LaserScan or sensor_msgs/msg/PointCloud2 observations.
Voxel layer maintains a three-dimensional voxel representation before projecting obstacles into the 2D costmap. It is useful with depth cameras or 3D LiDAR.
Inflation layer assigns costs around lethal obstacles that decrease with distance according to the configured inflation radius and cost-scaling factor.

A 2D LiDAR is often sufficient for indoor Leo Rover navigation when its scan plane detects the relevant obstacles. A depth camera or 3D LiDAR can provide PointCloud2 data for obstacles outside that plane, including elevated surfaces. IMU and wheel odometry do not directly mark obstacles, but they improve state estimation and therefore the transform accuracy required for correct sensor projection. GPS/RTK is relevant when a Raph Rover uses a global outdoor reference frame, but it does not replace local obstacle sensing.

Example Nav2 configuration

The following YAML fragment configures a local rolling costmap for a differential-drive UGV. The values are example configuration values, not universal hardware requirements. They should be validated against the robot footprint, braking distance, sensor field of view, and compute budget.

local_costmap:
  local_costmap:
    ros__parameters:
      global_frame: odom
      robot_base_frame: base_link
      update_frequency: 10.0
      publish_frequency: 5.0
      rolling_window: true
      width: 6.0
      height: 6.0
      resolution: 0.05
      robot_radius: 0.28
      plugins: ["obstacle_layer", "inflation_layer"]

      obstacle_layer:
        plugin: "nav2_costmap_2d::ObstacleLayer"
        observation_sources: scan
        scan:
          topic: /scan
          data_type: "LaserScan"
          marking: true
          clearing: true
          obstacle_max_range: 4.0
          raytrace_max_range: 5.0

      inflation_layer:
        plugin: "nav2_costmap_2d::InflationLayer"
        inflation_radius: 0.45
        cost_scaling_factor: 3.0

The configured robot_radius is appropriate only when the platform can be conservatively approximated by a circle. For Leo Rover with mounted payloads, or for Raph Rover with a rectangular chassis and external sensors, a polygon footprint is generally more accurate. The footprint must include parts that can collide during motion, not only the wheel track.

Use with Leo Rover and Raph Rover

On Leo Rover, costmap performance depends on the Raspberry Pi compute unit, sensor driver load, grid dimensions, and selected Nav2 plugins. A compact local rolling costmap is usually more practical than a large high-resolution grid. The platform’s differential-drive kinematics should be reflected in controller and footprint settings.

Raph Rover can carry larger sensor payloads and may operate over wider outdoor areas. Its costmap should account for longer stopping distances, larger physical dimensions, uneven terrain, and vegetation-related false observations. A 2D costmap cannot model all terrain hazards. Negative obstacles, soft ground, and slopes may require additional perception and terrain-classification logic before navigation decisions are made.