Blog – EnginZyme

Blog

Open source liquid handling automation at EnginZyme

Liquid handling robots are the best friends of the wet lab scientist. A liquid handling robot plays a key role when you need to screen for thousands of process conditions and enzyme candidates — as we do at EnginZyme.

In our early automation efforts, we relied on OT-2s for liquid handling. These inexpensive little fellows were easy to install, but they would only do what they had been instructed. One had to program the robots to move around, aspirate or dispense liquids while ensuring that the program, or protocol, uploaded to the robot represented the exact intentions of the scientist.

EnginZyme facilities
Liquid handling robots — the best friend of any wet lab scientist


Programming robots…

Opentrons Labworks, the company behind the OT-2s, open-sourced both the hardware and software design so that any engineer can tinker under the hood and extend the robot’s functionalities. By reading the design blueprints and code repositories, we could integrate custom accessories in the robot’s deck and build software plugins that connect to other parts of our company’s IT ecosystem.

The OT-2’s robot computer is a Raspberry Pi running a Linux distribution, and the robot protocols are python scripts written using the opentrons python library. In the beginning, scientists that were not familiar or very comfortable with python coding had to ask for help to create their protocols. Over time, we identified many common parameters and actions that we could copy/paste across protocols. This was the beginning of our own systematic protocol designer: restricting the humongous possibilities of a python script to a set of instructions that included:

  • The definition of the robot’s pipettes and labware
  • A series of liquid handling actions with aspiration and dispense locations and volumes
  • A series of miscellaneous instructions, like repeating a step or sending a notification
image.png

Scientists would sketch the liquid handling instructions from which a python script had to be written

image.png
Generating a robot protocol from a set of instructions simplified the life of the automation engineers since they could very quickly iterate a design by modifying the instructions file. The next step was to take the engineer out of the loop and let the scientist design and shuffle the liquid handling steps at will.

…with a “no-code” Protocol Designer

Our scientists and software developers started planning how to generate the robot protocol’s python code without having to deal with the intricate syntax details of a programming language. The “no-code” solution was a web application where users could create an instructions file and then generate a protocol file that would be uploaded to the robots.
image.png
The solution was very well accepted, and scientists could finally design and iterate protocols on their own. The automation team could focus on working on the app design and add plenty of new functionalities, like integrating a shaker from a third-party vendor or simulating the protocol in the app.

The protocol designer web app facilitates user interaction with the robots but does not make the OT2s infallible. Errors still occur, and robots still crash. We wanted to minimise downtime from the automation team side, so we added silent logging messages on every protocol, uploading usage analytics and error messages to our cloud servers. We can then rapidly diagnose if there is a calibration error or if a protocol failed because an unintended instruction was sent.

Introducing the OPiDi: A multiuser protocol designer server

As the number of users of our Opentrons Protocol Designer (OPiDi – pronounced Oh-Pee-Dee) grew, the protocol files started to clutter the system. It was time to redesign our file management and have users log in to their own space to create as many protocols as they wanted in their own sandbox. Protocol files could then be flagged as verified and shared, with more restricted permissions to avoid accidental updates.

image.png
image.png   image.png
We are still maintaining and updating the OPiDi, from small changes like slack messaging actions (no more waiting in front of the robot for a step that demands user intervention!) to the integration of custom-built hardware modules. Since it originated from an open-source project, we decided to keep the open-source nature, and we have recently published the source code with documentation so that any OT2 owner can give it a try. You can find it on our GitLab page.

What’s next on the journey?

“All of that work for a cheap robot? Shouldn’t you have bought a better robot instead?”

When we began automating the lab, the resources didn’t allow for more than a couple of OT2s. As we’ve grown and secured much larger amounts of funding, we have acquired several high-performance robots with larger labware capacity and high-end pipettes.

But even today, the OT2s are still the chosen workhorses to test new experiments or quickly run repetitive general-purpose tasks. They are very convenient to cover on-demand tasks, and since the OPiDi is not robot specific, it can generate protocols for multiple robots.

The OPiDi is only one of the many automation projects currently in development here at EnginZyme. The end goal is a lab where scientists spend most of their time designing their experiments on a computer and little time processing samples. If that sounds like something you want to help make happen, check out our open positions or get in touch with me directly at nadim@enginzyme.com.

Posted by Dr Nadim Morhell, Director of Automation and Data Management at EnginZyme

Prev post

EnginZyme – making the chemical industry green

Next post

EnginZyme Insight: Machine learning for enhanced in silico enzyme design