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.
Also known as: data synchronization, sensor synchronisation, sensor synchronization, temporal alignment, time alignment
Updated
A shared file is not necessarily a shared time
Putting video, joint state and actions in one episode does not prove that their samples refer to the same instant. Sensors may use different clocks and rates, buffers may add delay, and frames may arrive out of order or disappear.
Clock synchronisation makes timestamps comparable. Stream alignment then decides which samples belong together. These are related but distinct jobs: perfectly synchronised clocks do not specify whether a 30 Hz camera frame should pair with the preceding, nearest or interpolated 100 Hz state sample.
Exact and approximate matching answer different questions
ROS 2 message filters provide exact and approximate timestamp policies. Exact matching requires equal timestamps. Approximate matching groups nearby messages according to a policy, which can be necessary for independently triggered sensors but introduces a tolerance that must be recorded.
Interpolation, resampling and holding the last value can create a regular training sequence. Each method makes assumptions about motion between samples. Fast contact signals may be lost by downsampling, while nearest-neighbour matching can attach a camera observation to an action from the wrong side of a collision.
Misalignment changes the learned cause
Observation-action learning assumes that the action label follows from the paired observation. A fixed offset or variable latency can instead teach stale control. DROID documents synchronised camera streams and a common recording rate, illustrating why timing belongs in dataset provenance.
A dataset should preserve original timestamps, clock source, trigger method, measured offsets, rates, dropped-sample policy and every resampling step. Synchronisation quality should be tested with events visible in more than one stream, not inferred from equal array lengths.
Sources
Related terms
Data & collection
Robot training data
Robot training data is recorded experience used to train, fine-tune, or adapt models for robot perception, prediction, planning, or control. It can include sensor observations, robot state, actions, task instructions, rewards or outcomes, demonstrations, failures, and embodiment metadata. Not every dataset contains every field, but their timing and physical meaning must be clear.
Data & collection
Trajectory
A trajectory is a time-ordered sequence of states or observations, actions and, where applicable, rewards generated as an agent or robot evolves. A complete episode or policy rollout often yields a trajectory, but the terms are not universally identical: trajectories may be partial, while episodes have dataset- or environment-defined boundaries.
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.
Hardware & control
Control frequency
Control frequency is the rate, usually expressed in hertz, at which a robot control loop reads state, updates its controller or policy, and issues commands. A robot can contain several nested loops at different rates, so policy frequency, actuator-control frequency, sensor sampling rate, and dataset frame rate should not be assumed to be identical.
Hardware & control
Control latency
Control latency is the elapsed time between a relevant event or observation and the physical effect of the resulting robot command. It can include sensor exposure and transport, preprocessing, policy inference, network transfer, controller scheduling, actuator response, and communication back to a human operator. The measured boundary must be stated because each component has a different latency.