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(hardware-testing): enable multi sensor processing in liquid probe #14883

Merged
merged 18 commits into from
Apr 22, 2024

Conversation

ryanthecoder
Copy link
Contributor

Overview

This allows the liquid level detection script to tell the pipette to buffer the data from both pipettes and fetch them afterwards,
it will now spit out seprate CSVs for each sensor. post processing not yet updated so the final report just grabs one from each trial, will implement in EXEC-268

Test Plan

Changelog

Review requests

Risk assessment

@ryanthecoder ryanthecoder requested review from a team as code owners April 11, 2024 21:12
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 good, we should remove that print though

print("starting move group runner")
positions = await move_group.run(can_messenger=messenger)
messenger.add_listener(sensor_capturer, None)
print("starting move group runner")
Copy link
Member

Choose a reason for hiding this comment

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

accidental checkin?

output_option = _build_output_option_with_default(
from_conf.get("output_option", None), default.output_option
)
print(f"output_option {output_option}")
Copy link
Contributor

Choose a reason for hiding this comment

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

got a print left in here

@@ -1372,6 +1373,16 @@ async def liquid_probe(
can_bus_only_output = bool(
output_option.value & OutputOptions.can_bus_only.value
)
IPT_TO_SID: Dict[InstrumentProbeType, SensorId] = {
Copy link
Contributor

@caila-marashaj caila-marashaj Apr 19, 2024

Choose a reason for hiding this comment

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

why not just use sensor_id_for_instrument here?

Copy link
Contributor

@caila-marashaj caila-marashaj left a comment

Choose a reason for hiding this comment

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

Couple very small things, and otherwise looks great!

@ryanthecoder ryanthecoder merged commit d4f7f17 into edge Apr 22, 2024
22 checks passed
y3rsh added a commit that referenced this pull request Apr 23, 2024
* edge: (194 commits)
  fix(app): clone run with RTPs from HistoricalProtocolRun (#14959)
  fix(api): Filter out `air_gap()` calls as higher-order commands (#14985)
  fix(app): fix infinitely re-rendering/never rendering firmware success toasts (#14981)
  feat(api): add option to ignore different tip presence states (#14980)
  feat(opentrons-ai-client) add input textbox to container (#14968)
  fix(app): add robotSerialNumber to proceedToRun event (#14976)
  fix(api): remove homing patch fix for right mount when a 96-channel is attached (#14975)
  feat(api-client,app,react-api-client): upload splash logo from desktop app (#14941)
  fix(robot-server): notify /runs when a non-current run is deleted (#14974)
  feature(api, robot-server): Allow fixit commands to recover from an error (#14908)
  feat(hardware-testing): enable multi sensor processing in liquid probe (#14883)
  fix(app): prevent "run again" banner from rendering after navigating away from the current run (#14973)
  refactor(components): refactor roundtab stories (#14956)
  refactor(protocol-designer): assign module slot in createFileWizard instead of modal (#14951)
  fix(app, api-client): fix choose protocol slideout issue (#14949)
  refactor(protocol-designer): tip position modal max values round down (#14972)
  feat(app): add tiprack selection step to quick transfer flow (#14950)
  ci(shared-data): install dependencies in workflow (#14958)
  fix(components): fix icon stories (#14969)
  feat(opentrons-ai-client): introduce react-markdown to chat display component (#14965)
  ...
Carlos-fernandez pushed a commit that referenced this pull request May 20, 2024
#14883)

<!--
Thanks for taking the time to open a pull request! 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

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview
This allows the liquid level detection script to tell the pipette to
buffer the data from both pipettes and fetch them afterwards,
it will now spit out seprate CSVs for each sensor. post processing not
yet updated so the final report just grabs one from each trial, will
implement in EXEC-268

<!--
Use this section to describe your pull-request at a high level. If the
PR addresses any open issues, please tag the issues here.
-->

# Test Plan

<!--
Use this section to describe the steps that you took to test your Pull
Request.
If you did not perform any testing provide justification why.

OT-3 Developers: You should default to testing on actual physical
hardware.
Once again, if you did not perform testing against hardware, justify
why.

Note: It can be helpful to write a test plan before doing development

Example Test Plan (HTTP API Change)

- Verified that new optional argument `dance-party` causes the robot to
flash its lights, move the pipettes,
then home.
- Verified that when you omit the `dance-party` option the robot homes
normally
- Added protocol that uses `dance-party` argument to G-Code Testing
Suite
- Ran protocol that did not use `dance-party` argument and everything
was successful
- Added unit tests to validate that changes to pydantic model are
correct

-->

# Changelog

<!--
List out the changes to the code in this PR. Please try your best to
categorize your changes and describe what has changed and why.

Example changelog:
- Fixed app crash when trying to calibrate an illegal pipette
- Added state to API to track pipette usage
- Updated API docs to mention only two pipettes are supported

IMPORTANT: MAKE SURE ANY BREAKING CHANGES ARE PROPERLY COMMUNICATED
-->

# Review requests

<!--
Describe any requests for your reviewers here.
-->

# Risk assessment

<!--
Carefully go over your pull request and look at the other parts of the
codebase it may affect. 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 in protocol may also change the
behavior of labware calibration.

Identify the other parts of the system your codebase may affect, so that
in addition to your own review and testing, other people who may not
have the system internalized as much as you can focus their attention
and testing there.
-->
Carlos-fernandez pushed a commit that referenced this pull request Jun 3, 2024
#14883)

<!--
Thanks for taking the time to open a pull request! 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

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

This allows the liquid level detection script to tell the pipette to
buffer the data from both pipettes and fetch them afterwards,
it will now spit out seprate CSVs for each sensor. post processing not
yet updated so the final report just grabs one from each trial, will
implement in EXEC-268

<!--
Use this section to describe your pull-request at a high level. If the
PR addresses any open issues, please tag the issues here.
-->

<!--
Use this section to describe the steps that you took to test your Pull
Request.
If you did not perform any testing provide justification why.

OT-3 Developers: You should default to testing on actual physical
hardware.
Once again, if you did not perform testing against hardware, justify
why.

Note: It can be helpful to write a test plan before doing development

Example Test Plan (HTTP API Change)

- Verified that new optional argument `dance-party` causes the robot to
flash its lights, move the pipettes,
then home.
- Verified that when you omit the `dance-party` option the robot homes
normally
- Added protocol that uses `dance-party` argument to G-Code Testing
Suite
- Ran protocol that did not use `dance-party` argument and everything
was successful
- Added unit tests to validate that changes to pydantic model are
correct

-->

<!--
List out the changes to the code in this PR. Please try your best to
categorize your changes and describe what has changed and why.

Example changelog:
- Fixed app crash when trying to calibrate an illegal pipette
- Added state to API to track pipette usage
- Updated API docs to mention only two pipettes are supported

IMPORTANT: MAKE SURE ANY BREAKING CHANGES ARE PROPERLY COMMUNICATED
-->

<!--
Describe any requests for your reviewers here.
-->

<!--
Carefully go over your pull request and look at the other parts of the
codebase it may affect. 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 in protocol may also change the
behavior of labware calibration.

Identify the other parts of the system your codebase may affect, so that
in addition to your own review and testing, other people who may not
have the system internalized as much as you can focus their attention
and testing there.
-->
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

3 participants