Difference Between robot_walk.xml and robot_allcollisions.xml in Microduck RL

robot_walk.xml strips out collision geometries to maximize simulation throughput for locomotion tasks, while robot_allcollisions.xml retains exhaustive collision meshes for full self-collision detection at the cost of computational overhead.

The Microduck RL repository by Pollen Robotics maintains two parallel MuJoCo model definitions that share identical kinematic trees, actuator configurations, and visual meshes, but diverge critically in their collision geometry architecture. Selecting the correct XML file determines whether your reinforcement learning pipeline prioritizes raw simulation speed or physical contact fidelity.

Collision Geometry Architecture

Both files define the same 3D robot structure using identical visual meshes and joint hierarchies. The divergence lies entirely in how collision detection primitives are assigned to body parts.

Minimal Coverage in robot_walk.xml

In src/mjlab_microduck/robot/microduck/robot_walk.xml (429 lines), most body parts declare only a single <geom … class="visual"> with no corresponding collision geometry. Only select components—such as the power_support and specific leg segments—retain <geom … class="self_collision_only"> tags. This selective approach limits self-collision checks to a handful of explicitly tagged geoms.

Exhaustive Coverage in robot_allcollisions.xml

Conversely, src/mjlab_microduck/robot/microduck/robot_allcollisions.xml (435 lines) attaches a dedicated <geom … class="collision"> to every major body part. Examples include:

• <geom type="collision" … mesh="np_f970"> (line 102)
• <geom … class="collision" … mesh="hip_l">
• <geom … class="collision" … mesh="jaw">

This expansion ensures every movable link possesses explicit collision geometry, enabling comprehensive self-collision detection across the entire robot surface.

Performance and Computational Impact

The geometric differences directly translate to measurable runtime characteristics in MuJoCo simulations.

Simulation Speed Trade-offs

robot_walk.xml executes significantly faster because the narrow-phase collision checker evaluates fewer primitive pairs. This optimization proves critical when running thousands of parallel environments for walking policy training. robot_allcollisions.xml incurs higher CPU load per timestep due to the additional collision manifold calculations, making it suitable for lower-throughput tasks requiring contact precision.

CPU Load Characteristics

When training velocity-tracking policies, the minimal collision set in robot_walk.xml reduces the computational bottleneck, allowing vectorized environments to scale efficiently. The full collision fidelity in robot_allcollisions.xml becomes necessary only when the reward function or safety constraints depend on accurate self-contact sensing (e.g., obstacle avoidance, manipulation, or robustness testing).

Environment Configuration Mapping

The repository maps specific training tasks to the appropriate XML file through environment configuration classes.

Velocity and Walking Tasks

Locomotion-focused environments defined in src/mjlab_microduck/tasks/microduck_velocity_env_cfg.py default to robot_walk.xml. These configurations assume the policy controls gait patterns where inter-body collisions are rare or irrelevant to task success, rendering the extra collision fidelity unnecessary.

All-Collisions and Manipulation Tasks

Complex interaction scenarios—implemented in src/mjlab_microduck/tasks/microduck_allcollisions_env_cfg.py—explicitly reference robot_allcollisions.xml. These tasks require precise contact detection between limbs and external objects or between the robot's own body parts, necessitating the full collision mesh set.

Implementation: Loading and Switching Models

You can instantiate either model directly in Python or configure training scripts to toggle between them.

Direct MuJoCo Loading

For fast locomotion simulations:

import mujoco

model = mujoco.MjModel.from_xml_path(
    "src/mjlab_microduck/robot/microduck/robot_walk.xml"
)
sim = mujoco.MjSim(model)

For full collision fidelity:

import mujoco

model = mujoco.MjModel.from_xml_path(
    "src/mjlab_microduck/robot/microduck/robot_allcollisions.xml"
)
sim = mujoco.MjSim(model)

Environment Configuration Override

When constructing training environments programmatically:

from src.mjlab_microduck.tasks.microduck_velocity_env_cfg import make_microduck_velocity_env_cfg

# High-throughput walking (robot_walk.xml)

walk_cfg = make_microduck_velocity_env_cfg()
walk_cfg.robot_xml = "robot/microduck/robot_walk.xml"

# Precision collision mode (robot_allcollisions.xml)

collision_cfg = make_microduck_velocity_env_cfg()
collision_cfg.robot_xml = "robot/microduck/robot_allcollisions.xml"

Summary

• robot_walk.xml prioritizes simulation throughput by omitting most collision geometries, using only self_collision_only tags for critical parts like power_support.
• robot_allcollisions.xml provides complete physical fidelity with explicit <geom class="collision"> entries for every major body part (e.g., hip_l, jaw, np_f970).
• Performance gap: The walk configuration runs faster in parallelized vectorized environments, while the all-collisions configuration incurs higher computational cost per timestep.
• File paths: Both reside in src/mjlab_microduck/robot/microduck/, differing by only six lines (429 vs. 435) of collision geom definitions.
• Task mapping: Velocity environments use robot_walk.xml; manipulation and obstacle-heavy tasks require robot_allcollisions.xml.

Frequently Asked Questions

Can I use robot_walk.xml for manipulation tasks requiring object interaction?

No, you should use robot_allcollisions.xml for manipulation. The walk configuration lacks collision geometries on most body parts, meaning the arm links will pass through objects or the robot's own torso without registering contacts. Accurate grasping and obstacle avoidance require the explicit collision meshes defined in the all-collisions variant.

Which file should I use for high-throughput walking policy training?

Use robot_walk.xml for high-throughput locomotion training. According to the Microduck RL source code, velocity environment configurations (microduck_velocity_env_cfg.py) default to this file specifically because the reduced collision checks minimize CPU overhead when running thousands of parallel environments.

Are the visual meshes different between the two XML files?

No, the visual meshes are identical. Both robot_walk.xml and robot_allcollisions.xml reference the same STL and OBJ files for rendering. The divergence is strictly limited to the collision geometry layer—one uses class="visual" only for most parts, while the other supplements with class="collision" geoms.

How do I switch between the two models in my training script?

Override the robot_xml attribute in your environment configuration object. Instantiate your configuration from make_microduck_velocity_env_cfg(), then assign either "robot/microduck/robot_walk.xml" or "robot/microduck/robot_allcollisions.xml" to the robot_xml field before passing the config to the environment constructor.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}