OPEN VR CODER NEEDED !! PLEASE HELP !!

I asked this question a year or two ago and don't think I ever really got much of an answer. From what I saw it looked like it was mostly small throw sims with VR and no compensation, or large throw sims with monitors.

I hear you and I think we could use OVRIE as it already have the solution. Just make a new selection to use it with WMR or any other tracking technique.
This should lower the development costs and make OVRIE the "only" software source to use in VR motion compensation. Easier to fix 1 software than many if STEAMVR goes update frantic.
I invested 3000$ in my gear and I could chip in at least 200$ to get it working.

WMR and any 100% on-board tracking system presents a different problem though. The issue is that if you mount the controller behind the head where it mostly needs to be then the HMD cameras can't see it. That requires more work and/or creativity.

We will never get correct tracking if WMR controller is used ie inside-out-tracking.
Only way is to use another external tracking system ie vive.

1. The WMR tracking compensation is working 50% with Vive tracking compensation in OVRIE (Wrong motion on tracker and axle positions when selected as compensator unit).
This is a good start. This need to be tweaked to work with ie VIVE Tracker.

2. The next step is to fix how to track motion compensation using inside-out-tracker ie Reverb. This will be more intense problem solving. Still need external tracking.

Quick fix (not ideal)
Feedback appreciated

1. Setup the Reverb (wmr) controller as picture below.
2. Select the controller as the motion compensator unit in OVRIE.

It works as long as the controller is active.
It works ok looking around during dogfighting in DCS, but some distortion is felt.
Using 2 controllers (1 not motion compensated) tend to keep the controller alive longer.

Solution: we somehow keep the controller active it's a working setup for now.

Problem is long cruise segments.
Turning, pitching and rolls keep the controller alive and just lightly move the controller by hand wake it up quickly.

Issues I see.
1. Battery is drained quickly. (No charge cable)
2. Controller fall asleep during low continuous motion from the rig.

Did you try it out?
This could be integrated in OVRIE...
Is OVRIE development totally closed?

There is still also the issue of pitch motion. When the sim pitches forward driver head goes up, but controller goes down because of the center of rotation.

Perhaps this could be solved by inverting the heave value sent to OVRIE on 2DOF or some 3DOF but that would not work on a sim that has a heave axis.

Has anyone else attempted putting an enclosure on the sim for WMR tracking? My experiment was not "real-world" but it indicated that the WMR positional tracking would not function at all in a very small enclosed space.

Unfortunately that is absolutly correct. Indeed I've stumbled on that problem in a practical test, not in theoretic thinking.

What really disturbs me is the fact, that I had the feeling to be very close to a ─ or rather MY ─ solution (having a complete valve ecosystem v1 with two added trackers). The tracker mounted right behind my seat's headrest, the base stations placed so that both cover the tracker and the HMD, OVRIE works most of the time quite adequate. The problem is, with my WMR HMD (Reverb) I cannot match the coordinates of both systems. SPACE CALIBRATOR should solve that, but I never got it to work.
But reasoning about all that I suddenly came to a proposal, which ─ at least as far as I know ─ is not only new, but also looks feasible, open and not too complicated. However it needs a couple of base stations and a couple of trackers (or wands).

With tracker «A» in fixed position behind your head and tracker «B» attached to your headset (whatever brand that is) the «software» (e.g. adapted OVRIE) would calculate the DIFFERENCE of tracker A's and B's coordinates to correct the HMD's coordinates.
To reset the two trackers to their RELATIVE zero position you'd assign the same button you use in the sim to reset your head's position.

I think the big PRO of this proposal is that it is based on established and proven hardware, well integrated into SteamVR. OVRIE is also working within that system. My guess is it would cover about 2/3 of the programming logic. It needs to be augmented to cover TWO input devices and a slightly adapted calculation procedure, but the rest can stay unchanged.

What do you think about it?

Right, that's the exact same thing ORVRIE does now. It measures the HMD tracking data and the controller tracking data and uses the difference.

So the only thing you are changing is to add a SteamVR tracking device to a non SteamVR headset which should be a small and simple modification to the code I would think. If we find a coder he should be able to do that simply enough. You basically aren't changing anything except pointing it at a different device.

That will work for anyone who owns the SteamVR tracking equipment. There is the problem of course that most folks don't have that gear if they are using a WMR HMD and it's not cheap.

Unfortunately the releases of Vive Pro and Index as standalone HMD's pretty much ensured that there won't be a surplus of Lighthouses available cheap any time soon. There should be some Vive Wands floating around though, as a result of the Knuckles. If it wasn't for motion compensation and general tinkering I'd be happy to see mine go away. I really hate those controllers!

On the topic of finding a coder, can anyone tell me what language or whatever our savior needs to know to update OVRIE?

At a glance, the code in github is Windows C++.

My P3 DOF Reality rig is rotation centered on my seat so no big issue with that setup.
Only problem is extensive view away from the tracker may be give distortion and the controller goes to sleep quite quick.
Maybe the controller "Identify" action in OVRIE could be repeated say every 5 sec for 0.1 sec to keep it alive?

Correct. I have made a first tentative version of a "job description" in a simple text file (attached), so anyone is invited to download and re-upload it with corrections and addenda.
I'm not sure whether I understand OVRIE's current motion cancellation functionality correctly nor whether I described the desired change/expansion in the right way. In some moments of writing I thought I had made it up way too complicated.
Please help in the endeavor by improving the job description, and also with finding a C++ programmer. When we've found one, we'll get the money together!

I'll have a go at it a little later today. =)

If I had a reliable software that did high quality motion cancellation/compensation, I would gladly pay upwards of a few hundred dollars. I wish someone would step up to the plate to get this done.

That quote implies that there is a good chance my solution of disabling the IMU and using only optical Lighthouse tracking may be viable. Some may argue, but I suspect there is a good chance that the added latency he mentions will be sufficiently small to make this application work.

The reason I'm proposing attempting this (as an on/off option) is I think it likely to solve the bass shaker/transducer problem.



As for the rest, I think that assuming SteamVR will be maintained is reasonable. There's no guarantee of anything in this world, but I think that if there's one thing that will be "stable" in the VR market for years to come it is SteamVR due to it's open source model and the relative stability of the Steam ecosystem and of Valve itself. Oculus is of course likely to have equal or greater stability for the same reasons, but that's not really useful to us.

I'm getting out of my depth here, but I also think that if our solution is SteamVR based than it's likely that most future hardware that is SteamVR compatible (which I think will continue to be most mainstream devices) should be able to work with the plugin so long as it's recognized by SteamVR as a "tracked device". Some devices will be impractical to use for various reasons of course, such as the WMR controllers, but that's not something we can control.

If we consider lighthouse and vive trackers/wands/knuckles the primary hardware we are supporting there is likely to be an abundant supply for years to come since so many of these systems were sold. Every old used Vive system, every Vive Pro setup, and every Index setup available on ebay would give a motion sim user what they need in terms of hardware. Even Pimax has committed to Lighthouse for their current gen hardware. Benefits of Valve making it open-source!

No matter how this is done there's the chance of our solution becoming obsolete and needing to be re-done from scratch. No matter what we do at this point it's going to become obsolete sooner or later but I think that using SteamVR decreases rather than increases the likelihood of that happening any time soon.

I highly doubt that any of the rigs here can do 3600 deg/s! That would mean 10 full rotations per second. I think it will be more like 50 deg/s