DWA local planner can't find a trajectory unless rotate recovery runs

asked 2022-03-19 05:00:39 -0500

petrik
23 ●4 ●5 ●8

I'm trying to explore a room with my differential drive robot in Gazebo, running ROS Noetic on a Ubuntu 20.04 VM. When I set a 2D nav goal in RViz the global planner finds a path, but the local planner (DWA) cannot find a trajectory. After a while the recovery behaviours run (first the clearing of the cost maps which doesn't help, and then the rotate recovery). After the rotate recovery runs (or even during), the DWA planner generally finds a path and drives the robot to the goal.

The debug log returns the following

[ INFO][1:00:19.385 PM NZST][/move_base]: Got new plan
[DEBUG][1:00:19.385 PM NZST][/move_base]: Nearest waypoint to <-3.054630, 1.505509> is <-3.054631, 1.505509>

[DEBUG][1:00:19.385 PM NZST][/move_base]: Received a transformed plan with 88 points.
[DEBUG][1:00:19.387 PM NZST][/move_base]: Evaluated 0 trajectories, found 0 valid
[DEBUG][1:00:19.388 PM NZST][/move_base]: Cost PointCloud published
[DEBUG][1:00:19.388 PM NZST][/move_base]: The dwa local planner failed to find a valid plan, cost functions discarded all candidates. This can mean there is an obstacle too close to the robot.
[ WARN][1:00:19.388 PM NZST][/move_base]: DWA planner failed to produce path.
[ WARN][1:00:19.483 PM NZST][/move_base]: Clearing both costmaps to unstuck robot (3.00m).
[ INFO][1:00:19.683 PM NZST][/move_base]: Got new plan
[DEBUG][1:00:19.683 PM NZST][/move_base]: Nearest waypoint to <-3.054630, 1.505561> is <-3.054630, 1.505544>

[DEBUG][1:00:19.683 PM NZST][/move_base]: Received a transformed plan with 88 points.
[DEBUG][1:00:19.683 PM NZST][/move_base]: Evaluated 0 trajectories, found 0 valid
[DEBUG][1:00:19.683 PM NZST][/move_base]: Cost PointCloud published
[DEBUG][1:00:19.683 PM NZST][/move_base]: The dwa local planner failed to find a valid plan, cost functions discarded all candidates. This can mean there is an obstacle too close to the robot.
[ WARN][1:00:19.683 PM NZST][/move_base]: DWA planner failed to produce path.
[ WARN][1:00:19.783 PM NZST][/move_base]: Rotate recovery behavior started.
[ INFO][1:00:26.883 PM NZST][/move_base]: Got new plan
[ INFO][1:00:26.983 PM NZST][/move_base]: Got new plan
[DEBUG][1:00:26.983 PM NZST][/move_base]: Nearest waypoint to <-3.052998, 1.496237> is <-3.052971, 1.496269>

[DEBUG][1:00:26.983 PM NZST][/move_base]: Received a transformed plan with 88 points.
[DEBUG][1:00:26.994 PM NZST][/move_base]: Evaluated 1008 trajectories, found 1008 valid
[DEBUG][1:00:26.995 PM NZST][/move_base]: Cost PointCloud published
[DEBUG][1:00:26.996 PM NZST][/move_base]: A valid velocity command of (-0.06, 0.00, 0.91) was found for this cycle.
[ INFO][1:00:27.083 PM NZST][/move_base]: Got new plan
[DEBUG][1:00:27.083 PM NZST][/move_base]: Nearest waypoint to ...

(more)

Comments

Note. I don't have enough rep yet to add pictures. Will upload some once I have enough rep.

petrik ( 2022-03-19 05:01:29 -0500 )edit

I've uploaded a video of the behaviour here: https://www.youtube.com/watch?v=Nt9Xy.... From that video it looks that the DWA planner doesn't "get" the global path until the rotate recovery runs. Not sure why

petrik ( 2022-03-26 05:11:10 -0500 )edit

HI,

I have nearly the same issue as you described above, so I would like to know if you solved it and if you did can you please let me know what was the solution. Thank you in advance.

astef ( 2022-06-15 09:12:41 -0500 )edit

I haven't figured it out yet. I suspect that somewhere in the DWA planner it tries to work with the global plan but fails or it might not even get a valid path or something. I'd have to start looking at the code for the DWA planner and that hasn't been on my priority list yet. At the moment I'm thinking about switching to ROS2 so if the ROS2 DWA planner has the same issue I will have a look at it in more detail.

petrik ( 2022-06-16 00:26:36 -0500 )edit

Okay, thank you for the fast response. I will do some more experimenting with the parameters and in case I find something and solve it I will let you know.

astef ( 2022-06-16 03:54:35 -0500 )edit

add a comment

answered 2022-03-20 00:15:53 -0500

miura

1908 ●1 ●171 ●24 https://twitter.com/miura

From the circumstances, it appears that the local cost map is failing to be created.

I suggest that you try to run the local cost map in rviz while visualizing it. The recovery operation will clear the local cost map. And I think we can observe that the DWA planner runs after it is cleared.

If the cause is determined by the local cost map, I expect that trying the following will help identify the cause.

Activate the local_costmap plugins one by one.
- At first, experiment with static_layer only.
- Next, experiment with static_layer and obstacle_layer.

edit flag offensive delete link

Comments

When you say experiment with the static_layer only, does that mean I have to provide a static map and then use that to drive-to-goal? Or do I keep the 3 layers in the global planner (which seems to work) and only have a static layer in the local planner?

petrik ( 2022-03-20 23:11:10 -0500 )edit

When I display the local costmap in RViz I see the following: https://imgur.com/gallery/12fbYrA. It looks that the local costmap has something on it. Note that the information in the corners is for things that don't exist. They're artefacts of the lidar. The actual obstacles are the walls of the room and they are at least another square further out on all sides of the robot.

petrik ( 2022-03-21 02:27:54 -0500 )edit

Additionally if I disable the rotate-recovery behaviour then the robot doesn't move and eventually the navigation stack gives up. So I don't think clearing the costmap actually fixes the problem. I think the rotate-recovery does something that snaps the robot out of its issue

petrik ( 2022-03-21 02:44:20 -0500 )edit

When you say experiment with the static_layer only, does that mean I have to provide a static map and then use that to drive-to-goal? Or do I keep the 3 layers in the global planner (which seems to work) and only have a static layer in the local planner?

We suggest that the local planner (local cost map) be only a static layer. The global planner seems to be well done.

miura ( 2022-03-21 07:51:18 -0500 )edit

When I display the local costmap in RViz I see the following: https://imgur.com/gallery/12fbYrA. It looks that the local costmap has something on it. Note that the information in the corners is for things that don't exist. They're artefacts of the lidar. The actual obstacles are the walls of the room and they are at least another square further out on all sides of the robot.

The ones out in the corners will be areas that cannot be traveled due to obstructions. For the local planner because it is a local cost map. If something that doesn't exist is being treated as an obstacle, then there could be a problem lurking there.

miura ( 2022-03-21 07:52:03 -0500 )edit

Additionally if I disable the rotate-recovery behaviour then the robot doesn't move and eventually the navigation stack gives up. So I don't think clearing the costmap actually fixes the problem. I think the rotate-recovery does something that snaps the robot out of its issue

Perhaps when you stopped the rotational recovery, you also stopped clearing the cost map. navigation's standard recovery is illustrated below. http://wiki.ros.org/move_base#Expecte...

You may want to try the service clear_costmaps to explicitly clear the cost map.

miura ( 2022-03-21 07:52:32 -0500 )edit

Original comment:

Perhaps when you stopped the rotational recovery, you also stopped clearing the cost map. navigation's 
standard recovery is illustrated below. http://wiki.ros.org/move_base#Expecte...

You may want to try the service clear_costmaps to explicitly clear the cost map.

I don't think so the log seemed to indicate that it cleared the costmap twice and then immediately failed, I think due to time-out. I did notice that when I did a rotate-recovery, before the rotation the local planner didn't seem to know the global plan, while after the rotation it did. I'll see if I can get some pictures of that later today

petrik ( 2022-03-21 15:04:38 -0500 )edit

add a comment

DWA local planner can't find a trajectory unless rotate recovery runs

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

DWA local planner can't find a trajectory unless rotate recovery runs edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

DWA local planner can't find a trajectory unless rotate recovery runs