EV3 Robotics›Level 3 · Advanced›Lesson 4
Level 3 · Lesson 4 · EV3-L03-0460 minutes · Ages 9–16 · Model: Link Robot
The Link Robot: an arm made of linked bars that fold and unfold, mounted on a base that turns. Its reach and its rotation are two separate motors, and they share the same air.
That sharing is the lesson. Extend the arm while the base is swinging and the linkage sweeps through space it does not own. Nothing in the program stops that happening — only the order of things does.
By the end of the lesson you will have two announcements in the same program that behave completely differently — one that waits and one that does not — and you will be able to say why each is the right one where it sits.
A linkage is how a machine turns one motor’s simple turning into a complicated path. A digger’s boom, a scissor lift, the arm of a desk lamp, the wipers on a bus, the pantograph on a train roof — all of them are bars pinned together so that a short push at one end draws a long, curved sweep at the other.
On an assembly line the arms work in a cell, and a cell has an ordering problem: the welder must not swing in while the loader is still reaching out. The two are physically capable of occupying the same cubic metre, and the only thing stopping them is the sequence.
Industrial cells solve this with interlocks and handshakes. A robot does not simply announce “I have started retracting” and let the next machine guess. It reports when it is done and clear, and the next move does not begin until that report arrives.
That is a different kind of message from an alarm. An alarm is shouted at everyone and the shouter carries on. A handshake is waited for. Both exist in the same plant, doing different jobs, and confusing them is how cells crash into themselves.
A machine that starts its next move on time rather than on completion works perfectly right up until something is slightly slow — a cold motor, a heavier part, a tight joint — and then two tonnes of steel arrive somewhere already occupied.
“It has begun” and “it has finished” are different messages. Machines that confuse them break themselves.
EV3 Classroom has two broadcast blocks and they look almost identical. The difference is one word, and it changes everything about what happens next.
| Block | What the sender does | Use it when |
|---|---|---|
broadcast [x] | Shouts and carries straight on to its next block, while the listeners run alongside. | The reaction is independent — a sound, a light, a log line. Nothing later depends on it having finished. |
broadcast [x] and wait | Shouts and stops until every listener has run to the end of its stack. | The next thing must not begin until this one is done — a stage of a sequence, a move that must complete. |
when program starts :: events hat broadcast [extend v] :: events broadcast [swing v] :: events
when program starts :: events hat broadcast [extend v] and wait :: events broadcast [swing v] and wait :: events
You could get the same effect with wait (3) seconds between the two, and Level 2 would have done exactly that. It works until the motor is slower one day — a low battery, a stiff joint, a heavier load — and then three seconds is not enough and the arms meet.
and wait waits for the actual finish, not for a length of time you hoped would cover it. This is the same argument as Level 2’s repeat untilversus a counted loop: let the machine tell you it is done.
and wait waits for all listeners. If three stacks answer to extend and one of them contains a forever loop, the sender waits for ever — the program freezes and nothing on screen explains why.
A broadcast lets one stack tell another to start. The sender does not need to know who is listening — it announces, and any stack waiting for that message runs.
| Block | What it does |
|---|---|
broadcast [message1 v] :: events | Sends the message and carries straight on. |
broadcast [message1 v] and wait :: events | Sends the message and holds until every stack that received it has finished. |
when I receive [message1 v] :: events hat | Starts this stack whenever that message is sent. |
Both send the same message to the same stack. The difference is what the sender does next — which is invisible in a listing, because the two blocks sit in exactly the same place. Use the switch to try each one.
the sensor stack
the motor stack
The sender never names the receiver — it announces, and whoever is listening runs. That is what lets the motors keep exactly one owner.
Plain broadcast is the right choice when the two jobs are genuinely independent: announce it and get on with your own work. broadcast and wait is the right choice when what comes next depends on the receiver having finished — do not start reversing until the stack that stops the motors has actually stopped them.
Broadcasting splits a program into parts that each do one job. A stack that watches the sensors can announce obstacle; the stack that owns the motors reacts. Neither needs to contain the other’s code, and the motors still have exactly one owner.
Here is a driving base doing exactly that. Three stacks are running: one sets the wheels going, one does nothing but read the Ultrasonic Sensor, and one owns every movement from then on. Follow the distance rather than the wheels — and notice what it is still doing while the message is crossing.
the driving stack — sets it going, then it is done
the watching stack — no motor block in it at all
the motor stack — owns every movement after the start
Watch the distance at the moment the message is sent. It keeps falling, because a broadcast starts another stack — it does not stop this one.
The watching stack contains no motor block anywhere, and the motor stack never reads the sensor. That is the whole trick: each stack is short enough to hold in your head, and the message is the only join between them. Splitting it this way also means the base can be made to dodge left instead of right by editing four blocks in one place, without going anywhere near the sensor.
Watch the gap in the middle of the run. broadcast does not mean stop — the wheels keep turning right through it, and the base creeps another 3 cm closer before the receiving stack gets as far as its stop moving block. If a robot must halt on the spot, that gap is why it will not.
Any number of stacks can listen to the same message, so one announcement can set several things going at once — stop the motors, sound an alarm and turn the light red. And nothing in the sending block says which of those will happen. Press one and find out.
Press a broadcast block. Nothing in it says what will happen — the stack that receives it decides.
Nothing has been sent yet. Press one of the three yellow blocks above.
Three messages, three receivers, one Brick. The blocks you press are identical apart from the name in the dropdown — so whatever happens next was decided entirely by the when I receive stack at the other end. Press all three quickly: nothing queues, because three separate stacks run at the same time. Press the same one twice while it is still going and its stack starts again from the top.
A message called message1 tells a reader nothing. One called obstacle-found explains the whole design at a glance. Names matter more here than almost anywhere else, because the sender and the receiver may be far apart on screen.
The Ultrasonic Sensor measures distance. It sends out a burst of sound too high for people to hear, listens for the echo, and works out how far away the surface is from how long the echo took — exactly how a bat finds a moth, and how a submarine uses sonar.
front
side| Block | What it does |
|---|---|
([4 v] distance in [cm v] :: sensors) | Reports how far away the nearest thing in front of the sensor is, as a number in centimetres. |
wait until <([4 v] distance in [cm v] :: sensors) < (15)> | Holds the program until something comes closer than 15 cm. |
This is the important step up from the Touch Sensor. Touch gives you true or false; the Ultrasonic gives you a number, and the deciding is left to you. Pick a threshold below and watch where the robot ends up.
The black line on the bar is the threshold; the blue fill is the reading. The robot stops the instant the fill crosses the line.
Three different robots, and only one number is different between them. That is what having a number rather than a yes-or-no buys you: the behaviour is tuned by editing one slot, not by rebuilding the program. It also means the sensor can never tell you it is “close” — close is a decision you make about a reading.
Car parking sensors, automatic doors at a shopping centre, and the sensor that stops a lift door closing on somebody all work this way. Reacting before contact is what makes a machine feel safe.
The Home/Retail EV3 set (31313) ships an Infrared Sensor and a Beacon in place of the Ultrasonic and Gyro sensors. The Infrared Sensor also measures distance, so the programs in this module work with it — but it reports a rough 0–100 proximity rather than real centimetres, and it is affected by sunlight and by dark surfaces in ways the Ultrasonic is not.
IR Sensor
BeaconAsk one question: must the next thing wait for this? If yes, use and wait. If no, do not.
A broadcast lets one stack tell another to start. The sender does not need to know who is listening — it announces, and any stack waiting for that message runs.
| Block | What it does |
|---|---|
broadcast [message1 v] :: events | Sends the message and carries straight on. |
broadcast [message1 v] and wait :: events | Sends the message and holds until every stack that received it has finished. |
when I receive [message1 v] :: events hat | Starts this stack whenever that message is sent. |
Both send the same message to the same stack. The difference is what the sender does next — which is invisible in a listing, because the two blocks sit in exactly the same place. Use the switch to try each one.
the sensor stack
the motor stack
The sender never names the receiver — it announces, and whoever is listening runs. That is what lets the motors keep exactly one owner.
Plain broadcast is the right choice when the two jobs are genuinely independent: announce it and get on with your own work. broadcast and wait is the right choice when what comes next depends on the receiver having finished — do not start reversing until the stack that stops the motors has actually stopped them.
Broadcasting splits a program into parts that each do one job. A stack that watches the sensors can announce obstacle; the stack that owns the motors reacts. Neither needs to contain the other’s code, and the motors still have exactly one owner.
Here is a driving base doing exactly that. Three stacks are running: one sets the wheels going, one does nothing but read the Ultrasonic Sensor, and one owns every movement from then on. Follow the distance rather than the wheels — and notice what it is still doing while the message is crossing.
the driving stack — sets it going, then it is done
the watching stack — no motor block in it at all
the motor stack — owns every movement after the start
Watch the distance at the moment the message is sent. It keeps falling, because a broadcast starts another stack — it does not stop this one.
The watching stack contains no motor block anywhere, and the motor stack never reads the sensor. That is the whole trick: each stack is short enough to hold in your head, and the message is the only join between them. Splitting it this way also means the base can be made to dodge left instead of right by editing four blocks in one place, without going anywhere near the sensor.
Watch the gap in the middle of the run. broadcast does not mean stop — the wheels keep turning right through it, and the base creeps another 3 cm closer before the receiving stack gets as far as its stop moving block. If a robot must halt on the spot, that gap is why it will not.
Any number of stacks can listen to the same message, so one announcement can set several things going at once — stop the motors, sound an alarm and turn the light red. And nothing in the sending block says which of those will happen. Press one and find out.
Press a broadcast block. Nothing in it says what will happen — the stack that receives it decides.
Nothing has been sent yet. Press one of the three yellow blocks above.
Three messages, three receivers, one Brick. The blocks you press are identical apart from the name in the dropdown — so whatever happens next was decided entirely by the when I receive stack at the other end. Press all three quickly: nothing queues, because three separate stacks run at the same time. Press the same one twice while it is still going and its stack starts again from the top.
A message called message1 tells a reader nothing. One called obstacle-found explains the whole design at a glance. Names matter more here than almost anywhere else, because the sender and the receiver may be far apart on screen.
Say this back before moving on: “Shout and carry on, or shout and wait — which does the next move need?”
Work the linkage by hand through its whole range before you read on. Watch where the far end goes — that curved path is what the ordering problem is about.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The base and the ballast. A tall linkage on a light base tips over when the arm is out — the Brick is what stops that. |
| Large Motor — the linkage | Folds and unfolds the bars. Large because a linkage near full extension has terrible leverage and needs torque exactly when it has least. |
| Large Motor — the base | Swings the whole arm round. This is the motor that can put the arm somewhere it should not be. |
| Ultrasonic Sensor — on the arm | Looks along the reach. It tells you whether there is something in front of the arm before the arm goes there. |
| The bars and pins (not electronic) | Every pin adds slack. Fold and unfold three times and watch whether the tip returns to the same place — that slack is why the arm needs end stops rather than counted degrees. |
Find the collision by hand, now. Extend the arm halfway and swing the base slowly. Is there a position where the linkage hits the body? Note it. That is the thing your ordering has to avoid, and it is much better to discover it with your hands than at 60% speed.
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 |
|---|---|---|
| Linkage (Large) | A | The reach. First motor port, as always for the main actuator. |
| Base rotation (Large) | B | The swing. Keeping reach on A and swing on B means the two broadcasts read consistently. |
| Reach check (Ultrasonic) | 4 | Ultrasonic stays on 4 across the course. |
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.
Watch the cable if you use USB. The base swings through a wide arc, and a USB lead across that arc becomes one more thing for the linkage to catch on. Bluetooth is tidier here even though the model does not travel.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Build the wrong one first, on purpose. You need to see the collision to understand why the fix is a fix.
when program starts :: events hat broadcast [extend v] :: events broadcast [swing v] :: events when I receive [extend v] :: events hat [A v] run [clockwise v] for (180) [degrees v] at (30) % speed :: motors when I receive [swing v] :: events hat [B v] run [clockwise v] for (90) [degrees v] at (30) % speed :: motors
Keep the speeds at 30% for this one. You are deliberately running a program that makes the model do something it should not, and a slow collision is a demonstration while a fast one is a repair job.
when program starts :: events hat broadcast [extend v] and wait :: events broadcast [swing v] and wait :: events broadcast [retract v] and wait :: events play sound [Communication / Goodbye v] until done :: sound when I receive [extend v] :: events hat [A v] run [clockwise v] for (180) [degrees v] at (30) % speed :: motors when I receive [swing v] :: events hat [B v] run [clockwise v] for (90) [degrees v] at (30) % speed :: motors when I receive [retract v] :: events hat [A v] run [counterclockwise v] for (180) [degrees v] at (30) % speed :: motors
when program starts :: events hat broadcast [status lamp v] :: events broadcast [extend v] and wait :: events broadcast [swing v] and wait :: events broadcast [retract v] and wait :: events when I receive [status lamp v] :: events hat forever set status light to [orange v] :: display wait (0.4) seconds :: control set status light to [green v] :: display wait (0.4) seconds :: control end
and wait here would freeze the program on line 2.What success looks like: the lamp starts blinking, then the arm extends fully, then the base swings, then the arm retracts, then it says goodbye — with the lamp blinking throughout.
If the program does nothing at all after the lamp starts, you used and wait on the lamp. It contains a forever, so it never finishes, so the sender waits for ever. This is the classic bug and it looks like a crash.
One change at a time. Predict, then run, then look.
and wait off the swing only. Predict which two moves now overlap. Then run it and watch.and wait with wait (2) seconds. It works. Now drop the motor speed to 10% and run it again — the timing guess is exposed, and this is exactly how the bug reaches a real machine.extend that plays a sound lasting four seconds. The sender now waits for the sound too, because and wait waits for all listeners. Time it.and wait on the lamp and watch the program hang on line 2. Then undo it. Seeing the freeze once is worth more than being warned about it.wait until distance > 15 at the top of the swing listener, then hold your hand in the arm’s path. The sequence pauses until the way is clear — and the sender waits with it, because that is what and wait means.A stage waits. A background job does not. Getting that backwards either freezes the program or breaks the model.
Four lessons in, you can name routines, give those names inputs, name moments, and order them. Everything so far has been about organising a program you already knew how to write.
The next lesson changes subject. Every movement you have written has been open-loop: run 180 degrees, and hope 180 degrees was right. The arm you just built proves the limit — all those pins have slack, so “180 degrees at the motor” is not the same place twice.
A closed loop measures where it actually is, compares that with where it should be, and corrects — over and over, while it moves. That is the next lesson, and it is the biggest idea in Level 3.
You have finished learning how to say things clearly. Now you start learning how to be right.
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.
Add a fourth stage. After the arm retracts, make the base swing back to where it started, so the robot ends exactly as it began. Use another broadcast and wait. Check it really does return to the start — run it three times without touching the model and see whether it drifts.
Add a background job that must not be waited for. Write a stack that beeps softly every two seconds, for ever, and start it with a plain broadcast at the top of the program. Then try changing that one to broadcast and wait. Predict what happens before you run it. Undo it once you have seen it.
Make the sequence refuse to run into something. Put a guard at the top of the swing listener: it must not begin until the Ultrasonic Sensor reads more than 15 cm. Hold your hand in the arm's path when the sequence reaches that stage. The whole sequence should pause — not just the swing — and continue when you move away. Explain to a partner why the sender waits too.
Programme a full pick-and-place cycle from one button press. The robot must: extend to the pick position, close on the object, retract, swing to the drop position, extend, release, retract, and swing home. Eight stages, and no two may overlap. Two rules: 1. Every stage is its own listener with its own name, and the main program is nothing but a list of announcements. Someone must be able to read the main stack and know the whole cycle. 2. A status lamp must blink for the entire cycle and stop when it finishes — which means exactly one of your announcements is NOT an "and wait", and you must be able to say which and why. Work out the order on paper before you build. Then test it with the arm deliberately slowed to 15% speed: a correct sequence does not care how slow the motors are.
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.
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.
