Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/clearpathrobotics/cpr_gazebo/llms.txt

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

Every CPR Gazebo world launch file accepts a consistent set of arguments that control which robot is spawned, where the robot appears in the scene, where the world geometry is placed, and how the Gazebo simulator itself is started. Understanding these shared parameters means you can apply the same patterns across Agriculture, Inspection, Office, Obstacle, Orchard, and Empty worlds — only the world-specific defaults change. This page documents every common parameter in full. World-specific extras (such as walls and world_scale in the Obstacle world) are documented on the individual world pages.

​
Platform Selection

The platform argument determines which Clearpath robot is spawned into the simulation. It defaults to the CPR_GAZEBO_PLATFORM environment variable if that variable is set; otherwise each world falls back to a size-appropriate robot (typically husky for outdoor worlds, jackal for the Obstacle world).
​
platform
string
default:"$CPR_GAZEBO_PLATFORM or world default"
The robot platform to spawn. Available values across the package collection are husky, jackal, warthog, dingo, ridgeback, and boxer. Not all values are valid in every world — outdoor worlds do not support dingo or ridgeback. Refer to each world’s page for the supported subset.
roslaunch cpr_office_gazebo office_world.launch platform:=jackal
If CPR_GAZEBO_PLATFORM is set in your environment, you do not need to pass platform:= on the command line. See the Installation page for how to set this variable permanently in ~/.bashrc.

​
Robot Spawn Position

These four arguments control the initial pose of the robot when it is spawned into Gazebo. Most worlds default to a pose at or near the world origin. Two worlds are notable exceptions: the Inspection world defaults to robot_x:=6.0, robot_y:=-18.0, robot_z:=2.0 to place the robot on solid ground within the hilly terrain, and the Empty world defaults to robot_z:=2.0 so the robot settles cleanly onto the flat ground plane without clipping.
​
robot_x
float
default:"0.0"
The robot’s initial X position in the Gazebo world frame, in metres.
​
robot_y
float
default:"0.0"
The robot’s initial Y position in the Gazebo world frame, in metres.
​
robot_z
float
default:"0.2"
The robot’s initial Z position (height above the world origin) in metres. The standard default of 0.2 provides a small clearance above flat ground so the robot settles naturally under gravity.
​
robot_yaw
float
default:"0.0"
The robot’s initial heading, in radians. Zero points along the positive X axis. Positive values rotate counter-clockwise when viewed from above.
Always keep robot_z above the local ground level at the spawn location. Spawning the robot at or below the ground plane can cause the robot to fall through the world mesh, resulting in an unrecoverable simulation state. If you move robot_x or robot_y to a position over elevated terrain, increase robot_z accordingly.

​
World Spawn Position

These arguments control where the world geometry model is placed in the Gazebo scene. All worlds default to the origin (0, 0, 0, 0). Changing the world position is useful when composing multiple environments or aligning a world to a specific coordinate frame.
​
world_x
float
default:"0.0"
The X offset of the world geometry model, in metres.
​
world_y
float
default:"0.0"
The Y offset of the world geometry model, in metres.
​
world_z
float
default:"0.0"
The Z offset of the world geometry model, in metres.
​
world_yaw
float
default:"0.0"
The yaw rotation of the world geometry model, in radians.
If you move the world geometry away from the origin, you must also adjust the robot spawn position (robot_x, robot_y, robot_z) to keep the robot above the ground plane of the relocated world. Failing to do so will spawn the robot in mid-air or underground relative to the shifted terrain.

​
Simulation Control

These arguments govern how the Gazebo simulator itself is started.
​
use_sim_time
bool
default:"true"
When true, ROS nodes use the simulated clock published by Gazebo on the /clock topic rather than the system wall clock. This is almost always the correct setting for simulation and is required for time-dependent ROS functionality such as tf transforms and sensor timestamp synchronisation.
​
gui
bool
default:"true"
When true, the Gazebo client GUI is launched alongside the Gazebo server. Set to false to run the simulation headlessly (server only), which reduces CPU and GPU overhead — useful for CI pipelines or remote servers.
​
headless
bool
default:"false"
When true, the Gazebo server is started without rendering support. This is distinct from gui:=false: headless:=true suppresses the rendering pipeline entirely, while gui:=false merely skips launching the client window but still renders on the server side.
​
world_name
string
default:"world-specific .world file"
Path to the Gazebo .world file to load. Each package defaults to its own world file (for example, $(find cpr_agriculture_gazebo)/worlds/actually_empty_world.world for the Agriculture world). Override this to load a custom world file while still using the CPR Gazebo robot spawning and geometry infrastructure.

​
Full Example

The following command launches the Agriculture world with a Warthog positioned away from the default origin, with the GUI enabled: 
roslaunch cpr_agriculture_gazebo agriculture_world.launch \
  platform:=warthog \
  robot_x:=20.0 \
  robot_y:=10.0 \
  robot_z:=0.5 \
  gui:=true
And a headless Inspection world run with a Jackal using a custom starting position: 
roslaunch cpr_inspection_gazebo inspection_world.launch \
  platform:=jackal \
  robot_x:=6.0 \
  robot_y:=-18.0 \
  robot_z:=2.0 \
  gui:=false \
  headless:=true
Some worlds expose additional world-specific parameters beyond those listed here. For example, the Obstacle world adds walls (toggle surrounding walls on or off) and world_scale (scale factor for the environment geometry). These extras are documented on each world’s individual page.

Build docs developers (and LLMs) love

Get started for freeTalk to us