Navigation with gazebo doesn't work when using gz-harmonic branch on latest Jazzy - navigation.yaml issues

[PaulBouchier]

Summary: this issue provides documentation for a proposal to update navigation.yaml to the latest nav2 version.

I have updated/upgraded Ubuntu 24.04.2, including nav2 packages, to the latest

Evidence that gz-harmonic branch DOES work correctly with latest nav2_params.yaml:

• Copy the latest nav2_params.yaml to the config directory: cp /opt/ros/jazzy/share/nav2_bringup/params/nav2_params.yaml linorobot2_navigation/config/
• Modify linorobot2_navigation/launch/navigation.launch.py according to this diff:

@@ -45,7 +45,7 @@ def generate_launch_description():
     )
 
     nav2_sim_config_path = PathJoinSubstitution(
-        [FindPackageShare('linorobot2_navigation'), 'config', 'navigation_sim.yaml']
+        [FindPackageShare('linorobot2_navigation'), 'config', 'nav2_params.yaml']
     )

• colcon build
• start gazebo with: ros2 launch linorobot2_gazebo gazebo.launch.py
• start nav with: ros2 launch linorobot2_navigation navigation.launch.py sim:=true
• start rviz with: ros2 launch linorobot2_viz navigation.launch.py
• Observe no errors in the navigation.launch.py output
• Set the initial pose. Observe Navigation Status in rviz reports Navigation: active, Localization: active
• set a Nav Goal in rviz. Observe that the robot navigates to the desired location

Evidence that gz-harmonic branch DOES NOT work correctly with navigation.yaml from HEAD of gz-harmonic branch

• Restore navigation.launch.py to top of tree
• colcon build
• start gazebo as above: ros2 launch linorobot2_gazebo gazebo.launch.py
• start nav as above: ros2 launch linorobot2_navigation navigation.launch.py sim:=true

Problem 1

• Observe this fatal error in the navigation.launch.py window, and Navigation status in rviz is "inactive":

[component_container_isolated-1] [FATAL] [1748608168.819873061] [planner_server]: Failed to create global planner. Exception: According to the loaded plugin descriptions the class nav2_navfn_planner/NavfnPlanner with base class type nav2_core::GlobalPlanner does not exist. Declared types are  nav2_navfn_planner::NavfnPlanner nav2_smac_planner::SmacPlanner2D nav2_smac_planner::SmacPlannerHybrid nav2_smac_planner::SmacPlannerLattice nav2_theta_star_planner::ThetaStarPlanner

This error is caused by an error in navigation_sim.yaml as shown in the diff below - there is a '/' where there should be '::'. This problem is in navigation.yaml also, and I had to fix it in the hippo5329 fork of this repo as well.

@@ -353,7 +353,7 @@ planner_server:
     use_sim_time: false
     planner_plugins: ["GridBased"]
     GridBased:
-      plugin: "nav2_navfn_planner/NavfnPlanner"
+      plugin: "nav2_navfn_planner::NavfnPlanner"
       tolerance: 0.5

Problem 2

• Fix the problem by editing navigation.yaml to make it say: plugin: "nav2_navfn_planner::NavfnPlanner"
• colcon build after fixing the typo above
• start gazebo and nav as above
• Observe this error - bringup was aborted:

[component_container_isolated-1] [ERROR] [1748609171.632515818] [collision_monitor]: Error while getting parameters: parameter 'observation_sources' is not initialized
[component_container_isolated-1] [INFO] [1748609171.632593681] [collision_monitor]: Cleaning up
[component_container_isolated-1] [ERROR] [1748609171.664149785] [lifecycle_manager_navigation]: Failed to change state for node: collision_monitor
[component_container_isolated-1] [ERROR] [1748609171.664210638] [lifecycle_manager_navigation]: Failed to bring up all requested nodes. Aborting bringup.

This problem is caused by not having a collision_monitor: section in navigation.yaml

Problem 3

• Fix problem 2 by editing navigation.yaml and adding the collision_monitor: section from nav2_params.yaml
• colcon build afterward
• start gazebo and nav as above
• Observe this error - bringup was aborted:

[component_container_isolated-1] [INFO] [1748624212.345919902] [bt_navigator]: Configuring
[component_container_isolated-1] [INFO] [1748624212.356749252] [bt_navigator]: Creating navigator id navigate_to_pose of type nav2_bt_navigator::NavigateToPoseNavigator
[component_container_isolated-1] [WARN] [1748624212.364044133] [bt_navigator]: Error_code parameters were not set. Using default values of: follow_path_error_code compute_path_error_code
[component_container_isolated-1] Make sure these match your BT and there are not other sources of error codes youreported to your application
[component_container_isolated-1] [FATAL] [1748624212.491183706] [bt_navigator]: Failed to create navigator id navigate_to_pose. Exception: ID [ComputePathToPose] already registered
[component_container_isolated-1] [INFO] [1748624212.491261611] [bt_navigator]: Cleaning up
[component_container_isolated-1] [INFO] [1748624212.555558148] [bt_navigator]: Completed Cleaning up
[component_container_isolated-1] [ERROR] [1748624212.556182568] [lifecycle_manager_navigation]: Failed to change state for node: bt_navigator
[component_container_isolated-1] [ERROR] [1748624212.556260197] [lifecycle_manager_navigation]: Failed to bring up all requested nodes. Aborting bringup.

I can't readily determine the cause of this error.

Underlying issue

The root cause of these issues, which caused the gz-harmonic branch to apparently work at some time but is now broken, is the release strategy used by the nav2 team. They have been releasing backports of all kinds of features from their rolling branch into jazzy. You can see from the git commit history below that they have done 4 jazzy sync releases since Dec 13 2024. Several of these changed nav2_params.yaml.

Complicating matters is that navigation_sim.yaml seems to be based on humble, so there's no saying what's obsolete and what's missing.

Proposed Resolution

I think the best path forward is to take the current nav2 stack file nav2_params.yaml and port it to navigation.yaml by using it with as few changes as are deemed important. IOW start over from fresh with navigation.yaml and make changes from there.

Two changes I think are worth bringing in are the linorobot 2wd or 4wd parameters (size, max speed, etc), and the Follow_path module. The default path follower in the nav2 stack is plugin: "nav2_mppi_controller::MPPIController", which acts a bit like an ackermann vehicle. The current linorobot2 path follower is plugin: "nav2_rotation_shim_controller::RotationShimController, with its set of parameters (which are probably from humble). I think we should keep the RotationShimController but update its parameters for nav2 on jazzy per AutomaticAddison recommendation, or nav2 documentation, because my friend at DPRG who made it work says it drives more sensibly for a differential drive robot. (I tried but couldn't make it work on my minniebot HW, but he did on his robot.)

PR Proposal

I will submit a PR referencing this issue that should make the linorobot2 rolling branch run simulation on jazzy again. Please comment on this issue if you have any issues with this proposed plan.

[PaulBouchier]

@grassjelly I can't fork this repo in github because I already have a fork of @hippo5329 repo. However, I would like to make this repo work with gazebo again ASAP. Therefore I have emailed you an update of navigation_sim.yaml to this ticket. (Github won't let me attach a yaml file to this issue.) Can you please apply this change to the rolling branch and let me know when its merged (you can close the issue when its done, if you want).

I tagged you in an issue on Thomas Chou's fork of your repo, in which I outline a plan for fixing the divergence between this and his repos. Feel free to comment on it.

Let me know if you have any issues with this approach to getting this repo working with gazebo on jazzy ASAP.

[hippo5329]

@PaulBouchier I always hope to sync to upstream and avoid diversity. I am very happy to have your help. I will rename my branch to simply "hippo".

Thanks a lot.

[hippo5329]

I have renamed my hippo5329/rolling to hippo. It should be frozen for the moment. I will send PR later to sync my work upstream.

Out of thread: I would suggest we follow the coding style of ROS and trim tailing white-spaces. In my earlier works on Linux kernel and u-boot, we have strict coding style that everyone follows. It is important to collaboration.

Cheers.

[hippo5329]

https://docs.ros.org/en/rolling/The-ROS2-Project/Contributing/Code-Style-Language-Versions.html

[hippo5329]

Another OT: I would suggest use "rebase" instead of "merge" to merge the PRs. So that the extra "merge commit" can be reduced and linear commits will be easier to follow.

[PaulBouchier]

@grassjelly please comment on the recommendation to follow the ROS coding style, and also to use rebase instead of merge. I have worked on projects where a style guide was mandated, and where rebase was used instead of merge, and I'm OK with Thomas' proposals.

[PaulBouchier]

Fixed with PR #159