ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

Navigation path planning over long distances

asked 2021-06-24 22:43:37 -0500

torlog gravatar image

updated 2021-06-27 16:41:46 -0500

I'm having an issue with move_base and/or Navfn whereby the control system can't plan a path for anything over a certain distance.

The path planning (and following) works fine for short nav goals: image description

But then if I give the robot a longer goal, it either:

1) Plans the path backwards from the goal location, but doesn't reach the initial pose of the robot: image description

or 2) Doesn't even plan the path.

Regardless of if it was 1) or 2), if the goal is too far away, it clears the costmaps and starts a recovery behaviour (for some reason??)

[ INFO] [1624828201.921, 2362.060]: Got new plan
[ WARN] [1624828210.322, 2370.460]: Clearing both costmaps to unstuck robot (3.00m).
[ WARN] [1624828218.801, 2378.940]: Map update loop missed its desired rate of 0.2000Hz... the loop actually took 12.6100 seconds
[ WARN] [1624828218.822, 2378.960]: Rotate recovery behavior started.
[ WARN] [1624828236.140, 2396.260]: Clearing both costmaps to unstuck robot (1.84m).
[ WARN] [1624828236.492, 2396.610]: Map update loop missed its desired rate of 0.2000Hz... the loop actually took 7.6700 seconds
[ WARN] [1624828244.932, 2405.060]: Rotate recovery behavior started.
[ WARN] [1624828245.263, 2405.390]: Map update loop missed its desired rate of 0.2000Hz... the loop actually took 11.4500 seconds

The issue seems to be similar to this problem here, except I can't seem to find where to edit the Navfn numbers...

I am well and truly confused with this one, so any help would be greatly appreciated!! :)

edit retag flag offensive close merge delete

Comments

Just a quick comment: AMCL localises, it's not a planner.

gvdhoorn gravatar image gvdhoorn  ( 2021-06-25 04:30:31 -0500 )edit
2

I'm sorry to have to do this for something so seemingly unimportant, but please don't post screenshots of terminal text in question on ROS Answers. It's all text, so there is no need. Just copy-paste the text from the terminal into your question text. Do make sure to format it properly by selecting the text and pressing ctrl+k (or clicking the Preformatted Text button (the one with 101010 on it)).

You don't need to post a new question, just edit your curent one. You can use the edit button/link for this.

After you replace the screenshot with the error message itself, we can re-open your question.

gvdhoorn gravatar image gvdhoorn  ( 2021-06-25 04:31:18 -0500 )edit

Thanks for the info gvdhoorn - tried reopening it but i supposedly don't have enough points. Are you able to help with that? Cheers

torlog gravatar image torlog  ( 2021-06-27 16:48:34 -0500 )edit

What was approximately the original distance to goal, in meters?

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-07-12 08:18:08 -0500 )edit

What is the size of your static map, in cells? In the question you linked to, @David Lu says there is a limit on the global path length. [update] Never mind, I just saw you're aware of this from your answer. In my defense, you answer buries the important info!

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-07-12 08:26:06 -0500 )edit
1

NavFn appeared to have a tantrum with anything over 140m/160m, so for paths greater than this (i.e. in the second image) the issue would occur. Ultimately, it seems that it's not the physical length of the path that causes the error, but instead, the length of the path in pixels (as per this question/answer here). By editing the scale of the map, the path pixel count is reduced and the path can be generated. Another thing to note: the map itself has max limits of 35000 x 16000 pixels, so yet another thing to be aware of.

torlog gravatar image torlog  ( 2021-07-12 16:39:14 -0500 )edit
1

I had a very similar issue - mapping large areas of a sizeable warehouse - and found that lowering the map resolution to 0.2 still worked well. Admittedly, some support pylons disappeared off the map due to the dimensions being less than the map but didn't take long to add them back in using a map editor.

vector108 gravatar image vector108  ( 2021-07-12 18:11:49 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
4

answered 2021-07-12 01:49:12 -0500

torlog gravatar image

updated 2021-07-12 16:42:23 -0500

If anyone comes across a similar issue, this is how I worked around the problem:

Compress the map using GIMP (the original map resolution was 0.01 m/px; by scaling it down by a factor of 10, the new resolution is 0.1m/px). This does not appear to have any performance issues (apart from producing a 'grainier' map), if anything, it seems to improve performance - as long as the global map is a rough representation of the real world, local_planner seems to cope well with planning the 'nitty-gritty' of the path.

Another solution that worked to some extent was adding extra 'grey areas' (unknown space) around the map using GIMP. NavFn limits the size of the path based on the x and y pixel counts of the map... so by adding extra grey, the maximum path length is increased. I found that this method slowed the system considerably and would still flag errors every now and then.

Let me know if you have a similar issue and found a more suitable code-based solution.

edit flag offensive delete link more

Comments

Thanks for figuring this out. It's good to be aware of this limit with standard NavFn.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-07-14 16:37:35 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2021-06-24 22:43:37 -0500

Seen: 673 times

Last updated: Jul 12 '21