You can build an autonomous obstacle-avoiding robot at home with a microcontroller, two geared motors, a motor driver board, an ultrasonic distance sensor, and a battery pack — typically assembled in an afternoon for the cost of a few takeout meals. The robot drives forward, measures the distance ahead several times a second, and turns away whenever that distance drops below a threshold you set in code. "Autonomous" here means the robot decides on its own, with no remote control and no connection to a phone or computer once it is running. That is a modest kind of autonomy — it reacts to what is directly in front of it rather than mapping a room — but it is the foundation that mobile robotics builds on, and it is genuinely achievable with hobby parts.
Table of Contents
- The parts list and what each one does
- Wiring and first tests, in order
- How the avoidance logic actually works
- Where ultrasonic sensing fails, and what to use instead
- Common failures and how to diagnose them
- Realistic next steps once it works
- Frequently Asked Questions
The parts list and what each one does
A minimum build has six pieces. A microcontroller board such as an Arduino Uno, Arduino Nano, ESP32, or Raspberry Pi Pico acts as the brain: it reads sensors and sets motor speeds. A motor driver sits between the brain and the motors because a microcontroller pin cannot supply the current a motor needs — the L298N module and the smaller, more efficient TB6612FNG and DRV8833 boards are common hobby choices. Two DC gearmotors with wheels provide drive, usually the yellow plastic-geared "TT motors" sold in robot kits.
A caster ball or a third free-spinning wheel keeps the chassis level, so the robot steers by driving its two wheels at different speeds — differential drive, the same principle as a tracked vehicle. The chassis itself can be a laser-cut acrylic kit, a sheet of plywood, or a 3D print. For sensing, the HC-SR04 ultrasonic module is the default starting point. It emits a short burst of sound above human hearing and times the echo's return; the controller converts that interval to distance using the speed of sound. Power comes from a battery pack — four to six AA cells, or a lithium pack with a protection circuit — and it is worth giving the motors and the logic board a shared ground but a generous supply, since motors dragging the voltage down is the most common cause of a board that keeps resetting mid-drive.
Wiring and first tests, in order
Build in stages and test each stage before adding the next. That discipline matters more than any single component choice, because a robot that fails only when fully assembled gives you almost no information about which part is wrong.
Mount the sensor facing forward and slightly above the floor line. Ultrasonic sensors have a cone of sensitivity roughly 15 degrees wide, so a sensor aimed too low reads the floor as an obstacle and a sensor aimed too high misses a chair leg entirely.
- Power the board alone and confirm it runs a blink program.
- Wire one motor through the driver and run it forward, then backward, at a fixed speed. Repeat for the second motor.
- Check that both motors spin the same direction when commanded forward; if not, swap that motor's two leads rather than rewriting code.
- Wire the ultrasonic sensor and print distance readings to a serial monitor while you move a book toward and away from it.
- Only then combine the two: drive forward, read distance, stop and turn when the reading goes below your threshold.
How the avoidance logic actually works
The simplest working behaviour is a loop: measure, decide, act. If the distance ahead exceeds your threshold, drive forward. If it does not, stop, reverse briefly, turn in place for a fixed interval, and resume. A threshold around 20 to 30 centimetres gives most hobby robots enough room to stop, because a geared motor does not halt instantly and a top-heavy chassis will keep rolling.
Two refinements make a large difference. First, filter your readings: take three measurements and use the median, which discards the occasional wild value an ultrasonic sensor returns when the echo scatters off an angled surface. Second, alternate or randomise turn direction, or the robot will trap itself turning the same way into a corner forever. A sensor mounted on a small servo lets one sensor sweep left, centre, and right, so the robot turns toward the most open direction instead of guessing. The trade-off is time — each sweep position needs a moment for the servo to settle and the echo to return — so a sweeping robot drives more slowly but gets stuck far less often.
Where ultrasonic sensing fails, and what to use instead
Ultrasonic sensors have specific blind spots that will frustrate you if you do not expect them. Soft or fabric surfaces absorb sound rather than reflecting it, so curtains, upholstered furniture, and a cat read as empty space. Surfaces angled sharply away from the sensor bounce the pulse sideways and never return it, which is why a robot can drive confidently into a wall it approaches at a steep angle. The alternatives each trade one weakness for another.
Infrared proximity sensors are cheap and fast but are fooled by dark or glossy surfaces and by bright sunlight. Time-of-flight laser sensors such as the VL53L0X family give a narrow, accurate beam, which is better on angled walls but worse at catching a wide obstacle slightly off-axis. Mechanical bumper switches are the crudest option and the most reliable backstop: a physical contact is never a false reading. Many builders end up combining two kinds — ultrasonic or laser for ranging, plus bump switches as a last resort. That layering is the practical version of what commercial robot vacuums do, and it is the single upgrade most likely to turn a demo into something that can run unattended for an hour.
Common failures and how to diagnose them
Erratic behaviour almost always traces back to power, grounding, or timing rather than to your logic. If the board resets whenever the motors start, the motors are pulling the supply voltage down; separate the motor supply from the logic supply while keeping grounds connected, or add a large capacitor across the motor supply.
If distance readings jump between a plausible number and a very large or zero value, check that the sensor's trigger and echo timing is not being interrupted by other code, and that nothing on the chassis is reflecting the pulse back immediately. A sensor mounted behind a protruding bolt or a cable will read a few centimetres forever.
- Robot drives in a curve when told to go straight: the motors differ slightly — trim one motor's speed value in code.
- Robot stops far from obstacles: the sensor is catching the floor or a chassis part; raise or re-aim it.
- Robot hits obstacles it saw: the threshold is too tight for the robot's stopping distance, or the motors are too fast.
- Robot works on a desk and fails on carpet: the drive wheels need more torque or the caster is dragging.
Realistic next steps once it works
Obstacle avoidance is a reactive behaviour, not navigation. The robot has no memory of where it has been, which means it will cover a room by chance rather than by plan. Adding wheel encoders — sensors that count wheel rotations — gives it a rough sense of how far it has travelled, which is the first ingredient of deliberate movement. From there the common paths diverge.
Line following adds a floor sensor and a fixed route. Remote monitoring is easiest on a Wi-Fi capable board like an ESP32, which can report its sensor readings to a browser. Mapping and localisation generally mean moving to a Raspberry Pi or similar single-board computer running ROS 2, the open-source Robot Operating System — a significant step up in complexity, and one worth taking only after the simple robot reliably survives a lap of your living room. Keep the first build simple enough that you can change one thing at a time. The value of this project is not the finished robot; it is that every subsequent robotics problem you meet will decompose into the same three parts — sense, decide, actuate — and you will have already debugged all three.
Frequently Asked Questions
Do I need to know how to program before starting?
Basic familiarity helps, but the complete behaviour is under fifty lines in the Arduino language, a simplified form of C++. Most builders learn it from the example sketches bundled with the Arduino IDE and adapt from there.
Can I build this without soldering?
Yes. Jumper wires, screw-terminal motor drivers, and pre-wired motors let you assemble everything with a screwdriver. Soldered connections survive vibration far better, so expect to redo loose joints if the robot runs for long stretches.
Will it work on carpet?
Only if the motors have enough torque and the chassis clears the pile. Small plastic gearmotors that move easily on hard floors often stall on thick carpet; larger wheels and a higher-ratio gearbox fix it.
How long does a battery pack last?
Expect tens of minutes rather than hours from AA cells, since the motors dominate consumption. A rechargeable lithium pack with a protection circuit is the usual upgrade once the novelty of replacing batteries wears off.
