Blind Spot Monitoring and Warning System

ECE 3375 – Microprocessors & Microcomputers

Section 012
Professor Anestis Dounavis

Name: Addy Virk

Student Number: 251311740

Date: 2025/04/04
Problem Definition
Blind spot monitoring (BSM) is a crucial safety system used in modern vehicles to detect
adjacent vehicles that may not be visible to the driver, especially when preparing to change
lanes. This project simulates a practical BSM, and lane change alert system using LEDs
and a buzzer to represent feedback to the driver. By simulating different driving cases (ex.
Constant blind spot occupancy, cars approaching from behind, or passing slow car), the
system offers realistic scenarios that are critical for driver safety.

Specification

• Detect vehicles in or approaching the vehicle’s blind spots and signal through
constant yellow LED of presence.
• Simulate Time-To-Collision (TTC) alerts based on relative speed and distance.
• Visual lane change intent feedback using red LED blinkers.
• Alert drivers of unsafe lane changes using a buzzer.

User and Societal Impact:

• Increases driver situational awareness.

• Reduces risk of side-swipe collisions and unsafe merges.
• Promotes broader adoption of low-cost intelligent vehicle systems.
• Minimal drawbacks, though excessive reliance could cause driver complacency.

Functional Description
This BSM system monitors simulated vehicle proximity and motion data and uses logic to
determine whether lane changes are safe. The system issues timely warnings to the driver
via:

• Yellow LEDs: Show when a vehicle is in or approaching a blind spot.

• Red LEDs: Blink to indicate a driver’s intent to change lanes.
• Buzzer: Activates if a lane change is attempted into an occupied blind spot.

The system handles three primary cases:

• Constant left blind spot occupation.

• Vehicles approaching rapidly from behind (right side).
• Passing a slower vehicle (left side).

Each component is handled using timing and logic operations in software, creating a
modular and realistic simulation.
Input/Output Requirements
Inputs:

• BTN_TURN_LEFT (GPIO 11): Left turn signal button

• BTN_TURN_RIGHT (GPIO 12): Right turn signal button

Outputs:

• BLIND_LEFT_LED (GPIO 4): Yellow LED for left blind spot

• BLIND_RIGHT_LED (GPIO 5): Yellow LED for right blind spot
• TURN_LEFT_LED (GPIO 7): Red LED for left signal
• TURN_RIGHT_LED (GPIO 6): Red LED for right signal
• BUZZER (GPIO 10): Active buzzer for unsafe lane change warning

Tools and Circuits:

• ESP32 (powered via USB)

• LEDs with 220Ω resistors
• Active buzzer
• Push buttons with internal pull-up resistors

Initial Software Design

Initialization Tasks:

• Configure all GPIOs for input/output.

• Enable internal pull-ups for buttons.
• Initialize serial debugging

Main Software Loop:

• Monitor left/right button states.

• Toggle left/right turn signals on press.
• Blink LEDs every 500 ms.
• Simulate vehicle positions and compute TTC:
• TTC = distance / relative speed
• Trigger blind spot LEDs based on TTC and proximity thresholds.
• Trigger buzzer only if lane change intent and blind spot presence align.
Prototyping Plan

Focus of Prototype:

• Simulate three vehicle interaction scenarios.

• Use logic and timers to simulate movement and warning.
• Validate visual/auditory outputs and TTC logic.

Hardware/Simulation Platform

• ESP32 board (Espressif library v3.1.3)

• Use variable arrays or manual input to simulate sensor data.
• Integrate HLK-LD2420 radar modules for real-time sensor feedback.

Scenarios to Simulate

• Case 1: Constant car in left blind spot.

• Case 2: Repeated car approaching from rear on right side.
• Case 3: Repeated passing of slower car on left.

Verification Plan

• LEDs and buzzer trigger as expected.

• Time intervals, distance changes, and TTC calculations logged.
• Use Serial output to confirm logic and state transitions.

Planned Sensors Not Implemented

The initial prototyping plan included integrating a HLK-LD2420 radar sensor to detect
motion-based blind spot intrusion. This radar would have provided real-time object
detection within the blind spot. However, the sensor caused instability and boot-looping
on the ESP32-S3 when connected to 3.3V or 5, making implementation unfeasible within
the time constraint. Alternative sensors like the HC-SR04 ultrasonic sensor were also
explored, but voltage mismatches and GPIO conflicts led to similar issues.
Microcontroller Selection
Comparison

• ESP32 (Espressif): Chosen for its affordability, community support, and GPIO
flexibility. It includes WiFI/BLE with could be implemented in the future to make the
device more scalable.
• ARM Cortex-A9 (DE10-Standard): Powerful, but too complex and power-hungry for
our small, embedded simulation

Justification

ESP32 provides the required number of GPIOs, supports fast prototyping, and is cost-
effective. Its simplicity suits simulation-based embedded projects.

Revised Software Design

During implementation, I encountered significant issues integrating physical sensors. The
HLK-LD2420, though capable, could not be safely connected to the ESP32 without causing
resets. Similarly, the HC-SR04 ultrasonic module resulted in unstable power draw and
failed communication, even after moving signal pins to safe GPIOs (GPIOs 37–39). As a
result:

• Sensor logic was removed and replaced by a time-based simulation.

• Blind spot scenarios now use programmable timers and TTC calculations.
• The code includes toggles to control each case for testing.
• Buzzer logic improved to activate only when turn signal and blind spot warning are
both active.

Key Revisions:

• Physical input from sensors replaced with simulated movement.

• Case timing intervals added using millis().
• Modular toggles for easier testing and debugging.
• Code now fully operational without real-time sensor data.
• Interrupts were considered, but polling was sufficient due to the simplicity of user
input and fixed delay steps.
Results from Prototyping
Summary:

The prototyping yielded a fully functional simulation model. I tested:

• Lane signal toggling via buttons.

• LED blinking using software timers.
• Repeated vehicle detection scenarios using programmed time and TTC.
• Blind spot detection and buzzer warning logic.

Notable Challenges:

• HLK-LD2420 sensor could not be used due to voltage instability.

• USB and UART disconnections occurred with ultrasonic sensor.
• GPIO conflicts required reassignments to safe pins.

Iterations of Software:

• Phase 1: Simple LED/Button test.

• Phase 2: Lane change toggle + LED blink logic.
• Phase 3: TTC calculations with simulated movement.
• Phase 4: Case loop logic and toggles added.
• Phase 5: Final integration of warning logic and buzzer.

Source Code
// ===CASE TOGGLES===
// Set these to true or false to simulate different scenarios

bool enableCase1 = false; //Simulates a car travelling in the blindspot at the

same speed as the vehicle
bool enableCase2 = true; //Simulates a car approaching from behind on the
right side
bool enableCase3 = true; //Simualtes a car slowing down from in front on the
left side

// ===PIN LAYOUT===
// GPIO connections to ESP32 components

//Blind Spot Warning LEDS (Yellow)

#define BLIND_LEFT_LED 4
#define BLIND_RIGHT_LED 5
//Turn Signal LEDs (Red)
#define TURN_LEFT_LED 7
#define TURN_RIGHT_LED 6

//Lane Change Buttons

#define BTN_TURN_LEFT 11
#define BTN_TURN_RIGHT 12

//Active Buzzer
#define BUZZER 10

// ===SYSTEM STATE VARIABLES===

bool turnLeftActive = false; // Toggle for left turn signal
bool turnRightActive = false; // Toggle for right turn signal
bool blinkState = false; // Toggles LED blink every 500ms
unsigned long lastBlinkTime = 0; // Timestamp for LED blink control

// ===SPEED CONFIGURATION (in m/s)===

const float ourSpeed = 27.78; // Speed of vehicle
const float car2_speed = 33.33; // Speed of vehicle in case 2
(approaching fast from rear)
const float car3_speed = 26.39; // Speed of vehicle in case 3 (slower
car we're passing)

// ==BLIND SPOT CONFIGURATION===

const float blindspot_start = 0.3; // Closest distance active (beside the
car)
const float blindspot_end = 8.0; // Farthest distance active (extends
behind bumper)
const float ttc_threshold = 3.0; // TTC threshold for warning (in
seconds)

// ===CASE 2 (Right Side: Car Approaching from behind)===

float car2_distance = -10.0; // The vehicle in case 2 starts 10m
behind our vehicle
bool car2_active = true; // Checks if the vehicle in case 2 is
currently being simulated.
unsigned long lastCar2Time = 0; // Keeps track of the last time the car
was triggerd

// ===CASE 3 (Left Side: We Are Passing A Car)===

float car3_distance = 5.0; // The vehicle in case 3 starts 5m ahead
of our vehicle.
bool car3_active = false; // Checks if the vehicle in case 3 is
current being simulated.
unsigned long lastCar3Time = 0; // Keeps track of the last time we
passed a vehicle

void setup() {

// === CONFIGURE OUTPUT DEVICES ===

pinMode(BLIND_LEFT_LED, OUTPUT);
pinMode(BLIND_RIGHT_LED, OUTPUT);
pinMode(TURN_LEFT_LED, OUTPUT);
pinMode(TURN_RIGHT_LED, OUTPUT);
pinMode(BUZZER, OUTPUT);

// === CONFIGURE INPUTS ===

pinMode(BTN_TURN_LEFT, INPUT_PULLUP);
pinMode(BTN_TURN_RIGHT, INPUT_PULLUP);

// === SERIAL DEBUG ===

Serial.begin(115200);
delay(1000);
Serial.println("🚘 Blind Spot & TTC Simulation Initialized");
}

void loop() {

//Store the current time in ms after the boot

unsigned long now = millis();

// === SECTION 1: HANDLE BUTTON INPUT FOR TURN SIGNAL ===

static bool lastLeftBtn = HIGH, lastRightBtn = HIGH; // Keep track of

previous button states to detect press event
bool currLeftBtn = digitalRead(BTN_TURN_LEFT); // Read current state of
left and right button (LOW when pressed)
bool currRightBtn = digitalRead(BTN_TURN_RIGHT);

if (currLeftBtn == LOW && lastLeftBtn == HIGH) { // If the left button

transitioned from HIGH to LOW, toggle left turn signal
turnLeftActive = !turnLeftActive;
 }

if (currRightBtn == LOW && lastRightBtn == HIGH) { // If the right button

transitioned from HIGH to LOW< toggle right turn signal
turnRightActive = !turnRightActive;
}

lastLeftBtn = currLeftBtn; // Store current button

states for the next loop interation
lastRightBtn = currRightBtn;

// === SECTION 2: HANDLE TURN SIGNAL BLINKING ===

if (now - lastBlinkTime >= 500) { // Check if 500ms have

passed to toggle blink state (makes LED blink)
blinkState = !blinkState; // Toggle the blinking
state
lastBlinkTime = now; // Reset the timer
}
digitalWrite(TURN_LEFT_LED, (turnLeftActive && blinkState) ? HIGH : LOW); //
Set left signal LED: blinks if left turn is active and blinkstate is HIGH
digitalWrite(TURN_RIGHT_LED, (turnRightActive && blinkState) ? HIGH : LOW); //
Set right signal LED: it blinks if right turn is active and blinkstate is HIGH

// === SECTION 3: INITIALIZE OUTPUTS FOR BLIND SPOT LEDS ===

bool blindLeft = false; // Set the initial blind spot

status to false; each case may activate them
bool blindRight = false;

// === CASE 1: CONSTANT LEFT BLIND SPOT ===

if (enableCase1) { // If case 1 is enabled,

simulate a vehicle always present in left blind spot
blindLeft = true;
}

// === CASE 2: CAR APPROACHING FROM BEHIND (RIGHT) ===

if (enableCase2) {
float relSpeed = car2_speed - ourSpeed; // Relative speed between car
approaching our vehicle
 float ttc = abs(car2_distance) / relSpeed; // Time to collision if
current speeds and distances are maintained

if (car2_active) {
car2_distance += relSpeed * 0.05; // Move the car forward by
its relative speed every loop (~50ms step)

if (ttc < ttc_threshold || (car2_distance >= -blindspot_end &&

car2_distance <= -blindspot_start)) {
blindRight = true; // If TTC is low OR the car
is inside the blind spot zone, trigger warning
}

if (car2_distance > 2.0) { // Once the car has passed us

(distance > 2m ahead), deactivate it
car2_active = false;
lastCar2Time = now; // Start delay before
spawning next car
}
} else {

if (now - lastCar2Time >= 10000) { // Wait 10 seconds after last

car before spawning new one
car2_distance = -10.0; // Reset to start behind our
car
car2_active = true;
}
}
}

// === CASE 3: WE ARE PASSING A SLOWER CAR (LEFT) ===

if (enableCase3) {
float relSpeed = ourSpeed - car3_speed; // Relative speed between our
vehicle and the car we are passing.
float ttc = abs(car3_distance) / relSpeed; // Time to collision with the
car we're approaching from behind

if (car3_active) {
car3_distance -= relSpeed * 0.05; // Simulate us catching up
and passing the car by reducing distance
 if (ttc < ttc_threshold || (car3_distance >= blindspot_start &&
car3_distance <= blindspot_end)) {
blindLeft = true; // If TTC is low OR car is in
blind spot zone, trigger left warning
}

if (car3_distance < -5.0) { // Once we have passed the

car completely, deactivate
car3_active = false;
lastCar3Time = now;
}
} else {

if (now - lastCar3Time >= 15000) { // Spawn a new slower car

every 15 seconds
car3_distance = 5.0;
car3_active = true;
}
}
}

// === SECTION 4: OUTPUT TO LEDS AND BUZZER ===

// Light up respective blind spot LED if respective side has danger

digitalWrite(BLIND_LEFT_LED, blindLeft ? HIGH : LOW);
digitalWrite(BLIND_RIGHT_LED, blindRight ? HIGH : LOW);

// Turn ON buzzer only if a lane change is attempted into an active blind spot.
bool buzzerOn = (blindLeft && turnLeftActive) || (blindRight &&
turnRightActive);
digitalWrite(BUZZER, buzzerOn ? HIGH : LOW);

// SERIAL OUTPUT

Serial.print("Car2 Dist: ");

Serial.print(car2_distance);
Serial.print(" | Car3 Dist: ");
Serial.print(car3_distance);
Serial.print(" | TTC2: ");
Serial.print(abs(car2_distance) / (car2_speed - ourSpeed), 2);
Serial.print(" | TTC3: ");
Serial.print(abs(car3_distance) / (ourSpeed - car3_speed), 2);
Serial.print(" | BlindL: ");
 Serial.print(blindLeft);
Serial.print(" | BlindR: ");
Serial.print(blindRight);
Serial.print(" | Buzzer: ");
Serial.println(buzzerOn ? "ON" : "OFF");

delay(50);
}

Images of Circuit
Conclusions
This project demonstrated that it is feasible to implement an intelligent blind spot
monitoring system using minimal hardware and primarily software-based simulations. The
Time-To-Collision logic effectively models real-world scenarios, providing a cost-effective
and safe method for testing collision detection algorithms.

Although I originally planned to use real sensors like the HLK-LD2420 or HC-SR04, I
encountered significant power and compatibility issues. The fallback simulation allowed
us to maintain system functionality while ensuring safety and reliability.

From a sustainability standpoint, the system uses low-power components, is scalable for
future enhancements, and minimizes e-waste by avoiding unnecessary hardware.

Environmentally, the device has minimal negative impact and promotes safer driving,
which can indirectly reduce accident-related waste and emissions.

This project reinforced my skills in embedded system design, particularly around software
simulation, GPIO mapping, and power management. It also clarified how different
subsystems interact in real-time embedded systems. I also learned the importance of
considering GPIO boot behavior and sensor power constraints when working on hardware-
in-the-loop systems.