This seems equally possible with the opentrons definitions - once you calibrate a basic labware (single 384 well plate, single 96 well plate, etc), you really only need a Z calibration for depth. In order to get that basic labware definition and Z calibration, you must do actual calibrations on a robot. In this way, I’ve found that manufacturer specs are kind of useless - the grounding in physical reality is irrelevant to the specs (because it is just defined by the calibrations). This makes the labware model of opentrons pretty attractive to me, because these abstractions are very easy in it.
Hmmm, this doesn’t sit quite well. A coordinate model (correct me if I am wrong) is assuming that the coordinate system is consistent across the robot. Ie, if you ask to go to an XYZ position, as defined by the deck, and you have a labware you’ve calibrated and have the exact specifications for, you can find a given well position. But this abstraction is empirically untrue (at least for Opentrons) - the fact is that the XYZ positioning is not consistent across the deck. You have two methods - locally calibrate labwares (such that the underlying physical calibrations are only relevant to a deck position on the robot), or create offsets specific to local positions.
I can already do that, just constrained to the XYZ coordinates of a given labware/location.
Here is another way: You send identifiers with a deck location. For example:
{
"labware": "corning_384_wellplate_112ul_flat",
"position": "3",
"well": "A1"
}
The server knows of the labwares defined within PLR, or of a new labware if you so define it. It simply keeps the same labware until you want to change it at runtime. Here is how I change it at runtime in the plate protocol:
# Only delete deck 5 if we need the second plate
if needs_second_plate:
del protocol.deck["1"] # https://github.com/Opentrons/opentrons/issues/6214
agar_plates = [
protocol.load_labware("biorad_96_wellplate_200ul_pcr", x) for x in [3, 1]
]
else:
agar_plates = [protocol.load_labware("biorad_96_wellplate_200ul_pcr", 3)]
My argument for something closer to Opentron’s current API rather than absolute coordinate system is based off of the (perhaps specific to OT2) problems that the deck isn’t consistent, so coordinate positions that are not relative to particular positions on the deck can cause problems on 384 well plates.
Perhaps on Hamiltons you can rely on the fact that the coordinate system is accurate, so you can simply define the deck layout, and then derive from good definitions grounded in physical reality. But it doesn’t seem that way on the opentrons.
