Records Archive

I am excited to announce that Tetsuwan has integrated with PyLabRobot (PLR) & UniteLabs’ SDK to bring easily programmable automation to a variety of new platforms, including Hamilton’s STARlet platform. You can watch a demo of Leon generating a protocol for the STARlet below with ResearchOS + PLR!

It has not always been this straightforward to integrate lab automation hardware. The space has long been plagued by poorly documented or entirely absent drivers, platforms that get acquired and deprioritized, and vendor ecosystems that have little incentive to play nicely with one another. In an attempt to escape these walled gardens, many automation engineers have resorted to reverse engineering drivers entirely with tools like Wireshark. In 2009, the SiLA Consortium introduced the Standard in Lab Automation (SiLA 1) to establish a common driver framework with limited success. SiLA 2 followed in 2019 and has seen growing adoption.

About PyLabRobot

Community projects like PyLabRobot, driven by dedicated developers like Rick Wierenga and Camillo Moschner, have also helped greatly to democratize hardware control outside of vendor ecosystems. There are many hackathons, projects, and automation teams that would not be the same without PLR. It’s also easy to write your own drivers compatible with PLR’s API and contribute to the project- check out the contributor guide to learn more. ResearchOS can now use PLR to control the hardware supported by the ecosystem!

About UniteLabs

Funny enough, the product we are using from UniteLabs that enables this has a very similar name to our ResearchOS- AutomationOS (not to be confused with LabOS or ScientificOS). With such uncreative product names, it can get confusing to tell what is going on. So, what’s the difference between ResearchOS and AutomationOS, and what does it look like when we combine them? Simply put, the former helps researchers communicate experiments to an automated platform, and the latter makes sure that all the pieces of that automated platform are speaking the same language (it *unites* the fragmented hardware layer via a single API). UniteLabs will allow us to expand ResearchOS to a huge variety of hardware platforms, without us at Tetsuwan having to do the heavy lifting of writing a slew of drivers and building lab-specific Python SDKs. We are also able to use this SDK to feed back data and execution context to ResearchOS in real-time (with no black boxes!) to make decisions on troubleshooting, evaluating results, and to close the experimental validation loop.

There are two things in particular that make the UniteLabs SDK exciting to us:

• The transparency of the pricing model. The ability to purchase drivers is not a new thing. People can buy scheduling softwares like ThermoFisher Momentum, HighRes Cellario, Biosero’s GreenButton GO, or PAA Overlord, but drivers are locked behind the recurring purchase of the scheduling suite itself. UniteLabs turns this into an “integration flatrate” with a credit based system that scales with the complexity and number of instruments connected to the platform, a model that is both more transparent and flexible.
• The breadth of the SDK. For decades, platforms like Hamilton remained very closed off. UniteLabs has been working with Hamilton for the last two years to make their platforms reliably accessible through UniteLabs. There has never been such a comprehensive driver library (167 drivers, 5 liquid handling platforms) available that can be accessed without needing the overhead of a full scheduling software.

Community

The lab automation community is a deeply inventive and collaborative one. People share code and hard-won knowledge on labautomation.io, Twitter, and at local meet-ups. Boston and SF both have a Lab Automators & LRIG chapter, NYC has its own LRIG chapter, and Munich’s Lab Automator community has grown from <30 to 300 in a single year- shout out to Bernd Martensen! Our small corner of the industry has seen a significant influx of attention, talent, and capital over the past year as excitement around the autonomous science movement has grown, and there are no signs of that slowing in any way. We look forward to seeing how the rest of the tooling ecosystem, driver integrations included, evolves to meet the moment.