> For the complete documentation index, see [llms.txt](https://doc.ancorasir.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.ancorasir.com/2026spring/robot-description-basics/class-02-the-need-for-robot-description.md).
# Class 02: The Need for Robot Description
A robot description translates a physical mechanism into a model that software can load, inspect, simulate, plan with, and control. It is not just a drawing and not just a list of joints. It is an **executable contract** among mechanical design, kinematics, dynamics, rendering, planning, control, and learning.
Class 01 developed four perspectives on a robot: machine, graph, manifold, and agent. This chapter asks what must be serialized so those perspectives agree, compares three major description ecosystems, and then makes a crucial extension: an embodied robot cannot be modeled independently of the world with which it interacts.
> **Learning objectives.** By the end of this class, you should be able to audit the four essential parts of a robot description, choose among URDF, MJCF, and OpenUSD for a given workflow, design validation tests for a model, and explain why a scene description is part of the dynamical and learning problem.
### Contents
1. [A description is a model, not a picture](#id-1.-a-description-is-a-model-not-a-picture)
2. [The four pillars of a robot description](#id-2.-the-four-pillars-of-a-robot-description)
3. [Three format philosophies](#id-3.-three-format-philosophies)
4. [Why robot descriptions fail](#id-4.-why-robot-descriptions-fail)
5. [A practical validation workflow](#id-5.-a-practical-validation-workflow)
6. [Why describing the robot is not enough](#id-6.-why-describing-the-robot-is-not-enough)
7. [From robot description to world description](#id-7.-from-robot-description-to-world-description)
8. [Review questions](#id-8.-review-questions)
9. [References and further reading](#id-9.-references-and-further-reading)
***
### 1. A description is a model, not a picture
A robot model must answer questions from several consumers:
* A kinematics library asks: **Which body is connected to which, by what joint, and in which frame?**
* A dynamics engine asks: **Where is the mass, and how does it resist acceleration?**
* A collision checker asks: **Which volumes may intersect, and at what computational cost?**
* A controller asks: **What can each actuator command, and what are its limits?**
* A renderer asks: **What should the robot look like?**
* A learning system asks: **What observations and actions correspond to this embodiment?**
The description is valuable because it prevents each tool from hardcoding a different robot. Ideally, a change to a joint origin, link mass, or actuator limit propagates consistently through the software stack.
This does **not** mean that one file format captures every physical detail. Every model has a scope. A kinematic visualization may not need motor thermal dynamics; a sim-to-real locomotion study probably does. The first task is therefore to define what the model is expected to predict.
***
### 2. The four pillars of a robot description
#### 2.1 Kinematic topology: the graph
The first pillar declares the mechanism's connectivity:
* **links or bodies** are rigid components;
* **joints** connect parent and child bodies;
* **joint type** specifies allowed relative motion;
* **joint origin and axis** define the associated transform;
* **the root** anchors a fixed-base model or connects a floating-base model to the world.
*Figure 1. Kinematic topology supplies the graph from which transforms and Jacobians are assembled.*
For a tree, forward kinematics follows the unique path from root to body. If $${}^{P}\mathbf T\_C(q\_j)$$ is the transform across joint $$j$$, then the pose of link $$k$$ is the ordered product of transforms along its ancestor path. The corresponding Jacobian can be built from the joint motions on that path.
A useful topology audit asks:
1. Is there exactly one intended root?
2. Are all bodies connected?
3. Are parent and child frames oriented consistently?
4. Do joint axes match the manufactured mechanism?
5. Are closed loops, mimic joints, and coupled coordinates represented explicitly?
#### 2.2 Inertial properties: the physics prior
Each dynamic body requires more than a mesh. At minimum it needs:
* mass $$m$$;
* center-of-mass offset $$\mathbf c$$ from the declared link frame;
* inertia tensor $$\mathbf I$$ about a specified frame and point.
*Figure 2. Inertial data turn a kinematic graph into a dynamical model.*
The model parser uses these properties, together with topology and joint state, to assemble quantities such as the mass matrix $$\mathbf M(q)$$ and bias forces $$\mathbf h(q,v)$$. A visually perfect robot with incorrect inertial data may balance, fall, or collide unrealistically.
Common inertial mistakes include:
* expressing $$\mathbf c$$ in the visual-mesh frame rather than the link frame;
* using inertia about the CAD origin instead of the center of mass;
* mixing kilograms and grams or meters and millimeters;
* assuming a hollow, assembled link is a solid block;
* zeroing off-diagonal inertia terms without rotating into a principal-axis frame;
* assigning tiny mass or inertia solely to silence a simulator warning.
#### 2.3 Geometric boundaries: visual and collision models
The third pillar separates appearance from physical interaction.
*Figure 3. Distinct representations let rendering and collision detection optimize for different goals.*
**Visual geometry** may use high-resolution OBJ, STL, DAE, or other mesh assets. **Collision geometry** often uses boxes, capsules, cylinders, spheres, convex hulls, or a small collection of convex pieces.
The collision model should be simple, but not careless. For a locomotion task, the foot sole, heel, toe, and self-collision envelope may matter much more than cosmetic panel seams. For manipulation, fingertip and object-contact surfaces deserve more fidelity than distant decorative geometry.
The model should also state which pairs can collide. Adjacent links may require filtered collisions; hands, feet, and knees often need careful self-collision coverage.
#### 2.4 Actuation and limits: boundaries of feasible motion
The fourth pillar defines what the robot can command and which states are valid.
*Figure 4. Limits shape both the valid configuration set and the scale of controller outputs.*
Typical fields include:
* lower and upper position limits;
* maximum velocity;
* effort or torque limit;
* actuator type and control mode;
* gear ratio or transmission parameters;
* rotor inertia/armature;
* damping and friction;
* tendon, cable, or coupled-actuator routing.
Position limits define part of the feasible configuration set,
$$
\mathcal Q\_{\text{valid}}
\= {q\in\mathcal Q \mid q\_{\min}\le q\le q\_{\max},; g(q)\ge 0},
$$
where $$g(q)$$ may include collision or loop-closure conditions. Velocity and effort limits define which trajectories are dynamically executable. They should inform motion planners, controllers, and action normalization for learned policies.
An effort limit alone is not a full actuator model. Two joints with the same peak torque can have different speed-torque curves, bandwidth, thermal behavior, friction, delay, and compliance. The required fidelity depends on the question being studied.
***
### 3. Three format philosophies
No universal format dominates every robotics workflow. URDF, MJCF, and OpenUSD emphasize different parts of the problem.
| Format | Primary strength | Structural idea | Common use |
| ------- | ------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------ |
| URDF | Robot kinematics and ROS integration | XML links and joints forming a tree | TF, visualization, planning, robot software |
| MJCF | MuJoCo dynamics, constraints, and actuation | Hierarchically nested bodies with joints, geoms, tendons, actuators, and constraints | Contact-rich simulation, optimization, control, RL |
| OpenUSD | Composable scene description | Layered scene graph with references, variants, schemas, and metadata | Large environments, rendering, synthetic data, digital twins |
#### 3.1 URDF: the robot as a link-joint tree
URDF is the conventional robot model format in ROS. A model declares links and connects them with joints that name a parent and child. It is concise, broadly supported, and well matched to transform publication and tree-structured kinematics.
*Figure 5. URDF makes link and joint relationships explicit in XML.*
A minimal pendulum illustrates the pattern:
```xml
```
URDF's tree model is a feature for recursive kinematics but a limitation for native closed loops. ROS workflows often supplement URDF with Xacro macros, semantic descriptions, controller configuration, simulator-specific extensions, or explicit loop-handling strategies.
#### 3.2 MJCF: the robot as a dynamical hierarchy
MJCF is MuJoCo's native XML modeling format. Bodies are nested hierarchically; joints inside a body define its motion relative to its parent. Geometries, inertial properties, sites, sensors, tendons, actuators, contacts, and equality constraints can be described in the same model ecosystem.
*Figure 6. MJCF's nested structure mirrors the body hierarchy compiled by MuJoCo.*
```xml
```
MJCF is attractive when the simulator model itself is the primary artifact. It provides MuJoCo-specific features such as solver parameters, actuator and tendon models, contact dimensions, and equality constraints. The tradeoff is portability: a rich MJCF model may not map cleanly into a format with simpler semantics.
#### 3.3 OpenUSD: the robot inside a composable world
OpenUSD is a scene-description and composition framework rather than a robot-only format. Assets can be referenced, layered, overridden, instanced, and varied without flattening everything into one monolithic file. Physics and semantic information can be applied through schemas alongside rendering data.
*Figure 7. A scene framework can describe the robot, environment, objects, materials, sensors, and semantics together.*
This is useful for embodied AI because the training artifact is often not “a robot on a floor” but a distribution of furnished, lit, textured, interactive scenes. Composition lets teams reuse a robot asset across many environments and vary materials, objects, or sensors without duplicating the base description.
#### 3.4 Conversion is interpretation, not clerical work
Formats do not have identical expressive power. A converter must decide what to do when the source contains an idea the destination cannot represent directly.
Examples include:
* closed-loop constraints;
* simulator-specific contact parameters;
* actuator dynamics and tendon routing;
* material and shader graphs;
* layered scene composition;
* semantic metadata;
* custom sensors or plugins.
Therefore, never validate a converted model only by checking that the parser succeeds. Validate behavior: poses, mass, center of mass, limits, collision pairs, passive dynamics, contact, and actuator response.
***
### 4. Why robot descriptions fail
#### 4.1 “Format hell”
A model may pass through CAD, URDF, MJCF, USD, and simulator-specific caches. Each conversion can change frame conventions, units, topology, or unsupported features. A file that loads is not necessarily a faithful model.
Treat conversion as a build process with explicit inputs, scripts, versioned outputs, and tests. Avoid a chain of undocumented manual exports.
#### 4.2 Manufacturing CAD is not simulation geometry
CAD is designed to manufacture an assembly. It may contain fasteners, fillets, internal cavities, cable guides, and thousands of small surfaces. A simulator needs a stable mass model and efficient contact geometry.
Direct CAD export can cause:
* meshes with excessive triangle counts;
* inconsistent normals or non-manifold surfaces;
* unit errors;
* collision shapes containing tiny irrelevant features;
* inertial estimates based on the wrong material or density assumption;
* separate parts that should be treated as one rigid body.
The solution is a deliberate simulation-asset pipeline, not blind decimation. Preserve features that affect mass, contact, and sensing; remove details that do not.
#### 4.3 Invisible dynamics
Links and joints are visually obvious, while actuator bandwidth, backlash, compliance, delay, and thermal effects are not. Consequently, they are often missing. Yet these omitted dynamics may dominate sim-to-real performance.
Document model scope explicitly. If the actuator is idealized, say so. If damping is numerical rather than identified, say so. Hidden uncertainty is more dangerous than acknowledged simplification.
#### 4.4 Frame and unit mistakes
Many catastrophic model failures are bookkeeping errors:
* millimeters interpreted as meters;
* degrees interpreted as radians;
* inertia expressed about the wrong origin;
* a joint axis expressed in a parent frame when the parser expects a joint frame;
* mesh orientation corrected visually but not in collision or inertial data;
* left and right limbs mirrored with inconsistent signs.
Write down conventions, automate checks, and inspect numeric values rather than relying solely on rendering.
***
### 5. A practical validation workflow
#### 5.1 Start small
Do not learn description formats by authoring a full humanoid first. A progressive sequence exposes one concept at a time:
1. **One-link pendulum:** link, joint, gravity, mass, inertia, and damping.
2. **Cart-pole:** prismatic plus revolute motion and underactuation.
3. **Composed mechanism:** reusable subassemblies and frame interfaces.
4. **Closed-loop mechanism:** explicit closure constraint and independent coordinates.
5. **Humanoid:** floating base, self-collision, many actuators, and contact.
#### 5.2 Structural tests
Before simulation, verify:
* the expected number and names of bodies, joints, and actuators;
* one connected model with the intended root;
* joint types, axes, and limits;
* no duplicate or missing names;
* all mesh and texture paths resolve;
* all collision filters match their intended pairs.
#### 5.3 Physical sanity checks
Use simple tests with interpretable outcomes:
* **Total mass:** sum all link masses and compare with hardware.
* **Center of mass:** inspect the whole-body CoM in neutral poses.
* **Inertia plausibility:** check symmetry, positive definiteness, and scale.
* **Passive drop:** drop the unactuated robot; it should fall and contact without numerical explosion.
* **Pendulum period:** compare a single joint against an analytical or measured period.
* **Static gravity:** compare predicted gravity compensation with measurements where possible.
* **Energy behavior:** in a conservative test, look for unexplained energy growth.
#### 5.4 Actuator and contact tests
* command a joint step and compare rise time, overshoot, and saturation;
* reverse direction slowly to reveal friction or backlash mismatch;
* press a foot or hand into a known surface and inspect normal force;
* vary friction and confirm the expected transition from sticking to slipping;
* reduce the time step and confirm that the conclusions do not depend on a single numerical setting.
#### 5.5 Treat the model as source code
Version robot and scene descriptions with Git. Keep conversion scripts beside source assets. Record units and frame conventions. Review changes to mass, inertia, limits, collision geometry, friction, and solver parameters with the same care as control code.
A useful pull-request summary answers:
* What physical evidence motivated the change?
* Which downstream tools are affected?
* Which tests changed, and why?
* Is the change a correction, calibration, or deliberate approximation?
***
### 6. Why describing the robot is not enough
#### 6.1 The system includes the environment
A robot floating in an empty world can test kinematics, but locomotion and manipulation are defined by interaction. With external contact,
$$
\mathbf M(q)\dot v + \mathbf h(q,v)
\= \mathbf S^\top\tau
* \mathbf J\_c(q)^\top\lambda
* \mathbf J\_{\text{ext}}(q)^\top f\_{\text{ext}}.
$$
The left side depends primarily on the robot model. The right side includes forces produced by the scene: ground reaction, friction, object impact, support from a handrail, or resistance from a door.
A perfect robot model on the wrong surface is still the wrong system. Concrete and mud can share the same geometry while producing different compliance and valid motions. Ice and asphalt can share a plane while producing very different friction cones.
#### 6.2 The scene is a boundary condition
For physics, the scene supplies geometry, contact parameters, materials, and boundary conditions. For perception, it supplies the distribution of images, depth, sound, and tactile events. For task reasoning, it supplies objects, affordances, and semantics.
A scene description should therefore include at least:
* terrain and object geometry;
* friction, restitution, compliance, and density;
* articulated object mechanisms and limits;
* lights, cameras, and other sensor-relevant properties;
* semantic labels and task metadata;
* initial-state and randomization distributions.
#### 6.3 The scene graph
The robot's kinematic tree becomes one subgraph inside a larger scene graph.
*Figure 8. Embodied tasks require physical, perceptual, and semantic context beyond the robot itself.*
A conceptual hierarchy might be
```
/World
├── Robot_G1
│ ├── Body
│ ├── Sensors
│ └── Controllers
├── Terrain
│ └── KitchenFloor
├── Objects
│ ├── Mug
│ └── Door
└── Lighting
└── CeilingFixtures
```
Geometry alone is insufficient for high-level tasks. The agent may also need to know that the mug is graspable, contains liquid, and is fragile; that the door has a hinge and handle; or that a floor region is slippery.
#### 6.4 Perception has its own sim-to-real gap
A physically plausible scene can still be perceptually narrow. Training only under a single ambient light, a single camera exposure, and textureless geometry encourages a vision model to exploit correlations that do not survive deployment.
Scene variation may include:
* light position, intensity, color temperature, shadow, and reflection;
* camera pose, latency, noise, exposure, and lens distortion;
* textures, clutter, object pose, and background;
* weather, dust, transparency, and motion blur where relevant.
Randomization should remain plausible. The objective is not arbitrary visual chaos; it is coverage of uncertainty the real system may encounter.
***
### 7. From robot description to world description
The practical shift is from authoring one perfect asset to defining a **distribution of systems**.
#### 7.1 Randomized terrain, not one floor
Describe a generator of slopes, steps, gaps, bumps, compliance, and friction values. Separate training, validation, and stress-test distributions so robustness can be measured rather than assumed.
#### 7.2 Physical materials, not color labels
Assign contact-relevant properties to every object that may interact. A chair is not merely a mesh; it has mass, inertia, friction, and joints. A rug is not merely a texture; it changes the feel of contact.
#### 7.3 Interactive objects, not baked scenery
Doors, drawers, switches, and tools should be articulated mechanisms with limits, damping, friction, and mass. Otherwise, the robot learns against scenery that cannot respond.
#### 7.4 Semantic and task metadata
Record categories, affordances, states, relationships, and success conditions without conflating them with geometry. The same mesh can represent different task states; a semantic layer should be able to express that change.
#### 7.5 Reproducible scene generation
Store random seeds, generator versions, asset versions, and parameter ranges. A training result is difficult to interpret if the world distribution cannot be reconstructed.
#### Model-release checklist
* [ ] Topology and frame conventions are documented.
* [ ] Total mass, CoM, and inertia have passed sanity checks.
* [ ] Visual and collision assets are separated and resolve correctly.
* [ ] Joint and actuator limits match the intended hardware scope.
* [ ] Closed loops and couplings are explicitly represented.
* [ ] Passive dynamics, actuator response, and contact tests pass.
* [ ] Scene materials and interactive objects have physical properties.
* [ ] Sensor and lighting distributions cover expected deployment conditions.
* [ ] Conversions are scripted, versioned, and behaviorally validated.
* [ ] Known approximations and unidentified parameters are documented.
***
### 8. Review questions
1. What information must be present before a kinematics library can compute an end-effector Jacobian?
2. Why can a robot render correctly while its dynamics are completely wrong?
3. Which details should be preserved when converting manufacturing CAD into a collision model?
4. Compare the organizing ideas of URDF, MJCF, and OpenUSD.
5. Give an example of a model feature that may not survive conversion between formats.
6. Design three sanity checks for a newly exported humanoid model.
7. Why does a terrain material belong to the dynamical system rather than merely the renderer?
8. What scene variations would you include when training a vision-based door-opening policy?
***
### 9. References and further reading
* ROS 2 documentation, [URDF: geometry and organization of robots](https://docs.ros.org/en/rolling/Tutorials/Intermediate/URDF/URDF-Main.html).
* MuJoCo documentation, [MJCF XML reference](https://mujoco.readthedocs.io/en/stable/XMLreference.html) and [modeling guide](https://mujoco.readthedocs.io/en/stable/modeling.html).
* Alliance for OpenUSD, [Introduction to USD](https://openusd.org/release/intro.html).
* Roy Featherstone, [*Rigid Body Dynamics Algorithms*](https://link.springer.com/book/10.1007/978-1-4899-7560-7).
* NVIDIA, [*Isaac Lab: A GPU-Accelerated Simulation Framework for Multi-Modal Robot Learning*](https://arxiv.org/abs/2511.04831).
***
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://doc.ancorasir.com/2026spring/robot-description-basics/class-02-the-need-for-robot-description.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.