-
Notifications
You must be signed in to change notification settings - Fork 4
G7: Smart Parking Lot Monitoring System
| Name | GitHub |
|---|---|
| Mohamed Sabry | MohamedOmarSabry |
| Omar Bahgat | omar-bahgat |
Github Repo: Smart-Parking-Monitoring-System
Slides: Slides
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.
- 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
The system is organized into three hardware tiers and one software/cloud tier:
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.
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.
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.
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.
| ESP32 Board | Ultrasonic Sensor | RGB LED | 5VDC 2A Wall Adapter |
|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
Circuit diagrams, pinout tables, and breadboard layouts.
| 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 |
Calculations ensuring your power supply can handle the peak current draw of all components combined.
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:
- Fire HC-SR04 trigger pulse and time the echo response
- Compute distance in cm (
duration_µs / 58) - Classify slot state: distance < 20 cm →
OCCUPIED, otherwise →FREE - Set red LED GPIO high/low to reflect state
- 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.
Visual diagrams mapping out the core logic, state transitions, and interrupt service routines (ISRs).
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;bool occupied = (distance != -1 && distance < 20);| Layer | Toolchain |
|---|---|
| Firmware | ESP-IDF via PlatformIO (VS Code) |
| Backend | Node.js + Express |
| Frontend | HTML / CSS / JS |
- Install VS Code and the PlatformIO extension
- Clone the repo and open it in VS Code
- 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 monitorcd backend
npm install
npm start
# Server runs on http://localhost:3000Open frontend/index.html with the VS Code Live Server extension (right-click → Open with Live Server).
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 |
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.
A log of major bugs, hardware failures, or design flaws you encountered, and the engineering steps you took to solve them.
High-quality photos of the completed build. High-quality photos of the completed build.
A link to a short video showing the system working in real-time under various conditions.
| 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 |
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
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
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
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
Github Repo: Smart-Parking-Monitoring-System
Links to datasheets, tutorials, academic papers, and course materials used during development.



