More project photos (3)
The problem
Parking operators guess at occupancy: a guard waves cars in until the lanes jam, and nobody knows the peak hour, the turnover, or how many vehicles the lot actually handled today. The engineering gap is directional counting at the gate — not just "a car passed" but "one entered, one left" — driving a live occupancy figure the operator can trust, plus the analytics that come free once the data exists. This project builds that on an ESP32: two IR sensor beams across the lane detect travel direction by break order, a servo drives the boom barrier, a 7-segment display shows the running count, and the dashboard plots entries, exits and occupancy through the day.
Two IR beams across the lane; the break order gives the direction of travel.
Follow the working sequence
How it works
- A vehicle approaches; the IR beam pair watches the lane continuously.
- Beam A breaks, then beam B: the firmware registers an entry, increments the inside count and lifts the barrier.
- The barrier stays up until both beams clear plus a safety delay, then lowers.
- Beam B breaking before beam A registers an exit and decrements the inside count.
- Two rapid A-B sequences without a clear gap flag a suspected tailgating event in the log rather than silently double-counting.
- Counts stream to the dashboard, which maintains occupancy, the hourly profile and the event log.
Tech stack:
- ESP32 development board (Wi-Fi telemetry)
- 2x IR obstacle/beam sensor modules (direction pair)
- SG90/MG996R servo (boom barrier)
- 4-digit 7-segment display (gate count)
- Model barrier gate with striped boom arm (demo rig)
- Toy vehicles for demonstration
- Single-page parking dashboard (HTML/JS)
| Parameter | Value |
|---|---|
| Controller | ESP32, Wi-Fi dashboard sync |
| Direction sensing | Dual IR beam sequence (A→B entry, B→A exit) |
| Barrier | Servo-driven boom arm; lift/hold/lower timing configurable |
| Count display | 4-digit 7-segment at the gate |
| Occupancy | Inside = entries − exits; FULL flag at configured capacity |
| Tailgating | Rapid double-break flagged as suspected event, not silently counted |
| Dashboard | Live occupancy, hourly entry/exit profile, event log |
| Demo | Model gate with toy vehicles; real-gate actuation is out of scope |
Project features
- [Directional IR counting] Two beams broken in A-then-B order count an entry; B-then-A counts an exit — direction from sequence, not guesswork.
- [Servo boom barrier] The barrier lifts on a valid entry detection and lowers after the vehicle clears, with the timing configurable.
- [Live occupancy] Inside count = entries − exits, shown on the dashboard and on the gate display; a FULL state triggers at configured capacity.
- [Debounce and edge handling] Firmware debounces beam breaks and handles the tailgating case explicitly — flagged as a suspected double-entry for the log.
- [Hourly analytics] The dashboard builds the entries/exits profile across the day, exposing the peak hour for staffing decisions.
- [On-gate display] A 7-segment module shows the running count at the barrier itself for the demo.
- [Event log] Entries, exits, FULL transitions and tailgating flags are timestamped for the report.
What is included
- Working barrier-counter prototype (IR pair, servo barrier, display, ESP32)
- Model parking gate demo rig with vehicles
- Complete firmware source code (direction logic, debounce, barrier control, dashboard sync)
- Parking analytics dashboard with occupancy and profiles
- Circuit and wiring documentation
- Beam-alignment procedure (buyer-run setup for reliable detection)
- Project report PDF (counting method, edge cases, logged data from the buyer's run)
- PPT presentation for final review
- Viva Q&A preparation document (IR sensing, direction detection, debouncing, servo control)
Limitations & prerequisites
- Tailgating detection is heuristic — two cars bumper-to-bumper can still read as one; the log flags the suspicion rather than claiming certainty.
- IR beams need alignment and are affected by bright direct sunlight; the setup procedure covers positioning.
- Demonstrated on a model gate; driving a real barrier needs proper motor contactors and safety interlocks — out of scope.
- The count is only as honest as the lane discipline — vehicles bypassing the lane are not counted.
- Occupancy resets need a defined procedure (e.g., nightly reconciliation), documented in the report.
Frequently Asked Questions
How does it know direction?
Order of beam breaks: A-then-B means entering, B-then-A means leaving. The sequence is the direction signal — a single beam could never tell.
What about tailgating?
Two vehicles through on one barrier lift produce a rapid double A-B without a clear gap; the firmware flags it as a suspected tailgating event in the log instead of pretending the count is certain.
Why do the beams need debouncing?
A slow vehicle can flutter a beam edge. The firmware requires the break to persist past a debounce window before it counts as a real event.
Can it handle a real parking gate?
The counting and dashboard logic transfer directly; a real barrier needs proper actuators, safety loops and interlocks, which are out of student scope.
How accurate is the occupancy?
As accurate as lane discipline allows — every vehicle through the beams is counted directionally, and the nightly reconciliation procedure keeps drift from accumulating.
Is this project suitable for a final-year project?
Yes — for Electronics & Telecommunication, Electrical and IoT & Embedded programs. It is the canonical embedded counting problem done properly, with edge cases handled honestly. Suitable for B.E./B.Tech final-year projects in Electronics & Telecommunication, Electrical and IoT & Embedded Systems.
Components & software requirements
- ESP32 development board (Wi-Fi telemetry)
- 2x IR obstacle/beam sensor modules (direction pair)
- SG90/MG996R servo (boom barrier)
- 4-digit 7-segment display (gate count)
- Model barrier gate with striped boom arm (demo rig)
- Toy vehicles for demonstration
- Single-page parking dashboard (HTML/JS)
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.
Download free synopsis (PDF)
Enter your name and WhatsApp number — the synopsis PDF downloads immediately. We may send occasional project updates on WhatsApp; no spam.