Where you are. You know what a robot is, what its sensors actually return, the five ways one can be programmed, and why the field turned to learning. This lesson gives you the coordinate system all of that hangs on, so nothing in Modules 2 to 7 arrives unplaced.
Three papers, one evening
The first paper teaches a four-legged machine to cross gravel. It talks about reward functions, four thousand copies of the robot practicing in parallel, and a training schedule that starts flat and gradually adds rubble. Nothing in it touches an object.
The second teaches an arm to fold a shirt. It talks about fifty demonstrations recorded by a human holding two controllers, and about what happens when the shirt starts in a shape nobody demonstrated. It has no reward function anywhere in it.
The third gets a wheeled base across an office. It talks about loop closure, occupancy grids and a cost map. It never mentions learning.
None of the three cites either of the others. They share the word on the first line - robot - and almost nothing else: not the benchmarks, not the vocabulary, not the code, not the conferences. A researcher who is excellent at the first is a beginner at the second.
You have not fallen behind. You are reading three different fields.
The idea in one paragraph
Robotics is not one field with one frontier. It is three fairly separate problems that happen to share hardware, crossed with three choices every serious system makes whether or not it says so out loud: where it runs while it learns, where its behaviour came from, and how it splits work between a layer that thinks and a layer that reacts. Four axes. Ask them of any paper, demo or product and it lands in exactly one box on each. This lesson is the coordinate system; the rest of the course fills it in.
Wider than the screen; scroll it sideways.
Read that as a systems-architecture diagram of a field, not a list of techniques. You would not evaluate a service by listing the algorithms inside it; you would ask what it is responsible for, where it runs, where its data came from and what its latency budget is. Same four questions.
Axis 1: what problem is it?
They have separate literatures because they have separate hard parts. Manipulation’s is contact: the moment you touch something the physics turns discontinuous, and the state you care about - is the shirt folded, is the connector seated - is not measurable by any sensor you own. Locomotion’s is balance: you are always half a second from falling, so control is whole-body and fast, but the goal scores easily, because “moved forward, stayed upright” is a number. Navigation’s is knowing where you are over long distances in a world that changes, which is a mapping problem far more than a control problem.
| Problem | What usually wins today | Where in this course |
|---|---|---|
| Manipulation | learning from human demonstrations; fine-tuned foundation models | Modules 1 to 6, the spine |
| Locomotion | reinforcement learning in massively parallel simulation | Module 3, then track B in Module 7 |
| Navigation | classical mapping, localization and planning | awareness only, in Module 7 |
You do not choose this axis. The task chooses it for you. What you choose is which literature to read, and reaching for the wrong one costs months.
A humanoid is the awkward case: it inherits all three hard parts at once, which is why humanoid demos are impressive and humanoid products are late. This course is a manipulation course. Locomotion gets one honest visit through the reinforcement-learning door in Module 3; navigation gets vocabulary rather than depth. Deliberate, not an oversight.
Axis 2: where does it run?
Simulation is free, parallel, resettable and perfectly instrumented: four thousand robots at once, faster than real time, with the exact position of everything readable without a single sensor. Nobody bleeds and nothing snaps.
The catch is that a simulator is a model, and it is least accurate exactly where manipulation lives: contact, friction, soft objects, sensor noise and latency. Real hardware has the opposite profile. Honest about all of it, and expensive in every other way, because each reset costs a human walking over to put the cube back.
Wider than the screen; scroll it sideways.
Reach for simulation when you need trials by the million, when failure must be free, or when you want to test a change before it reaches a motor: Module 2. Reach for hardware when the thing you are trying to learn is precisely what your simulator gets wrong: Module 4.
Axis 3: where does the behaviour come from?
The five paradigms from lesson 0.5 collapse onto one axis here, and the axis is what you supply.
| Origin | You supply | The cost | Reach for it when |
|---|---|---|---|
| Written by hand | the algorithm itself | your engineering time; brittle outside its assumptions | the environment is predictable, or the behaviour must be certified |
| Imitation learning | demonstrations | human time, growing linearly with data | you can do the task yourself by teleoperation |
| Reinforcement learning | a reward function and a simulator | compute, plus the art of reward design | you can score the outcome numerically and simulate it |
| Foundation model | a small fine-tuning dataset | GPU time; someone else paid for the pretraining | you need it to work on things you never demonstrated |
Two things about that table matter more than the rest of this lesson.
First, the boundaries leak. A vision-language-action model is imitation learning at scale, and reinforcement learning increasingly shows up as a polishing step on a policy that was pretrained by imitation. Ingredients, not tribes.
Second, the axes are correlated, and the correlation is the structure of the field. Manipulation pushes you toward real data and imitation, because rewards for “folded” are unwritable and contact simulates badly. Locomotion pushes you toward simulation and reinforcement learning, because falling over is free in sim and forward velocity is trivial to score. A paper doing reinforcement learning on a real arm is either an unusual setup or a very patient graduate student.
Imitation and reinforcement learning are Module 3; foundation models are Module 5.
Axis 4: how is it split in time?
Every capable robot is two machines wearing one shell.
Wider than the screen; scroll it sideways.
The fast layer runs somewhere between 10 and 1000 times a second. Joint servo loops, balance, and the learned policy itself live here. It has no semantics; it does not know what a mug is. What it has is a deadline, every cycle.
The slow layer runs maybe once or twice a second, often less. What is in the scene, what to do next, whether the last step worked, what to do about the fact that it did not. Language, memory and judgment live here.
The split is not a preference. It is forced: a good decision takes longer than the fast layer’s deadline allows, so it has to happen somewhere else, less often.
The interesting engineering is the contract between them. The slow layer emits goals and skill calls downward; the fast layer reports state and results upward. Both directions fail characteristically: the slow layer proposes a plan the fast layer cannot physically execute, or the fast layer reports success for a grasp that was actually empty. This is why verification belongs between skills rather than inside them, and it is the subject of Module 6.
You build the fast layer by hand in Module 1, put a learned policy at the boundary in Modules 3 to 5, and wire up the slow layer in Module 6. Several current foundation models now split themselves this way internally, running a slower reasoning component alongside a faster action component.
Check yourself
1. A locomotion team trains in simulation with four thousand parallel robots and a reward for forward velocity. Why does that recipe not transfer to folding a shirt?
Two axes break at once. The method needs a reward function, and “folded” has no honest numerical score. The venue needs a simulator that is accurate on the thing being learned, and cloth plus contact is exactly where simulators are worst. So deformable manipulation goes the other way on both: real data, demonstrations instead of rewards.
2. Why does randomising a simulator help more than carefully tuning it, and what does that cost you?
Tuning aims a narrow training distribution at the real world and misses, because you cannot measure everything that matters. Randomizing widens the distribution until the real world falls inside it, so no transfer is required. The cost: a policy that must handle every friction value is more conservative than one tuned to the true value, and training takes longer because the problem is harder.
3. You can teleoperate a task today, you have one arm, and you need it working next week. Which origin do you pick, and why not the other three?
Imitation learning. Writing it by hand fails as soon as the object moves, unless you can fixture the scene. Reinforcement learning needs a reward and a simulator you do not have and cannot build in a week. A foundation model is a reasonable second choice, but a fine-tune still needs demonstrations, so imitation is the shorter path and gives you the baseline you would compare the fine-tune against anyway.
4. Where does the fast/slow split come from, and name the two failure modes at the boundary.
From the latency budget, not from design taste: good decisions take longer than the fast layer’s per-cycle deadline, so they must run less often, elsewhere. The two failures are a plan the fast layer cannot physically execute, and a skill reporting success it did not achieve. The second is worse, because everything downstream believes it.
5. A humanoid video shows a robot walking to a counter and putting a mug in a dishwasher. Place it on all four axes, and say which axis is doing the most work.
Problem: locomotion and navigation to get there, manipulation to do the task, which is why humanoids are hard. Venue: the walking was almost certainly learned in simulation, the manipulation almost certainly from real demonstrations. Origin: reinforcement learning below, imitation or a foundation model above. Split: a slow layer sequencing the steps over a fast layer executing them. The manipulation is doing the most work, and is the part most likely to be teleoperated in the video.
Do this
Create notes/00-field-map.md with a five-column table: source, problem, venue, origin, split.
Fill in six rows: two research papers, two company demo videos, two products you can buy today. Do not pick six of the same kind; the exercise only works if the rows disagree with each other.
Then do the part that teaches. Mark every cell you could not fill from the source itself. Those blanks are the finding: a demo video that never says whether it was autonomous has hidden the origin axis from you, and a paper reporting only simulation results has told you the venue and stayed quiet about whether it survives hardware. For one blank, decide whether it was left out for space or on purpose.
What you can now do
You can take any robotics paper, demo or product and place it on four axes: which of the three problems it solves, whether it runs in simulation or on hardware, where its behaviour came from, and how it divides work between a fast layer and a slow one. You can say which axes this course goes deep on and which it deliberately skims, and you can spot when a source has quietly left one of the four unstated.