ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Can I modify portion of the global plan in TrajectoryPlannerROS?

asked 2012-03-07 22:39:42 -0500

Kai Bublitz gravatar image

updated 2014-01-28 17:11:36 -0500

ngrennan gravatar image

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: 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 ...
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2012-03-08 02:45:54 -0500

DimitriProsser gravatar image

updated 2012-03-08 06:09:43 -0500

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.

edit flag offensive delete link more


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

Kai Bublitz gravatar image Kai Bublitz  ( 2012-03-08 04:54:26 -0500 )edit

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.

Kai Bublitz gravatar image Kai Bublitz  ( 2012-03-08 10:20:37 -0500 )edit

so, did you solve your problem?

Gazer gravatar image Gazer  ( 2013-06-17 14:04:20 -0500 )edit

answered 2012-03-11 05:04:28 -0500

Kai Bublitz gravatar image

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.

edit flag offensive delete link more



I don't understand your answer. But I am encountering the similiar problem, that the local plan is not following the global plan.

Gazer gravatar image Gazer  ( 2013-06-17 14:05:55 -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

1 follower


Asked: 2012-03-07 22:39:42 -0500

Seen: 2,324 times

Last updated: Mar 11 '12