Snap ! I read somewhere John Carmack mentioning the FSRK-USB-2 allowed to build a full matrix update and I assumed it would be a 4x4 with rotation and translation but it seems we can only build a 3x3 rotation accurately....I wonder how this is going to impact the occulus rift: "Yaw" and "Pitch" should be fine but human "roll" movement are also accompanied with translation since the movement starts at the base of the neck....I have never tried a VR Headset so maybe the brain won't notice....

A solution would be to hard code the head translation for the Yaw...

Carmack put in some "fake" translations so that all three rotations model the shape of the head and neck. So for example, looking down is not just a rotation around the camera midpoint, but is a rotations around a modeled head originating at a neck. Same with yaw and roll. These translation animations are "canned" however and not derived from actual translations pulled from the sensor.

Source ?

I'm pretty sure he mentioned it on one or two of the E3 videos that circulated.

I think he mentions it in this interview (but it could be another, there were a bunch of them):
http://www.giantbomb.com/e3-2012-john-c ... w/17-6164/

What's the reliability on the acceleration values? As in, can it reliably tell between if the user is stationery and moving in one direction or another? (I'd imagine that the drift would create a small degree of acceleration even when stable - but as long as it reports a reliable difference between stationary and moving, then you'd be able to discard the smaller drifting values.

If the reliability is good enough, wouldn't it be possible to use that data to initiate the translation movement in the view - while integrating slower camera based (i.e. kinect) absolute positioning information, to allow for some degree of view translation that should be adequate (i.e. better than nothing) for now?

The way I figure it - the accelerometers should help start the vector of translation at less than 20ms - the next 50ms, the view point accelerates at any arbitrary rate (determined by the average movement speed of a person), at the 70ms mark (a number I pulled from Carmack's mentioning about attempting to use the kinect (may have heard him wrongly)), the data from the kinect kicks in, overriding the assumed vector intiated by the accelerometers.

Of course there'd have to be some degree of prediction to smooth out the transition from accelerometer data to camera positional data - otherwise the view point would jump back 50ms to the kinect starting. But then doing that would probably add a few dozen more milliseconds as the system attempts to match the assumed trajectory up with the predicted, extrapolated data from the kinect.

But when head and torso movements regularly range into the second+ range, the jankiness of a couple hundred milliseconds may be an adequate compromise to having translation tracking at all. Additionally, there shouldn't be much in the way of overshoot - as you'd use the accelerometer data for stopping to halt the view point immediately, rather than continuing to use the lagging kinect data.

What do you think guys? Am I on the right track here?

I think it's instructive to view what raw accelerometer readings actually look like. Here is a short sample I took at 60Hz, holding an accelerometer as stable as I possibly can and then slowly moving it forward for about 1 meter. You can see the motion along the green axis starting from about 2 seconds to 5 seconds.



This is what we mean when we are talking about IMU sensor noise. And this is a very constrained example. Things get much more chaotic as you start turning and moving at normal speeds. Can you see the motion signal - yes. Is it easy for the software to pick it out - sometimes. But it's rarely as easy as a simple cutoff and you generally need to smooth the signal to increase accuracy which always introduces delay. There is always a fine line that you traverse between accuracy and timeliness. You can have high accuracy and low responsiveness or you can have low accuracy and high responsiveness. Getting both is difficult. Complex mathematics and multi-sensor fusions definitely help but no one solution has really been the magic bullet to solve this problem in the general case with high accuracy.

Thanks for the response. I understand quite clearly now the issue - by the time the acceleration signal overcomes the natural noisiness of the data, you've already been in motion for a few hundred millisecond - rendering this on-off initiation unusable.

I wonder if the Freespace lib will be library of choice for Rift games, if so we should work on emulating that lib from FreePIE so any generic tracker can be used, for example from Cyber's Rift driver etc

The Oculus SDK will be the library of choice and we should offer a plugin as soon as the SDK comes available.

I've totally missed that there will be a Official SDK, who will be doing it? As I understand it Palmer isn't a developer?

Oculus has 10 or 15 employees now. I think the ScaleForm guys that joined Oculus have a big hand in the SDK development.

I have to read up in the RIFT forum I hear

Does anyone have any advice for getting the FSRK USB ver 2 to work with FreePIE? I'm not having any luck. I used GlovePie before to map the mouse provided by the USB module to TrackIR so games will work with 2DOF, but I can't get the script you used to work. It'd be nice to get pitch/yaw/roll in games that support TrackIR.

Maybe I need to set my device to a different mode, don't know...

Thanks

Edit: I did get the Y/P/R values in the latest freepie and mapped to mouse (!) so I think this is just a trackir emulation problem.

FreePIE recently changed their script format from LUA to Python scripting so many of the scripts will not work any longer. It should be pretty simple to change the syntax. If you look at CyberVillain's scripts in this thread you can get a flavor for the new syntax.

http://www.mtbs3d.com/phpBB/viewtopic.php?f=139&t=15052#p74672

Thanks - I figured that out eventually I added diagnostics.watch() and was able to see the freespace.* values coming from my FSRK-USB-2/FSM-6.

It would be nice to get support built for the 250hz firmware (or just doing XYZ with custom fusion). Maybe just a toggle switch to use the Body Frame or User Frame for XYZ calculation. It still works right now with FreePie but since no fusion is being done it's not smooth.

Something like viewtopic.php?f=140&t=15247&start=1035#p90637

I am trying myself with a couple fusion algorithms (like the one shipped with FreePIE) but can't seem to get values in range.

I do think an open source fusion DLL for the Hillcrest is a good idea if tmek wants to donate the code, but I believe something like that should be handled at the "driver" level before it reaches FreePIE. Not necessarily a kernel level driver, but at least in dedicated user space code - like a DLL built on top of libfreespace that just handles fusion and exposes the values. I think there are too many unpredictable timing pathways in FreePIE to guarantee a solid fusion algorithm within the framework since a single thread is used to run the Python script and interact with all the devices. So you can't predict the duty cycle because you don't know what sort of Python loops or blocking operations that thread might encounter on its way back around to your plugin.

You could handle it in the plugin thread (Have the plugin return a action from the Start method)

Sure, but there's not much benefit from running it in C#. Code samples for fusion and hardware interface libraries are always written in C, so porting it to C# and marshalling all of the data structures is just an exercise in tedium with no clear benefit.

Just giving all the options, but if you can do it in the driver thats fine

The PS Move API uses the fusion code from Sebastian Madgwick and it can work at varying FPS with the time period being feeded to the algorithm at each refresh. Maybe that would be a good addition to FreePIE.

The fusion code from Sebastian Madgwick which looks like state of the art at this time (ie. better than Kalman filters) is also available with an open source C# implementation :
http://www.x-io.co.uk/open-source-imu-a ... lgorithms/

Also this algorithm is able to do good fusion even at slow frequencies, in his paper the author said that the quality was equivalent at 50Hz and 500Hz, so the 250Hz firmware for the Hillcrest may not be needed.

The paper : http://www.x-io.co.uk/res/doc/madgwick_ ... report.pdf