This blog discusses the following workshop paper:

"A Self-driving Laboratory Optimizes A Scalable Process For Making Functional Coatings"

Link to workshop paper

The 'self-driving laboratory' (SDL), the holy grail of material science, is a dream of many labs, but is out of reach for most. Completely automating the process of experimentation sounds like a no-brainer, but there are several challenges to overcome:

1. What strategy should we use to search the space of all possible materials?

2. How much will the whole robotic system cost? What about maintenance?

3. How do we assess that it is working well?

Connor and his co-authors embarked on a year-long journey to implement an SDL, to find the optimal functional coating. Here is his problem space:

Problem statement: 

"Large-scale coating methods are essential for manufacturing clean energy technologies such as photovoltaics , electrochromics and electrolyzers. Methods for depositing coatings at scale include vacuum-based methods (e.g. sputtering, thermal evaporation) and solution-based methods (e.g. blade coating, inkjet printing, spray-coating). Solution-based coating methods that avoid vacuum and high temperatures offer an opportunity to lower the cost and energy intensity of manufacturing clean energy technologies."

Unfortunately, finding the optimal solution-based coating is a high-dimensional problem. He has to choose the right temperature, the right airflow, the correct nozzle height and many more parameters. We cannot efficiently plot that many dimensions, so the best we can do is Bayesian Optimisation. Ideally, fully automated.

Connor did manage to build an SDL, but: It took almost a year to build, but only 3 days of running to find the optimal coating conditions. The one year of SDL building also includes longer stretches of time where one part of hardware or software did not work properly and development could not continue without that piece working. That is probably also the reason why this paper has so many co-authors, as there were many disciplines involved and many experts needed to solve the huge variety of problems from software to hardware to chemistry and beyond.

Connor has made all the data from the run available online here, which is a great step for OpenScience as it allows anyone without access to an SDL setup to still assess and get first-hand experience from real SDL data logs.

Open Challenges

Some problems still persist with his current setup, such as batch processing or fast recovery from failure (there are lots of moving parts, so lots of things can fail!). The SDL space continues to develop, but we are still far away from any standardisation of processes and software. With Matterhorn Studio, we hope to streamline one part of the value chain, namely the modelling building and execution and make that accessible and easy to use for any labs out there wanting to make a first step towards their own SDL.