EV3 Robotics›Level 1 · Beginner›Lesson 18
Level 1 · Lesson 18 · EV3-L01-1860 minutes · Ages 9–16 · Model: Wind Plane
The Wind Plane: a long body balanced on a single big wheel lying flat on the ground, with a rotor at one end and the Brick at the other. The whole thing can pivot freely on that wheel, like a weathervane.
Spin the rotor up and the machine does something none of your earlier models did. Nothing touches it, nothing pushes it — and it turns.
By the end of the lesson you will be able to say where that turn came from, and you will have proved the exact thing the Apache’s tail rotor exists to prevent.
Four lessons ago you built the Apache and read that its little tail rotor exists to stop the body of the helicopter spinning. That was a claim. This is the model that tests it.
A rotor is a fan. It grabs air and throws it one way, and whenever you push something, it pushes you back just as hard, in the opposite direction. That is Newton’s third law, and it has no exceptions.
So a tail rotor throwing air to the left is itself being shoved to the right. On a real helicopter that shove is the whole point: it holds the tail against the twist of the big rotor overhead, and the pilot uses the foot pedals to turn the nose by changing it.
This is also how a rocket works, and it is worth being clear about, because most people get it wrong. A rocket does not push against the air. It throws its own exhaust backwards very fast, and the exhaust pushes the rocket forwards. That is why rockets work in space, where there is nothing at all to push against.
Take away whatever holds a helicopter’s body still and the body starts to spin. That is not a rare fault — it is what the machine does naturally, and the tail rotor is the thing standing in its way every second of every flight.
Your Wind Plane is deliberately built with nothing standing in the way. It sits on one wheel and is free to turn, so you get to watch the failure the tail rotor prevents.
You cannot push on the world without the world pushing back on you.
This model has no step-by-step manual. What we have is a video of the finished machine, not instructions to follow. You will be working the build out from it, with your teacher, rather than turning pages.
Watch it twice. The first time, watch the rotor. The second time, watch the body — and notice which way it turns compared with which way the rotor is throwing air. That single observation is the whole lesson.
A rotor pushing air one way is being pushed the other way by exactly the same amount. If the machine is free to move, it moves.
Lesson 39, the Hanging Bar, was about a robot with nothing to push against — hanging in the air, its motor could only swing its own weight about. This model is the opposite case. There is plenty to push against: air. And the moment the rotor starts throwing it, the air returns the favour.
Two things decide how much it turns, and neither of them is a block you have not met.
| Change this | And the body turns |
|---|---|
| [A v] set speed to (80) % — a faster rotor | Harder and sooner. More air thrown per second means a bigger push back. |
| [counterclockwise v] — the rotor the other way | The other way. The air goes left instead of right, so the body goes right instead of left. |
| How freely the wheel turns | The build, not the program. A sticky pivot can swallow the whole push and the machine will sit there looking broken. |
Throwing something away from you is a way of moving yourself. It is how rotors, propellers and rockets all work.
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.
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.
Say this back before moving on: “The rotor pushes the air one way, so the air pushes the machine the other way.”
Look at your machine. One motor, one Brick, one big wheel doing a job you have not seen a wheel do before — it is not driving anything, it is a bearing.
Which motor is it? There is no manual for this model, so nobody can tell you from a page. Hold yours against these two pictures and decide.
Large MotorMedium Motor| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program — and is the counterweight. It sits at the far end from the rotor so the machine balances on its wheel. |
| One motor, port A | Spins the rotor. Whichever motor you have, the program says A and runs the same. |
| The big wheel | Lying flat on the ground, carrying the whole machine and letting it pivot. No cable — it is not driven by anything. |
| Sensors | None. The machine cannot tell that it is turning. You can. |
The pivot has to be genuinely free. Give the body a gentle push by hand and let go. It should swing round and coast for a moment. If it stops dead, the pivot is binding, and no amount of rotor speed will show you anything. Fix it before you go on.
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 (the rotor) | A | One motor with a job of its own takes A. There is no pair, so B and C stay free. |
| Sensors | none | Ports 1–4 stay empty. |
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 for this model if you possibly can. A USB cable to a laptop will hold the body still, and a body that is held still cannot demonstrate the one thing this lesson is about. If you must use USB, download the program, unplug, and run it from the Brick’s own screen.
Six blocks. Say what is about to happen, wait, spin up, hold, stop — and watch the body, not the rotor.
when program starts :: events hat clear display :: display write [HANDS OFF] at line (1) :: display wait (2) seconds [A v] set speed to (60) % :: motors [A v] start motor [clockwise v] :: motors wait (6) seconds [A v] stop motor :: motors
Walk it in the order the Brick runs it:
What success looks like: you take your hands off, the rotor spins up, and the whole machine slowly swings round on its wheel — the opposite way from the air. Note which way the rotor throws the air and which way the body goes, because you are about to reverse both.
If the body does not turn at all, do not touch the program. Either the pivot is binding or the cable is on the floor. Both are section 6 problems.
One change at a time, and predict before each run. Every prediction here is about the body, not the rotor.
Step 4 is the one to think about afterwards. Your finger was doing the tail rotor’s job. On a real helicopter no one can hold the body still, so the machine has to hold itself — which is why there is a second rotor back there at all.
Lesson 43 told you why a helicopter needs a tail rotor. This model is the proof.
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.
Turn the machine a half turn and stop it there. Mark which way the nose points before you start, run the rotor until the body has swung round to face the opposite way, and stop. You will have to find the right running time by trying it, so keep a record of your attempts.
Turn it one way, then back again. The machine must swing round, pause, and return to roughly where it started — using nothing but the rotor. Mark the starting position first so everyone can see how close you got.
Measure the relationship between rotor speed and turning. Time how long the body takes to make one complete turn at four different rotor speeds, and write the four pairs of numbers down. Then find the slowest speed at which the body will turn at all, and explain what is stopping it below that.
Point the machine at a target, from any starting position. Your teacher will place a marker somewhere around the room and set your machine down facing a random direction. Your job is to make it turn and end up pointing at that marker — using only the rotor, with nobody touching it once it has started. This is harder than it sounds, and the reason is worth thinking about before you begin. Your machine cannot see the marker, cannot tell how far it has turned, and does not stop the instant the rotor stops. You will be working entirely from measurements you took beforehand. Plan on paper first. Work out what you need to know to convert an angle into a running time, and go and measure it. Decide what you will do about the coasting at the end. Two questions when you demonstrate it. How did you turn an angle into a number of seconds? And what is the biggest source of error in your method — be specific.
