Navigation · Theory · M1
M1-T2 — The Navigation Stack at a Glance
A navigation stack is a team of small programs with clear hand-offs. Knowing the hand-offs tells you where to look when it breaks.
Almost every working navigation system, from a warehouse tugger to a hospital robot, has the same cast: a mission executive, a global planner, a controller, two costmaps, localization and frames, recovery behaviours and a safety monitor. Nav2, the standard open-source system, names them all. This lesson draws the cast and the messages between them.
Learning objectives
After this lesson, you should be able to:
- Name the parts of a navigation stack and say what each one receives and produces.
- Explain why there are two costmaps, and read a costmap’s cell values.
- Follow one goal through the stack, from a request to a wheel command.
- Size a costmap in cells and bytes from its extent and resolution.
The intuition
Think of a ship’s bridge. The captain decides the destination, the navigator draws the route on a chart, the helmsman steers moment to moment, a lookout watches for hazards, and an officer of the watch can take the wheel if something goes wrong. Nobody does everything, and each person trusts a defined hand-off from the others.
| Part | Receives | Produces | Runs about | In Nav2 |
|---|---|---|---|---|
| Mission executive | A goal from a user or a task system | Calls planner, controller and recoveries in order | On demand | bt_navigator |
| Global planner | Start, goal, global costmap | A path of poses | 0.2 to 2 Hz, or when needed | planner_server |
| Smoother | A path | A smoother path | With each plan | smoother_server |
| Controller (local planner) | Path, local costmap, current pose and speed | Velocity command | 10 to 50 Hz | controller_server |
| Costmaps | Static map, sensor data, robot footprint | A grid of traversal costs | 1 to 10 Hz | nav2_costmap_2d |
| Recovery behaviours | A request after a failure | A different action: wait, spin, back up, clear costmaps | On demand | behavior_server |
| Safety monitor | Commanded velocity, raw sensors | Commands scaled down or stopped | At the sensor rate | collision_monitor |
| Localization and frames | Scans, odometry, a map | A pose and the map, odom and base transforms | 10 to 50 Hz | AMCL or a SLAM system, plus TF |
The mathematics
The contracts between the parts
Each hand-off is a small, precise data type. Getting them right matters more than any algorithm inside.
- Goal: a target pose (x, y, θ) in the map frame, with tolerances for position and heading.
- Path: an ordered list of poses (xi, yi, θi) in the map frame. A path has no timing: it says where to go, not when.
- Velocity command: a forward speed v and a turn rate ω, for a differential-drive robot, or a speed and a steering angle for a car-like one, in the robot’s own frame.
- Costmap: a grid in which every cell holds one byte describing how bad it is to be there.
Reading a costmap
The ROS costmap convention stores each cell as an integer from 0 to 255:
| Value | Meaning |
|---|---|
| 0 | Free space. |
| 1 to 252 | Increasing cost: the closer to an obstacle, the higher. This is the inflation gradient. |
| 253 | Inscribed: if the robot’s centre is here, its footprint certainly touches an obstacle. |
| 254 | Lethal: an obstacle occupies this cell. |
| 255 | No information: unknown space. |
Planners treat 254 as impassable and 253 as almost always so, and use the values in between to prefer paths that keep their distance. Lesson M2-T2 shows how those values are produced.
Why two costmaps
The global costmap covers the whole known map and changes slowly, so a planner can search it once. The local costmap is a small window that moves with the robot and updates fast from live sensors, so a controller sees what is there now. They are built from the same footprint and the same obstacle layers but with different sizes, resolutions and update rates. If their settings drift apart, the planner and the controller see different worlds.
A worked example
Sizing the costmaps. Scout’s building is 20 m × 20 m and the costmap resolution is 0.05 m per cell. The local window is 5 m × 5 m. How many cells and bytes is each, and how many cells does the inflation radius cover?
The local costmap is sixteen times smaller (160 000 / 10 000), which is why it can be rebuilt many times a second. Halving the resolution to 0.10 m would cut the global costmap to 200 × 200 = 40 000 cells, four times smaller, but a doorway 0.90 m wide would then be 9 cells wide instead of 18 and an inflation radius of 0.55 m would be only 5.5 cells, so the rounding of small gaps gets coarser. Resolution trades memory and speed against fidelity, a theme of module 2.
One goal through the stack. A nurse taps “pharmacy”. The executive sends the goal pose to the planner, which searches the global costmap and returns a 31 m path of 620 poses (0.05 m apart). The executive hands the path to the controller. Twenty times a second the controller reads the pose and the local costmap and returns a command such as v = 0.8 m/s, ω = 0.1 rad/s. The safety monitor passes it unless a scan shows an obstacle inside the stopping distance, in which case it scales the speed down. If progress stalls for ten seconds, the executive calls a recovery behaviour, then asks the planner for a new path.
Engineering implications and limitations
Make the layers agree
The most common class of navigation bug is two layers with slightly different ideas of the same fact: a footprint that is 0.55 m long in one place and 0.60 m in another, a costmap in the odom frame and a path in the map frame, a goal tolerance tighter than the controller can achieve. Keep one source of truth for footprint, frames and limits, and check it at start-up.
Plugins make parts replaceable
Nav2 loads planners, controllers, smoothers and costmap layers as plugins, so swapping A* for a lattice planner, or a pure-pursuit controller for a model-predictive one, is a configuration change. Modules 3 to 6 compare these choices.
Keep a safety layer that does not trust the rest
A monitor that watches the raw sensors and the commanded velocity can stop the robot even when the planner and controller are wrong. It should be simple, fast and independent. Module 7 covers its design.
Common misconceptions
“The local costmap is just a crop of the global one.”
It is built separately from live sensor data, usually at a different resolution and update rate, and often with different layers. That is why the two can disagree.
“Recovery behaviours are an optional extra.”
Every real deployment meets blocked corridors, closed doors and bad localization. Without recovery the robot waits for a human, and in a hospital that costs time and trust.
“The path tells the robot how fast to go.”
A path has no timing. Speed comes from the controller and limits, or from a trajectory built on the path (module 5).
“If the planner finds a path, the robot can follow it.”
The planner searches a costmap. The controller must also fit the footprint through the gap at the speed it chooses, with the dynamics it has.
Engineering takeaways
- A navigation stack is an executive, a global planner, a controller, two costmaps, localization with frames, recovery behaviours and a safety monitor.
- Hand-offs are small data types: a goal, a path of poses, a velocity command and a grid of costs.
- The global costmap is large and slow; the local costmap is small and fast. They must be built from consistent settings.
- Costmap cells run from 0 (free) through an inflation gradient to 253 (inscribed) and 254 (lethal), with 255 for unknown.
- Most bugs live between layers. Keep one source of truth for footprint, frames and limits.
References and further reading
The Nav2 paper and documentation describe these parts and their names.
- S. Macenski, F. Martín, R. White and J. Ginés Clavero, “The Marathon 2: A Navigation System”, IEEE/RSJ IROS, 2020.
- Nav2 documentation, “Navigation Concepts” and “Configuration Guide”, docs.nav2.org.
- ROS Enhancement Proposal REP 105, “Coordinate Frames for Mobile Platforms”.
- D. Lu, D. Hershberger and W. Smart, “Layered Costmaps for Context-Sensitive Navigation”, IEEE/RSJ IROS, 2014.
Knowledge check
Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.
Question 1
Why does a navigation stack keep a local costmap that is separate from the global one, instead of planning and controlling on a single map?
Explanation
The two have different jobs and speeds. The global costmap covers the whole map and updates slowly, which suits a planner that searches it occasionally. The local costmap is small, built from live sensors and rebuilt many times a second, which suits a controller reacting to the world as it is now.
Question 2
A costmap cell holds the value 253. What does that tell a planner, and how is it different from 254?
Explanation
253 means inscribed: a robot whose centre is in that cell certainly touches an obstacle, so the cell is almost always impassable. 254 is lethal: the cell itself contains an obstacle. Values below 253 are inflation costs that a planner may accept to save distance.
Question 3
The global costmap resolution is changed from 0.05 m to 0.10 m for the same 20 m × 20 m map. How does the cell count change and what is the risk?
Explanation
It falls from 160 000 to 40 000 cells, four times fewer, so memory and search time drop. The risk is lost detail: a 0.90 m doorway is only 9 cells wide and the inflation gradient is coarse, so narrow gaps may be rounded closed or open.
What’s next
Next: how the robot actually moves, which decides which paths are even possible.
Related content
Nothing below is required to finish this lesson.
- BeforeM1-T1: What Is Robot Navigation?
Explain navigation as the loop of sensing, localizing, mapping, planning, controlling and recovering, and say what can go wrong at each step.
- LabM1-L1: Read a Failed Run
Scout stopped in a corridor and never arrived: read the logs and the trace, and decide which part of the stack failed.
Get notified when the next lesson and new labs are released.
One email per new lesson or lab.