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?
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=(ax, ay, az).
acceleration magnitude: this is a=sqrt(ax2 + ay2 + az2), 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.
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.
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.
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.
Related
gravity is an array of 3 floats containing the gravity vector expressed in the device's coordinate. You can simply use the values returned by a SensorEvent of a Sensor of type TYPE_ACCELEROMETER. This is noted in SensorManager.getRotationMatrix, but I want to know why not use values of TYPE_GRAVITY ? I think it will be better than using TYPE_ACCELEROMETER.because ACCELEROMETER = GRAVIDY - LINEAR_ACCELEROMETER, ACCELEROMETER won't point to the earth when moving.
The three sensors Sensor.TYPE_ACCELEROMETER, Sensor.TYPE_GRAVITY and Sensor.TYPE_LINEAR_ACCELERATION are related by the equation
"Sensor.TYPE_ACCELEROMETER" = "Sensor.TYPE_GRAVITY" + "Sensor.TYPE_LINEAR_ACCELERATION"
If you register for updates for all three, what you find is that Sensor.TYPE_ACCELEROMETER always arrives first, followed by Sensor.TYPE_GRAVITY and Sensor.TYPE_LINEAR_ACCELERATION, and that the values always satisfy that equation. Internally, Android is using filtering, and in particular a Kalman filter, to separate the two.
A low pass filter is a simple way of doing something similar. However, a lot of thought will have gone into the Android mechanism, so I'm sure that if a low pass filter was better, then Android would have implemented that.
I have a 3-D acceleration vector (a, b, c) obtained from an Android phone accelerometer.
I wish to calculate the angle between this vector (a, b, c) and the gravity vector, which points exactly downwards.
I notice that in Android, there is a way of getting gravity vector under the context of the phone coordinate system instead of the world coordinate system. By simply use sensor type SENSOR_TYPE_GRAVITY, I can get the 3-D gravity vector (d, e, f). Since both vectors are under the same coordinate system, the phone coordinate system. By simple vector inner product, their angle can be easily found.
After finding this angle, even if we move from the phone coordinate system to the real world coordinate system, the angle remains unchanged.
My question:
What is the working mechanism behind the SENSOR_TYPE_GRAVITY?
I don't think there is another hardware that measures the gravity. Thus, it is just the acclerometer who measures the gravity. How is the gravity extracted our of the resultant accleration?
I am asking because I am concerned with the accuracy of this way of getting the gravity.
If it is inaccurate, I can implement a LPF to filter the DC component, the gravity, out by myself. I am not sure whether getting it from SENSOR_TYPE_GRAVITY is more accurate than I do it myself.
================================== UPDATES =======================================
Just to clarify, can I get the BOTH acceleration and gravity data correctly with the following codes?
By correctly, I mean do the acceleration and the gravity belong to one same particular time instant? I need to use the values at ONE time instant. So the situation where the acceleration is for time=13:12:00 and the gravity is for a later time, say time=13:12:01 is NOT desired.
public void onSensorChanged(SensorEvent event) {
if (event.sensor.getType() == Sensor.TYPE_ACCELEROMETER) {
acceleration[0] = event.values[0];
acceleration[1] = event.values[1];
acceleration[2] = event.values[2];
}
if (event.sensor.getType() == Sensor.TYPE_GRAVITY) {
gravity[0] = event.values[0];
gravity[1] = event.values[1];
gravity[2] = event.values[2];
}
}
The three sensors Sensor.TYPE_ACCELEROMETER, Sensor.TYPE_GRAVITY and Sensor.TYPE_LINEAR_ACCELERATION are related by the equation
"Sensor.TYPE_ACCELEROMETER" = "Sensor.TYPE_GRAVITY" + "Sensor.TYPE_LINEAR_ACCELERATION"
If you register for updates for all three, what you find is that Sensor.TYPE_ACCELEROMETER always arrives first, followed by Sensor.TYPE_GRAVITY and Sensor.TYPE_LINEAR_ACCELERATION, and that the values always satisfy that equation. Internally, Android is using filtering, and in particular a Kalman filter, to separate the two.
A low pass filter is a simple way of doing something similar. However, a lot of thought will have gone into the Android mechanism, so I'm sure that if a low pass filter was better, then Android would have implemented that.
I am making a compass for android and I have it working but it has one flaw. The reading on the compass is consistently changing by a couple of degrees even when the device is not moving. I know that this is due to the magnetic distortion messing with sensor but how can I make my app still responsive while the user moves yet not have so much variation displayed when the user is still. So how can I give the appearance of a more steady compass?
You have to smooth the signal. How about displaying the average of the last N values instead of displaying the raw last value ?
Have you tried implementing a low pass filter? http://blog.thomnichols.org/2011/08/smoothing-sensor-data-with-a-low-pass-filter
If you want to write a compass, you'll need to low-pass filter both acceleration and magnetic field.
Here's an example of a low-pass filter. Not very elegant, but just to show the principle:
float filteredValue;
void lowPassFilter(float rawValue) {
final float alpha = 0.8f;
float filteredValue = alpha * filteredValue + (1.0f - alpha) * rawValue;
return filteredValue;
}
Note that filteredValue is remembered after each call (like a member variable).
On the other hand, rawValue is the value from the sensor event, like event.values[0].
Notice how every 'fresh' new rawValue only affects 20% of the filtered value (that's given by alpha). This brings 'stability' to the reading, at the cost of a delay.
I am working on accelerometer from an android phone. I wish to filter the horrible noise the accelerometer is returning recording the phone's moves.
I was reading around on Kalman filter, because low pass are just not enough.
But I don't have a model of the transition from ACCELERATION(k-1) to ACCELERATION(k) because it is the movements of the user. So I have no state transition matrix (H or F in different papers, the one that multiply Xk-1 in the equation Xk = HXk-1 + Bcommand+noise)
I saw some people taking the identity matrix in simple examples. How can it work for dynamic acceleration?
I know Kalman Filters, people always produce some H matrix, I just don't know how in my case.
Kalman Filter is often thought of as a linear filter where you have all model matrices but the idea of filter and its first applications come from non-linear models. In that case you use functions instead of matrices.
If the functions for prediction and update are highly non-linear you can use statistical methods to estimate your parameters on-line. The first look what you can take is unscented kalman filter which recovers mean and covariance from deterministic sampling technique - unscented transformation. I think in your case this could be the best to start with.
There are other variants of Kalman Filter. You can start from wikipedia but if you google "adaptive kalman filter" you can see the variety of the subject.
If you want to get deeper into the subject but not necessary start with all maths I recommend very good book: Kalman Filter for Beginners to start with by Phil Kim . There are also other possibility as sensor fusion, but it is another broad subject.
You can use the identity matrix.
The state transition matrix is used to predict the future state based on current state, in the absence of any new measurements. In your case, as you say, you do not have any way of predicting future state (acceleration) - so your best guess is that future state (acceleration) is the same as current state. This is exactly what identity matrix does.
In many Kalman filters, there is some way of predicting the future state based on current state, and that's where a non-identity state transition matrix would step in. For example, suppose your Kalman filter estimates vehicle position and speed based on GPS and speedometer; then you could predict future position by changing position based on speed, even without new measurements. Dave's answer shows how to do it using state transition matrix.
Given a state vector [x, v_x, a_x], i.e. the position, speed and acceleration
of the object in one direction (the same logic applies for the other two degrees of freedom).
You usually define the state transition matrix as
1 dt 0.5*dt*dt
0 1 dt
0 0 1
If you write this out you get:
xnew = x+v_x*dt + 0.5*a_x*dt*dt
vnew = v_x + a_x*dt
anew = a_x
These are the equations of motion for an object moving with a constant acceleration.
The way that the unknown user caused motions are handled in the Kalman framework is through the plant noise term. You assume that, instead of continuing on with the exact same acceleration, there are unknown random perturbations to acceleration (and thus to the other components of the state).
The thing with kalman filter is that it does prediction and then corrects your prediction based on your observation. If your model is not very dynamic although your model assumes constant position but based on your observation you will get something in between.So Identity could work.
I am trying to filter out the noise from the orientation/compass sensor in my magic phone.
Some of the readings seem to be 90-180 degrees off and there is a lot of jiggle. I have tried different things with limited success, so I was wondering if anyone could recommend an algorithm to filter this sort of noise to get a stable output.
BR, Mads
You need Low Pass Filter. There are explanation and simple algorithm on wikipedia
This is really late but it might help people like me who came to this question.
Use Type Rotation vector sensor. No need to use a low pass filter or calculate an average value of the last x sensor values.
Here's some code:
private float[] mMatrixR = new float[9];
private float[] mMatrixValues = new float[3];
#Override
public void onSensorChanged(SensorEvent event) {
switch (event.sensor.getType()) {
case Sensor.TYPE_ROTATION_VECTOR:
// Get rotation matrix
SensorManager.getRotationMatrixFromVector(mMatrixR, event.values);
SensorManager.getOrientation(mMatrixR, mMatrixValues);
// Use this value in degrees
mAzimuth = Math.toDegrees(mMatrixValues[0]);
}
I found the values very fast and smooth and use these in my app. I used accelerometer and magnetometer as a backup in case rotation type vector isn't present in the device, it's a software based sensor (Sensor fusion) which uses the magnetometer, accelerometer and gyro (if present).
I got rid of most of the noise by just using a slower update time. I'm not sure if Android has a built-in filter for these, but it seems to stabalize a lot. Something like:
mSensorManager.registerListener(
mSensorListener,
mSensorManager.getDefaultSensor(Sensor.TYPE_ORIENTATION),
// SENSOR_DELAY_UI, instead of SENDOR_DELAY_FASTEST (or similar)
// seems to iron out a lot of the jitter
SensorManager.SENSOR_DELAY_UI
);
SensorManager offers:
SENSOR_DELAY_FASTEST : get sensor data as fast as possible
SENSOR_DELAY_GAME : rate suitable for games
SENSOR_DELAY_NORMAL : rate (default) suitable for screen orientation changes
SENSOR_DELAY_UI : rate suitable for the user interface
What have you tried? How many readings do you get per second?
I would suggest something along the lines of an average of the last X number of readings to get rid of the "jiggles" and throw away any readings that are wildly different from the current direction to stop any crazy "jumping" of values.
Depending on how many readings you are getting, and how much averaging you are doing, your app may lose responsiveness.
The following link might be useful.
http://www.chem.uoa.gr/applets/appletsmooth/appl_smooth2.html
If you do get a significant number of completely-wrong values, you probably don't want to just average them. You could try applying a median filter first - take N samples, calculate the median, and throw out anything more than +- some threshold value. You can apply a smoothing filter after that.
If your readings are "90-180 degrees off", then either you need to calibrate your compass, or your sensor is faulty.
Certainly, the magnetic sensor has a lot of jiggle, but the "standard deviation" of such noise is about 4 degrees off. You can choose a variety of mathematical filters (low pass, Kalman) and algorithms (averaging, drop spurious readings) to apply to the measurements that can give you acceptable results.
Are you using:
List<Sensor> sens = mySensorManager.getSensorList(Sensor.TYPE_ORIENTATION);
You might be registering 2 separate sensor handles which are both being directed to your onSensorChanged method. Now, on my onSensorChanged method, I'm sending the bearing value to either the primary or secondary method based on the Vendor name. So try this code out:
Sensor sen = e.sensor;
double bearing = 0;
if (sen.getType()==Sensor.TYPE_ORIENTATION) {
bearing = e.values[SensorManager.DATA_X];
}
if (sen.getVendor().equals(sensorVendors[0])) {
myCompassView.setBearing(bearing);
} else {
myCompassView.setSecondaryBearing(bearing);
}