FAT for an OEM mobile manipulator: what should be tested before hardware handover?

Before a platform leaves the factory, both teams need more than a video of one successful transfer. Can it handle the specified labware, report a failed pickup and leave an interrupted task in a state your software can identify? When factory acceptance testing (FAT) is part of our delivery, we agree those checks with you before testing and record the configuration, results and open items.

What our platform FAT covers

The FAT plan needs to identify the hardware being accepted, the functions to test and the pass conditions. For each result, your team should be able to trace it back to that setup.

Keep the following acceptance responsibilities separate:

• Component qualification — whether the AMR, arm, gripper or sensor meets its own supplier specification.
• Platform FAT — whether the integrated LabCarry hardware platform performs its agreed functions.
• Application / workflow validation — whether the customer’s complete laboratory process achieves the intended scientific or operational result.

Our FAT covers the integrated hardware and its agreed external interface. Your team remains responsible for scheduling, instrument coordination and validation of the complete laboratory workflow.

1. Freeze the test configuration before testing

If a test passes, the report needs to show which machine and setup passed it. Record the as-tested configuration before starting:

• platform serial number or build ID,
• mobile base model and serial number,
• robotic arm model and serial number,
• gripper / end-effector revision,
• mechanical platform revision,
• sensor and barcode-reader configuration,
• controller, firmware and software versions,
• TCP / tool configuration,
• calibration files and relevant parameters,
• test labware and payload,
• station / docking fixture revision.

If the hardware, firmware or calibration changes after FAT, the team should decide which tests must be repeated.

2. Mechanical inspection comes before motion

Before running any automatic cycle, inspect the physical build. Mechanical problems discovered after motion begins can become safety issues or damage cables, instruments or tooling.

A platform-level mechanical FAT can include:

• arm mounting and base-to-platform fastening,
• gripper and tool mounting,
• platform flatness or critical mounting datums where specified,
• mechanical clearances through the intended arm workspace,
• cable routing, bend radius and strain relief,
• connector retention and service access,
• fastener marking / torque evidence where required,
• sharp edges, loose covers and exposed moving pinch points,
• casters, docking hardware, bumpers and external panels,
• labware platform, racks or fixtures against released drawings.

Dimensions should only be measured where they matter to function or the agreed drawing. FAT is not a substitute for manufacturing inspection; it is the final confirmation that the assembled platform matches the configuration that will be handed over.

3. Check wiring, power states and electrical interfaces

Electrical FAT should confirm that the integrated platform behaves predictably across power states and that the wiring matches the agreed design.

IEC 60204-1:2016+A1:2021 is a common reference for the electrical, electronic and programmable electronic equipment of machines. Whether and how it applies depends on the final machine architecture, intended market and legal classification. FAT documentation should therefore distinguish between functional electrical checks performed by the OEM platform supplier and any formal conformity or safety assessment required for the finished product.

4. Mobility testing should separate navigation from docking

For a mobile manipulator, mobility is not one pass/fail item. At minimum, distinguish:

• free navigation — can the platform travel through the defined test route?
• obstacle response — does the platform respond to obstacles according to the configured behavior?
• station approach — can it approach the required station geometry?
• docking / local alignment — can it establish the required final pose relative to the station datum?
• charging — can it enter, maintain and leave the charging process as intended?

ISO 18646-2:2024 provides performance criteria and test methods for navigation of mobile service robots, including pose accuracy, repeatability, obstacle avoidance, path deviation and mapping accuracy. Select the methods relevant to the agreed navigation requirements. A project FAT that uses only part of the document does not by itself establish conformity with the standard. It is not a safety-validation standard, and the final platform classification may require different or additional standards.

For instrument service, measure both the residual docking offset and its repeatability relative to the station datum. Map-navigation accuracy alone does not establish the handoff alignment. Test repeated approaches from different starting positions and headings rather than repeating one identical short route.

5. Manipulator FAT should use the production tool and payload

An arm moving through free space with no gripper and no labware is not representative of the delivered platform. Manipulation tests should use the intended:

• gripper / end effector,
• TCP definition,
• payload and center of gravity,
• speed / acceleration limits,
• arm mounting orientation,
• representative workspace positions.

Useful checks include:

• joint homing / initialization behavior,
• move to an agreed reference or recovery pose under the applicable procedure,
• move to task approach poses,
• workspace reach without mechanical or cable interference,
• repeat operation at near and far reach positions,
• behavior after controlled stop and restart,
• tool / TCP configuration verification.

Where pose performance is a contractual requirement, use a defined measurement method rather than visual judgment. ISO 9283 provides terminology and methods for manipulator performance such as pose accuracy and repeatability.

6. Handling tests should validate the object, not just the gripper

For plates, tube racks and carriers, the relevant question is whether the actual object is picked, retained, transported and placed consistently.

A handling FAT may include:

1. Pick representative labware from a defined source fixture.
2. Confirm object presence using the agreed sensing method.
3. Transport through the expected motion envelope.
4. Place into the receiving fixture without collision or forced seating.
5. Confirm release and final object presence / absence.
6. Repeat with representative tolerance extremes where samples are available.

If multiple labware families are in scope, each should have its own acceptance definition. “Supports tubes and plates” is not a useful FAT criterion unless the exact formats, gripper setup and pass conditions are stated.

7. Barcode and identity checks belong in FAT when they are part of the platform

If LabCarry supplies a barcode reader as part of the hardware platform, FAT should verify the agreed hardware behavior, for example:

• reader powers and communicates correctly,
• configured barcode types can be read on representative samples,
• read result is exposed through the platform interface,
• no-read is reported distinctly from a valid ID,
• mismatch information can be passed to the scheduler if the workflow provides an expected ID.

Whether a mismatched sample should be quarantined, re-routed or rejected is normally application logic owned by the customer scheduler. FAT should verify that the hardware platform reports the information needed for that decision.

8. Distinguish application interlocks from safety-rated functions

Not every motion inhibit is a safety function. A platform may include ordinary application interlocks for collision avoidance or process sequencing, and it may also include safety-related functions implemented through safety-rated hardware and a validated safety architecture. The FAT must identify which is which before testing.

Application-level examples might include:

• arm deployment inhibited until a docking condition is confirmed,
• manipulation inhibited while an instrument access condition is not satisfied,
• a workflow command rejected because a required station state is missing,
• scheduler receives a clear status indicating why motion is not permitted.

Where a function is claimed to be safety-related, its required performance and validation method must come from the actual risk assessment and applicable safety design. A normal software flag, standard PLC input or application sensor should not be presented as a safety-rated interlock unless the architecture and validation justify that claim.

FAT should also avoid implying that one robot standard covers the entire mobile manipulator. ISO 10218-2:2025 addresses industrial robot applications and robot cells and explicitly notes that laboratory automation is not excluded as medical or healthcare use, but it does not cover the mobility hazards created when a robot or manipulator is integrated with a driverless industrial truck or mobile platform. For a mobile base that is classified as a driverless industrial truck, ISO 3691-4:2023 is one relevant safety reference; other classifications can require different standards. The applicable safety framework has to be determined for the complete machine and intended use. The cited robot and truck standards do not, by themselves, address every hazard from dangerous loads or applications with specific hygienic requirements.

9. Interface FAT should test state and fault behavior

The customer software team should be able to rely on the platform interface after delivery. Test more than connectivity.

Agree these responses before your software team builds against the interface. If integration starts before shipment, use the same command definitions and expected results in the interface test and the final FAT.

10. Test faults and recovery

A successful cycle does not show what your team should do after an interruption. Include the relevant fault cases in the acceptance plan, with the expected platform state and the permitted next action.

Select the relevant cases with the engineers responsible for the test. Before running them, agree the simulation or controlled test method, protective measures, approved test loads and how the equipment will be restored. Use that method to check the response without creating an uncontrolled fault. Cases to review include:

• failed docking,
• blocked route,
• grip not confirmed,
• object lost / not detected,
• barcode no-read,
• barcode mismatch,
• arm motion error,
• interlock active,
• low battery or charging failure where relevant,
• scheduler disconnect,
• platform restart during or after an incomplete task.

For each fault, define three things:

1. Detection: how does the platform know the fault occurred?
2. Containment: what motion or action stops, and what state is entered?
3. Recovery ownership: does the platform recover automatically, does the scheduler decide, or is operator intervention required?

For example, a missing grip confirmation should lead to a defined state and a named decision owner. The words “error recovery” alone do not tell either team what may happen next.

Fault-case record: separate the response from the recovery decision

Use one record for each selected fault case. Agree the expected result before testing, including the evidence required to establish the object location and the operation outcome. A restored connection does not, by itself, establish whether a plate movement completed.

The matrix below is a planning aid, not a procedure for causing a fault. The responsible engineers must choose and approve a simulation or controlled test method for the actual equipment. It does not instruct anyone to interrupt power under load, bypass a safeguard or enter the robot workspace. Where a case cannot be represented safely or faithfully, record the coverage gap and the required next assessment.

For every selected row, record: case ID; requirement and expected response; platform/tool/fixture/firmware versions; initial supported object state; approved method reference; permitted test conditions; actual observations; result; evidence files; unresolved items; and recovery decision owner. Use pass, fail or not tested against the agreed criterion. If the outcome remains unknown, preserve that uncertainty in both the report and the interface state.

Keep the first result when a retest passes

Illustrative record: after reconnection in case FC-03, neither a retained operation result nor the agreed explicit reconciliation path is available. The agreed criterion requires at least one of those two outcomes, so this observation fails that criterion. Record what the interface actually returned and the missing evidence. A later firmware correction gets a new configuration entry and retest reference. Retain the original failed result beside the new result; the correction does not change what the earlier build demonstrated.

Use the recovery responsibility note to name the decision owner and the completion evidence worksheet to define what resolves an uncertain transfer. Application scheduling and laboratory-process disposition remain with your integration team. The hardware FAT verifies the agreed platform response and evidence, while safety validation follows the separately approved assessment and procedure.

11. Repeatability testing needs a declared method

A repeatability result needs its measurement method and tested setup beside it. Record:

• what was measured,
• measurement reference / datum,
• number of repetitions,
• starting conditions,
• payload and tool,
• speed / motion settings if relevant,
• environmental conditions where relevant,
• calculation used for the reported result.

For a mobile manipulator, separate at least docking repeatability, arm task repeatability and end-to-end handoff performance. A single undocumented number gives the next engineer little help locating whether an error came from docking, arm motion or the final handoff.

12. Record open items and release decisions

The FAT record should list incomplete tests and open items with an owner, required action and release decision.

Classify findings, for example:

• Pass — requirement met.
• Pass with observation — requirement met, non-blocking note recorded.
• Open action — correction required before shipment or agreed closure point.
• Not tested — test could not be executed; reason and ownership recorded.
• Out of scope — explicitly not part of platform acceptance.

Each open action needs an owner and closure evidence. An incomplete or failed check remains recorded as such until the agreed corrective work and retest are complete.

13. Decide the retest scope from the change impact

A hardware change does not automatically invalidate every FAT result, and a familiar part number does not automatically preserve the old evidence. Start with the last accepted configuration and the proposed configuration. Identify the function, physical reference, interface definition or test assumption that changed, then follow that dependency into the affected requirement.

Use the change review to choose one of four dispositions for each affected requirement: retain earlier evidence with a reason, repeat an existing check, add a new check, or hold the item until the missing input is resolved. Define the configuration, conditions and pass/fail criterion before execution. A successful free-space grip, for example, does not close station-clearance, payload or interface-response questions that it did not test.

Hypothetical example: longer fingers are proposed to reach a recessed pickup surface. Review the new contact position, tool reference, retained object, station opening and withdrawal path. Check whether the added tool mass and its position affect the selected arm’s load assessment. The result can close only the criteria represented by the agreed test conditions.

Keep a compact release record: change ID; old and new revisions; affected requirements; retained evidence and its justification; repeated or new checks; actual results; unresolved findings; and the decision owner. Attach results to the as-tested configuration. NASA’s requirements verification matrix guidance illustrates the general traceability principle of linking a requirement and its source to a verification approach; it does not certify this project or prescribe its laboratory process.

Use the labware difference record when the change starts with plates, racks, lids, inserts or carriers. Keep the resulting configuration and evidence with the traceability review and the handover document checklist. If a safety-related function or hazard assessment is affected, route that part to the responsible safety professionals; this change review does not authorize a reset, bypass or return to service.

Recommended FAT handover package

• As-built hardware configuration and serial-number record.
• Released mechanical / electrical revision information.
• Firmware, software and interface versions.
• Calibration record for the agreed platform configuration.
• FAT protocol with pass/fail criteria defined before test.
• Completed test results and measured data where applicable.
• Fault / recovery test record.
• Open-item list and closure status.
• Platform interface document and supported command/state definitions.
• Operating / service information included in the contracted scope.

Use the configuration and traceability review to identify the build that the FAT evidence applies to. Tie interface tests to the agreed command, state and recovery definitions. Include these requirements when defining the OEM manufacturing work package.

What should be agreed before FAT?

• Which hardware configuration is being accepted.
• Which tests are mandatory and which are informational.
• Pass/fail limits for positioning, docking, manipulation and interface behavior.
• Representative labware, payloads and stations.
• Who witnesses or signs off the FAT.
• What evidence must be included in the report.
• Which customer-owned software or instrument functions are excluded.
• What changes trigger partial or complete re-test.

FAT does not replace the complete-machine risk assessment, validation of safety-related functions, regulatory conformity assessment, or site acceptance and commissioning in the final operating environment. Route geometry, floors, operating zones, station placement, human access and surrounding instruments require site-specific verification. Confirm the applicable published standards, market requirements and project classification at the start of each project.

Technical references

• ISO 18646-2:2024 — Robotics — Performance criteria and related test methods for service robots — Part 2: Navigation
• ISO 9283 — Manipulating industrial robots — Performance criteria and related test methods
• IEC 60204-1:2016+A1:2021 — Safety of machinery — Electrical equipment of machines — Part 1: General requirements
• ISO 10218-2:2025 — Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells
• ISO 3691-4:2023 — Industrial trucks — Safety requirements and verification — Part 4: Driverless industrial trucks and their systems