Drift (tracking)
More actions
Drift in motion tracking is the gradual build-up of error in an estimated orientation or position when that estimate is computed by adding up relative measurements over time, a process known as dead reckoning. Steven M. LaValle and colleagues at Oculus VR defined drift error as the difference between the estimated and the true orientation, a dead-reckoning error that accumulates as gyroscope readings are integrated over time.[1] In visual odometry the same effect appears because each frame-to-frame motion estimate adds a little error, so the estimated path slowly departs from the real one.[2]
In virtual reality (VR) and augmented reality (AR), drift shows up as a virtual world that slowly rotates away from the user's real "forward" direction, or as virtual objects that slide away from the place in the room where they were put.[3][4] Tracking systems limit it by fusing the drifting estimate with measurements that hold an absolute reference: gravity and the magnetic field for orientation, external cameras or laser base stations for position, and recognized places in a map for inside-out systems that use visual-inertial odometry or SLAM.[1][5]
Causes
Integration of inertial sensors
An inertial measurement unit (IMU) reports angular velocity from a gyroscope and linear acceleration from an accelerometer. Orientation is obtained by integrating angular velocity once; position would require integrating acceleration twice. Any error in a reading is carried forward into every later estimate.[6] The 2014 Oculus paper models the gyroscope output as the true angular velocity plus a scale-factor error, cross-axis coupling, a zero-rate offset (bias) and random noise. Factory calibration can estimate the scale and bias terms, but calibration imperfections and temperature dependence mean they cannot be removed completely.[1] In his textbook on virtual reality, LaValle adds that even a perfectly calibrated gyroscope would still drift because of quantized outputs, limited sampling rates and unmodeled noise.[7]
Oliver J. Woodman's 2007 Cambridge technical report on inertial navigation describes how each error type grows over time:[6]
| Error source | Effect after integration |
|---|---|
| Constant gyroscope bias | Orientation error that grows linearly with time |
| Gyroscope white noise | Angle random walk whose standard deviation grows with the square root of time |
| Gyroscope bias instability (flicker noise) | Second-order random walk in angle |
| Constant accelerometer bias | Position error that grows quadratically with time |
| Accelerometer white noise | Second-order random walk in position, growing in proportion to t3/2 |
Woodman identifies the propagation of gyroscope errors into position as the critical error path. A small tilt error in the estimated orientation means part of gravity is not subtracted and is instead treated as horizontal acceleration. His example is a tilt error of 0.05 degrees, which leaves a residual acceleration of 0.0086 m/s2 and a horizontal position error of 7.7 m after 30 seconds. For a simple inertial navigation system built on an Xsens Mtx IMU, the average position error grew to more than 150 m after 60 seconds, and fusing magnetometer data reduced it to about 5 m.[6]
Unobservable directions
Some components of the pose cannot be measured directly by the available sensors, so their errors are never corrected and keep growing. Gravity gives a fixed "down" direction but says nothing about rotation around the vertical axis. For this reason LaValle's group splits orientation drift into tilt error (which makes the virtual horizon appear not level) and yaw error (rotation about the vertical axis).[1] An IMU also cannot distinguish motion at constant velocity from standing still.[7]
The same limits apply to camera-plus-IMU systems. Joel Hesch, Dimitrios Kottas, Sean Bowman and Stergios Roumeliotis showed in IEEE Transactions on Robotics (2014) that a vision-aided inertial navigation system has four unobservable directions: three degrees of freedom of global translation and one of rotation about the gravity vector.[8] The authors of the VINS-Mono estimator draw the practical conclusion: because the IMU makes roll and pitch observable, drift in a monocular visual-inertial system occurs only in x, y, z and yaw, so their loop-closure pose graph is optimized in those four degrees of freedom.[9]
Scale drift in monocular vision
A single camera recovers motion and structure only up to an unknown scale. Hauke Strasdat, J. M. M. Montiel and Andrew Davison explained at Robotics: Science and Systems 2010 that without the known baseline of a stereo rig, the scale of locally built map portions and motion estimates can drift over time. Their analysis counts seven degrees of gauge freedom for monocular SLAM (a rigid 6 DoF transformation plus scale), compared with six for stereo or laser SLAM in 3D, and three for a ground robot building a planar map. Drift in those degrees of freedom grows with the distance between parts of the map, and loop-closure optimization has to correct it in all seven.[10] Scaramuzza and Fraundorfer note that stereo visual odometry shows less drift than monocular for small motions, but that stereo degenerates into the monocular case when the scene is much farther away than the stereo baseline.[2] Adding an IMU makes metric scale observable, which is one reason visual-inertial systems drift only in the four directions listed above.[9]
Correction methods
Absolute references and filtering
Drift is corrected by measuring the accumulated error with a sensor that has an absolute reference and feeding that error back into the estimate. A common approach is the complementary filter, which trusts the gyroscope over short intervals and the reference sensor over long intervals.[11] LaValle's textbook gives an example gain of 0.0001 for the correction, so that the reference sensor has only a gradual effect, and notes that a camera may provide a reference at 60 Hz while the gyroscope reports at 1000 Hz. The gain must be high enough to remove the drift but low enough that the user does not notice the corrections. A Kalman filter can be used to choose the gain optimally, though that optimality holds only for linear stochastic systems, which human body tracking is not.[7] These techniques are covered in more detail under sensor fusion.
- Tilt is corrected with the accelerometer. Averaged over time, accelerometer output gives a good estimate of the direction of gravity, even though during head movement it also contains linear acceleration.[1] In his 2013 blog post on the Rift's sensor fusion, LaValle described applying the correction only when the measured acceleration is close to 9.8 m/s2 and the gyroscope reports very slow rotation, and making a tiny correction on each cycle of the fusion loop.[12]
- Yaw is corrected with a magnetometer, which is less straightforward than using it as a compass. The Earth's field varies from 0.25 to 0.65 Gauss over the planet's surface, its declination from true north can reach 25 degrees in inhabited areas, and its inclination varies up to 90 degrees. Ferrous materials and circuits in and around the headset add their own fields.[1] The Oculus method calibrated the magnetometer, stored "reference points" (a magnetometer reading together with the orientation estimate at that moment) and compared later readings with a reference point recorded at a nearby orientation to detect yaw error, using several reference points spread over the range of orientations. The method needs a field that is roughly constant over the small work area, not knowledge of true north.[1][3]
- Position cannot be corrected by the IMU alone. LaValle's textbook explains that a calibration error causes linearly growing drift after the single integration used for orientation but quadratically growing drift after the double integration used for position, which "becomes unbearable in practice after a fraction of a second".[7] Position drift is instead estimated from external measurements such as camera images of known features, solved as a Perspective-n-Point problem, and blended into the IMU estimate with the same kind of filter.[7]
Loop closure and relocalization
Visual odometry estimates the path pose after pose, so its error keeps accumulating.[2] Optimizing over a sliding window of recent poses (bundle adjustment over the last frames) reduces the drift; in a 10 km experiment by Konolige and colleagues, cited in the Scaramuzza and Fraundorfer tutorial, windowed bundle adjustment cut the final position error by a factor of 2 to 5.[2] It does not remove drift altogether. SLAM adds a map so that the system can recognize a place it has visited before. In the words of the 2016 survey by Cadena and colleagues, without a map "dead-reckoning would quickly drift over time", while with a map of distinguishable landmarks the robot can "reset" its localization error by revisiting known areas, which is loop closure.[5] The same survey states that visual-inertial odometry algorithms of the time had very small drift, under 0.5 percent of the trajectory length.[5]
The first arXiv version of the VINS-Mono paper gives an example of the difference. In a mixed indoor and outdoor walk of more than 700 m, lasting about ten minutes, that started and ended at the same seat in a laboratory, the final drift without loop closure was [-5.47, 2.76, -0.29] m in x, y and z, or 0.88 percent of the trajectory length; with loop closure it was [-0.032, 0.09, 0.07] m.[9]
In VR and AR
Rotation-only headsets
The 2014 Oculus paper describes head tracking for the Oculus Rift Development Kit, whose sensor board carried an Invensense MPU-6000 gyroscope and accelerometer and a Honeywell HMC5983 magnetometer. Sensor observations were reported at 1000 Hz, although the magnetometer readings changed only at 220 Hz. The paper's methods maintain head orientation, and it presents positional tracking as ongoing research.[1] LaValle wrote that the Rift Development Kit suffered from yaw drift, "a steadily growing error in the estimated 'forward' direction". In a first-person shooter this might not matter, because the player can turn the avatar without any fixed reference, but in a cockpit game the cockpit slowly drifts to the side while the player still faces forward in the real world. In seated tests of more than twenty minutes, with head orientation measured by an OptiTrack motion capture system, the Oculus yaw correction kept the average yaw error at about 3.7 degrees and the worst case within 10 degrees.[3] LaValle wrote that a tilt correction the player notices could be nauseating, and the yaw corrections were applied gradually, slowly enough that users would not notice them.[12][3]
The same paper reported the team's attempts at estimating position from the IMU alone. Straight double integration of acceleration produced a position error of more than 500 m after one minute; constraining the motion with a simple torso-and-head kinematic model kept the error within 1.1 m, but the method was only effective over a few seconds. The authors said their newest prototypes instead combined the IMU with "position data from a camera that observes infrared LEDs on the Rift surface".[1]
Phone-based mobile VR headsets such as Google's Daydream View also tracked rotation only; Google described the Daydream View as a 3DoF headset with a 3DoF controller.[13] Google's documentation for Daydream apps described its default recentering, triggered by a long press of the controller's home button, as a way to let users reorient themselves and "compensate for certain types of sensor drift". The Google VR developer site has since been archived.[14] In OpenXR, a runtime may offer a system-level recentering action that makes the user's current leveled head pose the new origin of the LOCAL reference space, and must notify the application when it happens.[15]
Outside-in tracking
External tracking systems provide the absolute positional reference that an IMU lacks. With Valve's Lighthouse system, as Hackaday summarized a 2016 Hackaday Superconference talk by its inventor, Valve engineer Alan Yates, the tracked device's IMU handles high-frequency movement and is "disciplined by the less frequent Lighthouse updates", giving both fast response and long-term accuracy.[16] LaValle's textbook adds that a camera's optical axis gives a direct reference for yaw drift in camera-based systems.[7]
Inside-out tracking and world-locked content
Inside-out headsets and phones estimate pose with cameras and IMUs. Apple documents that ARKit uses visual-inertial odometry, combining motion-sensor data with computer vision analysis of features in the camera image, and warns that world tracking depends on environmental details that "can be difficult to measure in real time without a degree of error".[17] Many vendors do not publish the internals of their tracking, including how they handle drift.
As the system's model of the environment is refined, content placed in a single global coordinate system can appear to move. Google's ARCore documentation says that virtual objects "can appear to drift away from where they were placed" as ARCore's environmental understanding updates, and recommends attaching objects to anchors and keeping them within 8 m of their anchor to avoid unexpected rotational movement.[4] The OpenXR specification gives the same reason for its spatial anchor extensions. Its description of Microsoft's unbounded reference space extension also notes that such a space adjusts its origin to keep coordinates stable near the viewer, which may cause content placed far away to drift in its alignment to the real world.[15] Microsoft's mixed reality guidance says holograms should be rendered within 3 m of their spatial anchor, and that holograms placed directly in the stationary frame of reference "might experience drift when the user is far from the hologram".[18]
Microsoft's World Locking Tools, a Unity library for HoloLens, explained that inside-out tracking is good at locating the head relative to nearby features but less good at measuring how far the head has traveled. When the user walks from point A to point B and back, the system's distance estimate is close to correct but not exactly correct, an effect the documentation calls drift. The tools corrected drift by recognizing from the physical features around point A that the head was back near A and correcting the head's coordinates; their engine computed a "world locked" coordinate space from a graph of active spatial anchors, chosen so that the anchors moved as little as possible. The documentation is now in Microsoft's retired archive.[19]
Measurement
Drift is usually reported separately from global accuracy. In the TUM RGB-D benchmark, Jürgen Sturm and colleagues defined the relative pose error, which measures the local accuracy of a trajectory over a fixed time interval and therefore "corresponds to the drift of the trajectory", alongside the absolute trajectory error used to judge the global consistency of SLAM systems.[20] Visual odometry results are also often given as final drift as a percentage of the distance traveled, as in the VINS-Mono experiments.[9]
For AR, researchers have measured drift as the displacement of a virtual object from where it was placed. In a 2021 preprint, Tim Scargill, Jiasi Chen and Maria Gorlatova defined hologram drift as the Euclidean distance between a hologram's original and later position and measured it with their HoloMeasure app. On an iPhone 11 running iOS 14.4 and ARKit 4, tested in more than 200 environments per action, mean drift ranged from 1.2 cm to 43.2 cm depending on which of six user actions came between the two views. In cross-platform tests, ARKit had lower drift for four of the six actions, while ARCore did much better when the user walked away and came back (mean drift of 4.8 cm on ARCore against 25.1 cm on ARKit).[21] These figures describe the software versions tested in 2021, not current releases.
See also
References
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 Steven M. LaValle, Anna Yershova, Max Katsev, Michael Antonov (2014-05). "Head tracking for the Oculus Rift". Proceedings of the 2014 IEEE International Conference on Robotics and Automation (ICRA), pp. 187-194. IEEE. doi:10.1109/ICRA.2014.6906608. https://doi.org/10.1109/ICRA.2014.6906608. Retrieved 2026-10-12.
- ↑ 2.0 2.1 2.2 2.3 Davide Scaramuzza, Friedrich Fraundorfer (2011-12). "Visual Odometry [Tutorial"]. IEEE Robotics & Automation Magazine, vol. 18, no. 4, pp. 80-92. doi:10.1109/MRA.2011.943233. https://doi.org/10.1109/MRA.2011.943233. Retrieved 2026-10-12.
- ↑ 3.0 3.1 3.2 3.3 Steve LaValle (2013-12-29). "Help! My Cockpit Is Drifting Away". Meta for Developers (Oculus developer blog). Meta. https://developers.meta.com/horizon/blog/magnetometer/. Retrieved 2026-10-12.
- ↑ 4.0 4.1 "Working with Anchors". ARCore documentation. Google. https://developers.google.com/ar/develop/anchors. Retrieved 2026-10-12.
- ↑ 5.0 5.1 5.2 Cesar Cadena, Luca Carlone, Henry Carrillo, Yasir Latif, Davide Scaramuzza, Jose Neira, Ian Reid, John J. Leonard (2016-12). "Past, Present, and Future of Simultaneous Localization and Mapping: Toward the Robust-Perception Age". IEEE Transactions on Robotics, vol. 32, no. 6, pp. 1309-1332. doi:10.1109/TRO.2016.2624754. https://doi.org/10.1109/TRO.2016.2624754. Retrieved 2026-10-12.
- ↑ 6.0 6.1 6.2 Oliver J. Woodman (2007-08). "An introduction to inertial navigation". Technical Report UCAM-CL-TR-696. University of Cambridge Computer Laboratory. https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-696.pdf. Retrieved 2026-10-12.
- ↑ 7.0 7.1 7.2 7.3 7.4 7.5 Steven M. LaValle (2020). "Virtual Reality, Chapter 9: Tracking". Virtual Reality (online draft, lavalle.pl). http://lavalle.pl/vr/vrch9.pdf. Retrieved 2026-10-12.
- ↑ Joel A. Hesch, Dimitrios G. Kottas, Sean L. Bowman, Stergios I. Roumeliotis (2014-02). "Consistency Analysis and Improvement of Vision-aided Inertial Navigation". IEEE Transactions on Robotics, vol. 30, no. 1, pp. 158-176. doi:10.1109/TRO.2013.2277549. https://doi.org/10.1109/TRO.2013.2277549. Retrieved 2026-10-12.
- ↑ 9.0 9.1 9.2 9.3 Tong Qin, Peiliang Li, Shaojie Shen (2017-08-13). "VINS-Mono: A Robust and Versatile Monocular Visual-Inertial State Estimator". arXiv:1708.03852v1 (later published in IEEE Transactions on Robotics, vol. 34, no. 4, pp. 1004-1020, 2018). doi:10.1109/TRO.2018.2853729. https://arxiv.org/abs/1708.03852v1. Retrieved 2026-10-12.
- ↑ Hauke Strasdat, J. M. M. Montiel, Andrew J. Davison (2010-06). "Scale Drift-Aware Large Scale Monocular SLAM". Robotics: Science and Systems VI. doi:10.15607/RSS.2010.VI.010. https://doi.org/10.15607/RSS.2010.VI.010. Retrieved 2026-10-12.
- ↑ Gordon Wetzstein. "EE 267 Virtual Reality Course Notes: 3-DOF Orientation Tracking with IMUs". EE 267 Virtual Reality course notes. Stanford University. https://web.stanford.edu/class/ee267/notes/ee267_notes_imu.pdf. Retrieved 2026-10-12.
- ↑ 12.0 12.1 Steve LaValle (2013-05-22). "Sensor Fusion: Keeping It Simple". Meta for Developers (Oculus developer blog). Meta. https://developers.meta.com/horizon/blog/sensor-fusion-keeping-it-simple/. Retrieved 2026-10-12.
- ↑ "Degrees of freedom". Google VR developer documentation (archived). Google. https://developers.google.com/vr/discover/degrees-of-freedom. Retrieved 2026-10-12.
- ↑ "Recentering for Daydream apps in Unity". Google VR developer documentation (archived). Google. https://developers.google.com/vr/develop/unity/guides/recentering. Retrieved 2026-10-12.
- ↑ 15.0 15.1 "The OpenXR Specification (version 1.1)". Khronos OpenXR Registry. The Khronos Group. https://registry.khronos.org/OpenXR/specs/1.1/html/xrspec.html. Retrieved 2026-10-12.
- ↑ Elliot Williams (2016-12-21). "Alan Yates: Why Valve's Lighthouse Can't Work". Hackaday. https://hackaday.com/2016/12/21/alan-yates-why-valves-lighthouse-cant-work/. Retrieved 2026-10-12.
- ↑ "Understanding World Tracking". Apple Developer Documentation. Apple. https://developer.apple.com/documentation/arkit/understanding-world-tracking. Retrieved 2026-10-12.
- ↑ "Spatial anchors". Mixed Reality documentation. Microsoft. https://learn.microsoft.com/en-us/windows/mixed-reality/design/spatial-anchors. Retrieved 2026-10-12.
- ↑ "The basic idea of World Locking Tools". Microsoft Learn (previous versions). Microsoft. https://learn.microsoft.com/en-us/previous-versions/mixed-reality/world-locking-tools/documentation/concepts/basicconcepts. Retrieved 2026-10-12.
- ↑ Jürgen Sturm, Nikolas Engelhard, Felix Endres, Wolfram Burgard, Daniel Cremers (2012-10). "A benchmark for the evaluation of RGB-D SLAM systems". 2012 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pp. 573-580. doi:10.1109/IROS.2012.6385773. https://doi.org/10.1109/IROS.2012.6385773. Retrieved 2026-10-12.
- ↑ Tim Scargill, Jiasi Chen, Maria Gorlatova (2021-09-29). "Here To Stay: Measuring Hologram Stability in Markerless Smartphone Augmented Reality". arXiv:2109.14757. https://arxiv.org/abs/2109.14757. Retrieved 2026-10-12.