Build an Obstacle-Avoiding Robot: Sense, Scan, and Steer

An obstacle-avoiding robot is the natural next build after a line follower. A line follower follows—it tracks a line someone drew for it. This robot decides: with no track and no map, it senses the space around it and chooses where to go. That one difference—reacting to the world instead of following it—is the first real taste of autonomy, and it is still simple enough to understand completely.

The core is a short, repeating loop: sense–scan–decide–turn. The HC-SR04 ultrasonic sensor pings forward and times the echo to estimate distance; when something is closer than a safety threshold, the robot stops, sweeps the sensor left and right on an SG90 servo, and turns toward the most open bearing. That threshold is not arbitrary — it is a safety distance built from current speed, sense-decide-actuate latency, braking distance (which grows with the square of speed), the robot’s radius and a margin, all visible as the stopping-distance curve in the simulator.

You add components a mobile robot needs and learn what each one does: an Arduino Uno for forgiving 5 V logic, the ultrasonic sensor and its blind zone (the minimum range below which it cannot report), the servo that gives the beam a second viewpoint, the L298N H-bridge that switches motor current the logic pins cannot provide, two TT gearmotors where the gearbox trades speed for usable torque, a 2WD chassis with a caster for differential steering, and a battery pack that must feed motor and logic on separate rails. The tech tree also carries you through two learning roadmaps — motor control and reactive navigation — so the same PWM, odometry and filtering ideas you met in the line follower return here in a navigation context.

Then — before spending anything or risking a miswire — tune the avoidance behaviour in the browser simulator until it navigates a cluttered space cleanly. The workspace there is top-down and two-dimensional with instant, noise-free rays; a real ultrasonic beam spreads about 15°, is blocked by the robot’s own body, and is disturbed by soft or angled surfaces, so you will filter readings and add a median filter and a short settle delay after the servo moves before trusting a distance on hardware. Finding a safe stopping distance and a clear-direction rule in simulation removes most of the guesswork before the robot ever moves.

Only then do you wire the real robot — trigger and echo to the correct voltage, servo signal to a PWM-capable pin, motor PWM and direction to the driver, motor battery to the driver’s VM pin only, every ground tied together — and let it roam a floor with boxes or chairs. The same sensing and filtering lessons lead directly into the Micromouse walled maze if you later want mapping, or into ROS 2 navigation if you add a Raspberry Pi.

Follow the tech tree below top to bottom. Each node opens once its prerequisites are done, and your progress is saved on this device, so you can build the robot over a weekend without losing your place.

Bill of materials

Total: roughly $30–40.

The two bump switches are the best forty cents on the robot, and they are the part most builds leave out. Every ranging sensor has surfaces it cannot see — a sonar is blind to curtains and to walls met at a steep angle — and a robot with no contact sensing will push a curtain until something gives. Two switches behind a wrapped bumper turn “usually avoids things” into “never gets stuck against something it could not see”.

How it all connects

Watch the timer conflict: the Servo library takes over Timer 1, which on an Uno drives PWM on pins 9 and 10. Put the motor PWM on 3, 5, 6 or 11 and the servo on any pin, and the problem never arises. Put a motor enable on pin 9 and its speed control will silently stop working the moment you attach a servo.

The stopping distance, computed rather than guessed

The stop threshold is the single most important number in this project, and it is not arbitrary. It is the sum of four distances:

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

Worked, for a robot at 0.3 m/s with 80 ms of latency and 1.0 m/s² of braking:

= (0.3 x 0.08) + (0.09 / 2.0) + 0.09 + 0.05
= 0.024 + 0.045 + 0.09 + 0.05 = 0.21 m

So about 21 cm. Now double the speed to 0.6 m/s:

= 0.048 + 0.18 + 0.09 + 0.05 = 0.37 m

The threshold has not doubled — it has grown by 76%, because the braking term goes with the square of speed. 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 number that makes the robot timid everywhere.

Build it in milestones

Milestone 10 is the one that separates a demo from a robot. A cushion absorbs the ultrasonic pulse entirely, so the sensor reports open space and the robot drives into it at full speed. Without a bump switch it then pushes until the motors stall.

Troubleshooting

Where to take it next

Add wall following. A robot that holds a fixed distance from a wall on one side traverses a room deterministically rather than wandering, and it is the first behaviour that starts to look like a plan. It is a small code change and a big conceptual one.

Add a second sensor type. A VL53L0X fails on almost exactly the opposite surfaces to the sonar — dark matte and mirrors, versus soft and angled. Together they cover far more of the room than either alone.

Accept the ceiling and move on. A reactive robot cannot be sent anywhere, cannot promise it covered the floor, and can loop in a horseshoe-shaped room forever. Those are properties of having no map, not bugs. When they start to matter, the micromouse adds mapping and planning, and the coverage robot tackles the “have I been everywhere?” question directly.