Wanted: special-purpose robots automating life science wet lab workflows.

Compared with manufacturing and service industries, the life science R&D industry in general is lagging behind in terms of utilizing large-scale industrial automation for productivity, capacity and quality improvements. Granted, the exploratory and dynamic nature of life science R&D dictates that for most life science R&D projects that come and go, there is not a fixed procedure to begin with, and there is no way to predict how a project is going to end up either. This uncertainty makes automation of general life science R&D workflows difficult. Still, life scientists around the world are working hard to isolate, extract and automate the portions of the workflow that can be automated [1]. Over the past decades, much progress has been made in the automation of analytical separation and detection, data acquisitions and downstream data extraction and processing. Relatively speaking, the progress of automating life science wet lab workflows has been much slower, due largely to the lackluster tools available.

The downsides of general-purpose liquid handling robots

Since a common denominator of life science R&D wet lab workflow is liquid, current robot manufacturers all aim to maximize the applicability of their products to assorted life science workflows (translation: maximizing profits) and offer general-purpose liquid handling robots (GPLHR). This makes their internal robotic products R&D relatively simple, but while the goal of GPLHRs is to suit all applications, they in fact please no one. For ordinary end-user groups, those robots are just too much of a hassle – difficult to use, crash often and the results vary [2-4]. Since there are no commercially available liquid-handling robots that tailor to their specific workflows, much postacquisition customization and development needs to be done either by internal staff, vendor staff or both, if they wish to automate more than just a few isolated steps of their experiments. Customization, development and maintenance costs aside, the process is slow, there is often no guarantee of the quality of such custom work and quality and success varies from one organization to another. For those end users’ management, it is often a struggle to see through the clouds of the capital expenditure, dedicated automation FTE investment [2], slow customization and slow adoption among ordinary scientists to find out whether the robots are worth the investment [3,4]. For the robot manufacturers, because the barrier of entry for GPLHRs is relatively low, competition is fierce. Due to slow adoption of these robots, the robot manufacturers are not fully realizing the huge life science market potential. Also, they might become the failure of their own success if the repair/maintenance service, technical support and most notoriously and unpredictably, custom development demand cannot keep up with their sales.

In short, there is much to be desired from a contemporary GPLHR. To give a few specific examples:

Tip management. Disposable tips eliminate the sample contamination issue and are more advantageous than syringes. Contemporary GPLHRs have internal tip counting libraries to help keep track of tip usage. While the idea is great, it is not doing a good enough job. The end users do not need to know where the next available tip is located, and they should not be expected to interfere with tip management. Their only responsibility for tips should be to ensure there are enough assorted tips for their experiments. Everything else should be handled automatically by the robot. A much improved tip feeding mechanism would be vertical barcoded stacks of assorted tip types on a carousal under the deck, and a 2D laser mesh tip sensing grid sitting underneath the deck surface at the microtiter plate opening to determine in real time the remaining tip count and the last tip location for the tip rack. On the deck, there should be only one tip rack opening for all tip-related operations. This would save much deck space for experimental purposes.

Upstream and downstream workflow hardware integration. Liquid transfers are important parts of web lab workflows, but they are intimately intertwined with other liquid-related operations such as solution preparation, capping/sealing containers, vortexing, centrifugation, decapping/desealing containers, nitrogen drying, plate reading, among others. Big pharmaceutical companies are integrating these devices with GPLHRs postmarket to make the system fully walk-away. Not every company can afford that kind of internal development. Why do the robot manufacturers not do this at the factory?

Workflow-specific software. Postmarket customization and development in the form of extensive scripting by user/vendor staff to suit particular workflows actually in a sense indicate that GPLHRs are half-finished products. Customization and development work needs to be done at the manufacturer to begin with and scripting is not good enough. Again, users do not need to know and should not be expected to know the inner-workings of the automation equipment. The scripting layer should be eliminated altogether. Workflow-specific user interface and business logic, including straightforward enterprise IT data integration configuration options, should all be done at the factory.

Intelligence. Common causes for GPLHR system halts and irrecoverable crashes include fatal tip/insufficient liquid errors, which can all be eliminated with additional intelligence built into the system. To continue with the tips example above, the tip-sensing 2D laser grid would report the status (number of tips and last tip position) of the partial tip rack in real time on demand. The system would combine that information with the number of same type full tip racks (read from the barcodes) available in the carousal, and keep a record of how many of that type of tips are available. If the system also knows/computes at the beginning of a run how many of this type of tips would be needed for the experiment, then the system could alert the user to add more tips if it foresees shortage. A common sense for every lab scientist is that one cannot get more liquid out of a container than what was put in there prior. And yet, current GPLHRs do not have that simple intelligence. Conceivably, the robot could keep an exhaustive internal database of container ID, well positions, volumes of liquids, implement some sort of aliquot safety mechanism [MARS] and if the entire experimental procedure is known at the beginning of a run, computes liquid transfer scheme and warn users of potential insufficient liquid errors before the experiment even starts.

The above wish list is by no means comprehensive and could go on.

Integrated specialized robots automating life science workflows

In summary, what life science R&D scientists really want are turn-key intelligent automation solutions that automate most, if not all, of their wet lab workflows without too much tinkering on their part [3,5-6]. Addressing the above list of issues/wishes would be a good start toward that direction.

In recent years, there have been relevant advances in that direction both in terms of hardware and software. Hardware wise, most recently a European automation lab is trying to tie assorted stand-alone analytical chemistry instruments/apparatuses together on a common hardware platform to achieve fully automated analytical chemistry workflows. Earlier this year, a UK/US-based company just introduced to the market their ingenious robot that automates aqueous solution preparation starting from solids weighing. Software wise, there have been several publications on attempts to automate majority portions of relatively well-defined bioanalytical wet lab workflows [7-11]. It is important to note that the concepts are entirely applicable to many other life sciences R&D wet lab workflows [6,12].

What we need are ultimate vertical integrators who would take on the tasks of consolidating assorted hardware and software products and advancements into integrated specialized robots that would automate large vertical sections of life science wet lab workflows. The tasks are not as impossible as they may seem. For each specific wet lab workflow, the lab hardware needed is usually limited. Therefore, such integration could start with a few workflows and then expand into/integrate more workflows. Along the way, a stream of robotic products with increasing complexity and expanding functionalities could be introduced to the market.

Conclusion

Life science R&D labs need more automation and scientists want automation to work for them, not the other way around. Ideal life science R&D wet lab robots should automate entire workflows, as opposed to mere liquid transfer steps. To achieve that, vertical integration of workflow-specific hardware and development of workflow-specific software are needed. There is no question that it would be challenging product R&D for robot manufacturers, but the effort would definitely be worth it. The fact that life science R&D industry have invested heavily in and have so far put up with half-finished products (i.e., current crop of GPLHRs) shows the dire need for automation. The underlying marketing message to robot companies is clear: if robot companies can come up with a better product, the life science R&D industry would embrace it and pay for it. The market potential for such robots would be tremendous. The race to special-purpose robots that would reshape the life science R&D wet labs is on.