Prerequisite: 08 — Nav2 Recoveries Progress And Goal Checkers, 04 — Nav2 Costmaps And Layers, 02 — Nav2 Bringup Lifecycle Actions Unlocks: Cleaner mission architecture, better use of waypoint flows, safer docking integration, stronger keepout and speed-zone design, fewer ownership bugs between Nav2 and task orchestration
Real AMRs do not just go to one pose and stop. They run missions such as:
If you treat all of that as one giant “navigation” blob, the system becomes hard to debug and harder to extend.
This lesson is about ownership boundaries:
NavigateToPose Is a Primitive, Not a Full Mission SystemNavigateToPose answers one question:
can the robot get to this pose under the current navigation policy?
It does not answer:
That is mission-layer logic.
Production AMRs often need:
That is where waypoint or route execution becomes useful, but it still does not replace a task orchestrator.
Waypoints are valuable when the route itself carries meaning.
Examples:
This is different from simply asking the planner for the shortest path to a single destination.
Waypoint handling belongs close to Nav2 when the need is mostly geometric or route-execution related.
Good examples:
It belongs higher up when:
| Symptom | Likely cause |
|---|---|
| robot succeeds each leg but overall mission logic is wrong | waypoint layer is being used like a full task engine |
| robot revisits a checkpoint unexpectedly | mission or preemption state machine bug |
| path through checkpoints looks unnatural | waypoint set is over-constraining geometry |
| stop-and-go motion at every point kills throughput | waypoint granularity is too fine |
More waypoints do not automatically mean better control.
Docking usually has tighter requirements than ordinary navigation:
That makes docking a layered workflow, not just a NavigateToPose with a stricter goal.
A typical production pattern is:
mission layer chooses target station
-> navigate to staging pose near dock
-> enter docking-specific alignment / final approach routine
-> confirm docked state via station-specific feedback
This preserves a clean split:
Common bad patterns:
These usually work in demos and fail under real repeatability requirements.
Keepout zones express “never plan or drive here” semantics.
Use them for:
If a keepout zone is treated as a mission-layer hint instead of a navigation-layer constraint, planners may still route through it and force higher layers to clean up the damage.
Speed zones express “you may pass here, but with restricted behavior.”
Examples:
These are often better expressed as map semantics than as ad hoc mission rules because they affect local motion quality everywhere in that region.
Some environments want more than obstacles and speed limits.
Examples:
Not all of these belong inside default costmaps. Some belong in higher-level route planning or fleet traffic management. The key is to avoid duplicating contradictory policy in two layers.
Costmap filters are often the clean way to express keepout and speed semantics because they modify navigation behavior from map-linked data instead of from scattered if-statements.
Use semantic overlays when:
Do not hardcode zone semantics in task logic if the real truth is geographic.
| Concern | Best owner |
|---|---|
| single-goal path planning and following | Nav2 |
| local obstacle avoidance and recoveries | Nav2 |
| keepout and speed semantics tied to map areas | Nav2 plus semantic map/filter setup |
| business decision about which station to visit next | mission layer |
| retrying a pickup task after manipulator failure | mission layer |
| deciding between multiple robots for the same job | fleet / mission layer |
| final station-specific docking confirmation | docking routine / mission layer |
Good architecture reduces ambiguity here.
The most common mistake is trying to encode business workflow inside navigation or encode navigation policy inside business workflow.
Examples:
Those choices create duplicate logic and harder incident ownership.
If the robot ignores a keepout or speed zone, inspect:
This is often a wiring or scope mistake, not a planner algorithm issue.
Likely causes:
Do not keep retuning global navigation for the last half meter of a station-specific task.
Possible causes:
This is where navigation and orchestration need a clear contract.
Use waypoints when:
Do not use waypoints just because the robot behaved oddly once on a single goal. That is often a planner, costmap, or controller problem.
Use zones when the rule is:
Examples include keepout, speed reduction, and restricted approach spaces.
Split docking out of generic navigation when:
That is almost always true in real AMRs.
Strong answers explain:
That is the difference between a demo integration and a production AMR architecture.
Continue to 10 — Nav2 Parameters Launch And Plugin Extension. That lesson shows how to organize the configuration, launch, and plugin structure that supports all of these AMR behaviors without creating an unmaintainable parameter pile.