Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/qualcomm-qrb-ros/qrb_ros_simulation/llms.txt

Use this file to discover all available pages before exploring further.

QRB ROS Simulation exposes its internal Gazebo state to the rest of the ROS graph through a set of bridged topics managed by the ros-gz stack. This page documents every topic the simulation publishes and the single topic it subscribes to for robot control. Not all topics are active for every launch — sensor topics are only bridged when their corresponding sensor is enabled and the robot model supports it.
If you launch with a non-empty namespace parameter, every topic listed here is prefixed with that namespace. For example, setting namespace:=robot1 produces /robot1/scan instead of /scan.

Published topics

These topics are produced by the simulation and consumed by your ROS application.

Always available

The following topics are published regardless of robot model or sensor configuration.
TopicTypeDescription
/clockrosgraph_msgs/msg/ClockSimulation time, sourced from Gazebo and bridged to ROS. Required for any node using use_sim_time:=true.

Robot-base models

The following topics are published by all robot-base models: QRB Robot Base AMR, QRB Robot Base AMR Mini, and QRB Mobile Manipulator. They are not published by the standalone RML-63 Robotic Arm.
TopicTypeDescription
/tftf2_msgs/msg/TFMessageReal-time coordinate frame transforms broadcast by the robot state publisher.
/tf_statictf2_msgs/msg/TFMessageStatic coordinate frame transforms for fixed joints in the robot model.
/robot_descriptionstd_msgs/msg/StringURDF description of the robot model, published by robot_state_publisher.
/joint_statessensor_msgs/msg/JointStateCurrent position and velocity of all joints in the robot model.
The RML-63 Robotic Arm also publishes /robot_description, /tf, /tf_static, and /joint_states — these come from the ros2_control controller stack rather than the differential driver bridge, and are available after the controllers are loaded.

Camera topics

Camera topics are available on models with camera support: the RML-63 Robotic Arm, QRB Robot Base AMR Mini, and QRB Mobile Manipulator. The standard QRB Robot Base AMR does not include cameras. Camera topics are only bridged when enable_rgb_camera or enable_depth_camera is set to "true" (both default to "true" on supported models).
TopicTypeDescription
/camera/color/camera_infosensor_msgs/msg/CameraInfoIntrinsic calibration parameters for the RGB camera.
/camera/color/image_rawsensor_msgs/msg/ImageRaw image stream from the RGB camera.
/camera/depth/camera_infosensor_msgs/msg/CameraInfoIntrinsic calibration parameters for the depth camera.
/camera/depth/image_rawsensor_msgs/msg/ImageRaw depth image stream from the depth camera.
/camera/depth/pointssensor_msgs/msg/PointCloud23D point cloud generated from the depth camera.

Conditional sensor topics

These topics are published on robot-base models when the corresponding sensor is enabled at launch time.
TopicTypeEnabled whenDescription
/scansensor_msgs/msg/LaserScanenable_laser:=trueLiDAR scan data from the simulated laser sensor.
/imusensor_msgs/msg/Imuenable_imu:=trueIMU data including linear acceleration and angular velocity.
/odomnav_msgs/msg/Odometryenable_odom:=trueOdometry data including estimated position and velocity.

Subscribed topics

The simulation subscribes to one topic for robot motion control.
TopicTypeAvailable onDescription
/cmd_velgeometry_msgs/msg/TwistAMR modelsVelocity commands for the differential drive controller. Publish linear and angular velocity to move the robot.

Inspecting topics at runtime

Use the standard ros2 topic commands to inspect the simulation’s topic graph. List all active topics:
ros2 topic list
Echo the LiDAR scan:
ros2 topic echo /scan
Check the publishing rate of a topic:
ros2 topic hz /odom
Print the full message type definition:
ros2 topic info /cmd_vel --verbose
Run with use_sim_time:=true on any node that needs to stay synchronized with the Gazebo clock. Nodes that do not set this parameter use wall-clock time and may behave unexpectedly with simulation data.

Build docs developers (and LLMs) love