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

Global planner makes robot drive in circles along U shaped path

asked 2020-07-29 10:26:42 -0600

MarcoStb gravatar image

updated 2020-07-31 01:13:50 -0600

I am using ROS kinetic and followed the navigation stack's tutorial on writing a global path planner. Most of the time its working great but on special occasions its behavior seems kinda odd. The global planner aims to follow a path derived from a tree built by my exploration algorithm. The path is not optimal so far but the focus lies on the robot closely following the edges connecting the tree nodes as they were cleared of 3D obstacles beforehand.

An example path calculated by the global planner can be seen in the image below (green lines show the path, purple arrows the orientation along the path's nodes, the red arrow marks the goal node and the hand-drawn red arrow shows where the robot is moving in a circular pattern. In this example the robot started from the first node on the right and then got stuck in the circle for quite some repititions until it finally (somehow) manages to reach the goal.

Global path and circular robot movement

Now my question: Is the global planner giving out paths which nodes are too far apart or might there be a problem with the orientation of said nodes? Right now all nodes along the path point towards the next node, the goal node points towards the exploration goal. Or is the actual problem the configuration of my local planner (DWA, parameters shown below)? I've played around with some of its parameters (path_distance_bias and goal_distance_bias) but this did not seem to stop the robot from driving in circles.

Thanks in advance,

Edit 2: Since I'm working on a VM and I had my issues recording the screen via video, I made a gif which you can see below. The robot is moving in circles again in another example. Or to be precise, it looks more like an outward spiral. This time you can see the tree structure (blue lines and spheres). The glboal path can still be identified by the purple arrows at the path's nodes (green line is hardly visible).

image description

Edit 3: I've changed 3 parameters and messed around with them for a bit. I think oscillation_reset_dist has no impact on this matter since the robot's behavior did not change on altering the parameter. the parameters path_distance_bias and goal_distance_bias actually led to a different behavior. The higher path_distance_bias was compared to goal_distance_bias the closer the robot followed the path up to the goal. When nearly reaching it, he made a sharp turn for the start as can be seen in the gif below ( with path_distance_bias: 50, goal_distance_bias: 10). The other way around leads to the robot just going from the start straight to the goal and turning around when nearly there.

image description
(Please ignore the red current goal marker here, it remained at the start node and was not set to the goal node. This happens sometimes)

It seems like the path is calculated anew when nearly there but I added console output to the methods and can verify ... (more)

edit retag flag offensive close merge delete


A video would be nice. How accurate is the red circle? Does the robot ever come close to the cost area of the obstacle or does it turn way before? In general the localplanner "drives" the robot the global planner just tells him in what direction. Analog to a car the localplanner is the driver the global planner the navigation system.

Maybe its even the high oscillation_reset_dist that disallows the robot to take the right turn away from the obstacle and forces it left into it, evading even more left. Video would really help here.

Dragonslayer gravatar image Dragonslayer  ( 2020-07-29 11:07:10 -0600 )edit

Also depends on the trajectory planner and how its setup.

stevemacenski gravatar image stevemacenski  ( 2020-07-29 11:44:00 -0600 )edit

@stevemacenski I almost fell for it too. He says he is using dwaplanner, and in the yaml you can see that below the TrajectoryPlannerROS: parameters there is actually a section DWAPlannerROS: with all the parameters. Tricky post, as lots of people will check the Trajecotry planner stuff only :)

Dragonslayer gravatar image Dragonslayer  ( 2020-07-29 12:41:41 -0600 )edit

On a side note, is it possible to add collapsible sections in this forum

No, it isn't.

See ros-infrastructure/ and ASKBOT/askbot-devel#842.

gvdhoorn gravatar image gvdhoorn  ( 2020-07-29 13:56:15 -0600 )edit

@Dragonslayer: I've added a gif, since I haven't found a program able to record the screen without artifacts on my VM. As you can see in the gif, this also happens when there are no obstacles nearby. I'll try to fiddle with the oscillation_reset_dist parameter as well. @gvdhoorn: Shame, but thanks for the info.

MarcoStb gravatar image MarcoStb  ( 2020-07-30 00:58:17 -0600 )edit

Strange, I have to take a closer look later and see if I can get any concret idea what might be going on, but as it seems to "redo" the plan somehow, maybe try link text:

~<name>/prune_plan (bool, default: true)

Defines whether or not to eat up the plan as the robot moves along the path. If set to true, points will fall off the end of the plan once the robot moves 1 meter past them.

I like the high path_distance_bias better as it clearly shows when things start to go wrong. Yes, it seems with the given plan the robot doesn reach the goal and just starts over again. Your idea that "your" global plan is different from dwa´s global plan might be missleading as the wiki states "The PORTION of the global plan that the local planner is currently attempting to follow... " It seems the ...(more)

Dragonslayer gravatar image Dragonslayer  ( 2020-07-30 09:30:19 -0600 )edit

That's a pretty fun bug to have in the scheme of possible bugs!

stevemacenski gravatar image stevemacenski  ( 2020-07-30 15:38:06 -0600 )edit

@Dragonslayer: Unfortunately, I already tried the prune_plan parameter to no avail. When I set it to false, it seems to be causing more problems finding a smooth path.
Yes, you're right. I read that but formulated it a bit unclear in my own words. I feel like it is not importing the next portion from the original plan but repeatedly calling the global planner's plugin method makePlan which in my case returns a new global plan starting at the tree node closest to the robot. In the "bug" case this tree node must be outside the remaining path which leads to the robot running in circles. But on the other hand, when looking at the gifs I posted, the robot seems not to be heading towards the nearest node in the tree.
Anyway, it would help me a lot to get clarity on how local and global planner ...(more)

MarcoStb gravatar image MarcoStb  ( 2020-07-31 01:12:02 -0600 )edit

1 Answer

Sort by » oldest newest most voted

answered 2020-08-20 06:18:13 -0600

MarcoStb gravatar image

updated 2021-03-25 03:27:37 -0600

Edit: I recently stumbled upon this answer and tried it myself. Reducing the rolling window size to around twice/thrice the size of the robot footprint improved the robot movement massively. This was done in addition to the configuration shown below.

So, it seems I somehow fixed the problem (at least I wasn't able to observe the described behavior for a longer simulation run) with a combination of things.

At first I rewrote my global planner so that it remembers the current start and goal nodes and doesn't take the closest node to the robot as a starting point. This alone did not really fix my problem. The robot was still moving in circles sometimes.

Then I played around with the DWA local planner parameters and the below seems to work. Maybe setting "latch_xy_goal_tolerance" to true did the trick but I'm not quite sure. Also I adjusted the simulation parameters according to this guide. Now the robot doesn't stick as close to the path as I'd like it to but at least it reaches the goal.

controller_frequency: 5.0
recovery_behaviour_enabled: true
clearing_rotation_allowed: false
max_planning_retries: 1
planner_patience: 1.0
controller_patience: 5.0
planner_frequency: 0.0
base_global_planner: rrt_nbv_exploration::RneGlobalPlanner
base_local_planner: dwa_local_planner/DWAPlannerROS

  # Robot configuration parameters  
  acc_lim_x: 2.5
  acc_lim_y: 0
  acc_lim_th: 3.2

  max_vel_x: 0.5
  min_vel_x: 0.0
  max_vel_y: 0
  min_vel_y: 0

  max_trans_vel: 0.5
  min_trans_vel: 0.1
  max_rot_vel: 1.0
  min_rot_vel: 0.2

  # Goal Tolerance Parameters
  yaw_goal_tolerance: 0.2
  xy_goal_tolerance: 0.2
  latch_xy_goal_tolerance: true

  prune_plan: true

  # # Forward Simulation Parameters
  sim_time: 4.0
  # sim_granularity: 0.02
  vx_samples: 20
  # vy_samples: 0
  vtheta_samples: 40
  # penalize_negative_x: true

  # # Trajectory scoring parameters
  path_distance_bias: 20.0 # The weighting for how much the controller should stay close to the path it was given
  goal_distance_bias: 1.0 # The weighting for how much the controller should attempt to reach its local goal, also controls speed
  occdist_scale: 0.02 # The weighting for how much the controller should attempt to avoid obstacles
edit flag offensive delete link more



Thanks for the update. That tuning guide saved a lot of people.

Dragonslayer gravatar image Dragonslayer  ( 2020-08-20 07:50:59 -0600 )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



Asked: 2020-07-29 10:26:42 -0600

Seen: 769 times

Last updated: Sep 02 '21