Feature request
Feature description
Propagate the accepted / rejected info back to the caller of the navigation action instead of starting the navigation and then aborting it right away.
Implementation considerations
When starting navigation with async_send_goal, there is no nice way to know if the request was accepted or rejected.
The "ROS" way would be to wait for the send_goal future, and then check if we have a goal handle. But because the BTActionServer uses SimpleActionServer under the hood, which only has an ExecuteCallback and a CompletionCallback, there is no way to truly reject the goal. What happens now, is that the goal is always accepted, and in the beginning of the ExecuteCallback, on_goal_received_callback_ is called, and if it returns false, the goal is aborted.
The best thing the user can do if this info is needed, is either to wait a bit and see if the goal was aborted right away, or to propagate the error info from the navigator "by hand" on a topic or similar. None of these are nice solutions though.
What is the right way to get this info? What was the motivation behind this decision? In case we were to fix it, I'm happy to contribute.
I think the solution is to add a goalReceived callback to SimpleActionServer, which seems pretty straightforward to do.
P.S.
Sorry if this has been asked before, I couldn't find anything related. Also not sure if this is a feature request or a bug report.
Feature request
Feature description
Propagate the accepted / rejected info back to the caller of the navigation action instead of starting the navigation and then aborting it right away.
Implementation considerations
When starting navigation with
async_send_goal, there is no nice way to know if the request was accepted or rejected.The "ROS" way would be to wait for the send_goal future, and then check if we have a goal handle. But because the
BTActionServerusesSimpleActionServerunder the hood, which only has anExecuteCallbackand aCompletionCallback, there is no way to truly reject the goal. What happens now, is that the goal is always accepted, and in the beginning of theExecuteCallback,on_goal_received_callback_is called, and if it returns false, the goal is aborted.The best thing the user can do if this info is needed, is either to wait a bit and see if the goal was aborted right away, or to propagate the error info from the navigator "by hand" on a topic or similar. None of these are nice solutions though.
What is the right way to get this info? What was the motivation behind this decision? In case we were to fix it, I'm happy to contribute.
I think the solution is to add a
goalReceivedcallback toSimpleActionServer, which seems pretty straightforward to do.P.S.
Sorry if this has been asked before, I couldn't find anything related. Also not sure if this is a feature request or a bug report.