RoboTerrain uses a layered topic architecture that connects three distinct systems: the Ignition Gazebo simulator, the RL training agent, and the MetricsNode monitoring system. Gazebo publishes raw sensor and state data (odometry, LIDAR, IMU, camera frames, ground-truth pose) which are bridged into the ROS 2 graph viaDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/jackvice/RoboTerrain/llms.txt
Use this file to discover all available pages before exploring further.
ros_gz_bridge. The RL agent consumes these topics to build observations and publishes velocity commands back to the robot. In parallel, the MetricsNode subscribes to a subset of these topics to compute collision, smoothness, and traversal metrics that are streamed to CSV for offline analysis. The PoseConverterNode (ign_ros2_Nav2_topics.py) sits between Gazebo and the rest of the stack, translating raw Gazebo dynamic-pose messages into standard ROS 2 types and broadcasting the corresponding TF transform tree.
Simulation Bridge Topics
Theros_gz_bridge node translates topics between the Ignition Gazebo message system and ROS 2. The bridge arguments use @ for bidirectional topics, [ for Gazebo → ROS 2 (subscribe from Gazebo), and ] for ROS 2 → Gazebo (publish to Gazebo). The table below documents every bridged topic in 4wd_rover_gazebo.launch.py.
| Topic | ROS 2 Message Type | Direction | Ignition Type | Description |
|---|---|---|---|---|
/cmd_vel | geometry_msgs/msg/Twist | Bidirectional (@) | ignition.msgs.Twist | Linear and angular velocity commands sent to the robot drive system |
/clock | rosgraph_msgs/msg/Clock | Gazebo → ROS 2 ([) | ignition.msgs.Clock | Simulation clock; consumed by all nodes running with use_sim_time:=true |
/odometry/wheels | nav_msgs/msg/Odometry | Bidirectional (@) | ignition.msgs.Odometry | Wheel-encoder odometry published by the Gazebo differential drive plugin |
/tf | tf2_msgs/msg/TFMessage | Gazebo → ROS 2 ([) | ignition.msgs.Pose_V | Robot joint and link transforms; populates the TF tree for sensor fusion |
/joint_states | sensor_msgs/msg/JointState | Gazebo → ROS 2 ([) | gz.msgs.Model | Per-joint position, velocity, and effort values for all robot joints |
/scan | sensor_msgs/msg/LaserScan | Bidirectional (@) | gz.msgs.LaserScan | 2-D LIDAR scan data; used by MetricsNode for collision detection and by Nav2 for obstacle avoidance |
/imu/data | sensor_msgs/msg/Imu | Bidirectional (@) | gz.msgs.IMU | Raw IMU linear acceleration and angular velocity; used by MetricsNode for smoothness and terrain-roughness metrics |
/camera/image_raw | sensor_msgs/msg/Image | Bidirectional (@) | gz.msgs.Image | RGB camera frames from the onboard camera; used by vision-based RL policies |
/camera_info | sensor_msgs/msg/CameraInfo | Bidirectional (@) | gz.msgs.CameraInfo | Camera intrinsic calibration data accompanying /camera/image_raw |
/world/default/dynamic_pose/info | geometry_msgs/msg/PoseArray | Gazebo → ROS 2 ([) | ignition.msgs.Pose_V | Ground-truth poses of all entities in the default world; consumed by PoseConverterNode to derive /rover/pose_array |
The
/scan topic is not bridged in Leo_rover_fisheye.launch.py because the fisheye model (leo_sim_fisheye.sdf) does not include a 2-D LIDAR sensor. Check which launch file your configuration uses before relying on /scan.The ten topics listed above are the only topics bridged in
4wd_rover_gazebo.launch.py. Other launch files such as Leo_rover_depth.launch.py and Leo_rover_fisheye.launch.py bridge additional topics (depth camera point clouds, actor poses, set-pose services) that are specific to those robot and world variants and are not part of the 4WD rover bridge configuration.Robot Control Topics
These topics form the primary control interface between the RL agent and the simulated robot.| Topic | ROS 2 Message Type | Publisher | Subscriber(s) | Description |
|---|---|---|---|---|
/cmd_vel | geometry_msgs/msg/Twist | RL agent / Nav2 | ros_gz_bridge → Gazebo drive plugin | Velocity commands. linear.x controls forward speed; angular.z controls yaw rate. Commands are forwarded directly to Gazebo via the bridge. |
/rover/pose_array | geometry_msgs/msg/PoseArray | PoseConverterNode | RL agent, MetricsNode | Ground-truth robot pose expressed as a PoseArray with a single element in frame world. Published over a BEST_EFFORT QoS profile at approximately 50 Hz (20 ms timer). |
/odom_ground_truth | nav_msgs/msg/Odometry | PoseConverterNode | Nav2 stack, logging tools | Planar-projected odometry derived from the Gazebo dynamic-pose stream. Roll and pitch are zeroed; only x, y, and yaw are propagated. Covariance is set to 0.01 on diagonal terms. |
Navigation Topics (Nav2)
When runningleo_nav2_lidar_launch.py, the full Nav2 stack is activated. These topics are standard Nav2 interfaces and are consumed or produced by the Nav2 servers launched in that file.
| Topic | ROS 2 Message Type | Direction | Description |
|---|---|---|---|
/scan | sensor_msgs/msg/LaserScan | → Nav2 | LIDAR scan fed to the DWB local planner and costmap layers |
/odom_ground_truth | nav_msgs/msg/Odometry | → Nav2 | Bridged from Gazebo; used as the odometry source in place of /odometry/wheels in the Nav2 LIDAR configuration |
/cmd_vel | geometry_msgs/msg/Twist | Nav2 → robot | Velocity commands output by the DWB controller server |
/goal_pose | geometry_msgs/msg/PoseStamped | External → Nav2 | 2-D navigation goal; can be published from RViz2 or the RL agent |
/tf | tf2_msgs/msg/TFMessage | PoseConverterNode → Nav2 | odom → base_footprint transform broadcast by the pose converter; consumed by all Nav2 costmap layers |
odom frame as the global frame for mapless navigation (no AMCL or map server). The global planner is SmacPlanner2D (MOORE grid search) and the local planner is DWB (Dynamic Window Approach). See leo_nav2_lidar_params.yaml for full planner parameters.
World-Specific Service Topics
Each world variant exposes a pose-reset service through the bridge:| Service | Type | World |
|---|---|---|
/world/inspect/set_pose | ros_gz_interfaces/srv/SetEntityPose | inspect |
/world/default/set_pose | ros_gz_interfaces/srv/SetEntityPose | default |
/world/moon/set_pose | ros_gz_interfaces/srv/SetEntityPose | moon |
QoS Profiles
Most topics in RoboTerrain use the ROS 2 default Reliable QoS profile with a history depth of 10. The/rover/pose_array topic is an exception — it is published and subscribed with a BEST_EFFORT profile to minimise latency at high update rates.
BEST_EFFORT Profile — /rover/pose_array
KEEP_LAST history with depth=1 means only the most recent pose is retained in the queue. Combined with the 20 ms publish timer in PoseConverterNode, this ensures subscribers always receive the freshest ground-truth pose with minimal buffering delay.