What's Your PyLabRobot Project?

General
1

Hello Everyone,
I’m curious to learn about the projects everyone is building with PyLabRobot.
Looking forward to meeting you all,
Dale

4 Likes
2

Working on cell culturing

3 Likes
3

some toy projects I made during initial development:

and:

  • a soon-to-be-released closed-loop liquid class optimizer
4 Likes
4

pylabrobot has been essential for setting up and scaling automated cell therapy drug discovery research where flexibility & quick integration is key

our engineers review PRs on stem cell differentiation protocols defined entirely by git-tracked python scrips and serialized object definitions

we think it’s based!

3 Likes
5

Obviously none of us can release any proprietary information from our companies but broadly, we’ve been using PLR for everything you can imagine happening in a biopharmaceutical company:

A Case for a Nuanced Outlook on Programming in BioWetlab Automation

Classified by application I guess our work can be broadly divided into:

  1. Molecular biology
  2. Bio-assays
  3. Cell biology

i.e. “everything” :sweat_smile:

Classified by task complexity I divide any automation task into:

  1. Process churning, i.e. simply automating a task in the lab (e.g. extractions, NGS prep, …): this is relatively easy, because besides throughput, nothing really changes between protocol executions.
    This means you can easily optimise specific liquid transfers and plate movements - this is what (in my experience) 99% of robot manufacturers cater to.
    → a good argument can be made that you don’t need programmatic/Python control for these tasks, and the original engineering manufacturer’s (OEM’s) proprietary GUI control software might not only be sufficient but might be better because it enables end user who cannot code (i.e. the vast majority of end users in bio-wetlabs).
    But for the writer of automated protocols GUIs are a nightmare that costs insane amounts of time by hiding the necessary features in a [pop-up in a [pop-up in a [pop-up in a [pop-up in a [pop-up]]]]] … PLR offers instant access and understanding to all features (e.g. function attributes and their defaults) via Python.

  2. Defined Automated Experiments, i.e. automation tasks that fundamentally vary from run to run, making it extremely difficult to optimise all liquid transfers and plate movements. But “defined” means that a human still declares the precise actions the machine has to execute.
    → this is were things really start to turn: with rapid changes to your setup you must have a Git-based (or equivalent) version control system that tracks what your experiments did at any time. The days of the physical lab notebook are over when you perform experiments with 1_000s of runs/experiment, and have complex sample patterns. Manually cataloging everything in an ELN is something companies won’t be able to afford (imo) because it is too error-prone and costs way too much time.
    This is also where machine accuracy becomes a massive issue. How do you verify your liquid transfer accuracy and precision for experiments in which your liquid’s composition is constantly changing?
    While the “old guard” appears to simply ignore these challenges or thinks they are not solvable, we know they are solvable with advanced, and crucially autonomous, liquid verification tools.

  3. Autonomous & Adaptive Experiments, the Golden Goose of BioWetlab Automation:
    i.e. experiments that are (a) defined in higher level terms, i.e. the design space to search through + any (potentially highly complex) constraints, and (b) in which an Autonomous Research Agent (ARA) makes iterative decisions of how to search/navigate through this design space.
    A human can be “in-the-loop” or “out-of-the-loop”/closed-loop to approve decision making of the ARA.
    In this situation the ARA makes decisions of what the machine setup is going to do. There is no time for human-based verifications.
    → I have never seen an OEM software that is capable of achieving such power. We are firmly in programmatic robot control territory here. Entire companies have been created to make this a reality undoubtedly driven by the enormous leap in efficiency one can achieve this way. However, PLR enables us to do this right now (with still quite a bit to be figured out!), simply by offering access to all the necessary tools via Python.

Classified by automation workcell complexity we divide any setup into (at least):

  1. Liquid Handler-only setups (potentially with small machine integrations [e.g. heater-shakers] and liquid handler upgrades [e.g. a camera-channel])
  2. Integrated workcells, i.e. there usually is 1+ central liquid handler and then n numbers of additional machines (e.g. plate readers, microscopes, robotic arms, fancy maglev plate shuttles, …)

Classified by type of PLR work/project we distinguish:

  1. Technology/PLR development: PLR still has and as time progresses most likely always will have a lot to improve upon, i.e. CD/CI and maintenance work.
    → this is our open-source work, and what we can share freely with the world:
    you can go through the PLR GitHub repo pull requests for a full record of PLR tech dev projects, and I’ve recently made this PyLabRobot Feature Demo: cLLD Probing for Resource Definition Automation.

  2. Process development: building automated workflows with many automated Protocols (aPs, equivalent to what some OEMs call “method”) - currently in the strong IP state but I’m sure as time progresses more people will be able to share some of these in a soon-to-be created PLR Protocol Library.

  3. Deployment Projects: our workflows and protocols might be nice but by themselves they don’t create any value.
    We must deploy them to generate data/products/services/insights in the biology we investigate. This is what generates value and the automation is the catalyst. Obviously proprietary in nature.
    (Companies that ignore this spend a ton of money, time and resources on automation which never leads to a return on investment)

This is all obviously reductive but hopefully still answers your question by showcasing the range of projects PLR is being used while hopefully providing a more nuanced outlook towards programmatic robot control in general :slight_smile:

4 Likes
6

Do you have any specific example of “Autonomous & Adaptive Experiments”?

7

Besides the bachelor thesis of a very talented young engineer, unfortunately I cannot talk about any specific biology examples.

But I can give a (hopefully) informative link to the general concept :sweat_smile:

The problem with autonomous experiments is no longer the software imo but making the hardware operable enough for our autonomous research agents to be able to do what they need to do… PLR is the only way I can see this being accomplished robustly, but PLR is not fully there yet.
Hence, there is a ton of PLR work to do and why I’m adding a lot of features with the explicit intend for it to be used by an algorithm or AI :slight_smile:

3 Likes