Hello everyone!
Have you also wondered about why the selection of tips that are actually available on a tip rack is so demanding, both for developers as well as users? Especially, if different methods with different tip types are used on a system resulting in a high rack exchange rate and potentially inhomogenious tip counters?
I am wondering, if anyone came up with the idea of placing a camera within the robotic platform. It should be possible to run a software which identifies filled and empty tip positions and provides that information to the software used by the liquid handling system. Of course, the camera software would not identify the tip type, but that can still be done by the barcode of the tip rack.
i’ve used Lab Eye by Robiotec,
multi-camera implementation
PTZ options
huge ability to verify labware locations, color recognition, tip counting, tip nest counting
even counting tips mounted on a pipetting head if you have issues with reliability at those steps
designed to be used with any automation solution - simply creates result/state files of each verification performed so you can build your own logic to decide if the system pauses, prompts or carries on
The Beckman’s have their own camera setup and new Tecan Fluent’s will come with the ability to run DeckCheck. With that said, LabEye allows you to remain platform agnostic and gives you greater ability than the embedded system provided options.
We, Genie Life Sciences, put an embedded camera right on the pipetting head. Tip counting / verification is one of the use cases we’re attempting to solve, though, in full disclosure, it’s at the very top of the list.
+1 for LabEye. Awesome easy to learn tool that has a ton of depth to it. Really simple API that can be called with shell commands at any point in the script. We use it with a really cheap Amcrest WiFi webcam that can be accessed anywhere from its IP address. The tricky bit comes down to finding a good angle to set the camera up where you can get a good vantage point on the deck without getting in the way of the arms. This is particularly tough with Hamilton STARs and Vantages: not a lot of space inside the enclosure to mount a camera without it potentially getting hit by the gantry. Curious if anyone else has found a solution using a camera on a STAR, we’re thinking of just drilling a hole in the sidewall and mounting the camera there
There is a custom VENUS Video Recorder library that is compatible with a variety of different cameras. See this link for a quick guide that includes a link to the library along with setup instructions.
We’ve done some custom camera setups - I’ll try to gather more information about camera types used and location. At our Franklin office, we have a camera set up on the gantry of the training STAR and VANTAGE to show the deck making it ideal for training and demo purposes. Zip ties and proper cable routing were critical!
For the offices, the camera we ended up using was an Akaso Brave 4. It is low cost, has vibration reduction (good for countering gantry movements), and has an adjustable FoV, which could help with getting the depth of the deck in one image.
For the cable routing, the solution was to just take the lower mounting screws off the back panel and use spacers to leave a ¾” gap by the X-rail for the camera cord to drop down. So the additional items besides the camera included:
64gb Memory card
USB extension cables, 3M
Cable ties
I am sure there are plenty of alternative approaches. We haven’t tested the VENUS library with this setup yet, but we will soon and I can report back.
Oh wouw, thank you a lot for your interesting insights. Indeed, I havent heard of LabEye before, but it looks like the solution I was looking for. The limited space in a Hamilton Starlet might be a challenge though because the LabEye camera looks quite big.
Will keep you updated.
How does communication occur? Yes, you can start .exe processes but it would need some sort of hsl library to send the information back to the method, no?
I’ve used this before by binding the return value of the LabEye.exe client to a variable in Venus for boolean plate detection (i.e. is the plate where it should be or not). For more involved things, the software can write positions to a .csv, which you can then read in Venus and execute commands accordingly.
