OpenVR-MotionCompensation

I'm using V1 lighthouse tracking. I've just ordered some V2 lighthouses. Not sure that will make any difference, but who knows. It seems it doesn't happen to everyone with SteamVR lighthouse tracking. Maybe it's the way the playspace is setup.
I'll look at building the code and see if there's anything I can contribute.

Im referring specifically to the virtual tracker (flypt) problem that afaik does affect everyone with lighthouses 1.0 or 2.0.

Would be awesome to have some progress. I and probably others would contribute!
I've resorted to optical tracking with 4 base stations (in the mail) for now. Would love to use virtual tracker as I've tasted a few playable seconds with that before the origin goes nuts and its much smoother than optical (despite filters).

4 base stations! I've only ordered 3.. The 3rd I hope to dedicate to a V3 tracker. I don't like the way my V1 tracker seems all jittery and sensitive to vibrations. Sounds like the virtual tracker is the way to go. Now you've got me motivated.

Yeah I completely agree! Virtual tracker is really the right way.

I think a lot of people have small enough motion on their rigs that they dont mind optical. For me I've got 30 degrees of pitch and roll and continuous yaw - lots of motion. The yaw is the reason for the 4 base stations.

Let us know if we can help other than cheer you on!

I'm still not quite happy with motion cancellation. Has anyone with a WMR headset (i.e. HP Reverb G2) played around with the OpenVR-MotionCompensation settings and can provide advice? I tried following the YouTube video linked on the official OVR-MC website, but lowering the DEMA samples actually caused the image to swim around more when static, and raising it above the default value seems to induce a disjointed feeling (but this could be as a result of too much testing).

Any more insight regarding the settings would be really helpful. My mounting solution is solid, and uses plenty of vibration absorption, so I think my issues are settings related. Thanks!

To test go with lpf 1 and Dema 2. This will disabled both filters. Do some small and slow sinus movements and check if this works smooth. The filters purely have the task to reduce shaking and vibrations that your controller receives through your rig. They do not help with tracking issues.
Tracking issues might be introduced by monitors that are mounted to your rig, or a wall without much contrast or your HMD losing sight to the reference tracker.

Agreed, it's almost certainly to do with light. Either from monitors on rig (even if off can cause tracking issues), not enough room lighting, or playing in a space with very little furniture or things like pictures on the walls.

I'm using G2 and SRS, no issues at all.

Another thing to check is of you're using USB extension cables, make sure they are USB 2.0 (connector has white plastic instead of blue), or try different extension cable.
If your motherboard has any USB 2.0 connectors, try using those for the sensor.

Thank you so much for the quick response. Just two follow-up questions: Are you suggesting LPF filter set to 1.0000, or LPF set to .1000? I am guessing it's the former (1.0000), but I just want to make sure. Also, would a white wall count as contrast when my controller is black? If not, how would you suggest that I add contrast to my wall (see photo below)? Thanks again for your help!

I hope you can pardon my ignorance, but how does USB come into play? I am using one of the standard HP Reverb G2 controllers as my tracker, which is mounted to my rig. Should I be using something else?

I am not sure how I can improve my room setup further, but here is a photo for reference (the monitor swings so that screen is against wall when driving). Tracker is mounted to the left of the left fan/blower above my wheel. Thank you so much for your help!

My bad.
I didn't read you were using the G2 controller.
As far as I know this is never going to work well. Many have tested mounting it, but it's not a good option for MC. The G2 WMR controllers are absolute trash.
I'm sure your can search all about it.

I'm using a WIT motion sensor in SRS which incorporates OVRMC and creates flawless motion compensation.

This is almost as worst as it gets.
Imagine you are a camera and are told to look at a high contrast point. The only contrast you will find is the edge between your black rig and your white wall. And now this point moves, but your sense of balance tells you, you are moving into a different direction. Result: you get dizzy.
That's what happens to your HMD. Put something at the wall in front of you and to your sides. Some pictures, a few colorful squares etc

Thank you for the response. I had a feeling the G2 controller was not ideal. Can you elaborate on the WIT motion sensor setup you use? Do you create a virtual tracker within OVRMC or something? Can such a sensor be used with Sim Tools? Thanks again for your time!

@Dschadu would be the best to answer if this can be used with Sim Tools.
I only use SRS as it does everything I need in an easy to use app. I initially used SimTools, but it was just too complicated and I found the motion response with the SRS app just better overall. I spend more time racing than fiddling with settings.
The WIT sensor is used as a virtual tracker, this was a collaboration between SRS and @Dschadu

@Chipless Check my page: https://ovrmc.dschadu.de/en/virtualtracker
At the moment SimTools does not provide the necessary data for a virtual tracker. You have to use SRS or Mover if you want to use a virtual tracker

@Dschadu, been working on the wit sensor, to add it to Mover.
Is srs sending position or just rotations?
I can't get anything worth out of the sensor for linear position.
We get accelerations, but to convert it to position we need to integrate the values and the accumulated error is huge.
Also using the magnetic sensor is out of question specially near the motors.
If srs can get position from this, I might be missing something. For a 3 dof rig with limited heave, it's enough, but for other rigs...
I'm lacking imagination to work around this.

I'm not sure how they implemented the sensor. I think they integrate the acceleration values to get a bit of a better understanding of where the sim is. If I would have to do it, I would use sensor fusion to use the sensor data to correct the assumption my software does. I don't think they use the sensor on its own to determine the simulator position, as the position will start to drift after a short time.

And their tracker sends position and rotation, yes.

It drifts, and exponentially.
I'm thinking of adding the possibility to mix data from Mover and from the sensor in the %% desired by the user.
But linear position is near impossible.

The only problem with Flypt Mover motion compensation are the discrepancies between the commanded pose and the actual motor movement. We don't know how fast the pose is moving to the commanded pose, we don't know the free play, and we don't know when the motor stalls due to overload.

But what your software does know is in what direction the motor is pushing the rig. So I don't think a mix from mover and a sensor needs to know the exact rig pose, it just needs to know what the motor is doing. So a sensor that gives motor feedback, like an angle sensor can be all that is needed. You just need to know where on which actuator it is, and you can calculate the current real life pose.

I have started on such a thing, but it is very simple as my dofreality 2dof has just one joint where I can simply measure two angles and I know the pose directly (I am just having problems programming the plugin, my arduino is putting out angles over the com port succesfully already).

With more complicated math, but that is what mover does, 6 angles or 6 lengths could determine the pose of a hexapod without resorting to a sensor that needs to keep track of its complete pose.

Edit (much later):
To make things standardized, you could define for each kind of rig which angles you want, and specify a format you are expecting over a com port, and everybody can do as I did.... Think of some mechanism to measure an angle and use an arduino to process it, format it, and send it over a com port.

So the end user has to solve how to measure the angles. I already made something for dofreality 2-axis, which also has logic for dofreality 3-axis, just not the hardware. My hardware is a 3d printed geared cardanic cage around the joint with two high quality wire pots and an arduino.

A hexapod user could measure angles against horizontal with a rack and pinion that attaches half way up the actuator and to the ground. The arduino would do a little trigonometry to convert that into an angle for the actuator. With the geometric information for the rig, Mover then calculates the pose.

Hi , Yesterday I lost my icon set up on my bar of Steam VR . I was’nt enable to change anything !! Steam VR has change something… ? like update ( Helper) and after accepte this change , everything was ok !!!
Q - I was Alone With this little problem?

Well, after attempting to transition to SRS, and setting up WIT sensor/virtual tracker, I am going back to SimTools for one simple reason: SRS will not allow me to use any part of my DIY wind sim setup. I basically would have to scrap the entire wind sim I currently have, and go with their own setup. Total deal breaker for me.

Is there hope of SimTools getting an update to allow for Virtual Tracking capabilities with OVRMC? Just curious.

As @Dschadu suggested, I hung some photos on my walls, and will try to dial in MC using the G2 controller as the reference point. I can't thank him, and all of you enough for the help with this MC stuff. It's quite the rabbit hole, but much less overwhelming thanks to the community here.

So, after determining that I can have SimTools and SRS run simultaneously, I am finishing up the setup of SRS and Motion Compensation (MC) with it. However, I am running into an issue that I can't find a solution for:

After setting up the virtual tracker per the SRS MC setup guide (with the WIT Motion Sensor), each axis tracks appropriately and motion is compensated in the correct directions for each movement, but the magnitude of pitch and roll is inaccurate.

Visually, when I am testing the virtual tracker using SRS's "joystick" mode, the green Y-axis line is centered vertically in front of my face about 6 virtual inches away, but when I roll to the maximum either direction, the green line moves slightly off-center and further to the side I rolled the rig to. The same happens with pitch: When I pitch the rig forward, the green Y-axis line does not stay 6 virtual inches away from my face, but instead moves further away from my face, and vice versa when I pitch the rig backwards; the line moves closer to my face.

This manifests itself while driving a racing sim too. When I am driving uphill, and the rig pitches rearward, the steering wheel gets closer to my face, and when I drive downhill, the steering wheel pulls away.

Any suggestions? I've tried positioning the intersection of the virtual axis in different places and fiddled with various settings in SRS, but the problem persists.