How I Built It.
What Broke.
What I Learned.
The portfolio shows the results. This is the part most portfolios skip — the actual process, the failures, and the things I'd do differently. Build logs are more honest than highlight reels.
The first version of the intercept logic was purely EKF-based. It looked clean on paper and completely fell apart on anything that moved erratically — a drone doing sharp lateral cuts would ghost the tracker for 200ms. That's enough time to matter.
I spent three weeks trying to tune the EKF before I stopped and admitted the model was wrong. The real fix was switching to an EKF + IMM (Interacting Multiple Models) setup that runs multiple motion hypotheses in parallel. The maneuver detection problem became a model selection problem, and suddenly the tracker stayed locked. The lesson wasn't about the algorithm — it was about diagnosing the actual failure mode instead of tuning around it.
What I learned
When your system breaks on edge cases, don't reach for the tuning knobs first.
Question whether the underlying model is even the right one. Sometimes the fix isn't in the parameters — it's in the architecture.
The 33% yield increase number is real. What the number doesn't show is that the first three field tests were disasters. The robot worked perfectly in the lab — consistent lighting, flat floor, predictable weeds. In an actual paddy field at 6AM, none of that holds. Mud jammed the wheels. Overcast light wrecked the vision model's confidence scores. The first weed it tried to remove was actually a young crop shoot.
We went back and rebuilt the training data almost entirely from field images instead of controlled shots. The model got worse on the lab benchmark and significantly better in the field. That was a lesson in what benchmarks are actually measuring.
What I learned
A system that performs well in controlled conditions is a prototype. A system that performs well in the field is a product.
The gap between those two is where most of the real engineering happens.
The offline-first constraint wasn't an aesthetic choice — it was forced by the environment. Rural Bihar has unreliable internet. If the robot needed a server, it was useless half the time. So everything had to run on the device.
Getting a voice interaction system, persistent memory, and facial expression generation to run on a Raspberry Pi without cloud calls took about four months of compressing, quantizing, and cutting things I thought were non-negotiable. The final ONNX-quantized model ran at a third of the original size with maybe 8% accuracy loss on the tasks that actually mattered. I cut features that sounded impressive but nobody used. What's left is slower to explain but faster to run.
What I learned
Constraints produce clarity. Having no internet access forced architectural decisions that made the whole system more robust. I now design for constraints before I design for features.
₹280. One ultrasonic sensor, a servo, an Arduino Nano, and about sixty failed attempts at getting the detection threshold right. The mask would lift when you put your face near it, which meant it also lifted whenever you leaned over your desk.
I never fully solved the false-positive problem. The real solution would have required a better sensor and more calibration time than I had. I shipped it anyway because a mask that lifts 90% of the time in the right context is more useful than one that works perfectly in theory. That pragmatic call — shipping something useful over something perfect — has stayed with me in every project since.
What I learned
Shipping something imperfect beats not shipping. But only if you're honest about the limitations — to yourself and to anyone using it. The ₹280 cost was also the lesson: constraints on resources force you to understand what the core problem actually is.
