The Simulator That Isn't There

Okay, this is one of those cases where I kvetch about other people not having built the tools I want to use - perhaps a bit of a insufferably egotistical position.  I mean, what gives me the chutzpah to do that?  My title, according to me, is "Automation Visioneer", so that gives me the right - though again, self-given title, self-given right.  But I hope you'll bear with me, because I think (there again, me! me! me!) it is an interesting observation on a curious gap in the software world - one that could make a very interesting project for someone so inclined. Oh, and this is one of the "a bit of promoting the product" entries - which means I get to blog on company time.

Our autonomous labs stitch together many laboratory instruments into a seamless whole - at least that is the goal.  And we've realized a lot of that, but there's always edge cases and new frontiers and so forth.  As you may have seen on social media (e.g. this LinkedIn post), I'm trying to learn how to write protocols for the autonomous lab - basically trying to prove "if even Keith can succeed here, it's gotta be amazing" as well as actually doing lab science. 

A core part of my protocol - which is absurdly too complex a procedure for a first project, but I'm that kind of fool - is to make a lot of things happen in quick succession on an Agilent Bravo liquid handler.  Bravo is a tried-and-true liquid handler - first launched in 2007 by Velocity11, which was acquired in 2009 by Agilent (that's what Gemini says).  There's many Bravo units out in the world - I'm pretty sure Codon Devices had a bunch of them.

Every time I've interacted with the liquid handling robot world in the past, I've come away surprised at how little standardization there is - how typically each robot has its own unique programming language.  It's also much more complicated than I ever imagined - briefly at Warp Drive Bio I was going to learn our Janus robot programming (then I crashed skiing, had knee surgery & was even more clumsy than before & even busier once I literally got back on my feet).  I mean, you must often program positions of tips at millimeter precision.  In an ideal world, there'd be a whole gradation of abstraction layers from "I just want stuff moved, spare me the details" to "I need to control the total physics of the operation".

PyLabRobot is the most prominent effort to try to build a common, open language for interacting with laboratory automation.  I haven't used it and can't comment on it, but certainly I love the idea that there are folks dedicated to advancing this.  Sadly, according to my good buddy Claude the only branch around Bravo is a dead item, never merged in and very stale.  

But that's not my unreasonable ask.  What came up is one of the most unyielding laws of physics - two objects can't occupy the same space at the same time.  So if I try to program the Bravo (particularly relevant for vibe-coding the Bravo), how do I make sure I don't try to sweep the pipette tips on the head through an adjacent plate?  Surely for such a venerable robot, there must be a robust, mature simulator to check one's robot code against the hard laws of physics without actually risking sending plastic flying or worse damaging a physical robot? Wouldn't that be useful to a huge community of users of this widely used lab robot?

And according to Claude, nope!  No such simulation harness exists.  Obviously this isn't a trivial ask at all - one must convert all possible Bravo instructions into their corresponding physical actions and understand the physical envelope of all possible labware - or at least have a way to import all that.  And the Bravo deck might be tricked out with other gadgets - we only put BioShake and magnetic bead stations on them, but these days you can trick out decks with all sorts of other devices.  Which will all have their own physical envelope and perhaps other rules.

Ideally any such simulator would itself be modular, so that it could be adapted to simulate all the other liquid handlers on the market - the underlying language would be different and each liquid handler will have its own physical quirks, but presumably the underlying physics model, as well as the labware dimensions, would all be portable across instruments.

Developing such a simulator (or perhaps I should call this a digital twin, to be trendier) would require both computing skills - I'm a skeptic about someone naive in real automation work being able to vibe code this - and access to an actual Agilent Bravo to test things.  Ideally a Bravo that nobody will get upset about if the simulator screws up and tries to pass plastic through plastic.

I suppose the major reason for my sense of culture shock is I'm used to the genomics world where there are usually a plethora of solutions for any long-standing problem.  Typically the challenge is to prioritize software options, triage that for issues such as needing a commercial license, and then keep trying to install packages until at least one works.  Some problems have bonkers numbers of solutions - I looking at you short-read merging authors!  Now there are obviously problems that are new and don't have solutions - I've tried to dive into some of those.  But I'd find it very strange in genomics space to run into something that appears to be an old problem yet has few solutions.  Yet that's where we are here - lab automation is a very different world in this regard.