Contents
Figure 1: Deploying machine learning models on Raspberry Pi — real Python, real Linux, real inference
The Arduino tutorial ended with a model living inside 2KB of tensor arena, hardcoded as a C array into your firmware. Raspberry Pi throws that whole constraint out entirely. You get a real Linux filesystem, a real Python interpreter, and enough RAM to just... load a model file normally, the way you would on your laptop. This is genuinely the "training wheels off" moment in the edge AI series.
I wanted to write this as the direct sequel to the Arduino piece specifically because the contrast matters — the Pi sits at a fundamentally different tier of the hardware spectrum from the edge AI hardware guide earlier in this series, and the workflow reflects that. You're not fighting kilobytes anymore; you're making genuinely practical choices about which model size fits your actual use case.
By the end of this guide, you'll have a Raspberry Pi running real-time image classification on a live camera feed, understand when to add a hardware accelerator, and know exactly where this platform's ceiling actually sits. IMO, this is the point in the edge AI series where things start feeling like genuine applied engineering rather than a constrained puzzle :)
Why the Pi Changes the Whole Equation
Recall from the Arduino tutorial: your entire model had to fit into a tensor arena measured in kilobytes, compiled directly into firmware. None of that applies here.
A full Linux OS means you can install Python, TensorFlow Lite, PyTorch, or OpenCV exactly like you would on a laptop — no cross-compilation, no C array conversion step.
Gigabytes of RAM (4GB or 8GB depending on your Pi 5 configuration) mean model size is rarely your binding constraint the way it was on Arduino.
A real camera interface and USB ports mean plugging in accelerators, cameras, and sensors is genuinely plug-and-play compared to the wiring and pin-mapping Arduino work demanded.
This is why the Pi sits in its own tier in the hardware guide — it's the platform for "I want to run genuinely capable models locally" rather than "I need the absolute minimum footprint that fits on a coin-cell-powered chip."
Setting Up Your Pi for ML Work
Starting from a fresh Raspberry Pi OS install, get your environment ready.
sudo apt update && sudo apt upgrade -y
sudo apt install python3-pip python3-venv -y
python3 -m venv ml-env
source ml-env/bin/activate
pip install tflite-runtime opencv-python numpy pillowtflite-runtime is worth using instead of full TensorFlow for inference-only work — it's a dramatically lighter package containing just the interpreter needed to run models, not the full training framework you don't need on-device anyway.
Your First Deployment: Image Classification
Let's get a pre-trained model classifying images from the Pi's camera, the most common first real project on this hardware.
Enabling the Camera
sudo raspi-config
# Navigate to Interface Options > Camera > EnableLoading a Pre-Trained Model
Rather than training from scratch, start with an established lightweight model — MobileNet is the standard choice here, purpose-built for exactly this resource tier.
import tflite_runtime.interpreter as tflite
import numpy as np
from PIL import Image
interpreter = tflite.Interpreter(model_path="mobilenet_v2.tflite")
interpreter.allocate_tensors()
input_details = interpreter.get_input_details()
output_details = interpreter.get_output_details()Notice allocate_tensors() — this is genuinely the same underlying concept as the Arduino tensor arena, just handled automatically by the runtime instead of something you size and manage by hand. The Pi's abundant RAM means you rarely think about this step failing the way you would on a microcontroller.
Running Inference on a Captured Frame
def classify_image(image_path):
img = Image.open(image_path).resize((224, 224))
input_data = np.expand_dims(np.array(img, dtype=np.float32) / 255.0, axis=0)
interpreter.set_tensor(input_details[0]['index'], input_data)
interpreter.invoke()
output_data = interpreter.get_tensor(output_details[0]['index'])
predicted_class = np.argmax(output_data)
confidence = np.max(output_data)
return predicted_class, confidence
result, confidence = classify_image("test_photo.jpg")
print(f"Class: {result}, Confidence: {confidence:.2f}")This structure should feel genuinely familiar — set input, invoke, read output — it's the same fundamental TFLite interpreter pattern from the Arduino tutorial, just running in normal Python instead of embedded C++.
Real-Time Video Classification
Static images are a good starting point, but the genuinely satisfying version of this project runs continuously against a live camera feed.
import cv2
cap = cv2.VideoCapture(0)
while True:
ret, frame = cap.read()
if not ret:
break
resized = cv2.resize(frame, (224, 224))
input_data = np.expand_dims(resized.astype(np.float32) / 255.0, axis=0)
interpreter.set_tensor(input_details[0]['index'], input_data)
interpreter.invoke()
output_data = interpreter.get_tensor(output_details[0]['index'])
predicted_class = np.argmax(output_data)
cv2.putText(frame, f"Class: {predicted_class}", (10, 30),
cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 255, 0), 2)
cv2.imshow("Live Classification", frame)
if cv2.waitKey(1) & 0xFF == ord('q'):
break
cap.release()
cv2.destroyAllWindows()Run this on a bare Pi 5 CPU, and expect a genuinely modest frame rate — a few frames per second on MobileNet-class models, workable for many projects but noticeably not real-time-smooth. This exact bottleneck is precisely why the hardware guide recommended pairing the Pi with an accelerator.
Adding Hardware Acceleration
This is where the edge AI hardware guide's recommendations become directly actionable. A bare Pi 5 CPU genuinely struggles with real-time vision at meaningful frame rates — an accelerator is the fix, not a bigger model or cleverer code.
With the Raspberry Pi AI Kit (Hailo-8L)
sudo apt install hailo-allThe Hailo-8L accelerator delivers 13 TOPS for roughly 2.5W, transforming the same classification task from a choppy few-fps experience into genuinely smooth real-time inference. Models need conversion to Hailo's format first, but the inference-side Python code structure remains conceptually the same — load, invoke, read output.
With a Google Coral USB Accelerator
interpreter = tflite.Interpreter(
model_path="mobilenet_v2_edgetpu.tflite",
experimental_delegates=[tflite.load_delegate('libedgetpu.so.1')]
)Notice you need an Edge TPU-compiled model variant specifically (the _edgetpu suffix) — the Coral's fixed-function ASIC needs models compiled for its specific instruction set, not a generic TFLite file. Recall from the hardware guide: this delivers over 400fps on MobileNet-class models for roughly 2W, dramatically outperforming bare CPU inference on exactly this kind of task.
Beyond Classification: What the Pi Tier Actually Enables
Given the Pi's genuinely capable compute budget compared to Arduino, a wider range of projects become realistic.
Object detection, not just classification — identifying multiple objects and their locations within a frame, using models like MobileNet-SSD or YOLO-tiny variants.
Basic voice assistants — running a wake-word model plus a larger speech-to-text pipeline, genuinely feasible on Pi-tier hardware in a way it isn't on a microcontroller.
Onboard RL policy inference — recall the robotics kits article recommendation that the Pi is the right platform for hosting a trained PyTorch policy directly, rather than tethering to a laptop.
ROS 2 integration — the Pi is genuinely capable of running the same robotics middleware used in serious research and industry work, not a simplified hobbyist substitute.
Managing the Pi's Real Constraint: Thermal and Power Budget
Unlike Arduino's RAM ceiling, the Pi's actual limiting factor is usually thermal throttling and power draw, not raw compute capacity.
Sustained inference workloads generate real heat — a passive heatsink is often insufficient for continuous vision inference; an active fan matters for anything running for extended periods.
USB accelerators like the Coral draw additional power — if you're running this from battery rather than wall power, factor accelerator power draw into your budget the same way the hardware guide flagged for battery-powered deployments.
Check vcgencmd measure_temp periodically during sustained workloads — thermal throttling silently reduces performance without an obvious error, similar in spirit to the Arduino tensor arena failing silently if undersized.
Common Mistakes People Make
Using full TensorFlow instead of tflite-runtime for inference-only work. The full package is dramatically heavier than necessary when you're just running inference, not training.
Expecting smooth real-time video from bare CPU inference. A few fps on MobileNet-class models is normal without acceleration — that's the accelerator's job to fix, not a sign something's misconfigured.
Forgetting Coral models need Edge TPU-specific compilation. A generic TFLite file won't run on the Edge TPU delegate — you need the _edgetpu compiled variant specifically.
Ignoring thermal management on sustained workloads. Continuous inference genuinely heats the board; passive cooling alone often isn't enough for extended real-time vision tasks.
Overbuilding for a simple task. If your actual need is basic classification at a few frames per second, you may not need an accelerator at all — confirm you've actually hit a wall before adding hardware complexity.
Where This Fits With the Rest of This Series
This is genuinely the midpoint of the edge AI hardware spectrum from the earlier hardware guide — more capable than Arduino's microcontroller tier, but a clear step below Jetson-class hardware for anything generative. If you've followed the robotics kits article too, this is the exact board recommended there for onboard RL policy inference, and the TinyML pipeline concepts from the Arduino tutorial (quantization, the interpreter pattern) carry over directly, just without the severe memory constraints forcing every decision.
Next Steps: Level Up Your Edge ML Skills
Ready to build more complex edge AI applications? Educative offers interactive courses on TensorFlow Lite, edge deployment, and building production ML systems — practice in real sandboxed environments and learn by building actual projects.
Wrapping This Up
Deploying your first model on Raspberry Pi feels genuinely different from the Arduino experience — real Python, real file loading, gigabytes instead of kilobytes — but the underlying TFLite interpreter pattern (allocate, set input, invoke, read output) is exactly the same concept you already learned. The Pi's actual ceiling isn't memory, it's real-time throughput on vision workloads without hardware acceleration.
Remember that a bare Pi CPU genuinely struggles with smooth real-time vision, and that adding a Hailo-8L or Coral accelerator is the correct fix rather than chasing a smaller model or cleverer code. FYI, thermal throttling is the Pi's quiet equivalent of the Arduino's tensor arena problem — both fail your performance expectations silently rather than with a clear error, so it's worth actively checking for both :)
Now go point your camera at a few genuinely different objects and watch the classification confidence scores shift in real time. That live feedback loop is where this hardware tier's actual advantage over Arduino becomes viscerally obvious.