-
Notifications
You must be signed in to change notification settings - Fork 179
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore(api,hardware): ot3 calibration backend (#10067)
The OT3 has an autocalibration routine that relies on its pipettes' (and gripper's) capacitive sensors. To execute this routine, the calibration_probe method is used to find the absolute position of the deck and the absolute position of a slot machined in the deck (with a binary search for each edge). What comes out of this routine, which is in new free functions in a helper file, is the estimated position in deck coordinates of the center of the calibration slot. This can then be subtracted from the nominal position of the center of the slot to form a pipette- and mount-specific offset that can be saved as the OT3 equivalent of pipette calibration. This is a heavily parametrized process; everything from the initial positions to the amount of binary searching to the exact behavior of each capacitive sensor pass can be changed. To accomodate this, add (a significant amount of) content to the robot config. While adding tests for new configuration values, a little refactoring reduced the size of the test files and added typing to some of the config tests. Tests for the calibration functionality itself are a little tough to write in a robust way. find_edge has complex behavior between the error handling and the binary search, so that is well tested; but find_deck_position strings together a couple extremely straightforward ot3api calls that would not be testable without writing the same code. We also need to add a context manager for telling a pipette to change its sync pin based on sensor values. Since only one sensor can be bound to an output at a time, it's important for that binding to end when it's relevant to do so. The best way to do that is a context manager, which this adds: in opentrons_hardware.sensors.scheduler.Scheduler, you can now do async with scheduler.bind_sync(...): to get an async context manager that binds a sensor and cleans up afterwards. This also required extending the rest of the scheduler functionality a bit more - waiting for a new kind of response - which meant it made sense to do a slight refactor of the response waiter to properly format data. There were also some dataclass changes that required adapting other classes. That binding can be used in autocalibration, when we move a Z axis until that tool senses a collision with the capacitive sensor. Now that there is an easy way to bind a sensor output, add hardware_control.tool_sensors.capacitive_probe (hardware_control.tool_sensors will eventually also contain the similar function for the pressure sensors that will be used for liquid level sensing). capacitive_probe assumes the system is already slightly above the anticipated position at which it will hit something, and moves down slightly more while configuring the proper sensor. We can also optionally stream out the sensor values, for now just to log, for debugging and inspection. * refactor(api): add OT3API.capacitive_probe This is a hardware control layer implementation of OT3 capacitive probing, using new capabilities in opentrons_hardware to implement it. The new function uses a type that will be in the config to configure itself. It has similar semantics to aspirate() and dispense() - the gantry will not move and it's assumed something else has put it in the right place, and so on. The new method will move down until the capacitive sensor triggers and then return the position at which it triggered in deck coordinates before returning to a safe height. Tests for the function only exist on the API layer because the controller is a oneliner. api test fixes and format * refactor(api): add logic for ot3 calibration
- Loading branch information
Showing
26 changed files
with
1,590 additions
and
533 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.