Oculus Rift tracking and Motion Simulation

>You can likely expect a full 180 dome coverage in the early release consumer version of the Rift and two of those cameras would give a full 360 coverage
New prototype Crescent Bay already have full 360 tracking: the problem is resolved the same way as Sony Morpheus did it - by adding tracking LEDs at the back. This addition makes it into first release version CV1.

>The Rift camera on the rig is unlikely to be the best option and even less so as the tracking technology of the Rift is expanded.
I don't exactly understand what's the logic behind this. To me, on contrary, using camera opens possibility to more reliably track rig-relative head motion if you attach it to the rig. I've heard on Reddit that there's issues with camera losing tracking sometimes, other times it works perfectly however and it's inconsistent behavior. I tie occasional tracking loss to apparent excessive camera jerking where usually distinct tracking LED images smear into a blotch which confuses tracking algorithm, i.e. the fixture wasn't rigid enough - using metal bars for the purpose would be. Without tracking camera footage is hard to tell so I just have to guess. The guess is unplausable anyhow because tracking camera should never increase exposure time (LEDs are clearly visible in all lighting conditions anyhow) and therefore there should not be smearing even under violent motion. Further development and investigation is required, but we're getting somewhere with this.

>There is currently no way to replicate the full G forces in a cost effective manner
You can to some extent simulate them properly, but that takes a very specific rig layout and very powerful motors. I'm thinking this through. Soon enough SketchUp 3d project will be finished. I don't know any good way to visualize forces in SkU, but I think that a free-swinging pendulum on a spring in place of driver will have to do.

>such increased latency and synchronization
This is a topic worth discussing. First off, I'd like to notice that contrary to (as I see it) popular belief that you should use PID, you shouldn't. PID has number of drawbacks, and with respect to current talk it imposes great deal of lag. This is because it's basically a low-pass filter with prediction function and damping applied. I only learned today that PID is a thing, but I've been doing something similar half a year ago when I was trying to create an algorithm for smoothing out wildly noisy Razer Hydra inputs. I tried a lot of functions and combinations, and it seems that the best option without deeply hacking into Hydra driver is to use aggressive gaussian smoothing and very aggressive prediction to compensate. Combination of two exhibits similar properties to PID, such as lag behind input data, killing high frequencies, bad reaction to abrupt function change, and PID additionally tends to oscillate around target value. This is because PID has no knowledge of the nature of the system it's working with. You should instead use accurate mathematical model of the system you're modelling, i.e. a motor that rotates weighted flywheel.

On topic of lag, how much lag there is between event happen in the game and servos start moving, assuming servos travel magnitude is not controlled and they just free spin accordingly to in-game forces? Depending on polling frequency lag from game to SimTools should be 3-15 ms, then SimTools imposes lag of up to sending rate of the signal, and controller board should take next to no time to send the signal to the servo. With high framerate and high sending rate, that should be about 20 ms worth of lag. Given that vestibular system is not as sensitive as visual system (let alone tactile sense of pressure from G-forces) this may be sufficient.

I would also bring up GVS, although this is complicated beyond reasonable. If you use GVS you can simulate sense of arbitrary amount of acceleration in arbitrary direction (realistically though just laterally but not vertially) thus lifting the need for the rig to provide G-force feedback. But then you end up with, eh, having no G-force acting on the rest of your body. GVS may be used well in conjunction with simxperience-like 2DOF rigs that mostly simulate abrupt changes in car motion such as violent turning, road bumps and collisions.

Hi raidho36, wellcome to the site. I'm guessing from the comments above that you already have a working VR motion sim? Just post some photos/videos in the project area - you don't have to give away all your secrets.

@SeatTime no I don't, I specifically said I'm thinking of building a sim (in welcome thread though), as in thinking it through, calculating, etc.

@noorbeast
I beleive to use a hard motion sim you'd have to be fastened to the chair so that only leaves a few inches worth of head travel. If camera is fixed to the rig that absolutely solves the finite tracking volume problem. Smearing is usually not an issue, but if it's strong enough for several points to smear into a single blotch then that becomes a serious problem which usually doesn't worth resolving programmatically since results will be sub-par and function behavior will be unstable anyway.

>You need a centrafuse to recreate strong G forces, anything less is a simulation and how well it works relies on fooling the brain in as seamless a way as possible.
I don't aim with actually simulating G-forces which is not really possible for any motion sim anyway, but yes I'm thinking of using a tangential (no pun intended) effect of that principle to provide sense of acceleration at low tilt angles. There's one parasitic variable to equation, though (velocity), and right now I'm trying to solve this more or less nicely. One is known for sure that the software is nowhere even remotely sophisticated enough to calculate motor drive strength, so I'll have to write whole another program to control the rig motors, only using SimTools to gather telemetry and feed it to the calculator.

>Latency and synchronization are far more complex than just one factor, they relate to all aspects of the simulation, the Rift, the motion simulator, the game and all associated hardware.
Yeah that didn't answered anything. I'm trying to actually calculate the latency of a motion sim so I'm trying to gather up some numbers. Latency of the Rift itself is out of question, but it promises to be well under 20 ms, which is good enough for visual cortex to think that there's none.

yes @raidho36 , have you actually built a simulator and then spent time getting the rift right on it?
@noorbeast has.......

Smearing is just a hunch, as I already said, but reportedly with some titles (AC specifically) it works nice and with others (Dirt 3 speifically) it has issues with tracking loss, which suggests that it could be smearing problem since road racing is supposedly gives smoother ride than rally racing. As I also said, it's not possible to tell without camera footage and more investigation is required.

>I would be interested in details as to the design factors you are considering concerning capitalizing on the tangential effects, particularly regarding practical implementation. Is it angular velocity you consider the 'parasitic variable'?
Yes. If you use tangential acceleration to provide sense of acceleration at low angles, by the time you wind up the rig to high angle you would build up a lot of velocity which you'd have to damp, but doing it is literally creating a counter-acceleration. I've derived a formula that accounts for that, but the speed damping function itself needs a lot of work. Right now I'm trying to simulate it programmatically - not that I have a real rig to test it on a bare metal anyway. I'm developing it in 2d since it's simplier that way and 3d only differs by having an extra dimension to force vector. It wasn't so bad and I got it working, and I immediately found out that I probably should use twofold filter: low-pass filter for overall tilt and high-pass filter for rapid jerking. Other than that, everything works as I estimated - it instantaneously creates some G-force and then drives the chassis to the angle that would generate similar amount of G-force through Earth gravity. Simple damping, as predicted, still resulted in subtle swaying which gets pretty strong upon very harsh abrupt changes, and additionally the G-force from continious surge has a drop in the middle of windup time frame. Still beats having it winding up from zero, or having it going in complete opposite direction up until the frame reaches required angle.


@bsft no I did not, as I said, but I heard reports of people who did. Even if that's one case out of ten, it's still an issue that needs addressing.

I can assure you that if you hard mount the camera on the rig it loses tracking ALOT , unless we have some way of stopping the violent vibrations travelling to the camera eg from heave over rumble strips or kerbs and wotnots.

Maybe some kind of shock absorbing mount, I even thought of getting a gambel and see if that would help but i don't think it would stop the up/down movement , the camera would always be level but would still get too much shock from the rig vibrations.

Must be something out there to do it.

And I Haven't got a clue what you 2 are discussing @noorbeast and @raidho36 lol. Way too many big words for my simple mind

Thanks for the input @SilentChill. So it looks like smearing from camera jerking is the case after all. I have to tell though that instead of using shock absorbing mount, you should make the mount as rigid as possible relatively to the rest of the rig, up to using "unbendable" (to some extent) materials such as steel frame. I once had similar issue with 6DOF LED headtracking OpenTrack - mounting point of the camera would yield vibrations time to time and it was causing problems with going out of tracking dot size due to smearing. I resolved the issue by fixing the camera in a really rigid fashion to ensure absense of random jerking from vibrations.

As I said the vibrations nearly shake me to bits let alone the camera any slight movement with the camera and it goes crazy.

I will try and do a video to show you how bad it is.

@SilentChill yes please. Thank you for your time in advance.

@SilentChill , do not waste your time, have a look at this guys posts and see why hes not worth your time.

@bsft @noorbeast Please go be counter-productive somewhere else. Figuring out how to make VR work well with motion rig is everyone's business, it has to do with every motion rig owner, because sooner or later all of you (and I hope me too) will be only using motion simulators in conjunction with VR and triples with projectors will drift into oblivion. For some, it happens already.

speak for your self!

OMG! I have just had my first laps in LFS with the Oculus Rift DK2 and motion on my sim! Apart from the fact that I don't see the room that I'm in, only the race track, the motion cues relating to what I'm seeing is absolutely amazing. I still have to tweak the profile as I had a complete re-install of Simtools following a computer upgrade. I appreciate that the DK2 is not a finished product, but the sense of "presence" is tremendous. VR isn't for everyone, But I love it!

Mike

@noorbeast So I assume we can now quit with unrelated things and concentrate on the topic, right?

The highlighted problem is tracking loss. Yes the camera tracking is designed to be static, as in it assumes that head doesn't moves too violently, and given that it has no issues with tracking people's natural motion I don't suppose that under 1G worth of accelerations is an issue for it. This gives some implications but first obvious thing about it is that rig-relative "static" is the same as room-relative "static". If camera is fixed in the room, then there may be issues with tracking volume limitations, as well as that if the rig moves around too much there may be occlusion problems. If a camera mounted on the rig, that obviously will not be an issue, but the camera is very heavily affected with vibrations, thus making it jerk around, which is known to not be acceptable. My idea regarding this is that fixing the camera in a really hard and really rigid fashion will make the picture static rig-relatively. I don't own a motion rig, so I can not really test it by myself. I may still test it with simple replacements such as simple webcam attached to a swivel-chair - I would jerk it around to see if camera's footage is static relatively to the chair. But that would be another two weeks until I get home and around here specifically I don't have a wired webcam, only a laptop webcam. However from my past experience with LED tracking and jerking camera, I know that doing it should probably work because it worked for me with OpenTrack, and Rift's tracker is a lot more sophisticated system. It would be appreciated if someone could test this kind of approach.

A minor correction there: Rift DK1 only uses magnetic field for yaw correction because due to gimbal lock it's not possible to do it any other way. Pitch and roll are corrected using gravity vector which is always pointing downwards.