Challenge 1
Build a three-line panel: the machine's name on line 1, the arm's state on line 3, and the speed you are running at on line 5. All three must be on screen at the same time, and only the state line may change while the arm moves.
What you are building 3 min
The Folding Fire Escape: a tower with a long arm hinged at its base. A motor winds a string, the string pulls, and the arm swings up and out with a hook at its tip.
Let the string back out and the arm folds down against the tower again. That is the whole machine — one motor, one string, one pivot, and a lot of reach.
The Brick has been telling people things for a while now: a picture in Lesson 9, a line of text in Lesson 15, a colour in Lesson 16. Each of those said one thing at a time. A rescue machine needs to say several at once, and today the screen stops being a message and becomes a panel.
In the real world 5 min
Where you have seen it
A fire engine with a ladder that unfolds off its roof and reaches up the side of a building. In Malaysia the Bomba run them in every major town, and they matter more every year, because the buildings keep getting taller.
Why it is built that way
The arm turns about a fixed pivot at its base. It does not grow out of the truck like a telescope — it swings, the way your arm swings from your shoulder, and that is what “folding” means here.
Pulling it up with a string is a clever trick worth noticing. A string can only pull, never push, so the same motor raises the arm by winding in and lowers it by letting gravity do the work. You get two directions of movement out of one direction of force.
What would go wrong without it
Now think about the crew. The person at the controls is at the bottom and cannot see the top. They need to know several things at the same time: how high the arm is, which way it is moving, and whether it is safe to climb.
One thing at a time is no use to them. A display that showed the height, then wiped it and showed the direction, then wiped that, would be worse than a piece of paper.
An operator needs a panel, not a conversation. Several facts, all visible at once, each in the place they always live.
The main concept — eight lines, and they do not touch each other 6 min
The Brick’s screen holds eight lines of text, numbered 1 at the top to 8 at the bottom. Writing to one of them leaves the other seven exactly as they were.
| Block | What it does |
|---|---|
write [EV3] at line (1) :: display | Puts text on that line only. Everything else on the screen stays. |
write [EV3] at x: (1) y: (1) with font [normal black v] :: display | Places it by pixel instead of by line, and lets you pick the font. More control, more to get wrong. |
clear display :: display | Wipes all eight lines at once. The only thing that does. |
That first row is the whole idea. Write a title to line 1 at the start of the program and it will still be there ten blocks later, because nothing you do to line 3 can reach it. So you can build a layout: line 1 is what this machine is, line 3 is what it is doing, line 5 is a number that keeps changing.
clear display
write READY at line 1
write READY at x: – y: – with font normal black
the screen is 178 pixels across and 128 down
0x · across0y · down1line
write [READY] at line (1). Line 1 is the top of the screen, hard against the left edge.
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.
One trap, and it is the same one from Lesson 9. Writing a short word over a longer one does not erase the tail of the old one. Put DOWN over RISING and the line reads DOWNNG. Pad your words to the same length with spaces, or clear the display first.
Decide what lives on which line before you write a block. A panel with a fixed layout can be read at a glance; one that moves around cannot.
The display, in fullBoth write blocks, the image blocks and clearing. Open it if the screen is not clear yet.Show meHide
The Brick display
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.
Blocks reference
| 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. |
Clear it, or write on top of what is there
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
when program starts
clear display
display Eyes / Neutral
write GATE OPEN at line 7
without it
display Eyes / Neutral
write GATE OPEN at line 7
1lines · cleared1lines · not cleared1run
Cleared: one message, readableNot cleared: 1 messages on line 7
Both Bricks still show whatever was left on the screen when the last run ended.
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.
Where the writing goes
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.
clear display
write READY at line 1
write READY at x: – y: – with font normal black
the screen is 178 pixels across and 128 down
0x · across0y · down1line
write [READY] at line (1). Line 1 is the top of the screen, hard against the left edge.
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.
Writing on a line
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.
- Line 1 is the top. The numbers count downwards, so line 2 is below line 1, not above it.
- There are eight of them, each about ten pixels lower than the last. That means all eight sit in the upper part of the screen and the line block cannot reach the bottom at all.
- One message per line. Two messages sent to the same line land on top of each other and turn into a smudge — put them on different lines, or clear the screen in between.
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.
Writing at x and y
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.
- x is how far across, from the left edge. x: 0 is the far left; x: 177 is the far right. Bigger x moves right, which is what everybody expects.
- y is how far down, from the top edge. y: 0 is the very top; y: 127 is the bottom. Bigger y means lower — this is the one that catches people out, because on a graph at school a bigger y means higher.
- The corner is 0, 0. x: 0 y: 0 is the top-left, and it puts the text in exactly the same place as at line 1 — the two blocks are describing the same screen.
- The pair of numbers is the top-left corner of the text, not its middle. The letters go down and to the right from the point you name.
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.
Which one to use
- Use lines for ordinary status messages — quick to write, impossible to get wrong, and eight of them is plenty for one robot.
- Use x and y when the position itself matters: putting a label and its number side by side, lining a heading up over a reading, filling the lower part of the screen, or moving something across the screen as a value changes.
Putting a number on the screen
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.
Advanced — a dashboard, not a number
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.
A variable with a label on it
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.
Several sensors, one line each
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.
Turning a number into a word
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.
24 cm
180°
Colour Sensor5 → RED
Touch Sensor3 presses
| 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.
Advanced — stopping the screen from flickering
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
YELLOWwhat the sensor says—what the screen says0characters left behind
never blankleftovers survive
The Colour Sensor reads a colour and the name goes on line 3, over and over, inside a forever loop.
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.
Advanced — a whole list on the screen
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.
Why it matters
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.
Say this back before moving on: “Writing to line 3 does not touch line 1. Only clear display wipes everything.”
What’s in this build 4 min
Two electronic parts, and one piece of string that matters as much.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and carries the screen — which today is the operator’s control panel. |
| Medium Motor | Winds and unwinds the string. The flat slab one. It is not lifting much, so speed matters more than force. |
| The string (no cable) | The part that actually raises the arm. It can pull and it cannot push — remember that when the arm refuses to go down. |
Wind it by hand first
- Turn the motor drum slowly by hand and watch the string. Is it winding onto the axle, or unwinding off it?
- Keep going until the arm is fully up. Count roughly how many turns of the drum that took.
- Now unwind. The arm should fold back down under its own weight. If it sticks halfway, something is catching — find it now, because the motor cannot push it down.
- Check the string is not crossing over itself on the axle. A string that piles up on top of itself winds at a different rate each turn, and your careful numbers will stop meaning anything.
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 |
|---|---|---|
| Medium Motor (winds the string) | A | A single working motor takes A, as it has all course. |
| The screen | none | Part of the Brick. Nothing to plug in. |
Check your own build now:
- Motor cable in port A — a letter, not a number.
- Arm folded down before every run, and the string taut but not tight. Slack string means the first part of every lift does nothing.
- Is the screen facing the person operating it? A panel nobody is looking at is not a panel.
- Is the tower steady on the table? A tall arm swinging out moves the model’s weight a long way sideways, and it will tip if the base is light.
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.
Either is fine, but keep the cable clear of the string. A USB lead lying across the winding axle will foul it, and the symptom — an arm that lifts partway and stops — looks exactly like a program with the wrong number in it.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Check the port tiles. A Medium Motor on A, nothing on the numbered ports.
- Wind the arm from fully down to fully up by hand, watching degrees counted. The difference is how far the motor must turn for a full lift — that is the number your program needs.
- Take about a tenth off it. Stopping just short of fully up is sensible; winding into the stop is not.
Make it move 10 min
Seven blocks, and two of them build the panel. Put your own measured number in place of the 180.
when program starts :: events hat clear display :: display write [FIRE ESCAPE] at line (1) :: display write [ARM: DOWN ] at line (3) :: display [A v] set speed to (25) % :: motors [A v] run [clockwise v] for (180) [degrees v] :: motors write [ARM: UP ] at line (3) :: display
Walk it in the order the Brick runs it:
- clear display — a blank panel, so nothing left over from the last run confuses anybody.
- write FIRE ESCAPE at line 1 — the title. Written once, at the start, and it survives everything below it.
- write ARM: DOWN at line 3 — the state, one blank line below the title so the two do not read as one sentence.
- set speed to 25 % — slow. A rescue arm that whips up is a rescue arm that swings the whole model over.
- run clockwise for 180 degrees — the string winds in and the arm rises. The block waits here until it has finished.
- write ARM: UP at line 3 — only line 3 changes. Look at the screen: the title is still there.
Notice the spaces inside the brackets. ARM: DOWN and ARM: UP are padded to the same length on purpose. Without them, UP written over DOWN would leave the last two letters of DOWN behind, and the line would read ARM: UPWN.
What success looks like: a two-line panel, a slow steady lift, and the bottom line changing at the moment the arm arrives — with the title still sitting untouched above it.
Change it and test 8 min
One change at a time, and predict before each run — specifically, predict what the whole screen will look like, not just the line you changed.
- Add a third row: write [HOOK: READY] at line (5) near the start. Predict how many lines are on screen at the end.
- Change the last block to write at line 1 instead of line 3. Predict what happens to the title. It is gone — you have written over it, and the panel has lost its label.
- Put it back, then delete the spaces from ARM: UP. Run it and read the line carefully. This is the leftover-characters trap, live.
- Add a lowering half: a wait 3 seconds, a run counterclockwise for 180 degrees, and a third write back to ARM: DOWN. Does the arm reach the same place it started?
- Now put a clear display just before that last write. Predict what the panel looks like afterwards. The title has gone too — because clear display is the one block that does not respect lines.
Step 5 is the one worth keeping. Clear display is a hammer. Once you are running a panel, you almost never want it in the middle of a program — you want to overwrite the one line that changed and leave everything else alone.
