EV3 Robotics›Level 3 · Advanced›Lesson 48
Level 3 · Lesson 48 · EV3-L03-4860 minutes · Ages 9–16 · Model: Gyro Boy
Gyro Boy: two wheels, no third point of contact, and a Gyro Sensor. It stays upright by driving the wheels underneath itself, about a hundred times a second, for as long as it is switched on.
This is the last model of the course, and it is the LEGO capstone for a reason. It cannot be made to work by trying harder. It needs almost everything the previous forty-seven lessons built.
By the end of the lesson your robot will balance — and, more importantly, you will be able to look at how it is failing and say which of the three corrections is wrong.
A Segway does exactly this. So does a hoverboard, and so do you, standing still — your ankles are making constant small corrections you are not aware of, and you notice them the moment you try to stand on one leg.
The same three-part correction runs a cruise control, a thermostat, a quadcopter, a car’s traction control and the temperature loop in a 3D printer. It is called PID, and it is the single most widely used control algorithm in engineering.
Because one correction is not enough. React only to how far you are leaning and you will overcorrect and oscillate. Add nothing about how fast you are falling and you cannot catch a fall early. Ignore how long you have been slightly off and you will drift across the room without ever noticing.
Each of the three fixes a failure the other two cannot. That is the whole design, and it is why the same three terms turn up in machines that have nothing else in common.
You get the failures by name, and you have already met two of them in this course. Lesson 5’s closed loop is P alone — and it oscillated. Lesson 40’s feed-forward answered a delay this loop still has.
How far off. How fast it is changing. How long it has been wrong. Add all three.
Every pass round the loop, the robot measures one thing — the error, how far from upright it is — and turns it into three separate corrections that are added together.
| Term | Answers | Where you met it | Without it |
|---|---|---|---|
| P — proportional | How far off am I right now? | Lesson 5, the closed loop. | No correction at all. It falls. |
| D — derivative | How fast is that changing? | Lesson 31, derived values. | It overshoots and oscillates — always correcting for where it was. |
| I — integral | How long have I been off? | New today. | It balances, leaning slightly, and slowly drives across the room. |
set [error v] to ((angle) - (upright)) :: variables set [sum v] to ((sum) + ((error) * (dt))) :: variables set [rate v] to (((error) - (last error)) / (dt)) :: variables set [last error v] to (error) :: variables set [power v] to ((((kp) * (error)) + ((ki) * (sum))) + ((kd) * (rate))) :: variables
Change one number at a time and write down what happened. Three interacting numbers changed together cannot be reasoned about — you will simply be guessing, and every engineer who has ever tuned a loop learned this the same way.
wait block anywhere in this loop is a fall. The loop must never stop.dt. Assume a fixed loop time and the tuning changes whenever the program does.This is the argument of the whole course in one model. Nothing here is a clever trick. It is six ordinary ideas that only work together.
The Gyro Sensor measures how far the robot has turned, in degrees. Wheels slip and floors vary, so counting wheel rotations is a poor way to turn accurately — the gyro measures the turn itself rather than inferring it.
from above
front| Block | What it does |
|---|---|
([2 v] angle :: sensors) | Reports how far the robot has turned since the angle was last reset. |
[2 v] reset angle :: sensors | Sets the current heading as zero. |
The angle is measured from wherever it was last zeroed — not from where this turn started. Here are two robots given the same instruction, one with a reset block and one without.
reset first
no reset
Both programs are correct about what they asked for. Only the left one asked the question from a known starting point.
Both programs did exactly what they said. Both gyros stopped at 90. But the robot on the right had 34 degrees already on the clock, so it only turned 55 — and nothing about the program looks wrong. Watch the first step too: neither robot is moving and the reading is still climbing. That is drift, and it is why the reset belongs immediately before the turn.
Reset with the robot completely still, as late as you can.
when program starts :: events hat [2 v] reset angle :: sensors start moving [straight: 0] :: movement wait until <([2 v] angle :: sensors) > (90)> stop moving :: movement
That program is the obvious one to write, and it will not give you a 90 degree turn. The next section is why.
Asking to stop at 90 does not stop the robot at 90. Between the gyro reaching 90 and the wheels actually standing still there is a delay — the sensor has to be read, the next block has to run, and the motors have to physically brake. The robot is still turning through all of it, so it ends up past where you asked.
The fix is to ask for less than you want. Aim for a 90 degree turn by waiting for 86: the robot coasts the last few degrees on its own and settles at roughly 89 to 91.
ask for exactly 90
stop 4° early
The tolerance has to match the speed. At 50°/s the number that lands this turn on 90° is 86 — let it loop, and watch that number change when the speed does.
The size of that gap is not a fixed property of the robot — it is the delay multiplied by how fast you are turning. The delay stays about the same whatever you do, so a turn at double the speed carries you about double the distance past the mark.
| Turn speed | Carried past the stop | Wait for | Ends up at |
|---|---|---|---|
| slow | about 4° | 86 | about 90° |
| fast | about 10° | 80 | about 90° |
So the tolerance and the speed have to be chosen together. Turn faster and you must give up more; if you speed a turn up and forget to lower the number, the robot starts overshooting every corner and the program that worked last week no longer does.
when program starts :: events hat [2 v] reset angle :: sensors start moving [right: 30] :: movement wait until <([2 v] angle :: sensors) > (86)> stop moving :: movement
Find your own number rather than copying this one — it depends on your robot’s weight, its wheels and the speed you turn at. Run the turn, measure where it actually stops, and move the number by however far it missed. Two or three tries is usually enough.
The other half of the answer is to slow down. A slower turn overshoots less, so it needs less guessing and repeats more reliably — which is why a turn worth getting right is rarely worth rushing.
A gyro slowly loses its zero even when nothing is moving. Leave a robot sitting still for a minute and the angle may have wandered several degrees all by itself. That is drift, and it is a property of the hardware, not a bug in your program.
Two habits deal with it: reset the angle as late as possible before a turn, and keep the robot dead still while the reset happens. Resetting while the robot is rolling bakes the error in permanently.
Aircraft, ships and phones all use gyros to know their orientation — it is how a phone knows you have turned it sideways. A robot that can turn exactly 90 degrees on any surface is far more reliable than one that guesses with wheel rotations.
Long before there were computers, people had exactly this problem. A shepherd counting sheep through a gate, a trader counting sacks of grain, a builder counting days — none of them can hold the number in their head while they get on with the work. So they scratched a mark on a wall, cut a notch in a stick, or wrote a number on a piece of paper. The number lived outside the person, in a place they had agreed on, and they could go back to it, read it, and change it.
Better still, once the number is written down somebody else can use it. Watch these two: one of them counts and writes, the other never sees a single animal and simply reads the wall.
Notice what never happens: Ben never asks Abby. He does not need to — the number is not in her head, it is on the wall, and the wall is there for anyone who needs it.
Neither Abby nor Ben is holding the number — the wall is. And notice what never happens: Ben does not ask Abby. He does not need to, because the count is not in her head. It is in a place they both agreed on, which is what makes it useful to more than one of them.
That is all a variable is. The robot cannot hold a number in its head either, so you give it a wall of its own, write a name at the top so everyone knows which wall is which — score, count, degree_turn — and the program can read what is on it and write something new. One part of the program writes; another part reads. Exactly Abby and Ben.
Say we are counting rotations of a motor. Before we start we write 0 on the paper. Every time the motor completes a turn we cross out what is there and write one more: 0 becomes 1, then 2, then 3. That is change — it has to read the old number to work out the new one.
set is the other thing you can do, and it is completely different: rub the whole paper out and write the number you want. It does not care what was there. Press the buttons and watch what happens to the crossings-out.
The paper starts blank, so we write 0 on it. That is what a variable is: a place to keep a number while the robot works.
| Block | What it does |
|---|---|
set [count v] to (0) | Puts a value in, replacing whatever was there. |
change [count v] by (1) | Adds to what is already there. |
(count) | Reports the current value, for use in a comparison or on the display. |
set replaces; change adds. Counting things needs change. Starting a count needs set. Both programs below have both blocks — the only difference is whether the set block is inside the loop or above it.
set before the loop
set inside it
Both programs contain both blocks. Only the position of set [count] to 0 is different.
The count on the right is not broken; it is being told to start again on every pass. Each time round the loop it is wiped back to zero and then changed by one, so the honest answer is always 1 — while the motor cheerfully turns four times. A counter stuck at 1 almost always means a set block that has slipped inside the loop.
EV3 Classroom tells you what a block does by its shape, and once you have noticed that, a whole set of questions answers itself:
So when a slot is oval, any oval fits it — and it does not matter in the least where that number came from. You can take the motor’s own A degrees counted and keep it in a variable you named degree_turn, then compare that with a number later. Pick an oval below and watch the same one drop into all three kinds of slot.
pick an oval
the same oval fits all three
Every one of those slots is oval-shaped, and A degrees counted is an oval — so it drops in. Nothing about where the number came from matters.
This is what makes a variable more than a counter. A sensor reading is true only at the instant you read it; copying it into a variable freezes it, so the robot can compare where it is now against where it was when something happened:
when program starts :: events hat [A v] reset degrees counted :: motors set [degree_turn v] to ([A v] degrees counted :: sensors) start moving [right: 30] :: movement wait until <(([A v] degrees counted :: sensors) - (degree_turn)) > (400)> stop moving :: movement
Read the condition aloud: how far the motor has gone now, minus where it was when we started, is more than 400. Both are ovals, so both can go into a subtraction, and the subtraction is an oval too — which is why it can go into a comparison. Ovals nest inside ovals as deep as you need.
A variable keeps its value after the program ends. Run the program again without setting it back and the second run begins where the first left off — the count starts at 14, the robot thinks it has already done the job. Every variable a program changes must be set to its starting value at the top.
A variable is the difference between a machine that repeats a fixed routine and one that responds to how things have gone — counting parts, tracking a score, remembering where it started.
A wait pauses for a length of time. The timer is different: it runs in the background and can be read at any moment, so the robot can know how long something has taken while it is still happening.
| Block | What it does |
|---|---|
(timer) | Reports the seconds since the timer was last reset. |
reset timer | Sets it back to zero, so the next reading counts from here. |
The most valuable use of a timer is escaping a wait that might never end. A robot told to drive until it sees a wall will drive for ever if the wall is not there. Combined with a timer, it can give up:
Repeat until the wall is close or five seconds have passed. That one change turns a program that can hang into one that always finishes. Both robots below are looking for a wall that is not there.
no way out
with a timeout
The sensor is not faulty and the program is not wrong. There is simply no wall, and only one of these two programs has a way of noticing that.
The left-hand robot is not broken, and neither is its sensor. Its condition is simply one that will never come true, so the program sits on that block for ever — with nothing on the Brick to say so. The right-hand program asks the same question with an escape route bolted on, and finishes every time.
Real systems time themselves out constantly — a lift that cannot close its doors eventually gives up and beeps rather than trying for ever. A robot with no timeout simply stops responding, and there is nothing on screen to say why.
P for now, D for the direction it is going, I for what has been quietly accumulating.
The Gyro Sensor measures how far the robot has turned, in degrees. Wheels slip and floors vary, so counting wheel rotations is a poor way to turn accurately — the gyro measures the turn itself rather than inferring it.
from abovefront| Block | What it does |
|---|---|
([2 v] angle :: sensors) | Reports how far the robot has turned since the angle was last reset. |
[2 v] reset angle :: sensors | Sets the current heading as zero. |
The angle is measured from wherever it was last zeroed — not from where this turn started. Here are two robots given the same instruction, one with a reset block and one without.
reset first
no reset
Both programs are correct about what they asked for. Only the left one asked the question from a known starting point.
Both programs did exactly what they said. Both gyros stopped at 90. But the robot on the right had 34 degrees already on the clock, so it only turned 55 — and nothing about the program looks wrong. Watch the first step too: neither robot is moving and the reading is still climbing. That is drift, and it is why the reset belongs immediately before the turn.
Reset with the robot completely still, as late as you can.
when program starts :: events hat [2 v] reset angle :: sensors start moving [straight: 0] :: movement wait until <([2 v] angle :: sensors) > (90)> stop moving :: movement
That program is the obvious one to write, and it will not give you a 90 degree turn. The next section is why.
Asking to stop at 90 does not stop the robot at 90. Between the gyro reaching 90 and the wheels actually standing still there is a delay — the sensor has to be read, the next block has to run, and the motors have to physically brake. The robot is still turning through all of it, so it ends up past where you asked.
The fix is to ask for less than you want. Aim for a 90 degree turn by waiting for 86: the robot coasts the last few degrees on its own and settles at roughly 89 to 91.
ask for exactly 90
stop 4° early
The tolerance has to match the speed. At 50°/s the number that lands this turn on 90° is 86 — let it loop, and watch that number change when the speed does.
The size of that gap is not a fixed property of the robot — it is the delay multiplied by how fast you are turning. The delay stays about the same whatever you do, so a turn at double the speed carries you about double the distance past the mark.
| Turn speed | Carried past the stop | Wait for | Ends up at |
|---|---|---|---|
| slow | about 4° | 86 | about 90° |
| fast | about 10° | 80 | about 90° |
So the tolerance and the speed have to be chosen together. Turn faster and you must give up more; if you speed a turn up and forget to lower the number, the robot starts overshooting every corner and the program that worked last week no longer does.
when program starts :: events hat [2 v] reset angle :: sensors start moving [right: 30] :: movement wait until <([2 v] angle :: sensors) > (86)> stop moving :: movement
Find your own number rather than copying this one — it depends on your robot’s weight, its wheels and the speed you turn at. Run the turn, measure where it actually stops, and move the number by however far it missed. Two or three tries is usually enough.
The other half of the answer is to slow down. A slower turn overshoots less, so it needs less guessing and repeats more reliably — which is why a turn worth getting right is rarely worth rushing.
A gyro slowly loses its zero even when nothing is moving. Leave a robot sitting still for a minute and the angle may have wandered several degrees all by itself. That is drift, and it is a property of the hardware, not a bug in your program.
Two habits deal with it: reset the angle as late as possible before a turn, and keep the robot dead still while the reset happens. Resetting while the robot is rolling bakes the error in permanently.
Aircraft, ships and phones all use gyros to know their orientation — it is how a phone knows you have turned it sideways. A robot that can turn exactly 90 degrees on any surface is far more reliable than one that guesses with wheel rotations.
Say this back before moving on: “How far, how fast, and for how long?”
Hold the robot upright, let go, and watch which way it falls. Do it five times. If it always goes the same way, its centre of mass is off, and no amount of tuning will fix a build problem.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the loop as fast as it possibly can. Every block you add inside it slows the loop and makes balancing harder — this is the one program in the course where tidiness costs stability. |
| Large Motor ×2 — the wheels | The only actuators. Their job is to keep driving the wheels back under the centre of mass — a fall is caught by moving towards it, which is counter-intuitive until you have seen it. |
| Gyro Sensor — the lean | The whole input. It drifts, so it must be reset while completely still, and the robot must be held motionless for two full seconds during that reset. |
| Colour Sensor — mode | Shows a card to switch between tuning stages, so you are not editing and downloading a program between every experiment. |
| Touch Sensor — start and stop | Starts the loop after calibration, and stops it. A balancing robot needs an off switch you can reach without putting your hand in the way. |
Weight high and centred is easier to balance than weight low. That surprises everybody. A tall robot falls slowly, which gives the loop time to react — the same reason a broom balances on your palm and a pencil does not.
Sensors go in ports 1, 2, 3, 4. Motors go in ports A, B, C, D. They are not interchangeable, and nothing will tell you politely if you swap them.
| Part | Port | Why this one |
|---|---|---|
| Left wheel (Large) | B | The movement pair, as in every lesson of this course. |
| Right wheel (Large) | C | The other half. |
| Start / stop (Touch) | 1 | Touch stays on 1 across the course. |
| The lean (Gyro) | 2 | Gyro stays on 2 across the course. |
| Mode card (Colour) | 3 | Colour stays on 3 across the course. |
Check your own build now:
Two routes, and either is fine. USB is the reliable one and the one to fall back on when a room’s Bluetooth is busy; Bluetooth leaves the robot free to move, which some models need.
Do these in order. Naming the Brick after you go looking for it in the list is how groups end up driving each other’s robots.
EV3 until somebody changes it.EV3.The two failures, every class, every time. The Brick has gone to sleep while you were building — press the centre button to wake it. Or you have paired with the group at the next table, which is why the name matters.
The long version, including Port View and how to read the port tiles, is in the Brick & Bluetooth guide.
Bluetooth is not optional here. A cable is a sideways force on a robot whose entire job is resisting sideways forces — and a fresh battery matters more than in any other lesson, because a tired one changes how hard the wheels push and therefore your whole tuning.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Build it in three stages and watch each one fail in its own way. The failures are the lesson; a robot that balances first time teaches nothing.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set [kp v] to (8) :: variables [2 v] reset gyro :: sensors wait (2) seconds :: control wait until <[1 v] is pressed? :: sensors> forever set [error v] to ([2 v] angle) :: variables start moving at ((kp) * (error)) % speed :: movement end
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set [kp v] to (8) :: variables set [kd v] to (0.6) :: variables [2 v] reset gyro :: sensors wait (2) seconds :: control reset timer :: control set [last t v] to (timer) :: variables set [last error v] to (0) :: variables wait until <[1 v] is pressed? :: sensors> forever set [dt v] to ((timer) - (last t)) :: variables set [last t v] to (timer) :: variables set [error v] to ([2 v] angle) :: variables set [rate v] to (((error) - (last error)) / (dt)) :: variables set [last error v] to (error) :: variables start moving at (((kp) * (error)) + ((kd) * (rate))) % speed :: movement end
when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
set [kp v] to (8) :: variables
set [ki v] to (0.1) :: variables
set [kd v] to (0.6) :: variables
set [sum v] to (0) :: variables
set [last error v] to (0) :: variables
// ---- calibrate: upright is whatever THIS robot balances at ----
write [HOLD ME STILL] at line (1) :: display
[2 v] reset gyro :: sensors
wait (2) seconds :: control
set [total v] to (0) :: variables
repeat (20)
set [total v] to ((total) + ([2 v] angle)) :: variables
end
set [upright v] to ((total) / (20)) :: variables
write [PRESS TO START] at line (1) :: display
wait until <[1 v] is pressed? :: sensors>
wait until <not <[1 v] is pressed? :: sensors>>
set status light to [green v] :: display
reset timer :: control
set [last t v] to (timer) :: variables
forever
// real elapsed time - never assume the loop takes a fixed period
set [dt v] to ((timer) - (last t)) :: variables
set [last t v] to (timer) :: variables
// smoothed, because D magnifies noise
set [total v] to (0) :: variables
repeat (3)
set [total v] to ((total) + ([2 v] angle)) :: variables
end
set [angle v] to ((total) / (3)) :: variables
set [error v] to ((angle) - (upright)) :: variables
set [sum v] to ((sum) + ((error) * (dt))) :: variables
set [rate v] to (((error) - (last error)) / (dt)) :: variables
set [last error v] to (error) :: variables
// stop the integral running away while it is on its side
if <(sum) > (60)> then
set [sum v] to (60) :: variables
end
if <(sum) < (-60)> then
set [sum v] to (-60) :: variables
end
set [power v] to ((((kp) * (error)) + ((ki) * (sum))) + ((kd) * (rate))) :: variables
if <(power) > (100)> then
set [power v] to (100) :: variables
end
if <(power) < (-100)> then
set [power v] to (-100) :: variables
end
// it has fallen - stop, do not sit there spinning the wheels
if <([abs v] of (error)) > (35)> then
stop moving :: movement
set status light to [red v] :: display
write [FELL OVER] at line (1) :: display
stop [all v] :: control
end
start moving at (power) % speed :: movement
endWhat success looks like: it stands, twitching slightly, and stays roughly where you put it. Nudge it gently and it recovers.
Diagnose by the shape of the failure. Rhythmic rocking: too much P, or too little D. Buzzing and twitchy: too much D. Balances but wanders off: too little I. Suddenly shoots across the table: too much I.
One number at a time. Predict, then run, then look — and write every result down. You are keeping a tuning log, which is what an engineer actually produces here.
wait 0.05 seconds in the loop. It falls immediately. Fifty milliseconds — that is how little slack a balancing loop has, and it is worth feeling once.Tune P until it oscillates, D until it stops, I until it holds still. In that order, one at a time, written down.
That is the end of the course — forty-eight models in Level 3, and a hundred and forty-four across the three levels.
Gyro Boy is the right place to finish because it cannot be faked. It needs a measured baseline, a smoothed reading, a derived rate, real elapsed time, a loop that never blocks, and an honest account of its own lag. Take any one away and it lies on the table.
That is what this course has actually been teaching. Not blocks — habits. Measure instead of guessing. Check that the world changed, not just that the command ran. Say which mistake you can afford. Make the machine explain itself on its own screen. Change one thing at a time and write down what happened.
The three numbers in this program are not the point either. PID is one algorithm; the method you used to find its numbers — one at a time, each failure named before it was fixed — is the thing that will still be useful in twenty years, on machines that have not been invented yet.
Everything you have built stands on a measurement somebody took. Now go and build something nobody has set as a lesson.
Build the model before you read any further. Everything after this is about making it do something, and none of it will make much sense with nothing on the table in front of you.
Use the viewer's own controls to zoom and turn pages. Fullscreen makes it big enough to build from.
Check the finished build against the picture before you switch anything on. A motor mounted the wrong way round is far easier to spot now than it is to debug later, when it looks like a program fault.
Work through the challenges in order — each is harder than the last. The mission comes after all three, and it is meant to make you plan before you build.
Tune P alone until it oscillates. With kd and ki at zero, raise kp until the robot rocks rhythmically back and forth. Report the kp at which the rocking starts. That oscillation is not a failure to fix by trying harder — it is the signal that P has gone as far as it can, and every engineer recognises it on sight.
Add D and take it away again. Raise kd until the rocking damps out, then keep going until it buzzes and twitches. Report both values. Then set kd to zero at a sensible kp and describe what comes back. That is what a derivative term is for, demonstrated rather than asserted.
Show what I fixes, and what it breaks. With ki at zero, let it balance for a full minute and measure how far across the table it travelled. Then add just enough ki to hold it still. Then set ki to 2 and watch the sum wind up and throw the robot. Explain in one sentence what the clamp on the sum is protecting you from.
Balance it, and produce the tuning log. Get Gyro Boy standing, recovering from a gentle nudge, and staying roughly where you put it. Requirements: 1. Upright measured at start-up while the robot is held still — not assumed to be zero. 2. A smoothed angle, because D magnifies noise. 3. Real elapsed time used for both the integral and the derivative. 4. No wait block anywhere inside the loop. 5. The integral clamped, and the output power clamped. 6. A graceful stop when it has genuinely fallen, instead of wheels spinning against the floor. The deliverable is not the balancing robot. It is the LOG: every value of kp, ki and kd you tried, in order, with one line each on what the robot did and what you changed next and why. Then add the failure table to the end — rhythmic rocking, buzzing, wandering, sudden launch — and which term causes each. That table is the last thing this course teaches, and it is the part that outlives the EV3. PID is one algorithm among many; tuning one number at a time and naming the failure before fixing it is the method, and it will still work on machines that have not been invented yet.
