In this guide
Best 10 TinyML & Edge AI Projects
Most AI demos run in the cloud, but the interesting engineering happens at the edge: a microcontroller that hears a keyword without a network connection, a camera that counts vehicles without streaming video anywhere, a wearable that detects a fall and raises an alarm on its own. TinyML (machine learning on microcontrollers) and edge AI (ML on small computers like the Raspberry Pi and Jetson Nano) are the most hardware-honest way to do an AI project — you cannot hide behind infinite cloud compute, so you learn quantization, model sizing, power budgets, and real-time constraints for real. This list collects ten builds that exist as published project listings on projectech.in, chosen for three reasons: each one runs its intelligence on the device itself (no cloud dependency for the core function), each has a crisp technical scope (one sensor, one model, one output), and each demos as a physical thing you can hold — which is a different and stronger impression than a notebook. The set spans microcontrollers (ESP32-class keyword spotting, cry detection, vibration sensing) and single-board computers (Pi and Jetson counting, compost and bird monitoring). If you like your AI with wires attached, start here.
1. Edge AI Vehicle Counter on Raspberry Pi
Traffic surveys are still done by people with clickers standing at intersections — expensive, inconsistent, and impossible to run around the clock. This project replaces the clicker with a Raspberry Pi and a camera: a lightweight detection model counts vehicles passing through a region of interest, classifies them (car, bike, truck, bus), and logs counts over time. The real problem is continuous traffic data for signal timing, road planning, and pollution studies. The technical design is detection plus tracking on constrained hardware: a small YOLO or MobileNet-SSD detector exported to run on the Pi (TFLite or ONNX Runtime), a centroid or SORT-style tracker to avoid double-counting the same vehicle across frames, and a counting line or zone in the frame. Frame-rate budgeting is the core engineering — the Pi 4/5 handles a small detector at a few to low-teens FPS, which is enough for counting if the tracker is tuned. Students learn the full edge pipeline: model selection for the hardware, quantization to int8, camera setup and mounting, region-of-interest configuration, and a simple dashboard or CSV log of counts. The demo is a recorded or live traffic clip with a running count overlay. Students pick it because the civic application is obvious, the hardware is one affordable board, and the report gets a clean architecture (camera, detector, tracker, logger). The honest limitation: night footage and heavy occlusion degrade counts, and the report should present the numbers as estimates validated against manual counts, not ground truth.
2. TinyML Keyword Spotting on Microcontroller
Every smart speaker listens for its wake word locally before it ever talks to the cloud — and that always-on listening has to run on milliwatts. This project builds exactly that: a microcontroller (ESP32 or an Arduino Nano 33 BLE Sense) that continuously listens through a microphone and wakes up when it hears a target keyword. The real problem is private, low-power voice interfaces — devices that respond to voice without streaming audio to a server. The technical core is a tiny neural network (a depthwise-separable CNN on mel-spectrogram or MFCC features, typically under 100KB after quantization) trained on the Google Speech Commands dataset plus your own recorded keyword samples, converted with TensorFlow Lite for Microcontrollers and deployed to the board. Students learn the defining TinyML skills: audio feature extraction on-device, int8 quantization, measuring inference latency and current draw, and the streaming-audio pipeline (overlapping windows, a small ring buffer, debouncing so one utterance triggers once). The demo is the classic one — say the keyword, watch the LED light up — and it works with no network, which is the whole point. Students pick it because it is the canonical TinyML project, the dataset is standard, and the power story (measure the milliamps, compute battery life) gives the report real engineering numbers. The honest limitation: a handful of keywords in quiet rooms; background noise and similar-sounding words cause false triggers, and the evaluation should measure both.
3. Bird Feeder Species Logger on Raspberry Pi
Birdwatchers keep life lists by hand, and ecologists need long-term presence data that nobody has time to collect. This project automates it: a Raspberry Pi with a camera watches a bird feeder, detects visiting birds, classifies the species, and logs each visit with a timestamp and a photo. The real problem is continuous, non-invasive wildlife monitoring — the same idea scales to camera-trap ecology. The technical stack is detection plus classification on the Pi: a lightweight detector finds the bird in the frame (or motion triggers capture), and a classifier trained on a bird-species dataset (CUB-200 or a regional dataset, fine-tuned MobileNet/EfficientNet-Lite) identifies it, with results stored in a local database and optionally a small web dashboard. Students learn transfer learning for fine-grained classification (species that look alike are a harder problem than generic object detection), the motion-trigger pipeline that saves power and storage, and how to handle the long tail of rare visitors. The demo is delightful — a feeder log with photos and species names — and the project has a natural citizen-science framing for the report. Students pick it because it combines vision, embedded deployment, and a genuinely charming application. The honest limitation: similar species get confused, poor light hurts, and the classifier only knows the species it was trained on — a new visitor is logged as unknown, which the report should present as correct behaviour, not a bug.
4. Edge AI People Counter on Jetson Nano
Shops, malls, and event venues need to know footfall — how many people entered, when the rush hours are, whether a promotion worked — and camera-based counting beats manual tallies and break-beam sensors that cannot distinguish direction or groups. This project builds a people counter on the NVIDIA Jetson Nano: a camera feed runs a person detector accelerated by the Nano's GPU, a tracker follows individuals across frames, and entries and exits are counted at a virtual line or zone. The real problem is retail and venue analytics without cloud video upload — everything processes on the device, which also answers the privacy objection to cloud cameras. The technical core is a detector (YOLO or SSD variant) exported to TensorRT for the Nano's GPU, plus a lightweight tracker (SORT or ByteTrack-style association) and direction logic at the counting line. Students learn the Jetson workflow specifically: flashing JetPack, TensorRT engine building, power modes, and the thermal reality of sustained inference on a small board. The demo shows a live count with in/out numbers on screen. Students pick it when they want the GPU-accelerated edge story (a step up from the Pi builds) and a retail-analytics framing for the report. The honest limitation: dense crowds with heavy occlusion are undercounted, and the report should validate against manual counts during a test period rather than claim turnstile accuracy.
5. Smart Compost Monitor Using Edge AI
Composting fails most often from neglect, not chemistry — the pile goes anaerobic because nobody turned it when temperature and moisture drifted out of range. This project builds a monitor that watches the pile for you: temperature, humidity, and gas sensors feed a small edge device, and a lightweight ML model predicts compost state (healthy, needs turning, too wet, too dry) and sends an alert. The real problem is making home and community composting actually work — the process is simple but the monitoring is tedious. The technical design pairs sensor fusion with a tiny classifier or regressor: a DHT22/SHT-series sensor for temperature and humidity, an MQ-series gas sensor for ammonia/CO2 proxies, and a model (even a small decision tree or a tiny neural net) trained on labelled compost-state data, running on an ESP32 or Pi that pushes readings to a dashboard over MQTT or WiFi. Students learn sensor interfacing and calibration, time-series feature extraction (rates of change matter more than absolute values in composting), and the full IoT loop from sensing to alert. The demo is a live dashboard with the pile's status and a sample alert. Students pick it because it is a complete sensing-plus-ML system with an environmental story, and the hardware bill is small. The honest limitation: gas sensors drift and need calibration, and the model's state labels are approximate — the report should present it as a monitoring aid, not a laboratory instrument.
6. TinyML Air Quality Forecaster
Air quality apps show you the current AQI, but what you actually want to know is whether tomorrow morning's run or commute will be bad. This project builds a forecaster on a microcontroller-class device: particulate and gas sensors collect local readings, and a tiny time-series model predicts near-term air quality trends. The real problem is hyperlocal forecasting — city-wide AQI stations are kilometres apart, and your street's air is what you breathe. The technical core is a small regression or classification model (a tiny LSTM or even a well-tuned linear model on lagged features) trained on historical sensor plus weather data, quantized and deployed to an ESP32 with a PMS5003 particulate sensor and a BME280 for temperature, humidity, and pressure. Students learn time-series feature engineering (rolling means, hour-of-day encoding, lag features), the discipline of train/validation/test splits over time (no shuffling time series), and sensor interfacing with real calibration concerns. The demo shows the current reading alongside the forecast trend on a small display or dashboard. Students pick it because forecasting is a rarer TinyML application than classification, the environmental framing is strong, and the project teaches time-series hygiene that transfers everywhere. The honest limitation: low-cost particulate sensors are approximate and humidity-sensitive, so the report should present forecasts as trends with uncertainty, not precise AQI numbers.
7. TinyML Baby Cry Detector
Parents want to know when a baby cries, but they do not want a cloud-connected microphone streaming their nursery to a server. This project builds a private cry detector on a microcontroller: it listens continuously, recognises crying sounds, and sends a local alert — with no audio ever leaving the device. The real problem is privacy-preserving baby monitoring: the detection that matters (cry vs not-cry) needs no cloud at all. The technical design is audio classification at TinyML scale: mel-spectrogram or MFCC features into a small CNN, trained on cry-vs-background audio (public infant-cry datasets plus recorded household background noise for the negative class), quantized to int8 and deployed with TensorFlow Lite for Microcontrollers on an ESP32-class board with a microphone. Students learn the full always-on audio pipeline — overlapping inference windows, smoothing predictions over time to avoid flicker, and measuring false-alarm rate over long quiet periods, which is the metric that actually matters for a device that runs all night. The demo plays cry samples and background sounds and shows the alert triggering only on cries. Students pick it because the privacy story is compelling, the use case is universally understood, and the false-alarm evaluation is a genuinely instructive ML exercise. The honest limitation: it detects crying sounds, not distress causes, and the report must not present it as a medical or safety device — it is a notification aid, and the write-up should say so plainly.
8. TinyML Fall Detection Wearable
Falls are the leading cause of injury for elderly people living alone, and the critical factor is response time — a fall nobody notices for hours is far more dangerous than one answered in minutes. This project builds a wrist- or waist-worn fall detector: an IMU (accelerometer plus gyroscope) streams motion data to a microcontroller, and a tiny ML model distinguishes real falls from everyday movements, triggering an alert (buzzer, BLE message to a phone) when a fall is detected. The real problem is independent living with a safety net — commercial fall-detection pendants exist, but building one teaches the entire wearable pipeline. The technical core is motion classification on time-series windows: accelerometer and gyroscope features (or raw windowed signals) into a small 1D-CNN or LSTM, trained on fall datasets (public fall-detection corpora plus recorded activities of daily living for the negative class), deployed with TFLite Micro on an ESP32 or Arduino-class board with an MPU6050. Students learn IMU interfacing and calibration, windowed time-series classification, and the central engineering trade-off of the project: sensitivity versus false alarms — a detector that cries wolf gets taken off, one that misses falls is useless. The demo drops a test dummy or performs staged falls alongside normal activities. Students pick it because the health-and-safety framing is powerful and the wearable form factor demos beautifully. The honest limitation, stated firmly: this is a student prototype, not a certified medical device — the report must say so, and real deployment would need clinical validation.
9. TinyML Gesture Recognition Using IMU
Touchscreens do not work with gloves, wet hands, or at a distance — which is why gesture control keeps reappearing in industrial, medical, and accessibility contexts. This project builds a gesture recogniser on a microcontroller: an IMU on the wrist or in the hand captures motion, and a tiny model classifies gestures (swipe left/right, circle, tap patterns, tilt) to control something — a presentation, a robot, a smart-home device. The real problem is hands-free control where cameras are impractical (privacy, lighting, cost) and buttons are unreachable. The technical design is windowed IMU classification: the MPU6050 streams accel/gyro data, a sliding window feeds a small 1D-CNN or LSTM, and the output drives an action over BLE or a wired link. Students learn gesture dataset collection (recording their own gestures — genuinely fun project work), the importance of a null/background class so random motion does not trigger actions, and on-device inference timing. The demo is interactive: wave to change slides or steer a small robot, which is the most engaging demo format on this list. Students pick it because the data collection is personal (your gestures, your model), the demo is live and physical, and the null-class problem teaches a real ML lesson. The honest limitation: a handful of distinct gestures in controlled conditions — similar gestures get confused, and the report should show the confusion matrix rather than hide it.
10. TinyML Vibration Anomaly Detector
Industrial motors, pumps, and fans fail gradually — bearing wear shows up as changing vibration long before the machine stops. Catching that early is the entire field of predictive maintenance, and this project builds its smallest possible version: an accelerometer on a motor, a microcontroller learning the machine's normal vibration signature, and an alert when the pattern drifts. The real problem is unplanned downtime, which costs factories far more than the sensor hardware. The technical approach is anomaly detection rather than classification: an autoencoder (or a statistical baseline) trained only on normal-operation vibration data learns to reconstruct healthy signals, and reconstruction error becomes the health score — high error means something changed. Students learn frequency-domain features (FFT spectra reveal bearing faults at characteristic frequencies), the train-on-normal-only paradigm, threshold selection on validation data, and deployment on an ESP32 with an ADXL345 or MPU6050 mounted on a small DC motor test rig. The demo runs the motor, introduces a fault (an unbalanced load), and shows the health score spiking. Students pick it because predictive maintenance is a serious industrial application, the autoencoder approach teaches unsupervised learning properly, and the test rig is cheap and repeatable. The honest limitation: a student rig demonstrates the principle — real fault diagnosis needs labelled failure data from actual machines, and the report should frame the build as a proof of concept, not a plant-ready system.
Comparison at a glance
| Project | Core tech | Best for | Build complexity |
|---|---|---|---|
| Vehicle Counter (Pi) | YOLO/TFLite, SORT tracking | Traffic analytics | Intermediate |
| Keyword Spotting (MCU) | TFLite Micro, MFCC, Speech Commands | Canonical TinyML | Beginner–Intermediate |
| Bird Feeder Logger (Pi) | MobileNet fine-tune, motion trigger | Wildlife + vision | Intermediate |
| People Counter (Jetson) | TensorRT, tracker, counting line | Retail analytics, GPU edge | Intermediate |
| Smart Compost Monitor | ESP32, sensor fusion, MQTT | IoT + ML system | Beginner–Intermediate |
| Air Quality Forecaster | Tiny LSTM, PMS5003, time series | Forecasting on MCU | Intermediate |
| Baby Cry Detector | TFLite Micro, audio CNN | Privacy-preserving audio | Intermediate |
| Fall Detection Wearable | IMU, 1D-CNN/LSTM, MPU6050 | Health-safety wearable | Intermediate |
| Gesture Recognition (IMU) | IMU windows, null class, BLE | Interactive demo | Beginner–Intermediate |
| Vibration Anomaly Detector | Autoencoder, FFT, ADXL345 | Predictive maintenance | Intermediate–Advanced |
How to pick yours
- Choose your hardware class first. Microcontroller builds (keyword, cry, vibration, gesture, air quality) cost little and teach quantization deeply; Pi/Jetson builds (vehicle, people, bird) handle vision and are easier to debug with a full OS. Do not pick a vision project for a microcontroller.
- Budget for the physical build. Edge AI means a real device: sensors, a board, a power supply, mounting. Add up the bill of materials before committing — it is the most common surprise in these projects.
- Plan your data collection early. Gesture, fall, and vibration projects need your own recorded data; keyword and bird projects start from public datasets. Data collection always takes longer than expected.
- Think about power from day one. Battery-powered always-on devices live or die on current draw. If your project claims low power, measure it with a USB meter and put the number in the report.
- Match the demo to the venue. Physical demos are persuasive but fragile — carry a recorded backup video of the device working, in case the venue has no space, quiet, or power where you need it.
- Keep the model small on purpose. If your TFLite model does not fit the MCU's flash and RAM, that is not a failure — it is the project. Document the size-accuracy trade-off; it is the most TinyML thing you can do.
Frequently asked questions
What is the difference between TinyML and edge AI?
TinyML means ML on microcontrollers (ESP32, Arduino-class: kilobytes of RAM, no OS). Edge AI is the broader term covering small computers too (Raspberry Pi, Jetson: full OS, gigabytes of RAM). This list has both — the MCU entries are TinyML, the Pi/Jetson entries are edge AI.
Do I need to buy hardware for these projects?
For the real thing, yes — a board and a sensor or two. Most entries need one board (ESP32-class or Pi) plus one sensor, which is a modest student budget. The report and demo both assume a physical device; a simulation-only version loses most of the point.
How do I fit a neural network on a microcontroller?
Three techniques: train a small architecture to begin with (depthwise-separable CNNs), quantize to int8 (TensorFlow Lite does this nearly automatically), and prune where possible. Edge Impulse and TFLite Micro handle deployment. Expect models in the tens to low hundreds of kilobytes.
Can I train these models without a GPU?
Yes. TinyML models are small enough to train on a CPU in minutes to an hour, and Colab's free tier covers anything bigger. Training is the easy part here — data collection and deployment debugging take the real time.
Which entry is best for a complete beginner?
Keyword spotting: the dataset is standard, the pipeline is documented end to end, the hardware is one board plus a microphone, and the demo (say the word, see the LED) cannot really fail silently. Gesture recognition is the other friendly starting point.
Every project on projectech.in is built to order — there is no ready-made stock shipped from a shelf. You share your requirements, get a quotation for your specific scope, and the build (working device firmware and models, circuit and mounting guidance, report, and explanation support) is developed for you. That means the entries above adapt to what you have: a keyword spotter for your board, a vehicle counter tuned for your campus gate's camera angle, or a vibration monitor for the specific motor in your lab — the built-to-order model exists for exactly that kind of customisation.
Want one of these built for you? Chat on WhatsApp with the project name and your deadline, and you will get a written quotation with scope, price and delivery date.