Predictive Maintenance from Motor Vibration Signatures

The problem

Motor and drivetrain faults in EVs, such as bearing wear, imbalance and mounting looseness, show up in vibration long before failure. Detecting them early reduces downtime for fleets, but it must run on low-cost embedded hardware with limited computing power.

Objectives

• Drive a DC motor at controlled PWM duty cycles and record vibration on the MPU6050.
• Create repeatable fault conditions: added imbalance mass and loosened mounting.
• Extract spectral features and build a healthy baseline and a fault classifier.
• Implement detection on the STM32 and compare with a simple RMS threshold.

What you need

Key concepts

1× running-speed component

Imbalance produces vibration at the shaft rotation frequency. Its amplitude grows with the imbalance mass and the square of speed.

Harmonics and looseness

Mechanical looseness produces several harmonics of running speed and a raised noise floor, unlike the single clean 1× peak of imbalance.

Fixed-point FFT

CMSIS-DSP provides Q15 FFT functions such as arm_rfft_q15 that run fast on the Cortex-M3 without an FPU, with scaling that must be tracked to keep amplitudes comparable.

Novelty detection

Learning only what healthy looks like and flagging departures, useful when examples of every fault are not available.

Step-by-step guide

1. 1

   Build the mechanical rig

   Fix the motor in its bracket on a rigid plate together with the kit, so vibration travels to the board, and fit a light disc on the shaft. Make sure nothing can fly off: tighten masses well, keep fingers and cables clear and run at modest speeds. Connect the motor to the motor driver block per the kit documentation, turning on only its DIP switches and those for the MPU6050, LCD and UART.

   Checkpoint: The motor runs smoothly at a low duty cycle and the rig does not move on the bench.

2. 2

   Configure PWM speed control

   Set a timer (for example TIM1 or TIM3) for PWM at around 20 kHz so the switching is above hearing, and drive the motor driver's inputs. Map the potentiometer through the ADC to duty cycle for manual tests and add UART commands for fixed duty steps. Because no speed sensor is fitted, find the running frequency from the vibration spectrum itself (the 1× peak) and note it for each duty setting.

   Checkpoint: Motor speed changes smoothly with duty, and each step can be repeated from a UART command.

3. 3

   Set up high-rate vibration sampling

   Configure the MPU6050 over I2C at 400 kHz with the accelerometer at 1 kHz output (DLPF set accordingly, SMPLRT_DIV adjusted) and read it through the FIFO in bursts to avoid missing samples. Collect blocks of 1,024 samples. Check sample timing by counting FIFO entries against a timer. At 1 kHz you can see components up to about 500 Hz, which covers 1× and several harmonics for a small motor at moderate speed.

   Checkpoint: Complete 1,024-sample blocks with no FIFO overflow and a measured sample rate close to 1 kHz.

4. 4

   Record healthy and fault data

   Record at several duty cycles: healthy, two or three imbalance sizes (add masses to the disc), and looseness (slightly loosen one bracket screw, safely). Repeat each condition several times on different days, re-assembling the rig, to capture normal variation. Stream raw blocks to the PC over UART with labels. Keep a log sheet of mass size, position, screw state and duty for every recording, and always stop the motor before changing masses.

   Checkpoint: A labelled dataset covering every condition and speed, with at least ten blocks per combination.

5. 5

   Analyse spectra and choose features

   In Python compute spectra with a Hann window, find the 1× peak and its harmonics, and plot them for each condition. Choose features: 1× amplitude, 2× and 3× amplitudes, band energy around harmonics, overall RMS and spectral kurtosis. Normalise imbalance features by speed squared where useful. Check which features separate conditions across speeds. Also plot how each feature changes with duty cycle, because a feature that depends strongly on speed needs normalising.

   Checkpoint: Feature plots showing separation of healthy, imbalance and looseness at several speeds.

6. 6

   Build the baseline and classifier

   Fit a healthy baseline as the mean and covariance of healthy features per speed band and use the Mahalanobis distance as a health index. Train a decision tree or logistic regression for fault type. Validate by session so test data come from a re-assembly the model has not seen. Compare with a plain RMS threshold baseline. Report the threshold chosen for the health index and how it was set.

   Checkpoint: Detection rate, false alarm rate and fault-type accuracy for each method, split by session.

7. 7

   Implement detection on the STM32

   Apply a Q15 Hann window and arm_rfft_q15 to each block, compute magnitudes and the selected features in fixed point, then the health index and classifier output. Verify against Python on replayed blocks. Measure time per block with the DWT counter; it should be well under the one-second block period so detection runs continuously. Keep the CMSIS-DSP scaling shifts documented, because they change absolute amplitudes and must match the thresholds learned in Python.

   Checkpoint: Firmware features within a stated tolerance of Python, and processing time per block measured.

8. 8

   Run live condition monitoring

   Show health index and fault type on the LCD and RGB LED, sound the buzzer on a confirmed fault (for example three blocks in a row), and log results over UART. Run live tests where you add or remove a mass with the motor stopped and check the system's response after restart. Include speed changes to test robustness. Record each live run so the results can be checked later against raw data.

   Checkpoint: Correct live detection of every fault condition with no alarms in a long healthy run.

9. 9

   Report quantified results

   Present the rig, the data, the features, the models and the embedded implementation with timing and memory. Report detection results against the RMS baseline with session-based validation. Discuss limits: a small brushed motor on a bench differs from an EV traction motor, and bearing faults were not created. Include photographs of the rig, the feature definitions, the dataset description and a short note on how the method would scale to a traction motor.

   Checkpoint: A results chapter and a live demo.

Testing & validation

• Measured sample rate and no FIFO overflow during long runs.
• Session-wise validation of detection and fault-type accuracy.
• Comparison with an RMS-threshold baseline.
• Firmware features checked against Python on the same data.

Expected results

A working vibration-based condition monitor on the kit that detects imbalance and looseness on a small motor, with quantified detection performance against a simple baseline and measured embedded cost.

Take it further

• Add an encoder motor to measure speed and use order tracking.
• Add motor current sensing through an INA219 to fuse electrical and vibration features.
• Send health status over CAN.
• Study detection under varying load on the motor shaft.

Viva and review questions