Challenge 1
Make the ride change speed at a moment you chose. Pick a number of turns, work out the degrees, and have the ride step up exactly then. Watch the screen and check it happened at the count you predicted, not near it.
What you are building 3 min
The Swing Ride: chairs hanging on strings from a turning top. It spins, and as it spins the chairs swing outward and lift.
Every program you have written so far does the same thing every time you run it. It cannot do anything else — the blocks are in an order, and the order is the whole story.
Today a program makes up its own mind. The ride starts slowly, keeps an eye on how far it has turned, and speeds up on its own once it has been going long enough.
In the real world 5 min
Where you have seen it
The chair swing — the wave swinger — at every funfair and pasar malam. Riders sit in seats on chains, the top turns, and the seats fly out into a wide circle well above the ground.
Why it is built that way
The chairs fly outwards because anything moving in a circle is constantly being pulled towards the middle to keep it there — and the chains are what pull. The faster the top turns, the harder the chains have to pull, and the only way a chain can pull harder is by hanging at a wider angle. So the seats rise as the ride speeds up. Nothing lifts them; the angle is the lift.
Which is also why the operator starts slowly. Bring a swing ride up to full speed instantly and the chairs do not rise smoothly — they lurch outward and swing back, and the passengers are thrown about.
What would go wrong without it
A ride that runs at one speed from the moment it starts is a ride nobody wants to be on. The whole experience is the change: slow, then faster, then the seats lifting. And the operator does not stand there with a stopwatch — the ride knows where it is in its own cycle.
A machine that can only follow a list cannot react. A machine that can ask a question can.
The main concept — if this, then that 6 min
A Switch block is a C-shape with a hexagonal hole in its head. Blocks inside the C only run when whatever is in the hole is true.
if <([A v] degrees counted) > (1080)> then [A v] set speed to (55) % :: motors end
Three separate things are going on there, and it is worth naming all three:
| Piece | Shape | What it is |
|---|---|---|
| ([A v] degrees counted) | Rounded | A reporter — a number. You met it in Lesson 8. |
| <() > ()> | Hexagon | A condition — it is either true or false, never a number. Put a reporter in one side and a number in the other. |
| if <> then | C-shape | The Switch — runs what is inside it, but only if the hexagon is true. |
The shapes are the rules. A rounded block will not drop into a hexagonal hole, and that is the editor stopping you from asking a nonsense question. “If 1080 then” means nothing; “if the count is more than 1080 then” means something.
Checked once, or checked often?
A Switch tests once, at the moment the program reaches it. If the answer is false it skips the inside and moves on, and it will never look again.
So a decision that needs to be made repeatedly has to be inside a loop — which is why today’s program wraps the Switch in a repeat. The loop asks the question over and over; the Switch answers it each time.
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.
A Switch does not watch. It asks once, when you reach it — so put it somewhere you will reach it again.
Comparing numbersThe green operator blocks — greater than, less than, equals. Open it if the hexagons are new.Show meHide
Comparing and combining
A sensor that reports a number cannot be used to make a decision on its own — 23 is neither true nor false. An operator turns that number into an answer by comparing it with something.
Blocks reference
| Block | What it does |
|---|---|
<(x) > (50)> | True when the left value is bigger than the right. |
<(x) < (50)> | True when it is smaller. |
<<> and <>> | True only when both conditions are true. |
<<> or <>> | True when at least one of them is. |
Try it: which way round does it go?
Forget the symbols for a moment. A comparison is a question about position on a number line: is x to the left of the other number, or to the right? Left is smaller, right is bigger — and that is the whole of it.
Drag the orange x and the black marker, and change the comparison. The green stretch is every position of x that would make the answer true — so you can see where the answer flips before you get there. Turn not on and watch the green jump to the other side.
Drag either marker, or use the arrow keys.
-3 < 4true
is x to the LEFT of it?
- < is true while x sits on the left. Slide x past the marker and it flips.
- > is the same question the other way round — so exactly one of the two is true, unless the markers are on the same spot.
- = is true for one single position out of twenty-one. Try landing on it. That is why a sensor is almost never compared with =: a reading passes straight through the exact number without ever being measured there.
- not flips the answer, whatever it was. not (x < 4) covers everything x < 4 does not — including landing exactly on 4.
Try it: which numbers make it true?
The lab above asks one question at a time: is this x true? A robot never has just one x, though — a sensor reading slides up and down all the time, so what really matters is which stretch of the line makes the condition true. This one draws the whole answer at once.
Drag the circle to move the number you are comparing against, and change the comparison. Everything shaded green is a value of x that would make it true.
Drag the circle, or use the arrow keys. It moves in steps of 0.2.
x < 0.2x < 0.2
Every number to the left of 0.2 — but not 0.2 itself, so the circle is hollow.
Watch the circle, because it carries the part everyone gets wrong:
- Hollow ○ — the boundary is not included. x < 0.2 shades everything left of 0.2 but leaves 0.2 itself out, because 0.2 is not less than 0.2.
- Filled ● — the boundary is included. Choose = and nothing is shaded at all: one single number qualifies.
Now turn not on with x > 2 selected and watch two things happen together. The shading jumps to the other side, and the circle fills in — because “not greater than 2” means 2 or less, and 2 has to be part of it. That pairing is the whole reason a hollow circle is worth drawing.
Why a robot cares. Two conditions that look almost identical — light < 30 and not (light > 30) — differ by exactly one value, the reading of precisely 30. A robot sitting right on its threshold behaves differently under the two, and that is the sort of bug that only shows up occasionally and looks like a broken sensor.
Try it: and, or, not
These three join answers together rather than numbers. The trap is that English is looser than a program: “stop if it is close and the bumper is pressed” sounds like it covers both situations, when it covers neither on its own.
Flip the two conditions and watch the table. There are only four possible situations in total, and and and or differ on exactly two of them.
close: true and bumper: falsefalse
| close | bumper | and | or |
|---|---|---|---|
| true | true | true | true |
| true | false | false | true |
| false | true | false | true |
| false | false | false | false |
and is fussy: it wants both. Three of the four rows are false.
- and is true on one row out of four. It narrows — the robot acts less often, but more certainly.
- or is true on three rows out of four. It widens — the robot acts more readily.
- The two agree on the top and bottom rows and disagree in the middle. Whenever swapping one for the other seems to make no difference, you have only tried the rows where they agree.
Watch them decide
Two sensors are running below: an Ultrasonic reporting a number, and a Touch Sensor reporting true or false. Watch the comparison turn the number into an answer, and watch and and or disagree.
when program starts
forever
if distance < 15 and is pressed? then
stop moving
if distance < 15 or is pressed? then
play beep 60 for 0.2 seconds
Nothing is within 15 cm and the bumper is out. Both conditions are false.
and was true in one row out of four. or was true in three. That is the whole difference, and it is why one of them makes a robot look broken.
The comparison is doing one job: it takes a reading that is neither true nor false and, by holding it against a number you chose, produces something a decision can use. The moment the blue fill crosses the black marker is the moment the answer changes.
Choosing the threshold
The number you compare against is a design decision, not a fact. “Close” for a parking sensor might be 15 cm; for a robot arm it might be 3. Pick it by measuring what the sensor actually reads in the situation you care about, then leave a margin.
Combining two conditions
and narrows: both must hold, so the robot acts less often but more certainly — stop only if something is close and the bumper is pressed. or widens: either will do, so the robot acts more readily — stop if something is close or the bumper is pressed.
In the four situations above, and was true in one of them and or in three. That is the practical difference: swapping one for the other does not adjust a robot slightly, it changes how often it reacts at all.
Say this back before moving on: “The hexagon is a question, not a number.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Asks the question a few times a second and acts on the answer. This is the first lesson where the Brick is deciding rather than obeying. |
| Medium Motor — the top | Turns the ride. Its own encoder is where the condition’s number comes from, so it is both the thing being controlled and the thing being measured. |
| The chairs and strings (not electronic) | Free to swing outward. If they catch on anything the ride will never lift, however fast it turns. |
| The Brick screen and speaker | Report the turn count and announce the change of speed, so you can see the decision being made rather than guessing. |
Check the swing before you check the program
- Spin the top by hand, fast, and let it go. Do all the chairs fly out evenly, or does one hang back?
- A chair that catches is usually a string wound the wrong way round its anchor. Untwist it now.
- Check nothing on the base is in the chairs’ way at full swing — including the cable.
- Hold the model down or weight it. A spinning ride on a light base walks across the table.
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 |
|---|---|---|
| Ride motor | A | One job motor — and today its port appears in three places: the start, the speed change, and inside the condition. |
| Sensors | none | The question is answered from the motor’s own counter, which arrives down the motor cable. No sensor needed to make a decision. |
Check your own build now:
- Find the motor that actually turns the top and put it in A. This model is built from a video rather than a manual, so check rather than assume.
- Whichever port you use, it must be the same port inside the reporter. A condition reading a motor that is not turning is a condition that never becomes true.
- Route the cable clear of the swinging chairs.
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 suits this one. You will be watching the Brick screen count while the ride turns, so the Brick wants to be where you can read it.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- One motor tile on A.
- Turn the ride by hand and watch the degrees climb. Turn it three full times and check you reach about 1080 — that is the exact number your condition is about to test.
- If the number goes down rather than up when you turn it the way the ride runs, your condition will never fire. Either turn the model the other way or use a negative threshold.
Make it move 10 min
The ride starts gently, watches its own turn count, and steps up to full speed once it has done three turns.
when program starts :: events hat
clear display :: display
[A v] reset degrees counted :: motors
write [SWING RIDE] at line (1) :: display
[A v] start motor at (20) % speed :: motors
repeat (24)
write ([A v] degrees counted) at line (3) :: display
if <([A v] degrees counted) > (1080)> then
[A v] set speed to (55) % :: motors
write [LAJU] at line (5) :: display
end
wait (0.25) seconds
end
[A v] stop motor :: motors
write [TAMAT] at line (7) :: display- reset degrees counted — so 1080 means three turns of this ride, not three turns since the Brick was switched on.
- start motor at 20% — non-waiting, from Lesson 7. The ride turns for the whole loop without being mentioned again.
- the loop — twenty-four passes at a quarter-second each, so about six seconds of ride. The loop exists purely so the question gets asked repeatedly.
- the Switch — false for the first few seconds, so it is skipped. Once the count passes 1080 it becomes true and stays true, and the speed is set to 55 on every remaining pass.
What success looks like: the ride turns slowly with the chairs hanging almost straight down, the number on screen climbs, and then — with nothing changing on the outside — it visibly speeds up and the chairs fly out. Nobody pressed anything.
If it never speeds up, either the count is going backwards or the ride is too slow to reach 1080 in twenty-four passes. Read the number on screen at the end: if it stopped at 700, your threshold is simply higher than the ride ever gets.
Change it and test 8 min
One change at a time. Watch the number on the screen at the moment the ride changes — that is the decision happening.
- Change the threshold to 360. One turn. It should speed up almost immediately.
- Change it to 100000. The condition is never true, so the Switch is skipped every single pass and the ride stays slow. A Switch that never fires is not broken — it is answering honestly.
- Put it back to 1080 and add
play beep (60) for (0.1) secondsinside the if, under the speed change. Run it and listen to what happens after the threshold is passed. - Now move that beep outside the Switch but still inside the loop. Compare — one beeps only after the change, the other beeps throughout.
- Move the whole Switch outside the loop, below it. Run it. The ride never changes speed while it is running, because the question is now only asked once, after everything is over.
Step 3 is the discovery. The beep does not sound once — it sounds on every remaining pass of the loop, because the condition stays true once the count is past 1080. The Switch is doing exactly what you asked, and what you asked was not what you meant. Remember it; it is one of the commonest bugs there is.
A condition that becomes true usually stays true. If you want something to happen once, that is a different question.
