Unified tracker: unmodeled/uncompensated IMU yaw drift causing stutter.

[rpavlik]

Noted primarily in racing games and flight sims (whether using RV or GRV, though naturally GRV should be worse) - as IMU reports drift in yaw (as they naturally must due to integration and lack of an external, totally stable yaw reference), this causes the "forward" direction according to the camera and the IMU to diverge (the room calibration step on startup exists primarily to align them). This produces a shuddering sensation, presumably as the camera tries tugging the pose back to what it thinks is forward (correct) but the IMU is reporting a drifted yaw. (Naturally, this latter effect only appears using the new, improved "unified" plugin that feeds IMU reports into the same filter state used by the video tracker: the old "fusion" just replaced the video-derived orientation with IMU orientation, resulting in drifting yaw in overall reports but without the tugging/shuddering)

Representative Reddit threads: https://www.reddit.com/r/OSVR/comments/5wipcl/dcs_world_in_vr_a10c_cas_with_osvr_hdk2_revisited/deacljs (warning: extensive long posts by yours truly within)

Test case suggested per /u/Doublep87:

in Project cars/assetto corsa i use the Nordschleife as a test, i can put in a fast lap with a relatively slow car (8 -9 minutes), the second lap i can feel something is wrong, and by the third lap i start noticing that i am driving looking to the right, making me feel dizzy shortly afterwards.

Two basic approaches considered so far:

• During IMU measurement filtration, augment the state with an additional value, a "yaw correction" value, akin to how video measurements augment the state with beacon positions to do autocalibration. (For the rewind/replay of history problem: Would have to store the previous timestamp and yaw correction with each IMU measurement for easiest rewind/replay of history. There's a fair bit of literature about doing this general approch, and I think I've got a few things designed in because I had assumed this was the only way to do it. I expounded on this concept here: https://www.reddit.com/r/OSVR/comments/5wipcl/dcs_world_in_vr_a10c_cas_with_osvr_hdk2_revisited/deq7t2o/
• Alternate approach, credit goes to /u/Doublep87 for suggesting it: essentially as an independent process in the IMU object, filter IMU yaw vs overall yaw over some period of time and update an internal correction value (basically a multi-mode filter - somebody else on the thread brought up "complementary filter" - or basically high pass and low pass) - wouldn't be totally 100% physical due to history replay, but would avoid touching the IMU measurement model and would thus be easier to implement - and would also reduce the need to well-characterize the IMU drift process model. https://www.reddit.com/r/OSVR/comments/5wipcl/dcs_world_in_vr_a10c_cas_with_osvr_hdk2_revisited/deqd1a0/