Edge Object Detection with YOLO on Raspberry Pi

Contents

YOLO object detection running on Raspberry Pi with real-time bounding boxes

Here's the genuinely nice thing about this project compared to some of the heavier deployments in this series: YOLO26, released by Ultralytics in January 2026, was actually engineered for exactly this scenario. Rather than the usual pattern of each new YOLO release adding complexity and accuracy at the cost of deployability, this generation deliberately went the other direction — edge-first, with Raspberry Pi and Jetson explicitly named as target hardware.

This project pulls together nearly everything from earlier in this series — the Raspberry Pi hardware tier, the quantization and pruning concepts, and the LiteRT/ONNX Runtime deployment pipelines — into one concrete, working application. Point a camera at your desk, and watch bounding boxes and confidence scores appear in real time, entirely on-device.

By the end of this guide, you'll have YOLO26 running real-time object detection on a Raspberry Pi camera feed, understand which export format actually gets you the best frame rate, and know the specific optimizations that separate a choppy demo from something genuinely production-usable. IMO, object detection is a more visually satisfying edge AI project than classification alone — watching boxes track a moving object in real time hits differently :)

Why YOLO26 Specifically Matters for This Project

YOLO26 broke the usual YOLO release pattern. Rather than adding complexity — transformer blocks, distribution-based regression heads, increasingly expensive post-processing — it adopted an edge-first engineering approach, shifting focus specifically to latency, export paths, and hardware-friendly design.

The detection pipeline is now fully end-to-end, simplifying exports to ONNX, TensorRT, and edge runtimes — directly building on the ONNX Runtime concepts from earlier in this series.
Distribution Focal Loss (DFL), used in earlier YOLO versions to improve bounding box precision, has been removed entirely and replaced with a simplified regression head — in practice, this causes no meaningful accuracy degradation while significantly improving deployability.
This change alone makes YOLO26 far easier to deploy on Jetson Orin, Raspberry Pi, and mobile NPUs specifically — the exact hardware tier this article targets.

This is genuinely worth knowing before you start, since plenty of existing tutorials still reference YOLOv5 or YOLOv8 — those still work, but YOLO26 was actually designed with your target hardware in mind from the start.

Setting Up the Pi

Starting from a fresh Raspberry Pi OS (64-bit) install on a Pi 4 or Pi 5.

sudo apt update && sudo apt upgrade -y
python3 -m venv yolo-env
source yolo-env/bin/activate

pip install ultralytics

The ultralytics package installs as a clean pip package rather than requiring a full repository clone — a genuinely cleaner path than older tutorials that recommend cloning the entire YOLOv5 repo with all its heavyweight training dependencies. You only need the inference-focused package for deployment.

Downloading and Running Your First Detection

from ultralytics import YOLO

model = YOLO("yolo26n.pt")  # nano variant, smallest and fastest
results = model("bus.jpg")
results[0].show()

That n suffix matters — it's the nano variant, custom-built specifically for speed and lighter hardware. YOLO ships in multiple sizes (n, s, m, l, x), and for Raspberry Pi specifically, you want the smallest variant that still gives acceptable accuracy for your task — bigger models simply won't hit usable frame rates on this hardware tier.

The Critical Step: Exporting to NCNN

Running the raw PyTorch .pt model directly on a Pi's ARM CPU is genuinely slow. The single most impactful optimization here is exporting to NCNN format — a lightweight inference framework specifically built for ARM processors.

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
model.export(format="ncnn")

ncnn_model = YOLO("yolo26n_ncnn_model")

NCNN consistently delivers the fastest inference on ARM among the export formats Ultralytics benchmarks — this is genuinely the format to reach for on Raspberry Pi specifically, the same way TensorRT is the right answer on Jetson hardware or NNAPI is the right answer on Android.

Comparing Export Formats

Ultralytics benchmarks YOLO26 across eight export formats specifically for Raspberry Pi, covering the speed-versus-accuracy tradeoff spectrum:

PyTorch (.pt) — baseline, genuinely the slowest on Pi's ARM CPU, useful only for initial testing.
ONNX — a solid middle ground, and directly compatible with the ONNX Runtime concepts from earlier in this series.
NCNN — the fastest on ARM specifically, the recommended default for this exact hardware.
TFLite — connects directly to the LiteRT article earlier in this series; a reasonable alternative if you're already invested in that ecosystem.

Benchmark these yourself on your specific Pi model rather than trusting a single number from documentation — actual performance varies meaningfully between Pi 4 and Pi 5, and even between different RAM configurations of the same board.

Real-Time Camera Inference

With the NCNN export ready, wiring it into a live camera feed follows the same pattern as the classification project from the Raspberry Pi ML tutorial earlier in this series.

import cv2
from ultralytics import YOLO

model = YOLO("yolo26n_ncnn_model")
cap = cv2.VideoCapture(0)

while True:
    ret, frame = cap.read()
    if not ret:
        break

    results = model(frame, verbose=False)
    annotated_frame = results[0].plot()

    cv2.imshow("YOLO26 Detection", annotated_frame)
    if cv2.waitKey(1) & 0xFF == ord('q'):
        break

cap.release()
cv2.destroyAllWindows()

results[0].plot() handles drawing the bounding boxes, class labels, and confidence scores automatically — genuinely convenient compared to hand-rolling the annotation logic yourself, and it's exactly the confidence-score display you'd see in the standard YOLO demo output (an 88% confidence "dog" label, for instance, is a genuinely typical result on a clear, well-lit image).

Realistic Performance Expectations

Worth setting genuine expectations rather than assuming benchmark-chart numbers translate directly to your setup.

A well-optimized YOLOv5-class setup on Raspberry Pi 4 has achieved 15-20 FPS in real deployments — genuinely usable for most practical applications, though noticeably short of smooth 30-60 FPS video.
Don't expect 60 FPS. Aim for 15-20 FPS as a realistic, reliable target, and build your application around that expectation rather than fighting for marginal gains beyond it.
Camera resolution frequently becomes the actual bottleneck before the model does — one deployment specifically found the camera itself capping performance at 30 FPS regardless of how much inference optimization followed, so check this before assuming your model needs further optimization.

Practical Optimizations That Actually Move the Needle

A handful of concrete changes deliver disproportionate real-world improvement, based on genuine deployment experience rather than theoretical benchmarks.

Run without a desktop environment. Operating headless — no GUI overhead competing for CPU and RAM — has delivered a measured 15-20% FPS boost in real deployments.
Lower your camera resolution before optimizing anything else. If the camera is already capping your throughput, no amount of model optimization changes your actual frame rate.
A cheap heatsink genuinely matters for sustained workloads. A few-dollar heatsink prevents thermal throttling from silently degrading performance over time — the same thermal concern flagged in the Raspberry Pi ML tutorial earlier in this series.
Process frames in batches if strict real-time isn't required. For applications like periodic security monitoring rather than live tracking, batched processing improves overall throughput at the cost of introducing latency.

Do You Actually Need a Coral or Hailo Accelerator?

Recall the edge AI hardware guide and Raspberry Pi ML tutorial from earlier in this series — this is genuinely a case where checking whether you need acceleration before buying it matters.

A well-optimized YOLO26n export can hit real-time-adjacent performance (15-20 FPS) on bare Pi CPU with NCNN alone — no GPU, no Coral TPU, no AI Hat required for many practical use cases.
Reach for a Hailo or Coral accelerator specifically when your application genuinely needs higher throughput — multiple camera streams, larger model variants, or genuinely smooth 30+ FPS tracking — rather than assuming you need one by default.

If you're evaluating accelerator hardware, the Raspberry Pi AI HAT with Hailo-8L is worth considering specifically for YOLO-class workloads — it integrates cleanly with the Pi 5's M.2 slot and doubles throughput compared to NCNN-only inference.

This mirrors the exact "confirm you've hit a wall before adding hardware" guidance from both the edge AI hardware article and the Raspberry Pi ML tutorial — YOLO26's edge-first design genuinely shifts where that wall sits compared to older model generations.

Want to Go Deeper?

If the NCNN export or bounding box regression concepts clicked and you want to dig into the theory behind YOLO architectures and real-time object detection, Educative's Computer Vision path covers detection algorithms in detail alongside the broader deep learning landscape — worth exploring if you're building custom detection pipelines into a real production system.

Common Mistakes People Make

Cloning the full YOLOv5/YOLO training repository for a deployment-only project. The pip install ultralytics package is dramatically lighter and entirely sufficient for inference.
Running the raw PyTorch model directly instead of exporting to NCNN. This is genuinely the single biggest performance mistake on this specific hardware — the export step is not optional if you want usable frame rates.
Choosing a larger YOLO variant than necessary. The nano (n) variant exists specifically for this hardware tier — reach for larger variants only after confirming the nano model's accuracy genuinely falls short for your task.
Skipping the heatsink. A few-dollar part prevents a genuine performance degradation problem over sustained runtime that's easy to misdiagnose as a software issue.
Assuming newer models are always better for edge deployment. Older, well-optimized model versions sometimes have better-established deployment tooling — though YOLO26's edge-first design genuinely narrows this gap compared to previous generations.

Where This Fits With the Rest of This Series

This article extends the edge AI arc into real-time object detection — building directly on the Raspberry Pi hardware tier from the Raspberry Pi ML tutorial, the quantization concepts and pruning from the compression series, and the ONNX Runtime and LiteRT deployment pipelines covered earlier. The TinyML Arduino tutorial's classification-only approach is the simpler precursor to this object detection workflow — detection adds bounding box regression on top of the same classification backbone.

Wrapping This Up

Deploying real-time object detection on a Raspberry Pi genuinely showcases how far edge-first model design has come — YOLO26's architecture changes specifically targeted exactly this deployment scenario, and the NCNN export format is the concrete lever that turns a sluggish PyTorch model into something hitting 15-20 FPS on bare CPU. This project directly builds on the Raspberry Pi hardware tier, the quantization concepts, and the export-pipeline thinking covered across this entire edge AI arc.

Remember that camera resolution often bottlenecks performance before the model does, that a cheap heatsink is genuinely not optional for sustained workloads, and that 15-20 FPS is a realistic and reliable target rather than a disappointing compromise. FYI, the fact that this runs entirely on bare Pi CPU without needing a Coral or Hailo accelerator is a genuine testament to how much edge-first model design has closed the gap this series' hardware guide originally described :)

Now go point your camera at a genuinely cluttered scene — a busy desk, a street view — and watch how confidence scores shift as objects partially overlap or move at the edge of frame. That's where object detection's real complexity (versus simple classification) becomes viscerally obvious.