feat(shared-data): add deck schema v6 #17250
Conversation
This schema contains a concept of "locating features" for addressable areas. These locating features are things that constrain the position of labware loaded on top of the addressable area. The presence of a locating feature indicates that the addressable area can contain deck items. Which locating feature is available constrains which labware can be loaded; different labware define different locatable features (for instance, their back left or front left corners, or the outer surface of one of their wells). Locating feature names are not constrained to enums because we expect a fairly wide number of them. Closes EXEC-80
shared-data/deck/schemas/6.json
Outdated
| "locatingFeature": { | ||
| "type": "object", | ||
| "required": ["locatingFeatureId", "offsetVector"], | ||
| "properties": { | ||
| "locatingFeatureId": { | ||
| "type": "string", | ||
| "description": "The name of a kind of locating feature that will be looked up in labware. Common ones are backLeft, frontLeft, wellA1, center, but others may be used." | ||
| }, | ||
| "offsetVector": { | ||
| "$ref": "#/definitions/xyzArray", | ||
| "description": "A vector from the origin of the thing that has the locating feature (i.e. an addressable area) to the key point of the locating feature." | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Locating feature names are not constrained to enums because we expect a fairly wide number of them.
I agree with not constraining them to enums, for versioning churn reasons, but I do think we'll need some central documented source that lists them all out and describes their semantics.
Like, what if we did something roughly like this:
"anyOf": [
{ "const": "backLeft": "description": "..."},
{ "const": "center": "description": "..."},
{ "type": "string", "description": "reserved for future expansion" }
]Alternatively, I guess this documentation could live in the labware definition schema. I don't have a preference.
There was a problem hiding this comment.
Oh definitely! I was trying to remember how to do this and couldn't haha. I'll add that.
| const defV5Glob = path.join(__dirname, '../../deck/definitions/5/*.json*') | ||
| const defV6Glob = path.join(__dirname, '../../deck/definitions/6/*.json*') |
There was a problem hiding this comment.
What are the trailing *s for?
There was a problem hiding this comment.
that's definitely a typo that got copy pasted
| { | ||
| "locatingFeatureId": "frontLeft", | ||
| "offsetVector": [0.0, 86.0, 0.0] | ||
| }, | ||
| { | ||
| "locatingFeatureId": "backLeft", | ||
| "offsetVector": [0.0, 0.0, 0.0] | ||
| } |
There was a problem hiding this comment.
Either:
- The slot origin is the front left, which means
frontLeftshould have an offset of[0, 0, 0]andbackLeftshould have an offset of[0, 86, 0] - Or the slot origin is the back left, which means
frontLeftshould have an offset of[0, -86, 0]andbackLeftshould have an offset of[0, 0, 0]
Right?
There was a problem hiding this comment.
...yes. I will fix this.
There was a problem hiding this comment.
The thing I'm going to do is keep the slot origin as the front left. This is fine because actually what we're saying is that the AA origin is the point indicated by the offsetFromCutoutFixture vector, and all coordinates are relative to that. Conveniently, keeping that vector the same means that we can avoid changing some app code.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## edge #17250 +/- ##
==========================================
+ Coverage 73.84% 75.33% +1.49%
==========================================
Files 43 30 -13
Lines 3303 2818 -485
==========================================
- Hits 2439 2123 -316
+ Misses 864 695 -169
Flags with carried forward coverage won't be shown. Click here to find out more.
|
This schema contains a concept of "locating features" for addressable areas. These locating features are things that constrain the position of labware loaded on top of the addressable area. The presence of a locating feature indicates that the addressable area can contain deck items. Which locating feature is available constrains which labware can be loaded; different labware define different locatable features (for instance, their back left or front left corners, or the outer surface of one of their wells).
Locating feature names are not constrained to enums because we expect a fairly wide number of them.
To come out of draft
risk
low, because nothing should be using this (purposeful, will be followup prs)
Closes EXEC-80