sometimes the local trajectory will cross the wall in stage and will abort finally.

[asimay]

hi, dear @croesmann , i test your local planner with stage, and find sometimes the local trajectory will cross the wall in stage, and in terminal it shows "TebLocalPlannerROS: trajectory is not feasible. Resetting planner..." and will abort finally. please see below:

my parameter config is:

[asimay]

and i have another question want to consult you: why the globalplanner 's path is so nearby the wall? Is it a bug? I have already set the global param.

and I adjust the weight_obstacle to 100, it is still cross the wall in stage and abort. weight_obstacle: 100

please help me. Thanks!

[croesmann]

Thanks for reporting this issue. I was able to reproduce the behavior, but only by setting the inflation radius of the global costmap's inflation radius to zero (this also addresses your second question).

After testing, I found out that the feasibility check failed due to the absence of any trajectory candidate. The planner was rejecting even the "main" trajectory candidate in a few lines of code that I implemented a long time ago without being aware of it right now ;-). The rejection was caused due to the infeasible location of the virtual/local goal (without any inflation layer, the global planner does not take the robot's size into account!). I removed the corresponding part of the code. However, the infeasible goal placed on that location might also introduce some other undesired effects (the robot could decide to choose the wrong hallway in order to reach it and get stuck as well. But before I have time to investigate that, please resolve this issue by adding an inflation layer.

Without any inflation layer the global planner is only aware of lethal obstacles (refer to this description). Add the layer to your global costmap. A radius of about 0.5-1.0 meters for your robot should be fine. For an example configuration, you might inspect the teb_local_planner_tutorials configuration files.

[asimay]

hi, dear @croesmann , glad to get your reply. Yes. of course, I set the inflation layer to a small value because the defalt maze.png has narrow corridor about 1m. and in costmap config file, default robot wide is 0.25, robot_radius is 0.46, inflation_radius is 0.5, so the robot cannot go through the corridor. so I set: robot_radius: 0.01 inflation_radius: 0.05 robot wide is 0.25, to let the robot go through the narrow corridor..

[asimay]

hi, dear @croesmann , I verify the inflation_radius , it is really has big relation with the global path produce. I set inflation_radius: 0.5, and modify the map's narrow corridor a little bigger, and get good result.

[asimay]

It acts very good. better than dwa local planner. but when it turns around, and in narrow place, it got a little stuck, it will back up the far away to the corner, and then turned around and to the destination. if this can be solved, it is perfect!

[asimay]

Another scenario to reflect: in some cases, like below screenshot, it will report no path error, but the robot is moving back actually, and finally arrived at goal. I think in this case, we can "tolerant" it , so it shouldn't print the error info. it is better for customer's view.

[croesmann]

In general, the inflation layer must not be reduced in case of narrow corridors. The inflation layer adds non-zero costs for areas close to walls that should be avoided if possible. However, the planner can still navigate through inflated regions as long as the robot does not collide. Even with a value of 1m, I am able to follow narrow corridors. But setting the value to 0.05 ignores the robot footprint as well such that the global plan might not be feasible.

Note, the planner currently assumes that the corridor's width is larger than the robot's length to allow the robot to rotate (by combining forward and backwards motions). There exist a narrow corridor in the maze map which does not fulfill this assumption (in the bottom-center of the map). However, I with the default confiugration in the teb_local_planner_tutorials package I was able to perfectly turn around in all other corridors (even in the scenarios/corners you mentioned).

Regarding your error messages from the previous comment: I will investigate this soon, but these messages are not generated directly from the teb_local_planner source.