Resource Management System#

The PyLabRobot (PLR) Resource Management System (RMS) is a framework that models both the physical components of an automation setup and the distinct physical behaviors of each component. (It does not provide electronic control of machines. This is the role of PLR’s machine control system.) It provides a structured approach for dynamically constructing precise and adaptable automation system layouts.

The PLR Resource Management System consists of two key components, each serving a distinct role:

  1. Resource Ontology System

    • The ‘blueprint’ of PLR’s physical definition framework, responsible for defining physical resources, modeling their distinct behaviors, and dynamically managing their relationships (i.e. tracking their state).

  2. Resource Library

    • The ‘catalog’ of premade resource definitions. This provides reusable, standardized definitions that enhance consistency and interoperability across automation workflows. This ensures smooth integration, scalability, and efficient resource utilization.

Resource Ontology System#

In PLR every physical object is a subclass of the Resource superclass (except for Tip). Each subclass adds unique methods or attributes to represent its unique physical specifications and behavior.

PLR’s Resource subclasses in the inheritance tree are:

Resource
├── Arm
│ ├── ArticulatedArm
│ ├── CartesianArm
│ └── SCARA
├── Carrier
│ ├── MFXCarrier
│ ├── PlateCarrier
│ ├── TipCarrier
│ ├── TroughCarrier
│ └── TubeCarrier
├── Container
│ ├── PetriDish
│ ├── Trough
│ ├── Tube
│ └── Well
├── Deck
│ ├── OTDeck
│ ├── HamiltonDeck
│ └── TecanDeck
├── ItemizedResource
│ ├── Plate
│ ├── TipRack
│ └── TubeRack
├── ResourceHolder
│ └── PlateHolder
├── Lid
├── PlateAdapter
├── ResourceStack
│ └── NestedTipRackStack (to be made)
└── Workcell (to be made)
Note: On the meaning of the terms "Resource" vs "Labware"

Most automation software systems (e.g. SDKs, APIs, GUIs) use the term "labware" to describe items on a machine's deck. However, in our discussions, it became evident that the term "labware" has different meanings to different stakeholders (e.g., "A plate is clearly labware, but is a liquid handler or a plate reader labware?"). As a result, PLR avoids the ambiguous term "labware".

Every physical item (describable via its item_x, item_y, item_z) is a "resource".

Resource Library#

The PyLabRobot Resource Library (PLR-RL) is PyLabRobot’s open-source, crowd-sourced collection of pre-made resource definitions. Laboratories across the world use an almost infinite number of different resources (e.g. plates, tubes, liquid handlers, microscopes, arms, …). We believe the way to most efficiently capture the largest portion of this resource superset is via crowd-sourcing and iteratively peer-reviewing definitions. If you cannot find something, please contribute what you are looking for!

Note: On the universality of resource definitions

Resource definitions are subject to numerous sources of variability, including (but not limited to) the following:

  • Resource batch-to-batch variability (e.g., a plate's wells height might vary ±1.5mm between different purchases of the same well).
  • Machine calibration differences (e.g., person A's liquid handler's pipettes are tilted in the x-dimension by 1mm compared to person B's).

As a result, many automation software systems believe that it is impossible to reuse resource definitions. In contrast, PyLabRobot is convinced that carefully created resource definitions combined with smart automation can be reused most of the time.

PLR is actively addressing these resource resuse constraints in numerous ways:

  • Development of self-correcting machine backend methods.
  • Using Coordinate Measurement Machine-based generation of resource "ground truths" (e.g., via liquid handler-based resource probing or 3D scanning).

Resource Library