Hi, I've not been following the forum lately, I'll have a look.
You may have a read at this for optical tracking : https://www.reddit.com/r/oculus/comment ... w_optical/
I've been playing a bit more with the Madgwick algorithm and I can reproduce the drift reliably. I thought the PS Move sensors were not up to the task but I can get the same problem with the DK2 using a 1.0 value for beta. With this a small rotatio…
Basically extended and linear Kalman filters, but they're more complex to implement and I've not seen open source implementations yet (didn't search for that specifically). In the paper it's said that the gradient descent algorithm is as good as EKF…
I took the value directly from the paper, I don't know why the PS Move API uses 0.5 by default, looks a bit high.
Yes, I've been reading a lot of papers lately and it seems the Madgwick algorithm is not the best in town contrary to what I thought (…
IIRC I had this kind of drift some months ago, but I don't have it anymore with Unity and the Madgwick algorithm implementation in C#. I'll try again with the C algorithm to see if there is a difference. I guess you did calibrate the PS Move magneto…
Yaw drift is not too bad for me, but not all initial physical orientations of the PS Move are in the same calculated orientations, which is a problem for the registration of the PS Move and DK2 orientations.
When I place the PS Move with the orb at…
For the orientation I've found two algorithms that should be able to return an absolute rotation in an earth reference frame using only the accelerometer and the magnetometer :
- Accelerometer and Magnetometer Based Gyroscope Emulation on Smart Sen…
Nice that you got this integrated into the PS Move API, too bad for the UE4 support. Do you intend to implement the plugin for Unity or do you want me to do it ?
No preference there. But if the coregistration is implemented in the PS Move API it could make sense to also add a function that can return the position of the PS Move in whatever referential needed by the application. That would mean a bit less wor…
When I started using UniMove it didn't support positional tracking so I implemented that myself, that's what I released 10 months ago. The code you're asking for seems to be this one in MoveManager.cs :
#if PSMOVE_TRACKING_THP psmove_fusion_get_p…
Sorry I didn't see your post, I've just updated my Github repo with the Ernst 2012 calibration implementation and some tries with the calibration of the rotation using the Madgwick C# sensor fusion implementation, in case you've Internet access.
I think it was just an error in the comments code. m/s^2 is a unit that should be returned for an accelerometer, not a gyroscope. And for the magnetometer it was specified "rotation rate in rad/s", but it should have been a value in gauss.…
I'm using the corrected sensor values for both the PS Move and the DK2 and I'm doing the sensor fusion in place with the Madgwick algorithm. Looks good for the PS Move (better than the PS Move API implementation even) but the DK2 is quite off. I tho…
Sorry for your family, I hope everything goes fine.
I'll try to implement rotation registration this week-end, along the lines of what you suggested previously. If I don't get something working I'll push the source for the translation part on Githu…
Thanks. :)
What works now is the coregistration of the position of the DK2 and the PS Move, whatever the position and orientation of the PS Eye and DK2 camera. I'll probably post a video shortly to show how it does work.
To have something usable f…
Testing a bit more, the lsqr implementation does in fact work, it's just that it's a lot more picky about the number of poses it requires in C# compared to Octave.
5 poses are enough in Octave to be able to get an identical result to the original m…
Not sure if anyone is still following, here is my progress anyway.
I've implemented the Matrix4x4.TRS and Quaternion.Euler Unity functions in MATLAB in order to have the exact same use cases in both environments. When I use these functions in Octa…
The problem is in the algorithm. When I build the test data, if instead of using B = inv(Y)*A*X I use B = inv(Y)*inv(A)*X I can obtain the correct X (translation only) and Y matrices.
So I've modified the algorithm to use the inverse of A in the ca…
I've read several papers from Zhuang that someone sent me (thanks!) but they don't answer the problem. They solve the AX=XB equation but B in this case corresponds to a combination of two poses of the PS Move. The rotation part is not needed in the …
The DK2 lens is not plano-convex but double convex, although one surface is much less curved than the other one. It's not clear if it's aspheric or spherical either, the DK1 lens was aspheric but nothing has been said for the DK2 lens.
If you don't…
Since resolving the AX = XB problem seems to be a dead end without PS Move orientation data, I've re-read the Ernst 2012 paper more in depth (dealing with the AX = YB problem).
I think I understand how it does work, but it doesn't fully solve the p…
From another paper from Zhuang it seems that their algorithm can't in fact find the transformation matrix X from AX=XB without knowing the orientation of B :
In this correspondence, we point out that although the iterative algorithm does not requir…
That's quite smart, I didn't think about this. Since we know that in axis-angle representation the PS Move and the DK2 have the same angle, maybe using the red LED and the PS Move orientation with the orb position we can get a reasonably good value …
There are at least two algorithms for the AX=XB problem that don't require to know RB (rotational part of B). The more recent one seems to require the knowledge of an initial pose for B (rotation + translation), so it's probably not usable.
The old…
When I read the Ernst 2012 paper I found a notation I didn't understand that basically transformed the AX = YB problem into a AX = XB problem for which there are known solutions. Unfortunately this equation also requires 6dof data like the AX = YB p…
I ignored the PS Move orientation as well, it's quite unreliable and it's not in a meaningful coordinate frame ("world" instead of PS Eye reference frame).
Yes I accounted for that as well (Rx and Tx in my equations).