Android get normalized acceleration

问题:

I wish to get the acceleration vector of an Android phone. The problem is, the accelerometer coordinates are relative to the phone's rotation. What I want is the "absolute" acceleration, i.e., it should return the same values whichever way the phone is facing. (I want to detect if a user that is skiing is sliding down a slope without using GPS. I also need to be able to differentiate sliding and going up the chairlift.)

I can probably get those values by combining the accelerometer with the gyroscope, but I have no idea how I could offset the accelerometer's values with the gyroscope's.

Is this possible, and if so, how?

回答1:

What you describe can't be done, unless you redefine the problem a bit. To help you redefine it, I'll outline the main issues:

First, I'm guessing that what you mean by "absolute acceleration" is acceleration with respect to geographical reference. The can't be done with the accelerometer alone, since it has no idea about geographical references. If you move far enough for the gps, or use the compass, you might be able to get around this, but each of these has its own issues (though at least the problem is soluble).

The second issue is that gravity and acceleration are completely indistinguishable using an accelerometer alone (this is known as the "equivalence principle"). Therefore, any measured acceleration will always be the vector sum of gravity and the acceleration, but there are always multiple solutions to these equations, and in the usual cases where the acceleration is smaller than gravity, you really can't determine anything about the acceleration. Since gravity is somewhat constant though, there are ways around this too, using, say, a gyroscope, or maybe your user could hold the phone in a fixed orientation (e.g., by looking at external cues like the horizon), and either of these approaches might let you subtract the influence of gravity, but it's generally a non-trivial problem.

The final point to not is that you seem to be thinking in an earth-fixed coordinate system and the phone's accelerometer is only phone-fixed. That is the accelerometer's z-axis many not have anything to do with up and down on the earth -- and the relationship will depend on the orientation of the phone. Really, many people would prefer an earth-fixed system, but the phone just doesn't know that. You can use external cues (GPS, magnetic field, gyroscope, gravity, horizon, etc) to try to align them, but given only a single arbitrary reading form the accelerometer, the information just isn't there.

Definitions:
acceleration vector: this is the x, y, z reading from the accelerometer (and each reading will depend on the phones orientation), sometimes written as A=(a_x, a_y, a_z).
acceleration magnitude: this is a=sqrt(a_x² + a_y² + a_z²), and this should not depend on the phones orientation (if the different axes are calibrated to be the same). If the phone is stationary, this will basically just be a reading of gravity. Note also that a lot of the information in the acceleration vector is lost using this measure.
normalized acceleration: The acceleration direction, that has magniture 1, i.e., A/a
acceleration in earth coordinates: I think this is what you really want, there's just no easy way to get it, and really even if you could, I don't think it would be as useful as it might seem at first.

Skiing:
I think you have a good shot at determining when someone is skiing based on the measurements from the accelerometer. Things like bumps and turns should all be quite distinctive using the accelerometer. For these I'd use the full acceleration vector. For example, in turns, the acceleration magnitude would stay roughly constant and the direction would sweep. Also note that free-fall (i.e., basically whenever the skier doesn't have their skies/feet/butt/etc on the ground, whether they're going upward when launching off a bump/jump, or falling out of the chairlift), the acceleration magnitude will be zero in free-fall. For the chairlift, it seems that it will likely have a distinctive rhythmic sway mostly within a single plane.

All of these things could be figured out. I'd recommend, if you really want to solve this problem, is to record data from your accelerometer while skiing, and see if you can determine when you're skiing based on the characteristics of the data. (My guess is, that your major stumbling block with this will be math, because it might be a bit tricky to come up with an algorithm the can distinguish the signatures of skiing, so it seems that it would be a good idea to review vector math, and things like dot-products and cross-products, and also, I suspect that a little bit on another topic known as FFTs or Fourier transforms might be useful in sorting out the time and frequency signatures of skiing vs swinging in the chair lift.)

You could also fold in GPS measurements, which wouldn't be as reliable, or give good time resolution, but could at least be used to double-check your algorithm.

回答2:

You can calculate acceleration regardless of the phone's orientation using:

a = sqrt(x*x + y*y + z*z)

Where a is the absolute acceleration and x, y and z are accelerometer values for each of the phone's 3 axes.

回答3:

Some phones have a barometer (air pressure sensor) built in. After applying a moving average, I have found it to be write ready to determine if the user is going up or down -perhaps useful for your problem. On the galaxy s4 and 5 I get a resolution good enough to determine whether the device just moved from the table, to the floor.

Note, gradual changes in weather will affect your readings, so you must consider the Delta over a reasonable time interval, and ignore changes around some threshold.

回答4:

Consider using the GPS. In a flight logging app I use the acceleration (albeit the absolute value, not the vector) to filter noisy GPS data (I remove locations where the acceleration needed for the change in speed is not plausible):

/**
 * Remove noise from the measurement of the location.
 * @param loc a location
 * @return Answer <code>false</code> iff the location should not be used.
 */
private boolean filterNoise(final Location loc) {
    if( ! loc.hasSpeed() )
        return true;
    if( this.recentSpeeds.isEmpty() ) {  // rescentSpeeds is a queue of locations
        this.recentSpeeds.add(loc);
        return true;
    }
    final Location lastFix = this.recentSpeeds.getHead();
    final long delta_t = (loc.getTime() - lastFix.getTime()) / 1000;
    if( delta_t == 0 )
        return false;
    final float delta_v = loc.getSpeed() - lastFix.getSpeed();
    final float a = delta_v / delta_t;
    if( Math.abs(a) <= AccelThreshold ) {
        this.recentSpeeds.add(loc);
        return true;
    }
    return false;
}

If you compute the speed using the coordinates from the last fix and the current fix you get the acceleration as vector.