Help needed

[kumarsmurthy]

Hey Fred, Thank you so much for sharing your code. I am trying to use PS move and Kinect for a School project that I am doing. After a lot of struggle, I ve got the PS eye to work on Windows 7 machine. But the PS move adjusts so that if I point the wand upwards, the move is pointing to the front. How do I work around this? Hopefully there is a way to do this in C# (I don't wanna mess with openCV!)

[Fredz66]

The code here will only help for registering positions between two referentials. It seems what you need is to register the orientation, which this code doesn't support. You may have more success by simply putting the PS Move in a known position and re-entering it by the push if a button. Accuracy will not be great though.

[kumarsmurthy]

Sorry, I understand that this code was not meant to do that. (Didn't know where else to comment on Github actually! ) But the problem was supposed to be very simple. The orientation was off by 90 degrees on X axis. So

1. I put a parent gameobject on top of psmove with 90 degrees on it -> Didn't work
2. Quaternion multiplication -> Didn't work
3. Tried to change ProcessData() to swap the axes orientation.Set(ry, -rz, -rx, rw); and many other combinations. -> Didn't work Push button always seems to be 90 degrees off! Am I holding the PS Move wrong(Upwards) or is there anything that I am missing?

[Fredz66]

Did you try with cboulay implementation ? It has a modified handling of rotation and doesn't require the CL Eye Driver. It's available here : https://github.com/cboulay/psmoveapi

[kumarsmurthy]

I am already using his version of drivers and not the PS Eye drivers. I tried both THP's and cboulay's dlls. I am having the same issue of rotation off by 90 degrees. I was just checking, there are 8 variables(-rx,rx, -ry, ry, -rz,rz, -rw,rw) that can be put in 4 places in 8_7_6*5 ways! No wonder I am doing so much trial and error !

[cboulay]

If you use my DLLs (you can find them here), then the orientation is returned in a right-handed system with +X going from the select to start buttons, +Y going from the USB connector to the sphere, and +Z going from the trigger to the move button. To get this to work naturally in UE4 (which I think uses the same coordinate system as Unity), I do one of two things depending on whether I'm coregistered through the HMD or not. The code for both can be seen here.

Briefly, the magic step for me at least when NOT coregistered is:

newQx = -oldQz
newQy = oldQx
newQz = oldQy
newQw = -oldQw

[cboulay]

And about the search space, it's not as big as you think because there are many redundancies and other rules that govern physical transforms. Because you are changing from a RHS to a LHS, you will always have one of the axes (x,y,z) negated and the angle will always be negated (i.e., -rw). I think there are 18 options.

-x,y,z;    x,-y,z;    x,y,-z;
-x,z,y;    x,z,-y;    x,-z,y;
y,-x,z;    -y,x,z;    y,x,-z;
y,z,-x;    -y,z,x;    y,-z,x;
z,-x,y;    z,x,-y;    -z,x,y;
z,y,-x;    z,-y,x;    -z,y,x;

[kumarsmurthy]

I tried all 18 combinations for the orientation quaternion. Unfortunately I had no luck with it. But later on I realized that in the Movemanager.cs by Fred that he has used

position.x = -px / 100.0f; position.y = py / 100.0f; position.z = -pz / 100.0f; orientation.Set(rx, ry, rz, rw); //I edited this for those 18 combinations

And according to cboulay's code, the positions are also interchanged.

PSMPos = FVector(-PSMPos.Z, PSMPos.X, PSMPos.Y); PSMOri = FQuat(-PSMOri.Z, PSMOri.X, PSMOri.Y, -PSMOri.W);

Why are the positions also swapped? I am finding hard to test out which axes are working or not working because I am not sure what's the XYZ rotations returned by the orientation quaternion means. How's XYZ defined on the PS Move controller? For the blinking calibration method, I am placing the PS Move on a table and pointing towards PS Eye. Is that the right way?

[cboulay]

If none of those 18 worked then my guess is you are not using my DLLs and/or you are doing additional transformations somewhere else, and/or you forgot to also negate the w axis. Of course, there might be more possibilities if something on my end was malformed to begin with.

For blinking calibration the controller doesn't have to have any specific orientation, but it should be stable and the camera should see the entire sphere.

The XYZ coordinate system for the controller's orientation is as I described above. The coordinate system for the position, when mirrored=true and when facing the camera straight on, is +X is right, +Y is up, +Z is away from the camera. This is the same coordinate system as orientation if the controller were standing on its bottom (USB port) and the trigger is facing the camera. For position, the origin is 100 cm from the camera along its principal axis.

The code for PSMPos and PSMOri you mentioned above is to transform from the psmoveapi coordinate system into the Unreal Engine coordinate system.

Note that, for all of the above discussion, I am using my own DLLs which are based on my fork of the psmoveapi. In my fork I changed many things, one of them being the default orientation axes. Most of those changes can be found in this commit. You can try undoing them and see what you get.

One more thing. Whenever you try a new transformation you should see if it's actually doing the correct orientation only the in-game object started off with the wrong local rotation. For example, if the in-game object thinks that the identity rotation is lying on its side but my code thinks it is standing straight up, then all of the manipulations you do to the controller will manipulate the game object correctly, but the game object just has an incorrect rotational offset.