Global path not changing despite newly discovered obstacle

asked 2013-05-06 23:13:06 -0500

Ernest
341 ●13 ●20 ●28 http://oppetit.me/

Hi,

I'm using move_base to generate paths based on a map & odom generated by hector_mapping. The below rviz screenshot sums up my problem quite well: essentially as the new (middle) obstacle appeared in my LiDAR's view, the global path (in green) doesn't update. It seems properly inflated (blue).

So what happens is that move_base keeps going onto the global path until it arrives too close to the obstacle, and then it backs up (recovery mode).

Any ideas why my global path isn't changing?

My yamls:

   global_costmap:

  global_frame: /map
  robot_base_frame: /base_link 
  update_frequency: 1.0

  static_map: false
  rolling_window: true

  width: 26
  height: 26
  resolution: 0.025

  map_type: costmap


local_costmap:
  global_frame: /odom
  robot_base_frame: /base_link 
  update_frequency: 1.5
  publish_frequency: 1.5
  static_map: false
  rolling_window: true
  width: 20.0 
  height: 20.0 
  resolution: 0.05

  map_type: costmap

edit retag flag offensive close merge delete

add a comment

1

answered 2013-05-08 10:07:43 -0500

Ernest
341 ●13 ●20 ●28 http://oppetit.me/

I was able to fix this problem by setting a smaller path_distance_bias for my base_local_planner. Now move_base veers away from this "wrong" global path & creates a new better global path.

path_distance_bias: 0.15 # weighting for how much the controller should stay close to the path it was given

edit flag offensive delete link

add a comment

2

answered 2013-05-08 14:43:47 -0500

piyushk
2861 ●31 ●49 ●76 http://cs.utexas.edu/~piyushk

updated 2013-05-08 15:55:33 -0500

@Ernest: I am not sure if the solution you have provided will work in every case. Here's my take on it.

Take a look at the planner_frequency parameter at http://www.ros.org/wiki/move_base I believe your navigation instance is not re-planning as the local_planner is not giving up control despite the obstacle.

On a differential drive robot, it can sometimes get difficult to balance the path and goal bias parameters to produce good behavior in all cases (in this particular instance you have found a solution by tweaking these parameters). An easier solution is to set planner_frequency to something other than 0, which forces replanning giving the local_planner a plan with a better chance of success.

edit flag offensive delete link

Comments

Hi, thanks a lot for your response, it made me discover a bunch of useful params that I had left as defaults! I've tried setting controller_frequency to non-zero values but my global path isn't recomputed - it still goes through the obstacle. I suppose it's not a big deal if the local planner avoids

Ernest ( 2013-05-08 15:47:51 -0500 )edit

the obstacle successfully. Can you think of particular situations in which this "hack" would not work? Thanks again

Ernest ( 2013-05-08 15:48:23 -0500 )edit

@Ernest: I can't remember, and I use a different local planner these days. You should try changing the planner_frequency instead of controller_frequency.

piyushk ( 2013-05-08 15:56:58 -0500 )edit

Oops yes I meant planner_frequency. I've changed it and I still have the same global paths..

Ernest ( 2013-05-08 16:03:36 -0500 )edit

hi dear Ernest , i have exactly the same problem . is your problem solved ? , if yes , how can i force the trajectory planner to generate dynamic paths when an obstacle comes in front of robot ... ?! if any body have any idea its my pleasure to hear them .