The price problem
Agricultural drones work. That was never in question. The issue is that a commercial one runs ₹5-10 lakhs — roughly $6,000 to $12,000 — which prices out essentially every small and medium farm in India, meaning the farms that could most use early warning about a failing crop are the ones that can't buy it.
In 2022 I joined a government-funded project at IIIT-L aimed at that gap. The target was a drone under ₹50,000, about $600, that could capture aerial imagery, analyse crop health on board, flag pests and disease early, and hand a farmer something they could act on.
The last item is the one that quietly reshaped the project.
Twelve people, four disciplines
This was not a software project with some hardware attached. It needed mechanical design, embedded work, computer vision, and ML, and I led a team of twelve students spread across all of it. My own work was project management, the ML, and systems integration — which in practice meant the seams, and the seams were where most of the difficulty lived.
Designing it to be copied
Every component had to be 3D-printable or sourceable locally, modifiable for uses we hadn't thought of, and documented well enough that someone else could rebuild it without us.
That last constraint shaped the hardware more than any performance target. A cheaper part that can't be bought in the district it's meant to be used in is not cheaper.
The model
We collected over 50,000 images across three crops — wheat, rice, mustard — in four states: healthy, water-stressed, nutrient-deficient, and disease or pest affected. Agricultural experts from IIIT-L's partner organisations labelled them by hand, which took far longer than gathering the images did.
Inference had to run on the drone, so the model had to be small. MobileNetV2 as the base got us:
- Validation accuracy: 87.3%
- Model size: 9.2 MB, quantized to 2.4 MB for edge deployment
- Inference time: 180ms on a Raspberry Pi 4
87.3% is a number worth being plain about. It's good enough to tell a farmer where to walk and look. It is not good enough to act on without looking, and we were careful never to present it as more than that.
In the field
We ran trials on five farms across Uttar Pradesh. Early detection of water stress, nutrient deficiency and pest infestation avoided an estimated 20-30% yield loss.
Field testing is also where the gap between a working prototype and a usable tool shows up. Things that were never a problem indoors — wind, dust, glare on the operator's screen, battery behaviour in heat — became most of the engineering work in the final months.
Released
Everything went on GitHub under MIT: hardware design files as STL and CAD, flight control firmware, ML training code and datasets, and the web application source.
Since then it's been replicated by 15+ universities for research, used by three agricultural startups as a base for commercial products, presented at agricultural technology conferences, and downloaded 2,000+ times.
The startups were not something we planned for. The licence permits it, and a commercial product that reaches farms is the goal regardless of who ships it.
Three things I got wrong first
We nearly built the wrong product. The early design assumed farmers wanted data — imagery, health maps, numbers. Interviews made it clear they wanted a decision: which field, what's wrong, what to do this week. Same sensors, different product, and we'd have found out far too late without those conversations.
Reliability beats capability. A drone that works 95% of the time reads as broken to someone who has to drive to the field to fly it. Months went into failure recovery and error handling — unglamorous work that determined whether the thing was used at all.
Documentation is the deliverable. For open-source hardware it's the entire difference between a project people admire and a project people rebuild. The universities that replicated this did it from the docs, not by talking to us.