SmartParking
Embedded sensing and automated access control
- Role
- Developer: firmware, sensor integration, control logic
- Year
- 2023
- Discipline
- Embedded Systems · IoT · Automation
- Context
- An Arduino-based occupancy and access-control system for parking facilities.
Most time spent in a car park is spent looking for the space, not using it. The information needed to eliminate that search, which bays are free, already exists physically. It just isn't being read.
This system reads it. Ultrasonic sensors monitor individual bays, a servo-driven barrier controls entry against live capacity, and a display surfaces availability at the gate. The engineering problem is not the concept but the sensors: they are noisy, they miss, and they are attached to a microcontroller with no room to be careless.
What madethis hard.
- 01
Ultrasonic sensors lie
Echo readings drop out, reflect off adjacent surfaces and drift with temperature. Reacting to raw values produces a display that flickers between states and a barrier that opens at random.
- 02
No room for a general-purpose runtime
Kilobytes of SRAM and no operating system. Dynamic allocation and blocking calls are not viable, so the control loop has to be flat, bounded and predictable.
- 03
A barrier is a moving object near people
The failure mode is physical. Actuation has to be interlocked against occupancy so the arm cannot close on a vehicle mid-transit.
- 04
Polling many sensors without stalling the loop
Ultrasonic ranging takes milliseconds per sensor. Reading them sequentially with blocking delays starves everything else the loop needs to do.
How Isolved it.
- 01
Filter before you trust
Each bay runs a rolling median over recent samples with hysteresis on the occupancy threshold, so a state change requires sustained agreement rather than one convenient reading.
- 02
An explicit state machine
Idle, vehicle detected, barrier opening, transit, barrier closing: enumerated states with defined transitions and timeouts, rather than nested conditionals that become unreadable at the third edge case.
- 03
Non-blocking scheduling
Sensor polling, display refresh and servo actuation run on independent millis-based intervals in a cooperative loop, so no subsystem can stall another.
- 04
Interlocked actuation
The barrier consults the transit sensor before closing and holds open while the path is occupied, with a timeout that fails to the safe state.
- 05
Telemetry over serial
Structured state output on the serial line, which makes the system debuggable on the bench and gives a dashboard something to consume later.
What itdoes now.
Stable per-bay occupancy detection under noisy sensor conditions via median filtering and hysteresis.
A deterministic state machine that makes barrier behaviour predictable and auditable.
A fully non-blocking control loop, with no delay() calls anywhere in the operational path.
Safety interlocks that fail to the open state rather than the closed one.
Hardware
- Arduino
- Ultrasonic Sensors
- Servo
- LCD
Firmware
- C++
- Embedded C
- State Machines
Techniques
- Median Filtering
- Hysteresis
- Non-blocking Loops
Interface
- Serial Telemetry
- LED Indicators
EmployeeManagement
A records system written in C++ without a framework or database underneath it, as an exercise in owning the class hierarchy, the persistence format and the memory, deliberately.
Read case study