Revision history [back]

The Solution (TL;DR)

In the parameters for the /move_base node, set: planner_frequency = 0.0

Setting heading_scoring = true in the parameters for base_local_planner also helps as it makes the robot turn corners tighter.

The Solution (full explanation)

I haven't found the real cause of the problem, I haven't figured out what changed between when I started and now. What I have done is found a work-around. I'll try to re-state the key issue and the solution as best as I can because the original question above is too big and horrible to read now.

Currently, the /move_base has a parameter called planner_frequency, this dictates the rate at which the global planner with re-plot a path. The ROS default is 0.0, but the default in the Clearpath files that I'm using is 20 Hz (this file specifically). With reference to this heavily exaggerated illustration, this is essentially the problem:

In travelling from A to B, the robot is obviously experiencing some drift (for whatever reason), so its just not travelling straight. But when it gets off the original path (bold green), rather than getting back on it, the global path is simply re-plotted (skinny green). Eventually the robot will get close enough to the goal that the local planner and controller will overrule the source of the drift. Hence the robot follows the dashed, light blue path from A to B.

The simple solution is to set planner_frequency = 0.0, that way "the global planner will only run when a new goal is received or the local planner reports that its path is blocked" This means that the global path never changes between goals, so the local planner rarely deviates from it. This means that instead of this:

You get this:

Not perfect, but a hell of a lot better and good enough for now. In addition, the local path planner can be a little too generous with its turning arcs, so I suggest setting heading_scoring = true in the parameters for base_local_planner (assuming that is the local planner you are using of course). This forces the planner to score trajectories based on angles rather than distance, and overall gives you tighter turns.

If I happen to stumble across the real cause of the drift, or if I figure out anything else that improves the trajectory, I'll update this again. Thanks again to everyone who helped.

The Solution (TL;DR)

In the parameters for the /move_base node, set: planner_frequency = 0.0

Setting heading_scoring = true in the parameters for base_local_planner also helps as it makes the robot turn corners tighter.

The Solution (full explanation)

I haven't found the real cause of the problem, I haven't figured out what changed between when I started and now. What I have done is found a work-around. I'll try to re-state the key issue and the solution as best as I can because the original question above is too big and horrible to read now.

Currently, the /move_base node has a parameter called planner_frequency, this dictates the rate at which the global planner with will re-plot a the global path. The ROS default is 0.0, but the default in the Clearpath files that I'm using is 20 Hz (this file specifically). With reference to this heavily exaggerated illustration, this is essentially the problem:

In travelling from A to B, the robot is obviously experiencing some drift (for whatever reason), so its just not travelling straight. But when it gets off the original path (bold green), rather than getting back on it, the global path is simply re-plotted (skinny green). Eventually the robot will get close enough to the goal that the local planner and controller will overrule the source of the drift. Hence the robot follows the dashed, light blue path from A to B.

The simple solution is to set planner_frequency = 0.0, that way "the global planner will only run when a new goal is received or the local planner reports that its path is blocked" This means that the global path never changes between goals, so the local planner rarely deviates from it. This means that instead of this:

You get this:

Not perfect, but a hell of a lot better and good enough for now. In addition, the local path planner can be a little too generous with its turning arcs, so I suggest setting heading_scoring = true in the parameters for base_local_planner (assuming that is the local planner you are using of course). This forces the planner to score trajectories based on angles rather than distance, and overall gives you tighter turns.

If I happen to stumble across the real cause of the drift, or if I figure out anything else that improves the trajectory, I'll update this again. Thanks again to everyone who helped.

The Solution (TL;DR)

In the parameters for the /move_base node, set: planner_frequency = 0.0

Setting heading_scoring = true in the parameters for base_local_planner also helps as it makes the robot turn corners tighter.

The Solution (full explanation)

I haven't found the real cause of the problem, I haven't figured out what changed between when I started and now. What I have done is found a work-around. I'll try to re-state the key issue and the solution as best as I can because the original question above is too big and horrible to read now.

Currently, the /move_base node has a parameter called planner_frequency, this dictates the rate at which the global planner will re-plot the global path. The ROS default is 0.0, but the default in the Clearpath files that I'm using is 20 Hz (this file specifically). With reference to this heavily exaggerated illustration, this is essentially the problem:

In travelling from A to B, the robot is obviously experiencing some drift (for whatever reason), so its just not travelling straight. But when it gets off the original path (bold green), rather than getting back on it, the global path is simply re-plotted (skinny green). green) starting from where the robot currently is. Eventually the robot will get close enough to the goal that the local planner and controller will overrule the source of the drift. Hence the robot follows the dashed, light blue path from A to B. B instead of following a straight line between both points.

The simple solution is to set planner_frequency = 0.0, that way "the global planner will only run when a new goal is received or the local planner reports that its path is blocked" This means that the global path never changes between goals, so the local planner rarely deviates from it. This means that instead of this:

You get this:

Not perfect, but a hell of a lot better and good enough for now. In addition, the local path planner can be a little too generous with its turning arcs, so I suggest setting heading_scoring = true in the parameters for base_local_planner (assuming that is the local planner you are using of course). This forces the planner to score trajectories based on angles rather than distance, and overall gives you tighter turns.

If I happen to stumble across the real cause of the drift, or if I figure out anything else that improves the trajectory, I'll update this again. Thanks again to everyone who helped.

The Solution (TL;DR)

In the parameters for the /move_base node, set: planner_frequency = 0.0

Setting heading_scoring = true in the parameters for base_local_planner also helps as it makes the robot turn corners tighter.

The Solution (full explanation)

I haven't found the real cause of the problem, I haven't figured out what changed between when I started and now. What I have done is found a work-around. I'll try to re-state the key issue and the solution as best as I can because the original question above is too big and horrible to read now.

Currently, the /move_base node has a parameter called planner_frequency, this dictates the rate at which the global planner will re-plot the global path. The ROS default is 0.0, but the default in the Clearpath files that I'm using is 20 Hz (this file specifically). With reference to this heavily exaggerated illustration, this is essentially the problem:

In travelling from A to B, the robot is obviously experiencing some drift (for whatever reason), so its just not travelling straight. But when it gets off the original path (bold green), rather than getting back on it, the global path is simply re-plotted (skinny green) starting from where the robot currently is. Eventually the robot will get close enough to the goal that the local planner and controller will overrule the source of the drift. Hence the robot follows the dashed, light blue path from A to B instead of following a straight line between both points.

The simple solution is to set planner_frequency = 0.0, that way "the global planner will only run when a new goal is received or the local planner reports that its path is blocked" This means that the global path never changes between goals, so the local planner rarely deviates from it. This means that instead of this:

You get this:

Not perfect, but a hell of a lot better and good enough for now. In addition, the local path planner can be a little too generous with its turning arcs, so I suggest setting heading_scoring = true in the parameters for base_local_planner (assuming that is the local planner you are using of course). This forces the planner to score trajectories based on angles rather than distance, and overall gives you tighter turns.

For reference, on a Clearpath Jackal, the planner_frequency parameter is found at the following filepath: /opt/ros/indigo/share/jackal_nagivation/params/move_base_params.yaml

If I happen to stumble across the real cause of the drift, or if I figure out anything else that improves the trajectory, I'll update this again. Thanks again to everyone who helped.