So, this is cool and it's nice to have an open standard with got traction from an active company.
When setting up lab automation, instrument communication is the biggest headache. There's lots of variability in how instruments communicate (serial, gpib, analog voltage, ftp/email from a contractor,...) and in how easily accessible their protocols are (published by manufacturer, closed, too old to know). Moreover, really old equipment is still in use and new equipment isn't likely to be 'designed for autoprotocol' for a while. How do you think managing instrument communication is going to work?
What are previous similar works like? I imagine stuff like this was made, way long ago, for doing combichem and hts... did it all remain in-house?
Support for extra parameters, like constant current vs constant voltage for gels, or that kind of thing? Or will this be in the name, like "op": "gel_separate_constant_I"
Support for timing, e.g. thaw out reagentB in time to mix it with reagentA which is being centrifuged, etc?
Reagents-- Any standardization for names/concentrations, or integration with inventory management?
Any planned integration with lab notebook/management software?
Any plans for 'preventing catastrophe' or 'forbidden operations' like centrifuging asymmetrically, or mixing stuff that precipitates+clogs (vs. intentional precipitation of, e.g., dna)? Not that we should need this, but increasing abstraction makes it easier to break stuff.
Looking forward to using this and contributing, etc.
> Moreover, really old equipment is still in use and new equipment isn't likely to be 'designed for autoprotocol' for a while. How do you think managing instrument communication is going to work?
This is obviously a big issue; it's what we spend most of our time on at Transcriptic. (That, and building new hardware when it makes sense.) Only a few devices are designed for being controlled by 3rd party software and even fewer are designed for real automation like motorized lids for sample loading. Internally we have a layer that handles all of the device communication, but we haven't open sourced that and it wouldn't make sense without the rest of our infrastructure anyway: not something easy to just pick up on part of.
This is kind of outside the scope of Autoprotocol. I think that in reality there will be three big uses of it right now:
- generating eg a PDF to take into the lab
- using it for more semantic information about the methods being used in conjunction with analysis of data you get from running stuff in lab
- running experiments on Transcriptic
In terms of automating communication and data capture in your own lab, I think Riffyn's doing the most interesting work here and it will be interesting to see what they come out with.
What is the overall process when using autoprotocol? I presume there are standardized robotic workstations with the capability to - 'do biology'. My experience of microbiology is limited to high school biology experiments 20 years ago -sequencing DNA and culturing bacteria on a petri dish. What is it exactly like to do biology in a modern research setting? (rough high-level description/example appreciated :) )
At Transcriptic we perform experiments using what we call a workcell - a set of devices like liquid handlers (automated pipettors), PCR machines, and plate readers all linked together via a common interface and a robotic arm that moves containers between devices. That interface understands Autoprotocol and executes the instructions accordingly. Autoprotocol itself was designed to be an agreed upon standard for different types of laboratory automation (not just ours) to execute protocols.
An example of an experiment someone could run through our cloud laboratory interface would be to monitor the growth rate of bacteria expressing different genes. This would be done using a protocol that contains some pipetting steps to dilute the bacteria and then alternates between incubating the plate at 37 degrees and reading OD600 of its wells using a plate reader at a specified interval for a certain number of repetitions.
I'm a molecular engineer working on a well-funded, stealth biotech project. We're building the world's first biological server farm. It's going to be a massive, fully automated research facility that manipulates, moves, mixes, and analyzes millions of batches of cells and molecules everyday.
It'll have the effective throughput capacity of taking everyone on earth, giving them a pipette, and having them do molecular biology by hand. But it'll be accessible from the comfort of a laptop. Biology will become a programming discipline.
We have an IMMEDIATE need for talented Python coders for short-term, on-site contract work. If the mission inspires you and you'd like to hear more, please email Kent Kemmish biokemmishtree at gmail.
Both the volume and duration are measures, which are strings of the format "value:unit".
FYI, ISO 31-0 [0] already defines a single space as the separator between the value and the unit. Granted, most people (and even some scientists) don't know about this rule.
This is neat, but you guys have failed on the basic human motivation. A python file isn't something I can take into the lab with me to reproduce an experiment. Does this spit out a useful human readable set of instruction?
Is there a sample output spec, compared with the norm of human readable input? As is, this seems like a solution for computers, not folks in the lab.
Does this spit out a useful human readable set of instruction?
At its core, Autoprotocol is just a way to agree on how to capture all of the information about an experimental method, which in itself turns out to be deceptively complex (though looks a little obvious afterwards when you see it). That description is just JSON: it can be generated by scripts, UIs, or written by hand (and we at Transcriptic + customers do all three) and it can be consumed by lots of different things. If you have a lab of your own, we'll release our to-english converter soon! You can also post the protocol JSON to Transcriptic to run it in our cloud lab environment, which produces a preview of the instructions that looks like this: http://imgur.com/EOBfZfW
If it's a subset of JSON... Is there a mechanism to add in comments for humans to read?
I know the main use-case may be inter-device, but someday you might want to embed a short hint or explanation along with a particularly arcane set of instructions or parameters.
Software-wise, there are a couple of unannounced things from our partners coming down the line that work with Autoprotocol, and several of our customers have been building on top of the autoprotocol-python[1] and autoprotocol-core[2] libraries. Hardware-wise, Autoprotocol is a description language, it could even be executed on a sufficiently meticulous "human" device. (We have a project in the works that transforms Autoprotocol into human-readable instructions suitable for inclusion in a publication.) Transcriptic is the only fully automated system today that accepts Autoprotocol, but we're working with other groups building low-cost hardware systems (in particular, OpenTrons) who want to build on top of the Autoprotocol standard.
When setting up lab automation, instrument communication is the biggest headache. There's lots of variability in how instruments communicate (serial, gpib, analog voltage, ftp/email from a contractor,...) and in how easily accessible their protocols are (published by manufacturer, closed, too old to know). Moreover, really old equipment is still in use and new equipment isn't likely to be 'designed for autoprotocol' for a while. How do you think managing instrument communication is going to work?
What are previous similar works like? I imagine stuff like this was made, way long ago, for doing combichem and hts... did it all remain in-house?
Support for extra parameters, like constant current vs constant voltage for gels, or that kind of thing? Or will this be in the name, like "op": "gel_separate_constant_I"
Support for timing, e.g. thaw out reagentB in time to mix it with reagentA which is being centrifuged, etc?
Reagents-- Any standardization for names/concentrations, or integration with inventory management?
Any planned integration with lab notebook/management software?
Any plans for 'preventing catastrophe' or 'forbidden operations' like centrifuging asymmetrically, or mixing stuff that precipitates+clogs (vs. intentional precipitation of, e.g., dna)? Not that we should need this, but increasing abstraction makes it easier to break stuff.
Looking forward to using this and contributing, etc.