Heuristics for lab robotics, and where its future may go

Heuristics for lab robotics, and where its future may go

Comments

Note: this article required conversations with a lot of people. A (hopefully) exhaustive, randomized list of everyone whose thoughts contributed to the article: Lachlan Munroe (Head of Automation at DTU Biosustain), Max Hodak (CEO of Science, former founder of Transcriptic), D.J. Kleinbaum (CEO of Emerald Cloud Labs), Keoni Gandall (former founder of Trilobio), Cristian Ponce (CEO of Tetsuwan Scientific), Brontë Kolar (CEO of Zeon Systems), Jason Kelly (CEO of Ginkgo Bioworks), Jun Axup Penman (COO of E11 Bio), Nish Bhat (current VC, ex-Color cofounder), Amulya Garimella (MIT PhD student), Shelby Newsad (VC at Compound), Michelle Lee (CEO of Medra), Charles Yang (Fellow at Renaissance Philanthropy), Chase Armer (Columbia PhD student), Ben Ray (current founder, ex-Retro Biosciences automation engineer), and Jake Feala (startup creation at Flagship Pioneering).

Introduction

I have never worked in a wet lab. The closest I've come to it was during my first semester of undergrad, when I spent 4 months in a neurostimulation group. Every morning at 9AM, I would wake up, walk to the lab, and jam a wire into a surgically implanted port on a rat's brain, which was connected to a ring of metal wrapped around its vagus nerve, and deposit it into a Skinner box, where the creature was forced to discriminate between a dozen different sounds for several hours while the aforementioned nerve was zapped. This, allegedly, was not painful to the rat, but they did not seem pleased with their situation. My tenure at the lab officially ended when an unusually squirmy rat ripped the whole port system out of its skull while I was trying to plug it in.

Despite how horrible the experience was, I cannot in good conscience equate it to true wet lab work, since my experience taught me none of the lingo regularly employed on the r/labrats subreddit. I mention my lack of background context entirely because it has had some unfortunate consequences on my ability to understand the broader field of lab automation. Specifically, that it is incredibly easy for me to get taken for a ride. This is not true for many other areas of biology. I have, by now, built some of the mental scaffolding necessary for me to reject the more grandiose claims spouted by people in neurotechnology, toxicology prediction, small molecule benchmarks, and more. But lab robotics eludes me, because to understand lab robotics, you need to understand what actually happens in a lab-the literal physical movements and the way the instruments are handled and how materials are stored and everything else-and I do not actually understand what happens in a lab.

Without this embodied knowledge, I am essentially a rube at a county fair, dazzled by any carnival barker who promises me that their magic box can do everything and anything. People show me robots whirling around, and immediately my eyes fill up with light, my mouth agape. To my credit, I recognize that I am a rube. So, despite how impressive it all looks, I have shied away from offering my own opinion on it. This essay is my attempt to fix this, and to provide to you an explanation of the heuristics I have gained from talking to many people in this space. It isn't comprehensive! But it does cover at least some of the dominant strains of thought I see roaming around in the domain experts of the world.

Heuristics for lab robotics

There are box robots, and there are arm robots

This is going to be an obvious section, but there is some groundwork I'd like to lay for myself to refer back to throughout the rest of this essay. You can safely skip this part if you are already vaguely familiar with lab automation as a field.

In the world of automation, there exist boxes. Boxes have been around for a very, very long time and could be considered 'mature technology'. Our ancient ancestors relied on them heavily, and they have become a staple of many, many labs. For one example of a box, consider a 'liquid handler'. The purpose of a liquid handler is to move liquid from one place to another. It is meant to take 2 microliters from this tube and put it in that well, and then to take 50 microliters from these 96 wells and distribute them across those 384 wells, and to do this fourteen-thousand times perfectly, which is something that humans eventually get bored with doing manually. They must be programmed for each of these tasks, which is a bit of a pain, but once the script is written, it can run forever, (mostly) flawlessly. Here is an image of a liquid handler you may find in a few labs, a $40,000-$100,000 machine colloquially referred to as a 'Hamilton'.

Why do this at all? Liquids are awfully important in biology. Consider a simple drug screening experiment: you have a library of 10,000 compounds, and you want to know which ones kill cancer cells. Each compound needs to be added to a well containing cells, at multiple concentrations, let's say eight concentrations per compound to generate a dose-response curve. That's 80,000 wells. Each well needs to receive exactly between 1 and 8 microliters of compound solution, then incubate for 48 hours, then receive 10 microliters of a viability reagent (something to measure if a cell is alive or dead), then incubate for another 4 hours, then get read by a plate reader. If you pipette 11 microliters into well number 47,832, your dose-response curve for that compound is wrong, and you might advance a false positive, or even worse, miss a drug candidate. Difficult! Hence why automation may be useful here.

Many other types of boxes exist. Autostainers for immunohistochemistry, which take tissue sections and run them through precisely timed washes and antibody incubations that would otherwise require a grad student to stand at a bench for six hours. Plate readers, often used within liquid handlers, measure absorbance or fluorescence or luminescence across hundreds of wells. And so on.

Boxes, which can contain boxes within themselves, represent a clean slice of a lab workflow, a cross-section of something that could be parameterized-that is, the explicit definition of the space of acceptable inputs, the steps, the tolerances, and the failure modes of a particular wet-lab task. Around this careful delineation, a box was constructed, and only this explicit parameterization may run within the box. And many companies create boxes! There are Hamiltons, created by a company called Hamilton, but there are boxes made by Beckman Coulter, Tecan, Agilent, Thermo Fisher, Opentrons, and likely many others; which is all to say, the box ecosystem is mature, consolidated, and deeply boring.

But for all the hours saved by boxes, there is a problem with them. And it is the unfortunate fact that they, ultimately, are closed off from the rest of the universe. A liquid handler does not know that an incubator exists, a plate reader has no concept of where the plates it reads come from. Each box is an island, a blind idiot, entirely unaware of its immediate surroundings.

This is all well and good, but much like how Baumol's cost disease dictates that the productivity of a symphony orchestra is bottlenecked by the parts that cannot be automated-you cannot play a Beethoven string quartet any faster than Beethoven intended, no matter how efficient your ticketing system becomes-similarly, the productivity of an 'automated lab' is bottlenecked by the parts that remain manual. A Hamilton can pipette at superhuman speed, but if a grad student still has to walk the plate from the Hamilton to the incubator, the lab's throughput is limited by how fast the grad student can walk. An actual experiment is not a single box, but a sequence of boxes, and someone or something must move material between them.

Now, you could add in extra parts to the box, infinitely expanding it to the size of a small building, but entering Rube-Goldberg-territory has some issues, in that you have created a new system whose failure modes are the combinatorial explosion of every individual box's failure modes.

A brilliant idea may occur to you: could we connect the boxes? This way, each box remains at least somewhat independent. How could the connection occur? Perhaps link them together with some kind of robotic intermediary-a mechanical grad student-that shuttles plates from one island to the next, opening doors and loading decks and doing all the mindless physical labor? And you know, if you really think about it, the whole grad student is not needed. Their torso and legs and head are all extraneous to the task at hand. Perhaps all we need are their arms, severed cleanly at the shoulder, mounted on a rail, and programmed to do the repetitive physical tasks that constitute the majority of logistical lab work. And with this, we have independently invented the 'arm' line of lab robotics research.

This has its own terminology: when you connect multiple boxes together with arm(s) and some scheduling software, the resulting system is often called a "workcell."

As it turns out, while only one field benefits from stuff like liquid handlers existing-the life-sciences-a great deal of other fields also have a need for arms. So, while the onus has been on our field to develop boxes, arms benefit from the combined R&D efforts of automotive manufacturing, warehouse logistics, semiconductor fabs, food processing, and any other industry where the task is "pick up thing, move thing, put down thing." This is good news! It means the underlying hardware-the motors, the joints, the control systems-is being refined at a scale and pace that the life sciences alone could never justify.

Let's consider one arm that is used fairly often in the lab automation space: the UR5, made by a company called Universal Robots. It has six degrees of freedom, a reach of about 850 millimeters, a payload capacity of five kilograms, and costs somewhere in the range of $25,000 to $35,000. Here is a picture of one:

Upon giving this arm the grippers necessary to hold a pipette, to pick up a plate, and to click buttons, as well as the ability to switch between them, your mind may go wild with imagination. What could such a machine do? Arms within boxes? Wheels to the platform that the robot is mounted upon, allowing it to work with multiple boxes at once? So much is possible! You could have it roll up to an incubator, open the door, retrieve a plate, wheel over to the liquid handler, load it, wait for the protocol to finish, unload it, wheel over to the plate reader, and so on, all night long, while you sleep and dream. This is the future, made manifest.

Well, maybe. If this were all true, why are there humans in a lab at all? Why haven't we outsourced everything to these cute robotic arms and a bunch of boxes?

Most lab protocols can be automated, they just often aren't worth automating

If you were to speak to LLMs about the subject of lab robotics, you will find that they are pretty pessimistic on the whole business, mostly because of how annoying the underlying machines are to use. I believed them! Especially because it does match up with what I've seen. For example, there is a somewhat funny phenomenon that has repeated across the labs of the heavily-funded biology startups I've visited: they have some immense liquid handler box lying around, I express amazement at how cool those things are, and my tour guide shrugs and says nobody really uses that thing.

But as was the case in an earlier essay I wrote about why pathologists are loathe to use digital pathology software, the truth is a bit complicated. First, I will explain, over the course of a very large paragraph, what it means to work with a liquid handler. You can skip it if you already understand it.

First, you must define your protocol. This involves specifying every single operation you want the machine to perform: aspirate 5 microliters from position A1, move to position B1, dispense, return for the next tip. If you are using Hamilton's Venus software, you pipette from seq_source to seq_destination, and you must do something akin to this for every container in your system.

Second, you must define your liquid classes. A liquid class is a set of parameters that tells the robot how to physically handle a particular liquid: the aspiration speed, the dispense speed, the delay after aspiration, the blow-out volume, the retract speed, and a dozen other settings that must be tuned to the specific rheological properties of whatever you're pipetting. Water is easy, glycerol is apparently really hard, and you will discover where your specific liquid lies on this spectrum as you go through the extremely trial-and-error testing process.

Third, and finally, you must deal with the actual physical setup. The deck layout must be defined precisely. Every plate, reservoir, and tip rack must be assigned to a specific position, and those positions must match reality. The dimensions of the wells, the height of the rim, the volume all must be accurately detailed in the software. If you're using plates from a different supplier than the one in the default library, you may need to create custom labware definitions. And at any point, the machine may still fail, because a pipette tip failed to be picked up, the liquid detection meter threw a false negative, something clogged, or whatever else.

To help you navigate this perilous journey, Hamilton, in their infinite grace, offers seminars to teach you how to use this machine, and it only costs between $3,500 and $5,000. And here's a Reddit post with some more details:

Now, yes, this is annoying, especially if you compare it with manual pipetting. There, a trained researcher picks up a pipette, aspirates the liquid, watches it enter the tip, adjusts instinctively if something seems off, dispenses into the destination well, and moves on. The whole operation takes perhaps fifteen seconds. Perhaps the researcher gets really bored with this and doesn't move particularly fast, but if you assemble enough of them together and call it gr