HadesVR Versions Save

The "DIY" SteamVR compatible VR setup made for tinkerers.

1.5

9 months ago

Been a while, huh? This update adds:

  • Image mirroring (just in case you need that for some odd reason)
  • The ability to rotate the individual display views
  • Some jank UV-Based offset for people who don't feel like having their lenses be horizontally aligned with their display.
  • A fix for OpenXR Unity games where the HMD view would not move because a few of the properties weren't set right.
  • Headless mode, because why not, it lets you boot up steamvr with no arduino connected something else I'm probably missing Known bugs:
  • The little HMD icon in the steamvr window is broken because I messed with the props, whoops. I'll fix that later:tm:
  • The driver version in the console says "BETA_1.41_6", it isn't, I just forgot to change it.

1.40

1 year ago

Changes:

  • Anranarl has redone the viewport and FOV implementation, now it's handled according to the Valve documents. This means the FOV number is actually the FOV you get unlike before where it had a lot more guesswork.
  • Postlund has done a clean UART implementation so non-hid compatible arduinos are supported once again by using UART as a transport instead of HID.
  • I've developed a new Arduino library to use with HadesVR, it's called FastIMU and from now on I'll be using it as it allows to use many different IMU types without having to make major changes to firmware code.
  • Added experimental optical drift correction, it's still a bit spotty and I don't recommend using it just yet. once this is working properly it will allow the use of cheaper, 6dof IMU's without a magnetometer.
  • Controller grip strength is now an analog value that can be sent from the controllers to the driver.

Bugfixes:

  • position is no longer jittery when not connected to psmoveservice.

Note: This driver requires you to update headset and controller firmware due to changes in the controller data packets.

1.36

1 year ago

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:

  • EDID descriptor settings in the .vrsettings file, these are for direct mode which is not yet properly working, more testing to be done.

Bugfixes:

  • Fixed viewport zoom not being calculated properly (Thanks again, Anranarl!).

1.35

1 year ago

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!).

1.34

1 year ago

whew couple things:

  • Updated OpenVR SDK to v1.14.15
  • If 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.
  • Velocity calculations were redone to account for UseAccelerometers, if enabled, the accelerometer readings from IMU's will be taken into account when calculating controller velocity.
  • Display angle canting is now an option though it's experimental and buggy. while the "eyes" get canted properly, steamvr's render plane is still the default one, making things outside of the view of the left eye to not render properly. this will get fixed eventually but it's not a priority at the moment. the setting to change display cant angle is DisplayCantAngle under the Display section
  • The Kalman filter parameters have been split up, there's now Measurement error, Estimation error and Process noise settings for both Camera tracking and IMU tracking, in case UseAccelerometers is enabled

1.33

1 year ago

New stuff:

  • Color 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.

Changes:

PSMoveService polling rate is now twice of PSMSTrackerFrequency, meaning if you're tracking at 60hz, the server will be polled 120 times a second.

1.32

2 years ago

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.

1.31

2 years ago

Hadesvr: now with less jitter!

  • New config entries added: 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).

1.3

2 years ago

HadesVR: now with 100% more filters

  • Added Madgwick filter for the HMD, you can tune in the beta value in the config file if you want to though the default of 0.05 works pretty well for me. I also left the old DMP based code back if you don't like proper filtering for some reason.

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!!

1.23

2 years ago

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.