Action space

An action space is the set of commands a robot policy can output at each step: what each number in the action vector controls, its units, and its range. For a robot arm, one action might be seven target joint angles, a small change in the gripper's position and rotation, or a velocity for each joint, usually with one more value for the end-effector. The camera footage of a demonstration doesn't change with this choice, but the numbers a policy learns from do.

Two choices define most action spaces. The first is joint space versus end-effector space, covered in end-effector, where end-effector actions leave inverse kinematics to the robot's controller. The second is absolute versus delta. An absolute action names a target, such as "move the gripper to this pose," and a delta action names a change, such as "move 2 centimeters forward and rotate 5 degrees." Many vision-language-action models output delta end-effector actions. OpenVLA, for example, outputs seven values per step: three for change in position, three for change in rotation, and one for the gripper.

A robot records its commands at a fixed rate, and each step stores an action vector next to the observations from the cameras and proprioception. Training normalizes each action dimension using statistics computed over the dataset, and the policy learns to predict vectors in that same space. A policy can run only where the controller accepts its action space. Converting between spaces needs the robot's kinematics, and converting between absolute and delta actions depends on the frame rate and on which frame the deltas are measured in. DROID shows how many options one dataset can carry: each step stores commanded joint positions, joint velocities, Cartesian positions, Cartesian velocities, and gripper position and velocity, and different training codebases pick different ones.

For anyone curating robot data, the action space is metadata to check, never to assume. Pooled datasets break in quiet ways: a gripper value where 1 means open in one dataset and closed in the next, joint angles in degrees mixed with radians, or deltas computed at 15 Hz fed to a policy that runs at 30 Hz. None of these stop a training run. The statistics look normal and the loss goes down, while the policy learns contradictory commands. Checking a few episodes per source, with the recorded actions played against the camera footage, can catch these before they cost a training run. This is one of the core problems behind cross-embodiment learning.

For how normalization statistics and camera rename maps depend on correct metadata at training time, see what training reads besides the frames.

Subtract consecutive targets to get deltas, or add deltas to a starting pose to get targets. Both directions need the control rate and the reference frame, which is why the conversion often goes wrong when datasets are pooled.

A delta action is a change relative to the current state, such as moving the gripper 2 centimeters to the left, instead of an absolute target. Delta actions are easier to learn across different starting positions, but their meaning depends on the control rate and the reference frame, so two datasets with the same delta format can still disagree.

Opening and closing the gripper is the decisive moment in most manipulation tasks, and it behaves differently from arm motion. Many datasets record it as one value, either a continuous width or a near-binary open or closed command. Its convention, whether 1 means open or closed, is one of the first things to check when combining datasets.

Degrees of freedom (DoF), End-effector, Inverse kinematics, Action head / action decoder, Proprioception, Cross-embodiment.