Challenge 1
Ten strikes, evenly spaced, then stop. Somebody listening from across the room should be able to count them without watching, and the machine must stop on its own with the hammer down. No forever loops.
What you are building 3 min
The Hammer Bot: a motor turns a lumpy wheel called a cam, the cam lifts a hammer, the hammer falls. Over and over, at whatever rhythm you decide.
Look at what the motor is being asked to do. It can only spin. The hammer needs to go up and down. Nothing in a motor does up and down — and yet the hammer does, because of one oddly-shaped piece of plastic between them.
Your job today is to control the two halves of that spin separately: the half that lifts, and the half that lets go.
In the real world 5 min
Where you have seen it
There is a cam in every petrol engine, and there are a lot of them. The camshaft is a bar with lumps along it, spinning beside the engine, and each lump pushes a valve open at exactly the right moment before letting it snap shut again.
Why it is built that way
An engine has one thing spinning — the crankshaft — and a dozen things that need to move up and down in a strict order. A camshaft solves all of them at once. Every lobe is cut at a different angle around the shaft, so each valve opens at its own moment in the cycle.
That is why an engine is described in degrees. A mechanic does not say a valve opens “a bit before the top”; they say it opens at 12 degrees before top dead centre. The shape of the lobe decides how far the valve lifts, and its angle on the shaft decides when.
What would go wrong without it
Get a camshaft a few degrees out of line and the engine either runs badly or destroys itself — a valve still open when the piston comes up gets hit by it. Whole engines are ruined by an angle being wrong by less than the width of a tooth.
A cam turns “going round” into “going up and down”, and the angle is when.
The main concept — one turn, two jobs 6 min
The cam does not do the same thing all the way round. For roughly half a revolution it is lifting the hammer. For the other half the hammer is coming back down.
| Where the cam is | What the hammer is doing | What you want the motor to do |
|---|---|---|
| 0° → 180° | Being lifted, against its own weight. | Go slowly. This is the hard half, and rushing it makes the model jump. |
| 180° → 360° | Falling, under gravity. | Get out of the way fast. The faster the cam clears, the harder the hammer lands. |
Two halves, two different speeds. To write that, you need to be able to say “half a turn” — and the unit for part of a turn is degrees.
[A v] run for (180) [degrees v] at (30) % speed :: motors [A v] run for (180) [degrees v] at (100) % speed :: motors
The number line you need
| Degrees | Fraction of a turn | Looks like |
|---|---|---|
| 90 | a quarter | A right angle — pointing up, then pointing right. |
| 180 | a half | Straight up to straight down. Today’s number. |
| 270 | three quarters | All the way round bar a quarter. |
| 360 | the whole thing | Exactly one rotation — the same as 1 in the other unit. |
You could write 0.5 rotations instead of 180 degrees and the motor would do the same thing. Write degrees anyway. Angles are how mechanisms are described — by the person who designed the cam, by the mechanic setting the valves, and in every lesson from here to Level 4.
Moving to an exact angle
Everything so far has been relative: move 90 degrees from wherever you are now. Sometimes what you actually want is absolute: go to the 90-degree position, whatever position you happen to be in at the moment.
Relative drifts, absolute does not
Both pointers below do the same job over and over: swing out a quarter turn, then come home. The only difference is the block that brings them back. Watch one trip and they look identical — so let it run for several.
relative — by an amount
A run clockwise for 90 degrees
A run counterclockwise for 90 degrees
absolute — to a place
A run clockwise for 90 degrees
A run to position 0
0°relative, off home0°absolute, off home1trip
Relative: 0° from home and growingAbsolute: home, exactly
Both pointers are at home, on the black mark.
Let it loop. Nothing about the left program is wrong — it is just that every trip starts from wherever the last one finished, so a small error is never corrected, only added to.
A pointer moved relatively slowly wanders: each movement starts from wherever the last one finished, so any small error is carried forward and added to. Each orange dash is a trip that called a slightly different place “home”. Nothing about that program is wrong — it is simply that a relative move has no idea where it is supposed to end up.
An absolute movement has no memory of the error. Told to go to position 0, it goes to position 0 — the same place every time, however wrong it was beforehand. That makes it the right tool for a home position: the known place a mechanism returns to before it starts work.
Every motor knows where it is
This is possible because an EV3 motor counts its own turning all the time. Its position can be read back, and can be reset to zero — which is how you tell the motor that here is what you mean by zero, usually at the start of a program with the mechanism held at its resting place.
Why it matters
A clock hand returns to twelve; a car’s steering returns to centre; a 3D printer homes its head before every print. All of them go to a position rather than moving by an amount.
Rotations for how far it travels. Degrees for what position it ends up in.
Repeating a fixed number of timesThe counted loop — ten strikes, not 'strike until someone stops it'. Open it if repeat is rusty.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: “360 degrees is one whole turn.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Counts the cam’s angle. It is also the heaviest thing on the model, and it is what stops the whole bot hopping across the desk when the hammer lands. |
| Large Motor — the cam | Turns the cam. It only ever spins one way; every up-and-down in this model is the cam’s shape, not the motor changing its mind. |
| The cam (not electronic) | The off-centre wheel or peg. Its shape decides how high the hammer lifts; the motor only decides how fast. |
| The hammer arm (not electronic) | Falls under its own weight. Nothing drives it down — which is why a heavier head hits harder. |
Find the two halves by hand
Before you write anything, turn the cam slowly with your fingers and watch the hammer.
- Turn until the hammer is at its lowest. This is your 0°. Mark the cam with a sticker or a coloured brick so you can see where it is.
- Keep turning and count until the hammer reaches its highest. Is it about half a turn, or noticeably more or less?
- Keep going. Does the hammer fall gradually, or drop off the edge of the cam suddenly?
- If the drop is sudden, your cam has a step in it and the fall is nearly free. If it is gradual, the cam is lowering the hammer rather than releasing it — and it will hit more softly.
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 |
|---|---|---|
| Cam motor (Large) | A | A job motor. It needs torque to lift the hammer against gravity, which is why it is the Large one. |
| Sensors | none | The Hammer Bot has no idea where its hammer is. Everything it does is counted, not sensed — which is exactly why the counting has to be right. |
Check your own build now:
- Cam motor into A.
- Set the model down on something you do not mind being hit — not a table someone is working on, and never over a hand.
- Turn the cam so the hammer is at its lowest before you run anything. A program that starts mid-lift does its first strike from the wrong place.
- Check nothing is under the hammer that you want to keep.
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.
USB is fine. The Hammer Bot stays put. Just keep the cable out of the hammer’s way — it will be struck ten times a run otherwise.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- One Large Motor tile on A, and nothing in ports 1–4.
- Turn the cam by hand through what looks like half a turn and read tile A. Does it say something near 180? That is the number you are about to type, measured on your own model.
- Turn it a full turn and check the tile climbs by about 360.
Make it move 10 min
Ten strikes, each one a slow lift and a fast drop, with a pause between so you can hear the rhythm.
when program starts :: events hat repeat (10) [A v] run for (180) [degrees v] at (30) % speed :: motors [A v] run for (180) [degrees v] at (100) % speed :: motors wait (0.5) seconds end
- repeat 10 — a counted loop. It ends by itself, which matters for a model that hits things.
- 180 degrees at 30% — the lift. Slow, because the motor is fighting the hammer’s weight the whole way.
- 180 degrees at 100% — the release. The cam gets out from under the hammer as fast as it can, and gravity does the rest.
- wait 0.5 seconds — the gap between strikes. This is the only place time belongs in this program, because a rhythm is a length of time.
What success looks like: ten clear, evenly-spaced strikes, all sounding about the same. Then it stops on its own with the hammer down.
If the strikes get weaker as it goes, the cam is drifting: each pass is ending a few degrees off, and the error adds up over ten strikes. Turn the speed of the lift down and see if it improves — a motor asked to stop from full speed overshoots more than one stopping from a crawl.
Change it and test 8 min
One change at a time. Listen rather than watch for this one — the rhythm and the loudness tell you more than the movement does.
- Change the drop from 100% to 30%, the same as the lift. Does it still sound like a hammer, or like something being put down?
- Put the drop back to 100% and change the wait to 0.1 seconds. A fast rhythm. Then 2 seconds. A slow one.
- Change both motor blocks to 90 degrees and leave everything else. Predict first: how many strikes will you get out of ten loops now?
- Change the lift to 170 degrees and the drop to 190. They still add to 360, so the cam still ends where it began — but the hammer is released a little earlier. Can you hear a difference?
- Take the wait out completely. Ten strikes as fast as the model can manage. Watch whether the bot starts walking across the desk.
Step 3 catches nearly everyone. Two blocks of 90 degrees is half a turn, so the cam only gets round once every two loops — ten loops give you five strikes, not ten. The loop count did not change; what one loop means did.
A loop repeats what you put in it, not what you meant to put in it.