LLM + RoboticsBuild a Robot Brain · Week 12 · Lesson 14

Going real: hardware, showing your work, what's next

Your robot brain works, on your laptop, in a perfect pretend room. This last lesson is about the two steps that turn a school project into something real: showing it to other people honestly, and (if you want) putting it on wheels.

Time2–4 hours (a hardware build: a few weekends)

You'll needYour finished project, a way to record your screen. Optional: a small robot kit.

New wordsREADME, demo, portfolio, ultrasonic sensor, motor, drift, kill switch

Project pieceShare it, or put it on a real robot

Start here

A project nobody can understand might as well not exist, and a simulation is only a rehearsal for the real, messy world.

The problem

You've built something genuinely impressive: a robot that understands commands, plans routes, brakes safely, dodges a cat and grades itself. Right now it lives in a folder only you know about. If you showed it to a teacher, a friend or a future employer, could they run it in five minutes? Would they know what it gets wrong? And the room it drives around is made of text characters. A real floor has slippery tiles, socks and an actual cat.

The idea in one picture

Think of a science fair. The best stands aren't the ones that claim "it works perfectly". They're the ones with a clear poster, a working demo, a graph of results, and a corner that says "what went wrong and what we learned". The judges trust those stands, because they're honest. A README is your science-fair poster. A real robot is taking your experiment out of the lab.

Words to know

README: The front-page text file of a project. It says what it is, how to run it, and how well it works.
Demo: A short recording or live show of the project doing its thing, failures included.
Portfolio: A collection of your projects that shows what you can do.
Ultrasonic sensor: A sensor that measures distance by sending a sound too high to hear and timing the echo, like a bat.
Drift: When a real robot slowly ends up somewhere other than where it thinks it is, because wheels slip.
Kill switch: A physical switch that cuts the power instantly, whatever the code is doing.

The full lesson: four parts: showing your work, going physical (optional), safety and ethics, and where to go next. There's no Python file this time: your homework is the README and a demo.

1. The problem

Two problems, actually.

Nobody can see your work. Your code is spread over 20 files. Someone new doesn't know to start at lesson11_robohelper.py, doesn't know about check.py, and doesn't know that 83% is the honest score, not a bug. Without a guide, most people give up after a minute.

The pretend world is too kind. In world.py, a step east moves the robot exactly one square. The sensor in Lesson 2 has neat, made-up noise. The cat sits still on one square. Real motors don't turn exactly the same amount each time, real sensors get confused by soft cushions, and real cats move. Every robot that works in real life first worked in a simulation, and then had to be fixed for the real world.

2. First principles

Part A: showing your work

Start from the reader. Someone opens your project. In order, they want to know:

What is it? One sentence, plus a picture or short recording.
Can I run it? The exact commands, copy-pasteable.
How does it work? The pipeline, in a small diagram. Which part does what.
How well does it work? Real numbers from a real test, and what the test was.
What fails, and why? The honest list.
What would you do next?

That list is your README's outline. You have every piece already. For the results, use your own evaluate() output: Test set: 83% passed, with FAILED: ('find the green block', 'The green block is in the bin.') and FAILED: ('make me a sandwich', 'Stopping.'). Add your Lesson 19 bake-off table: which brain passed what, how long it thought, and what it cost. If you did the Lesson 11 stretch, show the before and after.

Predict first: two READMEs. A says "My robot understands commands perfectly!". B says "83% on a 12-command test set. It thinks 'make me a sandwich' means stop, because the classifier can't say 'I don't know'." Which one would an engineer trust more?

B, by a mile. "Perfectly" makes an engineer suspicious straight away, because nothing is perfect, so either you didn't test it or you're hiding something. B shows that you tested, you measured, you understood the failure, and you can explain it. That's exactly what people who hire engineers look for. Honest failures are a strength, not a weakness.

See how grown-up AI work reports results: the "reading the results honestly" section of the distillation module is a good model, with numbers next to what they do and don't prove. And the open-source portfolio stage shows how professionals use public projects like yours to get noticed.

The demo recording. 30 to 60 seconds is plenty. Most computers have a built-in screen recorder. Show: one command working, the cat replan (the log line), the test-set score, and one failure on purpose. Talk over it, or add captions. Then put the recording file (or a GIF) next to your README and link to it.

Part B: going physical (optional)

You don't need hardware to finish this course. But if you want to see your ideas move, a cheap wheeled robot kit is the next step. Look for one with two motors and an ultrasonic distance sensor. Kits built around a micro:bit (which can run MicroPython, a small version of Python) or an Arduino (usually programmed in C++, which looks different but uses the same ideas) are common, well documented, and used in lots of schools.

How an ultrasonic sensor works, from first principles. It sends a short click of sound, too high-pitched to hear, and times how long the echo takes to come back. Sound travels at about 343 metres per second in air. The sound goes there and back, so you halve it:

echo time   = 2.9 milliseconds = 0.0029 s
distance    = 343 × 0.0029 ÷ 2
            = 0.497 m   ≈ half a metre      (one Robo-Helper square!)

Now map each lesson onto the real robot:

Lesson	In the simulation	On a real robot
L2 Sensors	`noisy_reading`, `average`	Take 5 to 10 ultrasonic readings in a row and average them. Real readings jump around, especially off soft or angled things. Lesson 2's maths is exactly why averaging helps.
L3 Braking	`STOP_DATA`, `fit_line`, `max_safe_speed`	Drive at a few motor power levels, cut the power, and measure with a tape how far it rolls. That's your own `STOP_DATA`. Fit the line on a laptop, then put the two numbers (w and b) into the robot's code.
L4–L5 Stop decision	`should_stop`, `safest_threshold`	Inputs: smoothed distance and current speed. Start with a simple safe rule, then collect real examples ("should it have stopped?") and train the neuron. Choose a threshold that favours recall: braking for nothing is fine, hitting the wall is not.
L6 Pathfinding	`astar_path`, `path_to_commands`	Use floor tiles (or tape squares on the floor) as your grid. Draw the map, plan with A*, and turn the path into moves: "forward one tile, turn left, forward two tiles".

The big surprise: drift. Tell a real robot "forward one tile" ten times and it won't land exactly ten tiles away, slightly to the left. Wheels slip and motors differ. This is why real robots keep sensing while they move, and correct themselves, instead of trusting the plan blindly. It's the same lesson as Lesson 10, in motors instead of words: never trust, always check.

Predict first: your robot plans a 6-tile route along a corridor using only "forward one tile" commands. What's the most likely thing to go wrong?

It drifts sideways and bumps a wall, or stops a bit short. Each move is slightly off, and the errors add up over 6 moves. The fix is feedback: use the distance sensor to check the gap to the wall ahead, and stop based on what it measures, not on how many moves you planned.

Later: a robot arm. When you're ready for a bigger project, look at LeRobot, Hugging Face's open-source robotics library. It supports low-cost robot arms that people build themselves, and lets you teach an arm by showing it what to do, then training a neural network on your demonstrations. Their free robotics course is a good next step after this one. This is a project for later, with an adult: it needs more money, tools and patience.

Part C: safety and ethics

Moving robots can hurt people and pets. Even a small one can pinch fingers in its wheels, trip someone, scare a pet, or drive off a table or down the stairs. Follow these rules every time:

Always have a physical off switch you can reach instantly. Not a button in your code: a real switch that cuts the power, because when the code is the problem, the code can't save you.
Test with the wheels off the ground first (prop it on a book), then on the floor at the slowest speed, away from stairs, table edges, pets and little brothers or sisters.
Adult supervision for anything with tools (soldering irons, hot glue guns, craft knives) and for batteries. Rechargeable lithium batteries can get very hot or catch fire if they're squashed, short-circuited or charged the wrong way. Use only the batteries and charger the kit says, and never leave them charging unattended.

Ethics, in plain words. Lesson 10's rule still applies: never let AI output control something that moves without checks you wrote. If your robot ever has a camera or microphone, ask people before recording them. And be honest in what you claim, in your README and in conversation. "It works 83% of the time on my test set" is a true sentence. "It understands language" is not.

Part D: where to go next

Free robotics courses: a checked list of free courses to go deeper into robotics.
Three books and a gym: a longer path through language models, reinforcement learning and building things.
Ilya's 30 papers: the famous reading list. Start with day 1, which is about next-word prediction, the same idea as your Lesson 8.

3. Play with it

Interactive: README builder

Fill in your own numbers. The README updates as you type and is saved in this browser. Tick each section only when it's true for your project. The honesty check is strict on purpose.

Project name Test-set score (from evaluate()) Biggest failure, and why

Sections ready

–

Honesty check

–

4. Homework

No Python file this time. You'll make three things, in your project folder.

4.1 Make sure everything passes

From the project folder, run python3 check.py all. When every lesson is done, the last line reads Total: 84/84 checks passed (that's the real total for the reference solutions). If anything is red or yellow, fix it first: a README for a broken project is a sad README.

4.2 Write `README.md`

Use the six questions from Part A as your headings. The builder above gives you a starting draft, but rewrite it in your own words. Keep it short: one screen per section at most.

Hint 1: the "how to run" section

Pretend the reader has never used a terminal. Give the exact commands, in order, in code blocks: cd project/solutions (or homework), then python3 lesson11_robohelper.py, then python3 ../check.py 11 from the right folder. Test them yourself in a fresh terminal window.

Hint 2: the results section

Say what was tested (12 commands, a fresh robot each time, a surprise at (4, 1)), then the number, then what it does and doesn't prove. "83% on 12 commands" is not "83% in real life". If you did the stretch, show before and after in a small table.

Hint 3: the "what fails" section

For each failure: the command, what the robot did, why (in one sentence), and an idea for fixing it. Include at least the sandwich. Good extras: Lesson 10's "hmm what about the blue" becoming a "put", and (if you found it) "find the green block" being classified as "put", which bins the block.

4.3 Record a demo

30–60 seconds of screen recording: one command working, the cat replan, the test score, and one failure on purpose. Save it next to the README and link to it.

How to check

Give your project folder to someone who hasn't seen it (a parent, a friend, a teacher). Don't help them. Can they run it from the README alone in under five minutes? Can they tell you, afterwards, what the robot is bad at? If yes to both, you're done.

Stretch

With a parent's or guardian's OK, put the project on a public code site such as GitHub. Check there are no secrets in it first (like an API key from Lesson 10's optional file).
If you have a robot kit: get just the sensor working first. Take 20 readings of a wall at 50 cm, then work out the average and how far the readings spread, exactly like Lesson 2's average_error. Add the numbers to your README.

5. Real-world challenge: present it

Real engineers explain their work out loud, to people who weren't there. That's a skill, and it gets better with practice.

Find someone willing to listen for 10 minutes: a parent, grandparent, friend, or teacher. Non-technical people are best.
Present for 5 minutes: what the robot does, the demo (live or recorded), the honest score, and one failure, explained simply.
Then stop and ask: "What questions do you have?" Write down every question, word for word, even the ones that seem silly.
Afterwards, sort the questions: ones you answered well, ones you answered badly, and ones you couldn't answer.
Add a short FAQ to your README with the best questions and answers. Put the ones you couldn't answer into "What I'd do next".

What it teaches: other people's questions show you what's unclear, and often what's genuinely missing. Questions like "what happens if the cat moves?" or "can it learn new words?" are real research questions.

6. Your Robo-Helper so far

Robo-Helper is finished: it understands commands (L8–L9), refuses unsafe ones (L10), plans (L6), senses and brakes (L2–L5), replans around surprises, and grades itself (L11). Lessons 12 and 13 showed how bigger models learn what people prefer and adapt cheaply. Now it also has the two things every real project needs: a README that tells the truth and a demo.

Nothing later in this course uses it, because this is the end of the course. But it lives on as the first piece in your portfolio, and, if you build the kit, as the brain of a robot you can actually watch drive across your floor.

7. Common mistakes

Hiding the failures. A README that only shows the good bits reads like an advert. Show the 83% and the 17%.
"How to run" that doesn't run. Test the commands from a fresh terminal, in a fresh copy of the folder.
A ten-minute demo. Nobody watches it. Under a minute, and the best part first.
Testing a real robot on a table. It will drive off the edge one day. Floor only, slow first, off switch in reach.
Trusting the plan on real wheels. Drift adds up. Keep sensing while moving.

8. Check yourself

Name the six questions a README should answer.

What is it? Can I run it? How does it work? How well does it work? What fails and why? What would you do next?

An ultrasonic echo comes back after 5.8 ms. How far away is the object?

343 × 0.0058 ÷ 2 ≈ 0.99 m. Twice the time, twice the distance: about one metre.

Predict: your real robot plans "forward 4 tiles" and you measure where it stops, five times. Will all five be the same?

No. They'll spread out a bit, and probably all lean slightly one way. That's drift plus noise, the real-world version of Lesson 2. Averaging the five shows the typical error, and checking with the sensor while driving fixes it.

Why must the off switch be physical, not a button in your code?

If the code has a bug or freezes, a software button may not work. A physical switch cuts the power whatever the code is doing.

Which lesson's idea is "keep sensing while you move, don't trust the plan blindly" most like?

Lesson 10: never trust, always check. There it was AI output, here it's your own motion plan. Lesson 11's replanning around the cat is the same idea too.