Closed GiantSeaweed closed 1 year ago
Please display the local costmap's footprint in another gif and zoom in on it (I don't care about the global costmap or its footprint or the TF frames, disable those so we can see clearly)
I assume you didn't disable DWB's obstacle critics - did you do any retuning of configurations of the controller?
Something doesn't seem right here in the first place - why is the planner going straight through an obstacle? What planner are you using? This vaguely reminds me of a synchronization issue with costmap clearing we resolved years ago. Given you're on Foxy, I suspect that may be the cause. If you upgrade to Humble or newer, does that work? You may need to compile from source and make a few superficial API updates from foxy->humble codebase changes, but it shouldn't take long.
Usually I'd close with "foxy's not supported" but collisions shouldn't be happening and I want to make sure this isn't still an issue in a modern version.
I disable the global costmap and TF and keep the local costmap. I did not do any retuning of controller configs, just the config in foxy-devel
branch. And I attach a new video here.
You can see at 3s, the robot successfully finished the previous navigation task and stopped quite close to the obstacle (within the light blue region).
Then, seven seconds later, I set the goal at 10s. Then the trajectory seems to have overlap with obstacle and the collision happened.
As for the planner, the console shows the info like Planning algorithm GridBased failed to generate a valid path to xxx
.
https://github.com/ros-planning/navigation2/assets/28821472/f1cf6f0f-37fe-4ef5-8f8f-4ca1a92e3ddf
I haven't try Humble source build yet, could you give me a pointer on how to make API updates from foxy->humble? Thanks!
I asked to see the footprint in rviz, I don't see any footprint at all. That may be part of your issue unless you didn't enable it.
I see the pipeline
That aligns with the bug that we resolved long ago w.r.t. costmap clearing mechanics and threading issues, I believe. Try a modern ROS 2 distribution and it very well likely is gone. We didn't backport to Foxy because it was either EOL at the time or the change required substantial reworks that wouldn't be ABI/API compatible (probably this). We've long, long ago abandoned Foxy in Nav2, even before it officially turned EOL because of the new changes that weren't backward compatible. You can try also using Docker with the Humble image and install Nav2 from binaries in the docker image (will be much faster than building) and running in the image. That may be faster.
Else, if you want to compile locally, start building and working through API issues. I can't tell you much more than that without doing it myself.
Thanks for your response! I found you said this issue is a wont-fix problem for Foxy at here https://github.com/ros-planning/navigation2/issues/2452. I will try on Humble.
I just attached a video with local costmap's footprint here. I changed the Fixed Frame in Rviz from map
to odom
, as instructed by here. I think it confirms your speculation.
https://github.com/ros-planning/navigation2/assets/28821472/40d01ad3-0d7b-4dea-873a-8e65fbe71e5a
OK! Closing then with found solution
Bug report
Required Info:
ca482808a7a7c52ce01ae3c662dc2b980968fc16
<!-- from source: output of `git -C navigation2 rev-parse HEAD apt binaries: output of: dpkg-query --show "ros-$ROS_DISTRO-navigation2" or: dpkg-query --show "ros-$ROS_DISTRO-nav2-*" -->Steps to reproduce issue
I kept every configuration of
foxy-devel
branch.Step1. Launch the nodes and simulation.
(Terminal 1) Started turtlebot3_world with:
ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py
(Terminal 2) Start slam_toolbox async mode:
ros2 launch slam_toolbox online_async_launch.py
(Terminal 3) Start nav2 navigation:
ros2 launch nav2_bringup navigation_launch.py
(Terminal 4) Start rviz2:
ros2 launch nav2_bringup rviz_launch.py
Step2. I found when the robot is faced with an obstacle in front direction and the destination is set behind the obstacle, the robot cannot successfully navigate around the obstacle to reach the goal. I attached the Terminal 3 console log and video below.
Expected behavior
The robot may spin to a direction with more free room ahead and bypass the obstacle.
Actual behavior
The robot just got stuck, could not follow the planned path, leading to a failed navigation task.
I am not sure if it is related to configuration problems. I can understand that if the tolerance is too narrow the robot cannot bypass the obstacle to reach the goal. But I am confused why it collides into the obstacle. Thanks!!
https://github.com/ros-planning/navigation2/assets/28821472/e3a1a6e1-2100-4ea0-aaa5-171e82c5608d