Liquid Handler Auto-Detection of Real Tip Presence

dev discussion
1

Hi everyone,

I’m tired of manual tip restacking.
(e.g. after automation runs use up partial tip_racks or tips have fallen off tip_racks)

The standard to solve this issue is to use a camera and some computer vision (CV) to detect the presence of tips in tip_racks, and then execute a tip_sorter.
This is nice, and pretty fast, there even is a commercial offering for such a CV system.

But I want to enable people who don’t have the time, money and/or skillsets to set up a CV system… or maybe just have bad lighting on their liquid handler :man_shrugging:

So here is my alternative: I’ve built LiquidHandler.probe_tip_presence_via_pickup()

It uses the LiquidHandler.pick_up_tips() command to try a tip pick up:

  • if it succeeds → tip is present
  • if it fails → tip is not present

i.e. any liquid handler that has the ability to detect whether it has picked up a tip correctly can instantly be used for real-time tip presence probing.
No CV needed.

In code:

Notes

  • From the PLR-integrated LiquidHandlers only the Opentrons OT-2 does not have the ability to detect whether it has correctly picked up a tip, i.e. this LiquidHandler method will not work for the OT-2.
  • It is slow compared to a computer vision based system. A CV system can, in optimal setup, detect in max tens of seconds all tips on a liquid handler deck (if its a big liquid handler, the camera has to move, costing some time).
    In comparison, on a STAR(let) probing an entire tip_rack takes between 80-240 sec - depending on how many tips are still present, i.e. if entire columns don’t have tips anymore it will cost less time because the tip_drop is skipped.
    I’m still working on optimising the probing speed.
  • This is step #1 in a series of error handling integrations into PLR that I started; some of the next steps:
    • recursive updates of TipTrackers across a liquid handler,
    • automated tip inventory consolidation, and then
    • moving on to recovery handlers for
      • aspirate/dispense and
      • pick_up_tip :slight_smile:

Community Question

Where do you think should this function go in the PLR ecosystem?

The obvious choice would be to make it a LiquidHandler method directly.
We can then add a conditional statement that if backend==OT2Backend it raises an error that the OT-2 doesn’t support tip presence probing.

But I am unaware of how this function will behave exactly on Tecan machines (I am deep in the Hamilton universe).
But PLR is a machine-agnostic (+ unique machine-power enabling) automation software system.
So I would like to ask people with Tecan experience what they think about this functionality & how Tecan machines can/cannot detect correct tip pickups before moving forward? (@VilhelmKM)

1 Like
2

Love the idea of this feature! Added benefit is it saves tips/plastic since many people are suspicious of partial tip racks and will often opt to use a new tip rack instead. And another use case is that I have seen PLR have issues knowing if tips are picked up/present when I have used off-brand or generic tips instead of the Hamilton ones.

Can you give me an example for how I would use this function to reorder tips or consolidate between tip racks?

Similarly, does this set the stage for a function similar to a “if no tip, try again with next available tip” feature? I have not seen this VENUS function translated into PLR yet (may already be out there, just haven’t used it myself).

2 Likes
3

@harley, thank you, this is a very good point!

This is very interesting; I am actually chasing down an elusive bug in PLR’s TipTracker at the moment.
If you find some time, could you please create a new forum thread in which you are describing your experience in more detail?

Not yet :slight_smile:
I am working on it right now. How would you like to implement it?

There is quite a lot actually that can go wrong, so I’m building this up step by step with this fairly atomic LiquidHandler.probe_tip_presence_via_pickup() being the first step.

Here is the evolving outline for it:

image
image1046×890 113 KB

Note:

  • The tip inventory consolidator will take information from the liquid handler’s tip tracker, i.e. it will not require a tip inventory check/update to be performed before it.
    The tip inventory check/update exists to update the believed tip tracking state, if one wants to do so (e.g. at the beginning of a new run there might be old tips that haven’t been re-racked/consolidated but the new automated protocol/script doesn’t know that).

Ohh, I didn’t know VENUS has such a feature.

The answer is yes, this is exactly what this sets up :slight_smile:

This adaptive tip pickup is actually relatively simple compared to the other error handling operations we are building at the moment (specifically adaptive error recovery from aspirate/dispense failures).
I can share the code next week. It is functional - we just haven’t yet found a nice way to integrate it with the agnostic nature of PLR, a general obstacle with these complex/high utility commands.
But also really fun problems to solve :slight_smile:

1 Like
4

Our laboratory utilizes third-party Tecan tips that have been thoroughly validated and confirmed to support automatic tip presence detection without compatibility issues.

5

@khani, that is fantastic - it is always good to secure your supply chain with some extra tip sources :slight_smile:

May I ask: Are you using an EVO system and could check whether the new tip presence probing feature works out of the box on your machine?

Here is the PR I submitted yesterday for it: