calculating gravity relative to an angle?

So I’m working on a personal project, and Android air-mouse app. However this is a math question, not a programming question.

What I need to do is get the phone’s acceleration along the x,y,z axis separately. If it’s not accelerating along an axis I need 0 (or as close as I can get when accounting for noise). I have a 3 axis accelerometer reporting acceleration in meters/second, and orientation data along each axis in radians to work with.

For example if I accelerate the phone up at 4m/s I’d like to get the result of 4m/s on the z axis, but x, and y are 0. If I accelerate the phone up at 2 m/s, and to the right at 2 m/s I’d like to get the result x,z =2, and y = 0. Simple, but here’s where it ties my head in knots, AKA the math part.
Gravity is constantly accelerating my phone, and since I can’t make gravity stop that crap, I need to correct for it to get true acceleration relative to the ground. This means that my phone on it’s back. at rest, has an acceleration of z=9.8m/s, x,y = 0. If I tilt it .5 radians on the y axis, while still at rest, it reports something like 4.5 m/s on the y axis, and 8.1 m/s on the z axis.
I’m thinking if I can use the orientation to calculate what gravity should be on each axis then I can subtract it from the accelerometer readings to get true acceleration.

My first question is am I approaching this problem from the right angle:)? Is there a simpler approach to this? I’m thinking probably no.

My second, and third questions are if I’m on the right track then I’m thinking I could simplify the problem to that of a bike rolling down a hill, is this correct? If so The steeper the hill the faster it goes, but was is the math for putting numbers on “faster”? In other words how do I calculate gravitational acceleration down an incline?

[QUOTE=My second, and third questions are if I’m on the right track then I’m thinking I could simplify the problem to that of a bike rolling down a hill, is this correct? If so The steeper the hill the faster it goes, but was is the math for putting numbers on “faster”? In other words how do I calculate gravitational acceleration down an incline?[/QUOTE]

Simple triganometry my dear Dr. Watson. The bicycle is accelerated by
g*Sine(alpha) where alpha is the angle of inclination.

When you are angled relative to some agency that is acting along some axis, the effect that it has along your axis is weaker, and the factor is the cosine of the angle between the axes. If the agency’s action is orthagonal to some axis, and you aligned your axis with its axis, you’d feel no effect, but if your axis is misaligned, the effect you feel contains a factor of the sine of the angle.

In my view, this is a more basic and comprehensible beginning to the subject of trigonometry than the traditional one.

We think about trigonometry by starting with triangular geometrical constructions, but that is only because the Nile floods seasonally and erases many of the landmarks showing property lines in its fertile and valuable floodplanes. For thousands of years, ropelayers have reconstructed the property lines for farmers and landowners. The methods they developed in this trade spawned geometry as a subject.

If people had paid more attention to the art of standing up, your question would be where we would start trigonometry, and I bet triangles would be as obscure as heptagons.

Acceleration is m/s[sup]2[/sup]. What does the developer’s guide for the phone say?

I am probably not the right guy to answer all your questions but I am curious about one thing.

How do you get orientation of the phone? It seems to be that the only way the phone knows its orientation is to determine which way is it being pulled at 9.8m/s[sup]2[/sup], which creates circular reasoning for being able to subtract out the effect of gravity from other acceleration data.

For example, if your phone is experiencing an acceleration of g along the x-axis and also g along the z-axis, how can you tell whether it’s orientation is the x-axis vertical and the phone is accelerating along the z-axis at 9.8m/s[sup]2[/sup], or the other way around?

Thanks yo! It seems to be working on the y axis, for the most part. I’ve got acceleration detection accuracy on the y axis with an error range of ± .4 m/s, and that’s without using any code to calibrate the accelerometer values, so it can only get better! I’m getting closer.
However the x, and z axises are giving me all sorts of weirdness still. I’m thinking I’m using the wrong approach there.

The math I’m using on all three is:

acceleration reading - gravitational constant * sin(angle) = true acceleration.

Trying to figure out why x and z would be different. the y angle is taken relative to the magnetic north pole. The phone uses it’s 3axis compass to get that reading. Thinking it’s messing me up.

Per CookingWithGas’s question it says in the [, float)"]documentation for the orientation](SensorManager  |  Android Developers data:

and for acceleration events:

Definition of the coordinate system used by the SensorEvent API

I’m thinking what that’s telling me is acceleration x, and z doesn’t line up with orientation x, and z unless I hold the phone a very specific way, so if I need to go back to the drawing board.

So I think I’m getting close. I think I just need one last follow up question. what’s the formula for what incline produces a specific acceleration?

Digging around I found this math which is supposed to calculate the tilt value from an accelerometer axis. I don’t pretend to currently understand it, though I’d like to someday. Anyway:

x, y, and z are their respective accelerations along their axises in meters\second.

divide the negative of each of these axises by gravitational acceleration(g), so

nextX = -x\g
nextY = -y\g
nextZ = -z\g

Then take the square root of (x squared plus y squared plus z squared), so

So j = sqrt(x²y²z²)

Then divide x, y, and z by j and take the arc-sine of this for some reason, so

anotherX = arc-sin(newX \ j)
anotherY = arc-sin(newY \ j)
anotherZ = arc-sin(newZ \ j)
Then I take the sin of this
finalX= sin(anotherX)
finalY= sin(anotherY)
finalZ= sin(anotherZ)

I must get something pretty close to the opposite angle because I input them into the gravitational acceleration down an incline formula because the function for computing gravitational acceleration down on incline works to produce the opposite value.

For example if the phone is at rest: x + G * sin(finalX) ~ 0, on most inclines

However it still seems to have some weirdness. The place I read the code said the arc-sin step produced incline based on acceleration, but I need values in rads. So I guess what I’m asking is what’s the formula for what incline produces a specific acceleration?

I think if I had that I could smooth out the last of the weirdness.

I think what you’re looking for is a conversion between spherical coordinates and cartesian coordinates, which is at the bottom of this page. Of course r would actually represent acceleration instead of distance.

Assuming you mean 9.8 m/s[sup]2[/sup].

Regardless, acceleration occuring at rest just doesn’t compute.

What am I missing here ?

I think you’re so confused because you think that gravity is accelerating your phone at all times. It’s not*. My phone is at rest right now because the table is exerting a counteracting normal force. There’s no need to subtract gravity from your equation if the phone is on a desk, in your pocket, or in your hand. I say scrap your gravity idea entirely. It’s no more relevant than your hand’s force on the phone.

Are you sure you don’t want to be dealing with velocities, the first derivative of the position function, isntead acceleration, the second derivative? Because you keep saying, for example, that the phone accelerates at 4 m/s. That makes no sense.

Back off, pedants. You know what I mean.