Preparing the published article.
Humanoid Pilot Acceptance Checklist: Tasks, Recovery, Handover
Define testable tasks, an intervention taxonomy and rollback criteria so a humanoid pilot ends in a written decision.
An acceptance checklist is not a summary of the pilot. It is the document that decides whether payment, extension or rollback happens, and it only works if the pass and fail conditions are agreed in writing before the robot arrives.
1. Freeze the task set in writing before the pilot starts
Define each task as a numbered sequence with a stated start state, a stated end state and a completion definition. "Pick the tote from the lower shelf and place it on the outfeed conveyor" is testable; "assist with order picking" is not. For each task, write whether the object pose is known to the robot or must be found, whether objects may be occluded or stacked, what the item weight and surface are, and what the correct behaviour is when the item is missing. Fix the environment too: lighting level at the working position, floor condition, and whether people or vehicles cross the path. At acceptance, run each task a set number of times in one session and record completion rate and intervention rate per task id, never as a single aggregate figure. If a task cannot be defined to this level of detail, it is not ready to be accepted.
Build one table with a row per task: task id, start state, end state, objects, environment, required repetitions, and the pass threshold. Both parties sign the same table, and any task added later is added in writing with its own threshold.
2. Define intervention, recovery and handover down to the event
The intervention taxonomy is where a pilot is won or lost. Every human touch should be logged with a cause code: grasp failure, navigation stall, localisation loss, obstacle it refused to pass, e-stop pressed by a bystander, operator error, or environment change. Draw the distinction between a soft intervention, where the robot reports and self-recovers, and a hard intervention, where a person must physically reset, reposition or restart it. Recovery behaviour is a separate test: deliberately introduce a displaced object, a blocked path and a mislabelled tote, then measure whether the robot attempts recovery, how long recovery takes, and what fraction of events resolve without human contact. Record the outcome, not the impression. Then test handover. At the end of the pilot the site should receive a written handover pack: task procedures as numbered steps, a fault-code-to-action table, a list of routine maintenance items with intervals, and the contact path for escalation. Ask the operator who ran the robot to perform each procedure unaided while you watch, and record which steps needed prompting.
Before anyone steps onto the floor, agree how the e-stop chain works: onboard button, wireless pendant and fleet-level command, and which of those actually cuts motion. Ask for the stopping distance and time measured on your floor, at your payload and speed, and record it in the log rather than the brochure. Test the guarding questions in the same session: does the robot slow, stop, or replan when a person enters the path; how much floor area does it need to keep clear; and who authorises bypassing a safety function. Log every e-stop with position, speed, cause and the time taken to restart, because restart time is a real cost in a shift.
3. Write the exit criteria and the rollback plan
Define three outcomes in advance: pass, conditional pass with a named remediation list and a review date, and fail with a rollback. Each condition needs a metric, a threshold and a measurement window. A conditional pass must name who fixes what by when, and what the second acceptance test will consist of. A rollback plan should state how the robot is removed from the floor, how the space is restored, and who bears the cost of the removal, so the decision is a commercial one rather than an argument. Add the data clause: state which logs, images and maps the site retains after the pilot, in what format, and for how long. Finally, run one blind repetition on the last day: pick a task at random from the agreed set, without telling the operator in advance, and record the result. A checklist that only tests rehearsed tasks measures preparation, not capability.
Photo credits: the images in this article are licensed reference photographs of the relevant robot class, credited with author and licence in each caption; they are not photographs of the specific equipment discussed. Licence and author details are recorded with each image.