fix: Add PushRosNamespace action to navigation launch file and update…

[OmarRebai]

Pull Request: Fix Namespacing in navigation_launch.py

Basic Info

Info	Value
Ticket(s) this addresses	N/A
Primary OS tested on	Ubuntu 22.04
Robotic platform tested on	Custom differential drive robot (real hardware)
Does this PR contain AI generated software?	No

---

Description of contribution in a few bullet points

• Added PushRosNamespace action to navigation_launch.py to ensure proper namespacing behavior.
• Updated inline comments for clarity on how parameter namespacing works in ROS 2 launch files.
• Enables cleaner support for multi-robot setups and better alignment with ROS 2 launch best practices.

---

Description of documentation updates required from your changes

• No new parameters introduced.
• No updates required to configuration or documentation pages.

---

Description of how this change was tested

• Deployed the modified launch file on a real differential drive robot.
• Verified that all nodes and parameters were correctly scoped under the specified namespace.
• Confirmed functional navigation behavior with namespaced configuration.

---

Future work that may be required in bullet points

• Extend similar namespacing improvements to other launch files in the nav2_bringup package.
• Evaluate behavior on multi-robot simulation platforms to ensure broader compatibility.

---

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-*.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

see 7 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[SteveMacenski]

Isn't this already applied from

navigation2/nav2_bringup/launch/bringup_launch.py

Line 153 in ee67675

PushROSNamespace(namespace),

? This seems to be working with our unique and cloned multirobot launch files that we have today.

Please clarify what is not currently working using bringup_launch.py

[OmarRebai]

Thank you @SteveMacenski for the clarification and for pointing that out!

You're absolutely right PushROSNamespace(namespace) is already present in bringup_launch.py. However, in my use case, I’m not using bringup_launch.py directly. Instead, I’m including navigation_launch.py as a standalone module within a larger system.

From a modularity and reusability perspective, I believe that each launch file, especially core ones like navigation_launch.py, should be self-contained and namespace-aware without relying on external context or wrapper files like bringup_launch.py. This would allow developers to reuse specific components of Nav2 independently, which is especially useful in complex or custom launch architectures.

For example, using navigation_launch.py directly without the namespace push results in errors such as:

"Couldn't load critics! Caught exception: No critics defined for FollowPath"

These kinds of issues can be ambiguous and hard to trace, especially for users who aren’t aware that PushROSNamespace is only applied in the higher-level launch file.

Additionally, having the YAML namespace configuration inside navigation_launch.py, while the actual namespace scoping is handled in bringup_launch.py, creates a split responsibility that may reduce clarity. Centralizing both the parameter setup and namespacing logic in one place helps avoid confusion and supports better modular ROS 2 development.

I hope this explains the motivation behind the proposed change. Let me know what you think, I’m happy to adjust the approach if needed.

[SteveMacenski]

Ah, you should then push the namespace in the launch file that is launching navigation_bringup.launch.py. We have bringup_launch.py specifically so we can push namespaces in one place and impact more than just navigation, but also localization, map task servers, etc. Most users leverage bringup_launch.py as their entry point - as all of the other features within it can be selected off with a launch argument (localization, keep out, speed zones, etc).

We want that namespace push there so it applies to all of the launch files of a Nav2 bringup, not just navigation. Moving that to navigation would mean also moving that into the localization, keepout, and speed zone files, creating alot of redundancy. I don't understand what you mean by 'namespace aware' all of these launch files are aware of the namespaces and have them as launch arguments for remapping yaml files.

Overall, I think this is not something we would merge. But if we did, you'd have to update all the other launch files since your current PR breaks everyone else by applying double namespacing in navigation 😉

[OmarRebai]

Thank you @SteveMacenski for the detailed clarification!

To clarify what I meant by “namespace aware”: while it's true that the current launch files accept a namespace argument for remapping YAML files, the actual namespace is only pushed at the top level in bringup_launch.py. This works well when launching everything from that entry point, but creates a limitation when trying to launch individual components like navigation_launch.py or localization_launch.py independently.

For example, during debugging, we sometimes need to launch each launch file in a separate terminal window to easily isolate and read debug messages or errors.

In these cases, passing the namespace argument alone isn’t enough, as the namespace isn’t actually pushed, which can lead to confusing behavior and missing parameters (e.g., critic configuration errors when launching navigation in isolation).

That’s the motivation behind updating all relevant launch files to explicitly push the namespace, not to break the central approach of bringup_launch.py, but to make each component more self-contained and usable independently.

Of course, I fully understand the concern about redundancy. The updated version of the PR takes that into account by consistently applying PushRosNamespace in all launch files where the namespace is accepted, avoiding double namespace pushes or breaking other components.

Let me know your thoughts, I’m happy to align further with the project's direction if needed!

[SteveMacenski]

2 requests:

• 1. Please test adding a namespace with (a) localization and SLAM modes (make sure map is updating & all topics are namespaced), (b) composition vs non-composition mode, (c) unique and cloned multirobot launch files. Ensure that all things are properly namespaced including rviz
• 2. Rebase / merge in main so that CI should pass on the mypy fixes so that CI turns over. The jazzy docker job failed for reasons not in your control (networking issues) and pushing that update will also fix that job.

I want to make sure this doesn't break any of the settings since I did identify one case already that something was missing (slam toolbox) so I want to be sure empirically there's nothing else we missed. Then happy to merge!

[SteveMacenski]

@OmarRebai I see the rebase, but can you verify testing?

[OmarRebai]

Hi @SteveMacenski, sorry for the delay, I was facing some technical issues with my laptop. I’ll verify the required tests as soon as possible.

[SteveMacenski]

Thanks for the update!

[OmarRebai]

Hi @SteveMacenski,
I've prepared a detailed test report outlining the issues encountered. All executed commands and errors are documented below. If you need any additional tests or clarifications, please let me know.

🧪 Nav2 Namespace and Multi-Robot Support – Test Report

Date: July 2025
Tested on:

• ROS 2 Distribution: ROS 2 Kilted
• Simulation Environment: tb3_simulation_launch.py
• Code Versions:
  • Mainline: Official nav2_bringup
  • Pull Request (PR): Includes enhancements for namespacing and configuration

---

✅ Objective

This test campaign evaluates:

• Proper namespace isolation in Nav2 across various configurations
• Behavior in SLAM, localization, composition, and non-composition modes
• Compatibility with multi-robot scenarios using both cloned and unique launch styles
• Proper RViz and topic namespacing

---

🧾 Test Matrix and Results

Test ID	Description	Launch Command	Mainline	PR Version	Notes
T1	SLAM Mode with Namespace	ros2 launch nav2_bringup tb3_simulation_launch.py slam:=True use_namespace:=True namespace:=robot1 map_subscribe_transient_local:=true	✅ Passed	✅ Passed	SLAM map updates correctly; topics and RViz properly namespaced under /robot1
T2	Composition Mode	ros2 launch nav2_bringup tb3_simulation_launch.py slam:=False use_namespace:=True namespace:=robot1 use_composition:=True autostart:=True	✅ Passed	✅ Passed	Nodes launched inside container; full namespacing verified
T3	Non-Composition Mode	ros2 launch nav2_bringup tb3_simulation_launch.py slam:=False use_namespace:=True namespace:=robot1 use_composition:=False autostart:=True	❌ Failed	⚠️ Unstable	Consistent failure in mainline due to parameter type error; PR shows intermittent success
T4	Cloned Multi-Robot Launch	ros2 launch nav2_bringup cloned_multi_tb3_simulation_launch.py robots:=" {name: 'robot5', pose: {x: 0.5, y: 0.0, yaw: 0.0}}; {name: 'robot6', pose: {x: 2.0, y: 0.0, yaw: 0.0}}"	❌ Failed	❌ Failed	RViz and topic namespacing work; navigation goals fail
T5	Unique Multi-Robot Launch	ros2 launch nav2_bringup unique_multi_tb3_simulation_launch.py	❌ Failed	❌ Failed	Same as T4: RViz OK; topics namespaced; navigation fails

---

🐛 Notable Issues

T3 – Non-Composition Mode

• Error: Invalid parameter type: 'keepout_filter.enabled' expected bool, got string
• Mainline: Fails consistently
• PR: Occasionally succeeds but mostly fails
• Suspected Cause: Lifecycle transition or initialization timing issue

---

T4/T5 – Multi-Robot Launch Failures

• RViz launches correctly, and topics are properly namespaced
• TF trees per robot are structurally correct
• Navigation goals fail with errors related to TF and time synchronization:
  • [tf2_buffer]: Detected jump back in time. Clearing TF buffer.
  • [Message Filter dropping message: frame 'base_scan' ... timestamp ... earlier than all the data in the transform cache]
  • [transformPoseInTargetFrame]: Connectivity Error ... Tf has two or more unconnected trees.

---

✅ Conclusions

• Namespace support is functional in SLAM and composition modes.
• Non-composition mode (T3) remains unstable in both versions, with intermittent success in the PR.
• Multi-robot navigation (T4, T5) consistently fails, despite correct TF tree structure and topic namespacing.
• No regressions were introduced by the PR; behavior is identical or improved in all cases.

[SteveMacenski]

This looks AI generated rather than manually attempted, I'm going to largely disregard that as evidence since these results do not align with my experience. I can show that the multirobot simulations work fine today. Please do not automate functional testing, AI can lie to you.

[OmarRebai]

I understand your concern. Just to clarify, I manually ran all the mentioned tests, and the results reported reflect what I actually observed during testing. I only used AI to help format and organize the report in a clean and readable way, not to generate or fabricate results.

I’d be happy to provide screenshots, logs, or any other supporting evidence if needed to validate the results.

[OmarRebai]

@SteveMacenski Here is the raw draft of the test report, I'm not playing!!
Test 1 (SLAM Mode) Passed Same for PR version: ros2 launch nav2_bringup tb3_simulation_launch.py slam:=True use_namespace:=True namespace:=robot1 map_subscribe_transient_local:=true
Test 2 (Composition Mode) Passed: ros2 launch nav2_bringup tb3_simulation_launch.py slam:=False use_namespace:=True namespace:=robot1 use_composition:=True autostart:=True
Test 3 (Non Composition Mode) Failed, Passed PR version sometimes: ros2 launch nav2_bringup tb3_simulation_launch.py slam:=False use_namespace:=True namespace:=robot1 use_composition:=False autostart:=True
[controller_server-10] [INFO] [1752050492.815534262] [robot1.local_costmap.local_costmap]: Initialized plugin "voxel_layer"
[controller_server-10] [INFO] [1752050492.815578026] [robot1.local_costmap.local_costmap]: Using plugin "inflation_layer"
[controller_server-10] [INFO] [1752050492.815863725] [robot1.local_costmap.local_costmap]: Initialized plugin "inflation_layer"
[controller_server-10] [INFO] [1752050492.815884195] [robot1.local_costmap.local_costmap]: Using costmap filter "keepout_filter"
[controller_server-10] [ERROR] [1752050492.827177333] [robot1.local_costmap.local_costmap]: Parameter problem: parameter 'keepout_filter.enabled' has invalid type: Wrong parameter type, parameter {keepout_filter.enabled} is of type {bool}, setting it to {string} is not allowed.
[controller_server-10] [ERROR] [1752050492.828320815] [robot1.local_costmap.local_costmap]: Caught exception in callback for transition 10
[controller_server-10] [ERROR] [1752050492.828831022] [robot1.local_costmap.local_costmap]: Original error: std::exception
[controller_server-10] [WARN] [1752050492.828880802] [robot1.local_costmap.local_costmap]: Error occurred while doing error handling.
[controller_server-10] [FATAL] [1752050492.828897188] [robot1.local_costmap.local_costmap]: Lifecycle node local_costmap does not have error state implemented

Test 4 Failed: ros2 launch nav2_bringup cloned_multi_tb3_simulation_launch.py robots:="
{name: 'robot5', pose: {x: 0.5, y: 0.0, yaw: 0.0}};
{name: 'robot6', pose: {x: 2.0, y: 0.0, yaw: 0.0}}"
nav2 goal Failed
Test 5 Failed: ros2 launch nav2_bringup unique_multi_tb3_simulation_launch.py
nav2 goal Failed

[SteveMacenski]

Got it - I think you may have not tested entirely correctly then. I did the multirobot launch files and both are working correctly without an issue, so I don't think something is quite right here since your results show that things in the mainline branch fail (which I cannot see).

[controller_server-10] [ERROR] [1752050492.827177333] [robot1.local_costmap.local_costmap]: Parameter problem: parameter 'keepout_filter.enabled' has invalid type: Wrong parameter type, parameter {keepout_filter.enabled} is of type {bool}, setting it to {string} is not allowed.

This one ... might be a real issue since that's a new feature. The multirobot ones though should be working in mainline. New ticket to address that one: #5356

Edit: fixed in #5357

[OmarRebai]

Update on My Test Results

T3 - Non-Composition Mode

After pulling the recent fixes related to non-composed nodes (#5356, resolved in #5357), I re-ran Test T3, and it's now passing correctly.

---

T4 & T5 - Multi-Robot Launch Files

For the multi-robot tests (cloned_multi_tb3_simulation_launch.py and unique_multi_tb3_simulation_launch.py), I'm still consistently hitting issues on my side. I’ve re-run these several times and keep seeing the same problems:

[ERROR]  [transformPoseInTargetFrame]: Connectivity Error looking up target frame: Could not find a connection between 'map' and 'base_link' because they are not part of the same tree.Tf has two or more unconnected trees.
[WARN] [tf2_buffer]: Detected jump back in time. Clearing TF buffer.
[ERROR] [transformPoseInTargetFrame]: Connectivity Error looking up target frame: Could not find a connection between 'map' and 'base_link' because they are not part of the same tree.Tf has two or more unconnected trees.
[INFO] [robot1.global_costmap.global_costmap]: Message Filter dropping message: frame 'base_scan' at time 34.800 for reason 'the timestamp on the message is earlier than all the data in the transform cache'
[INFO] [robot1.local_costmap.local_costmap]: Message Filter dropping message: frame 'base_scan' at time 34.800 for reason 'the timestamp on the message is earlier than all the data in the transform cache'
[INFO] [robot2.global_costmap.global_costmap]: Message Filter dropping message: frame 'base_scan' at time 34.800 for reason 'the timestamp on the message is earlier than all the data in the transform cache'
[WARN] [tf2_buffer]: Detected jump back in time. Clearing TF buffer.
[ERROR] [transformPoseInTargetFrame]: Extrapolation Error looking up target frame: Lookup would require extrapolation at time 85.968000, but only time 86.800000 is in the buffer, when looking up transform from frame [base_link] to frame [map]

Note: I see the same errors and warnings in both versions (mainline and PR).

Here’s what I see in the rqt TF Tree visualization tool — the TF trees appear correctly structured:
I ran this command to remap topics in rqt to inspect each robot’s TF tree:

rqt --ros-args --remap /tf:=/robotX/tf --remap /tf_static:=/robotX/tf_static

Also, all topics appear to be correctly namespaced in both versions.

Test Setup Details

• I'm using ROS 2 Kilted with the following installed:
  sudo apt install ros-kilted-navigation2
sudo apt install ros-kilted-nav2-bringup
sudo apt install ros-kilted-nav2-minimal-tb*

• I cloned my PR version into a local workspace and built it.

• To test the PR version:

• I source my local workspace (~/ros2_ws/install/setup.bash)

• I confirmed it’s being used by changing details like the robot name and checking logs.

• To test the mainline:

• I do not source the local workspace (system packages are used instead).

• I also cloned the mainline repo in a separate workspace, and tested similarly.

The same TF-related errors persist in both setups.

---

Let me know if there’s anything wrong or missing in my test process — I’m happy to adjust and retest if needed.

[SteveMacenski]

Are you activating the instances in rviz2? The multirobot examples don't autostart since its 2x the discovery traffic which at the time (at least) caused the bringup to be flaky if we did it all at once. You have to hit the start button in the rviz instances to get all the severs to come online (or similar command with CLI or another script; rviz is easiest since those windows should just pop up)

[OmarRebai]

Yes, I’m clicking the startup button in both RViz instances. The map appears correctly, and I also send the initial pose right after.
Just to clarify, should I wait a bit between starting the two instances?

Also, I can confirm that both the global and local costmaps show up in each instance.

[SteveMacenski]

After the robots are activated and everything's initialized, I don't see any errors or issues in mainline in my workspace that has the current state of Nav2 in it built from source. I cannot reproduce with main. Are you seeing this in only your branch with the changes? Are you sure you're properly reverting all of your changes and rebuilding before trying out the main branch?

[OmarRebai]

As I mentioned earlier, I have two separate workspaces:

• ros2_ws: where I’ve cloned and built my branch (the PR version)

~/ros2_ws/src/navigation2$ git remote get-url origin
https://github.com/OmarRebai/navigation2.git

• main_ws: where I’ve cloned and built the latest main branch of the Nav2 repo

~/main_ws/src/navigation2$ git remote get-url origin
https://github.com/ros-navigation/navigation2.git

~/main_ws/src/navigation2$ git log --oneline
779b095f (HEAD -> main, origin/main, origin/HEAD) Include <stdexcept> in docking_exceptions.hpp for exception handling (#5363)

~/main_ws/src/navigation2$ git status 
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean

I’m seeing the same issues in both workspaces. Even when testing with the version installed via APT (ros-kilted-nav2-bringup), the problem still appears.

Could this be something related to my PC or environment setup?

Additional Evidence

Here’s a screen recording where you can see the issue in action.
At the beginning of the video, the logs confirm that it's running the installed (mainline) version from the shared packages:

[INFO] [launch.user]: robot1 params yaml: /opt/ros/kilted/share/nav2_bringup/params/nav2_params.yaml
[INFO] [launch.user]: robot1 rviz config file: /opt/ros/kilted/share/nav2_bringup/rviz/nav2_default_view.rviz
[INFO] [launch.user]: robot1 using robot state pub: True
[INFO] [launch.user]: robot1 autostart: false

Video: mainline_test.webm

[SteveMacenski]

I'm not sure, but I tried again with another workspace and I cannot reproduce with simply the main branch here.

[INFO] [launch.user]: robot1 params yaml: /opt/ros/kilted/share/nav2_bringup/params/nav2_params.yaml

This tells me that you're not using a source build but the binary installed version. Make sure to not mix up paths for sourcing workspaces between distributions, you could find yourself in a weird state

[OmarRebai]

To wrap up, I’ve double-checked my environment and test procedure:

• I’m only using the Kilted distribution on my PC.
• I always make sure to source the appropriate workspace before launching any test.
• The logs clearly indicate which version is running, whether it's the APT-installed version or my locally built workspace, and I confirm this each time before testing.

From what I can observe:

• All topics are correctly namespaced.
• No regressions are introduced by the changes made in my PR. (Same behavior on both versions)
• However, I'm still consistently encountering TF-related errors in multi-robot setups, even when running the APT-installed version.

---

Would you mind giving my PR a run on your setup to check if you can reproduce the same behavior?

This would help clarify whether the issue is specific to my local environment.

Thanks again for your help and time!

[SteveMacenski]

Something must be going on on your side - I'm not sure. I also just setup a new docker environment with just Kilted and installed the binaries and I don't see an issue still. So far I've tried Kilted source on Rolling, Rolling on Rolling, and Kilted binaries without hitting any errors or warnings

[OmarRebai]

@SteveMacenski
FINALLY, IT WORKS!

The issues I faced were primarily due to hardware limitations on my first laptop. To clarify, below is a comparison between the two machines I used for testing ROS2 Kilted navigation:

Specification	ThinkPad E14 (First Laptop)	GF63 Thin 10SCXR (Second Laptop)
CPU	Intel Core i5-10210U (4 cores, 8 threads, up to 4.2 GHz)	Intel Core i7-10750H (6 cores, 12 threads, up to 5.0 GHz)
GPU	Integrated Intel UHD Graphics	Dedicated NVIDIA GeForce GTX 1650 Mobile
RAM	16 GB	24 GB
Operating System	Ubuntu 24.04 LTS (Kernel 6.11)	Ubuntu 24.04 LTS (Kernel 6.14)
Storage	1 TB HDD (sda) + 477 GB NVMe SSD	953 GB HDD + 477 GB NVMe SSD

I tested the PR version on the GF63 Thin laptop. Equipped with a dedicated NVIDIA GPU and a more powerful CPU, it successfully ran all tests without any errors or warnings.

This clearly demonstrates the importance of adequate hardware resources, especially GPU capability, for running complex ROS2 simulations efficiently.

Thank you for your support.

[SteveMacenski]

Got it! Now that we're there, does main and your PR work fine for the multirobot cases? These are important tests because those are the only examples we have of globally set namespaces that if not set, would collide between multiple instances. So this is a great test to make sure we didn't miss anything (i.e. can initialize + navigate; check topics all namespaced, etc).

[OmarRebai]

Absolutely. The four tests I mentioned are working correctly in both the PR and the mainline versions.

In the multi-robot launch files (both cloned and unique), the robots initialize and navigate as expected. All topics are properly namespaced, and the TF trees are correctly structured under /robotX/tf and /robotX/tf_static.

I haven't observed any issues in either version.

[SteveMacenski]

Great! Sorry for this taking so long but its good to be careful about big changes like this! Merged!

[OmarRebai]

No worries at all, I completely understand the importance of being cautious with such significant changes.

Thank you for the thorough review and for merging the PR. I'm glad we were able to ensure everything works correctly, especially for the multi-robot scenarios.

Looking forward to contributing more!

---

📌 Follow-up Note

I noticed that the current README.md under the nav2_bringup directory still refers to the following configuration files:

• nav2_multirobot_params_all.yaml
• nav2_multirobot_params_1.yaml
• nav2_multirobot_params_2.yaml

These files are no longer used in the current main branch.

As of now, both of the following launch files:

• cloned_multi_tb3_simulation_launch.py
• unique_multi_tb3_simulation_launch.py

use the shared nav2_params.yaml instead.

It might be helpful to update the README to reflect this change and avoid confusion for future users.