gz_topic_name in cli to param_bridge

[aarsht7]

🎉 New feature

Summary

A quick feature that I needed, so here it is, in case it seem useful to the audience,

It adds the possibility of considering gz_topic_name through CLI/launch arguments if it differs from the ros_topic_name or vice-versa.

The syntax is /ROS2_TOPIC@ROS_MSG@GZ_MSG@/GZ_TOPIC, such that ROS2_TOPIC is the name of the ROS 2 topic, GZ_TOPIC is the Gazebo internal topic, ROS_MSG is the ROS message type for this topic, and GZ_MSG is the Gazebo message type.

It is optional if ROS 2 and GZ topic names are the same and can be neglected.

Test it

ros2 run ros_gz_bridge parameter_bridge /ros/chatter@std_msgs/msg/String@gz.msgs.StringMsg@/gz/chatter
OR
ros2 run ros_gz_bridge parameter_bridge /ros/chatter@std_msgs/msg/String]gz.msgs.StringMsg@/gz/chatter
OR
ros2 run ros_gz_bridge parameter_bridge /ros/chatter@std_msgs/msg/String[gz.msgs.StringMsg@/gz/chatter

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[ahcorde]

hi @aarsht7

There are several things here:

• This will break other user, we can't include this feature in Humble
• If you want to include this you can open a PR againt rolling but
• you already have this behaviour

ros2 run parameter_bridge /chatter@std_msgs/msg/String@gz.msgs.StringMsg --ros-args -r /chatter:=<your desired new ros topic>

Can you try this last tip and see if this work in your use case.

[aarsht7]

Hello @ahcorde ,

I tested it thoroughly, and it does not break the existing behavior on ros humble (at least not on the tests I performed and for my use cases)
I can also create a PR for rolling if it seems like a useful feature.

Here is the scenario of why I needed this.

I am using simulation to dynamically add the bridge for the topics using a launch file to develop a multi-robot simulation that depends on the number of robots and the types of robots.

I am creating a list of topics to bridge dynamically and passing it to the parameter_bridge node as an argument in my launch file.

For most of the sensors, I can change the topic names in sdf file with the namespace and all, but some of the gz-system plugins do not allow the change of the topic name with the tag, and data is published with some weird gz topic names, e.g./model/robot_A_1/battery/robot_A_1/state (I can not find <topic> tag in class ref of linear battery plugin)

So, to make it more readable and easier for the end-user, I am doing the following in my launch file (this is just an example code) using the changes I have made in PR

robots  = {'A': 2, 'B': 3, 'C': 1}
bridge_topics = [ ]
for key in robots:
    for i in range(1,robots[key]+1):     
        bridge_topics.append(f"/robot_{key}_{i}/battery@sensor_msgs/msg/BatteryState[gz.msgs.BatteryState@/model/robot_{key}_{i}/battery/robot_{key}_{i}/state")

Node(
        package="ros_gz_bridge",
        executable="parameter_bridge",
        arguments=bridge_topics,
        output="screen",
    )