ros_gz_bridge — Gazebo ↔ ROS 2 bridge

ros_gz_bridge — why it’s needed

ros2 run ros_gz_bridge parameter_bridge \
  /drone/tf_luna_down@sensor_msgs/msg/LaserScan[gz.msgs.LaserScan

You’re right — the output is unreadable for a human. But it isn’t for you — it’s for ROS 2 nodes.

The problem: Gazebo and ROS 2 speak different languages:

Gazebo:  gz.msgs.LaserScan        ← its own format
ROS 2:   sensor_msgs/LaserScan    ← its own format

The bridge is the translator between them:

Gazebo topic → bridge translates → ROS 2 topic
/drone/tf_luna_down (Gazebo) → /drone/tf_luna_down (ROS 2)

After the bridge, your sensor_monitor.py can read sensor data from Gazebo.

Streaming data from multiple sensors

ros2 run ros_gz_bridge parameter_bridge \
  /drone/tf_luna_down@sensor_msgs/msg/LaserScan[gz.msgs.LaserScan \
  /drone/vl53l0x/ch0@sensor_msgs/msg/LaserScan[gz.msgs.LaserScan

Bridge for the drone’s position

ros2 run ros_gz_bridge parameter_bridge \
  /world/indoor_room/pose/info@geometry_msgs/msg/PoseArray[gz.msgs.Pose_V

Command breakdown:

parameter_bridge — bridge program
/world/indoor_room/pose/info — topic in Gazebo
@ — separator
geometry_msgs/msg/PoseArray — type in ROS 2
[ — direction: from Gazebo to ROS 2
gz.msgs.Pose_V — type in Gazebo

Verify:

ros2 topic echo /world/indoor_room/pose/info

Add the bridge to a launch file

/home/aleks/git/proj/claudedrone/simulation/src/drone_sim/launch/drone.launch.py:

# Bridge — Gazebo <-> ROS 2
Node(
    package='ros_gz_bridge',
    executable='parameter_bridge',
    name='gz_bridge',
    arguments=[
        '/world/indoor_room/pose/info'
        '@geometry_msgs/msg/PoseArray'
        '[gz.msgs.Pose_V',
        '/clock'
        '@rosgraph_msgs/msg/Clock'
        '[gz.msgs.Clock',
    ],
    output='screen'
),

Now everything is set up in the launcher.