OSVR-Core
OSVR-Core copied to clipboard
OSVR
Option to use camera as absolute yaw reference
Right now, to my understanding, the HDK does not take advantage of its magnetometer and the camera is only used as a "forward" reference when the server starts. This has resulted in often excessive yaw drift for myself and at least one other HDK user I've spoken to.
It would be extremely useful if the rotation data from the camera could be merged with the IMU rotational data. Or, as a stop-gap, it would be equally acceptable if there was an option to prioritize rotation data from the camera over the IMU, and only fall back on the IMU when the camera can't see enough beacons. This would be very helpful to those developing "cockpit" games that require a constant forward reference, as right now such games become unplayable after a time.
We can add config option to use the magnetometer. It requires one-time calibration for any magnetic environment (a few 'figure-8' movements), but it seems a small price to pay for what you are describing
On Fri, Feb 26, 2016 at 8:31 PM, nanospork [email protected] wrote:
Right now, to my understanding, the HDK does not take advantage of its magnetometer and the camera is only used as a "forward" reference when the server starts. This has resulted in often excessive yaw drift for myself and at least one other HDK user I've spoken to.
It would be extremely useful if the rotation data from the camera could be merged with the IMU rotational data. Or, as a stop-gap, it would be equally acceptable if there was an option to prioritize rotation data from the camera over the IMU, and only fall back on the IMU when the camera can't see enough beacons. This would be very helpful to those developing "cockpit" games that require a constant forward reference, as right now such games become unplayable after a time.
— Reply to this email directly or view it on GitHub https://github.com/OSVR/OSVR-Core/issues/374.
Yuval Boger CEO | VRguy http://www.vrguy.net Sensics, Inc. http://www.sensics.com
Latest news and blog posts: 21 Feb: VRguy podcast Episode 3: Paul Travers, CEO of Vuzix, on AR/VR in the Enterprise and Consumer Markets http://sensics.com/vrguy-podcast-episode-3-paul-travers-ceo-of-vuzix-on-arvr-in-the-enterprise-and-consumer-markets/ 16 Feb: Vision Summit 2016: Using OSVR to Support (practically) Any Device in AR/VR http://vrguy.blogspot.com/2016/02/vision-summit-2016-using-osvr-to.html 25 Jan: Got new or custom HMD? Need direct render, time warping, distortion correction and game engine integration? http://vrguy.blogspot.com/2016/01/got-new-hmd-need-direct-render-time.html
You can check out the IMU class in VRPN for a way to auto-calibrate the magnetometer while the server is running. It has the deficit that it rotates north a lot while the user is first moving around but the benefit that it does not need parameters. A better solution would probably have at least a cached initial guess for the calibrations that could be optimized during running.
We don't have access to the mag, Russ, that's done inside Hillcrest code on the bno chip on the HDK. That's what they get the big bucks for :D
When the unified tracker is ready to go, we can add a yaw drift term when filtering in the absolute orientation values. The current "fusion" plugin just replaces the camera tracking orientation with the IMU one after aligning them at startup.
On Sat, Feb 27, 2016, 7:37 AM Russell Taylor [email protected] wrote:
You can check out the IMU class in VRPN for a way to auto-calibrate the magnetometer while the server is running. It has the deficit that it rotates north a lot while the user is first moving around but the benefit that it does not need parameters. A better solution would probably have at least a cached initial guess for the calibrations that could be optimized during running.
— Reply to this email directly or view it on GitHub https://github.com/OSVR/OSVR-Core/issues/374#issuecomment-189641245.
Ryan A. Pavlik, Ph.D. Senior Software Engineer Sensics, Inc. www.sensics.com
Any news about this? I do also experience immense drift in the HDK2 (e.g. within in two hours the the yaw-rotation is off by approximatly 90 degrees). I am currently not using the camera for postional tracking. Would the camera improve the yaw drift with the current or with an upcoming OSVR version?
See my comment history on Reddit, I've basically written out (with the help of some additional ideas from others) several different ways to do this with the code - so it should be accessible to many coders at this point.
Sensics does not have the resources or funded contracts to dedicate further engineering time to this at this time.