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

Path planned through unmapped region for goal present inside map.

asked 2019-11-26 06:20:23 -0500

spiritninja gravatar image

updated 2019-12-05 05:25:02 -0500

could someone explain why sometines the global path planned by the robot for navigation ventures into the unmapped region? Images of the path planned to the goal are attached below. The planned path is in green. global path planned in unmapped region with goal point near by to robot's location

global path planned in unmapped region for a goal point far away from the robot

Through normal understanding, the global planner plans the shortest path in the mapped region and wouldn't traverse the unmapped region even if the goal point appears much closer through this.

Is there a way to correct this apart from editing the map?

Global planner : NavfnROS

Local planner : TrajectoryPlannerROS

OS: Ubuntu 14.04. ROS: Indigo.

Thank you.


image description

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2019-11-26 08:03:16 -0500

jordan gravatar image

updated 2019-12-05 09:28:49 -0500

Make sure you have set in navfn_global_planner_params.yaml:

allow_unknown: false          #Specifies whether or not to allow navfn to create plans that   traverse unknown space, default true

I have observed that sometimes the first plan (after setting a goal) can still be wrong, but then it gets updated by the next plan (which is correct). If the planner frequency is high enough, then the robot does not have a chance to do anything undesirable.

Also, from:

Are you using a layered costmap from costmap_2d with an obstacle or voxel layer? If so you have to set the param track_unknown_space for that layer to true, otherwise it's converting your map's unknown space into free space (which navfn then correctly goes quite happily through).

So, make sure you have also set in costmap_common_params.yaml:

  track_unknown_space:  true    #true needed for disabling global path planning through unknown space
edit flag offensive delete link more


@jordan Yeah you're right about the parameter. In-fact i had taken care of that earlier by changing the default value that's True to False. But the problem still persists and that is waht intrigued me. The presence of allow_unknown: false is to prevent the planner in planning into unknown regions.

So, if planing into unknown regions still persists, what else could influsence it? Also waht value of planner frequency do you think is generally good? I've tried with 0.0 and few values moderately greater than that.

Edited the question with another image of the wrong planning happening.

spiritninja gravatar image spiritninja  ( 2019-12-05 05:20:27 -0500 )edit

Check this...

The above may solve your issue.

Robots around here use: planner_frequency: 1.0 (in move_base_params.yaml), which seems to be a reasonable balance between keeping the plan updated with respect to incoming data vs. CPU loading.

jordan gravatar image jordan  ( 2019-12-05 09:19:55 -0500 )edit

Exactly. This is what I was trying out the other day after checking about the global planner Here on the Wiki page.

The above discussion is the one I was referring.

The robot costmap_common_params.yaml is as follows

obstacle range: 2.5
raytrace_range: 3.0

footprint: [[0.35, -0.3], [0.35, 0.3], [-0.35, 0.3], [-0.35, 0.3]]
inflation_raduis: 0.05

    observation_sources: hokuyo_laser
    hokuyo_laser: {sensor_frame: hokuyo_laser_link, data_type: LaserScan, topic: /hokuyo_base/scan, marking: true, clearing: true}

So, as the track_unknown_space parameter wasn't present earlier, i thought adding it under the obstacle layer would suffice. But it didn't change anything.

@jordan any suggestion on this? I appreciate the help provided.

spiritninja gravatar image spiritninja  ( 2019-12-06 00:16:57 -0500 )edit

Please attach the entire modified 'costmap_common_params.yaml'.

jordan gravatar image jordan  ( 2019-12-09 09:37:56 -0500 )edit

@spiritninja did you find the solution, I faced the same problem, even change allow_unknown or tracking_unknown_space

drtritm gravatar image drtritm  ( 2021-02-17 20:35:19 -0500 )edit

I was also frustrated with this issue. For future reference see

li9i gravatar image li9i  ( 2021-07-23 05:26:54 -0500 )edit

Question Tools

1 follower


Asked: 2019-11-26 06:20:23 -0500

Seen: 502 times

Last updated: Dec 05 '19