ros-navigation / navigation2

ROS 2 Navigation Framework and System
https://nav2.org/
Other
2.5k stars 1.26k forks source link

Planner Server Crash When Using ThetaStarPlanner Near Map Edges #4694

Open JeisonUR opened 4 days ago

JeisonUR commented 4 days ago

Hello I am launching nav2 on a small test map, with the default configuration; the only change is that I am using the ThetaStarPlanner. When using the action to try to navigate to points near the edge of the map, the planner server is crashing.

Bug report

Required Info:

Steps to reproduce issue

planner_server:
  ros__parameters:
    expected_planner_frequency: 20.0
    use_sim_time: False
    planner_plugins: ["GridBased", "LongFootprint"]
    GridBased:
      plugin: "nav2_theta_star_planner/ThetaStarPlanner"
      how_many_corners: 8
      w_euc_cost: 1.0
      w_traversal_cost: 2.0
      w_heuristic_cost: 1.0
ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose "{pose: {header: {frame_id: "map"}, pose: {position: {x: -5.69, y: 3.72}} }}"

Expected behavior

#### Actual behavior

planner server crash

[bt_navigator-7] [INFO] [1727370008.710462882] [gary.nav.nav2.bt_navigator]: Begin navigating from current location (-1.77, 0.34) to (-5.69, 3.72) [LAUNCH ERROR] [planner_server-5.launch]: process has died [pid 1631378, exit code -11, cmd '/opt/ros/humble/lib/nav2_planner/planner_server --ros-args -r __node:=planner_server -r __ns:=/gary/nav/nav2 --params-file /tmp/tmp4k0ocqsj -r /tf:=/tf -r /tf_static:=/tf_static -r /gary/nav/nav2/cmd_vel:=/gary/wheels/cmd_vel -r /gary/nav/nav2/odom:=/gary/odom/odom'].


#### Additional information

[map.txt](https://github.com/user-attachments/files/17155358/map.txt)

![map](https://github.com/user-attachments/assets/e473980a-15ce-48a1-8708-143d0e5a4847)
SteveMacenski commented 4 days ago

The map you uploaded is corrupted and I can't view it. Could that be related? Please fork https://github.com/botsandus/planner_playground and add your map + start/goal/map as a reproducible example with your configurations - then comment back once you have a reproducable example. Please also provide an image of the map/start/goal that creates this issue so I can see how close to the edge "close" means.

This is a weird error to see - is there something odd about your install or configuration of your computer? Does this occur using the global_costmap's default parameter / footprint set? Curious if this relates to your specific robot config as well.

./include/nav2_costmap_2d/costmap_2d.hpp: No such file or directory.

This isn't exactly an "I'm out of bounds" or other normal crash. This seems like a compilation issue. Does this work for other non-edge requests?

brayanpa commented 4 days ago

Hi Steve, sorry for the misunderstanding. We missed the initial part of the error message. The error referring to the missing costmap_2d.hpp is because gdb can't find the file during debugging, but that doesn't affect the library execution. The original error is a segmentation fault. We just updated the original issue to add the missing part of the error (first lines).

We have forked the planner_playground repo and have been able to replicate the error there. Here is our fork:

https://github.com/brayanpa/planner_playground

We launch it with:

ros2 launch planner_playground test_planner.launch.py

and set the start and goal points as:

ros2 topic pub --once /goal_pose geometry_msgs/msg/PoseStamped "{header: { frame_id: map}, pose: {position: {x: 1.22, y: -3.81}}}"
ros2 topic pub --once /goal_pose geometry_msgs/msg/PoseStamped "{header: { frame_id: map}, pose: {position: {x: -6.1, y: -4.67}}}"

As a result, the planner_server crashed again.

[lifecycle_manager-7] [INFO] [1727387190.917720018] [lifecycle_manager_navigation]: Managed nodes are active
[rviz2-9] [INFO] [1727387191.152310412] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-9] [INFO] [1727387191.152396343] [rviz2]: OpenGl version: 4.6 (GLSL 4.6)
[rviz2-9] [INFO] [1727387191.172072072] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-9] [INFO] [1727387191.271659887] [rviz2]: Trying to create a map of size 483 x 627 using 1 swatches
[rviz2-9] [INFO] [1727387192.100608204] [rviz2]: Trying to create a map of size 483 x 627 using 1 swatches
[planner_server-6] [WARN] [1727387208.421591443] [planner_server]: No planners specified in action call. Server will use only plugin GridBased  in server. This warning will appear once.
[ERROR] [planner_server-6]: process has died [pid 146773, exit code -11, cmd '/opt/ros/humble/lib/nav2_planner/planner_server --ros-args --log-level info --ros-args -r __node:=planner_server -p use_sim_time:=False --params-file /home/brayanur/nav2_tools/install/planner_playground/share/planner_playground/config/planner_server.yaml --params-file /home/brayanur/nav2_tools/install/planner_playground/share/planner_playground/config/global_costmap.yaml --params-file /home/brayanur/nav2_tools/install/planner_playground/share/planner_playground/config/global_costmap_test.yaml --params-file /home/brayanur/nav2_tools/install/planner_playground/share/planner_playground/config/costmaps_plugins.yaml --params-file /tmp/launch_params_ci5du8el -r /map:=/map_amcl'].

The same can be replicated by setting a goal in rviz outside of the map size.

image

SteveMacenski commented 4 days ago

Is the case that you were describing near the edge doing footprint collision checking where part of the footprint is outside of the costmap bounds? Or when you say "close" you mean just over the edge for point-checks that are done when using robot_radius rather than footprint

It seems like that may be the case, in which case we can do a check in the collision checker in Theta such that we reject plans off the map. We do this in other planning algorithms but perhaps we don't check the return value on worldToMap in Theta to handle it.

SteveMacenski commented 4 days ago

Ah, I see that we do check the worldToMap in main https://github.com/ros-navigation/navigation2/blob/main/nav2_theta_star_planner/src/theta_star_planner.cpp#L120-L126 but not in Humble's branch. Likely the PR that added that was not backward compatible with Humble so it wasn't backported. The throw is handled by Iron and newer when we added the contextual error codes for when algorithms fail.

I suppose we could just return an empty path in this case for humble and this condition should handle that situation properly

What do you think? (I didn't test your case yet, just looking into this from your descriptions, this seems like a very plausible explanation)

brayanpa commented 3 days ago

Reviewing the situation described at the beginning of the issue, the goal was slightly outside the map—by 1 pixel, to be exact. It seems that goals within the map are being handled correctly, even when part of the footprint extends beyond the map.

In our case, receiving an empty path would be sufficient to handle the situation.

SteveMacenski commented 3 days ago

Great! Can you open a PR to add in the worldToMap check on the output and return an empty path if that check fails - targeting the humble branch? Please also test that this resolves your issue completely :-)