TinyML Machine Anomaly Detection using ESP32

Unplanned machine downtime is expensive, yet most small workshops cannot afford industrial condition-monitoring systems. Vibration is one of the earliest indicators of developing faults: bearing wear, imbalance and looseness all change a machine's vibration signature long before failure. TinyML makes it possible to run that analysis on a low-cost microcontroller: an ESP32 samples an accelerometer, runs a quantized neural network entirely on-device, and reports only anomalies instead of streaming raw data. This project builds that system around the MPU6050 accelerometer and a dense autoencoder trained on healthy vibration windows, with a web dashboard for live scores and event history. Because detection is unsupervised, the project needs no labeled fault recordings — the model only ever learns "healthy".

1. The MPU6050 streams 3-axis acceleration to the ESP32 over I2C while the machine runs normally; firmware logs healthy windows.
2. The training notebook converts windows to 24 features and trains a dense autoencoder to reconstruct healthy inputs.
3. The model is quantized to int8, converted to TensorFlow Lite Micro and flashed to the ESP32 with a calibrated threshold.
4. In operation, firmware extracts features per window, runs the autoencoder and computes reconstruction error as the anomaly score.
5. Scores below threshold mean normal operation; crossings light the on-board indicator and publish an MQTT alert.
6. The dashboard plots the live error curve against the threshold line and appends every event to the log.

Tech stack:

• ESP32 DevKit, MPU6050 accelerometer (I2C)
• TensorFlow Lite Micro (int8 quantized autoencoder)
• Arduino IDE / ESP-IDF (firmware)
• Python 3.10, TensorFlow/Keras (training notebook)
• MQTT (Mosquitto), HTML/CSS/JS web dashboard

• [On-device autoencoder inference] Quantized int8 dense autoencoder (24-16-4-16-24) running in TensorFlow Lite Micro on the ESP32, no cloud needed for detection
• [Vibration sensing pipeline] MPU6050 3-axis sampling over I2C with fixed windowing and 24-feature extraction (RMS, FFT-band energy, time-domain statistics)
• [Unsupervised anomaly scoring] Mean-squared reconstruction error as the anomaly score — trained only on healthy data, so no fault labels required
• [Live web dashboard] Real-time reconstruction-error curve with threshold line, anomaly score gauge, device status and event log
• [MQTT/Wi-Fi telemetry] Scores and window features published to a local broker; dashboard updates live
• [Threshold calibration procedure] Buyer-run routine that sets the detection threshold from the machine's own healthy baseline
• [Local alert output] On-board indicator and optional OLED display showing live status without the dashboard
• [Artificial-fault demo procedure] Documented method to introduce a controlled imbalance and watch the detector flag it

• Complete ESP32 firmware source (sensor driver, feature extraction, TFLite Micro inference, MQTT)
• Python training notebook (feature pipeline, autoencoder training, quantization, threshold calibration)
• Live web dashboard (error curve, threshold, gauge, event log)
• Wiring diagram and component list
• Project report PDF (TinyML background, model design, quantization, evaluation, honest scope)
• PPT presentation for final review
• Viva Q&A preparation document (autoencoders, quantization, I2C, MQTT, anomaly scoring)
• Setup and calibration guide (collecting baseline, setting threshold, fault-demo procedure)

• Detection is only as good as the healthy baseline: if the training data includes faulty operation, the model learns it as normal — the calibration guide stresses clean baseline collection.
• The autoencoder flags that something changed, not what changed: it cannot name the fault type (bearing vs imbalance) without labeled data, which is documented future scope.
• Sensor mounting matters enormously: loose mounting or a different machine position changes the signature, so the threshold must be recalibrated per installation.
• Wi-Fi range and reliability bound the dashboard telemetry; core detection keeps running on-device even if Wi-Fi drops, but events will not reach the dashboard until reconnect.
• This is an academic prototype, not certified industrial condition-monitoring equipment.