Robotics StackExchange | Archived questions

DWA doesn't avoid obstacles

Hello,

The dwa with navigation stack does not avoid obstacles. And I am completely stuck. For DWA I even have tried default parameters and the next screenshot was done with default for DWA.

image description

Does anyone have a suggestion? Thank you!

EDIT 1

image description

image description

EDIT 2

image description

image description

Asked by Yehor on 2020-09-10 08:35:56 UTC

Comments

Answers

tuning guide To me this actually looks plausible. In navigation the inflation value needs to be half the base_size plus margin. Collision is usualy calculated from the "center" of base_link (base_frame), not its boarders (green rectangle in picture). As I think I can see in the picture (resolution) the base_link center is actually outside the inflation layer thus this outcome is possible. It seems to use a very high path_distance_bias though. Have a look at the linked tuning guide, this should help getting better results.

Asked by Dragonslayer on 2020-09-10 08:59:46 UTC

Comments

@Dragonslayer I have used default parameters, and I also reduce inflation radius. I have added additional screenshot, could you please check

Asked by Yehor on 2020-09-10 09:04:40 UTC

I would actually increse (double or tripple) the inflation radius and lower path_distance_bias. What movement does the base make, it seems it doesnt go straight on the straight path? Does the base in any way seem to react to the obstacle? The default parameters are for, I think turtlebot, is your robot similar enough, specially size wise?

If its not the tuning then something went wrong in the .yaml or .launch -files.

Asked by Dragonslayer on 2020-09-10 10:17:43 UTC

In the new pictures it would be nice to have costmap color-coding. What came to my mind, if those "pixels" in the air over the obstacle are actually obstacle scans, maybe something with the obstacle height parameters (in obstacle layer params) might be wrong. If the controller thinks the obstacles are above and thus irrelevant, it might try driving under them.

Asked by Dragonslayer on 2020-09-10 12:27:23 UTC

@Dragonslayer Actually I have tried to increase the inflation radius, but the behavior was the same( The base seems to try to avoid the obstacle but very very little and it tries very late. At least it seems that.

My robot is similar to turtlebot, however, anyway I adjust things like speed and size to my robot.

Asked by Yehor on 2020-09-10 13:24:58 UTC

@Dragonslayer I will add a color (costmap style) screenshot tomorrow.

Yes, the pixels are the laser_scan, which I am using for marking and clearing. The reason is why there are higher is that my Lidar is at a height of 20cm from base_footprint. In the obstacle layer parameter, the min_obstacle_height is by default 0 and max_obstacle_height is 2 m. So it should be okay?

I also have a question about cost_scaling_factor for inflation radius, what does it do? Maybe I have an issue with that?

Asked by Yehor on 2020-09-10 13:35:43 UTC

Well, if it tries to avoid we know that dwa does its job, it really all points to parameter tuning now. This can be a very annoying task. I really would suggest using the tuning guide I linked, its the best paper out there in this regard. Iam at the moment not to deep into dwa. But to me it seems the following parameter and its associates path_distance_bias and goal_distance_bias is where I would start experimenting.

**occdist_scale (double, default: 0.01)**
The weighting for how much the controller should attempt to avoid obstacles 

Also "forward_point_distance (double, default: 0.325) " could be a point of interest if your robot is slow. As well raising "sim_time" might help (5.0 for a try).

In the end dwa will produce very short sample trajectories with slow big robots, that might even be smaller then the base itself. It would just not be looking "into the future" long enough to react early.

Asked by Dragonslayer on 2020-09-10 14:59:24 UTC

@Dragonslayer "Well, if it tries to avoid we know that dwa does its job" It seems, but I don't really sure. I will check it again today.

Asked by Yehor on 2020-09-10 15:25:47 UTC

What also has come to my mind. Is this a dynamic obstacle? It seems the global planner doesnt plan arround it as well. Also did you try a bigger obstacle? In the first picture it looks to by tiny, lidar might not every scan catch it, clearing marking clearing marking and so on.

Asked by Dragonslayer on 2020-09-10 16:04:10 UTC

@Dragonslayer It is a dynamic obstacle. This object is absent on the original static map.

What does it mean "scan catch it". I thought if the lidar marking it, it means it found and catch the object.

I want to ask also, what does this parameter means "forward_point_distance"??? Why do we need that?

Asked by Yehor on 2020-09-11 01:16:30 UTC

@Dragonslayer I have added new screenshots with bigger objects. Actually it really tries to avoid the dynamic obstacle but it goes too close to it(

Asked by Yehor on 2020-09-11 02:22:26 UTC

This seems to be a little special case, as it seems path_distance and goal_distance both increase cost when trying to move around the obstacle. However in the tuning guide I linked, "4.2 Inflation" shows how to tune the cost_scaling_factor of the costmap. This should do the trick, if the other parameters dont intervene. Did you experiment with the occdist_scale parameter already?

Asked by Dragonslayer on 2020-09-11 07:51:23 UTC

@Dragonslayer I have created additional topic, where I have also attached the video from robot motion. You can check it here: https://answers.ros.org/question/361386/navigation-stack-dwa-local-planner-crashes-into-dynamic-obstacles/

Yes I was playing with that. Is It correct that this parameter is significantly lower than path and goal distance?

Asked by Yehor on 2020-09-11 08:08:22 UTC

I dont know if "lower" will help. In the end you either have to try or go into the math of the algorithm to find "good values". Give the tuning guide a try.

Asked by Dragonslayer on 2020-09-11 08:13:59 UTC