| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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.
Does anyone have a suggestion? Thank you!
EDIT 1
EDIT 2
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.
@Dragonslayer I have used default parameters, and I also reduce inflation radius. I have added additional screenshot, could you please check
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.
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.
@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.
@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?
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 ...
@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.
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: 2020-09-10 08:35:56 -0500
Seen: 9,718 times
Last updated: Sep 11 '20
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.