EV3 Robotics›Level 3 · Advanced›Lesson 21
Level 3 · Lesson 21 · EV3-L03-2160 minutes · Ages 9–16 · Model: Flying Chair big
The Flying Chair: a fairground swing ride — chairs hanging on chains from a rotating top, which swing outwards as it spins up.
One Medium Motor turns the whole thing, and there is one button and no screen. That is the constraint the lesson is built on: the ride has several speeds, and a single switch has to reach all of them.
By the end of the lesson each press of that one button will move the ride to its next setting, and round again from the end — the interface every kettle, desk fan and torch in your house uses.
A chairoplane looks like the chairs are being flung outwards. Nothing flings them. The chains pull them inwards, towards the middle, and that inward pull is the only horizontal force there is — it is what bends their path into a circle instead of a straight line.
The faster it turns, the more inward pull is needed, and the only way the chains can supply more is by hanging at a steeper angle. So the chairs rise — not because something pushed them out, but because they are being pulled in harder.
Now look at the ride’s controls. There is no keyboard in the operator’s booth. There is a lever or a couple of buttons, because a machine used by a person standing in the rain all day must be operable without looking and without reading.
Most machines you own work this way. A desk fan cycles off → low → medium → high → off from one switch. A torch cycles bright → dim → flashing. A kettle has one button that means “the next thing”.
A ride with one button per speed needs five buttons, five labels and five things to go wrong in the wet. And the operator still has to look down to find the right one.
When there is only one control, it cannot mean a choice. It has to mean “next”.
Lesson 7 gave you a state variable and rules that change it. Lesson 20 let a user choose a state from a menu. Today the user has one button and no screen, so the button cannot name a state — it can only advance to the next one.
when program starts :: events hat
set [mode v] to (0) :: variables
forever
wait until <[1 v] is pressed? :: sensors>
wait until <not <[1 v] is pressed? :: sensors>> :: control
change [mode v] by (1) :: variables
if <(mode) > (3)> then
set [mode v] to (0) :: variables
end
endWait for the press, then wait for the release. Both, in that order. The loop runs hundreds of times a second and a finger stays on a button for a tenth of one. Without the second wait, one press advances the mode twenty or thirty times and the ride ends up somewhere nobody chose — and, because the number of advances depends on how long the finger stayed, it lands somewheredifferent each time.
This is Level 2’s edge detection from Lesson 38. There it was tidiness. Here the whole interface fails without it, which is why it is worth meeting twice.
| Menu (Lesson 20) | Cycling (today) | |
|---|---|---|
| Needs | A screen and three or four buttons. | One button. A screen is optional. |
| Reaching mode 4 of 5 | Scroll to it and confirm — no side effects. | Pass through 1, 2 and 3 on the way, and the machine does each of them. |
| Going back one | One press of Up. | All the way round. |
| Best for | Many options, or options with consequences. | Three or four options that are all harmless to pass through. |
That is the real design cost, and it decides where cycling belongs. Cycling a fan through medium on the way to high is fine. Cycling a machine through “full speed” on the way to “stop” is not, and no amount of good code makes it acceptable.
The Brick has a status light and a speaker. A different colour per mode, or a number of beeps matching the mode, gives feedback to somebody who is looking at the ride rather than at the Brick.
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 ring of light around the Brick’s buttons can be set to green, orange or red. It is the fastest possible way for a robot to say what it is doing — no reading required, visible from across the room.
| Block | What it does |
|---|---|
set status light to [green v] :: display | Sets the ring to a chosen colour and carries straight on. |
set status light to [red v] :: display | The same block with a different colour picked from the dropdown. |
set status light to [orange pulse v] :: display | The three colours each have a pulse version, which flashes on and off until something changes it. A pulse reads as “busy”; a steady colour reads as “settled”. |
The light is most useful when each colour means one thing, consistently, for the whole program. Watch a short program set it three times as it goes.
the ring around the buttons is the status light
The light is the only output here you can read without looking at the screen — which is why it is worth setting deliberately at every stage of a program.
Nothing in that program is about the light — it starts, waits for a button, turns a motor and stops. The light is simply told the truth at each stage, and the result is a robot whose state you can read without touching it. A common scheme:
Machines everywhere signal with colour — traffic lights, a kettle’s power light, the charging light on a laptop. It also makes debugging far easier: set the light at each stage of a program and you can see how far it got without adding a single screen message.
Wait for the press, wait for the release, advance, wrap. Four lines, and the second wait is the one that matters.
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.
releasedpressed| Block | What it does |
|---|---|
wait until <[1 v] is pressed? :: sensors> | Holds the program here until somebody presses the sensor. |
<[1 v] is pressed? :: sensors> | Reports true or false. Drop it into a condition to make a decision rather than a wait. |
[1 v] when [bumped v] :: events hat | Starts a whole stack of its own. The dropdown chooses the moment: pressed, released or bumped. |
A button is not only “pressed”. One press is three things: the moment it goes down, the time it stays down, and the moment it comes back up. Watch what a single press does to three programs at once.
versus two hat blocks
The middle counter is the one that surprises people. Nothing is wrong with it — a loop really does check that fast, and every check really is a separate answer.
Nothing there is broken. A loop really does get round hundreds of times a second, and each time it asks is pressed? the honest answer is still yes — so if that loop plays a sound or counts something, it does it hundreds of times from one finger. The two hat blocks each fire once, and they fire at different moments: pressed the instant the button goes down, bumped only when it comes back up.
The three options, and what each is for:
when program starts :: events hat set movement motors to [B v] and [C v] :: movement start moving [straight: 0] :: movement wait until <[1 v] is pressed? :: sensors> stop moving :: movement
The robot drives until something presses the sensor. Note that the movement is started unmeasured on purpose — the sensor decides when to stop, not a distance.
Touch sensors are everywhere in machines you cannot see into: a lift knows the doors are shut, a printer knows the lid is closed, a washing machine will not spin until it is latched. They are safety devices as much as inputs.
Say this back before moving on: “One press, one step, and round at the end.”
Spin the top by hand and watch the chairs. How fast does it have to turn before they lift noticeably? That speed is the bottom of your useful range.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The tower and the base. Its status light is the whole display today — there is no screen in the user’s eyeline when they are watching the ride. |
| Medium Motor — the ride | Turns the top. Medium because the ride is light and wants a wide, controllable speed range rather than force. |
| Touch Sensor — the only control | Every setting the ride has must be reachable through this one switch. Mount it where an operator’s hand naturally rests. |
| The chairs and chains (not electronic) | Must hang free and all at the same length. One short chain makes one chair fly at a different angle, which looks like a fault and is a build problem. |
Give the chairs room, and start slow. At speed they swing out a surprising distance. Clear the table around the model before the first run — a chair catching on a pencil case at full speed will strip the top off the ride.
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 ride (Medium) | A | The only motor. |
| The button (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.
Download it, then unplug and operate it. Like Lesson 20, this machine is meant to be used away from a computer — and a cable near a spinning ride is asking for trouble.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Build the broken one first — you need to see what a missing release-wait does before the fix means anything.
when program starts :: events hat
set [mode v] to (0) :: variables
forever
if <[1 v] is pressed? :: sensors> then
change [mode v] by (1) :: variables
end
write (mode) at line (1) :: display
endwhen program starts :: events hat
set [mode v] to (0) :: variables
set status light to [off v] :: display
clear display :: display
forever
wait until <[1 v] is pressed? :: sensors>
wait until <not <[1 v] is pressed? :: sensors>> :: control
change [mode v] by (1) :: variables
if <(mode) > (3)> then
set [mode v] to (0) :: variables
end
play sound [Mechanical / Blip 2 v] :: sound
end
when program starts :: events hat
forever
write (mode) at line (1) :: display
if <(mode) = (0)> then
[A v] stop motor :: motors
set status light to [off v] :: display
write [STOPPED] at line (3) :: display
end
if <(mode) = (1)> then
[A v] start motor at (25) % speed :: motors
set status light to [green v] :: display
write [SLOW] at line (3) :: display
end
if <(mode) = (2)> then
[A v] start motor at (50) % speed :: motors
set status light to [orange v] :: display
write [MEDIUM] at line (3) :: display
end
if <(mode) = (3)> then
[A v] start motor at (75) % speed :: motors
set status light to [red v] :: display
write [FAST] at line (3) :: display
end
endmode and is the only thing that changes it; the other reads it and drives the ride. One writer, many readers — Lesson 11.What success looks like: press once, the ride starts slow and the light goes green; press again for medium, again for fast, and once more to stop — every time, with no skipped or doubled steps.
If it sometimes jumps two modes, your switch is bouncing — add a short wait (0.1) seconds after the release wait. If it sometimes misses a press, you are pressing faster than the loop notices; check the second stack has no wait blocking it.
One change at a time. Predict, then run, then look.
Cycling is only kind when passing through the middle options is harmless. Check that before choosing it.
Your ride can be told what to do and will keep doing it, correcting nothing, because there is nothing to correct — a spinning ride has no target to miss.
The next model does. A basketball robot has to put a ball through a hoop, and the moment the ball leaves the launcher nothing the program does can change where it lands.
Some actions can be corrected while they happen, and some cannot. Knowing which is which — and putting all your accuracy before the point of no return — is the next lesson, and it is a genuine limit on everything Lesson 5 taught you.
A closed loop needs a second chance. Next: what to do when there is not one.
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.
Break it on purpose, then fix it. Delete the wait-for-release and press the button once. Watch the mode number race away and land somewhere different every time. Put it back, then explain to a partner in one sentence why one press became twenty.
Add a fifth speed, and a beep that says which mode you are in. One beep for mode 1, two for mode 2, and so on. Now the ride can be operated with your eyes on the chairs instead of on the Brick.
Reverse the order so it goes fast first. Hand it to somebody and ask them to set it to slow. Watch them cycle through full speed to get there. Write one sentence on when cycling is the wrong interface, using what you just saw.
Build a ride an operator could run all day without looking at the Brick. Requirements: - at least four settings, always starting from stopped - one button, and every setting reachable from it - the current setting announced without the screen — status light, sound, or both - the ride ramps between settings rather than snapping, so the chairs never jerk - a press that does not register is impossible to confuse with one that did Then the real test. Turn the Brick screen away from the operator entirely and ask somebody to set the ride to its second speed, then stop it. If they can do it without leaning round to read anything, the interface works. Finally, write down one machine in your house that cycles like this and one that does not, and say why each chose what it did.