CODEWITHSUNDEEP
iosopengl-esaugmented-realityeuler-angles
MikaelW
MikaelW

Reputation: 1205

iPhone augmented reality Euler angles rotation – roll issue

I’m working on an iOS augmented reality application. It is location-based, not marker-based.

I use the GPS, compass and accelerometers to get latitude, longitude, altitude and the 3 euler angles: yaw, pitch and roll. I know using NSLog() that those 6 variables contain valid data.

My application shows some 3d objects over the camera view. It works fine as long as I use everything but the roll angle.

If I add that third angle, the rotation applied to my opengl world is not good. I do it that way in the main OpenGL draw method

glRotatef(pitch, 1, 0, 0);
glRotatef(yaw, 0, 1, 0);
//glRotatef(roll, 0, 0, 1);

I think there is something wrong with this approach but am certainly not a specialist. Maybe I should create some sort of unique rotation matrix rather than 3 different ones?

Maybe that’s not possible easily? After all most desktop video games, FPS and the like, just let the user change the yaw and the pitch using the mouse, so only 2 angles, not 3. But unlike the mouse, which is a 2d device, a phone used for augmented reality can move in any angles.

But then again, all AR tutorials I have seen online couldn’t handle ‘roll’ properly. ‘Rolling’ your phone would either completely mess AR stuff up or do nothing at all, using some roll-compensation strategies.

So my question is, assuming I have my 3 Euler angles using the phone sensors, how should I apply them to my 3d opengl view?

Upvotes: 1

Views: 1118

Answers (1)

Tommy
Tommy

Reputation: 100662

I think you're likely talking about gimbal lock.

The essence of the problem is that if you rotate with Eulers then there's always a sequence to it. For example, you rotate around x, then around y, then z. But then one axis can always becomes ambiguous because a preceding can move it onto a different axis.

Suppose the rotation were 0 degrees around x, 90 degrees around y, then 20 degrees around z. So you do the x rotation and nothing has changed. You do the y rotation and everything moves 90 degrees. But now you've moved the z axis onto where the x axis was previously. So the z rotation will appear to be around x.

No matter what most people's instincts tell them, there's no way to avoid the problem. The kneejerk reaction is that you'll always rotate around the global axes rather than the local one. That doesn't resolve the problem, it just reverses the order. The z rotation could then the y rotation — which has already occurred — into an x rotation.

You're right that you should aim to create a unique description of rotation separated from measuring angles.

For augmented reality it's actually not all that difficult.

The accelerometer tells you which way down is. The compass tells you which way north is. The two may not be orthogonal though — the compass reading should vary from being exactly at a right angle to the floor on the equator to being exactly parallel to the accelerometer at the poles.

So:

  1. just accept the accelerometer vector as down;
  2. get the cross product of down and the compass vector to get your side vector — it should point along a line of longitude;
  3. then get the cross product of your side vector and your down vector to get a north vector that is suitably perpendicular.

You could equally use the dot product to remove that portion of the compass vector that is in the direction of gravity and cross product from there.

You'll want to normalise everything.

That gives you three basis vectors, so just put them directly into a matrix. No further work required.

Upvotes: 1

Related Questions