EV3 Robotics›Level 1 · Beginner›Lesson 5
Level 1 · Lesson 5 · EV3-L01-0560 minutes · Ages 9–16 · Model: Riding Unicycle
The Riding Unicycle: a figure balanced on a single wheel, pedalling along without falling over.
You have written words to the Brick screen before — SPEED 75, PRESS CENTRE. Useful, but plain. The screen can also draw pictures, and a machine with a face is a machine people understand without being told anything.
By the end your unicycle will show a face while it rides, and change what that face says about how the ride is going.
A unicycle has one wheel, no handlebars and no way to lean on anything. Circus performers ride them, and so do a growing number of people getting to work — on electric versions that do the balancing themselves.
A bicycle stays up partly because it is long: put your weight anywhere between the two wheels and it holds. A unicycle has one point of contact with the ground, so the rider has to keep their weight over that single point, constantly, in every direction at once.
They do it by moving the wheel. Feeling themselves tipping forward, they pedal forward to bring the wheel back underneath. That is why you cannot ride a unicycle standing still — the balancing is done by going somewhere.
A machine that cannot tell anyone what it is doing is a machine nobody trusts. Your unicycle is going to be doing something quite hard, and a person watching from across the room has no way to know whether it is going well.
A face on the screen is not decoration. It is the fastest way a machine can tell a person how it is getting on.
This model has no step-by-step manual, and the video below is not one. What the lesson has for this build is a film of the finished unicycle working — useful for seeing what you are aiming at, and no use at all for finding out which beam goes where. Watch it for the target, then build from the model your teacher has, or from a photograph of a finished one. If you get stuck, ask — you are not missing a page, the page does not exist.
Two display blocks, and the difference between them is the same difference you met with sound in Lesson 4.
| Block | What it does |
|---|---|
display [Eyes / Neutral v] :: display | Draws a built-in picture and moves straight on. The picture stays until something replaces it. |
display [Eyes / Neutral v] for (2) seconds :: display | Draws it and holds the program for that long before carrying on. |
clear display :: display | Wipes the screen. Nothing else does. |
Open the dropdown in EV3 Classroom and look at the whole list before you choose. There are eyes, faces, arrows, symbols and objects, and picking a good one is most of the work — a face that matches what the robot is doing tells a story, and a random one is just noise.
The screen keeps whatever was drawn on it. It is not a message that fades — it is a mark that stays until you clear it or draw over it.
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.
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.
Everything an EV3 does begins with a motor turning. Before worrying about how far or how fast, there are only two things to say to a motor: start and stop. The blocks are the same whichever motor you use — only the port letter changes.
| Block | What it does |
|---|---|
[A v] start motor [clockwise v] :: motors | Starts the motor and immediately carries on to the next block. The motor keeps turning on its own. |
[A v] stop motor :: motors | Stops the motor. |
wait (2) seconds | Holds the program here, which is how you control how long a motor runs. |
Because start motor does not wait, a motor started on its own would run until the program ended. The pattern that gives a motor a length is three blocks:
when program starts :: events hat [A v] start motor [clockwise v] :: motors wait (2) seconds [A v] stop motor :: motors
Read it aloud: start it, leave it two seconds, stop it. Change the wait and you change how far the motor gets.
The highlight below follows the block the Brick is running, and the shaft turns only while the program is between start motor and stop motor. Notice that the count keeps climbing all the way through the wait — the wait does not pause the motor, it pauses the program.
0.00rotations so farnoshaft turning
The count does not pause when the program does. A wait holds up the blocks, and the motor carries on turning underneath it.
This is the whole idea behind start motor: it hands the motor its instruction and moves on, leaving the motor running behind it. Nothing stops the shaft until a block tells it to.
The direction dropdown says clockwise or counterclockwise — but clockwise seen from where? Always from the axle end: look straight at the shaft coming towards you, and clockwise is the way a clock’s hands go.
Here the Medium Motor faces you, so its output axle points straight out of the page. This is the view to picture when you are choosing a direction.
when program starts :: events hat [A v] start motor [clockwise v] :: motors wait (2) seconds [A v] stop motor :: motors
A Medium Motor normally lives in port A or D.
The Large Motor is shown from the side, which is the face its axle comes out of — so once again you are looking straight down the shaft.
when program starts :: events hat [B v] start motor [clockwise v] :: motors wait (2) seconds [B v] stop motor :: motors
A Large Motor normally lives in port B or C. Compare the two programs: they are the same three blocks, and only A has become B.
Medium · port ALarge · port BA fan, a conveyor belt or a spinning ride does not need to stop at an exact position — it just needs to run while something is happening. For those, timing the motor is simpler and perfectly good enough.
Say this back before moving on: “What I draw on the screen stays there. If I want it gone, I have to clear it or draw something else.”
Find the parts with cables. A Brick and one motor — and again you have to tell us which motor it is, because this model has no written parts list either.
Large Motor
Medium MotorThis model stands on one wheel, so it will fall over unless its weight is directly above that wheel. The heaviest single thing in your kit is the Brick, so wherever the Brick is, the balance is.
Do this before you program anything. A unicycle that is badly balanced will fall over on every run no matter what the program says, and you will spend the lesson debugging blocks to fix a building problem.
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 motor (drives the wheel) | A | A single working motor conventionally takes A, and every program on this page says A. If yours is elsewhere, either move the cable or change every block — not half of each. |
| The screen | none | Part of the Brick, like the buttons in Lesson 6. Nothing to plug in. |
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.
Use Bluetooth if you possibly can. A USB cable hanging off a model that balances on one wheel will pull it over, and you will blame the balance. This is the build where the tether really does change the result.
If the number does not move when the wheel does, stop here. The cable is in the wrong port or not pushed fully home.
Seven blocks: a face before the ride, a steady roll, and a different face at the end. Choose your own two pictures from the dropdown — the ones named here are just to show the shape.
when program starts :: events hat clear display :: display display [Eyes / Neutral v] :: display [A v] set speed to (30) % :: motors [A v] start motor [clockwise v] :: motors wait (5) seconds [A v] stop motor :: motors
Walk it in the order the Brick runs it:
What success looks like: a face on the screen before the wheel turns, a steady roll across the table, and a clean stop. If it topples immediately, go back to the balance in section 5 — the program is not the problem.
One change at a time, and predict before each run.
Step 2 is the one people get caught by all year. A screen remembers. If a robot ever tells you something that does not match what it is doing, suspect an old message before you suspect a broken sensor.
If it falls over every time no matter what you try, stop programming and go back to balance. Shift the Brick a stud at a time, and check the cable is not hanging off one side. Almost every unicycle problem is a weight problem.
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.
Give your unicycle three faces: one while it is waiting to start, one while it is riding, and one when it has finished. Each must be on screen only during its own stage — a person watching from across the room should always know which stage it is in.
Make the screen show both a picture and words at the same time — a face, and a line of text underneath saying what it is doing. Then make the text change during the ride while the face stays put, so you can see that drawing one thing does not wipe the other.
Make the unicycle ride, then report on its own ride: after it stops, the screen must show how many seconds it rode for and a face that matches how it went. Run it three times at three different speeds and photograph each ending screen. The screen must never show a number left over from a previous run.
Make a machine that tells people how it is getting on. Your unicycle must ride across a distance you choose and, without any person touching it, use its screen to report what happened — including when things go wrong. If it finishes the distance it should say so; if it stalls or is stopped early, it should say that instead, and it must not be the same face for both. Plan on paper before you build. Work out what your program can actually know about how the ride went, and how it could tell the difference between finishing and being interrupted, using only what you have learned so far. Two questions when you demonstrate it. What can your robot genuinely tell about its own ride, and what is it only assuming? And why is a wrong report worse than no report at all?