Home / Case studies / Edge AI On-Device Object Detection for Industrial Cameras
Case study · Industrial IoT · Edge AI
Edge AI On-Device Object Detection for Industrial Cameras
A US industrial device manufacturer needed on-device object detection so its camera hardware could spot objects without sending every frame to the cloud. Brainy Neurals built a detection pipeline that uses a compact neural network to find objects in each live frame. The model runs on the neural processing unit built into each device & replaced a first version that sent each frame to the cloud. Each device now detects objects with zero cloud calls & keeps working when the network drops.
On the device
No per-frame cloud cost
Offline ready
Keeps working when networks drop
No cloud setup
Faster device rollout
Published September 2026 · Updated October 2026
At a glance
Brainy Neurals built an on-device object detection pipeline for a US industrial device manufacturer.
What problem did the build solve?
Camera-equipped industrial devices couldn’t run real-time object detection on their own. Cloud inference filled the gap, but every frame paid for bandwidth & waited on the network.
What did Brainy Neurals build?
A compact detector runs on the board’s neural processing unit (NPU), with the frame loop around it written in C.
What changed after it went live?
Detection now runs on the device, with no cloud round trip & no per-frame bandwidth bill. A dropped connection no longer stops it, & rollout got faster.
Who else could use this build?
Any team shipping camera hardware whose frames can’t wait for a network could use it. Shelf cameras & dock cameras fit the pattern. So do inspection stations on a factory line.
Engagement facts
| Fact | Detail |
|---|---|
| Industry | Industrial Internet of Things |
| Sub-vertical | Camera-equipped devices |
| Client | US industrial device manufacturer |
| Engagement | Edge AI inference platform |
| Timeline | Not disclosed |
| Capabilities | Computer vision & edge AI |
| Delivery | Project-based |
Why couldn’t detection run on the device?
Detection couldn’t stay on the device because on-device inference had never worked on the manufacturer’s board. The US industrial device manufacturer ships camera hardware into sites where the network isn’t guaranteed, & its devices must spot objects as things happen. Without on-device object detection, the first version sent every frame to the cloud & waited for an answer.
Where it broke
- Each frame left the device, so the uplink bill grew with every camera the manufacturer switched on.
- Detections waited on a round trip, so alerts came late.
- A network drop turned a smart device into a plain camera until the connection came back.
- Running the model on the board’s main processor stalled far below usable frame rates.
- Simple ports ran out of memory every time.
Researchers flagged these limits years before this build started. A 2016 survey of edge computing listed response time & bandwidth cost as reasons to compute on the device[1]. The survey also counted battery life among those reasons.
What do teams usually try first?
Teams usually try one of three routes before an on-board detector.
| Approach | What it gets right | Where it stops | Who it still suits |
|---|---|---|---|
| Cloud inference | Any model size & easy updates | Lag & bandwidth on every frame | Solid connections & low frame rates |
| CPU only | No new hardware | Single-digit frame rates & rising heat | Snapshots rather than live video |
| Smart camera | Works out of the box | Fixed object classes & closed firmware | Pilots with standard objects |
| NPU detector (our route) | Real-time frames on the existing board | Weeks of memory & operator work | Devices that decide alone, in volume |
Three common routes each hit a wall that the NPU route on the board avoids.
An independent benchmark found detection models ran about ten times faster on an AI accelerator chip than on the embedded main processor[2].
How did we design the on-device pipeline?
We designed the pipeline to live on one board, where the camera & the NPU share one memory pool with the display. The camera writes each frame into a fixed ring of buffers. A compact detector that looks at the frame once runs on the NPU, & the main processor draws the result.
Where detection lives
Nothing waits on a network, because there’s no network in the loop. We rejected a hybrid design that sent hard frames to the cloud, since a device that sometimes needs a network still needs one. The detector runs on every frame locally, & a single-pass model was the only kind small enough.
What the processor touches
Per frame, the main processor does two jobs in C, setting up capture & drawing the results. Python stayed in the build tools, where it handles model conversion & calibration. It runs the test suite too, yet it never runs on the device at run time.
Nothing waits on a network, because there’s no network in the loop.
Every stage from capture to render runs on one board, & no frame leaves it.
The object detection model itself was a small part of the work, & the code around it made the build run.
What technology stack did we use?
The stack runs on one board with a fixed power budget, so every layer had to earn its place. We picked each layer for the work it does per watt. The same layers show up in our camera analytics builds, with a different board underneath.
Hardware & capture
| Layer | What we used | Why | What we ruled out |
|---|---|---|---|
| Compute board | The manufacturer’s existing board, NPU included | Already qualified | A separate accelerator module |
| Camera path | Vendor capture into shared memory | One copy per frame | A USB camera stack |
Model & runtime
| Layer | What we used | Why | What we ruled out |
|---|---|---|---|
| Detection model | Compact single-pass detector | One pass per frame, in real time | Two-stage detectors |
| Precision | Reduced numerical precision | Where this NPU is fast | Full precision on the CPU |
| NPU runtime | Vendor runtime, called from C | Operators stay on the accelerator | A generic library |
Application & delivery
| Layer | What we used | Why | What we ruled out |
|---|---|---|---|
| Application | C for the frame loop | Predictable timing | Python on the device |
| Tooling | Python scripts for model prep & tests | Fast to change & never ships | Hand-kept spreadsheets |
| Deployment | Firmware image with the model baked in | One artifact per device | Pulling models at boot |
How does the device process one frame?
The device processes each frame in six steps, from capture to release, without a single network call.
The processor packs the next frame while the NPU works on the current one, which sets the frame rate.
- The camera writes a frame into the next free slot of a fixed buffer ring, so nothing is allocated mid-stream.
- In one pass of C code, the main processor resizes the frame & packs it into the layout the NPU expects.
- The NPU runs the compact detector while the processor prepares the next frame.
- Next, the processor turns the raw outputs into boxes & labels, then drops any boxes that overlap before drawing.
- A renderer draws the boxes on the live frame & passes it to the display or event output.
- The slot then returns to the ring, & the loop starts over.
What nearly stopped the build?
Three problems nearly stopped the build, & they showed up in this order.
Memory ran out
The first port ran out of memory within seconds of starting. The camera & the NPU drew from the same pool as the processor, so each copy of a frame counted three times.
Layers fell back to the CPU
Some layers of the detector had no NPU version, & nothing in the build tools flagged them. The runtime quietly ran those layers on the CPU, & the frame rate collapsed.
The board overheated
Steady load pushed the board past its power budget, & it slowed down. Its detections stayed correct but arrived late, & a late detection is as useless as a wrong one.
A 2026 benchmark of low-cost edge chips found that memory bandwidth mattered more than raw compute for detection on a busy board[3]. In weeks like these, clients often ask about adding specialist engineers instead of learning the slow way.
How did we fix each problem?
Each problem took one targeted change to fix, & none was quick to find.
Memory
We replaced every per-frame memory grab with a fixed ring of buffers sized at boot. Then we rewrote the capture path so the NPU reads the camera buffer directly, making one copy per frame. The out-of-memory crash never came back after that.
Fallback
We rebuilt the problem layers from operations the NPU supports, & any layer that falls back to the CPU now fails the build. A slow layer gets caught in testing before it ever reaches a device.
Power
We trimmed the model to the manufacturer’s object classes & lowered the input resolution until each frame finished with time to spare. The board stopped throttling, & timing held under the steady load that broke the demo build.
A fixed ring of buffers, set up once at boot, replaced every per-frame memory grab.
Audio drivers have used the buffer ring trick for decades.
An AI proof of concept exists to surface work like this before anything gets promised.
What changed after the pipeline went live?
After go-live, detection moved off the cloud.
| What | Before | After |
|---|---|---|
| Where detection runs | In the cloud, after an upload | On the device, on the NPU |
| Cloud calls per frame | One round trip per frame | Zero |
| When the network drops | Detection stops | Detection continues |
| Cost that grows with each camera | Cloud inference & bandwidth | Neither |
| Bringing up a new device | Cloud account, uplink & setup | One firmware image |
We haven’t published a frame-rate or latency figure, & no power figure either. The manufacturer reports all three improved, but we only print numbers that we’ve measured ourselves.
A customer can now switch on a device in a room with no network, & it still detects objects. The compute came with the board, so the bill for detection no longer grows with the camera count.
Rollout got faster too, since each new device needs only its firmware.
Does your device need detection without the cloud?
Tell us what your camera needs to see & where the device will run. We’ll scope the build from a look at your hardware & quote a fixed price.
What runs on the devices today?
The on-device object detection pipeline runs in production on the manufacturer’s devices, on the same board the first prototype used. Each unit runs the whole loop by itself, so network changes don’t affect it.
Since handover, the manufacturer has rolled the same image out across more of its device line for manufacturing customers. The model rides along as one more file in that image, versioned with the firmware it belongs to. Python never made it onto the device, & that rule still holds.
What would we do differently next time?
Four lessons would change how we start the next build.
Check NPU support before picking the model
We picked the detector before checking which layers the NPU supports, & that cost time we hadn’t budgeted for.
Measure memory traffic on day one
Accelerator specs advertise compute, so we profiled that first. Memory bandwidth was the real limit, & we only found it when the board crashed.
Run the soak test before the demo
A pipeline that holds for a demo & throttles over a shift is not done. We now run every build hot for hours first.
A pipeline that holds for a demo & throttles over a shift is not done.
Keep Python off the device from the first commit
Prototyping the frame loop in Python looks faster, but the port then becomes the whole project.
Where else does on-device object detection fit?
The same pattern fits any setting where a camera frame can’t wait for a network, since the detector runs on the camera itself.
| Industry | The equivalent problem | What changes in the build |
|---|---|---|
| Retail | Shelf cameras spotting gaps before shoppers do | Retrain on packaging & send events on change |
| Logistics | Warehouse dock cameras counting pallets with no site network | More pixels for small boxes, costing frame rate |
| Manufacturing | Inspection stations catching defects before the next part | Tighter timing & a reject signal to the line |
| Agriculture | Field sensors watching crops on a solar budget | Duty-cycled capture & a smaller model |
| Fleet safety | In-cab cameras flagging distraction on the move | Vibration-proof mounts & strict rules on what leaves the cab |
The same on-device pattern watches a store shelf, sending events out while the video stays put.
Porting the pattern starts with a retrained detector & an operator check on the new board. A soak test then confirms the timing holds under steady load.
What do buyers usually ask?
Buyers weighing on-device detection usually ask the six questions below.
How it works
Can object detection run in real time on an embedded device?
Yes, when the board has an AI accelerator & the model is built for it. A compact single-pass detector on an NPU handles live video on one board, while the CPU alone usually can’t keep up.
What is an NPU, & why use one instead of a GPU?
A neural processing unit is a block of silicon built only for neural network math. It runs detection on a fraction of a GPU’s power, which is why it suits a small device with a tight power budget.
How is edge AI inference different from cloud inference?
Edge inference runs the model on the device that captured the data, so no video leaves the site. Cloud inference ships each frame over a network & waits for the answer to come back.
Time, cost & rollout
How long does it take to move a detection model onto an NPU?
A proof of concept on your own board usually takes a few weeks. Operator support & memory layout each need a pass. Heat gets its own pass too, & a production image follows once the soak test holds.
How much does an on-device object detection build cost?
The price depends on your board & the objects the model must find. Brainy Neurals looks at the hardware & any existing work after a short call, then quotes a fixed price. An AI readiness assessment tells you first whether your board can carry the model.
How do the costs of edge AI & cloud AI compare over time?
Edge hardware is a one-time cost per device, while cloud inference is a recurring cost per frame. At low volumes the cloud is cheaper to start with. If you ship devices in volume for years, the on-device route pulls further ahead each year.
What does your device need to see?
Tell us what the camera must find & which board it runs on. Your message won't start a sales sequence. You'll get one reply, from the person who would architect your build.
Services behind this case study
Six Brainy Neurals services went into this build, one per card.
Edge AI & embedded services
We build on-device object detection for NPUs & embedded boards, from operator checks to a production firmware image.
Computer vision development
Compact detectors are trained on each client’s objects & sized for the hardware they run on.
Video analytics
Camera analytics run at the camera & send only events.
Robotics & hardware automation
Vision & sensor pipelines get wired into machines, where timing is a matter of safety.
Hire AI developers
Edge AI engineers join a client’s team when the board fights back.
AI in manufacturing
We build inspection systems for plants with unreliable networks.
An AI proof of concept tests the pattern on a client’s own board before a larger build. AI consulting helps choose the hardware first, & an AI readiness assessment shows whether the model will fit. The industries hub shows where the pattern already runs.
Similar case studies
Three more Brainy Neurals builds went into real environments instead of staying demos.
Overhead Line Geometry Measurement
In rail & logistics, stereo cameras on a moving train measure wire geometry with inference on the train.
AI Diet Assistant for Gastroenterology
In healthcare, the assistant writes dietary guidance under review gates & runs live.
Personalised AI Meal Planning for Chronic Care
Also in healthcare, structured meal plans come from messy personal health data, grounded & reviewable.
Cite this case study
Mori, Prasiddh. Edge AI On-Device Object Detection for Industrial Cameras. Brainy Neurals, August 2026. https://brainyneurals.com/case-studies/on-device-object-detection-npu/
Sources cited on this page
- Shi W, Cao J, Zhang Q, Li Y, Xu L. Edge Computing: Vision and Challenges. IEEE Internet of Things Journal. 2016;3(5):637-646. DOI 10.1109/JIOT.2016.2579198.
- Cantero D, Esnaola-Gonzalez I, Miguel-Alonso J, Jauregi E. Benchmarking Object Detection Deep Learning Models in Embedded Devices. Sensors. 2022;22(11):4205. DOI 10.3390/s22114205. PMID 35684827.
- Kong C, Li F, Yan X, Yang J, Mo P, Luo Q, Mao R. Object detection on low-compute edge SoCs: a reproducible benchmark and deployment guidelines. Scientific Reports. 2026;16:5875. DOI 10.1038/s41598-026-36862-y.