Quick Learn — the model, the instructions, the program and the challenges. The theory is in Full Lesson.
EV3 Robotics›Level 1 · Beginner›Lesson 3
Level 1 · Lesson 3 · EV3-L01-0360 minutes · Ages 9–16 · Model: Dual Gyro
The Dual Gyro: a launcher with one motor under the Brick turning a large gear, and a spinning top on each side of it. Run the motor and both tops are flung off together, spinning.
Lesson 1 was about where the robot went. Lesson 2 was about when it moved. This one is about how hard — the third dial, and the one students reach for first and set wrong.
By the end you will launch two tops at once, and you will have found the slowest speed that still leaves them standing. That number is not in this page. You have to measure it.
A warning about the name. This model is named after gyroscopes — spinning tops. It has nothing to do with the EV3 Gyro Sensor, and there is no sensor of any kind on this build. The Gyro Sensor arrives in Level 2.
A spinning top stands on a point it has no business standing on. In the world the great example is the gasing, the traditional top from Tuscany and Andalusia — some as wide as a dinner plate and heavier than a brick, launched with a rope by two people. A well-thrown gasing can spin for well over an hour.
A spinning wheel resists being tilted. Physicists call the effect angular momentum, and the important part for today is that it grows with speed: the faster the wheel turns, the harder it fights anything trying to tip it over. That is the whole reason a top stays upright — not balance, but spin.
The same effect is why a moving bicycle is easy to ride and a stationary one falls over, why aircraft and ships have used gyroscopes to hold a course, and why your phone can tell which way you tilted it.
Spin a top too slowly and it does not wobble a bit more — it falls over at once. Below a certain speed the trick stops working entirely.
Speed is not a volume knob where more is simply more. Somewhere between “falls over” and “stands up” there is a line, and it is a real number you can find by testing.
Finding that line is this lesson’s mission. Everything before it is you learning to set the dial accurately enough to trust the answer.
Last lesson your motor blocks said how far. None of them said how fast, so the Brick used whatever speed it happened to be set to. Today you set it on purpose.
Speed and distance are two separate dials. The speed block does not move anything — it changes what the next movement does.
That second half is where nearly everyone slips. A speed block put after the movement it was meant to change is not an error, and nothing warns you: the program runs, the number is right there in the code, and the motor ignores it completely. Watch both versions run side by side.
speed first — works
speed last — does nothing
Both shafts turn exactly 2 rotations. Only the time they take is different — and the right-hand program never gets the slow movement it was written to have.
Speed is set separately from movement. You tell the motor how fast it should go, and then you tell it to go — two blocks, in that order.
| Block | What it does |
|---|---|
[A v] set speed to (25) % :: motors | Sets the speed for this motor from now on. Nothing moves — it only changes what the next movement will do. |
[A v] run [clockwise v] for (2) [rotations v] :: motors | Now moves, at whatever speed was last set. |
when program starts :: events hat [A v] set speed to (25) % :: motors [A v] run [clockwise v] for (2) [rotations v] :: motors
Swap those two blocks round and the program still contains a speed of 25 % — it just never gets used. Both shafts below are asked for exactly 2 rotations; watch how long each one takes.
speed first — works
speed last — does nothing
Both shafts turn exactly 2 rotations. Only the time they take is different — and the right-hand program never gets the slow movement it was written to have.
The right-hand movement is over before the left is a third of the way round, because it ran at the default speed. Its set speed to () block does run — you can see it light up — but by then the movement it was meant to slow down has already happened. A speed block only ever affects the movements after it. This catches people out constantly.
A high speed is not a better program. Slow movements are gentler on the gears, easier to watch and debug, and look more like the real machine — a barrier that snaps up in a fraction of a second reads as broken rather than fast.
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.
Say this back before moving on: “Setting the speed moves nothing. It decides how fast the movements after it will happen.”
Look at your model and find the parts with cables. There are fewer than in either lesson so far — only two.
EV3 Brick × 1
Large Motor × 1This is a Large Motor — the long one, the same kind that drove Lesson 1’s wheels. It is slower than the Medium Motor and stronger, which is what a launcher wants: it has to get two tops and a gear train moving from a standstill.
The motor turns one large gear in the middle. A smaller gear on each side meshes with it, and each of those carries a top. Two useful things follow, and you can check both by hand before the Brick is even switched on:
Turn the centre gear slowly with a finger and watch. If one top turns and the other does not, a gear has come unmeshed — fix it now, because later it will look exactly like a program fault.
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.
There is only one thing to plug in today, so this is the easiest wiring in the course — which makes it the easiest to be careless with.
| Part | Port | Why this one |
|---|---|---|
| Large Motor (the launcher) | A | A single working motor conventionally takes A, leaving B and C free for a driving pair. Every program on this page says A. |
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 traps: a Brick that has gone to sleep, and connecting to the next group’s robot. Today the second one is easy to spot — if somebody else’s tops fly across the table when you press play, you have found it.
If that number does not move when the gear does, stop here. The cable is in the wrong port or not pushed fully home, and nothing later in this lesson can work.
A motor is not only something you drive. It counts its own turning and reports it, which is why that number is the fastest way to prove a cable is good — before a single block runs.
One change at a time, and predict before each run. Give the tops the same start every time — same spot on the launcher, same table — or you are measuring the table, not the speed.
Step 4 is worth a moment. Fewer rotations is a shorter launch, but not a gentler one — the tops still come off at the speed you set. Distance and speed really are separate dials, and step 5 is what happens when the second one is set after it was needed.
If the tops fall over instantly at every speed, the problem is probably not the program. Check that both tops sit level on their gears, that nothing rubs, and that the table is not a slope — then start testing speeds again.
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.
When Center Button is pressed:
When Center Button is released:
Fullscreen it while you build — you can pause and scrub with the player's own controls.
Work through them in order — each is harder than the last. The extra challenge comes after all three, and it is meant to make you plan before you build.
- When Center Button is pressed, play a sound "okey-dokey", then motor turn clockwise. - When Center Button is released, stop motor and play a sound "bravo".
Fullscreen it while you build — you can pause and scrub with the player's own controls.
- When Up button pressed, speed increse by 5, display the new speed. - When Down button pressed, speed decrease by 5, display the new speed. - The motor speed must stay strictly between 0% and 100% (it should not go above 100 or below 0). - Press the center button, motor turn clockwise at the set speed, release it stop the motor.
Fullscreen it while you build — you can pause and scrub with the player's own controls.
Set the initial speed to 0 1. When center button is pressed, the motor will turn clockwise with increase the speed by 10 for every 1 second and update the motor speed on the display. 2. Stop the loop once speed exceeds 100%. 3. Play a countdown sequence ("Three", "Two","One"), stop motor and exit the program.
Fullscreen it while you build — you can pause and scrub with the player's own controls.
Design your own gyro and test timer better than original. 1. When center button is pressed, set the speed to 100% and motor turn clockwise. 2. When the center button is released, stop motor, reset the timer and continuously display the live timer on the screen. 3. When up button is pressed, stop the timer and display the final recorded time.
Fullscreen it while you build — you can pause and scrub with the player's own controls.