Where you are. You can build a configuration space and run an RRT through it. Module 3 is about to teach you policies that learn a motion from demonstrations. This lesson is the join between those two, and it is the join a lot of real systems are built along.
Two people and a piano
A piano has to come out of a first-floor flat. Two removal people turn up.
The first walks the route before touching anything. She measures the doorway, the turn on the landing, the height of the banister, and works out that the piano has to go through on its side, rotated eleven degrees, lifted over the newel post rather than round it. She writes the sequence down. Then they do it, and it works, because she checked.
The second does not measure anything. He takes the weight, feels where it wants to go, notices the moment a corner starts to bind and shifts his grip a centimetre before it jams. He has done four hundred pianos. He could not tell you the doorway’s width to save his life.
They are not competing. Watch a good crew and you will see the first one’s plan get them to the landing and the second one’s hands get them round the newel post, and both of them would fail alone: her plan says nothing about how hard to press, and his hands have no way to know that the piano will not fit down the back stairs at all.
The idea in one paragraph
A planner and a policy are not two algorithms racing at the same job. They are answers to two different questions. A planner asks given a model of the world, what route is legal, and hands back an artifact - a list of configurations - that you can inspect, re-check, bound, simulate and log before anything moves. A policy asks given what has worked before, what should I do next, and hands back behaviour that copes with everything the model left out: contact, friction, deformable objects, an object whose pose you only half know. Each one’s strength is the other’s failure mode. The planner is exactly as correct as its model and silently wrong when the model is, and the policy cannot be verified in advance because there is nothing to inspect except its outputs on inputs you happened to try. Real systems use both, split by segment, and the interesting engineering is the boundary between them.
Wider than the screen; scroll it sideways.
What each one needs before it can exist
Module 3’s paradigm lesson puts this as the artifact a human has to author, and it is the right way to see it. A planner’s artifact is a model; a policy’s artifact is data.
| Motion planner | Learned policy | |
|---|---|---|
| You must supply | geometry of the robot and the scene, and a collision checker | demonstrations, or a reward and a simulator |
| It gives you | a path, before anything moves | an action, once it is already moving |
| Verified how | re-check the path, at any resolution you like, without a robot | roll it out many times and report a rate with its denominator |
| Fails when | the model is wrong, or the goal needs contact | the situation is outside what the demonstrations covered |
| Fails how | loudly, usually as a timeout or a refusal | quietly, by doing something plausible and wrong |
| Reruns | give a different path with the same guarantee | give a different action with no guarantee either way |
The row that matters most is the last-but-one. A planner that cannot solve your query stops and says so. A policy that has never seen your situation does not know that, and produces its best guess with exactly the same confidence it has when it is right. Covariate shift is the name for the mechanism, and you will measure it yourself in Module 3.
What “verifiable” actually buys
The planner’s output is a list of numbers. That has consequences a policy’s output does not have.
You can re-check it independently, at a finer resolution than the planner used, with a different collision checker, against a scene the planner never saw. The previous lesson’s audit is exactly this move, and it caught thirteen of twenty paths driving straight through a disc.
You can bound it: read the maximum joint velocity the path implies, the closest approach to anything, the total travel, the region of the workspace it visits. Those are properties of the artifact, computed without a robot.
You can replay it, byte for byte, a year later, in an incident review, and get the same motion.
Wider than the screen; scroll it sideways.
That is why safety cases, industrial certification and incident reviews all lean on the planning side. It is not that planners are better. It is that a path is a document.
Where the planner loses, precisely
A planner is exactly as good as its model, and this module has already shown you three ways that model is a fiction.
Contact is failure by definition. Ask the planner to put the fingertip on a disc and watch what it does. As the gap to the surface closes, the goal configuration stops being legal and the planner refuses.
| gap to the surface (m) | is the goal legal? | what the planner did |
|---|---|---|
| 0.20 | yes | solved, 122 nodes |
| 0.10 | yes | solved, 128 nodes |
| 0.05 | yes | solved, 128 nodes |
| 0.02 | no | refused: the goal is a collision |
| 0.00 | no | refused: the goal is a collision |
| -0.02 | no | refused: the goal is a collision |
n = 6 trials · plan from the start to a configuration whose fingertip is a stated gap from a disc's surface, RRT seed 0 · 2026-08-10
The cutoff is the link’s own radius, 0.04 m. Below it the arm overlaps the disc, and overlapping is the only thing the planner knows how to call wrong. Every task that ends in touching something - grasping, wiping, inserting, pushing, holding - is a task whose goal state the planner classifies as an obstacle. You can move the goal off the surface and hand over, and that hand-over is the design.
The parameters are not yours. Lesson 2.12 took the same grasp from twenty successes out of twenty to zero by changing one attribute in <option>, and showed that the friction number you set on the cube was never read. A planner’s world has no friction in it at all.
The model has to be true. A planner is at its best when the geometry is known and static: a fixture, a cell, a robot that owns its workspace. It degrades exactly as fast as your knowledge of the scene does, and a perception error of two centimetres produces a confidently computed path through the middle of an object.
Where the policy loses, precisely
Symmetrically, and this is the half people skip.
A policy has no notion of a route it has not been shown. Move the start pose four centimetres off the demonstrated one and Module 3 will measure what happens: on the groove task, a clone trained on fifty demonstrations goes from 60 out of 60 to 53 out of 60, and one trained on ten goes to 17 out of 60. The scripted rule, being a function of geometry rather than a summary of visited states, stays at 60 out of 60 everywhere.
A policy also cannot answer a question about a motion it has not made. There is no artifact to inspect, so “will this move be safe” becomes “how often has it been safe”, which needs trials, which needs a denominator, which is the whole of Module 3’s evaluation lesson.
And a policy cannot tell you it is out of its depth. That is the asymmetry worth carrying: the planner’s failure is a refusal you can catch in an if, and the policy’s failure is a confident wrong answer you catch only by watching.
The rule that comes out of it
Cut the task into segments and answer separately for each, which is the same rule Module 3 arrives at from the other side.
- Free-space transit, known geometry, no contact. Plan it. It is faster to build, deterministic to debug, checkable before it moves, and it needs no data at all.
- Contact, deformables, an object whose pose you only half know. Learn it, or script it if the variation can be engineered away.
- The boundary between them. A pose, in free space, close enough to the object that the policy’s demonstrations all start from something like it. That pose is a real design decision: put it too far away and the policy has to cover ground it was never shown, put it too close and the planner refuses to reach it.
Check yourself
1. Your arm has to reach into a bin, pick up a bolt whose position you know to about a centimetre, and drop it in a tray at a fixed spot. Which segments would you plan and which would you learn?
Plan the transit from wherever the arm is to a pre-grasp pose above the bin, and plan the transit from the bin to the tray: both are free space with known geometry, and both are cheaper and more auditable as paths. Learn or script the grasp itself, because it ends in contact, the bolt’s pose is uncertain at the scale that decides success, and the planner’s model classifies the goal state as a collision. The drop into the tray is fixed geometry and needs no policy at all. The interesting decision is where the pre-grasp pose sits, because that is what determines how much variation the learned part has to absorb.
2. Why is “the planner is verifiable” a claim about the artifact rather than about the algorithm?
Because the guarantee comes from the path being a list of numbers that exists before the robot moves. You can re-check it at a finer resolution, with a different collision checker, against a different scene model; you can compute its closest approach and its total travel; you can replay it exactly a year later. None of that is a property of RRT, which is randomised and gives a different answer every run. Swap RRT for PRM or for a grid search and the verifiability is unchanged, because it was never the algorithm doing the work.
3. A colleague proposes replacing the whole motion stack with one learned policy, arguing it is simpler. Give the strongest version of the argument against.
The transit segments are the part with the least uncertainty and the most cheaply available guarantee, so learning them buys nothing and costs the guarantee. A planner needs no demonstrations, produces a path you can check before it moves, refuses loudly when it cannot solve the query, and generalises to any start and goal in free space rather than to the ones somebody happened to demonstrate. Replacing it means collecting data for the easy part of the problem, giving up pre-motion verification everywhere including where it was free, and taking on a failure mode - confident wrong output outside the demonstrated distribution - in exactly the segments that had no distribution problem to begin with. Learning is the right tool where the model runs out, and transit is not that.
4. Both a motion planner and a task planner appear in this course. What is each one’s input, output and rate, and what would you have got wrong by treating them as one thing?
The motion planner takes scene geometry and two configurations, returns a collision-free path in configuration space, and runs in milliseconds. The task planner takes a goal in language plus an observation of the scene, returns which skill to call next, and runs in seconds. Conflating them produces a system that either asks a language model to sequence joint angles, which is far too slow and has no geometry, or asks a motion planner to decide what the task is, which it has no concept of. The two-tier framing that keeps them apart is the architecture Module 6 opens with.
5. The RRT refused every goal closer than about four centimetres to the disc. Is that a bug, and what does it tell you about the interface between the two halves?
Not a bug. The collision checker treats the arm’s links as capsules of a stated radius, and a fingertip inside that radius of the surface genuinely overlaps it; the planner is reporting its model accurately. What it tells you is that the model has no way to express touch this deliberately, so the hand-over cannot happen at the object’s surface - it has to happen at a pose the planner is still willing to reach. The margin is not a nuisance parameter to be tuned down; it is where the pre-grasp pose lives, and shrinking it towards zero deletes the interface rather than improving it.
Do this
Two parts, about forty minutes. The first uses code/rrt_2link.py from the previous lesson.
1. Find the hand-over point yourself.
python module-02-simulation/code/rrt_2link.py --touch # ~2 sReproduce the table above, then change LINK_RADIUS in cspace_2link.py from 0.04 to 0.01 and re-run. The refusal moves. Write one sentence on what you have actually changed: not the planner, not the disc, but the model’s claim about how thick the arm is. Then ask yourself which value is true of an arm whose fingertip has a rubber pad on it, and note that the answer is not a number anyone measured for you.
2. Cut a task you care about.
Take the pick-and-place you will script in the milestone and write it out as four or five segments. For each one, put down four lines: whether you would plan it or learn it, what that choice needs you to supply, how it fails, and how you would find out that it had failed. Then mark the boundaries between segments and name the pose at each boundary.
Keep the page. Module 3 hands you real policies and asks the same question with measurements attached, and Module 6 turns those boundaries into skill contracts with preconditions on them. It is the same cut, made three times, with more evidence each time.
What you can now do
You can say what a motion planner needs before it can exist, what it hands back, and why that artifact is checkable in a way a policy’s behaviour is not. You can name the three ways this module has already shown its model to be a fiction, and give the measured point at which the planner refuses to reach an object it is meant to touch. You can state the symmetric case honestly - where a policy wins and how it fails quietly when it does not. And you can cut a task into segments and defend which half of the stack owns each one, which is the decision the rest of this course keeps handing back to you.