Skip to content
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

Stop planner if the goal is cancelled #4139

Closed
bektaskemal opened this issue Feb 23, 2024 · 2 comments · Fixed by #4148
Closed

Stop planner if the goal is cancelled #4139

bektaskemal opened this issue Feb 23, 2024 · 2 comments · Fixed by #4148

Comments

@bektaskemal
Copy link
Contributor

Feature request

Feature description

The current implementation of PlannerServer invokes the getPlan function in a blocking manner. This means that even if a goal is cancelled, the planner computation continues until completion, leading to potential delays, especially with slower planners like Hybrid A*.

Implementation considerations

Potential implementations could be either running planner in an async way and keep checking for isCancelRequested or having a cancel service. Both requires GlobalPlanner to have a cancel interface.

@SteveMacenski
Copy link
Member

The planners generally shouldn't be all that long running of processes (Smac Hybrid-A* might be ~400ms in semi-normal large scale use-cases, but I suppose depending on parameterization it could increase more) where we felt that this might be an issue. But its true that especially if you're BOY-planner, then that planner could be, 5-10-20-N seconds long and we might want to kill that.

We do that right now in the Smac Planner and others with planning timeouts. The planner action API contains a timeout that if we exceed, the planner exits. Its different than a cancelation for sure, but helps a portion of this issue to make sure we don't plan indefinitely.

I'd be very open to an architectural update that would allow for the in-run preemption of planning algorithms based on cancellations.

Potential implementations could be either running planner in an async way and keep checking for isCancelRequested

That makes sense, basically pass in a function to the planning plugin's main request function who is a lambda that returns the bool value of the action server's is cancel requested API. We can check this on looping over the search or to other internal libraries that can take an external exit condition. I took a quick glance at a couple of the planners and I see where that could be used:

NavFn is a little trickier, but should also be possible in the same concept. This is something you'd be willing to take the lead on implementing and opening a PR? This seems like a good contribution for sure!

@bektaskemal
Copy link
Contributor Author

Sounds good, I will create a PR soon for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants