Path planned through unmapped region for goal present inside map.

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

spiritninja
48 ●15 ●21 ●22

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.

Edit:

image description

edit retag flag offensive close merge delete

add a comment

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

jordan
125 ●3 ●15 ●12 http://rhoeby.com

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:

https://answers.ros.org/question/2155...

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

Comments

@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 ( 2019-12-05 05:20:27 -0500 )edit

Check this...

https://answers.ros.org/question/2155...

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 ( 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.

https://answers.ros.org/question/1982...

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

obstacle_layer:
    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 ( 2019-12-06 00:16:57 -0500 )edit

Please attach the entire modified 'costmap_common_params.yaml'.

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