A Sensor Is a Number: The Radar Device

What you are building 3 min

The Radar Device: an Ultrasonic Sensor mounted on a Medium Motor, sweeping slowly through an arc and reporting what it finds at each step.

You have used the Ultrasonic before, and you used it as a doorbell: wait until something is closer than 15 cm, then do the next thing. The program stopped and the sensor let it go again.

That is not what a radar does. A radar never waits. It keeps turning, and at every angle it asks “how far away is whatever is in front of me right now?” — and writes the answer down.

In the real world 5 min

Where you have seen it

The slowly turning aerial beside an airport runway. It goes round once every few seconds, all day, and from that one spinning dish an air traffic controller gets a live picture of every aircraft for a hundred kilometres.

Why it is built that way

The dish can only look one way at a time, so it turns. Every reading is two facts, not one: how far away something is, and which way the dish was pointing when it found it. Distance alone is useless — a plane 40 km away is not a position until you know the bearing.

Your radar has both. The distance comes from the Ultrasonic; the bearing comes from the motor’s degrees counter, which you learned to read last lesson. That pairing is the whole instrument.

What would go wrong without it

A sensor that can only trigger cannot map anything. “Something is close” tells you to stop; it does not tell you where the gap is, which side is clearer, or how big the room is. Every robot that finds its own way around does it by reading numbers, not by waiting for triggers.

A trigger tells you when. A reading tells you how much — and how much is what you can compare.

The main concept — asking instead of waiting 6 min

The Ultrasonic Sensor gives you a number in centimetres, at any moment you care to ask for it. You have simply never asked before.

([4 v] distance in [cm v]) :: sensors

Put the two ways of using the sensor side by side:

Drop the reporter into a display block and the Brick becomes a measuring instrument:

write ([4 v] distance in [cm v]) at line (3) :: display

Two numbers make a position

One reading on its own is not much. Take a reading at every step of a sweep and pair it with the angle the motor has reached, and you have a survey of the room:

Nothing in that table required the program to stop and wait for anything. Three angles, three numbers, and now you know there is a narrow object about 30° off to one side.

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.

front

side

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.

stop under 10 cmstop under 15 cmstop under 30 cm

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 robot drives forward. The sensor is sending a burst of sound and timing its echo, over and over, and the number falls.The reading has dropped past the threshold. The condition is true, so the robot stops.Try another threshold. The program is identical — only that one number is different.Finished. The threshold is yours to choose — the sensor only supplies the number.

▶ Play⏭ Step↺ Restartstopped

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

Beacon

Stop asking the sensor to interrupt you. Start asking it for a number.

▶Reporters, from last lessonThe motor's own counter, which supplies the angle half of every reading here.Show meHide

ComponentSensing5 min

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.Both turning. The counters climb together, and so far the two motors agree.The right-hand arm has run into the post and cannot go past it. The motor is still straining against it, the counter has stopped, and the program is still waiting on that block.The left motor finished at 720. The right is stuck at 284 — it never got past the post, and that gap is the only way the robot can tell.Finished on the left. The right-hand program is still waiting, and will wait for ever.

▶ Play⏭ Step↺ Restartstopped

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.

Say this back before moving on: “A reading does not stop the program.”

What’s in this build 4 min

What the sensor can and cannot see

Sound does not bounce back off everything equally, and knowing that now saves an hour of confusion later.

1. Hold a book flat-on to the sensor at about 30 cm and watch the reading. Now angle the book steeply. The reading gets worse or vanishes — the echo is bouncing away rather than back.
2. Try a soft jumper or a cushion. Soft things absorb the click and read badly or not at all.
3. Point it at nothing — out across the room. It reads its maximum, around 250 cm.
4. Hold your hand right against it. Very close readings are unreliable too; there is a minimum as well as a maximum.

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.

Check your own build now:

1. Motor in A, Ultrasonic in 4.
2. The sensor must sit level and face outward. Tilted down it measures the table, and every reading will be about 10 cm whatever else is in the room.
3. Check the sensor cable has enough slack to turn through the whole sweep and back without pulling. A radar that winds its own cable up will stall halfway.
4. Set the radar in the middle of a clear space with a couple of objects at known distances to find.

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

1. Switch the Brick on with the dark grey centre button.
2. Cable into the Brick’s PC port — the small square socket beside the numbered ports, not one of the numbered ones.
3. 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.

1. 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.
2. Turn Bluetooth on. Settings → Bluetooth. Tick Bluetooth and Visibility. Leave iPhone/iPad/iPod unticked.
3. Connect from EV3 Classroom. Click the Brick icon at the top of the programming area, find your Brick by name, and click Connect.
4. Say yes on the Brick. It asks “Connect?” with the computer’s name — choose the tick, then accept the passkey, which is already 1234.

⤢ Tap to enlarge

⤢ Tap to enlarge

⤢ Tap to enlarge

⤢ Tap to enlarge

⤢ Tap to enlarge

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 is worth it here. You will be reading the Brick screen while the sensor turns, and a USB cable pins the Brick to wherever the laptop is rather than where you can see it.

Confirm the connection 2 min

1. Check the Brick icon: connected, or not.
2. A Medium Motor on A and an Ultrasonic on 4.
3. Wave your hand in front of the sensor and watch its tile change. This is the single most important check in the lesson — everything today depends on that number being live.
4. Turn the turntable by hand and watch tile A count. Both halves of every reading are now proven.

Make it move 10 min

A sweep out and back, taking a reading and a ping at every step, with angle and distance both on screen.

when program starts :: events hat
clear display :: display
[A v] reset degrees counted :: motors
write [Sudut / Jarak] at line (1) :: display
repeat (6)
  [A v] run for (30) [degrees v] at (25) % speed :: motors
  write ([A v] degrees counted) at line (3) :: display
  write ([4 v] distance in [cm v]) at line (5) :: display
  play beep (65) for (0.1) seconds :: sound
  wait (0.3) seconds
end
repeat (6)
  [A v] run for (30) [degrees v] at (-25) % speed :: motors
  write ([A v] degrees counted) at line (3) :: display
  write ([4 v] distance in [cm v]) at line (5) :: display
  play beep (55) for (0.1) seconds :: sound
  wait (0.3) seconds
end

1. reset degrees counted — so the sweep starts from 0° rather than from wherever the dish was left.
2. run for 30 degrees at 25% — one step of the sweep. Slow, because the sensor needs a moment of stillness to get a clean echo.
3. the two writes — angle on line 3, distance on line 5. Fixed lines, so each new reading replaces the last instead of scrolling.
4. negative speed on the way back — same block, same 30 degrees, but −25% runs the motor the other way. Watch the angle on screen count back down.

What success looks like: put a book somewhere in the arc. As the dish sweeps past it, the distance on screen should drop sharply and then rise again — and it should do it at the same angle on the way out and on the way back.

If the object is found at different angles each way, the dish is overshooting its 30° steps and not returning to the same places. Slow the sweep down, or set the motor to hold position at stop so each step ends where it was told to.

Change it and test 8 min

Keep one object in a fixed place for all of these, so you are testing the radar rather than rearranging the room.

1. Change the step to 15 degrees and the loop to 12. Same 180° arc, twice as many readings. Does the object show up more precisely?
2. Change the step to 60 degrees and the loop to 3. A fast, coarse sweep. Put a narrow object in the arc — can this sweep miss it entirely?
3. Delete the wait (0.3) seconds. A continuous sweep. Watch whether the readings get less reliable when the sensor never sits still.
4. Move the distance write block to before the motor block inside the loop. Now every reading is taken at the previous angle — the screen pairs each distance with the wrong bearing. Subtle, and completely wrong.
5. Take a proper survey. Run the sweep and write down all six angle/distance pairs on paper, then draw them as dots on a fan-shaped diagram. That drawing is a map of your room made by a robot.

Step 2 is the one to argue about. A coarse sweep is faster, and it can look right while walking straight past a chair leg. Every real radar makes the same trade, and the answer is never “as detailed as possible” — it is “detailed enough for what I am looking for”.

A reading is only useful if you know where the machine was pointing when it took it.