EV3 Robotics›Level 2 · Intermediate›Lesson 24
Level 2 · Lesson 24 · EV3-L02-2460 minutes · Ages 9–16 · Model: Lucky Draw Machine
The Lucky Draw Machine: a paper wheel cut into segments, a pointer at the top, and a motor that spins the wheel. It slows down, coasts, and stops — and whichever segment is under the pointer is your prize.
Here is the question worth asking before you build it. How does the machine decide where to stop?
It does not. Nothing in the program picks a segment, and there is no block anywhere in this lesson that produces a random number. The wheel just spins and runs out of speed — and that turns out to be enough.
The roundabout in a playground. You push it as hard as you can, jump on, and it goes round and round and gradually slows and stops — and you have no idea in advance which way you will be facing when it does.
Once it is turning, a heavy wheel keeps turning. That stored motion is momentum, which you met on the Stone Grinder in Lesson 20 — and here it is the feature rather than the nuisance.
What stops it is friction: a little at the bearing, a little from the air. Friction is small and steady, so a fast wheel takes a long time to stop, and it makes hundreds of turns getting there.
And that is where the unpredictability comes from. To know where it will stop you would have to know exactly how hard the push was, exactly how much friction there is today, exactly how the paper is sitting. A difference far too small to notice at the start becomes half a turn by the end.
Imagine a prize wheel that always stopped in the same place. It would be worthless — everybody would get the same prize, and after one go nobody would want another.
A draw has to be one nobody can predict, including the person who built it. That is not decoration; it is the entire reason the machine exists.
A long coast turns a tiny difference at the start into a completely different answer at the end.
Two blocks you already know, used in a way you have not needed before: start the motor, stop the motor, and let the wheel carry on by itself.
| Block | What happens to the wheel |
|---|---|
[B v] run [clockwise v] for (3) [rotations v] :: motors | Exactly three turns, then it holds. Predictable — the same three turns every single time. |
[B v] start motor [clockwise v] :: motors | Spins up and keeps going, with no ending built in. This is the Lesson 4 block. |
[B v] stop motor :: motors | Stops driving it. The wheel keeps turning on its own and coasts to a halt — and where it lands is nobody’s decision. |
That third row is the whole lesson. You noticed it on the Stone Grinder, where the stone kept turning after the program had finished and it was slightly annoying. Here it is the machine.
EV3 does have a random block, and you are not using it. It belongs to a later level, and for this machine it would be the wrong tool anyway: a random number would tell the wheel where to stop, and then you would have to make it stop there — which is far more work than simply letting go.
The physical world is already unpredictable. Sometimes the cheapest way to get a surprise is to stop controlling something.
The Large Motor is the bigger of the two EV3 motors. It turns more slowly than the Medium Motor but pushes far harder, which is why it drives wheels and lifts loads. If a mechanism struggles or stalls with a Medium Motor, this is usually the answer.
Large Motor
Medium Motor| Block | What it does |
|---|---|
[B v] run [clockwise v] for (3) [rotations v] :: motors | Turns the motor a measured amount, then stops. |
[B v] run [clockwise v] for (2) [seconds v] :: motors | Turns it for a length of time rather than a distance, then stops — however far the shaft actually got. |
[B v] set speed to (40) % :: motors | Sets how fast the next movement will be. |
[B v] start motor [clockwise v] :: motors | Starts it turning and carries straight on. |
Give both motors the same program and the same arm. With nothing on the arm the Medium Motor wins easily — which is why it is tempting to treat it as simply the better motor. Then the demo hangs a weight on both arms and runs it again.
and on the Large Motor, only the port changes
Turning the speed up would not rescue the Medium Motor here — a stalled motor needs more force, which means gearing it down or using the Large Motor.
That is the whole difference. The Medium Motor is quicker; the Large Motor is stronger. A motor that cannot produce enough force does not move slowly — it stops altogether and strains, which is the buzzing, going-nowhere failure almost every LEGO builder meets sooner or later.
Being stronger buys the Large Motor a bigger load, not an infinite one. Every winch runs out of cable and every lift reaches the top of its rails, and when a motor arrives at a limit it stalls: the shaft stops turning and the motor sits there straining.
That is a problem for the program, not just the mechanism. run for (3) rotations does not finish when three rotations’ worth of time has gone by — it finishes when the shaft has actually turned three times. A winch that reaches the top after two and a half will never report three, so the block waits, and every block after it is unreachable. Nothing crashes. The motor keeps pushing and the rest of the program simply never happens.
The third setting in that dropdown is the way out. for () seconds drives the motor for a duration and then stops regardless, so it always finishes and the program always moves on. Drive into a limit slowly, for a comfortably long time, and then call that position zero:
when program starts :: events hat [B v] set speed to (30) % :: motors [B v] run [counterclockwise v] for (3) [seconds v] :: motors [B v] reset degrees counted :: motors
The lift ends up against its own stop, the encoder is zeroed there, and every measured move afterwards starts from a place you know. The rule is the same for both motors: if the movement ends against something solid, run for seconds; if it ends somewhere in the middle, measure it. The Medium Motor module has the animation for it — see The Medium Motor, which is where this bites hardest, because a Medium Motor is usually the one doing the lifting.
The blocks are identical apart from the port letter, so swapping one motor for the other is a build change, not a programming change.
Real machines match the motor to the load. A lift uses a powerful, slow motor; the button panel beside it uses tiny ones. Choosing the wrong size is the most common reason a LEGO mechanism whines but does not move.
The Brick has five buttons of its own — up, down, left, right and centre. They need no sensor, no cable and no port, which makes them the easiest way to let a person tell the robot to do something.
| Block | What it does |
|---|---|
when [center v] button [pressed v] :: events hat | Starts a whole stack when that button is pressed. |
wait until <is [center v] button pressed? :: sensors> | Holds an existing program until the button is pressed. |
A program sitting on a wait block looks exactly like a program that has crashed. Watch one wait — including through two presses of the wrong button.
the other way to do it
A program parked on a wait block looks identical to a crashed one. This is why the status light or a line on the screen is worth setting before you wait.
The wait is watching one button. Up and right change the (button) reading, and the program does not care. That reading is a number rather than a name: 0 for nothing, then 1 left, 2 centre, 3 right, 4 up, 5 down.
Nearly every machine has a start button that is deliberately separate from switching the power on. A robot that begins moving the instant it is powered up is hard to set down and hard to test — one that waits for a press can be positioned first.
Say this back before moving on: “Stop motor stops driving it. It does not stop the wheel.”
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program, and its centre button is the start switch for the draw. |
| Large Motor, port B | Spins the wheel. Strong, because a paper wheel on an arm has real swing to it. |
| Large Motor, port C | The lever the player pulls down. See the note below — your program does not read this one. |
| The paper wheel (no cable) | You cut this yourself: a disc divided into 8 to 12 segments. |
About the lever, honestly. Making the program react to somebody pulling that second motor means reading a motor backwards — asking it how far it has been turned by hand. That is a real EV3 skill and it is a Level 3 one, so it is not in this lesson. For now the lever is a satisfying thing to pull and the Brick’s centre button is what actually starts the draw. When you meet degrees counted properly, come back and wire it up.
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 |
|---|---|---|
| Large Motor (spins the wheel) | B | The motor the program actually drives. Every block below says B. |
| Large Motor (the player’s lever) | C | Plugged in and doing nothing, on purpose. Leaving it connected means it is ready the day somebody adds the Level 3 code. |
| The centre button | none | Part of the Brick, like the screen and the speaker. |
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 Brick has to be reachable today. The centre button starts the draw, so mount the Brick where a player can press it without leaning across the spinning wheel.
That number climbing with no program running is proof the motor is a sensor as well as a motor. Level 3 is where you get to use it.
Six blocks: wait for a player, spin up, drive for two seconds, and let go. Notice there is nothing in here that decides an answer.
when program starts :: events hat wait until <is [center v] button pressed? :: sensors> [B v] set speed to (100) % :: motors [B v] start motor [clockwise v] :: motors wait (2) seconds [B v] stop motor :: motors
Walk it in the order the Brick runs it:
What success looks like: press the button, the wheel winds up for two seconds, then spins freely for several more before settling — and the pointer lands on a clearly readable segment. Run it five times and get five different answers.
If it keeps landing on the same segment, the coast is too short. Free up the bearing, take weight off the wheel, or drive it for longer. A wheel that stops after half a turn is a wheel you could predict.
This section is a measurement, not a fiddle. Run each version ten times and write down which segment came up each time. Ten is not many, but it is enough to see the difference.
Step 4 is the surprise, and it is the reverse of everything the course has taught so far. Measured movement has been the reliable, grown-up choice since Lesson 5 — and here it is the wrong one, because reliability is exactly what this machine must not have.
Precision is not always the goal. Ask what the machine is for before you decide which block is better.
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 your draw is fair enough to use. Run twenty draws and tally which segment comes up each time. Report the tally. Every segment does not have to appear — twenty is a small number — but if half of them never come up at all, your wheel is not spinning freely enough and you should say so.
Make it a proper show. The machine must announce that it is starting, build suspense while the wheel spins, and signal clearly when the wheel has stopped and the result can be read. Use sound, screen and status light, and time it so the announcement does not arrive before the wheel has actually settled.
Break your own machine, then fix it. Deliberately make the draw predictable — a short spin, a tight bearing, a slow speed — and show it landing on the same few segments over twenty runs. Then undo it and show the difference. Report both tallies side by side.
Build a draw somebody would accept losing on. Your machine must be one another group is willing to use for a real prize, which means they have to be convinced they cannot influence or predict it. Run it in front of them and let them try to work out how to make it land where they want. Plan on paper before you build. Decide what would make this draw unfair — a wheel that always stops in the same arc, a pointer that can be nudged, a spin the player controls — and design each one out. Two questions when you demonstrate it. Nothing in your program chooses a segment, so what does? And how long does your wheel coast for after the program has finished, and why does that number matter more than anything you wrote?
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.
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.