fix(app, robot-server): support retryLocation when retrying dropTipInPlace during Error Recovery
#16839
Conversation
mjhuff
changed the title
retryLocation when retrying dropTipInPlace during Error Recovery
mjhuff
changed the title
retryLocation when retrying dropTipInPlace during Error RecoveryretryLocation when retrying dropTipInPlace during Error Recovery
| current_location = self._state_view.pipettes.get_current_location() | ||
| current_position = await self._gantry_mover.get_position(params.pipetteId) |
There was a problem hiding this comment.
Unrelated fix. Fixing a potentially unbound reference to curent_position.
| @@ -76,8 +76,8 @@ async def execute(self, params: DispenseInPlaceParams) -> _ExecuteReturn: | |||
| """Dispense without moving the pipette.""" | |||
| state_update = StateUpdate() | |||
| current_location = self._state_view.pipettes.get_current_location() | |||
| current_position = await self._gantry_mover.get_position(params.pipetteId) | |||
There was a problem hiding this comment.
Unrelated fix. Fixing a potentially unbound reference to current_position.
| @@ -145,6 +145,7 @@ async def execute(self, params: DropTipParams) -> _ExecuteReturn: | |||
| error=exception, | |||
| ) | |||
| ], | |||
| errorInfo={"retryLocation": position}, | |||
There was a problem hiding this comment.
This is redundant for dropTip, but it lets us share the same TipPhysicallyAttachedError shape.
|
|
||
| async def execute(self, params: DropTipInPlaceParams) -> _ExecuteReturn: | ||
| """Drop a tip using the requested pipette.""" | ||
| state_update = update_types.StateUpdate() | ||
|
|
||
| retry_location = await self._gantry_mover.get_position(params.pipetteId) |
There was a problem hiding this comment.
@mjhuff Do we ever attempt a dropTipInPlace in a situation where the robot is not homed? If so, this might cause trouble, because the robot doesn't know the retryLocation, and my naive implementation here will cause it to raise an exception and fail the command. I think we had another bug like this.
There was a problem hiding this comment.
@mjhuff Do we ever attempt a
dropTipInPlacein a situation where the robot is not homed?
Hm, it's possible for users to dropTipInPlace during the drop tip wizard portion of recovery (so effectively every flow minus the gripper flow) and during the "Tip drop failed" flow.
However, in theory, the only instances during ER that the robot may be unaware of its position is during a gripper stall/collision error, and it's possible to get to dt wiz during that flow.
We do update position estimators before the blowout/drop tip, however, if a MustHomeError is possible, this will be problematic, since error recovery has its own error modals and won't show the "home the gantry" CTA.
There was a problem hiding this comment.
If you tried to dropTipInPlace when you don't have a position estimation then it will fail, so if we're ever doing that then it isn't working already. After you unsafe/updatePositionEstimators, get_position will work.
There was a problem hiding this comment.
Ok, great, I believe we are covered then. If you're dropping tips during a gripper stall/collision, you are about to end the run, and get_position won't matter. If you are resuming the run after a gripper stall/collision, we are doing an "everything but the plungers" home.
If you are dropTipInPlaceing during a different error recovery flow, as of this release, the robot knows its position.
|
|
||
| async def execute(self, params: DropTipInPlaceParams) -> _ExecuteReturn: | ||
| """Drop a tip using the requested pipette.""" | ||
| state_update = update_types.StateUpdate() | ||
|
|
||
| retry_location = await self._gantry_mover.get_position(params.pipetteId) |
There was a problem hiding this comment.
If you tried to dropTipInPlace when you don't have a position estimation then it will fail, so if we're ever doing that then it isn't working already. After you unsafe/updatePositionEstimators, get_position will work.
|
On hold until we fix https://opentrons.atlassian.net/browse/RQA-3599 and we can test this with gripper error recovery. |
Done! |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## chore_release-8.2.0 #16839 +/- ##
======================================================
Coverage ? 92.43%
======================================================
Files ? 77
Lines ? 1283
Branches ? 0
======================================================
Hits ? 1186
Misses ? 97
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more. |
Closes RQA-3591
Overview
When dropping a tip in a trash bin or waste chute, the pipette moves downwards before doing the drop tip. During Error Recovery, when we retry the failed command with a
fixitintent, we need to perform amoveToCoordinatesfirst before dispatching thedropTipInPlaceor the robot drops the tip(s) from too high a location.To know how far to move, we need the
failedCommandto containretryLocationmetadata. We have a pattern for this already withoverpressurein place commands, so we extend the same functionality here.Test Plan and Hands on Testing
Changelog
Risk assessment
low