EV3 Robotics›Level 3 · Advanced›Lesson 7
Level 3 · Lesson 7 · EV3-L03-0760 minutes · Ages 9–16 · Model: EV3 Robot Chicken
The Robot Chicken: a bird that walks, stops, pecks and looks up, with an Ultrasonic Sensor in its head watching the ground ahead of it.
A real chicken does not do all of those at once, and neither will yours. It does one of them, and which one depends on what it was doing a moment ago as much as on what it can see now.
By the end of the lesson your chicken will move between four named behaviours on its own — and the program will say, in one word on the screen, which one it is in.
Watch a chicken foraging and you will see it cycle through a small set of distinct behaviours: walk a few steps, stop, scratch, peck, then lift its head and look around. Ethologists call these behavioural states, and the striking thing is how sharp the boundaries are. A chicken is not half-pecking and half-scanning. It is doing one, then the other.
The head-up scan is not optional. A bird with its beak in the ground cannot watch for predators, so it must stop feeding to look. That trade-off — you cannot be in two states at once — is what shapes the whole rhythm.
Because attention is a limited resource, and so is a machine’s. A washing machine is filling, or washing, or spinning, or draining — never two. A traffic light is red, or amber, or green. A lift is idle, or moving, or holding doors.
In every case there is a small list of states, and a small list of events that move you from one to another. Engineers draw this as circles with arrows between them and call it a state machine. It is one of the most useful pictures in the subject.
A washing machine that tried to spin while filling would flood. A lift that moved while its doors were open would be lethal. The states are not a tidy way of describing the machine — they are what stops it doing two incompatible things at once.
A machine in exactly one state at a time cannot contradict itself.
Last lesson ended stuck: conditions describe now, so nothing could latch. The fix is a variable whose whole job is to hold which mode the robot is in — and rules that both read it and change it.
A state machine is four states and the arrows between them. Write this out before touching a block:
| State | What the chicken does | Leaves when… | Goes to |
|---|---|---|---|
walk | Legs run; head up. | Something is close ahead | stop |
stop | Everything still. | Half a second has passed | peck |
peck | Head down and up, three times. | The pecks are done | scan |
scan | Head up, turning, looking. | Nothing is close any more | walk |
Every state must have a way out. Read the table again and check each row’s “leaves when” can actually happen. A state with no exit is a robot that has frozen, and it is the commonest bug in this lesson by a wide margin.
when program starts :: events hat
set [state v] to [walk] :: variables
forever
write (state) at line (1) :: display
if <(state) = [walk]> then
[B v] start motor at (40) % speed :: motors
if <([4 v] distance in cm) < (15)> then
set [state v] to [stop] :: variables
end
end
if <(state) = [stop]> then
[B v] stop motor :: motors
wait (0.5) seconds :: control
set [state v] to [peck] :: variables
end
end| Conditions alone (Lesson 6) | A state machine (today) | |
|---|---|---|
| Decides using | Only what is true now. | What is true now and what mode it is in. |
| Can it latch? | No. Let go and it reverts. | Yes. It stays until something moves it on. |
| Same input, twice | Always the same result. | Can do different things — because the state differs. |
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.
Up to now a robot has been able to wait for a sensor. Deciding is different: the robot checks the sensor and does one thing or another depending on the answer — and then carries on either way.
| Block | What it does |
|---|---|
if <> then end | Runs the blocks inside only when the condition is true. Otherwise skips them. |
if <> then else end | Runs one set of blocks when true and a different set when false. |
A decision made once, at the start, is almost never what you want. Here are two robots with the identical if-else, testing the identical sensor against the identical number — one inside a loop and one not.
decision inside a loop
the same decision, once
A decision is only worth as much as the last time it was made. Inside a loop, that is a few milliseconds ago.
Nothing is wrong with the right-hand program’s decision. It asked the question, got a truthful answer, and acted on it correctly. It simply never asked again, and the world moved on. Decisions belong inside a loop, so the robot keeps re-deciding as things change.
when program starts :: events hat
forever
if <([4 v] distance in [cm v] :: sensors) < (15)> then
stop moving :: movement
else
start moving [straight: 0] :: movement
end
endOnce there is more than one question, decisions can be arranged in four ways. They look nearly identical stacked up in the editor, which is exactly why they get muddled — the thing that differs is not what the blocks say, it is which routes through them exist.
One question sorts them almost completely:
| Are the questions… | Use | How many bodies can run |
|---|---|---|
| independent — any combination can be true | separate ifs | none, some, or all |
| one question, two answers | if / else | exactly one |
| the second only matters when the first is true | nested if | one, and only via the outer |
| mutually exclusive cases — exactly one should win | chained if / else | exactly one, the first that matches |
Each if is asked no matter what the others answered, so any number of them can fire on the same pass. That is the right shape when the conditions genuinely have nothing to do with each other.
forever
if <[3 v] is ambient light intensity [< v] (20) %? :: sensors> then
[A v] start motor [clockwise v] :: motors
end
if <[4 v] is distance [< v] (15) [cm v]? :: sensors> then
[D v] start motor [clockwise v] :: motors
end
endExactly one branch runs, every time. Reach for this whenever the robot must do something either way — and in preference to two ifs testing opposite conditions, which is the same idea written twice and can drift apart.
Putting one if inside another means the inner question is only ever asked when the outer one is true. Use it when the second question is meaningless otherwise: there is no point asking which side an obstacle is on when there is no obstacle.
if <[4 v] is distance [< v] (15) [cm v]? :: sensors> then
if <([2 v] angle :: sensors) < (0)> then
start moving [right: 50] :: movement
end
endWhen not to nest. If you only want “both true” and nothing happens at the outer level, an and says it in one block and reads better:
if <<[4 v] is distance [< v] (15) [cm v]? :: sensors> and <([2 v] angle :: sensors) < (0)>> then start moving [right: 50] :: movement end
Nesting earns its place when something happens at the outer level too, or when there is an else at each level and the two mean different things.
This is the shape for a list of cases where exactly one should win: colour bands, distance bands, speed ranges. EV3 Classroom has no else-if block, so you build a chain by putting the next if inside the else of the last one.
And here is why it matters, because this is the single commonest bug in this whole module. Three bands written as three separate ifs are each perfectly correct, and together they are wrong: a reading of 20 is under 30 and under 60 and under 90, so all three run and the last one to run is the one that sticks.
three separate ifs
chained — if / else / if
↑ the rest is inside the else — never asked
Separate ifs are not wrong here so much as unguarded: nothing stops a second one matching. Chaining is what makes “the first one wins” true.
The rule to carry away: if the cases are meant to be exclusive, they must be made exclusive. Chaining does it by construction. Separate ifs only work if you are careful to write non-overlapping bands yourself — light < 30, 30 to 60, 60 and over — which is more to get right and easy to break later.
This is the point at which a machine stops following a script and starts responding. A thermostat, an automatic door, a robot vacuum — all of them are a decision inside a loop.
Each state does one thing and knows one way out. Write the table first; the blocks are then just typing.
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.
Say this back before moving on: “What am I doing, and what would make me stop?”
Find the three electronic parts, then work the legs by hand and watch what the head does. On many chicken builds the two are linked, and that matters for your states.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The body. Today its screen shows the state name, which turns an invisible variable into something a class can watch. |
| Medium Motor — the head | Pecks and lifts. Medium because the head is light and a peck should be quick. |
| Large Motor — the legs | Drives the walking linkage. Large because walking legs push the whole bird along and stall easily on carpet. |
| Ultrasonic Sensor — in the head | Looks ahead for food or an obstacle. It is what triggers the change out of walk. |
| The leg linkage (not electronic) | Turn it by hand through a full stride. If the bird lifts and drops rather than sliding, the walk will look right; if it scrapes, drop the speed later rather than forcing it. |
Check what the sensor sees when the head is down. If the head pecks towards the floor, the Ultrasonic reading collapses to a couple of centimetres mid-peck — which will look like an obstacle to a badly written state. It is one reason peck is its own state and does not check for obstacles at all.
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 |
|---|---|---|
| Head (Medium) | A | The detail motor, first port. |
| Legs (Large) | B | The locomotion motor. |
| 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, because this one walks. A tethered chicken drags its cable, and the drag changes the walking — which then changes when the sensor sees something, which changes the states. Cut that variable out.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
All four states. Notice the shape repeats exactly — do the job, then decide whether to hand over.
when program starts :: events hat
set [state v] to [walk] :: variables
clear display :: display
forever
write (state) at line (1) :: display
if <(state) = [walk]> then
[B v] start motor at (40) % speed :: motors
if <([4 v] distance in cm) < (15)> then
set [state v] to [stop] :: variables
end
end
if <(state) = [stop]> then
[B v] stop motor :: motors
play sound [Animals / Cluck v] :: sound
wait (0.5) seconds :: control
set [state v] to [peck] :: variables
end
if <(state) = [peck]> then
repeat (3)
[A v] run [clockwise v] for (60) [degrees v] at (70) % speed :: motors
[A v] run [counterclockwise v] for (60) [degrees v] at (50) % speed :: motors
end
set [state v] to [scan] :: variables
end
if <(state) = [scan]> then
[A v] run [clockwise v] for (30) [degrees v] at (30) % speed :: motors
[A v] run [counterclockwise v] for (30) [degrees v] at (30) % speed :: motors
if <([4 v] distance in cm) > (25)> then
set [state v] to [walk] :: variables
end
end
endpeck does not look at the sensor at all. It is busy, its head is down, and its reading would be meaningless. A state is allowed to ignore inputs that do not apply to it.scan exits on 25 cm, not 15. If both used 15 the bird would flicker between walking and stopping at the boundary. The gap between the two numbers is deliberate — and it is the idea Lesson 10 is about.What success looks like: the chicken walks until something is close, clucks and stops, pecks three times, looks around, and walks off again once the way is clear — with the state name changing on screen at each step.
If it freezes in one state, that state has no way out. Look at the screen for its name, find that block, and ask: what would make this set state to something else? If the answer is “nothing”, you have found the bug.
One change at a time. Predict, then run, then look.
set state to scan from the peck state. Predict first. The chicken pecks for ever — a state with no exit, seen deliberately, so you recognise it when you cause it by accident.alarm, entered from any state when something comes within 5 cm: flap, squawk, and go back to walk. Update your paper table first.peck and watch it peck at nothing before joining the ring. Where a machine starts is part of its design.Draw the states and arrows on paper first. Every bug in this lesson is a missing arrow.
Your chicken remembers one thing: which mode it is in. It cannot remember a series of things.
Suppose you wanted it to record how far it walked between each peck, and then report the five longest walks at the end. One variable cannot hold five numbers — each new value would overwrite the last.
A list is a variable that holds many values in order, and can be added to while the program runs. That is the next lesson, and it is the last big data idea in Level 3.
A variable remembers one thing. A state machine remembers where it is. A list remembers everything that happened.
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.
Change one state without touching the others. Make the chicken peck six times instead of three, and add a cluck on every peck. You should only have opened one of the four state blocks. That containment is what states are for — say out loud which state you edited and why nothing else was affected.
Add a fifth state. Add "alarm": if anything comes within 5 cm from ANY state, the chicken flaps, squawks, and then goes back to walking. Update your paper table first — add the row, and draw the arrows in from every other state. A state you can enter from anywhere needs a check in every state, which is worth noticing.
Make it get tired. The chicken should walk more slowly and peck less each time round the cycle, until after four full cycles it stops in a new "rest" state for five seconds and then starts fresh. You need a variable that counts cycles alongside the state variable. Decide carefully where it goes up and where it resets — getting that wrong gives a chicken that either never tires or never recovers.
Give the chicken a convincing feeding routine, designed on paper before it is built. Draw the full state diagram first: every state as a circle, every transition as an arrow with the condition written on it. Your machine must have at least five states, and at least one state must be reachable from more than one other. Three rules: 1. Every state has at least one way out. Check every circle on your drawing has an arrow leaving it. 2. The current state is always shown on the screen. 3. No state may run for longer than ten seconds without either finishing or being interrupted. Then test it by trying to break it: put an obstacle right at a boundary distance, take it away mid-peck, block the chicken while it walks. A well-drawn state machine survives all three. Where yours does not, the missing arrow is on your drawing, not in your blocks.