A few days ago I ran into a bug that prevented me from running PyLabRobot (PLR) protocols on the Opentrons robot. The issue was ultimately resolved by updating PLR and opentrons-python-api – a python wrapper around the Opentrons HTTP API used by PLR. But it took long enough for me to figure this out that I looked into using the Opentrons python API.
There are two main reasons I see for using the Opentrons python API over PLR for my LLM automation assistant project:
- Opentrons hardware is always going to be supported by the
opentronspython package, whereas integrating it into PLR will require writing code to integrate the labware and the HTTP commands used to control various modules. This is some of what I’ve been working on in the last few days. - There’s a larger corpus of Opentrons protocols and documentation than PLR at this stage, which will make it easier to scaffold the LLM assistant.
My main complaint while exploring the Opentrons library (rather briefly I might add) is that the “out of the box” way to run experiments on Opentrons is to write a python file containing the entire protocol where you stick the commands you want to send to a robot in a run function, and then upload that python file to the Opentons app on your computer. Once you’ve uploaded the protocol, Rick tells me it gets sent to an onboard Rasberry Pie which converts your python into actual firmware level commands.
In this way, your protocol gets executed in a sort of linear, inflexible way. You have the option to pause the protcol and start over, but tweaking things means making an edit in your run function and then uploading the revised protocol to the Opentrons app where you then begin again. This is useful for sharing highly systemized protocols with other Opentrons users, where everything is controlled and the deck layout and hardware is largely the same was designated in the original protocol. But as I pointed out in my last post, protocol development feels like a very iterative process where you want to be able to execute single commands, let things fail, and build your protocol one part after another.
My main reason for preferring PyLabRobot was that this iterative development is baked into the whole library. You can use Jupyter Notebooks to write individual commands or code blocks and execute them one at a time on the Opentrons robot or any of the other platforms supported by PLR for that matter.
As it turns out, Opentrons also let you access some version of this feature by serving a Jupyter Notebook which you can connect to with you web browser. You can read their docs here. Essentially, you can call opentrons.execute around commands. I still need to verify this in lab.
Anyways, if it turns out this works well with the Opentrons platform, there may be a better argument to switching my focus from PLR implementation to Opentrons. Of course, there are other benefits of PLR to consider, the main one being that whatever system I build to write/develop protocols will work much better on other robot platforms, like Hamiltons and Tecans.