Harvest sorting: where quality and margin are lost
Manual harvest sorting runs into the human factor: a single operator evaluates thousands of fruits per shift, and by the end of the shift the attention threshold drops.
The same fruit goes into the first grade in the morning and into the second grade in the evening, because fatigue and lighting change the perception of color and shape.
The spread in evaluation between operators on the same line reaches 15-20%, and this is a direct loss of margin: a batch that went into a lower grade is sold cheaper, although in fact it corresponds to a high one.
Harvest defects make the picture worse. Minor skin damage, incipient rot, uneven coloring — the eye registers them inconsistently, especially at conveyor speed.
A missed defective fruit in a batch triggers a chain: spoilage during storage, claims from the processor, return of the entire batch. Losses during processing grow not because of the raw material, but because incoming inspection did not separate the problem at an early stage.
Fruit quality assessment rests on subjective criteria that are difficult to pass on to a shift. As long as the standard lives in the foreman's head rather than in a measurable model, every new shift starts from scratch.
Hence the unstable quality of batches and the inability to guarantee the processor a repeatable result from delivery to delivery.
We break down how this is closed: where exactly accuracy is lost, which fruit parameters can be measured objectively, and how to integrate assessment into an existing line without stopping production.
How an AI crop sorting system works on the line
What the system sees on the line
Computer vision on a sorting line solves three tasks at once: it finds a defect, measures the geometry of the fruit, and assigns a quality class.
A camera captures the object from several angles, a segmentation model separates the fruit from the background, and a classifier assigns it to one of the specified classes.
The key parameter is camera calibration: without being tied to a color scale and a lighting reference, the same batch receives different scores across different shifts, and the line begins to "drift."
Calibration and scoring stability
Calibration is done against reference samples before a shift and repeated when the batch or lighting changes.
This eliminates the main problem of manual sorting — the discrepancy between operators: the share of disputed fruit that different people assign to different classes drops severalfold.
Scoring becomes reproducible: the same fruit receives the same class regardless of who is standing at the belt.
Throughput speed and quality classes
Throughput speed determines the requirements for the output conveyor: the model must process a frame faster than the fruit passes through the capture zone, otherwise gaps appear.
Quality classes are defined for the task — export, processing, rejection — and may include subclasses by defect type. In practice, line throughput increases, and the rejection share decreases because good fruit stops being sent to waste due to operator error.
| Operating mode | When it fits | Limitations |
|---|---|---|
| Frame-by-frame classification | Simple defects, high speed | Does not see fine geometry |
| Segmentation + classification | Size, shape, color, defects | Requires calibration and references |
| Multi-camera capture | Complex defects, hidden areas | More expensive in hardware and labeling |
We train the model on the customer's real batches, not on synthetic data — otherwise on the line it encounters conditions it has never seen. Labeling is done by agronomists and process engineers: a quality class is a production decision, not just a technical one. To control model drift, we monitor the class distribution and accuracy on a reference sample.
OpenCV
Stages of implementing a crop quality assessment system
Implementing a crop sorting system is not about installing a camera or launching an off-the-shelf model. Assessment accuracy depends on how well we understand your line: conveyor speed, type of lighting, batch uniformity, the varieties and calibers that go into the flow.
That is why the journey begins with an audit and ends with handing over the regulations your shift can use to work with the system without us.
- Line audit and task definition. We record the shooting points, product movement speed, discharge and rejection zones, and bottlenecks of the existing process. The output is a list of defects the system must catch, along with target metrics for accuracy and throughput.
- Installation plan. We select the placement of cameras, lighting, and protection of the optics from dust and moisture, and calculate how the installation will fit into the current conveyor without stopping production for an extended period. We agree on the plan with your engineers before purchasing equipment.
- Data collection and labeling. We collect real batches from your line — different varieties, stages of ripeness, typical defects, and edge cases. Labeling is done by your technologists under our supervision: this way the model learns from your quality standards, not from abstract examples.
- Model tuning. We train and calibrate the model for your classes and rejection thresholds, and adjust sensitivity so that the system does not reject good product or miss a defect. We test on a holdout set that the model did not see during training.
- Testing on batches. We run the system in parallel mode: it assesses the flow, but the operator still makes the decision for now. We compare the model's and the human's verdicts, calculate the share of discrepancies, and adjust thresholds until the result becomes stable across different batches.
- Industrial launch. We switch the system to operating mode, connect it to the sorting and discharge mechanisms, and set up logging: each batch receives a report with the distribution by class and the rejection share.
- Documentation handover. We provide instructions for operators, regulations for optics maintenance and calibration, the installation plan, and the procedure for actions in case of failure. We train the shift and stay in touch during the support period.
The key principle is that the system is tuned to your quality standard, not the other way around. If the variety or market requirements change after a season, the model is retrained on new batches without rebuilding the entire line.
How does appearance-based assessment differ from internal-trait assessment?
External assessment works on reflected light: the camera captures the geometry, color, and texture of the surface. Based on these traits, the line confidently splits the flow into marketable grade, substandard, and reject — shape, size, spots, mechanical damage to the skin.
Threshold values are set from a calibration sample and remain stable throughout a shift if lighting and conveyor speed do not fluctuate. There is one weak spot: external traits say nothing about what is inside the fruit.
Internal defects — voids, core browning, incipient rot, immaturity with normal skin — are not visible under reflected light. They are covered by a separate circuit: spectral inspection in the near range, where tissue absorption differs from healthy areas.
This circuit produces not an "image" but numerical indicators for each item, and thresholds are set based on those.
Hence the key difference: external sorting is a machine vision task on a single frame, while internal sorting is a task of matching spectral signatures against a reference library.
The practical takeaway for choosing a solution is simple. If losses come from shape, color, and surface damage, an optical circuit with calibrated thresholds is enough — it is fast and low-cost to maintain.
If rejects reach the customer with perfect skin, reject classes cannot be built without spectral inspection: thresholds would have to be set blindly, and the share of missed defects would remain unknown.
On a line, these are two different circuits with different throughput, and merging them into one module means losing both accuracy and pace.
We start with which reject classes actually affect shipment, and select a set of traits for them — first external, then internal. This way threshold values rely on line data rather than averaged tables.
Case study: how the rejection rate on a sorting line was reduced
Before implementation, the line relied on visual inspection by operators: a batch consistently passed with 8–12% missed defects, and the variation in assessment between shifts reached 15%.
The cause was not the people — the eye tires by the third hour, and the "pass/fail" criteria differ from person to person. On top of that, the flow had to be slowed down so the inspector could keep up with examining each fruit.
We framed the task differently: not "replace the operator," but give them a tool that maintains the same criterion around the clock. We assembled a training set from manually sorted batches — separately for each defect type, with labeling by severity rather than binary.
The model is trained on this data and calibrated so that the trigger threshold can be adjusted to the acceptance requirements of a specific customer.
What changed on the line
Rejection was split into two loops: automatic screening of obvious defects and a zone where only borderline cases reach the operator. This removed the main load — the person reviews not the entire flow, but 10–15% of it, and fatigue stops affecting the result.
Metrics before and after across three checkpoints:
| Indicator | Before | After |
|---|---|---|
| Share of missed defects | 8–12% | 1.5–2.5% |
| Variation in assessment between shifts | up to 15% | within 3% |
| Flow speed | limited by operator pace | not tied to shift |
Shift stability was tracked separately: previously, morning and night shifts produced noticeably different results on the same batch. Now the discrepancy falls within labeling error — the criterion no longer depends on who is standing at the conveyor.
What provided stability
The key turned out to be not the classifier itself, but the feedback loop: the operator flags borderline cases, they go into retraining, and the model adjusts the boundaries to the customer's actual batches.
Without this, accuracy would have dropped after a couple of months on a new harvest — seasonality and variety change the appearance of the fruit.
For versioning datasets and reproducibility of experiments, we used DVC — this made it possible to roll the model back to a previous point if a new calibration worsened the metric on the validation set.
Compatibility, migration, and rollback: technical concerns
What happens if the solution doesn't fit and has to be rolled back?
Rollback is designed before work starts, not after.
We move the model and sorting rules into a separate loop that can be turned on and off without stopping the conveyor: the line continues to operate as before, while the system's decisions run in shadow mode and are written to a log.
If quality at acceptance is not confirmed, we switch the flow back to manual or the previous logic within one shift, and the line's equipment and settings remain untouched.
The data accumulated during the pilot is preserved: it can be used to retrain the model and return to implementation without re-collecting the dataset.
What about access and roles? The system runs under a separate service account with the minimum necessary permissions: reading signals from the line, writing evaluation results, and access to the image storage.
The line operator gets an interface for confirming disputed cases, the process engineer gets a quality thresholds panel, and the engineer gets logs and metrics. Full access to the industrial network remains with your operations department; we work through an agreed-upon gateway.
How do you integrate into an existing line? Integration is done via the interfaces already present at the site — dry contact, an industrial protocol, or file exchange with a buffer.
If the line manufacturer locks down the protocol, we install signal pickup on the sensors without interfering with the controller.
Data migration when replacing a section is done via control batches: we run the same volume of raw material through the old and new loops and compare the labeling before switching the flow.
What you receive:
- an integration diagram with the line and signal pickup points;
- a matrix of roles and access rights for each account;
- a step-by-step rollback plan with trigger criteria;
- operating regulations and a shift acceptance checklist;
- a log of control batches for comparison before and after migration;
- instructions for the operator and process engineer on disputed cases.
Describe your line and current acceptance process — we'll come back with an assessment and an integration plan for your site.
Implementation Timeline by Stage
The timeline depends not on the amount of code, but on how much data needs to be collected on a real flow and how quickly the line is ready to accept automation.
Below is the approximate duration by stage for crop sorting: from labeling the pilot zone to support during the season. We do not fix dates — they shift according to the harvest window and production schedule.
Data accumulation takes the longest: models need examples of your specific varieties, lighting conditions, and damage types. If a frame archive already exists, this stage is cut in half; if the flow still needs to be labeled — plan it first in the queue.
The pilot zone is a mandatory step, not a formality. On one line you can see how the automation behaves at flow speed and what to do with fruit at the class boundary.
The industrial launch after that goes predictably: the logic has already been tested, all that remains is to scale.
We set aside personnel training as a separate stage: the operator must understand why the system classified a fruit as defective and be able to intervene.
Support during the season is not a one-time setup, but regular monitoring of the error rate and retraining for the new harvest. Describe your line and volumes — we will get back to you with an estimate and a stage-by-stage plan.
