-
Notifications
You must be signed in to change notification settings - Fork 152
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
[ros2]: Fixed preempting of execution #363
base: ros2
Are you sure you want to change the base?
Conversation
@mechwiz Please review |
Codecov Report
@@ Coverage Diff @@
## ros2 #363 +/- ##
==========================================
- Coverage 38.85% 38.82% -0.03%
==========================================
Files 78 78
Lines 7520 7526 +6
==========================================
Hits 2921 2921
- Misses 4599 4605 +6
Continue to review full report at Codecov.
|
I tested these changes on a project I'm working on and can verify they work. LGTM! |
@@ -95,7 +97,8 @@ void ExecuteTaskSolutionCapability::initialize() { | |||
ActionServerType::CancelCallback( | |||
std::bind(&ExecuteTaskSolutionCapability::preemptCallback, this, std::placeholders::_1)), | |||
ActionServerType::AcceptedCallback( | |||
std::bind(&ExecuteTaskSolutionCapability::goalCallback, this, std::placeholders::_1))); | |||
std::bind(&ExecuteTaskSolutionCapability::goalCallback, this, std::placeholders::_1)), |
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 believe the std::bind
isn't needed here since 1 argument is expected
…ting the goal so it does not block the server from accepting a cancel request. While client is waiting for the result future, repeatedly check if preempting was requested and send a cancel request if it was
a760804
to
fcdce1e
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.
preempt was added to allow the user to stop planning.
As execution is just a thin wrapper around the action server it seems like a clumsy interface to repurpose preempt for execution instead.
Wouldn't it be better and more flexible to expose the action client to the user to cancel execution there?
error_code.val = moveit_msgs::msg::MoveItErrorCodes::PREEMPTED; | ||
return error_code; | ||
} | ||
} |
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.
Is that really the best we can do for this kind of feature? 10ms waits are quite bad style :(
Same as JafarAbdi#6