Challenge 1
Ski towards a wall and stop with a gap of about 12 cm, arriving slowly rather than stopping suddenly.
What you are building 3 min
The Skiing Robot: a figure on skis with two motorised poles. The poles reach forward, plant, and push back — and the whole robot slides forward.
An Ultrasonic Sensor is its head, looking down the track. It has no brakes: on skis, stopping means stopping poling and then waiting for the glide to run out.
By the end of the lesson the robot will slow down smoothly as it nears an obstacle, instead of charging up to it and stopping dead — and it will do that with one block you have never used this way before.
In the real world 5 min
Where you have seen it
A cross-country skier moves by planting poles and pushing. Between pushes they glide — no effort at all, just the ski sliding on a thin film of melted snow under its own base.
Why it is built that way
Skis are built to have almost no friction forwards and quite a lot sideways. That is wonderful for going and terrible for stopping. A skier has no brakes. They slow by snowploughing, by turning across the hill, or simply by stopping poling and letting the glide die.
So a skier approaching another skier does not decide at the last second. They ease off gradually, and the closer they get the more they ease off. Watch a queue at the top of a slope and you will see everybody doing continuous, smooth, tiny adjustments — nobody is switching between “full speed” and “stopped”.
You do the same in a car without being told. You do not hold full speed to the junction and then stamp on the brake. You press harder the closer you get. The response scales with the situation.
What would go wrong without it
Lesson 35’s King Kong ran flat out and stopped when the wall got close, and it overshot every time — because a machine at full speed cannot stop instantly. Arriving slowly is much easier than stopping quickly.
Do not go full speed until you must stop. Go slower as the reason to stop gets nearer.
Before you build 1 min
This model has no step-by-step manual, and the video above is not one. It films a finished robot skiing. Watch it for how the poles plant and how far they swing, then build from the model your teacher has. You are not missing a page; the page does not exist.
The programs below name ports rather than motor types.
The main concept — the reading becomes the setting 6 min
Every sensor program you have written so far has asked a yes-or-no question. Is it closer than 25? Is the switch pressed? Two answers, two behaviours.
set movement speed to ([4 v] distance in [cm v] :: sensors) % :: movement
No question is asked. Nothing is compared. The number simply goes straight in — and because it does, the robot has not two speeds but a hundred.
| Wall is | Sensor reports | Robot travels at |
|---|---|---|
| far off | 90 cm | 90% — full pelt |
| getting closer | 50 cm | 50% — easing off already |
| close | 20 cm | 20% — creeping |
| nearly there | 8 cm | 8% — barely moving, easy to stop |
By the time it needs to stop, it has almost stopped anyway. That is why this beats the King Kong’s approach. The overshoot problem has not been solved by better stopping — it has been removed by never being fast when it mattered.
Two names worth knowing
- Bang-bang control — full on, or full off. A kettle, a fridge, and Lesson 35. Simple, and it always overshoots.
- Proportional control — the response is proportional to the reading. Smooth, and much harder to overshoot. This is the P in the PID line follower that Level 4 is built around, and you have just written one.
Two honest warnings
Speed clamps at 100. The Ultrasonic reads up to 255 cm, and a speed of 255% is not a thing. Anything above 100 is simply 100, which happens to be the behaviour you wanted — but know that it is a clamp and not your program being clever.
Below about 10%, motors stop turning at all. There is not enough torque to overcome the machine’s own friction, so a proportional robot creeps to a halt slightly further out than you expected and sits there humming. Adding a small fixed amount to the speed — a minimum — is the standard fix, and step 10 has you find yours.
The Ultrasonic Sensor
The Ultrasonic Sensor measures distance. It sends out a burst of sound too high for people to hear, listens for the echo, and works out how far away the surface is from how long the echo took — exactly how a bat finds a moth, and how a submarine uses sonar.
front
sideBlocks reference
| Block | What it does |
|---|---|
([4 v] distance in [cm v] :: sensors) | Reports how far away the nearest thing in front of the sensor is, as a number in centimetres. |
wait until <([4 v] distance in [cm v] :: sensors) < (15)> | Holds the program until something comes closer than 15 cm. |
A number, not a yes or no
This is the important step up from the Touch Sensor. Touch gives you true or false; the Ultrasonic gives you a number, and the deciding is left to you. Pick a threshold below and watch where the robot ends up.
when program starts
start moving straight: 0
4 wait until distance < 15 cm
stop moving
60cm · reading15cm · threshold
Nothing is close. The sensor reports about 60 cm and the program waits.
The black line on the bar is the threshold; the blue fill is the reading. The robot stops the instant the fill crosses the line.
Three different robots, and only one number is different between them. That is what having a number rather than a yes-or-no buys you: the behaviour is tuned by editing one slot, not by rebuilding the program. It also means the sensor can never tell you it is “close” — close is a decision you make about a reading.
Why it matters
Car parking sensors, automatic doors at a shopping centre, and the sensor that stops a lift door closing on somebody all work this way. Reacting before contact is what makes a machine feel safe.
If your set has an Infrared Sensor instead
The Home/Retail EV3 set (31313) ships an Infrared Sensor and a Beacon in place of the Ultrasonic and Gyro sensors. The Infrared Sensor also measures distance, so the programs in this module work with it — but it reports a rough 0–100 proximity rather than real centimetres, and it is affected by sunlight and by dark surfaces in ways the Ultrasonic is not.
IR Sensor
BeaconSpeed and power
Speed is set separately from movement. You tell the motor how fast it should go, and then you tell it to go — two blocks, in that order.
Blocks reference
| Block | What it does |
|---|---|
[A v] set speed to (25) % :: motors | Sets the speed for this motor from now on. Nothing moves — it only changes what the next movement will do. |
[A v] run [clockwise v] for (2) [rotations v] :: motors | Now moves, at whatever speed was last set. |
Set it first
when program starts :: events hat [A v] set speed to (25) % :: motors [A v] run [clockwise v] for (2) [rotations v] :: motors
Swap those two blocks round and the program still contains a speed of 25 % — it just never gets used. Both shafts below are asked for exactly 2 rotations; watch how long each one takes.
speed first — works
A set speed to 25 %
A run clockwise for 2 rotations
speed last — does nothing
A run clockwise for 2 rotations
A set speed to 25 %
0.00rotations · slow0.00rotations · fast
Speed first: the movement was slowSpeed last: it only affects the NEXT movement
Two programs. Same two blocks in each — only the order is different.
Both shafts turn exactly 2 rotations. Only the time they take is different — and the right-hand program never gets the slow movement it was written to have.
The right-hand movement is over before the left is a third of the way round, because it ran at the default speed. Its set speed to () block does run — you can see it light up — but by then the movement it was meant to slow down has already happened. A speed block only ever affects the movements after it. This catches people out constantly.
Slow is often better
A high speed is not a better program. Slow movements are gentler on the gears, easier to watch and debug, and look more like the real machine — a barrier that snaps up in a fraction of a second reads as broken rather than fast.
A sensor reading can be an answer to a question, or it can be a number you use directly. The second one is smoother.
Arithmetic on measurementsFrom Lesson 18 — operators taking sensor readings as their inputs.Show meHide
Comparing and combining
A sensor that reports a number cannot be used to make a decision on its own — 23 is neither true nor false. An operator turns that number into an answer by comparing it with something.
Blocks reference
| Block | What it does |
|---|---|
<(x) > (50)> | True when the left value is bigger than the right. |
<(x) < (50)> | True when it is smaller. |
<<> and <>> | True only when both conditions are true. |
<<> or <>> | True when at least one of them is. |
Try it: which way round does it go?
Forget the symbols for a moment. A comparison is a question about position on a number line: is x to the left of the other number, or to the right? Left is smaller, right is bigger — and that is the whole of it.
Drag the orange x and the black marker, and change the comparison. The green stretch is every position of x that would make the answer true — so you can see where the answer flips before you get there. Turn not on and watch the green jump to the other side.
Drag either marker, or use the arrow keys.
-3 < 4true
is x to the LEFT of it?
- < is true while x sits on the left. Slide x past the marker and it flips.
- > is the same question the other way round — so exactly one of the two is true, unless the markers are on the same spot.
- = is true for one single position out of twenty-one. Try landing on it. That is why a sensor is almost never compared with =: a reading passes straight through the exact number without ever being measured there.
- not flips the answer, whatever it was. not (x < 4) covers everything x < 4 does not — including landing exactly on 4.
Try it: which numbers make it true?
The lab above asks one question at a time: is this x true? A robot never has just one x, though — a sensor reading slides up and down all the time, so what really matters is which stretch of the line makes the condition true. This one draws the whole answer at once.
Drag the circle to move the number you are comparing against, and change the comparison. Everything shaded green is a value of x that would make it true.
Drag the circle, or use the arrow keys. It moves in steps of 0.2.
x < 0.2x < 0.2
Every number to the left of 0.2 — but not 0.2 itself, so the circle is hollow.
Watch the circle, because it carries the part everyone gets wrong:
- Hollow ○ — the boundary is not included. x < 0.2 shades everything left of 0.2 but leaves 0.2 itself out, because 0.2 is not less than 0.2.
- Filled ● — the boundary is included. Choose = and nothing is shaded at all: one single number qualifies.
Now turn not on with x > 2 selected and watch two things happen together. The shading jumps to the other side, and the circle fills in — because “not greater than 2” means 2 or less, and 2 has to be part of it. That pairing is the whole reason a hollow circle is worth drawing.
Why a robot cares. Two conditions that look almost identical — light < 30 and not (light > 30) — differ by exactly one value, the reading of precisely 30. A robot sitting right on its threshold behaves differently under the two, and that is the sort of bug that only shows up occasionally and looks like a broken sensor.
Try it: and, or, not
These three join answers together rather than numbers. The trap is that English is looser than a program: “stop if it is close and the bumper is pressed” sounds like it covers both situations, when it covers neither on its own.
Flip the two conditions and watch the table. There are only four possible situations in total, and and and or differ on exactly two of them.
close: true and bumper: falsefalse
| close | bumper | and | or |
|---|---|---|---|
| true | true | true | true |
| true | false | false | true |
| false | true | false | true |
| false | false | false | false |
and is fussy: it wants both. Three of the four rows are false.
- and is true on one row out of four. It narrows — the robot acts less often, but more certainly.
- or is true on three rows out of four. It widens — the robot acts more readily.
- The two agree on the top and bottom rows and disagree in the middle. Whenever swapping one for the other seems to make no difference, you have only tried the rows where they agree.
Watch them decide
Two sensors are running below: an Ultrasonic reporting a number, and a Touch Sensor reporting true or false. Watch the comparison turn the number into an answer, and watch and and or disagree.
when program starts
forever
if distance < 15 and is pressed? then
stop moving
if distance < 15 or is pressed? then
play beep 60 for 0.2 seconds
Nothing is within 15 cm and the bumper is out. Both conditions are false.
and was true in one row out of four. or was true in three. That is the whole difference, and it is why one of them makes a robot look broken.
The comparison is doing one job: it takes a reading that is neither true nor false and, by holding it against a number you chose, produces something a decision can use. The moment the blue fill crosses the black marker is the moment the answer changes.
Choosing the threshold
The number you compare against is a design decision, not a fact. “Close” for a parking sensor might be 15 cm; for a robot arm it might be 3. Pick it by measuring what the sensor actually reads in the situation you care about, then leave a margin.
Combining two conditions
and narrows: both must hold, so the robot acts less often but more certainly — stop only if something is close and the bumper is pressed. or widens: either will do, so the robot acts more readily — stop if something is close or the bumper is pressed.
In the four situations above, and was true in one of them and or in three. That is the practical difference: swapping one for the other does not adjust a robot slightly, it changes how often it reacts at all.
Say this back before moving on: “The closer it gets, the slower it goes — no question asked.”
What’s in this build 4 min
Look at your robot. Nothing here is a wheel. How does a machine with no wheels know how fast it is going? (It does not — and that matters today.)
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The skier’s body. Its weight presses the skis down, which is what gives the poles something to push against. |
| Pole motor ×2 | A matched pair, driven together. If they fall out of step the robot skis in a circle. |
| Ultrasonic Sensor — the head | Looks down the track. Today it does not answer a question; it supplies a number, continuously. |
| The skis (not electronic) | Low friction forwards, high friction sideways. That is what makes the pole push turn into travel instead of a slide. |
| The pole tips (not electronic) | Need grip. On a smooth table they slip and the robot goes nowhere — try a sheet of paper or a cloth under it. |
The encoder is lying to you on this model, and it is fine. The motors turn the poles, not wheels, so degrees counted says how much the robot poled, not how far it went. Lesson 42’s circumference maths does not apply here at all — which is a good reason to be measuring the world with the sensor instead.
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 pole | B | The pair. Two motors, one job. |
| Right pole | C | The other half — and the pair the set movement speed to block governs. |
| Head (Ultrasonic) | 4 | The Ultrasonic’s standing home. |
Check your own wiring now:
- Poles in B and C, head in 4.
- Both poles must start at the same point in their swing. Set them by hand before every run.
- Cables taped to the body so they cannot swing with the poles or drag on the surface. Drag on this robot is the difference between skiing and sitting.
- Aim the head level, down the track. Tipped down it reads the table and the robot will crawl from the start.
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 this time it is not optional. This machine travels on almost no friction, so a USB cable is not a minor drag — it is a bigger force than the poles produce. The robot will simply not move.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Two motor tiles on B and C, and an Ultrasonic tile on 4.
- Walk the robot slowly towards your wall and watch tile 4 the whole way. It should count smoothly down: 80, 60, 40, 20. Today you are not checking one threshold — you are checking the numbers in between, because every one of them will become a speed.
- If the reading jumps about, the wall is scattering the echo. Use a flat book, square on, before you blame the program.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
Ski towards the wall, easing off the whole way, and arrive gently.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement clear display :: display repeat until <([4 v] distance in [cm v] :: sensors) < (12)> set movement speed to ([4 v] distance in [cm v] :: sensors) % :: movement write ([4 v] distance in [cm v]) at line (1) :: display move [forward v] for (0.5) [rotations v] :: movement end stop moving :: movement write [SAMPAI] at line (3) :: display play sound [Communication / Hello v] until done :: sound
- The speed is set fresh every stroke. Put that block outside the loop and the robot picks a speed once, at the start, and skis into the wall at it.
- The
moveblock carries no speed of its own. It uses whateverset movement speedlast said — which is the whole mechanism. A speed typed into the move block would override it and silently break the lesson. - Half a rotation per stroke keeps the blind spot small, exactly as Lesson 35 argued. Small strides matter more here, because the speed is being recalculated between them.
- Line 1 shows the distance so you can watch the number fall and hear the poling slow at the same time. The screen and the sound tell the same story.
What success looks like: the robot sets off briskly, and audibly eases. By the time it is a hand’s width from the book it is barely moving, and it stops with a gap rather than a bump.
If it stalls a long way out, you have found the low-speed limit — the motors cannot turn at 15%. Step 10 fixes it. If it is still fast at the wall, the head is reading something further away than the wall; check tile 4 by hand.
Change it and test 8 min
One change at a time, and measure the final gap with a ruler every run. Predict the gap before each one.
- Find your stall speed. Replace the sensor with a fixed
set movement speed to (20) %and run. Then 15, then 10. The lowest number that still moves the robot is your minimum — write it down. - Add that minimum in. Put the sensor back but use (([4 v] distance in [cm v]) + (15)) as the speed. Now it never stalls, and it still eases off. This is a proportional response with an offset, and every real controller has one.
- Change the gain. Try (([4 v] distance in [cm v]) * (2)). The robot stays fast for much longer and brakes late. Then try (([4 v] distance in [cm v]) / (2)) — cautious and slow. Which arrives closest to 12 cm?
- Go back to bang-bang and compare properly. Replace the whole thing with a fixed speed of 60 and Lesson 35’s
repeat until. Run both five times and measure the final gap each time. Which is more accurate, and which is more repeatable? - Move the wall further away and run again without changing anything. Does the proportional version still arrive gently? It should — it never had a distance in it at all.
- Put a hand in front of the robot and take it away again while it is running. It slows and speeds back up. Nothing in the program expects an obstacle to leave — it just keeps reading.
Step 4 is the comparison to write down. Bang-bang is faster on a good day and never the same twice. Proportional is a little slower and lands in almost the same place every run. For a competition robot that has to score points reliably, the second one wins, and that is why Level 4 spends twelve lessons on it.
Two states give you two behaviours. A number gives you all of them.