Challenge 1
Cycle through three named modes and act on each one, with the screen always showing the current mode.
What you are building 3 min
The Battle Rescue Robot: a driving base with a magazine that holds up to ten short beams, and a Medium Motor that releases a rubber band to launch them one at a time.
It is meant to be sent somewhere a person should not go — to clear a path, to knock something over, to reach and come back. One machine, several different jobs.
By the end of the lesson your robot will have a menu — three modes, cycled with one button and confirmed with another, with the live mode always visible on the screen.
Safety, before anything else. This model launches a beam. Point it at a wall or a cardboard box, never at a person, an animal or a window. Everybody within two metres wears eye protection. One rule, no exceptions, all lesson.
In the real world 5 min
Where you have seen it
Bomb disposal robots are sent in so that a person does not have to be there. One machine carries a camera, an arm, a gripper and sometimes a disruptor, and an operator a safe distance away chooses which to use.
Why it is built that way
One robot with several tools beats several robots with one tool each. It is cheaper, it is one thing to carry and maintain, and — the real reason — you do not know which tool the job needs until you get there.
But it creates a problem that a single-purpose machine never has. The same control now does different things depending on what mode the robot is in. The operator has to know which mode they are in before they touch anything.
What would go wrong without it
You already know this failure. Type your password with Caps Lock on: every key does something different from what you intended, nothing warns you, and you only find out afterwards. The keyboard was in a mode and did not say so.
In aviation this has a name — mode confusion — and it has caused real crashes: a crew believing the autopilot was in one mode while it was in another, both giving perfectly correct commands to a system doing something else. The fix, everywhere, is the same: show the mode, all the time, where the operator is looking.
A mode you cannot see is a trap. If a machine has modes, its display has one job above all others.
The main concept — a variable with more than two states 6 min
Lesson 34’s Transmitting Gyro had a variable with two values, 0 and 1, and one button flipped between them. Nothing said it had to stop at two.
change [mod v] by (1) if <(mod) > (3)> then set [mod v] to (1) end write (mod) at line (1) :: display
if is what makes it a cycle instead of a number that runs away.The wrap is the bit people get wrong
Without those three lines the counter goes 4, 5, 6, and every mode check after 3 fails. The robot ends up in no mode at all, silently — and change by 1 gives no warning, because counting past 3 is a perfectly reasonable thing for a number to do.
Check for greater-than, not equals. if <(mod) > (3)> catches 4 and also catches 7 if anything ever skipped. if <(mod) = (4)> works right up until something increments twice, and then the menu is broken for the rest of the session. Lesson 33 made the same point about the ammunition counter.
Choosing, then doing
The mode is picked with one button and acted on with another, and that separation is the whole design:
if <(mod) = (1)> then
move [forward v] for (2) [rotations v] at (40) % speed :: movement
else
if <(mod) = (2)> then
[A v] run [clockwise v] for (1) [rotations v] at (100) % speed :: motors
else
move [backward v] for (3) [rotations v] at (60) % speed :: movement
end
endNotice there is no fourth branch and no need for one. The final else catches everything that is not 1 or 2, and because the wrap keeps mod in range, that means 3.
Three rules for a menu somebody else can use
- Show the mode every time it changes, in the same place on the screen. This is not a nicety — it is the whole safety story from step 2.
- Separate choosing from doing. One button cycles, another commits. A menu where selecting is acting cannot be browsed safely.
- Name the modes, do not number them. “MOD 2” means nothing under pressure. “LANCAR” means something.
Variables
Why anybody needs one
Long before there were computers, people had exactly this problem. A shepherd counting sheep through a gate, a trader counting sacks of grain, a builder counting days — none of them can hold the number in their head while they get on with the work. So they scratched a mark on a wall, cut a notch in a stick, or wrote a number on a piece of paper. The number lived outside the person, in a place they had agreed on, and they could go back to it, read it, and change it.
Better still, once the number is written down somebody else can use it. Watch these two: one of them counts and writes, the other never sees a single animal and simply reads the wall.
Abby never remembers the numberBen never sees a henThe wall holds it for both
Abby has a gate and a wall. Before a single hen comes through she chalks 0 on the wall — that is where the number is going to live.
Notice what never happens: Ben never asks Abby. He does not need to — the number is not in her head, it is on the wall, and the wall is there for anyone who needs it.
Neither Abby nor Ben is holding the number — the wall is. And notice what never happens: Ben does not ask Abby. He does not need to, because the count is not in her head. It is in a place they both agreed on, which is what makes it useful to more than one of them.
That is all a variable is. The robot cannot hold a number in its head either, so you give it a wall of its own, write a name at the top so everyone knows which wall is which — score, count, degree_turn — and the program can read what is on it and write something new. One part of the program writes; another part reads. Exactly Abby and Ben.
The paper, and the two things you can do to it
Say we are counting rotations of a motor. Before we start we write 0 on the paper. Every time the motor completes a turn we cross out what is there and write one more: 0 becomes 1, then 2, then 3. That is change — it has to read the old number to work out the new one.
set is the other thing you can do, and it is completely different: rub the whole paper out and write the number you want. It does not care what was there. Press the buttons and watch what happens to the crossings-out.
score
0
The paper starts blank, so we write 0 on it. That is what a variable is: a place to keep a number while the robot works.
- change leaves a trail — every value follows from the one before it. This is what counting is.
- set wipes the sheet. Use it to start a count, never to continue one.
- Press set score to 0 after counting up a few times and watch the whole history vanish. That is what happens to a count when a set block ends up in the wrong place — and it is the commonest variable bug there is.
Blocks reference
| Block | What it does |
|---|---|
set [count v] to (0) | Puts a value in, replacing whatever was there. |
change [count v] by (1) | Adds to what is already there. |
(count) | Reports the current value, for use in a comparison or on the display. |
Set, or change?
set replaces; change adds. Counting things needs change. Starting a count needs set. Both programs below have both blocks — the only difference is whether the set block is inside the loop or above it.
set before the loop
when program starts
set count to 0
repeat 4
A run clockwise for 1 rotations
change count by 1
set inside it
repeat 4
set count to 0
A run clockwise for 1 rotations
change count by 1
Before the loop: counted 0Inside the loop: stuck at 0
Both programs count the turns of a motor. The left sets the count to zero before the loop; the right sets it inside.
Both programs contain both blocks. Only the position of set [count] to 0 is different.
The count on the right is not broken; it is being told to start again on every pass. Each time round the loop it is wiped back to zero and then changed by one, so the honest answer is always 1 — while the motor cheerfully turns four times. A counter stuck at 1 almost always means a set block that has slipped inside the loop.
Anything oval is a number you can pick up
EV3 Classroom tells you what a block does by its shape, and once you have noticed that, a whole set of questions answers itself:
- Oval — reports a number. The blue degrees counted, the timer, a distance, your own variable.
- Pointed — reports true or false. These go in an if or a wait until, not in a variable.
- Block-shaped — does something. These stack up; they do not fit inside anything.
So when a slot is oval, any oval fits it — and it does not matter in the least where that number came from. You can take the motor’s own A degrees counted and keep it in a variable you named degree_turn, then compare that with a number later. Pick an oval below and watch the same one drop into all three kinds of slot.
pick an oval
the same oval fits all three
set degree_turn to A degrees countedkeep it in a variable of your own
A degrees counted + 10do arithmetic with it
A degrees counted > 50compare it with a number
Every one of those slots is oval-shaped, and A degrees counted is an oval — so it drops in. Nothing about where the number came from matters.
This is what makes a variable more than a counter. A sensor reading is true only at the instant you read it; copying it into a variable freezes it, so the robot can compare where it is now against where it was when something happened:
when program starts :: events hat [A v] reset degrees counted :: motors set [degree_turn v] to ([A v] degrees counted :: sensors) start moving [right: 30] :: movement wait until <(([A v] degrees counted :: sensors) - (degree_turn)) > (400)> stop moving :: movement
Read the condition aloud: how far the motor has gone now, minus where it was when we started, is more than 400. Both are ovals, so both can go into a subtraction, and the subtraction is an oval too — which is why it can go into a comparison. Ovals nest inside ovals as deep as you need.
Reset at the start, every time
A variable keeps its value after the program ends. Run the program again without setting it back and the second run begins where the first left off — the count starts at 14, the robot thinks it has already done the job. Every variable a program changes must be set to its starting value at the top.
Why it matters
A variable is the difference between a machine that repeats a fixed routine and one that responds to how things have gone — counting parts, tracking a score, remembering where it started.
The Brick buttons
The Brick has five buttons of its own — up, down, left, right and centre. They need no sensor, no cable and no port, which makes them the easiest way to let a person tell the robot to do something.
Blocks reference
| Block | What it does |
|---|---|
when [center v] button [pressed v] :: events hat | Starts a whole stack when that button is pressed. |
wait until <is [center v] button pressed? :: sensors> | Holds an existing program until the button is pressed. |
Press to begin
A program sitting on a wait block looks exactly like a program that has crashed. Watch one wait — including through two presses of the wrong button.
when program starts
wait until is center button pressed?
A run clockwise for 1 rotations
the other way to do it
when center button pressed
A run clockwise for 1 rotations
The program has reached the wait block. It is not stuck — it is waiting, and nothing below it will run until the centre button goes down.
A program parked on a wait block looks identical to a crashed one. This is why the status light or a line on the screen is worth setting before you wait.
The wait is watching one button. Up and right change the (button) reading, and the program does not care. That reading is a number rather than a name: 0 for nothing, then 1 left, 2 centre, 3 right, 4 up, 5 down.
A hat, or a wait?
- A hat gives the button its own separate stack, which can run at any time. Good for a control the user may press whenever they like.
- A wait puts the button in the middle of a sequence. Good for “press to begin”, where nothing should happen before it.
Why it matters
Nearly every machine has a start button that is deliberately separate from switching the power on. A robot that begins moving the instant it is powered up is hard to set down and hard to test — one that waits for a press can be positioned first.
A mode is a variable with more than two values. Wrap it, and show it.
One button, two jobsFrom Lesson 34 — ask, act, record, and why the recording is the hard part.Show meHide
Variables
Why anybody needs one
Long before there were computers, people had exactly this problem. A shepherd counting sheep through a gate, a trader counting sacks of grain, a builder counting days — none of them can hold the number in their head while they get on with the work. So they scratched a mark on a wall, cut a notch in a stick, or wrote a number on a piece of paper. The number lived outside the person, in a place they had agreed on, and they could go back to it, read it, and change it.
Better still, once the number is written down somebody else can use it. Watch these two: one of them counts and writes, the other never sees a single animal and simply reads the wall.
Abby never remembers the numberBen never sees a henThe wall holds it for both
Abby has a gate and a wall. Before a single hen comes through she chalks 0 on the wall — that is where the number is going to live.
Notice what never happens: Ben never asks Abby. He does not need to — the number is not in her head, it is on the wall, and the wall is there for anyone who needs it.
Neither Abby nor Ben is holding the number — the wall is. And notice what never happens: Ben does not ask Abby. He does not need to, because the count is not in her head. It is in a place they both agreed on, which is what makes it useful to more than one of them.
That is all a variable is. The robot cannot hold a number in its head either, so you give it a wall of its own, write a name at the top so everyone knows which wall is which — score, count, degree_turn — and the program can read what is on it and write something new. One part of the program writes; another part reads. Exactly Abby and Ben.
The paper, and the two things you can do to it
Say we are counting rotations of a motor. Before we start we write 0 on the paper. Every time the motor completes a turn we cross out what is there and write one more: 0 becomes 1, then 2, then 3. That is change — it has to read the old number to work out the new one.
set is the other thing you can do, and it is completely different: rub the whole paper out and write the number you want. It does not care what was there. Press the buttons and watch what happens to the crossings-out.
score
0
The paper starts blank, so we write 0 on it. That is what a variable is: a place to keep a number while the robot works.
- change leaves a trail — every value follows from the one before it. This is what counting is.
- set wipes the sheet. Use it to start a count, never to continue one.
- Press set score to 0 after counting up a few times and watch the whole history vanish. That is what happens to a count when a set block ends up in the wrong place — and it is the commonest variable bug there is.
Blocks reference
| Block | What it does |
|---|---|
set [count v] to (0) | Puts a value in, replacing whatever was there. |
change [count v] by (1) | Adds to what is already there. |
(count) | Reports the current value, for use in a comparison or on the display. |
Set, or change?
set replaces; change adds. Counting things needs change. Starting a count needs set. Both programs below have both blocks — the only difference is whether the set block is inside the loop or above it.
set before the loop
when program starts
set count to 0
repeat 4
A run clockwise for 1 rotations
change count by 1
set inside it
repeat 4
set count to 0
A run clockwise for 1 rotations
change count by 1
Before the loop: counted 0Inside the loop: stuck at 0
Both programs count the turns of a motor. The left sets the count to zero before the loop; the right sets it inside.
Both programs contain both blocks. Only the position of set [count] to 0 is different.
The count on the right is not broken; it is being told to start again on every pass. Each time round the loop it is wiped back to zero and then changed by one, so the honest answer is always 1 — while the motor cheerfully turns four times. A counter stuck at 1 almost always means a set block that has slipped inside the loop.
Anything oval is a number you can pick up
EV3 Classroom tells you what a block does by its shape, and once you have noticed that, a whole set of questions answers itself:
- Oval — reports a number. The blue degrees counted, the timer, a distance, your own variable.
- Pointed — reports true or false. These go in an if or a wait until, not in a variable.
- Block-shaped — does something. These stack up; they do not fit inside anything.
So when a slot is oval, any oval fits it — and it does not matter in the least where that number came from. You can take the motor’s own A degrees counted and keep it in a variable you named degree_turn, then compare that with a number later. Pick an oval below and watch the same one drop into all three kinds of slot.
pick an oval
the same oval fits all three
set degree_turn to A degrees countedkeep it in a variable of your own
A degrees counted + 10do arithmetic with it
A degrees counted > 50compare it with a number
Every one of those slots is oval-shaped, and A degrees counted is an oval — so it drops in. Nothing about where the number came from matters.
This is what makes a variable more than a counter. A sensor reading is true only at the instant you read it; copying it into a variable freezes it, so the robot can compare where it is now against where it was when something happened:
when program starts :: events hat [A v] reset degrees counted :: motors set [degree_turn v] to ([A v] degrees counted :: sensors) start moving [right: 30] :: movement wait until <(([A v] degrees counted :: sensors) - (degree_turn)) > (400)> stop moving :: movement
Read the condition aloud: how far the motor has gone now, minus where it was when we started, is more than 400. Both are ovals, so both can go into a subtraction, and the subtraction is an oval too — which is why it can go into a comparison. Ovals nest inside ovals as deep as you need.
Reset at the start, every time
A variable keeps its value after the program ends. Run the program again without setting it back and the second run begins where the first left off — the count starts at 14, the robot thinks it has already done the job. Every variable a program changes must be set to its starting value at the top.
Why it matters
A variable is the difference between a machine that repeats a fixed routine and one that responds to how things have gone — counting parts, tracking a score, remembering where it started.
Say this back before moving on: “Cycle, wrap, show — then act.”
What’s in this build 4 min
Look at your robot. Three motors and no sensors — so where does everything the robot knows come from? (From you. That is what the menu is for.)
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The robot and the control panel. Its screen is the most important part today — it is the only thing telling the operator which mode they are in. |
| Large Motor ×2 — the drive | A matched pair, taking the robot in and bringing it back. |
| Medium Motor — the launcher | Releases the band. One shot per rotation, so its own port and its own mode. |
| The magazine and band (not electronic) | Holds up to ten beams and stores the energy. Nothing here counts them — which is Lesson 33’s counter waiting to be added. |
Decide your three modes before you program them
- Write down three jobs this robot should do, in words, before touching a block. Advance. Launch. Withdraw.
- Give each a short name that fits the screen — eight characters or fewer — and that a person could read at a glance.
- Decide which is mode 1. That is the one the robot starts in, so it should be the safest of the three.
Step 3 matters more than it looks. The starting mode is the one somebody gets by accident. Make it the one that cannot hurt anybody.
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 |
|---|---|---|
| Left drive wheel | B | The pair. Two motors, one job. |
| Right drive wheel | C | The other half of the pair. |
| Launcher | A | Its own job, away from the pair. |
| Sensors | none | A person chooses the mode and a person decides when to act. Adding a sensor that chooses the mode is what the challenges are for. |
The manual never says which port anything goes in — it ends at the last building step with no cables drawn. So the ports above are this course’s conventions, not the manual’s instructions, and nothing in your build contradicts them.
Check your own build now:
- Wheels in B and C, launcher in A.
- Point the robot at the box before you load it, and keep it that way for the whole lesson.
- Load the magazine and write down how many beams went in.
- Cables off the ground and clear of the launch path.
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 hold the Brick where you can read it. The whole lesson rests on the operator being able to see the mode. If the screen is face-down on a desk while the robot drives away, you have built exactly the trap step 2 described.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Three motor tiles — A, B and C.
- Turn each drive wheel by hand and confirm left is B and right is C. Then move the launcher and confirm A. A swapped A would make the menu’s launch mode drive instead.
- Test the menu with the magazine empty first. Cycle through all three modes and fire each one before you load a single beam.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
Three stacks: set up, cycle the menu, and act on whatever is selected.
when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
set [mod v] to (1)
clear display :: display
write [1 MARA ] at line (1) :: display
when [left v] button [pressed v] :: events hat
change [mod v] by (1)
if <(mod) > (3)> then
set [mod v] to (1)
end
if <(mod) = (1)> then
write [1 MARA ] at line (1) :: display
else
if <(mod) = (2)> then
write [2 LANCAR ] at line (1) :: display
else
write [3 UNDUR ] at line (1) :: display
end
end
when [center v] button [pressed v] :: events hat
if <(mod) = (1)> then
move [forward v] for (2) [rotations v] at (40) % speed :: movement
else
if <(mod) = (2)> then
[A v] run [clockwise v] for (1) [rotations v] at (100) % speed :: motors
else
move [backward v] for (3) [rotations v] at (60) % speed :: movement
end
end- Mode 1 is MARA — advance. It is the starting mode because driving forward is the least dangerous of the three, and it is the one a stray button press will get you.
- The menu stack redraws the screen every single time. There is no path through it that changes the mode without changing the display, and there must not be.
- Both nested Switches ask the same questions in the same order. Keeping them identical means a reader can check them against each other, and a mismatch between them is the bug that produces a screen that lies.
- The trailing spaces pad every name to the same length, so LANCAR cannot leave an R behind when MARA is written over it.
What success looks like: the screen reads 1 MARA. Press left twice and it reads 3 UNDUR. Press left once more and it wraps to 1 MARA. Press centre and the robot does exactly what the screen says — every time, with no surprises.
If the screen and the action disagree, your two Switch chains have drifted apart. That is the mode-confusion bug in miniature, and it is worth sitting with for a moment: the robot is behaving perfectly and lying about it.
Change it and test 8 min
One change at a time, and hand the Brick to somebody else after each without explaining. Whether they can use it is the only test that counts.
- Delete the wrap. Press left five times and then centre. Nothing happens —
modis 6 and no branch matches, except the finalelse, which now fires the wrong thing. Find out which. - Change the wrap to
if <(mod) = (4)>. It works. Now press left very fast and see whether you can make it skip past 4. This is why greater-than is safer. - Take the screen writing out of the menu stack. The modes still cycle and the screen never changes. Ask a friend to use it. This is the whole of step 2 in one experiment, and it is the most important run in the lesson.
- Add a fourth mode — a spin on the spot. Change the wrap to 4 and add a branch to both chains. Notice you had to edit two places, and what happens if you forget one.
- Add Lesson 33’s ammunition counter to the launch mode: refuse to fire when
peluruis 0, and show it on line 2. - Put the mode name on the status light too: set status light to [green v] for advance, orange for launch, red for withdraw. Now the mode is visible from across the room, without reading anything.
Step 3 and step 6 are the same lesson from opposite ends. Take the display away and a working robot becomes unusable; add a second, wordless display and it becomes usable from further away. None of that changed what the robot does. All of it changed whether a person can work with it.
Every path that changes the mode must also change the display. No exceptions, or the screen becomes a liar.