Humble main compilation

[coderwyvern]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	(add tickets here #4998)
Primary OS tested on	(Ubuntu)
Robotic platform tested on	(Nav2 minimal tb4 sim, yet to test on real robot)
Does this PR contain AI generated software?	(No; Yes and it is marked inline in the code)

---

IMPORTANT To see the actual changes clearly that I made to compile main on humble, we will need to merge #5108 first. This branch's parent is the branch in #5108. The changes are on top of that.

Description of testing performed

Ran the navigate to pose action using the nav2 minimal tb4 sim. It worked fine.
No failing functional system tests other than the one my mate reported in #5111
Will test on the real robot on Monday.

Description of contribution in a few bullet points

Description of documentation updates required from your changes

Does not fix anything in tools, .github/workflows for "humble". So that is still pending. I am not sure how to go about doing this and what is actually necessary.

Description of how this change was tested

---

Future work that may be required in bullet points

For Maintainers:

• Check that any new parameters added are updated in docs.nav2.org
• Check that any significant change is added to the migration guide
• Check that any new features OR changes to existing behaviors are reflected in the tuning guide
• Check that any new functions have Doxygen added
• Check that any new features have test coverage
• Check that any new plugins is added to the plugins page
• If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

[mergify]

@coderwyvern, all pull requests must be targeted towards the main development branch.
Once merged into main, it is possible to backport to @humble_main, but it must be in main
to have these changes reflected into new distributions.

[SteveMacenski]

@coderwyvern please rebase so I can see the changes now that your other PR is merged

[coderwyvern]

@coderwyvern please rebase so I can see the changes now that your other PR is merged

Done! Please let me know in case of any issues.

[SteveMacenski]

Small changes, but generally looks good. Why is this so much more concise than #5017? It seems like there aren't packages that have their cmakelists updated for the older cmake style -- do all these other packages compile properly?

Does colcon test pass & run all the nav2_bringup launch files?

[coderwyvern]

@SteveMacenski I've pushed the changes addressing your comments.

I think it is much more concise because the linting stuff is separated.
Also, I faced linking errors only with yaml-cpp and tf2_geometry_msgs. yaml-cpp was resolved when I linked to yaml-cpp and not yaml-cpp::yaml-cpp. For tf2_geometry_msgs, I had to use ament_target_dependencies. I have not looked deeply why this is happening, but it's able to link and build.

All colcon tests pass (provided we use ros2/launch#864) except for nav2_bringup because it's not able to find a copyright notice and the test reported here fails #5111 (sometimes).

I tested again using the nav2_loopback_sim and it works well. All launch files run successfully except for cloned_multi_tb3_simulation_launch.py and localization_launch.py. I will fix it.

[coderwyvern]

I have fixed the issues with cloned_multi_tb3_simulation_launch.py by reverting the changes done here #5000.

However, I have an issue with localization_launch.py. If I do ros2 launch nav2_bringup localization_launch.py map:=map_path it works fine. If I don't give the map parameter in the command line, I get the following error

[map_server-1] [ERROR] [1746093687.465956618] [map_server]: Original error: parameter 'yaml_filename' is not initialized
[map_server-1] [WARN] [1746093687.465967662] [map_server]: Error occurred while doing error handling.
[map_server-1] [FATAL] [1746093687.465973959] [map_server]: Lifecycle node map_server does not have error state implemented
[lifecycle_manager-3] [ERROR] [1746093687.466128966] [lifecycle_manager_localization]: Failed to change state for node: map_server
[lifecycle_manager-3] [ERROR] [1746093687.466143229] [lifecycle_manager_localization]: Failed to bring up all requested nodes. Aborting bringup.

I get the same error when I try to launch this on the main branch as well. I think it makes sense because localisation only mode cannot run without a map. What is the expected behaviour if map param is not provided?

[SteveMacenski]

The map is a required input. If you check in the nav2_bringup packages, we always provide the map and the simulation world to use in the higher level TB3/4 launch files that are propagated down in the launch hierarchy. If none is provided at launch time, that's actually fine, but then the parameter YAML file must then contain the map in yaml_filename for the map server to initialize. By default, we don't set it in the yaml file since there is no logical default for a map, so it is given from the launch tree.

Did you test using the GZ simulator? Humble uses Gazebo Classic and main uses modern Gazebo, I just want to make sure those sims work in Humble with Ignition-Gazebo which I think had different namespaces for its plugins, settings, etc with ign instead of gz.

By the way, I'm not able to build this properly on Humble. I get the following errors locally:

In file included from /home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp:15:
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/include/nav2_lifecycle_manager/lifecycle_manager_client.hpp:111:51: error: ‘SharedPtr’ in ‘class nav2_util::ServiceClient<nav2_msgs::srv::ManageLifecycleNodes>’ does not name a type
  111 |   nav2_util::ServiceClient<ManageLifecycleNodes>::SharedPtr manager_client_;
      |                                                   ^~~~~~~~~
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/include/nav2_lifecycle_manager/lifecycle_manager_client.hpp:112:53: error: ‘SharedPtr’ in ‘class nav2_util::ServiceClient<std_srvs::srv::Trigger>’ does not name a type
  112 |   nav2_util::ServiceClient<std_srvs::srv::Trigger>::SharedPtr is_active_client_;
      |                                                     ^~~~~~~~~
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp: In constructor ‘nav2_lifecycle_manager::LifecycleManagerClient::LifecycleManagerClient(const string&, std::shared_ptr<rclcpp::Node>)’:
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp:39:3: error: ‘manager_client_’ was not declared in this scope
   39 |   manager_client_ = std::make_shared<nav2_util::ServiceClient<ManageLifecycleNodes>>(
      |   ^~~~~~~~~~~~~~~
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp:41:3: error: ‘is_active_client_’ was not declared in this scope; did you mean ‘rcl_action_client_t’?
   41 |   is_active_client_ = std::make_shared<nav2_util::ServiceClient<std_srvs::srv::Trigger>>(
      |   ^~~~~~~~~~~~~~~~~
      |   rcl_action_client_t
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp: In member function ‘nav2_lifecycle_manager::SystemStatus nav2_lifecycle_manager::LifecycleManagerClient::is_active(std::chrono::nanoseconds)’:
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp:97:8: error: ‘is_active_client_’ was not declared in this scope; did you mean ‘rcl_action_client_t’?
   97 |   if (!is_active_client_->wait_for_service(std::chrono::seconds(1))) {
      |        ^~~~~~~~~~~~~~~~~
      |        rcl_action_client_t
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp:106:16: error: ‘is_active_client_’ was not declared in this scope; did you mean ‘rcl_action_client_t’?
  106 |     response = is_active_client_->invoke(request, timeout);
      |                ^~~~~~~~~~~~~~~~~
      |                rcl_action_client_t
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp: In member function ‘bool nav2_lifecycle_manager::LifecycleManagerClient::callService(uint8_t, std::chrono::nanoseconds)’:
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp:128:11: error: ‘manager_client_’ was not declared in this scope
  128 |   while (!manager_client_->wait_for_service(timeout)) {
      |           ^~~~~~~~~~~~~~~
/home/steve/Documents/humble_ws/src/navigation2/nav2_lifecycle_manager/src/lifecycle_manager_client.cpp:140:26: error: ‘manager_client_’ was not declared in this scope
  140 |     auto future_result = manager_client_->invoke(request, timeout);

[coderwyvern]

The map is a required input. If you check in the nav2_bringup packages, we always provide the map and the simulation world to use in the higher level TB3/4 launch files that are propagated down in the launch hierarchy. If none is provided at launch time, that's actually fine, but then the parameter YAML file must then contain the map in yaml_filename for the map server to initialize. By default, we don't set it in the yaml file since there is no logical default for a map, so it is given from the launch tree.

Understood, thanks.

Did you test using the GZ simulator? Humble uses Gazebo Classic and main uses modern Gazebo, I just want to make sure those sims work in Humble with Ignition-Gazebo which I think had different namespaces for its plugins, settings, etc with ign instead of gz.

Yes, I tested it using the modern gazebo. In my test env, I had gazebo harmonic installed and it worked fine. However, I need to make sure that this is also true in case of a fresh install since rosdep in that case might install fortress. Thanks for pointing it out. I will try out a fresh install on a clean image and see if that works. If not, I will make the changes to revert to gazebo classic. Will get back to you on this

By the way, I'm not able to build this properly on Humble. I get the following errors locally:

I think I had got similar errors too. When I tried to rebuild on a clean docker without ANY nav2 package preinstalled in /opt/ros, the build passed. Please let me know if it works...

[coderwyvern]

Hello,

I built the whole thing on a clean docker image and your error got reproduced. I think it is because of slam toolbox being installed via rosdep. This installs some of the current nav2 packages through apt. During colcon build, it picks up the nav2 packages inside of opt/ros for some reason instead of the ones in the current works space.

When I remove the packages manually using sudo apt remove ros-humble-nav2* and then rebuild the entire stack, it builds properly.

Here is the Dockerfile I used.

FROM osrf/ros:humble-desktop-full

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y \
    git \
    python3-colcon-common-extensions

WORKDIR /workspaces/nav2_ws/src

RUN apt-get update
RUN apt update --fix-missing
RUN apt-get upgrade -y

RUN rm -rf /etc/ros/rosdep/sources.list.d/20-default.list
RUN . /opt/ros/$ROS_DISTRO/setup.sh
RUN apt-get install python3-rosdep -y
RUN rosdep init
RUN rosdep update

RUN echo "Cloning modules...."
RUN git clone https://github.com/coderwyvern/navigation2 -b humble_main_compilation
RUN git clone https://github.com/ros-navigation/nav2_minimal_turtlebot_simulation
RUN git clone https://github.com/ros2/common_interfaces -b humble
RUN git clone https://github.com/suchetanrs/launch -b humble

WORKDIR /workspaces/nav2_ws
RUN rosdep update
RUN rosdep install --from-paths src --ignore-src -r -y

RUN sudo apt remove ros-humble-nav2* -y

RUN . /opt/ros/humble/setup.sh && \
    colcon build --symlink-install --parallel-workers 3

Line 31 in this Dockerfile is responsible for the successful build.

docker-compose.yaml I used is below:

version: "3"
services:
  humble_nav2_docker:
    image: humble_nav2_docker
    container_name: humble_nav2_docker
    volumes:
      #full dev
      - /dev:/dev:rw
      #full media
      - /media:/media:rw
      #Time
      - /etc/timezone:/etc/timezone:rw
      - /etc/localtime:/etc/localtime:rw
      - /tmp/.X11-unix:/tmp/.X11-unix:rw
    privileged: true
    network_mode: host
    ipc: host
    pid: host
    stdin_open: true
    tty: true
    environment:
      - DISPLAY
      - TERM
      - QT_X11_NO_MITSHM=1
    entrypoint: /bin/bash

---

Regarding the gazebo issues, I have changed everything from gz, sim to ign, gazebo and tested it using the dockerfile shared above. The tb3 / tb4 simulations work fine!

However, this requires nav2_minimal_turtlebot_simulation to be installed and rosdep can't resolve it. Is it better to release nav2_minimal_turtlebot_simulation package for humble? Or do something else?

Please let me know if the above Dockerfile works for you or if there are any further issues.

[SteveMacenski]

Any issues with the behavior tree cpp version? I thought humble was still on v3 and we use v4 for jazzy/rolling and newer. I think we may want to use behaviortree_cpp_v4 instead?

I'm building in a osrf/ros:humble-desktop-full docker container to see how it works in isolation now. I had to do that removal for slam toolbox. FYI: you may want to set that up as as skip-key in rosdep install rather than removing them after the fact.

However, this requires nav2_minimal_turtlebot_simulation to be installed and rosdep can't resolve it. Is it better to release nav2_minimal_turtlebot_simulation package for humble? Or do something else?

We can use the main version, this is supposed to be a version of Humble that is aligned with main, so I think that's OK. I don't want to release a humble version since I think that would confuse things since that wouldn't actually be used by humble, but rather this humble-main. If there's no changes needed in the main version to support humble-main with GZ vs IGN, then they can both be used.

I setup CI for humble if you pull in the latest for Humble so that CI should be able to turn over theoretically for this branch if everything works.

[SteveMacenski]

So I got it to build, but I'm seeing alot of test failures when I do colcon test and colcon test-result --verbose. I don't care about linting issues, but it looks like real tests are failing - which I think might be largely due to the simulation problems? One example:

    [tester_node-18] [INFO] [1746582337.463704303] [nav2_waypoint_tester]: Sending goal request...
    [waypoint_follower-13] [INFO] [1746582337.464876922] [waypoint_follower]: Action server is inactive. Rejecting the goal.
    [tester_node-18] [ERROR] [1746582337.466337487] [nav2_waypoint_tester]: Goal rejected
    [tester_node-18] Traceback (most recent call last):
    [tester_node-18]   File "/root/hi_ws/src/navigation2/nav2_system_tests/src/waypoint_follower/tester.py", line 281, in <module>
    [tester_node-18]     main()
    [tester_node-18]   File "/root/hi_ws/src/navigation2/nav2_system_tests/src/waypoint_follower/tester.py", line 223, in main
    [tester_node-18]     assert result
    [tester_node-18] AssertionError
    [ERROR] [tester_node-18]: process has died [pid 80668, exit code 1, cmd '/root/hi_ws/src/navigation2/nav2_system_tests/src/waypoint_follower/tester.py'].

It looks like the system never fully initialized due to missing transforms from the simulator, I expect that the sim isn't working and maybe more needs to be updated to IGN or the files need more updating than previously suggested.

I think its more that the system tests didn't have IGN update:

      File "/root/hi_ws/install/launch/lib/python3.10/site-packages/launch/actions/execute_local.py", line 546, in __execute_process
        transport, self._subprocess_protocol = await async_execute_process(
      File "/opt/ros/humble/lib/python3.10/site-packages/osrf_pycommon/process_utils/async_execute_process_asyncio/impl.py", line 139, in async_execute_process
        transport, protocol = await _async_execute_process_nopty(
      File "/opt/ros/humble/lib/python3.10/site-packages/osrf_pycommon/process_utils/async_execute_process_asyncio/impl.py", line 45, in _async_execute_process_nopty
        transport, protocol = await loop.subprocess_exec(
      File "/usr/lib/python3.10/asyncio/base_events.py", line 1681, in subprocess_exec
        transport = await self._make_subprocess_transport(
      File "/usr/lib/python3.10/asyncio/unix_events.py", line 207, in _make_subprocess_transport
        transp = _UnixSubprocessTransport(self, protocol, args, shell,
      File "/usr/lib/python3.10/asyncio/base_subprocess.py", line 36, in __init__
        self._start(args=args, shell=shell, stdin=stdin, stdout=stdout,
      File "/usr/lib/python3.10/asyncio/unix_events.py", line 799, in _start
        self._proc = subprocess.Popen(
      File "/usr/lib/python3.10/subprocess.py", line 971, in __init__
        self._execute_child(args, executable, preexec_fn, close_fds,
      File "/usr/lib/python3.10/subprocess.py", line 1863, in _execute_child
        raise child_exception_type(errno_num, err_msg, err_filename)
    FileNotFoundError: [Errno 2] No such file or directory: 'gz'

(from the same test)

[coderwyvern]

Thanks a lot for your comments.

I'll do a clean compile again and run the tests. Like you mentioned, I'm pretty sure these failing ones are due to the gazebo version since they were passing when I ran them with gazebo harmonic built on humble. I'll test them now and let you know

[SteveMacenski]

OK! I tried what you updated with and still getting 19 failures, many of which are failing to produce results or for some reason is crashing

    [tester_node-18] [INFO] [1746722258.450282382] [nav2_gps_waypoint_tester]: Goal succeeded!
    [tester_node-18] Traceback (most recent call last):
    [tester_node-18]   File "/root/hi_ws/src/navigation2/nav2_system_tests/src/gps_navigation/tester.py", line 230, in <module>
    [tester_node-18]     main()
    [tester_node-18]   File "/root/hi_ws/src/navigation2/nav2_system_tests/src/gps_navigation/tester.py", line 189, in main
    [tester_node-18]     assert not result
    [tester_node-18] AssertionError
    [ERROR] [tester_node-18]: process has died [pid 104212, exit code 1, cmd '/root/hi_ws/src/navigation2/nav2_system_tests/src/gps_navigation/tester.py'].
    [INFO] [navsat_transform_node-17]: sending signal 'S

I assume that's not actually the core issue, that's just a symptom (or maybe it is the core issue).

[coderwyvern]

Thanks a lot for trying it out 😄

I have similar error cases too when I run the tests. I will take a look at them first thing tomorrow.

Can you please let me know if simply pulling the main branch into this branch will allow the pipelines to run properly for the PR? Will I need to make any other changes?

[SteveMacenski]

You need to pull in the latest in main, then make the following changes:

• 4eb4ee0
• c7bd4fb

[coderwyvern]

I first synced up my fork with the latest main and then ran git merge main while being on my humble_main_compilation branch. But unfortunately, this will flood the current PR with linting changes. I would ideally like them to be fixed as well 😬

I don't think git is tracking those changes since this branch was branched off from humble_main. I am unsure of what I should do here. Shall I make a new PR just to make humble_main upto date with main with correct linting and then sync my fork's humble_main branch? After, that run git merge humble_main onto this? Would that work?

[SteveMacenski]

Frankly for this branch, I'm not overly concerned about linting errors. Nicely ament_uncrustify has a --reformat option that'll take care of its violations automatically. Maybe that'll solve most of the issue. I'm more worried about the functionality of the Humble compatible main branch than I am linting.

Arguably, I would actually prefer if you didn't fix the linting so that the branch here is as close as humanly possible to main so that we can more easily backport PRs to this branch in the future. We can just disable the linting job on this branch and that's OK. The reason you see linting issues is that the profiles from Humble-Jazzy-Kilted have slightly changed over time but are all still reasonable profiles.

Would 'just don't change it' solve the issue? :-)

[coderwyvern]

Hello @SteveMacenski !

I pulled in the latest main and didn't care about the linting stuff when I did so like you mentioned. I also applied the commits you shared so that the CI would run correctly.

However, there is a test in nav2_system_tests that fails all the time like you mentioned. I believe it is because the lat long in the gps coordinates are not converted properly to poses and the output is always 0.0.

I added some logs and the output is below:

[waypoint_follower-10] [INFO] [1747046434.317489333] [waypoint_follower]: Converting GPS waypoints to map Frame..

[waypoint_follower-10] [INFO] [1747046434.317549215] [waypoint_follower]: REQUESTED GPS waypoint lat55.9448 long: -3.187

[waypoint_follower-10] [INFO] [1747046434.318265495] [waypoint_follower]: CONVERTED GPS waypoint x: 0 y: 0

[waypoint_follower-10] [INFO] [1747046434.318300992] [waypoint_follower]: REQUESTED GPS waypoint lat55.9448 long: -3.18708

[tester_node-18] [INFO] [1747046434.318342723] [nav2_gps_waypoint_tester]: Goal accepted

[waypoint_follower-10] [INFO] [1747046434.318726353] [waypoint_follower]: CONVERTED GPS waypoint x: 0 y: 0

[waypoint_follower-10] [INFO] [1747046434.318745463] [waypoint_follower]: REQUESTED GPS waypoint lat55.9448 long: -3.18706

[waypoint_follower-10] [INFO] [1747046434.318956884] [waypoint_follower]: CONVERTED GPS waypoint x: 0 y: 0

I found a similar issue here : ros-navigation/navigation2_tutorials#77

It's weird that the service interface fromLL exists on humble but it doesn't work. I'm not sure if I'm doing something wrong. What should I do here?

[coderwyvern]

Okay, so it seems like the build passed properly on CI. There are a lot of failures on release_test and most of these are from uncrustify and that it can't find a copyright. Is there a way to make colcon test skip linting and copyright related tests?

Or maybe, disable the linting specific jobs and specifically for colcon test on circleci, add an ament_uncrustify --reformat to the .circleci/config.yaml just before the colcon test command?

[SteveMacenski]

Merged, can you rebase / fix conflicts?

[mergify]

This pull request is in conflict. Could you fix it @coderwyvern?

[suchetanrs]

@SteveMacenski I've rebased and the history is cleaner now.
I think DCO failed last time because this PR also involved a merge commit which had commits from other contributors as well. It seems to pass now that those commits are removed.

We should post on discourse about it!

Sure thing �� Excited for that hehe

[SteveMacenski]

For my sanity checking an you confirm:

• You tested the TB3/4 launch files with IGN and loopback sim working
• Add in an eq to this workflow for humble_main so I can autobackport. I just created the backport-humble-main label

Otherwise LGTM!

[suchetanrs]

@SteveMacenski

* You tested the TB3/4 launch files with IGN and loopback sim working

Yep! I retested the tb3 and tb4 loopback sim + ign gazebo launch files now and they seem to work. On a fresh container, on first startup, gazebo does wait to download the models I think but after that it's okay. I also tested the cloned and unique multi robot launch files again, they seem to work.

* Add in an eq to [this workflow](https://github.com/ros-navigation/navigation2/blob/main/.github/mergify.yml#L11-L18) for humble_main so I can autobackport. I just created the backport-humble-main label

Done!

Can you check in on this merging? This is blocking the PR from being accepted until we use Humble's launch

ros2/launch#871 will be preferred over my PR (ros2/launch#864) since that is more feature complete. It seems like it will be merged soon. I'll retest the launch files when that's merged and let you know.

[SteveMacenski]

Great! Thanks and merged now that the ROS 2 launch works! We should hopefully remember to remove from underlay once the binaries are out, but either way this is a good solution :-)

Thanks so much for this time and effort, I think this will gain alot of use in the community. Want to announce it on ROS Discourse in the Nav2 category? :-)

[suchetanrs]

Want to announce it on ROS Discourse in the Nav2 category? :-)

I know you made a few changes to the main branch to make it compatible with Jazzy but I don't have all the context here :p (I just know what I did for Humble and not the other distros). I'll leave the honours to announce it to the community to you! 😁