Challenge 1
Add a second sweep speed. Call "sweep" a third time in your program with a number you have not used yet — something very slow, like 8. Watch the lure. A real anglerfish varies its motion because prey judges by movement alone.
What you are building 3 min
The Anglerfish: a deep-sea ambush predator with a hinged jaw, and a lure on a stalk that arches out over its own mouth.
A Medium Motor waves the lure. A Large Motor works the jaw. A Gyro Sensor tells the fish whether it is being moved. Almost nothing about this model is fast — it is a machine built around waiting, and the waiting is the point.
By the end of the lesson you will have one block called sweep that can wave the lure gently, wildly, or anywhere in between — without a second copy of it existing anywhere in your program.
In the real world 5 min
Where you have seen it
Two hundred metres down, sunlight has run out. Below a thousand metres there is none at all. Food in that water is scarce and unpredictable — most of it drifts down from far above — and an animal that swam about looking for a meal would spend more energy hunting than the meal would return.
So the anglerfish does the opposite of hunting. It hangs almost still and dangles a light in front of its own mouth. The rod is a modified fin spine called the illicium; the glowing tip is the esca, and it does not make its own light — it is packed with bioluminescent bacteria that live there and are fed by the fish.
Why it is built that way
The lure is not waved at one speed. A slow, drifting wave looks like a small swimming animal. A short twitch looks like something injured. The fish varies the motion because the same movement at a different size means a different thing to whatever is watching — and it is watching in the dark, judging by almost nothing.
The economics are brutal. A deep-sea anglerfish may eat a handful of times a year. Every wave of that lure costs energy it cannot easily replace, so the motion has to be worth making.
What would go wrong without it
A lure that only ever moved one way would attract only one kind of prey — and only until that prey learned. A fish that could vary its motion from lazy to frantic without growing a second rod has one piece of equipment doing many jobs.
One piece of equipment, many sizes of movement. That is exactly what you are about to build in blocks.
The main concept — a block that takes a number 6 min
Last lesson you named a routine. This lesson the name gets a slot in it — a number you fill in each time you use the block. It is called an input, and it is the difference between a block that does one thing and a block that does one kind of thing.
The problem, seen honestly
Suppose the lure must sweep gently at first and wildly when something is close. Without inputs you need two blocks:
define sweep slow repeat (4) [A v] run [clockwise v] for (40) [degrees v] at (15) % speed :: motors [A v] run [counterclockwise v] for (40) [degrees v] at (15) % speed :: motors end define sweep fast repeat (4) [A v] run [clockwise v] for (40) [degrees v] at (60) % speed :: motors [A v] run [counterclockwise v] for (40) [degrees v] at (60) % speed :: motors end
This is Lesson 1’s problem wearing a name badge. Giving a routine a name stopped the copies appearing in the main program. It did not stop the copies — it just moved them.
The fix: one block, one slot
define sweep (speed) repeat (4) [A v] run [clockwise v] for (40) [degrees v] at (speed) % speed :: motors [A v] run [counterclockwise v] for (40) [degrees v] at (speed) % speed :: motors end
speed is the input — a value the caller supplies, used wherever it appears inside.when program starts :: events hat sweep (15) :: custom sweep (60) :: custom sweep (15) :: custom
| Word | What it means | Where you see it |
|---|---|---|
| Input | The empty slot in the block’s name. | In the define hat: sweep (speed) |
| Argument | The actual number you put in when you use it. | In the program: sweep (60) |
| Inside the block | The input behaves like a number. Drag it from the define hat into any slot. | at (speed) % speed |
Making one, in EV3 Classroom
- My Blocks → Make a Block.
- Type the name, then click Add an input — number.
- Name the input for what it means, not what type it is:
speed,times,degrees. Nevernumber1. - Click OK.
- To use it inside the definition, drag the input out of the
definehat and drop it into a slot. You cannot type its name — you have to drag the real thing.
My Blocks
A My Block is a block you make yourself. You take a group of blocks that do one job, give the group a name, and from then on that name is the block.
Blocks reference
| Block | What it does |
|---|---|
define grab | The head of a definition. Whatever is attached under it is what the block does. There is exactly one of these per My Block. |
grab :: myblocks | Runs the definition. Use it as many times as you like. |
define turn (degrees) | A definition with an input. degrees is a name for whatever number the caller types. |
turn (90) :: myblocks | Runs it with 90 in place of that name. |
Why bother
Copying blocks works perfectly — right up until the copied thing has to change. Here are two robots driving a square, one with a My Block and one with the blocks copied four times, and then somebody asks for a bigger square.
a My Block, used four times
define side
move forward for 2 rotations
move right: 100 for 0.5 rotations
repeat 4
side
the same thing copied
move forward for 2 rotations
move right: 100 for 0.5 rotations
move forward for 2 rotations
move right: 100 for 0.5 rotations
move forward for 2 rotations
move right: 100 for 0.5 rotations
move forward for 2 rotations
move right: 100 for 0.5 rotations
↑ the fourth copy still says 2
1place to edit · My Block4places to edit · copies
My Block: square closedCopies: one rotation adrift
Both robots drive a square: forward, turn, four times. The left uses a My Block called «side»; the right has the same two blocks copied four times.
The bug is not in any block. It is in the fact that the same idea was written down four times, and only three of them were updated.
The right-hand robot is not running a broken program. It is running four programs that were supposed to be identical, and three of them were updated. Nothing is misspelled, nothing reports an error, and the only evidence is a square that does not close.
The left-hand program is these two listings, and nothing else:
define side move [forward v] for (3) [rotations v] :: movement move [right: 100 v] for (0.5) [rotations v] :: movement
when program starts :: events hat repeat (4) side :: myblocks end
- One place to fix. A turn defined once and used eleven times is corrected in one place. Copied eleven times, it is corrected in eleven — and one always gets missed.
- Readable. A program that reads turn-right, drive-to-wall, grab explains itself. The same program written out in full does not.
Inputs make it general
A My Block can take a value. Turn-right is useful; turn (degrees) is far more useful, because one definition then serves every turn in the program. The value is given a name when the block is made, and that name is used inside the definition wherever the number belongs.
The name is the part that trips people up. Inside the definition, (cm) is not a variable you have to set anywhere — it is a hole, and it is filled in with whatever the caller typed, every time the block is called.
Example 1 — a block that thinks in centimetres
EV3 movement blocks count wheel turns, and nobody measures a table in wheel turns. One turn of a standard driving wheel carries the robot about 17.5 cm, so driving 50 cm means asking for 50 ÷ 17.5 rotations. Doing that sum in your head, at every movement block, all program long, is how mistakes get in.
Put the sum inside a My Block once and the whole program can be written in centimetres. Change the two numbers below and watch where they end up.
cm
These two numbers are the whole interface. Everything below is what the definition does with them.
what you write in the program
drive (50) cm at (75) % :: myblocks
the definition — (cm) and (speed) are names, not values
define drive (cm) cm at (speed) % set movement speed to (speed) % :: movement move [forward v] for ((cm) / (17.5)) [rotations v] :: movement
the same blocks, with your two numbers put in
set movement speed to (75) % :: movement move [forward v] for ((50) / (17.5)) [rotations v] :: movement
The green division block is doing the only real work: the movement block underneath counts wheel turns, and you asked in centimetres. One turn of these wheels carries the robot 17.5 cm, so 50 cm is 50 ÷ 17.5 = 2.86 turns.
2.86rotations · what the block gets2whole turns15.0cm · the part turn75%speed
Set the distance to 17.5, 35 or 70 and the part turn disappears — those are whole numbers of wheel turns. Every other distance leaves a fraction, which is exactly why the division belongs inside the My Block and not in your head.
Two inputs, and the definition is three blocks. Note what has actually been gained: not fewer blocks — the same blocks run either way — but a program you can check against a ruler. drive (50) cm at (75) % is either right or wrong about the table, and you can tell which without running it.
Typing a fixed number inside the definition instead of using the input is the classic slip — the block then ignores whatever it is given and always drives the same distance:
define drive (cm) cm at (speed) % set movement speed to (speed) % :: movement move [forward v] for ((50) / (17.5)) [rotations v] :: movement
That block takes a distance and throws it away. It will pass every test you run at 50 cm.
Build a script and run it
Here are those two My Blocks and a 100 × 100 cm mat. Drag blocks into the script, set the numbers, and press Run — the base always starts in the left-hand corner facing up the mat. Say where you think it will finish before you press it; the ruler is there to settle the argument.
Two My Blocks, a 100 × 100 cm mat and a ruler. Drag blocks into the script — or press one to add it — set the numbers, then Run and see whether the base ends up where you said it would.
my blocks — drag or press
the script — 0 / 8 blocks
when program starts
Empty. Drag a block in from above, or press one.
10, 10cm · where it is0°heading0.0sthe whole run
Nothing to run yet. A square is four drives and four turns — try predicting the distance before you press Run.
Eight blocks is enough for a square with 40 cm sides, and not enough for anything you cannot picture. If a shape needs more than that, it wants a repeat (4) around it — which is the next thing a My Block usually grows into.
Example 2 — a block that thinks in degrees
The Gyro Sensor gives an accurate turn, and it costs five blocks every time: reset the angle, start turning, wait until the reading is a few degrees short of the target, stop. Those five blocks are about the sensor. What the program wants to say is turn 90.
define turn (degrees) [2 v] reset angle :: sensors start moving [right: 30 v] :: movement wait until <([2 v] angle :: sensors) > ((degrees) - (4))> stop moving :: movement
The − 4 is the overshoot allowance from the Gyro Sensor module: the robot carries on turning for a moment after the motors are told to stop, so the block asks for less than it wants and lets it coast in. Written here, it is decided once. Written out at every corner, it is eleven chances to forget it.
Now the input earns its keep — because the shape a robot draws is decided entirely by that one number. A closed shape turns through 360° in total, so a shape with n corners turns 360 ÷ n at each one.
the whole program
when program starts :: events hat repeat (4) move [forward v] for (2) [rotations v] :: movement turn (90) :: myblocks end
what turn is, once
define turn (degrees) [2 v] reset angle :: sensors start moving [right: 30] :: movement wait until <([2 v] angle :: sensors) > ((degrees) - (4))> stop moving :: movement
90°the input0 / 4corners turned360°turned in total
1 block in the program5 gyro blocks, written once
A square has 4 corners, so each turn is 360 ÷ 4 = 90°. That number is the only thing being changed.
Nothing in the program mentions the gyro. It is all inside turn, which is the point: the sensor is an implementation detail of turning, and the program should be about the shape.
Same definition, same drive block, same length of side. The only edit between a triangle and a pentagon is turn (120) :: myblocks becoming turn (72) :: myblocks. That is what a well-chosen input does: it turns a program that draws one shape into a program that draws shapes.
The same block also turns left, if you let it. Give the definition an if … then … else and a negative input means anticlockwise:
define turn (degrees) [2 v] reset angle :: sensors if <(degrees) > (0)> then start moving [right: 30 v] :: movement wait until <([2 v] angle :: sensors) > ((degrees) - (4))> else start moving [left: 30 v] :: movement wait until <([2 v] angle :: sensors) < ((degrees) + (4))> end stop moving :: movement
One block, two directions, and every program that uses it gets the left turn for free the moment this definition is edited.
When to make one
The signal is repetition: the same sequence appearing in more than one place. That is the moment to name it. Making a My Block for something used once adds a layer without adding clarity.
The second signal is a unit. If the blocks convert between what you think in (centimetres, degrees, seconds) and what the hardware counts (rotations, sensor readings), that conversion is worth a name — it is the thing you will otherwise get wrong.
The Gyro Sensor
The Gyro Sensor measures how far the robot has turned, in degrees. Wheels slip and floors vary, so counting wheel rotations is a poor way to turn accurately — the gyro measures the turn itself rather than inferring it.
from above
frontBlocks reference
| Block | What it does |
|---|---|
([2 v] angle :: sensors) | Reports how far the robot has turned since the angle was last reset. |
[2 v] reset angle :: sensors | Sets the current heading as zero. |
Always reset before you turn
The angle is measured from wherever it was last zeroed — not from where this turn started. Here are two robots given the same instruction, one with a reset block and one without.
reset first
when program starts
2 reset angle
start moving right: 100
2 wait until angle > 90
stop moving
no reset
start moving right: 100
2 wait until angle > 90
0°actually turned · reset0°actually turned · no reset
Reset: a real 90° turnNo reset: 0°, and no warning
Both robots have been sitting still. Both gyros already read about 34° — left over from an earlier turn — and the reading is creeping upward even now. That creep is drift.
Both programs are correct about what they asked for. Only the left one asked the question from a known starting point.
Both programs did exactly what they said. Both gyros stopped at 90. But the robot on the right had 34 degrees already on the clock, so it only turned 55 — and nothing about the program looks wrong. Watch the first step too: neither robot is moving and the reading is still climbing. That is drift, and it is why the reset belongs immediately before the turn.
Reset with the robot completely still, as late as you can.
when program starts :: events hat [2 v] reset angle :: sensors start moving [straight: 0] :: movement wait until <([2 v] angle :: sensors) > (90)> stop moving :: movement
That program is the obvious one to write, and it will not give you a 90 degree turn. The next section is why.
Stop before you get there
Asking to stop at 90 does not stop the robot at 90. Between the gyro reaching 90 and the wheels actually standing still there is a delay — the sensor has to be read, the next block has to run, and the motors have to physically brake. The robot is still turning through all of it, so it ends up past where you asked.
The fix is to ask for less than you want. Aim for a 90 degree turn by waiting for 86: the robot coasts the last few degrees on its own and settles at roughly 89 to 91.
ask for exactly 90
2 reset angle
start moving right: 30
2 wait until angle > 90
stop moving
stop 4° early
2 wait until angle > 86
stop moving
slowthis run · 50°/s+4°carried past the stop86tolerance needed here
Asked for 90: ended at 0°Asked for 86: ended at 0°
Both robots are told to turn 90°. The left one waits for the angle to pass 90; the right one gives up 4° early and waits for 86.
The tolerance has to match the speed. At 50°/s the number that lands this turn on 90° is 86 — let it loop, and watch that number change when the speed does.
The size of that gap is not a fixed property of the robot — it is the delay multiplied by how fast you are turning. The delay stays about the same whatever you do, so a turn at double the speed carries you about double the distance past the mark.
| Turn speed | Carried past the stop | Wait for | Ends up at |
|---|---|---|---|
| slow | about 4° | 86 | about 90° |
| fast | about 10° | 80 | about 90° |
So the tolerance and the speed have to be chosen together. Turn faster and you must give up more; if you speed a turn up and forget to lower the number, the robot starts overshooting every corner and the program that worked last week no longer does.
when program starts :: events hat [2 v] reset angle :: sensors start moving [right: 30] :: movement wait until <([2 v] angle :: sensors) > (86)> stop moving :: movement
Find your own number rather than copying this one — it depends on your robot’s weight, its wheels and the speed you turn at. Run the turn, measure where it actually stops, and move the number by however far it missed. Two or three tries is usually enough.
The other half of the answer is to slow down. A slower turn overshoots less, so it needs less guessing and repeats more reliably — which is why a turn worth getting right is rarely worth rushing.
Drift — the thing that catches everyone
A gyro slowly loses its zero even when nothing is moving. Leave a robot sitting still for a minute and the angle may have wandered several degrees all by itself. That is drift, and it is a property of the hardware, not a bug in your program.
Two habits deal with it: reset the angle as late as possible before a turn, and keep the robot dead still while the reset happens. Resetting while the robot is rolling bakes the error in permanently.
Why it matters
Aircraft, ships and phones all use gyros to know their orientation — it is how a phone knows you have turned it sideways. A robot that can turn exactly 90 degrees on any surface is far more reliable than one that guesses with wheel rotations.
A block with an input does one kind of job at any size. A block without one does exactly one job.
The Gyro SensorFrom Level 2, Lesson 21 — measuring how far the model has turned, and why it must be still when the program starts.Show meHide
The Gyro Sensor
The Gyro Sensor measures how far the robot has turned, in degrees. Wheels slip and floors vary, so counting wheel rotations is a poor way to turn accurately — the gyro measures the turn itself rather than inferring it.
from abovefrontBlocks reference
| Block | What it does |
|---|---|
([2 v] angle :: sensors) | Reports how far the robot has turned since the angle was last reset. |
[2 v] reset angle :: sensors | Sets the current heading as zero. |
Always reset before you turn
The angle is measured from wherever it was last zeroed — not from where this turn started. Here are two robots given the same instruction, one with a reset block and one without.
reset first
when program starts
2 reset angle
start moving right: 100
2 wait until angle > 90
stop moving
no reset
start moving right: 100
2 wait until angle > 90
0°actually turned · reset0°actually turned · no reset
Reset: a real 90° turnNo reset: 0°, and no warning
Both robots have been sitting still. Both gyros already read about 34° — left over from an earlier turn — and the reading is creeping upward even now. That creep is drift.
Both programs are correct about what they asked for. Only the left one asked the question from a known starting point.
Both programs did exactly what they said. Both gyros stopped at 90. But the robot on the right had 34 degrees already on the clock, so it only turned 55 — and nothing about the program looks wrong. Watch the first step too: neither robot is moving and the reading is still climbing. That is drift, and it is why the reset belongs immediately before the turn.
Reset with the robot completely still, as late as you can.
when program starts :: events hat [2 v] reset angle :: sensors start moving [straight: 0] :: movement wait until <([2 v] angle :: sensors) > (90)> stop moving :: movement
That program is the obvious one to write, and it will not give you a 90 degree turn. The next section is why.
Stop before you get there
Asking to stop at 90 does not stop the robot at 90. Between the gyro reaching 90 and the wheels actually standing still there is a delay — the sensor has to be read, the next block has to run, and the motors have to physically brake. The robot is still turning through all of it, so it ends up past where you asked.
The fix is to ask for less than you want. Aim for a 90 degree turn by waiting for 86: the robot coasts the last few degrees on its own and settles at roughly 89 to 91.
ask for exactly 90
2 reset angle
start moving right: 30
2 wait until angle > 90
stop moving
stop 4° early
2 wait until angle > 86
stop moving
slowthis run · 50°/s+4°carried past the stop86tolerance needed here
Asked for 90: ended at 0°Asked for 86: ended at 0°
Both robots are told to turn 90°. The left one waits for the angle to pass 90; the right one gives up 4° early and waits for 86.
The tolerance has to match the speed. At 50°/s the number that lands this turn on 90° is 86 — let it loop, and watch that number change when the speed does.
The size of that gap is not a fixed property of the robot — it is the delay multiplied by how fast you are turning. The delay stays about the same whatever you do, so a turn at double the speed carries you about double the distance past the mark.
| Turn speed | Carried past the stop | Wait for | Ends up at |
|---|---|---|---|
| slow | about 4° | 86 | about 90° |
| fast | about 10° | 80 | about 90° |
So the tolerance and the speed have to be chosen together. Turn faster and you must give up more; if you speed a turn up and forget to lower the number, the robot starts overshooting every corner and the program that worked last week no longer does.
when program starts :: events hat [2 v] reset angle :: sensors start moving [right: 30] :: movement wait until <([2 v] angle :: sensors) > (86)> stop moving :: movement
Find your own number rather than copying this one — it depends on your robot’s weight, its wheels and the speed you turn at. Run the turn, measure where it actually stops, and move the number by however far it missed. Two or three tries is usually enough.
The other half of the answer is to slow down. A slower turn overshoots less, so it needs less guessing and repeats more reliably — which is why a turn worth getting right is rarely worth rushing.
Drift — the thing that catches everyone
A gyro slowly loses its zero even when nothing is moving. Leave a robot sitting still for a minute and the angle may have wandered several degrees all by itself. That is drift, and it is a property of the hardware, not a bug in your program.
Two habits deal with it: reset the angle as late as possible before a turn, and keep the robot dead still while the reset happens. Resetting while the robot is rolling bakes the error in permanently.
Why it matters
Aircraft, ships and phones all use gyros to know their orientation — it is how a phone knows you have turned it sideways. A robot that can turn exactly 90 degrees on any surface is far more reliable than one that guesses with wheel rotations.
Say this back before moving on: “The definition has a slot. The program fills it in.”
What’s in this build 4 min
Look at the fish before you read on. Which electronic parts can you find, and which of them is not doing anything you can see? There are four things worth naming.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The body of the fish, and most of its weight. It also carries the screen, which today reports what the Gyro can feel. |
| Medium Motor — the lure | Waves the stalk. Medium because the lure is light and the movement wants to be quick and precise, not strong. |
| Large Motor — the jaw | Snaps the mouth. Large because a jaw has to move a real amount of plastic in a hurry, and torque is what does that. |
| Gyro Sensor | Feels the fish being tilted or turned. Nothing on the model moves it — you move it, which makes it an input from the world rather than from the machine. |
| The lure stalk and jaw linkage (not electronic) | Both must swing freely. Work each by hand before powering anything: a stiff stalk turns a graceful sweep into a series of jerks, and the difference between your slow and fast sweeps will disappear. |
The Gyro must be still when the program starts. It works out its zero in the first moment of running, so a fish being carried across the room at that instant will read wrong for the whole session. Put it down, then press Run.
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 |
|---|---|---|
| Lure stalk (Medium) | A | The motor this lesson is about. Every sweep you write drives A. |
| Jaw (Large) | B | The second motor, and the one with the load. |
| Gyro Sensor | 2 | Level 2 put the Gyro on 2 and Level 3 keeps it there, so a program moves between models without rewiring. |
Check your own build now:
- Lure in A, jaw in B, Gyro in 2.
- Swing the lure stalk through its whole travel by hand. It must not foul the jaw at any point — if it does, the sweep will stall and every speed will look the same.
- Open and shut the jaw by hand. It should fall closed under its own weight.
- Set the fish down on the table and leave it there. You are about to start a program that zeroes the Gyro.
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.
Either route is fine today. The fish stays on the table for most of the lesson, so a USB cable costs you nothing — and in the last challenge, when you pick it up to tilt it, the cable is worth noticing: it pulls on the model, and the Gyro will feel it.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Two motor tiles — A and B.
- One sensor tile — 2, reading a Gyro in degrees.
- Turn the whole fish slowly through a quarter turn and watch tile 2. It should climb to about 90 and stay there when you stop. If it keeps drifting while the fish sits still, the Gyro was moving when the program started — put it down and restart.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
Same two-step method as last lesson. Get one sweep working, then give the block its slot.
Step 1 — one sweep, no input
define sweep repeat (4) [A v] run [clockwise v] for (40) [degrees v] at (25) % speed :: motors [A v] run [counterclockwise v] for (40) [degrees v] at (25) % speed :: motors end
Step 2 — give it a slot
- Right-click your
sweepblock and choose Edit. - Add an input — number. Call it
speed. - Drag
speedout of thedefinehat and drop it into both motor blocks, replacing the 25.
Step 3 — the whole fish
define sweep (speed) repeat (4) [A v] run [clockwise v] for (40) [degrees v] at (speed) % speed :: motors [A v] run [counterclockwise v] for (40) [degrees v] at (speed) % speed :: motors end when program starts :: events hat [2 v] reset gyro sensor :: sensors clear display :: display forever write [WAITING] at line (1) :: display sweep (15) :: custom wait (2) seconds :: control sweep (55) :: custom write ([2 v] angle) at line (3) :: display end
reset gyro sensorcomes first, once. It sets today’s zero. Do it inside the loop and the fish forgets where it started every couple of seconds.- The two sweeps are the same block. Look at them — they differ only by the number in the slot. That is the lesson, on screen.
- The pause is doing real work. An anglerfish that never stops moving its lure looks like a machine. The stillness is part of the illusion.
What success looks like: the lure drifts slowly four times, holds still for two seconds, then flicks quickly four times — and the number on line 3 changes when you turn the fish.
If both sweeps look identical, you probably typed 15 and 55 into the definition instead of dragging the input into the motor blocks. Open the definition: do the motor blocks contain an orange speed oval, or a number?
Change it and test 8 min
One change at a time. Predict, then run, then look.
- Change one
sweep (15)tosweep (100). Predict what the lure does. Notice you did not open the definition to do it. - Change the
40degrees inside the definition to15. Both sweeps get smaller — one edit, every caller affected. That is the other half of the bargain. - Add a second input. Edit the block again and add
times, then drag it into therepeatslot. Now you can callsweep (15) (10)for a long lazy wave. - Try to name the inputs badly on purpose. Rename them
aandb, then read your program. It still runs and you can no longer tell what it means — names are not decoration. - Tilt the fish while it sweeps and watch line 3. The Gyro reads the world regardless of what the lure is doing, because the two are not connected — yet. Challenge 3 connects them.
Change the number at the call to change one use. Change the definition to change every use. Knowing which you want is the skill.
Where this goes 3 min
You now have blocks that can be told what to do. What you do not have is a way for one part of a program to tell another part something has happened.
Notice what is missing from today’s program. The Gyro reading goes to the screen and nowhere else. If you wanted the jaw to snap the moment the fish is tilted, you would have to check the Gyro inside the same loop that is busy sweeping — and a loop that is sweeping is not looking.
What you want is for one stack to shout, and another to be listening. That is a broadcast, and it is the next lesson.
Lesson 1 gave a routine a name. Lesson 2 gave the name a slot. Lesson 3 gives a moment a name.