-
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
fix(hardware): clear move group from node if move condition is met #12986
fix(hardware): clear move group from node if move condition is met #12986
Conversation
Codecov Report
@@ Coverage Diff @@
## internal-release_0.13.0 #12986 +/- ##
===========================================================
+ Coverage 72.82% 72.83% +0.01%
===========================================================
Files 2364 2364
Lines 64467 64514 +47
Branches 7191 7191
===========================================================
+ Hits 46945 46988 +43
- Misses 15842 15847 +5
+ Partials 1680 1679 -1
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.
This check looks good, but is there a way we could add a quick test for this scenario?
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 really think this should just clear out the one single node from the move group, and still wait until every node has reported that it's done. The way this is written, other axes could still be moving after the one axis reports its stall, and the robot could move on and start a new move before they stop moving.
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.
The more I think about it, I think we don't want to do this only if the stop condition is stall - I think this should happen any time we're stopped_by_condition
no matter what the condition is
@@ -422,6 +422,17 @@ def _handle_move_completed( | |||
) | |||
self._should_stop = True | |||
self._event.set() | |||
if ( | |||
stop_cond == MoveStopCondition.stall | |||
and ack_id == MoveAckId.stopped_by_condition |
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 think we might want this to just be ack_id == MoveAckId.stopped_by_condition
whether or not the stop condition is stall; I think you're going to get similar behavior from home commands, including the home backoffs, and the tip action motors, and definitely the stop-on-sync commands from calibration
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.
You're right!
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.
Nice, LGTM!
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.
Nice, thank you!
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.
ty looks good to me!
c5d49d8
to
8170fd3
Compare
Overview
The expected-stall move group times out whenever a stall is detected before the final move block, even though this is an acceptable behavior. This fixes it by clearing and finishing the move group whenever a move block is completed with a stall.