Comment out rosdep update and pin Rviz version to 15.2.1

[mini-1235]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	(add tickets here #1)
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]

Circle CI is still not working because the base image is not updated, but the workflow in my fork is already green https://github.com/mini-1235/navigation2/actions/runs/25112190826/job/73589075208

[mini-1235]

The kilted/jazzy workflow is failing because I pin the rviz version, not sure what's the best solution here

[SteveMacenski]

Is there a fix possible in nav2 rviz plugins? This would suck if we stopped being able to compile main against Jazzy. That's a major win for folks.

[mini-1235]

Is there a fix possible in nav2 rviz plugins? This would suck if we stopped being able to compile main against Jazzy. That's a major win for folks.

I don't think so, this looks more like an upstream issue IMO.

I think the options would be:

• Update Gazebo to support Qt5, or
• Migrate all core ros2 packages to Qt6

and I don't think this worth the effort right now, especially we are transitioning to 26.04 in a few weeks.

What about maintaining separate .repos file for different distros instead? Realistically, most of the dependencies we rely on are not version-aligned across distros right? Libraries like btcpp is an exception here

[SteveMacenski]

Actually, can you detail the problem? Maybe I'm not understanding correctly. I agree we shouldn't do anything for a transient couple of week problem. But any issue with supporting Jazzy/24.04 and Lyrical/26.04 on a single Nav2 branch as-is? I thought perhaps we needed to support QT5/6 in Nav2's rviz plugins, but not sure why we'd have to mess with gazebo since we don't own any customziations there.

[mini-1235]

The issue is basically that our base image + rviz is building against qt5, which is still the default for 24.04. qt6 only becomes the default in 26.04.

Now when we install gazebo, it starts pulling in qt6, that's the default option in 24.04. Then when nav2_rviz_plugins tries to find rviz_common, it ends up picking the qt6 one, since that is also supported, even though it was originally exported with qt5.

I believe we tried hacking the cmakelist on our side before, but it didn't work, and after we raised an issue upstream they switched things to qt6 by default. But then I think because of some issues in rqt, they rolled it back to qt5 again

Qt5 is still supported in the main branch, but it assumes that you don't have qt6 installed or upstream rviz doesn't prioritize qt6 when both are available

[SteveMacenski]

To be clear, does this code work for Qt5 as long as Qt6 is not installed for 24.04 (i.e. if we change nothing, the same code still supports 24.04 and 26.04 distros) -- and Qt6 when Qt6 is installed & exported? Trying to assess if we if this breaks main on 24.04 when we upgrade to 26.06 if we need to change the things.

I'm reading your comment and I could see it being both ways, potentially, so just want to be clear

[mini-1235]

To be clear, does this code work for Qt5 as long as Qt6 is not installed for 24.04 (i.e. if we change nothing, the same code still supports 24.04 and 26.04 distros) -- and Qt6 when Qt6 is installed & exported? Trying to assess if we if this breaks main on 24.04 when we upgrade to 26.06 if we need to change the things.

I'm reading your comment and I could see it being both ways, potentially, so just want to be clear

That really depends on platform + distros + installation method + build order. Before Lyrical, qt6 wasn't supported, so rviz would always export and find qt5. Even if qt6 was installed on the system, it wouldn't be an issue.

The problem only comes when you are building against a version of rviz that supports both qt5 and qt6, and qt5 is exported from rviz, eventually if qt6 is installed in your environment when building Nav2, it can end up picking qt6 instead, and that is where things start to break.

[SteveMacenski]

So what should we do in Nav2's code to support both 24.04/Jazzy and 26.04/Lyrical on main?

[mini-1235]

A bit busy today, so I didn't get a chance to respond to all the PRs. I will try to get through them within this week. I am spending some time on this now before going to bed, hopefully I can get CI green again so I don't block others.

So what should we do in Nav2's code to support both 24.04/Jazzy and 26.04/Lyrical on main?

Nothing I think. My PR a few months ago should already handle this properly, so most people shouldn't run into build issues.

A minority(I think the Tier3 platform in REP) might still hit the issue I described above, but I think the right fix is upstream. Given I am not too familiar with the Qt APIs and don't really have time to go through that many repos, my suggestion is:

• Pin rviz version temporarily in rolling
• Do nothing for Jazzy + Kilted, but add new .repos files so the workflow passes (since it needs a source build of BT.CPP)

Does that make sense to you?

[SteveMacenski]

yes that makes sense! Let me know when I should look again, but so far so good

[mini-1235]

I see the workflows are passing, except for circle ci, so this is ready to review and merge right now.

I am on the way to the airport so I probably can't do any push if you want me to fix something

[mini-1235]

I think the rosdep install still needs to comment out, iirc that's what causing the update image workflow to fail