I have a question concerning accelerometer readings. I think it´s pretty basic but I don´t really have an engineering or physics background.

The situation is like this:

I´m reading the accelerometer readings from my ADXL345 on the x axis (already converted in g-values, but it doesn´t really matter). I have my Sensor flat on a table so gravity does not affect this axis right now. If I don´t move it I get values around 0.00g.
Now i´m moving the sensor quickly about 20cm in the direction of the axis.

I get the values like this from the movement:
0.05
0.59
0.38
0.11
0.02
-0.32
-0.58
-0.32
-0.09
-0.03

I interpret the values like this: first 5 values are acceleration, last values are because of the decceleration. Otherwise I couldn´t explain the negative values.

But here´s the problem: If I integrate the values for velocity and displacement (yes, I know that this is not really working well) I will end up pretty much at the start (first moving in the x-axis direction and then back again). This is not what I want. I want to measure at least some significant movement in the direction I was going. What am I missing?

Acceleration has a direction, just like position or velocity, and can be either positive or negative. This technical note explains why integration doesn't work with consumer grade accelerometers: http://www.chrobotics.com/library/accel-position-velocity

I would hazard a guess that you're using those -ve acceleration numbers wrongly, and ending up with -ve velocity, which is taking you back towards the start.

raw(/g) indicates your raw values which I have presumed are fractions of g.
a(t) just multiplies each raw reading by the specified value for g to change it from a fraction of 'g' to units of m/s/s.
Then a(t) is integrated to produce v(t) and v(t) is integrated to produce s(t), both using the specified sampling rate which I assumed to be a tenth of a second.
The maximum distance reached is .4974 (=49.7cm) in the 7th reading and then it starts going backward again. This is presumably because of the inaccuracies of using the accelerometer. A large part of the error in the distance is due to my assumption that the sampling rate was 10/sec. The actual value should produce a better estimate of the distance.

FYI. Changing the sampling rate to 15/sec gives a distance estimate that is closer to "about 20cm". The seventh reading for s(t) gives 22.1cm.
All of which must be taken with a large grain of salt as explained in the link from @jremington.

Hey there! Thanks for all the replies. So after all the values seem to be right.

Thank you Pete. I adjusted my integration scheme so that I´ll get the same outputs of the algorithm as you have in your sheet there. Now I get "satisfying" results. I still have some anomalies where my position goes back again but just a little bit.

I think I can get better results after I dig deeper into sensor fusion etc.. My biggest enemy right now is gravity. I´m going to check out the quaternion based gravity compensation solution which is built into Free IMU. It´s hard to understand though ;)...

Subtracting gravity is discussed and the problem solved in this long series of posts. The basic algorithm should be clear from the code in reply #27 (once Roger and I worked out a how the IMU was defining the quaternion for object orientation).

Hello @jambi, can you please share your codes about the accelerometer. When you move the sensor to the left, it will give you distance travelled by the object. Thankyou..