Challenge 1
Find every mine in one lane at crawling speed, with the count matching the number you laid out.
What you are building 3 min
The Minesweeping Robot: a driving base with an arm out in front. A Medium Motor swings that arm left and right, and on the end of it a Colour Sensor looks down at the ground.
The mines are coloured beams laid out on the floor. The robot drives forward slowly, sweeping the sensor side to side, and counts what it finds.
By the end of the lesson your robot will find mines — and you will know exactly how fast it can go before it starts missing them.
In the real world 5 min
Where you have seen it
Humanitarian demining is slow, deliberate work. A deminer kneels, sweeps a detector across a narrow lane, moves forward a few centimetres, and sweeps again — for hours.
Why it is built that way
A metal detector does not see a field. It sees a small patch under its coil, and nothing else at all. Everything outside that patch is invisible — not “probably empty”, just unlooked at.
So the whole method is about coverage. Sweep slowly, keep the coil low, and — the rule that matters — overlap every sweep with the last one. Deminers advance about half the width of the coil each time, so every patch of ground is covered twice. Clearance standards require it, and the reason is arithmetic rather than caution.
International standards ask for 99.6% clearance of a defined area. The work is measured in square metres per day, and a good deminer does not do very many, because going faster does not mean finding fewer mines. It means looking at less ground.
What would go wrong without it
Sweep too fast and the detector still works perfectly. It still beeps on everything under the coil. It simply passes over stripes of ground that were never under the coil at all — and there is nothing in a clean sweep to tell you that you missed a stripe.
A sensor that reports nothing has either found nothing or looked nowhere. They are indistinguishable.
Before you build 1 min
This model has no step-by-step manual, and the video above is not one. Watch it for how far the arm swings and how low the sensor sits, then build from the model your teacher has. You are not missing a page; the page does not exist.
The programs below name ports rather than motor types.
The main concept — the blind spot has a shape 6 min
Twice already this level you have met a blind spot in time. Lesson 29’s gripper could not look at its switch during a bite; Lesson 35’s walker could not look at the wall during a stride. Today the blind spot is in space, and it is worse, because it leaves no trace.
What the sensor actually sees
The Colour Sensor looks at a spot roughly 1 to 2 cm across, about a centimetre below its face. That is all. Everything else on the floor might as well not exist.
The arm sweeps that spot side to side, painting a stripe across the robot’s path. Meanwhile the robot rolls forward. Put those two movements together and the sensor traces a zig-zag over the ground.
The arithmetic of a gap
One full sweep — over and back — takes some time. Call it T. During that time the robot advances speed × T centimetres.
If the robot advances further in one sweep than the sensor spot is wide, there is a stripe of floor nobody looked at.
| Advance per sweep | Spot width | Coverage |
|---|---|---|
| 0.5 cm | 1.5 cm | overlapping. Every patch looked at more than once — this is the demining standard |
| 1.5 cm | 1.5 cm | just touching. Perfect in theory, and one wobble opens a gap |
| 5 cm | 1.5 cm | 3.5 cm of unswept floor per sweep, and the robot will report a clean field |
This is why the robot has to crawl, and it is not because the sensor is slow. The sensor reads hundreds of times a second. The limit is geometric: a small dot cannot cover a wide floor unless it is given the time to travel over all of it.
The sweep must not stop when the robot does
Two things have to happen at once — driving and sweeping — so this is a two-stack program, and it is Lesson 1’s idea doing genuinely useful work. Put the sweep inside the driving loop and it pauses every time the robot stops to log a mine.
And the count re-arms
A mine stays red under the sensor for as long as the robot sits on it, so counting it needs Lesson 38’s edge detection: wait for red, count once, then wait for not-red before looking again.
The Colour Sensor
The Colour Sensor looks down at a surface and can answer three quite different questions: what colour is this?, how bright is this? and how light is the room? Choosing the wrong one is the usual reason a line-following robot refuses to work.
front
sideBlocks reference
| Block | What it does |
|---|---|
([3 v] color :: sensors) | Reports which colour it sees, from a short list — red, blue, green, black, white and a few more. |
([3 v] reflected light intensity :: sensors) | Reports how bright the surface is, as a number from 0 (black) to 100 (white). |
<[3 v] is color [red v]? :: sensors> | Reports true or false for one particular colour. |
([3 v] ambient light intensity :: sensors) | Reports how much light is falling on the sensor, 0 to 100, with its own lamp switched off. |
Which colour, exactly?
The sensor does not describe a colour — it picks one from a list of eight, and that list is the whole of what it can ever say:
| Reports | Means |
|---|---|
| 0 | no colour — too far away, or too dark to call |
| 1 · 2 · 3 | black, blue, green |
| 4 · 5 · 6 | yellow, red, white |
| 7 | brown |
Anything you put under it is forced into one of those eight. There is no orange and no purple: an orange brick comes back as red or as yellow, and often as red one moment and yellow the next as the robot creeps along. Light blue and grey are the other classic pair to avoid — grey is neither black nor white, so it flips between them.
This is why colour mode is a good fit for a task you control and a bad fit for one you do not. Sorting the LEGO bricks that come in the set works, because they are made in exactly these colours. Reading a printed sheet, a coloured tile from another set, or anything pastel is asking the sensor to answer a question it does not have a word for.
Two practical points follow from how it decides. It shines its own lamp and looks at how much red, green and blue comes back, so it must be close — about half a centimetre, and no more than a centimetre. Lift it and the answer decays to 0. And because it takes those three readings before it can answer, colour mode is the slowest thing this sensor does; a robot driving quickly can pass right over a small patch without ever reporting it.
When a colour must be recognised reliably, test it. Drive the robot slowly over the real surface with color shown on the screen and watch what it actually says — including what it says at the edges between two colours, which is where the wrong answers live.
Colour, or brightness?
Both questions are asked of the same surface at the same moment. Watch the two answers travel across a strip of colours and then over the edge of a black line.
when program starts
forever
write 3 color at line 1
write 3 reflected light intensity at line 3
colour: 2 possible answers herereflected light: every value from 88 down to 8
The sensor sits a few millimetres above the surface, with its own lamp shining down.
Watch the two read-outs over the last third of the strip. One of them changes once. The other changes the whole way across.
Over the patches, both read-outs are useful. Over the edge of the line they part company: the colour name has only two answers to give and jumps between them, while the number slides smoothly from 88 down to 8. Every value in that slide tells you how far onto the line the sensor is — which is information the name simply does not carry.
- Use colour when the answer really is a name — sorting red bricks from blue ones, stopping on a green square.
- Use reflected light when the answer is a matter of degree — following the edge of a black line, where the useful readings are all the greys between black and white.
A line follower built on colour names only knows “black” or “not black”, so it can only lurch. Built on reflected light it can tell how far onto the line it has drifted, which is what makes smooth following possible.
The third mode: ambient light
The first two modes both switch the sensor’s own lamp on and measure what bounces back off the surface. Ambient light intensity does the opposite: the lamp goes off, and the sensor simply reports how much light is arriving from wherever — 0 in the dark, up to 100 in bright light.
| Mode | Own lamp | Measures | Points |
|---|---|---|---|
| colour | on | which of eight colours the surface is | at the surface, very close |
| reflected light | on | how much of its own light comes back | at the surface, very close |
| ambient light | off | how bright the surroundings are | wherever you want to measure |
That makes it the only one of the three that is not really about the floor. A number between 0 and 100 means very little on its own, so watch the same sensor sit through five different rooms — nothing underneath it changes at any point.
the sensor’s own lamp is off — it is measuring the room
Start in the dark — a hand over the lens, or the lights off. Almost no light reaches the sensor, and it reports 0.
Nothing under the sensor changed at any point in this run. Ambient light is the one mode that is not asking about the surface at all.
Those are the shape of the scale rather than exact figures, but the shape is the useful part: a lit room is nowhere near 100, and the top of the range is reserved for a light pointed straight at the sensor. Cover it with your hand and the number drops to near zero — which is the easiest way to check the sensor is doing what you think.
Point it at the ceiling and it tells you whether the room lights are on; point it forwards and a torch will spike the reading, which is a way of signalling to a robot without touching it.
Do not reach for it as a substitute for reflected light. Room light falling on a black line and on white paper is almost the same, so ambient mode can barely tell them apart — the reason reflected light works is precisely that the sensor brings its own light and measures how much of it survives.
It is also the mode most at the mercy of the room. A reading taken by a window in the morning will not match the same spot in the afternoon, so anything built on ambient light needs measuring on the day, in the place, with the lights as they will be.
Light and height matter
Even the two lamp-on modes are affected by room lighting — a reading taken by a sunny window differs from one taken in a corner. The sensor must also sit close to the surface and at a constant height, because lifting it changes the reading even though the surface has not changed.
Two things at once
A program does not have to be one long column of blocks. Several stacks can run at the same time, each doing its own job — one driving, one watching a sensor, one keeping the display up to date.
How it is done
Give each stack its own hat block. Every stack beginning with when program starts starts at the same instant — not one after another — and from then on they run alongside each other.
Nor is it limited to two. Below, three stacks run together: a Medium Motor turning an attachment, the status light flashing, and the drive base rolling. Watch the arrows at the top — they all begin at once, and no stack waits for any other.
when program starts :: events hat [A v] start motor [clockwise v] :: motors when program starts :: events hat forever set status light to [green v] :: display wait (0.5) seconds set status light to [red v] :: display wait (0.5) seconds end when program starts :: events hat start moving [straight: 0] :: movement
Written down they have to go one under another, because a page is a column — but that is an accident of paper. On the Brick they sit side by side, and nothing in the first stack happens before anything in the third.
The rule: one owner per thing
Parallel stacks go wrong when two of them try to control the same thing. Use the switch below to take the wheels away from the third stack and point it at motor A, which the first stack is already driving.
the program starts — all of these begin here
stack 1 · Medium Motor
when program starts
A start motor clockwise
stack 2 · status light
when program starts
forever
set status light to green
wait 0.5 seconds
set status light to red
wait 0.5 seconds
stack 3 · drive base
when program starts
start moving straight: 0
One stack, one jobAll three at once
Three stacks, each with its own hat block. All three start the moment the program starts — none of them waits for the others.
Every stack is highlighted at the same moment on purpose — that is what running in parallel looks like. The switch above changes only what the third stack controls.
With one owner each, all three stacks are highlighted at the same instant and all three jobs get done. With two owners, motor A is handed contradictory orders hundreds of times a second and shivers instead of turning — and notice the second cost, which is easy to miss: the wheels now have nobody driving them. A stack that goes to fight over someone else’s motor has abandoned its own job. Nothing reports an error either way; as far as the Brick is concerned every stack is working perfectly. The same happens to a display line or a variable that two stacks both write to.
The discipline is simple: give each stack sole ownership of what it controls. One stack owns the motors, another owns the screen, another watches the sensors and tells the others what it found — which is what broadcasting is for.
Coverage is speed against sweep time. Going faster does not find fewer things — it looks at less ground.
Counting events, not readingsFrom Lesson 38 — arrive, count, leave, and only then look again.Show meHide
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.
Say this back before moving on: “Nothing found is not the same as nothing there.”
What’s in this build 4 min
Look at your robot. How high is the Colour Sensor above the floor? On this model that one measurement decides whether anything works.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The body, and the tally board for the mines found. |
| Drive motor ×2 | A matched pair. Today they run slowly, and that is the point rather than a limitation. |
| Sweep motor | Swings the arm side to side. Its speed sets T — the sweep time — which is half of the coverage sum. |
| Colour Sensor | Faces straight down. It must be about 1 cm above the floor — higher and it reads a wide, washed-out average; touching and it drags. |
| The arm (not electronic) | Longer arm, wider lane, but slower to sweep. Another trade, and you can measure this one. |
Measure your own spot and your own sweep
- Put a red beam on the floor. Move the sensor across it slowly by hand and note where it starts and stops seeing red. That width is your spot.
- Run the sweep motor and time ten full sweeps. Divide by ten for T.
- Measure how far the robot travels in T at your chosen speed. Compare it with your spot width. If it is bigger, you have gaps — before you have run the program even once.
- Check the arm sweeps clear of the wheels at both extremes.
Step 3 is the lesson done on paper. You can predict a missed mine with a ruler and a stopwatch, and then go and prove it on the floor.
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 wheel | B | The pair. Two motors, one job. |
| Right drive wheel | C | The other half of the pair. |
| Sweep arm | A | Its own job, and its own stack. |
| Colour Sensor | 3 | The Colour Sensor’s standing home since Level 1, and the port in every condition below. |
Check your own wiring now:
- Wheels in B and C, sweep in A, sensor in 3.
- The sensor cable travels with the arm. Leave enough slack for the full sweep both ways and check it at both extremes — a cable that goes tight will pull the arm short at one end and quietly narrow your lane.
- Work under steady light. The Colour Sensor has its own lamp, but bright sun or a desk lamp shining onto the floor will change what it calls red.
- Lay out your minefield: coloured beams on a plain, light floor, and write down how many you put out. That number is the only way to know whether the robot missed any.
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, and this time it is not optional. A USB cable dragging behind the robot will sweep the beams out of position — you will be testing whether the robot can find mines that your own cable has already moved.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Three motor tiles — A, B and C — and a Colour Sensor tile on 3.
- Hold a red beam under the sensor and watch tile 3. It must say red. Now the floor: it must not. If the floor also reads as a colour you are hunting for, change the floor or change the mine colour.
- Test every mine you have laid out. Some LEGO reds read as brown at the wrong height. Two minutes here saves a lesson of blaming the program.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
Two stacks. One sweeps, for ever. The other crawls forward and counts what passes underneath.
when program starts :: events hat forever [A v] run [clockwise v] for (120) [degrees v] at (50) % speed :: motors [A v] run [counterclockwise v] for (120) [degrees v] at (50) % speed :: motors end when program starts :: events hat set movement motors to [B v] and [C v] :: movement set [periuk v] to (0) clear display :: display write (periuk) at line (1) :: display start moving [straight: 0] at (15) % speed :: movement forever wait until <[3 v] is color [red v]? :: sensors> stop moving :: movement change [periuk v] by (1) write (periuk) at line (1) :: display play beep (76) for (0.3) seconds :: sound start moving [straight: 0] at (15) % speed :: movement wait until <not <[3 v] is color [red v]? :: sensors>> end
- 15% speed is a crawl, and it is deliberate. It is the number your coverage sum in step 5 should have produced. Put your own number in.
start moving, notmove for. The drive must keep running while the loop watches the sensor — Lesson 35’s second answer, and here it is the right one because the robot is rolling rather than stepping.- The restart comes before the re-arm wait. The robot has to be moving to get off the red beam; wait for not-red while stopped and it waits for ever, sitting on the mine.
- Stopping on a find is not required — it is courtesy. It makes the count visible and gives you a beep you can match to a beam.
What success looks like: the arm sweeps steadily, the robot crawls, and each time the sensor crosses a beam it stops, beeps, adds one to the screen and moves on. At the end of the lane, the number on the screen equals the number of beams you laid out. That last check is the whole test.
If it counts one mine several times, the re-arm wait is missing or the robot is not clearing the beam. If it sits on a mine for ever, the restart is after the re-arm wait instead of before it.
Change it and test 8 min
One change at a time, and lay out the same minefield every run — same beams, same places, counted before you start. The measurement is: how many did it find out of how many are there?
- The baseline. Run it at 15% three times over the same field. Write down found-out-of-laid each time. You should get them all, every time.
- Now 40%. Predict how many it will miss before you run it, using your coverage sum. Run it three times. Were you right?
- Now 80%. Watch the sensor’s path rather than the screen. You can see the zig-zag opening up.
- Go back to 15% and slow the sweep motor to 20% instead. Same drive speed, longer T, bigger gaps. Coverage has two halves and this is the other one.
- Find the fastest speed that still finds them all. Work down from 80 rather than up from 15 — that is how you find an edge. Write the number on a card and keep it with the model.
- Make the robot honest about what it did not do. Add reset timer at the start, and show ((timer) * (speed)) as an estimate of ground covered. A machine that reports its own coverage is much harder to mislead yourself with.
Step 2 is the run to sit with. The robot is not broken. Every sensor reading is correct, every count is correct, the program has no bug — and the screen says 4 when the floor says 6. The failure is not in anything the machine did. It is in the ground it never passed over.
Before you trust a sensor’s answer, work out how much of the problem it actually looked at.