Where you are. Orientation is finished: you can say what a robot is, what it is built from, what its sensors actually return, how one gets programmed, how the field is laid out, and how to grade a claim about it. This lesson turns all of that into a calendar and a week-one checklist.
The tab you bookmarked in March
Somewhere in your browser is a tutorial series you were going to work through. You read the first two parts, and they were good; you remember them being good. It sits in a folder called something like learn, and you last opened it five months ago.
Now think about the last technology you actually got good at. There was something you had to ship. There was a date. You worked on it in particular hours rather than in the gaps between other things. When you got stuck you could not close the tab, because the thing you were stuck on stood between someone else and something they wanted.
Nothing about the teaching explains the difference. The bookmarked series was quite possibly the better material. What the second one had was a slot in the week, and something at the end that another person was going to look at.
That is what this lesson is. Not a reading list; a calendar.
The idea in one paragraph
You are going to spend roughly twelve months becoming someone who can build robots that learn. The route runs through eight modules: this orientation, then foundations, simulation, learning in simulation, real hardware, foundation models, the agentic layer, and a capstone. The engine that moves you along it is a weekly rhythm of about seven and a half protected hours, and the thing that proves you moved is that each module ends in something public with real numbers in it. Reading is fuel. The artifacts are the credential.
The route
Wider than the screen; scroll it sideways.
| Module | What ends up in your repo | Weeks |
|---|---|---|
| 0 Orientation | a one-page thesis note: what you believe and what you are betting on | ~1 |
| 1 Foundations | your own transforms, kinematics, inverse kinematics and PID code, and a scripted pick-and-place built on them | 6-8 |
| 2 Simulation | a MuJoCo scene you built and can drive | 3-4 |
| 3 Robot learning | imitation and reinforcement-learning policies trained in simulation, with honest evaluation curves | 6-8 |
| 4 Real hardware | a physical arm you assembled, a dataset you teleoperated, a policy running on it | 6-8 |
| 5 Foundation models | a fine-tuned vision-language-action model and a comparison against your own Module 3 baseline | 8-10 |
| 6 Agentic robotics | a language-model planner driving learned skills, with verification between them | 6-8 |
| 7 Capstone | one deep project in the track you pick | 6-8 |
Two things about the order. Modules 3 and 5 are where most of the hours and most of the payoff land, so expect the rhythm to strain there. And Module 1’s two months of hand-written mathematics come before anything that learns, on purpose. It is the module people with an AI background skip, and months later they cannot work out why a trained policy sends the gripper somewhere strange, because the bug is a frame convention and they have no model of frames to debug with.
The week that produces all of this
Wider than the screen; scroll it sideways.
- Two deep blocks, two hours each. The current module’s lessons and its build. Calendar-blocked, phone in another room.
- One lab block, two hours. Hands on the code: run it, break it, tune it, log what happened. This is not the same activity as the deep blocks and does not substitute for them.
- One reading hour. One paper or post, triaged with an assistant.
- About thirty minutes of community. Presence in the LeRobot Discord. From Module 3 onward, answer one beginner question a week; teaching is the fastest consolidation there is.
Then two longer cycles. Monthly: one weekend push, where you replicate somebody’s result or ship a small demo. Quarterly: reread your thesis note, update it, and check that the course’s later modules still point at a live frontier rather than last year’s one.
Publish from Module 1, not when you feel ready
Each module ends with a short public writeup: a blog post, or a repository README with real numbers in it. Twelve months of that is six to eight artifacts, and they are the thing that makes the year legible to anyone else. Nobody is going to ask whether you have a robotics degree; they are going to read the artifacts.
The writing rule is to report numbers, including the failures. “82% success, dropping to 41% when I moved the camera fifteen centimetres” is more credible than any polished claim, and more useful to you six months later when you have forgotten which camera position produced the good number.
The second effect matters more than the first. A writeup with numbers in it cannot be produced without having measured something, so the habit of publishing quietly forces the habit of measuring.
How to study with an AI
You already use these tools daily, so generic advice is worse than none. The specific problem: an assistant is built to be helpful, and in a learning context its helpfulness lands in your file rather than in your head unless the request is shaped so that it cannot. Every move below shapes it.
Wider than the screen; scroll it sideways.
| What you want | The ask that gets it | Why it works |
|---|---|---|
| To find your own bug | “Here is my code and what I expected to happen. Ask me questions until I spot the mistake. Do not tell me what it is.” | The search stays in your head, which is where the model of the system gets built |
| To find out what you do not know | “Grill me on this lesson. Keep probing until you find a gap, explain only that gap, then re-test me tomorrow.” | Your confidence is a poor detector of your own gaps; an examiner is a better one |
| An honest read of a paper | “Before you summarise this: what would a hostile reviewer attack, and what did the authors not evaluate?” | A summary read first primes you to accept the paper’s framing, and you do not get that neutrality back |
| A derivation you keep | Ask for the first step only, derive the rest yourself, then have it check your work | Checking is a job it does well and you can verify; deriving for you is neither |
| Speed on things that are not the lesson | Generate the plotting boilerplate, the argument parsing, the Dockerfile | Nothing about your understanding of robotics is at stake in an axis label |
That last row is the real boundary. The rule is not “do not generate code.” It is “do not generate the code that is the lesson.”
Worked solutions live in solutions/. They are for after you are genuinely done, or genuinely stuck for more than a session. Reading one before you attempt the exercise costs you the exercise, and there is no way to un-see it.
Check yourself
1. Why is a module finished when its project runs rather than when its lessons are read?
Because reading produces the feeling of understanding at roughly a fifth of the cost of the build, and the feeling tracks the ability poorly. The project is the part that discovers what you actually cannot do: the frame convention you had backwards, the sign error, the assumption that only shows up when the arm stretches straight. Reading is fuel; on its own it produces a well-informed person who cannot make anything move.
2. A brutal work month arrives and you can defend one block a week. Which do you keep, and what do you deliberately drop?
Keep one deep block and let it absorb the lab work; the thing that must not stop is the milestone project. Drop the reading hour and the community time, because they are the two that produce nothing you own. The trap is the opposite instinct, which is to “keep up” by reading, since reading fits in small gaps and feels like progress. A slow month on the build is recoverable. A month of reading with no build leaves you where you started, feeling further ahead.
3. The Module 1 artifact is a beginner’s kinematics library. Why publish it rather than waiting until the work is good?
Three reasons, and only the last is about audience. The habit has to exist before the interesting work arrives, and habits do not start on demand at Module 5. A writeup with numbers cannot be written without measuring. And waiting for “good enough” means the first half of the year produces nothing visible, which is the half where you most need evidence that you are moving. A rough artifact with honest numbers beats a polished one with none.
4. Why is “ask for hints, not solutions” a sharper rule in robotics than in ordinary software?
Because the failures are physical and the feedback is poor. Generated web code that is wrong usually throws, and the trace teaches you what it was doing. Generated robot code that is wrong produces a pose that is off, a motor that saturates, or a policy that misbehaves near one edge of the arm’s reach, and none of those tell you where to look. Debugging it needs a model of what the code was supposed to do, which is exactly what you skipped acquiring when you asked for the answer. There is also no undo: a bad command can break hardware, or whatever the hardware is holding.
5. Why does this course spend two months on hand-written mathematics before touching anything that learns?
Because the debugging surface underneath a learned policy is made of frames, transforms, units and timing, and those do not become learnable just because the layer above them is. When a trained policy sends the gripper somewhere strange, a convention mismatch in the plumbing is a common cause. If you implemented that plumbing yourself you find it in an hour. If you never did, it looks identical to the policy being bad, and you can spend a week collecting more data to fix a bug that was never in the data.
Do this
Week one. Five things, in this order.
- Decide about the arm, and if you want one, order it today. See the setup guide. Buying is optional: the course runs end to end without an arm, and lesson 4.0 is the honest comparison of the two routes. But the decision belongs in week one either way, because if the answer is yes, lead times run in weeks and the clock should start while you study.
- Set up the Python environment and run the verification script. Instructions in the same setup guide. Do this before Module 1 rather than during it.
- Join the LeRobot Discord and introduce yourself. Say you are working through a self-directed course. This costs five minutes and makes the community time in the weekly rhythm possible later.
- Put the weekly blocks in your calendar as recurring events with real names, for the next three months: both deep blocks, the lab block, the reading hour. Not a note. Calendar entries.
- Write
notes/00-thesis.md, the Module 0 milestone: what you believe about robotics right now, which layer of the stack you are aiming at and why, one thing from Module 0 that surprised you, and one claim you are sceptical of. One page. You will reread it at Module 7 and enjoy being wrong about parts of it.
Then turn the page: Module 1, Foundations.
What you can now do
You can state the route from here to a capstone, say what lands in your repository at the end of each module, and describe the weekly shape that gets you there. You know the rule that decides when a module is finished, why publishing starts at Module 1 rather than when the work is good, and how to put a question to an AI assistant so the understanding ends up in your head instead of in your file. Orientation is over. Module 1 opens with a question that sounds trivial and is not: where is anything, and relative to what?