# Global planner makes robot drive in circles along U shaped path

Hey,
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.

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.

Marco

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).

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.

(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 ...

edit retag 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.

( 2020-07-29 11:07:10 -0500 )edit

Also depends on the trajectory planner and how its setup.

( 2020-07-29 11:44:00 -0500 )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 :)

( 2020-07-29 12:41:41 -0500 )edit
1

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

No, it isn't.

( 2020-07-29 13:56:15 -0500 )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.

( 2020-07-30 00:58:17 -0500 )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)

( 2020-07-30 09:30:19 -0500 )edit

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

( 2020-07-30 15:38:06 -0500 )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)

( 2020-07-31 01:12:02 -0500 )edit