Challenge 1
Spin the top and toggle the plate five times, with the screen showing ATAS or BAWAH correctly every single time.
What you are building 3 min
The Transmitting Gyro: a spinning top held on a liftable plate. One motor spins the top up through a gear train; another raises and lowers the plate. One button controls the plate.
Raise the plate and the top spins in the air. Lower it and the top drops onto the table — still spinning, and it keeps spinning on its own for a surprisingly long time.
By the end of the lesson a single button will raise the plate on one press and lower it on the next — which sounds obvious, and is the first program in this course that has to remember something about itself.
In the real world 5 min
Where you have seen it
A gyroscope toy is a heavy wheel in a frame. Spin it up with a string, balance the frame on a fingertip, and it refuses to fall over. Every child who meets one tries to push it down, and it pushes back sideways.
Why it is built that way
A spinning wheel has angular momentum, and momentum resists being changed. Push on the axle of a spinning gyroscope and it does not tip the way you pushed — it swings round at right angles instead. That sideways swing is called precession, and it is why the toy walks in a slow circle rather than falling.
The heavier the rim and the faster it spins, the harder it is to shift. That is why your model gears the spinner up: a Medium Motor turning a small gear driving a large one gives away force to buy speed — the trade you met in Lesson 24, used here in the opposite direction.
Ships use this. A gyrocompass finds true north with no magnet at all, because a spinning wheel that is free to move keeps pointing where it was pointed while the Earth turns beneath it.
What would go wrong without it
Drop the top without spinning it and it falls over instantly. The spin is not decoration — it is the only thing holding the top upright, and the plate must not come down until the spinner has done its work.
Spin first, then release. The order is the trick, and a machine that forgets the order has no trick at all.
The main concept — the machine has to remember 6 min
You have one button and two jobs. Press it once, the plate should go up. Press it again, the plate should go down. The press is identical both times — so the difference cannot come from the press.
The cliff at the end of Level 1
Level 1 finished on the Mechanical Clamp, and it finished stuck. The clamp had no way to know whether its jaws were open or shut, so a single button could not close them and then open them. The lesson said plainly that the missing pieces were a Switch and a variable, and that both were coming.
You now have both. The Switch arrived in Lesson 13, the variable in Lesson 26. Put them together and the cliff disappears.
if <(naik) = (0)> then [D v] run [clockwise v] for (1) [rotations v] :: motors set [naik v] to (1) else [D v] run [counterclockwise v] for (1) [rotations v] :: motors set [naik v] to (0) end
Read it as three steps, in this order, and it will never confuse you again:
- Ask the variable which state you are in.
- Act — do the job for that state.
- Record the new state, immediately, in the same branch.
Step 3 is where every toggle goes wrong. Leave it out and the plate goes up on the first press and up again on the second, because the box still says 0. The machine did the right thing and then forgot it had.
A pen remembers without a variable
Click a ballpoint pen: out. Click again: in. Same click, opposite results — and there is no computer in there at all. Inside is a little cam and a rotating collar that physically holds which state the pen is in.
That cam is a memory made of plastic, and it is doing exactly the job your variable does. Your model has no cam, so the memory has to live in a number instead. Both are memory; only one can be changed without a screwdriver.
Why 0 and 1?
Nothing forces it. You could use 1 and 2, or 7 and 99. Zero and one are the convention because there are exactly two states, and because it makes a third trick possible later: a state you can flip with arithmetic rather than a Switch.
Variables
Why anybody needs one
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.
Abby never remembers the numberBen never sees a henThe wall holds it for both
Abby has a gate and a wall. Before a single hen comes through she chalks 0 on the wall — that is where the number is going to live.
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.
The paper, and the two things you can do to it
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.
score
0
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.
- change leaves a trail — every value follows from the one before it. This is what counting is.
- set wipes the sheet. Use it to start a count, never to continue one.
- Press set score to 0 after counting up a few times and watch the whole history vanish. That is what happens to a count when a set block ends up in the wrong place — and it is the commonest variable bug there is.
Blocks reference
| 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, or change?
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
when program starts
set count to 0
repeat 4
A run clockwise for 1 rotations
change count by 1
set inside it
repeat 4
set count to 0
A run clockwise for 1 rotations
change count by 1
Before the loop: counted 0Inside the loop: stuck at 0
Both programs count the turns of a motor. The left sets the count to zero before the loop; the right sets it inside.
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.
Anything oval is a number you can pick up
EV3 Classroom tells you what a block does by its shape, and once you have noticed that, a whole set of questions answers itself:
- Oval — reports a number. The blue degrees counted, the timer, a distance, your own variable.
- Pointed — reports true or false. These go in an if or a wait until, not in a variable.
- Block-shaped — does something. These stack up; they do not fit inside anything.
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
set degree_turn to A degrees countedkeep it in a variable of your own
A degrees counted + 10do arithmetic with it
A degrees counted > 50compare it with a number
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.
Reset at the start, every time
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.
Why it matters
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.
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.
Ask, act, record. A toggle that forgets to record is a button that only works once.
The SwitchFrom Lesson 13 and 14 — `if`, and `if/else`: two branches, one question.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 press is the same. The memory is what changed.”
What’s in this build 4 min
Look at your model. Two motors are doing completely different jobs — can you tell which is which by looking? One is geared for speed, the other for control.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and — today — is the only thing in the machine that knows whether the plate is up or down. |
| Medium Motor — the spinner | Drives the top through a gear train that gears up: small gear driving large, trading force for speed. Follow the gears with a finger and count the teeth. |
| Large Motor — the plate | Raises and lowers the plate the top sits on. It needs force, not speed — the opposite trade. |
| Touch Sensor — the control | One button, and the reason this lesson exists. There is no second button, and no “down” button. |
| The top and its axle (not electronic) | Heavy at the rim and light at the centre, which is what makes it hold its spin. A top with the weight near the middle stops almost at once. |
Check the plate travel by hand
- Raise and lower the plate by hand through its full range. Note roughly how far the motor has to turn — you will need that number.
- With the plate down, the top must sit on the table and spin freely. With it up, the top must clear the table completely.
- Leave the plate down before every run. The program will assume that, and a program that assumes something must be told where to start.
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 |
|---|---|---|
| Spinner motor | A | A motor with its own job. |
| Plate motor | D | A second motor with a separate job takes D, skipping B and C so nothing drives them as a pair. Same rule as Lesson 31. |
| Control button (Touch Sensor) | 1 | The Touch Sensor’s standing home. |
The manual agrees with every port on this page — “large motor D port, medium motor A port, button sensor port 1”. Build it from the manual and the programs below run unchanged. That is not true of every model in this level, so it is worth noticing when it is.
Check your own wiring now:
- Spinner in A, plate in D, button in 1.
- Get A and D the right way round. Swapped, the plate tries to spin at gear-up speed and the top barely moves — a spectacular and completely avoidable failure.
- Route the plate motor’s cable so it does not tighten when the plate lifts. Hinged parts eat cables.
- Keep everything clear of the table under the top. A spinning top that wanders into a cable stops dead.
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.
Keep the cable off the table under the plate. The top is released onto that surface and will travel across it as it precesses. A cable lying there is a wall.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Two motor tiles — A and D — and a Touch Sensor tile on 1.
- Turn the top by hand and watch tile A. Then move the plate by hand and watch tile D. If those two are swapped, fix the cables before you run anything.
- Press the button and confirm tile 1 changes and changes back. The toggle watches for both.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
Spin the top continuously, and let one button raise and lower the plate underneath it.
when program starts :: events hat
set [naik v] to (0)
clear display :: display
write [BAWAH] at line (1) :: display
[A v] start motor [clockwise v] :: motors
forever
[1 v] wait until [pressed v] :: sensors
[1 v] wait until [released v] :: sensors
if <(naik) = (0)> then
[D v] run [clockwise v] for (1) [rotations v] :: motors
set [naik v] to (1)
write [ATAS ] at line (1) :: display
else
[D v] run [counterclockwise v] for (1) [rotations v] :: motors
set [naik v] to (0)
write [BAWAH] at line (1) :: display
end
endset [naik] to (0)matches the plate being down. The program cannot see the plate, so the starting value is a promise you make — and step 5 told you to keep it.start motor, notrun for, on the spinner. It runs until stopped, so the top is still being driven while the plate moves. Lesson 7’s distinction, doing real work.- Press then release, before the Switch. Without the release wait the toggle flips many times per press and the plate judders.
- Each branch writes the screen. The state is now visible, which makes a wrong toggle obvious instead of mysterious. Note the space in
ATAS— it overwrites the longer word underneath.
What success looks like: the top spins up and keeps spinning. Press once: the plate lifts, the screen says ATAS. Press again: the plate lowers, the top touches down still spinning and walks slowly across the table. Press again and it lifts back off.
If the plate goes the same way twice, a set [naik] is missing from one branch — the machine acted and forgot. If it judders on a press, the release wait is missing.
Change it and test 8 min
One change at a time, and predict before each run. Two of these are meant to break.
- Delete
set [naik] to (1)from the first branch. Press twice. The plate goes up, then up again. Now you have seen a machine act correctly and fail to remember it. - Put it back and start the program with the plate already up. Everything is backwards for the whole run. The program is fine; the promise was broken.
- Replace the whole Switch with one line: set [naik v] to ((1) - (naik)), then run the plate motor at a speed of ((naik) * (100)) - (50). The toggle now flips by arithmetic. Harder to read — and this is why 0 and 1 are the conventional pair.
- Change the spinner to
run for (3) secondsinstead ofstart motor. The top now spins up and stops. Lower the plate ten seconds later. How much spin is left? - Time it properly. Lower the plate immediately, then after 5 seconds, then after 15. Time how long the top keeps spinning on the table in each case, and write the three numbers down.
- Add a second toggle on the centre Brick button that starts and stops the spinner. Two independent toggles, two variables — and now you must not reuse the name.
Step 5 is a real experiment with a real answer, and step 1 is the lesson. The machine did exactly what it was told, and it was still wrong, because being right the first time is not the same as knowing what you did.
A machine with no memory can only ever do one thing per button.
