Edge AI on a Raspberry Pi
Most of my AI work has not lived on a GPU server somewhere — it has lived on a Raspberry Pi 4 sitting next to a road, looking at vehicles in real time. The headline project is a ResNet50 vehicle classifier deployed at the edge: 97% accuracy, sub-second end-to-end latency, and an actuator pipeline that physically reacts to what the model sees.
That one project taught me more about applied AI than two years of coursework. When the inference has to finish before a car finishes passing the camera, you stop arguing about benchmarks and start arguing about milliseconds. Every decision — model size, input resolution, frame skipping, thread layout — gets weighed against a budget that does not care how clever your architecture is.
Getting there meant treating the model as just one component in a larger system. The interesting engineering was everywhere else — the camera capture loop, the pre-processing, the UART handoff to an Arduino, the MQTT telemetry going back up to the cloud. The model is the easy part, honestly. Wrapping it in something reliable is where the work lives.
Why edge AI matters
Running a model at the edge removes the cloud round-trip, preserves privacy, and lets embedded systems react in real time. That last part is the whole point. A vehicle has already passed the camera by the time a cloud response comes back; the decision has to happen on-device or it does not happen at all.
That constraint shapes everything: model choice, quantization, threading, even the housing the hardware sits in. You stop thinking about 'AI features' and start thinking about a closed-loop system that has to behave correctly in the rain, in the dark, and at 2 a.m. when nobody is watching.
It is also a different career skill set. Cloud ML engineers think in batches and dashboards. Edge AI engineers think in interrupts, watchdogs, and thermals. Both are valuable. I just happen to enjoy the side where the wire matters.
The stack I keep coming back to
Python, TensorFlow, OpenCV, NumPy on the Pi side. Embedded C and an Arduino Nano on the actuator side. UART between them. MQTT to the cloud. Nothing exotic — but composed carefully enough that the whole pipeline holds under load.
I used to chase frameworks. Every new project, a new tool. Then I noticed that the engineers I respected the most had a small, boring toolkit they used everywhere — and they were faster because of it. So now I default to the boring stack and only reach for something new when the boring one actually breaks.
The one upgrade that has been worth it: TensorFlow Lite with INT8 quantization. Same model, a fraction of the memory, real latency wins on the Pi. It is the difference between 'works in a demo' and 'works in a deployment'.
What 'an AI project' actually involves
If I had to break down the time I spent on the smart speed breaker, the model itself was maybe 15%. Data prep and labelling was another 20%. The rest — the camera pipeline, the inter-process comms, the actuator firmware, the dashboards, the housing, the demo-day fixes — was the actual project.
This is the part beginners underestimate. They see a tutorial that trains a classifier in 50 lines and assume the rest will be easy. The rest is the job. Training a model is a course assignment; shipping a model is engineering.
Where this is going next
The next chapter is fewer demos, more durability — quantized models from day one, better thermal design, and a sensor node that runs entirely on harvested energy. The work has stopped being about proving a model can run on a Pi, and started being about proving it can run there for a year.
Long term, I want a pipeline I can drop on any small board: capture, infer, act, report, recover. That last word matters the most. A system that recovers from a bad frame, a power glitch, or a dropped UART byte without me touching it is the real goal. Anything less is just a clever prototype.