Where you are. You can place frames, chain transforms, solve a two-link arm and tune a PID controller, all in code you wrote yourself. This lesson is about where that code runs from now on, and what running it there costs you.
Ship it straight to production
Picture the worst deployment you have been part of. There is no staging environment. The migration runs against production, and if it is wrong the rollback is a four-hour restore with everything down.
Now make it worse in three ways. Each run takes twelve seconds, and you need tens of thousands of runs to tune it. Every failed run does a little permanent damage to the machine. And somebody has to be physically present, between runs, to put the data back.
That is the cost of teaching a real arm to pick up a cube. The third one is the killer. The attempt is cheap. The reset is not, and the reset cannot be automated, because the thing that needs resetting is a cube lying on a table.
The idea in one paragraph
A simulator is a staging environment for physics. It holds a model of your robot and its world, and advances that model in small slices of time, so you can run a task ten thousand times before lunch, put the world back with a function call, break nothing, and change gravity if you want to. What you buy is throughput, reversibility and instrumentation. What you pay is that the model is not the world: every friction coefficient, every mass, every motor delay in it was typed in by somebody who was estimating, and the places they got wrong are exactly the places your controller will fail on hardware. That difference has a name, the sim-to-real gap, and the honest position is not that you will close it. It is that you will find out where it is, and buy the rest with a small amount of real data.
What a trial actually costs
Do the arithmetic with your own numbers. Say an attempt takes twelve seconds: approach, grasp, lift, drop. Say putting the cube back takes twenty. That is one attempt every thirty-two seconds, or about 110 an hour, and only while you are sitting there. Overnight runs need a fixture that resets itself, which is a mechanical engineering project of its own.
Wider than the screen; scroll it sideways.
The exercise at the end of this lesson runs a deliberately tiny simulated task. On one core of an ageing laptop it does somewhere between forty thousand and three hundred thousand attempts per second, depending on the machine and what else it is doing. Either end of that range makes the comparison silly rather than close.
Speed is the obvious win and the least interesting one. Three others matter more.
Reset is free and exact. Not approximately the same starting position: the same one, to the last bit. A run that fails can be replayed from the same seed and inspected step by step.
Nothing breaks. Exploration is what learning is. A policy that has never driven the arm into the table has never learned that the table is there, and on hardware every one of those lessons costs you a gearbox or a wrist.
You can read the answer. This is the underrated one. In a simulator you can ask the world where the cube truly is, so a script can decide whether the episode succeeded without a human watching. That single capability is what makes automated evaluation possible, which is what makes learning at scale possible.
What simulation is honest about
Simulation is not uniformly trustworthy or uniformly suspect. Its reliability depends entirely on how much of the answer comes from geometry you measured versus physics somebody guessed.
Wider than the screen; scroll it sideways.
At the top of that ladder, a simulator is essentially a calculator. Whether a six-jointed arm can reach a pose is a question about link lengths and joint limits, and the model states both exactly. Whether your inverse kinematics converges, whether your controller oscillates, whether your gripper command fires one step too late: these are properties of your code, and your code is identical in both worlds.
The gap, named
“The sim-to-real gap” sounds like a single mysterious quantity. It is not. It is a short list of specific, nameable discrepancies, and naming them is most of the work.
Wider than the screen; scroll it sideways.
What the field actually does about it
A 2026 follow-up sharpens it in a way worth carrying into every later lesson. Transfer works when the features a policy learns in simulation line up with the features it needs in reality. But when the only difference between your simulator and your bench is physics, and the pictures already look the same, pushing the two representations closer together can make transfer worse rather than better. “Reduce the gap” is not a universally correct instruction. It depends which gap.
The rest of this module builds the honest version of that workflow: install the engine, read the arm model line by line, drive it from Python with the kinematics you already wrote, build a task scene, discover what contact physics does to your assumptions, randomise the parts you know are wrong, and record the result as a dataset. Module 3 trains on that dataset. Module 4 puts it on hardware, where you find out which of your guesses were bad.
Check yourself
1. Of the four things simulation buys, which one does a speed benchmark fail to capture, and why does it matter more than speed?
Automatic scoring. In simulation you can query the true state of the world, so a script decides whether an episode succeeded. On hardware something has to measure success, and usually that something is a person watching. Speed without automatic scoring gives you a million unlabelled attempts, which is not obviously useful. Free exact resets and never breaking anything are the other two.
2. You tune a controller in simulation and it succeeds 97% of the time. What does that number tell you about the real robot?
Almost nothing on its own. It tells you the controller is internally consistent, converges, and does not have a sign error, because those failures would show up in either world. It says nothing about whether the friction, mass, servo delay and camera in your model resemble the ones on your desk. The exercise below makes exactly this point: 97% becomes 36% from one unmodelled 50 ms delay.
3. Rank these by how much you should trust a simulated answer: “does the gripper collide with the table on the way down”, “does this grasp survive being lifted and rotated”, “can the arm reach that pose at all”.
Reachability first, because it comes from link lengths and joint limits that the model states exactly. Collision second, because the geometry is exact but only if the scene you built matches your actual desk. Grasp durability last, because it depends on friction, contact stiffness and finger geometry, which are guessed, guessed and approximated respectively.
4. Domain randomisation trains a policy across a range of friction values rather than the correct one. Why would deliberately using wrong numbers help?
Because you do not know the correct one, and a policy trained on a single guessed value learns to depend on that value. Training across a range forces it to find a strategy that works for all of them, and the real value is probably somewhere in the range. You pay for it: a policy hedged across many worlds is more conservative than one tuned to the true world, so randomising more is not monotonically better.
5. Someone proposes closing the sim-to-real gap by making the simulator as physically accurate as possible. Give one reason this is not automatically the right goal.
Two available. First, accuracy has to be aimed: if your sim and your bench already look identical to the camera and differ only in dynamics, work spent forcing the two representations together has been reported to hurt transfer rather than help it. Second, the cheaper current answer is co-training, mostly simulated data plus a small amount of real data, which buys more improvement per hour than chasing better physics parameters.
6. Why is the reset, not the attempt, the thing that makes hardware experimentation slow?
Because the attempt is the part a robot can do, and the reset is the part it usually cannot. Putting the cube back where it started requires either a person or a purpose-built fixture, so throughput is capped by human availability rather than by the robot. In simulation the reset is a function call, which is why episode counts jump by four or five orders of magnitude.
Do this
Run code/sim_economics.py, then fill in the three TODO(you) functions until it produces the table below. It needs numpy and about a second; there is no physics engine involved yet, and that is deliberate.
The scenario: a gripper carries a cube sideways at 0.5 m/s, 25 cm above the floor, and you choose the x at which you command it to open. The world adds noise to the carry speed and the height. And the real gripper opens 50 ms after you ask, which your simulator does not know about.
| what the release point was tuned against | what it was then run against | success |
|---|---|---|
| a simulator with no gripper delay | the same simulator | 96.9% |
| a simulator with no gripper delay | a 50 ms gripper delay | 35.9% |
| a randomised 20 to 80 ms delay | a 50 ms gripper delay | 95.1% |
n = 2000 trials · drop the cube in the bin · 2026-08-09
Then change one thing at a time and watch the number move:
- Set
TRUE_DELAY = 0.02and rerun. The delay-free tuning survives much better. Small unmodelled effects are survivable; the middle row is not an argument that simulation is useless, it is an argument about magnitude. - Widen the randomisation to
(0.0, 0.20)and rerun. Success at the true delay drops, because you are now asking one release point to cover a spread of landing positions wider than the bin. That is over-randomisation, and it is the failure mode lesson 16 exists to warn you about. - Add a second unmodelled effect of your own, for instance a systematic 3% error in the carry speed, and see whether randomising the delay still rescues you. It will not, and the reason is worth writing down in one sentence before you move on.
What you can now do
You can explain what a simulator actually buys, in the order that matters: automatic scoring, free exact resets, nothing breaking, and only then speed. You can name the five places a model and a robot diverge, and point at two of them written into the SO-101 model file. You can say why “make the simulator more accurate” is not automatically the right goal, and you have watched a controller that scores 97% in one world score 36% in a world that differs by fifty milliseconds.