VR Motion Cancellation - Time to test!

wow cool , im gonna have to give it a go tonight. hopefully i can set it up the right way.

Hi @JMB3D - I tried my Vive Wand on my rig with zip ties just to test out how motion compensation worked. I turned on SteamVR, set the wand as the motion Compensation tracker, and it started working but I went on iRacing and onto Laguna Seca for example and the car was severly dipping up/down because of the steep hill there and it wasn't possible to drive with it moving so much.

Have you seen something similar to this also?

Also, is it still impossible to use 2 knuckles controllers with 1 Vive Wand as a tracker?

i dont know? i have the rift, CV1 i am getting the Rift S and wondering how im going to use the controller with the rift s on the same controller. im going to have to do some experimenting for sure.

Im not even sure if it works with Rift S because of the inside out tracking now. Not sure how that works to be honest but i found out only 1 tracker can be used and you have the other left to use. In your case i dont know if you can connect a 2nd controller either

I agree that software is the best and most scaleable approach for all the different custom systems we use.

The developers of both Hexpod (@hexpod) and FlyPT Mover (@pmvcda) have said that it is possible to supply that position and angle data from their software. I believe the latter might be including it as part of his newest software update soon.
The developer of OpenVR input emulator has also said he will provision for an input position feed/stream but we have not heard from him for a while so someone else may have to write that code.

Yes, I need to know how to send that data.
What is the preferred way.
For me it's easy to send it through UDP or memory mapped file. Maybe the later would be the best solution.
And what format?
Easy and fast for me would be to send yaw, roll, pitch, sway, surge and heave (translations in the rotation direction).
Floats or doubles? Radians or degrees?

I'm working on forward kinematics, but I could already send the calculated values.
If there are no filters in the actuators and they don't reach limits, data is valid. Forward kinematics are needed if we are in one of those situations.

Motion compensation software has IPC with well (if not complete) defined protocol. You can currently create a virtual device and feed pose data into it from forward kinematics solver. A fork of this software currently goes through the process of pruning much of the features unrelated to motion compensation and it will likely NOT keep the virtual device functionality. It will however expose some sort of IPC protocol for forward kinematics input that operates much in the same way.

I have suggested usingUDP, however the software itself already uses the same IPC for communicating with SteamVR, so that would be a second IPC protocol to support. This idea is between being on hold and completely dismissed.

Regarding motor feedback, is it possible to read this data back in SimTools software (assuming the hardware supports this)? Using middleware is an option but it's far from optimal.

I am not an expert on mechanics (even when it comes to racing cube) but I think the problem on some motion simulators with software calculated motion cancellation is "slipping" parts. Racing cube platform rotates on rubber wheels and there is possibility that they will slip on surface and software can´t calculate that if I understand anything on mechanics and softwares.

I have theory why I had problems earlier and they stopped when I used JMD´s over the Simulator base station placement. My room is not that high and even I had both base stations on roof on opposite corners the angle of laser was too similar and Index missunderstood which laser was which on some points. Now the other laser is close to 90 degree compared to another on corner and lasers make more like cubic grid so index has much clearer image which laser is from where and calculations are easier. Just tought I share this idea if someone wants to test if this really matters

I know you can't do a bunch of extra work just for me, but I need that functionality for my sim to allow me to see where my hands are using Vive Trackers and "display model" feature as well as the controller offset settings of OVRIE. If those features go away I'll be back to square one on VR hand visibility. =( Maybe someone else will maintain that side of the project, I know there are other things that depend on OVRIE besides just us.

Still I'm glad to hear that we have someone working on this project.

I was just thinking about the bass shaker/transducer issue. How difficult would it be to add TrackIR as a device Steam recognizes as a controller? If we could have a TrackIR "track clip" act like a Vive Tracker, we could then use purely optical tracking data for the motion cancellation and not have to deal with IMU's getting confused by the transducers.

I did suddenly realize though, that the SteamVR loss of tracking was positional... which isn't from the IMU. I don't understand why the positional (which is all optical AFAIK) tracking gets confused.

I don't own a Vive so I wouldn't know exactly. But my best guess is that it's because its tracking is sweeping laser timing based, it knows when the laser hit every particular sensor but nothing beyond that. Smooth motion can be accounted for but vibrations is a different story, and because of that the timing data that it receives looks like noise, and that translates to garbled positional data. I suppose camera-based optical tracking would fare better because it tracks actual positions and the worst that vibrations could do is create motion blur on the sensor, which it's designed to work through to begin with. I don't own TrackIR so I wouldn't know this either. My headset is Windows Mixed Reality and it's not exactly well equipped for tracker-based motion cancellation, and to top it off the controller tracking isn't very good. My current idea is to chiefly rely on forward kinematics motion cancellation, and only use physical trackers on parts of the rig that may drift - the parts that don't experience strong vibrations by definition.

Regarding offsetting the controllers, it should be possible to do using the same mechanism as for the HMD, so virtual devices aren't needed for that.

Great post!

Regarding the InputEmulator thing, I don't just need to offset, I also need to attach a render model to the trackers that persists throughout all games and does not interact with the games. Currently I can do this easily with OVRIE. Only problem is I've yet to obtain a render model of hands or gloves that is acceptable to the Steam overlay so I'm stuck with render models of controllers.

Has anyone come across a problem with motion comensation using Advanced settings where the visual update for space drag is very slow?
Its refreshing the image maybe 2-3 times a second both in Steam Home and in game (only played with LFS so far)
All the other graphics of Steam Home or in game are ticking over just fine, its just the space drag is updating slowly.
For reference, Im using Pimax 5k+ and HTC vive wands with a single base station.
Anyone come across this before?

You said advanced settings, do you mean you are attempting to use the filter modes? If so, they were and unsuccessful experiment aimed at solving the bass shaker problem, you have to leave that stuff at the default for it to work properly.

I didnt realise that was an available option. I thought I was running it as default. Maybe I switched it on somehow without realising.
I'll look into it more. Thanks

edit:
Just reading the documentation on Github,
Maybe it was comfort mode that was limiting the updates.
I'll check that out tomorrow night.

So that was my problem. The comfort mode slider needs to be turned off.

So Ive played around with motion compensation using Open VR Advanced Settings,

Is it correct to say the best we have available to us right now is compensation in the linear axis 3dof only?
ie surge sway and heave, but not roll,pitch and yaw?

The Space Drag works for surge sway and heave
There is Sace Turn that allows for yaw but at the moment I cant get both space drag and space turn at the same time.

Is anyone able to get motion compensation for the full 6dof with any other methods?

Hi guys, Can confirm the InputEmulator is up and working.
When mounting the tracker, it's best to mount it as firmly as possible to the rig chassis (and isolate as much mid-high frequency vibration as possible from affecting the tracker... in the Vive at least, high vibrations affect tracker stability)

Forgot to mention, I also had to coil the headset cable around 4 huge ferrite RF chokes in order to stop the electromagnetic interference from the motor wires from blacking out the headset!

Here's a video of it in action:

JAD are you using Oculus? Currently my sim is apart, but as far as I know right from the start this fix only worked halfway with Oculus, something like you describe.

With native SteamVR headsets (Vive, Vive Pro, Index) we get motion compensation on all six DOF. The Oculus compositor gets in the way and causes problems, thanks to their closed ecosystem =/ there's likely no way to fix it.