The AI part of a laser weeder is the easy part. Training a model that recognizes weeds in a dataset, that's solved territory. Getting an actual laser to hit an actual weed in an actual moving field, that's the part nobody talks about. My job in California, for [duration], was that part.
I was on a small team from a Berlin-based agtech robotics startup, out in California to run field demonstrations of our laser weeder at a client's tomato farm. The system itself was the team's product. My piece of it was validation: making sure the laser was hitting the right weeds, in the right place on the weed, under conditions that were actually a field and not a lab.
This post is about what that work actually involved, and why it turned out to be a way harder and more interesting problem than I went in expecting.
Briefly, the system
The rig was mounted on a trailer, towed behind a tractor. The trailer was wide enough to span five tomato crop rows. Each row got two of our laser-weeding units, one facing each half of the row. So ten units running in parallel, all looking down at the same thing: newly planted tomatoes, with weeds around them.
Each unit was basically:
- A camera, feeding continuous video of the crop row underneath it
- An NVIDIA Jetson Nano running inference
- A galvanometer steering the laser beam
- A laser diode (the part that actually does the killing)
- Cooling for the diode and the electronics
- The power and electrical setup to keep all of that running off the tractor
Inside the trailer there was a PC running the inference for all ten units at up to 60 frames per second. The model wasn't off-the-shelf. It was custom-trained on imagery we'd collected from this client's actual tomato-weed fields before the demonstration started. The reasoning here is pretty obvious: a generic weed classifier trained on web-scraped images doesn't know what this farm's specific weed species, or this farm's specific tomato cultivar at this growth stage, actually look like. So you train on the field you're going to be deploying in.
When the tractor was moving, each unit's loop was: see a weed in the frame, classify it, work out where in the world that weed actually is (which means accounting for the tractor's speed and the inference latency, so you're aiming at where the weed will be by the time the beam arrives, not where it was in the frame), send the angle to the galvanometer, fire the laser at the base of the stem.
That last part, hitting the base of the stem, is the entire validation problem.
Two questions, two completely different problems
Validating a laser weeder is not one problem. It's two, and they don't overlap much.
Question 1: did the system pick weeds, and not tomato plants?
This one is a classification problem. The failure mode is brutal. A weed that gets missed is a small loss. A tomato plant that gets lasered is dead. No grower is going to deploy a system that kills any non-trivial fraction of their crop, ever. So false positives on the crop are the thing that absolutely sinks commercial viability for a system like this.
Question 2: when the system did fire, did the laser actually hit the stem, at the base?
This one is a targeting problem, and it's about everything downstream of the classification step. Where did the inference engine think the weed was. What angle did it send to the galvanometer. Where did the galvanometer actually steer. Where on the ground did the beam land. Each of those is a step that can go wrong independently of the others.
Hit a weed's leaf with the laser, and you scorch the leaf. The weed regrows. Hit the stem at the base, and you disrupt the meristem and the plant doesn't come back. The difference between "we shot at the weed" and "we killed the weed" is a couple of centimeters of vertical accuracy on the ground.
These two questions get conflated all the time in agtech marketing. "Targets weeds at X% accuracy" usually means classifies weeds at X% accuracy. The number that actually matters for the grower is the kill rate, which is classification accuracy times targeting accuracy times the fraction of stem-hits that actually take the weed down.
What validation looked like day to day
The team would run a planned pass with the trailer over a section of the field. Before and after each pass, I was out in the rows doing the ground-truth work.
Before the pass - I walked the section and characterized the weed population. Counting, locating, sometimes tagging individual weeds I wanted to track specifically. The point was to have a ground-truth picture of what was actually out there, before the system ever saw it.
During the pass - The on-board system logged what it detected, where it fired, and its inference confidence for every shot.
After the pass - I walked the same section again and checked: which weeds had been hit, where on the weed the burn mark was, and whether any tomato plants had been touched. Photographs of every hit and every miss. The burn patterns tell you the truth. A clean burn at the base of the stem is the success case. A scorched leaf is a false success. A burn on a tomato leaf is a hard failure.
Then cross-referencing the on-board logs with the ground-truth observations. That was the actual validation work. The cases that mattered were the ones where the system thought it had succeeded and the ground disagreed. Every one of those was a clue about which part of the pipeline was failing: classification, position calculation, galvanometer calibration, or laser timing.
What turned out to be harder than I expected
A few things were not what I went in expecting.
Stem occlusion. In the dataset the model was trained on, weeds were photographed cleanly. In the field, weeds grow in clusters, leaves overlap, and the base of the stem is often hidden under foliage from the same plant or a neighbor. "Hit the base of the stem" is conceptually clean. Visually identifying the base of the stem from above, in real time, with leaves in the way, is not.
Dust and lighting. California afternoon light is hard light. Dust kicked up by the tractor changes the contrast of every frame. The classification model had been trained on imagery from these same fields, but not necessarily under the same exposure conditions. We'd see classification behavior shift between morning passes and afternoon passes on the same row.
The tractor itself. The whole rig was bolted to a moving, bouncing trailer. Vibration affected the camera, the galvanometer mounting, and the timing of the shots. Calibration that held in the calibration yard didn't always hold after an hour of fieldwork.
Definition of success. Was a hit on the upper stem a success, or a failure? It depended on the weed species, the growth stage, and what we counted as "the base." Some of the most useful conversations during the campaign weren't actually about the technology. They were about agreeing internally on what we meant by "kill" before we counted the kill rate.
What I'd take into the next campaign
Three things, if I did this again.
Treat lighting normalization as a real input. Exposure conditions aren't something the training data is assumed to have covered. They're an environmental variable the model needs to handle explicitly. That alone would have saved us a lot of afternoon-pass debugging.
Denser ground-truth sampling. I was marking representative sections. More aggressive sampling, especially on the harder weed species, would have given us better statistical confidence in the kill-rate numbers we were reporting back.
Stem-base detection as a separate model. The targeting logic computed "base of the visible plant" from the classification mask. A second small model trained specifically on stem-base localization might have closed a meaningful part of the targeting gap.
Why this work mattered to me
A lot of AI/ML work stops at "the model gets X% accuracy on the test set." That number is necessary, but it's nowhere near sufficient for a physical system operating on a real field on a real farm. The work between the model and the kill rate is field-engineering work, and that's where the actual product lives.
The discipline I learned on this campaign, treating the model as one piece of a longer pipeline, instrumenting every stage to figure out which one is failing, agreeing on what success even means before you count it, is the same work I keep ending up doing now on every applied ML system I touch. Different crop. No laser. Same questions.