EV3 Robotics›Level 3 · Advanced›Lesson 32
Level 3 · Lesson 32 · EV3-L03-3260 minutes · Ages 9–16 · Model: EV3 Insect
The Insect: a six-legged walker driven by two motors, with an Ultrasonic Sensor looking ahead and a touch antenna that feels what the sensor misses.
It has two jobs at once. One is a plan — cross the table. The other is a reflex — something touched the antenna, back off now. Both want the same two motors, and they want them at the same moment.
By the end of the lesson the reflex will always win, immediately, without the plan needing to know it exists — which is how animals and autonomous robots both handle the problem.
Touch a cockroach’s antenna and it is gone before you have finished reaching. The escape response runs through a handful of very large nerve fibres straight to the legs — it does not go up to anything that could be called a decision. Reaction times are measured in a few thousandths of a second.
Your own body does the same thing. Touch something hot and your arm is moving before you feel the pain — the reflex arc goes through the spinal cord and back, without waiting for the brain to be consulted.
Because thinking is slow and some things cannot wait for it. Evolution’s answer is a hierarchy: fast, simple responses that can override slow, clever ones — and crucially, the clever part is not asked for permission.
Robotics reached the same design. In the 1980s Rodney Brooks built robots as layers where a higher, faster layer could suppress a lower one, with no central planner at all. Simple layers that interrupt each other turned out to walk over rough ground better than one system trying to think it all through.
If the plan had to notice the obstacle, decide, and then act, the machine would have hit it already. And if both parts simply commanded the motors whenever they liked, the machine would receive contradictory orders several times a second and twitch.
Fast and simple must be able to override slow and clever — without asking.
Two behaviours, both live, both wanting the motors. This is not a state machine — the insect is not in walking mode or escaping mode. Both are running; the question is which one is allowed to drive.
when program starts :: events hat
forever
start moving [forward v] at (30) % speed :: movement
end
when program starts :: events hat
forever
if <[1 v] is pressed? :: sensors> then
start moving [backward v] at (40) % speed :: movement
end
end// THE REFLEX — fast, simple, and the only one that may seize control
when program starts :: events hat
forever
if <<[1 v] is pressed? :: sensors> or <([4 v] distance in cm) < (10)>> then
set [reflex v] to (1) :: variables
start moving [backward v] at (40) % speed :: movement
wait (0.6) seconds :: control
turn [right v] for (0.5) [rotations v] at (40) % speed :: movement
set [reflex v] to (0) :: variables
end
end
// THE PLAN — only allowed to drive while the reflex is not running
when program starts :: events hat
forever
if <(reflex) = (0)> then
start moving [forward v] at (30) % speed :: movement
end
end| State machine (Lesson 7) | Priority (today) | |
|---|---|---|
| How many behaviours run? | One. The state says which. | All of them, always. |
| Switching | A rule inside a state hands over. | A higher layer takes over. The lower one is not consulted. |
| Adding a behaviour | New state, and arrows to and from it. | New stack and one line in the flag check. Nothing else changes. |
| Best for | Phases of a task that follow each other. | Things that can happen at any moment and must not wait. |
Exactly one stack may command the motors at any instant, and the flag is what guarantees it. This is Lesson 11’s one-writer rule applied to actuators rather than to values — and breaking it produces the same class of bug: no error, no crash, just a machine that behaves unpredictably.
Real machines stack several. A number rather than a flag lets a higher layer override a lower one, and each behaviour only acts if nothing more urgent is running:
Each stack acts only when urgency is not above its own level. Adding a fourth behaviour is one stack and one number.
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.
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.
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
stack 2 · status light
stack 3 · drive base
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.
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.
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.
The urgent one takes control and the calm one checks before acting. Never both commanding 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.
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.
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
stack 2 · status light
stack 3 · drive base
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.
Say this back before moving on: “Is anything more urgent happening right now?”
Find both sensors, then work out what each one can detect that the other cannot. That difference is why the insect has two.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The body. Its status light shows which layer has control — green for the plan, red for the reflex — which makes priority visible from across a room. |
| Large Motor ×2 — the legs | Drive the walking linkages, steered like a tank. They are the contested resource — the thing both behaviours want. |
| Ultrasonic Sensor — ahead | Sees at a distance, but only straight ahead and only things that reflect well. The planning sense. |
| Touch Sensor — the antenna | Feels what the Ultrasonic missed: a table leg to the side, something soft, a chair. The reflex sense — and by the time it fires, contact has already happened. |
| The antenna wire (not electronic) | Should stick out in front and to the side, so it meets things before the body does. An antenna shorter than the insect is a sensor that reports collisions after they matter. |
The antenna must reach further than the widest part of the body. Its whole purpose is to touch first. If the insect’s shoulder hits a chair leg before the antenna does, the reflex never fires and the machine just pushes.
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 legs (Large) | B | The movement pair. |
| Right legs (Large) | C | The other half. |
| Antenna (Touch) | 1 | Touch stays on 1 across the course. |
| 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.
Bluetooth — this one walks into things on purpose. A cable will be dragged over the obstacles you have laid out, and it will trip the antenna at random, which is a very confusing fault to debug.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Build the broken version first. You need to see two stacks fighting over the motors before the flag looks like anything but extra work.
when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
forever
start moving [forward v] at (30) % speed :: movement
end
when program starts :: events hat
forever
if <[1 v] is pressed? :: sensors> then
start moving [backward v] at (40) % speed :: movement
end
endwhen program starts :: events hat
set movement motors to [B v] and [C v] :: movement
set [urgency v] to (0) :: variables
clear display :: display
// ---- LAYER 2: the reflex. contact has already happened. ----
when program starts :: events hat
forever
if <[1 v] is pressed? :: sensors> then
set [urgency v] to (2) :: variables
set status light to [red v] :: display
write [BUMPED] at line (1) :: display
start moving [backward v] at (45) % speed :: movement
wait (0.7) seconds :: control
turn [right v] for (0.6) [rotations v] at (40) % speed :: movement
set [urgency v] to (0) :: variables
end
end
// ---- LAYER 1: obstacle ahead. only if nothing more urgent. ----
when program starts :: events hat
forever
if <<(urgency) < (2)> and <([4 v] distance in cm) < (15)>> then
set [urgency v] to (1) :: variables
set status light to [orange v] :: display
write [AVOIDING] at line (1) :: display
turn [left v] for (0.4) [rotations v] at (35) % speed :: movement
set [urgency v] to (0) :: variables
end
end
// ---- LAYER 0: the plan. drives only when nothing else wants the motors. ----
when program starts :: events hat
forever
if <(urgency) = (0)> then
set status light to [green v] :: display
write [WALKING] at line (1) :: display
start moving [forward v] at (30) % speed :: movement
end
endurgency < 2 — before it claims the motors.What success looks like: the insect walks (green), turns away from things it can see (orange), and reverses instantly when the antenna is touched (red) — even mid-turn.
If it never walks again after a bump, the reflex did not reset urgency. Watch line 1 — whatever it says last is the layer that never let go.
One change at a time. Predict, then run, then look.
set urgency to 0. Predict what happens before you run it, then check line 1 to confirm you were right.Adding a behaviour should cost one stack and one number. If it costs edits everywhere, the priority is not really in one place.
Your insect decides everything for itself. The last three lessons of this set hand control back to a person — and the first of them asks a question the menu in Lesson 20 could not.
A menu chooses between things somebody listed in advance. But a microwave has to let you enter ninety seconds, and nobody can list every possible number of seconds.
Entering a value is a different problem from picking an option — and doing it with four buttons and one line of screen takes a genuine piece of interface design, which is the next lesson.
Today the machine decided who wins. Next, a person tells it a number.
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.
Build the fight, then fix it. Write two stacks that both command the motors — one driving forward for ever, one reversing while the antenna is pressed. Hold the antenna and watch the insect judder. Then add the flag and watch it behave. Say which earlier lesson this bug is.
Swap the priorities. Make the obstacle layer outrank the antenna. Then push the antenna while an obstacle is in view and watch the insect ignore a contact it has already made. Write one sentence on why the fastest, simplest sense should usually win.
Add a fourth layer. At urgency 3: if the antenna is held for more than a second, stop entirely and flash red until it is released. It should cost you one stack and one number. If it cost more, your priority is not really in one place.
Cross a cluttered table. Set out a course with at least four obstacles — some the Ultrasonic can see, at least two it cannot (a chair leg approached at an angle, something soft, something low). The insect must get from one end to the other without being touched by a human. Three rules: 1. At any instant exactly one layer commands the motors, and you can point at the line that guarantees it. 2. Every layer releases control when it finishes. Prove it by running the course three times without restarting. 3. The status light and screen always say which layer has control, so a stuck insect can be diagnosed from across the room. Then swap courses with another group and run theirs. A machine tuned to one obstacle course and helpless on another has been tuned rather than designed — and finding that out is worth more than a clean run on your own table.