G7: Smart Parking Lot Monitoring System - shalan/CSCE4301-WiKi GitHub Wiki

Project Title: Smart Parking Lot Monitoring System

Name GitHub
Mohamed Sabry MohamedOmarSabry
Omar Bahgat omar-bahgat

Github Repo: Smart-Parking-Monitoring-System

Slides: Slides

1. The Proposal

Abstract / Elevator Pitch:

Finding a parking spot is a daily frustration β€” drivers waste time circling lots with no idea which slots are actually free. The Smart Parking Slot Monitoring System eliminates that problem by giving real-time, per-slot occupancy visibility to both on-site drivers and remote users.

Each parking slot is equipped with an HC-SR04 ultrasonic sensor connected to an ESP32 microcontroller. When a vehicle pulls in or leaves, the system detects the change automatically and within one second updates three outputs: a red/green LED directly above the slot, an LED matrix display showing the total free-slot count for the lane, and a live web dashboard accessible from any browser.

The result is a fully automated, wireless, low-cost alternative to manual monitoring and expensive commercial systems β€” built from off-the-shelf embedded components.

Project Objectives & Scope:

  • Per-slot vehicle detection using ultrasonic sensors
  • Real-time slot monitoring
  • Occupancy detection (free vs occupied using distance thresholds)
  • LED indicators per slot (green = free, red = occupied)
  • WiFi-based communication (ESP32) sending JSON data to a backend server
  • Web-based dashboard for live monitoring and visualization

2. System Architecture

2.1 High-Level Block Diagram:

Screenshot 2026-05-20 at 9 52 11β€―AM

Subsystem Breakdown:

The system is organized into three hardware tiers and one software/cloud tier:

Tier 1 β€” Slot Controller (per parking slot)

An ESP32 running the Occupancy Detection Module reads a dedicated HC-SR04 ultrasonic sensor via GPIO. It classifies the slot as FREE or OCCUPIED, then drives a red/green LED pair reflecting the current state. Slot state changes are reported up to the Lane Controller over Bluetooth.

Tier 2 β€” Lane Controller (per lane)

An ESP32 aggregates state reports from all Slot Controllers in its lane over Bluetooth. It updates the lane's LED matrix display (free slot count) via SPI and forwards occupancy JSON payloads to the Central Controller over WiFi.

Tier 3 β€” Central Controller (one per parking lot)

An ESP32 receives lane-level data over WiFi, maintains the global slot map, drives the central LED matrix display via SPI, and sends the JSON occupancy payload to the backend over WiFi.

Tier 4 β€” Backend + Web Dashboard (cloud)

A lightweight server (Flask or Node.js) receives JSON on every state change and at a 1-second heartbeat interval. It stores event logs, and pushes live updates to a web dashboard. The dashboard shows a per-slot status map and real-time total occupancy percentage.

3. Hardware Design

Component Selection:

ESP32 Board Ultrasonic Sensor RGB LED 5VDC 2A Wall Adapter

Schematics & Wiring:

Circuit diagrams, pinout tables, and breadboard layouts.

Bill of Materials (BOM):

Component Part Number Quantity Unit Cost (EGP) Total Cost (EGP) Datasheet
ESP32 Microcontroller Board ESP32-WROOM-32 5 350 1,750 Datasheet
RGB LED (5mm) L-7113ID 2 1.5 3 β€”
HC-SR04 Ultrasonic Sensor HC-SR04 2 50 100 Datasheet
5VDC 2A Wall Adapter SS-MW5V2A 1 60 60 β€”
Total 1,913

Power Budget:

Calculations ensuring your power supply can handle the peak current draw of all components combined.

4. Software Implementation

Software Architecture

The current firmware follows a bare-metal superloop design running on the ESP32 via ESP-IDF. The main loop executes the following steps sequentially every 1 second:

  1. Fire HC-SR04 trigger pulse and time the echo response
  2. Compute distance in cm (duration_Β΅s / 58)
  3. Classify slot state: distance < 20 cm β†’ OCCUPIED, otherwise β†’ FREE
  4. Set red LED GPIO high/low to reflect state
  5. HTTP POST a JSON payload {"occupied": true/false} to the Node.js backend over WiFi.

The backend is a Node.js/Express server that accepts POST requests from the ESP32 and serves the current state via a GET endpoint. The frontend is a vanilla HTML/CSS/JS dashboard that polls GET /sensor every second and updates the DOM.

Flowcharts & State Machines:

Visual diagrams mapping out the core logic, state transitions, and interrupt service routines (ISRs).

Key Algorithms

Distance Sensing

gpio_set_level(TRIG_PIN, 1);
esp_rom_delay_us(10);
gpio_set_level(TRIG_PIN, 0);
// Time the ECHO pulse; timeout at 50 ms
float distance_cm = echo_duration_us / 58.0f;

Occupancy Classification

bool occupied = (distance != -1 && distance < 20);

Development Environment

Layer Toolchain
Firmware ESP-IDF via PlatformIO (VS Code)
Backend Node.js + Express
Frontend HTML / CSS / JS

Setup β€” Firmware

  1. Install VS Code and the PlatformIO extension
  2. Clone the repo and open it in VS Code
  3. PlatformIO will auto-download the ESP-IDF framework and dependencies
# Build only
pio run
 
# Upload to board
pio run --target upload
 
# Upload and open Serial Monitor
pio run --target upload && pio device monitor

Setup β€” Backend

cd backend
npm install
npm start
# Server runs on http://localhost:3000

Setup β€” Frontend

Open frontend/index.html with the VS Code Live Server extension (right-click β†’ Open with Live Server).

5. Testing, Validation & Debugging

Unit Testing:

Each node was tested in isolation via the serial debug terminal before integration.

Slot Node Lane Node Main Node
Obstructed the ultrasonic sensor and verified distance readings in the terminal Verified Slot–Lane Wi-Fi communication via the terminal Confirmed all Lanes connected successfully and appeared in terminal output
Confirmed the occupancy flag triggers at the expected distance threshold Inspected outgoing JSON payloads in the terminal for correctness Verified occupancy data is transmitted to the backend via terminal logs
Observed LED color changes during occupied and vacant states Confirmed Slot–Lane connectivity through terminal logs Connected to the Main AP and validated the web interface end-to-end

Integration Testing:

Once all nodes passed unit testing, the full system was brought up tier by tier β€” Slots first, then Lanes, then the Main controller β€” verifying at each stage that occupancy data flowed correctly through to the web dashboard.

Challenges & Solutions:

A log of major bugs, hardware failures, or design flaws you encountered, and the engineering steps you took to solve them.

6. Results & Demonstration

Final Prototype:

High-quality photos of the completed build. High-quality photos of the completed build.

WhatsApp Image 2026-05-20 at 9 32 08 AM

image

Video Demonstration:

A link to a short video showing the system working in real-time under various conditions.

7. Project Management

7.1 Division of Labor:

Area Mohamed Sabry Omar Bahgat
System Design Hardware architecture & tier hierarchy Software architecture & data flow
Hardware Build Wiring, sensors & LED indicators Power setup & ESP32 configuration
System Implementation Firmware (ESP-IDF, occupancy logic) Backend (Node.js) & web dashboard
Integration Slot–Lane–Central controller linking WiFi communication & JSON pipeline
Test & Debug Hardware validation & sensor tuning End-to-end testing & edge cases

7.2 Timeline:

Week 1 β€” Hardware Setup & Single-Slot Prototype

Goal: Full single-slot system working end-to-end, from sensor to browser.

  • Breadboard and wire all components for a single parking slot
  • Validate ultrasonic sensor readings and tune the occupancy detection threshold
  • Wire red LED indicator and LED matrix display
  • Implement occupancy detection β€” slot correctly classified as free or occupied

Week 2 β€” Wireless Communication & Web Dashboard

Goal: Data flows reliably from the microcontroller to a server and is visible in a live browser dashboard.

  • Connect microcontroller to WiFi and transmit occupancy data to the backend
  • Build a backend server to receive and store slot state
  • Build a web dashboard showing live occupied and free slot counts
  • Verify full data flow from sensor to browser

Week 3 β€” Multi-Slot Scaling

Goal: Scale the single-slot prototype to multiple slots per lane and bring up the full three-tier hardware hierarchy.

  • Extend firmware to support multiple slots simultaneously
  • Implement Lane Controller β€” collects slot states wirelessly and updates the lane display
  • Implement Central Controller β€” aggregates all lane data and drives the central display

Week 4 β€” Testing & Demo Prep

Goal: Full system working end-to-end; dashboard complete; documented and ready to present.

  • Expand dashboard to show a per-slot status map and total occupancy percentage
  • Switch dashboard to real-time push updates instead of polling (using web sockets)
  • End-to-end integration testing across all hardware tiers
  • Handle edge cases
  • Full system demo dry run

8. Appendices & References

8.1 Source Code Repository:

Github Repo: Smart-Parking-Monitoring-System

8.2 References:

Links to datasheets, tutorials, academic papers, and course materials used during development.

Datasheets

⚠️ **GitHub.com Fallback** ⚠️