Tutorial 2: URDF/XML modeling (Understand robot description)

1. how to read/visualize xml

An XML file is a structured description of the simulated robot and its environment. In asimov_1.xml, it defines the simulation environment, robot links and kinematic structure, joints, collision geometry, actuators, inertial properties, and sensors. Here below are the instructions on how to read the xml file.

Robot kinematic tree: bodies and joints

The robot is written as a parent-child tree, meaning each link is attached to the link above it.

<body name="pelvis_link">

  <body name="left_hip_link">
    <joint name="left_hip_pitch_joint" type="hinge" axis="0 1 0"/>

    <body name="left_knee_link">
      <joint name="left_knee_joint" type="hinge" axis="0 1 0"/>
    </body>
  </body>

</body>

Read this as:

pelvis → hip → knee → ankle → foot

A parent joint moves every link below it. Check that the joint hierarchy, joint axes, and joint limits match the real robot.

<joint
  name="left_knee_joint"
  type="hinge"
  axis="0 1 0"
  range="0 1.5"/>
  • axis defines the rotation direction.
  • type="hinge" defines it’s an one-degree-of-freedom rotational joint.
  • range defines the allowed angle range (here it’s in radians).

Joint order

The xml file by default also assumes a specific joint order:

<joint name="left_hip_pitch_joint" .../>
<joint name="left_hip_roll_joint" .../>
<joint name="left_hip_yaw_joint" .../>
<joint name="left_knee_joint" .../>

In locomotion training, you’ll see a config called preserve_order=False . By setting that the resolved joint order follows the XML/model order. Always check the joint-order overlay before training, especially that action indices, observations, PD gains, and hardware motor mapping refer to the same physical joints.

Mass and inertia

Each link should have physical properties:

<inertial
  pos="-0.002 0 -0.090"
  mass="2.391"
  fullinertia="0.00962 0.00975 0.00233 0.00001 -0.00064 -0.00001"/>
  • mass is the link mass.
  • pos is the center of mass in the local link frame.
  • fullinertia controls how difficult the link is to rotate.

These values strongly affect standing balance, swing-leg motion, impact, and push recovery. Correct mass distribution is usually more important than having a visually perfect STL mesh.

STL Meshes vs Collision Geometry

STL meshes define how the robot looks in the viewer:

<mesh name="left_knee_mesh" file="LEFT_KNEE.STL"/>

<geom
  type="mesh"
  mesh="left_knee_mesh"
  class="visual"/>

Collision geometry defines how the robot physically contacts the floor and other objects:

<geom
  name="left_knee_collision"
  type="capsule"
  fromto="0 0 -0.04 0 0 -0.22"
  size="0.04"/>

For locomotion, collision shapes are usually simplified: capsules for limbs, simple shapes for the torso, and several contact shapes for the feet. Foot collision geometry is especially important because it determines where the robot contacts the ground and how stable it is.

Sensors

Sensors define what information is available to the policy.

<site name="imu_in_pelvis" pos="-0.05 0 0.08"/>

<sensor>
  <gyro name="imu_ang_vel" site="imu_in_pelvis"/>
  <accelerometer name="imu_lin_acc" site="imu_in_pelvis"/>
  <framequat name="imu_quat" objtype="site" objname="imu_in_pelvis"/>
</sensor>

For locomotion, the pelvis IMU commonly provides base orientation, angular velocity, acceleration, and gravity direction.
It’s important to make sure the sensor position/orientation defined in xml matches in real, especially IMU sensors. Otherwise, the policy may receive inconsistent observations across training and deployment which will potentially leads to sim2real failure.

2. define collision box - How and Where

Collision geometry is the shape used by the simulator to determine physical contact. It affects foot-ground contact, friction, and balance.
Here’re 3 types of collision box used for asimov xml:

type="sphere"    <!-- foot contact points -->
type="capsule"   <!-- limbs and torso -->
type="mesh"      <!-- STL visual geometry -->
  • Sphere: defined by one radius. It is commonly used as a simple foot contact point because contact is fast and stable.
  • Capsule: a cylinder with rounded ends. It approximates long links such as thighs, shins, arms, or the torso with much fewer geometric details.
  • Mesh: uses the full STL surface, made of many triangles. It closely matches the CAD shape

In the Asimov XML, capsules and spheres are used for limbs and feet rather than mesh collision because their simple shapes make contact computation faster and more stable, while mesh geometry is mainly used for accurate visual appearance and is less suitable for training-time collision.

Figure1. Mesh collision(left) vs simplified cylinder + sphere collision (right)

Figure2. Foot collision is defined by 4 spheres

The four spheres represent the heel and toe corners of the foot, creating a simple support area for stable and efficient foot-ground contact without using expensive mesh collision. Need to make sure that the bottom of the collision geometry should align with the mesh’s ground-contact surface, so both touch the floor at the same height.