Drift eliminated (camera optional)

[m-7761]

The code here ( https://github.com/gusmanb/PSVRFramework/blob/master/PSVRFramework/BMI055Integrator.cs ) is highly redundant (can be rewritten to a handful of lines of code) but on the following subroutine invocations:

fusion.Update(angularAcceleration.X, angularAcceleration.Y, angularAcceleration.Z, linearAcceleration.X, linearAcceleration.Y, linearAcceleration.Z, 0.05f, interval);

fusion.Update(angularAcceleration.X, angularAcceleration.Y, angularAcceleration.Z, linearAcceleration.X, linearAcceleration.Y, linearAcceleration.Z, 0.035f, interval);

If more aggressive values are used (I'm using 0.1f) for both cases (there are multiple cases in the redundant code) then "drift" is practically eliminated from the PSVR.

The home-theater mode drifts quite a lot, so it's worth noting that drift can be eliminated from play sessions entirely, or only require corrective action sometimes, seldom enough to not be a nuisance.

Higher values here introduces a wobble, that is probably just a side effect of the algorithm. The wobble is visible if you use the data to drive the in-software camera. However it's not so bad that you cannot enjoy yourself, and there is probably techniques (which I'll explore) to decouple the in-software camera from the in-hardware sensor readings.

In short, more aggressive values add wobble, but eliminate drift. And 0 values (no "fusion") has the least wobble, but also, the most drift.

[m-7761]

Okay, there's still slight drift sometimes (edited: mainly on yaw) but 0.1 seems near optimal... EXCEPT HERE IS A BETTER way to see immediate results versus the PSVRToolkit implementation:

        /*
        (G):
        125d/s 262.4 LSB/d/s
        250d/s: 131.2 LSB/d/s
        500d/s: 65.6 LSB/d/s
        1000d/s: 32.8 LSB/d/s
        2000d/s: 16.4 LSB/d/s 
        */
        //gRes = 0.06097f*M_PI/180;    
        //gres = 0.06097560975609756097560975609756*M_PI/180;
        gRes = scalar(0.00106422515365507901031932363932);

In addition to this, change 32-bit floating point types to 64-bit types. The results are much more like the home-theater mode's. The "fusion" algorithm (Madgwick) continues to behave the same, but there is very little to no noise in the system. It would surely do better than without the fusion corrective. So, it's totally worth going to 64-bit, as this kind of thing almost always is so.

With this change, it's much less urgent to switch to 0.1 for the beta figure, but I honestly cannot say if it remains better for minimizing drift, but it certainly wobbles.

(The wobble is actually not so bad, since it functions as a kind of AA filter, but there is probably better ways to add to an AA regimen. It's hard to make things look nice on the unique display. I've had some success replicating the home-theater mode's filter, by generating a mipmap of the final image, and sampling it with a 75/25 blend. That's a fast way to do it. I think the home-theater mode does something much more expensive, that has a DOF effect, but whatever it does, it reduces the effective resolution of the input image by half. Similar to if the mipmap itself was used, or 100/0 blend.)

[m-7761]

NOTICE: #14 follows up on this.