Robot Arms
A robot arm moves labware between instruments, for example from a plate hotel to a reader. In UniteLabs an arm is two things: a device, like any other instrument, and a set of teachpoints that say where on the bench it can go.
The arm as a device
An arm runs a connector and appears in the platform as a device. Its actions are grouped into modules, as for any instrument. Module names depend on the connector, but an arm connector covers the same jobs. The PF400 connector's modules, for example:
| Job | What it does | On the PF400 |
|---|---|---|
| Joint moves | Moves each axis to a value | joint_movement_controller |
| Cartesian moves | Moves the tool to a position. Also homes the arm | movement_controller |
| Paths | Moves through a list of waypoints in one call | path_controller |
| Transfers | Picks up or puts down labware in one call | transport_controller |
| Gripper | Opens, closes, grabs and releases | gripper_controller |
| Safety | Stops the arm, cancels a move, recovers after a fault | safety_controller |
| State | Reports whether the arm is powered, homed and idle | information_provider |
| Lamp | Switches the arm's status lamp | lighting_controller |
| Simulation | Switches between the real arm and a simulated one | simulation_controller |
The connector does not plan paths or check for collisions. It drives the positions it is given, in the order it is given them. It does check each target before it moves: a pose the arm cannot reach, or one that would fold the shoulder and elbow into each other, is refused, not attempted.
Teachpoints
Where the arm can go is defined by teachpoints: poses someone drove the arm to and captured in the Teach view. A teachpoint records where the arm actually reached the labware, not where a drawing of the bench says it should be.
- A teachpoint belongs to one device. Two arms in the same cell each have their own, and a teachpoint is only valid while the arm and the instrument it was taught against stay where they were.
- A teachpoint is stored as joint values, one per axis. A Cartesian position can be reached with more than one arm shape; joint values name exactly one, so playing a point back is repeatable.
- A teachpoint has a kind:
| Kind | What it is |
|---|---|
| Nest | Where labware sits on an instrument. The gripper grabs or releases here |
| Approach | A pose just outside the nest, clear of the instrument |
| Transition | An extra pose on the way in or out, when the path needs one |
| Safe | A pose clear of everything, which the arm leaves a nest to and arrives from |
Groups and the safe spine
A nest and its approach, transitions and safe point form a group, named after the station, for
example A1 with NEST_A1, APPROACH_A1 and SAFE_A1. An approach is stored as an offset from its
nest, so it follows the nest when the nest is re-taught.
Stations can share safe points, and the shared safe points form a safe spine. A transfer from one nest to another goes out along the source's group, along the spine and in along the destination's group. A new instrument adds one group; it does not need a route to every other station.
Teachpoints and a model of the bench
A liquid handler computes its positions from a deck model: carrier, track and labware definition give the coordinates of well A1. Those parts are machined to fit one deck, so the numbers hold.
An arm works across instruments that were placed by hand on a bench. A model of that bench says roughly where each instrument is, which is enough to plan and to check a route. To set a plate into a nest it is not: the gripper needs the nest to within a millimeter or two. That last step always comes from a teachpoint taught on the real bench.
Teachpoints in scripts and workflows
Teachpoints live in the platform, attached to the device, and the REST API serves them
(/v1/devices/{deviceId}/teach-points), each with its joint values. A script or workflow reads them
at run time and passes the values to the arm's transfer commands, so a re-taught point takes effect
on the next run. The Teach view can also export them as a JSON file, for a workflow that should
stay pinned to one set of points.
Arm or liquid handler gripper
Some liquid handlers carry their own gripper, like the Hamilton iSWAP or the Bravo's gripper. It moves labware between positions on its own deck, and finds them from the deck model. Use it while the plate stays on that deck. Use an arm when the plate has to go between instruments: the arm finds them from teachpoints, and the platform treats it as a device of its own.
Arm state
An arm reports whether it is powered, homed and idle. It only moves when homed, and homing is lost after a power cycle or a stop. Three actions interrupt an arm, and they leave it in different states:
| Action | Leaves the arm | On the PF400 |
|---|---|---|
| Stop | Halted, motor power off, not homed. Needs recovery | stop |
| Cancel | Halted near a waypoint, powered, gripper still holding. A leg already queued behind the halted one still runs | cancel_motion |
| Recover | Fault cleared and homed again. Recovery itself moves the arm | recover |
Stop is the only true abort. After one, the platform does not know where the labware is: in the nest, in the gripper or at the destination.
Blended paths
A path can blend: the arm carries its speed through a waypoint instead of stopping on it. It then passes near the waypoint, not through it, and the corner it cuts grows with speed. Clearances have to allow for the rounded path. On the PF400, blending needs the controller's status port, and the legs run one at a time without it.
Related
Last updated
Error Handling
Handle device failures, timeouts, and unexpected states safely in your lab automation scripts.
Workflow
The top-level process in UniteLabs, defined by the scientific result it produces. It coordinates phases, data flow, and physical state, and runs the same way locally and on the platform.