fix: Changed cloned_multi_tb3_simulation_launch.py file to conform with common ROS 2 launch syntax

[TannerGilbert]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	#4803
Primary OS tested on	Ubuntu 24.04, ROS Rolling
Robotic platform tested on	Turtlebot3
Does this PR contain AI generated software?	No

---

Description of contribution in a few bullet points

• Changed cloned_multi_tb3_simulation_launch.py file to conform with common ROS 2 launch syntax and thereby allow for including it in other launch files as expected.
• Made robots a required launch argument

Description of documentation updates required from your changes

None

---

Future work that may be required in bullet points

I would prefer that the headless and SLAM options are added to this script similar to how it's handled in the tb3_simulation_launch.py file

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

see 4 files with indirect coverage changes

[SteveMacenski]

I'm not sure this is the best way to handle the problem. I think what makes more sense is to have the parsing nav2_common utility be a proper launch substitution https://github.com/ros2/launch_ros/tree/rolling/launch_ros/launch_ros/substitutions. I think that would make this work better and be in the intended launch file's declarative style (rather than trying to get around it using opaque functions). If we're going to try to circumnavigate declarative programming, I think we might be better off using the current styling instead since its more clear to new developers and is equally as circumnavigated

[TannerGilbert]

I'm not sure this is the best way to handle the problem. I think what makes more sense is to have the parsing nav2_common utility be a proper launch substitution https://github.com/ros2/launch_ros/tree/rolling/launch_ros/launch_ros/substitutions. I think that would make this work better and be in the intended launch file's declarative style (rather than trying to get around it using opaque functions). If we're going to try to circumnavigate declarative programming, I think we might be better off using the current styling instead since its more clear to new developers and is equally as circumnavigated

I'll have a look at this. Thanks for the feedback

[mergify]

@TannerGilbert, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[mergify]

@TannerGilbert, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[TannerGilbert]

@SteveMacenski sorry for the delay. I had a look at how to write a custom substitution class and tried to refactor the ParseMultiRobotPose accordingly. Still, as a dict is needed in the launchfile to the bringup_cmd_group list I wasn't fully able to remove the OpaqueFunction. Maybe my ROS knowledge is insufficient. I would be glad for any feedback and sorry for the inconvenience.

[SteveMacenski]

OK - we can use the opaque function method!

[SteveMacenski]

Please rebase / pull in main and that should make CI turn over. TF2 had some API changes we fixed over the weekend

[mergify]

@TannerGilbert, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[TannerGilbert]

I updated the PR based on the change request. Thanks for all the feedback and patience.

[SteveMacenski]

Very minor changes, but LGTM!

Last thing is to add this to our migration guide so people know about these changes! https://docs.nav2.org/migration/Jazzy.html

[SteveMacenski]

@TannerGilbert just sanity check me that you tested that the default works now after the updates & that it works when you specify some other robot parameters? We don't have system tests that run the multirobot case, so I just want to have that verified explicitly before I merge.

[TannerGilbert]

@TannerGilbert just sanity check me that you tested that the default works now after the updates & that it works when you specify some other robot parameters? We don't have system tests that run the multirobot case, so I just want to have that verified explicitly before I merge.

Yes I checked after doing the changes that the behaviour didn't change. For a bit more detail when running ros2 launch nav2_bringup cloned_multi_tb3_simulation_launch.py one should get the two robots in the default position and in the command line there will be the following output:

Launching namespace=robot1 init_pose={'x': 0.5, 'y': 0.5, 'yaw': 0, 'z': 0.0, 'roll': 0.0, 'pitch': 0.0}
Launching namespace=robot2 init_pose={'x': -0.5, 'y': -0.5, 'z': 0, 'roll': 0, 'pitch': 0, 'yaw': 1.5707}

When supplying a custom position like ros2 launch nav2_bringup cloned_multi_tb3_simulation_launch.py robots:="robot1={x: 1.0, y: 1.0, yaw: 1.5707}" the output changes accordingly.

Launching namespace=robot1 init_pose={'x': 1.0, 'y': 1.0, 'yaw': 1.5707, 'z': 0.0, 'roll': 0.0, 'pitch': 0.0}

[SteveMacenski]

Thanks for the efforts and getting this to completion! I pride myself that Nav2 is generally a 'best practices' ROS 2 codebase as an example, so its really good to fix this up to be in line with the best practices. Thanks for your time!