Robot Trajectory: Definition and Robotics Data Requirements

Direct definition

What Is Robot Trajectory?

A robot trajectory is a time-indexed sequence describing how a robot or one of its components moves. It can contain joint positions, velocities, accelerations, efforts, end-effector poses, gripper state, base motion, or control targets. Timing is what distinguishes a trajectory from an unordered set of poses or a geometric path.

Plain-language analogyA path says where the robot should go. A trajectory says where it should be at each moment, how fast it moves, and often what its body is doing along the way.

Operational example

Representative robot trajectory

time_from_start: Monotonic time for each trajectory point
joint_names: Stable ordered list tied to a robot model
positions: Joint targets or measured joint states
velocities: Optional joint velocities with units
context: Task, observation window, controller, outcome, and validity

Trajectory, Path, and Action Sequence

Source-backed context[1] ROS 2 JointTrajectory message definition [2] DROID robot manipulation trajectories

A geometric path describes a route through configuration or workspace without necessarily specifying when each point is reached. A trajectory adds time and may include velocity, acceleration, effort, or other dynamics. An action sequence records commands, which can resemble a trajectory but may differ from the motion that the robot actually executed.

The distinction matters during collection. A planned trajectory, commanded trajectory, and measured trajectory can diverge because of controller behavior, safety limits, latency, contact, or tracking error. A dataset should name which one it contains and preserve links among them when more than one is available.

Joint-Space and Cartesian Trajectories

Source-backed context[1] ROS 2 JointTrajectory message definition [3] ROS 2 Pose message definition

Joint-space trajectories describe how individual robot joints change. Cartesian trajectories describe the position and orientation of an end effector, camera, base, object, or other frame. A robot model and forward kinematics can relate the two, but the mapping depends on joint configuration and is not always one-to-one.

Learning systems may use both. Joint data gives embodiment-specific configuration and control detail. Cartesian data can make task geometry easier to compare across robots. Coordinate frames, transform conventions, units, joint names, and the robot description must stay attached to the release.

How Trajectories Become Training Examples

Source-backed context[2] DROID robot manipulation trajectories [4] LeRobotDataset v3 episode format

A trajectory becomes useful for policy learning when it is aligned with the observations and task context that explain why each movement occurred. Camera frames, robot state, action commands, language, object state, contact signals, and outcomes may all provide this context. Episode boundaries define which sequence belongs to which attempt.

Preprocessing can resample trajectories, transform coordinate frames, normalize values, segment action chunks, or derive velocities. Each transformation should be versioned and traceable to the raw sequence. Otherwise a model result cannot be reproduced against the original motion.

Trajectory Data Failure Modes

Source-backed context[1] ROS 2 JointTrajectory message definition [2] DROID robot manipulation trajectories

A smooth plotted line can still be wrong. Timestamps may be non-monotonic, coordinate frames may switch, joint ordering may change, rotations may use inconsistent conventions, or interpolation may cross discontinuities. Failed attempts and recovery motion are often removed even though they describe states the deployed policy will encounter.

Acceptance tests should check timing, continuity, limits, frame transforms, commanded-versus-measured differences, interpolation, terminal states, and visual alignment. Representative trajectories should replay through the production loader and visualization tools.

Path data mislabeled as time-indexed trajectory data
Commanded and measured motion combined without a source flag
Quaternion, Euler-angle, or rotation ordering undocumented
Resampling method and original timestamps discarded
Recovery, intervention, and failure segments removed

What a Buyer Should Specify

Implementation guidanceEGXO guidance for translating the definition into a project specification.

Define the body or frame being tracked, whether values are planned, commanded, or measured, and which dynamics are required. State how the trajectory aligns with observations, actions, task phases, and outcomes. Include raw and processed versions when downstream transformations are material.

Joint-space, Cartesian, object, camera, or base trajectory
Planned, commanded, measured, derived, or retargeted origin
Timestamps, sampling rate, interpolation, and valid masks
Joint names, units, axes, frames, and rotation convention
Episode, task, action, contact, and outcome alignment
Robot-model and preprocessing-version lineage

Research basis

Primary Sources and Further Reading

The sources establish the technical context. The buyer requirements are EGXO guidance for converting that context into a testable data specification.

Robot Trajectory