EV3 Robotics›Level 2 · Intermediate›Lesson 12
Level 2 · Lesson 12 · EV3-L02-1260 minutes · Ages 9–16 · Model: AH-64 Apache Helicopter
The AH-64 Apache: a long-nosed attack helicopter with a four-bladed rotor on top, a small rotor standing upright at the tail, and a gun slung under the nose. Switch it on and all three move at once.
It is the biggest build of the level so far — seventy-four steps — and almost all of that is gears. Underneath the body panels is a chain of them running the whole length of the aircraft.
By the end of the lesson one Medium Motor will be turning the main rotor, the tail rotor and the gun together, with the Brick screen reporting what the aircraft is doing. And you will be able to explain why you cannot make the tail rotor spin faster than the main one.
A helicopter does something no aeroplane can: it rises straight up, stops in mid-air and hovers. That is why they fly mountain rescues, land on hospital roofs and drop water on wildfires. A runway is not needed, because the wing is spinning instead of the aircraft moving.
The main rotor blades are wings that go round. They throw air downwards, and the air pushes back up — that push is the lift holding the machine in the sky.
But throwing a heavy rotor round one way shoves the body of the helicopter the other way. Left alone, the cabin would spin under the blades like a fairground teacup. The small tail rotor exists only to push sideways against that spin and hold the nose still.
Here is the part that matters today. In a real Apache the tail rotor is not a separate engine with its own throttle. It is driven off the same engine as the main rotor, through a long shaft down the tail boom. The two are geared together on purpose.
If the tail rotor could slow down on its own while the main rotor kept going, the aircraft would begin to spin — and the pilot would have a second thing to control at the worst possible moment. Locking them together means that whatever the engine does, the tail is always pushing in the right proportion.
Losing the tail drive is one of the most serious failures a helicopter can have, which tells you how much work that little rotor is doing.
One engine, geared to everything, so nothing can drift out of step with anything else.
A gear train can split one motor’s turn between several mechanisms — and everything on that train is then locked to the same source.
Every model you have built so far had one motor per moving thing, or two motors sharing one job. The Apache is the other arrangement: one motor, three moving things. The gears carry its turn up to the main rotor, back along the tail boom to the tail rotor, and forward to the gun.
The consequence is the thing to take away. Because they are all on one train, the three mechanisms have fixed proportions. The gearing may make the tail rotor spin four times for every one turn of the main rotor — but it is always four. Change the motor speed and all three change together, in step, by the same factor.
| What you want to change | Where you change it |
|---|---|
| How fast everything turns | In the program — [A v] set speed to (30) % |
| Which way everything turns | In the program — the [clockwise v] dropdown |
| How fast the tail rotor turns compared with the main rotor | Nowhere in the program. That is set by the gears, and only a rebuild changes it. |
That last row is Lesson 18 coming back. Some things are program problems and some things are build problems, and telling them apart saves you an hour of editing blocks that were never going to help.
One motor on a shared gear train sets the speed of everything. The build sets the proportions between them.
The Medium Motor is the smaller of the two EV3 motors. It is quick and light rather than strong, which makes it the right choice for anything that has to move a part of the robot rather than the whole robot — a gate arm, a pair of jaws, a winch, a pointer.
side
from above| Block | What it does |
|---|---|
[A v] run [clockwise v] for (1) [rotations v] :: motors | Turns the motor a measured amount, then stops. One rotation is one full turn of the motor shaft. |
[A v] run [clockwise v] for (90) [degrees v] :: motors | The same idea, but in degrees — useful when a quarter or a half turn is what the mechanism needs. 360 degrees is one rotation. |
[A v] run [clockwise v] for (2) [seconds v] :: motors | Turns the motor for a length of time and then stops, whatever the shaft managed to do in it. The one measurement that always finishes. |
[A v] set speed to (50) % :: motors | Sets how fast the motor will run from now on. It does not start the motor by itself. |
[A v] start motor [clockwise v] :: motors | Starts the motor turning and moves straight on to the next block. It keeps going until something stops it. |
[A v] stop motor :: motors | Stops the motor. |
These two look similar and behave completely differently, and almost every early EV3 bug comes from picking the wrong one. Watch both run the same job, over and over.
versus
Let it loop a few times. The left dial keeps landing on the same mark; the right one leaves a new mark almost every run — that scatter is what “not repeatable” means.
The black mark is where the shaft should finish. The measured motor hits it every single run, because the program waits at that block until the motor has turned exactly that far. The timed motor is only running for a second — and a second covers a different amount depending on the battery, the friction and whatever the mechanism is carrying. Each orange dash is a run that finished somewhere it was not asked to.
If a mechanism has to end up in a particular place — a gate that must finish upright, a jaw that must close fully — use the measured block.
The dropdown at the end of the run block has a third setting, and it is the one that saves lifting mechanisms. for () seconds switches the block off a distance and onto a duration: it drives the motor for that long and then stops, whatever the shaft managed to do in the time.
That sounds strictly worse than a measured turn, and for most jobs it is. It matters because of what the measured block actually waits for. run for (90) degrees does not finish when 90 degrees’ worth of time has passed. It finishes when the shaft has turned 90 degrees — and if the mechanism runs out of travel first, the shaft never will.
Every arm, jaw and lift has a physical limit: a point where the mechanism reaches the top of its travel, or something in the build gets in the way. Push a motor into that limit and it stalls — the shaft stops turning and the motor sits there straining. The motor is fine and the program is spelled correctly. But the encoder has stopped counting, so a measured block that was told a bigger number is still waiting, and it will wait until the Brick is switched off.
Nothing after that block ever runs. Not the next motor block, not the sound, not the display, not the rest of the program. That is the whole failure, and it looks like a crash even though nothing has crashed.
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [clockwise v] for (90) [degrees v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
Watch the Brick screen, not the arm. HOME SET is the block after the motor block, so a blank screen means the program never got past it.
Compare the first two. The only difference between them is 45 and 90, the mechanism is identical, and one of them is a working program while the other locks up on the third block. Nothing in the listing distinguishes them — the end stop is a fact about the build, and the program has never heard of it.
This is the mistake almost every student makes the first time a Medium Motor lifts something. A lifting arm has a lowest position and a highest one; ask it to turn past either and the program hangs. It is worse than an ordinary bug, because the robot looks alive — the motor is still being driven, still buzzing, still hot — and the next block never comes.
The fix turns the problem into the technique. You often do not know how many degrees it is to the top of an arm’s travel — it depends on the build, and it changes the moment somebody rebuilds it. So do not measure it. Drive the arm gently into its own end stop for a couple of seconds, and then declare that position to be zero:
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [counterclockwise v] for (2) [seconds v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
Three things make that work, and all three are deliberate:
After that, use measured blocks for everything inside the travel and timed blocks whenever you are driving to a limit. The rule of thumb: if the movement ends against something solid, run for seconds.
A Medium Motor is normally plugged into port A or D, which leaves B and C free for the Large Motors that drive wheels. The letter in the block must match the port the cable is actually in — this is the single most common reason a program appears to do nothing at all.
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.
Two meshed gears are a bargain. Whatever one of them gains in turns it loses in force, and whatever it loses in turns it gains in force. There is no arrangement of gears that gives you more of both, and no amount of building will find one.
Count the teeth on the gear you are turning (the driver) and the teeth on the one being turned (the follower). That is the whole calculation:
turns out = turns in × driver teeth ÷ follower teeth
An 8-tooth gear driving a 24 gives ⅓ of a turn out for every turn in — and three times the turning force. Turn the pair round and you get three turns out and a third of the force. Count the turns yourself below.
The number of teeth is the whole story. 8 teeth driving 24 means 8 ÷ 24 of a turn out for every turn in — and the force changes by exactly the opposite amount.
| Arrangement | Turns | Force | What it is for |
|---|---|---|---|
| Gearing down — small driving large | fewer | more | winches, lifts, robot arms, anything that has to move a weight |
| Gearing up — large driving small | more | less | fans, spinners, launchers, wheels on a light fast robot |
| 1 : 1 — same size | same | same | moving the drive to a different axle, or fixing a direction |
The names are worth getting right because they are backwards from what people expect: gearing down makes the output slower, not smaller, and it is the setting that makes a weak motor able to lift things.
Put several pairs in a row and the ratios multiply. Two 1:3 reductions in series give 1:9 — which is how a Medium Motor ends up able to raise something it could never shift directly. This is also how a gearbox with a sensible number of parts reaches a ratio that a single pair never could: a 40-tooth gear driven by an 8 is 1:5, and doing it twice is 1:25.
Only the first and last gear affect the ratio. Anything in the middle passes the motion along and changes nothing but the direction — which is a whole idea of its own, in Changing the direction of a turn.
Every mesh loses a little to friction, so a long train is less efficient than a short one. Gearing down far enough to lift a heavy load also makes the mechanism slow, and slow is not always acceptable. And a gear train that is geared down hard is very hard to turn backwards by hand, which is either a useful brake or a nuisance depending on what you are building.
A bicycle is the same idea with a chain instead of teeth in mesh: the low gear that gets you up a hill is turning the back wheel slowly and pushing hard, and the high gear you use going downhill does the opposite. Cars, drills, cranes and clocks are all making the same trade.
Say this back before moving on: “Everything on one gear train shares one motor. I can change how fast they all go, but not how fast one goes compared with another.”
Look at your finished Apache. Which parts have a cable? For a model this size the answer is surprisingly short.
Medium — in this build
Large — not used here| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program, and is the fuselage. The screen faces the side and is the aircraft’s instrument panel. |
| Medium Motor, port A | Drives everything. Fast rather than strong, which suits rotors — they need turns, not force. |
| Sensors | None. The Apache cannot tell whether its rotors are actually turning. It only knows what it was told to do. |
Turn the main rotor by hand before you plug anything in. The tail rotor and the gun should move too. If they do not, a gear has come out of mesh somewhere along the boom — find it now, because from here on 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.
The manual builds the Apache all the way to the finished aircraft and never once shows you where to plug the cable. That is not an oversight to worry about — it is your decision, and the course has a habit for it.
| Part | Port | Why this one |
|---|---|---|
| Medium Motor (the whole drivetrain) | A | A single motor with a job of its own takes A. B and C are kept for a matched pair, and this model has no pair. |
| Sensors | none | Nothing numbered is used. Ports 1–4 stay empty, and an empty port is a perfectly good answer. |
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 is the kinder choice for this model. The Apache is tall and the rotor sweeps a wide circle; a USB cable running to a laptop is one more thing for a blade to catch.
Eight blocks: a start-up announcement on the screen, then the rotors spin for five seconds and stop.
when program starts :: events hat clear display :: display write [ROTORS TURNING] at line (1) :: display play sound [Mechanical / Motor start v] until done :: sound [A v] set speed to (30) % :: motors [A v] start motor [clockwise v] :: motors wait (5) seconds [A v] stop motor :: motors
Walk it in the order the Brick runs it:
Remember the difference from lesson 2: [A v] start motor runs until something stops it, so it needs a wait and a stop. A [A v] run [clockwise v] for (2) [rotations v] block measures its own ending. Here the first is right: a rotor spins for a length of time, not for a number of turns.
What success looks like: the screen reads ROTORS TURNING, the engine sound plays, and then the main rotor, tail rotor and gun all turn together for five seconds and stop at the same instant. If one of the three is still, that is a gear out of mesh — not a block.
One change at a time, and predict before each run. Write your prediction down before you press play — being wrong on paper is how you find out what you actually believed.
Step 5 is the lesson. The program can set how fast the whole aircraft runs, and nothing else. The proportions between the three mechanisms were decided by whoever chose the gears, and the only way to change them is to take the tail boom apart.
If a change is not possible in the program, stop looking for a block and go and look at the build.
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.
Make the Apache run a proper start-up and shutdown. The screen must say what the aircraft is doing at each stage, the rotors must spin up gently rather than jumping to full speed, and everything must come to a stop on its own. Somebody watching should be able to follow what is happening without being told.
Fly a mission with three phases: idle, cruise, and full power. Each phase must run at a different speed, last a different length of time, and announce itself on the Brick screen. Write down the speed and the duration of each phase before you build it, then check that what the aircraft does matches your plan.
Count the gearing yourself and prove it. Work out how many turns the tail rotor makes for every one turn of the main rotor, using nothing but the port A reading and your own eyes. Then use that number to run the aircraft for an exact number of main-rotor turns. Report the ratio and how you measured it.
Build a start-up sequence a pilot could actually use. A real aircraft is not switched on. It is brought to life in a fixed order, with a check at each stage, because doing it in the wrong order breaks things. Your job is to design that sequence for your Apache and make the Brick run it. Plan on paper first. Decide what the stages are, what the screen says at each one, and how long each lasts. At least one stage must give a person time to do something — stand clear, confirm the rotor is free — and the aircraft must not move during it. Then build in a shutdown that is not simply the reverse. Ask yourself what a rotor with momentum needs that a stationary one does not. Two questions when you demonstrate it. Why did you put your stages in that order? And what would go wrong if somebody skipped one?