-
Notifications
You must be signed in to change notification settings - Fork 179
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
feat(api, robot-server): add estop state machine #13146
Conversation
…rear panel. This is already supported on the firmware, I'm not sure why it's missing from the monorepo?
Codecov Report
@@ 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
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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 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]: |
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.
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.
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.
👌
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.
"""Callback from the detector.""" | ||
self._handle_state_transition(new_summary=summary) | ||
|
||
def _transition_from_physically_engaged(self) -> None: |
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.
For testability can we make these take summaries as arguments and return new states?
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.
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.
Excellent, looks great!
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](https://private-user-images.githubusercontent.com/27798632/255195520-970b2171-31c4-4b70-87da-5fd335c975a2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg4NzA0NjUsIm5iZiI6MTczODg3MDE2NSwicGF0aCI6Ii8yNzc5ODYzMi8yNTUxOTU1MjAtOTcwYjIxNzEtMzFjNC00YjcwLTg3ZGEtNWZkMzM1Yzk3NWEyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA2VDE5MjkyNVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWY2MDUxN2MxNzJmNjc1YWE0OGVkYmIxYjRkMGRhNzdjNDcwYTgzNThiMjU3NDgyNTM4MjdmNjE5M2U5ZDUyZDMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.xklJavCzcOchQLMbznq-eA3Lfg0eCVQk-mj71Z8A4O8)
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
/robot/control
endpoints to hardware controllerReview requests
Risk assessment
Pretty low until we hook this up to block movements in a later PR!