Agricultural robotics failures: a working framework for postmortems that carry into the next season
When an autonomous machine fails in the field, the lesson often stays with the operator who was there. This briefing lays out a four-question postmortem framework with four failure classes, including the viability failures that take machines out of the field even when they work.
When an autonomous machine fails in the field, the lesson often stays with the operator who was there. This briefing lays out a framework for turning a single incident into a repeatable postmortem: what the robot was supposed to do, what it observed, what it decided, and what the ground truth was. The purpose is to distinguish a one-off fault from a systemic one before the next season starts.
This is a first-principles framework, not a field study. No manufacturer, farm or robot dataset was analysed, so the categories below are professional conceptual tools, not a postmortem of any specific deployment, South African or otherwise. Many operators may already keep incident logs of some kind. What the four-question structure adds is a forcing function: it makes the operator ask the viability question explicitly and write the answer somewhere the next person can find it, instead of letting the lesson live only in one head. The framework becomes evidence only when tested against actual operational logs.
The postmortem discipline
For each incident the framework asks four questions:
- What was the robot supposed to do?
- What did it observe?
- What did it decide?
- What was the ground truth?
The purpose is repeatability, not blame. A record built on these answers makes it possible to tell whether a fault recurs, and whether the fix from the last incident held.
Four failure classes and the fix each implies
An incident can be decomposed into four classes:
- Sensor error: the position estimate or the detection was wrong given the data. A row-following robot that drifted across a bed because its camera read the crop line in poor light is a sensor-class incident.
- Decision error: the plan was wrong given a correct estimate. The same robot, seeing the bed correctly but steering into it anyway because the path planner chose the wrong row, is a decision-class incident.
- Integration error: the pieces were individually correct but the hand-off between them failed. A robot whose camera and planner both passed their bench tests but lost synchronisation in the field is an integration-class incident.
- Viability error: the machine worked but the economics of keeping it in the field did not.
The first three are engineering classes, and each implies a different technical fix: sensor rework, planning rework, or boundary rework between navigation and task execution. The fourth is different in kind. The public record of commercial failures shows machines that ran and were withdrawn anyway. Naio entered judicial recovery in June 2025 after its service and leasing model proved unsustainable, and relaunched under new ownership selling robots only (Future Farming on the Naio relaunch). FarmWise closed in April 2025 after failing to raise capital to continue manufacturing, with its chief executive citing concrete return on investment that did not prevent the closure (Farm Progress on FarmWise). Abundant Robotics shut its fruit-harvesting business after failing to raise another round during the pandemic, despite a robotics-as-a-service plan built around two 90-day harvest seasons (The Robot Report on Abundant). The pattern in all three is the same: the machine ran, and it was withdrawn for economic reasons. A postmortem that only asks why the robot misbehaved will miss the reason the machine is no longer in the field at all.
The framework does not claim how often each class occurs; that is a question for the logs. It claims only that a record which never asks whether the platform's economics survived the season is incomplete.
From pilot to programme
A useful postmortem ends with concrete, testable changes for the next deployment: a tuning change, a fallback policy, a safety rule, or a commercial threshold. If those changes are recorded against the machine and the site, the pilot becomes a programme with memory. If the record is missing, the lesson stays in one operator's head and the next season starts again.
What an operator should do with this
For a South African operation running or trialling autonomous equipment, the practical step is to agree the four questions and the four classes before an incident happens, then log every field fault against them. A season's worth of such records is what turns this framework into a decision tool for whether a platform is dependable enough to scale. Until such records exist, treat any vendor failure-rate claim as unverified.
