Dynamic ros gz bridges by Tuxliri · Pull Request #910 · gazebosim/ros_gz

Tuxliri · 2026-06-27T12:00:26Z

🎉 New feature

Closes #849

Summary

Adds opt-in dynamic discovery of Gazebo Transport topics to ros_gz_bridge.

When create_dynamic_bridges is enabled, the bridge periodically:

Discovers Gazebo topics using TopicList and TopicInfo.
Maps supported Gazebo message types using the existing generated mappings.
Creates bridges for topics that appear after startup.
Prevents duplicate bridge creation.
Ignores unsupported or ambiguous message types.

Dynamic bridges default to GZ_TO_ROS. The direction can be changed using
dynamic_bridge_direction, including BIDIRECTIONAL.

parameter_bridge can now run without positional topic arguments when dynamic
bridging is enabled.

Usage

ros2 run ros_gz_bridge parameter_bridge \
  --ros-args \
  -p create_dynamic_bridges:=true

Publish from Gazebo:

gz topic -t /hello_dynamic_bridge \
  -m gz.msgs.StringMsg \
  -p 'data: "hello from Gazebo"'

Observe from ROS:

ros2 topic echo /hello_dynamic_bridge std_msgs/msg/String

Tests

Added launch integration tests covering:

Discovery of topics created after bridge startup.
Gazebo-to-ROS message delivery.
Bidirectional ROS and Gazebo delivery.
Duplicate bridge prevention.
Unsupported message types.
A burst of 50 ordered messages without duplicates.
Isolation from other ROS and Gazebo processes.

The tests use separate GZ_PARTITION and ROS_DOMAIN_ID values.

source /opt/ros/rolling/setup.bash

colcon build --packages-select ros_gz_bridge \
  --cmake-args -DBUILD_TESTING=ON

source install/setup.bash
colcon test --packages-select ros_gz_bridge
colcon test-result --all --verbose

Local result:

100% tests passed, 0 tests failed out of 20

Backport Policy

This should not be backported

This is a Jetty roadmap feature introducing new parameters and behavior.

Checklist

Note to maintainers: Please use Squash-Merge and retain the
Signed-off-by and Generated-by trailers.

azeey · 2026-07-06T14:56:00Z

Hi @Tuxliri, thanks for the contribution. However, as mentioned in #849, the issue is actively being worked on by a GSoC student @C88-YQ. To avoid duplication of work, I recommend finding other Github issues to contribute to.

Tuxliri · 2026-07-14T04:31:55Z

Hi @azeey, gotcha. If @C88-YQ hasn’t coded this in yet the PR is pretty much ready for review, I have tested it and is working fine on my side. Might take this task off his plate.

Signed-off-by: Davide Iafrate <dvde.iafrate98@gmail.com>

Generated-by: OpenAI Codex (GPT-5) Signed-off-by: Davide Iafrate <dvde.iafrate98@gmail.com>

azeey · 2026-07-16T15:48:22Z

@C88-YQ will be reviewing this

C88-YQ · 2026-07-21T09:26:44Z

+  ASSERT_TRUE(gzNode.Subscribe<gz::msgs::StringMsg>(
+    topic,
+      [&mutex, &gzMessages](const gz::msgs::StringMsg & _msg)
+      {
+        std::lock_guard<std::mutex> lock(mutex);
+        gzMessages.push_back(_msg.data());
+    }));


Suggested change

ASSERT_TRUE(gzNode.Subscribe<gz::msgs::StringMsg>(

topic,

[&mutex, &gzMessages](const gz::msgs::StringMsg & _msg)

{

std::lock_guard<std::mutex> lock(mutex);

gzMessages.push_back(_msg.data());

}));

std::function<void(const gz::msgs::StringMsg &)> gzCallback =

[&mutex, &gzMessages](const gz::msgs::StringMsg & _msg)

{

std::lock_guard<std::mutex> lock(mutex);

gzMessages.push_back(_msg.data());

};

ASSERT_TRUE(gzNode.Subscribe(topic, gzCallback));

I hit a build failure with gz-transport16 here. The migration notes mention that Node::Subscribe changed to a forwarding wrapper in newer gz-transport versions: Migration.md.

Perhaps we can change it like this to make it compatible across different gz-transport versions

Good catch, I was mistakenly building against Jetty

The regression is tracked in gazebosim/gz-transport#880

C88-YQ · 2026-07-21T10:08:55Z

+  bool create_dynamic_bridges = false;
+  bridge_node->get_parameter("create_dynamic_bridges", create_dynamic_bridges);
+  if (filteredArgs.empty() && !create_dynamic_bridges) {
+    usage();
+    return -1;
+  }
+


This change seems to break the existing config-file-only usage:

ros2 run ros_gz_bridge parameter_bridge --ros-args -p config_file:=$WORKSPACE/ros_gz/ros_gz_bridge/test/config/full.yaml

Adding a check for empty config file string.

C88-YQ · 2026-07-21T10:50:50Z

+  const auto direction_str = this->get_parameter("dynamic_bridge_direction").as_string();
+  const auto direction = parse_bridge_direction(direction_str);


I wonder if we should consider determining the bridge direction automatically instead. Since Gazebo and ROS topics may have different directions depending on the specific topic, relying on a single dynamic_bridge_direction for all topics might not be flexible enough.

We could potentially infer the direction based on the publishers and subscribers of each topic. For example, if a topic only has a publisher on the Gazebo side, it could be bridged as GZ_TO_ROS; if it only has subscribers on the Gazebo side, it could be ROS_TO_GZ; and if both exist, we could fall back to BIDIRECTIONAL for now.

Do you suggest to automatically bridge all compatible ROS topics to Gazebo?

Or just supporting a mix of GZ_TO_ROS and ROS_TO_GZ based on the gazebo topic direction?

C88-YQ · 2026-07-21T11:02:00Z

+    std::set<std::string> gz_type_names;
+    for (const auto & publisher : publishers) {
+      const auto gz_type_name = publisher.MsgTypeName();
+      if (!gz_type_name.empty()) {
+        gz_type_names.insert(gz_type_name);
+      }
+    }


It looks like the current implementation only supports automatically bridging topics published from Gazebo, while topics subscribed by Gazebo are not handled in the same way. This might be another case we need to consider.

We could potentially apply the same logic to the subscribers information from TopicInfo and get the gz_type_name from there as well.

C88-YQ · 2026-07-23T13:55:02Z

+  bool lazy;
+  this->get_parameter("lazy", lazy);


I think the default lazy state for dynamically created bridges should be true. Otherwise, it may cause unnecessary overhead, especially when there are many topics.

…age in main

…cribe method

azeey added this to Core development Jun 27, 2026

github-project-automation Bot moved this to Inbox in Core development Jun 27, 2026

Davide Iafrate added 2 commits July 16, 2026 11:37

feat(ros_gz_bridge): dynamically bridge Gazebo topics

ce0e29c

Signed-off-by: Davide Iafrate <dvde.iafrate98@gmail.com>

test(ros_gz_bridge): cover dynamic bridge discovery

2be4169

Generated-by: OpenAI Codex (GPT-5) Signed-off-by: Davide Iafrate <dvde.iafrate98@gmail.com>

Tuxliri force-pushed the dynamic-ros-gz-bridges branch from 497e09e to 2be4169 Compare July 16, 2026 11:39

Tuxliri marked this pull request as ready for review July 16, 2026 11:53

Tuxliri requested a review from ahcorde as a code owner July 16, 2026 11:53

C88-YQ reviewed Jul 21, 2026

View reviewed changes

C88-YQ reviewed Jul 23, 2026

View reviewed changes

Davide Iafrate added 2 commits July 30, 2026 15:03

fix(ros_gz_bridge): ensure config file existence is checked before us…

59f900c

…age in main

refactor(test_dynamic_bridge): use std::function for callback in Subs…

119c403

…cribe method

		const auto direction_str = this->get_parameter("dynamic_bridge_direction").as_string();
		const auto direction = parse_bridge_direction(direction_str);

Uh oh!

Conversation

Tuxliri commented Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🎉 New feature

Summary

Usage

Tests

Backport Policy

Checklist

Uh oh!

azeey commented Jul 6, 2026

Uh oh!

Tuxliri commented Jul 14, 2026

Uh oh!

azeey commented Jul 16, 2026

Uh oh!

C88-YQ Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

C88-YQ Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Tuxliri commented Jun 27, 2026 •

edited

Loading

C88-YQ Jul 21, 2026 •

edited

Loading

C88-YQ Jul 21, 2026 •

edited

Loading