Close
0%
0%

Autonomous Gas Leak Detection Robot — ESP32 + Live

Wall-following robot that detects CO + LPG in real time, streams
live video via ESP-CAM, and serves its own web dashboard — built
in 24 hour

Public Chat
Similar projects worth following
What if a robot could patrol your lab or garage and alert you the moment a gas leak starts — before you even smell it?

We built exactly that in 24 hours at a hackathon. This autonomous gas leak detection robot uses two MQ9 sensors to detect CO and LPG simultaneously, navigates on its own using IR wall-following and ultrasonic obstacle avoidance, streams live video via ESP-CAM, and serves a full web dashboard — all running directly on the ESP32 with no cloud dependency.

▶ Full demo: https://www.youtube.com/watch?v=gHuSf0Qwavs

Key design decisions:
- MQ9 CO sensor runs on 3.3V (GPIO36/VP), MQ9 LPG runs on 5V (GPIO32) — different supply voltages are critical for accurate readings
- ESP-CAM connects over WiFi only — joins the ESP32's own hotspot and streams over HTTP, no serial wires
- Dual battery setup isolates motor noise from sensor supply rails — eliminates false gas readings on motor startup
- Entire dashboard (Auto mode + Manual joystick) served from the ESP32 itself on

What We Built in 24 Hours (And What Nearly Killed Us)

This entire project was designed, wired, coded, and tested in a single 24-hour hackathon session.

The first 2 hours were component triage — figuring out what we had and what was compatible. The live camera stream was a last-minute addition when someone grabbed an ESP-CAM from the parts bin at hour 6.

The biggest technical fight was the MQ9 sensor supply voltages. We had both sensors reading garbage for the first 3 hours. The CO sensor was on 5V — outputting saturated readings regardless of actual gas. Fix: CO sensor needs 3.3V, LPG sensor needs 5V. Once sorted, readings made sense.

The ESP-CAM integration was surprisingly smooth. Instead of a serial link, we made it join the ESP32's own WiFi AP and stream over HTTP. The dashboard embeds the stream URL as an image source. Simple and it works.

IR wall-following turned out far more reliable than expected. The bot ran 8+ minutes without collision in the test corridor.

Code: https://github.com/Nikhil-A-E/Gas-Leak-Detection-Bot
Video:

Key Wiring Decisions and Why We Made Them

A few wiring choices in this build aren't obvious from the schematic alone.

Why two batteries:
One 2S LiPo powers the motors through the L298N. A second powers all logic through the breadboard PSU. This isolates motor noise from sensor supply rails. Running everything from one battery caused ADC spikes every time a motor started — motor current draw dragged supply voltage down, showing up as false gas readings. Separate supplies fixed this completely.

Why GPIO15 as a power output:
GPIO15 is set HIGH in software at boot and stays there — it becomes a 3.3V source pin for sensors. It's a strapping pin that must be HIGH at boot anyway, so it's a natural choice. Sensors draw very little current, well within what the ESP32 can supply.

Why input-only pins for sensors:
GPIO34, 35, 36 (VP) have no internal pull resistors and cannot be outputs. This makes them ideal for analog sensor inputs — no accidental output state, no pull affecting the ADC reading.

What We're Adding Next

Power: Two 2S LiPo packs are clunky. A single 3S (11.1V) would feed the L298N directly and run the PSU from the same source — simpler wiring, more capacity.

Gas sensors: MQ-135 covers CO2, NH3, benzene, smoke, and alcohol in one package. Replacing both MQ9s simplifies wiring and broadens coverage. Tradeoff: less specificity about which gas triggered.

Mapping: The current dashboard map is dead reckoning from the MPU6050 yaw angle. It drifts badly. Real SLAM would make it actually useful for locating a leak source.

Logging: Nothing is persisted right now. SD card logging would store timestamped gas readings + position estimates even when WiFi is out of range — useful in industrial environments.

esp_code_final.ino

ino - 33.66 kB - 03/18/2026 at 17:04

Download

esp_code_cam_final.ino

ino - 4.73 kB - 03/18/2026 at 17:04

Download

  • 1 × ESP32 DevKit V1 Main controller — 30-pin
  • 1 × ESP32-CAM AI Thinker OV2640, WiFi stream only
  • 2 × MQ9 Gas Sensor Module CO on 3.3V, LPG on 5V
  • 2 × HC-SR04 Ultrasonic Sensor Front + rear obstacle detection
  • 2 × IR Sensor Module Left + right wall following

View all 12 components

  • What We're Adding Next

    blinknbuild2 days ago 0 comments

    Power: Two 2S LiPo packs are clunky. A single 3S (11.1V) would feed the L298N directly — simpler wiring, more capacity.

    Gas sensors: MQ-135 covers CO2, NH3, benzene, smoke, and alcohol in one package. Replacing both MQ9s simplifies wiring and broadens coverage.

    Mapping: Current dashboard map is dead reckoning from MPU6050 yaw — drifts badly over time. Real SLAM would make it useful for actually locating a leak source.

    Logging: Nothing is persisted right now. SD card logging would store timestamped readings even when WiFi is out of range.

  • Key Wiring Decisions and Why We Made Them

    blinknbuild2 days ago 0 comments

    Why two batteries: One 2S LiPo powers motors through L298N. A second powers all logic through the PSU module. Running everything from one battery caused ADC spikes every time a motor started — motor current dragged supply voltage down, showing up as false gas readings. Separate supplies fixed this completely.

    Why GPIO15 as a power output: GPIO15 is set HIGH in software at boot and stays there — becomes a 3.3V source pin for sensors. It's a strapping pin that must be HIGH at boot anyway, so it's a natural choice.

    Why input-only pins for sensors: GPIO34, 35, 36 (VP) have no internal pull resistors and can't be outputs. This makes them ideal for analog inputs — no accidental output state, no pull affecting ADC readings.

  • What We Built in 24 Hours (And What Nearly Killed Us)

    blinknbuild2 days ago 0 comments

    This entire project was designed, wired, coded, and tested in a single 24-hour hackathon session.

    The biggest technical fight was the MQ9 sensor supply voltages. Both sensors read garbage for the first 3 hours. The CO sensor was on 5V — outputting saturated readings regardless of actual gas. Fix: CO sensor needs 3.3V, LPG sensor needs 5V. Once sorted, everything made sense.

    The ESP-CAM integration was surprisingly smooth. Instead of a serial link, we made it join the ESP32's own WiFi AP and stream over HTTP. The dashboard embeds the stream URL as an image source. Simple and it works.

    IR wall-following ran 8+ minutes without collision in the test corridor.

    Code: https://github.com/Nikhil-A-E/Gas-Leak-Detection-Bot
    Video:

View all 3 project logs

  • 1
    Gather Components and Install Libraries

    Components needed: ESP32 DevKit V1, ESP32-CAM AI Thinker, 2x MQ9 Gas Sensor, 2x HC-SR04, 2x IR Sensor, L298N Motor Driver, 2x DC Gear Motor, Active Buzzer, MPU6050, 2x 2S LiPo, Breadboard PSU Module, Acrylic 2WD Chassis.

    Install in Arduino IDE: ESP32 Board Package (Espressif), MPU6050 by Electronic Cats. WiFi.h, WebServer.h, Wire.h are built-in.

  • 2
    Wire the Circuit

    Critical power rules — MQ9 CO → 3.3V only (GPIO36/VP). MQ9 LPG → 5V only (GPIO32). Swapping these voltages causes wrong readings.

    Key pin mapping: Buzzer→GPIO4, HC-SR04 Front TRIG/ECHO→GPIO5/18, Rear→GPIO19/21, IR Left→GPIO34, IR Right→GPIO35, L298N: ENA→GPIO12, IN1→GPIO14, IN2→GPIO27, IN3→GPIO26, IN4→GPIO25, ENB→GPIO33, MPU6050 SDA/SCL→GPIO23/22.

    ESP-CAM: dedicated 5V supply only — never from ESP32 3.3V pin.
    Remove ENA/ENB jumper caps on L298N before connecting PWM pins.

  • 3
    Flash ESP-CAM Then Main ESP32

    Flash ESP-CAM first using FTDI programmer: FTDI TX→U0R, RX→U0T, IO0→GND before powering. Board: AI Thinker ESP32-CAM, Partition: Huge APP 3MB.
    After flash: disconnect IO0 from GND, press RESET. Serial should show IP 192.168.4.2.

    Flash main ESP32 via USB-C. Board: ESP32 Dev Module, Partition: Default 4MB spiffs.
    After flash: connect phone to ESP32_BOT WiFi → open 192.168.4.1 → dashboard loads.

View all 4 instructions

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates