Challenge 1
Check the Gyro against a protractor. Reset it, turn the model to what the screen calls 90 degrees, and measure the real angle. Report both numbers and the difference.
What you are building 3 min
The Gyro Magic Stick: a wand with a Gyro Sensor in it and a Large Motor that responds to how far you have turned it. Twist the stick and the machine reacts.
Every number your robot has used so far came from inside itself. The degree counter says how far a shaft turned — which is why the Rickshaw could report five rotations while its wheels were skidding, and why the Lawnmower’s square never quite closed.
The Gyro is different. It measures the model turning in the room. Not the motor. Not the wheels. The thing itself.
In the real world 5 min
Where you have seen it
There is a gyroscope in your phone — it is how the screen knows to rotate, and how a game knows you have tilted the handset. There are better ones in every aircraft, every ship and every spacecraft, because when there is no road underneath you, knowing which way you are pointing is not a convenience.
Why it is built that way
Older gyroscopes were spinning wheels — a heavy disc, spun fast, that resists being turned and so holds its direction while the vehicle moves around it. The one in the photograph has no moving parts at all; it splits a laser beam in two, sends the halves round a loop in opposite directions, and measures the tiny difference that rotation causes.
The one in your EV3 is a third kind, a vibrating chip smaller than your fingernail. All three do the same job: they measure rotation without touching anything. That is the property that matters. A wheel sensor needs the wheel to grip; a gyro needs nothing outside itself.
What would go wrong without it
An aircraft in cloud has no horizon and no landmarks. Pilots who fly into cloud without instruments lose track of which way is up within about twenty seconds — not through carelessness, but because the inner ear genuinely cannot tell a turn from level flight. The gyro is the only thing that knows.
Counting what the motor did tells you what you asked for. A gyro tells you what actually happened.
The main concept — degrees of the model 6 min
The Gyro reports one number: how many degrees the sensor has turned since it was last reset. Clockwise counts up, anticlockwise counts down.
([2 v] angle) :: sensors
degrees counted — and telling you something completely different.degrees counted | angle | |
|---|---|---|
| Measures | How far the motor shaft turned. | How far the whole model turned. |
| If the wheels slip | Still counts. It is wrong about the robot. | Unaffected. It never mentions wheels. |
| If you pick the robot up and turn it | Does not change at all. | Changes. It felt the turn. |
| Good for | Distance travelled, how far a mechanism moved. | Which way the model is pointing. |
That third row is the quickest way to feel the difference. Pick the model up, turn it a quarter circle in your hands and put it down. The motor counter has no idea anything happened. The Gyro says 90.
The blocks
| Block | What it does |
|---|---|
| ([2 v] angle) | Reports the angle now, in degrees. |
| [2 v] reset angle | Calls the current direction zero. Everything after is measured from here. |
| <[2 v] is angle [> v] (45) °?> | A hexagon, for a Switch — exactly like the sensor question in Lesson 16. |
The Gyro Sensor
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
frontBlocks reference
| 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. |
Always reset before you turn
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
when program starts
2 reset angle
start moving right: 100
2 wait until angle > 90
stop moving
no reset
start moving right: 100
2 wait until angle > 90
0°actually turned · reset0°actually turned · no reset
Reset: a real 90° turnNo reset: 0°, and no warning
Both robots have been sitting still. Both gyros already read about 34° — left over from an earlier turn — and the reading is creeping upward even now. That creep is drift.
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.
Stop before you get there
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
2 reset angle
start moving right: 30
2 wait until angle > 90
stop moving
stop 4° early
2 wait until angle > 86
stop moving
slowthis run · 50°/s+4°carried past the stop86tolerance needed here
Asked for 90: ended at 0°Asked for 86: ended at 0°
Both robots are told to turn 90°. The left one waits for the angle to pass 90; the right one gives up 4° early and waits for 86.
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.
Drift — the thing that catches everyone
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.
Why it matters
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.
The Gyro does not know where it is. It knows how far it has turned since you told it to start counting.
It drifts, and you need to know that. Leave a Gyro perfectly still and its reading will creep — a degree here, a degree there — because it is measuring something very small and adding it up. Over a few seconds that does not matter. Over ten minutes it does. Reset it at the start of anything that depends on it.
Asking a sensor inside a SwitchFrom Lesson 16 — the hexagon that reads the world without stopping the program.Show meHide
Making a decision
Up to now a robot has been able to wait for a sensor. Deciding is different: the robot checks the sensor and does one thing or another depending on the answer — and then carries on either way.
Blocks reference
| Block | What it does |
|---|---|
if <> then end | Runs the blocks inside only when the condition is true. Otherwise skips them. |
if <> then else end | Runs one set of blocks when true and a different set when false. |
Deciding again and again
A decision made once, at the start, is almost never what you want. Here are two robots with the identical if-else, testing the identical sensor against the identical number — one inside a loop and one not.
decision inside a loop
forever
if distance < 15 then
stop moving
else · start moving
the same decision, once
if distance < 15 then
stop moving
else · start moving
247checks · in a loop1check · once only
Nothing is close, so both robots ask «is the wall within 15 cm?», both hear no, and both take the else branch and drive.
A decision is only worth as much as the last time it was made. Inside a loop, that is a few milliseconds ago.
Nothing is wrong with the right-hand program’s decision. It asked the question, got a truthful answer, and acted on it correctly. It simply never asked again, and the world moved on. Decisions belong inside a loop, so the robot keeps re-deciding as things change.
when program starts :: events hat
forever
if <([4 v] distance in [cm v] :: sensors) < (15)> then
stop moving :: movement
else
start moving [straight: 0] :: movement
end
endFour shapes, and how to choose
Once there is more than one question, decisions can be arranged in four ways. They look nearly identical stacked up in the editor, which is exactly why they get muddled — the thing that differs is not what the blocks say, it is which routes through them exist.
One question sorts them almost completely:
| Are the questions… | Use | How many bodies can run |
|---|---|---|
| independent — any combination can be true | separate ifs | none, some, or all |
| one question, two answers | if / else | exactly one |
| the second only matters when the first is true | nested if | one, and only via the outer |
| mutually exclusive cases — exactly one should win | chained if / else | exactly one, the first that matches |
Separate ifs — independent questions
Each if is asked no matter what the others answered, so any number of them can fire on the same pass. That is the right shape when the conditions genuinely have nothing to do with each other.
forever
if <[3 v] is ambient light intensity [< v] (20) %? :: sensors> then
[A v] start motor [clockwise v] :: motors
end
if <[4 v] is distance [< v] (15) [cm v]? :: sensors> then
[D v] start motor [clockwise v] :: motors
end
endif / else — one question, two answers
Exactly one branch runs, every time. Reach for this whenever the robot must do something either way — and in preference to two ifs testing opposite conditions, which is the same idea written twice and can drift apart.
Nested if — a follow-up question
Putting one if inside another means the inner question is only ever asked when the outer one is true. Use it when the second question is meaningless otherwise: there is no point asking which side an obstacle is on when there is no obstacle.
if <[4 v] is distance [< v] (15) [cm v]? :: sensors> then
if <([2 v] angle :: sensors) < (0)> then
start moving [right: 50] :: movement
end
endWhen not to nest. If you only want “both true” and nothing happens at the outer level, an and says it in one block and reads better:
if <<[4 v] is distance [< v] (15) [cm v]? :: sensors> and <([2 v] angle :: sensors) < (0)>> then start moving [right: 50] :: movement end
Nesting earns its place when something happens at the outer level too, or when there is an else at each level and the two mean different things.
Chained if / else — one winner out of several
This is the shape for a list of cases where exactly one should win: colour bands, distance bands, speed ranges. EV3 Classroom has no else-if block, so you build a chain by putting the next if inside the else of the last one.
And here is why it matters, because this is the single commonest bug in this whole module. Three bands written as three separate ifs are each perfectly correct, and together they are wrong: a reading of 20 is under 30 and under 60 and under 90, so all three run and the last one to run is the one that sticks.
three separate ifs
if light < 30 then
stop
if light < 60 then
go slowly
if light < 90 then
go fast
chained — if / else / if
if light < 30 then
stop
else
if light < 60 then
go slowly
else
go fast
↑ the rest is inside the else — never asked
3bands matchedgo fastseparate ifs dostopchained does
Separate ifs: 3 matched, last one winsChained: first match wins, rest never asked
The sensor reads 20 — a dark surface. Both programs should stop.
Separate ifs are not wrong here so much as unguarded: nothing stops a second one matching. Chaining is what makes “the first one wins” true.
The rule to carry away: if the cases are meant to be exclusive, they must be made exclusive. Chaining does it by construction. Separate ifs only work if you are careful to write non-overlapping bands yourself — light < 30, 30 to 60, 60 and over — which is more to get right and easy to break later.
Why it matters
This is the point at which a machine stops following a script and starts responding. A thermostat, an automatic door, a robot vacuum — all of them are a decision inside a loop.
Say this back before moving on: “The Gyro measures the model, not the motor.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Reads the Gyro many times a second and drives the motor from what it says. |
| Gyro Sensor | Must be mounted flat and firmly. It measures rotation about one axis only, so a sensor mounted on its side measures the wrong turn entirely. |
| Large Motor | Responds to the reading. This is the “linking” part — a sensor on one end of the stick and a movement on the other. |
| The stick itself (not electronic) | Has to be rigid. A Gyro on a bendy beam measures the beam flexing as well as the stick turning. |
Watch it drift before you trust it
- Put the model down and do not touch it. Open Port View or the sensor tile and watch the angle.
- Wait a full minute. Write down what it reads at the start and at the end. That difference is drift, and it is your model’s personality.
- Now turn the stick a quarter turn by hand and back again. Does it come back to where it started, or is there a little left over?
- Do not move the model while the program resets the Gyro. A reset taken mid-movement calibrates the sensor wrongly, and everything after it is out by that amount.
Ports — and the rule 4 min
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 |
|---|---|---|
| Gyro Sensor | 2 | Gyro is always port 2 in this course, in every lesson and every level. Touch 1, Gyro 2, Colour 3, Ultrasonic 4. |
| Large Motor | A | One job motor, driven by what the Gyro says. |
Check your own build now:
- Gyro in 2, motor in A.
- Check the Gyro is flat. Its measuring axis is marked on the case — turning the model about that axis is the turn it can feel, and any other turn it mostly cannot.
- Make sure the sensor cannot wobble on its mounting. A loose Gyro reports its own wobble as a turn.
- Set the model down on a still surface before running anything.
Connect the Brick 4 min
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.
How to connect the BrickUSB and Bluetooth, step by step, with a photograph of every screen. Open it if you have not done this before — or if pairing is not working.Show meHide
USB — the reliable one
- Switch the Brick on with the dark grey centre button.
- Cable into the Brick’s PC port — the small square socket beside the numbered ports, not one of the numbered ones.
- Other end into the computer.
Bluetooth — name it first
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.
- Name your Brick. On the Brick: Settings (the spanner) → Brick Name. Type something nobody else will pick, then press the tick. Every Brick is called
EV3until somebody changes it. - Turn Bluetooth on. Settings → Bluetooth. Tick Bluetooth and Visibility. Leave iPhone/iPad/iPod unticked.
- Connect from EV3 Classroom. Click the Brick icon at the top of the programming area, find your Brick by name, and click Connect.
- Say yes on the Brick. It asks “Connect?” with the computer’s name — choose the tick, then accept the passkey, which is already 1234.
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, because you will be waving this about. A cable on a stick you are turning by hand pulls on the model and the Gyro will feel every tug.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- A Gyro tile on 2 and a Motor tile on A. If the Gyro tile is missing, the program will read 0 for ever and look like a logic bug.
- Turn the whole model a quarter circle and watch the Gyro tile read about 90. Turn it back and watch it return to about 0.
- Turn it the other way and check it goes negative. Direction matters today, and this is where you find out which way is positive on your build.
Make it move 10 min
The stick reports its own angle, and the motor responds when you have turned far enough.
when program starts :: events hat
clear display :: display
[2 v] reset angle :: sensors
write [Sudut:] at line (1) :: display
forever
write ([2 v] angle) at line (2) :: display
if <[2 v] is angle [> v] (45) °?> then
write [PUSING] at line (4) :: display
[A v] set speed to (60) % :: motors
[A v] start motor [clockwise v] :: motors
else
write [DIAM ] at line (4) :: display
[A v] stop motor :: motors
end
end- reset angle — whichever way the stick is pointing when you press Play becomes zero. Hold it still for this.
- write the angle to line 2 — a live readout, so you can watch the number as you turn the stick.
- the Switch — asked continuously, exactly like the Dancing Crab, but the question is about the model’s own orientation rather than a button.
- start / stop rather than run for — because the motor has to be able to stop the instant you bring the stick back. Lesson 10 again.
What success looks like: hold the stick still and nothing happens. Turn it slowly and watch the number climb. As it passes 45 the motor starts; bring it back below 45 and the motor stops. The number on screen should match roughly what you can see with your eyes.
If the number runs away on its own, the model is not still, or something is vibrating it. If it reads backwards, your Gyro is mounted the other way up — either flip it or use a negative threshold, and say which you chose.
Change it and test 8 min
Hold the model still whenever the program resets, and check the reading against a real protractor at least once — a sensor you have never checked is a sensor you are trusting on faith.
- Change the threshold to 90. A quarter turn before it reacts. Check with a protractor or the corner of a book that 90 on the screen really is a right angle.
- Change the comparison to less than −45. Now it reacts to turning the other way, and does nothing at all in the direction it used to work.
- Use
andfrom Lesson 17 to make it react only between 45 and 90 — past 45 but not past 90. Turn slowly through the whole range and watch it switch on and then off again. - Take the
reset angleout. Run the program, stop it, turn the model a long way, and run it again. The threshold is now measured from wherever the model happened to be — which is exactly the bug the reset exists to prevent. - Leave the model completely still for two minutes with the program running and watch the number on line 2. Write down how far it drifted.
Step 5 is the one to remember. Nothing touched the model and the number changed anyway. That is not a fault in your build — it is what this kind of sensor does, and the answer is always the same: reset it immediately before you rely on it, and never build something that trusts a gyro reading taken ten minutes ago.
A gyro is exact over seconds and vague over minutes. Reset it often and it is the most useful sensor in the box.