Challenge 1
Run five laps, counting them, and stop honestly the moment a lap fails.
What you are building 3 min
The Ball Coaster: a track with a loop in it. A ball runs down, round the loop and along to the end — and a Large Motor lifts it back up to the top so it can go again.
An Ultrasonic Sensor watches the end of the track. When the ball arrives, the machine knows the run is finished and can start the next one.
By the end of the lesson the coaster will run laps on its own and stop itself sensibly when the ball gets stuck — because on a machine like this, the ball getting stuck is not a possibility. It is a certainty.
In the real world 5 min
Where you have seen it
A looping roller coaster hauls its train up a lift hill, lets go, and everything after that is gravity. No engine, no brakes until the end — the whole ride is paid for by the height of that first climb.
Why it is built that way
The lift hill is storing potential energy. Coming down, that turns into kinetic energy — speed — and the loop spends some of it climbing again. That is why the loop is always lower than the lift hill: some energy is lost to friction on the way, so the train can never climb back as high as it started.
Your ball obeys exactly the same rule. If the loop is too tall for the drop it will crawl round the top and fall off the track — and if you look closely at the real ones you will see the loop is not a circle. It is pinched at the top, so the train is turning tightest where it is going slowest.
What would go wrong without it
Now the part that matters today. Real coasters are divided into block sections, and the control system knows how long a train should take to clear each one. If a train has not cleared its block in time, the ride does not wait patiently — it stops every other train on the circuit and calls an engineer.
It has to. A control system that simply waited for the sensor would wait for ever, with a stopped train on the track and the next one still coming.
Waiting for something that will never come is the same as breaking, but quieter.
The main concept — a wait with a deadline 6 min
Here is the honest version of the program you would write first.
[4 v] wait until distance [< v] (10) [cm v] :: sensors
Then the Brick waits. The screen does not change, no error appears, nothing beeps. A program hanging on a sensor looks exactly like a program that is thinking. That is why it is such an unpleasant bug: there is nothing to see.
Give the wait two ways out
reset timer wait until <<([4 v] distance in [cm v] :: sensors) < (10)> or <(timer) > (8)>>
That is Lesson 31’s or, used for something new. There it was two players racing; here it is the job racing the clock.
And now the question Lesson 31 warned you about
or ended the wait and did not say which side ended it. The program knows something happened and nothing more. To behave sensibly it has to ask a second question — exactly as the Hand Speed game had to ask who pressed.
if <([4 v] distance in [cm v] :: sensors) < (10)> then change [pusingan v] by (1) else write [BOLA TERSANGKUT] at line (3) :: display stop [and exit program v] end
The rule that makes a timeout worth having
The two outcomes must lead to different behaviour. A timeout that falls through into the normal path has bought you nothing: the machine now lifts a ball that is not there, and does it for ever, and still nobody knows.
A good timeout names the failure. Yours writes it on the screen so a person walking past can see what happened without watching from the start.
How long should the deadline be?
| Deadline | What you get |
|---|---|
| Shorter than a good run | False alarms. A slow but successful lap is reported as a jam |
| A little longer than the slowest good run | Right. Time your own laps and add a margin |
| Much longer | Works, but the machine sits jammed for a long time first |
So a deadline is measured, not guessed — the same discipline as Lesson 37’s overshoot and Lesson 39’s ratio.
The Timer
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.
Blocks reference
| 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 timeout — a safety net
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
repeat until distance < 15
start moving straight: 0
with a timeout
reset timer
repeat until distance < 15 or timer > 5
start moving straight: 0
write GAVE UP at line 1
1.2stimer212cm · distance
Both robots are told to drive until something is within 15 cm. The room ahead is empty.
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.
Why it matters
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.
The Ultrasonic Sensor
The Ultrasonic Sensor measures distance. It sends out a burst of sound too high for people to hear, listens for the echo, and works out how far away the surface is from how long the echo took — exactly how a bat finds a moth, and how a submarine uses sonar.
front
sideBlocks reference
| Block | What it does |
|---|---|
([4 v] distance in [cm v] :: sensors) | Reports how far away the nearest thing in front of the sensor is, as a number in centimetres. |
wait until <([4 v] distance in [cm v] :: sensors) < (15)> | Holds the program until something comes closer than 15 cm. |
A number, not a yes or no
This is the important step up from the Touch Sensor. Touch gives you true or false; the Ultrasonic gives you a number, and the deciding is left to you. Pick a threshold below and watch where the robot ends up.
when program starts
start moving straight: 0
4 wait until distance < 15 cm
stop moving
60cm · reading15cm · threshold
Nothing is close. The sensor reports about 60 cm and the program waits.
The black line on the bar is the threshold; the blue fill is the reading. The robot stops the instant the fill crosses the line.
Three different robots, and only one number is different between them. That is what having a number rather than a yes-or-no buys you: the behaviour is tuned by editing one slot, not by rebuilding the program. It also means the sensor can never tell you it is “close” — close is a decision you make about a reading.
Why it matters
Car parking sensors, automatic doors at a shopping centre, and the sensor that stops a lift door closing on somebody all work this way. Reacting before contact is what makes a machine feel safe.
If your set has an Infrared Sensor instead
The Home/Retail EV3 set (31313) ships an Infrared Sensor and a Beacon in place of the Ultrasonic and Gyro sensors. The Infrared Sensor also measures distance, so the programs in this module work with it — but it reports a rough 0–100 proximity rather than real centimetres, and it is affected by sunlight and by dark surfaces in ways the Ultrasonic is not.
IR Sensor
BeaconEvery wait on the world needs a deadline, and every deadline needs a different thing to do when it runs out.
`or`, and the question it leaves behindFrom Lesson 31 — either side ends the wait; an `if` afterwards says which.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: “It arrived, or the time ran out. Find out which.”
What’s in this build 4 min
Look at your coaster. Only two parts are electronic — where is all the work being done?
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the machine and reports on it. Today its screen carries the lap count and, when things go wrong, the reason. |
| Large Motor — the lift | Raises the ball and tips it back onto the start. Large because lifting against gravity is exactly the job Large Motors are for. |
| Ultrasonic Sensor — the end detector | Aimed along the end of the track. It answers one question: is the ball here yet? |
| The loop (not electronic) | Where the runs fail. Its height must be comfortably less than the drop, or the ball will not carry enough speed round the top. |
| The track and joints (not electronic) | Every joint is a place a ball can catch. This is the part to check when timeouts start happening. |
Roll the ball by hand first — ten times
- Release the ball from the top by hand and time how long it takes to reach the end. Do it ten times.
- Write down the slowest of the ten. Your deadline goes a little above that number.
- Count how many of the ten got stuck. If none did, roll it ten more times — you need to know where it fails, because your program is about to depend on it.
- Check the sensor sees the ball at the end, and does not see the track when the ball is elsewhere.
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 |
|---|---|---|
| Lift (Large Motor) | A | One motor doing its own job. |
| End detector (Ultrasonic) | 4 | The Ultrasonic’s standing home, and the port that appears in both halves of the timeout. |
Check your own build now:
- Motor in A, sensor in 4.
- Cables clear of the track. A cable across the run is a jam waiting to be blamed on the program.
- The whole model on a flat, steady surface. A coaster on a wobbling table has a different loop every run.
- Start with the ball at the top, ready to go, and the lift at its lowest position.
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 away from the loop. The loop is the tightest part of the track and the place with least energy to spare. A cable resting anywhere near it will add exactly the jam you are trying to detect.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- A motor tile on A and an Ultrasonic tile on 4.
- Put the ball at the end and read tile 4. Take it away and read again. Those two numbers must be clearly different. If they are close, re-aim the sensor — a threshold between two similar numbers will fire at random.
- Turn the lift by hand and watch tile A move, so the motor port is confirmed before it runs.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
Five laps, counted — and an honest stop if the ball ever fails to arrive.
when program starts :: events hat
set [pusingan v] to (0)
clear display :: display
repeat (5)
[A v] run [clockwise v] for (1) [rotations v] at (50) % speed :: motors
reset timer
wait until <<([4 v] distance in [cm v] :: sensors) < (10)> or <(timer) > (8)>>
if <([4 v] distance in [cm v] :: sensors) < (10)> then
change [pusingan v] by (1)
write (pusingan) at line (1) :: display
else
write [TERSANGKUT] at line (3) :: display
play beep (45) for (1) seconds :: sound
stop [and exit program v]
end
end
play sound [Communication / Goodbye v] until done :: soundreset timerimmediately before the wait. The timer must measure this run, not the whole session. Put it outside the loop and every lap after the first times out.- The condition asks two completely different things — a distance and a clock — joined by
or. They have nothing in common except that either one ends the waiting. - The
ifre-reads the sensor. That is the only way to find out which side won, and it is why the sensor appears twice. - The failure branch is loud. A message, a low beep, and a full stop. Nobody has to be watching at the moment it happens to know what happened.
What success looks like: the lift raises the ball, the ball runs the loop and reaches the end, the screen counts 1, and it goes again. Five laps, then goodbye. Then catch the ball halfway on purpose — eight seconds later the Brick says TERSANGKUT and stops.
If it reports a jam on a lap that clearly worked, your deadline is shorter than a slow run — go back to your ten hand-timed laps. If it counts a lap without the ball arriving, the sensor is seeing the track.
Change it and test 8 min
One change at a time. You will need to jam the ball deliberately for several of these — a finger on the track is the easiest way.
- Take the
or (timer)out, leaving only the distance. Now hold the ball. The Brick waits, silently, for as long as you like. That silence is what a hang looks like. - Put the timeout back but delete the
elsebranch — let it fall through and carry on. Hold the ball and watch: the machine lifts nothing, counts nothing, and keeps going. A timeout with no consequence is theatre. - Set the deadline to 2 seconds. Now good laps get reported as jams. Too tight a deadline is its own bug, and a common one.
- Set it to 60. It still works — and you will get bored waiting to find out that something is broken.
- Replace
stop [and exit program]with a recovery: run the lift backwards half a rotation, then forwards again, and try the same lap once more. Some jams shake loose. Lesson 27’s bump-and-recover, in a new place. - Count the failures instead of stopping on the first:
change [gagal] by (1), and only stop whengagalreaches 3. A machine that gives up after one bad lap is annoying; one that never gives up is broken.
Steps 5 and 6 together are the grown-up answer. Detecting a failure, recovering from it, and giving up after enough recoveries are three different jobs — and a machine that does all three can be left running unattended, which is the whole reason anybody automates anything.
A program that cannot fail has not been tested. A program that cannot notice it failed cannot be trusted.