Wet-lab robotics: the orchestration layer

A single instrument — liquid handler, incubator, plate reader — is a closed problem with known physics. Connect six of them through one transport robot and you have something else entirely: a distributed system with shared resources, mismatched cycle times and partial failure. Most of the engineering difficulty of wet-lab robotics lives in that federation layer. The devices were never the hard part; the between is.

Scheduling is part of the protocol

Devices in a line have wildly different cycle times — a one-hour incubation next to a thirty-second read — and they share single-capacity resources: the transport arm serves every station. Sequencing plates through this is a production-scheduling problem, and it is not bookkeeping, because the schedule is itself an experimental variable. A plate that queues forty minutes for a busy reader has evaporated further and aged differently from its replicates; spread in waiting time is experimental noise the researcher never asked for. A reproducible protocol therefore requires a reproducible schedule — bound timing belongs to the method, alongside incubation temperature and reagent age. Static schedules break at the first deviation, so real systems re-plan continuously as devices report state.

Every device is a fortress

Instruments were designed to be driven by a human through their own interface, and much of their internal state — what a centrifuge did about an imbalance error, where a reader believes the plate is — is invisible from outside. Integration drivers paper over this, and abstractions leak: a device reports “ready” without saying what it is ready for, and an acknowledgement that a step “completed” underdetermines what actually happened in the well. Device-communication standards — SiLA 2 and OPC UA in this space — attack exactly that by giving instruments a common command model and exposed state, but coverage is uneven, and an integrator still ends up encoding instrument-specific knowledge by hand. The interface, not the motor, is where integration projects spend their time.

Failure is the design case, not the exception

In a manual lab, errors are absorbed by a person noticing. In an unattended line, the first deviation meets nobody, so recovery has to be designed in. Moves must be atomic: a plate is either in nest A or in nest B, never in between — a power cut mid-transfer otherwise leaves a plate in the void, and inventory tracking stops meaning anything. Mature systems keep a whitelist of recognised exceptions — a short tip, a missing lid, an unbalanced rotor — each with a scripted recovery, and define fail-safe states: on anything unrecognised, the system brings itself to a known configuration and stops with a specific alarm. The human is not eliminated but repositioned, from continuous operator to the addressee of a defined alarm state. How far that delegation can go — all the way to someone operating the line from another country — is the question the remote-operation model takes up.