NavfnPlanner randomly fails for a clearly reachable goal saying "Failed to create a plan from potential when a legal .... found" #4655
Comments
|
Additional info: [planner_server-8] [DEBUG] [1725088039.676608922] [planner_server.rclcpp_action]: Accepted goal 7f8e7e847727a3bebe82e1ea16f1576 |
|
Please provide a reproducable example. You might find https://github.com/botsandus/planner_playground useful to create that example if you fork + add your map and start/goal locations Please also show your costmap + validate that your footprint is valid |
|
Thank you for your kind response @SteveMacenski Here is the robot footprint, seems valid. The cost-map looks like this: Map png file: map yaml file: Issue was reproduced multiple-times for the goal: I have created my fork of planner_playground repo (https://github.com/saad-waqar-robotics/planner_playground_fork) it has my custom map in it. But I could not reproduce the issue on it, because, the planner plans the path successfully, it usually gets the error while moving on the path (during replanning). So I could not reproduce this replanning scenario here on the playground. |
|
I will need a way to reproduce in order to help. There should be no difference in replanning with NavFn, but you could adjust the planner playground to plans 2x in a row if the replan is what causes the issue to be reproducable (should I be wrong about that!). |
|
I am creating a package so you will be able to reproduce the issue. I have tried changing the inflation radius etc, but still the problem persists.
Thanks for the help. |
|
Still need something preproducible. I wonder if this relates to the fact that you have a very low robot radius since you have the pivot point so close to the front of the robot. As you can see, the blue inscribed band around obstacles is incredibly small - and very unusual. It could be that the neighbor expansion in some situations isn't hitting that cell so it by passes it and then causes issues when doing the gradient descent its creating a problem. What happens if you add |
|
Thanks @SteveMacenski. I'll definitely check that and report the results. The pivot point is actually on the rear side of the robot (here in the image we are looking at the rear side, its a rear side differential drive, forward 2 wheels are castor wheels. Here in the image, it was going straight on the path, but when the failure occurred, then it went into recovery behavior and spun towards right side.) THanks! |
|
I checked with footprint padding of 7.5cm. The blue inscribed band definitely increased, but I still got the error around the corners. I tried with robot radius (instead of robot_footprint polygon), then it inflated the inscribed blue band appropriately). (I have my baselink at the center of rotation, so the circle is also on offset but the obstacles are inflated correctly. Although the error is very less frequent which this, but still I saw it once. May be due to this invalid circle position, I will confirm it by fixing the center of the circle.) My question is, isnt costmap supposed to inflate the inscribed region according to robot footprint as well (just like it does with robot_radius)? Thanks a lot. |
|
After setting the circle to the center (by changing robot_base_frame for costmaps to chassis_link {center link in my robot}), the error is very rare. But I still got it 3 times, even in open spaces. Here is my latest .yaml file: amcl: bt_navigator: bt_navigator_navigate_through_poses_rclcpp_node: bt_navigator_navigate_to_pose_rclcpp_node: controller_server: local_costmap: global_costmap: planner_server: smoother_server: behavior_server: robot_state_publisher: waypoint_follower: velocity_smoother: |
Did that not work?
It uses the footprint if given, else the radius. This is very strange. I've never seen this & I've never received a report about this in all the years of working with ROS 1 Navigation and now Nav2. Please provide a reproducable example and I can toy around with it to see what's going on! |
I still get errors (although very less frequently). Thank you for your assistance. I am trying to create a reproducable example, and I'll share that ASAP. |
|
The easiest way to reproduce is to install Ubuntu 24 from scratch and to install ROS Jazzy with Nav2 from the official packages there, then to run turtlebot4 simulation and send Nav2 goals. I think it is safe to say that Nav2 is not in a good shape, very unreliable compared to what ROS1 featured. |
|
@patham9 I'm not sure what makes you say this - but if you had specific advice for @saad-waqar-robotics or information on this ticket to share, we'd love to hear it :-) |
Bug report
Required Info:
Operating System:
UBUNTU 22
ROS2 Version:
Humble
Version or commit hash:
dpkg-query --show "ros-$ROS_DISTRO-navigation2"
ros-humble-navigation2 1.1.16-1jammy.20240824.191514
DDS implementation:
Cyclone
Steps to reproduce issue
Expected behavior
It should successfully complete the navigation.
Actual behavior
Global planning fails randomly on the way while re-planning. At the beginning, it perfectly finds a plan for a clearly reachable goal, starts driving on it, but randomly fails during re-planning saying:
[planner_server]: Failed to create a plan from potential when a legal potential was found. This shouldn't happen.
[planner_server]: GridBased: failed to create plan with tolerance 0.50.
[planner_server]: Planning algorithm GridBased failed to generate a valid path to (-6.30, -2.68)
Additional information
I am using a diff_drive robot with ROS2 Humble, NAV2 & slam_toolbox. Everything seems to be in place.
I am currently simulating the robot in Gazebo classic, House map.
I have started using RegulatedPurePursuit with NavfnPlanner. Usually it works nicely, but randomly I am getting this error from planner:
[planner_server]: Failed to create a plan from potential when a legal potential was found. This shouldn't happen.
[planner_server]: GridBased: failed to create plan with tolerance 0.50.
[planner_server]: Planning algorithm GridBased failed to generate a valid path to (-6.30, -2.68)
This issue comes purely RANDOMLY. It usually does not occur when I send a new goal request. Usually, it takes a goal request, plans the path and starts moving. While moving on its way to a clearly reachable goal, it randomly starts giving this error while re-planning the global path. Due to this error, it falls into recovery mode, sometimes it recovers, sometimes it gives a failure after multiple tries.
I have tried to look on google, I could not find anything helplful.
Please let me know if I am doing something wrong. :) :)
In this screenshot, I was travelling from position 3 to position 1, that is clearly reachable. It started on the path perfectly fine, but in the middle it starting giving this error and fell down to recovery mode.
The text was updated successfully, but these errors were encountered: