Allow the controller to handle cancel if properly implemented #274
Conversation
|
@corot I had a look at the bug and it looks not good. I've dead locked the node with your code and generated a coredump. Interestingly in the coredump, I didn't find the thread execution the cancel method anymore - which explains why the cancel method never returns... Since its related to the spinning (I'm not sure if spinning within the plugin is actually a good idea but this is not the point), I've created a dedicated callback queue just for our servers - and this seems to solve the problem. Could you check out https://github.com/magazino/move_base_flex/tree/dima/callback_queue (without the here mentioned changed to TEB) to see if it works for you? |
you mean, u had a deadlock with this PR? And which controller? default TEB or my example for slowing down? |
wooooo,,,, I knew something superfishy was happening,,, I though because of stopping the execution thread, but not |
Your TEB example from #273 |
Ah,,, yes, yes. I thought u meant this PR 😌 It's still interesting to investigate that strange problem, but this PR is a much cleaner solution to smooth cancels, imho |
But wait,,, this can be much simpler, right? Not enough to run an async spinner instead of spin? In any case, yes, sounds reasonable to run this multi-threaded. Did you try to reproduce the freezing with this change, but removing the |
Also a good idea - to me both seems fine.
Not sure about which spinOnce we are talking now 😕 About the one in cancel or in the main? It worked for me with the spinOnce in the cancel |
Then, can u approve this PR? Also @spuetz, can you test and approve this? As for the async spinner... I see the point, but is a completely different issue and so we shouldn't mix with this PR |
mbf_abstract_nav/include/mbf_abstract_nav/abstract_controller_execution.h
Outdated
Show resolved
Hide resolved
mbf_abstract_nav/include/mbf_abstract_nav/abstract_controller_execution.h
Outdated
Show resolved
Hide resolved
mbf_abstract_nav/include/mbf_abstract_nav/abstract_controller_execution.h
Outdated
Show resolved
Hide resolved
mbf_abstract_nav/include/mbf_abstract_nav/abstract_controller_execution.h
Outdated
Show resolved
Hide resolved
| @@ -254,18 +254,24 @@ bool AbstractControllerExecution::reachedGoalCheck() | |||
|
|
|||
| bool AbstractControllerExecution::cancel() | |||
| { | |||
| // request the controller to cancel; it returns false if cancel is not implemented or rejected by the plugin | |||
| if (!controller_->cancel()) | |||
| // Request the controller to cancel; returns true if he takes care of stopping, returning CANCELED when done, | |||
There was a problem hiding this comment.
controller seem to be very male in this pr 😁
There was a problem hiding this comment.
mmm.... I think I refer always as "him"... 🤔
I'll start using it
corot
force-pushed
the
ctrl_handled_cancel
branch
2 times, most recently
from
0c8decd
to
392c67c
Compare
corot
force-pushed
the
ctrl_handled_cancel
branch
from
392c67c
to
0064cf7
Compare
Possibly a much safer solution for #273. This allows smooth cancels with decreasing velocities without risking the deadlocks reported in #273. The controller becomes responsible of slowing down by returning decreasing speeds on computeVelocityCommands and SUCCESS outcome. When he considers that the robot can stop, returns zero velocity and CANCELED outcome.
Trivial example implementation for TEB:
If the controller doesn't implement the controller plugin API cancel method, or returns false, we use the normal stop method with an abrupt zero-velocity.
One corner case is when we cancel the controller but it reaches the goal while slowing down. In this case, we will report success, which is a sensible result because we accomplish the requested goal despite the cancel, but one could argue that we should return preempted.
Example:
cancel.online-video-cutter.com.mp4