EV3 Robotics›Level 1 · Beginner›Lesson 7
Level 1 · Lesson 7 · EV3-L01-0760 minutes · Ages 9–16 · Model: Pirate Ship
The Pirate Ship: the fairground ride where a boat full of people hangs from a frame and swings higher and higher, one way and then the other.
Every motor you have run so far has gone one way. Wheels forward, wheel round, crank round, worm round — always clockwise, always the same direction. A swing cannot work like that.
By the end your ship will swing back and forth on its own, and you will have found — by testing, not by being told — the one timing that makes the swing grow instead of fighting itself.
Almost every theme park has one. The ship hangs from a pivot at the top of a tall A-frame, and it does not go round — it swings, further each time, until the people at the ends are nearly upside down.
A hanging weight that is pushed to one side and let go is a pendulum, and a pendulum has a timing of its own. It takes the same time to swing across whether the swing is big or small — that timing comes from how long it is, not how hard you pushed.
Which is why the ride does not need a huge motor. It needs a small push, given at the right moment, over and over.
Push in time with a swing and it grows. Push against it and it dies. Same push, same machine — only the timing is different.
You already know this in your body: it is exactly how you get a playground swing going without anyone pushing you.
A ride that tried to force a heavy ship through a big swing by brute strength would need an enormous motor and would shake its frame to pieces. Working with the natural timing is not a clever trick — it is the only affordable way to build the ride.
The block you have used since Lesson 1 has had a direction in it all along, and you have never changed it.
[A v] run [clockwise v] for (2) [rotations v] :: motors [A v] run [counterclockwise v] for (2) [rotations v] :: motors
One way then the other way is a swing. That is the whole mechanism — there is nothing else to it.
Put those two blocks in a loop and the ship goes back and forth for as long as you like. What decides whether the swing grows is not how hard the motor pushes but how long each push lasts compared with the ship’s own natural rhythm.
The wheel turns at a steady rate and the slider does not. Watch the two ends: it stops dead at both of them without the motor ever stopping.
A motor does exactly one thing: it goes round. Everything that wipes, saws, pumps, nods or waves is a mechanism converting that rotation into oscillation — a movement that goes one way, stops, and comes back.
Put a pin near the edge of a turning wheel and connect a rod from the pin to something that can only slide in a straight line. The wheel keeps turning one way; the slider goes out, stops, comes back and stops, once per revolution.
A crank with the rod attached to a pivoting arm rather than a slider gives a rocking motion instead of a sliding one. Same mechanism, and it is how a windscreen wiper works.
The wheel turns at a steady rate and the slider does not. Watch the two ends: it stops dead at both of them without the motor ever stopping.
A pendulum swings at a rhythm of its own, and that rhythm is set by exactly one thing you can control: its length. Longer means slower. Specifically the period goes as the square root of the length, so making it four times as long makes each swing twice as slow.
Two things students expect to matter and which do not:
This is worth meeting because it is the first mechanism in the course whose timing is not yours to program. If a nodding or swinging model has to keep a particular beat, you change its geometry, not its code.
| Rhythm set by | To change it | |
|---|---|---|
| Crank mechanism | the motor | change the motor speed — see Motor speed |
| Pendulum | the mechanism | change its length |
Push a free-swinging thing at its own rhythm and the swings grow — that is resonance, and it is how a child on a swing goes higher without anybody pushing harder. Push at the wrong rhythm and you fight it. A model that has to swing widely is far easier to build by matching the push to the mechanism than by pushing harder.
Engines run this backwards: the up-and-down of a piston becomes the round-and-round of a crankshaft, using exactly the linkage above. Sewing machines, pumps, saws and metronomes are all in the same family, and a clock is a pendulum used as a ruler for time.
Machines repeat. A wiper sweeps, a conveyor runs, a ride goes round — and none of that should mean copying the same blocks over and over. A loop says “do this again” once.
| Block | What it does |
|---|---|
repeat (10) end | Runs the blocks inside a set number of times, then carries on below. |
forever end | Runs the blocks inside over and over, and never carries on below. |
repeat until <> end | Repeats until a condition becomes true — a loop with a sensor as its exit. |
Anything placed after a forever loop will never run. Not “runs late” — never. Both programs below end with the same block: set the status light green.
repeat (3)
forever
↑ this block never runs
Both programs contain the same green-light block. Let it run as long as you like — the right-hand ring will never turn green.
The repeat loop counts its three passes, stops, and moves on to the block underneath, so its light turns green. The forever loop reaches the bottom of its own blocks and jumps straight back to the top, so the block underneath is never reached — however long you leave it. If a program seems to stop half way through, look for a forever loop above the blocks that are not happening.
A program is a list, and the Brick works down it once. Every block runs, in order, and when the last one is done the program is over. That is fine for a list of instructions — drive, turn, beep, stop — because each is a thing you do once.
A sensor is not a thing you do once. Asking is 1 pressed? gives you an answer about this instant, and an instant later it may be wrong. Checking a sensor once tells you what the world was like at the moment the program started — which is almost never what you wanted to know.
So a program that has to react must ask again, and again, for as long as it is running. That is the whole job of the loop: not to repeat an action, but to keep the question being asked.
Wrap a sensor check and the motor it controls in a forever loop and you have built a closed-loop control system — the pattern behind every line follower, thermostat and cruise control:
It is called closed because the output feeds back round to the input: the motors move the robot, moving the robot changes what the sensor sees, and what the sensor sees changes the motors. Break the circle at any point and the robot stops responding.
when program starts :: events hat
forever
if <[1 v] is pressed? :: sensors> then
[A v] start motor [clockwise v] :: motors
else
[A v] stop motor :: motors
end
endRead it as a sentence and it is almost too simple to need explaining: for ever, if the button is pressed run the motor, otherwise stop it. The motor now follows the button for as long as the program is running.
This is the mistake nearly everybody makes first, and it is a hard one to spot because nothing about it looks wrong:
when program starts :: events hat if <[1 v] is pressed? :: sensors> then [A v] start motor [clockwise v] :: motors else [A v] stop motor :: motors end
The logic is perfect. The ports are right. Nothing is misspelled. And the robot will ignore the button completely — because the Brick reaches that if/else a few milliseconds after you press Run, finds the button not pressed, takes the else branch, stops the motor, runs out of blocks and ends. By the time a finger arrives, there is no program left to notice it.
with forever — a closed loop
without it — the common mistake
↑ running — for the only time
Both programs contain exactly the same if/else. The only difference is the forever block around one of them.
Both programs contain exactly the same if/else. The counter is what gives it away: one keeps checking for as long as it runs, the other is stuck on the single check it made before anybody touched anything. A student who has seen this once stops writing it.
The tell on a real robot is a program that ends the instant you start it — the Brick returns to its menu almost immediately. If a sensor program finishes rather than waits, the loop is what is missing.
Say this back before moving on: “A swing is one direction then the other, repeated — and the timing of the push decides whether it builds up or dies away.”
Look at your model and find the parts with cables. There is a Brick and there is one motor — and this time you have to tell us which motor it is.
Large Motor
Medium MotorThis is a real question, not a quiz. This model is built from a video rather than a printed manual, so its parts list has never been written down. Compare the motor in your hand with the two pictures above and write down which it is. Your programs work either way — a motor block names a port, not a kind of motor — but you should know what you are holding.
Before you switch anything on, find the single point the ship hangs from and swing it by hand. Two things to notice:
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 (drives the swing) | A | A single working motor conventionally takes A, and every program on this page says A. If the video put yours somewhere else, either move the cable to A or change the letter in every block — but do not do half of each. |
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 motor cable clear of the swinging ship. A cable that catches the ship at one end of its swing will damp it just enough to ruin every measurement you take today, and it will look like a program problem.
That last one matters today. Clockwise and counterclockwise are about to be the entire lesson, so make sure you can see the difference on the screen before you rely on it.
Six blocks: push one way, push the other, five times over, then a bell to say the ride is done.
when program starts :: events hat [A v] set speed to (60) % :: motors repeat (5) [A v] run [clockwise v] for (0.6) [seconds v] :: motors [A v] run [counterclockwise v] for (0.6) [seconds v] :: motors end play beep (60) for (0.5) seconds :: sound
Walk it in the order the Brick runs it:
What success looks like: the ship rocks back and forth in a steady rhythm. It may not swing very far yet, and that is expected — 0.6 seconds is a guess, and the next section is where you beat it.
This is a measuring exercise, so measure. Mark on the frame — or just watch against a fixed point behind — how far the ship gets at its highest, and write the number down for every run. Always start the ship hanging still.
Step 3 is the discovery, and you made it rather than read it. The best push is not the hardest or the longest. It is the one that arrives when the ship is already going that way.
If the ship barely moves at any timing, check the frame is not sliding on the table and the cable is not catching the hull. Both of them take energy out of the swing on every single pass, which is exactly the thing you are trying to put in.
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 ride swing gently for a long time instead of fiercely for a short one: fifteen swings that never rise above halfway. Keep it steady — a ride that grows and collapses and grows again has not been controlled, it has been left alone.
Give the ride a proper shape: it must start gently, build to its biggest swing in the middle, and die down again at the end, before sounding a bell. The change must be gradual enough that a person watching would call it one ride rather than three.
Find and report your model's natural swing time. Push the ship once by hand, let go, and time how long a complete there-and-back takes. Then show that your best pushing timing is close to half of it, using at least four measured timings as evidence. Numbers, not opinions.
Build the ride an operator would actually be given. Your Pirate Ship must reach a big swing and then be brought safely back to rest — not switched off mid-swing, but slowed down deliberately until it hangs still enough for passengers to step off. It must then be ready to run again without anyone touching the model. Plan on paper first. Getting a swing going and stopping one are opposite problems: work out what you have to change about the timing of the pushes to take energy out rather than put it in, and test that idea before you build the whole program. Two questions when you demonstrate it. What exactly makes a push slow the ship instead of speeding it up? And how long does your ride take to bring the ship to rest — measured, and is that fast enough for a real queue?