Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Android TYPE_LINEAR_ACCELERATION sensor - what does it show?

I am developing application for car acceleration tracking. I used standard accelerometer, calibrating it in specific position beforehand.

Then, assuming phone's orientation is not changing, I logged the accelerometer data for a specified time and calculated move parameters, one of which is the car's speed at the end of the test.

It works rather well, on a straight, horizontal road: error of a few percent.

But then I found out, that in API-level 10 there is a virtual sensor called TYPE_LINEAR_ACCELERATION and, as far as I understand, it must do what I need: filter gravity, orientation changes - so I may use it and get pure linear acceleration of mobile device.

BUT in real life..

I made a simple application, that does a little test:

//public class Accelerometer implements SensorEventListener { ...
public void onSensorChanged(SensorEvent se) 
{
    if(!active)
        return;

    lastX = se.values[SensorManager.DATA_X];
    lastY = se.values[SensorManager.DATA_Y];
    lastZ = se.values[SensorManager.DATA_Z];
    long now = System.currentTimeMillis();
    interval = now - lastEvetn;
    lastEvetn = now;
    out.write(Float.toString(lastX) + ";" + 
                    Float.toString(lastY) + ";" + 
                    Float.toString(lastZ) + ";" + 
                    Long.toString(interval) + "\n");
}

I bind a listener with the following parameters:

  mSensorManager.registerListener(linAcc,
                mSensorManager.getDefaultSensor(Sensor.TYPE_LINEAR_ACCELERATION),
                SensorManager.SENSOR_DELAY_GAME);

It works OK, but when I analyzed data dump, calculating speed like V = V0 + AT, where V0 = 0 at first, then - speed of interval before this, A = acceleration (SQRT (x*x+y*y+z*z)) (t = time of interval), eventually I get a very low speed - three times less than real speed.

Changing Sensor type to TYPE_ACCELEROMETER, calibrating and using same formula to calculate speed - I get good results, much closer to reality.

So, the question is:

What does Sensor.TYPE_LINEAR_ACCELERATION really show?

Where am I wrong, or is something wrong with Sensor.TYPE_LINEAR_ACCELERATION implementation?

I used Samsung Nexus S phone.

like image 662
Maep Avatar asked Oct 22 '11 10:10

Maep


People also ask

What does accelerometer sensor detect in an app?

Measures the acceleration force in m/s2 that is applied to a device on all three physical axes (x, y, and z), excluding the force of gravity. Monitoring acceleration along a single axis.

What do sensors do on Android?

Android sensors give applications access to a mobile device's underlying physical sensors. They are data-providing virtual devices defined by sensors.

How accurate is the Android accelerometer?

The accelerometers read around -0.8 ms^-2 on both X and Y axes when stationary, so I used this as my offset.

What is accelerometer sensor Android?

The accelerometer is an in-built comment of a smartphone to measure its acceleration. It tracks the different motion like shaking, tilting, swinging, and rotating and accordingly change the orientation of your app. To calculate and detect the motion, the accelerometer uses the value of XYZ.


5 Answers

Very interesting question!!!!

I'm developing somethig similar to your application. What i found about TYPE_LINEAR_ACCELERATION isn't happy for me.

1) TYPE_LINEAR_ACCELERATION, TYPE_GRAVITY, ecc are implemented only for Android 2.3 (and up) So i have Android 2.2 and i can't test them.

2) TYPE_LINEAR_ACCELERATION isn't so accurate as it would be, because there are some simple problem when substract the gravity. In fact is a "sensor fusion" that uses accelerometer and orientation to know where is directed the gravity and then subs. it.

Here i found a very usefull answer that explain it:

https://groups.google.com/forum/#!topic/android-developers/GOm9yhTFZaM

TYPE_ACCELEROMETER uses the accelerometer and only the accelerometer. It returns raw accelerometer events, with minimal or no processing at all.

TYPE_GYROSCOPE (if present) uses the gyroscope and only the gyroscope. Like above, it returns raw events (angular speed un rad/s) with no processing at all (no offset / scale compensation).

TYPE_ORIENTATION is deprecated. It returns the orientation as yaw/ pitch/roll in degres. It's not very well defined and can only be relied upon when the device has no "roll". This sensor uses a combination of the accelerometer and the magnetometer. Marginally better results can be obtained using SensorManager's helpers. This sensor is heavily "processed".

TYPE_LINEAR_ACCELERATION, TYPE_GRAVITY, TYPE_ROTATION_VECTOR are "fused" sensors which return respectively the linear acceleration, gravity and rotation vector (a quaternion). It is not defined how these are implemented. On some devices they are implemented in h/w, on some devices they use the accelerometer + the magnetometer, on some other devices they use the gyro.

On Nexus S and Xoom, the gyroscope is currently NOT used. They behave as if there was no gyro available, like on Nexus One or Droid. We are planing to improve this situation in a future release.

Currently, the only way to take advantage of the gyro is to use TYPE_GYROSCOPE and integrate the output by hand.

I hope this helps,

Mathias

Anyway, in various place on the web i found no best word about phone sensor and their potential, due to the fact that aren't accurate...

Some more precision can be reached using Kalman filter, but i have no idea how...

like image 59
Lork Avatar answered Oct 03 '22 00:10

Lork


I realize my answer is pretty late. I bumped into this thread while hunting for some info on TYPE_LINEAR_ACCELERATION.

It is not right to do a = sqrt(ax^2+ay^2+az^2) and then do v=u+at. That will work only when v and a are in the exact same direction. And any deviation would make the errors add up. Acceleration and velocity are vector quantities, and should be treated as such. You should do vx=ux+axt, vy=uy+ayt and vz=uz+azt. and then v= sqrt(vx^2+vy^2+vz^2).

like image 25
sudP Avatar answered Oct 03 '22 00:10

sudP


TYPE_LINEAR_ACCELERATION doesn't show the "raw" data from the sensor, it shows data that was processed by hi-frequency filter, so the constant acceleration like gravity or any other slowly changing acceleration cannot pass through the filter.

Your car has pretty constant acceleration that cannot pass the filter. If you change your acceleration very fast pressing the brakes then pressing the accelerometer pedal then back to the brakes then TYPE_LINEAR_ACCELERATION would show the pretty correct result, otherwise it always shows less then the real acceleration value.

Use TYPE_ACCELEROMETER and then remove G (9.81) manually. Actually, you have to measure G yourself when the real acceleration is 0 and then use TYPE_ACCELEROMETER value as G. In my case it is 9.6.

TYPE_ACCELEROMETER is good for the fast changing acceleration that lasts less then 1 second like moving you hand emulating a box or sword fighting.

like image 31
Dmitry Avatar answered Oct 03 '22 01:10

Dmitry


TYPE_LINEAR_ACCELERATION is a three dimensional vector indicating acceleration along each device axis, not including gravity. TYPE_ACCELEROMETER = TYPE_GRAVITY + TYPE_LINEAR_ACCELERATION

like image 40
Evgeny Karpov Avatar answered Oct 03 '22 02:10

Evgeny Karpov


As @thxmxx says, the TYPE_LINEAR_ACCELERATION vector is given in the device coordinate frame. Therefore, to estimate velocity in the inertial (world) coordinate frame, you need to rotate by the estimated device orientation before integrating.

However, even if you do that, it's unlikely that the estimated velocity will be accurate for long. Suppose your acceleration estimate is consistently off by 0.1 m/s^2 in the device x-axis. This is around 1/100 the acceleration of gravity - it's a small error relative to the magnitude of accelerations the device is meant to measure. Then, after sitting still for ten seconds, your velocity estimate will be 1 m/s in the device x-axis.

Even small errors add up to form big ones. If you further integrate your velocity estimate to form a position estimate, errors will compound even faster.

To get a reliable velocity estimate, you need either:

  • A sensor that measures speed, like a pitot/static system on an aircraft or a wheel odometer on a car.
  • A sensor that measures position, like GPS, LIDAR, or vision-based SLAM, and a sensor fusion algorithm that uses the sequence of position estimates over time to correct drift in the velocity estimate.
  • An extremely accurate IMU like the type used in missiles.

The second option is the most useful for phone-based applications.

like image 42
japreiss Avatar answered Oct 03 '22 02:10

japreiss