The proposed system is an intelligent parking assistant designed to monitor the rear of a vehicle using three reference points. The goal of the project is to prevent collisions by providing real-time visual, auditory, and numerical feedback.

Utility: Helps drivers estimate distance in blind spots.
Differentiator: Unlike basic systems, it uses three sensors to cover the entire width of the bumper (left, center, right).

The system reads distance data from three ultrasonic sensors and processes it using the ATmega328P microcontroller.

Features:

• Visual feedback: 3 RGB LEDs that change color (Green → Yellow → Red) depending on the proximity of obstacles for each zone.
• Auditory feedback: A passive buzzer that emits intermittent beeps, with frequency increasing as the car approaches an object.
• Display: The LCD shows the distance in centimeters for each of the three zones (L: XX cm | C: XX cm | R: XX cm).

Component List:

Electrical Diagram:

Component Justification

The HC-SR04 ultrasonic sensor was selected for distance measurement due to its operating range (2–400 cm), which perfectly covers the rear parking use case. It is also low-cost and features a simple TRIG/ECHO interface that is directly compatible with the GPIO pins of the ATmega328P. Using three sensors (left, center, right) provides full spatial coverage of the area behind the vehicle and enables detection of lateral obstacles that would not be visible with a single central sensor.

The RGB LEDs (common cathode) were chosen to provide intuitive visual feedback. They allow color-coded signaling (green → yellow → red), which is universally recognized in parking and safety systems. Compared to single-color LEDs, RGB LEDs reduce the number of physical components while enabling multiple states to be displayed for each sensing zone.

The passive buzzer was selected for auditory feedback because it allows control over the frequency of the emitted sound. This makes it possible to vary the beep rate depending on the distance to the obstacle. In contrast, an active buzzer would only produce a constant tone, limiting the ability to convey proximity information dynamically.

The 16×2 LCD with I2C interface was chosen to display numerical distance values for each zone. This provides precise, easy-to-read feedback similar to a dashboard display. The use of an I2C adapter significantly reduces the number of required microcontroller pins compared to parallel communication (4- or 8-bit mode), simplifying wiring and leaving more pins available for other components.

The firmware is built around a non-blocking main loop that coordinates four main tasks: collecting distance data from three ultrasonic sensors, controlling three RGB LEDs for visual feedback, driving a passive piezo buzzer for audio alerts, and updating a 16×2 I²C LCD display.

To keep the system responsive, sensor measurements are handled asynchronously using interrupts, so the CPU never sits idle waiting for an echo pulse. The buzzer also runs on its own timing scheduler based on millis(), which means the beep pattern remains smooth and independent from the sensor update rate.

The program logic is based on calculating the round-trip time of the sound signal:$$Distance = \frac{Time \times Speed of Sound}{2}$$

The firmware is split into five logical modules:

1. HC-SR04 Driver (Interrupt-Based)
   1. Each ultrasonic sensor is represented by a structure containing pointers to its TRIG and ECHO registers along with the associated bit positions.
   2. Sending the trigger pulse is straightforward: a synchronous 10 µs pulse is applied to the TRIG pin. The actual echo timing, however, is handled entirely through Pin Change Interrupts (PCINTs), allowing the CPU to continue running other tasks while the sensor responds.
   3. Because the three ECHO pins are connected to different ports (PD4, PB0, and PC1), they use separate interrupt vectors.
   4. Each ISR records the timestamp from micros() when the echo signal rises, then calculates the pulse duration when the signal falls. Once the measurement is complete, a volatile bool ready flag is set so the main loop knows fresh data is available.
2. Exponential Moving Average Filter
   1. Raw HC-SR04 measurements naturally fluctuate by about ±1–2 cm because of acoustic noise, reflections, and air movement. To stabilize the readings, each sensor output is filtered using a first-order Exponential Moving Average (EMA): y[n]=αx[n]+(1−α)y[n−1].
   2. The smoothing factor was chosen experimentally as: α=0.5
   3. This value provided a good balance between responsiveness and stability. In practice, the system reacts to genuine distance changes within roughly 500 ms while ignoring most isolated spikes and noisy readings.
3. LED State Machine with Asymmetric Hysteresis
   1. Each RGB LED behaves as a simple three-state machine: Green — safe distance; Yellow — caution; Red — critical proximity.
   2. The state transitions are based on the filtered sensor distance. Moving toward a more urgent state happens immediately once a threshold is crossed, while returning to a safer state requires the distance to exceed the threshold by an additional 1 cm margin.
   3. The LEDs are driven using digitalWrite() on the red and green channels. PWM-based color blending was tested early in development, but later removed because of timer conflicts with the buzzer subsystem.
4. Adaptive Buzzer Driver
   1. The buzzer always reacts to the minimum distance detected across all three sensors, since even one nearby obstacle should trigger an alert.
   2. That minimum distance controls two things simultaneously: Beep period — interpolated from 600 ms at 30 cm down to 80 ms at 10 cm; Tone frequency — interpolated from 1500 Hz to 2048 Hz. The higher frequency corresponds to the buzzer module’s resonant frequency, which produces the loudest output according to the datasheet.
   3. Once the measured distance drops below 10 cm, the buzzer switches to a continuous 2048 Hz tone.
   4. The actual waveform generation is handled by Arduino’s tone() function, which configures Timer2 in CTC mode and toggles the buzzer pin (A0) inside the TIMER2_COMPA_vect ISR. The higher-level beep scheduling uses millis(), keeping the implementation fully non-blocking.
5. LCD Driver
   1. The LCD updates every 100 ms and displays the filtered distances in a compact two-line layout: L:<dist>cm C:<dist>cm\nR:<dist>cm Min:<dist>
   2. Each value is formatted as a fixed-width, right-aligned field so changing numbers overwrite cleanly without leaving visual artifacts. If a reading is invalid or out of range, the display shows —.

Algorithm structure:

1. Initialization: Configure I/O pins, timers for the buzzer and sensors, and LCD interface.
2. Main loop:
   1. Sequentially trigger Sensor 1, then 2, then 3 (to avoid interference).
   2. Calculate distance for each sensor.
   3. Update LED states.
   4. Compute buzzer “beep” frequency based on the smallest detected distance.
   5. Update LCD display.

The first version of the project measured echo duration using a busy-wait loop around TCNT1. While functional, this approach blocked the CPU and tied up Timer1 completely.

Moving to Pin Change Interrupts solved both issues: the CPU remains free while measurements occur in the background, and Timer1 is now available for future extensions.

An earlier implementation used PWM to create smooth color transitions between green, yellow, and red. In practice, this introduced visible glitches because the LEDs relied on timers shared with the buzzer subsystem.

Specifically, Timer2 is also used by tone(), so activating the buzzer interfered with PWM outputs on pins such as D3 and D11.

The final design uses three discrete LED states with hysteresis. Although this sacrifices continuous color gradients, it results in clearer feedback and avoids timer conflicts entirely.

The system achieves an accuracy of approximately 1–2 cm. The interface is intuitive, allowing the driver to quickly identify which part of the car is closest to an obstacle.

The implementation on the ATmega328P demonstrates efficient handling of multiple sensors simultaneously using interrupts and timers. The project is scalable and can be integrated into any small vehicle.