-
Notifications
You must be signed in to change notification settings - Fork 180
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(api): inner well geometry unit tests #17082
Conversation
a3440a9
to
9a0eaf5
Compare
998393f
to
11ee5b7
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## edge #17082 +/- ##
===========================================
- Coverage 92.43% 73.82% -18.62%
===========================================
Files 77 43 -34
Lines 1283 3301 +2018
===========================================
+ Hits 1186 2437 +1251
- Misses 97 864 +767
Flags with carried forward coverage won't be shown. Click here to find out more.
|
5f9a620
to
98ea908
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good once you run make format-js
!
14e10fc
to
dc3cb04
Compare
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview This just copies the updated well geometry definitions from edge over to chore_release. <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. --> Co-authored-by: Caila Marashaj <[email protected]>
This copies geometry across definitions: opentrons_24_tuberack_nest_1.5ml_snapcap --> opentrons_24_aluminumblock_nest_1.5ml_snapcap The tuberack one was already correct before this PR, but its updates in PR #17082 were never propagated to the aluminumblock one.
This copies geometry across definitions: opentrons_24_tuberack_nest_2ml_snapcap --> opentrons_24_aluminumblock_nest_2ml_snapcap. The tuberack one was already correct before this PR, but its updates in PR #17082 were never propagated to the aluminumblock one.
This copies geometry across definitions: opentrons_10_tuberack_nest_4x50ml_6x15ml_conical --> opentrons_6_tuberack_nest_50ml_conical --> opentrons_15_tuberack_nest_15ml_conical 4x50ml_6x15ml was already correct before this PR, but its updates in #17082 were never propagated to the other two definitions.
This copies geometry across definitions: opentrons_24_tuberack_nest_1.5ml_snapcap --> opentrons_24_aluminumblock_nest_1.5ml_snapcap The tuberack one was already correct before this PR, but its updates in PR #17082 were never propagated to the aluminumblock one.
This copies geometry across definitions: opentrons_24_tuberack_nest_2ml_snapcap --> opentrons_24_aluminumblock_nest_2ml_snapcap. The tuberack one was already correct before this PR, but its updates in PR #17082 were never propagated to the aluminumblock one.
This copies geometry across definitions: opentrons_10_tuberack_nest_4x50ml_6x15ml_conical --> opentrons_6_tuberack_nest_50ml_conical --> opentrons_15_tuberack_nest_15ml_conical 4x50ml_6x15ml was already correct before this PR, but its updates in #17082 were never propagated to the other two definitions.
Overview
This pr resolves the geometry calculations pertaining to liquid tracking. It updates a lot of the inner well geometry definitions according to the hardware team's measurements, and includes some math and logic fixes.
Frustum Whoopsie
One notable math fix is that the first time
height_to_volume_circular
orvolume_to_height_circular
are called for a given well, we'll now generate a table inshared-data
containing the volume calculated at every height within the well at a 0.005 mm interval. We did this because the inverse function of the polynomial relationship (only for circular frusta) we came up with was shown to have an exponential increase in error with respect to height that peaked at the middle of each well segment.To clarify, finding the volume from the height within a conical frustum works reliably well. This is because the relationship between height and volume takes the following shape:
Volume = a * target_height^3 + b * target_height^2 + c * target_height
, where a, b, and c are found from the heights and radii of the top and bottom faces.This makes finding the volume only a matter of addition and multiplication, but finding the height from some arbitrary volume to require an estimation of the roots of a third-degree polynomial. So, the solution here is just to avoid using that estimation and rely on a set number of the more reliable volume calculations that are done all at once.
For whatever reason, this was only a problem when calculating heights in circular, and not rectangular, frusta, so we left the rectangular math as is.
Changelog