EV3 Robotics›Level 3 · Advanced›Lesson 37
Level 3 · Lesson 37 · EV3-L03-3760 minutes · Ages 9–16 · Model: EV3 Red Light Green Light
The Red Light Green Light machine: a doll that turns to face the players, an Ultrasonic Sensor watching whether anybody moved, and a finish switch for whoever gets there.
Lesson 8’s wooden man ran the same game and measured reaction times. This one does something harder: it judges. When the doll is facing, movement is against the rules, and the machine has to catch it.
By the end of the lesson your machine will referee a game fairly enough that the players accept its decisions — which is a much higher bar than getting the code to run.
Automated officiating is now everywhere in sport. Hawk-Eye tracks a tennis ball to a couple of millimetres. Goal-line technology decides in under a second whether a football fully crossed the line. Swimming touchpads decide races that human eyes cannot split.
Every one of those systems has a precisely defined window. Goal-line technology does not care where the ball is during a throw-in. A false start is only a false start between the set command and the gun — a fraction of a second either side and the same movement means nothing.
Because a rule is not “do not move”. It is “do not move, during this period, in this place”. An official who watched all the time would penalise players for walking back to the start.
And every system gives notice. A sprinter hears “set” before the gun; a driver sees amber before red. A rule enforced without warning is a trap, and people will not accept decisions from a machine that behaves like one.
A referee that catches things outside the window is not strict — it is wrong, and it will be argued with. A referee that misses breaches inside the window is ignored. Both destroy the game, and neither is a programming failure exactly.
A rule has a window. Enforce it only inside, and give notice before it starts.
Enforcing a rule is three separate things, and mixing them up is where every bug in this lesson comes from: when the rule applies, what counts as breaking it, and what happens when it is broken.
| Part | On this machine | Gets wrong when… |
|---|---|---|
| The window | While the doll is facing the players, and not before. | The check runs while the doll is still turning — players are caught for moving before the rule applied. |
| The breach | The measured distance changed by more than a tolerance. | The tolerance is smaller than the sensor noise, so standing perfectly still is a breach. |
| The consequence | Sound, message, and that player goes back. | It is silent, so players do not know why they were sent back. |
The sensor cannot see movement. It sees distance. Movement is a change in distance between two moments — which is Lesson 31’s derived value, doing something with real consequences.
// the instant the rule starts applying, record the scene set [frozen at v] to (smoothed) :: variables // then, while the rule applies, watch for a change if <([abs v] of ((smoothed) - (frozen at))) > (tolerance)> then broadcast [caught v] :: events end
The snapshot must be taken when the window OPENS, not when the doll starts turning. A player who is mid-step as the doll begins to turn has not broken any rule yet, and a machine that records the scene too early will catch them for it.
Nobody stands perfectly still, and the Ultrasonic reading wanders by a centimetre or two anyway (Lesson 14). A tolerance of zero catches everybody instantly; a tolerance of thirty centimetres lets players stroll.
Set it from the noise, not from an opinion. Measure how much the reading wanders with a person standing still, then set the tolerance a little above that — the same reasoning as Lesson 10’s deadband, applied to a rule instead of a control loop.
play sound [Mechanical / Blip 4 v] :: sound set status light to [red v] :: display [A v] run [clockwise v] for (180) [degrees v] at (90) % speed :: motors wait (0.4) seconds :: control set [frozen at v] to (smoothed) :: variables set [watching v] to (1) :: variables
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.
A broadcast lets one stack tell another to start. The sender does not need to know who is listening — it announces, and any stack waiting for that message runs.
| Block | What it does |
|---|---|
broadcast [message1 v] :: events | Sends the message and carries straight on. |
broadcast [message1 v] and wait :: events | Sends the message and holds until every stack that received it has finished. |
when I receive [message1 v] :: events hat | Starts this stack whenever that message is sent. |
Both send the same message to the same stack. The difference is what the sender does next — which is invisible in a listing, because the two blocks sit in exactly the same place. Use the switch to try each one.
the sensor stack
the motor stack
The sender never names the receiver — it announces, and whoever is listening runs. That is what lets the motors keep exactly one owner.
Plain broadcast is the right choice when the two jobs are genuinely independent: announce it and get on with your own work. broadcast and wait is the right choice when what comes next depends on the receiver having finished — do not start reversing until the stack that stops the motors has actually stopped them.
Broadcasting splits a program into parts that each do one job. A stack that watches the sensors can announce obstacle; the stack that owns the motors reacts. Neither needs to contain the other’s code, and the motors still have exactly one owner.
Here is a driving base doing exactly that. Three stacks are running: one sets the wheels going, one does nothing but read the Ultrasonic Sensor, and one owns every movement from then on. Follow the distance rather than the wheels — and notice what it is still doing while the message is crossing.
the driving stack — sets it going, then it is done
the watching stack — no motor block in it at all
the motor stack — owns every movement after the start
Watch the distance at the moment the message is sent. It keeps falling, because a broadcast starts another stack — it does not stop this one.
The watching stack contains no motor block anywhere, and the motor stack never reads the sensor. That is the whole trick: each stack is short enough to hold in your head, and the message is the only join between them. Splitting it this way also means the base can be made to dodge left instead of right by editing four blocks in one place, without going anywhere near the sensor.
Watch the gap in the middle of the run. broadcast does not mean stop — the wheels keep turning right through it, and the base creeps another 3 cm closer before the receiving stack gets as far as its stop moving block. If a robot must halt on the spot, that gap is why it will not.
Any number of stacks can listen to the same message, so one announcement can set several things going at once — stop the motors, sound an alarm and turn the light red. And nothing in the sending block says which of those will happen. Press one and find out.
Press a broadcast block. Nothing in it says what will happen — the stack that receives it decides.
Nothing has been sent yet. Press one of the three yellow blocks above.
Three messages, three receivers, one Brick. The blocks you press are identical apart from the name in the dropdown — so whatever happens next was decided entirely by the when I receive stack at the other end. Press all three quickly: nothing queues, because three separate stacks run at the same time. Press the same one twice while it is still going and its stack starts again from the top.
A message called message1 tells a reader nothing. One called obstacle-found explains the whole design at a glance. Names matter more here than almost anywhere else, because the sender and the receiver may be far apart on screen.
Warn, then snapshot, then judge — and only for as long as the rule applies.
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: “When does the rule apply, and what changed since it did?”
Stand where a player would and watch the Ultrasonic reading for ten seconds without moving. How much does it wander? That number is the smallest fair tolerance.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The referee. Its screen and light must make the state of the game obvious from where the players are standing, not from where the programmer sits. |
| Large Motor — the doll | Turns to face the players. The turn is the warning, so it must be fast and unambiguous — a slow turn leaves players guessing whether the rule has started. |
| Ultrasonic Sensor — the eyes | Watches the nearest player. Note it reports one distance, not one per player — the machine can catch somebody moving without knowing who. |
| Touch Sensor — the finish | Pressed by whoever reaches the doll. It ends the game, and it must work even mid-judgement. |
The sensor sees the nearest thing, and that is a real limitation. With several players it cannot tell which one moved, and a machine that penalises the whole line for one person’s movement will be argued with. The mission asks you to deal with that honestly rather than pretend it away.
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 |
|---|---|---|
| The doll (Large) | A | The only motor. |
| Finish (Touch) | 1 | Touch stays on 1 across the course. |
| The eyes (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.
Download and unplug — then stand well back. You are about to be one of the players, and a person standing beside the machine is a person the sensor can see.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
One stack runs the game’s phases; another watches for a breach, but only while it is allowed to.
when program starts :: events hat
set [watching v] to (0) :: variables
set [caught v] to (0) :: variables
set [tolerance v] to (6) :: variables
clear display :: display
// ---- the smoothed reading, computed once for everybody ----
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 [smoothed v] to ((total) / (5)) :: variables
end
// ---- the game's phases ----
when program starts :: events hat
forever
// GREEN — moving is allowed, nothing is watching
set [watching v] to (0) :: variables
set status light to [green v] :: display
write [GREEN - GO] at line (1) :: display
[A v] run [counterclockwise v] for (180) [degrees v] at (90) % speed :: motors
wait (pick random (3) to (7)) seconds :: control
// WARNING, then the turn
play sound [Mechanical / Blip 4 v] :: sound
[A v] run [clockwise v] for (180) [degrees v] at (90) % speed :: motors
// settle, THEN snapshot, THEN start judging
wait (0.4) seconds :: control
set [frozen at v] to (smoothed) :: variables
set [watching v] to (1) :: variables
set status light to [red v] :: display
write [RED - FREEZE] at line (1) :: display
wait (pick random (2) to (5)) seconds :: control
set [watching v] to (0) :: variables
end
// ---- the judge: only acts inside the window ----
when program starts :: events hat
forever
if <(watching) = (1)> then
set [moved by v] to ([abs v] of ((smoothed) - (frozen at))) :: variables
write (moved by) at line (5) :: display
if <(moved by) > (tolerance)> then
set [watching v] to (0) :: variables
change [caught v] by (1) :: variables
play sound [Mechanical / Error v] :: sound
write [CAUGHT MOVING] at line (3) :: display
wait (2) seconds :: control
write [] at line (3) :: display
end
end
end
// ---- somebody finished ----
when program starts :: events hat
wait until <[1 v] is pressed? :: sensors>
set [watching v] to (0) :: variables
[A v] stop motor :: motors
write [WINNER!] at line (1) :: display
play sound [Communication / Cheering v] until done :: sound
stop [all v] :: controlwatching before doing anything. Outside the window it is silent — a green-light sprint must not be penalised.What success looks like: players advance during green, freeze on red, and somebody who shuffles is caught with a noise and a message — while somebody genuinely still is not.
If it catches everybody instantly, the tolerance is below the sensor noise — raise it to a little above the wander you measured. If it never catches anybody, the tolerance is larger than a step, or the snapshot is being retaken inside the loop.
One change at a time. Predict, then run, then look. Play the game with real people for each — a referee is only testable against players.
Test a referee by playing against it. Code that runs is not the same as decisions people accept.
Your referee has one response: caught, or not. A player twenty centimetres over the line and one who shuffled a fraction get exactly the same treatment.
The next model responds in degrees. Znap watches something approach and does not simply strike — it stirs, then threatens, then snaps, depending on how close and how persistent the intruder is.
A graded response says more than a binary one, and it is how almost every animal warns before it acts. Building the ladder of reactions — and making sure it can climb back down — is the next lesson.
Today the machine judged yes or no. Next it learns to say “not yet”.
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.
Find the smallest fair tolerance. Have somebody stand still at the far end for ten seconds and record the highest and lowest reading. Then have them take one small step and record the change. Report both numbers and the tolerance you chose from them. A tolerance picked without those two numbers is a guess dressed up as a rule.
Break the window on purpose. Move the snapshot to before the turn instead of after it. Play one round and watch somebody get caught for moving while the rule did not yet apply. Then put it back, and write one sentence on why the settle delay is a fairness measure and not an accuracy one.
Make the decision arguable. Put the measured movement on screen during every red phase, and freeze the number that triggered a catch so the player can see it. Then have a player dispute a call and settle it with the number. Evidence is what turns a machine decision into one people accept.
Referee a real game. Run Red Light Green Light for at least four people who have not seen the machine before, from a marked start line to a marked finish. Requirements: 1. A warning before every red phase, so nobody is caught without notice. 2. The snapshot taken after the doll has settled, never before. 3. A tolerance you can justify from measured noise, written on the board. 4. The movement number visible on screen, so every call can be checked. 5. The finish switch works even mid-judgement. Then deal honestly with the machine's real limitation: the Ultrasonic Sensor reports one distance, so with several players it can catch somebody moving without knowing who. Write down how you handled it — one player at a time, a narrower beam, a rule that the whole line goes back — and why your choice is fair. A referee that pretends to know more than it does is worse than one that admits the limit.
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.
