Ask Your Question
0

Global path not changing despite newly discovered obstacle

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

Ernest gravatar image

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

2 Answers

Sort by ยป oldest newest most voted
1

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

Ernest gravatar image

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 more
2

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

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 more

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 gravatar image 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 gravatar image 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 gravatar image 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 gravatar image 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 .

edwin gravatar image edwin  ( 2014-05-25 10:18:30 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

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

Seen: 1,038 times

Last updated: May 08 '13