Ask Your Question

NO PATH ! error and questions to gradient_path.cpp in global_planner

asked 2015-10-14 07:21:51 -0600

maomao2015 gravatar image

    Problem Description:

I am trying to get a global path based on a 500 * 500 static map with global_planner (indigo). I set up the parameter use_grid_path to be false, so that the path is calculated with a gradient descent method. Goal Pose is fed with the 2D Nav Goal in Rviz. Sometime it works fine by showing the global path. But sometimes it publishes rosconsole [Error] messages repetitively in the terminal, even if a potential map is successfully showed by Rviz.

[ERROR] [1444812100.339654309, 6406.380000000]: NO PATH!
[ERROR] [1444812100.340210027, 6406.380000000]: Failed to get a plan from potential when a legal potential was found. This shouldn't happen.
[ERROR] [1444812100.364187125, 6406.410000000]: NO PATH!
[ERROR] [1444812100.364835403, 6406.410000000]: Failed to get a plan from potential when a legal potential was found. This shouldn't happen.

I dug a little bit into the code in gradient_path.cpp I think it must failed at row 80 to get this kind of error message.

00080     while (c++ < ns*4) { 

But my static map is not big, and I have already got the potential map. So I do not really understand what is going on here.

    Question to the code in gradient_path.cpp


    This part comes from function float GradientPath::gradCell(float* potential, int n). In my opinion, the potential from cells on the left, right, up and down side should be taken into account. But at line 285, it is a fixed cell. Why should man always take care at this fixed cell?
00276     // check for in an obstacle
00277     if (cv >= POT_HIGH) {
00278         if (potential[n - 1] < POT_HIGH)
00279             dx = -lethal_cost_;
00280         else if (potential[n + 1] < POT_HIGH)
00281             dx = lethal_cost_;00282 
00283         if (potential[n - xs_] < POT_HIGH)
00284             dy = -lethal_cost_;
00285         else if (potential[xs_ + 1] < POT_HIGH)
00286             dy = lethal_cost_;
00287     } 


    Why do we take stc, stc + 1, stcnx and stcnx + 1 but not other neighbors for interpolation?

00181             // get grad at four positions near cell
00182             gradCell(potential, stc);
00183             gradCell(potential, stc + 1);
00184             gradCell(potential, stcnx);
00185             gradCell(potential, stcnx + 1);
00187             // get interpolated gradient
00188             float x1 = (1.0 - dx) * gradx_[stc] + dx * gradx_[stc + 1];
00189             float x2 = (1.0 - dx) * gradx_[stcnx] + dx * gradx_[stcnx + 1];
00190             float x = (1.0 - dy) * x1 + dy * x2; // interpolated x
00191             float y1 = (1.0 - dx) * grady_[stc] + dx * grady_[stc + 1];
00192             float y2 = (1.0 - dx) * grady_[stcnx] + dx * grady_[stcnx + 1];
00193             float y = (1.0 - dy) * y1 + dy * y2; // interpolated y


    Why do we only consider these two horizontal bounds, why not the vertical bounds?
00091         if (stc < xs_ || stc > xs_ * ys_ - xs_) // would be out of bounds
00092         {
00093             printf("[PathCalc] Out of bounds\n");
00094             return false;
00095         }

These questions troubled me a lot. Please help ~~

Thanks in advance :-)

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2016-02-17 11:31:27 -0600

palmlster gravatar image

I am having the same kind of error.

One solution could be to increase the constant distance values in here from 0.5 to 1.0 .

I think this is due to missing potential values on cells around the start of the path, see this picture image description

The white space under the axes represents cells to which no potential was assigned. Sometimes the cell (nx,ny) is far more than 0.5 (m?) from start cell in here, therefore the path extraction will return false (exit from the while loop).

What do you think?



edit flag offensive delete link more


Replacing 0.5 with 1 seems to work; it actually refers to cells number.

jorge gravatar image jorge  ( 2018-10-19 08:21:51 -0600 )edit

it works for me too, thank very much!!!

jinseoi gravatar image jinseoi  ( 2019-01-26 05:31:36 -0600 )edit

answered 2015-11-01 11:26:15 -0600

David Lu gravatar image

These are valid points. As you may know, global_planner is based off of nav_fn, and as a result, some of the bugs propagated forward.

1) This is a valid point. This error came from nav_fn. Both should be n+nx (as is on line 1029). A pull request with this for indigo and jade would be most welcome.

2) The current x position lies somewhere between stc%nx and (stc%nx)+1. Therefore we want to compute the gradient between stc and stc+1. Similarly in the y direction. Thus we get the four cells which make up the immediate neighborhood of the current position.

3) I think the answer has something to do with the row-order nature of the costmap, but I'm not certain.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2015-10-14 05:48:58 -0600

Seen: 1,791 times

Last updated: Nov 01 '15