Build a mini robotBeginnerLesson 2675 min read

Avoiding obstacles

Use the distance sensor to wander around a room full of obstacles without touching any. Learn simple avoidance rules, why robots get stuck, and how to test fairly.

✦ Ask the tutor 🧪 Lab · 25 min 📝 Lesson test

Speed

Lesson in motion

In 60 seconds

Avoiding obstacles

Use the distance sensor to wander around a room full of obstacles without touching any. Learn simple avoidance rules, why robots get stuck, and how to test fairly.

1/6

In simple words

Think of a goat walking through a village lane. It walks forward until something is in the way: a bicycle, a cart, a person. Then it turns and tries another way. It does not need a map of the whole village. A simple obstacle-avoiding robot works the same way: go forward, and when something is close, turn.

Robot vacuum cleaners, toy robots and many student robots use reactive obstacle avoidance. They do not plan a full route. They react to what the sensors say right now. This is simple and often good enough to explore a room without crashing.

The basic rule

1
Look
Read the distance straight ahead.
2
Far enough?
If nothing is closer than a safe distance (for example 30 cm), drive forward.
3
Too close?
Stop driving forward, and turn on the spot until the path ahead is clear.
4
Repeat
Check again every step.

Choosing the safe distance

The safe distance must be bigger than the distance the robot needs to stop and turn. It depends on speed, the size of the robot and how fast the sensor reacts. In our simulator the distance is measured from the middle of the robot, which is 5 cm from its edge, so a safe distance of 30 cm leaves a gap of about 25 cm.

Safe distance	What happens
Too small (for example 8 cm)	The robot starts turning when it is already touching the obstacle
About right	The robot turns away with room to spare
Too large (for example 90 cm)	The robot turns all the time and never explores narrow spaces

Ways robots get stuck

Always turning the same way can trap the robot in a corner, turning back and forth between two walls. Some robots pick a random direction, or turn the other way if the first turn did not work.
The sensor only looks ahead. While turning, the side of the robot can scrape an obstacle the sensor never saw. The cone of the sensor helps a little; side sensors help more.
Spinning forever. If the robot turns on the spot whenever anything is within the safe distance, and it is in a very tight space, it may spin without ever moving. Measure progress, not just "no crash".

Testing fairly

A robot that works from one starting point may be lucky. Test from several starting points and headings, and measure more than one thing: did it crash, how long did it survive, and how far did it actually travel? A robot that stands still never crashes, but it is not useful.

Weak test

One start, one run
Only checks "did not crash"
Obstacles moved until it works

Stronger test

Several starts and headings
Checks no crash and distance travelled
Same obstacle layout for every version of the code

Danger

A real robot that fails to stop can hit feet, pets or table legs, or drive off a table or down stairs. Test on the floor, in a clear area, at low speed, with an adult nearby for younger learners. Keep long hair, loose sleeves and fingers away from spinning wheels. Keep a way to switch off power quickly.

Try this. In the lab, change the turn to always go left, then always right. Does the robot get stuck in a different place? What does that tell you about testing from only one start?

Watch and read more

Lab

An obstacle-avoiding robot that explores a cluttered room for 500 steps from several starts, never crashes, and keeps moving.

~25 min

The problem

This runs in your browser. The room has five round obstacles (red). The robot starts near a corner.

Run the starter. The robot drives straight into an obstacle.
Change decide so that when s["distance"] is below a safe distance, the robot turns on the spot, and otherwise it drives forward.
Goal: for 500 steps, no crash, and the robot travels at least 300 cm. The check tries four different starts.
Try safe distances of 10, 30 and 80 cm. Write down what happens with each.

Practice lab

Edit the code and run it. Python runs in your browser — nothing is sent to our server.

Ctrl + Enter to run

import numpy as np
# ---------- Mini robot simulator (the same in every lab; you do not need to change it) ----------
ARENA, BASE, VMAX, DT = 200.0, 10.0, 20.0, 0.1   # arena cm, wheel gap cm, top speed cm/s, seconds per step
def line_y(x):                                   # black tape on the floor: straight, then a wave
    return 100 + 25 * (1 - np.cos((np.asarray(x) - 20) / 25))
def hit(px, py, obstacles, r):                   # True where a point (plus radius r) touches a wall or obstacle
    bad = (px < r) | (px > ARENA - r) | (py < r) | (py > ARENA - r)
    for ox, oy, orad in obstacles:
        bad = bad | (np.hypot(px - ox, py - oy) < orad + r)
    return bad
def read_sensors(x, y, th, obstacles):
    s, c, n = {"x": x, "y": y, "heading": th}, np.cos(th), np.sin(th)
    for name, side in (("left", 2), ("right", -2)):  # two IR line sensors, 6 cm ahead, 4 cm apart
        s[name] = int(abs(y + 6 * n + side * c - line_y(x + 6 * c - side * n)) < 3)  # 1 = sees tape
    s["offset"] = float(y + 6 * n - line_y(x + 6 * c))  # line-position sensor: cm left (+) or right (-) of tape
    d = np.arange(0, 100.0)                          # ultrasonic sensor: 3 rays in a narrow cone, max 100 cm
    ends = [d[hit(x + d * np.cos(th + a), y + d * np.sin(th + a), obstacles, 0)] for a in (-0.2, 0, 0.2)]
    s["distance"] = float(min([e[0] if len(e) else 100.0 for e in ends]))
    return s
def simulate(decide, start=(20, 100, 0.0), steps=300, obstacles=()):
    x, y, th = start
    path, crashed = [(x, y)], False
    for t in range(steps):
        s = read_sensors(x, y, th, obstacles)
        s["step"] = t
        left, right = np.clip(decide(s), -1, 1) * VMAX   # wheel speeds: -1 full back ... 1 full forward
        th += (right - left) / BASE * DT
        x, y = x + (left + right) / 2 * np.cos(th) * DT, y + (left + right) / 2 * np.sin(th) * DT
        path.append((x, y))
        if hit(x, y, obstacles, 5):                    # the robot is a circle with radius 5 cm
            crashed = True
            break
    return np.array(path), crashed
def show(path, obstacles=(), line=False):          # draw the arena and the path
    import matplotlib.pyplot as plt
    ax = plt.figure(figsize=(4, 4)).gca()
    if line: ax.plot(np.arange(20, 190), line_y(np.arange(20, 190)), "k", lw=5, alpha=0.3)
    for ox, oy, orad in obstacles: ax.add_patch(plt.Circle((ox, oy), orad, color="tab:red"))
    ax.plot(path[:, 0], path[:, 1], "b-", path[-1, 0], path[-1, 1], "bo")
    ax.set_xlim(0, ARENA); ax.set_ylim(0, ARENA); ax.set_aspect("equal"); plt.show()
# -------------------------------------------------------------------------------------------------

OBSTACLES = [(100, 100, 15), (60, 150, 12), (150, 50, 12), (150, 150, 12), (50, 60, 10)]

def decide(s):
    # s["distance"]: cm to the nearest thing ahead (walls and obstacles), max 100
    return 0.6, 0.6                   # TODO: when something is close, turn; otherwise drive

path, crashed = simulate(decide, start=(20, 20, np.pi / 4), steps=500, obstacles=OBSTACLES)
travel = np.hypot(*np.diff(path, axis=0).T).sum()
print(f"crashed={crashed}, steps survived={len(path) - 1}, distance travelled={travel:.0f} cm")
show(path, OBSTACLES)

Output

No output. Add print(...) to see values.

You are done when

No crash in 500 steps from all four starts
The robot travels at least 300 cm, so it is exploring, not spinning
The notes compare three safe distances and explain what went wrong with the extremes
The learner can explain why the check uses several starts

Hard questions

Try to answer before you reveal. If you can answer these, you understood the lesson.

Q1Your robot passes all four starts. Someone moves one obstacle 10 cm and it crashes. What does this tell you, and what would you do?Reveal

The rules were tuned to one layout and are fragile. Test on many layouts, including new ones you did not tune for, before you trust the code. Then make the rules more robust: a bigger safe distance, backing up before turning, or turning away from the side where the obstacle is closer, if you add side sensors.

Q2Why is "survived 500 steps without crashing" not enough to call a real robot safe?Reveal

The test only covers the situations it tried. Real rooms have moving people, pets, stairs, thin legs and soft objects that the sensor may not see. Safety needs slow speeds, a quick way to cut power, supervision, and testing in the real place, not only in a simulator.

Please sign in to continue.

Questions people ask

Is reactive avoidance enough for a real delivery robot?

No. Real delivery and warehouse robots also use maps, planned routes, several kinds of sensors and strict safety systems. Reactive rules are a good first layer and a good way to learn, but they cannot plan a route to a goal on their own.

Should the robot back up before turning?

If the obstacle is very close, backing up a little first gives room to turn without scraping it. Many simple robots do "stop, back up briefly, turn, go". Add it if your robot gets too close before it reacts.

Why measure distance travelled?

Because "no crash" alone is easy to fake: a robot that just spins on the spot never crashes. Distance travelled shows the robot is actually exploring.

What about obstacles that move, like people?

Moving obstacles are much harder. The robot must react faster and leave bigger gaps. Small hobby robots should move slowly around people, and never be used where they could trip someone.

Lesson test

5 questions. Get 3 right (60%) to pass and complete this lesson.

Avoiding obstacles

Avoiding obstacles

The basic rule

Look

Far enough?

Too close?

Repeat

Choosing the safe distance

Ways robots get stuck

Testing fairly

Watch and read more

The problem

Practice lab

You are done when

Hard questions

Questions people ask