fix(app): Update tip detection logic

[mjhuff]

Closes RQA-2935

Overview

Now, whenever a protocol run ends, show drop tip CTAs if the run command history shows the run ended with tips attached, even if this was intentionally done by the user (intentional in the sense of the protocol never explicitly specifying a drop tip before the run ends).

All the changes here really occur in getPipettesWithTipAttached, and there are two:

• The aforementioned change.
• Don't use the Flex sensors anymore, since in practice, it's difficult to ensure the data we get isn't stale without delaying action for a bit.

Note that the run failure behavior and error recovery behavior remains the same.

Test Plan and Hands on Testing

• Verified the above behavior using the following protocols:

Case 1, the client doesn't explicitly drop tips in their protocol (show the CTAs):

from opentrons import protocol_api

# metadata
metadata = {
    "protocolName": "Pick up tip with no return",
    "author": "Name <[email protected]>",
    "description": "Simple protocol to get started using the Flex",
}

# requirements
requirements = {"robotType": "Flex", "apiLevel": "2.15"}


# protocol run function
def run(protocol: protocol_api.ProtocolContext):
    tiprack_left = protocol.load_labware(
        load_name="opentrons_flex_96_tiprack_1000ul", location="C2"
    )
    left_pipette = protocol.load_instrument(
        instrument_name="flex_8channel_1000", mount="left", tip_racks=[tiprack_left]
    )
    left_pipette.pick_up_tip()

Case 2, the client does explicitly drop tips in their protocol (don't show the CTAs):

from opentrons import protocol_api

# metadata
metadata = {
    "protocolName": "Pick up tip",
    "author": "Name <[email protected]>",
    "description": "Simple protocol to get started using the Flex",
}

# requirements
requirements = {"robotType": "Flex", "apiLevel": "2.15"}


# protocol run function
def run(protocol: protocol_api.ProtocolContext):
    tiprack_left = protocol.load_labware(
        load_name="opentrons_flex_96_tiprack_200ul", location="D1"
    )
    left_pipette = protocol.load_instrument(
        instrument_name="flex_1channel_1000", mount="left", tip_racks=[tiprack_left]
    )
    left_pipette.pick_up_tip()
    left_pipette.return_tip()

Changelog

• Drop tip CTAs now properly display at the end of a run based on tip state.

Review requests

@SyntaxColoring points out that at the end of a run, the robot implictly drops the tip without an explicit drop tip at the end of a protocol:

• The E-stop was pressed
• The run loaded no obvious trash where we can drop them
• The run was stopped by the user, as opposed to erroring or completing naturally

Knowing this, are we still ok nagging the users with drop tip CTAs despite the tips not actually being there?

Risk assessment

low with the caveat mentioned in review requests

[mjhuff]

Woops, only the last commit is the real commit. Ignore the other ones while I fix this.

[sfoster1]

I think we want to keep the "or if the command failed" logic.

I think also that the automatic post-run droptip could maybe not exist if we're makign things this mandatory, and alternately that if it does exist maybe we should do it by dispatching fixit commands from the orchestrator to make it get picked up by this logic (not for this release, though - for this release I'm ok with it). What do you think @SyntaxColoring

[sfoster1]

Nice, makes sense to me!