Challenge 1
Pick three objects of different sizes, one after another, without changing a single block between them. Show the degrees counted for each on the screen, then put the three in size order using the numbers alone.
What you are building 3 min
The Apple Picker: a long arm with a gripper on the end, and a switch hidden inside the gripper that closes when there is something in there.
The arm is driven by a Medium Motor. The gripper closes a little at a time. When an apple is properly held, the apple itself presses the switch — and that is how the machine knows.
By the end of the lesson your gripper will close on its own and stop the moment it has the apple — not after a time you guessed, and not after a number of turns you counted. It stops because it has the apple.
In the real world 5 min
Where you have seen it
Fruit is still picked mostly by hand, on ladders, one apple at a time. A picker does not grip for two seconds and hope. They squeeze until they feel the apple, and then they twist.
Why it is built that way
Every apple is a different size, and every one sits at a different angle. A machine that closed its gripper by a fixed amount would crush the big ones and drop the small ones. The apple has to be the thing that says stop, because the apple is the only part of the job nobody can predict.
Growers care about this to the ringgit. A bruised apple is sold as juice instead of fruit, at a fraction of the price, so a gripper that squeezes slightly too hard turns a good harvest into a cheap one.
What would go wrong without it
A picker with no sense of touch has only two settings: too gentle, so the fruit falls, or too firm, so the fruit is ruined. Neither one gets the apple to the crate.
When the job depends on something you cannot measure in advance, let the job tell you when it is done.
The main concept — a loop that carries its own ending 6 min
You know two loops. forever never stops. repeat (10) stops after a count you chose when you wrote the program. Today you meet the third: repeat until, which stops when the world says so.
repeat until <[1 v] is pressed? :: sensors> [A v] run for (15) [degrees v] at (25) % speed :: motors end
Read it in the order the Brick runs it: check the condition, then run the inside once, then check again. The loop ends between bites, never in the middle of one.
Why this is not the same as waiting
In Level 1 you used [1 v] wait until [pressed v], which also ends on the switch. Put that on the Apple Picker and it will sit there for the rest of the lesson.
| Block | While it is waiting for the switch, the motor is… |
|---|---|
[1 v] wait until [pressed v] :: sensors | doing nothing. The gripper never closes, so the apple is never held, so the switch is never pressed. Waits for ever. |
repeat until <[1 v] is pressed? :: sensors> [A v] run for (15) [degrees v] at (25) % speed :: motors end | closing, a bite at a time. The loop is what brings the condition true. It ends because of what it did. |
Waiting is not trying. A wait until is right when something else will make the condition true — a person, gravity, another stack. A repeat until is right when this program has to make it true.
How big should one bite be?
The bite is the smallest movement the loop makes between checks, and it decides how much the gripper overshoots. Fifteen degrees is a squeeze you can barely see. Three hundred and sixty degrees would slam shut before the loop ever got to look at the switch again.
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.
The Touch Sensor
The Touch Sensor is the simplest input the EV3 has: a button that is either pressed or not. That sounds trivial, but it is how a robot knows it has hit a wall, reached the end of a track, or been told to start by a person.
released
pressedBlocks reference
| Block | What it does |
|---|---|
wait until <[1 v] is pressed? :: sensors> | Holds the program here until somebody presses the sensor. |
<[1 v] is pressed? :: sensors> | Reports true or false. Drop it into a condition to make a decision rather than a wait. |
[1 v] when [bumped v] :: events hat | Starts a whole stack of its own. The dropdown chooses the moment: pressed, released or bumped. |
Three different events
A button is not only “pressed”. One press is three things: the moment it goes down, the time it stays down, and the moment it comes back up. Watch what a single press does to three programs at once.
when program starts
forever
if 1 is pressed? then
change count by 1
versus two hat blocks
1 when pressed
1 when bumped
0is pressed? in a loop0when pressed0when bumped
In a loop: 0 answers from one pressBumped: exactly one
Nobody is touching the sensor. All three programs are watching it.
The middle counter is the one that surprises people. Nothing is wrong with it — a loop really does check that fast, and every check really is a separate answer.
Nothing there is broken. A loop really does get round hundreds of times a second, and each time it asks is pressed? the honest answer is still yes — so if that loop plays a sound or counts something, it does it hundreds of times from one finger. The two hat blocks each fire once, and they fire at different moments: pressed the instant the button goes down, bumped only when it comes back up.
The three options, and what each is for:
- Pressed — the button is down right now. Good for “hold to run”.
- Released — it is up again. Good for acting when somebody lets go.
- Bumped — pressed and released. This is what you want for “click to start”, because it will not fire repeatedly while a finger stays down.
The classic bumper
when program starts :: events hat set movement motors to [B v] and [C v] :: movement start moving [straight: 0] :: movement wait until <[1 v] is pressed? :: sensors> stop moving :: movement
The robot drives until something presses the sensor. Note that the movement is started unmeasured on purpose — the sensor decides when to stop, not a distance.
Why it matters
Touch sensors are everywhere in machines you cannot see into: a lift knows the doors are shut, a printer knows the lid is closed, a washing machine will not spin until it is latched. They are safety devices as much as inputs.
repeat until does something while it waits — and the something is what ends the wait.
The Touch SensorFrom Level 1 — pressed and released, and why it lives in a numbered port.Show meHide
The Touch Sensor
The Touch Sensor is the simplest input the EV3 has: a button that is either pressed or not. That sounds trivial, but it is how a robot knows it has hit a wall, reached the end of a track, or been told to start by a person.
releasedpressedBlocks reference
| Block | What it does |
|---|---|
wait until <[1 v] is pressed? :: sensors> | Holds the program here until somebody presses the sensor. |
<[1 v] is pressed? :: sensors> | Reports true or false. Drop it into a condition to make a decision rather than a wait. |
[1 v] when [bumped v] :: events hat | Starts a whole stack of its own. The dropdown chooses the moment: pressed, released or bumped. |
Three different events
A button is not only “pressed”. One press is three things: the moment it goes down, the time it stays down, and the moment it comes back up. Watch what a single press does to three programs at once.
when program starts
forever
if 1 is pressed? then
change count by 1
versus two hat blocks
1 when pressed
1 when bumped
0is pressed? in a loop0when pressed0when bumped
In a loop: 0 answers from one pressBumped: exactly one
Nobody is touching the sensor. All three programs are watching it.
The middle counter is the one that surprises people. Nothing is wrong with it — a loop really does check that fast, and every check really is a separate answer.
Nothing there is broken. A loop really does get round hundreds of times a second, and each time it asks is pressed? the honest answer is still yes — so if that loop plays a sound or counts something, it does it hundreds of times from one finger. The two hat blocks each fire once, and they fire at different moments: pressed the instant the button goes down, bumped only when it comes back up.
The three options, and what each is for:
- Pressed — the button is down right now. Good for “hold to run”.
- Released — it is up again. Good for acting when somebody lets go.
- Bumped — pressed and released. This is what you want for “click to start”, because it will not fire repeatedly while a finger stays down.
The classic bumper
when program starts :: events hat set movement motors to [B v] and [C v] :: movement start moving [straight: 0] :: movement wait until <[1 v] is pressed? :: sensors> stop moving :: movement
The robot drives until something presses the sensor. Note that the movement is started unmeasured on purpose — the sensor decides when to stop, not a distance.
Why it matters
Touch sensors are everywhere in machines you cannot see into: a lift knows the doors are shut, a printer knows the lid is closed, a washing machine will not spin until it is latched. They are safety devices as much as inputs.
Say this back before moving on: “Check, do a little, check again — and stop when the apple says so.”
What’s in this build 4 min
Look at your model before you read on. Which electronic parts can you find? There are three, and one of them is deliberately hard to see.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The body of the picker. It runs the program and shows what the gripper thinks it is holding. |
| Medium Motor | Drives the gripper. Medium rather than Large because this is a small, precise squeeze, not a heavy lift. |
| Touch Sensor — inside the gripper | The one part that makes this lesson possible. It is pressed by the apple, not by a person. That is unusual, and it is the whole idea. |
| The arm linkage (not electronic) | Turns the motor’s rotation into the gripper’s closing. If it is stiff, the loop will take many more bites — worth checking by hand first. |
Check the switch by hand before you program it
- Press the Touch Sensor with a finger. You should feel and hear a definite click.
- Now close the gripper by hand with nothing in it. The switch must not press. If it does, your loop will end instantly and the gripper will never close.
- Close it by hand on an apple-sized brick. The switch must press before the gripper jams. If it does not, move the sensor deeper into the jaw.
Step 2 and step 3 together are the real test. A switch that presses when empty and a switch that never presses at all are both fatal, and both look like a program fault when you meet them at step 9.
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 |
|---|---|---|
| Gripper (Medium Motor) | A | A lone motor doing its own job has taken A since Level 1 lesson 1. |
| Gripper switch (Touch Sensor) | 1 | The course’s standing home for a Touch Sensor, and it is the port that appears in the loop condition. |
Check your own wiring now:
- Motor in A, switch in 1.
- Run the sensor cable along the arm, not across the gripper’s jaws. A cable trapped in the jaw will press nothing and hold everything open.
- Leave enough slack for the arm’s full travel. Wave the arm through its whole range by hand and watch the cable.
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.
Either route is fine here — the picker stays on the desk. But keep the cable clear of the arm’s swing. This model has a long arm and a short temper about snagged wires.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- A Medium Motor tile on A and a Touch Sensor tile on 1.
- Press the switch with your finger and watch tile 1. It must change while you hold it. This is the single most useful check in the lesson — a sensor that reads nothing here will read nothing in your loop.
- Turn the gripper by hand and watch tile A’s count move. If it does not, the motor is in the wrong port.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
The smallest program that picks an apple: open, wait for a person to offer the fruit, then close until it is held.
when program starts :: events hat clear display :: display write [SEDIA] at line (1) :: display [A v] run [counterclockwise v] for (1) [rotations v] :: motors [A v] reset degrees counted :: motors repeat until <[1 v] is pressed? :: sensors> [A v] run for (15) [degrees v] at (25) % speed :: motors end [A v] stop motor :: motors clear display :: display write [EPAL DIPEGANG] at line (1) :: display play sound [Communication / Hello v] until done :: sound
- The first motor block opens the gripper a full turn counterclockwise. Every run must start from the same place, or the loop begins half-closed.
- Resetting the counter costs nothing now and gives you a number to read later — how far it had to close before it found the apple.
- The loop checks first, then squeezes. If you put an apple in before pressing Play, the loop ends immediately having done nothing, which is correct.
stop motorafter the loop is belt and braces — the lastrun forhas already finished — but it makes the ending explicit.
What success looks like: the jaw opens and stops. You hold an apple-sized brick in it. The jaw closes in small steps, visibly stepping rather than sweeping, and the moment it grips, it stops dead and the Brick says EPAL DIPEGANG.
If the gripper closes fully and keeps trying, the apple is not reaching the switch — go back to the hand check in step 5. If it stops before touching anything, the switch is being pressed by the build itself.
Change it and test 8 min
One change at a time. Predict out loud before each run — a prediction you get wrong teaches you something, and a run you only watch teaches you nothing.
- Change the bite from 15 degrees to 90. Predict first: does the gripper still stop on the apple? Watch how much further it closes past the moment of contact.
- Now try 360 degrees — a whole turn per bite. This is the one that should worry you. The loop cannot look at the switch until the turn has finished.
- Go the other way: 5 degrees. Gentler, and slower. Time how long a pick takes. You are trading speed against gentleness, and there is no answer that wins both.
- Change the speed from 25% to 60% and leave the bite at 15. Does a faster squeeze overshoot more, even though each bite is the same size?
- Swap the
repeat untilfor [1 v] wait until [pressed v] on its own and run it. Nothing happens, for ever. Now you have seen the difference rather than been told it. - After the loop, show the count: write ([A v] degrees counted) at line (2). Pick a small brick and a big one. The number tells you the size of what you caught.
Step 6 is worth dwelling on. Nothing was added to the machine — the encoder was always counting — and yet the picker can now report how big the apple was. A machine often already knows more than it says.
A smaller bite means a gentler grip and a slower pick. Choose the trade on purpose.