Why a 'smart' speed breaker?
Speed breakers are dumb on purpose — they slow everyone down equally. Ambulances, school buses, late-night commuters, all get the same jolt. The question that started this project was simple: what if the breaker could see who was coming, and adjust its height accordingly?
That one question turned into months of work, a lot of failed UART handshakes, and eventually a Winner tag at the Avishkar Project Competition. The trophy was nice. The lessons underneath were better.
The original sketch lived on the back of a notebook in October. The first working prototype existed in February. In between there were three full rewrites, two burnt servos, one fried voltage regulator, and the kind of late-night debugging session where you stop being sure what year it is. None of that shows up in the demo video.
The two-brain architecture
I split the system into two brains. A Raspberry Pi 4 handles the heavy thinking — OpenCV grabs frames from a camera, a ResNet50 classifier figures out what kind of vehicle is approaching. An Arduino Nano handles the reflexes — it listens over UART and drives a PWM signal to a servo that lifts or drops the breaker.
Trying to do everything on the Pi made the loop sluggish; trying to do everything on the Arduino was obviously impossible. The split felt right the moment end-to-end latency dropped under a second.
The protocol between them is embarrassingly simple — a one-byte command code, then a one-byte argument, then a newline. No JSON. No CRC at first. I added a checksum later, after the first time a noisy power supply corrupted a byte and lifted the breaker for a motorbike. That bug, more than any tutorial, taught me why people put checksums on their serial links.
Getting to 97% accuracy without a GPU
Training was the easy part. The hard part was making ResNet50 behave on a Pi.
I resized aggressively, dropped to a smaller input resolution, skipped frames intelligently, and moved pre-processing onto a separate thread so the camera never blocked inference. The model landed at 97% accuracy with an F1 of 0.97 — not because the model got smarter, but because the pipeline around it stopped wasting time.
Frame skipping was the unsexy hero. Instead of trying to run inference on every captured frame, the system grabs the freshest available frame at a fixed cadence and drops the rest. The user-visible behaviour is identical, the CPU stops drowning, and the worst-case latency becomes predictable. Predictable latency is more valuable than fast latency. Anyone who has shipped a real-time system will tell you the same thing.
MQTT, telemetry, and the cloud layer
Every classification, every actuation, every error gets pushed over MQTT to a small cloud dashboard. That sounds like over-engineering for a speed breaker, but it turned out to be the single most useful thing I added — I could watch the system live during demos and catch edge cases I would never have reproduced on a bench.
The rule I have taken from this project: if you cannot see what your embedded system is doing right now, you do not really own it.
The dashboard also doubled as a sanity check during judging. When the judges asked 'how do you know it actually works?', I pointed at the live stream of classifications and actuations updating in real time. That kind of transparent observability does more for credibility than any slide ever will.
What I would do differently
If I rebuilt this tomorrow, I would quantize the model to INT8 from day one, swap UART for I²C to free up the serial console for logs, and design the housing before the electronics — not after.
The biggest lesson was not technical though. It was that 'edge AI' is 10% the model and 90% the boring glue around it. The glue is the project.
And I would build the cloud dashboard first, before I even trained the model. Visibility is not a polish step. It is a prerequisite for moving fast. Every time I have built it last, I have wished I had built it first.