Robotic-Microfluidic Interfaces

Combining liquid handling robotics with microfluidic devices seems like it would enable a lot of very useful experiments. Liquid handling robots allow for a lot of flexibility, throughput, and experimental conditions, while microfluidic devices enable precision and miniaturization.

A few papers have shown such interfaces where a rubber seal is used to allow the liquid handler pipette tips to apply pressure to a microfluidic channel. Makes sense but seems like it might be failure-prone.

This paper uses a combination of syringe pumps and rotary valves to move liquid between the liquid handler deck and microfluidic devices. The liquid handler aspirates and dispenses from open containers on the deck without the need for a closed seal. Seems a lot safer, but their documentation as to the exact design is somewhat sparse.

Any thoughts?@ben

2 Likes

I haven’t read any of the papers detailing the tip with rubber seal method, but I worked with droplet generation microfluidics quite a bit and that sounds like a nightmare to get working properly. The method outlined in the paper you attached is a much more reliable method in my experience. Syringe pumps work pretty well for the pressure delivery and an injector valve allows for the use of really whatever input vessel you want. One problem in my experience with microfluidics systems is mixing, since the reynolds number in the chip itself is so darn low, so everything has to be mixed before hand (or you use very silly chip based mixing methods). That makes experiments a massive pain if you have tons of conditions to test in the DOE. So the integration of a liquid handler, where you could do automated preparation of the inputs and whatever else have you would be incredibly nice. The paper does droplet analysis after the fact, but one neat thing you could also do if its a ddPCR machine is thermal cycle the droplets in microfluidic tubes as they flow after the droplet generator, then you can just image the droplets downstream one at a time. Allows for easy separation of experiments as a single block of signal is associated with a particular experimental condition. And it’s fully automated!

1 Like

That’s very interesting, for mixing I’ve seen papers with good results from using ridges in the fluidic channels. Do you think there are any drawbacks with this approach?

Are you thinking of something like this?

Main disadvantages in my mind are adding more things in the microfluidic path, which is always risky when dealing with droplet generation since the chips are very finicky whenever you change anything. Also it limits you to whatever inputs/outputs are built into the chip, which isn’t terrible if you’re doing similar experiments over and over again, but if you are maybe doing multiplexed vs singleplex reactions or something else that changes reagents a lot it becomes a bit of a pain.

All of that being said they do mix well, and so if you want to miniaturize mixing they are fantastic. Funnily enough I did that in a past life for field deployable instrumentation, and for doing a similar ddPCR reaction over and over again over the course of a day or more it works well. But in my mind if you’re integrating a liquid handler miniaturization is probably not top of mind.

2 Likes

the main question will be how reliable the setup is. with enough dust mitigation, one could use a robotic-microfluidic interface to continuously generate barcoded droplets for time-series scRNAseq

we’ve set up this same workflow manually, spending most of our time working out high efficiency single cell library preps

if anyone wants to build a setup like this, reach to me! we are interested in ambitious projects in automation

1 Like

In the chemistry world, we often use autosamplers + sample loops, similar to what you see in an HPLC system. The autosampler aspirates the necessary components from vials on deck and then mixes the components to make a homogenous droplet. This droplet can then be injected into a microfluidic reactor via the sample loop. Klavs Jensen’s group at MIT pioneered this idea, but we’ve also used it in Cambridge.

From the SI of 10.1021/acs.oprd.8b00018

The disadvantage of this approach vs the one in the paper is throughput.