I am curious how/if people are doing regular performance validation of their automated lab equipment.
For example, for your liquid handling:
Do you validate that it’s dispensing volumes accurately regularly?
Is that validation different than you would do it for the non-automated version (weighing vs. something else)?
Is the validation itself automated or manual?
I’d like to hear how you do this for any equipment that needs it (characterization techniques, material handling etc.). Or if anyone has any workflows that eliminate the need for it!
Thanks for taking the time to detail this question!
While for a simple example, I have a unit test that runs regularly on GitHub actions that verifies proper communication with a device. This could be set with some validation and checking of expected ranges of the sensor data, which if logged to a database could be an indication of degrading or changing results over longer periods of time. Naturally, one could simply subscribe to notifications for when a GitHub action fails (as is the case for me) or a more specialized notification setup could be introduced.
More specific to liquid handling, there has been some discussion of machining a hole in the baseplate of an OT-2, raising the OT-2, and putting a scale underneath. A similar auto scheduled maintenance routine could be used to dispense into a container for calibration and warning checks. You could probably have a “fake tip” container that you can move to and from the scale — the Opentrons pipettes have often been used for “tool changing” or sample transfer by picking the thing up as if it were a normal pipette tip with the appropriate (usually 3D printed) adapter. Likewise, we have a small hack for moving wellplates around in an OT-2 by sacrificing one of the wells with a small insert (see video).
Hopefully others can comment on this from real-world workflows and experiences.
I like these methods, I think that running checks periodically and notifications if they’re off is cool.
Incorporating a balance beneath the baseplate is interesting - I had been thinking about a small footprint scale to go on the baseplate, like a small kitchen scale. I’m working with a Jubilee system, so using 1/6 slots is a somewhat bigger sacrifice.
I like using the pipette head as a manipulation tool - maybe the labware-to-pipette connector should become a standard automation “dongle”!
I’ve also thought about processing on an image of a pipette tip (or syringe etc.) with some amount of liquid to extract a liquid height value, then gravimetrically (manually) determining the volume in the tip. After fitting enough height/volume data, an image taken can be used for validation by using that fit to calculate the volume.
Using automated tests sounds like a fantastic approach for systems validation, but I’m not sure I fully understand how you’ve set it up.
How do you combine a Github action and your lab equipment? Are you somehow exposing an interface to the outside world and let Github’s servers access it? If that’s the case, how do you handle access control and security?
In our case, we have a local instance of Grafana where we log all the parameters of our instruments. This allows us to perform (for the time being non-automated) control experiments to evaluate the systems’ performance and use historical benchmarks.
How do you combine a Github action and your lab equipment? Are you somehow exposing an interface to the outside world and let Github’s servers access it? If that’s the case, how do you handle access control and security?
Via a cloud-based MQTT broker (HiveMQ), with “proper” encryption and authentication to keep it private and secure. MQTT credentials live as secrets on GitHub and are stored on the equipment. MQTT allows for granularity in terms of which users are allowed to communicate on which topics, which also helps (providing the minimum necessary access). If you have more specifics, happy to point to some additional resources. A while back I spent ~6 months learning IoT best practices, trying to consolidate and implement what was relevant to self-driving labs and lab automation. A number of those discussions are below:
Thanks a lot!
I didn’t know HiveMQ, I’ll take a look to their offering. I guess for this type of work, the number of messages and badwidth required is so low that it can easily be handled with the free-tier. I used MQTT for home applications, but never thought about getting it into “lab-grade”, I will keep brainstorming about this.
I also just found out you can use gRPC over an MQTT connection. I’m looking at gRPC for low-latency execution within the same LAN. If I can add an approach similar to yours for remote execution it would be an interesting bonus.
