Forum Discussion
Reading sensor data from Oculus, Yaw doesn't go past 90
I'm able to read data from the Rift, using the oculusplugin.dll. Pitch and Roll seem to work fine. However, I turn left and yaw goes to about -90 degrees then starts to raise. I turn right, it increases to 90 degrees, then past that point starts to decrease. Any ideas what I am missing? Right now I am just calling GetOrientation(int sensor, Quat q) every tick.
EDIT: I just noticed that the Pitch seems to "flip" when the Yaw crosses -90 or 90.
Event bool GetOrientation(int sensor, Quat q)
{
local float w, x, y, z;
if (OVR_GetSensorOrientation(0, w, x, y, z) == true)
{
q.w = w;
q.x = x;
q.y = y;
q.z = z;
CurHMDOrientation=OrientSensor(q);
return true;
}
return false;
}
EDIT: I just noticed that the Pitch seems to "flip" when the Yaw crosses -90 or 90.
7 Replies
- In this case w/x/y/z are quaternion coordinates, not Euler angle yaw/pitch/roll.
Here is an example and discussion (which contains a minor variation of your code snippet):
http://gmc.yoyogames.com/index.php?showtopic=591049
Notice that 'q' is defined as a quaternion, which requires conversion to Euler angles to get roll/pitch/yaw. Your example does not do that. - Well, between that and when I log out the data, I use a function that converts into a euler angle based rotator. (I can't log the value of quats for some reason). I've noticed that it is reading yaw as pitch, pitch as negative roll, and roll as negative yaw. I believe this is because the quat I am getting from the .dll is not using the same coordinate system. Then, as a result of the conversion, the yaw issue arises, so I can't just move and flip values post conversion. I need to reorganize the quat before conversion to angles. Do you know how I should go about rearranging the quat? I've been Googling for a few hours with nothing to show for it.
I'm not sure what the oculus system is, but mine is x=forward, y=right, z=up.
Edit: Oculus is Y=up, x=right, and z= backwards. Now how to change one to the other.....
So OX=Y, OY=Z and OZ=-X. How to quatify that..... - Somebody on stack overflow helped me. It was as simple as swapping components and flipping signs all along. I feel rather silly now :P
- Could you post the Link to your Stackoverflow Question please?
- Although counter-intuitive, this is actually not a bug but the way it was designed.
If you attach an object to the orientation, you will see it appears fine, even if the angles are flipping around sometimes. "BlackFang" wrote:
http://stackoverflow.com/questions/18818102/convert-quaternion-representing-rotation-from-one-coordinate-system-to-another
I ran into this issue with converting the OVR quaternion into the GLM representation. I actually found it most intuitive to just go through Euler angles, especially since the OVR template code for fetching the angles lets you explicitly specify the axes, rotation direction and handedness:
// Fetch the pitch roll and yaw out of the sensorFusion device
glm::vec3 eulerAngles;
sensorFusion.GetOrientation().GetEulerAngles<
OVR::Axis_X, OVR::Axis_Y, OVR::Axis_Z,
OVR::Rotate_CW, OVR::Handed_R
>(&eulerAngles.x, &eulerAngles.y, &eulerAngles.z);
// Now convert it into a GLM quaternion.
glm::quat orientation = glm::quat(eulerAngles);
Just remember, the enemy's gate is 'down'.
