Hi @soonki,
I think what you want is not coherent with the normal behavior of the actionlib
implementation. If you cancel a Goal from the Client, the Server will immediately stop processing the current Goal since its state was forced to be change to PREEMPTED
, resuming the execution of the Client and finished in a PREEMPTED
state. Unless you block the Server execution, but in that case It will not be able to process more Goals and you will need to synchronize that with the Client to be sure new goals are not fetched. The main problem for this set up is that the Server processing occurs in a callback function not its main process and I am not really sure if blocking its execution in a callback is advisable.
When fetched a new Goal, the Client needs to call the waitForResult function either waiting indefinitely if the duration
argument is 0 or the amount specified, or until the Goal is cancelled by the Client or the Server.
Once the goal is Cancelled you can use several approach to perform a task after Preemption:
- You can use in your Server implementation the isPreemptRequested method to query about the Goal state and if there was a preemption requested from the Client.
- You also can use instead the registerPreemptCallback that allow you to register a callback (function) to perform a tasks when a new preempt request is available.
Since I do not know your real set up, you can also implement that behavior in your Client, when the Goal is cancelled you can use the getState method to get the Goal state and wait or do whatever you want to do there. Since the Server cancelled past goals, the execution will be waiting for a new goal until you resumes it in the Client and fetch a new Goal to the Server.
I do not know if this answers is useful for your question but hope it can help you. If anyone come up with another useful approach I will glad to discuss it here.
Regards.