EV3 Robotics›Level 3 · Advanced›Lesson 42
Level 3 · Lesson 42 · EV3-L03-4260 minutes · Ages 9–16 · Model: EV3 Scorpion Bot
The Scorpion Bot: two claws, a striking tail, and an Ultrasonic Sensor watching whatever comes near. Its job is to decide, over and over, whether what it can see is a threat.
Lesson 29 taught it to classify. This lesson starts from an uncomfortable fact: whatever threshold you choose, it will be wrong sometimes — and it can be wrong in two different directions.
By the end of the lesson you will have counted both kinds of mistake separately and chosen a threshold on purpose — not the one that is “most accurate”, but the one whose mistakes you can live with.
A scorpion’s venom is expensive. It takes days to rebuild and the animal knows it — most encounters are settled with claws, and the sting is held back. But a scorpion that hesitates against a real predator does not get a second chance.
Human systems face the same choice openly. A smoke alarm is deliberately tuned to cry wolf at burnt toast, because a missed fire is unthinkable. A medical screening test is set to over-refer, because a second test is cheap and a missed illness is not. A car’s emergency braking is tuned the other way — braking at a plastic bag on a motorway causes the crash it was meant to prevent.
Because there are exactly two ways to be wrong, and they are not the same size:
You cannot reduce both by moving one threshold. Tighten it and misses rise; loosen it and false alarms rise. The only real question is which one you would rather have.
You get a machine tuned for “accuracy”, a single number that averages the two mistakes as though they cost the same. A smoke alarm optimised that way would be silent nine hundred and ninety-nine nights out of a thousand and correct — and useless on the thousandth.
Count the two mistakes separately. Accuracy hides the one that matters.
Every decision this machine makes lands in one of four boxes. Two of them are correct, and the two mistakes have different names because they have different consequences.
| Really a threat | Really harmless | |
|---|---|---|
| Struck | Correct — defended itself. | False alarm. Venom wasted on a passing leaf. |
| Did not strike | Miss. The predator got there. | Correct — stayed calm, saved venom. |
The machine cannot count these by itself, because it does not know the truth. You do. That is what the Touch Sensor is for in this lesson: after each approach you tell it whether that was really a threat, and it fills in the table.
Strike at anything within 40 cm and almost nothing is missed — and it strikes at everything that walks past. Strike only within 10 cm and it almost never wastes a strike — and slow threats reach it first.
// one number, two consequences that move in opposite directions if <(gap) < (threat gap)> then broadcast [strike v] :: events end
threat gap that makes both counts zero. Choosing it is the engineering.Decide the exchange rate first, in words, before you touch a number. “I would rather waste five strikes than miss one threat” is a decision anyone can argue with — and it fixes the threshold almost by itself.
Then run twenty approaches at each of three thresholds, count both mistakes, and pick the one that matches what you said. The number comes last, out of the data and the policy together.
Sometimes you can escape the trade-off by measuring something else as well. A leaf drifts; a hand approaches steadily. Add speed of approach and the two groups separate, so a tighter threshold no longer costs you misses.
That is the only honest way to improve both at once — better information, not a better-tuned single number.
The Ultrasonic Sensor measures distance. It sends out a burst of sound too high for people to hear, listens for the echo, and works out how far away the surface is from how long the echo took — exactly how a bat finds a moth, and how a submarine uses sonar.
front
side| Block | What it does |
|---|---|
([4 v] distance in [cm v] :: sensors) | Reports how far away the nearest thing in front of the sensor is, as a number in centimetres. |
wait until <([4 v] distance in [cm v] :: sensors) < (15)> | Holds the program until something comes closer than 15 cm. |
This is the important step up from the Touch Sensor. Touch gives you true or false; the Ultrasonic gives you a number, and the deciding is left to you. Pick a threshold below and watch where the robot ends up.
The black line on the bar is the threshold; the blue fill is the reading. The robot stops the instant the fill crosses the line.
Three different robots, and only one number is different between them. That is what having a number rather than a yes-or-no buys you: the behaviour is tuned by editing one slot, not by rebuilding the program. It also means the sensor can never tell you it is “close” — close is a decision you make about a reading.
Car parking sensors, automatic doors at a shopping centre, and the sensor that stops a lift door closing on somebody all work this way. Reacting before contact is what makes a machine feel safe.
The Home/Retail EV3 set (31313) ships an Infrared Sensor and a Beacon in place of the Ultrasonic and Gyro sensors. The Infrared Sensor also measures distance, so the programs in this module work with it — but it reports a rough 0–100 proximity rather than real centimetres, and it is affected by sunlight and by dark surfaces in ways the Ultrasonic is not.
IR Sensor
BeaconLong 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.
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.
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.
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.
| 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 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
set inside it
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.
EV3 Classroom tells you what a block does by its shape, and once you have noticed that, a whole set of questions answers itself:
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
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.
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.
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.
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
pressed| 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. |
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.
versus two hat blocks
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:
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.
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 which mistake you can afford. Then measure both, and pick the number that matches.
The Ultrasonic Sensor measures distance. It sends out a burst of sound too high for people to hear, listens for the echo, and works out how far away the surface is from how long the echo took — exactly how a bat finds a moth, and how a submarine uses sonar.
frontside| Block | What it does |
|---|---|
([4 v] distance in [cm v] :: sensors) | Reports how far away the nearest thing in front of the sensor is, as a number in centimetres. |
wait until <([4 v] distance in [cm v] :: sensors) < (15)> | Holds the program until something comes closer than 15 cm. |
This is the important step up from the Touch Sensor. Touch gives you true or false; the Ultrasonic gives you a number, and the deciding is left to you. Pick a threshold below and watch where the robot ends up.
The black line on the bar is the threshold; the blue fill is the reading. The robot stops the instant the fill crosses the line.
Three different robots, and only one number is different between them. That is what having a number rather than a yes-or-no buys you: the behaviour is tuned by editing one slot, not by rebuilding the program. It also means the sensor can never tell you it is “close” — close is a decision you make about a reading.
Car parking sensors, automatic doors at a shopping centre, and the sensor that stops a lift door closing on somebody all work this way. Reacting before contact is what makes a machine feel safe.
The Home/Retail EV3 set (31313) ships an Infrared Sensor and a Beacon in place of the Ultrasonic and Gyro sensors. The Infrared Sensor also measures distance, so the programs in this module work with it — but it reports a rough 0–100 proximity rather than real centimetres, and it is affected by sunlight and by dark surfaces in ways the Ultrasonic is not.
IR SensorBeaconSay this back before moving on: “Which would I rather have — a false alarm, or a miss?”
Wave a hand past the sensor, then push a slow object towards it. Watch how the reading behaves in each case. If the two look different on screen, the second axis is available to you.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The scoreboard. Two counts on screen, kept apart — that separation is the whole lesson made visible. |
| Medium Motor — the tail | The expensive action. Fast and dramatic on purpose: a strike should feel like something you would not want to waste. |
| Large Motor ×2 — the claws | The cheap warning. Opening the claws costs nothing, which is why a real scorpion tries it first. |
| Ultrasonic Sensor — the approach | All the evidence there is. Distance, and how fast it is changing — two numbers out of one sensor. |
| Touch Sensor — your verdict | Pressed by you after each approach to say “that really was a threat”. Without a human ground truth there is no table to fill in. |
Decide before you start what counts as a threat — a hand reaching for the model, say, and nothing else. If the rule changes while you are collecting data, the counts mean nothing and the comparison is worthless.
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 |
|---|---|---|
| Tail (Medium) | A | The fast strike. |
| Left claw (Large) | B | The warning pair. |
| Right claw (Large) | C | The other half. |
| Your verdict (Touch) | 1 | Touch stays on 1 across the course. |
| The approach (Ultrasonic) | 4 | Ultrasonic stays on 4 across the course. |
Check your own build now:
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.
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.
EV3 until somebody changes it.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 stand out of the beam. You are the experimenter here, and an experimenter standing in front of the sensor is part of every measurement.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
One program, run three times at three thresholds. It is an experiment, not a demo — the output is a table.
when program starts :: events hat
set [threat gap v] to (25) :: variables // the number under test
set [struck v] to (0) :: variables
set [false alarms v] to (0) :: variables
set [misses v] to (0) :: variables
set [correct v] to (0) :: variables
set [armed v] to (1) :: variables
[A v] reset degrees counted :: motors
clear display :: display
// ---- the smoothed reading ----
when program starts :: events hat
forever
set [total v] to (0) :: variables
repeat (5)
set [total v] to ((total) + ([4 v] distance in cm)) :: variables
end
set [was v] to (gap) :: variables
set [gap v] to ((total) / (5)) :: variables
set [closing v] to ((was) - (gap)) :: variables
end
// ---- the decision ----
when program starts :: events hat
forever
wait until <<(gap) < (60)> and <(armed) = (1)>>
set [armed v] to (0) :: variables
set [did strike v] to (0) :: variables
[B v] run to position (60) [degrees v] at (60) % speed :: motors
[C v] run to position (-60) [degrees v] at (60) % speed :: motors
// watch this approach until it either crosses the line or goes away
repeat until <<(gap) > (70)> or <(did strike) = (1)>>
if <(gap) < (threat gap)> then
set [did strike v] to (1) :: variables
[A v] run to position (120) [degrees v] at (100) % speed :: motors
[A v] run to position (0) [degrees v] at (60) % speed :: motors
change [struck v] by (1) :: variables
play sound [Mechanical / Blip 4 v] :: sound
end
end
// ---- YOUR verdict: was that really a threat? ----
write [WAS IT A THREAT?] at line (1) :: display
reset timer :: control
set [truth v] to (0) :: variables
repeat until <(timer) > (3)>
if <[1 v] is pressed? :: sensors> then
set [truth v] to (1) :: variables
end
end
write [] at line (1) :: display
// ---- fill in the table ----
if <<(did strike) = (1)> and <(truth) = (1)>> then
change [correct v] by (1) :: variables
end
if <<(did strike) = (1)> and <(truth) = (0)>> then
change [false alarms v] by (1) :: variables
end
if <<(did strike) = (0)> and <(truth) = (1)>> then
change [misses v] by (1) :: variables
end
if <<(did strike) = (0)> and <(truth) = (0)>> then
change [correct v] by (1) :: variables
end
write (false alarms) at line (4) :: display
write (misses) at line (6) :: display
write (correct) at line (8) :: display
[B v] run to position (0) [degrees v] at (40) % speed :: motors
[C v] run to position (0) [degrees v] at (40) % speed :: motors
wait until <(gap) > (70)>
set [armed v] to (1) :: variables
endarmed makes one approach into one decision. Without it a single hand hovering nearby fills the table with dozens of entries.closing is measured but not yet used. It is the second axis, waiting for the last modification.What success looks like: twenty approaches — ten genuine threats, ten harmless — and three numbers at the end that you wrote down. Then do it again at a different threshold.
Mix the order of your threats and non-threats. Ten of one then ten of the other lets you drift into pressing the button by habit, and your ground truth is then no better than the machine’s guess.
One change at a time. Predict, then run, then look. Twenty approaches each — fewer than that and the counts are noise.
closing above a small value as well as the distance. Re-run twenty approaches. If both counts fall, you did not tune better — you measured more.No threshold has zero mistakes. Choosing which ones to make is the job.
The Scorpion decides one approach at a time. It never looks at the whole situation before committing to anything.
The next model does. The Elephant has a heavy trunk and several joints, and moving them one at a time is slow and clumsy — the interesting version coordinates them so they all arrive together.
Arriving together is not the same as starting together — a joint with further to travel has to move faster, and working out how much faster is what turns a machine’s movement from mechanical into lifelike.
Today the machine chose its mistakes. Next it learns to move all of itself at once.
Build the model before you read any further. Everything after this is about making it do something, and none of it will make much sense with nothing on the table in front of you.
Use the viewer's own controls to zoom and turn pages. Fullscreen makes it big enough to build from.
The same build on Google Drive — sometimes a video, sometimes a scan:
Use the viewer's own controls to zoom and turn pages. Fullscreen makes it big enough to build from.
Check the finished build against the picture before you switch anything on. A motor mounted the wrong way round is far easier to spot now than it is to debug later, when it looks like a program fault.
Work through the challenges in order — each is harder than the last. The mission comes after all three, and it is meant to make you plan before you build.
Fill in the table three times. Twenty approaches at 40 cm, twenty at 25, twenty at 10 — ten genuine threats and ten harmless in each, mixed in order. Report all three rows: false alarms, misses, correct. Three rows of counts is the deliverable, not a working machine.
State the policy before you look at the data. Write down, in words, which mistake you would rather make and by how much. Then pick the row that matches. Say whether it is the row with the fewest total mistakes. If it is not, explain why that is the right answer anyway.
Escape the trade-off with better information. Add how fast the object is closing as a second condition, and re-run twenty approaches. If BOTH counts fall, you did not tune better — you measured more. Report both tables and say which of the two things you did.
Set the threshold for somebody else's rules. Run the machine for two different scenarios with the same hardware and the same data-gathering program. Scenario A: a scorpion with plenty of venom facing frequent predators — a miss is disastrous, a wasted strike is cheap. Scenario B: a scorpion nearly out of venom — a wasted strike may be its last, and it can survive being wrong once. Requirements: 1. Twenty scored approaches per threshold, with false alarms and misses in separate counters at all times. 2. Threats and non-threats defined before you start and unchanged throughout. 3. Threats and non-threats mixed in order, so you cannot press the verdict button out of habit. 4. A different chosen threshold for A and for B, each justified from the same table. 5. The armed logic working, so one approach produces exactly one row. Then write the two sentences that matter: what threshold you chose for each scenario, and what the machine gets wrong at that setting. Every machine that decides anything is wrong sometimes. Saying in advance which way it will be wrong — and being able to show the numbers — is the difference between an engineer and somebody who got lucky.