An end-effector pose describes where a robot's tool is and which way it's pointed: three numbers for position (x, y, z) and three more degrees of freedom for orientation, six total. It's the quantity most manipulation policies actually predict or track, because it's closer to "what the task requires" than a list of joint angles is — grasping a handle cares about where the gripper is and how it's rotated relative to the handle, not which combination of shoulder and elbow angles got it there. But a pose is meaningless without two things stated alongside it: the reference frame it's measured in, and the representation used to encode the rotation.
Frames: base, world, tool, TCP
A pose is always a pose relative to something. The frames that show up constantly in manipulation:
- World frame. Fixed relative to the environment — a table, a room, a mocap origin. Useful for tasks defined relative to the scene rather than the robot.
- Base frame. Fixed to the robot's mounting point. Most robot APIs report joint state and often end-effector pose relative to this frame by default.
- Tool flange frame. The mechanical mounting interface at the end of the robot's last link, defined by the robot manufacturer, independent of whatever tool is attached.
- Tool center point (TCP) frame, also called the end-effector frame. Defined by you, at whatever point on the attached tool is actually functionally relevant — the midpoint between a gripper's fingertips, the tip of a screwdriver bit, the center of a suction cup.
A URDF or robot description typically fixes the base and flange frames; the TCP frame is the one you configure per tool, and it's the one that matters for the task.
Representing rotation: why the encoding matters
Three-DoF rotation has several standard encodings, and they are not interchangeable in practice:
- Euler angles (roll-pitch-yaw and variants) are compact and human-readable, but they suffer from gimbal lock — configurations where two rotation axes align and a degree of freedom is effectively lost — and the same orientation can be written with more than one angle triple, making the mapping from orientation to angles discontinuous.
- Rotation matrices (3x3, orthonormal) have no singularities and compose cleanly, but are a 9-number representation of something with only 3 degrees of freedom, and a network's raw output has to be re-orthonormalized to stay a valid rotation.
- Quaternions are compact (4 numbers), singularity-free, and standard in robotics libraries — but a rotation and its negation represent the same orientation (double cover), which is itself a discontinuity a regression model has to learn around.
- 6D continuous representation, from Zhou et al.'s "On the Continuity of Rotation Representations in Neural Networks" (CVPR 2019), encodes the first two rows or columns of the rotation matrix directly and reconstructs a valid rotation via Gram-Schmidt orthonormalization. The paper shows Euler angles and quaternions are both discontinuous as regression targets in ways that hurt neural network training, and that a continuous 6D (or 5D) representation avoids the problem — which is why it has become common as an action-space encoding for learned manipulation policies.
The TCP offset problem
Every pose you record or command is only correct if the TCP-to-flange transform is correct. Get that offset wrong — a miscalibrated gripper length, a tool swapped without updating the transform, a fingertip that wears down over months of use — and every logged pose is off by a fixed, silent error, even though the joint angles and the physical motion were exactly right. This is a common, hard-to-notice failure mode in demonstration data collection: nothing in the recording looks wrong, because joint states and camera frames are internally consistent, but the derived end-effector poses are shifted, which teaches a policy the wrong relationship between what it sees and where the tool actually is. Recalibrating and version-controlling the TCP transform whenever a tool changes is a small habit that prevents a hard-to-diagnose data bug later.
Absolute versus delta action spaces
A policy that outputs end-effector poses can be trained to predict either:
- Absolute pose — the target pose in a fixed frame, at each timestep. Simple to interpret, easy to debug against ground truth, and doesn't accumulate drift, but it requires the policy to implicitly learn where it is relative to the task from observations alone, and it doesn't generalize as cleanly to novel starting positions.
- Delta (relative) pose — the change from the current pose to the next target, usually expressed in the current tool or base frame. Generalizes better across starting configurations since the policy only has to learn a local correction, but small per-step errors can accumulate into drift over a long rollout, and delta actions are meaningless without knowing exactly which frame and timestep they're relative to.
Why the action space you record determines what you can train
This choice can't be made after the fact. If a dataset only logs absolute poses at low frequency with no reliable timestamp alignment to state, you cannot cleanly reconstruct accurate deltas later — you'd be differencing noisy, unevenly-spaced samples and calling the result an action. Conversely, if only relative motion was logged and the base frame or origin drifted between episodes, absolute pose is unrecoverable. Deciding the action space — absolute or delta, which frame, which rotation representation — is a recording-time decision, and it constrains every architecture choice downstream, from the loss function a policy uses to whether action chunking is even meaningful for the task.