In a real warehouse, autonomy is more than a percentage on a specification sheet. What happens when a robot cannot finish an action matters just as much. If every exception closes the dock and requires an engineer, a high successful-pick rate does not yet create a dependable operation.
Human involvement should be designed as a normal part of the process, with a clear signal, safe sequence, and measurable outcome.
Exceptions found during unloading
An exception is not necessarily a system failure. A robot may stop correctly when it detects a condition outside its approved operating envelope. Examples include:
- a torn, open, or heavily dented carton;
- a package above the permitted weight;
- a strap, wrap, or loose object;
- an unstable wall of freight;
- an inaccessible contact area;
- a full downstream conveyor;
- a person or vehicle in the protected area;
- insufficient vacuum or another technical signal.
Classify these events because their resolution and operational impact differ.
Separate three levels of assistance
Routine operational work includes opening doors, positioning the system, and confirming that the conveyor is ready. It is planned for each load.
Freight exceptions occur when an operator safely removes or adjusts one problem and allows the robot to continue. The help may be infrequent but expected.
Technical events require diagnostics, maintenance, or engineering support. They should not be counted as normal operator activity.
This distinction clarifies which skills are required on site and which assistance can be provided remotely.
Every exception needs a safe state
The operator must see why the system stopped and what action is allowed. Before a person enters the working area, robot motion and relevant energy sources must be controlled according to the approved safety concept.
A complete scenario answers five questions:
- How does the system detect the problem?
- How is the operator notified?
- How does the equipment enter a safe state?
- What may a trained operator do?
- How is a safe restart confirmed?
A “continue” button alone is not an exception-management process.
The interface should explain the action
“Error 47” may help a developer, but it does not help a shift operator. The local interface needs a clear category, problem location, and approved next action. When an event cannot be resolved locally, it should explain how to pass useful information to support.
Capturing the event time, sensor state, and concise context helps identify recurring exceptions without collecting more operational data than necessary.
Measure assistance in minutes and frequency
The autonomous package percentage can be misleading on its own. Ten quickly resolved rejects may affect the shift less than one 30-minute technical stop.
During a pilot, measure:
- exceptions per 1,000 packages;
- share of each exception category;
- active operator minutes per load;
- median and longest recovery time;
- events that required a technician;
- causes that recur across loads.
These measures support a realistic staffing model and identify the most valuable product improvements.
The operator should supervise, not compensate
If a person constantly adjusts packages before every robotic action, the task is not meaningfully automated. Assistance should be infrequent, well-defined, and compatible with the operator’s other responsibilities.
Before deployment, verify that the operator can recognise a signal, complete the safe action, and resume work without the development team. Training should cover common exceptions and the conditions in which work must not continue—not only the normal start sequence.
Convert exception counts into an operator workload
Consider a hypothetical 1,000-carton test with 12 freight exceptions. If each requires two active operator minutes, the exception workload is 24 minutes, or 24 operator minutes per 1,000 cartons. Add a separate 15 minutes for preparation and clearance: the measured workload for that test is 39 minutes.
That result does not mean an operator can leave for the remaining unload. Record notification delay, travel to the dock and whether the operating procedure requires continuous attendance. A ten-minute response delay can occupy the dock even when the correction itself takes two minutes. Report active labour and elapsed interruption separately.
| Event | Record | Ownership question |
|---|---|---|
| Carton outside the tested profile | Profile, location and approved disposition | Who handles the excluded carton? |
| Receiving line unavailable | Queue state and wait duration | Who restores downstream availability? |
| Grip confirmation missing | Sensor state and attempted action | Which recovery is approved for the operator? |
| Recurring technical fault | Fault history and support response | When does the event escalate to maintenance? |
Use the pilot checklist to agree these categories before testing. Carry measured assistance into the unloading cost model; omitting it overstates the change in labour.
Aim for a resilient operation
Zero human touches is not the only measure of maturity. A well-designed system knows its limits, stops safely, explains the situation quickly, and records information that reduces recurring exceptions. This form of human–robot cooperation can be more reliable than an autonomy promise with no clear recovery process.
- human in the loop
- exception handling
- warehouse robotics
KRONA U1 unloads boxes from containers onto pallets or conveyors and also loads containers with boxes from pallets or conveyors. Explore KRONA U1 →
Discuss the pilot process