Overspeed and Harsh-Acceleration Alert System

The problem

Fleet operators of electric two- and three-wheelers want riders to keep to speed limits and avoid harsh manoeuvres that waste energy, wear tyres and cause accidents. A simple on-board alert gives immediate feedback without needing a connected back end.

Objectives

• Emulate vehicle speed from the potentiometer and set a speed limit from the keypad
• Detect overspeed with hysteresis and time qualification
• Detect harsh acceleration and braking from filtered MPU6050 data
• Give graded alerts and count events per trip

What you need

Key concepts

Emulated speed

The kit has no speed sensor, so the potentiometer position is mapped to 0–100 km/h as a stand-in for a wheel-speed signal.

Hysteresis

Overspeed turns on above the limit and turns off only a few km/h below it, so the alert does not flicker at the threshold.

Longitudinal acceleration

With the board's x-axis aligned forward, the accelerometer's x reading minus the gravity component from tilt is the vehicle's acceleration.

Harsh event threshold

A starting value around 0.3 g for harsh braking or acceleration is common in telematics, but it should be tuned for the vehicle type.

Step-by-step guide

1. 1

   Requirements

   Write the rules before coding. The default speed limit is 50 km/h and can be set from 20 to 90 km/h on the keypad. An overspeed warning starts after 2 s above the limit, and an urgent alert sounds at the limit plus 10 km/h. Harsh acceleration and harsh braking start at about ±0.3 g sustained for 300 ms, to be tuned from data. List the alert pattern for each event: buzzer tone, RGB colour and LCD text.

   Checkpoint: A requirement table and a list of alert patterns (tone, colour, LCD text).

2. 2

   Board setup

   Use the DIP switches to enable the MPU6050, potentiometer, keypad, LCD, RGB LEDs and buzzer. In CubeMX configure the 72 MHz clock, I2C at 400 kHz, ADC with DMA on the pot, the keypad rows and columns, a timer for buzzer tones and a timer for a 50 Hz main loop. Build a test program that reads WHO_AM_I from the MPU6050 and prints the pot value, to confirm the hardware before adding logic.

   Checkpoint: MPU6050 WHO_AM_I reads 0x68 and the pot reads across its range.

3. 3

   Speed emulation

   The kit has no speed sensor, so map the filtered potentiometer value to 0–100 km/h as the emulated vehicle speed. Limit how fast the emulated speed may change to a realistic acceleration for an electric scooter, so that spinning the pot quickly does not create impossible jumps in speed. Show the speed on the LCD and log it, and state clearly in the report that speed is emulated rather than measured.

   Checkpoint: LCD speed follows the pot smoothly and stays within realistic rates of change.

4. 4

   Acceleration measurement

   Configure the MPU6050 at ±2 g with its low-pass filter enabled, calibrate it on a level surface, and align the board so its x-axis points forward. Filter the forward axis further with a low-pass filter around 2 Hz to remove vibration, and subtract the gravity component using the tilt measured at rest. Slide the board forward and stop it sharply to check that acceleration and braking give clear positive and negative peaks.

   Checkpoint: Sliding the board forward and stopping it gives clear positive and negative peaks.

5. 5

   Overspeed logic

   Implement overspeed as a timer-qualified state: start counting when the speed exceeds the limit and raise the warning after 2 s; clear it only when the speed falls 3 km/h below the limit, which is the hysteresis. Add the urgent level at the limit plus 10 km/h. Let the rider set a new limit on the keypad with * to start entry and # to confirm, and reject values outside 20–90 km/h.

   Checkpoint: Exceeding the limit for 2 s triggers the warning, and dropping 3 km/h below clears it.

6. 6

   Harsh event logic

   Detect harsh acceleration and harsh braking when the filtered forward acceleration exceeds the threshold for the qualification time. After each event apply a 2 s hold-off, so one long manoeuvre is not counted several times. Keep separate counters for each event type per trip, and record the peak acceleration of each event. Test with ten deliberate harsh movements and ten gentle ones and check the counts.

   Checkpoint: Ten deliberate harsh movements give ten counted events and gentle movements give none.

7. 7

   Alerts and display

   Give each alert a distinct pattern: a slow beep and amber LED for overspeed, a fast beep and red LED for urgent overspeed, and a short double beep with a purple flash for a harsh event. Show the speed, the limit and the event counts on the LCD. Ask someone who has not seen the code to identify each alert without looking at the LCD, as a simple usability check, and note what confused them.

   Checkpoint: Each alert type is recognisable without looking at the LCD.

8. 8

   Test and document

   Run a scripted test list covering every rule: overspeed timing, hysteresis, urgent level, limit entry, each harsh event type and the hold-off. Log the data during the tests and use the plots to tune the thresholds, then rerun the whole list with the final values. Write up the design, the tests and how the thresholds were chosen, and include a short demonstration video.

   Checkpoint: A completed test table and a short report with a demonstration.

Testing & validation

• Speed emulation rate limit
• Overspeed timing and hysteresis tests
• Harsh-event detection counts for deliberate and gentle movements

Expected results

A working alert unit that warns of overspeed and harsh manoeuvres with clear graded feedback and per-trip event counts, using emulated speed and real accelerometer data.

Take it further

• Log events with RTC timestamps to SPI flash
• Derive acceleration from emulated speed and compare it with the accelerometer
• Send trip summaries to a phone via a Bluetooth module add-on

Viva and review questions