Data & collection
Visual-inertial odometry
Visual-inertial odometry estimates a moving sensor rig's motion by combining camera observations with inertial measurements from accelerometers and gyroscopes. Its core output is a relative motion or pose estimate over time, not an independently measured ground-truth trajectory or necessarily a reusable global map.
Also known as: VIO, visual inertial odometry
Updated
Images and inertial samples constrain the same motion
VIO combines visual evidence across images with the rig's inertial measurements. OpenVINS provides a concrete filter-based implementation: an extended Kalman filter fuses inertial information with sparse visual feature tracks through a sliding-window formulation. That is one implementation, not a definition requiring every VIO system to use a Kalman filter.
The relationship between sensors matters as much as their individual specifications. Camera intrinsics, the camera-to-IMU transform and their timing relationship are explicit calibration quantities in OpenVINS. Sensor calibration and data synchronisation should therefore be treated as part of the recording pipeline, not inferred from the mere presence of cameras and an IMU.
Odometry and SLAM are related but different
Odometry emphasises the rig's motion; SLAM jointly estimates pose and a map that can support later localisation. The ORB-SLAM3 paper distinguishes these goals while noting that odometry systems with loop-closing extensions make the boundary less sharp. A product labelled VIO may include additional mapping features, so inspect its actual outputs rather than deciding from the acronym alone.
Visual-inertial sensing also does not supply every global reference. OpenVINS's observability analysis identifies global translation and yaw about gravity as unobservable in its analysed setup. Choosing an initial origin produces coordinates; it does not turn those coordinates into externally referenced truth.
A headset trajectory is not a hand-action label
For egocentric robot-learning data, VIO can describe how the recording rig moved while a person performed a task. It does not by itself measure finger joints, object pose, contact forces or the robot command that would reproduce the action. Those require separate measurements or inference, with their own uncertainty.
Keep raw camera and IMU data distinct from the derived trajectory. Record the estimator and calibration versions, frame conventions, output timestamps, tracking failures and resets. If a later mapping stage revises the trajectory, label the corrected result separately from the online estimate available during capture. This prevents training or evaluation from silently treating future-corrected poses as causal sensor observations.
Sources
Related terms
Hardware & control
State estimation
State estimation is the process of inferring variables that are not known exactly—such as a robot’s base pose, velocity, contact state or sensor bias—from noisy measurements, control inputs and a model of how the system evolves. An estimator should provide both an estimate and, where possible, a representation of its uncertainty.
Models & learning
Pose estimation
Pose estimation is the process of inferring the position and orientation of a body, object, camera, hand, or robot relative to a specified coordinate frame. In three-dimensional robotics this is often called 6D or 6-DoF pose estimation because the result has three translational and three rotational degrees of freedom, even when orientation is stored with more than three numbers.
Data & collection
Sensor calibration
Sensor calibration is the estimation and documentation of parameters that map raw sensor readings into physically meaningful values and known spatial relationships. In robotics it can include scale, bias, distortion, intrinsic camera parameters, sensor-to-sensor or sensor-to-robot transforms, and timing offsets. Calibration does not remove all noise or drift.
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.
Hardware & control
SLAM
SLAM is the joint estimation of a moving robot or sensor rig's pose and a map of its environment from sensor observations. It addresses the coupled problem of needing a map to localise while needing pose estimates to build that map.
Hardware & control
Observability
Observability is the property that a system's internal state can be determined from its measured outputs over time, given the known inputs and the assumed model. If different states can generate indistinguishable observations, those differences are unobservable under that sensing setup.