> 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-01-perspectives-in-understanding-robots.md).
# Class 01: Perspectives in Understanding Robots
Robotics is unusual because the same system must be understood simultaneously as a physical machine, a software object, a dynamical system, and an intelligent agent. Each view introduces a different vocabulary and a different definition of correctness. A mechanically impossible robot cannot be rescued by better software; an accurate mechanism without a computable model cannot be controlled; a perfect simulator without a task has no intent.
This chapter develops four complementary perspectives:
1. **Machine** - matter, energy, actuators, and physical limits.
2. **Graph** - links, joints, coordinate frames, and computable structure.
3. **Manifold** - configurations, velocities, dynamics, and energy.
4. **Agent** - observations, actions, objectives, uncertainty, and semantics.
Together they form a useful mental stack for modern humanoid robotics.
> **Learning objectives.** By the end of this chapter, you should be able to explain what information is introduced at each level, trace how an error propagates upward through the stack, and connect a robot description file to both physical hardware and an embodied policy.
### Contents
1. [One robot, four models](#id-1.-one-robot-four-models)
2. [The machine perspective](#id-2.-the-machine-perspective)
3. [The graph perspective](#id-3.-the-graph-perspective)
4. [The manifold perspective](#id-4.-the-manifold-perspective)
5. [The agent perspective](#id-5.-the-agent-perspective)
6. [The complete embodied stack](#id-6.-the-complete-embodied-stack)
7. [Review questions](#id-7.-review-questions)
8. [References and further reading](#id-8.-references-and-further-reading)
***
### 1. One robot, four models
Consider a humanoid taking one step. The four perspectives describe the same event at different levels.
| Perspective | The robot is... | A step is... | Typical failure |
| ----------------------- | --------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------- |
| Mechanical engineering | A physical machine | Motors transmitting energy through mechanisms | Insufficient torque, overheating, backlash, structural failure |
| Computer science | A graph and data structure | Updating joint state and traversing transforms | Wrong frame, broken topology, inconsistent serialization |
| Mathematics and physics | A state evolving on a constrained space | A trajectory governed by dynamics and contact | Invalid model, unstable integration, incorrect inertia or constraints |
| Artificial intelligence | An agent acting under uncertainty | A decision made to maximize an objective | Poor observations, misspecified reward, distribution shift |
These views are not competing explanations. They are interfaces. The mass properties established by the mechanical model become data stored on graph nodes; the graph is used to assemble the mass matrix; the mass matrix shapes the dynamical state space; that dynamics model defines the transitions experienced by a policy.
***
### 2. The machine perspective
#### 2.1 The hardware prior
Before a robot can estimate, plan, or learn, it must survive gravity. Its links are manufactured from finite-strength materials; its motors have finite torque and thermal limits; its transmissions introduce compliance and friction; its batteries can deliver only finite power.
This physical design is the **hardware prior** to embodied intelligence. It determines which behaviors are possible before any algorithm begins. No controller can make an undersized actuator produce sustained torque beyond its thermal envelope, and no policy can recover from a structure that fractures under repeated impact.
*Figure 1. The robot is first an assembly of physical components, not an abstract collection of coordinate frames.*
Three mechanical questions dominate:
* **Structural integrity:** Can the frame and joints sustain static, impact, and fatigue loads?
* **Power density:** Can the actuation system deliver the required torque and speed without excessive mass or heat?
* **Kinematic viability:** Can the mechanism reach the necessary workspace without singularity, collision, or joint-limit failure?
#### 2.2 Mass, center of mass, and inertia
A link's mass is only the first moment of its physical description. Its **distribution** determines how the link accelerates and how it couples motion about different axes.
For density $$\rho(\mathbf r)$$ over volume $$V$$, total mass and center of mass are
$$
m = \int\_V \rho(\mathbf r),dV,
\qquad
\mathbf c = \frac{1}{m}\int\_V \mathbf r,\rho(\mathbf r),dV.
$$
The center of mass is the point about which the first mass moment vanishes. In a humanoid limb, moving heavy components closer to the hip or shoulder can reduce distal mass and swing inertia. This often improves acceleration capability and control bandwidth, even if the total robot mass remains unchanged.
*Figure 2. Component placement changes the center of mass and therefore the effort required to swing a limb.*
Rotational resistance is described by the inertia tensor. About a chosen link frame,
$$
\mathbf I = \int\_V \rho(\mathbf r)
\begin{bmatrix}
y^2+z^2 & -xy & -xz\\
-xy & x^2+z^2 & -yz\\
-xz & -yz & x^2+y^2
\end{bmatrix} dV.
$$
The diagonal entries are moments of inertia about the frame axes. The off-diagonal products of inertia describe coupling. They vanish in a principal-axis frame, but simply deleting them in an arbitrary frame changes the model. For an asymmetric link, that can corrupt predicted Coriolis and centrifugal effects during fast motion.
Two practical rules follow:
1. Express $$\mathbf c$$ and $$\mathbf I$$ in the exact frame declared by the model.
2. Check that $$\mathbf I$$ is symmetric, physically plausible, and consistent with the link's mass and geometry.
#### 2.3 Actuation is not an ideal torque source
Control diagrams often treat joint torque $$\tau$$ as an immediate command. The real joint contains a motor, a current controller, a transmission, bearings, lubrication, wiring, and a structure. Each contributes dynamics that may be absent from a rigid-body model.
For an ideal transmission with reduction ratio $$N$$, a simple approximation of the inertia reflected to the joint is
$$
I\_{\text{eff}} = I\_{\text{link}} + N^2 I\_{\text{rotor}}.
$$
The square is important. A high reduction ratio increases output torque, but it also amplifies the motor's rotor inertia. High-ratio drives can therefore feel rigid and difficult to backdrive. Lower-ratio quasi-direct drives trade some torque amplification for mechanical transparency, impact tolerance, and better force observability.
*Figure 3. Reflected inertia connects a transmission design decision to contact behavior and control bandwidth.*
A complete actuator model may also require:
* torque and velocity saturation;
* electrical and thermal limits;
* motor and driver bandwidth;
* rotor inertia or armature;
* transmission elasticity;
* sensor delay and quantization;
* current-dependent or temperature-dependent torque constants.
#### 2.4 Friction, stiction, and backlash
Real joints are not perfect hinges. Backlash creates a dead zone when motion reverses: the motor can rotate before the output link begins to move. Friction is also regime-dependent. A useful conceptual model combines static friction, Coulomb friction, a Stribeck transition, and viscous friction,
$$
\tau\_f(\dot q)
\approx
\tau\_c\operatorname{sgn}(\dot q)
* (\tau\_s-\tau\_c)e^{-(|\dot q|/v\_s)^2}\operatorname{sgn}(\dot q)
* b\dot q.
$$
This expression is only one approximation, but it makes the modeling lesson clear: the error is nonlinear and largest near zero velocity, exactly where balance controllers and contact transitions often operate.
#### 2.5 Visual geometry and collision geometry
The shape used for rendering need not be the same as the shape used for collision detection.
* **Visual geometry** can preserve appearance: dense meshes, textures, logos, and small surface details.
* **Collision geometry** should preserve interaction-relevant shape at a computational cost the simulator can afford: primitives, convex hulls, or decomposed low-poly meshes.
*Figure 4. Rendering asks “what does it look like?” while collision detection asks “where can contact occur efficiently?”*
Using a manufacturing mesh directly for collision can turn every contact query into an unnecessarily expensive geometric problem. Over-simplification is also dangerous: a collision hull that misses the sole curvature, toe, or self-collision envelope changes the feasible contact set. The right collision model is therefore **task dependent**.
#### 2.6 Mechanical abstraction and the sim-to-real gap
Robot descriptions necessarily simplify reality. Common assumptions include:
* links are perfectly rigid;
* density is homogeneous;
* joints are ideal constraints;
* torque commands are instantaneous;
* material properties do not change with temperature;
* cables, soft covers, and shifting internal components are negligible.
Each assumption can be reasonable at one operating regime and harmful at another. Flexible structure may be negligible during slow kinematics but critical during impact. Thermal drift may be irrelevant in a short test but decisive in a long locomotion episode. The sim-to-real gap is therefore not a single missing coefficient; it is the accumulated mismatch between the physical machine and its abstraction.
***
### 3. The graph perspective
#### 3.1 From matter to information
A processor cannot operate directly on aluminum, bearings, or carbon fiber. The mechanism must be serialized into data that software can query. The central abstraction is the **kinematic graph**:
* links become nodes;
* joints become edges;
* link properties become node data;
* joint type, axis, limits, and relative pose become edge data.
*Figure 5. The graph retains the connectivity needed for kinematics while attaching physical properties to each body.*
For a tree-structured mechanism, every child has one parent, and there is a unique path from the root to any link. That property enables efficient recursive algorithms for kinematics and dynamics.
#### 3.2 Fixed base, floating base, and the world
An industrial arm is commonly attached to the world by a fixed edge. A humanoid is not. Its pelvis can translate and rotate because the robot's global motion is produced indirectly through contact.
Computationally, a free robot is represented by a six-degree-of-freedom base connection, often using a free joint or a pose in $$SE(3)$$. This is a modeling device, not a physical actuator.
*Figure 6. A floating base lets the entire kinematic tree move through the world frame.*
This distinction has a major control consequence. Joint torques act only on actuated coordinates; the base is underactuated and can be accelerated only through gravity and contact forces.
#### 3.3 Edges store transformations
Each joint defines allowable relative motion and a transform between adjacent frames. A homogeneous transform is
$$
{}^{P}\mathbf T\_C(q) =
\begin{bmatrix}
{}^{P}\mathbf R\_C(q) & {}^{P}\mathbf p\_C(q)\\
\mathbf 0^\top & 1
\end{bmatrix}
\in SE(3),
$$
where $$P$$ and $$C$$ denote parent and child frames. Along a path from the world to a hand,
$$
{}^{W}\mathbf T\_H
\= {}^{W}\mathbf T\_B
{}^{B}\mathbf T\_{S}
{}^{S}\mathbf T\_{E}
{}^{E}\mathbf T\_H.
$$
Forward kinematics is therefore a graph traversal plus ordered transform composition. For a tree with $$n$$ joints, a full traversal is linear in $$n$$, which is one reason recursive algorithms can run at control rates.
The transform convention must be explicit. Confusing “parent-to-child” with “child-to-parent,” active with passive rotations, or local with world coordinates produces errors that often look like poor control but are actually due to poor bookkeeping.
#### 3.4 The model becomes an API
Serialization turns the graph into a file; parsing turns it into runtime objects. A useful robotics API hides repeated traversal behind queries such as:
```python
pose = robot.frame_pose("right_hand", q)
J = robot.frame_jacobian("right_hand", q)
M = robot.mass_matrix(q)
tau_g = robot.gravity_forces(q)
```
The policy or planner does not need to know how every ancestor transform was multiplied. It relies on the graph implementation to produce consistent geometry and dynamics.
#### 3.5 Where trees are not enough
Parallel mechanisms and four-bar linkages contain closed kinematic loops. A pure tree traversal cannot represent a cycle without duplicating a body or creating conflicting paths. Common strategies include:
* cut one edge and impose an equality constraint;
* introduce mimic/coupling relations for a reduced model;
* use a simulator or dynamics library with native loop constraints;
* work in independent generalized coordinates and solve closure equations.
The key point is that topology is not just file organization. It determines which recursive computations are valid and which constraints must be solved numerically.
***
### 4. The manifold perspective
#### 4.1 Configuration space
At the mathematical level, an entire robot posture is represented by a single point in configuration space. For a simplified floating-base humanoid with $$n$$ revolute joints,
$$
\mathcal Q \approx SE(3) \times \mathbb T^n,
$$
where $$SE(3)$$ represents base position and orientation, and each circle in $$\mathbb T^n$$ captures a periodic revolute coordinate. Real robots may also include prismatic joints, non-periodic limits, coupled joints, and loop-closure constraints, so the actual valid set is often a constrained subset of this product.
*Figure 7. Rotations make configuration space different from an ordinary flat vector space.*
Why does geometry matter? The numerical average of $$1^\circ$$ and $$359^\circ$$ is $$180^\circ$$, but their circular mean is near $$0^\circ$$. Similar problems arise when linearly interpolating quaternions or subtracting poses without respecting the group structure.
#### 4.2 Velocity lives in a tangent space
A configuration tells us where the robot is, not how it is moving. Velocity at $$q$$ belongs to the tangent space $$T\_q\mathcal Q$$. The state is therefore naturally written as
$$
x = (q,v) \in T\mathcal Q,
$$
where $$T\mathcal Q$$ is the tangent bundle. This distinction is especially useful for floating-base robots: the number and representation of configuration coordinates need not match the generalized velocity representation.
#### 4.3 The mass matrix as an energy metric
The generalized mass matrix $$\mathbf M(q)$$ converts velocity into kinetic energy,
$$
T(q,v) = \frac{1}{2}v^\top \mathbf M(q)v.
$$
Because $$\mathbf M$$ depends on posture, equal coordinate velocities do not necessarily have equal physical cost. Extending the arms changes whole-body rotational inertia; bending the knees changes coupling among base and joint motion. In geometric language, the mass matrix provides a configuration-dependent inner product - an energy metric - on velocity directions.
*Figure 8. Energy-optimal motion can be interpreted as motion through a configuration-dependent metric.*
This viewpoint connects mechanical design to optimization. The CAD-derived mass distribution changes $$\mathbf M(q)$$; $$\mathbf M(q)$$ changes the energy landscape; the energy landscape changes which trajectories an optimizer or learning system prefers.
#### 4.4 Equations of motion
For a fixed-base system, a common form is
$$
\mathbf M(q)\ddot q + \mathbf C(q,\dot q)\dot q + \mathbf g(q) = \tau.
$$
For a floating-base robot with contact, it is more explicit to write
$$
\mathbf M(q)\dot v + \mathbf h(q,v)
\= \mathbf S^\top\tau + \mathbf J\_c(q)^\top\lambda,
$$
where $$\mathbf S$$ selects actuated joints, $$\mathbf J\_c$$ is the contact Jacobian, and $$\lambda$$ contains contact forces or wrenches. This equation reveals why a humanoid cannot directly command its base: base motion arises from the coupled effects of joint actuation, gravity, momentum, and contact.
#### 4.5 A wrong description creates a wrong universe
Every controller, trajectory optimizer, and simulated policy operates on the model implied by these equations. If a link mass, frame, inertia, or contact geometry is wrong, then $$\mathbf M$$, $$\mathbf h$$, and $$\mathbf J\_c$$ are wrong. The algorithm can be internally optimal and still fail on hardware because it optimized the wrong dynamical world.
***
### 5. The agent perspective
#### 5.1 From motion to intent
The first three perspectives answer “what can happen?” The agent perspective asks “what should happen?” It introduces goals, incomplete information, semantic observations, and decision making.
A Markov decision process is commonly written
$$
\mathcal M = (\mathcal S,\mathcal A,P,R,\gamma),
$$
with state space $$\mathcal S$$, action space $$\mathcal A$$, transition model $$P$$, reward $$R$$, and discount factor $$\gamma$$. In a partially observable setting, the robot receives an observation $$o\_t$$ rather than the full state $$s\_t$$.
At this level:
* the **state** expands beyond proprioception to include objects, terrain, people, and task context;
* the **action** may be a torque, position target, end-effector command, or high-level skill;
* the **transition model** encapsulates the machine, graph, and manifold below;
* the **reward or objective** formalizes intent.
A policy $$\pi\_\theta(a\mid o)$$ seeks to maximize expected return,
$$
J(\theta)=\mathbb E\_{\tau\sim\pi\_\theta}
\left\[\sum\_{t=0}^{T}\gamma^t R(s\_t,a\_t)\right].
$$
The action interface matters. A torque policy assumes very different low-level dynamics from a policy that outputs desired joint positions tracked by a PD controller.
#### 5.2 Symbol grounding
An instruction such as “bring me the apple” must be grounded across all four levels:
1. **Perceive:** associate pixels, depth, or language tokens with the apple.
2. **Reason:** infer that “bring” requires approach, grasp, transport, and handover.
3. **Plan:** convert the task into feasible trajectories for the body and objects.
4. **Control:** map trajectories through the kinematic graph to actuator commands.
5. **Interact:** generate contact forces using the physical mechanism.
Vision-language-action models attempt to learn parts of this mapping from multimodal data. Whether modular or end-to-end, however, the output still passes through the geometry, dynamics, and hardware constraints of the lower levels.
#### 5.3 Sim-to-real as distribution shift
A simulated policy is trained under a distribution $$P\_{\text{sim}}$$ of states, observations, and dynamics parameters. Hardware produces samples from $$P\_{\text{real}}$$. Large mismatches can appear as unfamiliar images, incorrect contact forces, actuator delays, different inertia, or any combination of these.
Domain randomization reduces overfitting by training across a family of models:
$$
\xi \sim p(\xi),
\qquad
s\_{t+1}\sim P\_\xi(\cdot\mid s\_t,a\_t),
$$
where $$\xi$$ may include mass, friction, delay, motor strength, terrain, lighting, and sensor noise. Randomization is not a substitute for system identification; it is a way to make the policy less brittle in the face of remaining uncertainty.
***
### 6. The complete embodied stack
The four views form a dependency chain:
```
Intent and semantics Agent: policy, observation, objective
↓
Dynamics and constraints Manifold: state, energy, contact, equations of motion
↓
Computable structure Graph: links, joints, frames, traversal, API
↓
Physical possibility Machine: materials, mass, actuators, geometry, heat
```
A failure at any layer propagates upward:
* a weak motor makes a commanded behavior impossible;
* a reversed transform moves the wrong body in the wrong direction;
* an incorrect inertia changes the simulated dynamics;
* a misspecified reward produces the wrong behavior efficiently.
The central lesson is therefore methodological: **debug from the bottom upward**. Before tuning a policy, verify the mechanism. Before tuning a controller, verify frames and model parameters. Before interpreting a learning curve, verify the simulated state, action, and objective.
#### Key takeaways
1. A robot description is not merely geometry; it is the interface between a machine and every algorithm above it.
2. Mass distribution, transmission dynamics, and collision boundaries are algorithmic facts because they shape the model.
3. A tree topology enables efficient recursion, whereas closed loops require additional constraints or coordinates.
4. Configuration and velocity live on structured spaces; careless Euclidean arithmetic can be physically wrong.
5. An embodied policy inherits every approximation made by the mechanical, graph, and dynamics models beneath it.
***
### 7. Review questions
1. Why can two robots with the same total mass have very different locomotion performance?
2. How does a transmission ratio affect both output torque and reflected rotor inertia?
3. Why should visual and collision geometry usually be separated?
4. What property of a kinematic tree makes recursive forward kinematics efficient?
5. Why is a floating base not equivalent to six actuated joints?
6. Give an example in which linear arithmetic on rotation coordinates produces the wrong result.
7. Trace how an incorrect link inertia can change the behavior learned by a simulated policy.
8. For the command “open the door,” identify one requirement at each of the four levels.
***
### 8. References and further reading
* Roy Featherstone, [*Rigid Body Dynamics Algorithms*](https://link.springer.com/book/10.1007/978-1-4899-7560-7).
* ROS 2 documentation, [URDF tutorials](https://docs.ros.org/en/rolling/Tutorials/Intermediate/URDF/URDF-Main.html).
* MuJoCo documentation, [overview of generalized-coordinate and optimization-based contact dynamics](https://mujoco.readthedocs.io/en/stable/overview.html).
* Joan Solà, Jérémie Deray, and Dinesh Atchuthan, [*A Micro Lie Theory for State Estimation in Robotics*](https://arxiv.org/abs/1812.01537).
* NVIDIA et al., [*GR00T N1: An Open Foundation Model for Generalist Humanoid Robots*](https://arxiv.org/abs/2503.14734).
***
---
# 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-01-perspectives-in-understanding-robots.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.