EV3 Robotics›Level 1 · Beginner›Lesson 6
Level 1 · Lesson 6 · EV3-L01-0660 minutes · Ages 9–16 · Model: Auto Gate
The Auto Gate: a barrier arm on a post, geared to a Medium Motor, that lifts to let traffic through and lowers to stop it.
You have made models beep before. The Ferris Wheel beeped, the Stegosaurus made a noise on every step. In both cases the sound was decoration — pleasant, and it would not have mattered if it arrived slightly late.
A barrier is different. Its sound is a warning, and a warning that arrives after the arm has already moved is not a warning. It is an announcement.
So today’s question is not which sound, or how loud. It is: while the sound plays, what is the rest of the program doing?
The arm at the entrance to every shopping-mall car park in Malaysia. The toll plazas on the PLUS highway. The gate at your own school. They all do the same thing: a hinged arm across a road, up to let you in, down to keep you out.
The arm is a lever turning about a pivot at the post. All its weight hangs out on one side, so the further out the weight sits the harder the motor must work to lift it — that turning effort is torque, which you met with the Walking Bot.
Real barriers cheat. They bolt a lump of metal on the short side of the pivot so the two sides nearly balance, and then a small motor can lift a long arm. Look behind the post next time you are at a car park; the counterweight is usually right there.
And a barrier only ever needs a quarter turn. Horizontal blocks the road, upright lets traffic through. It never spins, which is exactly why degrees — from Lesson 10 — is the right unit for it.
At a railway level crossing the barriers do not simply drop. The lights flash and the alarm sounds first, for several seconds, and only then does the arm come down. Those seconds exist because a car travelling towards the crossing needs time to stop.
Reverse the order and you have a machine that tells people about a danger they are already in. The sound has not become useless — it has become worse than useless, because it sounds like a working safety system.
A warning has to finish before the thing it is warning about starts. Otherwise it is not a warning, it is a sound effect.
Two sound blocks. They play the same file, at the same volume, for the same length of time. The difference is what happens underneath them.
| Block | What the rest of the program does meanwhile |
|---|---|
play sound [Information / Blip 1 v] until done :: sound | Waits. Nothing below this block runs until the sound has finished playing. |
start sound [Information / Blip 1 v] :: sound | Carries straight on. The sound plays while the next blocks are already running. |
You have met this shape before without it having a name. In Lesson 4 the Ferris Wheel’s start motor let the program run on while the wheel turned, and run for 2 rotations made it wait. Sound works exactly the same way, and so will most things you meet later.
Neither block is the better one. A level crossing wants until done for the warning before the arm moves, and start sound for the alarm that carries on ringing while it comes down. Same machine, both blocks, chosen by what has to happen at the same time.
play sound until done
start sound
Watch the barriers, not the clock. On the left the warning finishes before anything moves; on the right it sounds while the barrier lifts.
Ask “does the next block have to wait for this one?” Until done means yes. Start means no.
The Brick has a small speaker. It can play one of the built-in sound files, or beep a note you choose. Sound is what makes a machine feel finished — and it is also a way for the robot to tell you something without you having to look at it.
| Block | What it does |
|---|---|
play sound [Communication / Hello v] until done :: sound | Plays the sound and waits for it to finish before the next block runs. |
start sound [Communication / Hello v] :: sound | Starts the sound and moves straight on to the next block, so the sound plays while the robot keeps working. |
play beep (60) for (0.5) seconds :: sound | Plays a single note for a set time — useful for short alerts. The number is a note, not a volume: bigger means higher. |
set volume to (100) % :: sound | Sets how loud everything after it will be. Worth putting at the top of a program — the Brick remembers the last volume it was given, even from somebody else’s program. |
stop all sounds :: sound | Cuts off anything that is still playing, including a long sound started earlier. |
These two blocks play the very same file. The difference is what the rest of the program does while it plays — so it cannot be heard on its own, only seen. Here are both, each lifting a barrier.
play sound until done
start sound
Watch the barriers, not the clock. On the left the warning finishes before anything moves; on the right it sounds while the barrier lifts.
The bars underneath are when the speaker was on and when the motor was turning. On the left they never overlap: the program is stuck at the sound block until the file has finished, and only then does the barrier lift. On the right they overlap almost completely, and the whole job is done in half the time.
Real machines warn before they move, not after: a lift chimes before the doors close, a reversing lorry beeps while it rolls back, a level crossing sounds before the barrier drops. Getting the order right is the difference between a warning and an apology.
The Medium Motor is the smaller of the two EV3 motors. It is quick and light rather than strong, which makes it the right choice for anything that has to move a part of the robot rather than the whole robot — a gate arm, a pair of jaws, a winch, a pointer.
side
from above| Block | What it does |
|---|---|
[A v] run [clockwise v] for (1) [rotations v] :: motors | Turns the motor a measured amount, then stops. One rotation is one full turn of the motor shaft. |
[A v] run [clockwise v] for (90) [degrees v] :: motors | The same idea, but in degrees — useful when a quarter or a half turn is what the mechanism needs. 360 degrees is one rotation. |
[A v] run [clockwise v] for (2) [seconds v] :: motors | Turns the motor for a length of time and then stops, whatever the shaft managed to do in it. The one measurement that always finishes. |
[A v] set speed to (50) % :: motors | Sets how fast the motor will run from now on. It does not start the motor by itself. |
[A v] start motor [clockwise v] :: motors | Starts the motor turning and moves straight on to the next block. It keeps going until something stops it. |
[A v] stop motor :: motors | Stops the motor. |
These two look similar and behave completely differently, and almost every early EV3 bug comes from picking the wrong one. Watch both run the same job, over and over.
versus
Let it loop a few times. The left dial keeps landing on the same mark; the right one leaves a new mark almost every run — that scatter is what “not repeatable” means.
The black mark is where the shaft should finish. The measured motor hits it every single run, because the program waits at that block until the motor has turned exactly that far. The timed motor is only running for a second — and a second covers a different amount depending on the battery, the friction and whatever the mechanism is carrying. Each orange dash is a run that finished somewhere it was not asked to.
If a mechanism has to end up in a particular place — a gate that must finish upright, a jaw that must close fully — use the measured block.
The dropdown at the end of the run block has a third setting, and it is the one that saves lifting mechanisms. for () seconds switches the block off a distance and onto a duration: it drives the motor for that long and then stops, whatever the shaft managed to do in the time.
That sounds strictly worse than a measured turn, and for most jobs it is. It matters because of what the measured block actually waits for. run for (90) degrees does not finish when 90 degrees’ worth of time has passed. It finishes when the shaft has turned 90 degrees — and if the mechanism runs out of travel first, the shaft never will.
Every arm, jaw and lift has a physical limit: a point where the mechanism reaches the top of its travel, or something in the build gets in the way. Push a motor into that limit and it stalls — the shaft stops turning and the motor sits there straining. The motor is fine and the program is spelled correctly. But the encoder has stopped counting, so a measured block that was told a bigger number is still waiting, and it will wait until the Brick is switched off.
Nothing after that block ever runs. Not the next motor block, not the sound, not the display, not the rest of the program. That is the whole failure, and it looks like a crash even though nothing has crashed.
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [clockwise v] for (90) [degrees v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
Watch the Brick screen, not the arm. HOME SET is the block after the motor block, so a blank screen means the program never got past it.
Compare the first two. The only difference between them is 45 and 90, the mechanism is identical, and one of them is a working program while the other locks up on the third block. Nothing in the listing distinguishes them — the end stop is a fact about the build, and the program has never heard of it.
This is the mistake almost every student makes the first time a Medium Motor lifts something. A lifting arm has a lowest position and a highest one; ask it to turn past either and the program hangs. It is worse than an ordinary bug, because the robot looks alive — the motor is still being driven, still buzzing, still hot — and the next block never comes.
The fix turns the problem into the technique. You often do not know how many degrees it is to the top of an arm’s travel — it depends on the build, and it changes the moment somebody rebuilds it. So do not measure it. Drive the arm gently into its own end stop for a couple of seconds, and then declare that position to be zero:
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [counterclockwise v] for (2) [seconds v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
Three things make that work, and all three are deliberate:
After that, use measured blocks for everything inside the travel and timed blocks whenever you are driving to a limit. The rule of thumb: if the movement ends against something solid, run for seconds.
A Medium Motor is normally plugged into port A or D, which leaves B and C free for the Large Motors that drive wheels. The letter in the block must match the port the cable is actually in — this is the single most common reason a program appears to do nothing at all.
The Brick’s screen is a small black-and-white whiteboard. You can wipe it, draw one of the built-in pictures on it, or write your own words at a spot you choose. It is how the robot tells a person what it is doing.
| Block | What it does |
|---|---|
clear display :: display | Wipes the screen blank, ready for something new. |
display [Eyes / Neutral v] :: display | Draws a built-in picture chosen from a list — eyes, faces, arrows, symbols. |
display [Eyes / Neutral v] for (2) seconds :: display | Draws the picture, holds the program for that long, and then carries on. Handy when a face should be seen before anything else happens. |
write [Hello] at line (1) :: display | Writes your own text on one of the screen’s eight lines. |
write [Hello] at x: (10) y: (40) with font [normal black v] :: display | Writes text at an exact spot instead of a line, and lets you choose the size. Use it when a message has to line up with something else on the screen. |
The screen has no memory of whose writing is whose. It keeps every mark until something wipes it — including the marks left by the last run. Watch the same program with and without its clear display block.
with clear display
without it
Let it loop two or three times. The left screen still reads cleanly; the right one is the same program with one block missing.
Both Bricks are told exactly the same thing. The left one wipes the screen first, so line 7 holds one message and reads correctly. The right one never wipes, so each new message is drawn over the last and the words turn into a smudge. This is why a program that seems to display nonsense is usually displaying the truth — several times over.
There are two blocks for writing text, and they describe where in two completely different ways. Watch one message move around the screen under both of them.
the screen is 178 pixels across and 128 down
The arrows are the two numbers. The one along the top is x; the one down the side is y, and it counts downwards from the top edge.
write [EV3] at line (1) is the simple one. You give it a line number and it puts the text there, starting hard against the left edge — you do not choose how far across, only how far down.
For most robots this is all you need: a status word on line 1, a reading on line 3, a warning on line 5. Pick your lines at the start and keep each one for one job, the way you would keep one colour of status light for one meaning.
write [EV3] at x: () y: () with font [] treats the screen as a grid of pixels — 178 across and 128 down — and lets you put the text anywhere on it.
The block ends with a font dropdown, and normal black is the usual choice. A larger font makes the writing easier to read from across the room but takes more room across the screen, so fewer characters fit before the text runs off the edge.
The text slot of either block will take a reporter, so a sensor value can be shown directly: drop (4 distance in cm) into the slot and the screen shows the reading. That is the EV3’s version of a print statement, and it is the fastest way to find out what a robot actually thinks it is seeing.
A bare number on its own is hard to read, though. To show DIST: 23 rather than 23, use the operator block join [DIST: ] () to glue the label to the value, and put the join into the write block’s text slot.
when program starts :: events hat clear display :: display forever write (join [DIST: ] ([4 v] distance in [cm v] :: sensors)) at line (1) :: display end
Note the forever: a value written once is a value from the start of the program. To watch a reading change, the write block has to be inside a loop.
Once one value is on the screen the rest follows, and the useful trick throughout is join: it glues two pieces of text together and hands the result to the write block. Anything that reports a value can go in either slot — a variable, a sensor, or another join.
Counting is the classic case. A variable counts how many times the Touch Sensor has been pressed, and a bare 5 on the screen tells nobody anything — PRESSED: 5 tells them everything:
when program starts :: events hat clear display :: display set [count v] to (0) :: variables forever wait until <[1 v] is pressed? :: sensors> change [count v] by (1) :: variables write (join [PRESSED: ] (count)) at line (1) :: display wait until <not <[1 v] is pressed? :: sensors>> end
The two wait until blocks are what make it count presses rather than counting as fast as the loop runs while your finger is down. That is the Touch Sensor’s own lesson, but it shows up here because a counter on the screen is where you first notice it going wrong.
Give every reading its own line and keep it. A line that changes meaning halfway through a program is unreadable at a glance, which is the only speed a screen on a moving robot gets read at.
when program starts :: events hat clear display :: display forever write (join [DIST: ] ([4 v] distance in [cm v] :: sensors)) at line (2) :: display write (join [DEG: ] ([A v] degrees counted :: sensors)) at line (5) :: display end
degrees counted is worth putting on the screen the first time you use it — it is the fastest way to find out whether a motor is turning as far as you think it is, and it is the block behind every “why did it stop early” question.
Sensors report numbers, and people read words. The Colour Sensor reports 5; the person watching wants RED. A chain of if … then … else blocks does the translation, and it is worth doing once into a variable rather than in every write block:
if <([3 v] color :: sensors) = (5)> then
set [name v] to [RED] :: variables
else
if <([3 v] color :: sensors) = (4)> then
set [name v] to [YELLOW] :: variables
else
set [name v] to [OTHER] :: variables
end
end
write (join [COLOR: ] (name)) at line (4) :: displayThe same shape turns a distance into a warning. Here the screen carries the number and what the number means, which is what lets somebody across the room tell whether the robot is about to hit something:
if <([4 v] distance in [cm v] :: sensors) < (10)> then
set [status v] to [TOO CLOSE!] :: variables
else
if <([4 v] distance in [cm v] :: sensors) < (30)> then
set [status v] to [OBSTACLE FOUND] :: variables
else
set [status v] to [NOTHING FOUND] :: variables
end
end
write (status) at line (3) :: displayDrive all four of those at once below. The screen is the real thing — five write blocks, five lines, and every one of them a join.
Drive the sensors and read the screen. Every line is one write block with a join in its text slot.
| Line | What goes in the write block | On the screen now |
|---|---|---|
| 1 | join "PRESSED: " (count) | PRESSED: 3 |
| 2 | join "DIST: " (4 distance in cm) | DIST: 24 |
| 3 | (status) — set by the if chain | OBSTACLE FOUND |
| 4 | join "COLOR: " (name) | COLOR: RED |
| 5 | join "DEG: " (A degrees counted) | DEG: 180 |
Line 4 says COLOR: RED, but the sensor only ever said 5. The if chain in between is what turns a number into a word.
The moment a reading goes inside a loop, one of two things goes wrong, and which one depends on where the clear display block went.
Almost everybody tries clear inside the loop first. It gives the right text — and a screen that blinks several times a second, because between the clear and the write there is genuinely nothing on the screen and the loop goes round faster than your eye.
So the clear gets moved to the start of the program, the blinking stops, and the words go wrong. Writing text paints only the characters it has and leaves everything past them exactly where it was. Write RED over YELLOW and the LOW is still there: the screen says REDLOW. Go the other way — yellow first, then red — and it looks fine, which is why this bug takes so long to pin down.
when program starts :: events hat clear display :: display forever write (name) at line (3) :: display end
Watch the bottom three rows rather than the Brick. They are what the screen is actually doing: old characters, new characters, and whatever survives.
The fix is to make the new text at least as long as the old one, and join already does that: pad it with spaces. RED plus three spaces is six characters — exactly enough to paint over YELLOW. Nothing is left behind, and nothing is ever blank.
write (join (name) [ ]) at line (3) :: display
Pad to the length of the longest thing that line can ever show. Six characters covers RED, BLUE and GREEN but not NOTHING FOUND — count the longest message, and add spaces to match. The same applies to numbers: DIST: 5 after DIST: 40 leaves a stray 0 on the end, so a line that shows a two-digit reading needs a trailing space.
Use clear-inside-the-loop when the whole screen changes at once and a flicker does not matter; use the padding trick whenever a value is being watched.
Once several values need showing, the line number becomes a counter and the values come out of a list: write item 1 at line 1, item 2 at line 2, and so on inside a repeat. That needs the list blocks rather than the display blocks, so it lives with them — Lists covers building one and reading it back item by item, and the loop that walks it is the same loop that fills the screen.
Machines in the real world tell you what they are doing: a microwave counts down, a lift shows its floor, a car dashboard warns you. A robot that shows WAITING and then OPEN is far easier to understand — and far easier to debug — than one that moves silently.
A lever is a bar that turns about a point. Three things matter and no others: where the load is, where your effort goes, and where the pivot sits between or beside them.
What a lever actually balances is torque — a force multiplied by how far it is from the pivot. A small force a long way out does the same job as a large force close in, which is why a spanner with a longer handle undoes a tighter bolt.
effort × effort arm = load × load arm
Both distances are measured from the pivot. That is the part people get wrong: the arm is not the length of the bar, it is the distance from the pivot to where the force is applied.
Move the pivot and watch both sides of that equation change.
Drag the triangle, or use the arrow keys. The load never changes — only where you put the pivot.
The pivot is near the middle, so effort and load are close to equal. This is a seesaw: no force gained, no distance gained, and easy to reason about.
The mechanical advantage — how much your force is multiplied — is just the ratio of the two arms. And exactly as with pulleys and gears, whatever you gain in force you pay for in distance: a lever that lets you lift with a third of the effort makes your end travel three times as far.
| Class | Arrangement | Examples |
|---|---|---|
| First | pivot in the middle, effort and load on opposite sides | seesaw, crowbar, scissors, a pair of pliers |
| Second | load in the middle, pivot at one end | wheelbarrow, nutcracker, a bottle opener |
| Third | effort in the middle, pivot at one end | tweezers, a fishing rod, your own forearm |
A third-class lever always needs more effort than the load, which sounds useless until you notice what it buys: speed and reach. Your bicep pulls hard over a couple of centimetres and your hand travels half a metre quickly. A catapult arm and a robot’s throwing arm are the same idea.
Every gripper, every digger arm and every set of scales is a lever. So is a light switch, a car’s brake pedal and the claw on a claw machine. The question to ask of any of them is always the same: where is the pivot, and how far is each force from it?
Say this back before moving on: “Until done holds the program. Start lets it carry on.”
Find the parts with cables. Two, as usual — but three things do work.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program — and this time it is also the speaker and the screen. Both are built into it, so neither needs a port. |
| Medium Motor | Drives the barrier arm through a gear train. The flat slab one. Light and quick suits a barrier: it is not lifting much, and it wants to react. |
Brick off. Same routine as the Folding Fan, for the same reason.
The number in your program is the motor’s degrees, not the arm’s. This trips up nearly everyone. If your gearing is 3:1 then a 90-degree arm lift needs roughly 270 degrees at the motor. Start with 90, watch what actually happens, and adjust.
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 |
|---|---|---|
| Medium Motor (lifts the arm) | A | One motor with a job of its own takes A, and every program on this page says A. |
| The speaker and the screen | none | Both are part of the Brick. There is nothing to plug in and no port to get wrong. |
| Sensors | none | Not today. A real barrier has a sensor that spots the car — that is what the mission is about. |
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.
The two usual failures. The Brick has gone to sleep while you were building — wake it. Or you have paired with the group behind you, because every Brick in the room is called EV3 — rename yours.
Step 4 gives you the exact degrees your gate needs. Write it down and use it below.
Seven blocks, in the order a level crossing uses: say what you are, warn, then move. Put your own measured number in place of the 90.
when program starts :: events hat clear display :: display write [GATE CLOSED] at line (1) :: display play sound [Information / Blip 1 v] until done :: sound [A v] set speed to (30) % :: motors [A v] run [clockwise v] for (90) [degrees v] :: motors write [GATE OPEN] at line (1) :: display
Walk it in the order the Brick runs it:
What success looks like: the screen reads GATE CLOSED, a beep sounds and finishes completely, and only then does the arm rise smoothly to upright and stop there. Nothing should overlap.
If the arm over-swings or does not reach upright, your degrees number is wrong for your gearing — not the program. Change the 90 and run again. Go up in steps of 30 rather than doubling it.
One change at a time, and predict before each run. Reset the arm to horizontal before every single run — the program assumes it.
Steps 1 and 2 are the lesson. The same three blocks, in three different arrangements, giving a safe machine, a useless one and a faintly ridiculous one. Order is not style. Order is the behaviour.
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.
Complete the cycle. Your gate must open, hold long enough for a car to pass, and close again — with a warning that finishes before each of the two movements, not just the first. The arm must end horizontal, in the same place it began, ready to run again.
Count the driver down. While the gate is open, the screen must show 3, then 2, then 1 before the arm starts to come down. Each number must replace the one before it rather than piling up underneath, and the last number must be gone before the arm moves.
Make the alarm ring while the arm is coming down, the way a real level crossing does, rather than only before it. Then explain in one sentence why the block the lesson used could not have produced that effect, and which block you used instead.
Build the sequence a real level crossing uses, and defend every choice in it. Your gate must run a full crossing cycle without anyone touching it: announce its state, warn, close, hold closed long enough to matter, warn again, open, and return to rest. It must be readable from across the room and audible from the same distance. Plan on paper before you build. Write the sequence out as a list of moments first, and beside each one note whether the program should wait there or carry on. That list is the program; typing it in afterwards is the easy part. Two questions when you demonstrate it. Point at every sound in your program and say whether it holds the program or not, and why that is the right choice at that moment. And is there any point in your cycle where a person watching would be misled about what the gate is about to do?
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.
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.