Costmap

On this page 7

A costmap is a grid representation of the environment in which every cell stores the cost of a robot being there, combining detected obstacles, safety margins and other preferences into one map that planners can search. In robot navigation, the costmap is the working surface for path planning and obstacle avoidance: it turns raw sensor data and static maps into numbers that algorithms can optimize.

A costmap builds on the occupancy grid but answers a different question. An occupancy grid estimates whether a cell is occupied; a costmap estimates how undesirable it is for the robot’s center to enter that cell, given the robot’s size, its uncertainty and the rules of the site.

How a costmap is built

A costmap is a 2D grid with a fixed resolution, commonly 0.05 m per cell for indoor robots, where each cell holds a cost value. In the widely used ROS navigation stacks the values run from 0 for free space to 254 for a lethal obstacle, with 255 reserved for unknown space. Planners treat lethal cells as forbidden and search for paths that keep the accumulated cost low.

The defining step is inflation. Because planners usually treat the robot as a point, the costmap expands every obstacle by the robot’s inscribed radius, marking those cells as certainly in collision, and then adds a decaying cost gradient beyond it. This gradient makes the planner prefer paths that keep a comfortable distance from walls instead of brushing past them.

Cost bandMeaningPlanner behavior
Free (0)No obstacle influenceTraverse freely
Inflated (1 to 252)Near an obstacle, cost decays with distanceAllowed, but penalized
Inscribed (253)Robot footprint would touch an obstacleTreated as collision for a circular robot
Lethal (254)Cell contains an obstacleNever entered
Unknown (255)No information about the cellConfigurable: avoided or allowed
Typical cost value bands in a costmap

Layered costmaps

Modern implementations use a layered costmap, in which separate layers each maintain one kind of information and are merged into a master grid on every update. Layering keeps the logic modular: a team can add a custom layer for slippery floors or restricted zones without rewriting obstacle handling.

LayerData sourcePurpose
Static layerPrebuilt map from SLAMPermanent walls and fixed structures
Obstacle layerLiDAR scans, sonarMarks and clears dynamic obstacles in 2D
Voxel layerDepth cameras, 3D LiDARTracks obstacles in 3D, projects them to 2D
Inflation layerOutput of the other layersAdds safety margins and cost gradients
Keepout or speed layerOperator-defined zonesForbidden areas and speed restrictions
Common costmap layers and their sources

The obstacle and voxel layers both mark cells where sensors detect returns and clear cells along the ray between sensor and return through ray tracing. Correct clearing is as important as marking, because a costmap that never clears accumulates ghost obstacles that block corridors long after a person has walked away.

Global and local costmaps

Navigation systems normally run two costmaps with different scopes. The global costmap covers the whole known map and supports long-range path planning, while the local costmap is a small rolling window around the robot, often a few meters wide, updated at a higher rate for the local controller that follows the path and avoids new obstacles.

PropertyGlobal costmapLocal costmap
ExtentEntire mapRolling window, typically 3 to 10 m
Update rateAbout 1 to 5 HzAbout 5 to 20 Hz
Main inputStatic map plus obstaclesLive sensor data
ConsumerGlobal path plannerLocal controller or trajectory planner
Typical inflationWider, to favor center-of-corridor routesTighter, to allow maneuvering
Global and local costmaps compared

The costmap connects several Navigation terms. Localization tells the costmap where to place sensor data; the occupancy grid supplies the static layer; path planning searches the global costmap with algorithms such as A* or Dijkstra; and obstacle avoidance relies on the local costmap to react to changes. The costmap itself performs no planning; it only describes how expensive each place is.

Alternatives exist for specific needs. Elevation maps and traversability maps suit rough outdoor terrain where height and slope matter, 3D voxel maps serve drones and arms, and Euclidean signed distance fields give optimization-based planners smooth distance gradients. The 2D costmap remains the default for wheeled robots on flat floors because it is simple, fast and well understood.

Tuning a costmap in practice

Most navigation problems in the field trace back to a handful of costmap parameters. The goal is a map that is cautious enough to prevent collisions but permissive enough that the robot can pass through doorways and narrow aisles.

  • Resolution: finer cells capture narrow gaps but increase memory and computation; 0.05 m is a common compromise indoors.
  • Footprint: an accurate polygon matters for rectangular robots, since a circular approximation either blocks doors or underestimates corners.
  • Inflation radius and cost scaling factor: these set how far and how steeply cost decays; too much inflation closes corridors, too little produces wall-hugging paths.
  • Obstacle range and raytrace range: these bound how far sensors may mark and clear, which suppresses noise from distant returns.
  • Height limits: voxel layers need minimum and maximum obstacle heights so that floors are ignored and overhanging tables are detected.

A frequent failure is a robot that stops in front of an empty doorway. The usual causes are inflation wider than half the door width, a footprint padded too generously, or stale obstacles from a sensor whose clearing rays never reach the door frame.

In plain words

A costmap is like a floor plan colored by how risky each spot is for the robot. Walls and furniture are painted as forbidden, the areas right next to them are painted as risky, and open floor is painted as safe.

When the robot plans a route, it looks for the path that stays on the safest colors while still being short. As people and boxes move around, the robot keeps repainting the map around itself so its plan stays current.

A real-world example

A hospital deploys an autonomous delivery robot that carries medication between floors. The robot is about 0.6 m wide, so engineers configure a 0.05 m costmap resolution, a rectangular footprint, and an inflation radius of 0.55 m so that the global planner keeps the robot near the center of corridors.

During testing, the robot refused to enter one patient ward because its door was only 0.9 m wide, and inflation from both frames left no zero-cost path. The team reduced inflation in the local costmap, kept the wider setting in the global one, and added a speed-limit layer near the nurses’ station. The robot then passed the door smoothly at reduced speed while still keeping a generous margin in open corridors.