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

[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]

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

[mini-1235]

This triggers the null dereference warning:

/root/nav2_ws/src/navigation2/nav2_collision_monitor/include/nav2_collision_monitor/types.hpp:51:8: error: potential null pointer dereference [-Werror=null-dereference]
   51 | struct Point
      |        ^~~~~
/root/nav2_ws/src/navigation2/nav2_collision_monitor/include/nav2_collision_monitor/types.hpp:51:8: error: potential null pointer dereference [-Werror=null-dereference]
/root/nav2_ws/src/navigation2/nav2_collision_monitor/include/nav2_collision_monitor/types.hpp:51:8: error: potential null pointer dereference [-Werror=null-dereference]
cc1plus: all warnings being treated as errors
gmake[2]: *** [CMakeFiles/collision_detector_core.dir/build.make:93: CMakeFiles/collision_detector_core.dir/src/polygon.cpp.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
In file included from /root/nav2_ws/src/navigation2/nav2_collision_monitor/include/nav2_collision_monitor/polygon.hpp:32,
                 from /root/nav2_ws/src/navigation2/nav2_collision_monitor/src/polygon.cpp:15:
In member function ‘constexpr nav2_collision_monitor::Point& nav2_collision_monitor::Point::operator=(const nav2_collision_monitor::Point&)’,
    inlined from ‘constexpr void std::__assign_one(_OutIter&, _InIter&) [with bool _IsMove = false; _OutIter = nav2_collision_monitor::Point*; _InIter = const nav2_collision_monitor::Point*]’ at /usr/include/c++/15/bits/stl_algobase.h:407:9,
    inlined from ‘constexpr _OutIter std::__copy_move_a2(_InIter, _Sent, _OutIter) [with bool _IsMove = false; _InIter = const nav2_collision_monitor::Point*; _Sent = const nav2_collision_monitor::Point*; _OutIter = nav2_collision_monitor::Point*]’ at /usr/include/c++/15/bits/stl_algobase.h:462:28,
    inlined from ‘constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = const nav2_collision_monitor::Point*; _OI = nav2_collision_monitor::Point*]’ at /usr/include/c++/15/bits/stl_algobase.h:492:42,
    inlined from ‘constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = __gnu_cxx::__normal_iterator<const nav2_collision_monitor::Point*, vector<nav2_collision_monitor::Point> >; _OI = __gnu_cxx::__normal_iterator<nav2_collision_monitor::Point*, vector<nav2_collision_monitor::Point> >]’ at /usr/include/c++/15/bits/stl_algobase.h:500:31,
    inlined from ‘constexpr _OI std::copy(_II, _II, _OI) [with _II = __gnu_cxx::__normal_iterator<const nav2_collision_monitor::Point*, vector<nav2_collision_monitor::Point> >; _OI = __gnu_cxx::__normal_iterator<nav2_collision_monitor::Point*, vector<nav2_collision_monitor::Point> >]’ at /usr/include/c++/15/bits/stl_algobase.h:642:7,
    inlined from ‘constexpr std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = nav2_collision_monitor::Point; _Alloc = std::allocator<nav2_collision_monitor::Point>]’ at /usr/include/c++/15/bits/vector.tcc:250:21,
    inlined from ‘virtual void nav2_collision_monitor::Polygon::getPolygon(std::vector<nav2_collision_monitor::Point>&) const’ at /root/nav2_ws/src/navigation2/nav2_collision_monitor/src/polygon.cpp:229:10,
    inlined from ‘bool nav2_collision_monitor::Polygon::configure()’ at /root/nav2_ws/src/navigation2/nav2_collision_monitor/src/polygon.cpp:98:15:
/root/nav2_ws/src/navigation2/nav2_collision_monitor/include/nav2_collision_monitor/types.hpp:51:8: error: potential null pointer dereference [-Werror=null-dereference]
   51 | struct Point
      |        ^~~~~
/root/nav2_ws/src/navigation2/nav2_collision_monitor/include/nav2_collision_monitor/types.hpp:51:8: error: potential null pointer dereference [-Werror=null-dereference]
/root/nav2_ws/src/navigation2/nav2_collision_monitor/include/nav2_collision_monitor/types.hpp:51:8: error: potential null pointer dereference [-Werror=null-dereference]
gmake[1]: *** [CMakeFiles/Makefile2:234: CMakeFiles/collision_detector_core.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
cc1plus: all warnings being treated as errors
gmake[2]: *** [CMakeFiles/collision_monitor_core.dir/build.make:93: CMakeFiles/collision_monitor_core.dir/src/polygon.cpp.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[1]: *** [CMakeFiles/Makefile2:202: CMakeFiles/collision_monitor_core.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2

I believe a possible alternative is to check if poly is empty before assigning it:

if (poly.empty()) {
    return;
  }

Is that something you would prefer?

[SteveMacenski]

Yeah

[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

[mini-1235]

Sorry for the delay, as I mentioned, I have been quite sick and still have some travel coming up, so it has been a lot to manage. I will get to the review items tomorrow

Also, I noticed that rolling moved to 26.04 last week. Could we get #6262 merged before this PR? That way CI can run correctly against it

[mini-1235]

f5f77ad is related to recent updates in ament/ament_index#120

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[SteveMacenski]

Merge as you see fit

[mini-1235]

CI fails to compile, but I have never seen that error and I am not able to reproduce it locally. I will investigate tomorrow

[SteveMacenski]

@mini-1235 change

navigation2/nav2_costmap_2d/include/nav2_costmap_2d/denoise/image_processing.hpp

Line 420 in fa134c9

labels_.resize(1, 0);

to push_back(0);. I can't seem to push to your branch directly to do it. Its not a real bug but a known bug in the compiler

[mini-1235]

@mini-1235 change

navigation2/nav2_costmap_2d/include/nav2_costmap_2d/denoise/image_processing.hpp

Line 420 in fa134c9

labels_.resize(1, 0);

to push_back(0);. I can't seem to push to your branch directly to do it. Its not a real bug but a known bug in the compiler

Maybe because we are pushing at the same time?😄 I am going to sleep now, will fix again tomorrow if it is not green

[SteveMacenski]

I had to fix another case, but building now. WIll merge once tests run and retrigger the docker build

[mini-1235]

It seems like this PR and #6118 introduce some failures in the test, I try to fix it here: #6271