Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(ot3): add shared data support for ot3 pipettes #11704

Merged

Conversation

Laura-Danielle
Copy link
Contributor

Overview

We need a better way to encapsulate the new functionality that ot3 pipettes has, as well as the
types of pipettes available. I will be splitting up this work into a series of bits of work ticketed here.

Changelog

  • Bump the schema version on the pipettes (for now only GEN 3s are supported)
  • Split out the pipette schemas into more "reasonable" sections that are also easier to use

Review requests

  • Can someone make sure my js tests are all actually running correctly?
  • Anything else you think is missing from the schemas?
  • Anything you don't like about the schemas as they are set-up now?

Risk assessment

Low. Not being used yet.

@Laura-Danielle Laura-Danielle requested review from a team and mcous and removed request for a team November 9, 2022 19:32
@codecov
Copy link

codecov bot commented Nov 9, 2022

Codecov Report

❗ No coverage uploaded for pull request base (RLIQ-131-support-96-channel@934c322). Click here to learn what that means.
The diff coverage is n/a.

Impacted file tree graph

@@                      Coverage Diff                       @@
##             RLIQ-131-support-96-channel   #11704   +/-   ##
==============================================================
  Coverage                               ?   74.40%           
==============================================================
  Files                                  ?     2089           
  Lines                                  ?    58016           
  Branches                               ?     6158           
==============================================================
  Hits                                   ?    43164           
  Misses                                 ?    13403           
  Partials                               ?     1449           
Flag Coverage Δ
app 72.61% <0.00%> (?)
notify-server 88.26% <0.00%> (?)
protocol-designer 45.86% <0.00%> (?)
shared-data 84.87% <0.00%> (?)
step-generation 88.46% <0.00%> (?)

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

@Laura-Danielle Laura-Danielle requested a review from a team as a code owner November 9, 2022 19:42
Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is so much nicer!

That said,

  • let's get the new schema data in the README
  • can you say a little more in the README and/or pr description about what the 3d files are for?
  • can you say a little more in the README and/or pr description about what the T200/T50 things are for and how they'll be used?

@@ -0,0 +1,5 @@
{
"$otSharedSchema": "#/pipette/schemas/2/pipetteGeometrySchema.json",
"pathTo3D": "pipette/definitions/2/eight_channel/p1000/placeholder.gltf",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

})

liquidPaths.forEach(liquidPath => {
const filename = path.parse(liquidPath).base
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As CI says, you don't use filename. Maybe just remove this line?

Copy link
Contributor

@andySigler andySigler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Went through and checked config values based off values we're currently using in testing

Copy link
Contributor

@mcous mcous left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've got a couple tiny comments with an eye towards RCORE-382 and some yet-to-be-written PAPI tickets for 96-channel support, but otherwise this looks really solid and a vast improvement over the old configs

Comment on lines 46 to 50
"patternProperties": {
"description": "Tip specific liquid handling properties for a given pipette. Using the active tip on a pipette, we will look up the pipetting configurations associated with that tip+pipette combo.",
"type": "object",
"$comment": "Example key: 'T50'",
"^T[0-9]{2,4}": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple notes:

  • Pattern properties are not easy to to map into Pedantic and other runtime models
  • I would softly prefer lowercase identifiers to upper or mixed-case

Could this be a list instead with a string field for the t50 (or whatever) portion?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mcous could I wrap the tip types in a top level key instead? I.e.:

supportedTips: {
  t50 {...},
  t200 {...},
}

etc? That way I can load the pydantic models based on the guaranteed keys inside each nested "tip" object and then I can use the top level pattern property keys to create a look-up table.

Comment on lines 111 to 120
"availableSensors": {
"type": "object",
"description": "object with keyed by sensor and number available",
"required": ["pressure", "capacitive", "environment"],
"properties": {
"pressure": { "enum": [1, 2] },
"capacitive": { "enum": [1, 2] },
"environment": { "enum": [1] }
}
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This specific capabilities list is a little hard to understand coming in blind. Can we make one of both of these changes?

  • Change to a list so we can define new sensors without changing the schema?
  • Do something like pressure: { count: number } rather than pressure: number to make it more obvious what's going on when reading the data?

As an aside, how is the sensor count data used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not currently used, but it will be used in the expanded pipette object class for ot3 pipettes to know how many sensor objects to build (will mainly be used for liquid sensing purposes)

Copy link
Contributor Author

@Laura-Danielle Laura-Danielle Nov 15, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mcous what do you think about this:

Available sensors is still an object that contains:

  • A list of available sensors (can be anything)
  • A pattern property which is keyed by sensor type and the object it contains is {count: number}

Then, an available sensors object might look like:

availableSensors: {
   "sensors": ["pressure", "capacitive", "environment"],
   "pressure": {count: 2},
    "capacitive": {count: 1},
    "environment": {count: 1}
}

@Laura-Danielle Laura-Danielle dismissed sfoster1’s stale review November 16, 2022 15:36

talked f2f, seth is OK with merging into feature branch

Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks awesome!

@Laura-Danielle Laura-Danielle merged commit 355ee9c into RLIQ-131-support-96-channel Nov 16, 2022
@Laura-Danielle Laura-Danielle deleted the shared-data_ot3-pipette-support branch November 16, 2022 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants