Obstacle-Avoiding Rover.

Project Overview

A rover that drives itself around a room, sensing obstacles ahead and steering toward the clearest path — reactive autonomy without a map.

The simplest form of free-roaming autonomy is not to plan a route but to react: drive forward, and whenever something is in the way, turn toward the clearer side. An obstacle-avoiding rover does exactly that — it wanders a space on its own, using a distance sensor to detect what is ahead and steering around it — and in doing so it demonstrates the foundation of mobile robotics: sense the world, decide, and act, in a tight loop, fast enough to stay out of trouble. No map, no localisation; just continuous reaction to what the sensors see right now.

The rover measures distance ahead with an ultrasonic (or time-of-flight) sensor, usually mounted on a small servo so it can look left and right as well as straight ahead. The behaviour is a state machine: while the path ahead is clear, drive forward; when an obstacle comes within a threshold, stop, scan left and right to compare clearances, and turn toward the more open direction before resuming. This "sense–scan–steer" reaction, repeated many times a second, lets the rover thread its way around furniture, walls and people without ever knowing where it is.

It is the ideal first mobile robot because it teaches the whole reactive-autonomy loop honestly and cheaply, and its limits are as instructive as its behaviour: a purely reactive rover can get stuck in corners or oscillate between two obstacles (it has no memory or plan), ultrasonic sensing has blind spots and struggles with soft or angled surfaces, and it avoids obstacles rather than navigating to a goal. Real autonomous robots add mapping, localisation and path planning on top. But as a self-driving, obstacle-avoiding rover built on differential drive and a scanning distance sensor, it is both a satisfying autonomous machine and the clearest introduction to the sense–decide–act loop at the heart of all robotics.

What this project does

• Drives itself around a space avoiding obstacles
• Measures distance ahead with an ultrasonic/ToF sensor
• Scans left/right (servo) to compare clearances
• Steers toward the more open direction
• Runs a fast sense–decide–act reaction loop
• Needs no map or localisation (reactive autonomy)
• Demonstrates the foundation of mobile robotics

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• Ultrasonic distance sensing (scanning)
• Reactive obstacle-avoidance state machine
• Differential-drive steering
• Stuck/oscillation handling (basic)
• Adjustable stop distance and turn behaviour
• Cheap, robust first autonomous robot
• Honest about the limits of purely reactive navigation

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• Ultrasonic/ToF distance sensing (and scanning with a servo)
• Reactive state-machine behaviour design
• Differential-drive steering
• Handling reactive failure modes (stuck/oscillation)
• Sensor–actuator loop timing

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹2,940, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 496 mA. With a 1.5× design margin the supply should deliver at least 800 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x (AVR core 1.8.6). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Select Tools → Board → Arduino AVR Boards and the matching board. Clone boards with a CH340 USB bridge need the CH340 driver on Windows and macOS.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Mount the ultrasonic sensor on the scan servo at the front, level and looking ahead.
• Wire the two motors through an H-bridge; ENA/ENB take PWM for speed.
• Keep the sensor clear of the chassis so it does not see the robot itself.
• Power motors and logic sensibly with a common ground.
• Balance the rover so it does not tip when it stops/turns quickly.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

There are two ways to make a robot move through a space without hitting things: plan a route (which needs a map and localisation) or react to what is immediately sensed. Reactive navigation is the simpler and older idea, and it is remarkably capable: a robot that simply drives forward and turns away from whatever is close can explore a cluttered room indefinitely without ever knowing where it is. This rover is the canonical reactive robot, and its value is that it demonstrates the sense–decide–act loop — the beating heart of all robotics — in its purest, most visible form.

The sense stage measures the world with a distance sensor. An ultrasonic sensor emits a pulse and times its echo to gauge how far away the nearest surface ahead is; a time-of-flight laser does the same with light. Crucially, one forward reading is not enough to choose a direction, so the sensor is usually mounted on a servo that pans it left and right — letting the rover build a coarse picture of where the space is open. This scanning is what turns blind "something ahead" detection into a decision between alternatives.

The decide stage is a small state machine. While the forward distance exceeds a threshold, the decision is trivial: keep driving. When an obstacle comes within the threshold, the rover stops, scans left and right, compares the clearances, and decides to turn toward the more open side. If both sides are blocked, it backs up and turns — a recovery from a dead end. The whole intelligence is a few rules over the sensed distances, and its elegance is that complex-looking wandering emerges from simple reactions. The act stage executes the decision through differential drive: forward when clear, a pivot toward the open side when not, exactly as in any two-wheeled robot.

What makes this an honest teaching robot is that its limitations are as clear as its behaviour, and they motivate everything more advanced. Because it is purely reactive — no map, no memory, no goal — it can get stuck in a corner or oscillate between two obstacles, repeating the same reaction forever; basic recovery (back up, turn a random extra amount) mitigates but does not solve this, because the real fix is memory and planning. Ultrasonic sensing has its own honest flaws: blind spots, poor returns from soft or steeply angled surfaces, and a wide beam that blurs fine detail. And fundamentally it avoids obstacles rather than navigating to a goal — going somewhere specific needs localisation and path planning layered on top. Those limits are precisely why real autonomous robots add mapping (SLAM) and planning. But as a first robot, the obstacle-avoiding rover delivers the essential lesson intact: a fast, tight sense–decide–act loop is enough to produce genuine autonomous behaviour, and everything else in mobile robotics is built on that foundation.

The maths behind it

Ultrasonic distance

distance = (echo_time × speed_of_sound) / 2

  ≈ echo_time_µs / 58   → distance in cm

(÷2 because the pulse travels out AND back.)

Reactive decision

if forward > D_stop:            drive forward
else:
  scan left, right
  if max(left, right) > D_stop: turn toward the more open side
  else:                        back up, then turn (dead end)

Complex wandering emerges from these few rules.

Loop-rate vs stopping

To stop before hitting an obstacle:

  D_stop  >  v × (t_loop + t_react)

The faster the rover, the larger the stop distance and the
faster the loop must run. Reactive safety = fast loop.

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Build the rover and scanner

   Assemble the differential-drive chassis, mount the H-bridge and battery, and put the ultrasonic sensor on the scan servo at the front, level and clear of the body.

2. Verify sensing and drive

   Confirm the distance readings are sane across the range and that the rover drives straight and pivots cleanly.

3. Tune the avoidance behaviour

   Set the stop distance for the speed, tune scan angles/turn amounts, and add stuck/oscillation recovery.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Sense, scan and decide

   Drive forward while clear; when an obstacle is within the stop distance, scan left and right and turn toward the more open side (or back up if both are blocked).

   cppavoid.ino Copy Download

   #include <Servo.h>
   Servo scan;
   const int D_STOP = 25;                 // cm
   
   long ping();                           // HC-SR04 distance ahead
   
   long look(int angle){                  // pan sensor, then measure
     scan.write(angle); delay(180);
     long d = ping(); scan.write(90);     // recentre
     return d;
   }
   
   void loop(){
     long ahead = ping();
     if (ahead > D_STOP){ drive(FWD, FWD); return; }   // clear: cruise
   
     drive(0,0);                          // obstacle: stop
     long left  = look(150);
     long right = look(30);
   
     if (left < D_STOP && right < D_STOP){
       drive(REV, REV); delay(300);       // dead end: back up
       pivot(random(0,2) ? LEFT : RIGHT); // turn away
     } else if (left > right){
       pivot(LEFT);                       // steer to the more open side
     } else {
       pivot(RIGHT);
     }
   }

   if (ahead > D_STOP){ drive(FWD, FWD); return; } // clear: cruiseWhile the path ahead is clear the decision is trivial — keep driving. Most of the loop is this fast forward cruise.

   long left = look(150); long right = look(30);When blocked, the sensor pans to compare left and right clearances — turning blind detection into a choice between directions.

   if (left < D_STOP && right < D_STOP){If both sides are blocked the rover recognises a dead end and backs up before turning — basic recovery from getting boxed in.

   pivot(LEFT); // steer to the more open sideThe core reaction: turn toward the more open side. Complex wandering emerges from this simple rule.

2. Handle stuck/oscillation and keep the loop fast

   Add recovery for getting stuck or oscillating (e.g. a random extra turn, or backing up further after repeated blocks), and keep the loop fast enough to stop in time.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

/* ═══════════════════════════════════════════════════════════════
   Obstacle-Avoiding Rover

   Reactive autonomy: drive forward while clear; when blocked, scan
   left/right and steer toward the more open side; back up from dead
   ends. A fast sense-decide-act loop — the foundation of mobile
   robotics — with honest handling of stuck/oscillation.
   ══════════════════════════════════════════════════════════════════ */

#include <Servo.h>
Servo scan;
const int D_STOP = 25, TRIG=9, ECHO=10;
int blockedStreak = 0;                  // detect being stuck

long ping(){
  digitalWrite(TRIG,LOW); delayMicroseconds(2);
  digitalWrite(TRIG,HIGH); delayMicroseconds(10); digitalWrite(TRIG,LOW);
  long us = pulseIn(ECHO, HIGH, 30000);
  return us ? us/58 : 400;              // cm; 400 = nothing in range
}
long look(int a){ scan.write(a); delay(180); long d=ping(); scan.write(90); return d; }

void drive(int l,int r){ setMotor(LEFT,l); setMotor(RIGHT,r); }
void pivot(int dir){ dir==LEFT ? drive(-180,180) : drive(180,-180); delay(300); }

void setup(){ scan.attach(11); scan.write(90); motorInit(); }

void loop(){
  long ahead = ping();

  if (ahead > D_STOP){                  // clear: cruise
    drive(200,200); blockedStreak=0; return;
  }

  drive(0,0);                           // obstacle: stop and scan
  long left = look(150), right = look(30);
  blockedStreak++;

  if (left < D_STOP && right < D_STOP){ // dead end
    drive(-200,-200); delay(400);       // back up
    pivot(random(0,2)?LEFT:RIGHT);
  } else {
    pivot(left > right ? LEFT : RIGHT); // toward the more open side
  }

  if (blockedStreak > 4){               // stuck/oscillating -> break out
    drive(-200,-200); delay(500);
    pivot(random(0,2)?LEFT:RIGHT);
    for (int i=0;i<3;i++) pivot(left>right?LEFT:RIGHT);
    blockedStreak = 0;
  }
}

Configuration & Calibration

Configuration steps

• Configure the stop distance for the rover's speed.
• Configure scan angles and turn/pivot amounts.
• Configure dead-end and stuck/oscillation recovery.
• Configure loop timing so it can stop before collision.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. Distance sensing

   Verify readings are accurate and sensible across the range; check for blind spots and false returns.

2. Stop distance vs speed

   Set the stop distance so the rover halts before contact at its cruise speed; slow down if it clips obstacles.

3. Turn amounts

   Tune pivot durations so turns are decisive but not excessive.

Mechanical Assembly & Motion

Mechanical assembly

• Two-wheel differential-drive chassis with a castor, an H-bridge driver and battery.
• A scan servo at the front carries the ultrasonic sensor, mounted level and clear of the chassis.
• Low centre of mass so the rover does not tip when it stops or pivots quickly.

Motion logic

Motion is differential drive: forward with equal wheel speeds, and turns by pivoting (one wheel forward, one back or stopped) toward the open side.

The rover alternates between a fast forward "cruise" while clear and discrete stop–scan–turn manoeuvres when blocked, rather than steering continuously like a line follower.

Sensor integration

• Ultrasonic (or ToF) distance sensor on a scan servo: forward distance plus left/right clearances.
• Optional side/rear sensors or bump switches for blind-spot and contact backup.

Actuator explanation

Two geared DC motors via an H-bridge, PWM-controlled, providing forward drive and pivots.

A servo pans the distance sensor to scan left and right so the rover can choose the more open direction.

Kinematics

The rover uses the same differential-drive relations as any two-wheeled robot; here the turn is usually a discrete pivot rather than a continuous arc.

v     = (v_R + v_L)/2      # forward speed
omega = (v_R − v_L)/L      # turn rate

Pivot to open side:
  turn right:  v_L = +s, v_R = −s   (spin in place)
  turn left:   v_L = −s, v_R = +s

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

A rover that explores a space on its own, avoiding obstacles by scanning and steering toward open space.

ahead: 22 cm  (< stop)
scan  left: 60 cm   right: 18 cm
decision: LEFT is clearer -> pivot left
state: AVOIDING -> resume cruise

The rover found the left side far clearer than the right and pivoted left — the sense–decide–act loop making a visible choice.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Keep the loop fast and the stop distance matched to speed.
• Scan left/right to choose a direction, not just detect ahead.
• Add dead-end and stuck/oscillation recovery for a memoryless robot.
• Note ultrasonic blind spots; add sensors/margin where needed.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Wrap constant strings in F("...") so they stay in flash — an Uno only has 2 KB of SRAM.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• Profile before optimising — print micros() deltas around each stage and fix the slowest one first.

Safety Precautions

• Keep speeds modest; a fast reactive rover can hit people or fall off edges.
• Add an edge/cliff or bump backup if operating near drops or fragile objects.
• Purely reactive avoidance is not a safety guarantee — do not rely on it where a collision could cause harm.
• Secure the battery and wiring so nothing snags during quick turns.
• Lithium cells vent and burn when abused. Only use protected cells or a proper BMS, never charge below 0 °C, and never leave a charging pack unattended on a wooden desk.
• Moving parts pinch. Keep fingers, cables and hair out of gear trains and wheels, and always test motion with the drivetrain unloaded and the robot on blocks first.
• Motors are inductive — always fit a flyback diode across a DC coil, or use a driver that already has one, or the back-EMF spike will destroy your GPIO.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Keep the sensor clean and correctly aimed; re-check after knocks.
• Check wheels/motors for wear that causes drift.
• Re-tune stop distance/turns if speed, battery or surface changes.
• Verify the servo scan still sweeps freely.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Log pack voltage. When resting voltage after a full charge drops below about 4.0 V, the cell is near end of life — replace it.
• Listen for gear chatter. A servo that buzzes at rest is either stripped or fighting a mechanical bind — fix it before it burns out.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add wheel encoders and odometry toward mapping.
• Add multiple/side sensors or a ToF array for fewer blind spots.
• Add SLAM and path planning to navigate to a goal, not just avoid.
• Layer behaviours (wander, seek light, follow) on the reactive base.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add connectivity — an ESP32 and an MQTT publish turn a local gadget into something you can graph, alert on and analyse over months.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Mobile robotReference
2. Obstacle avoidanceReference
3. Behavior-based roboticsReference
4. Ultrasonic ranging (HC-SR04)Reference
5. Differential wheeled robotReference