Edge AI camera: how on-device vision works in a home product

12 Oct 2026 By Shreya P T

An edge AI camera runs its vision models on the device that holds the lens, instead of streaming video to a server. A proximity trigger decides when to capture, a quality gate rejects frames that are too dark or too blurry in under a millisecond, and only frames that pass reach a quantized neural network that runs locally. In our bowl-mounted camera the landmark model is a 46-point TFLite network running at 384 by 384 pixels, and the gates in front of it reject most frames before it ever runs. The design goal is the same for any always-on camera in a home: process locally, send little, and never miss the moment that matters.

This post explains the five parts of an edge AI camera, the constraints that shape model choice, and the mistakes that show up only after the camera is in someone’s kitchen.

The short version

Edge AI means inference on the device: the camera decides what it is looking at without sending video off the device.
A good edge pipeline is mostly rejection. Cheap checks (proximity, sharpness, brightness, geometry) stop 60 to 90 percent of frames before a neural network runs.
Models are chosen by memory and latency budget first, accuracy second; quantized TFLite or similar formats at a few megabytes are the norm.
Models need the same safe update path as firmware, because the first model shipped is never the last.

What makes a camera an edge AI camera

A conventional connected camera captures video and uploads it; a server decides what is in it. An edge AI camera moves that decision onto the device. The difference is not marketing. It changes power draw, bandwidth, latency and privacy at the same time. A camera that uploads continuous video from a kitchen needs a steady network and a server bill, and it ships every frame of a family’s home to the cloud. A camera that runs detection locally sends a small result, or a single frame, only when something worth recording has happened.

The cost is that the device has to do the work with a fraction of a server’s resources: tens to hundreds of megabytes of RAM, a microcontroller or small application processor, and a thermal budget set by a plastic enclosure sitting next to a water bowl.

The five parts of an on-device vision pipeline

1. A trigger that is not the camera
Running image capture continuously wastes power and generates frames nobody needs. A separate low-power sensor decides when to capture. In our camera node that trigger is a time-of-flight proximity sensor with a narrow 4 by 4 zone field of view; when something enters the capture window at the right distance, the camera wakes and captures. The trigger’s accuracy depends on calibration that must survive firmware updates, which is its own engineering problem, covered in ToF calibration persistence with dual-bank flash redundancy.

2. Quality gates before any model
The cheapest computation in the pipeline is the most valuable. Before any neural network runs, each frame is checked for sharpness (Laplacian variance above a threshold) and exposure (mean brightness neither too dark nor blown out). These checks take a fraction of a millisecond and remove most night frames and fast-motion blur. A second gate uses a small, fast model to confirm the geometry you need is present; in our pipeline an eye-pair check runs before the landmark model, so frames with a profile view or a partial face never reach it. The full gate sequence is described in building the multi-stage vision pipeline.

3. A detector sized for the device
Detection models for edge cameras are small by necessity. YOLOv8-nano and MobileNet-class backbones run in tens of milliseconds on modest hardware and fit in a few megabytes once quantized to 8-bit integers. The accuracy loss from quantization is usually 1 to 2 percentage points; the memory and latency gain is 3 to 4 times. The practical rule is to choose the smallest model that meets the accuracy target on your own data, not on a public benchmark.

4. Task models that run only when needed
After detection, task-specific models run on the cropped region: landmarks, embeddings, classification. Because they run only on frames that passed every gate, they can be larger than the detector. Our 46-point landmark model runs at 384 by 384 on the dog crop and returns normalized coordinates across four facial regions; it is a lightweight CNN exported to TFLite, and it was fine-tuned on deliberately imperfect indoor frames because the clean public datasets it started from produced confident false detections on fur and bowls. That retraining cut false detections by roughly 30 to 35 percent in indoor conditions; the method is in reducing false detections by training on bad indoor data.

5. A small result leaves the device

What leaves an edge AI camera should be a result, not a video stream: a timestamp, an identity, a confidence, and a single frame when the event warrants it. This keeps bandwidth to kilobytes per event, makes the product usable on weak home WiFi, and keeps continuous footage off any server.

Choosing the model: constraints come first

Constraint	Typical edge budget	Design consequence
RAM for weights and activations	2 to 64 MB	Quantize to int8; prefer depthwise-separable backbones
Latency per frame	20 to 200 ms	Gate aggressively; run heavy models on crops, not full frames
Power	Battery or passive-cooled mains	Trigger capture with a low-power sensor; sleep between events
Flash for models	A few MB per model	Version models separately from firmware; plan the update path
Data domain	Overhead angle, indoor light, close range	Fine-tune on frames from the real camera, not public photos

The last row is the one teams underestimate. A detector pretrained on COCO has never seen a dog from directly above at 30 centimeters under a yellow kitchen light. In our evaluation, the largest failure bucket was the general-purpose detector finding no dog at all in 20 of 49 failed frames, which points to training a detector on footage from the camera itself rather than tuning thresholds on someone else’s model.

Updating models in the field

An edge model is shipped software, and it needs the same discipline as firmware: signed images, a slot that is not the one currently running, a health check after the swap and a way back if the new model is worse. On a microcontroller-class camera node that means dual-bank flash and a bootloader that can swap banks atomically; the mechanics are in firmware updates with bank switching on STM32H5. On a Linux-class node it means A/B root filesystems and a staged rollout, which A/B OTA updates that cannot brick a device covers.

Model updates also change behavior in ways a crash log does not catch. A new detector that finds 10 percent fewer dogs is a regression that only shows up in event counts. Ship model updates to a canary group first and compare detection rate and match accuracy against the previous model before widening.

Mistakes that only appear in real homes

Evaluating on the training camera. A model that scores well on frames from the lab unit and poorly in homes has learned the lab. Collect evaluation frames from several homes, lighting conditions and times of day before trusting a number.

Filtering the dataset too hard. Removing blurry, dark and partial frames from training produces a model that has never seen failure and so cannot recognize it. Keep the bad frames and label them as negatives.

Skipping the quality gate to save a few lines of code. Every frame that reaches the neural network costs power and time. The gate is where most of the efficiency lives.

Reporting one accuracy number. Detection rate (how many frames produce a result) and accuracy on detected frames (how many results are right) move independently. Report both.

Treating the model as finished. The first model shipped meets the first homes it saw. The update path is part of the product.

How this works in EverBowl™

EverBowl™ learns how a dog eats and drinks by watching the bowl, and much of that watching happens on the camera node itself. A proximity trigger wakes the camera when a dog arrives, quality and geometry gates discard frames that cannot be used, and only frames that pass reach the landmark and identification models that run locally. The aim of the design is that what leaves the home is a record of visits attributed to a dog, not a video feed of a kitchen. EverBowl does not diagnose anything; the value is the record, built from thousands of ordinary visits, that shows a vet when a dog’s pattern changed and how. Every meal and every sip becomes a thorough health check.

Conclusion

An edge AI camera is a rejection pipeline with a neural network at the end. Trigger capture with a cheap sensor, discard bad frames with arithmetic before any model runs, size the detector to the device, run heavier task models only on crops that pass every gate, and send results rather than video. Train and evaluate on frames from the real camera in real homes, report detection rate and accuracy separately, and give models the same update path as firmware. The one thing to do before the next model ships: collect a held-out evaluation set from homes that were not used in training.

FAQs

What is an edge AI camera?

A camera that runs its detection and recognition models on the device itself rather than streaming video to a server. It sends results (an event, an identity, a single frame) instead of continuous footage.

Why run computer vision on the device instead of the cloud?

Lower bandwidth, lower latency, no dependence on a strong network connection, and far less footage leaving the home. The trade-off is a strict memory, latency and power budget for the models.

How small do edge AI models have to be?

Typically a few megabytes after int8 quantization, with per-frame latency of tens to low hundreds of milliseconds. The exact budget depends on the processor and on how many frames the gates let through.

What is a quality gate in a vision pipeline?

A cheap check, such as sharpness or brightness, run on every frame before any neural network. It rejects unusable frames in a fraction of a millisecond so the expensive models run only on frames that can produce a result.

How are models on an edge camera updated?

Through the same mechanism as firmware: a signed image written to an inactive slot, a swap, a health check and automatic rollback if the new model fails. Model updates should also go to a small canary group first and be compared on detection metrics.

Does an edge AI camera send video to the cloud?

Not in this design. The device sends a small result per event and, when warranted, a single frame. Continuous video stays on the device or is never stored at all.