Challenge 1
Show that a wait blinds the stack. Take your working gait and put a wait of one second in the loop. Now put your hand in front of the head and time how long it takes to stop. Take it out and time it again. Report both numbers.
What you are building 3 min
The Gorilla: a knuckle-walker that moves on two legs and two arms together, with an Ultrasonic Sensor in its head watching where it is going.
A walk is a sequence of phases with durations — swing, plant, push, shift. You could write those with wait blocks, and then the gorilla walks beautifully into a wall, because a stack that is waiting is not looking.
By the end of the lesson your gorilla will time every phase of its gait without a single wait block — and it will be able to stop mid-stride, because it never stopped watching.
In the real world 5 min
Where you have seen it
A gorilla knuckle-walks: weight on the front of the hands, on the middle bones of the fingers, with the arms taking roughly a third of the load. It is a proper four-limbed gait with a repeating rhythm, and it lets a large animal move efficiently while keeping its head up.
Head up is the detail worth noticing. The gait is rhythmic and timed, and the animal is watching the whole way through it — the timing never costs it its attention.
Why it is built that way
An animal that stopped sensing while it completed a stride would be an easy meal. Nervous systems run the rhythm and the watching in parallel, and a danger signal can interrupt a stride half-way through.
That is exactly what a wait block cannot do. A wait is a promise to do nothing at all for a fixed period, and things you would want to notice do not agree to happen outside it.
What would go wrong without it
Consider your basketball robot in the last lesson. Its one-second settle was correct — and if somebody had walked in front of the hoop during it, the robot would have shot anyway, because for that second it was not capable of noticing anything.
Time your actions by watching the clock, not by closing your eyes and counting.
The main concept — timing without waiting 6 min
A wait block does not pause time. It pauses the stack it is in, and everything that stack was responsible for. The alternative is to note when something started and keep checking whether long enough has passed.
when program starts :: events hat forever [A v] run [clockwise v] for (90) [degrees v] at (50) % speed :: motors wait (1) seconds :: control [A v] run [counterclockwise v] for (90) [degrees v] at (50) % speed :: motors wait (1) seconds :: control end
when program starts :: events hat
reset timer :: control
set [phase started v] to (timer) :: variables
set [phase v] to (1) :: variables
forever
// this runs hundreds of times a second, whatever the gait is doing
set [gap v] to ([4 v] distance in cm) :: variables
if <((timer) - (phase started)) > (1)> then
change [phase v] by (1) :: variables
if <(phase) > (2)> then
set [phase v] to (1) :: variables
end
set [phase started v] to (timer) :: variables
end
endThe pattern, in three lines
- When a phase begins, write down the time:
set phase started to timer. - Every pass, ask how long it has been:
timer − phase started. - When that exceeds the phase’s duration, move to the next phase and write the time down again.
Forgetting step 3’s reset is the classic bug. If phase started is never updated, the elapsed time keeps growing and every phase after the first ends instantly — the gorilla flickers through its whole gait in one pass and looks like it is vibrating.
When each is right
| Use | When | Example from this course |
|---|---|---|
wait | Nothing needs watching, and nothing else is running that matters. | The debounce in Lesson 21 — a tenth of a second, blind, harmless. |
| Elapsed time | Something must keep being sensed, or another job shares the stack. | A gait that must stop for an obstacle. The settle in Lesson 22, if you wanted it interruptible. |
A parallel stack is not always the answer either. You could put the watching in its own stack and keep the waits — and sometimes that is right. But the two stacks then have to agree about when to abandon a stride, which is a shared-state problem (Lesson 11) you did not have before. One loop that never blinks is usually simpler.
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.
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.
Repeating
Machines repeat. A wiper sweeps, a conveyor runs, a ride goes round — and none of that should mean copying the same blocks over and over. A loop says “do this again” once.
Blocks reference
| Block | What it does |
|---|---|
repeat (10) end | Runs the blocks inside a set number of times, then carries on below. |
forever end | Runs the blocks inside over and over, and never carries on below. |
repeat until <> end | Repeats until a condition becomes true — a loop with a sensor as its exit. |
Forever really does mean forever
Anything placed after a forever loop will never run. Not “runs late” — never. Both programs below end with the same block: set the status light green.
repeat (3)
repeat 3
A run clockwise for 0.25 rotations
set status light to green
forever
forever
A run clockwise for 0.25 rotations
set status light to green
↑ this block never runs
0passes · repeat (3)0passes · forever
repeat (3): still goingforever: light never set
Both loops begin. Each pass turns the motor a quarter turn.
Both programs contain the same green-light block. Let it run as long as you like — the right-hand ring will never turn green.
The repeat loop counts its three passes, stops, and moves on to the block underneath, so its light turns green. The forever loop reaches the bottom of its own blocks and jumps straight back to the top, so the block underneath is never reached — however long you leave it. If a program seems to stop half way through, look for a forever loop above the blocks that are not happening.
Why a sensor program needs a loop at all
A program is a list, and the Brick works down it once. Every block runs, in order, and when the last one is done the program is over. That is fine for a list of instructions — drive, turn, beep, stop — because each is a thing you do once.
A sensor is not a thing you do once. Asking is 1 pressed? gives you an answer about this instant, and an instant later it may be wrong. Checking a sensor once tells you what the world was like at the moment the program started — which is almost never what you wanted to know.
So a program that has to react must ask again, and again, for as long as it is running. That is the whole job of the loop: not to repeat an action, but to keep the question being asked.
Read, decide, act — and then do it again
Wrap a sensor check and the motor it controls in a forever loop and you have built a closed-loop control system — the pattern behind every line follower, thermostat and cruise control:
- Read the sensor.
- Decide what that reading means.
- Act on the motors.
- Go back to 1 — immediately, thousands of times a minute.
It is called closed because the output feeds back round to the input: the motors move the robot, moving the robot changes what the sensor sees, and what the sensor sees changes the motors. Break the circle at any point and the robot stops responding.
when program starts :: events hat
forever
if <[1 v] is pressed? :: sensors> then
[A v] start motor [clockwise v] :: motors
else
[A v] stop motor :: motors
end
endRead it as a sentence and it is almost too simple to need explaining: for ever, if the button is pressed run the motor, otherwise stop it. The motor now follows the button for as long as the program is running.
The same program without the loop
This is the mistake nearly everybody makes first, and it is a hard one to spot because nothing about it looks wrong:
when program starts :: events hat if <[1 v] is pressed? :: sensors> then [A v] start motor [clockwise v] :: motors else [A v] stop motor :: motors end
The logic is perfect. The ports are right. Nothing is misspelled. And the robot will ignore the button completely — because the Brick reaches that if/else a few milliseconds after you press Run, finds the button not pressed, takes the else branch, stops the motor, runs out of blocks and ends. By the time a finger arrives, there is no program left to notice it.
with forever — a closed loop
when program starts
forever
if 1 is pressed? then
A start motor clockwise
else
A stop motor
without it — the common mistake
when program starts
if 1 is pressed? then
A start motor clockwise
else
A stop motor
↑ running — for the only time
40checks · with forever1checks · no loop
Looped: motor off, matching the buttonNo loop: motor off for ever, whatever you press
Both programs start. The button is not pressed, so both take the else branch and leave the motor off. So far they agree exactly.
Both programs contain exactly the same if/else. The only difference is the forever block around one of them.
Both programs contain exactly the same if/else. The counter is what gives it away: one keeps checking for as long as it runs, the other is stuck on the single check it made before anybody touched anything. A student who has seen this once stops writing it.
The tell on a real robot is a program that ends the instant you start it — the Brick returns to its menu almost immediately. If a sensor program finishes rather than waits, the loop is what is missing.
Choosing the right loop
- Known number of times — repeat (n). A wiper that sweeps five times.
- Until something happens — repeat until. Drive until the wall is close.
- For as long as the machine is on — forever. A fan, a ride, a monitor.
Note the start, check the difference, reset when you move on. Never close your eyes to count.
The timerFrom Level 2, Lesson 40 — elapsed seconds since the last reset. Today it becomes a condition rather than a readout.Show meHide
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.
Say this back before moving on: “How long has this phase been going?”
What’s in this build 4 min
Work the gorilla through one full stride by hand and count the distinct phases. However many you find is how many your program will have.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The torso, and the weight that has to be shifted from side to side. Its screen shows the current phase and its elapsed time — the instrument for everything today. |
| Large Motor ×2 — the legs | Drive the walking linkage. They must be in step; a gorilla whose legs drift out of phase turns instead of walking. |
| Medium Motor — the arms | Swings the arms, which carry real load in a knuckle-walk. Their timing relative to the legs is what makes the gait look right. |
| Ultrasonic Sensor — the head | Watches ahead throughout the gait. It is the reason the timing cannot block. |
| The limb linkages (not electronic) | Work every joint by hand. Anything stiff makes one phase take longer than its allotted time, and a phase that overruns its clock is a gait that falls apart. |
Time one stride with a stopwatch before you program. Push the gorilla through a full cycle by hand at a natural pace and note how long each phase wants to take. Those numbers are your phase durations, and guessing them costs far more time than measuring them.
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 |
|---|---|---|
| Arms (Medium) | A | The detail motor, first port. |
| Left leg (Large) | B | The movement pair. |
| Right leg (Large) | C | The other half. |
| Eyes (Ultrasonic) | 4 | Ultrasonic stays on 4 across the course. |
Check your own build now:
- Arms in A, legs in B and C, sensor in 4.
- Set the limbs to their start positions by hand before every run — legs together, arms forward. A gait started mid-stride never recovers.
- Stand it on a hard, flat floor. Carpet stalls the legs and stretches every phase past its clock.
- Give the head cable slack — it swings with the body through the whole gait.
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 — this one walks and it walks slowly. A cable dragging behind a knuckle-walker adds a load that varies through the stride, which will make some phases overrun their timing and not others.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Three motor tiles — A, B and C.
- One sensor tile — 4.
- Time one full stride by hand and write down each phase’s duration. Four numbers, in seconds. They go straight into the program, and they are the difference between a gait that works first time and an afternoon of guessing.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
Write the blocking version first and try to make it stop for an obstacle. You will not be able to, and that is the point.
Step 1 — a gait with waits, and why it will not do
when program starts :: events hat set movement motors to [B v] and [C v] :: movement forever start moving [forward v] at (30) % speed :: movement [A v] run [clockwise v] for (90) [degrees v] at (40) % speed :: motors wait (1) seconds :: control [A v] run [counterclockwise v] for (90) [degrees v] at (40) % speed :: motors wait (1) seconds :: control end
wait.Step 2 — the same gait, timed without blocking
when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
reset timer :: control
set [phase v] to (1) :: variables
set [phase started v] to (timer) :: variables
set [walking v] to (1) :: variables
clear display :: display
forever
// ---- ALWAYS, every pass, whatever the gait is doing ----
set [gap v] to ([4 v] distance in cm) :: variables
set [elapsed v] to ((timer) - (phase started)) :: variables
write (phase) at line (1) :: display
write (elapsed) at line (3) :: display
write (gap) at line (5) :: display
if <(gap) < (20)> then
set [walking v] to (0) :: variables
stop moving :: movement
[A v] stop motor :: motors
set status light to [red v] :: display
end
if <(gap) > (30)> then
set [walking v] to (1) :: variables
set status light to [green v] :: display
end
// ---- the gait, only while walking ----
if <(walking) = (1)> then
start moving [forward v] at (30) % speed :: movement
if <(phase) = (1)> then
[A v] start motor at (40) % speed :: motors
if <(elapsed) > (1)> then
change [phase v] by (1) :: variables
set [phase started v] to (timer) :: variables
end
end
if <(phase) = (2)> then
[A v] start motor at (-40) % speed :: motors
if <(elapsed) > (1)> then
set [phase v] to (1) :: variables
set [phase started v] to (timer) :: variables
end
end
end
endelapsedis computed once at the top and used everywhere below, so every test in one pass agrees about what time it is. Lesson 11’s habit, applied to the clock.- Every phase change resets
phase started. Miss one and that phase and all the ones after it end instantly. - The obstacle check is outside the gait. It runs whatever phase is current — that is the entire difference from step 1.
- Stop at 20 and resume at 30 — hysteresis from Lesson 10, so the gorilla does not judder at the boundary.
What success looks like: a steady walking rhythm with the phase number alternating on screen, and a gorilla that freezes the moment your hand appears — including part-way through a stride — and carries on when you take it away.
If the phase number races, you are not resetting phase started when the phase changes. If it never changes, you reset it every pass rather than only on the change — look at where that line sits.
Change it and test 8 min
One change at a time. Predict, then run, then look.
- Change one phase duration to 0.4 seconds and leave the other at 1. The gait becomes lopsided — and you have just discovered that phases need not be equal, which is how a real gait is built.
- Delete one
set phase started to timer. Predict what the phase number does, then watch it. This is the bug, caused deliberately so you recognise it later. - Add two more phases so a stride has four. Time them by hand first, then put your measured numbers in.
- Put the obstacle check back inside the walking branch. It still works — until you stop, at which point it can never resume, because the check no longer runs. A rule about when to restart must live outside the thing it restarts.
- Add a wait of 0.05 seconds at the top of the loop and watch the phase timing stay correct while the responsiveness drops. Elapsed-time logic survives a slower loop;
wait-based logic would not.
If a machine must notice something while it is timing something, it cannot use a wait block at all.
Where this goes 3 min
Your gorilla runs two motors on a shared clock, and the relationship between them is what makes the gait look like walking rather than twitching.
The last model of this set takes that idea to its conclusion. An egg-drawing machine has two motors turning at once, and the ratio between their speeds decides what shape appears. Change the ratio and you get a different pattern from the same program.
Two motors moving together are not two movements. They are one movement in two dimensions — which is how a plotter, a lathe and every CNC machine in the world works.
Today two motors shared a clock. Next they share a shape.