EV3 Robotics›Level 1 · Beginner›Lesson 23
Level 1 · Lesson 23 · EV3-L01-2360 minutes · Ages 9–16 · Model: Big Mouth Monster
The Big Mouth Monster: a pair of jaws on a frame that open wide and snap shut, driven by a single motor.
It is a silly machine and a serious one at the same time. Silly, because it is a monster made of grey beams with red teeth. Serious, because it is the first model in this course that you would not want to put your finger into at the wrong moment.
The Timber Saw solved that with a switch you could reach from a safe distance. This one solves it a different way: the machine will tell you, from across the room, whether it is about to bite — using a part of the Brick you have not touched yet.
A crocodile’s jaw is the most famous pair of jaws on the planet. Malaysia has its own — the saltwater crocodile lives in the rivers and mangroves of Sabah and Sarawak, and it is not a small animal.
A jaw is a lever, like the barrier arm in Lesson 15 — but hinged the other way round. The muscle pulls close to the hinge and the teeth are far from it, which trades distance for force: the muscle moves a little, the jaw tip moves a lot.
That is why a crocodile’s bite is famously strong and its opening is famously weak. All the muscle is on the closing side. A person can hold a crocodile’s mouth shut with two hands, which is a true fact and a terrible idea.
Here is the problem your model has. Between snaps, the jaws sit open and completely still. A machine that is waiting to move looks exactly like a machine that has finished moving.
You cannot tell them apart by looking, and the difference is the entire question of whether it is safe to reach in. Every dangerous machine in the world has solved this the same way: a light.
Still is not the same as finished. A machine that is armed and waiting has to say so.
The ring of light around the Brick’s buttons is an output, just like the screen and the speaker. One block controls it.
set status light to [green v] :: display
The dropdown holds six choices, and they are three colours twice:
| Choice | What people already read it as |
|---|---|
| green / green pulse | Fine. Safe. Ready. |
| orange / orange pulse | Busy, working, or about to do something. |
| red / red pulse | Stop. Danger. Something is wrong. |
The pulse versions flash slowly instead of staying lit. Use a pulse when the machine is in the middle of something and a steady colour when it has settled — a flashing light says “happening now” in a way a steady one does not.
You do not get to invent what the colours mean. Every traffic light, every kettle and every charger in the world has already taught your audience, and a robot that lights up green while it is about to snap is not being clever — it is lying.
the ring around the buttons is the status light
The light is the only output here you can read without looking at the screen — which is why it is worth setting deliberately at every stage of a program.
The screen needs to be read. The light only needs to be seen. That is why it is the right output for a warning.
The ring of light around the Brick’s buttons can be set to green, orange or red. It is the fastest possible way for a robot to say what it is doing — no reading required, visible from across the room.
| Block | What it does |
|---|---|
set status light to [green v] :: display | Sets the ring to a chosen colour and carries straight on. |
set status light to [red v] :: display | The same block with a different colour picked from the dropdown. |
set status light to [orange pulse v] :: display | The three colours each have a pulse version, which flashes on and off until something changes it. A pulse reads as “busy”; a steady colour reads as “settled”. |
The light is most useful when each colour means one thing, consistently, for the whole program. Watch a short program set it three times as it goes.
the ring around the buttons is the status light
The light is the only output here you can read without looking at the screen — which is why it is worth setting deliberately at every stage of a program.
Nothing in that program is about the light — it starts, waits for a button, turns a motor and stops. The light is simply told the truth at each stage, and the result is a robot whose state you can read without touching it. A common scheme:
Machines everywhere signal with colour — traffic lights, a kettle’s power light, the charging light on a laptop. It also makes debugging far easier: set the light at each stage of a program and you can see how far it got without adding a single screen message.
The Medium Motor is the smaller of the two EV3 motors. It is quick and light rather than strong, which makes it the right choice for anything that has to move a part of the robot rather than the whole robot — a gate arm, a pair of jaws, a winch, a pointer.
side
from above| Block | What it does |
|---|---|
[A v] run [clockwise v] for (1) [rotations v] :: motors | Turns the motor a measured amount, then stops. One rotation is one full turn of the motor shaft. |
[A v] run [clockwise v] for (90) [degrees v] :: motors | The same idea, but in degrees — useful when a quarter or a half turn is what the mechanism needs. 360 degrees is one rotation. |
[A v] run [clockwise v] for (2) [seconds v] :: motors | Turns the motor for a length of time and then stops, whatever the shaft managed to do in it. The one measurement that always finishes. |
[A v] set speed to (50) % :: motors | Sets how fast the motor will run from now on. It does not start the motor by itself. |
[A v] start motor [clockwise v] :: motors | Starts the motor turning and moves straight on to the next block. It keeps going until something stops it. |
[A v] stop motor :: motors | Stops the motor. |
These two look similar and behave completely differently, and almost every early EV3 bug comes from picking the wrong one. Watch both run the same job, over and over.
versus
Let it loop a few times. The left dial keeps landing on the same mark; the right one leaves a new mark almost every run — that scatter is what “not repeatable” means.
The black mark is where the shaft should finish. The measured motor hits it every single run, because the program waits at that block until the motor has turned exactly that far. The timed motor is only running for a second — and a second covers a different amount depending on the battery, the friction and whatever the mechanism is carrying. Each orange dash is a run that finished somewhere it was not asked to.
If a mechanism has to end up in a particular place — a gate that must finish upright, a jaw that must close fully — use the measured block.
The dropdown at the end of the run block has a third setting, and it is the one that saves lifting mechanisms. for () seconds switches the block off a distance and onto a duration: it drives the motor for that long and then stops, whatever the shaft managed to do in the time.
That sounds strictly worse than a measured turn, and for most jobs it is. It matters because of what the measured block actually waits for. run for (90) degrees does not finish when 90 degrees’ worth of time has passed. It finishes when the shaft has turned 90 degrees — and if the mechanism runs out of travel first, the shaft never will.
Every arm, jaw and lift has a physical limit: a point where the mechanism reaches the top of its travel, or something in the build gets in the way. Push a motor into that limit and it stalls — the shaft stops turning and the motor sits there straining. The motor is fine and the program is spelled correctly. But the encoder has stopped counting, so a measured block that was told a bigger number is still waiting, and it will wait until the Brick is switched off.
Nothing after that block ever runs. Not the next motor block, not the sound, not the display, not the rest of the program. That is the whole failure, and it looks like a crash even though nothing has crashed.
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [clockwise v] for (90) [degrees v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
Watch the Brick screen, not the arm. HOME SET is the block after the motor block, so a blank screen means the program never got past it.
Compare the first two. The only difference between them is 45 and 90, the mechanism is identical, and one of them is a working program while the other locks up on the third block. Nothing in the listing distinguishes them — the end stop is a fact about the build, and the program has never heard of it.
This is the mistake almost every student makes the first time a Medium Motor lifts something. A lifting arm has a lowest position and a highest one; ask it to turn past either and the program hangs. It is worse than an ordinary bug, because the robot looks alive — the motor is still being driven, still buzzing, still hot — and the next block never comes.
The fix turns the problem into the technique. You often do not know how many degrees it is to the top of an arm’s travel — it depends on the build, and it changes the moment somebody rebuilds it. So do not measure it. Drive the arm gently into its own end stop for a couple of seconds, and then declare that position to be zero:
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [counterclockwise v] for (2) [seconds v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
Three things make that work, and all three are deliberate:
After that, use measured blocks for everything inside the travel and timed blocks whenever you are driving to a limit. The rule of thumb: if the movement ends against something solid, run for seconds.
A Medium Motor is normally plugged into port A or D, which leaves B and C free for the Large Motors that drive wheels. The letter in the block must match the port the cable is actually in — this is the single most common reason a program appears to do nothing at all.
Say this back before moving on: “The light does not wait. It changes colour and the program carries straight on.”
Two electronic parts — and today one of them is doing three jobs at once.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program, and is the model’s head — the status light is on the Brick, so wherever the Brick faces is where the warning can be seen from. |
| Medium Motor | Works the jaw. The flat slab one, with the small red boss on the end face. Fast and light, which is what a snap needs. |
Brick off. You need two numbers before you can program anything.
Step 4 catches half the class. If you get it backwards, your monster will try to open past its stop instead of biting, and it will sound like it is breaking — because it is.
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 |
|---|---|---|
| Medium Motor (works the jaw) | A | A single working motor takes A, and every program on this page says A. |
| The status light | none | Built into the Brick, like the screen and the speaker. Three outputs, no cables between them. |
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.
One thing to know about the light before you start. When a program is running, the Brick lights the ring green all by itself. So a green ring at the start does not mean your program said green — it means the program is running. Your first block will take it over.
Use a number a little smaller than the one you measured. Stopping just short of the limit costs you nothing and saves the gears.
Seven blocks: safe, then a warning, then the bite, then safe again. Swap the two directions if you decided counterclockwise closes.
when program starts :: events hat set status light to [green v] :: display wait (2) seconds set status light to [red v] :: display [A v] run [clockwise v] for (60) [degrees v] :: motors [A v] run [counterclockwise v] for (60) [degrees v] :: motors set status light to [green v] :: display
Walk it in the order the Brick runs it:
What success looks like: a green ring, a pause long enough to notice, the ring turning red, a clean snap and re-open, and green again. Stand back three metres and watch. Can you still tell what state it is in? That is the test.
If the jaw grinds at the closed end, 60 degrees is more than your bite. Take it down in steps of 10 until the teeth meet without straining.
One change at a time, and predict before each run. For each one, ask the real question: would a person standing nearby be correctly warned?
Steps 3 and 4 are the lesson, and they are the two ways every warning light in the world fails: one that never goes off, and one that comes on too late. Both are worse than no light at all, because both teach the person watching to ignore it.
A signal is a promise. If it is ever wrong, it stops being a signal and becomes decoration.
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.
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 third colour. Your monster must show orange while it is getting ready — after the green waiting period but before the jaw moves — so a person sees a clear green, then orange, then red before anything happens. Each colour must be on long enough to notice.
Make the monster bite five times in a row, with the light correct on every single bite. Green between bites, red during each one, and green again at the very end. The trap is the last one: after the fifth bite the light must not be left red.
Give it a fake-out. The monster should sometimes go red and then not bite, so a person cannot rely on the timing alone — but every real bite must still be preceded by red. Then answer in one sentence: does a warning that sometimes means nothing still count as a warning?
Build a machine a stranger could stand next to safely. Your monster must run unattended for at least a minute, biting when it chooses, and at every single moment its status light must correctly say whether it is safe to reach in. Somebody who has never seen your model must be able to work out the rule by watching for thirty seconds, without being told anything. Plan on paper before you build. Write down every state your machine can be in, and beside each one the colour it will show. That list is your design; the blocks are just typing it in. Two questions when you demonstrate it. Point to a moment where your light could be wrong — and if you believe there is none, say what makes you sure. And why is a warning light that is sometimes late worse than having no light at all?