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(api, robot-server): add estop state machine #13146

Merged
merged 14 commits into from
Jul 21, 2023

Conversation

fsinapi
Copy link
Contributor

@fsinapi fsinapi commented Jul 21, 2023

Overview

Adds a state machine to handle the Estop status on the hardware controller, and makes it available to the robot server.

The state machine looks like this:
image

This PR does not block out any movements when the Estop is in the "logically-engaged" state, because the only way to clear that is through the HTTP endpoint and if the app doesn't give that option we'd be blocking all movements until the robot server restarts.

Test Plan

Threw it out a robot and walked through all of the state transitions in the diagram. Checked the state & acknowledged the logically-engaged state with the endpoints under /robot/control. Everything worked correctly, physical changes all seemed to get detected by the rear panel.

Changelog

  • Added message definition to request estop state (this already existed in the rear panel firmware?)
  • Added Estop Detector to listen for binary messages, parse them, and forward them
  • Added Estop State machine to listen for the messages from the Detector and transition through the required state machine
  • Hooked up /robot/control endpoints to hardware controller

Review requests

Risk assessment

Pretty low until we hook this up to block movements in a later PR!

@fsinapi fsinapi requested review from sfoster1 and a team July 21, 2023 14:04
@fsinapi fsinapi requested a review from a team as a code owner July 21, 2023 14:04
@fsinapi fsinapi self-assigned this Jul 21, 2023
@codecov
Copy link

codecov bot commented Jul 21, 2023

Codecov Report

Merging #13146 (0f8ae72) into edge (0f1e0bb) will decrease coverage by 0.10%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             edge   #13146      +/-   ##
==========================================
- Coverage   72.56%   72.46%   -0.10%     
==========================================
  Files        2380     2387       +7     
  Lines       65881    66060     +179     
  Branches     7274     7304      +30     
==========================================
+ Hits        47806    47872      +66     
- Misses      16339    16452     +113     
  Partials     1736     1736              
Flag Coverage Δ
g-code-testing 96.44% <ø> (ø)
hardware 56.65% <100.00%> (-0.08%) ⬇️
notify-server 89.13% <ø> (ø)

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

Impacted Files Coverage Δ
...entrons/hardware_control/backends/ot3controller.py 66.66% <ø> (ø)
...pentrons/hardware_control/backends/ot3simulator.py 87.30% <ø> (ø)
api/src/opentrons/hardware_control/ot3api.py 80.05% <ø> (ø)
api/src/opentrons/hardware_control/types.py 96.35% <ø> (ø)
robot-server/robot_server/hardware.py 81.94% <ø> (ø)
robot-server/robot_server/router.py 100.00% <ø> (ø)
...ons_hardware/firmware_bindings/binary_constants.py 100.00% <100.00%> (ø)
...re_bindings/messages/binary_message_definitions.py 88.48% <100.00%> (+0.24%) ⬆️
...ntrons_hardware/hardware_control/estop/detector.py 100.00% <100.00%> (ø)

... and 20 files with indirect coverage changes

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 overall, but I think as we add more stuff to the hardware controller that depends on estop stuff we'll really thank ourselves if we make the upward interface of the backend non-Optional.

return True

@property
def estop_state_machine(self) -> Optional[EstopStateMachine]:
Copy link
Member

Choose a reason for hiding this comment

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

I don't love the difference being exposed in this way (with it returning an optional) - I'd rather have the controller and the simulator return a guaranteed object that just stays locked in "disengaged" if the backing hardware isn't present. It'll save us a bunch of little tests in the hardware controller.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👌

Copy link
Contributor Author

Choose a reason for hiding this comment

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

"""Callback from the detector."""
self._handle_state_transition(new_summary=summary)

def _transition_from_physically_engaged(self) -> None:
Copy link
Member

Choose a reason for hiding this comment

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

For testability can we make these take summaries as arguments and return new states?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@fsinapi fsinapi requested a review from sfoster1 July 21, 2023 15:19
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.

Excellent, looks great!

@fsinapi fsinapi merged commit 98f191d into edge Jul 21, 2023
@fsinapi fsinapi deleted the RCORE-796-Add-e-stop-state-machine-to-hardware-control branch July 21, 2023 17:38
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.

2 participants