Challenge 1
Measure a metre. Mark a start and a finish exactly one metre apart, and make the robot report a distance within two centimetres of that. You may change the rotations but not the formula.
What you are building 3 min
The Adjustable Bed: a bed frame whose head end is raised and lowered by a motor, with preset positions you can call up on the Brick’s buttons.
Here is a question that sounds easy. Somebody presses the sitting up button. What should the bed do?
“Raise the head by 400 degrees” is wrong, and it is wrong in a way that will not show up in testing until somebody presses the button twice. A preset is not an amount to move. It is a place to end up.
In the real world 5 min
Where you have seen it
Hospital beds have had adjustable backs for centuries — long before electricity. This one is a wooden bed rest from the 1700s, propped at a chosen angle with padded supports.
Why it is built that way
Notice what that object does. It does not raise a patient by anything. It has notches, and each notch is a position — you put it in the third notch and the back is at the third-notch angle, whatever it was at before.
A modern bed does the same with a motor and a sensor. Press “chair position” and the bed goes to the chair position: from flat it goes a long way, from half-raised it goes a short way, and from above it comes back down. The button names a destination, not a journey.
What would go wrong without it
A bed that raised by a fixed amount each press would climb to its limit after four presses and stay there. A nurse would have no way to say “put it back where it was” except by counting. And the one thing nobody wants to be doing at a hospital bed is counting.
“Move by” depends on where you already are. “Move to” does not — which is why it is safe to press twice.
The main concept — drive until you arrive 6 min
Two instructions that look similar and behave completely differently.
| Move BY | Move TO | |
|---|---|---|
| What you write | run for (400) degrees | Drive while the count is below 400. |
| From flat (0) | Ends at 400. Correct. | Ends at 400. Correct. |
| From half-raised (200) | Ends at 600. Too far. | Ends at 400. Correct. |
| Pressed twice | Ends at 800. Runs out of bed. | Stays at 400. Nothing happens, which is right. |
How to write “move to” with what you have
There is no go-to-position block at this level, so you build one out of a loop and a condition — the same two things you have been using since Lesson 13:
[A v] start motor at (25) % speed :: motors repeat until <([A v] degrees counted) > (400)> end [A v] stop motor :: motors
That is a closed loop: the machine acts, measures the result, and keeps acting until the result is what was wanted. Every self-correcting machine ever built works this way, and you will meet a much more careful version of it in Level 4.
An empty loop body looks wrong and is not. repeat until re-tests its condition constantly, so a loop with nothing in it is a loop that does nothing except watch — which is exactly what you want while a motor that was already started keeps running.
Which way to go?
One problem remains. If the bed is above the target, that loop will not work — it is already past 400, so the loop ends immediately and the bed stays where it is. Going to a position properly means choosing a direction first, and choosing between two things is exactly what Lesson 14 gave you.
Reading a motor's position
Every EV3 motor contains a sensor that counts how far it has actually turned. That means a motor is not only an output — you can ask it where it is, and the answer describes what really happened rather than what you asked for.
Blocks reference
| Block | What it does |
|---|---|
([A v] degrees counted :: sensors) | Reports how far this motor has actually turned since the count was last reset, in degrees. |
[A v] reset degrees counted :: motors | Sets the count back to zero, making right here the new reference point. |
([A v] speed :: sensors) | Reports how fast the motor is turning right now, as a percentage. A motor that is being driven but reads zero is a motor that is stuck. |
Asked for, versus achieved
Those two are not always the same. Here are two identical motors, running the same program, with only their mechanisms different.
when program starts
A reset degrees counted
A run clockwise for 2 rotations
write A degrees counted at line 1
the same program, on two identical motors
720degrees asked for0counted · free0counted · jammed
Free: asked 720, counted 720Jammed: asked 720, counted 0
Both motors are told to turn two rotations — 720 degrees. Both counters start at zero.
Nothing on the Brick announces a stall. The only evidence is that the counter stopped changing while the motor was still being told to turn.
Nothing on the Brick announces the jam. The motor is still being driven, the program is still sitting on the same block, and the only trace of the problem anywhere is a counter that has stopped climbing. Comparing what you asked for with what was counted is how a robot notices — which is the whole of stall detection.
Zero is wherever you say it is
When the Brick powers on, the count is simply whatever it happens to be. It is not a position on the machine — it becomes one only when you tie it to something physical.
That is what reset degrees counted is for, and it is not just a tidy-up block for the top of a program. Where you put it decides what zero means, so putting it part-way through — after the mechanism has been driven somewhere known — is the normal way to use it, not an abuse of it.
Find home first, then reset
A conveyor has no idea where it is. Give it a touch sensor at one end and it can find out: drive it until the sensor is pressed, and it is now at a place you can name. Only then reset the count, and that end becomes 0.
when program starts :: events hat [A v] start motor [counterclockwise v] :: motors [1 v] wait until [pressed v] :: sensors [A v] stop motor :: motors [A v] reset degrees counted :: motors
The order is the whole point. Reset before the sensor is pressed and you have zeroed a random spot; reset after it, and every later reading means “how far from home”. This is called homing, and it is why a printer rattles its head to one side when you switch it on.
Drive towards home gently. The mechanism is deliberately being run into its own end stop, so a slow speed saves the gears — and the touch sensor is what stops it, which means it stops in the same place every time regardless of where it started.
Putting zero somewhere more useful
Home is often a corner, and a corner is an awkward place to measure from. Say the conveyor carries a chute that dispenses bricks, and you would rather describe its position as left and right of the middle. Then home once, drive the known distance to the middle, and reset again there:
when program starts :: events hat [A v] start motor [counterclockwise v] :: motors [1 v] wait until [pressed v] :: sensors [A v] stop motor :: motors [A v] reset degrees counted :: motors [A v] run [clockwise v] for (900) [degrees v] :: motors [A v] reset degrees counted :: motors
Now the middle is 0. Moving right counts up, moving left counts down past zero into negative numbers — the count is perfectly happy to go negative — and “go back to the middle” becomes the simplest instruction in the program: drive until the count reaches 0.
Both resets earn their place. The first one turns a meaningless number into a distance from a real, repeatable place. The second one moves zero to where the maths is easiest. A reset in the middle of a program is only a mistake when the mechanism is somewhere you cannot name.
Turning turns into distance
Because the count is in degrees, and a wheel of known size travels a known distance per turn, the reading can be converted into how far the robot has actually driven. That is how a robot reports a distance in centimetres rather than in rotations — and it is why changing the wheels changes the answer.
Why it matters
This is how a printer knows the paper jammed, how a car window stops when it meets your hand, and how a robot arm knows it has reached its limit. A machine that can only give orders is fragile; one that can check what happened can recover.
To reach a target: decide which way, start moving, and watch until you arrive.
Choosing between two thingsThe if/else from Lesson 14 — here it picks the direction of travel.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.
Say this back before moving on: “Move to means it does not matter where I start.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Holds the presets and its buttons are the control panel. No extra sensor is needed for the buttons. |
| Large Motor — the backrest | Raises and lowers the head end. Its encoder is the bed’s only sense of where it is, so it must never be moved by hand while the program is running. |
| The lifting mechanism (not electronic) | A screw, a lever or a rack. It must hold the backrest up without the motor fighting it — which is a build problem before it is a stop-setting one. |
| The Brick screen | Names the position the bed is in, so a user knows which preset they are looking at. |
Find your own numbers
The 400 on this page is a placeholder. Your bed’s numbers come from your bed.
- Wind the backrest fully flat by hand. Reset the motor’s counter here — this is position zero, and everything is measured from it.
- Wind it slowly to its highest safe angle, stopping well before anything strains. Read the count. That is your maximum.
- Pick three presets between those two — flat, half, sitting up — and write the counts down. They belong to this bed and nobody else’s.
- Wind it back to flat. Every run today starts from a known place.
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 |
|---|---|---|
| Backrest motor (Large) | A | One job motor — and the port appears inside every condition as well as every movement. |
| Sensors | none | The Brick’s own buttons are the controls, and the position comes from the motor. |
Check your own build now:
- Motor in A.
- Set the bed flat before pressing Play, every single time. The program cannot see the bed; it only knows what its counter says.
- Check the mechanism cannot run past its limits under power. A closed loop will happily drive into a hard stop for ever if the target is beyond it.
- Keep fingers out of the hinge. It is slow, but it does not stop for you.
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 suits this one. You will be pressing the Brick’s own buttons as the control panel, so the Brick needs to be in front of you rather than wherever the cable reaches.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- One Large Motor tile on A.
- Wind the bed from flat to fully up by hand and watch the count. Compare it with the maximum you wrote down — they should match.
- Check the count goes up as the bed rises. If it goes down, every comparison in your program needs to face the other way, and it is easier to fix that now.
Make it move 10 min
Two presets on two buttons, each of which goes to its position from wherever the bed happens to be.
when program starts :: events hat [A v] set motor to [hold position v] at stop :: motors [A v] reset degrees counted :: motors clear display :: display write [RATA] at line (1) :: display when [up v] button [pressed v] :: events hat write [DUDUK] at line (1) :: display if <([A v] degrees counted) < (400)> then [A v] start motor at (25) % speed :: motors repeat until <([A v] degrees counted) > (400)> end else [A v] start motor at (-25) % speed :: motors repeat until <([A v] degrees counted) < (400)> end end [A v] stop motor :: motors when [down v] button [pressed v] :: events hat write [RATA ] at line (1) :: display [A v] start motor at (-25) % speed :: motors repeat until <([A v] degrees counted) < (20)> end [A v] stop motor :: motors
- The setup stack — hold position at stop, so the backrest does not sag once it arrives, and a reset that declares the current position flat.
- The UP stack decides direction first. Below 400, drive up and watch for the count to pass it. Above 400, drive down — note the negative speed — and watch for it to fall below. That if/else is what makes it a real “go to”.
- The empty repeat-until bodies — the motor is already running; the loop only watches.
- The DOWN stack needs no if/else, because flat is the bottom and the bed can only ever be above it. Aiming at 20 rather than 0 leaves a little room so it does not grind into the stop.
What success looks like: from flat, press UP and the bed rises to the sitting position and holds. Press UP again and nothing happens — that is the test. Press DOWN and it returns to flat. Then wind the bed halfway by hand, press UP, and watch it come to the same place as before.
If it overshoots noticeably, the speed is too high for how often the loop can check. Drop to 15% and it will stop closer to the mark — a slower machine has more chances to notice it has arrived.
Change it and test 8 min
Start every test from a different position on purpose. A go-to that only works from flat has not been tested.
- Replace the whole UP stack with a plain
[A v] run for (400) [degrees v] at (25) % speed. Press UP three times. Watch the bed climb past its limit and strain. Then put the loop version back. - Add a third preset on the right button — halfway, around 200. Now check the awkward case: from the sitting position, press halfway, and confirm it comes down to get there.
- Change the speed to 60%. Measure how far past the target it now stops. Then 15%, and measure again.
- Set the UP target beyond your mechanical maximum on purpose. Watch it drive into the stop and keep trying — then stop the program, and say what you would add to prevent it.
- Wind the bed by hand while a preset is running. The loop is watching the count, so it reacts. Is that good behaviour or dangerous behaviour on a real bed?
Step 1 is the whole lesson in three button presses. The relative version works perfectly the first time and destroys itself the third — which is exactly the kind of bug that passes a demo and fails in a ward.
Test a “go to” by pressing it twice. If the second press does something, it is a “go by” wearing a disguise.
