EV3 Robotics›Level 3 · Advanced›Lesson 1
Level 3 · Lesson 1 · EV3-L03-0160 minutes · Ages 9–16 · Model: M134 Minigun (handheld)
The M134 Minigun: a handheld model with a cluster of barrels that spin as one, a Large Motor buried in the body to spin them, and a trigger you pull with your finger.
It is held, not driven. There are no wheels and no mat. Everything this model does happens in your hands, which makes it the right model for a lesson about tidying up a program — you can pull the trigger twenty times in a minute and see instantly whether the behaviour is the same every time.
By the end of the lesson your program will contain a block that you invented, with a name you chose — and the main part of your program will be short enough to read out loud in one breath.
A rotary gun is an engineering answer to a heat problem, and the problem is worth understanding even if the machine is not. Fire repeatedly through one barrel and the barrel gets hot; hot metal wears and warps, and eventually the tube is scrap. Richard Gatling’s answer in 1861 was to stop asking one barrel to do all the work. Put six in a ring, spin the ring, and each barrel gets the other five barrels’ worth of time to cool down before its turn comes round again.
The idea long outlived the weapon. It is why a rotary tool changer on a CNC machine carries a carousel of cutters instead of one, why a rotary valve in a bottling plant fills twelve bottles on a turning table instead of one at a stop, and why a big printing press puts the impression on a rotating drum. In each case the same job comes round again and again, so it is given to a ring of identical parts that take turns.
That is exactly the shape of today’s programming idea. A minigun does not have six different firing actions — it has one firing action that happens over and over, performed by whichever barrel is in position. Your program is about to be built the same way: one firing routine, given a name, used again and again.
When the same job keeps coming round, build it once and reuse it — in metal, and in your program.
Everything you have written for two whole levels has been instructions. Today you write a name. A My Block is a block you invent: you choose what it is called, you put a stack of blocks inside it, and from then on your program can say fire instead of spelling out five blocks.
when [1 v] is [pressed v] :: sensors hat play sound [Laser v] :: sound set status light to [red v] :: display [A v] start motor at (100) % speed :: motors wait (1) seconds :: control [A v] stop motor :: motors set status light to [green v] :: display
define fire play sound [Laser v] :: sound set status light to [red v] :: display [A v] start motor at (100) % speed :: motors wait (1) seconds :: control [A v] stop motor :: motors set status light to [green v] :: display
fire is explained to the Brick.when [1 v] is [pressed v] :: sensors hat fire :: custom
Nothing the model does. Pull the trigger and both versions behave identically — the same sound, the same spin, the same second of hold. The Brick runs exactly the same six blocks either way.
What changed is who has to understand it. The first version tells you how the minigun fires. The second tells you what the minigun does, and keeps the how in a drawer you open only when you want to change it.
| When you want to… | Without a My Block | With a My Block |
|---|---|---|
| Fire from a second trigger as well | Copy all six blocks. Now there are two copies. | Use fire again. Still one copy. |
| Make the burst longer | Change the wait in every copy. Miss one and the two triggers behave differently. | Change it once, inside the definition. |
| Work out what the program does | Read six blocks and infer. | Read the word. |
The danger is the second copy, not the first. One copy of a sequence is fine. The trouble starts the moment there are two, because from then on every change has to be made in two places and nothing warns you when you only make it in one. That is not a beginner’s mistake — it is the commonest bug in professional software, and it has a name: duplication.
fire, spin up, reset. Not block1, and not motor stuff.define hat appears on the canvas, and your new block appears in the palette.define hat. They are now the inside of fire.A My Block is a block you make yourself. You take a group of blocks that do one job, give the group a name, and from then on that name is the block.
| Block | What it does |
|---|---|
define grab | The head of a definition. Whatever is attached under it is what the block does. There is exactly one of these per My Block. |
grab :: myblocks | Runs the definition. Use it as many times as you like. |
define turn (degrees) | A definition with an input. degrees is a name for whatever number the caller types. |
turn (90) :: myblocks | Runs it with 90 in place of that name. |
Copying blocks works perfectly — right up until the copied thing has to change. Here are two robots driving a square, one with a My Block and one with the blocks copied four times, and then somebody asks for a bigger square.
a My Block, used four times
the same thing copied
↑ the fourth copy still says 2
The bug is not in any block. It is in the fact that the same idea was written down four times, and only three of them were updated.
The right-hand robot is not running a broken program. It is running four programs that were supposed to be identical, and three of them were updated. Nothing is misspelled, nothing reports an error, and the only evidence is a square that does not close.
The left-hand program is these two listings, and nothing else:
define side move [forward v] for (3) [rotations v] :: movement move [right: 100 v] for (0.5) [rotations v] :: movement
when program starts :: events hat repeat (4) side :: myblocks end
A My Block can take a value. Turn-right is useful; turn (degrees) is far more useful, because one definition then serves every turn in the program. The value is given a name when the block is made, and that name is used inside the definition wherever the number belongs.
The name is the part that trips people up. Inside the definition, (cm) is not a variable you have to set anywhere — it is a hole, and it is filled in with whatever the caller typed, every time the block is called.
EV3 movement blocks count wheel turns, and nobody measures a table in wheel turns. One turn of a standard driving wheel carries the robot about 17.5 cm, so driving 50 cm means asking for 50 ÷ 17.5 rotations. Doing that sum in your head, at every movement block, all program long, is how mistakes get in.
Put the sum inside a My Block once and the whole program can be written in centimetres. Change the two numbers below and watch where they end up.
These two numbers are the whole interface. Everything below is what the definition does with them.
what you write in the program
drive (50) cm at (75) % :: myblocks
the definition — (cm) and (speed) are names, not values
define drive (cm) cm at (speed) % set movement speed to (speed) % :: movement move [forward v] for ((cm) / (17.5)) [rotations v] :: movement
the same blocks, with your two numbers put in
set movement speed to (75) % :: movement move [forward v] for ((50) / (17.5)) [rotations v] :: movement
The green division block is doing the only real work: the movement block underneath counts wheel turns, and you asked in centimetres. One turn of these wheels carries the robot 17.5 cm, so 50 cm is 50 ÷ 17.5 = 2.86 turns.
Set the distance to 17.5, 35 or 70 and the part turn disappears — those are whole numbers of wheel turns. Every other distance leaves a fraction, which is exactly why the division belongs inside the My Block and not in your head.
Two inputs, and the definition is three blocks. Note what has actually been gained: not fewer blocks — the same blocks run either way — but a program you can check against a ruler. drive (50) cm at (75) % is either right or wrong about the table, and you can tell which without running it.
Typing a fixed number inside the definition instead of using the input is the classic slip — the block then ignores whatever it is given and always drives the same distance:
define drive (cm) cm at (speed) % set movement speed to (speed) % :: movement move [forward v] for ((50) / (17.5)) [rotations v] :: movement
That block takes a distance and throws it away. It will pass every test you run at 50 cm.
Here are those two My Blocks and a 100 × 100 cm mat. Drag blocks into the script, set the numbers, and press Run — the base always starts in the left-hand corner facing up the mat. Say where you think it will finish before you press it; the ruler is there to settle the argument.
Two My Blocks, a 100 × 100 cm mat and a ruler. Drag blocks into the script — or press one to add it — set the numbers, then Run and see whether the base ends up where you said it would.
my blocks — drag or press
the script — 0 / 8 blocks
Empty. Drag a block in from above, or press one.
Nothing to run yet. A square is four drives and four turns — try predicting the distance before you press Run.
Eight blocks is enough for a square with 40 cm sides, and not enough for anything you cannot picture. If a shape needs more than that, it wants a repeat (4) around it — which is the next thing a My Block usually grows into.
The Gyro Sensor gives an accurate turn, and it costs five blocks every time: reset the angle, start turning, wait until the reading is a few degrees short of the target, stop. Those five blocks are about the sensor. What the program wants to say is turn 90.
define turn (degrees) [2 v] reset angle :: sensors start moving [right: 30 v] :: movement wait until <([2 v] angle :: sensors) > ((degrees) - (4))> stop moving :: movement
The − 4 is the overshoot allowance from the Gyro Sensor module: the robot carries on turning for a moment after the motors are told to stop, so the block asks for less than it wants and lets it coast in. Written here, it is decided once. Written out at every corner, it is eleven chances to forget it.
Now the input earns its keep — because the shape a robot draws is decided entirely by that one number. A closed shape turns through 360° in total, so a shape with n corners turns 360 ÷ n at each one.
the whole program
when program starts :: events hat repeat (4) move [forward v] for (2) [rotations v] :: movement turn (90) :: myblocks end
what turn is, once
define turn (degrees) [2 v] reset angle :: sensors start moving [right: 30] :: movement wait until <([2 v] angle :: sensors) > ((degrees) - (4))> stop moving :: movement
Nothing in the program mentions the gyro. It is all inside turn, which is the point: the sensor is an implementation detail of turning, and the program should be about the shape.
Same definition, same drive block, same length of side. The only edit between a triangle and a pentagon is turn (120) :: myblocks becoming turn (72) :: myblocks. That is what a well-chosen input does: it turns a program that draws one shape into a program that draws shapes.
The same block also turns left, if you let it. Give the definition an if … then … else and a negative input means anticlockwise:
define turn (degrees) [2 v] reset angle :: sensors if <(degrees) > (0)> then start moving [right: 30 v] :: movement wait until <([2 v] angle :: sensors) > ((degrees) - (4))> else start moving [left: 30 v] :: movement wait until <([2 v] angle :: sensors) < ((degrees) + (4))> end stop moving :: movement
One block, two directions, and every program that uses it gets the left turn for free the moment this definition is edited.
The signal is repetition: the same sequence appearing in more than one place. That is the moment to name it. Making a My Block for something used once adds a layer without adding clarity.
The second signal is a unit. If the blocks convert between what you think in (centimetres, degrees, seconds) and what the hardware counts (rotations, sensor readings), that conversion is worth a name — it is the thing you will otherwise get wrong.
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.
A My Block turns a stack of instructions into a word — and words are what you can build with.
A good block name says what happens, not how. Test it like this: read your main program out loud. If it sounds like a description of the machine, the names are right.
A name that has stopped being true is worse than no name at all, because it is trusted. If you change what a block does, change what it is called.
Say this back before moving on: “A My Block is a stack of blocks with a name on the front.”
Put the model down and look at it. Which electronic parts can you find? There are three, and one of them you will feel before you see it.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The body of the gun, and the heaviest thing in your hands. It runs the program and its status light is part of the effect. |
| Large Motor — in the body, driving the barrels | Spins the whole barrel cluster through a gear train. Large rather than Medium because a ring of barrels has real rotational inertia: it takes torque to get it moving and it keeps turning after the motor stops. |
| Touch Sensor — the trigger | The only input. Note where it is: under your index finger, exactly where a trigger belongs. A control you can reach without looking is a design decision, not an accident. |
| The barrel cluster and gear train (not electronic) | Turns one motor shaft into six barrels going round together. Spin it by hand before you power it — if it is stiff or catches, the motor will struggle and every burst will sound different. |
Check the spin by hand first. A barrel cluster that binds will make the Large Motor stall, and a stalled motor draws current and gets warm without doing anything. If it does not coast freely for a turn or so after you flick it, something is rubbing — find it now, not after three failed programs.
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 |
|---|---|---|
| Barrel cluster (Large) | A | The model’s only motor, so it takes the first motor port. Every program on this page says [A v]. |
| Trigger (Touch Sensor) | 1 | The model’s only sensor. Keeping the trigger on 1 across the Level 3 handheld models means a program written for one nearly runs on the next. |
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.
Bluetooth suits this model. The minigun is picked up, aimed and swung about, and a USB cable turns that into a tethered experience — it also drags on the trigger cable, which is the one you least want disturbed. Fall back to USB if the room’s Bluetooth is busy.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Build it in two goes. First get the firing sequence working with no My Block at all — you cannot name a routine you have not got working. Then give it the name.
when [1 v] is [pressed v] :: sensors hat play sound [Laser v] :: sound set status light to [red v] :: display [A v] start motor at (100) % speed :: motors wait (1) seconds :: control [A v] stop motor :: motors set status light to [green v] :: display
fire. Click OK.define fire hat appears on the canvas. Drag it somewhere clear.when pressed hat — grab play sound and the five below it come with it — and drop them under define fire.when pressed hat is now empty. Drag the new fire block out of the palette and clip it underneath.define fire play sound [Laser v] :: sound set status light to [red v] :: display [A v] start motor at (100) % speed :: motors wait (1) seconds :: control [A v] stop motor :: motors set status light to [green v] :: display
when [1 v] is [pressed v] :: sensors hat fire :: custom
What success looks like: a two-block main program, a define fire hat with six blocks under it, and a minigun that behaves precisely as it did before you tidied it up.
If nothing happens now, you left the blocks behind. The commonest slip is clipping fire into place but never moving the six blocks into the definition — so fire is defined as nothing at all, and nothing is exactly what it does. Look at your define fire hat: is there a stack under it?
One change at a time. Predict, then run, then look. A student who predicts and turns out to be wrong has learned something; a student who only watches has merely seen something.
wait (1) seconds to (3) inside the definition. Predict the burst length first. Then ask the real question: how many blocks did you have to edit?start motor at (100) % to (30) %. Does the cluster get up to speed within the burst at all? A heavy ring at low power may never really spin before it is told to stop.[A v] stop motor, run, then put it back. What ends the burst now? Nothing does. This is the difference between a routine that cleans up after itself and one that leaves a mess for whatever runs next.fire to spin and read your main program aloud again. Does it still sound like a description of the machine? Names are part of the program.fire under the first. You get a double burst — from one definition, with nothing copied.Notice what you did not have to do. Every change above was made in exactly one place. Keep that feeling — it is what you buy each time you make a My Block.
A My Block turns a stack of instructions into a word — and words are what you build with.
Level 2 ended stuck on exactly this. The Forklift with Pulley ran the same five blocks four times over and had no way to give that sequence a name — that lesson said so on purpose, and left you feeling the gap.
You have just been handed the missing thing. Everything in Level 3 gets shorter from here:
You did not teach the minigun anything new today. You taught the program to explain itself.
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 the minigun a reload. Make a second My Block called "reload". Inside it: two beeps, the status light orange for two seconds, then back to green. Now call it straight after "fire", so the minigun reloads itself every time you pull the trigger. Your main program should still be short enough to read aloud: "when the trigger is pressed, fire, reload."
One pull, three bursts. Pulling the trigger once must now fire three bursts with a reload between each. Use a repeat loop and the two My Blocks you already have. Do not copy the firing blocks — if you find yourself pasting, stop and look at what you already named. The rule: everything below the "when trigger pressed" hat must fit in three blocks.
Make it overheat. A real minigun cannot fire for ever. After three bursts yours must refuse: instead of firing, it shows a warning on the screen, sets the status light red and plays a different sound for five seconds — then it is ready again. You will need a variable to count the bursts, and it is worth making a My Block called "cool down" for the refusing part. Work out the approach before you build it. Where does the count go up? Where does it get checked? Where does it go back to zero?
Programme a full firing drill, and keep it readable. Pressing the Brick centre button runs the whole drill by itself: three short bursts, a reload, two long bursts, a reload, and one final long burst. The screen counts the rounds remaining down from 12 to 0 as it goes, and the status light changes as the ammunition runs low. Two rules, and they are the mission: 1. The firing sequence may appear in your program ONCE. Everything else calls it. 2. Someone who has never seen your program must be able to read the main stack and say what the drill does, without opening a single My Block. Plan it on paper first. Decide what your named blocks are and what each one is responsible for BEFORE you drag anything. If you get stuck on the two burst lengths, that is the right thing to get stuck on — it is what the next lesson is about.