Challenge 1
Make a flight with a clear take-off and a clear glide, and have the screen name which one is happening. Somebody across the room should be able to say when it switched without being told what to look for.
What you are building 3 min
The Pterosaur: a flying reptile with a long crested head and a wingspan far wider than its body, its wings driven up and down by a single motor through a linkage.
Lesson 13 taught your ride to decide whether to do something. This model needs more than that. A pterosaur is never doing nothing — it is either flapping or it is gliding, and it is always doing one of them.
That is a different kind of question. Not “should I?” but “which one?”
In the real world 5 min
Where you have seen it
Pteranodon hangs from the ceiling of natural history museums with a wingspan of six or seven metres and a body no heavier than a large dog. It lived at the same time as the dinosaurs — and was not one — and it fished the seas that covered much of North America.
Why it is built that way
Flapping is expensive. Moving those wings takes far more energy than holding them still, so a big flier does as little of it as it can get away with — it flaps to gain height or speed, then locks its wings and glides, losing height slowly while spending almost nothing.
Seabirds still do exactly this. An albatross can cross an ocean barely flapping at all, using the wind rising off the waves, and its wings are long and narrow for the same reason Pteranodon’s were.
What would go wrong without it
A flier that could only flap would run out of energy long before it found food. A flier that could only glide would sink to the sea and never get up again. Neither behaviour is any use on its own — the animal needs both, and needs to switch between them.
Some choices are not do-it-or-do-nothing. Some are always one thing or the other.
The main concept — two branches, always one taken 6 min
The Switch grows a second mouth. Whatever is in the hexagon, exactly one of the two halves runs — never both, and never neither.
if <([A v] degrees counted) < (1440)> then [A v] set speed to (70) % :: motors write [FLAP] at line (3) :: display else [A v] set speed to (15) % :: motors write [GLIDE] at line (3) :: display end
| if / then | if / then / else | |
|---|---|---|
| Condition true | Runs the inside. | Runs the top half. |
| Condition false | Does nothing at all. | Runs the bottom half. |
| Use it for | Something extra, sometimes. | Picking between two behaviours. |
It fixes last lesson’s trap, too
Lesson 13 ended with a beep that would not stop, because once the condition became true it stayed true and the if fired on every pass. An if/else has no equivalent problem for this job: whichever way the answer goes, exactly one thing happens per pass, so the machine settles into a behaviour instead of piling actions up.
That is not a rule about which block is better. It is a reason to ask what you actually want: an extra thing sometimes, or one of two things always.
Making a decision
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.
Blocks reference
| 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. |
Deciding again and again
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
forever
if distance < 15 then
stop moving
else · start moving
the same decision, once
if distance < 15 then
stop moving
else · start moving
247checks · in a loop1check · once only
Nothing is close, so both robots ask «is the wall within 15 cm?», both hear no, and both take the else branch and drive.
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
endFour shapes, and how to choose
Once 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 |
Separate ifs — independent questions
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
endif / else — one question, two answers
Exactly 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.
Nested if — a follow-up question
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.
Chained if / else — one winner out of several
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
if light < 30 then
stop
if light < 60 then
go slowly
if light < 90 then
go fast
chained — if / else / if
if light < 30 then
stop
else
if light < 60 then
go slowly
else
go fast
↑ the rest is inside the else — never asked
3bands matchedgo fastseparate ifs dostopchained does
Separate ifs: 3 matched, last one winsChained: first match wins, rest never asked
The sensor reads 20 — a dark surface. Both programs should stop.
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.
Why it matters
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.
If/then adds something. If/then/else chooses something.
Comparing numbersGreater than, less than, equals — and why the direction of the arrow matters here more than usual.Show meHide
Comparing and combining
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.
Blocks reference
| 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. |
Try it: which way round does it go?
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.
-3 < 4true
is x to the LEFT of it?
- < is true while x sits on the left. Slide x past the marker and it flips.
- > is the same question the other way round — so exactly one of the two is true, unless the markers are on the same spot.
- = is true for one single position out of twenty-one. Try landing on it. That is why a sensor is almost never compared with =: a reading passes straight through the exact number without ever being measured there.
- not flips the answer, whatever it was. not (x < 4) covers everything x < 4 does not — including landing exactly on 4.
Try it: which numbers make it true?
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.
x < 0.2x < 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:
- Hollow ○ — the boundary is not included. x < 0.2 shades everything left of 0.2 but leaves 0.2 itself out, because 0.2 is not less than 0.2.
- Filled ● — the boundary is included. Choose = and nothing is shaded at all: one single number qualifies.
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.
Try it: and, or, not
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: true and bumper: falsefalse
| 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.
- and is true on one row out of four. It narrows — the robot acts less often, but more certainly.
- or is true on three rows out of four. It widens — the robot acts more readily.
- The two agree on the top and bottom rows and disagree in the middle. Whenever swapping one for the other seems to make no difference, you have only tried the rows where they agree.
Watch them decide
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.
when program starts
forever
if distance < 15 and is pressed? then
stop moving
if distance < 15 or is pressed? then
play beep 60 for 0.2 seconds
Nothing is within 15 cm and the bumper is out. Both conditions are false.
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.
Choosing the threshold
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.
Combining two conditions
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.
Watch the direction of the comparison. This lesson uses less than, so the interesting behaviour is at the start and the calm one at the end. Turn the arrow round and your pterosaur glides first and flaps later — which is a perfectly good animal, but it is a different one.
Say this back before moving on: “One of the two always runs.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Chooses between two behaviours, several times a second, and reports which one it picked. |
| One motor — the wings | Drives both wings through a linkage, so they always beat together. Its encoder is also where the condition’s number comes from. |
| The wing linkage (not electronic) | Turns rotation into a beat. Like the Hammer Bot’s cam, it is heavier at one point in the cycle than another — which is why a slow glide sounds different from a fast flap, not just slower. |
| The Brick screen and speaker | Say which branch is running. On a machine that chooses, being able to see the choice is most of the debugging. |
Check both wings before you fly it
- Turn the motor by hand through one full beat. Both wings should rise and fall together and by the same amount.
- A wing that lags is a loose linkage pin. Find it now — at 70% it will come apart.
- Check the wings clear the body, the base and the cable at the top and bottom of the beat.
- Hold the model down. A flapping model on a light base walks, and this one has long arms to walk with.
Ports — and the rule 4 min
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 |
|---|---|---|
| Wing motor | A | One job motor. Its port appears in the start block, both speed blocks and the condition — four places, all of which must agree. |
| Sensors | none | The pterosaur decides from its own wingbeat count, not from anything it senses about the world. |
Check your own build now:
- Wing motor into A. Built from a video, so confirm it rather than assuming.
- Route the cable so it does not foul the wings at the top of the beat.
- Give it space on both sides — the wingspan is the widest thing you have built this level.
Connect the Brick 4 min
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.
How to connect the BrickUSB and Bluetooth, step by step, with a photograph of every screen. Open it if you have not done this before — or if pairing is not working.Show meHide
USB — the reliable one
- Switch the Brick on with the dark grey centre button.
- Cable into the Brick’s PC port — the small square socket beside the numbered ports, not one of the numbered ones.
- Other end into the computer.
Bluetooth — name it first
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.
- Name your Brick. On the Brick: Settings (the spanner) → Brick Name. Type something nobody else will pick, then press the tick. Every Brick is called
EV3until somebody changes it. - Turn Bluetooth on. Settings → Bluetooth. Tick Bluetooth and Visibility. Leave iPhone/iPad/iPod unticked.
- Connect from EV3 Classroom. Click the Brick icon at the top of the programming area, find your Brick by name, and click Connect.
- Say yes on the Brick. It asks “Connect?” with the computer’s name — choose the tick, then accept the passkey, which is already 1234.
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 if you can. A cable near a pair of beating wings gets caught, and a caught cable stalls the motor mid-branch.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- One motor tile on A.
- Turn the wings through four full beats by hand and watch the count. Four beats is roughly 1440 degrees — the threshold your else branch waits for.
- Check the number climbs rather than falls when you turn it the way the wings actually beat.
Make it move 10 min
Take off with hard flapping, then settle into a glide — and say which it is doing the whole time.
when program starts :: events hat
clear display :: display
[A v] reset degrees counted :: motors
write [PTEROSAUR] at line (1) :: display
[A v] start motor at (70) % speed :: motors
repeat (30)
if <([A v] degrees counted) < (1440)> then
[A v] set speed to (70) % :: motors
write [FLAP ] at line (3) :: display
else
[A v] set speed to (15) % :: motors
write [GLIDE] at line (3) :: display
end
wait (0.2) seconds
end
[A v] stop motor :: motors
write [MENDARAT] at line (5) :: display- reset degrees counted — so “four wingbeats” means four beats of this flight.
- start motor at 70% — take-off. Non-waiting, so the loop below can get on with deciding.
- the Switch — asked thirty times. Early on the count is small, so the top branch runs and it keeps flapping hard. Once the count passes 1440 the bottom branch runs instead.
- FLAP with a trailing space — five characters, same as GLIDE, so the shorter word does not leave a letter of the longer one behind on the screen.
What success looks like: fast, noisy flapping for the first few seconds with FLAP on screen, then a clear change to a slow heavy beat with GLIDE on screen. The transition should happen once and stay.
If it flickers between FLAP and GLIDE, your threshold is sitting right where the count happens to be hovering — most likely the wings are stalled and the count is barely moving. Look at the model rather than the program.
Change it and test 8 min
One change per run, and watch the word on the screen — it tells you which branch is running without you having to guess from the wings.
- Turn the comparison round: greater than 1440 instead of less than. Predict what the animal does before you run it, then watch it glide first and flap later.
- Delete everything in the else branch, leaving it empty. Run it. The pterosaur now flaps and then simply carries on flapping — because an empty else does nothing, and doing nothing means the last speed set stays.
- Put the else back and change the glide speed to 0. Wings stop dead. Is that a glide, or is it a dead bird?
- Change the threshold to 360 — one beat and it is gliding. Then 5000 — it never gets there and flaps the whole flight.
- Swap the two branches over completely, keeping the same condition. Same question, opposite answers. Compare with step 1 — you got to the same animal two different ways.
Step 5 is worth pausing on. Turning the comparison round and swapping the branches produce identical behaviour, which means there is more than one correct way to write the same decision. Pick whichever one reads more like the sentence you would say out loud.
An empty else is not the same as no else — but it looks the same from the outside, which is what makes it worth knowing.