DrCrop
Turning drone flights into acres not sprayed.
Convert one drone flight into a decision a grower can act on, and then verify with a second flight whether the decision was right.
- Builder
- Fourth place — GStack × GBrain, June 2026
- Survey drones designed and built with teammates
- Deployed prototype, synthetic data
- 2026
- Northern California vineyards
- HTTP API · web demo console · file exports
- Deployed prototype running on synthetic orthomosaics. The survey drones fly and capture imagery, but no vineyard flight has been processed and no grower has used it.
Vineyard treatment is commonly decided a block at a time, even though vine condition varies row to row. Drone imagery can show that variation and is cheap to collect; what does not exist is the layer that turns that imagery into a decision an applicator can follow and a grower can check afterwards.
DrCrop is that layer. One flight produces a map of where to spray, where to scout, and where to skip — with acreage attached — plus the export formats the people downstream actually use, and a verification pass that diffs a later flight against the first.
The survey platform
NVIDIA Jetson Orin
The onboard computer, sized to run perception on the aircraft rather than stream every frame to the ground. The fan is not decorative — sustained inference is what heats it.
Forward-facing camera
The imaging payload. It is an RGB sensor, which is what the excess-green index in this pipeline expects; an NDVI-style crop-health index would need a near-infrared camera instead.
Flight controller and power distribution
Reads the gyro, accelerometer and barometer and runs the loops that keep the aircraft stable. The distribution board feeds the motors from the battery.
Brushless motor and speed controller
Four of them. The controller sets each motor's speed independently, and the difference between them is how the aircraft rolls, pitches and yaws.
Propeller
Two turn clockwise and two counter-clockwise, so their torques cancel and the airframe does not spin about its own axis in a hover.
Carbon-fibre frame
Stiff and light. Frame stiffness is a payload decision as much as a weight one: vibration reaching the camera and the flight controller is what makes survey imagery unusable.
XT60 battery connector
Where the lithium-polymer pack connects. No battery is attached in this photograph.
Ducted trainer quad
Small and shrouded enough to fly indoors, used to exercise the flight stack without putting the payload aircraft at risk.
Second test airframe
Bench aircraft for flight-controller and video-link work, wired up here for configuration rather than flight.
Six stages, one flight
Intake
RGB orthomosaic, field boundary, row geometry
Vegetation index
Excess green per pixel, thresholded to a mask
Row-aware mask
Canopy strips separated from inter-row strips
Zoning
Spray, scout, or skip per cell, with acreage
Export
PDF for the grower, KML and GeoJSON for the field
Verify
Diff two flights: acres spared, zones improved
Every stage is deterministic and independently testable. The model sits outside this path, writing the grower-facing briefing over a plan it did not choose.
The stage that makes it trustworthy
The vegetation index itself is straightforward — excess green, computed per pixel and thresholded into a green mask. Anyone can produce that. The problem is that in a vineyard, green is mostly vines, and vines are supposed to be there.
So the pipeline classifies row geometry first and separates under-vine canopy strips from inter-row strips, scoring weed pressure between the vines rather than under the canopy. Without that step a skip zone is just a place where the canopy happened to be dense, and no grower should act on it.
Management zones
Each cell buckets into spray, scout, or skip with acreage and estimated material saved. Schematic — the live pipeline renders these over the actual orthomosaic.
Exports, because the decision leaves the software
Three different people need the same answer in three different formats.
PDF
For the grower — the overlay map and a per-zone summary in one page they can read without an account.
KML
For the drone pilot and the applicator, so the zones open in the mapping tools they already fly with.
GeoJSON
For the licensed advisor's own systems, as a plain feature collection with no vendor lock.
Implementation notes
The raster and export work is written from scratch on Node's built-in compression: a pure-JavaScript PNG encoder for the orthomosaic and overlay, a hand-rolled PDF builder, and KML and GeoJSON writers. The drone module added zero npm dependencies.
That was a deliberate constraint rather than a stunt. Geospatial toolchains are heavy, platform-specific, and slow to install, and the whole pipeline needed to run on a small deployed instance and stay reproducible. The stages are separated so each one — index, mask, zoning, overlay, encoder, exporters, verification diff — is independently testable, and eight test suites cover them along with the risk engine and adapters.
Closing the loop
The verification endpoint takes two flight identifiers and diffs them, reporting the acreage the prescription would have left untreated and the zones that improved. This is the part that separates a decision-support product from a map: a map tells you what the field looked like, and a diff tells you whether the recommendation was any good.
The briefing layer sits on top, writing a plain-language explanation grounded in the deterministic plan and linked history — with a local fallback when no model key is present, so the pipeline never depends on an external service to produce its output.
What I built
Solo build, apart from the drone hardware. Concretely:
Co-designed and built the survey quadcopters from components with teammates — airframe, motors and speed controllers, power distribution, flight-controller stack, and the companion computer and camera that carry the imaging payload.
Built the six-stage pipeline: orthomosaic intake, excess-green vegetation index, row-aware masking, management zoning with acreage and cost estimates, export, and before/after verification.
Implemented the row-aware mask that separates canopy strips from inter-row strips — the step that makes a skip recommendation defensible.
Wrote a pure-JavaScript PNG encoder, a PDF builder, and KML and GeoJSON writers on Node's zlib, keeping the module dependency-free.
Built the synthetic orthomosaic generator with a ground-truth grid so the pipeline could be validated end to end before any real flight existed.
Implemented the verification diff that compares two flights and reports acres spared and zones improved.
Built the HTTP API, the demo console, the grower-facing site, and a validated lead-capture endpoint with redacted logging and fire-and-forget notification that cannot fail the request.
What remains unproven
- No vineyard flight has been processed. The drones fly and capture imagery, but never over a vineyard. Every result here comes from a deterministic synthetic vineyard orthomosaic with a known ground-truth grid, which validates pipeline shape and nothing about real-world accuracy.
- No grower has used it and no acreage has been sprayed or skipped on its recommendation. The savings figures the zoning stage produces are arithmetic on synthetic inputs.
- Operating this for real requires things software cannot supply: a licensed advisor signing every prescription, drone certification, and insurance. Those are prerequisites, not details.
What I took from it
Build the synthetic case first
A deterministic synthetic orthomosaic with a known answer meant the pipeline could be validated, tested, and demonstrated without waiting on weather, hardware, or a grower's permission.
Domain structure beats model capacity
The accuracy that matters here came from encoding row geometry, not from a bigger model. Knowing that vines are supposed to be green is the entire insight.
Ship the format people already use
A prescription nobody can open is not a prescription. The export writers were as important as the analysis.
Stack
- Survey drone build with teammates — airframe, power, flight-controller stack, imaging payload
- Orthomosaic intake and vegetation index computation
- Row-aware masking that separates canopy from inter-row
- Management zoning with acreage and cost estimates
- PDF, KML, and GeoJSON export writers
- Before/after verification diffing
- Grower-facing site and lead capture endpoint