Behavior of global_planner seems unreasonable

[zkytony]

Here is the situation in the above picture. The robot is between a sofa and a wall, and it is facing upwards. I am setting a goal in the bigger room (right part of the map), and global_planner fails to produce a path. The visualization of global_planner's potential shows that it didn't even search in the big room.

Here are two videos (Link to video1, Link to video2) that demonstrates this problem. In these videos, the global_planner just seems to fail with no reason - why would it not search in some area of the map?

What led to this behavior, i.e. graph search doesn't cover the region involving the goal? How do we correct it?

I will definitely investigate as well. But if anyone have any idea, we can discuss here.

Some info: use_dijlstra is set to true (default).

Thanks!

[zkytony]

How to explain this "hole"? It looks like the shape of the robot's footprint, but I don't see any source code related to footprint in global_planner.

I read the source code in planner_core.cpp, dijkstra.cpp and quadratic_calculator.cpp. Planning will fail if calculatePotentials return false, which happens when 1) both current and next priority blocks are empty 2) we hit start cell and we have looped a lot of times more than expected (or we have just looped a lot of times more than expected). In other words, if we hit start cell when expanding in a shorter amount of time, then we claim that there is a path found.

if when the planner claims "Fail to find a path", not all of the map is searched, then I think that there should still be some priority buffer left, but there have been too many cycles. How come?

Can someone provide any insight to this? I am confused.

[zkytony]

Another confusing global_planner behavior that I observed is: sometimes it successfully finds a path, but since I set planner_frequency to 2.0, the planner will replan as the robot moves, and such replanning may fail despite previous success.

If I set planner_frequency to 0.0, the global planner won't replan dynamically unless global planner or local planner failed (Documentation: http://wiki.ros.org/move_base) This isn't often desirable because the furniture arrangement/human activity may be diifferent, and it's better to replan ahead rather than replan only when local planner fails to produce a path.

What's your idea on solving this problem?

[tappan-at-git]

This might be a more appropriate topic for answers.ros.org, since it involves digging into the specifics of your setup. I would post your question there with as much detail as you can about the launch files and parameters you're using. The issues board isn't ideal since the people tracking it are probably busy, and may not have the time to dig into your problem.

[zkytony]

I posted a question on ROS Ask several days ago: http://answers.ros.org/question/247908/global_planner-fails-to-find-a-plan-it-doesnt-search-certain-regions-on-the-map/

If you have a moment, please take a look! Thanks!

[asimay]

I think the "hole" is not too important if your robot drive around it and can clear it. the "grid" is very small compared to your visual map. maybe something too small you cannot see occupied the grid, so the inflation is strange sometimes. If it can clear, it's nothing.

[zkytony]

@asimay Thanks for the attention. The problem is that with the holes present, global planner fails to make a plan, even when there is an obvious path.

But time has went by, and I was able to work around this by having an FSM that executes additional recovery behaviors, which may bring the robot to somewhere that a global plan can be made. I also have ways to set a series of closer goals.

[mikeferguson]

Link to videos has gone dead.

[zkytony]

@mikeferguson Sorry for the late reply. I have uploaded one of those videos to Youtube: https://youtu.be/_mvyDoMls2U

In this video, the global_planner appears to not able to make a plan to the upper-left room.