Sim-to-real (sim2real)

Sim-to-real (sim2real) – definition

Sim-to-real, often written as sim2real, is the process of transferring a robotics algorithm, controller, perception model, or complete autonomy stack from a simulated environment to a physical robot while preserving acceptable behaviour and performance. In mobile robotics, the central problem is the reality gap: simulation cannot reproduce every physical property of a UGV, its sensors, computing hardware, terrain, communication delays, and operational environment.

For a differential-drive UGV, sim2real concerns more than visual realism. It includes wheel radius and wheel separation accuracy, motor response, traction, encoder errors, payload-dependent dynamics, LiDAR noise, camera exposure, IMU bias, and the timing of ROS 2 messages. A simulation is useful when it enables repeatable testing, but the resulting system must still be validated on the physical platform.

The reality gap in mobile UGV systems

The reality gap is the difference between the simulated robot-environment system and its physical equivalent. It affects both classical robotics algorithms and machine-learning-based perception. A Nav2 configuration that follows paths in simulation can fail on a real rover if the transform tree is incomplete, odometry drifts, the LiDAR frame is incorrectly defined, or acceleration limits do not match the drivetrain.

For a mobile robot, the simulated state can be represented as a transition model:

x(k+1) = f(x(k), u(k), θ) + w(k)

In this model, x is the robot state, u is the control input, θ contains physical parameters, and w represents unmodelled effects and noise. Sim2real reduces the mismatch between the simulated parameters and the parameters observed on the physical rover.

The main sources of mismatch in UGV projects include the following:

kinematic mismatch, such as an incorrect wheel separation or wheel radius;
dynamic mismatch, including motor lag, gearbox backlash, friction, wheel slip, and changing payload;
sensor mismatch, including LiDAR range noise, IMU bias, rolling-shutter effects, and depth-camera invalid pixels;
timing mismatch caused by message latency, clock configuration, CPU load, or wireless networking;
environment mismatch, such as unmodelled slopes, loose soil, reflective surfaces, vegetation, or variable illumination.

Sim2real in ROS 2 and Gazebo

In ROS 2, sim2real is normally implemented by keeping ROS interfaces consistent between simulation and hardware. A navigation node should receive the same logical interfaces in both cases: odometry, laser scans, IMU data, transforms, velocity commands, and optionally global positioning data. This reduces software changes when moving from a virtual model to a physical UGV.

The ROS coordinate conventions should follow REP 103. REP 103 defines right-handed coordinate frames and the common convention of x forward, y left, and z up. Mobile navigation frame relationships should follow REP 105, particularly the distinction between map, odom, and base_link.

A practical simulation setup usually exposes these ROS 2 interfaces:

Function	Typical ROS 2 interface	Purpose during sim2real validation
Velocity control	`geometry_msgs/msg/Twist` on `/cmd_vel`	Uses the same high-level command interface in simulation and hardware.
Wheel odometry	`nav_msgs/msg/Odometry`	Validates kinematics and odometry covariance assumptions.
2D LiDAR	`sensor_msgs/msg/LaserScan`	Supports localisation, mapping, and obstacle detection tests.
IMU	`sensor_msgs/msg/Imu`	Supports state estimation and evaluates bias sensitivity.
Transforms	`tf2` frame tree	Verifies sensor extrinsics and navigation frame consistency.

ROS 2 nodes that use simulation time must set use_sim_time to true and receive the simulated clock through /clock. The ROS 2 time model is documented in the ROS 2 Clock and Time design document. When the same node is deployed on a physical rover using system time, this parameter should normally be set to false.

localization_node:
  ros__parameters:
    use_sim_time: true
    base_frame: base_link
    odom_frame: odom
    world_frame: map

Domain randomization and system identification

Two complementary methods are commonly used to improve sim2real transfer. Domain randomization varies simulated conditions during testing or training. System identification estimates physical parameters from measurements of the real platform. Domain randomization improves robustness to variation. System identification improves model fidelity.

For a UGV simulator, parameters that should be varied or measured include:

wheel radius, wheel separation, motor torque limits, and velocity response;
surface friction and terrain slope;
LiDAR noise, maximum usable range, and scan dropouts;
camera brightness, motion blur, image noise, and depth failures;
IMU bias, random walk, orientation offset, and mounting vibration;
sensor mounting transforms between base_link and each sensor frame.

Sensor extrinsics should be represented explicitly in URDF or through static transforms. URDF is the standard robot description format used by ROS tooling, while Simulation Description Format (SDF) is commonly used by Gazebo simulators. The official ROS 2 URDF documentation describes the robot model workflow.

Sim2real with Leo Rover and Raph Rover

For Leo Rover, sim2real projects commonly begin with a differential-drive URDF model, ROS 2 Humble or a newer supported distribution, and a simulated sensor payload. Leo Rover uses an onboard Raspberry Pi as its default compute unit, so deployment tests should also account for the available CPU resources and sensor-driver load on the target system. A configuration that performs correctly on a development workstation may have different timing characteristics on the rover.

Leo Rover is not autonomous out of the box. A simulated navigation stack must be connected to real sensor drivers, calibrated transforms, localisation, costmaps, and a safety-reviewed velocity-control path before autonomous field operation. The Nav2 documentation defines the ROS 2 navigation framework and its expected interfaces.

Raph Rover follows the same sim2real principles but requires additional attention to payload mass, centre of gravity, braking distance, terrain interaction, and the sensor placement required by a larger platform. It is appropriate when a project requires a higher payload capacity, but it does not replace Leo Rover in laboratory and educational workflows where a smaller platform is sufficient.

Validation criteria for sim-to-real transfer

Sim2real validation should compare measurable behaviour rather than rely on visual similarity between the simulator and the robot. Tests should use repeatable routes, recorded ROS 2 bags, fixed payload conditions, and documented sensor configurations.

Useful validation outputs include:

difference between simulated and measured trajectory for identical command sequences;
odometry drift relative to ground truth or RTK/GNSS reference data where available;
localisation continuity and transform availability in the map → odom → base_link chain;
command-to-motion latency between /cmd_vel and measured rover movement;
navigation success rate, collision events, recovery behaviour, and CPU utilisation on the target compute unit.

Sim-to-real (sim2real)