Simulation (Gazebo/Isaac Sim)

Simulation (Gazebo/Isaac Sim) – definition

In mobile robotics, simulation is a software environment that reproduces the behavior of a robot, its sensors, actuators, and operating environment with enough fidelity to test algorithms before deployment on physical hardware. In the ROS and ROS 2 ecosystem, simulation usually means running the same robot model, message interfaces, and navigation or perception nodes against a virtual world instead of a real UGV.

For UGV platforms such as Leo Rover and Raph Rover, simulation is used to validate kinematics, sensor placement, navigation pipelines, SLAM, and autonomy logic. Gazebo and Isaac Sim are two commonly used simulators, but they differ in architecture and typical use. Gazebo is closely associated with the ROS community and URDF/SDF-based robot modeling. Isaac Sim is NVIDIA’s simulation platform built on Omniverse, commonly used for GPU-accelerated rendering, synthetic data generation, and physics-based testing of perception pipelines.

In practical terms, simulation is not a replacement for field testing. It is a controlled step between software development and deployment. For Leo Rover, this is especially important because the platform ships with a Raspberry Pi-based compute unit and does not provide full autonomy out-of-the-box. For Raph Rover, simulation reduces integration risk when testing heavier payloads, larger LiDARs, GNSS receivers, or more computationally demanding autonomy stacks.

How simulation works in ROS 2

In ROS 2, a simulator acts as a producer of robot state and sensor data, while navigation, SLAM, control, and perception nodes consume these topics as if they came from real hardware. The key requirement is interface compatibility. If the simulator publishes the expected topics and transforms, most ROS 2 packages can run unchanged.

A typical ROS 2 simulation stack for a differential-drive UGV includes the following interfaces and conventions.

• /cmd_vel – usually geometry_msgs/msg/Twist, used by a controller plugin or bridge.
• /odom – usually nav_msgs/msg/Odometry, published from simulated wheel motion or physics.
• /tf and /tf_static – frame transforms defined according to REP 105.
• /scan – typically sensor_msgs/msg/LaserScan for 2D LiDAR-based SLAM and navigation.
• /imu/data – typically sensor_msgs/msg/Imu.
• /camera/image_raw and /camera/camera_info – for RGB or depth camera workflows.
• /clock – simulation time, required when use_sim_time is enabled.

ROS frame naming should follow REP 103 and REP 105. For a ground robot, the common chain is map -> odom -> base_link, with sensor frames such as laser_frame or camera_link. A simulator that breaks this convention often causes failures in Nav2, SLAM Toolbox, or robot_localization.

Gazebo and Isaac Sim – practical differences

Both tools can simulate a mobile robot, but they solve different problems with different strengths. For UGV development, the choice depends on whether the priority is ROS-native integration, physics speed, photorealistic rendering, or synthetic vision data.

Aspect	Gazebo	Isaac Sim
Typical role	ROS-focused robot simulation	GPU-accelerated simulation and synthetic data
Robot description	URDF and SDF	USD-based scene description, URDF import supported
ROS 2 integration	Native through Gazebo ROS packages or ros_gz_bridge	ROS 2 bridge provided by NVIDIA
Strengths	Fast setup, mature ROS workflows, navigation testing	High-fidelity rendering, perception validation, synthetic datasets
Typical compute	Runs on a standard workstation; GPU is optional depending on rendering	Requires NVIDIA GPU for best performance

For Leo Rover, Gazebo is usually the faster path for ROS 2 navigation and SLAM integration. For Raph Rover projects with larger camera payloads, depth pipelines, or synthetic training data, Isaac Sim may be more suitable.

Key parameters and metrics

Simulation quality is determined by measurable properties. In robotics, the useful question is not whether the world looks realistic, but whether the simulated outputs are valid enough for algorithm development and regression testing.

• Physics update rate – often 100 Hz to 1000 Hz for stable wheeled contact simulation.
• Sensor publish rate – for example 5-20 Hz for a 2D LiDAR, 30 Hz for an RGB camera, 100-200 Hz for IMU.
• Real-time factor – ratio of simulated time to wall-clock time. A value of 1.0 means real-time execution.
• Latency – delay between command publication and simulated actuation or sensor output.
• Noise model – Gaussian noise, bias drift, quantization, dropouts, rolling shutter, motion blur.
• Map resolution – relevant for occupancy grids, often 0.02-0.10 m/cell in UGV testing.
• Contact and friction parameters – critical for differential-drive behavior on loose or uneven terrain.

For navigation stack testing, three metrics are especially important: odometry drift, collision rate, and path tracking error. For perception, the critical metrics are sensor timing, frame alignment, and whether the simulator reproduces failure modes such as partial occlusion, reflective surfaces, or wheel slip.

Robot modeling for Leo Rover and Raph Rover

A simulated UGV starts with a robot description. In ROS 2, this is usually a URDF or Xacro model with joints, inertial parameters, collision geometry, visual geometry, and sensor frames. Gazebo may use URDF directly or convert to SDF internally. Isaac Sim can import URDF, but often converts it into its own scene representation.

For Leo Rover, the important elements are the differential-drive kinematics, four-wheel geometry, realistic wheel radius and track width, and correct placement of payload sensors. Since Leo Rover is intended for mobile field robotics, simulated use cases often include ramps, curbs, uneven terrain, and outdoor lighting changes. However, the onboard Raspberry Pi means developers often split workloads: heavy simulation on a workstation, lightweight runtime on the physical robot.

For Raph Rover, the model should capture increased mass, payload-dependent inertia, and the impact of larger sensors on center of gravity and vibration. This matters when validating GNSS antenna placement, mast-mounted LiDARs, or stereo camera rigs.

Example ROS 2 configuration

The most common ROS 2 setup is to start the simulator, load the robot description, and enable simulation time for all consumers. This keeps SLAM, Nav2, and visualization synchronized to the simulator clock.

/**:
  ros__parameters:
    use_sim_time: true

robot_state_publisher:
  ros__parameters:
    use_sim_time: true

slam_toolbox:
  ros__parameters:
    use_sim_time: true

controller_server:
  ros__parameters:
    use_sim_time: true

A minimal ROS 2 launch sequence may look like this.

ros2 launch leo_gazebo leo_world.launch.py
ros2 launch nav2_bringup navigation_launch.py use_sim_time:=true
ros2 launch slam_toolbox online_async_launch.py use_sim_time:=true

At runtime, interface inspection should confirm topic and transform consistency.

ros2 topic list
ros2 topic hz /scan
ros2 topic echo /odom
ros2 run tf2_tools view_frames

Typical use cases on Fictionlab platforms

On Leo Rover, simulation is mainly used for early-stage algorithm validation and teaching. A student or researcher can test Nav2 behavior trees, SLAM Toolbox, robot_localization fusion, or custom perception nodes without risking hardware damage. This is useful when integrating a 2D LiDAR, IMU, depth camera, or GNSS receiver before deployment on the physical rover.

On Raph Rover, simulation is often part of a systems engineering workflow. The larger payload envelope makes it possible to mount more complex sensors, but it also raises the cost of integration errors. Simulated tests can verify line-of-sight occlusion, sensor field of view, bandwidth budgets, or autonomy behavior on rough terrain models before field trials.

Limitations and trade-offs

No simulator reproduces real terrain and sensor behavior perfectly. Wheel slip on sand, mud adhesion, LiDAR multipath, camera exposure artifacts, and GNSS degradation near structures are difficult to model with full fidelity. This matters for outdoor UGVs more than for indoor research robots.

Gazebo usually gives faster ROS iteration, but lower visual realism than Isaac Sim. Isaac Sim can model camera pipelines more credibly, but often requires more hardware, more setup time, and more scene engineering. In both cases, the main engineering risk is assuming that successful simulation implies successful field autonomy. For Leo Rover and Raph Rover, simulation should be treated as a verification layer, not as final validation.

Normative references and standards

The technical interpretation of simulation in ROS-based mobile robotics depends on several official references. REP 103 defines standard units and coordinate conventions. REP 105 defines the relationship between mobile platform frames such as map, odom, and base_link. ROS 2 message contracts such as sensor_msgs, nav_msgs, and geometry_msgs determine whether a simulator is interoperable with downstream software. URDF remains the standard XML robot description format in ROS workflows, while Gazebo commonly relies on SDF for simulator-specific semantics. Isaac Sim documentation defines its ROS 2 bridge behavior and sensor publication interfaces.

See also

• ROS 2
• URDF
• SLAM
• Nav2