OMPL and Qt API update, bump cmake minimum version requirement

[mini-1235]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	Lyrical Sync
Primary OS tested on	(Ubuntu, MacOS, Windows)
Robotic platform tested on	(Steve's Robot, gazebo simulation of Tally, hardware turtlebot)
Does this PR contain AI generated software?	(No; Yes and it is marked inline in the code)
Was this PR description generated by AI software?	Out of respect for maintainers, AI for human-to-human communications are banned

---

Description of contribution in a few bullet points

Description of documentation updates required from your changes

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
• Should this be backported to current distributions? If so, tag with backport-*.

[mini-1235]

I figured out that the EventsExecutor wasn't included in the last rolling sync, but we do have it in Lyrical, so it seems easier for me to test it in Lyrical :)

This PR fixes all the compile errors but is not ready to review/merge, I am opening as draft to check the backward compatibility for Jazzy/Kilted. It also depends on ros2/message_filters#292, ros/rosdistro#51321, BehaviorTree/BehaviorTree.CPP#1139, and an upstream OMPL sync, we should probably merge this after we migrate to Ubuntu 26.04 (most fixes here are related to 26.04 using g++15)

[mergify]

This pull request is in conflict. Could you fix it @mini-1235?

[codecov]

Codecov Report

❌ Patch coverage is 80.35714% with 11 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
nav2_waypoint_follower/src/waypoint_follower.cpp	16.66%	5 Missing ⚠️
nav2_behaviors/plugins/spin.cpp	25.00%	3 Missing ⚠️
...nclude/nav2_behaviors/plugins/drive_on_heading.hpp	66.66%	2 Missing ⚠️
nav2_behaviors/plugins/back_up.cpp	50.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
...ehavior_tree/plugins/action/follow_path_action.cpp	94.11% <100.00%> (ø)
...ehaviors/include/nav2_behaviors/timed_behavior.hpp	92.47% <100.00%> (ø)
nav2_collision_monitor/src/circle.cpp	95.00% <100.00%> (ø)
nav2_collision_monitor/src/polygon.cpp	96.98% <100.00%> (ø)
...d/include/nav2_costmap_2d/footprint_subscriber.hpp	100.00% <ø> (ø)
...map_2d/include/nav2_costmap_2d/layered_costmap.hpp	100.00% <100.00%> (ø)
nav2_costmap_2d/plugins/obstacle_layer.cpp	81.62% <100.00%> (-0.55%)	⬇️
nav2_costmap_2d/src/footprint_subscriber.cpp	100.00% <100.00%> (ø)
nav2_costmap_2d/src/layered_costmap.cpp	96.61% <ø> (ø)
...av2_docking/opennav_docking/src/docking_server.cpp	89.48% <100.00%> (ø)
... and 9 more

... and 10 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mini-1235]

Executor Performance Report.docx
Diff

Event

Singlethreaded

I finally found some time to generate those flamegraphs today. To speed things up, I had AI put together a quick summary report. I did a scan through it, and for the most part, the findings look pretty reasonable to me.

The report also digs into the lifecycle_manager. We definitely see some performance gains there, but if you look closely at the flamegraph, it is still eating up a massive chunk of the CPU (compared to other components like the controller_server or planner_server).

Also, like we discussed on slack earlier, if you download the EventsCBGExecutor flamegraph and search for "singlethreaded", you will still see it popping up all over the place. I suspect we are going to see another massive performance once absolutely everything is switched over to the event executor, but waiting for the ros2 core repos to merge those updates first

[SteveMacenski]

My apologies for the delay. Saying I've simply been overwhelmed would be a misuse of the word.

Can you summarize for me the actions or what you think should happen from the flamegraph? I'm reading from your phrasing you think some things still need to change so I'm not clear if this is ready or not (seems like there's some places the wrong executor is being used still?).

Wrt the report: I see that it reduces CPU cycles, but what's the actual % improvement in terms of stable-runtime performance? As your report mentions, CPU cycles doesn't mean the % changes and the % is important to understand.

lifecycle_manager does not need fast failure detection for most deployments

I disagree with this, we need fast detection failure for all deployments. Rather than simply reducing the rate, I think we should fix it (which AI may well help with) in code changes or in how its run (i.e. executor, in another process, etc).

Running it as a standalone node eliminates cross-node lock contention

Have you shown this is actually true? I would be open to moving that to another process if that's the case. I question though if AI is properly diagnosing this though. If this solves it, that seems easy enough.

[mini-1235]

No worries, I marked this as draft because of the blocking issues I mentioned in the lyrical release ticket. I am also very busy at the moment, feel free to review now or wait until everything is ready :)

I'm reading from your phrasing you think some things still need to change so I'm not clear if this is ready or not (seems like there's some places the wrong executor is being used still?).

I thought your preference was to use SingleThreadedExecutor in the code until the ros2 team tests and agrees to switch everything to EventsExecutor by default. I also have a branch here mini-1235@d779849. Did you change your mind? For context we discussed this on Slack:

Stress testing and finding things like this is important so we could in the future do that, but I agree we shouldn't make it default yet. I'm also not sure if its worth making the default anytime soon either if the improvement in performance isn't > 1%. I had expected like 10% or more back from this change (since a non-trivial amount of our overhead in Nav2 is actually ROS 2 by itself)

Can you summarize for me the actions or what you think should happen from the flamegraph?

Could you take a quick look at the lifecycle manager flamegraph/report and let me know if you are satisfied with the improvement (and the potential improvement once everything switches to EventsExecutor)? If you are not satisfied with the current results, then my proposal in #6061 is probably in the wrong direction, and we will need to think of some alternative approaches

but what's the actual % improvement in terms of stable-runtime performance?

When you ask about % improvement, do you mean total CPU usage? I have been measuring with btop before and after, and it's around 1% as I mentioned on Slack(my CPU is much faster than typical onboard computers, so I would still consider the improvement meaningful)

I disagree with this, we need fast detection failure for all deployments. Rather than simply reducing the rate, I think we should fix it (which AI may well help with) in code changes or in how its run (i.e. executor, in another process, etc).

Have you shown this is actually true? I would be open to moving that to another process if that's the case. I question though if AI is properly diagnosing this though. If this solves it, that seems easy enough.

I would ignore the AI-generated solutions in there, I didn't have time to polish the report. I generated the data by hand and had AI summarize it just to give you a rough before vs after picture.

[GYKrauss]

It is not building for me...

Base docker image - "osrf/ros:lyrical-desktop-full" - June 1st 2026

FROM osrf/ros@sha256:e2850b225534d1c9b9f511a1d19ce45bbd632a4711a7f74ef4c466c808fdb909 AS base

Relevant dockerfile snippet

WORKDIR /opt/nav2_ws
ARG nav2_setup_bash=/opt/nav2_ws/install/setup.bash
RUN mkdir -p /opt/nav2_ws/src &&
git clone -b lyrical/sync https://github.com/mini-1235/navigation2.git ./src/navigation2 &&
apt-get update -y &&
apt-get install -y libompl-dev &&
rosdep update &&
rosdep install -r -y --from-paths ./src/navigation2 --ignore-src --skip-keys="ompl" &&
source /opt/ros/${ros_distro}/setup.bash &&
colcon build --symlink-instal

Error:
11:48:27 --- stderr: nav2_behavior_tree
11:48:27 In file included from /opt/nav2_ws/src/navigation2/nav2_behavior_tree/src/behavior_tree_engine.cpp:27:
11:48:27 /opt/nav2_ws/src/navigation2/nav2_behavior_tree/include/nav2_behavior_tree/utils/loop_rate.hpp: In member function ‘bool nav2_behavior_tree::LoopRate::sleep()’:
11:48:27 /opt/nav2_ws/src/navigation2/nav2_behavior_tree/include/nav2_behavior_tree/utils/loop_rate.hpp:64:27: error: ‘class BT::Tree’ has no member named ‘wakeUpSignal’; did you mean ‘emitWakeUpSignal’?
11:48:27 64 | auto wake_up = tree_->wakeUpSignal();
11:48:27 | ^~~~~~~~~~~~
11:48:27 | emitWakeUpSignal
11:48:27 gmake[2]: *** [CMakeFiles/nav2_behavior_tree.dir/build.make:79: CMakeFiles/nav2_behavior_tree.dir/src/behavior_tree_engine.cpp.o] Error 1
11:48:27 gmake[1]: *** [CMakeFiles/Makefile2:722: CMakeFiles/nav2_behavior_tree.dir/all] Error 2
11:48:27 gmake[1]: *** Waiting for unfinished jobs....
11:48:27 gmake: *** [Makefile:146: all] Error 2
11:48:27 ---
11:48:27 Failed <<< nav2_behavior_tree [18.0s, exited with code 2]

[mini-1235]

Check the blockers I listed earlier, you might need to build some packages from source before a lyrical sync happens

[GYKrauss]

OK... just needed one more line - building BT from source and it all built on the lyrical image.
WORKDIR /opt/nav2_ws
ARG nav2_setup_bash=/opt/nav2_ws/install/setup.bash
RUN mkdir -p /opt/nav2_ws/src && \
git clone -b lyrical/sync https://github.com/mini-1235/navigation2.git ./src/navigation2 && \
git clone -b master https://github.com/BehaviorTree/BehaviorTree.CPP.git ./src/BehaviorTree.CPP && \
apt-get update -y && \
apt-get install -y libompl-dev && \
rosdep update && \
rosdep install -r -y --from-paths ./src --ignore-src --skip-keys="ompl" && \
source /opt/ros/${ros_distro}/setup.bash && \
colcon build --symlink-install

[SteveMacenski]

I thought your preference was to use SingleThreadedExecutor in the code until the ros2 team tests and agrees to switch everything to EventsExecutor by default. I also have a branch here mini-1235@d779849. Did you change your mind? For context we discussed this on Slack:

I don't think we need to wait for the ROS team to make it default, but I would want to see testing that this works reliably and has a measurable performance improvement. Once we change it though, we can/should change it everywhere else too including the BT nodes and others you've mentioned in that branch. I think its an all-at-once thing so we can have consistent behavior across the board.

When you ask about % improvement, do you mean total CPU usage? I have been measuring with btop before and after, and it's around 1% as I mentioned on Slack(my CPU is much faster than typical onboard computers, so I would still consider the improvement meaningful)

Yes, this is what I mean. And OK - its just not listed here anywhere and I've forgotten the context in Slack after this long :-)

---

Could you take a quick look at the lifecycle manager flamegraph/report and let me know if you are satisfied with the improvement (and the potential improvement once everything switches to EventsExecutor)? If you are not satisfied with the current results, then my proposal in #6061 is probably in the wrong direction, and we will need to think of some alternative approaches

This is what I'm not understanding. There's some potential plans, ideas, and options, but I'm not seeing a recommendation or what works and the analysis to show the impact. As you pointed out in the report, just having a large reduction in CPU cycles is not eq. to having a change in resource utilization. Not to say reducing cycles is bad, but if you're saying that the lifecycle manager is taking a ridiculous amount of compute %, then we should also be measuring CPU % of changes to know if they make an impact on the actual problem.

I suspect you actually did a bunch of testing off those ideas and options and have a conclusion that perhaps I'm just missing or maybe you didn't communicate it yet. I might just be tired and missing something obvious between all of these sources. I am starting tomorrow able to get back into normal hours so my thought process will be alot less clouded, but I'm feeling like I'm missing some key details to make decisions or help answer your concerns.

Can you be specific and let me know what you changed, tested, and measured -- or concisely what you are trying to get from me that I'm not giving & the context for that in one post? 😆 It seems like we're talking about the new executor for use in Nav2 as well as fixes for the lifecycle manager taking too much compute for what it rightfully does.

I don't see a proposal in #6061 that you're referring to 🙃 There's just a flamegraph without context or comparison, so I'm not sure what to make of it honestly in isolation, i.e.:

I wonder if the CPU usage can be largely reduced here after switching to the new EventExecutor in Lyrical

Did you get to testing and that made the difference to fix the lifecycle manager high compute problem with the current bond rate?

[mini-1235]

I don't think we need to wait for the ROS team to make it default, but I would want to see testing that this works reliably and has a measurable performance improvement. Once we change it though, we can/should change it everywhere else too including the BT nodes and others you've mentioned in that branch. I think its an all-at-once thing so we can have consistent behavior across the board.

My previous testing shows it is pretty much stable (the rviz bug I mentioned is hard to reproduce and I am not even sure it is related to the new executor). I think real robot testing would be more reliable here, and that is probably not something I can lead, do you know anyone who might be interested? And should I cherry-pick the commit here?

I don't see a proposal in #6061 that you're referring to 🙃 There's just a flamegraph without context or comparison, so I'm not sure what to make of it honestly in isolation, i.e.:

Yeah that is more of an idea than a proposal. My initial assumption was that "switching to EventExecutor could bring a big reduction in lifecycle manager CPU usage", but from my preliminary testing that doesn't seem to be the case. Based on the flamegraphs, there is some improvement, but it is not that obvious. Right now we are also in a mixed state where SingleThreadedExecutor and EventExecutor are both used in lifecycle manager, I suspect even if we unified everything under EventExecutor (by modifying rclcpp/bond code), it wouldn't bring much more improvement based on what the flamegraphs are showing(but worth testing).

Another thing I want to note: from the flamegraph, lifecycle manager is taking roughly 3-6x more CPU than the other individual components. If the goal is to get it closer to the same level as other components, that feels like it might need more fundamental changes beyond just switching the executor

So my current take on #6061: there is some benefit, but probably not enough to be obvious. I would love to hear your thoughts as well before I do more testing, like, what kind of reduction would you want to see to consider this worthwhile?

Next steps on my end would be to switch bond/rclcpp to EventExecutor as well and remeasure, then see if there is room to optimize further on the hottest paths. But realistically that can only happen around August/September when I am back home

[mini-1235]

Or simply put(if you agree with me), I think I was wrong about #6061, switching to EventExecutor does bring some benefit, but it doesn't solve it. The gap is still there and we probably need a better solution discussed over there. I don't think we should continue the lifecycle manager discussion in this PR

[mini-1235]

I added some more:

• Use constsharedptr and Add format arguments in rclcpp logging related to rclcpp warnings not showing as expected ros2/rclcpp#3176

• Use new aggregate rosidl target related to Create an aggregate target for rosidl generated interfaces targets ros2/rosidl#947

[mini-1235]

it looks like jazzy + kilted image is not up to date:

> docker run --runtime=nvidia --gpus all -it --ipc=host --net=host --privileged -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -e NVIDIA_DRIVER_CAPABILITIES=all ghcr.io/ros-navigation/nav2_docker:jazzy-nightly-standard
root@mini1235-XPS-15-9520:~/nav2_ws# apt update
Get:1 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Get:2 http://archive.ubuntu.com/ubuntu noble InRelease [256 kB]
Get:3 http://packages.ros.org/ros2/ubuntu noble InRelease [4676 B]
Get:4 http://packages.ros.org/ros2/ubuntu noble/main Sources [2081 kB]
Get:5 http://security.ubuntu.com/ubuntu noble-security/multiverse amd64 Packages [43.8 kB]
Get:6 http://security.ubuntu.com/ubuntu noble-security/restricted amd64 Packages [1308 kB]
Get:7 http://security.ubuntu.com/ubuntu noble-security/universe amd64 Packages [1486 kB]
Get:8 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages [964 kB]
Get:9 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Get:10 http://archive.ubuntu.com/ubuntu noble-backports InRelease [126 kB]
Get:11 http://archive.ubuntu.com/ubuntu noble/restricted amd64 Packages [117 kB]
Get:12 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages [1808 kB]
Get:13 http://archive.ubuntu.com/ubuntu noble/multiverse amd64 Packages [331 kB]
Get:14 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages [19.3 MB]
Get:15 http://archive.ubuntu.com/ubuntu noble-updates/restricted amd64 Packages [1383 kB]
Get:16 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages [1284 kB]
Get:17 http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 Packages [2108 kB]
Get:18 http://archive.ubuntu.com/ubuntu noble-updates/multiverse amd64 Packages [49.5 kB]
Get:19 http://archive.ubuntu.com/ubuntu noble-backports/main amd64 Packages [48.9 kB]
Get:20 http://archive.ubuntu.com/ubuntu noble-backports/universe amd64 Packages [35.9 kB]
Get:21 http://archive.ubuntu.com/ubuntu noble-backports/multiverse amd64 Packages [671 B]
Get:22 http://packages.ros.org/ros2/ubuntu noble/main amd64 Packages [1956 kB]
Fetched 35.0 MB in 6s (5685 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
324 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@mini1235-XPS-15-9520:~/nav2_ws# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  ca-certificates glslang-dev libapparmor1 libcups2t64 libdrm-amdgpu1 libdrm-common libdrm-dev libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libegl-mesa0 libgbm-dev libgbm1 libgcrypt20 libgl1-mesa-dev
  libgl1-mesa-dri libglx-mesa0 libgnutls30t64 libgraphite2-3 libheif-dev libheif-plugin-aomdec libheif1 libllvm20 libpam-systemd libpoppler-dev libpoppler-private-dev libpoppler134 librabbitmq4 libssl-dev
  libssl3t64 libsystemd-shared libsystemd0 libudev-dev libudev1 libva-drm2 libva-x11-2 libva2 mesa-libgallium openssl python3-pil python3-pil.imagetk ros-jazzy-action-msgs ros-jazzy-action-tutorials-cpp
  ros-jazzy-action-tutorials-interfaces ros-jazzy-action-tutorials-py ros-jazzy-actionlib-msgs ros-jazzy-actuator-msgs ros-jazzy-ament-cmake-ros ros-jazzy-ament-index-cpp ros-jazzy-ament-index-python
  ros-jazzy-builtin-interfaces ros-jazzy-camera-calibration ros-jazzy-camera-calibration-parsers ros-jazzy-camera-info-manager ros-jazzy-class-loader ros-jazzy-common-interfaces ros-jazzy-composition
  ros-jazzy-composition-interfaces ros-jazzy-compressed-depth-image-transport ros-jazzy-compressed-image-transport ros-jazzy-console-bridge-vendor ros-jazzy-cv-bridge ros-jazzy-demo-nodes-cpp
  ros-jazzy-demo-nodes-cpp-native ros-jazzy-demo-nodes-py ros-jazzy-depth-image-proc ros-jazzy-depthimage-to-laserscan ros-jazzy-desktop ros-jazzy-desktop-full ros-jazzy-diagnostic-msgs
  ros-jazzy-diagnostic-updater ros-jazzy-domain-coordinator ros-jazzy-dummy-map-server ros-jazzy-dummy-robot-bringup ros-jazzy-dummy-sensors ros-jazzy-eigen3-cmake-module ros-jazzy-example-interfaces
  ros-jazzy-examples-rclcpp-minimal-action-client ros-jazzy-examples-rclcpp-minimal-action-server ros-jazzy-examples-rclcpp-minimal-client ros-jazzy-examples-rclcpp-minimal-composition
  ros-jazzy-examples-rclcpp-minimal-publisher ros-jazzy-examples-rclcpp-minimal-service ros-jazzy-examples-rclcpp-minimal-subscriber ros-jazzy-examples-rclcpp-minimal-timer
  ros-jazzy-examples-rclcpp-multithreaded-executor ros-jazzy-examples-rclpy-executors ros-jazzy-examples-rclpy-minimal-action-client ros-jazzy-examples-rclpy-minimal-action-server
  ros-jazzy-examples-rclpy-minimal-client ros-jazzy-examples-rclpy-minimal-publisher ros-jazzy-examples-rclpy-minimal-service ros-jazzy-examples-rclpy-minimal-subscriber ros-jazzy-fastrtps-cmake-module
  ros-jazzy-filters ros-jazzy-geometry-msgs ros-jazzy-geometry2 ros-jazzy-gps-msgs ros-jazzy-gz-common-vendor ros-jazzy-gz-fuel-tools-vendor ros-jazzy-gz-gui-vendor ros-jazzy-gz-math-vendor
  ros-jazzy-gz-msgs-vendor ros-jazzy-gz-physics-vendor ros-jazzy-gz-rendering-vendor ros-jazzy-gz-sensors-vendor ros-jazzy-gz-sim-vendor ros-jazzy-gz-transport-vendor ros-jazzy-image-common
  ros-jazzy-image-geometry ros-jazzy-image-pipeline ros-jazzy-image-proc ros-jazzy-image-publisher ros-jazzy-image-rotate ros-jazzy-image-tools ros-jazzy-image-transport ros-jazzy-image-transport-plugins
  ros-jazzy-image-view ros-jazzy-interactive-markers ros-jazzy-intra-process-demo ros-jazzy-joy ros-jazzy-kdl-parser ros-jazzy-laser-filters ros-jazzy-laser-geometry ros-jazzy-launch ros-jazzy-launch-ros
  ros-jazzy-launch-testing ros-jazzy-launch-testing-ament-cmake ros-jazzy-launch-testing-ros ros-jazzy-launch-xml ros-jazzy-launch-yaml ros-jazzy-liblz4-vendor ros-jazzy-libstatistics-collector
  ros-jazzy-libyaml-vendor ros-jazzy-lifecycle ros-jazzy-lifecycle-msgs ros-jazzy-logging-demo ros-jazzy-map-msgs ros-jazzy-marine-acoustic-msgs ros-jazzy-mcap-vendor ros-jazzy-message-filters ros-jazzy-nav-msgs
  ros-jazzy-orocos-kdl-vendor ros-jazzy-pcl-conversions ros-jazzy-pcl-msgs ros-jazzy-pcl-ros ros-jazzy-pendulum-control ros-jazzy-pendulum-msgs ros-jazzy-perception ros-jazzy-perception-pcl ros-jazzy-pluginlib
  ros-jazzy-point-cloud-transport ros-jazzy-python-orocos-kdl-vendor ros-jazzy-qt-gui ros-jazzy-qt-gui-cpp ros-jazzy-qt-gui-py-common ros-jazzy-quality-of-service-demo-cpp ros-jazzy-quality-of-service-demo-py
  ros-jazzy-rcl ros-jazzy-rcl-action ros-jazzy-rcl-interfaces ros-jazzy-rcl-lifecycle ros-jazzy-rcl-logging-interface ros-jazzy-rcl-logging-spdlog ros-jazzy-rcl-yaml-param-parser ros-jazzy-rclcpp
  ros-jazzy-rclcpp-action ros-jazzy-rclcpp-components ros-jazzy-rclcpp-lifecycle ros-jazzy-rclpy ros-jazzy-rcpputils ros-jazzy-rcutils ros-jazzy-resource-retriever ros-jazzy-rmw ros-jazzy-rmw-dds-common
  ros-jazzy-rmw-fastrtps-cpp ros-jazzy-rmw-fastrtps-shared-cpp ros-jazzy-rmw-implementation ros-jazzy-robot-state-publisher ros-jazzy-ros-base ros-jazzy-ros-core ros-jazzy-ros-gz-bridge ros-jazzy-ros-gz-image
  ros-jazzy-ros-gz-interfaces ros-jazzy-ros-gz-sim ros-jazzy-ros-gz-sim-demos ros-jazzy-ros2action ros-jazzy-ros2bag ros-jazzy-ros2cli ros-jazzy-ros2cli-common-extensions ros-jazzy-ros2component
  ros-jazzy-ros2doctor ros-jazzy-ros2interface ros-jazzy-ros2launch ros-jazzy-ros2lifecycle ros-jazzy-ros2multicast ros-jazzy-ros2node ros-jazzy-ros2param ros-jazzy-ros2pkg ros-jazzy-ros2plugin ros-jazzy-ros2run
  ros-jazzy-ros2service ros-jazzy-ros2topic ros-jazzy-rosbag2 ros-jazzy-rosbag2-compression ros-jazzy-rosbag2-compression-zstd ros-jazzy-rosbag2-cpp ros-jazzy-rosbag2-interfaces ros-jazzy-rosbag2-py
  ros-jazzy-rosbag2-storage ros-jazzy-rosbag2-storage-default-plugins ros-jazzy-rosbag2-storage-mcap ros-jazzy-rosbag2-storage-sqlite3 ros-jazzy-rosbag2-transport ros-jazzy-rosgraph-msgs ros-jazzy-rosidl-adapter
  ros-jazzy-rosidl-cli ros-jazzy-rosidl-cmake ros-jazzy-rosidl-core-generators ros-jazzy-rosidl-core-runtime ros-jazzy-rosidl-default-generators ros-jazzy-rosidl-default-runtime
  ros-jazzy-rosidl-dynamic-typesupport ros-jazzy-rosidl-dynamic-typesupport-fastrtps ros-jazzy-rosidl-generator-c ros-jazzy-rosidl-generator-cpp ros-jazzy-rosidl-generator-py ros-jazzy-rosidl-generator-rs
  ros-jazzy-rosidl-generator-type-description ros-jazzy-rosidl-parser ros-jazzy-rosidl-pycommon ros-jazzy-rosidl-runtime-c ros-jazzy-rosidl-runtime-cpp ros-jazzy-rosidl-runtime-py ros-jazzy-rosidl-typesupport-c
  ros-jazzy-rosidl-typesupport-cpp ros-jazzy-rosidl-typesupport-fastrtps-c ros-jazzy-rosidl-typesupport-fastrtps-cpp ros-jazzy-rosidl-typesupport-interface ros-jazzy-rosidl-typesupport-introspection-c
  ros-jazzy-rosidl-typesupport-introspection-cpp ros-jazzy-rqt-action ros-jazzy-rqt-bag ros-jazzy-rqt-bag-plugins ros-jazzy-rqt-common-plugins ros-jazzy-rqt-console ros-jazzy-rqt-graph ros-jazzy-rqt-gui
  ros-jazzy-rqt-gui-cpp ros-jazzy-rqt-gui-py ros-jazzy-rqt-image-view ros-jazzy-rqt-msg ros-jazzy-rqt-plot ros-jazzy-rqt-publisher ros-jazzy-rqt-py-common ros-jazzy-rqt-py-console ros-jazzy-rqt-reconfigure
  ros-jazzy-rqt-service-caller ros-jazzy-rqt-shell ros-jazzy-rqt-srv ros-jazzy-rqt-topic ros-jazzy-rviz-assimp-vendor ros-jazzy-rviz-common ros-jazzy-rviz-default-plugins ros-jazzy-rviz-ogre-vendor
  ros-jazzy-rviz-rendering ros-jazzy-rviz2 ros-jazzy-sdformat-urdf ros-jazzy-sdformat-vendor ros-jazzy-sensor-msgs ros-jazzy-sensor-msgs-py ros-jazzy-service-msgs ros-jazzy-shape-msgs ros-jazzy-simulation
  ros-jazzy-simulation-interfaces ros-jazzy-spdlog-vendor ros-jazzy-sqlite3-vendor ros-jazzy-sros2 ros-jazzy-sros2-cmake ros-jazzy-statistics-msgs ros-jazzy-std-msgs ros-jazzy-std-srvs ros-jazzy-stereo-image-proc
  ros-jazzy-stereo-msgs ros-jazzy-teleop-twist-joy ros-jazzy-teleop-twist-keyboard ros-jazzy-tf2 ros-jazzy-tf2-bullet ros-jazzy-tf2-eigen ros-jazzy-tf2-eigen-kdl ros-jazzy-tf2-geometry-msgs ros-jazzy-tf2-kdl
  ros-jazzy-tf2-msgs ros-jazzy-tf2-py ros-jazzy-tf2-ros ros-jazzy-tf2-ros-py ros-jazzy-tf2-sensor-msgs ros-jazzy-tf2-tools ros-jazzy-theora-image-transport ros-jazzy-tlsf ros-jazzy-tlsf-cpp
  ros-jazzy-topic-monitor ros-jazzy-tracetools ros-jazzy-tracetools-image-pipeline ros-jazzy-trajectory-msgs ros-jazzy-turtlesim ros-jazzy-type-description-interfaces ros-jazzy-unique-identifier-msgs
  ros-jazzy-urdf ros-jazzy-urdf-parser-plugin ros-jazzy-urdfdom ros-jazzy-urdfdom-headers ros-jazzy-vision-msgs ros-jazzy-vision-opencv ros-jazzy-visualization-msgs ros-jazzy-xacro ros-jazzy-zstd-image-transport
  ros-jazzy-zstd-vendor spirv-headers spirv-tools systemd systemd-dev systemd-sysv
324 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 121 MB of archives.
After this operation, 2098 kB of additional disk space will be used.

[mergify]

This pull request is in conflict. Could you fix it @mini-1235?

[SteveMacenski]

I suspect even if we unified everything under EventExecutor (by modifying rclcpp/bond code), it wouldn't bring much more improvement based on what the flamegraphs are showing(but worth testing).

I think we may have surprised there, but I agree I would not put the probabilities very high (but still real).

Another thing I want to note: from the flamegraph, lifecycle manager is taking roughly 3-6x more CPU than the other individual components. If the goal is to get it closer to the same level as other components, that feels like it might need more fundamental changes beyond just switching the executor

Agreed, it would be good to understand exactly why this is happening and if there's any obvious solutions to it. What kind of improvements did you see with the events executor?

---

What's the state of this work? It seems to address a few things. Perhaps the non-executor items can be spun out and merged pretty quickly and the executor ones can be WIP/discussion continues to happen for performance improvements. I see no reason to block the vast majority of this PR and since I'm back from vacation now we can iterate quickly

[mini-1235]

Responding here quickly before I go to bed 😀

Agreed, it would be good to understand exactly why this is happening and if there's any obvious solutions to it. What kind of improvements did you see with the events executor?

I have been a bit too busy recently, and honestly I don't remember the exact numbers without looking at the graph again. I will leave that for later when I have more time to re-test and discuss properly.

What's the state of this work? It seems to address a few things. Perhaps the non-executor items can be spun out and merged pretty quickly and the executor ones can be WIP/discussion continues to happen for performance improvements.

The purpose of this PR is to try to migrate to 26.04, but as far as I know there are still a few blockers:

• Switch Rolling to use Ubuntu resolute. osrf/docker_images#881: Rolling is still on 24.04, which makes this PR hard to run with the correct setup. I believe I pinged about this on zulip here: https://openrobotics.zulipchat.com/#narrow/channel/526027-ROS-General/topic/On.20Resolute.20.2F.20Rolling.20transition.20and.20pre-Lyrical.20testing/near/604877721, but so far I have not heard back
• In my earliest test on Lyrical, I fixed some BTCPP issues so that we could compile successfully. Since we are also building from source on the rolling branch now, I think it would be good to have a new BT.CPP sync. I also pinged here: Remove tinyxml2 vendor on rolling BehaviorTree/BehaviorTree.CPP#1135 (comment).
• I also need the Jazzy/Kilted nav2_docker images to be updated. For reasons I don't fully understand, the images do not seem to have been updated, as shown in the logs above. Any idea?

If I remember correctly, there are no other blockers after OMPL is released, but we will see once we have Lyrical CI / Rolling moved to 26.04.

I think perhaps, if you have time, you can start reviewing this PR. Most of it is due to compilation errors from the platform migration / API updates. The last few commits, as I noted above, are changes that I think would be good to have before branching off. Some are related to rclcpp issues, and some are rosidl target updates.

The PR is currently not really related to EventsExecutor, except that it switches the default isolated container from SingleThreadedExecutor to EventsExecutor.

For the "make everything internal use EventsExecutor by default" work, I think I can cherry pick and open another draft PR? However, I have only tested in simulation, so I would appreciate testing on real robots from others

[mini-1235]

(I will resolve the conflict tomorrow / Thursday)

[SteveMacenski]

Mostly just a few questions but LGTM! Interestinly Jazzy continues to work but Kilted doesn't.

Kilted is EOL in 6 months, non-LTS, and is now superseded by Lyrical, so I could also be convinced to simply drop compilation compatibility with it at this point if its too much a hassle to make it work.

[SteveMacenski]

These are actually not the same thing since there is a possibility to have an empty, but "populated" path with no poses. Checking the constructor is to check if there was never a new path in the first place, not simply that its empty.

I know this was to fix a compilation issue, but perhaps we could just change this to:

nav_msgs::msg::Path initialized_path;
if (goal_.path != new_path && new_path != initialized_path) {

I however, don't actually feel that strongly about it. Its just a potential subtle bug that could happen in some situations I'm trying to avoid.

[SteveMacenski]

Obviously some of this commentary would need to be removed (temporarily) until we actually do migrate to the events executor in another PR?

[SteveMacenski]

Why? This seems immensely silly if we cannot copy a vector

[mergify]

This pull request is in conflict. Could you fix it @mini-1235?

[SteveMacenski]

Otherwise if you can just fix the conflict with those other changes I can merge