Robot agnosticism

General
21

i agree. we can get a good abstraction and not force/hurt all LH to work the same.

22

visiting this thread back after a week because i deeply think agnosticism (or basically a good wrapper/frontend of what could be standardised) is important. we have quite helpful ones already in PLR and I think having this better at the right layer will bring us a long way. for now, i believe this is what should live in PLR and genuinely helpful:

  1. the resource and labware model;
  2. standard plate, well, tip-rack, carrier, and container definitions;
  3. liquid-volume, tip, resource-location, and machine-state tracking;
  4. shared communication and I/O infrastructure;
  5. standard result formats for analytical instruments, such as plate readers;
  6. common APIs for machines whose underlying operations are genuinely similar.

on 6, using LH example, what we can do is:


Protocol written using the PLR pipetting API

await lh.aspirate(…)

await lh.dispense(…)

↓

Pipette-based liquid-handler frontend

PipetteLiquidHandler

↓

Standard pipetting operation objects

PickupTip

SingleChannelAspiration

SingleChannelDispense

Mix

↓

Machine-specific backend

STARBackend / EVOBackend / OpentronsBackend

↓

Shared or device-specific I/O

USB / serial / HTTP / firmware commands

↓

Physical pipetting robot

vs acoustic liquid handlers


Protocol written using the PLR acoustic-transfer API

await acoustic_lh.transfer(…)

↓

Acoustic liquid-handler frontend

AcousticLiquidHandler

↓

Standard acoustic operation objects

AcousticTransfer

SourceWellSurvey

DropletEjection

↓

Machine-specific backend

EchoBackend / other acoustic backend

↓

Shared or device-specific I/O

HTTP / file exchange / vendor API

↓

Physical acoustic liquid handler

or if needed, make pipette-based LH explicitly different in API, too.

we may also have this hierarchy:


LiquidTransferDevice

├── PipetteLiquidHandler

├── AcousticLiquidHandler

└── NonContactDispenser

where different families can still share the same PLR resource model, plate definitions, well objects, volume tracking, operation logging, serialization, and I/O utilities.

additionally, what i think PLR genuinely need to keep upgrading is state tracking across machines (eg readiness, activity, lid/tray status), not just device actions in the frontend (more here: Suggesting a thicker frontend for getting status of machines · Issue #1183 · PyLabRobot/pylabrobot · GitHub )

therefore, “solving” higher-level scientific protocol intent with planner selecting a suitable device and execution strategy, or handling complex protocols like whole PCR prep, could live outside and build on top of PLR, imho.

23

I imagine we would share the logic of those things across all pipettes of course, but more so coming from the perspective of code sharing (DRY) than making a universal driver API for everything

is this feasible? on what level can you translate? I think that “aspirate” is too low level

24

yes these are all still the same, with the exception of point 6 and to an extent 5

this is learning towards the capability architecture, which imo is the “correct” but not the “dumb” solution. it gets too complex for people to actually use. writing mostly independent drivers is very fast, and it’s agnostic enough for what I actually see people do

1 Like