EV3 RoboticsComponent tutorialsWaiting

Control · Level 1 · 4 min

Waiting

Pause for a length of time, or until a sensor says so.

ComponentControl4 min

Waiting

Waiting is how a program gives the physical world time to catch up. There are two kinds, and choosing between them is one of the first real design decisions in robotics.

Blocks reference

BlockWhat it does
wait (1) seconds
Holds the program for a fixed length of time, whatever else is happening.
wait until <>
Holds the program until a condition becomes true — usually a sensor reading.

One wait for every sensor

Most sensors bring their own ready-made wait block, already coloured to match the sensor and with its comparison built in. They are all the same idea — hold here until this is true — and they live in the sensor’s own palette rather than in Control.

SensorBlockWaits until
Touch
[1 v] wait until [pressed v] :: sensors
the button is pressed. The dropdown also offers released and bumped.
Colour
[3 v] wait until color is [red v] :: sensors
the surface underneath is that one of the eight colours.
Ultrasonic
[4 v] wait until distance [< v] (15) [cm v] :: sensors
something is nearer than 15 cm. Flip the dropdown to > to wait for something to move away.
Gyro
[2 v] wait until angle [< v] (45) :: sensors
the robot has turned past that angle.
Brick buttons
wait until [center v] button is [pressed v] :: sensors
somebody presses that button on the Brick. No port — it is built in.
When there is no ready-made block

Some readings have no wait block of their own — reflected light, ambient light, the timer, and a motor’s degrees counted. For those, drop the matching boolean into the plain wait until from Control. It does exactly the same job:

wait until <[3 v] is reflected light intensity [< v] (30) %? :: sensors>
wait until <[3 v] is ambient light intensity [> v] (50) %? :: sensors>
wait until <(timer) > (5)>
wait until <([A v] degrees counted :: sensors) > (720)>

This is also the way to wait for two things at once, which no ready-made block can do — the sensor blocks each take one condition, but a boolean can be combined:

wait until <<[1 v] is pressed? :: sensors> or <(timer) > (5)>>

That one says “stop waiting when the button is pressed, or after five seconds, whichever comes first” — which is how you stop a wait hanging for ever when the thing you are waiting for never happens.

Guessing, or knowing

Two robots, the same job: drive up to the wall and stop. One waits two seconds; the other waits for the wall. Let it run several times — the interesting part is what happens on the second and third run.

wait for a length of time

start moving straight: 0
wait 2 seconds
stop moving

wait for a condition

start moving straight: 0
4 wait until distance < 15 cm
stop moving
60cm left · timed60cm left · sensed1run
Timed: 60 cm — a different answer againSensed: 15 cm, as asked
Both robots start driving towards the wall.
both stopped

Each orange dash is where a previous timed run finished. The sensing robot has never left a second mark, because it has never stopped anywhere else.

The timed robot is not being careless. Two seconds is a perfectly good guess, and on the first run it may look exactly right. But a second covers a different distance on a fresh battery, on a dusty floor, or with a heavier load, so the robot finishes somewhere new every run — sometimes short, sometimes into the wall. The sensing robot has never had to guess.

  • wait () seconds is a guess. You are betting that two seconds is long enough. On a fresh battery, on a smooth floor, it might be — and then it is not.
  • wait until is knowing. The robot carries on the moment the thing has actually happened, however long that takes.

Prefer waiting for a condition wherever a sensor can tell you. Keep timed waits for things with no sensor to check — letting a sound finish, or pausing so a person can watch.

Why it matters

A lift that waits three seconds for its doors is guessing; one that waits for the door sensor knows. The first eventually closes on somebody.

More control tutorials