PSA: Watch PSVRTracker

[m-7761]

I think there may be movement yet for PSVR... watch this (https://github.com/HipsterSloth/PSVRTracker) space. I think it will be the new PSVRToolkit at some juncture. (I'm going to start working with cameras before long.)

P.S. Here (http://oddsheepgames.com/?topic=here-is-a-demo-that-has-great-anti-drift-steadiness-qualities) is info on a demo (https://www.reddit.com/r/KingsField/comments/9kj984/very_early_playable_section_of_kf2_for_windows/) that includes a hybrid approach to defeating drift that works very well. I talked about developing this before. Just for the record, it works well, and is straightforward to implement. With it, you can easily get by without position tracking, since the approximation of the set's orientation is very good. It can get thrown off, but for the most part, you can work for 30mins or hours and not drift. It seems especially good at defeating roll drift, which I think is most important. I don't know why.

FYI: That demo's FOV is fixed for PSVR but uses a pretty obnoxious value to approximate the game it's porting. Alt+F3 can change the value in the INI file. The original game distorts the picture in some way, that I don't yet understand. It's pretty interesting that it makes such high FOV possible.

[dylanmckay]

Great find!

I trawled through the King's field ZIP but could not find any source code, it'd be cool to hear a bit more information about the hybrid algorithm.

I've been using a Madgwick filter from a library, plugging the same beta value in as one of the PSVR example projects. Your oddsheepgames post talks about having two beta values, which seems incompatible with plain-old-madgwick. What IMU algorithm are you using?

[dylanmckay]

Just spotted this, makes sense now

In the meantime I quickly developed a hybrid system that blends two side-by-side Madgwick integrators (mainly copied from existing sources) so that one is optimized for its anti-drift quality, and the other for its picture stability, so that when your head isn't moving (imperceptible movements) the more drifty/stable position is shown, until that is, it drifts too far from the other's better estimate. At which point some fudging is required to reel it in to the orbit of the more chaotic/correct approximation.

[dylanmckay]

I've added a link to PSVRTracker and all the other examples I know of to the docs in d29ed97.

[m-7761]

Sorry, I just updated/cleaned up (removed space based indents) the source code. The relevant code is in this (http://svn.swordofmoonlight.net/code/SomEx/som.mocap.cpp) file which I think I've shared before. It's buried in game type logic. The source files are usually updated with each release, however this demo is between releases, and is not really meant to demonstrate this, but I took an hour or two to improve its PSVR experience before publishing it.

The block that does the blending, I just threw together intuitively. It looks fine. It begins with the following comment:

//slerp/attractor: should be aggressive as long as head is not still

FWIW I think this probably offers far better experience than any existing PSVR projects have... outside of the PS3. Possibly there too! But I'm not basing that on anything, other than code I've seen is not using the higher beta value. Trinus PSVR's maintainer contacted me a while back and said they were adding an INI like option to change the beta factor, but I think this is not useful in itself. They had not thought about it, and after investigating determined that it can technically depend on factors like altitude and temperature, humidity, etc, but this all seems to me like the difference due to these factors would not be more than fine tuning, and that the 0.1 value must be inherently far better, regardless of these factors...

I'm a little superstitious that using float works better for defeating drift, which is why I implemented the integrator class as a template. It's hard to say, because all I can go on without a deep understanding of the difference is spending time in VR with either valueformat, and saying anecdotally if drift seemed better or worse, which is really hard to say if drift is nearly eliminated. It's certainly far better than my unit's Home Theater mode, usomg the original firmware. Which suggests that Sony used an inferior method at production time. (I think my color correction is a lot better than theirs too, but it still has a lot of room for improvement, and is not methodical enough. I kind of don't like to think about how bad the color is out of the box... and the fact that it's never going to be satisfying.)

EDITED: For the record, the source code is in the project development software (Sword of Moonlight) whereas the demo is a product developed with said development software.

[m-7761]

There is a bug (I think*) in the following code (I noticed looking over it) that kind of helps to illustrate how calibrating the "steadycam" doesn't really matter since it converges on the "antidrift" calibration almost instantly regardless. FWIW not wanting to overthink it, the attractor code converges on the bind-pose of the antidrift target, and since that doesn't change unless recentered, they both end up with the same bind-pose in short order. They are implemented independently mainly because it's less code that way.
*I may have done it intentionally, since it is pretty pointless to calibrate... but if so I forget about it :)

		//scalar2 beta; 
		if(samples>-samplesN/4*3) //-1500
		{
			beta = beta2 = 1.5f;
		}
		else if(samples>-samplesN)
		{
		//	beta = best; //0.05f;
		}
		else //beta = best; //beta = 0.035f;

		//MadgwickAHRS(angularAcceleration,linearAcceleration,beta,interval);		
		steadycam.MadgwickAHRS(angularAcceleration,linearAcceleration,beta,interval);
		antidrift.MadgwickAHRS(angularAcceleration,linearAcceleration,beta2,interval);

[m-7761]

BTW: Since you downloaded, here (http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip) is new version of the main DLL in the EX/SYSTEM folder that adds dedicated support for Sony's DualShock4 drivers. The TXT file in the PSVR folder describes how to turn on stereo mode, after turning on the PSVRToolbox provided. It automatically switches between the set's home-theater and pass-through modes.

[m-7761]

Sorry to continue to add to this, but just FYI for readers, I've edited a comment on FOV without PSVR into the top post, since I realized the default setting is pretty unpleasant. (The early demo is that way to approximate the PlayStation game but is missing something.)

[dylanmckay]

Here's a summary for any readers.

@mick-p1982's description of the head tracking algorithm:

In the meantime I quickly developed a hybrid system that blends two side-by-side Madgwick integrators (mainly copied from existing sources) so that one is optimized for its anti-drift quality, and the other for its picture stability, so that when your head isn't moving (imperceptible movements) the more drifty/stable position is shown, until that is, it drifts too far from the other's better estimate. At which point some fudging is required to reel it in to the orbit of the more chaotic/correct approximation.

Here's the snippet of code (from som.mocap.cpp) that sets up the integrators.

//TODO: TRY <double> BUT FLOAT SEEMS MORE STABLE, DRIFTWISE
//IT'S HARD TO SAY THOUGH, AND AS TO WHY IS A MYSTERY IF SO
Madgwick<float> antidrift;
Madgwick<scalar2> steadycam;
som_mocap_BMI055Integrator()
:antidrift(/*0.1f*/0.125f) //RATIONAL FRACTION
,steadycam(/*0.05*/0.035)

Here's the beta values for the two Madwick integrators used. Anecdotal evidence says that using 32-bit float values for the anti-drift calculations and 64-bit doubles for the picture steadying calculations.

Integrator	Suggested data type	Beta
Anti-drift	float	0.125
Picture steadying	double	0.035

I can't quite tell how the rotation quaternions are combined yet, one [untested] idea of mine is interpolating between the two rotation quaternions produced by the two Madgwick filters at the midpoint between the two, like how you can interpolate a line from two points and then choose the midpoint to find a point in the center of the two.

[dylanmckay]

Sorry to continue to add to this

I'm the only one getting emails, but I find this really interesting! I struggled to get good motion tracking in my program, your solution sounds like a very novel and easy way to get it working well.

[m-7761]

I fixed a few (strange) typos in my earlier post. Right now my PSVR is being serviced under warranty for debris that is loose behind the lenses, maybe some adhesive broke free inside the housing. Otherwise I might be working with cameras/PSVRTracker.

I thought I left it on a value even less than 0.035, but maybe I Ctrl+Z that away accidentally. Truth is these values can be pushed higher/lower as much as is comfortable as long as the experience doesn't seem to get worse. I know at some point too high of a value (more than 0.1) will stop working altogether. I've pushed it to 0.125 in the hope that more aggressive is even better, however there may be something magical about 0.1, but 0.125 is not bad. (EDITED: 0.125 is a rational number, which might be more stable since floating-point can represent it absolutely. It's just hocus pocus, but that's why I chose it.)

What this setup buys you is a lot more freedom to explore values for the beta factors, since it decouples what you see from the drift fighting aspect of the fusion algorithm. I think 0.035 and 0.1 are good starting points.

The reason for float is using double (and feeling out constants to all significant digits) is very smooth, but I worry that somehow the very small rounding errors slowly creep into the system, whereas with float the values are all truncated, and the system is inherently chaotic (it's always bouncing around all over the place) and that maybe this actually improves things.... I say "maybe" only because I've only tried double briefly, and it seemed to drift a little more, but it could just be my imagination, whereas I've spent a lot of time with float and know what to expect from it... double needs more testing/I cannot endorse it IOW. double certainly looks better, and that is why it's used for the picture.

I can't quite tell how the rotation quaternions are combined yet, one [untested] idea of mine is interpolating between the two rotation quaternions produced by the two Madgwick filters at the midpoint between the two, like how you can interpolate a line from two points and then choose the midpoint to find a point in the center of the two.

A basic description is you measure the angle between the two quaternions and do a "slerp" that pulls A (0.035) toward B (0.125) by a degree, "t," that is more when the angle is higher than when it is lower. After that, it's just a matter of deciding on how to arrive at "t." I think the example code uses an exponential function and some maximum angle to arrive at "t." So the basic idea is very simple, and the devil is in how to parameterize "t."

This process is interpolation, as you say, except it's moving the points in rotation space, interpolating rotations, and if you did as you suggest, you would set "t" to 0.5 under all circumstances. That should give you an idea of what is going on, but this would not be a good approach, because either the picture would always be pulled closer, and so 0.5 is always moving ever closer to the chaotic center of this binary system (and so the picture becomes chaotic) or it is not pulled, and so the picture drifts away from the orbit of its chaotic star so-to-speak until they are a world apart, and your picture is between them (in rotational terms, since we are speaking about orientation.)

[dylanmckay]

Well put, I think that answers all my questions around it.

Next time I start working on my VR project again I'll implement it and report back.

[dylanmckay]

Here's my implementation

dylanmckay/hmdee@30613bc

I've left t=0.5 for now but will calculate it properly in the future.

[m-7761]

Hey, I finally got my set back last night (it took 3wks in all, because I left the cables in town, since Sony didn't want them) and just FYI it feels like it's more drifty than I remember, especially at the beginning, so I need to look into it. I think probably it should be scaled back to 0.1. I think the unit/box I got back is not the same ones I sent in for servicing.

It's also much colder now, but I am still unconvinced temperature is a major factor for the sensors.

P.S. It seems to me like the resting values have a little bias in them. But it's hard to tell if it's imaginary or not. It's hard to explain what I mean: it's like the roll doesn't drift away, but it sometimes feels like it's stuck where up is a little bit off, but it's really hard to tell with the head set on if your head is upright or not, because you have this weight on it, and maybe your neck muscles are just a asymmetrical. I find what helps is to move my head more often and in a more exaggerated way, so that the sense of being a tad bit crooked cannot take root. In any event, I'm contemplating adding a static offset/calibration to see if it can be made more comfortable.

BTW: In a few days I'm going to be updating that demo. But while it will be a nice update, the VR elements are not going to change. I've been eager to look at camera work. But I think a more interesting area to pursue is color correction, which could use a more methodical approach than I've so far afforded it. The color is quite good in the updated demo, but mainly because I've figured out how to make the game appear identical to the original (there is a pretty complex color transformation function, and I've since figured out the 3-point+ambient lighting through observation. It took hours over many evenings to work it all out by eye!)

[m-7761]

Hey again, it looks like sticking to 0.1 is best.

Right now I'm concerned about some code in the PSVRFramework that I don't understand (https://github.com/gusmanb/PSVRFramework/blob/master/PSVRFramework/BMI055Integrator.cs) that I worry is unsound. The gravityVector part I can't understand, or justify. I looked at your hmdee code to see if it did calibration this way, and could not find anything.

I looked at other code, and could not either. 2 or 3 weeks ago the TrinusPSVR person asked me to take on a job for them to implement this feature, which I turned down, offering to answer questions instead. But I wrote them again just now, because I realized their code is not open-source, and so maybe it would be worth it to help them to be able to look into its code.

The value for accelOffset in that code, after calibration is generally small. I can't see a difference if I set it to 0,0,0. So I think it may just not be registering as a problem, since the Madgwick algorithm seems to do well with or without it. The logical thing to do (to my mind) would be to remove the influence of the gravity based acceleration, by subtracting it from the readings. But that degrades tracking considerably. Adding (which seems strange, but is what this code is effectively doing, although I think the value tends to be negative) looks fine, until you start looking up/down, at which point it drags back to the middle.