Alan Yates on the Impossible Task of Making Valve's VR Work - YouTube

[Lorne Covington]

Don't think I've seen this posted here yet:

https://www.youtube.com/watch?v=75ZytcYANTA

Good talk about the nitty-gritty of lighthouse, and how a good idea is
5% of the job; the rest is making it work, and work reliably.

Cheers!

- Lorne

--

http://noirflux.com

[TobyCWood]

Fascinating.
...
There may be an easier, more effective way that was done back in the 70s...
yes I am revealing that I am not a millennial and older then a Gen X er..
. and it's probably not classified any longer... for sure not the general approach which was published... a very long time ago,
Anybody here ever hear of PLRS.... a preGPS position reporting system? It used a very early form of time delay multiple access. All you need is a VERY accurate clock. We used an atomic clock at the base station... but that was a long time ago... given what Yates says about only needing the optical Calc for time for error correction for inertial sensors and it could probably work, chances are BT is fast enough and the concept of the BT network fits the bill with every node talking to every node. For sure the data set would be nowhere near as large as the original battlefield system used. You could have quite a bit more tracked objects...no need for any lighthouses and it would overcome light occlusion issues (which I experience now and then playing with my Vive). The only thing about it that may make it hard to do is the distance between objects which in VR is minuscule compared to the original concept. As such the time differences will be extremely small.
No need for any little sensors.

[TobyCWood]

Doh! I forgot to mention... no tether to a PC at all. No cables.

[TobyCWood]

Uhhh... data cables that is.

[Jan Ciger]

Actually that is what Alan has mentioned in the video at the end. If you
have a very accurate and well synchronized clock, you can measure
time/phase differences and you get distance from the transmitter, in
addition to the elevation/azimuth angles. But you are working with the
speed of light, so this would require extremely accurate clock on both
sides to make it work on the small distances used in VR and with usable
resolution.

That is the same idea the aviation DME distance measuring system uses.
But there you don't need neither low latency nor sub-mm accuracy, the
distances are typically in tens of miles and resolution about 0.1
nautical mile. Your PLRS is, afaik, enhanced version of the civilian DME
system. It has published error 300-400ft - good enough to navigate
bombers on target, but several orders of magnitude to big for VR use.

I can't imagine having an atomic clock in a consumer product that this
would require, the cost would be astronomical. Also the technical
complexity of measuring the picosecond-range time intervals, yikes!

Light or radio signal traverses the 5m VR working distance that Alan
mentioned in his presentation in < 2ns! With typical distances PLRS or
DME operate at the times are in more sensible tens of microseconds ranges.

Otherwise if you have two perfectly stable and in sync oscillators (very
difficult problem!), you could measure the phase difference between your
local signal and signal coming from the remote transmitter - the phase
difference would be proportional to distance. That is less complicated
than measuring the tiny time intervals and can be done using some analog
electronics but it is still an extremely complex problem (btw, this is
how time of flight cameras work - they measure phase difference between
the emitted and received reflected light signal).

I am afraid that this idea is not very practical for this use case. I
could imagine this being done using ultrasound instead of light/radio,
then the timing issues are much more manageable. However ultrasound has
its own share of issues, such as interference, all emitters are very
directional so you would need an array of matched emitters, occlusions, etc.

Regards,

J.