A bounded workflow with a measurable result.

Workflow

Identify an approved tote, confirm the destination, execute an authorized movement, and stop for assistance when conditions fall outside the agreed scope.

Required foundations

Compatible hardware, commercial software rights, access to the manufacturer’s interfaces, known load limits, and an appropriate site assessment.

Evidence

Task completion rate, intervention rate, cycle time, exception handling, and performance against the customer’s baseline.

Why this is the realistic starting point

Moving known objects between known places in a structured space is as close as robotics gets to a tractable task at commercial scale. Almost every property that makes a robotics problem hard is absent or reduced: the environment can be controlled, the objects are largely consistent, the route is knowable, the volume is high enough to measure reliability properly, and a failure usually means something sits in the wrong place for a few minutes.

It is also commercially legible. This work is already scheduled, already costed and already a known source of difficulty, so an improvement is visible to the person who has to approve it. That is not true of most impressive-sounding robotics demonstrations.

What the task requires in practice

A supervised tote transfer sounds simple and decomposes into a surprising number of things that each have to work:

• Identification. Confirming this is an approved tote, not a similar one, under real lighting and real clutter.
• Pose estimation. Knowing where it is accurately enough to grasp it, including when it is not square to the world.
• Grasp selection. Choosing a hold that survives the weight, the material and the acceleration of the move.
• Load awareness. Staying inside rated limits for the arm and the gripper, including dynamic loads during motion.
• Navigation and clearance. Reaching the destination without contacting people, structures or other equipment.
• Placement. Releasing in a position the next step of the process can accept.
• Refusal. Recognising when conditions fall outside the agreed scope and stopping for assistance rather than improvising.

The last one is the most important and the most often skipped. A capability without a well-specified refusal behaviour is not deployable regardless of how well it performs on average.

Where it actually goes wrong

Not usually in the main case. The failures cluster in the exceptions: a tote that is overfilled or deformed, a label that is obscured, a stack that has shifted, a pallet that is not where the system believes, a person standing in the path, a surface that is wet, lighting that changed because a door opened. Any single one is manageable. The question is the aggregate exception rate, and that is measurable only on a real floor over real time.

The evidence that would matter

A pilot in this area is worth nothing without numbers, and the numbers worth collecting are specific: task completion rate, intervention rate, cycle time against the existing baseline, exception categories with counts, and the conditions under which performance degraded. A completion rate quoted without an intervention rate is not a result.

Current status

Concept only. No material handling software has been built, no robot has been integrated, no site has been assessed and no pilot exists. The task described here would be selected with a technical partner and an operator, and would require compatible hardware, commercial software rights, access to a manufacturer's interfaces, known load limits and an appropriate site assessment before anything ran.

How a pilot on this kind of task would be judged: pilot acceptance criteria and scorecard.