Obstaclear- Obstacle avoidance vehicle pptx

sdf

1. ObstaClear: Wi-Fi Enabled Obstacle-Avoider Vehicle
with Live Dashboard (ESP32 + Dual Ultrasonic)

Submitted By

Student Name Student ID
Nazmul Huda Badhon 221-15-4772
Md. Abrar Awal Procchod 221-15-5912
Md. Saiful Islam 221-15-5463
Md. Abu Sayed 221-15-5908
Md. Tomal Ahmed Sajib 221-15-5406



MINI LAB PROJECT REPORT
This Report Presented in Partial Fulfillment of the course CSE234:
Embedded Systems and IoT Lab in the Computer Science and
Engineering Department





DAFFODIL INTERNATIONAL UNIVERSITY
Dhaka, Bangladesh
August 22, 2025

2. DECLARATION
We hereby declare that this lab project has been done by us under the supervision of MD
Moniruzzaman Hemal, Lecturer, Department of Computer Science and Engineering, Daffodil
International University. We also declare that neither this project nor any part of this project has been
submitted elsewhere as lab projects.

Submitted To:

MD Moniruzzaman Hemal
Lecturer
Department of Computer Science and Engineering Daffodil
International University

Submitted by




Nazmul Huda Badhon
ID: 221-15-4772
Dept. of CSE, DIU



Md Abrar Awal Procchod
ID: 221-15-5912
Dept. of CSE, DIU



Md Saiful Islam
ID: 221-15-5463
Dept. of CSE, DIU



Md Abu Sayed
ID: 221-15-5908
Dept. of CSE, DIU



Md Tomal Ahmed Sajib
ID: 221-15-5406
Dept. of CSE, DIU

3. COURSE & PROGRAM OUTCOME


The following course have course outcomes as following:

Table 1: Course Outcome Statements
CO’s Statements
CO1 We wired sensors, driver, and ESP32, using current embedded tools safely (3.3 V logic,
common GND).
CO2 We measured, logged, and fixed issues (timeouts, NaN reads, thresholds) using systematic
testing.
CO3 We designed a full system (sense → decide → act) that solves obstacle avoidance in a small
space.
CO4 We planned tasks, split work across cores, and delivered a reproducible build and demo.



Table 2: Mapping of CO, PO, Blooms, KP and CEP
CO PO Blooms KP CEP
CO1 PO5 C1, C2 KP3 EP1, EP3
CO2 PO4 C2 KP3 EP1, EP3
CO3 PO3 C4, A1 KP3 EP1, EP2
CO4 PO11
C3, C6, A3,
P3
KP4 EP1, EP3

The mapping justification of this table is provided in section 4.3.1, 4.3.2 and 4.3.3.

4. Table of Contents

Declaration i
Course & Program Outcome ii
1 Introduction 1
1.1 Introduction ...............................................................................................................................1
1.2 Motivation ................................................................................................................................. 1
1.3 Objectives .................................................................................................................................. 1
1.4 Feasibility Study ........................................................................................................................ 1
1.5 Gap Analysis ............................................................................................................................. 1
1.6 Project Outcome ........................................................................................................................1
2 Proposed Methodology/Architecture 2
2.1 Requirement Analysis & Design Specification ......................................................................... 2
2.1.1 Overview ......................................................................................................................2
2.1.2 Proposed Methodology/ System Design .......................................................................2
2.1.3 UI Design ......................................................................................................................2
2.2 Overall Project Plan................................................................................................................... 2
3 Implementation and Results 3
3.1 Implementation .......................................................................................................................... 3
3.2 Performance Analysis................................................................................................................3
3.3 Results and Discussion .............................................................................................................. 3
4 Engineering Standards and Mapping 4
4.1 Impact on Society, Environment and Sustainability ................................................................. 4
4.1.1 Impact on Life .............................................................................................................. 4
4.1.2 Impact on Society & Environment ............................................................................... 4
4.1.3 Ethical Aspects ............................................................................................................. 4
4.1.4 Sustainability Plan ........................................................................................................ 4
4.2 Project Management and Team Work ....................................................................................... 4
4.3 Complex Engineering Problem .................................................................................................4
4.3.1 Mapping of Program Outcome .....................................................................................4
4.3.2 Complex Problem Solving ............................................................................................4
4.3.3 Engineering Activities ..................................................................................................5

5. Table of Contents Table of Contents


5 Conclusion 6
5.1 Summary ................................................................................................................................... 6
5.2 Limitation .................................................................................................................................. 6
5.3 Future Work ..............................................................................................................................6
References 6

6. Chapter 1
Introduction


1.1 Introduction
Small mobile robots often run into things because they do not sense their surroundings well or they react too
slowly. Our project answers this in a practical way: we built a low-cost robot car that can see obstacles on its
left and right using ultrasonic sensors, make quick decisions on an ESP32 microcontroller, and move safely
using an L298N motor driver with two DC motors. The robot also looks after safety beyond obstacles: it watches
the temperature with a DHT11 sensor and triggers a fire alert when the area is 33 °C or more, and it switches
a headlight on in the dark based on an LDR reading. To make the system easy to demonstrate and understand,
we added a small Wi-Fi dashboard hosted directly on the ESP32. Anyone on the same network (or connected
to its fallback access point) can open a simple web page at / to see live readings and the robot’s current action;
raw data is also available as JSON at /data. Altogether, the project shows the essential steps of an embedded
system: sense, decide, act, and inform.

1.2 Motivation
We wanted a project that teaches real, practical skills—something you can wire, program, test, break, and fix
in a lab. Obstacle avoidance is a classic task where you immediately see if your design works: the robot either
keeps a safe distance or it doesn’t. By choosing the ESP32, we get fast control plus built-in Wi-Fi, which lets
us add a friendly dashboard without extra hardware. This directly benefits us as students: we practice clean
wiring, careful voltage levels, timing, state machines, and a tiny web server—all valuable skills for IoT and
embedded jobs. It also benefits future teams because our design is easy to copy, cheap to build, and simple to
extend with new features like phone control or a battery meter.

1.3 Objectives
Our objectives are to build a small autonomous rover that stays at least 30 cm away from obstacles, turns away
from the closer side, and uses a smart evasion routine when both sides are blocked; to implement a fire alert
that stops the vehicle and plays SOS beeps when temperature ≥ 33 °C and only resumes when safe; to auto-
control the headlight based on ambient light from the LDR; to expose a live dashboard at / and a JSON API at
/data refreshing roughly every 0.5 s; and to keep the whole system low-cost and reproducible with an ESP32,
L298N, two DC motors, common sensors, and a 5 V power bank.

1.4 Feasibility Study
There are many hobby projects online that show a single ultrasonic sensor driving a basic avoidance behavior,
and there are separate examples that use ESP32 web servers to print sensor readings. However, many demos
either rely on cloud apps, do not include a local dashboard, or skip safety features like a temperature alarm and
a proper headlight logic. Our plan is feasible because the parts are widely available and inexpensive, the ESP32
already supports FreeRTOS tasks and a lightweight WebServer, and the logic we need is simple but effective.
The two-sensor layout reduces blind spots compared to a single-sensor robot. The dashboard does not need the
internet—it is served locally—so we can demo anywhere, including classrooms with no Wi-Fi access by using
the board’s AP fallback.

7. 1.5 Gap Analysis
The gap we target is a small, reproducible robot that combines dual-side sensing, clear safety behavior, and a
no-internet dashboard in one clean build. Many beginner robots either do not show what the system is sensing,
or they miss safety and lighting features, or they depend on a phone app. Our work fills this gap by bundling
the features into one neat package: autonomous movement with distance rules, a temperature-based emergency
stop with SOS beeps, automatic lighting in the dark, and a local web page that shows everything live.

1.6 Project Outcome
By the end, we expect a working robot that moves safely, avoids collisions, and presents its decisions
clearly on the dashboard. We also expect a neat codebase that other students can reuse with minimal setup:
set Wi-Fi credentials, upload, and go. The outcome includes screenshots of the dashboard and JSON feed,
a block diagram of the system, and a short testing summary showing that the robot keeps distance, escapes
tight spots, turns the headlight on in low light, and stops with SOS beeps during high temperature.

8. Chapter 2
Proposed Methodology/Architecture


2.1 Requirement Analysis & Design Specification
2.1.1 Overview
Functionally, the system must read two ultrasonic sensors, a DHT11, and an LDR; make motion decisions
(forward, left, right, smart evasion, stop); switch a headlight in the dark; and serve a web dashboard and JSON
data locally. Non-functionally, the design must be low-cost, readable for students, quick to deploy, and
responsive enough that the dashboard feels live while the robot moves.

2.1.2 Proposed Methodology/ System Design


Figure 2.1: Obstaclear project block diagram

2.1.3 UI Design

9. 2.2 Overall Project Plan

We follow a simple plan that fits lab time. First we assemble the chassis and test each pin and motor direction;
then we add basic avoidance with one sensor and upgrade to two; then we add safety features—DHT11 SOS
and LDR headlight—and tidy the timings; finally we add the dashboard and test in both STA mode (joining a
router) and AP fallback (ESP32 creates its own Wi-Fi). The plan ends with a short measurement session to
collect distances, timing, and screenshots for the report.


2.3 Circuit Diagram

10. 2.4 Our Project

11. Chapter 3
Implementation and Results

3.1 Implementation

The controller is an ESP32 running Arduino/C++. We wire two HC-SR04 modules on the left and right (TRIG
on GPIO 5 and 17; ECHO on GPIO 18 and 16), a DHT11 on GPIO 15 for temperature, and an LDR to ADC
GPIO 34 through a simple resistor divider. The motors are driven by an L298N using IN1=26, IN2=27, IN3=13,
IN4=14. We use GPIO 21 for the buzzer, GPIO 2 for a status LED, and GPIO 25 for the headlight LED, which
is wired active-low so 0 V turns it on. Power comes from a 5 V bank, and all grounds are common; we also
place a large capacitor across the motor supply to reduce voltage sag.

In software, we keep two FreeRTOS tasks. The sensor task (Core 0) samples temperature, LDR, and both
distances roughly every 100 ms, and decides the headlight state. The motor task (Core 1) runs about every 50
ms: if both sides are closer than 30 cm, it performs a smart evasion routine (back off, check which side is
clearer, try left/right turns, re-check); if only one side is close, it turns away; otherwise it goes forward.
Temperature ≥ 33 °C triggers a fire alert that stops the robot and plays SOS beeps with the LED until it cools.
For visibility, an HTTP server on port 80 serves a neat HTML dashboard at / and JSON at /data. The ESP32
first tries to join a given Wi-Fi network (STA mode). If it cannot connect in time, it automatically creates its
own hotspot so we can always open the dashboard during demos.
3.2 Performance Analysis

From hands-on tests, the dashboard updates feel quick and stable with about a half-second refresh. The robot
reacts smoothly to obstacles at arm’s length; when both sides are blocked, the smart evasion wiggles out within
a second or two. The headlight state tracks normal room lighting well: covering the LDR immediately flips it
to “ON,” and bright light switches it off. The fire alert begins near our set point (around 33–34 °C), and the
robot halts and signals clearly, which is exactly what we expect for a safety-first behavior. These results indicate
that sensor sampling, decision logic, and UI polling are balanced well for a small lab robot.
3.3 Results and Discussion

The robot achieved its main goals. It kept a safe buffer, avoided direct collisions, and handled tight spots thanks
to the smart evasion steps. The dashboard made our internal state visible—distances, headlight, fire status, and
vehicle action—so it was easy to debug and to present in class. We did notice that very soft or angled materials
sometimes confuse ultrasonics, which is normal for this sensor type. The DHT11 is slow and not very precise,
but it is good enough to show an alert demo. Occasional long delays (like SOS beeps) can briefly reduce web
responsiveness, but not enough to hurt a live demo. Overall, the system is simple, understandable, and solid for
student use.

12. Chapter 4
Engineering Standards and Mapping

4.1 Impact on Society, Environment and Sustainability
4.1.1 Impact on Life

The robot behaves safely around people. It maintains distance, it stops and warns in hot environments, and its
headlight improves visibility in darker corners. These small choices matter in labs and classrooms where people
walk close to the robot and do not expect it to rush toward them. By making the robot predictable and clearly
communicative—through lights, beeps, and a dashboard—we reduce surprise and lower the chance of minor
accidents.
4.1.2 Impact on Society & Environment

Our design keeps all data local. There is no camera and no cloud service, so there is minimal risk of exposing
personal information or causing privacy concerns. Using a 5 V power bank and common modules means the
system has a low energy footprint and can be reused for many semesters. If a part fails, it is inexpensive to
replace, and the wiring remains the same, which reduces electronic waste over time.
4.1.3 Ethical Aspects

We intentionally avoided sensors that could capture personal identity (like microphones or cameras). The
dashboard is transparent: it shows exactly what the robot is reading and doing. If something goes wrong, the
live numbers help us diagnose it quickly. Keeping everything on local Wi-Fi also respects lab policies where
external cloud services might not be allowed.
4.1.4 Sustainability Plan

To keep this sustainable for future students, we document the pin map, thresholds, and setup steps so others
can rebuild it without guessing. We prefer standard parts, which keeps costs low and replacements easy. If a
lab wants to reduce power loss further, they can swap the L298N for a more efficient driver (e.g., TB6612)
later without changing the overall design. The code is organized and commented so it can become a base for
new features like speed control or phone control.
4.2 Project Management and Team Work

We split the work into clear roles: one person focused on hardware wiring and power stability; one took the
lead on firmware logic and FreeRTOS tasks; one built and styled the web dashboard; and one handled testing,
measurement, and report writing. This kept our schedule realistic and reduced blocking. Our budget covered
the ESP32 board, two ultrasonics, DHT11, LDR plus a resistor, L298N, two DC motors with wheels, a chassis,
a buzzer, LEDs with resistors, jumper wires, and a 5 V power bank. If costs need to be trimmed further, a team
can reuse an existing power bank and choose a basic chassis. The revenue model is educational—our value is
in reusable kits that can support multiple lab batches with minimal maintenance.

13. 4.3 Complex Engineering Problem
4.3.1 Mapping of Program Outcome
In this section, provide a mapping of the problem and provided solution with targeted Program Outcomes
(PO’s).

Table 4.1: Justification of Program Outcomes
PO’s Justification
PO3 Our design choices (thresholds, evasion steps, headlight logic) address a
practical problem.
PO4 We investigated sensor timing, cross-talk, and debounced signals.
PO5 We used modern boards/tools (ESP32, WebServer, FreeRTOS).
PO11 We scoped tasks, scheduled work, managed budget.


4.3.2 Complex Problem Solving

Table 4.2: Mapping with complex problem solving.
EP1
Dept of
Knowledge
EP2
Range of
Conflicting
Requiremen
ts
EP3
Depth of
Analysis
EP4
Familiarity
of Issues
EP5
Extent of
Applicable
Codes
EP6
Extent
Of
Stakeholder
Involvemen
t
EP7
Inter-
dependence
✓ ✓
✓ ✓


4.3.3 Engineering Activities
In this section, provide a mapping with engineering activities. For each mapping add subsections to
put rationale (Use Table 4.3).

Table 4.3: Mapping with complex engineering activities.
EA1
Range of
resources
EA2
Level of Interaction
EA3
Innovation
EA4
Consequences for
society and
environment
EA5
Familiarity
✓
✓
✓ ✓

14. Chapter 5
Conclusion


5.1 Summary

We built a small but capable robot car that senses, decides, acts, and communicates. It uses two ultrasonic
sensors to stay clear of obstacles, a smart evasion routine to escape tight spots, a DHT11 to raise a fire alert at
33 °C, and an LDR to control a headlight automatically. An ESP32 hosts a clean dashboard and a JSON feed
so anyone can watch live values during a demo. The system runs on a 5 V power bank, is easy to copy, and
teaches real embedded thinking—exactly what we wanted.
5.2 Limitation

Ultrasonic sensors can struggle with soft fabrics or sharp angles, so there will always be corner cases where
readings jump. The DHT11 is slow and coarse, so the fire alert is a demonstration rather than a precise alarm.
During SOS, the buzzer’s timed beeps can momentarily slow the web server because they use blocking delays.
None of these issues stop the project from working as a lab robot, but they are helpful to keep in mind.
5.3 Future Work

We would first add phone control buttons on the same web page for manual override—Forward, Left, Right,
Stop. Next, we would add a battery meter to the dashboard with a low-power warning so the robot can stop
safely before voltage drops too far. We would also enable PWM speed control and perhaps add a front-center
sensor for even smoother turns. Finally, we would convert longer waits (like SOS) to non-blocking timing to
keep the web server perfectly responsive under all conditions.

15. Appendix (detailed code snippets)

22. References

1. ESP32 Arduino Core (Board manager & WebServer examples)
2. Adafruit DHT Sensor Library (DHT11 usage)
3. HC-SR04 notes (timing, voltage levels)
4. L298N Dual H-Bridge driver basics