Embedded Systems / Mechatronics
—
2024
Smart Vehicle Safety System
My Role
Individual project — complete system design, electronics, firmware, interface and integration.
Project Type
Individual University Mechatronics Project
University Subject
41099 Introduction to Mechatronics Engineering
Tools & Technologies
Arduino · C/C++ · LCD · Joystick · Potentiometer · Rain Sensor · Collision Sensor · Buzzer · Tinkercad
Team Context
Individual project.
Overview
The Smart Vehicle Safety System was designed around a simple question: how could useful modern vehicle features be recreated as a low-cost embedded prototype for older or budget vehicles?
A joystick simulated steering input for turn signals, a potentiometer acted as the manual wiper control, a rain sensor enabled automatic wiper behaviour and a collision sensor triggered hazard lights and an audible warning. An LCD provided feedback about wiper mode, automatic operation and turn-signal state.
My Contribution
What I owned
This was an individual project, so I was responsible for the complete system: concept development, subsystem selection, wiring, firmware, calibration, interface design, debugging and final integration.
I created custom turn-signal graphics for the LCD, tuned joystick dead zones, introduced hysteresis to stabilise analogue inputs and implemented averaging / debounce behaviour to reduce sensor noise.
When the physical LCD failed late in development, I verified remaining interface behaviour through Tinkercad simulation so one hardware failure did not stop the entire project.
The Challenge
The main challenge was integration. Manual wiper control, automatic rain response, turn signals, braking, collision alerts and the display all shared the same microcontroller.
Analogue sensors also produced noisy values. Without calibration and filtering, a stationary joystick could appear to move, potentiometer values could fluctuate between modes and rain-sensor readings could cause unstable wiper behaviour.
Constraints
Single Arduino-based controller.
Multiple sensors, controls and outputs operating together.
Analogue input noise and calibration uncertainty.
Joystick required a reliable centred dead zone.
Wiper modes needed stable switching.
Rain sensing had to map values into useful automatic speeds.
Collision detection needed to override normal behaviour.
LCD hardware failure occurred late in the project.
Repeated debugging and tutor design approvals were required.
System & Design Development
How the system took shape
System Architecture
Joystick input
→ left / right indicators
→ red brake-light state when braking
Potentiometer / wiper dial
→ manual low, intermediate and high wiper modes
Rain sensor
→ automatic rain detection
→ automatic wiper speed selection
Collision sensor
→ hazard-light activation
→ buzzer warning
System state
→ LCD
→ wiper mode, automatic status and turn-signal graphics
Design Process
The system was broken into user input, wiper actuation, lighting, collision response and display output.
Custom arrow graphics were created for the LCD using `createChar()`. The joystick required a dead zone. The potentiometer replaced an earlier push-button approach and required hysteresis so small analogue fluctuations did not repeatedly change the wiper mode.
Rain sensing was mapped to automatic wiper behaviour and refined using averaging and debounce-style logic. The final stage was coordinating all states so safety functions, manual controls and interface output remained consistent.
Key engineering decisions
Replace a push button with a potentiometer
A potentiometer better represented a real vehicle wiper dial and supported multiple speed states from one input. Hysteresis was added so values near a boundary did not cause rapid mode switching.
Treat sensor noise as a system-design problem
Averaging, dead zones and debounce-style logic were introduced so the software responded to meaningful state changes rather than electrical noise.
Use collision detection as a system-level override
Collision detection activates both hazard lights and the buzzer so the warning is immediate and not treated as just another display value.
Testing & iteration
Joystick calibration was adjusted until indicator LEDs stayed off at centre. Potentiometer thresholds were tuned to prevent mode chatter. Rain-sensor behaviour was tested across different values.
LCD graphics were iterated until the turn arrows were clear. When the LCD failed, Tinkercad was used to continue software verification.
Final outcome
The project moved beyond a simple Arduino demonstration and became an integrated mechatronic system with sensing, decision logic, actuation and interface output.
Results & Measurements
The completed system integrated manual wiper selection, automatic rain-responsive wipers, turn signals, braking lights, collision-triggered hazards, buzzer warning and LCD feedback.
Limitations
The project was a scaled prototype rather than an automotive-certified system. Real implementation would require automotive-grade sensing, protection, actuation, durability and safety compliance.
Part of final interface verification relied on simulation after the LCD hardware failed.
Reflection
The project taught me that embedded-system difficulty often comes from interactions between components rather than any single component.
I initially underestimated debugging and calibration time. Analogue noise, joystick drift, custom LCD graphics and the failed display forced me to use a more structured debugging process and adapt when the original plan became impossible.
Project Links