Introduction
Buying a humanoid should end with evidence that the delivered machine matches the contract. Acceptance testing turns broad promises into measurable requirements before the robot enters normal operations. It also creates a baseline that can be reused after repairs updates and performance disputes.
Key facts
- Acceptance criteria should be agreed before delivery.
- Factory tests and site tests answer different questions.
- Task success should include recovery and human intervention rules.
Write measurable acceptance criteria
Specify payload object set cycle time success rate allowed retries walking surfaces operating time safety functions and maximum human interventions. Avoid statements such as reliable picking or safe navigation unless the contract defines how each claim will be tested.
Factory acceptance checks the delivered platform
The vendor site is suitable for configuration checks joint and sensor health safety functions battery behavior communications software versions and repeatable task tests. Record serial numbers and calibration state so the tested machine can be matched to the unit shipped.
Site acceptance exposes integration problems
The customer site adds real floors lighting wireless networks machines racks people and production timing. Site tests should include doorways workcell access charging traffic and the exact objects the robot must handle. A robot can pass a vendor lab test and still fail because the plant environment changes perception or motion margins.
Include endurance and fault recovery
Run enough cycles to expose thermal load intermittent communication and repeated grasp variation. Inject defined failures such as an unavailable workstation lost network object shift or low battery. Record whether the robot recovers requests help or enters a safe state.
Close with a signed evidence package
Keep test scripts logs videos configuration files calibration results software checksums deviations corrective actions and the final accepted limits. This package becomes the reference for maintenance teams and later software updates.
Limitations and missing information
- Acceptance tests are application specific.
- A short acceptance run cannot prove multi year reliability.
- Changes after acceptance may require partial retesting.
Conclusion
Acceptance testing protects both buyer and vendor because it defines what the robot must do and under which conditions. The strongest contracts use repeatable tests instead of relying on product videos or broad capability language.
Sources and methodology
This guide separates published standards and official technical documents from engineering practice. Draft standards are described as work in progress. Product capability is not treated as verified unless a source supports it.
Related TechniaHQRobot guides
Share this article
Share the current TechniaHQRobot article page.
Continue reading
Open the latest robotics reporting, Physical AI analysis and hardware notes.