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

navfn long plans don't start at the start #16

Closed
hershwg opened this issue Dec 28, 2012 · 5 comments
Closed

navfn long plans don't start at the start #16

hershwg opened this issue Dec 28, 2012 · 5 comments
Assignees
Labels

Comments

@hershwg
Copy link
Contributor

hershwg commented Dec 28, 2012

When navfn is asked to make a plan which ends up being quite long, the plan that is returned starts somewhere between the start and goal and ends at the goal. Usually such plans are not usable because they don't tell the robot which way to go from their current location.

Attached image shows start location as a yellow square in upper right and goal location as a green square on left side. Generated path (in cyan) does not start at the start.

navfn-bug

@ghost ghost assigned hershwg Dec 28, 2012
hershwg added a commit that referenced this issue Dec 28, 2012
hershwg added a commit that referenced this issue Dec 28, 2012
@hershwg
Copy link
Contributor Author

hershwg commented Dec 28, 2012

Fixed by increasing the previous path length limit. Old limit was map-width * 4, but no indication why it was so low. I changed it to map-area / 2, which should be enough for even the worst map.

There is a "cycle" limit in NavFn::propNavFnDijkstra() which is map-area / 20, which may be the new limiting factor on plan-able path length. I'm not sure exactly what a single "cycle" means though, or how it relates to path length, so leaving alone for now.

@nightingale0131
Copy link

Hi, I ran into this issue again recently, on a much smaller map (see below).
The path is the cyan line, and the robot is in the lower right corner. As you can see, the path doesn't start from where the robot is, resulting in move_base aborting the goal.

The package version is 1.14.4, on kinetic.
pathnotlongenough

@DLu
Copy link
Member

DLu commented Sep 25, 2019

That bug looks similar to the one presented here, but given the size of the map, I don't think it stems from the same problem. Can you open an answers.ros.org post with your configuration?

@nightingale0131
Copy link

@fcelitok
Copy link

I also had the same problem and I solved it as increasing pathStep = 0.5 to pathStep = 1.0

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

No branches or pull requests

4 participants