Laboratory and QA Automation Systems

Motionwell’s flagship laboratory project delivers a working QA laboratory automation system in a manufacturer’s own test lab. An autonomous mobile robot carrying a collaborative arm moves samples between a 70-position PLC-native storage rack and the lab’s universal testing machines, covering tensile, compression and flex testing with traceability from sample pickup through to filed result.

This is not a concept or a pilot. The customer has re-ordered against it for four consecutive years, and the same architecture is now being replicated for other manufacturers. This page describes what that looks like from inside a QA lab. If you are evaluating the technology itself, transport, instrument tending, scheduling, traceability and what each layer costs, start with the laboratory automation capability page, which owns that subject in detail.

What does Motionwell’s QA lab automation system actually do?

Motionwell Automation builds QA laboratory automation in Singapore for mechanical test labs. The delivered system pairs an autonomous mobile robot with a collaborative robot arm as one compound mobile unit, moving samples between a 70-position PLC-native storage rack (7 rows x 10 columns) and the lab’s universal testing machines for tensile, compression and flex testing, with vision-compensated docking at pickup. A single PLC orchestrates sample queuing, test scheduling, automatic result-file naming and network upload, with no MES layer required, and sample state is tracked explicitly from queued through to completed. The customer has re-ordered against it for four consecutive years. Sample transport is one entry in the full capability list; the scheduling logic, the vision correction and the qualification route are written up separately.

Which labs is this built for?

Mechanical QA labs, not analytical chemistry benches. The pattern fits a lab that runs a high volume of repetitive destructive or mechanical tests on a small number of instrument types, where the samples are physically handled and the results are filed against a batch or a lot.

That describes the incoming and in-process test labs attached to medical device manufacturing, the release testing behind pharmaceutical packaging lines, and materials and coupon testing in aerospace and precision machining. What these labs share is not the test method. It is the shape of the working day: a queue that builds up during the shift, instruments that sit idle overnight, and a technician spending part of every day carrying trays and renaming files.

Inside the QA lab programme: what was delivered?

How reliable is the sample handoff, cycle after cycle?

This is the question that decides whether a lab can leave the system running unattended, and it is the one customers ask first. A mobile robot does not park in exactly the same spot twice, so precision has to be recovered at the point of pickup rather than assumed from navigation.

Three layers stack to make the handoff repeatable. SLAM-based localization brings the mobile base to the docking station, correcting continuously against known landmarks. The cobot arm then reaches the target using its joint encoders, with hand-eye calibration mapping camera coordinates onto the tool frame so residual docking offset is already accounted for. Finally, a wrist camera measures the actual sample position immediately before gripping and applies a pixel-to-world correction.

Because the last correction is measured rather than assumed, pickup accuracy does not decay as the AMR accumulates navigation drift over a long shift. The machine vision inspection page covers how that calibration and correction is built, and AMR vs AGV explains why a free-navigating robot is chosen over a fixed-path one in a lab that gets rearranged.

What changes for the lab technician?

Three things, and none of them is the robot.

Samples stop being carried. The rack becomes the single place a sample lives between tests, and the AMR takes the tray to whichever station is free rather than whichever station the technician walked past.

Instruments stop idling. Because a scheduler dispatches work instead of a person, the queue keeps draining after the technician goes home, and the backlog that used to build up over a shift gets absorbed overnight.

Files stop being named by hand. Sample ID, test type, timestamp and operator ID are concatenated by rule and uploaded to network storage the moment a test finishes. Nobody types a filename, so nobody mistypes one.

The technician’s day shifts toward setting up methods, reviewing out-of-specification results and handling the low-volume tests that were never worth automating. How that split is decided, which methods are worth end-to-end automation and which are better left manual, is worked through on the laboratory automation capability page.

Will the records survive an audit?

Sample state is tracked explicitly rather than inferred: queued, in-transit, at-station, in-test, completed, failed. Every transition carries a timestamp and is logged to the server database, so the question “where was this sample at 02:40” has an answer rather than a reconstruction.

For a lab operating under GxP, that log is only half the requirement. Audit trails, access control and electronic signatures on the equipment layer are covered on the electronic device history record page, and the qualification route for the system itself, IQ, OQ, PQ and the traceability matrix behind them, is set out under computer system validation.

Safety matters here too, because a lab is a shared space. A mobile robot and a collaborative arm operating around technicians need a risk assessment before the layout is fixed; cobot safety standards covers what that assessment has to establish, and machine safety and compliance covers the safeguarding, interlocks and certification that follow.

What we need from you to scope it

Four inputs get a realistic proposal back:

• Sample volume per day and per test method, plus how much of it arrives in bursts
• Which instruments you already own, their make and model, and whether they expose a control interface
• A lab layout with floor space, door widths and where the samples currently wait
• Your IT rules for network storage, server access and who is allowed to write result files

The instrument control interface is the item that most often changes the answer, so it is worth checking before anything else. A lab that cannot pause testing during installation is a normal starting condition, not an obstacle, the laboratory automation capability page explains how the build is phased around a running lab.

Frequently Asked Questions

What is QA lab automation and who needs it?

QA lab automation moves samples, runs the instruments and files the results without a technician carrying trays or typing filenames. Motionwell's system pairs an autonomous mobile robot with a collaborative arm to shuttle samples between a 70-position storage rack and universal testing machines for tensile, compression and flex testing, then names and uploads each result file by rule. It suits mechanical QA labs rather than analytical chemistry benches: a high volume of repetitive tests on a small number of instrument types, samples that are physically handled, results filed against a batch or lot. That describes test labs attached to medical device manufacturing, release testing behind pharmaceutical packaging lines, and materials and coupon testing in aerospace and precision machining.

How does Motionwell's AMR-cobot lab automation work?

Motionwell's system pairs an autonomous mobile robot with a collaborative robot arm as one compound mobile unit. The AMR navigates between a 70-position sample rack and the lab's universal testing machines. The cobot loads and unloads specimens using vision-compensated docking. A single PLC orchestrates the whole workflow, including automatic test-result naming and server upload, with no MES layer required. The same customer has re-ordered for four consecutive years.

Can the lab keep testing while the system is being installed?

Yes. A lab that cannot pause testing during installation is a normal starting condition, not an obstacle, and Motionwell phases the build around a running lab. To scope it we need four inputs: sample volume per day and per test method, including how much arrives in bursts; which instruments you already own and whether they expose a control interface; a lab layout with floor space, door widths and where samples currently wait; and your IT rules for network storage and who is allowed to write result files. The instrument control interface is the item that most often changes the answer.