Steadying a Jumpy Number: The Biped — EV3 L3

What you are building 3 min

The Biped: a two-legged robot that walks by shifting its weight from one foot to the other, with an Ultrasonic Sensor in its chest watching what is in front of it.

A biped does not glide. It rocks side to side and nods forward and back with every step, and the sensor rocks with it — so the distance it reports swings up and down several times a second even when the wall is perfectly still.

By the end of the lesson your robot will hold a steady distance from a wall while walking — which is impossible until you stop believing any single reading.

In the real world 5 min

Where you have seen it

Human walking is a controlled fall. You lift one foot, topple forward, and catch yourself with the other — which is why walking is so hard for robots and why a toddler takes a year to learn it. Your head moves several centimetres up and down with every step.

A two-legged walking robot standing upright. — Biped walking robot model human1. Photo: Pipimaru / Wikimedia Commons (CC BY-SA 3.0).

You do not notice, because your brain smooths it. The vestibulo-ocular reflex moves your eyes to cancel head motion, and higher up, your sense of “how far away is that door” is built from many glances rather than one.

Why it is built that way

Any measurement taken from a moving platform carries the platform’s motion. A ship’s radar rolls with the swell; a phone’s step-counter is swamped by hand-wave; a drone’s altitude sensor sees its own vibration.

The standard answer is a filter: combine several readings so that the wobble, which goes up as often as down, largely cancels — while the real signal, which does not, survives.

What would go wrong without it

A machine acting on every twitch of a noisy sensor spends its time chasing noise. Worse, it looks broken in a way that is hard to diagnose, because the program is correct and the sensor is working — the fault is in believing a single sample.

A measurement from a moving thing is the world plus the movement. Filtering is how you get the world back.

The main concept — averaging out the wobble 6 min

A moving average is the simplest useful filter: instead of using the newest reading, use the average of the last few. Noise that goes up as often as down mostly cancels; a real change does not.

set [total v] to (0) :: variables
repeat (5)
  set [total v] to ((total) + ([4 v] distance in cm)) :: variables
end
set [smooth v] to ((total) / (5)) :: variables

Five readings, one number. The rocking of a stride shows up in individual samples and largely disappears from the average.

Why it works

The wobble is roughly symmetrical: as the robot rocks forward the reading falls, as it rocks back it rises, by similar amounts. Add five of those together and the ups and downs partly cancel. The wall’s actual distance is in every sample, so it adds up five times and survives the division.

More samples means smoother — and later. This is the whole trade-off. Average two readings and you keep most of the noise. Average twenty and the number is beautiful, but by the time it changes the robot has walked into the wall. A filtered value is always a report of the recent past.

Samples averaged	Steadiness	Lag	Good for
1 (no filter)	Jumps constantly.	None.	Nothing on a moving robot.
3–5	Usably steady.	Barely noticeable.	Most jobs. Start here.
20+	Very steady.	Obvious and dangerous.	Slow-changing things only — room temperature, not obstacles.

The other filter: throw away the nonsense

Ultrasonic sensors occasionally return a wild value — 255 when the pulse comes back from nothing, or a sudden 3 when it catches the robot’s own leg. One of those inside an average drags it badly.

set [reading v] to ([4 v] distance in cm) :: variables
if <<(reading) > (2)> and <(reading) < (150)>> then
  set [total v] to ((total) + (reading)) :: variables
  change [count v] by (1) :: variables
end

Only plausible readings are counted. A value the sensor cannot really mean is discarded rather than averaged in.

Decide what is plausible from the physical situation, not from the data. Your robot cannot be 1 cm from a wall it is walking towards, and it does not care about anything three metres away.

ComponentSensing6 min

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.

EV3 Ultrasonic Sensor from the front, showing its two round openings — The two round openings on the front are the point of this sensor: one sends the burst of sound out, the other listens for the echo coming back.

EV3 Ultrasonic Sensor from the side — The two round openings on the front are the point of this sensor: one sends the burst of sound out, the other listens for the echo coming back.

Blocks 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.

stopped

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.

EV3 Infrared Sensor from the front — The Infrared Sensor and its Beacon, from the Home set. If your kit has these, expect proximity numbers rather than centimetres — and retune any threshold accordingly.

ComponentControl5 min

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 false · or 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.

ComponentControl5 min

Repeating

Machines repeat. A wiper sweeps, a conveyor runs, a ride goes round — and none of that should mean copying the same blocks over and over. A loop says “do this again” once.

Blocks reference

Block	What it does
repeat (10) end	Runs the blocks inside a set number of times, then carries on below.
forever end	Runs the blocks inside over and over, and never carries on below.
repeat until <> end	Repeats until a condition becomes true — a loop with a sensor as its exit.

Forever really does mean forever

Anything placed after a forever loop will never run. Not “runs late” — never. Both programs below end with the same block: set the status light green.

repeat (3)

repeat 3

A run clockwise for 0.25 rotations

set status light to green

forever

A run clockwise for 0.25 rotations

set status light to green

↑ this block never runs

0passes · repeat (3)0passes · forever

repeat (3): still goingforever: light never set

Both loops begin. Each pass turns the motor a quarter turn.

starting

Both programs contain the same green-light block. Let it run as long as you like — the right-hand ring will never turn green.

The repeat loop counts its three passes, stops, and moves on to the block underneath, so its light turns green. The forever loop reaches the bottom of its own blocks and jumps straight back to the top, so the block underneath is never reached — however long you leave it. If a program seems to stop half way through, look for a forever loop above the blocks that are not happening.

Why a sensor program needs a loop at all

A program is a list, and the Brick works down it once. Every block runs, in order, and when the last one is done the program is over. That is fine for a list of instructions — drive, turn, beep, stop — because each is a thing you do once.

A sensor is not a thing you do once. Asking is 1 pressed? gives you an answer about this instant, and an instant later it may be wrong. Checking a sensor once tells you what the world was like at the moment the program started — which is almost never what you wanted to know.

So a program that has to react must ask again, and again, for as long as it is running. That is the whole job of the loop: not to repeat an action, but to keep the question being asked.

Read, decide, act — and then do it again

Wrap a sensor check and the motor it controls in a forever loop and you have built a closed-loop control system — the pattern behind every line follower, thermostat and cruise control:

Read the sensor.
Decide what that reading means.
Act on the motors.
Go back to 1 — immediately, thousands of times a minute.

It is called closed because the output feeds back round to the input: the motors move the robot, moving the robot changes what the sensor sees, and what the sensor sees changes the motors. Break the circle at any point and the robot stops responding.

when program starts :: events hat
forever
  if <[1 v] is pressed? :: sensors> then
    [A v] start motor [clockwise v] :: motors
  else
    [A v] stop motor :: motors
  end
end

Read it as a sentence and it is almost too simple to need explaining: for ever, if the button is pressed run the motor, otherwise stop it. The motor now follows the button for as long as the program is running.

The same program without the loop

This is the mistake nearly everybody makes first, and it is a hard one to spot because nothing about it looks wrong:

when program starts :: events hat
if <[1 v] is pressed? :: sensors> then
  [A v] start motor [clockwise v] :: motors
else
  [A v] stop motor :: motors
end

The logic is perfect. The ports are right. Nothing is misspelled. And the robot will ignore the button completely — because the Brick reaches that if/else a few milliseconds after you press Run, finds the button not pressed, takes the else branch, stops the motor, runs out of blocks and ends. By the time a finger arrives, there is no program left to notice it.

with forever — a closed loop

when program starts

forever

if 1 is pressed? then

A start motor clockwise

else

A stop motor

without it — the common mistake

when program starts

if 1 is pressed? then

A start motor clockwise

else

A stop motor

↑ running — for the only time

40checks · with forever1checks · no loop

Looped: motor off, matching the buttonNo loop: motor off for ever, whatever you press

Both programs start. The button is not pressed, so both take the else branch and leave the motor off. So far they agree exactly.

button released

Both programs contain exactly the same if/else. The only difference is the forever block around one of them.

Both programs contain exactly the same if/else. The counter is what gives it away: one keeps checking for as long as it runs, the other is stuck on the single check it made before anybody touched anything. A student who has seen this once stops writing it.

The tell on a real robot is a program that ends the instant you start it — the Brick returns to its menu almost immediately. If a sensor program finishes rather than waits, the loop is what is missing.

Choosing the right loop

Known number of times — repeat (n). A wiper that sweeps five times.
Until something happens — repeat until. Drive until the wall is close.
For as long as the machine is on — forever. A fan, a ride, a monitor.

Never act on one sample from a moving machine. Average a few, and know that you are acting on the recent past.

The closed loopFrom Lesson 5 — measure, compare, correct. Today the measuring gets careful.Show meHide

ComponentSensing6 min

The Ultrasonic Sensor

Blocks 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

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.

stopped

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.

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

Say this back before moving on: “Smoother is later. Choose how much later.”

What’s in this build 4 min

Walk the robot forward by hand, slowly, and watch the sensor. Does it stay level, or does it dip and rise with each step? The answer is today’s problem.

Part	What it is doing here
EV3 Intelligent Brick	The body, and most of the mass being thrown side to side. Its height is why the robot rocks so much — a tall thing on two feet has a long lever.
Large Motor ×2 — the legs	Drive the walking linkage. They must be in step: a biped whose legs drift out of phase does not walk, it shuffles sideways.
Ultrasonic Sensor — the chest	Faces forward and rocks with the body. This is the noisy input, and its noise is mechanical rather than electrical — which means it is periodic, and averaging across a whole stride works well.
The leg linkage (not electronic)	Slack here becomes wobble there. Work both legs through a full stride and look for anything loose — you are about to spend the lesson filtering out exactly that.

Mount the sensor as low and as central as you can. Height multiplies rocking: a sensor at the top of the Brick swings much further than one at hip level. Fixing the mechanics costs nothing and reduces how much filtering you need — always prefer that to filtering harder.

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 leg (Large)	B	The movement pair, as on every walking or driving model.
Right leg (Large)	C	The other half of the pair.
Eyes (Ultrasonic)	4	Ultrasonic stays on 4 across the course.

Check your own build now:

Legs in B and C, sensor in 4.
Check the legs are in phase. Set both to their start position by hand — one forward, one back — before every run, or the first few steps will be a stumble.
Stand the robot on a hard, flat floor. Carpet damps the rocking and hides today’s problem until you move to a table.
Hold it still facing a wall, read the sensor for ten seconds, then walk it on the spot and read it again. Write both ranges down. The difference between them is what you are about to filter.

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 EV3 until 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.

The EV3 Brick's home screen with the name EV3VE circled in red at the top of the display, labelled Your Brick's name. — **Where to read it.** The name sits in the bar across the very top of the screen, on *every* screen — so you can check which Brick you are holding at any moment without going into a menu. This one is **EV3VE**. A Brick nobody has renamed says `EV3`.

The Connect via Bluetooth dialog in EV3 Classroom listing three available bricks named HUGO, EV3 and EV3VE, each with a CONNECT button. — Step 3, and the reason step 1 exists. Three Bricks in range — **read the name** before you click Connect. Pairing with the wrong one is not an error: it works perfectly, on somebody else’s robot.

The EV3 Bluetooth settings screen showing Connections, Visibility ticked, Bluetooth ticked, and iPhone/iPad/iPod unticked. — **Step 2.** **Bluetooth** switches the radio on; **Visibility** is what lets the computer find you. With Visibility off your Brick works perfectly and simply never appears in the list.

The EV3 Brick screen showing a Connect? dialog naming the computer ALJAY-MSI, with a cross and a tick. — **Step 4.** Look *at the Brick*. It asks whether to accept and names the computer. Choose the tick.

The EV3 Brick PASSKEY screen with 1234 already entered and an on-screen keyboard below. — **Then the passkey**, already **1234**. Press the tick again and you are connected.

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, definitely. A biped is barely stable at the best of times, and a USB lead hanging off it changes its balance and adds a pull that varies with the stride — which would add noise of a kind no filter is designed for.

Confirm the connection 2 min

Check the Brick icon: connected, or not.
Two motor tiles — B and C.
One sensor tile — 4, in centimetres.
Rock the robot gently by hand while watching tile 4. The number should swing noticeably. That swing is the entire subject of this lesson, and seeing it before you program makes everything afterwards obvious.

Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.

Make it move 10 min

Show the problem first. Put both the raw and the smoothed value on screen at once, so the class can see the difference rather than be told about it.

Step 1 — raw against smoothed, side by side

when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
clear display :: display
start moving [forward v] at (30) % speed :: movement
forever
  set [raw v] to ([4 v] distance in cm) :: variables
  set [total v] to (0) :: variables
  repeat (5)
    set [total v] to ((total) + ([4 v] distance in cm)) :: variables
  end
  set [smooth v] to ((total) / (5)) :: variables
  write (raw) at line (2) :: display
  write (smooth) at line (4) :: display
end

Walk it towards a wall and watch both lines. Line 2 dances; line 4 walks steadily down. Same sensor, same wall.

Step 2 — hold a distance using the steady number

when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
set [target v] to (25) :: variables
set [band v] to (4) :: variables
clear display :: display
forever
  set [total v] to (0) :: variables
  set [count v] to (0) :: variables
  repeat (5)
    set [reading v] to ([4 v] distance in cm) :: variables
    if <<(reading) > (2)> and <(reading) < (150)>> then
      set [total v] to ((total) + (reading)) :: variables
      change [count v] by (1) :: variables
    end
  end
  if <(count) > (0)> then
    set [smooth v] to ((total) / (count)) :: variables
  end
  set [error v] to ((smooth) - (target)) :: variables
  write (smooth) at line (2) :: display
  if <([abs v] of (error)) > (band)> then
    start moving [forward v] at ((error) * (2)) % speed :: movement
  else
    stop moving :: movement
  end
end

Filter, discard nonsense, then run Lesson 5’s loop and Lesson 10’s deadband on the steady value. Move the wall and the robot follows it.

count exists because readings can be rejected. If two of five were nonsense, dividing by 5 gives a wrong answer. Divide by how many you actually kept.
if count > 0 guards the division. If every reading were rejected, dividing by zero would break the program — so keep the previous smoothed value instead.
The whole of Lessons 5, 10 and 14 are in one loop. Filter, compare, deadband, act. That stack of ideas is what a real controller looks like.
The error drives the speed, sign and all. Too far → positive → walk forward. Too close → negative → walk back. Still no if choosing a direction.

What success looks like: the biped walks up to about 25 cm from a board, stops, and follows the board when you move it slowly — without the twitchy stop-start that a raw reading produces.

If it lurches back and forth, your average is too long and the value is arriving too late — drop to 3 samples. If it still twitches, the average is too short or the deadband too narrow. Change one at a time.

Change it and test 8 min

One change at a time. Predict, then run, then look.

Average 1 sample (change both 5s to 1). You are back to the raw reading. Watch how the robot behaves and describe it in one word.
Average 20 samples. Line 2 becomes beautifully steady — and the robot walks into the board, because by the time the number moves it is too late. This is lag, felt rather than explained.
Find your best number. Somewhere between 3 and 8 there is a value that is steady enough to act on and fast enough to matter. Write it on the board with your stride speed — the two are related.
Halve the walking speed and re-test your best number. A slower stride rocks less and rocks slower, so your filter may want to be shorter. Filters are tuned to the machine, not chosen once.
Break the plausibility check. Change it to accept anything under 255, then hold a hand very close so the sensor returns a wild value. Watch one bad sample drag the average and the robot lurch.

Fix the wobble in the machine first, then filter what is left. Filtering is a repair, not a design.

Where this goes 3 min

You can now trust what a machine measures — calibrated, cross-checked and steady. The next two lessons are about trusting what a machine does.

Your walking program is one loop that always does the same thing. A robot that has to perform a routine — go here, do this, then that, then the other — currently needs that routine written out as blocks, in order, for ever.

A list can hold a sequence of instructions just as easily as a sequence of measurements. Store the moves, then step through them — and suddenly changing the routine means changing data rather than blocks. That is the next lesson.

A list of numbers is a record. A list of instructions is a program your program can read.

What you are building 3 min

The Biped: a two-legged robot that walks by shifting its weight from one foot to the other, with an Ultrasonic Sensor in its chest watching what is in front of it.

By the end of the lesson your robot will hold a steady distance from a wall while walking — which is impossible until you stop believing any single reading.

In the real world 5 min

Where you have seen it

Why it is built that way

The standard answer is a filter: combine several readings so that the wobble, which goes up as often as down, largely cancels — while the real signal, which does not, survives.

What would go wrong without it

A measurement from a moving thing is the world plus the movement. Filtering is how you get the world back.

The main concept — averaging out the wobble 6 min

A moving average is the simplest useful filter: instead of using the newest reading, use the average of the last few. Noise that goes up as often as down mostly cancels; a real change does not.

set [total v] to (0) :: variables
repeat (5)
  set [total v] to ((total) + ([4 v] distance in cm)) :: variables
end
set [smooth v] to ((total) / (5)) :: variables

Five readings, one number. The rocking of a stride shows up in individual samples and largely disappears from the average.

Why it works

Samples averaged	Steadiness	Lag	Good for
1 (no filter)	Jumps constantly.	None.	Nothing on a moving robot.
3–5	Usably steady.	Barely noticeable.	Most jobs. Start here.
20+	Very steady.	Obvious and dangerous.	Slow-changing things only — room temperature, not obstacles.

The other filter: throw away the nonsense

Ultrasonic sensors occasionally return a wild value — 255 when the pulse comes back from nothing, or a sudden 3 when it catches the robot’s own leg. One of those inside an average drags it badly.

set [reading v] to ([4 v] distance in cm) :: variables
if <<(reading) > (2)> and <(reading) < (150)>> then
  set [total v] to ((total) + (reading)) :: variables
  change [count v] by (1) :: variables
end

Only plausible readings are counted. A value the sensor cannot really mean is discarded rather than averaged in.

Decide what is plausible from the physical situation, not from the data. Your robot cannot be 1 cm from a wall it is walking towards, and it does not care about anything three metres away.

ComponentSensing6 min

The Ultrasonic Sensor

Blocks 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

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.

stopped

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.

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

ComponentControl5 min

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?

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?

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.

Try it: and, or, not

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 false · or 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.

Choosing the threshold

Combining two conditions

ComponentControl5 min

Repeating

Machines repeat. A wiper sweeps, a conveyor runs, a ride goes round — and none of that should mean copying the same blocks over and over. A loop says “do this again” once.

Blocks reference

Block	What it does
repeat (10) end	Runs the blocks inside a set number of times, then carries on below.
forever end	Runs the blocks inside over and over, and never carries on below.
repeat until <> end	Repeats until a condition becomes true — a loop with a sensor as its exit.

Forever really does mean forever

Anything placed after a forever loop will never run. Not “runs late” — never. Both programs below end with the same block: set the status light green.

repeat (3)

repeat 3

A run clockwise for 0.25 rotations

set status light to green

forever

A run clockwise for 0.25 rotations

set status light to green

↑ this block never runs

0passes · repeat (3)0passes · forever

repeat (3): still goingforever: light never set

Both loops begin. Each pass turns the motor a quarter turn.

starting

Both programs contain the same green-light block. Let it run as long as you like — the right-hand ring will never turn green.

Why a sensor program needs a loop at all

So a program that has to react must ask again, and again, for as long as it is running. That is the whole job of the loop: not to repeat an action, but to keep the question being asked.

Read, decide, act — and then do it again

Wrap a sensor check and the motor it controls in a forever loop and you have built a closed-loop control system — the pattern behind every line follower, thermostat and cruise control:

Read the sensor.
Decide what that reading means.
Act on the motors.
Go back to 1 — immediately, thousands of times a minute.

when program starts :: events hat
forever
  if <[1 v] is pressed? :: sensors> then
    [A v] start motor [clockwise v] :: motors
  else
    [A v] stop motor :: motors
  end
end

The same program without the loop

This is the mistake nearly everybody makes first, and it is a hard one to spot because nothing about it looks wrong:

when program starts :: events hat
if <[1 v] is pressed? :: sensors> then
  [A v] start motor [clockwise v] :: motors
else
  [A v] stop motor :: motors
end

with forever — a closed loop

when program starts

forever

if 1 is pressed? then

A start motor clockwise

else

A stop motor

without it — the common mistake

when program starts

if 1 is pressed? then

A start motor clockwise

else

A stop motor

↑ running — for the only time

40checks · with forever1checks · no loop

Looped: motor off, matching the buttonNo loop: motor off for ever, whatever you press

Both programs start. The button is not pressed, so both take the else branch and leave the motor off. So far they agree exactly.

button released

Both programs contain exactly the same if/else. The only difference is the forever block around one of them.

Choosing the right loop

Known number of times — repeat (n). A wiper that sweeps five times.
Until something happens — repeat until. Drive until the wall is close.
For as long as the machine is on — forever. A fan, a ride, a monitor.

Never act on one sample from a moving machine. Average a few, and know that you are acting on the recent past.

The closed loopFrom Lesson 5 — measure, compare, correct. Today the measuring gets careful.Show meHide

ComponentSensing6 min

The Ultrasonic Sensor

Blocks 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

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.

stopped

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.

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

Say this back before moving on: “Smoother is later. Choose how much later.”

What’s in this build 4 min

Walk the robot forward by hand, slowly, and watch the sensor. Does it stay level, or does it dip and rise with each step? The answer is today’s problem.

Part	What it is doing here
EV3 Intelligent Brick	The body, and most of the mass being thrown side to side. Its height is why the robot rocks so much — a tall thing on two feet has a long lever.
Large Motor ×2 — the legs	Drive the walking linkage. They must be in step: a biped whose legs drift out of phase does not walk, it shuffles sideways.
Ultrasonic Sensor — the chest	Faces forward and rocks with the body. This is the noisy input, and its noise is mechanical rather than electrical — which means it is periodic, and averaging across a whole stride works well.
The leg linkage (not electronic)	Slack here becomes wobble there. Work both legs through a full stride and look for anything loose — you are about to spend the lesson filtering out exactly that.

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 leg (Large)	B	The movement pair, as on every walking or driving model.
Right leg (Large)	C	The other half of the pair.
Eyes (Ultrasonic)	4	Ultrasonic stays on 4 across the course.

Check your own build now:

Legs in B and C, sensor in 4.
Check the legs are in phase. Set both to their start position by hand — one forward, one back — before every run, or the first few steps will be a stumble.
Stand the robot on a hard, flat floor. Carpet damps the rocking and hides today’s problem until you move to a table.
Hold it still facing a wall, read the sensor for ten seconds, then walk it on the spot and read it again. Write both ranges down. The difference between them is what you are about to filter.

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 EV3 until 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.

The long version, including Port View and how to read the port tiles, is in the Brick & Bluetooth guide.

Confirm the connection 2 min

Check the Brick icon: connected, or not.
Two motor tiles — B and C.
One sensor tile — 4, in centimetres.
Rock the robot gently by hand while watching tile 4. The number should swing noticeably. That swing is the entire subject of this lesson, and seeing it before you program makes everything afterwards obvious.

Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.

Make it move 10 min

Show the problem first. Put both the raw and the smoothed value on screen at once, so the class can see the difference rather than be told about it.

Step 1 — raw against smoothed, side by side

when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
clear display :: display
start moving [forward v] at (30) % speed :: movement
forever
  set [raw v] to ([4 v] distance in cm) :: variables
  set [total v] to (0) :: variables
  repeat (5)
    set [total v] to ((total) + ([4 v] distance in cm)) :: variables
  end
  set [smooth v] to ((total) / (5)) :: variables
  write (raw) at line (2) :: display
  write (smooth) at line (4) :: display
end

Walk it towards a wall and watch both lines. Line 2 dances; line 4 walks steadily down. Same sensor, same wall.

Step 2 — hold a distance using the steady number

when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
set [target v] to (25) :: variables
set [band v] to (4) :: variables
clear display :: display
forever
  set [total v] to (0) :: variables
  set [count v] to (0) :: variables
  repeat (5)
    set [reading v] to ([4 v] distance in cm) :: variables
    if <<(reading) > (2)> and <(reading) < (150)>> then
      set [total v] to ((total) + (reading)) :: variables
      change [count v] by (1) :: variables
    end
  end
  if <(count) > (0)> then
    set [smooth v] to ((total) / (count)) :: variables
  end
  set [error v] to ((smooth) - (target)) :: variables
  write (smooth) at line (2) :: display
  if <([abs v] of (error)) > (band)> then
    start moving [forward v] at ((error) * (2)) % speed :: movement
  else
    stop moving :: movement
  end
end

Filter, discard nonsense, then run Lesson 5’s loop and Lesson 10’s deadband on the steady value. Move the wall and the robot follows it.

count exists because readings can be rejected. If two of five were nonsense, dividing by 5 gives a wrong answer. Divide by how many you actually kept.
if count > 0 guards the division. If every reading were rejected, dividing by zero would break the program — so keep the previous smoothed value instead.
The whole of Lessons 5, 10 and 14 are in one loop. Filter, compare, deadband, act. That stack of ideas is what a real controller looks like.
The error drives the speed, sign and all. Too far → positive → walk forward. Too close → negative → walk back. Still no if choosing a direction.

What success looks like: the biped walks up to about 25 cm from a board, stops, and follows the board when you move it slowly — without the twitchy stop-start that a raw reading produces.

Change it and test 8 min

One change at a time. Predict, then run, then look.

Average 1 sample (change both 5s to 1). You are back to the raw reading. Watch how the robot behaves and describe it in one word.
Average 20 samples. Line 2 becomes beautifully steady — and the robot walks into the board, because by the time the number moves it is too late. This is lag, felt rather than explained.
Find your best number. Somewhere between 3 and 8 there is a value that is steady enough to act on and fast enough to matter. Write it on the board with your stride speed — the two are related.
Halve the walking speed and re-test your best number. A slower stride rocks less and rocks slower, so your filter may want to be shorter. Filters are tuned to the machine, not chosen once.
Break the plausibility check. Change it to accept anything under 255, then hold a hand very close so the sensor returns a wild value. Watch one bad sample drag the average and the robot lurch.

Fix the wobble in the machine first, then filter what is left. Filtering is a repair, not a design.

Where this goes 3 min

You can now trust what a machine measures — calibrated, cross-checked and steady. The next two lessons are about trusting what a machine does.

A list of numbers is a record. A list of instructions is a program your program can read.