Coming back to this thread in 2026, it is fascinating to see how well the original decision to use Protocol Buffers for ign-transport (now Gazebo Transport) has aged. Protobuf’s performance, simplicity, and multi-language/MLOps friendliness have proven indispensable.
However, as many in the community have experienced over the years, the divergence between Gazebo speaking Protobuf and ROS 2 speaking DDS/CDR created an unfortunate architectural divide. The resulting ros_gz_bridge ros_gz/ros_gz_bridge/README.md at ros2 · gazebosim/ros_gz · GitHub has to deserialize gz::msgs, copy fields into ROS 2 .msg structs, and serialize into CDR—which becomes a noticeable CPU and latency bottleneck for high-frequency sensors like 4K cameras or high-beam Lidars.
Historically, people often framed the solution as either “Gazebo should adopt DDS” (which Open Robotics rightly resisted) or “live with the bridge marshaling penalty”.
Recently, we’ve been exploring the third possibility: What if ROS 2 natively embraces Protobuf without modifying ros2core or RMW vendors?
We recently announced our work on protoros2 Announcing protoros2: use protobuf in ros2 without compromise. One relevant architectural takeaway for the Gazebo ecosystem is:
- Zero-conversion on stock RMW: Even under default RMWs (rmw_fastrtps_cpp / rmw_cyclonedds_cpp), ROS 2’s publish_serialized API can pass raw Protobuf bytes directly as an opaque payload.
- Direct consumption: Subscribing nodes leveraging SerializedMessage callbacks can parse directly into C++ Protobuf objects with 0 intermediate .msg conversions and 0 extra field copies.
If this concept were applied to ros_gz_bridge (for instance, as an opt-in direct_proto fast-path mode for heavy sensor streams), gz::msgs could flow from Gazebo through the ROS 2 transport directly into downstream perception nodes with virtually zero translation overhead.
I thought this perspective might be interesting to those who followed this design debate. The historical gap between Gazebo’s transport and ROS 2 doesn’t necessarily have to be paid in CPU conversion cycles anymore!