Logo
← Back to Projects

Edge Object Detection on Raspberry Pi

Project type Personal embedded AI project
Main contribution Deployed MobileNet-SSD in Caffe format through OpenCV DNN directly on a Raspberry Pi 3 and built a concurrent camera, inference, and remote-display pipeline
Core technologies Python, OpenCV DNN, MobileNet-SSD, Caffe, Raspberry Pi 3, Raspbian, Logitech C615
System focus On-device inference · edge AI deployment · USB video · multithreading · remote monitoring
01

Project context

This personal project focused on a practical edge-AI question: can neural object detection run directly on a Raspberry Pi 3 without sending frames to a cloud service or GPU server? The target use case was a fixed indoor camera monitoring relatively slow-moving objects.

The prototype used a Logitech C615 USB camera for image acquisition and a MobileNet-SSD detector through OpenCV. Camera capture, preprocessing, inference, and detection-result generation were executed on the Raspberry Pi itself. The laptop was used only to view the Raspberry Pi remotely over LAN.

Raspberry Pi edge object detection overview

The detector was configured for 20 predefined object categories and returned a bounding box, class label, and confidence for recognized objects.

02

Edge Deployment Goals

I designed the prototype around the practical constraints of resource-constrained edge hardware: limited compute, continuous camera input, local inference, and the need to keep monitoring responsive even when neural inference was significantly slower than the camera frame rate.

Area Engineering goal
On-device inference Run the object detector directly on the Raspberry Pi 3 rather than using a separate server for AI computation.
Continuous operation Continuously capture frames from the USB camera and process them locally on the edge device.
Responsive monitoring Keep the camera/display path responsive even though neural inference is much slower than frame acquisition.
Recognition Detect 20 predefined object classes and return a bounding box, class label, and confidence.
Monitoring environment Target a fixed indoor camera with sufficient lighting and relatively slow-moving objects.

The central engineering challenge was therefore not simply running a neural network once. It was integrating camera capture, local inference, display, and remote monitoring into a usable pipeline on a small edge computer.

03

Hardware and Software Stack

Component Purpose
Raspberry Pi 3 Model B Runs Raspbian, captures frames, performs object detection, and manages the concurrent display/inference paths.
Logitech C615 USB camera used to capture approximately 640 x 480 video at around 29-30 FPS.
MobileNet-SSD (Caffe) + OpenCV DNN Lightweight object detector loaded from Caffe model files and executed locally on the Raspberry Pi CPU.
Laptop + Remote Desktop Remote display only. It receives the Raspberry Pi desktop over LAN; the object-detection workload remains on the Raspberry Pi.

The Raspberry Pi 3 was the actual inference target, not merely a camera gateway. The device handled frame acquisition, preprocessing, MobileNet-SSD inference, and detection-result generation locally, while the laptop provided a convenient way to inspect the running system.

Raspberry Pi 3 connected to the Logitech C615 camera
Prototype hardware: Raspberry Pi 3 connected to the Logitech C615 camera.
Remote Desktop Connection used to access the Raspberry Pi
Remote Desktop Connection used to access the Raspberry Pi over LAN.
04

System Architecture

Camera-to-display path

The system was organized around three hardware blocks: image acquisition, embedded processing, and remote display. The camera sent frames to the Raspberry Pi through USB. The Pi handled both the live-video path and the recognition path, while the laptop displayed the result through a LAN Remote Desktop connection.

Embedded monitoring architecture USB camera input → Raspberry Pi processing → LAN remote display
Raspberry Pi object detection system architecture A USB camera sends frames to Raspberry Pi 3. The Pi processes detection and live display data, then the result is viewed from a laptop over LAN using Remote Desktop. Image acquisition Logitech C615 640 x 480 · ~29-30 FPS USB video stream USB Raspberry Pi 3 Frame capture + queue OpenCV video input Live display path recent camera frames Detection path MobileNet-SSD LAN Laptop Remote Desktop video + detection result display
Edge architecture: camera input and MobileNet-SSD inference run on the Raspberry Pi, with the laptop used only for remote visualization.

Concurrent processing on the Raspberry Pi

A key design decision was to avoid making the slow object-detection stage block the live video display. The Raspberry Pi used multithreading so that frame acquisition/display and object recognition could proceed as concurrent paths.

This separation was necessary because the camera produced roughly 29-30 frames each second while the detector processed only about one frame each second. Keeping the two paths separate allowed the displayed stream to remain responsive even when inference was much slower.

05

Software Pipeline

At startup, the application loads the MobileNet-SSD model through OpenCV DNN, initializes the object classes and frame queue, and opens the video source. The main loop then captures frames and feeds separate live-video and inference paths.

Deploying MobileNet-SSD on Raspberry Pi

For deployment, I used MobileNet-SSD in Caffe format, with a .prototxt network definition and .caffemodel trained weights. OpenCV DNN loaded these files and executed inference directly on the Raspberry Pi 3 CPU.

This deployment setup kept the complete AI workload on the edge device. Camera frames did not need to be sent to the laptop for recognition, and the laptop remained only a remote visualization interface.

Runtime flow One frame source, a queue, and separate display and MobileNet-SSD inference paths
Raspberry Pi runtime flow The application loads the model, initializes the queue and video, captures frames, then runs a live display path and a MobileNet-SSD detection path before showing bounding boxes and confidence. Start application Load Caffe model with OpenCV DNN .prototxt + .caffemodel · initialize classes Initialize queue + video capture USB camera input Capture current frame push frame / reference into processing flow Live-video path display camera frames independent of slow inference Detection path MobileNet-SSD inference class · confidence · bounding box Render detection result box + label + confidence Remote display
Runtime organization used to decouple responsive video display from the slower on-device inference path.
06

Results

The final prototype successfully ran MobileNet-SSD object detection directly on the Raspberry Pi 3 from live USB-camera input. The laptop was used only to monitor the Pi remotely, while inference remained on the edge device.

Edge deployment result: MobileNet-SSD inference ran directly on the Raspberry Pi 3. The camera/display path operated at about 29 FPS, while neural inference ran at about 0.9-1 FPS. The system therefore provided real-time video monitoring with periodic on-device detections.

Camera / display ~29 FPS
Detection ~0.9-1 FPS
Recognition accuracy ~90%
Remote delay ~0.2 s

The key engineering result was successful local neural inference on a resource-constrained edge device. Because inference was slower than camera capture, I separated the two workloads so the live video remained responsive while detection results were updated independently.

Demo Video

The video below shows the final prototype running object detection on the Raspberry Pi 3, with the output viewed remotely from the laptop.

Final edge object-detection demonstration running on the Raspberry Pi 3.
07

Limitations and Next Steps

  • Inference speed was the main bottleneck. The Raspberry Pi 3 processed only about one detection frame per second, so I decoupled live display from neural inference instead of forcing every camera frame through the detector.
  • Remote Desktop was practical for demonstration, not an optimized video-delivery architecture. A dedicated streaming/output path would provide better control over latency and bandwidth.
  • The Raspberry Pi 3 provided limited compute capacity. A newer edge platform or dedicated accelerator would provide more headroom while keeping inference local.
  • A modern revision would focus on model/runtime acceleration. Quantization, a lighter inference runtime, hardware acceleration, and bounded frame queues are natural next steps while preserving the same decoupled display/inference architecture.