[RFC] New Hardware Interface: Native gz-transport bridge for Multi-Domain / Network-Isolated Simulation

[yenode]

Context: Currently, gz_ros2_control runs the controller manager inside the Gazebo process and relies on shared memory. This is highly efficient but presents limitations for multi-robot fleets, custom network-isolated state estimators, and distributed simulation setups where the ROS_DOMAIN_ID must be strictly separated from Gazebo's transport layer.

Proposal: I've developed a lightweight "data diode" hardware interface (emcon_gz_hardware_interface). It acts as a standard SystemInterface in the ros2_control framework, but instead of using shared memory, it communicates directly with Gazebo using gz-transport.

Key Features:

• Bypasses RMW entirely for simulation comms.
• Lock-free RT loop using realtime_tools::RealtimeBuffer ensuring read() never blocks.
• O(1) joint lookups during high-frequency Gazebo state callbacks.
• Fully parameterized via standard <ros2_control> URDF tags (bot_name, world_name, joint_state_topic).

Working Implementation: I have a clean, working repository here: https://github.com/yenode/emcon_gz_hardware_interface

Questions for Maintainers:

1. Would you be interested in merging this as an alternative hardware interface within the gz_ros2_control meta-package?
2. Are there specific CI, formatting, or architectural adjustments you'd require before I open a PR?

[christophfroehlich]

Not commenting on the idea now, just to

2. Are there specific CI, formatting, or architectural adjustments you'd require before I open a PR?

https://control.ros.org/rolling/doc/contributing/contributing.html

and having a look at the current tests

[yenode]

I have implemented comprehensive testssuite of 7 C++ unit and integration tests in the standalone repository using ament_cmake_gtest.

The tests verify:

• Lifecycle & Plugin Loading: Correct registration and state transitions via ResourceManager.
• Parameter Validation: Handling of mandatory URDF tags (bot_name, world_name).
• Data Flow Integration: I added a DataFlowPubSub integration test that uses a mock gz::transport::Node to verify that commands are correctly published to the Gazebo network and that incoming joint states are correctly reflected in the ROS 2 interfaces.

You can see the implementation and the passing CI runs here: https://github.com/yenode/emcon_gz_hardware_interface/actions

Is there anything else you would like me to adjust?

[yenode]

@christophfroehlich Just checking in on this RFC.

Since the standalone package is implemented and the gtest suite is passing locally, I'd love to get your guidance on the best path forward for the ecosystem integration.

In your view, does a rmw-bypassing interface like this belong as a package directly within the gz_ros2_control repository, or would Open Robotics prefer this to live as an independent package elsewhere?