Challenge 1
Build a four-control panel that flies the crane — up, down, left, right — with each control on its own stack and every motor holding position when it stops.
What you are building 3 min
The Crane: a slewing tower with a hoist, operated by the Brick’s buttons — up, down, left, right — with limits that stop it hurting itself.
Every machine you have built this level ran a routine. You pressed Play and it did its thing.
A crane does not have a routine. An operator decides, moment by moment, and the machine’s job is to do exactly what it is told — and to refuse the few things that would break it.
In the real world 5 min
Where you have seen it
Tower cranes stand over every building site, lifting steel and concrete all day. One operator sits at the top with two joysticks and a screen, and everything the crane does comes from those hands.
Why it is built that way
A building site is different every hour. Loads arrive in different places, people move around, the wind changes. No routine could cope — so the crane does not try. It is a set of controls, and the intelligence is the operator.
But it is not only controls. Underneath the joysticks sit limits the operator cannot override: the hoist stops before the hook reaches the pulley, the slew has an end, and the load moment indicator will refuse a lift that would tip the crane over. The operator decides what to do; the machine decides what is survivable.
What would go wrong without it
Controls with no limits mean the machine is only as safe as the tiredest moment of the operator’s shift. Limits with no controls mean a machine that can only do what somebody guessed in advance. Real machines need both, and the limits have to be the part that cannot be argued with.
The operator says what to do. The machine says what it will not do.
The main concept — one control, one stack 6 min
A control panel is not one clever program. It is several small ones, each owning one control and one motor, all running at once.
when [up v] button [pressed v] :: events hat [A v] run for (90) [degrees v] at (30) % speed :: motors when [down v] button [pressed v] :: events hat [A v] run for (90) [degrees v] at (-30) % speed :: motors
You have had every piece of this since Lesson 1. Separate stacks run independently; a button hat waits for its own button. What is new is using that to build an interface rather than a routine.
The rule that keeps it safe
One motor, one stack at a time. Lesson 1 warned that two stacks must never drive the same motor, and a control panel is where students break that rule. Two hats may both mention motor A — as above — but only because a person cannot press up and down at the same moment. If two controls could ever be active together and both drive the same motor, the motor obeys whichever order arrived last, and the result changes run to run.
Limits are not optional
An operator holding the up button does not want to think about the top of the mast. So the control checks for them, using the encoder comparison from Lesson 13 and the and from Lesson 17:
when [up v] button [pressed v] :: events hat if <([A v] degrees counted) < (1000)> then [A v] run for (90) [degrees v] at (30) % speed :: motors else play beep (45) for (0.3) seconds :: sound end
That else matters more than it looks. A control that does nothing at all when refused feels broken, and an operator who thinks a control is broken starts pressing harder and looking for another way.
The Brick buttons
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.
Blocks reference
| 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. |
Press to begin
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.
when program starts
wait until is center button pressed?
A run clockwise for 1 rotations
the other way to do it
when center button pressed
A run clockwise for 1 rotations
The program has reached the wait block. It is not stuck — it is waiting, and nothing below it will run until the centre button goes down.
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.
A hat, or a wait?
- A hat gives the button its own separate stack, which can run at any time. Good for a control the user may press whenever they like.
- A wait puts the button in the middle of a sequence. Good for “press to begin”, where nothing should happen before it.
Why it matters
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.
Give every control its own stack, its own motor, and a limit it cannot be talked out of.
Separate stacksFrom Lesson 1 — why several hats run at once, and the one motor rule.Show meHide
Two things at once
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.
How it is done
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.
The rule: one owner per thing
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
when program starts
A start motor clockwise
stack 2 · status light
when program starts
forever
set status light to green
wait 0.5 seconds
set status light to red
wait 0.5 seconds
stack 3 · drive base
when program starts
start moving straight: 0
One stack, one jobAll three at once
Three stacks, each with its own hat block. All three start the moment the program starts — none of them waits for the others.
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.
Say this back before moving on: “One control, one stack, one motor.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The cab. Its five buttons are the whole control panel, and its screen is the instrument display. |
| Large Motor — the hoist | Raises and lowers the hook. Must hold position when it stops, or the load descends every time the operator lets go. |
| Large Motor — the slew | Turns the tower. Geared down heavily, because turning a loaded jib is the hardest thing this model does. |
| The jib and counterweight (not electronic) | The counterweight is what stops the crane tipping when the load is out at the end. Take it off and the model will show you why real cranes have one. |
Find the limits before you program them
- Wind the hoist all the way down by hand and reset the counter there. That is zero.
- Wind it up until the hook is close to the top — stop well before anything meets. Read the count. Your upper limit goes a little below that.
- Do the same for the slew: find how far the tower can turn each way before a cable goes tight, and note both numbers.
- Wind everything back to a known starting position. Every run begins from there, because the encoder is the only thing the crane knows about itself.
Ports — and the rule 4 min
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 |
|---|---|---|
| Hoist (Large) | A | Up and down live here, and its port appears in both stacks and both limits. |
| Slew (Large) | D | Left and right. Kept well away from A so a mis-typed port cannot make the hoist slew. |
| Sensors | none | The Brick’s buttons are the controls and the encoders are the limits. Adding a Touch Sensor as a real end-stop is what the challenges are for. |
Check your own build now:
- Hoist in A, slew in D.
- Route the hoist cable so the tower can turn its full range without winding it up. This is the model most likely to strangle itself.
- Set both mechanisms to their known start and reset the counters before every session.
- Nothing valuable under the hook. Limits are being tested today, which means they are also being found.
Connect the Brick 4 min
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.
How to connect the BrickUSB and Bluetooth, step by step, with a photograph of every screen. Open it if you have not done this before — or if pairing is not working.Show meHide
USB — the reliable one
- Switch the Brick on with the dark grey centre button.
- Cable into the Brick’s PC port — the small square socket beside the numbered ports, not one of the numbered ones.
- Other end into the computer.
Bluetooth — name it first
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.
- Name your Brick. On the Brick: Settings (the spanner) → Brick Name. Type something nobody else will pick, then press the tick. Every Brick is called
EV3until somebody changes it. - Turn Bluetooth on. Settings → Bluetooth. Tick Bluetooth and Visibility. Leave iPhone/iPad/iPod unticked.
- Connect from EV3 Classroom. Click the Brick icon at the top of the programming area, find your Brick by name, and click Connect.
- Say yes on the Brick. It asks “Connect?” with the computer’s name — choose the tick, then accept the passkey, which is already 1234.
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. The Brick is the cab, and you will be holding it and pressing its buttons while watching the hook. A cable decides where you have to stand.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Two Large Motor tiles, on A and D.
- Wind the hoist and check tile A; turn the tower and check D. If those are swapped, up will slew and left will lift.
- Check both counts read what you expect at your starting position.
Make it move 10 min
Five stacks: one setup and four controls. Each control owns one direction of one motor and checks its own limit.
when program starts :: events hat [A v] set motor to [hold position v] at stop :: motors [D v] set motor to [hold position v] at stop :: motors [A v] reset degrees counted :: motors [D v] reset degrees counted :: motors clear display :: display write [KREN SEDIA] at line (1) :: display when [up v] button [pressed v] :: events hat if <([A v] degrees counted) < (1000)> then [A v] run for (90) [degrees v] at (30) % speed :: motors else play beep (45) for (0.3) seconds :: sound end when [down v] button [pressed v] :: events hat if <([A v] degrees counted) > (30)> then [A v] run for (90) [degrees v] at (-30) % speed :: motors else play beep (45) for (0.3) seconds :: sound end when [left v] button [pressed v] :: events hat if <([D v] degrees counted) > (-400)> then [D v] run for (45) [degrees v] at (-25) % speed :: motors else play beep (45) for (0.3) seconds :: sound end when [right v] button [pressed v] :: events hat if <([D v] degrees counted) < (400)> then [D v] run for (45) [degrees v] at (25) % speed :: motors else play beep (45) for (0.3) seconds :: sound end
- The setup stack — both motors hold at stop, both counters reset, and a message. It runs once and finishes.
- Each control does a small bite — 90 degrees of hoist, 45 of slew. Small movements make a panel feel responsive and keep the limit checked often. A control that moved a whole rotation per press would sail past its limit.
- Every control has an else. At the limit you hear a low beep instead of movement, so a refusal is never confused with a dead button.
- Up and down share motor A, left and right share D — legal, because a person cannot press two Brick buttons at once.
What success looks like: pick the Brick up and fly the crane. Up and down raise and lower smoothly; left and right slew. Hold the up button and the hook climbs in steps and then, at the top, starts beeping instead — and nothing strains.
If a control runs the wrong way, change the sign of that stack’s speed, not the limit. And if the hoist creeps down when you let go, the stop setting is not hold position — go back to Lesson 2.
Change it and test 8 min
Test the panel the way an operator would: use it. Try to do a real job with it and notice what annoys you.
- Take the limit off the up control. Hold the button and watch the hoist run into its stop and strain. Stop it, and put the limit back — this is what the limit is for.
- Take away the else beeps. Now drive to a limit and hold the button: nothing happens, no sound, no message. Ask somebody else to use it and see whether they think it is broken.
- Change the hoist bite from 90 degrees to 360. Fewer, bigger movements. Does the crane feel better or worse to operate — and does it still stop at the limit or sail past it?
- Add a fifth control on the centre button that returns the hoist to a known height, using the go-to loop from Lesson 22. A “home” button, which every real machine has.
- Show the hoist height and slew angle on the screen, updating as you operate. You now have instruments as well as controls.
Step 2 is the interesting one and it is not really about code. The machine is behaving perfectly — it is protecting itself exactly as designed — and it feels broken. Most of what makes a machine pleasant to operate is telling the operator what it is doing and why it is refusing.
A refusal must be audible. A machine that silently ignores you is indistinguishable from one that has failed.