URDF

URDF – definition

URDF stands for Unified Robot Description Format. In ROS and ROS 2, it is the XML-based format used to describe a robot’s kinematic structure, physical properties, visual geometry, collision geometry, and joint relationships. In practical terms, URDF is the machine-readable model that tells the software stack what the robot looks like, how its frames are connected, and how links move relative to each other.

In mobile robotics and UGV development, URDF is not a navigation algorithm and not a simulator by itself. It is a structural description used by tools such as robot_state_publisher, RViz, Gazebo-compatible workflows, TF2, and planning or perception pipelines that need a consistent frame tree. For a differential-drive platform such as Leo Rover, URDF typically defines base_link, wheel links, sensor frames, inertial properties, and fixed or rotating joints. For a larger payload-oriented platform such as Raph Rover, the same model becomes important when integrating heavier LiDARs, GNSS antennas, stereo cameras, or custom sensor masts.

URDF is a ROS convention rather than an IEEE standard. Its use is closely tied to ROS tooling and REP conventions, especially frame naming and coordinate frame semantics defined in ROS Enhancement Proposals such as REP 103 and REP 105. In ROS 2 Humble and newer, URDF remains a standard input for robot model publication, although SDF may be preferred in some simulation workflows.

How URDF works in ROS 2

In ROS 2, the URDF file is commonly loaded at launch time and passed as the robot_description parameter. The main consumer is robot_state_publisher, which computes the forward kinematics of the robot and publishes the TF tree based on joint states. If the robot has moving joints, a joint_state_publisher or hardware driver must provide sensor_msgs/msg/JointState messages.

For UGVs, the operational value of URDF is frame consistency. A navigation stack, SLAM node, EKF, and visualization pipeline all assume that sensor frames are correctly placed relative to the robot body. If the LiDAR is mounted 0.18 m above base_link and shifted 0.06 m forward, that transform should be represented in the URDF or in a consistent static transform configuration.

ROS 2 element	Typical role with URDF	Relevant data
`robot_state_publisher`	Publishes TF transforms from the robot model	`robot_description`, joint states
`joint_state_publisher`	Publishes joint values for non-hardware or test setups	`sensor_msgs/msg/JointState`
RViz2	Visualizes links, frames, and sensor positions	TF2, robot model
Nav2 / SLAM tools	Consume frame relationships indirectly through TF	`base_link`, `odom`, `map`

A minimal ROS 2 launch pattern looks like this:

from launch import LaunchDescription
from launch_ros.actions import Node
from launch.substitutions import Command
from launch_ros.parameter_descriptions import ParameterValue
from launch.substitutions import PathJoinSubstitution
from launch_ros.substitutions import FindPackageShare

def generate_launch_description():
    robot_description = ParameterValue(
        Command([
            'xacro ',
            PathJoinSubstitution([
                FindPackageShare('my_rover_description'),
                'urdf',
                'rover.urdf.xacro'
            ])
        ]),
        value_type=str
    )

    return LaunchDescription([
        Node(
            package='robot_state_publisher',
            executable='robot_state_publisher',
            parameters=[{'robot_description': robot_description}]
        )
    ])

Core URDF elements for a mobile robot

A useful UGV model starts with a small number of correct elements. The model does not need every screw or bracket. It must represent the links and frames that affect kinematics, perception, and collision checking.

The most important URDF concepts are the following:

link – a rigid body such as chassis, wheel, LiDAR housing, or camera mount
joint – the relationship between two links, for example fixed, continuous, revolute, or prismatic
origin – translation and rotation between parent and child frames, usually in meters and radians
visual – geometry used for rendering in RViz or simulation tools
collision – simplified geometry used for collision checking
inertial – mass, center of mass, and inertia tensor used by physics engines

For a differential-drive rover, wheel joints are often defined as continuous joints. Sensor mounts are usually fixed joints. A compact example is shown below:

<link name="base_link"/>

<link name="lidar_link">
  <visual>
    <geometry>
      <cylinder radius="0.03" length="0.05"/>
    </geometry>
  </visual>
</link>

<joint name="lidar_joint" type="fixed">
  <parent link="base_link"/>
  <child link="lidar_link"/>
  <origin xyz="0.06 0.0 0.18" rpy="0 0 0"/>
</joint>

Frames, conventions, and REP references

URDF is only useful when frame semantics are consistent with ROS conventions. REP 103 defines standard units and coordinate conventions. It specifies SI units, right-handed frames, meters for distance, radians for angles, and common axis orientation practices. REP 105 defines standard mobile platform frames such as base_link, odom, and map.

For UGVs, this means the URDF should support a TF tree that works cleanly with localization and navigation software:

map – global frame, usually produced by SLAM or localization
odom – locally smooth frame from odometry
base_link – robot body reference frame
sensor frames – for example laser_frame, camera_link, imu_link, gps_link

A common source of integration errors is incorrect sensor orientation. For example, a camera optical frame uses a different convention than a generic body frame in ROS. If the URDF and drivers disagree about axes, point clouds, image reprojection, and fused state estimates may all become inconsistent.

Use on Leo Rover and Raph Rover

On Leo Rover, URDF usually serves three concrete tasks. First, it defines the base geometry and wheel frames for a four-wheel skid-steer robot running ROS 2 Humble or newer. Second, it anchors optional sensors such as 2D LiDAR, IMU, depth camera, or GNSS receiver. Third, it provides the robot model for RViz, TF debugging, and simulation-oriented development. Leo Rover uses an onboard Raspberry Pi-class compute unit by default, so the robot model should stay simple enough for efficient deployment and debugging.

On Raph Rover, the same principles apply, but the larger chassis and higher payload capacity make the model more important for multi-sensor integration. A raised LiDAR mast, dual-antenna RTK setup, or heavier stereo head changes the sensor baselines and center of mass. Those parameters may affect not only visualization but also state estimation and simulation fidelity.

In both platforms, URDF does not make the rover autonomous by itself. It supports autonomy by giving Nav2, SLAM, localization, and perception nodes a correct spatial description of the robot.

Key parameters and validation points

For technical users, the quality of a URDF model can be checked against a short list of measurable attributes. These parameters should come from CAD, caliper measurements, mass properties, or manufacturer documentation.

Wheel radius and wheel separation or track geometry – needed by the drive kinematics and odometry configuration
Sensor pose relative to base_link – typically measured in meters with millimeter-level care for tightly coupled perception setups
Mass and inertia tensor – required for realistic dynamics in simulation
Collision envelope – should reflect the real outer dimensions of the rover, not only the visual mesh
Frame names – should match driver and navigation configuration exactly

Useful ROS 2 validation commands include:

ros2 topic echo /joint_states
ros2 run tf2_tools view_frames
ros2 run robot_state_publisher robot_state_publisher --ros-args --params-file params.yaml

Limitations and trade-offs

URDF has practical limits. It is good for tree-structured kinematic models, but less expressive than SDF for advanced simulation features. Closed kinematic chains are awkward in pure URDF. Contact parameters, sensors, and physics engine settings are often handled through simulator-specific extensions or separate SDF files.

For mobile robots, another trade-off is model detail. High-resolution meshes improve visualization but increase package size and load time. Simplified collision geometry is usually better for simulation and planning. A common engineering approach is to keep visual meshes detailed enough for inspection and collision meshes simple enough for performance.

Normative references and standards

The following references are the most relevant when implementing URDF for ROS-based UGVs:

ROS / ROS 2 URDF documentation – robot model structure and parser behavior
REP 103 – Standard Units of Measure and Coordinate Conventions
REP 105 – Coordinate Frames for Mobile Platforms
ROS 2 robot_state_publisher documentation – publication of transforms from URDF
SDFormat documentation – relevant when moving from URDF-centric modeling to richer simulation descriptions

In practice, a correct URDF is one of the first artifacts to validate on a mobile robot. If the frame tree is wrong, localization, mapping, and perception will usually fail in ways that are hard to debug later.