TinyML Model Drift on Microcontrollers

ISEF Category: Embedded Systems

Subcategory: Other  ·  Difficulty: Advanced  ·  Setup: University Lab  ·  Time: Full Year

The Hook

Two chips running the same model can give different answers after days of use. That sounds like a software bug, but it can also be a hardware and power issue. If you care about TinyML on real devices, you need to know whether the model stays steady over time. Your project can test that with data, not guesswork.

What Is It?

TinyML means machine learning on tiny devices, like microcontrollers. These chips have little memory, low power, and no fancy operating system. A TFLite-Micro audio classifier is a small model that listens to sound and sorts it into labels, like clap, noise, or speech. Your job is to see whether that same model behaves the same way on different chips, and whether its results stay stable during long continuous use.

Think of it like five cooks using the same recipe, but each cook has a different stove. The recipe is the model. The stove is the MCU, or microcontroller unit. Even if the code stays the same, the timing, power draw, and even accuracy can shift because each board handles memory, math, and thermal load a little differently. Over a 30-day run, tiny changes can stack up. That makes reproducibility, the ability to get similar results again, a real research question.

Why This Is a Good Topic

This is a strong science fair topic because you can measure it, compare it, and repeat it. You have clear variables, like board type, runtime, and power state. You also have useful outputs, like accuracy, latency, and energy use. That connects to real problems in wearables, smart home devices, health monitors, and edge AI systems that must work reliably for a long time.

Research Questions

• How does MCU type affect audio classification accuracy over a 30-day continuous run?
• How does MCU type affect inference latency for the same TFLite-Micro model?
• What is the effect of long-term runtime on energy use per inference?
• Does continuous operation cause accuracy drift across identical devices of the same MCU family?
• To what extent does ambient temperature correlate with latency drift during long runs?
• Which audio classes show the largest performance drift across boards?

Basic Materials

• Five popular microcontroller boards with comparable support for TFLite-Micro.
• USB data cables for each board.
• Laptop or desktop computer for code upload and data logging.
• Microphone module or audio input source matched to the boards.
• Stable power supplies or powered USB hubs.
• Digital multimeter with current measurement.
• Power monitoring board or USB power meter.
• Clock or timestamped logging system.
• Quiet test environment with repeatable audio playback.
• Notebook or spreadsheet for logging board conditions.

Advanced Materials

• Five popular microcontroller boards with detailed datasheets.
• Precision power analyzer for current and voltage measurement.
• Audio playback speaker with known output characteristics.
• Calibrated microphone and acoustic reference source.
• Environmental sensor for temperature and humidity.
• Oscilloscope or logic analyzer for timing verification.
• SD card module or serial logger for long-run data capture.
• Reference laptop for dataset management and analysis.
• Heat sink or enclosure components for thermal consistency tests.
• Reference audio dataset for controlled validation runs.

Software & Tools

• TFLite Micro: Runs the audio classifier on each microcontroller and keeps the model identical across boards.
• Python: Cleans logs, computes drift metrics, and runs statistical tests.
• ImageJ: Not needed for this project, so skip it unless you add visual inspection of hardware setup photos.
• Arduino IDE: Uploads firmware and helps you manage board-specific builds.
• Jupyter Notebook: Organizes analysis, plots trends, and documents each comparison.
• Google Sheets: Tracks daily measurements and helps you spot missing or inconsistent entries.

Experiment Steps

1. Define one audio task and one model architecture, then keep both fixed across every board.
2. Choose the performance metrics you will compare, such as accuracy, latency, and energy per inference.
3. Plan a repeatable test schedule that lets you compare boards under the same input conditions across the full run.
4. Set up controls that separate model drift from board drift, including identical firmware, logging, and power conditions.
5. Build a data pipeline that stores raw outputs, timestamps, and board metadata in one place.
6. Pre-plan your statistics so you can compare drift within each board and across boards without changing the rules midstream.

Common Pitfalls

• Changing the audio input source between test days, which makes accuracy shifts impossible to separate from input drift.
• Letting each board run with slightly different firmware builds, which turns a hardware comparison into a code comparison.
• Measuring power with a different meter or wiring setup on each board, which breaks energy comparisons.
• Ignoring board temperature and enclosure differences, which can distort latency and current draw over long runs.
• Logging only summary results instead of raw inference outputs, which makes it hard to check whether drift came from the model or the measurement pipeline.

What Makes This Competitive

A strong version of this project does more than compare average numbers. You can track drift over time, test whether one board degrades faster than another, and separate random noise from real change. Better analysis would include confidence intervals, repeated trials, and a fair test design that keeps firmware, audio inputs, and logging identical. If you also connect the results to power management or thermal behavior, your project becomes much deeper.

Project Variations

• Compare audio classifiers across boards using wake word, keyword spotting, or sound event detection tasks.
• Test whether battery power versus USB power changes latency drift and energy stability over time.
• Add temperature as a second variable and compare whether warmer boards lose accuracy faster.

Learn More

• TensorFlow Lite Micro documentation: Learn how TinyML models run on microcontrollers and find setup details in the official TensorFlow docs.
• MIT OpenCourseWare: Search for embedded systems or machine learning on the edge materials to build background on MCU constraints.
• NIH PubMed: Search for review articles on edge AI, embedded inference, or long-term sensor reliability.
• NASA Technical Reports Server: Search for embedded systems reliability and low-power onboard processing reports.
• IEEE Xplore: Look for peer-reviewed papers on TinyML benchmarking, model drift, and microcontroller inference performance.