The "DIY" SteamVR compatible VR setup made for tinkerers.
Been a while, huh? This update adds:
Note: This driver requires you to update headset and controller firmware due to changes in the controller data packets.
I wanted to have this update dedicated to magless drift correction, so mpu6050's and other 6dof IMU's could be used, but instead I decided to work on fixing some tracking things.
Changes:
Velocity is calculated differently now, before it's calculation was based on unfiltered camera position and some IMU tracking in between camera frames. This was changed to use the last Fliter position at a new camera frame. This makes tracking feel less jittery, and makes it so even 30fps cameras are usable for vr tracking (though with an added latency penalty, of course).
HMD Madgwick filter beta is now dynamic and dependant on rate of rotation of the headset. meaning, if your headset is still, the filter beta is very small, producing less rotation jitter. On the contrary, when rotation rate is high (turning your head quickly, etc) the filter beta goes up slightly to correct for any possible tracking error.
Minor Data handler stuff, pose rotation checking, pose angular velocity, etc.
New stuff:
Bugfixes:
This update fixes a bug with the Kalman filter, where I used different filter gain variables for IMU and Camera tracking, resulting in inconsistent tracking latency. This has been fixed, now the IMU + Camera fusion works correctly, the IMU accelerometers doing most of the job for the controllers to keep latency low.
However this introduced a new issue which made the HMD feel jittery when using the same filter values as the controller values. For this reason I decided to separate the configuration values of the kalman filter in HMD and Controllers, the HMD has a (while technically less accurate) smoother movement. This can be seen in the filter settings.
I've also done a bit of tuning of the filter, adjusted the FOV degrees since it was configured for a bit too high of an FOV before which resulted in spatial distortions (hands not matching where they are irl and in vr, for example)
The other change is regarding the viewport zoom, the settings for width and height have been removed in favor of a single general zoom one. This makes sure the image doesn't get stretched, preventing image distortion (Thanks Anranarl#9231 on discord!).
whew couple things:
UseAccelerometers
is enabled, position from cameras and accelerometer data from both controllers and headset IMU's will be fused to smooth out position. This requires accelerometer bias calibration to work correctly. it is enabled by default.UseAccelerometers
, if enabled, the accelerometer readings from IMU's will be taken into account when calculating controller velocity.DisplayCantAngle
under the Display
sectionUseAccelerometers
is enabledColor aberration correction: Now each color channel gets it's own distortion coefficients, if you don't know what to do with these just leave them be or set all channels of them to the same K1, K2, K3 distortion coefficients.
Removed janky filter in favor of a Kalman filter: There's three parameters that control the Kalman filter that runs both the HMD and Controllers, this might change in the future or it might not.
PSMoveService polling rate is now twice of PSMSTrackerFrequency
, meaning if you're tracking at 60hz, the server will be polled 120 times a second.
Added the ability to offset the position of the tracking blob for controllers and hmd (because the tracking blob isn't the center of the controller). This is done through some new settings entries:
All setting values are in meters. by default the HMD should probably have a 7cm down offset (because the tracking ball goes on top of the headset, that would make it so the headset in vr is closer to where it is irl).
Settings added:
HMDXOffset
Left and right position offset for HMD.
HMDYOffset
Forwards and backwards position offset for HMD.
HMDZOffset
Up and down position offset for HMD.
CTRLRightXOffset
Left and right position offset for the right controller.
CTRLRightYOffset
Forwards and backwards position offset for the right controller.
CTRLRightZOffset
Up and down position offset for the right controller.
CTRLLeftXOffset
Left and right position offset for the left controller.
CTRLLeftYOffset
Forwards and backwards position offset for the left controller.
CTRLLeftZOffset
Up and down position offset for the left controller.
Bugfixes: fixed a bug where yaw offset for the controllers was wrong, not like it mattered much since it gets calibrated away
Other changes: I made some icons for the HMD so it doesn't use the default H icon in steamvr anymore. Turned the default jitter smoothing values up (less smoothing), the change isn't noticeable jitter wise and should make for more responsive position tracking.
Hadesvr: now with less jitter!
ControllerSmoothingK
HMDSmoothingK
These control the jitter rejection for both HMD and controllers by rejecting tiny movements. Higher values mean less jitter rejection but faster(er) response and low values mean more jitter rejection but a more laggy feeling movement.
I believe the default values are the best balance between the two, avoiding jitter at very small movements while feeling snappy at fast, beatsaber like ones.
if you want to see how the curve works plug "f\left(x\right)=\left(1-e^{-kx}\right)" into Desmos, X being the movement difference from last update (in meters) and y being the amount of movement that isn't ignored (multiply * 100 for %).
code is also a bit more readable (looking at you, dataHandler.cpp) by using quaternion and vector libraries. to do some stuff
I disabled the alwaysActivate thing in the driver. (thanks okawo for reminding me that it exists).
HadesVR: now with 100% more filters
I might consider doing this for the controllers aswell but don't count on it, they work pretty well as they are right now and besides, I'd need to change the way I send data to the hmd since I can only do 32 byte packets at a time with the nrf24s.
Firmware updates for the basic hmd to support this new mode are coming but the old DMP based code will still work. you can use a packet ID of 1 to send quaternion data or a packet ID of 3 to send raw (but scaled and biased) sensor data and let the driver do the math.
Don't forget to save your config before updating!!
The HadesVR driver, now with more efficient use of the bytes it works with.
Added support for the controllers to send over acceleration values, which will (at some point which is not yet) be used to smooth out controller position by interpolating them between tracking frames.
The rotation quaternions of controllers aren't made out of 4 floats anymore because those use a total of 16 bytes and that is too much for me to also send accel data, also unnecesary since those last digits were basically noise anyways. They are now made out of 4 signed 16 bit integers that get divided by 32k to form the output quaternion with a resolution of something like 0.0003 or something stupid like that.