EV3 Robotics›Level 1 · Beginner›Lesson 40
Level 1 · Lesson 40 · EV3-L01-4060 minutes · Ages 9–16 · Model: Drop Tower
The Drop Tower: a tower with a motorised lift that hauls a car to the top and lets it fall, and an eye at the bottom that watches for it landing.
This is the second of the course’s two reference builds. The Driving Base was a machine that did; this is the first one that notices. Once it is running you will be able to leave it alone and it will keep cycling by itself — lifting, dropping, waiting for the landing, lifting again — with nobody pressing anything.
The trick is not the tower. It is that the machine decides when to lift next by looking, rather than by counting seconds.
A drop tower is the tall ride that hauls a car of riders to the top, holds them there a moment, and lets them fall. There are ones you can ride at Genting Highlands.
Hauling the car up stores potential energy. Release it and gravity turns that into kinetic energy — the energy of motion — which is what the riders feel. Brakes near the ground take it out again safely.
But here is the part that matters for today: the ride does not lift the next group after a fixed wait. It waits until the car is actually down. A sensor at the bottom confirms it, every single cycle.
Run the ride on a timer instead and it works — right up until the day the car is slow. A gust of wind, a cold morning, a heavier load, and the machine starts the next lift while the car is still coming down. A timer assumes; a sensor checks. That difference is the whole lesson.
Lesson 1’s robot was blind. It did exactly what it was told for exactly as long as it was told, and it would have driven into a wall quite happily. Today the machine gets an eye, and starts deciding for itself when to move on.
Two ideas, and they only matter together:
A sensor turns something in the world into a number. A loop makes the robot read that number again, and again, for as long as it is switched on.
One without the other is not much use. A sensor read once is a snapshot — true when you looked and possibly wrong a second later. A loop with nothing to look at just repeats itself blindly. Put them together and you have the pattern underneath nearly every robot ever built: sense, react, repeat.
The Colour Sensor looks down at a surface and can answer three quite different questions: what colour is this?, how bright is this? and how light is the room? Choosing the wrong one is the usual reason a line-following robot refuses to work.
front
side| Block | What it does |
|---|---|
([3 v] color :: sensors) | Reports which colour it sees, from a short list — red, blue, green, black, white and a few more. |
([3 v] reflected light intensity :: sensors) | Reports how bright the surface is, as a number from 0 (black) to 100 (white). |
<[3 v] is color [red v]? :: sensors> | Reports true or false for one particular colour. |
([3 v] ambient light intensity :: sensors) | Reports how much light is falling on the sensor, 0 to 100, with its own lamp switched off. |
The sensor does not describe a colour — it picks one from a list of eight, and that list is the whole of what it can ever say:
| Reports | Means |
|---|---|
| 0 | no colour — too far away, or too dark to call |
| 1 · 2 · 3 | black, blue, green |
| 4 · 5 · 6 | yellow, red, white |
| 7 | brown |
Anything you put under it is forced into one of those eight. There is no orange and no purple: an orange brick comes back as red or as yellow, and often as red one moment and yellow the next as the robot creeps along. Light blue and grey are the other classic pair to avoid — grey is neither black nor white, so it flips between them.
This is why colour mode is a good fit for a task you control and a bad fit for one you do not. Sorting the LEGO bricks that come in the set works, because they are made in exactly these colours. Reading a printed sheet, a coloured tile from another set, or anything pastel is asking the sensor to answer a question it does not have a word for.
Two practical points follow from how it decides. It shines its own lamp and looks at how much red, green and blue comes back, so it must be close — about half a centimetre, and no more than a centimetre. Lift it and the answer decays to 0. And because it takes those three readings before it can answer, colour mode is the slowest thing this sensor does; a robot driving quickly can pass right over a small patch without ever reporting it.
When a colour must be recognised reliably, test it. Drive the robot slowly over the real surface with color shown on the screen and watch what it actually says — including what it says at the edges between two colours, which is where the wrong answers live.
Both questions are asked of the same surface at the same moment. Watch the two answers travel across a strip of colours and then over the edge of a black line.
Watch the two read-outs over the last third of the strip. One of them changes once. The other changes the whole way across.
Over the patches, both read-outs are useful. Over the edge of the line they part company: the colour name has only two answers to give and jumps between them, while the number slides smoothly from 88 down to 8. Every value in that slide tells you how far onto the line the sensor is — which is information the name simply does not carry.
A line follower built on colour names only knows “black” or “not black”, so it can only lurch. Built on reflected light it can tell how far onto the line it has drifted, which is what makes smooth following possible.
The first two modes both switch the sensor’s own lamp on and measure what bounces back off the surface. Ambient light intensity does the opposite: the lamp goes off, and the sensor simply reports how much light is arriving from wherever — 0 in the dark, up to 100 in bright light.
| Mode | Own lamp | Measures | Points |
|---|---|---|---|
| colour | on | which of eight colours the surface is | at the surface, very close |
| reflected light | on | how much of its own light comes back | at the surface, very close |
| ambient light | off | how bright the surroundings are | wherever you want to measure |
That makes it the only one of the three that is not really about the floor. A number between 0 and 100 means very little on its own, so watch the same sensor sit through five different rooms — nothing underneath it changes at any point.
the sensor’s own lamp is off — it is measuring the room
Nothing under the sensor changed at any point in this run. Ambient light is the one mode that is not asking about the surface at all.
Those are the shape of the scale rather than exact figures, but the shape is the useful part: a lit room is nowhere near 100, and the top of the range is reserved for a light pointed straight at the sensor. Cover it with your hand and the number drops to near zero — which is the easiest way to check the sensor is doing what you think.
Point it at the ceiling and it tells you whether the room lights are on; point it forwards and a torch will spike the reading, which is a way of signalling to a robot without touching it.
Do not reach for it as a substitute for reflected light. Room light falling on a black line and on white paper is almost the same, so ambient mode can barely tell them apart — the reason reflected light works is precisely that the sensor brings its own light and measures how much of it survives.
It is also the mode most at the mercy of the room. A reading taken by a window in the morning will not match the same spot in the afternoon, so anything built on ambient light needs measuring on the day, in the place, with the lights as they will be.
Even the two lamp-on modes are affected by room lighting — a reading taken by a sunny window differs from one taken in a corner. The sensor must also sit close to the surface and at a constant height, because lifting it changes the reading even though the surface has not changed.
Machines repeat. A wiper sweeps, a conveyor runs, a ride goes round — and none of that should mean copying the same blocks over and over. A loop says “do this again” once.
| Block | What it does |
|---|---|
repeat (10) end | Runs the blocks inside a set number of times, then carries on below. |
forever end | Runs the blocks inside over and over, and never carries on below. |
repeat until <> end | Repeats until a condition becomes true — a loop with a sensor as its exit. |
Anything placed after a forever loop will never run. Not “runs late” — never. Both programs below end with the same block: set the status light green.
repeat (3)
forever
↑ this block never runs
Both programs contain the same green-light block. Let it run as long as you like — the right-hand ring will never turn green.
The repeat loop counts its three passes, stops, and moves on to the block underneath, so its light turns green. The forever loop reaches the bottom of its own blocks and jumps straight back to the top, so the block underneath is never reached — however long you leave it. If a program seems to stop half way through, look for a forever loop above the blocks that are not happening.
A program is a list, and the Brick works down it once. Every block runs, in order, and when the last one is done the program is over. That is fine for a list of instructions — drive, turn, beep, stop — because each is a thing you do once.
A sensor is not a thing you do once. Asking is 1 pressed? gives you an answer about this instant, and an instant later it may be wrong. Checking a sensor once tells you what the world was like at the moment the program started — which is almost never what you wanted to know.
So a program that has to react must ask again, and again, for as long as it is running. That is the whole job of the loop: not to repeat an action, but to keep the question being asked.
Wrap a sensor check and the motor it controls in a forever loop and you have built a closed-loop control system — the pattern behind every line follower, thermostat and cruise control:
It is called closed because the output feeds back round to the input: the motors move the robot, moving the robot changes what the sensor sees, and what the sensor sees changes the motors. Break the circle at any point and the robot stops responding.
when program starts :: events hat
forever
if <[1 v] is pressed? :: sensors> then
[A v] start motor [clockwise v] :: motors
else
[A v] stop motor :: motors
end
endRead it as a sentence and it is almost too simple to need explaining: for ever, if the button is pressed run the motor, otherwise stop it. The motor now follows the button for as long as the program is running.
This is the mistake nearly everybody makes first, and it is a hard one to spot because nothing about it looks wrong:
when program starts :: events hat if <[1 v] is pressed? :: sensors> then [A v] start motor [clockwise v] :: motors else [A v] stop motor :: motors end
The logic is perfect. The ports are right. Nothing is misspelled. And the robot will ignore the button completely — because the Brick reaches that if/else a few milliseconds after you press Run, finds the button not pressed, takes the else branch, stops the motor, runs out of blocks and ends. By the time a finger arrives, there is no program left to notice it.
with forever — a closed loop
without it — the common mistake
↑ running — for the only time
Both programs contain exactly the same if/else. The only difference is the forever block around one of them.
Both programs contain exactly the same if/else. The counter is what gives it away: one keeps checking for as long as it runs, the other is stuck on the single check it made before anybody touched anything. A student who has seen this once stops writing it.
The tell on a real robot is a program that ends the instant you start it — the Brick returns to its menu almost immediately. If a sensor program finishes rather than waits, the loop is what is missing.
Say this back before moving on: “My robot reads a number off the floor, over and over, and acts when the number changes.”
Look at your model and find the parts with cables. There are three again — but one of them is a kind you have not used before.
EV3 Brick × 1
Medium Motor × 1Colour Sensor × 1The Medium Motor does the lifting. It is smaller and faster than the Large Motors that drove Lesson 1’s wheels, and it is the right choice for an arm, a winch or a gate — jobs that need speed and precision more than raw pulling power.
The Colour Sensor is a different kind of part. Every component so far has been an output — you tell it to do something and it does it. This one is an input: it tells the Brick something. Nothing you send it makes it move.
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.
Lesson 1 only used lettered ports. This is the first build that needs both ends of the Brick, so the rule stops being a formality: put the Colour Sensor in a lettered port and it will not read at all.
| Part | Port | Why this one |
|---|---|---|
| Medium Motor (the lift) | A | A single working motor conventionally takes A, leaving B and C free for a driving pair. |
| Colour Sensor (the landing) | 3 | The course convention across all four sensors: Touch 1, Gyro 2, Colour 3, Ultrasonic 4. Keep it and any lesson’s program runs on your robot. |
Check your own wiring 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.
Still the same two traps: a Brick that has gone to sleep, and connecting to the next group’s robot. If a tower across the room starts lifting when you press play, you have found the second one.
This step earns its keep today. Last lesson the port tiles confirmed two motors; this time one of the three parts is a sensor, and a sensor that is plugged in wrongly looks exactly like a sensor that is plugged in correctly — until the program refuses to work.
If the number does not move when your hand does, stop here. Nothing later in this lesson can work.
That live number is the single most useful debugging tool you have all year, and it is available before you write a line of program.
First, the sensor by itself. The Colour Sensor can work several ways, and today’s job needs reflected light intensity — it shines a light down and measures how much bounces back, as a number from 0 (dark) to 100 (bright).
Watch the two read-outs over the last third of the strip. One of them changes once. The other changes the whole way across.
Read your own two numbers before programming anything. Using the live port tile: what does the bare landing surface read? What does it read with the car sitting on it? Write both down. Your threshold is a number in between, and it belongs to your robot on this table — a lesson cannot tell you what it is.
when program starts :: events hat forever set [A v] motor to (30) % speed :: motors run [A v] motor for (2) rotations :: motors wait until <([3 v] reflected light intensity :: sensors) < (25)> play beep (60) for (0.3) seconds :: sound end
Walk it in the order the robot runs it:
What success looks like: the car lifts, drops, beeps, and lifts again — and keeps going without you touching anything. Put your hand under the sensor while the car is up and the machine should carry on as if the car had landed.
repeat (3)
forever
↑ this block never runs
Both programs contain the same green-light block. Let it run as long as you like — the right-hand ring will never turn green.
One change at a time, and predict before each run.
That last one is the point of the whole lesson. A timer would have needed changing; the sensor did not, because it was never counting time — it was watching for a thing to happen.
If your ride stops after one cycle, your threshold is a number the sensor never reaches. Go back to the port tile, read the surface again with the car down, and pick a number between your two readings rather than at one end.
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.
Make the ride beep twice when the car lands instead of once, and add a different, lower beep just before it lifts. A person watching from across the room should be able to tell lifting from landing with their eyes shut. One extra block and one changed number is enough.
Hold the car at the top for two seconds before it drops, but keep the landing detection exactly as it is. Then make the ride refuse to lift again until the landing has been clear for a full second — so a hand left under the sensor does not start the next cycle. Think carefully about which waits belong inside the loop and which do not.
Run the ride ten times and then stop by itself, showing the count on the Brick screen as it goes. Ten means ten completed rides, not ten lifts — a cycle that never lands must not be counted. You will need something other than a forever loop, and you will need to decide where the counting happens.
The safety inspector will not sign off a ride that cannot tell the difference between a car that landed and a sensor that failed. Build a Drop Tower that detects its own faults. If the car has not landed within a reasonable time of being released, the ride must stop, show a clear warning on the screen, and sound an alarm that is obviously not the normal landing beep. It must not simply hang waiting forever, which is what your Lesson 2 program does today. You must also be able to demonstrate it: with the ride running normally, cause a fault on purpose and show the machine catching it. Plan on paper first. Work out how the program can wait for a thing to happen AND notice that it has not happened, when a plain wait-until can only do the first. Be ready to explain what "a reasonable time" should be for your build, and how you chose it.