Building simulation worlds and robot models

A simulator is only as good as the models fed into it. A robot model with the wrong mass or inertia will accelerate and tip differently from the real machine; a lidar model without noise will make localization look perfect; a warehouse world without reflective shrink-wrap and moving forklifts will never expose the failures that happen on site. This lesson covers how robots are described for simulation and visualization (URDF, Xacro and SDF), how to get mass and inertia right, how collision and visual geometry differ, how sensors and their noise are modelled and how to build worlds and scenarios that test what matters.

Describing a robot: URDF and Xacro

The Unified Robot Description Format (URDF) is the standard way to describe a robot in ROS. It is an XML file listing links (rigid bodies) and joints (connections between links). Each link can have visual geometry for display, collision geometry for contact computation and inertial properties: mass, centre of mass and inertia tensor. Each joint has a type (fixed, revolute, continuous, prismatic, floating or planar), a parent and child link, an origin transform, an axis and limits on position, velocity and effort. Joints form a tree, which tf2 and robot_state_publisher use to compute frame transforms from joint states.

Handwritten URDF quickly becomes long and repetitive: a robot with four identical wheels repeats the same block four times. Xacro (XML macros) adds variables, mathematical expressions, macros and file inclusion, so that a wheel is defined once and instantiated four times with different positions. Xacro files are expanded into plain URDF at build or launch time. Keeping dimensions as named properties in one place also helps keep the model consistent with the mechanical design.

<?xml version="1.0"?>
<robot name="delivery_base" xmlns:xacro="http://www.ros.org/wiki/xacro">
  <xacro:property name="wheel_r" value="0.08"/>     <!-- m -->
  <xacro:property name="wheel_w" value="0.04"/>
  <xacro:property name="track" value="0.42"/>
  <xacro:macro name="wheel" params="side y">
    <link name="${side}_wheel">
      <visual><geometry><cylinder radius="${wheel_r}" length="${wheel_w}"/></geometry></visual>
      <collision><geometry><cylinder radius="${wheel_r}" length="${wheel_w}"/></geometry></collision>
      <inertial><mass value="1.2"/>
        <inertia ixx="0.00208" iyy="0.00208" izz="0.00384" ixy="0" ixz="0" iyz="0"/></inertial>
    </link>
    <joint name="${side}_wheel_joint" type="continuous">
      <parent link="base_link"/><child link="${side}_wheel"/>
      <origin xyz="0 ${y} ${wheel_r}" rpy="${-pi/2} 0 0"/><axis xyz="0 0 1"/>
    </joint>
  </xacro:macro>
  <xacro:wheel side="left"  y="${track/2}"/>
  <xacro:wheel side="right" y="${-track/2}"/>
</robot>

SDF and simulator-specific descriptions

URDF was designed for describing a single robot for ROS tools, and it has limits: it cannot describe closed kinematic loops, worlds with many models, lights, terrain or detailed physics properties. The Simulation Description Format (SDF), used natively by Gazebo, covers all of these. In practice teams keep the URDF (generated from Xacro) as the single source of truth for the robot, and Gazebo converts it to SDF when the robot is spawned, with simulator-specific details such as friction coefficients, sensor plugins and the ros2_control plugin added through extension tags. Worlds, buildings and obstacles are written directly in SDF. Other simulators use their own formats, such as MJCF for MuJoCo and USD for Isaac Sim, with importers for URDF.

Mass, centre of mass and inertia

Wrong inertial values are one of the most common causes of unrealistic simulations: robots that tip over too easily, arms that oscillate, wheels that spin up instantly. Every link needs a positive mass and a physically consistent inertia tensor, with principal moments that satisfy the triangle inequality (each at most the sum of the other two). The best source is the CAD model, which can export mass properties from material densities. For simple shapes, standard formulas give good approximations.

# Inertia of simple shapes about their CoM (kg m^2)
def box(m, x, y, z):
    return (m * (y*y + z*z) / 12, m * (x*x + z*z) / 12, m * (x*x + y*y) / 12)
def cylinder_z(m, r, h):          # axis along z
    ixx = m * (3*r*r + h*h) / 12
    return (ixx, ixx, m * r * r / 2)
def check(I):
    a, b, c = I
    return a > 0 and b > 0 and c > 0 and a <= b + c and b <= a + c and c <= a + b
chassis = box(18.0, 0.60, 0.45, 0.20)
wheel = cylinder_z(1.2, 0.08, 0.04)
print("chassis ixx, iyy, izz = %.4f, %.4f, %.4f  valid=%s" % (*chassis, check(chassis)))
print("wheel   ixx, iyy, izz = %.5f, %.5f, %.5f  valid=%s" % (*wheel, check(wheel)))
bad = (0.01, 0.01, 0.05)          # a typo: izz too large for the others
print("typo tensor valid =", check(bad))
# parallel axis theorem: wheel spinning about the robot's vertical axis, offset 0.21 m sideways
d = 0.21
print("wheel izz about robot vertical axis = %.4f" % (wheel[0] + 1.2 * d * d))

chassis ixx, iyy, izz = 0.3638, 0.6000, 0.8438  valid=True
wheel   ixx, iyy, izz = 0.00208, 0.00208, 0.00384  valid=True
typo tensor valid = False
wheel izz about robot vertical axis = 0.0550

Inertia is expressed in the link's own frame. In the Xacro listing, the joint's rotation of −π/2 about x turns the wheel link so that its z axis points sideways, along the robot's y axis; the cylinder therefore stays aligned with the link's z axis, and izz carries the larger value m r²/2 while ixx and iyy take the other moment. Mixing up the link frame and the robot frame is a classic error that gives wheels the wrong spin inertia. Tools such as the Gazebo inertia visualization, which draws an equivalent box for each link, make such mistakes easy to spot.

Collision geometry versus visual geometry

Visual geometry is for appearance and can use detailed meshes. Collision geometry is used by the physics engine and should be as simple as possible: boxes, cylinders, spheres and capsules, or convex hulls of meshes, because collision checking cost grows with complexity and concave meshes are poorly supported by many solvers. A wheel modelled as a detailed tyre mesh may bounce and jitter; modelled as a cylinder or sphere it rolls smoothly. Simplified collision shapes should still be slightly conservative where it matters for safety, such as the outline of the robot body near people.

Sensor models and noise

Simulated sensors in Gazebo are added through sensor elements and plugins: cameras, depth cameras, gpu_lidar, IMU, contact, force-torque, GPS (navsat), magnetometer, altimeter and others. Each has parameters for rate, resolution, field of view and range, and most support noise models, typically additive Gaussian noise with a mean and standard deviation, sometimes with bias and bias drift. Noise-free sensors are a trap: algorithms tuned on perfect data often fail on real data, and some failure modes, such as a localization filter becoming overconfident, only appear with realistic noise.

Good sensor models go beyond Gaussian noise where it matters: lidar dropouts on dark or shiny surfaces, multipath and range spikes, rolling-shutter and motion blur in cameras, IMU bias that changes with temperature, GPS outages near buildings and wheel encoder slip. The parameters should come from datasheets and, better, from measurements of the actual sensors, the same characterization used in ROB-220 and ROB-310.

import random, math
# A simple lidar range model: Gaussian noise, dropouts on dark surfaces, occasional spikes
rnd = random.Random(42)
def lidar_range(true_r, dark=False, sigma=0.015, p_drop=0.02, p_spike=0.005, r_max=12.0):
    if dark: p_drop = 0.25                 # dark material returns fail more often
    u = rnd.random()
    if u < p_drop: return float("inf")     # no return
    if u < p_drop + p_spike: return rnd.uniform(0.1, true_r)   # spurious short return
    return min(r_max, rnd.gauss(true_r, sigma))
for dark in (False, True):
    rs = [lidar_range(4.0, dark) for _ in range(5000)]
    valid = [r for r in rs if math.isfinite(r)]
    mean = sum(valid) / len(valid)
    sd = (sum((r - mean) ** 2 for r in valid) / len(valid)) ** 0.5
    print(f"dark={dark}: valid {len(valid) / len(rs):.1%}, mean {mean:.3f} m, std {sd:.3f} m")

dark=False: valid 97.8%, mean 3.993 m, std 0.130 m
dark=True: valid 75.0%, mean 3.984 m, std 0.203 m

The standard deviation of the valid returns is much larger than the 1.5 cm Gaussian noise because the rare spurious short returns are counted in it. This is exactly the kind of outlier behaviour that robust estimators and gating (ROB-310) must handle, and a simulation that omits it gives a false sense of security.

Building worlds and scenarios

A world is the environment: buildings, floors, furniture, lighting, other agents and weather. Worlds can be modelled from floor plans, built from asset libraries such as Gazebo Fuel, or generated procedurally to create many variations. A scenario is a world plus a script of what happens: start pose, goal, people walking across, a pallet appearing in an aisle, the network dropping. Scenario lists come directly from the use cases and exception flows of lesson 2, so that each requirement has simulated tests that exercise it.

Moving agents make scenarios much more valuable. Gazebo supports actors with scripted trajectories and animations; pedestrian simulation libraries add crowd behaviour. Parameterized scenarios let one description generate many test cases: a person crossing at a random point, speed and angle within stated ranges. Lesson 8 extends this idea to domain randomization, where variation is used deliberately to make software robust to the gap between simulation and reality.