How do I account for gravity using a wiimote's accelerometer?

Question

For a project my team and I have been trying to track a wiimote in a 3D space using the built in accelerometer and the WiiMotion Plus gyroscope.

We’ve been able to track the rotation and position using an ODE (Found at http://www.alglib.net/,) but we’ve run into a problem with removing the gravity component from the accelerometer.

We looked at Accelerometer gravity components which had the formula (implemented in C# / XNA)

    private Vector3 RemoveGravityFactor(Vector3 accel)
    {
        float g = -1f;
        float pitchAngle = (Rotation.Z);
        float rollAngle = (Rotation.Y);
        float yawAngle = (Rotation.X);

        float x = (float)(g * Math.Sin(pitchAngle));
        float y = (float)(-g * Math.Cos(pitchAngle) * Math.Sin(rollAngle));
        float z = (float)(-g * Math.Cos(pitchAngle) * Math.Cos(rollAngle));

        Vector3 offset = new Vector3(x, y, z);

        accel = accel - offset;
        return accel;
    }

But it doesn’t work at all. As a reference, the acceleration is straight from the accelerometer, and the rotation is measured in radians after it has been worked through the ODE.

Also, We are having problems with understanding how this formula works. Due to the fact that our tracking is taking into account all dimensions, why is Yaw not taken into account?

Thanks in advance for any advice or help that is offered.

EDIT:

After discussing it with my teammates and boss, we've come to find that this formula would actually work if we were using X, Y, and Z correctly. We've come to another stump though.

The problem that we're having is that the Wiimote library that we're using returns relative rotational values based on the gyroscope movement. In otherwords, if the buttons are facing up, rotating the wiimote left and right is yaw and if the buttons are facing toward you, yaw is the same when it SHOULD be the rotation of the entire wiimote.

We've found that Euler angles may be our answer, but we're unsure how to use them appropriately. If there is any input on this new development or any other suggestions please give them.

Farquhar

Answer 1

I'd bet that your accelerometer was not calibrated in zero gravity, so removing the effect of gravity will be difficult, at the very least.

Hagiography

Does that mean the remote fails when you turn it upside down? – Comus

it doesn't need to be calibrated in zero gravity. gravity is 1g down and very predicable. it's not like you can't compensate for it. – Impresario

@dan_waterworth: yes, gravity is very predictable; and yes, you can compensate for it. That's different from "removing the gravity effect from the accelerometer". Compensation won't remove the effect; it will compensate for it, but there's a different level of accuracy involved between removal and compensation. – Hagiography

You can also calibrate each axis in a plane perpendicular to gravity. – Impresario

@dan_waterworth: actually, multiple calibrations bring in their own set of problems. Devices aren't ideal; measurements (and calibrations) have their ranges of errors and tolerances. The problem becomes that calibrating in (let's say) 3 axes perpendicular to gravity will give you three different sets of measurements; those will differ; how much is the difference due to measurement error, and how much is due to individual axis calibration? With ideal devices, your suggestions are good; it's just that the question was not about ideal devices. – Hagiography

Answer 2

First I'd suggest not using individual components to store the rotation (gimbal lock), a matrix would work better. calibrate by holding it still and measuring (it will be 1g downward). then for each rotation, multiple the rotation matrix by it. then you can tell which way is up and subtract a matrix of 1g down from the vector representing the acceleration. I know that doesn't make a lot of sense but I'm in a bit of a rush, add comments if you have questions.

Impresario

I'm not sure what you're refering to when you say "multiple the rotation matrix by 'it'." However, we're using a Quaternion (which can be transformed into a rotational matrix if needed,) but we're unsure of how to capture gravity correctly. We could do this if we didn't take into account periods when gravity is on two axis (the wiimote rolls 45 degrees, gravity is on z and x) – Farquhar

To capture gravity, keep the remote still and measure the acceleration (making sure there is no rotation). This will give you vector which is 1g in the direction of gravity (ie down). Normalise this vector and multiple it by -1. Now you have a vector that represents 'up' in relation to the wiimote. Now construct a matrix that rotates a unit Z vector to the up vector, (you'll have to choose forward). If, for every rotation, you multiple this matrix by the transpose of the rotation matrix. Then when you rotate a Z vector by the matrix, you get the vector up. – Impresario

Thank you for your input. We're currently trying to exhaust all resources using a quaternion. As far as your reply goes, we're unsure how to work with it. What do you mean by - "Construct a matrix that rotates a unit Z vector to the up vector?" – Farquhar