wall-following-robot

KO | EN

gitlite — search

#javascript #ai #typescript #golang #android #rust #deep-learning #docker #awesome #kubernetes #pytorch #mcp #ios #openai

wall-following-robot

(★ 10)

Autonomous wall following robot on Arduino Uno: ultrasonic corridor-centering with a PD controller, and IMU-measured turns

wall-following-robot 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Wall-Following Robot

An Arduino Uno robot that drives itself through a maze by keeping itself centered
between the corridor walls, counts the turns it makes along the way, and reports the
turn sequence to a PC over WiFi when it reaches the end.

The core of the firmware is a PD controller that holds the robot in the middle of the
corridor as it drives. Everything else handles the cases where centering alone isn't
enough: gaps that open up beside it, walls in front, dead ends, junctions, and the
finish.

![The cardboard test maze](https://raw.githubusercontent.com/HelanaNady/wall-following-robot/main/images/maze.jpg)

## Hardware

- **Arduino Uno** (ATmega328P)
- **L298N** driver with two geared DC motors, each with a 20-tick/rev wheel encoder
- **3× HC-SR04** ultrasonic sensors, mounted front / right / left
- **MPU6050** IMU for measuring turn angle
- **ESP-01** (ESP8266) for WiFi
- Start button and a status LED

Wheel diameter is 6 cm and the wheelbase is 12 cm. Those two numbers drive all the
distance and turn math in `Config.h`. The full pin map lives in one place,
`WallFollower/Pins.h`, so wiring and code never drift apart.

![System block diagram](https://raw.githubusercontent.com/HelanaNady/wall-following-robot/main/images/block_diagram.png)

The Arduino sits in the middle: it reads the three ultrasonic sensors and the two
encoders, drives the motors through the L298N, and talks to the ESP-01 over UART. The
wiring, down to the breadboard, is in the diagram below.

![Wiring diagram](https://raw.githubusercontent.com/HelanaNady/wall-following-robot/main/images/electric_diagram.png)

## Build and run

The project builds with PlatformIO:

```bash
pio run                 # compile
pio run -t upload       # flash the Uno
pio device monitor      # watch serial at 115200
```

Before the first run, set your network details in `WallFollower/Config.h`:
`WIFI_SSID`, `WIFI_PASS`, `SERVER_HOST` (the PC that receives the result), and
`SERVER_PORT`.

To start a run: power the robot, then press the button. It waits a few seconds to
arm and let the IMU settle, then takes off. Pressing the button again at any point
restarts the run cleanly.

## How it's put together

The `WallFollower/` directory is split into small modules, each owning one concern.

**`HwApi` (bare-metal AVR).** The motor, sensor, timing, and I2C code talk to the
ATmega328P registers directly instead of going through `pinMode` / `digitalWrite` /
`analogWrite`. Timer0 generates the motor PWM, Timer2 runs the millisecond clock,
Timer1 times the ultrasonic echo pulses, and the encoders use the INT0/INT1 edge
interrupts. The only place we still lean on the Arduino libraries is the MPU6050 DMP
driver and the `Serial` port used to talk to the ESP-01. Going register-level kept
the timing predictable and the binary small, which matters on a 32 KB part.

**Main loop.** `WallFollower.ino` runs a fixed 25 ms tick. Every tick it reads the
three sensors, updates the IMU yaw estimate, advances the state machine, and sets the
LED. A fixed period keeps the PD controller's timestep honest and makes the timing
constants in `Config.h` mean what they say.

**Sensors (`Ultrasonic`).** The three HC-SR04s are pinged one at a time, front then
right then left, with an 8 ms gap between them so the echo of one doesn't get picked
up as the echo of the next. Each sensor runs a median-of-3 filter followed by a light
exponential smoother, which throws out the occasional wild reading these sensors love
to produce. A reading that times out once is treated as stale. Time out twice in a row
and we take it at face value as open space rather than a glitch.

**Steering (`WallFollow`).** A PD controller keeps the robot centered between the two
walls of the corridor, balancing the gap on the left against the gap on the right. When
a wall drops away on one side it falls back to holding a fixed distance from the wall
that's left, at 14.5 cm, so it keeps a steady line until the corridor closes back in.
The derivative term is smoothed so a single noisy distance reading can't jerk the
steering, and the PWM output is slew-limited so the motors ramp instead of snapping. As
the front sensor closes in on an obstacle, the base speed tapers down so the robot isn't
flat-out when it needs to decide what to do.

**Navigation (`Fsm`, `TurnDetect`).** A state machine handles everything the plain
PD loop can't. It drives the corridor until something interesting shows up: a gap
opening up beside it to turn into, a wall in front to turn away from, a dead end to
reverse out of, or the finish. `TurnDetect` is what decides those events are real. Every
trigger is debounced over time and most use hysteresis (a gap has to open past one
threshold and only counts as closed once it shrinks back past a tighter one) so the
robot doesn't oscillate on a borderline reading. There's also a "prior wall" flag: the
robot only commits to an opening if it had a wall to track just beforehand, which stops
it from turning off into open space it was never driving along.

Each completed turn appends `L`, `R`, or `U` to a sequence (`Sequence`), and that's
what gets reported at the finish.

The diagram below is the high-level view of that logic: drive straight, branch off to a
turn when a path opens or the front blocks, and drop into finish when every side reads
open or every side reads walled. The firmware splits these into more states than shown
(separate backup, cooldown, and recovery steps), but the shape is the same.

![Navigation state machine](https://raw.githubusercontent.com/HelanaNady/wall-following-robot/main/images/state_diagram.png)

**Turning (`Imu`).** Each turn is measured by angle. The MPU6050's on-chip DMP gives a
yaw reading that the firmware unwraps and accumulates, and the turn states drive the
motors until the angle target is hit. If the DMP never comes up (bad wiring, a clone
chip), the IMU module falls back to integrating the raw gyro, and if even that fails the
turn falls back again to counting encoder ticks for the arc length of a 90° pivot. Each
level is less accurate than the one above it, but a turn still completes even if the IMU
never works.

**Reporting (`Comm`).** At the finish the robot brings up the ESP-01 with plain AT
commands over the serial line, joins WiFi, opens a TCP connection to your PC, and sends
the turn count and sequence as text. If WiFi won't come up it falls back to printing
the same result repeatedly over the UART, so you can still read it off a serial monitor.

**Safety nets.** A stall watchdog watches the encoders: if the motors are commanded to
move but no ticks come in for 700 ms, something is jammed and the robot drops into an
error state, backs up, and tries again. After a couple of failed recoveries with every
sensor reading blocked, it decides it's physically stuck and stops for good rather than
grinding the motors.

## Tuning

Most of the behaviour lives in `CONFIG_TUNABLES` in `Config.h`: speeds, the PD gains,
distance thresholds, and the debounce windows. They're defined through an X-macro so the
same list produces both the compiled-in constants and the names the debug tool uses to
read and write them live. Edit a value and reflash, or change it live from the debug
tool. The motor trim values
(`LEFT_MOTOR_TRIM` and friends) correct for one motor being stronger than the other so
the robot drives straight.

wall-following-robot

wall-following-robot 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

wall-following-robot

wall-following-robot 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README