Challenge 1
Build a routine with a beat you can clap along to. Eight bars, a beep on every downbeat, and a move that changes within each bar. If a person can clap it, it has a rhythm.
What you are building 3 min
The Dancing Robot: two Large Motors driving the legs and a Medium Motor swinging the arms, with the Brick calling out the moves.
The last two lessons both made one decision. The swing ride sped up and stayed fast; the pterosaur started gliding and kept gliding. Once the answer changed, it never changed back.
A dance is not like that. A dance is a decision taken over and over — this move, now that one, now back to the first — and today you build a condition that can answer differently every few seconds.
In the real world 5 min
Where you have seen it
Street dance at a festival, a line of dancers moving together, changing figure on a count that everybody in the line is keeping in their head. Nobody is calling out instructions — they all know the pattern and they all know where they are in it.
Why it is built that way
Dance is built on counts. Eight beats of one figure, eight of the next, and back again. The count is what lets forty people change at the same instant without anyone shouting — each dancer is asking themselves the same question on every beat: where am I in the eight?
And crucially the count resets. It runs one to eight and starts again, which is what makes a dance repeat rather than wander off.
What would go wrong without it
A count that only went up would give you a performance that changed once and then did the same thing for ever. That is a machine, not a dance. Everything that has a rhythm — music, walking, breathing, a heartbeat — depends on something coming back round to the start.
A question worth asking repeatedly is one whose answer can change back.
The main concept — a number that comes back down 6 min
Every condition you have written so far was built on a motor’s degree count, and a degree count only ever climbs. That is why your machines changed once.
(timer) :: sensors reset timer :: sensors
The timer climbs like anything else. What makes it different is that you can reset it whenever you like, and a value you can send back to zero is a value a condition can answer both ways about, over and over.
repeat (8)
reset timer :: sensors
repeat until <(timer) > (2)>
if <(timer) < (1)> then
write [KIRI ] at line (3) :: display
else
write [KANAN] at line (3) :: display
end
end
endFollow the timer rather than the blocks. It is reset to 0, climbs past 1 — so the answer flips from the top branch to the bottom — and then past 2, which ends the inner loop and sends it back to the reset. That is a cycle, and a cycle is what a rhythm is.
| Value | Goes up | Comes back down | So a condition on it… |
|---|---|---|---|
| degrees counted | Yes | Only if you reset it, or drive the motor backwards. | Flips once and stays. Good for a stage of a task. |
| timer | Yes | Yes — whenever you reset it. | Can flip back and forth for ever. Good for a rhythm. |
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.
If you want a machine to keep changing its mind, give it something that keeps changing.
Loops inside loopsThis program has a repeat inside a repeat-until. Open it if the nesting is hard to read.Show meHide
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.
Say this back before moving on: “Reset the timer and the answer can change back.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Keeps the count and calls the moves. The timer it is reading is inside the Brick, not in any motor. |
| Large Motor ×2 — the legs | Ports B and C, driven as a pair. Equal speeds step in place; opposite speeds spin — both of which are dance moves. |
| Medium Motor — the arms | Runs on its own, at its own speed, using the non-waiting start from Lesson 7. The arms keep going while the legs change figure. |
| The Brick screen and speaker | Call the move and keep the beat, so an audience can hear the count the robot is dancing to. |
Give it room, and check it stays up
- Stand the robot up and let go. It should stay standing without being held.
- Push it gently at shoulder height. If it topples easily, the base is too light or the Brick is too high — a dancing robot spends the whole lesson being unbalanced on purpose.
- Turn the arms by hand through a full circle and check they clear the head and the body.
- Clear a circle of floor about half a metre across. It steps and it spins.
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 |
|---|---|---|
| Left leg (Large) | B | B is left, and the Movement blocks assume it. |
| Right leg (Large) | C | C is right. |
| Arms (Medium) | A | Off the movement pair, so the arms can run at their own speed while the legs are being driven as a pair. |
Check your own build now:
- Standing behind the robot, left leg in B, right in C, arms in A.
- Route the arm cable so it cannot wrap when the arms go round and round.
- Check the leg cables are long enough for the robot to spin without tugging.
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 spins on the spot repeatedly, and a cable will be wound round its legs within about two bars.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Three motor tiles — Large on B and C, Medium on A.
- Turn the left leg and check tile B; the right and C. A swapped pair mirrors every spin.
- Turn the arms and check tile A.
Make it move 10 min
Eight bars of a two-move routine: step left, step right, arms going the whole time.
when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
clear display :: display
write [MENARI] at line (1) :: display
[A v] start motor at (60) % speed :: motors
repeat (8)
reset timer :: sensors
play beep (70) for (0.1) seconds :: sound
repeat until <(timer) > (2)>
if <(timer) < (1)> then
write [KIRI ] at line (3) :: display
start moving at (30) (-30) % speed :: movement
else
write [KANAN] at line (3) :: display
start moving at (-30) (30) % speed :: movement
end
end
end
stop moving :: movement
[A v] stop motor :: motors
write [TAMAT] at line (5) :: display- start motor at 60% on the arms — once, before everything. They run for the whole dance without appearing again until the end.
- reset timer, then beep — the top of each bar. The beep is the downbeat and the reset is what makes it a bar rather than a moment.
- repeat until timer > 2 — the bar lasts two seconds. Inside it, the Switch is asked as fast as the Brick can manage.
- the Switch — under one second, spin one way; over one, spin the other. The same block gives both moves.
What success looks like: a beep every two seconds, and between beeps the robot turns one way then the other, with the arms swinging continuously. The screen alternates KIRI and KANAN in time with the movement.
If it only ever goes one way, the timer is not being reset — check the reset timer is inside the outer repeat (8) and not above it. Reset once and the timer is past 2 for ever after the first bar.
Change it and test 8 min
Change one number at a time and clap along with the beeps — if you can clap it, it has a rhythm.
- Change the bar to 1 second and the switch point to 0.5. Twice the tempo. Does it still read as a dance or just as twitching?
- Keep the 2-second bar but move the switch point to 1.5. Now one move lasts three times as long as the other — an uneven rhythm, and a much more interesting one.
- Move the
reset timerabove therepeat (8). Run it and watch the dance stop after one bar. Then explain in one sentence why. - Change the arms to 15% while leaving the legs alone. Two speeds, one machine — Lesson 7 again, now inside a dance.
- Add a second beep, a different note, just after the else. Now you can hear the moment the decision changes as well as see it.
Step 3 is the lesson in one change. Move the reset out of the loop and the value stops coming back down — and the moment it stops coming back down, the Switch answers the same way for ever and you are back to Lesson 14.
The reset is not tidying up. The reset is what makes it a rhythm.