Challenge 1
Collect everything in a marked area on the mat. Scatter at least eight balls, record where they are, then run a pattern that collects all of them. Any ball left behind means the pattern has a gap — find it and say where it was.
What you are building 3 min
The Ball Collector: a driving base with a row of hanging fingers across its front. Drive at a ball and it pushes past the fingers into the cage; the fingers swing back and it cannot get out again.
You have driven robots to places before. This one has nowhere in particular to go — its job is to visit everywhere.
That is a genuinely different problem. Getting to a spot has an obvious test: did you arrive? Covering an area does not, because the bit you missed is by definition the bit you did not look at.
In the real world 5 min
Where you have seen it
The little round robot that cleans the floor. It has no idea where the dirt is, so it does not try to go to the dirt — it tries to go everywhere, and lets the dirt come to it.
Why it is built that way
Watch one for a minute and you will see it is not wandering randomly — it is running a pattern. Long straight runs, a turn, another straight run alongside the first. Back and forth, like mowing a lawn or reading a page.
The pattern matters because of overlap. Each pass covers a strip as wide as the machine. Space the passes further apart than that and you leave untouched lanes between them; space them closer and you waste time going over ground you have already done.
What would go wrong without it
A robot with no pattern — one that just drives about and bounces off things — does eventually cover most of a room, but it takes many times longer and it can never say it has finished.
And here is the part that catches people out: from the outside, a robot that missed a strip looks exactly like a robot that did the job. It is moving, it is busy, it comes back with something. You only find out by checking the floor.
Looking busy is not the same as having covered everything. A collector has to be judged on what it left behind.
The main concept — the search pattern 6 min
To cover an area you need a repeating shape: a straight run, a turn, a straight run back. Everything else is choosing the numbers.
You already have every block you need. A straight is a move forward; a turn on the spot is the two-speed block from Lesson 28 with opposite numbers; and repeat does the pattern as many times as it takes.
| Choice | What it costs you if you get it wrong |
|---|---|
| Passes spaced too far apart | Missed lanes. The robot looks like it worked and did not. |
| Passes spaced too close | Wasted time going over the same ground. Nothing is missed, but a real machine runs out of battery. |
| Turn slightly wrong | The whole pattern tilts, and every later pass is wrong too — the drift you measured in Lesson 35, now with consequences. |
Space your passes a little closer than the width of your robot. A bit of overlap is cheap; a missed lane is a failed job.
Driving with two motors, and repeatingThe full reference for the pair blocks and for loops. Open either if it is not clear yet.Show meHide
Driving with two motors
A driving base has two Large Motors, one per wheel. You could drive them with two separate motor blocks — but they would never start at quite the same instant, and the robot would curve away. EV3 has a separate family of Movement blocks that treat the pair as a single driving base.
port Bport CBlocks reference
| Block | What it does |
|---|---|
set movement motors to [B v] and [C v] :: movement | Tells the Movement blocks which two ports are the driving wheels. Put it at the top of the program, before any movement. |
move [forward v] for (2) [rotations v] :: movement | Drives both wheels together, so the robot travels in a straight line. |
move for (1) [rotations v] at (75) (25) % speed :: movement | Drives the two wheels at different speeds, which makes the robot curve. |
set movement speed to (50) % :: movement | Sets how fast the driving base travels from now on. |
The letters must match the sockets
set movement motors to [B] and [C] is the block that decides which two motors every Movement block after it will drive. It does not look at the robot. It drives the two ports you name, whether or not there is a motor in them — so those two letters have to be the two sockets the cables are actually in.
This is the single commonest reason a driving base does nothing, and it is invisible in the program: every block is spelled correctly and the robot still will not go.
when program starts
set movement motors to B and C
move forward for 3 rotations
the same program on both robots
2wheels driven · matched1wheel driven · mismatched
B and C: both sockets fullB and C: C is empty
Two robots, and the very same program: drive the motors in ports B and C forward.
The yellow outline marks the two ports the block is driving. A robot only goes straight when both of them have a motor in them.
Both robots run the identical program. The left one has its motors in B and C, so both named ports have a motor and the robot drives straight. The right one is plugged into A and B: the block drives B, finds nothing in C, and never mentions the motor in A at all — so one wheel turns, one wheel sits there, and the robot swings round the dead one instead of driving.
If neither named port has a motor in it — cables in A and D, say, with the block still set to B and C — the robot does not move at all. The program runs happily to the end and the Brick reports nothing wrong, because as far as it is concerned it did exactly what it was told.
So before you look for a bug in the program, look at the cables: read the port letters off the Brick, then make the block say those two. B and C are only the usual choice, not a rule — if your build has the driving motors in A and D, set the block to A and D and everything works.
Straight, curved, and on the spot
Everything a driving base can do comes from those two speed numbers. Try each button below and watch the trail the robot leaves.
when program starts
set movement motors to B and C
move for 2 rotations at 50 50 % speed
50left wheel · B50right wheel · C
Equal speeds → a straight line
Both wheels are set to the same speed.
The path is worked out from the two wheel speeds in the block, not drawn by hand — so changing the preset changes the numbers and the shape together.
- Both wheels the same speed — the robot goes straight.
- One wheel faster than the other — it curves towards the slower side. The bigger the difference, the tighter the curve.
- One wheel forward, the other backward — it spins on the spot, which is how a robot turns in a space no wider than itself.
Notice there is no steering block anywhere in that program, and no steering part anywhere on the robot. The turn is made entirely by driving the two wheels different amounts.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement move [forward v] for (2) [rotations v] :: movement move for (1) [rotations v] at (50) (-50) % speed :: movement
How far is one rotation?
“Move forward 2 rotations” says nothing about the floor — it says how many times the wheels go round. How far the robot actually travels depends on how big the wheels are, and once round a standard EV3 driving wheel is about 17.5 cm.
Before doing any sums, get a feel for it. Drag the robot along and watch both scales at once — rotations on top, centimetres underneath, the same line. Land on the half marks: there is a number between 1 and 2, and it is 1.5.
Drag the robot, or use the arrow keys — it moves in half rotations. Rotations above the line, centimetres below.
1.5 rotations26.3 cm
1.5 — a half rotation past 1. Half a turn of the wheels is 8.75 cm, so halves matter.
cm=2rotations
35 ÷ 17.5 = 2. That is a number you can type straight into the block.
- 1 rotation = 17.5 cm. Two rotations is 35, three is 52.5.
- Halves are real. 1.5 rotations is a perfectly good thing to type into the block, and it is 26.25 cm — right between the 1 and the 2 you already tried.
- To go a distance you have chosen, divide by 17.5. The calculator does it, but do a few by hand first — 35 ÷ 17.5 = 2 is worth seeing.
- Measure your own wheels before trusting the number. A base built with different wheels travels a different distance per rotation, and every calculation on this page moves with it.
set movement motors to [B v] and [C v] :: movement set movement speed to (30) % :: movement move [forward v] for (2) [rotations v] :: movement
Turning on the spot
Steering at right 100 or left 100 drives the two wheels in opposite directions, so the base stops travelling and pivots where it stands. The angle it sweeps is a simple doubling of the rotations:
Half a rotation is the one worth remembering: a square corner, 90°.
| Rotations | The robot turns |
|---|---|
| 0.25 | 45° — half a corner |
| 0.5 | 90° — a square corner |
| 1 | 180° — turn round and face back |
| 2 | 360° — all the way round |
The one to memorise is 0.5 rotations = 90°. Everything else follows from doubling or halving it.
set movement speed to (20) % :: movement move [right: 100] for (0.5) [rotations v] :: movement
Turn slowly. The wheels on a driving base are big and the robot carries a lot of weight, so at full speed it keeps going after the motors stop and lands past the angle you asked for. Somewhere between 15% and 30% speed is where turns become repeatable. A turn that overshoots is almost always a turn taken too fast, not a wrong number.
These figures belong to your robot. The distance depends on the wheels and the angle depends on how far apart they are, so a wider base needs a different number for 90°. Test it, measure what actually happened, and adjust — the same discipline as the Gyro Sensor tolerance.
Why it matters
Every wheeled vehicle steers this way — a tank, a digger, an office chair with two driven castors. Cars use a steering rack instead, but a robot that turns by driving its wheels at different speeds needs no steering mechanism at all.
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: “Cover an area with parallel passes, spaced a bit narrower than the robot.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and sits over the driven wheels. |
| Large Motor ×2 | Ports B and C. Straights and turns, as on the Tricycle. |
| The finger gate (no cable) | A row of loose fingers on a shaft. They swing inwards to let a ball in and will not swing outwards to let it go. |
Test the trap, and measure the robot
- Push a ball into the front by hand. It should go in with a light push. Now try to push it back out — it should not come.
- If a ball can escape, the fingers are too short or too stiff. Fix it now: a collector that loses balls is worse than useless, because you will blame the driving.
- Measure how wide your robot is at the front, across the collecting mouth. Write it down in centimetres. That number is the width of one pass, and the next two sections depend on it.
- Measure how far the robot travels for one rotation of the wheels. Push it by hand through exactly one wheel turn and measure. Write that down too.
Those two numbers are the lesson’s real tools. You cannot plan a coverage pattern without knowing how wide your robot is and how far it goes per rotation.
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 drive motor | B | B is left and it is the first number in the two-speed block. Today that matters: every turn in your pattern depends on it. |
| Right drive motor | C | Right is C, second number. |
| Sensors | none | The collector cannot see balls or walls. Everything it does, you planned. |
Check your own build now:
- Left in B, right in C, decided from behind the robot.
- Mark out a rectangle on the floor with tape — about a metre square is plenty. That is your area.
- Scatter ten balls (or ten crumpled paper balls) across it, and photograph or sketch where they are before you start. You will need to know what you missed.
- Cables up and over, clear of the wheels and the mouth.
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. A robot running a coverage pattern crosses its own path repeatedly, and a USB cable will be driven over, dragged and eventually wrapped round a wheel.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- A Large Motor on B and one on C.
- Turn the left wheel and check tile B counts, then the right and C. A swap mirrors every turn in your pattern.
- Place the robot in one corner of your taped rectangle, facing along the long edge. Same corner, same direction, every run.
Make it move 10 min
Six blocks. A straight, then a spin, four times over — which traces a square rather than a proper back-and-forth sweep. That is deliberate: it is the simplest pattern that goes somewhere, and the next section is about improving it.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set movement speed to (40) % :: movement repeat (4) move [forward v] for (4) [rotations v] :: movement move for (1) [rotations v] at (40) (-40) % speed :: movement end
Walk it in the order the Brick runs it:
- set movement motors to B and C — a setting.
- set movement speed to 40 % — this only affects the forward block; the spin block carries its own two speeds.
- repeat (4) — four sides.
- move forward for 4 rotations — one side of the square, sweeping up whatever is in the way.
- move for 1 rotation at 40 and −40 — a spin on the spot. The negative number is the right wheel going backwards, from Lesson 28.
What success looks like: the robot traces a rough square and collects any ball that happened to be on one of the four lines. Count what it got and — more importantly — count what it missed and where. The middle of your square is almost certainly untouched.
The 1 rotation in the spin is a guess. It will not be exactly a quarter turn on your robot. Adjust it until the square closes — that is the first thing to fix.
Change it and test 8 min
One change at a time. After every run, put the balls back where your sketch says they were, so each pattern gets the same test.
- Tune the spin until the square really closes — the robot should finish facing the way it started, near where it started.
- Now build the back-and-forth pattern instead. Inside a repeat: forward a long way, spin a quarter, forward a short way (one robot-width), spin a quarter the same way, forward a long way, and so on. Sketch it on paper before you build it.
- Set your short move to exactly one robot width, using the measurement from section 5. Run it and count what is missed.
- Now set the short move to three-quarters of a robot width. Overlapping passes. Predict whether it collects more, then check.
- Finally, set it to one and a half robot widths. Run it and look at the floor. There are lanes it never went near, and the robot looked exactly as busy the whole time.
Step 5 is the one to remember. Nothing failed, nothing stalled, no block was wrong — and half the floor is still covered in balls. This is the kind of bug you can only find by checking the outcomerather than watching the robot.
Judge a collector by what is left on the floor, never by how purposeful it looked.