bug: When targeting a location somewhere above the top of a well, pipette first moves to exact top of the well, then moves vertically up

[Dardin-dale]

Overview

Working with a non-standard pipette tip length. I can calibrate to the new length just fine. However, if I also want to use standard pipettes in the same python protocol it is not currently possible. If I calibrate with a standard tip I can set the height via the location definition. However, when aspirating it first moves to the set calibration height before moving to the specified height above the well. This would smash the non-standard pipette tip into the deck.

Implementation details

I would propose that the robot calculates where to move and aspirate from it's current position instead of the calibration point if given a specific location or that if a move_to() call is used prior to an aspirate() that the robot determines it's path based on it's current position instead of from the calibration position.

Design

Ideally, I would like to calibrate and use a standard pipette tip along side a custom tip length. So calibrating with a standard tip length but specifying a custom aspirate height without smashing the custom tip would be helpful for some procedures. Ideally some custom setter to tell the robot when the tip is attached would be an added benefit. I'm currently just telling the OT-2 to pick up a tip from an empty location and then pausing to add the custom pipette.

Acceptance criteria

Pipetting from a set location above the well does not dip to calibration point before aspirating. Or other suitable workaround.

[SyntaxColoring]

Thanks for opening this issue!

However, if I also want to use standard pipettes in the same python protocol it is not currently possible.

So, for example, if your protocol uses a P300, you want that P300 to use Opentrons 300 µL tips in some parts of the protocol, and tips from another company in other parts of the protocol?

If I calibrate with a standard tip I can set the height via the location definition. However, when aspirating it first moves to the set calibration height before moving to the specified height above the well. This would smash the non-standard pipette tip into the deck.

Sorry, I don't think I understand.

Could you clarify what do you mean by "set the height via the location definition"?

[Dardin-dale]

Yes, Right now I'm trying to use just a single P1000 (Gen 2). I'm using an in-house made pipette tip. Ideally we would want to swap tips between a custom tip and an opentrons tip with the p1000 mid protocol.

The custom tip is much longer than the standard pipette tip (7.5cm). I can specify the aspirate via a location class instance say p1000.aspirtate(1000, plate['A1'].top(75)) for example. It does go to that location to aspirate. However, the robot first jogs to the top of the well height as calibrated before moving to the specified height which would smash the tip into the deck (I fortunately tested this before trying it). This makes sense if the height specified is below the top of the well but If I specify a height above the labware definition I would expect it to go to that location and not the top of the well as calibrated first.

Additionally, If I dispense in the same fashion i.e.p1000.dispense(plate['A2'].top(75)) it moves to the correct height immediately without first moving to the top of the well and dispenses.

[Dardin-dale]

I guess I could just calibrate with the custom tip and then specify negative values for the opentrons tip but I am unaware of any warnings or Errors if I go below where it thinks the deck is in relation to the Labware.

[nickcrider]

Hi @Dardin-dale ! Quick question, are you using a custom tiprack definition for your custom tip? The ultimate source of the tip length in the geometry system comes from these two values:

opentrons/shared-data/labware/definitions/2/opentrons_96_tiprack_1000ul/1.json

Lines 1006 to 1007 in 03c3051

	"tipLength": 88,
	"tipOverlap": 7.95,

Off the top of my head, I'm not sure how the tip length gets set when you have two different tiprack definitions for the pipette, but I am thinking that if you do p1000.pick_up_tip(tall_tiprack['A1']) before doing the aspirate command with the custom tip, this might work around the issue you are seeing.

You can find more info on creating labware definitions here.

[Dardin-dale]

Thank you! I've been going on the website labware library page and I didn't see any mention of custom tiprack definitions (only plate definitions) so I thought it was not implemented. But I'll try making a dummy definition to see what the behavior is.

I might make my own definition for a pick_up_tip() eventually since I'm not sure if the tip that we are using will survive the shaking. Is there a state value that I can change to inform the OT-2 that a tip is attached?

[SyntaxColoring]

The problem reported in the original post still exists on robot software v4.2.1, Python Protocol API v2.9.

metadata = {
    'apiLevel': '2.9'
}

def run(protocol):
    tip_rack = protocol.load_labware('opentrons_96_tiprack_300ul', 2)
    plate = protocol.load_labware('corning_384_wellplate_112ul_flat', 1)
    pipette = protocol.load_instrument('p300_multi_gen2', mount='right', tip_racks=[tip_rack])
    
    pipette.pick_up_tip(tip_rack['A1'])
    
    # Expected behavior: Move in an arc to 10 cm above the plate, then aspirate
    # in place.
    #
    # Actual behavior: Move in an arc to the top of the plate, then move 10 cm
    # straight up, then aspirate in place.
    pipette.aspirate(300, plate['A1'].top(100))
    
    pipette.return_tip(tip_rack['A1'])

[SyntaxColoring]

To make it easier for us to understand and keep track of this issue, I've hidden the comments in this thread that seem to be talking about other things.

I don't mean to imply that those things are unimportant or not worthy of discussion—just that they're separate. If you're still seeing those problems on the latest robot software version (currently v4.2.1), please reach out to Opentrons Support or create a new GitHub issue—we want to fix them!

[Matt-Zwimpfer]

MLM - address in future

[mcous]

This is a motion planning bug in PAPIv2 that will likely not be changed due to the risk of causing unintended side-effects. The upcoming PAPIv3 has new motion planning logic that does not exhibit this behavior