EV3 Robotics›Level 3 · Advanced›Lesson 5
Level 3 · Lesson 5 · EV3-L03-0560 minutes · Ages 9–16 · Model: EV3 Flower Rafflesia
The Rafflesia: a huge, fleshy flower whose petals open and close on a single Medium Motor, with an Ultrasonic Sensor in the middle of the bloom watching for anything that comes close.
Every model you have programmed so far was told how far to move. This one is told where to end up, and left to work out the moving for itself — which means it can be pushed, held, or interfered with, and it will still get there.
By the end of the lesson your flower will hold its petals at an opening that tracks your hand — closer means wider — and it will keep correcting for as long as the program runs.
Rafflesia arnoldii grows in the rainforests of Sumatra and Borneo and produces the largest single flower on Earth — up to a metre across and around ten kilograms. It has no leaves, no stem and no roots. It lives inside a vine, and for most of its life it is nothing but threads within its host.
It smells of rotting meat, which is not an accident: it is advertising to carrion flies. The bloom lasts about five days, after up to nine months of the bud swelling. Everything about the plant is a long, slow adjustment towards one short event.
Plants do not follow a schedule; they follow feedback. A stem grows towards light because the shaded side elongates faster — a continuous measure and correct that runs for the plant’s whole life. A flower opens when temperature and moisture say so, not on a fixed date.
That is the difference between a schedule and a feedback loop. A schedule says “open on the twelfth of March”. Feedback says “keep checking, and adjust towards where you should be”. Only one of those survives a cold spring.
A machine driven by a schedule works only if the world matches the schedule. A thermostat that ran the heating for a fixed forty minutes would overheat the house on a mild day. A cruise control that held a fixed throttle would crawl up hills and race down them. Both work by measuring the gap and acting on it.
Do not tell a machine how far to move. Tell it where to be, and let it keep checking.
Everything you have written so far has been open loop: the program gives an instruction and never finds out whether it worked. A closed loop checks, every time round, and uses the difference to decide what to do next.
| Open loop (Levels 1–2) | Closed loop (today) | |
|---|---|---|
| The instruction | “Run 180 degrees.” | “Be at 180 degrees.” |
| If something blocks it | It fails and never knows. | It keeps pushing, because the gap is still there. |
| If the target moves | Nothing. The instruction is already given. | It follows, because the gap changed. |
| When it finishes | When the movement is done. | It does not finish. It keeps correcting. |
error = target − measured.The error carries two pieces of information at once. Its sign says which way to move — positive means one way, negative the other — and its size says how hard. You never need an if to choose a direction: the arithmetic already knows.
when program starts :: events hat [A v] reset degrees counted :: motors forever set [target v] to ((60) - ([4 v] distance in cm)) :: variables set [error v] to ((target) - ([A v] degrees counted)) :: variables [A v] start motor at ((error) * (0.5)) % speed :: motors end
if anywhere. Hand closer → target bigger → error positive → petals open. Hand away → error negative → motor reverses on its own.That 0.5 is the gain — how strongly the machine reacts to being wrong. Too small and it creeps towards the target and never quite arrives. Too large and it overshoots, corrects too hard the other way, and shakes.
Finding the gain is a practical job, not a calculation. You start low, raise it until the machine starts to wobble, then come back down. Every real control system in the world is tuned this way.
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.
A sensor that reports a number cannot be used to make a decision on its own — 23 is neither true nor false. An operator turns that number into an answer by comparing it with something.
| Block | What it does |
|---|---|
<(x) > (50)> | True when the left value is bigger than the right. |
<(x) < (50)> | True when it is smaller. |
<<> and <>> | True only when both conditions are true. |
<<> or <>> | True when at least one of them is. |
Forget the symbols for a moment. A comparison is a question about position on a number line: is x to the left of the other number, or to the right? Left is smaller, right is bigger — and that is the whole of it.
Drag the orange x and the black marker, and change the comparison. The green stretch is every position of x that would make the answer true — so you can see where the answer flips before you get there. Turn not on and watch the green jump to the other side.
Drag either marker, or use the arrow keys.
is x to the LEFT of it?
The lab above asks one question at a time: is this x true? A robot never has just one x, though — a sensor reading slides up and down all the time, so what really matters is which stretch of the line makes the condition true. This one draws the whole answer at once.
Drag the circle to move the number you are comparing against, and change the comparison. Everything shaded green is a value of x that would make it true.
Drag the circle, or use the arrow keys. It moves in steps of 0.2.
Every number to the left of 0.2 — but not 0.2 itself, so the circle is hollow.
Watch the circle, because it carries the part everyone gets wrong:
Now turn not on with x > 2 selected and watch two things happen together. The shading jumps to the other side, and the circle fills in — because “not greater than 2” means 2 or less, and 2 has to be part of it. That pairing is the whole reason a hollow circle is worth drawing.
Why a robot cares. Two conditions that look almost identical — light < 30 and not (light > 30) — differ by exactly one value, the reading of precisely 30. A robot sitting right on its threshold behaves differently under the two, and that is the sort of bug that only shows up occasionally and looks like a broken sensor.
These three join answers together rather than numbers. The trap is that English is looser than a program: “stop if it is close and the bumper is pressed” sounds like it covers both situations, when it covers neither on its own.
Flip the two conditions and watch the table. There are only four possible situations in total, and and and or differ on exactly two of them.
| close | bumper | and | or |
|---|---|---|---|
| true | true | true | true |
| true | false | false | true |
| false | true | false | true |
| false | false | false | false |
and is fussy: it wants both. Three of the four rows are false.
Two sensors are running below: an Ultrasonic reporting a number, and a Touch Sensor reporting true or false. Watch the comparison turn the number into an answer, and watch and and or disagree.
and was true in one row out of four. or was true in three. That is the whole difference, and it is why one of them makes a robot look broken.
The comparison is doing one job: it takes a reading that is neither true nor false and, by holding it against a number you chose, produces something a decision can use. The moment the blue fill crosses the black marker is the moment the answer changes.
The number you compare against is a design decision, not a fact. “Close” for a parking sensor might be 15 cm; for a robot arm it might be 3. Pick it by measuring what the sensor actually reads in the situation you care about, then leave a margin.
and narrows: both must hold, so the robot acts less often but more certainly — stop only if something is close and the bumper is pressed. or widens: either will do, so the robot acts more readily — stop if something is close or the bumper is pressed.
In the four situations above, and was true in one of them and or in three. That is the practical difference: swapping one for the other does not adjust a robot slightly, it changes how often it reacts at all.
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
BeaconMeasure. Subtract. Act in proportion. Repeat for ever — that is a closed loop, and it is the idea the rest of Level 3 is built on.
A sensor that reports a number cannot be used to make a decision on its own — 23 is neither true nor false. An operator turns that number into an answer by comparing it with something.
| Block | What it does |
|---|---|
<(x) > (50)> | True when the left value is bigger than the right. |
<(x) < (50)> | True when it is smaller. |
<<> and <>> | True only when both conditions are true. |
<<> or <>> | True when at least one of them is. |
Forget the symbols for a moment. A comparison is a question about position on a number line: is x to the left of the other number, or to the right? Left is smaller, right is bigger — and that is the whole of it.
Drag the orange x and the black marker, and change the comparison. The green stretch is every position of x that would make the answer true — so you can see where the answer flips before you get there. Turn not on and watch the green jump to the other side.
Drag either marker, or use the arrow keys.
is x to the LEFT of it?
The lab above asks one question at a time: is this x true? A robot never has just one x, though — a sensor reading slides up and down all the time, so what really matters is which stretch of the line makes the condition true. This one draws the whole answer at once.
Drag the circle to move the number you are comparing against, and change the comparison. Everything shaded green is a value of x that would make it true.
Drag the circle, or use the arrow keys. It moves in steps of 0.2.
Every number to the left of 0.2 — but not 0.2 itself, so the circle is hollow.
Watch the circle, because it carries the part everyone gets wrong:
Now turn not on with x > 2 selected and watch two things happen together. The shading jumps to the other side, and the circle fills in — because “not greater than 2” means 2 or less, and 2 has to be part of it. That pairing is the whole reason a hollow circle is worth drawing.
Why a robot cares. Two conditions that look almost identical — light < 30 and not (light > 30) — differ by exactly one value, the reading of precisely 30. A robot sitting right on its threshold behaves differently under the two, and that is the sort of bug that only shows up occasionally and looks like a broken sensor.
These three join answers together rather than numbers. The trap is that English is looser than a program: “stop if it is close and the bumper is pressed” sounds like it covers both situations, when it covers neither on its own.
Flip the two conditions and watch the table. There are only four possible situations in total, and and and or differ on exactly two of them.
| close | bumper | and | or |
|---|---|---|---|
| true | true | true | true |
| true | false | false | true |
| false | true | false | true |
| false | false | false | false |
and is fussy: it wants both. Three of the four rows are false.
Two sensors are running below: an Ultrasonic reporting a number, and a Touch Sensor reporting true or false. Watch the comparison turn the number into an answer, and watch and and or disagree.
and was true in one row out of four. or was true in three. That is the whole difference, and it is why one of them makes a robot look broken.
The comparison is doing one job: it takes a reading that is neither true nor false and, by holding it against a number you chose, produces something a decision can use. The moment the blue fill crosses the black marker is the moment the answer changes.
The number you compare against is a design decision, not a fact. “Close” for a parking sensor might be 15 cm; for a robot arm it might be 3. Pick it by measuring what the sensor actually reads in the situation you care about, then leave a margin.
and narrows: both must hold, so the robot acts less often but more certainly — stop only if something is close and the bumper is pressed. or widens: either will do, so the robot acts more readily — stop if something is close or the bumper is pressed.
In the four situations above, and was true in one of them and or in three. That is the practical difference: swapping one for the other does not adjust a robot slightly, it changes how often it reacts at all.
Say this back before moving on: “Where should I be, where am I, how big is the gap?”
Open and close the petals by hand and count how far the motor turns between shut and fully open. You need that number before you can give the loop a target.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The base of the flower. Today its screen is an instrument — you will watch the error on it while the loop runs. |
| Medium Motor — the petals | Drives all the petals through one linkage. Its own rotation counter is the measured half of the loop — the flower knows how open it is because the motor remembers. |
| Ultrasonic Sensor — in the bloom | Watches for a visitor. It supplies the target: nearer hand, wider flower. |
| Touch Sensor — the reset | Re-zeroes the petal count when the flower is fully shut. Without it, every restart guesses where “closed” is. |
| The petal linkage (not electronic) | Must move freely in both directions. A linkage that sticks makes the loop push harder and harder against nothing — you will hear the motor straining, and that is the loop doing its job on a broken machine. |
A closed loop will fight you, and that is the point. Hold a petal shut while the program wants it open and the motor pushes harder the longer you hold. Let go gently — do not fight it back, and do not hold it for more than a second or two.
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 |
|---|---|---|
| Petals (Medium) | A | The only motor, and the one whose degrees counter is half of the loop. |
| Visitor sensor (Ultrasonic) | 4 | Ultrasonic stays on 4 across the course. |
| Reset (Touch) | 1 | Touch stays on 1 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.
USB is fine and probably better. The flower does not go anywhere, and you will be adjusting one number — the gain — over and over, downloading each time. Anything that shortens that cycle is worth having.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Build it in two goes: a loop with a fixed target first, so you can see it hold a position, then let the sensor move the target.
when program starts :: events hat [A v] reset degrees counted :: motors set [target v] to (120) :: variables forever set [error v] to ((target) - ([A v] degrees counted)) :: variables [A v] start motor at ((error) * (0.5)) % speed :: motors write (error) at line (3) :: display end
Try this before going on. Push a petal gently closed and watch line 3: the error grows, the motor works harder, and when you let go it returns. That is the whole idea, and it is worth thirty seconds of playing with.
when program starts :: events hat wait until <[1 v] is pressed? :: sensors> [A v] reset degrees counted :: motors clear display :: display forever set [target v] to (((60) - ([4 v] distance in cm)) * (4)) :: variables set [error v] to ((target) - ([A v] degrees counted)) :: variables [A v] start motor at ((error) * (0.5)) % speed :: motors write (target) at line (2) :: display write (error) at line (4) :: display end
60 − distance flips the sensor round. Ultrasonic gives a bigger number when things are further away, and you want the opposite, so subtract it from a constant.× 4 converts centimetres into petal degrees. Your model’s number may differ — use the full-open figure you wrote down in step 8.if in it. The sign of the error is doing that work.What success looks like: move your hand towards the bloom and the petals open smoothly; take it away and they close. Hold still and they hold still, with the error hovering near zero.
If the petals slam open and shut and buzz, the gain is too high — drop 0.5 to 0.2. If they drift open lazily and never arrive, it is too low — try 0.8. If they run the wrong way entirely, swap the two terms in the subtraction.
One change at a time. Predict, then run, then look. Today you are tuning a control loop, which is a real engineering skill and is done exactly like this.
reset degrees counted inside the forever. The measured value is now always zero, so the error never shrinks and the flower runs away. A loop that cannot measure is not a loop.Too little gain never arrives. Too much never settles. Tuning is finding the edge and stepping back from it.
You have just written the most important four lines in Level 3. Every self-correcting machine — a thermostat, a drone holding altitude, a line follower, a self-balancing robot — is this loop with more terms added.
Two problems are already visible if you watched carefully:
× 4 and the gain were found for this flower, in this room. Lesson 12 turns that from guesswork into calibration.Before either of those, the next lesson asks a different question: what if the machine has to react to more than one condition at once, and treat some combinations differently from others? That is boolean logic, and it is a drum kit.
Open loop says what to do. Closed loop says where to be. Only one of them survives contact with the world.
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.
Tune it properly and write the number down. Find the gain that makes your flower follow a moving hand quickly without buzzing. Start at 0.2 and work up. Compare with another group. If your numbers differ, that is the right answer — the machines differ. Say what would have to change for your gain to work on their flower.
Stop it hurting itself. Right now a big error commands a big speed, and the petals will drive hard into their end stops. Limit the target so it can never ask for more than the fully-open figure you measured, and never less than zero. The loop should still correct — it just may not be asked for the impossible.
Make it breathe. With no hand present, the flower should slowly open and close on its own, about once every four seconds, as if breathing. The moment a hand comes within 30 cm it must switch to following the hand instead. The breathing is a moving target, not a different program — you are changing what the target is, not how the loop works.
Build a flower that behaves as if it were alive. It must respond to a visitor in a way that is convincing rather than mechanical, using nothing but a target that changes and a loop that chases it. Ideas worth trying: opening faster than it closes, hesitating before it commits, opening further for something that stays than for something passing. Two rules: 1. There is ONE closed loop in your program, and it never changes. All your behaviour comes from changing the target. 2. Nobody watching should be able to guess where the numbers came from. Before you build, write down in one sentence what you want a visitor to feel. Then work out what the target has to do to produce it. This is the first time in the course the interesting question is not "does it work" but "does it convince".
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.