feat(shared-data,api,robot-server): Use new OT-3 deck slot naming style

[SyntaxColoring]

Overview

This is a chunk of back-end support for OT-3 style deck slot names, like D1 instead of 1.

Closes RLAB-250, RLAB-251, RLAB-253, RLAB-256, RLAB-257, RLAB-339, and RLAB-346.

Changelog

In general, the robot will now accept deck slots of either style (1 or D1) as input. It will normalize them to the device's preferred style (1 for OT-2s, D1 for OT-3s) in its internal state, and in its output. In protocol analyses, the style in the output will follow the protocol's declared robotType.

This affects:

• loadLabware commands
• moveLabware commands
• loadModule commands
• Labware offsets POSTed over HTTP
• Run summaries visible over HTTP

The underlying OT-3 deck definition in shared-data is changed to use the OT-3-style names. The module definitions are updated to match.

Review requests

• Scrutinize my updates in shared-data.
  • Make sure I'm updating things to the correct new values. Here's a handy quick reference table, but double-check this with a physical OT-3.
  • Make sure I didn't accidentally leave any of the OT-2-style numbers behind. It's very important that the module definitions and deck definitions are consistent with each other.
• Can you think of any other places that might need to normalize deck slots before comparing them? For example, any conflict-checking code hiding out somewhere?

Risk assessment

High.

This unfortunately has to change a bunch of stuff all at once, because it's all cross-dependent on each other.

Code that does this is in danger of breaking silently:

if some_slot == some_other_slot:
    ...

We do this in places such as:

• Determining the offset of a module. Modules have per-slot transformations, which are matched by slot ID.
• Determining the Labware Position Check offset to apply to a labware. Labware Position Check offsets are defined by a labware URI and a location, and the location includes the slot ID.

Test plan

Here's the protocol file that I'm using.

After pushing this branch to an OT-3, you'll need to factory-reset runs history before the robot is usable. You'll also need to factory-reset runs history when pushing edge back.

• OT-3-only: Make sure you can still detach and attach pipettes.
• OT-3-only: Make sure you can still calibrate pipettes.
• OT-2 and OT-3: Make sure the Labware Position Check flow continues to behave correctly.
  • Yes, with PRs fix(app): Make labware filtering in Labware Position Check robust to different deck types #12822 and fix(app): render correct deck in LPC #12815.
• OT-2 and OT-3: Make sure that offsets saved in Labware Position Check correctly apply to the actual protocol run.
• OT-2 and OT-3: Make sure you can apply labware offsets from prior runs.
• OT-2 and OT-3: Make sure that in a protocol run, the robot physically continues to go to the right place, especially when the labware is loaded atop a module.
• OT-2 and OT-3: Make sure the robot continues to dodge Thermocyclers, in protocols that have them.
• OT-2 and OT-3: In general, make sure the Opentrons App shows slot names like "1" everywhere it's dealing with an OT-2, and "D1" everywhere it's dealing with an OT-3.
  • RAUT-473 is one missed spot, but otherwise this seems good.
• OT-2 and OT-3: In general, make sure the Opentrons App keeps displaying the deck map correctly.

[codecov]

Codecov Report

Merging #12571 (0c52b1e) into edge (e65750c) will decrease coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             edge   #12571      +/-   ##
==========================================
- Coverage   73.35%   73.33%   -0.03%     
==========================================
  Files        2284     2307      +23     
  Lines       62736    63272     +536     
  Branches     6829     6949     +120     
==========================================
+ Hits        46022    46400     +378     
- Misses      15088    15239     +151     
- Partials     1626     1633       +7     

Flag	Coverage Δ
app	71.46% <ø> (+0.01%)	⬆️
g-code-testing	96.44% <ø> (ø)
hardware-testing	∅ <ø> (∅)
notify-server	89.13% <ø> (ø)
protocol-designer	46.35% <ø> (ø)
shared-data	75.47% <ø> (-0.89%)	⬇️
step-generation	88.64% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...i/src/opentrons/protocol_engine/protocol_engine.py	100.00% <ø> (ø)
...pi/src/opentrons/protocol_engine/state/geometry.py	100.00% <ø> (ø)
api/src/opentrons/protocol_engine/state/modules.py	91.48% <ø> (-0.05%)	⬇️
api/src/opentrons/protocol_engine/state/state.py	100.00% <ø> (ø)
api/src/opentrons/protocol_engine/types.py	97.72% <ø> (ø)
api/src/opentrons/types.py	86.17% <ø> (ø)
...data/python/opentrons_shared_data/deck/__init__.py	62.06% <ø> (+2.06%)	⬆️
api/src/opentrons/protocol_engine/state/labware.py	100.00% <100.00%> (ø)

... and 29 files with indirect coverage changes

[TamarZanzouri]

not for this PR but these changes are starting to make me think of moving all specific implementation details to a designated class. for example this will be a field in a class instead of a variable. same for _RIGHT_SIDE_SLOTS.

[TamarZanzouri]

again, this is me thinking from a DB perspective. This will probably live in a db table related to each robot

[TamarZanzouri]

still looks great! Max tested this a lot!

[SyntaxColoring]

There's one failing app front-end test, but I think that's an unrelated thing that's fixed in #12842.