EV3 Robotics›Level 1 · Beginner›Lesson 36
Level 1 · Lesson 36 · EV3-L01-3660 minutes · Ages 9–16 · Model: Gyro Launcher
The Gyro Launcher: a motor spins a gear up to speed, a stretched rubber band waits on a trigger, and when you pull the trigger the spinning top is flung out to fight.
You built the Dual Gyro back in Lesson 3 and launched two tops at once. This one is the serious version — it stores energy in a band like the Elastic Car, and it holds it until you choose to let go.
Everything about this machine depends on one thing: being at full speed before the release. A top that leaves the launcher half spun-up is a top that stops in three seconds. So today’s idea is about a block that does nothing when it runs — and decides everything that happens afterwards.
Spinning tops are old. The Japanese beigoma below is a small cast-iron top spun into a bowl against other tops — and it is the direct ancestor of the Beyblades sold in every mall today, launcher and all.
A top stays upright for the same reason a bicycle does: once something is spinning fast, it resists being tipped over. The faster it spins, the more stubbornly it holds its angle — and the longer it lasts before friction wins.
So a launcher has exactly one job, and it is not aiming. It is getting the top to the highest speed it can manage before letting go. Every real launcher — the ripcord, the winder, the geared handle — exists to solve that and nothing else.
Release too early and you have wasted the launch. Not slightly — a top spun at half speed does not last half as long, it wobbles over almost at once, because below a certain speed it cannot hold itself upright at all.
Some machines have a moment they must be ready for. Getting ready afterwards is the same as not getting ready.
This model has no step-by-step manual, and the video below is not one. What this lesson has is a film of a finished Gyro Launcher 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.
Not every block makes something happen. Some blocks only change what the next blocks will do — and they look exactly the same sitting in the stack.
| Block | When it runs, it… |
|---|---|
[A v] start motor [clockwise v] :: motors | Does something. The motor turns. You can see it and hear it. |
[A v] set speed to (100) % :: motors | Sets something. Nothing moves, nothing makes a sound. It writes down a number the motor will use next time it is asked to turn. |
You have quietly been using this since Lesson 3 without it being named. It matters today because of where the block sits. Put set speed after start motor and the motor spins up at whatever speed it was already using — and your new number sits there doing nothing until something asks the motor to move again.
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.
Both programs in that demo contain the same two blocks. That is what makes this bug so hard to find by reading: there is nothing wrong with either block, and nothing missing. Only the order.
A setting has to be in place before the thing it affects happens. Set the speed, then start the motor — never the other way round.
The same is true of some blocks you already know: set volume and set movement motors are settings too. None of them does anything on its own.
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 Touch Sensor is the simplest input the EV3 has: a button that is either pressed or not. That sounds trivial, but it is how a robot knows it has hit a wall, reached the end of a track, or been told to start by a person.
released
pressed| Block | What it does |
|---|---|
wait until <[1 v] is pressed? :: sensors> | Holds the program here until somebody presses the sensor. |
<[1 v] is pressed? :: sensors> | Reports true or false. Drop it into a condition to make a decision rather than a wait. |
[1 v] when [bumped v] :: events hat | Starts a whole stack of its own. The dropdown chooses the moment: pressed, released or bumped. |
A button is not only “pressed”. One press is three things: the moment it goes down, the time it stays down, and the moment it comes back up. Watch what a single press does to three programs at once.
versus two hat blocks
The middle counter is the one that surprises people. Nothing is wrong with it — a loop really does check that fast, and every check really is a separate answer.
Nothing there is broken. A loop really does get round hundreds of times a second, and each time it asks is pressed? the honest answer is still yes — so if that loop plays a sound or counts something, it does it hundreds of times from one finger. The two hat blocks each fire once, and they fire at different moments: pressed the instant the button goes down, bumped only when it comes back up.
The three options, and what each is for:
when program starts :: events hat set movement motors to [B v] and [C v] :: movement start moving [straight: 0] :: movement wait until <[1 v] is pressed? :: sensors> stop moving :: movement
The robot drives until something presses the sensor. Note that the movement is started unmeasured on purpose — the sensor decides when to stop, not a distance.
Touch sensors are everywhere in machines you cannot see into: a lift knows the doors are shut, a printer knows the lid is closed, a washing machine will not spin until it is latched. They are safety devices as much as inputs.
Say this back before moving on: “Set speed does not move anything. It decides how fast the next movement will be.”
Find the parts with cables. There are three — and you have to tell us which motor it is, because this model has no written parts list to check against.
Large MotorMedium Motor| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and anchors the launcher. |
| One motor — you decide which | Spins the gear that spins the top. Whichever it is, it goes in port A and every program below says A. |
| Touch Sensor | Starts the spin-up. The same part you met on the Timber Saw in Lesson 16. |
| The rubber band and trigger (no cable) | Holds stored energy and releases the top — the same elastic energy you measured on the Elastic Car in Lesson 14. |
The launch itself is not programmed. The motor spins the gear up; the trigger is pulled by a person. The program controls the getting-ready, and your hand controls the moment. Knowing which part is which is half of understanding this machine.
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 (spins the gear) | A | A single working motor takes A. Note the programs say A, not “the Medium Motor” — because the port is the thing the Brick actually knows about. |
| Touch Sensor (starts the spin-up) | 1 | Touch is always port 1 in this course, exactly as on the Timber Saw. |
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.
Keep the computer out of the firing line. Whichever you pick, set the launcher up so the top flies away from the desk rather than across it.
If the port 1 tile does not change when you press the button, stop. Nothing you write will start.
Six blocks. Set the speed, wait for a click, spin up, hold at speed, stop. You pull the trigger by hand while it is at full speed.
when program starts :: events hat [A v] set speed to (100) % :: motors [1 v] wait until [bumped v] :: sensors [A v] start motor [clockwise v] :: motors wait (3) seconds [A v] stop motor :: motors
Walk it in the order the Brick runs it:
What success looks like: a click, three seconds of rising whine, a top that leaves the launcher hard and stays upright for a good while. Time it. That number is how you will judge every change you make next.
If the top wobbles over almost at once, it left too slowly. Either the trigger went early, or the gear was not free, or the speed never reached 100 — which is what the next section is for.
One change at a time, and predict before each run. Time how long the top spins after each launch — that is your measurement, and it beats an opinion.
Step 2 is the nastiest bug in this lesson and worth sitting with. The program was wrong, and it worked — on the second try. A fault that disappears when you run it again is the hardest kind to find, and this is exactly how they happen.
“It worked the second time” is not fixed. It is a setting arriving too late.
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.
Prove the order matters, with numbers. Launch three times with set speed above start motor, and three times with it below, timing how long the top spins each time. Six timings, two averages, and one sentence saying which arrangement won and by how much.
Find the spin-up time your launcher actually needs. Try 1, 2, 3, 4 and 6 seconds between the click and your trigger pull, timing the spin each time. Report the point past which waiting longer stops buying you anything, and say what is happening at that point.
Make the launcher tell you when it is ready. It must warn before it starts spinning, show or sound something while it is spinning up, and clearly signal the moment it has reached full speed — so a person knows exactly when to pull the trigger without counting in their head.
Build a launcher that gives the same launch every time. Your machine must produce launches consistent enough to compete: five launches in a row whose spin times are close to each other, with the operator doing nothing but pulling the trigger when told. Consistency is the target, not the record — a launcher that is brilliant once and poor four times is no use in a tournament. Plan on paper before you build. List everything that could differ between one launch and the next, including the things a program cannot control, then decide which of them you can remove. Two questions when you demonstrate it. What is the biggest remaining source of difference between your launches, and how do you know? And which parts of your program are settings rather than actions — point at each one.
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.