Challenge 1
Build a crab that never stops walking but changes pace the moment it is touched — faster while held, back to normal the instant you let go. Both changes must feel immediate.
What you are building 3 min
The Dancing Crab: a Large Motor working the legs sideways, a Touch Sensor for a claw, and a Brick that reacts to being touched while it is still dancing.
In Lesson 10 the saw waited for the button and did nothing else at all until it arrived. That is right for a saw. It would be a strange crab — a crab that stood perfectly still until you poked it, then moved.
This crab dances all the time. Touching it changes what the dance is, and the difference between those two ideas is today’s lesson.
In the real world 5 min
Where you have seen it
Ghost crabs on any beach from Krabi to Kelantan. They run sideways at surprising speed, stop dead, wave a claw, and vanish down a hole the moment your shadow reaches them.
Why it is built that way
A crab’s leg joints hinge sideways rather than forwards, so sideways is simply the direction it is built to run. And its eyes are on stalks, giving it very nearly all-round vision.
That combination matters: the crab is watching the whole time it is moving. It does not stop to check whether anything is coming. If it had to, it would be caught — a crab that freezes to look around is a crab a gull can see.
What would go wrong without it
An animal that has to stop in order to sense is helpless in the moment it is sensing. Everything that survives outdoors senses while it moves — and every robot that has to keep working while watching for something has the same problem to solve.
Waiting for something and watching for something are not the same thing.
The main concept — a sensor you can ask 6 min
The Touch Sensor gives you a hexagon as well as a wait block. The hexagon is a question you can ask at any moment, and the answer does not hold anything up.
<[1 v] is pressed?> :: sensors
Put the two ways of using the same sensor side by side:
| Block | Shape | What the machine does |
|---|---|---|
| [1 v] wait until [pressed v] | Stack | Stops. Nothing else can happen until the sensor changes. Lesson 10’s saw. |
| <[1 v] is pressed?> | Hexagon | Answers and moves on. Used inside a Switch in a loop, the machine checks constantly while doing something else. |
You have seen this distinction once before, in Lesson 9: the Ultrasonic had a wait until distance block and a distance reporter, and the radar needed the reporter because a radar that stopped to wait would never sweep. Same idea, different sensor — and it is worth noticing that it is the same idea.
forever
if <[1 v] is pressed?> then
[A v] set speed to (80) % :: motors
else
[A v] set speed to (25) % :: motors
end
endNothing in that loop ever pauses. It asks the sensor thousands of times a minute, and the crab is dancing throughout — the sensor changes the dance rather than starting it.
The Touch Sensor
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
pressedBlocks reference
| 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. |
Three different events
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.
when program starts
forever
if 1 is pressed? then
change count by 1
versus two hat blocks
1 when pressed
1 when bumped
0is pressed? in a loop0when pressed0when bumped
In a loop: 0 answers from one pressBumped: exactly one
Nobody is touching the sensor. All three programs are watching it.
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:
- Pressed — the button is down right now. Good for “hold to run”.
- Released — it is up again. Good for acting when somebody lets go.
- Bumped — pressed and released. This is what you want for “click to start”, because it will not fire repeatedly while a finger stays down.
The classic bumper
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.
Why it matters
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.
Wait-until is for “then what?”. A hexagon is for “meanwhile, how?”
The SwitchIf, if/else, and where to put them — the three lessons behind this one, in one place.Show meHide
Making a decision
Up to now a robot has been able to wait for a sensor. Deciding is different: the robot checks the sensor and does one thing or another depending on the answer — and then carries on either way.
Blocks reference
| Block | What it does |
|---|---|
if <> then end | Runs the blocks inside only when the condition is true. Otherwise skips them. |
if <> then else end | Runs one set of blocks when true and a different set when false. |
Deciding again and again
A decision made once, at the start, is almost never what you want. Here are two robots with the identical if-else, testing the identical sensor against the identical number — one inside a loop and one not.
decision inside a loop
forever
if distance < 15 then
stop moving
else · start moving
the same decision, once
if distance < 15 then
stop moving
else · start moving
247checks · in a loop1check · once only
Nothing is close, so both robots ask «is the wall within 15 cm?», both hear no, and both take the else branch and drive.
A decision is only worth as much as the last time it was made. Inside a loop, that is a few milliseconds ago.
Nothing is wrong with the right-hand program’s decision. It asked the question, got a truthful answer, and acted on it correctly. It simply never asked again, and the world moved on. Decisions belong inside a loop, so the robot keeps re-deciding as things change.
when program starts :: events hat
forever
if <([4 v] distance in [cm v] :: sensors) < (15)> then
stop moving :: movement
else
start moving [straight: 0] :: movement
end
endFour shapes, and how to choose
Once there is more than one question, decisions can be arranged in four ways. They look nearly identical stacked up in the editor, which is exactly why they get muddled — the thing that differs is not what the blocks say, it is which routes through them exist.
One question sorts them almost completely:
| Are the questions… | Use | How many bodies can run |
|---|---|---|
| independent — any combination can be true | separate ifs | none, some, or all |
| one question, two answers | if / else | exactly one |
| the second only matters when the first is true | nested if | one, and only via the outer |
| mutually exclusive cases — exactly one should win | chained if / else | exactly one, the first that matches |
Separate ifs — independent questions
Each if is asked no matter what the others answered, so any number of them can fire on the same pass. That is the right shape when the conditions genuinely have nothing to do with each other.
forever
if <[3 v] is ambient light intensity [< v] (20) %? :: sensors> then
[A v] start motor [clockwise v] :: motors
end
if <[4 v] is distance [< v] (15) [cm v]? :: sensors> then
[D v] start motor [clockwise v] :: motors
end
endif / else — one question, two answers
Exactly one branch runs, every time. Reach for this whenever the robot must do something either way — and in preference to two ifs testing opposite conditions, which is the same idea written twice and can drift apart.
Nested if — a follow-up question
Putting one if inside another means the inner question is only ever asked when the outer one is true. Use it when the second question is meaningless otherwise: there is no point asking which side an obstacle is on when there is no obstacle.
if <[4 v] is distance [< v] (15) [cm v]? :: sensors> then
if <([2 v] angle :: sensors) < (0)> then
start moving [right: 50] :: movement
end
endWhen not to nest. If you only want “both true” and nothing happens at the outer level, an and says it in one block and reads better:
if <<[4 v] is distance [< v] (15) [cm v]? :: sensors> and <([2 v] angle :: sensors) < (0)>> then start moving [right: 50] :: movement end
Nesting earns its place when something happens at the outer level too, or when there is an else at each level and the two mean different things.
Chained if / else — one winner out of several
This is the shape for a list of cases where exactly one should win: colour bands, distance bands, speed ranges. EV3 Classroom has no else-if block, so you build a chain by putting the next if inside the else of the last one.
And here is why it matters, because this is the single commonest bug in this whole module. Three bands written as three separate ifs are each perfectly correct, and together they are wrong: a reading of 20 is under 30 and under 60 and under 90, so all three run and the last one to run is the one that sticks.
three separate ifs
if light < 30 then
stop
if light < 60 then
go slowly
if light < 90 then
go fast
chained — if / else / if
if light < 30 then
stop
else
if light < 60 then
go slowly
else
go fast
↑ the rest is inside the else — never asked
3bands matchedgo fastseparate ifs dostopchained does
Separate ifs: 3 matched, last one winsChained: first match wins, rest never asked
The sensor reads 20 — a dark surface. Both programs should stop.
Separate ifs are not wrong here so much as unguarded: nothing stops a second one matching. Chaining is what makes “the first one wins” true.
The rule to carry away: if the cases are meant to be exclusive, they must be made exclusive. Chaining does it by construction. Separate ifs only work if you are careful to write non-overlapping bands yourself — light < 30, 30 to 60, 60 and over — which is more to get right and easy to break later.
Why it matters
This is the point at which a machine stops following a script and starts responding. A thermostat, an automatic door, a robot vacuum — all of them are a decision inside a loop.
Forever means forever. This is the second program in the level with no natural end — know where the stop button is before you run it, exactly as you did for the saw.
Say this back before moving on: “Asking does not stop anything.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Asks the sensor over and over while the legs keep running. It is doing two things at once without a second stack. |
| Large Motor — the legs | Drives the sideways walking linkage. Its speed is the only thing the Switch changes, which keeps the decision easy to see. |
| Touch Sensor — the claw | Mounted where a claw would be, so touching the crab is the natural way to press it. On this model the sensor is part of the character, not a control panel. |
| The walking linkage (not electronic) | Turns one rotation into a sideways step. Watch which legs are down at each point — a crab that drags a leg is a linkage assembled a hole out. |
Check the walk before you check the sensor
- Turn the motor by hand and watch the legs. They should move in a pattern, with some down while others lift.
- Set it on the table and push it through a few steps by hand. Does it track sideways, or does it curve?
- Press the claw and feel the click. A sensor that needs a hard shove is one nobody will trigger by accident — or on purpose.
- Check the claw can be pressed without your hand fouling the legs.
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 |
|---|---|---|
| Leg motor (Large) | A | One job motor, driving the whole walking mechanism. |
| Touch Sensor (claw) | 1 | Touch is always port 1 in this course — the same port as the saw’s dead-man’s switch, used a completely different way. |
Check your own build now:
- Motor in A, Touch in 1.
- Route the sensor cable along the body so it does not get walked on by the crab’s own legs.
- Give it a clear stretch of table. It walks sideways, so clear the sides rather than the front.
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, and find the stop button first. This program never ends by itself, and the crab walks — so it will keep going right off the edge of the table if you let it.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- A Large Motor on A and a Touch on 1.
- Press and release the claw several times and watch the tile. It must change every time — a sticky sensor gives a crab that scuttles for ever.
- Turn the legs by hand and check tile A counts.
Make it move 10 min
A crab that ambles along until you touch its claw, and scuttles while you hold it.
when program starts :: events hat
clear display :: display
write [KETAM] at line (1) :: display
[A v] start motor at (25) % speed :: motors
forever
if <[1 v] is pressed?> then
[A v] set speed to (80) % :: motors
write [LARI ] at line (3) :: display
else
[A v] set speed to (25) % :: motors
write [JALAN] at line (3) :: display
end
end- start motor at 25% — before the loop, and only once. The crab is already walking before any decision is made.
- forever — the loop that makes the question get asked again. Without it the sensor would be checked exactly once, at the very start, and the crab would keep that speed for the rest of its life.
- if pressed → 80% — the scuttle. Notice this is a speed change, not a start: the legs were already going.
- else → 25% — back to an amble the instant you let go. The else is what makes it change back.
What success looks like: the crab is walking from the moment you press Play. Touch the claw and it speeds up immediately; let go and it slows immediately. It never stops, and there is no lag you can perceive in either direction.
If the crab freezes until you touch it, you have used wait until pressed somewhere instead of the hexagon. That is the saw’s program, and on a crab it is the wrong animal.
Change it and test 8 min
Keep a hand near the stop button for these — several of them leave the crab running.
- Replace the whole Switch with
[1 v] wait until [pressed v]followed by a speed change. Run it and watch the crab stand still until touched. Compare that with the version above and say which is a crab. - Put the Switch back and take away the forever, leaving the Switch on its own. The crab picks one speed at the very start and keeps it. Touching it does nothing at all.
- Put the forever back. Empty the else branch. Touch the crab once — it scuttles, and it never slows down again. Explain why in one sentence.
- Change the pressed speed to −80. Now touching the crab makes it run the other way. A different animal entirely, from one minus sign.
- Add
play beep (75) for (0.05) secondsinside the if. Hold the claw and listen — this is Lesson 13’s repeated-action problem again, and now you know what it sounds like.
Steps 2 and 3 are the two halves of the same idea. Without the loop the question is asked once; without the else the answer only ever changes one way. You need the loop and both branches for a machine that genuinely tracks the world.
A machine that watches has to be in a loop, and it has to know what to do when the answer is no.