Obstacle Avoidance Simulator for Mobile Robots

Controls

The workspace includes movable obstacles, robot speed, sensing range, field of view, measurement noise, and a safety-distance threshold. Sensor rays and predicted stopping distance stay visible. Step mode reveals exactly which observation caused each steering decision.

Theory

A robot must stop or turn before its swept footprint intersects an obstacle. Safe distance depends on current velocity, controller latency, braking capability, measurement uncertainty, and the robot’s physical radius—not just the latest range value.

Reactive controllers such as potential fields turn nearby obstacles into repulsive vectors and the goal into an attractive vector. They respond quickly but can become trapped in local minima. A practical stack pairs reactive safety with a global or local planner.

Algorithm

1. Reject stale and physically impossible range samples.
2. Transform valid observations into the robot coordinate frame.
3. Expand each obstacle by the robot radius plus a safety margin.
4. Compute stopping distance from velocity and estimated deceleration.
5. Stop when the forward corridor is unsafe; otherwise steer toward the clearest goal-aligned sector.
6. Limit acceleration and angular velocity before sending motor commands.

Source code

Keep the emergency decision small enough to test exhaustively:

def safe_velocity(target, ranges, stop_distance):
    front = [r for angle, r in ranges if abs(angle) < 0.35]
    if not front or min(front) <= stop_distance:
        return 0.0, choose_clear_turn(ranges)
    return limit_acceleration(target), steer_toward_clearance(ranges)

In a real system, record sensor timestamps and enter a safe stopped state when required data becomes unavailable.

Assumptions and hardware differences

The world is top-down and two-dimensional: sensor rays are instant, perfectly thin, and never occluded by the robot’s own body, and the robot is a disk that can brake to zero without momentum. On a Raspberry Pi robot, ultrasonic beams spread 15°, time-of-flight readings depend on surface and sun, and stopping distance is set by real mass, motor torque and sense-decide-actuate latency — all covered in the reactive navigation roadmap. The simulator also ignores loop jitter and power sag, so treat the stopping-distance curve as the shape to internalise, not a number to copy.

Circuit diagram

Level-shift any 5 V echo signal before it reaches Raspberry Pi GPIO. Power motors separately and connect grounds at a deliberate common point.

Guided experiments

1. Derive the stop threshold instead of guessing it

Set a low speed and lower the stop threshold until the robot starts clipping obstacles. Note the value. Now double the speed and repeat.

The threshold you need does not double, because it is the sum of a term that scales with speed and one that scales with its square:

stop_distance = (v x t_latency) + (v^2 / (2 x a_brake)) + robot_radius + margin

This is why a robot that avoids reliably at walking pace starts hitting things when you speed it up — and why the fix is a speed-dependent threshold rather than one large fixed value that makes the robot timid everywhere.

2. Produce the threshold stutter, then fix it

Park the robot so it hovers right at the stop distance. With a single threshold it flips between driving and turning many times a second.

Now separate the two: stop at 20 cm, and do not resume until 30 cm. The stutter disappears because the behaviour has to commit. That gap is hysteresis, and the same pattern fixes almost every threshold-driven oscillation in robot code.

3. Trap it deliberately

Build a concave corner — a horseshoe — and let the robot drive in. With a deterministic “turn toward the most open direction” rule it will turn, drive, and arrive back where it started, forever.

This is not a bug to fix. It is what having no map means, and it is the clearest possible demonstration of the ceiling of reactive navigation. The mitigations are a random component in the turn and a stuck-detector that escalates after several failed attempts; the actual fix is memory, which is a different path entirely.

4. Compare scan resolution against scan time

Increase the number of scan angles and watch two things move in opposite directions: the turn decisions get better, and the robot spends longer standing still.

A scan is a blind moment — the robot is stopped and making no progress. Three to five angles is the usual sweet spot, and past that the extra information rarely justifies the extra time.

What you should observe

Taking it to hardware

The simulator’s rays are instant, noise-free, and infinitely thin. A real ultrasonic sensor is none of those, and the differences are the whole of the work on hardware:

Find a safe stopping distance and a clear-direction rule here, where a mistake costs nothing. Then on hardware, add the median filter, the servo settle delay, and the contact sensing — the avoidance algorithm tutorial has each in code.