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

Before we hand over a mobile manipulator, we test the agreed hardware configuration, platform functions and interface responses. The FAT plan also covers interrupted commands, failed handling and recovery. Your software team receives the tested configuration and results alongside the hardware.

What our platform FAT covers

For an OEM mobile manipulator, FAT should answer a simple question: Does the delivered hardware platform perform the agreed functions, in the agreed configuration, under the agreed test conditions?

That sounds obvious, but projects often blur three different layers:

• 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

A FAT report is weak if the tested machine cannot be reconstructed later. Before the test begins, record the as-tested configuration:

• 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. An OEM project does not need to reproduce every test in that document, but it is a useful reference for defining measurable navigation performance. It is not a safety-validation standard, and the final platform classification may require different or additional standards.

For instrument service, docking repeatability is usually more directly related to manipulation success than general map-navigation accuracy. 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 safe pose,
• 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 therefore has to be determined for the complete machine and intended use.

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.

For an OEM platform, this part of FAT is especially valuable because the customer may begin scheduler integration before the final robot is shipped. A documented interface test gives both teams a shared baseline.

10. Test faults and recovery

We include interrupted and failed cycles in the acceptance plan so both teams know which state the platform enters and what recovery is permitted.

At minimum, consider test cases for:

• 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?

This structure prevents “error recovery” from becoming an undefined promise.

11. Repeatability testing needs a declared method

We record the measurement method and tested setup with each repeatability result:

• 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. Combining them into one undocumented number makes later troubleshooting almost impossible.

12. Record open items and release decisions

We record 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.

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.

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.

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