M6-T1 — Local versus Global Planning

Learning objectives

After this lesson, you should be able to:

• State the job, the input, the rate and the horizon of the global and the local planner.
• Describe what the global planner hands to the local planner and what comes back.
• Size a local window from speed, braking and latency.
• Explain what happens when the two disagree and name the usual remedies.

The intuition

Think of a driver with a satnav. The satnav knows the whole city and tells you which streets to take, but it does not see the cyclist. The driver sees the cyclist and nothing beyond the next junction. The satnav is the global planner: a path over the whole known map, recomputed rarely. The driver is the local planner: the next second or two, recomputed many times a second, from what the sensors see now.

They split the work because the two jobs pull in opposite directions. Searching the whole map takes time and needs a map that is not too fresh. Reacting to a cart needs the freshest data and no time at all. A planner that does both is either slow to react or short-sighted. The price of the split is an interface, and the interface is where things go wrong: the local planner must follow a path it did not choose, and the global planner must accept that the robot will not follow it exactly.

The mathematics

Two planners compared

What crosses the interface

1. Path down: the global path, as a list of poses, and the goal. The local planner picks a local goal on it, usually the point a fixed look-ahead distance ahead of the robot.
2. Cost down: both read costmaps built from the same layers (lesson M2-T4), but the local costmap is a small window that moves with the robot.
3. Status up: progress, blocked, and failure. A local planner that cannot move reports it, and the behaviour tree decides whether to replan or recover (lesson M7-T6).

How big must the local window be?

Whatever the window shows must include everything that could matter before the robot can stop. A simple budget is the distance travelled during the sensing-to-command latency, plus the braking distance, plus a margin.

v

speed of the robot (m/s).

t_latency

time from a sensor reading to the motor command taking effect (s).

a_brake

comfortable braking deceleration (m/s²).

When the two disagree

• Different footprints or costmaps: the global planner routes through a door the local planner refuses (lab M1-L1).
• Blocked path, no replan: the local planner is stuck against a cart, the global path still goes through it. The global planner must be asked again with the new obstacle in its costmap.
• Flip-flop: the local planner bends left around a cart, the global planner, replanning, prefers the right, the robot swings between them. Replan only when the new path is clearly cheaper, or hold the old one for a while (hysteresis).
• Local minima: the local planner follows its own cost function and can stop in a dead end that the global path would avoid (lesson M6-T2).

A worked example

Sizing Scout’s window. Scout drives at v = 1.0 m/s, brakes at 0.5 m/s², and the delay from laser scan to wheel command is 0.2 s.

A 5 m × 5 m window reaches 2.5 m from the robot in the worst direction, so it is enough with a metre to spare. At 1.5 m/s the braking distance grows to 2.25 m and the same window no longer qualifies: the speed limit, not the window, has to give.

Why the window is small. With a 0.05 m cell, the 5 m × 5 m local window has 100 × 100 = 10 000 cells. The 60 m × 40 m global map has 1200 × 800 = 960 000 cells, 96 times more. Updating, inflating and searching ten thousand cells twenty times a second is easy; doing it for nearly a million is not. The window is a budget decision.

Staleness. The global planner runs once a second, so its path can be up to 1 s old: at 1.0 m/s that is up to 1.0 m of travel. The path can therefore never be trusted to be clear of an obstacle that is nearer than a metre or so. The local planner covers the gap, which is why it must run an order of magnitude faster. At 20 Hz it moves the robot 0.05 m per cycle.

The cart. The cart appears 3 m ahead. The local planner sees it on the next scan, and steers around it using the room in its window. If the corridor is too narrow, no local trajectory exists, the progress checker fires after its timeout, and the global planner is asked again with the cart in the map (lab M6-L1 builds the stuck detector).

Engineering implications and limitations

Keep the two costmaps consistent

Same footprint, same inflation parameters, same obstacle sources. The only intended difference is size and update rate. Every other difference is a future incident.

Choose the look-ahead deliberately

The local goal sits a look-ahead distance along the path. Too short and the robot wobbles at every kink of the path; too long and it cuts corners through obstacles the path avoided. Scale it with speed.

Let the local planner stay on the path

A local planner that drifts far from the global path can end up in space the global planner never checked. Penalise distance from the path and cap how far the robot may deviate before it asks for a new plan.

Replan on events, not only on a clock

Periodic replanning at 1 Hz is a baseline. Add triggers: the path now crosses a lethal cell, the robot has made no progress, the goal moved. Add hysteresis so a marginally better path does not cause flip-flop.

Common misconceptions

Engineering takeaways

1. The global planner finds a route over the whole map; the local planner finds a safe velocity over the next seconds.
2. The local planner follows a local goal on the global path, and reports progress or failure upward.
3. Size the local window from latency, braking distance and a margin; limit speed if the window is too small.
4. Disagreements come from different footprints, stale paths, flip-flop and local minima.
5. Replan on events, add hysteresis, and keep both costmaps consistent.

References and further reading

The Navigation 2 papers and documentation, and the classic local-planning papers.

• S. Macenski, F. Martín, R. White and J. Ginés Clavero, “The Marathon 2: A Navigation System”, IEEE/RSJ IROS, 2020.
• E. Marder-Eppstein, E. Berger, T. Foote, B. Gerkey and K. Konolige, “The Office Marathon: Robust Navigation in an Indoor Office Environment”, IEEE ICRA, 2010.
• S. Quinlan and O. Khatib, “Elastic Bands: Connecting Path Planning and Control”, IEEE ICRA, 1993.
• Nav2 documentation, “Concepts” and “Configuration Guide”, docs.nav2.org.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

What’s next

Next: the simplest local planner, forces from the goal and the obstacles, and the way it gets stuck.

Related content

Nothing below is required to finish this lesson.