The problem
When an electric scooter falls, a spinning rear wheel with power still on can injure the rider or others. Detecting a fall or crash quickly and isolating traction power, without false trips on potholes or kerbs, is a basic safety function.
Objectives
- Read acceleration and angular rate from the MPU6050 over I2C
- Estimate roll and pitch angles and acceleration magnitude
- Detect falls (sustained large tilt) and crashes (impact spike) with time qualification
- Cut power through the relay and latch until a deliberate reset
What you need
From the EV Embedded Development Kit
- STM32F103C8T6 microcontroller unit (Arm Cortex-M3)
- 3-axis accelerometer and gyroscope (MPU6050, I2C)
- General output relay (NO / COM / NC)
- 4×3 matrix keypad
- 16×2 LCD
- RGB LEDs and a buzzer
Software
- STM32CubeIDE with HAL I2C, GPIO and UART
- Embedded C
- Python with pandas and matplotlib to plot recorded motion and tune thresholds
Extra parts
None. Everything this project needs is on the kit.
Key concepts
- MPU6050 registers
- The device answers at I2C address 0x68, WHO_AM_I (0x75) returns 0x68, PWR_MGMT_1 (0x6B) wakes it, and acceleration data starts at 0x3B.
- Tilt from gravity
- When the vehicle is still, the accelerometer measures gravity, so roll is atan2 of the lateral and vertical components.
- Impact detection
- A crash shows as a short spike in acceleration magnitude well above 1 g; using the ±16 g range avoids clipping.
- Time qualification
- Requiring a condition to persist for a set time, such as tilt over 60 degrees for 1 s, rejects brief events like leaning into a corner or hitting a bump.
Step-by-step guide
- 1
Requirements
Define a fall as roll beyond about 60 degrees for more than 1 s, and a crash as acceleration magnitude above a threshold such as 4 g followed by low motion; tune these later from data. Power must be cut within a stated time and stay off until upright and a keypad code is entered. The relay stands in for the main contactor.
Checkpoint: A written requirement list with initial thresholds and a state diagram (Normal, Suspect, Tripped, Reset).
- 2
Board setup
Use the DIP switches to enable the MPU6050, the general output relay, keypad, LCD, RGB LEDs and buzzer. In CubeMX configure the 72 MHz clock, I2C1 at 400 kHz for the MPU6050, GPIO outputs for the relay and buzzer, the keypad rows and columns, a UART for logging and a timer for a 100 Hz sampling loop. Make the relay pin's reset state the safe state. Read WHO_AM_I to confirm the I2C link works.
Checkpoint: An I2C read of WHO_AM_I returns 0x68.
- 3
MPU6050 driver
Wake the MPU6050 by clearing the sleep bit in PWR_MGMT_1, set the accelerometer range to ±16 g (2048 LSB per g) and the gyro to ±500 °/s (65.5 LSB per °/s), and choose a digital low-pass filter setting. Every 10 ms read the 14 bytes starting at register 0x3B with HAL_I2C_Mem_Read, which gives acceleration, temperature and rate. Convert to milli-g and tenths of a degree per second, and handle I2C errors by retrying.
Checkpoint: At rest flat, the vertical axis reads about 1000 mg and the others near zero.
- 4
Calibration
Place the board at rest on each of its six faces for 2 s and record the accelerometer readings. From these compute the offset and scale for each axis so each face reads plus or minus 1000 mg on the vertical axis. Record the gyro reading at rest to get its bias. Store the calibration values in a constant table, or in SPI flash for a later version, and apply them to every sample before any further processing.
Checkpoint: After calibration, each face reads close to plus or minus 1000 mg on its axis.
- 5
Angle and magnitude
Compute roll and pitch with a complementary filter: integrate the gyro rate for short-term changes and correct slowly toward the accelerometer tilt to remove drift. Compute the acceleration magnitude from the three calibrated axes, which is about 1 g at rest and spikes during an impact. Show roll and magnitude on the LCD. Check the roll angle against a protractor at several tilts and note the error.
Checkpoint: Tilting the board to 45 degrees reads 45 within a few degrees and holds steady.
- 6
Detection logic
Implement the state machine. From Normal, enter Suspect when roll exceeds the fall threshold or the acceleration magnitude spikes above the crash threshold. From Suspect, go to Tripped if the tilt persists for the qualification time, or, for a crash, if motion settles after the spike; otherwise return to Normal. Log every transition with the triggering values so you can tune thresholds later from real data.
Checkpoint: Brief shakes return to Normal while a held tilt goes to Tripped.
- 7
Power cut and alerts
On entering Tripped, switch the relay to open the emulated traction circuit, flash the RGB LEDs red, sound the buzzer and show the cause, fall or crash, on the LCD. Toggle a spare GPIO at the moment of detection and at the relay command so you can measure trip-to-relay time on an oscilloscope or logic analyser. Make sure a reset of the MCU also leaves the relay in the safe state.
Checkpoint: Trip-to-relay time measured with a logic GPIO is within the requirement.
- 8
Reset procedure
Allow reset only when the board has been upright, within a small roll angle, for 3 s and the correct keypad code is entered. Refuse the code while tilted and show why on the LCD. Log each event over UART with its cause, the peak values, how long the system stayed tripped and how it was reset. This log is what a service engineer would read after an incident.
Checkpoint: Entering the code while tilted is refused; upright plus code restores power.
- 9
Test and tune
Record a set of events: normal handling, bumps and taps on the desk, a hand-held lean like cornering, and slow tip-overs onto a soft surface such as foam. Do not drop the kit. Plot the logged data in Python and tune thresholds so falls and impacts are separated from normal events. Run at least 20 trials of each type with the final thresholds and count detections and false trips.
Checkpoint: A test table of at least 20 trials per event type with detection and false-trip counts.
- 10
Report
Write up the requirements, the MPU6050 driver and calibration, the angle estimation, the detection state machine, the power-cut and reset logic, and the test results with the chosen thresholds and the data that justifies them. Discuss the limits of bench testing compared with a real vehicle, such as vibration and real crash dynamics, and how the thresholds would need to be revalidated on a scooter.
Checkpoint: Report and demonstration video.
Testing & validation
- WHO_AM_I and calibrated rest readings
- Tilt accuracy against a protractor at several angles
- Trip-to-relay response time
- Detection and false-trip counts over repeated trials
Expected results
A fall and crash detector that reliably cuts emulated traction power on a sustained tip-over or impact, ignores brief bumps, and needs a deliberate reset, with test data supporting the chosen thresholds.
Take it further
- Store event data before and after a trip in SPI flash with RTC timestamps
- Send a crash alert to a phone through a Bluetooth module add-on
- Train a small classifier on recorded data to reduce false trips
Viva and review questions
Why use the ±16 g range?
Impacts can exceed the smaller ranges and clip the reading, which would hide the true peak.
How do you avoid tripping when cornering?
Corner lean is brief and usually below the fall angle, and the time qualification requires the tilt to persist.
Why must reset need a code?
So power cannot return accidentally while the vehicle is still on its side or someone is lifting it.
What does the complementary filter do?
It combines the gyro, which is smooth but drifts, with the accelerometer, which is noisy but drift-free, to get a stable angle.