What it proves
This project sits in the practical zone between electronics, firmware, and power systems. It required designing control behavior for a real vehicle platform, where reliability and debugging matter more than clean diagrams.
The conversion was not only about replacing an engine with an electric drive. The interesting part was building the control layer around it: access logic, signal routing, motor controller integration, and predictable behavior when the system is powered, armed, started, and tested on real hardware.
System architecture
RF keyless access and RFID logic were used as the entry point for enabling the vehicle electronics.
Arduino Nano firmware coordinated states, input signals, PWM behavior, and communication with the rest of the system.
The control electronics had to work near a real traction system, so noise, wiring, grounding, and fail states mattered.
Firmware behavior
The firmware treated the scooter as a state machine rather than a set of separate switches. It had to distinguish inactive, authorized, armed, and running states, react to RF/RFID input, and keep motor-control signals predictable instead of letting random input combinations reach the controller.
UART and PWM were used as practical embedded interfaces rather than demo features: UART for device-level communication and diagnostics, PWM for control signaling, and discrete inputs/outputs for vehicle behavior that had to be visible and testable on the bench before road tests.
Testing on real hardware
The main challenge was that every firmware decision affected a physical vehicle. Debugging meant checking code, wiring, voltage levels, connector reliability, and the actual response of the motor controller. This made the project closer to an embedded integration task than a clean isolated Arduino prototype.
Core responsibilities
- Implemented Arduino Nano firmware for embedded vehicle-control logic.
- Integrated RF keyless access and RFID-based interaction.
- Worked with UART, PWM, motor-control signals, and power electronics constraints.
- Tested and debugged firmware against physical hardware behavior.
- Structured vehicle behavior as clear states instead of loose independent switches.
- Validated control electronics through bench checks and practical ride testing.