Data & collection
Robot state
Robot state is the set of variables used to describe a robot at a particular time, such as joint positions and velocities, base pose, end-effector pose, gripper state, actuator measurements, or estimated motion. In control theory, a complete state contains enough information to predict future evolution given an action; in robot datasets, “state” often means only the measured or estimated subset that was logged.
Also known as: robot state vector, robot-state data
Updated
State is not the same as observation
In a dynamical model, state collects the variables needed to describe how the system can evolve. Probabilistic Robotics treats state as aspects of the robot and environment that can affect the future. Sensors provide observations from which some of that state must be inferred.
The true state is rarely available on hardware. A camera does not directly reveal every object property, and encoders do not fully determine a floating humanoid's world pose. A state estimator combines measurements and models to produce an estimate, sometimes with uncertainty.
Dataset “state” is usually a practical subset
Robot datasets commonly use “observation.state” for measured or derived robot variables. DROID, for example, exposes joint position, Cartesian end-effector position and gripper position as observation fields while storing commands separately.
That schema is useful, but it is not a claim that every variable required by a formal Markov state is present. Contact, object motion, motor temperature or base velocity may remain unobserved. Simulation can also expose privileged state that a deployed robot cannot measure.
State fields need physical definitions
A state vector should document each element's name, units, coordinate frame, source, sampling rate and whether it is raw, filtered or estimated. Position, velocity, measured torque and commanded targets should not be merged under an unnamed numeric array.
For humanoids, base pose, IMU data, joint state, hand configuration and contact assumptions may come from different clocks and estimators. Their timestamps and calibration determine whether the combined vector describes one physical instant.
Sources
Related terms
Hardware & control
Proprioception
Proprioception is sensing of a robot’s own internal configuration and motion rather than the external scene. For a humanoid it commonly includes joint positions and velocities, actuator effort or torque, and inertial measurements of body rotation and acceleration. These signals support state estimation and feedback control but do not, by themselves, directly describe nearby objects or terrain.
Models & learning
Markov decision process
A Markov decision process is a mathematical model of sequential decision-making defined by states, actions, transition probabilities and rewards. After an agent chooses an action, the current state and action determine the distribution of the next state and reward. Reinforcement-learning methods use this structure to compare policies by expected cumulative reward.
Hardware & control
Robot embodiment
A robot embodiment is the particular body and sensorimotor interface through which a robot perceives and acts. It includes morphology and kinematics, actuators, end effectors, sensors, physical limits, and the observation and action conventions exposed to a controller or learned policy. Two robots can perform the same task while having different embodiments.
Models & learning
Policy
A policy is the decision rule that maps a robot’s current observations or estimated state, and sometimes a task instruction, to an action or probability distribution over actions. It can be hand-designed or learned from demonstrations, rewards or both. In humanoid robotics, its outputs may be joint targets, torques, end-effector changes or higher-level skills.
Data & collection
Data synchronisation
Data synchronisation is the process of placing sensor, state, action, annotation, and outcome records on a common timeline so samples that describe the same physical instant or transition can be matched. It requires trustworthy timestamps or trigger relationships and an explicit rule for handling streams with different rates, delays, dropped samples, and clock offsets.