EV3 Robotics›Level 1 · Beginner›Lesson 39
Level 1 · Lesson 39 · EV3-L01-3960 minutes · Ages 9–16 · Model: Mechanical Clamp
The Mechanical Clamp: a gripper you hold in your hand. A motor drives the jaws, and two Touch Sensors sit where your fingers naturally fall — thumb on one to grab, finger on the other to release.
This is the last model of Level 1, and it is the first one that is a tool. Everything before it was a machine you switched on and watched. This one you pick up and use.
By the end of the lesson it will work in your hand — and you will have found a real limit in what Level 1 can do, which is exactly what Level 2 is for.
Powered grippers are how people handle things they cannot touch. A deep-sea robot picks samples off the seabed with one. A hot cell in a nuclear laboratory has a pair behind thick glass. A surgeon’s robot closes tiny jaws inside a patient through a hole the width of a pencil.
Grab and release are given separate controls, and that is a decision rather than an accident. One button that swapped between them would be smaller and cheaper — and much more dangerous, because the operator would have to remember which way it was going to go.
With two buttons there is nothing to remember. The one under your thumb always closes. The one under your finger always opens. Being tired or distracted cannot make you drop the sample.
Real grippers also know when to stop. They sense how hard they are squeezing, or they have a switch that trips when the jaws are fully open. Without that, a gripper that is already shut and told to shut harder will keep pulling until something gives — the motor, the gears, or the thing it is holding.
Hold on to that thought. Your clamp is about to have exactly this problem, and you are going to be the one who solves it.
A tool that a person holds has to be predictable in their hand, even when they are not thinking about it.
This model has no step-by-step manual. What we have is a video of the finished clamp, not instructions to follow. You will be working the build out from it, with your teacher, rather than turning pages.
Watch it twice. The first time, watch the jaws. The second time, watch where the two sensors are relative to a hand — a gripper whose buttons are in the wrong place is uncomfortable within a minute, and that is a build decision you get to make yourself.
Your clamp can be told to close and told to open. Nothing anywhere in it records which of those it did last.
You have built this shape of program before. Lesson 23 gave you event hats — several stacks, each waiting for its own thing — and lesson 22 taught that two identical sensors are told apart by nothing but the port. Put those together and the clamp almost writes itself: one hat for port 1 that closes, one hat for port 2 that opens.
It works. Then somebody presses grab twice.
Press grab on a clamp that is already shut and the motor tries to close jaws that have nowhere left to go. It cannot. It stalls — the same stall you met on the Push-up Robot in lesson 27 — and it sits there straining until the block finishes or something breaks.
| What a good gripper would do | What we can do about it in Level 1 |
|---|---|
| Remember whether it is open or shut | Nothing. Remembering needs a variable, and variables are Level 3. |
| Check before moving — if already shut, do not close | Nothing. Checking needs a Switch, and that is Level 2. |
| Stop when the jaws reach their end of travel | Build it in. Choose a movement small enough that it cannot damage anything, and let the person be the memory. |
That third row is the honest Level 1 answer, and it is a real engineering answer rather than a consolation prize. When the program cannot be made safe, make the machine safe. You have done this before — lesson 18 fixed the EV3 Fan in the build rather than the program.
A machine that cannot remember must be built so that forgetting does no harm.
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.
Everything an EV3 does begins with a motor turning. Before worrying about how far or how fast, there are only two things to say to a motor: start and stop. The blocks are the same whichever motor you use — only the port letter changes.
| Block | What it does |
|---|---|
[A v] start motor [clockwise v] :: motors | Starts the motor and immediately carries on to the next block. The motor keeps turning on its own. |
[A v] stop motor :: motors | Stops the motor. |
wait (2) seconds | Holds the program here, which is how you control how long a motor runs. |
Because start motor does not wait, a motor started on its own would run until the program ended. The pattern that gives a motor a length is three blocks:
when program starts :: events hat [A v] start motor [clockwise v] :: motors wait (2) seconds [A v] stop motor :: motors
Read it aloud: start it, leave it two seconds, stop it. Change the wait and you change how far the motor gets.
The highlight below follows the block the Brick is running, and the shaft turns only while the program is between start motor and stop motor. Notice that the count keeps climbing all the way through the wait — the wait does not pause the motor, it pauses the program.
0.00rotations so farnoshaft turning
The count does not pause when the program does. A wait holds up the blocks, and the motor carries on turning underneath it.
This is the whole idea behind start motor: it hands the motor its instruction and moves on, leaving the motor running behind it. Nothing stops the shaft until a block tells it to.
The direction dropdown says clockwise or counterclockwise — but clockwise seen from where? Always from the axle end: look straight at the shaft coming towards you, and clockwise is the way a clock’s hands go.
Here the Medium Motor faces you, so its output axle points straight out of the page. This is the view to picture when you are choosing a direction.
when program starts :: events hat [A v] start motor [clockwise v] :: motors wait (2) seconds [A v] stop motor :: motors
A Medium Motor normally lives in port A or D.
The Large Motor is shown from the side, which is the face its axle comes out of — so once again you are looking straight down the shaft.
when program starts :: events hat [B v] start motor [clockwise v] :: motors wait (2) seconds [B v] stop motor :: motors
A Large Motor normally lives in port B or C. Compare the two programs: they are the same three blocks, and only A has become B.
Medium · port ALarge · port BA fan, a conveyor belt or a spinning ride does not need to stop at an exact position — it just needs to run while something is happening. For those, timing the motor is simpler and perfectly good enough.
Waiting is how a program gives the physical world time to catch up. There are two kinds, and choosing between them is one of the first real design decisions in robotics.
| Block | What it does |
|---|---|
wait (1) seconds | Holds the program for a fixed length of time, whatever else is happening. |
wait until <> | Holds the program until a condition becomes true — usually a sensor reading. |
Most sensors bring their own ready-made wait block, already coloured to match the sensor and with its comparison built in. They are all the same idea — hold here until this is true — and they live in the sensor’s own palette rather than in Control.
| Sensor | Block | Waits until |
|---|---|---|
| Touch | [1 v] wait until [pressed v] :: sensors | the button is pressed. The dropdown also offers released and bumped. |
| Colour | [3 v] wait until color is [red v] :: sensors | the surface underneath is that one of the eight colours. |
| Ultrasonic | [4 v] wait until distance [< v] (15) [cm v] :: sensors | something is nearer than 15 cm. Flip the dropdown to > to wait for something to move away. |
| Gyro | [2 v] wait until angle [< v] (45) :: sensors | the robot has turned past that angle. |
| Brick buttons | wait until [center v] button is [pressed v] :: sensors | somebody presses that button on the Brick. No port — it is built in. |
Some readings have no wait block of their own — reflected light, ambient light, the timer, and a motor’s degrees counted. For those, drop the matching boolean into the plain wait until from Control. It does exactly the same job:
wait until <[3 v] is reflected light intensity [< v] (30) %? :: sensors> wait until <[3 v] is ambient light intensity [> v] (50) %? :: sensors> wait until <(timer) > (5)> wait until <([A v] degrees counted :: sensors) > (720)>
This is also the way to wait for two things at once, which no ready-made block can do — the sensor blocks each take one condition, but a boolean can be combined:
wait until <<[1 v] is pressed? :: sensors> or <(timer) > (5)>>
That one says “stop waiting when the button is pressed, or after five seconds, whichever comes first” — which is how you stop a wait hanging for ever when the thing you are waiting for never happens.
Two robots, the same job: drive up to the wall and stop. One waits two seconds; the other waits for the wall. Let it run several times — the interesting part is what happens on the second and third run.
wait for a length of time
wait for a condition
Each orange dash is where a previous timed run finished. The sensing robot has never left a second mark, because it has never stopped anywhere else.
The timed robot is not being careless. Two seconds is a perfectly good guess, and on the first run it may look exactly right. But a second covers a different distance on a fresh battery, on a dusty floor, or with a heavier load, so the robot finishes somewhere new every run — sometimes short, sometimes into the wall. The sensing robot has never had to guess.
Prefer waiting for a condition wherever a sensor can tell you. Keep timed waits for things with no sensor to check — letting a sound finish, or pausing so a person can watch.
A lift that waits three seconds for its doors is guessing; one that waits for the door sensor knows. The first eventually closes on somebody.
Say this back before moving on: “My clamp has no idea whether it is open or shut. I am its memory.”
Look at your clamp. Three things have cables, and two of them are identical to each other.
Which motor is it? There is no manual for this model, so nobody can tell you from a page. Hold yours against these two pictures and decide.
Touch ×2 — identical
Medium MotorLarge Motor| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program, and is the handle. Its weight is why a clamp like this gets tiring — think about that when you decide where to hold it. |
| One motor, port A | Opens and closes the jaws. Whichever motor you have, the program says A and runs the same. |
| Touch Sensor, port 1 | Under the thumb. Grab. |
| Touch Sensor, port 2 | Under a finger. Release. |
Work the jaws by hand, all the way each way. Find the point where they are fully shut and the point where they are fully open. Everything in section 9 depends on you knowing how far the jaws can actually travel before something stops them.
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 course’s usual table is Touch=1, Gyro=2, Colour=3, Ultrasonic=4. This model has two Touch Sensors, so the second one borrows the Gyro’s slot and sits in port 2. That is fine — there is no Gyro here — and it is the same deviation lessons 22 and 23 made, said out loud rather than done quietly.
| Part | Port | Why this one |
|---|---|---|
| Touch Sensor — grab | 1 | The usual Touch slot, and the one your thumb reaches. |
| Touch Sensor — release | 2 | The Gyro’s slot, borrowed. The two sensors are physically identical, so the port is the only thing that makes one of them “grab”. |
| The motor (the jaws) | A | One motor with a job of its own takes A. |
Swap these two cables and nothing will look wrong. No error, no warning — the clamp will simply open when you meant to grab. This is lesson 22’s point, and it is worth meeting twice.
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 suits this model best. A clamp is meant to be carried to the thing it is picking up, and a USB cable keeps it tethered to the desk. If you only have USB, download the program, unplug, and run it from the Brick’s own screen.
Two stacks, six blocks in total. Neither stack starts the program — each one waits for its own button, exactly as in lesson 23.
Use your own measured number in place of the 90s. Take the degrees you noted in section 8 and use a little less, so the jaws stop just short of their end stop.
[1 v] when [pressed v] :: events hat [A v] set speed to (30) % :: motors [A v] run [clockwise v] for (90) [degrees v] :: motors [2 v] when [pressed v] :: events hat [A v] set speed to (30) % :: motors [A v] run [counterclockwise v] for (90) [degrees v] :: motors
Walk it as the Brick sees it:
If your jaws close when you meant them to open, do not edit the program yet. First check you have the two cables the right way round; then, if they are correct, swap [clockwise v] and [counterclockwise v] — which way a motor turns the jaws depends on how it was built in, and with no manual, yours may differ from your neighbour’s.
What success looks like: holding the clamp comfortably in one hand, you can close it on a marker pen with your thumb and let go with a finger, without looking at the computer.
One change at a time, and predict before each run. The first one is the important one, so do it properly.
Step 6 is the end of Level 1. You need the program to ask a question — is it already closed? — and then do one thing or another depending on the answer. There is no block in everything you have learned that can ask a question.
That block exists. It is called Switch, it looks like if <> then … else …, and it is the first thing you meet in Level 2. Everything you have built so far does what it is told in the order it is told. From here on, your robots start making decisions.
Forty-eight models, and the last one ends by needing something you have not been given. That is not a gap. That is the door to Level 2.
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.
Pick something up, carry it across the table, and put it down again — without dropping it and without over-squeezing it. Choose the object yourself, and be ready to say why you chose it. Something hard and something soft will not need the same grip.
Make the clamp report itself. Each button must give a different sound and a different message on the Brick screen, so a person using it can tell what they just did without looking at the jaws. Then hand it to somebody who has not seen it and watch whether they can work it out.
Make the clamp safe to forget. Somebody who presses grab five times in a row must not damage anything. You cannot stop the motor being told to close, so you will have to change how far and how hard it closes each time. Report what you changed and what it costs you — because it does cost you something.
Design a gripper that somebody else can use without instructions. You have used your own clamp all lesson, so you know what it does. That is exactly what makes you the wrong person to judge it. Your job is to make it usable by a stranger. Plan on paper before you change anything. Decide where the buttons should sit for a hand that is not yours, what the clamp should do the moment it is switched on so its state is known, and how it tells its user what is happening. Then test it properly. Hand it to somebody from another group with no explanation at all, give them an object to pick up, and watch without helping. Write down every moment they hesitate. Two questions when you demonstrate it. What did your tester get wrong, and what did you change because of it? And your clamp still does not know whether it is open or shut — describe exactly what you would do about that if you had a block that could ask a question.
