views:

921

answers:

4

Hi All,

I am using a WinSock connection to get the accelerometer info off and iPhone and into a Direct3D application. I have modified Apples GLGravity's sample code to get my helicopter moving in relation to gravity, however I need to "cap" the movement so the helicopter can't fly upside down! I have tried to limit the output of the accelerometer like so

if (y < -0.38f) {
  y = -0.38f;
}

Except this doesn't seem to work!? The only thing I can think of is I need to modify the custom matrix, but I can't seem to get my head around what I need to be changing. The matrix is code is below.

    _x = acceleration.x;
_y = acceleration.y;
_z = acceleration.z;

float length;
D3DXMATRIX matrix, t;

memset(matrix, '\0', sizeof(matrix));

D3DXMatrixIdentity(&matrix);

// Make sure acceleration value is big enough.
length = sqrtf(_x * _x + _y * _y + _z * _z);

if (length >= 0.1f && kInFlight == TRUE) { // We have a acceleration value good enough to work with.
 matrix._44 = 1.0f; // 

 // First matrix column is a gravity vector.
 matrix._11 = _x / length;
 matrix._12 = _y / length;
 matrix._13 = _z / length;

 // Second matrix is arbitrary vector in the plane perpendicular to the gravity vector {Gx, Gy, Gz}.
 // defined by the equation Gx * x + Gy * y + Gz * z = 0 in which we set x = 0 and y = 1.
 matrix._21 = 0.0f;
 matrix._22 = 1.0f;
 matrix._23 = -_y / _z;
 length = sqrtf(matrix._21 * matrix._21 + matrix._22 * matrix._22 + matrix._23 * matrix._23);
 matrix._21 /= length;
 matrix._22 /= length;
 matrix._23 /= length;

 // Set third matrix column as a cross product of the first two.
 matrix._31 = matrix._12 * matrix._23 - matrix._13 * matrix._22;
 matrix._32 = matrix._21 * matrix._13 - matrix._23 * matrix._11;
 matrix._33 = matrix._11 * matrix._22 - matrix._12 * matrix._21;
}

If anyone can help it would be much appreciated!

A: 

Try normalizing the acceleration vector first. (edit: after you check the length) (edit edit: I guess I need to learn how to read... how do I delete my answer?)

BananaRaffle
A: 

So if I understand this correctly, the iPhone is feeding you accelerometer data, saying how hard you're moving the iPhone in 3 axes.

I'm not familiar with that apple sample, so I don't know what its doing. However, it sounds like you're mapping acceleration directly to orientation, but I think what you want to do is doubly integrate the acceleration in order to obtain a position and look at changes in position in order to orient the helicopter. Basically, this is more of a physics problem than a Direct3D problem.

legalize
A: 

It looks like you are using the acceleration vector from the phone to define one axis of a orthogonal frame of reference. And I suppose +Y is points towards the ground so you are concerned about the case when the vector points towards the sky.

Consider the case when the iphone reports {0, -6.0, 0}. You will change this vector to {0, -.38, 0}. But they both normalize to {0, -1.0, 0}. So, the effect of clamping y at -.38 is influenced by magnitude of the other two components of the vector.

What you really want is to limit the angle of the vector to the XZ plane when Y is negative.

Say you want to limit it to be no more than 30 degrees to the XZ plane when Y is negative. First normalize the vector then:

const float limitAngle = 30.f * PI/180.f; // angle in radians
const float sinLimitAngle = sinf(limitAngle);
const float XZLimitLength = sqrtf(1-sinLimitAngle*sinLimitAngle);

if (_y < -sinLimitAngle)
{
    _y = -sinLimitAngle;
    float XZlengthScale = XZLimitLength / sqrtf(_x*_x + _z*_z);
    _x *= XZlengthScale;
    _z *= XZlengthScale;
}
You would also have to handle the case when _x and _z are zero. The simplest, though probably not best, would be to choose the vector _x = XZLimitLength, _y = -sinLimitAngle, _z = 0.
And I also agree with legalize that if you are trying to make a virtual helicopter move with as the phone does then the whole approach is wrong.
+1  A: 

I think double integration is probably over-complicating things. If I understand the problem correctly, the iPhone is giving you a vector of values from the accelerometers. Assuming the user isn't waving it around, that vector will be of roughly constant length, and pointing directly downwards with gravity.

There is one major problem with this, and that is that you can't tell when the user rotates the phone around the horizontal. Imagine you lie your phone on the table, with the bottom facing you as you're sitting in front of it; the gravity vector would be (0, -1, 0). Now rotate your phone around 90 degrees so the bottom is facing off to your left, but is still flat on the table. The gravity vector is still going to be (0, -1, 0). But you'd really want your helicopter to have turned with the phone. It's a basic limitation of the fact that the iPhone only has a 2D accelerometer, and it's extrapolating a 3D gravity vector from that.

So let's assume that you've told the user they're not allowed to rotate their phone like that, and they have to keep it with the bottom point to you. That's fine, you can still get a lot of control from that.

Next, you need to cap the input such that the helicopter never goes more than 90 degrees over on it's side. Imagine the vector that you're given as being a stick attached to your phone, and dangling with gravity. The vector you have is describing the direction of gravity, relative to the phone's flat surface. If it were (0, -1, 0) the stick is pointing directly downwards (-y). if it were (1, 0, 0), the stick is pointing to the right of the phone (+x), and implies that the phone has been twisted 90 degrees clockwise (looking away from you at the phone).

Assume in this metaphor that the stick has full rotational freedom. It can be pointing in any direction from the phone. So moving the stick around describes the surface of a sphere. But crucially, you only want the stick to be able to move around the lower half of that sphere. If the user twists the phone so that the stick would be in the upper half of the sphere, you want it to cap such that it's pointing somewhere around the equator of the sphere.

You can achieve this quite cleanly by using polar co-ordinates. 3D vectors and polar co-ordinates are interchangeable - you can convert to and from without losing any information.

Convert the vector you have (normalised of course) into a set of 3D polar co-ordinates (you should be able to find this logic on the web quite easily). This will give you an angle around the horizontal plane, and an angle for vertical plane (and a distance from the origin - for a normalised vector, this should be 1.0). If the vertical angle is positive, the vector is in the upper half of the sphere, negative it's in the lower half. Then, cap the vertical angle so that it is always zero or less (and so in the lower half of the sphere). Then you can take the horizontal and capped vertical angle, and convert it back into a vector.

This new vector, if plugged into the matrix code you already have, will give you the correct orientation, limited to the range of motion you need. It will also be stable if the user turns their phone slightly beyond the 90 degree mark - this logic will keep your directional vector as close to the user's current orientation as possible, without going beyond the limit you set.

MrCranky