Rosanswers logo

Hi there,

I would like to know if it is possible to change the length of the "portion of the global plan that the local planner is currently attempting to follow" as stated in the wiki for the published topic.

The wiki says for goal_distance_bias parameter: "The weighting for how much the controller should attempt to reach its local goal". I assume the local goal is the end of the portion of the local plan, is that correct?

I want to use the TrajectoryPlannerROS plugin in move_base to follow a global path, but the robot tends to drive towards walls and get stuck, when driving around corners. I think I could improve the performance if I the portion of the global plan was shorter, because the robot would not try to take shortcuts that lead into walls. Basically I want the robot to follow the path more closely, however I don't want to increase the path_distance_bias because higher path_distance_bias means the robot can't avoid obstacles on the path then. I'm not sure what impact the local path length has to navigation, but I think it's worth trying.

So can I somehow influence the length of the current portion of the path? If it's possible how would I do this? Of course I surely can get the source code and make a new planner, but I don't want to this if it can be avoided.

Thanks in advance for anything that might help me improve the local planner behavior.

UPDATE1: Perhaps I could improve the behavior of the local planner by changing some other parameters, but I can't get it to work reliably. The footprint matches the actual robot plus some extra space for movement of the kinect and some padding. I don't think further increasing the footprint will help me. I tried different settings for the local costmap, but it did not help either. When I use high cost values around the obstacles the robot has problems going through doors. The idea behind my idea was , that it seems pretty useless scoring a local trajectory by "heading towards goal" if the goal is in a different room. I have an image of rviz: imagebam.com http://thumbnails46.imagebam.com/17875/e103d8178747299.jpg As you can see, the robot is heading toward the wall, where the goal is behind. If I could dynamically change the length of the plan portion, I could perhaps make the planner head towards the door. Though I'm not sure if this really works. I noticed I can improve the planner's behavior by increasing the sim_time parameter (to about 10 sec), but it does not work in every situation.

Here is a parameter dump of the relevant parameters:

TrajectoryPlannerROS: {acc_lim_th: 1, acc_lim_theta: 1.0, acc_lim_x: 1.0, acc_lim_y: 0.0,
  angular_sim_granularity: 0.025, controller_frequency: 20, dwa: true, escape_reset_dist: 0.1,
  escape_reset_theta: 1.57079632679, escape_vel: -0.1, gdist_scale: 0.8, global_frame_id: odom,
  goal_distance_bias: 0.8, heading_soring: false, holonomic_robot: false, latch_xy_goal_tolerance: true, max_rotational_vel: 0.3,
  max_vel_theta: 1.0, max_vel_x: 0.3, min_in_place_rotational_vel: 0.05, min_in_place_vel_theta: 0.4,
  min_vel_theta: 0.0, min_vel_x: 0.05, occdist_scale: 0.05, oscillation_reset_dist: 0.02,
  path_distance_bias: 0.6, pdist_scale: 0.6, publish_cost_grid_pc: true, restore_defaults: false,
  sim_granularity: 0.025, sim_time: 3.0, simple_attractor: false, vtheta_samples: 20,
  vx_samples: 20, xy_goal_tolerance: 0.1, y_vels: '-0.3,-0.1,0.1,-0.3', yaw_goal_tolerance: 0.1}
aggressive_reset: {reset_distance: 1.84}
base_global_planner: navfn/NavfnROS
base_local_planner: base_local_planner/TrajectoryPlannerROS
clearing_rotation_allowed: true
conservative_reset: {reset_distance: 3.0}
conservative_reset_dist: 3.0
controller_frequency: 20.0
controller_patience: 5.0
  cost_scaling_factor: 4.0
  footprint: '[[0.217,0.33],[-0.325,0.33],[-0.325,0.25],[-0.53,0.13],[-0.53,-0.13],[-0.325,-0.25],[-0.325,-0.33],[-0.0936,-0.33],[-0.0936,-0.51],[0.397,-0.51],[0.397,-0.079],[0.31,0.083],[0.217,0.083]]'
  footprint_padding: 0.03
  global_frame: map
  height: 10
  inflation_radius: 0.65
  kinect: {clearing: true, data_type: PointCloud, marking: true, min_obstacle_height: 0.1,
    obstacle_range: 2.5, raytrace_range: 3.0, sensor_frame: kinect_link, topic: kinect/cloud}
  laser_scan_sensor: {clearing: true, data_type: LaserScan, marking: true, sensor_frame: base_scan_link,
    topic: base_scan/scan}
  lethal_cost_threshold: 100
  map_topic: map
  map_type: voxel
  mark_threshold: 0
  max_obstacle_height: 1.8
  max_obstacle_range: 2.5
  observation_sources: laser_scan_sensor kinect
  obstacle_range: 9.5
  origin_x: 0.0
  origin_y: 0.0
  origin_z: 0.0
  publish_frequency: 2.0
  publish_voxel_map: true
  raytrace_range: 9.5
  resolution: 0.05
  restore_defaults: false
  robot_base_frame: base_footprint
  robot_radius: 0.46
  rolling_window: true
  static_map: false
  track_unknown_space: true
  transform_tolerance: 0.3
  unknown_cost_value: 0
  unknown_threshold: 15
  update_frequency: 5.0
  width: 10
  z_resolution: 0.2
  z_voxels: 10
oscillation_distance: 0.5
oscillation_timeout: 0.0
planner_frequency: 0.0
planner_patience: 5.0
recovery_behavior_enabled: true
restore_defaults: false
shutdown_costmaps: false

Originally posted by Kai Bublitz on ROS Answers with karma: 357 on 2012-03-07

Post score: 1


2 Answers 2


Rosanswers logo

I know this may not directly answer your question, but I would recommend first tuning your robot_footprint and inflation_radius parameters. By increasing the robot's footprint to the correct size, it will automatically cause the robot to leave more space around obstacles (the corner) and could potentially solve your problem without having to modify base_local_planner. See costmap_2d for descriptions on the robot_footprint and see this question for information regarding the inflation radius.

To actually answer your question, you cannot modify the local path without intercepting it in move_base. The move_base node is responsible for passing the plan from the global planner to the local planner. You'd have to modify the move_base source code if you want to add this functionality. Could it be done? Yes. Is it the best way? I'm not so sure.


From your parameter dump, I've noticed that your path_distance_bias is set to 0.0. This means that the local planner (in theory) won't care about the path generated by the global planner, and will head directly toward the goal as directly as possible. You need to give some path bias to tell the robot to value the plan in order to move out of the room.

Originally posted by DimitriProsser with karma: 11163 on 2012-03-08

This answer was ACCEPTED on the original site

Post score: 4

Original comments

Comment by Kai Bublitz on 2012-03-08:
Thanks for your answer. I updated my question to add some more information. I already spent a lot of time optimizing the footprint and inflation parameters, but I can't find a working configuration. I don't really want to modify move_base, but if there I can't better way I guess I'll give it a try

Comment by Kai Bublitz on 2012-03-08:
my path_distance_bias is usually set to 0.6. I just had it set to 0 in the launch file to test something, but I used the reconfigure_gui to set it (that's pdist_scale) back to 0.6. I corrected that in my question now.

Comment by Gazer on 2013-06-17:
so, did you solve your problem?


Rosanswers logo

DimitriProsser's answer is basically correct, I just wanted to add some additional information.

It seems the length of the portion of the global plan that move_base passes to the local planner depends on the size of the local costmap. After doing some more research on the way the TrajectoryPlannerROS is working I found out that the goal distance is not calculated through obstacles. It's more like grid cell steps in non-obstacle-cells. This leads to the conclusion, that my approach of shortening the plan is mostly useless.

However I was able to dynamically shorten the path inside the local planner, it is not necessary to modify move_base. In combination with an approach I call adaptive sim_time I think the navigation works better now. I'm still working on my modified planner, so I can't yet tell if it really improves the planner or it is just in my special case.

Originally posted by Kai Bublitz with karma: 357 on 2012-03-11

This answer was NOT ACCEPTED on the original site

Post score: 2

Original comments

Comment by Gazer on 2013-06-17:
I don't understand your answer. But I am encountering the similiar problem, that the local plan is not following the global plan.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.