EV3 Robotics›Level 2 · Intermediate›Lesson 36
Level 2 · Lesson 36 · EV3-L02-3660 minutes · Ages 9–16 · Model: Crazy Pirate Ship
The Crazy Pirate Ship: the fairground ride from Lesson 8, except this one can go all the way over the top. A tyre in the middle drives the ship, and two Touch Sensors — one left, one right — let a person push it either way.
You cannot get it round with one long push. The motor is not strong enough and never will be. You get it round by pushing in the right direction at the right moment, over and over, until each swing is bigger than the last.
Which means a person has to be at the controls, watching. And that breaks something about every program you have written so far: a single column of blocks, running top to bottom, cannot watch two buttons at once.
The swinging ship is in every theme park from Genting to Sunway Lagoon. The gentle ones swing to about forty-five degrees. The ones with a queue go past vertical and hang you upside down at the top.
The ride does not have a huge motor. It has a small one and a driving wheel pressed against the underside of the ship — exactly like the tyre in your model — and it uses the same trick you met with the Clock Ticking in Lesson 12.
Each push is small. But a push given while the ship is already moving the same way adds to the swing, and a few dozen of those build up to something enormous. That build-up of motion is momentum, and it is stored in the swing itself rather than in any part of the machine.
Push at the wrong moment and you do not just waste the push — you take energy out. A shove against a ship that is coming towards you slows it down.
So the operator has to react to what the ship is doing right now, continuously, in both directions. A machine that could only be told one thing at a time would be no use to them at all.
A machine a person drives has to be listening the whole time — not working through a list.
This model has no step-by-step manual, and the video below is not one. It is a film of a finished Crazy Pirate Ship going over the top. Watch it for the target — and watch what the driving tyre does at the moment the ship changes direction — then build from the model your teacher has. You are not missing a page; the page does not exist.
A program does not have to be one column of blocks. You can put down several separate stacks, each with its own hat, and the Brick runs them all at the same time.
Every program you have written has started with one hat: when program starts. There are others, and they wait for other things.
| Hat block | Its stack runs when… |
|---|---|
when program starts :: events hat | the green flag is pressed. Once. |
[1 v] when [pressed v] :: events hat | the Touch Sensor in port 1 is pressed — every time, for as long as the program is running. |
when [center v] button [pressed v] :: events hat | a button on the Brick itself is pressed. |
A sensor hat is not the same as wait until, and the difference is the whole lesson. Wait until stops the program at one spot until one thing happens, once. A hat sits there for the whole run and fires its stack every single time.
the program starts — all of these begin here
stack 1 · Medium Motor
stack 2 · status light
stack 3 · drive base
Every stack is highlighted at the same moment on purpose — that is what running in parallel looks like. The switch above changes only what the third stack controls.
Notice how the demo is drawn: the stacks are side by side under one starting bar, not stacked in a column. Nothing in one stack is “before” anything in another. They are simply all live.
One stack per thing that can happen. That is how a program listens to two buttons at once without ever asking “which one?”
One rule comes with it: one owner per motor. If two stacks both try to drive port A at the same moment, the last one to speak wins and the result is nonsense. Today that is safe, because a person only presses one button at a time — but it is the trap waiting for you the moment you add a third stack.
A program does not have to be one long column of blocks. Several stacks can run at the same time, each doing its own job — one driving, one watching a sensor, one keeping the display up to date.
Give each stack its own hat block. Every stack beginning with when program starts starts at the same instant — not one after another — and from then on they run alongside each other.
Nor is it limited to two. Below, three stacks run together: a Medium Motor turning an attachment, the status light flashing, and the drive base rolling. Watch the arrows at the top — they all begin at once, and no stack waits for any other.
when program starts :: events hat [A v] start motor [clockwise v] :: motors when program starts :: events hat forever set status light to [green v] :: display wait (0.5) seconds set status light to [red v] :: display wait (0.5) seconds end when program starts :: events hat start moving [straight: 0] :: movement
Written down they have to go one under another, because a page is a column — but that is an accident of paper. On the Brick they sit side by side, and nothing in the first stack happens before anything in the third.
Parallel stacks go wrong when two of them try to control the same thing. Use the switch below to take the wheels away from the third stack and point it at motor A, which the first stack is already driving.
the program starts — all of these begin here
stack 1 · Medium Motor
stack 2 · status light
stack 3 · drive base
Every stack is highlighted at the same moment on purpose — that is what running in parallel looks like. The switch above changes only what the third stack controls.
With one owner each, all three stacks are highlighted at the same instant and all three jobs get done. With two owners, motor A is handed contradictory orders hundreds of times a second and shivers instead of turning — and notice the second cost, which is easy to miss: the wheels now have nobody driving them. A stack that goes to fight over someone else’s motor has abandoned its own job. Nothing reports an error either way; as far as the Brick is concerned every stack is working perfectly. The same happens to a display line or a variable that two stacks both write to.
The discipline is simple: give each stack sole ownership of what it controls. One stack owns the motors, another owns the screen, another watches the sensors and tells the others what it found — which is what broadcasting is for.
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.
Say this back before moving on: “Each hat starts its own stack, and they all run at the same time.”
Four parts with cables. And again, you have to tell us which motor it is — no manual, no verified parts list.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program. It is also the heaviest thing in the frame, so it is what stops the whole model rocking off the table when the ship swings. |
| One motor — you decide which | Turns the driving tyre. Goes in port A, and every program below says A. |
| Touch Sensor ×2 | Left and right. Identical parts, told apart only by port — the lesson you just had with the Machine Gun. |
| The driving tyre (no cable) | Presses against the ship and pushes it along. It only works where it touches, which is why timing matters so much. |
Brick off. You met this routine with the Clock Ticking.
Step 4 is the whole game. Push with the movement, at the moment it is already moving fastest. Push against it and you are braking.
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 tyre) | A | A single working motor takes A, as it has all course. |
| Touch Sensor — left | 1 | Touch is always port 1 in this course. |
| Touch Sensor — right | 2 | The second one borrows the Gyro’s slot, same as the Machine Gun. There is no Gyro here to mind. |
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 every cable out of the ship’s arc. This model swings through a full circle if you get it right, and a cable in the way will stop it at exactly the moment you were about to succeed.
A swapped pair here does not look like a bug. It looks like a ship that refuses to swing however hard you try — because every push is landing on the wrong side.
Three stacks, six blocks. Look at the shape before you read the words: there are three separate hats, and a blank line between each. They are not one program that runs downwards — they are three programs that run together.
when program starts :: events hat [A v] set speed to (60) % :: motors [1 v] when [pressed v] :: events hat [A v] run [clockwise v] for (120) [degrees v] :: motors [2 v] when [pressed v] :: events hat [A v] run [counterclockwise v] for (120) [degrees v] :: motors
How the Brick handles this:
Now use it. Start the ship swinging gently by hand, then tap the button that pushes it the way it is already going, each time it passes the bottom. Small pushes, in time. Watch the swing grow.
What success looks like: a swing that gets visibly bigger over eight or ten well-timed taps, and a ship that eventually makes it over the top. It will take several goes. That is the machine working, not you failing.
If the swing never grows, you are almost certainly pushing at the wrong moment rather than pushing too weakly. Try deliberately mistiming it — push against the movement for a few swings and watch the swing shrink. Once you can kill it on purpose, you know which moment is the right one.
One change at a time, and predict before each run. Count how many taps it takes to get over the top — that is your score, and lower is better.
Step 5 is worth keeping for good. An emergency stop is the perfect job for its own stack, precisely because it must work regardless of where the rest of the program has got to. A single-column program can never offer that.
Anything that must work at any moment belongs in its own stack.
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.
Get it over the top, and count the cost. Using well-timed taps, bring the ship all the way round at least once. Then do it again and count how many pushes it took. Report your best count — and if you cannot get it round at all, report the biggest swing angle you reached and what is stopping you.
Add an emergency stop on its own stack, using a Brick button, that halts the drive whatever else is happening. Then prove it works by triggering it in the middle of a push rather than between pushes. Explain in one sentence why this belongs in its own stack.
Prove that timing beats force. Push at the wrong moment deliberately and bring a big swing down to almost nothing, then time how long that takes. Then do the opposite from rest. Report both, and state the rule you have demonstrated in one sentence.
Build the ride an operator could be handed, controls and all. Your Crazy Pirate Ship must be drivable by somebody who has not practised: two clearly labelled controls, an emergency stop that always works, and something on the Brick that tells the operator what the machine is doing. They should be able to build a swing and bring it safely back down to rest. Plan on paper before you build. Sketch every stack you are going to write and what starts it. Then check the one rule that will break you: does any motor have more than one stack trying to drive it? Two questions when you demonstrate it. Why does your emergency stop work no matter where the rest of the program has got to? And what would happen if two of your stacks fired at the same instant — have you made that impossible, or just unlikely?
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.