Where you are. You have controlled an arm, in simulation and on hardware. This lesson is about the machines that fall over, and about being honest with yourself before spending four figures to find out whether you like them.
Stand on one foot again, and this time close your eyes
You did this once already, in lesson 5.4, to feel the difference between a fast loop and a slow one. Do it again. Ten seconds, eyes shut.
Notice what the first second feels like. Nothing dramatic happens. There is just a continuous small argument between your ankle and the floor, running below the level you can consciously follow, correcting something before you notice it needed correcting.
Now notice what would happen if that argument stopped for half a second. You would not drift. You would go down.
That is the whole difference between an arm and a leg. An arm that stops receiving commands sags, or holds, or at worst drops what it was carrying, and you pick it up and try again. A legged machine that stops receiving commands falls, and a fall is not an error you handle in software. It is an event with a repair bill and a lead time on the replacement part.
Everything expensive about this track descends from those two sentences.
The idea in one paragraph
Locomotion is the track where the physics is genuinely harder than anything you have met so far, where the dominant method is reinforcement learning run at enormous scale in simulation, and where the resource you spend is compute and hardware rather than architectural judgment. Almost none of your existing background compounds inside it; you buy competence here with time and money, at a worse exchange rate than either of the other two tracks. It is also the most viscerally interesting robotics there is, which is a real reason and needs to be treated as one rather than disguised as a strategic one. Choose it if legged robots genuinely pull you, in the sense of pulling you back repeatedly over months. Do not choose it because of a salary table.
Why legs are a different problem from arms
An arm is bolted to the floor. Whatever you want the end-effector to do, there is a chain of motors between it and something immovable, and you can push against that.
A walking machine has nothing to push against except the ground, and only through whichever feet happen to be touching it. During the airborne part of a stride there is no actuator anywhere on the robot that can change where the body is going to land. You have already committed. The only control you had was applied before you left the ground.
There is a second property that makes the mathematics unpleasant. When a foot lands, the equations describing the robot change, discontinuously, in an instant. A planner that wants to reason about a two-second gait has to reason across a sequence of these switches, and the number of possible switch sequences grows fast. That combination, underactuation plus contact that changes the model, is why hand-designed locomotion controllers stayed narrow for decades and why learning in simulation eventually won.
A missed deadline costs differently
Wider than the screen; scroll it sideways.
This shows up everywhere in the track. Debugging is harder because you cannot stop and inspect. Data collection is harder because failures are expensive. And a habit that served you well until now, adding a step to be safe, becomes actively dangerous when the step costs milliseconds.
How the track is actually trained
Wider than the screen; scroll it sideways.
The method has settled into a recognisable shape. Simulate thousands of copies of the robot in parallel on a GPU. Randomise the things you do not know precisely: friction, mass, motor response, sensor delay, terrain. Reward forward progress and penalise falling, energy and jerk. Run a curriculum so the task starts easy and gets harder. Then deploy the resulting policy to one physical robot and find out what your simulator was lying about.
The tooling is mostly a small number of GPU-parallel simulation frameworks, of which NVIDIA’s Isaac Lab is the one most job postings name. The reading is different too: Russ Tedrake’s Underactuated Robotics, free at underactuated.mit.edu and on the resources page, becomes core rather than optional, and it is genuinely a course rather than a weekend of documentation. That course is also where the model-based controllers this one skipped actually live: LQR has a chapter of its own, and receding-horizon MPC sits inside its trajectory-optimisation chapter, so that is the address. Lesson 1.17 closed by naming LQR and MPC and then not teaching them, because a manipulator running PID plus gravity feedforward never needs them; a machine that is half a second from falling does, and both are standard equipment here.
What it costs, honestly
Three bills, and only the first is obvious.
Hardware. The cheapest honest entry is a small quadruped development platform, which costs several times what your whole SO-101 setup did. Check current pricing yourself before budgeting, because this market moves and any figure printed here will be wrong within a year. Then add repairs, which are not optional; you will break things, and that is the process working.
Compute. Sustained GPU time, not occasional. Parallel simulation is the method, and the method has a floor. If you do not own a suitable GPU, this becomes a monthly cloud bill for the length of the track.
Calendar. The longest of the three tracks to a first showable result, because the pipeline has more stages that must all work before anything walks. That matters most for the reason discussed in the track-choice lesson: it decides how many times you are allowed to be wrong.
The market, said plainly
The highest compensation figures in robotics cluster around this work, and they are the least reliable numbers in the field. The reason they are high is that the roles want a credential which is genuinely scarce: hands-on whole-body control or legged policy work on real hardware, at a program a hiring manager recognises. A year of self-directed study on a small quadruped does not produce that credential, however good the work is. It is worth being blunt about, because the gap between “I have done impressive independent locomotion work” and “I clear the hiring bar for a humanoid controls role” is real and is not closed by effort.
There is an honest door next to that one. Simulation and evaluation engineering, meaning parallel simulation infrastructure, domain randomisation tooling, evaluation harnesses and continuous integration for policies, is undersupplied, sits inside the same teams, and is a much cleaner port of the software skills you already have. Someone who arrives as the person who made the sim farm reliable is inside the room where the locomotion work happens.
Testing the pull before you spend
Do this before buying anything. The whole point of the track-choice lesson was that pull is measured by return, not by enthusiasm, and this track is expensive enough to deserve a real test.
Spend two weekends, four weeks apart, on a legged task entirely in simulation. No hardware, no purchases. Train a small policy to walk on flat ground, then break it on purpose with terrain it has not seen. Between the two weekends, do not plan the second one.
Then ask the only question that matters: did you want the second weekend, or did you schedule it because this lesson told you to? The answer is the track decision, and it cost nothing but time.
Check yourself
1. What does “underactuated” mean, and why is a legged robot the clean example?
It means the system has fewer independent actuators than degrees of freedom it needs to control. A legged robot in the airborne phase of a stride is the cleanest case: the body has six degrees of freedom and, for that moment, no actuator anywhere on the machine can change any of them. Whatever authority you had was exercised before takeoff. Control becomes a question about future contact rather than present motion, which is a different problem from anything an arm bolted to a table poses.
2. Why did hand-designed locomotion controllers stay narrow while learning in simulation eventually won?
Because contact changes the model. Every time a foot lands or lifts, the equations describing the robot switch, discontinuously, and a controller reasoning about a two-second gait has to reason across a growing tree of possible switch sequences. Hand-designed controllers handled this by committing to one contact schedule, which is why they worked well on the terrain they were designed for and poorly elsewhere. Learning in simulation sidesteps the combinatorics by sampling instead of enumerating, and it can afford to because simulation is cheap and parallel.
3. Your policy walks on every terrain in your randomised simulation and falls on its first real step. What is the most likely class of cause, and why is this loop expensive to debug?
Something real sits outside the range you randomised, most often actuator response under load or sensor latency, so the policy learned to rely on a property the real robot does not have. It is expensive because each experiment needs a working robot, each failure is a fall that wears or breaks hardware, and you cannot pause mid-stride to inspect state. Compared to arm work, you get fewer trials, slower feedback and a repair queue between attempts.
4. Why do legged robots use low gear ratios and large expensive motors when your arm uses the opposite?
Because they need to know and control the force at the foot. A high reduction ratio puts friction, nonlinearity and reflected inertia between the motor current you can measure and the torque you care about, and those effects swamp the signal. Single-digit reductions keep the motor honestly connected to the joint at the cost of needing a much larger motor to produce the same torque. That trade is a large part of why a capable legged platform costs several times what a hobby-class arm costs.
5. Legged work is what pulls you, but you cannot clear the hiring bar for a controls role. What is the honest move?
Take the simulation and evaluation door into the same teams: parallel simulation infrastructure, domain randomisation tooling, evaluation harnesses, continuous integration for policies. It is undersupplied, it is a direct port of the software skills you already have rather than a credential you must manufacture, and it puts you inside the room where the locomotion work happens. It also has an underrated learning advantage, since the person who runs the evaluation infrastructure sees every failure the team produces.
Do this
The exercise is the pull test, and it is deliberately spread over a month.
Weekend one. Install a GPU-parallel simulation framework and train a walking policy for a small quadruped on flat ground, using a published example configuration. Do not write anything from scratch. Log wall-clock time, the number of parallel environments your machine sustained, and how long until the policy first stayed upright.
In between. Nothing scheduled. Notice whether you read about it anyway.
Weekend two, four weeks later. Break it. Add terrain the policy has never seen, change the friction coefficient outside the training range, and add a delay to the observations. Record the failure mode for each, in one line each.
Then write half a page in notes/07-track-memo.md: what you learned about legged control, what it cost in hours and compute, and honestly, whether you wanted the second weekend. If the answer is no, you have saved yourself several thousand dollars and two months, which is the most valuable outcome this lesson can produce.
What you can now do
You can explain what underactuation means and why a legged robot is its cleanest example, say why contact discontinuities defeated hand-designed controllers, describe the parallel-simulation training loop and where its sim-to-real failures come from, name the three bills this track sends and which one governs how often you can be wrong, and state the honest adjacent role for someone the controls door is closed to.