# Accelerometer readings not consistently increasing during movement

I want my code to be able to determine the direction of motion for the LIS2DE12 accelerometer. I did a test where I had the accelerometer on a breadboard (connected to the STM32) and logged the values over UART while the breadboard was at rest and when I slid the board in one direction.

When the board is not moving, the values make sense:

Timestamp: 26852, X: -0.63, Y: -0.47, Z: 10.04
Timestamp: 26869, X: -0.47, Y: -0.47, Z: 9.89
Timestamp: 26886, X: -0.78, Y: -0.63, Z: 10.20


The z-axis is the gravity axis and although it's not perfect, it's close to 9.8 m/s^2. The x and y axes are near 0. When I move the board in one direction, just sliding it in the x-direction on a table, I would expect the values to either consistently increase in the positive or negative direction. But the values jump all over the place and switch from positive to negative or vice versa, and switch between increasing and decreasing. What could be going on here?

These are data samples during the time of movement:

Timestamp: 26920, X: 4.24, Y: 1.73, Z: 11.30
Timestamp: 26936, X: -0.47, Y: -2.04, Z: 10.20
Timestamp: 26953, X: 0.47, Y: -1.10, Z: 8.47
Timestamp: 26969, X: 2.51, Y: -1.73, Z: 13.02
Timestamp: 26986, X: 0.16, Y: -2.35, Z: 10.51
Timestamp: 27003, X: -1.10, Y: 0.94, Z: 8.32
Timestamp: 27019, X: 2.82, Y: 1.57, Z: 12.71
Timestamp: 27035, X: 0.63, Y: -0.94, Z: 12.87
Timestamp: 27052, X: 2.35, Y: -6.28, Z: 11.61
Timestamp: 27069, X: -0.31, Y: 0.31, Z: 10.98
Timestamp: 27086, X: -1.73, Y: 0.47, Z: 3.92
Timestamp: 27102, X: 1.73, Y: -5.65, Z: 10.20
Timestamp: 27119, X: 0.00, Y: -8.63, Z: 8.32
Timestamp: 27135, X: 3.92, Y: 0.47, Z: 16.16
Timestamp: 27151, X: 2.98, Y: -7.06, Z: 13.65
Timestamp: 27168, X: -1.73, Y: -1.88, Z: 11.45

• What is the unit of acceleration from the datasheet? ms^-2 or g? Commented Jul 16 at 6:34
• I think you need to revisit the general mechanic section of your physics book if you expect a constant increasing acceleration when you slide something at a approximately constant speed along the table. Commented Jul 16 at 6:37
• The data is in m/s^2 (this is computed in code). I only expected a constant increasing acceleration initially, and then if it's moved at constant speed at a certain point, then shouldn't the acceleration go back to being near 0 again? I only want to know the information about the initial movement. Commented Jul 16 at 6:42
• What's the sample rate in your application? It seems to vary in the data you've posted, from at least 13-17 something - I guess ms? Is that fast enough to be able to see acceleration plateauing in the timeframe of moving something with your hand across the table? Commented Jul 16 at 6:45
• If you saw a trapezoidal shaped curve, you would be looking at a speedometer. During acceleration it would increase to a fixed speed where it flattened out at that speed and went down to zero again. Acceleration only tells you if you changed your speed. You can't tell the difference between constant speed and constant no speed. The acceleration of such a speed curve would be a spike going positive in the first part of the ramp of the trapezoid, going back to zero when the trapeze flattened, and then a negative spike on the falling flank of the trapeze going back towards zero when the speed is0 Commented Jul 16 at 7:56

It's quite difficult to move an object manually with steady acceleration. Your experiment of 'just sliding it ... on a table' would be likely to have fairly constant speed. Any slight change in speed, or more strictly, velocity, would show up as a wildly fluctuating acceleration. Remember, acceleration is the differential of speed, so much more noisy.

A better experiment would be to tilt it in the x or y directions, to observe the sin(alpha) component of earth's gravity. Low noise, very stable and easy to set up, and with a ruler or protractor, very accurate. If you have a tilt-meter app on your phone, that's exactly how it works.

If you want a more dynamic experiment, then instead of reporting acceleration, first do a summation to velocity, then a summation to position, and report those. Spend some time investigating the rate of drift due to offsets and initial conditions (welcome to the tricky world of Inertial Navigation), and then move it about on your table (or off your table, if you're handling all three axes properly). The speed and position will be much easier to control manually, and will be less noisy due to the inherent low-pass filtering effect of the summation. You may well find the position drift is just too unstable to do anything with in a reasonable time. However the speed will be more stable.

• Agreed. Tilting would be a good way to see large changes (~ 9.8 m/sec²) in acceleration. Commented Jul 17 at 0:08
• @bfris tilting through a small angle would be a good way to see a small change in acceleration, the technique is limited to a maximum of g. Commented Jul 17 at 4:56
• The undergrad physics version of a constant acceleration experiment involves an air track with a carriage, accelerated by a weight on a string via a pulley. You don't need this near-frictionless setup here, but something like a Lego car to carry the sensor, again accelerated by the gravitational force on a mass hanging from a pulley (also Lego) should give pretty steady acceleration, roughly m₁g/(m₁+m₂). where m₁ is the hanging mass and m₂ that of the car, minus losses to friction etc. Commented Jul 17 at 9:14
• For steady speed, a motorised toy car on an even surface is pretty good. Use Lego again and you can gear it low enough that the proportion of travel spent accelerating is small over reasonable distances. You can also measure the distance travelled to compare to your integrated signal. An independent measure of speed wouldn't be impossible either, using simple parts and probably a camera (e.g. marks on the floor and a pointer on the car, timings from counting frames) Commented Jul 17 at 9:21

Acceleration is the derivative of speed and the second derivate of position.

It is quite unlikely that moving things by hand you could obtain a constant speed, and thus a zero acceleration. As your speed changes, the acceleration will vary as well, being positive if you increase speed (even slightly) and negative if you decrease speed (even slightly).

To determine the direction of travel, you need to integrate (sum) acceleration to get speed.

In your case, once you integrate, you get this:

Timestamp aX aY aZ Delta vX vY vZ
26920 4.24 1.73 11.3
26936 -0.47 -2.04 10.2 16 0.06784 0.02768 0.1808
26953 0.47 -1.1 8.47 17 0.05985 -0.007 0.3542
26969 2.51 -1.73 13.02 16 0.06737 -0.0246 0.48972
26986 0.16 -2.35 10.51 17 0.11004 -0.05401 0.71106
27003 -1.1 0.94 8.32 17 0.11276 -0.09396 0.88973
27019 2.82 1.57 12.71 16 0.09516 -0.07892 1.02285
27035 0.63 -0.94 12.87 16 0.14028 -0.0538 1.22621
27052 2.35 -6.28 11.61 17 0.15099 -0.06978 1.445
27069 -0.31 0.31 10.98 17 0.19094 -0.17654 1.64237
27086 -1.73 0.47 3.92 17 0.18567 -0.17127 1.82903
27102 1.73 -5.65 10.2 16 0.15799 -0.16375 1.89175
27119 0 -8.63 8.32 17 0.1874 -0.2598 2.06515
27135 3.92 0.47 16.16 16 0.1874 -0.39788 2.19827
27151 2.98 -7.06 13.65 16 0.25012 -0.39036 2.45683
27168 -1.73 -1.88 11.45 17 0.30078 -0.51038 2.68888

There you see that the speed along X axis is indeed always positive.

You can see on this graph that speed was definitely not constant or even increasing monotonically, which explains the acceleration alternating between positive and negative values:

Note also that:

• The acceleration along the Z axis is not the "real" acceleration (it would be 0 at rest if it were) so you can't really use it to compute speed or position in the Z axis (but you can use it to determine partial orientation of the sensor/your board -- full orientation would require a magnetometer on top of that).
• Integration accumulates errors. Even very small errors, when added repeatedly, quickly lead to large errors. This is called drift. For instance, Wikipedia tells us, in the case of computing the position (so double integration):

Even the best accelerometers, with a standard error of 10 micro-g, would accumulate a 50-meter (164-ft) error within 17 minutes

• While in the case of position there can be ways of resetting things (e.g. by using GPS or other geolocation methods to get the actual position), in the case of speed this is much more difficult, so even if acceleration gets to exactly 0, you cannot know if you are at rest or moving at a constant speed.
• Your accelerometer has 8-bit output, and is configured for ±2g. That results in a precision of about $$\g/64\$$ = 0.15 m.s-2.
• Frequency greatly affects the result, especially when acceleration varies a lot, which, as you can see, is quite frequent.
• Given the accelerations (and variations of accelerations) at rest, it's quite possible that one or more of the following are true:
• Your accelerometer was not actually horizontal (so some of the gravity is included in the X and Y accelerations)
• Your accelerometer was not actually at rest (there could be minor vibrations)
• You have calibration issues
• There is some other problem in your accelerometer configuration or the way you process the data
• It also means the results are even less accurate than could be expected

In short, accelerometers (alone) are often not as useful as one would think. Useful use cases:

• Determine (partial) orientation of the sensor (and thus board/device)
• Determine if an object is moving or not
• Measure vibration rates
• Detect "patterns"/"gestures" (shake, tap...)
• Measure acceleration itself (e.g. max acceleration)
• Should you still be able to determine which direction along the x-axis it was moving over 1-2 seconds after it started moving? Commented Jul 16 at 22:47
• @donut as you can see in the table, yes, speed along the X axis was always positive. But the fact we start from still and we know it helps a lot. If you keep it running for a long time, the speed may take values qui are completely off, so that you will have a non-0 speed when still, and it can make the measured speed a different sign from the actual one. You will need a way to reset the speed to 0 (and possibly keep it there) somehow. Easy if you have a fixed starting point and you can add a way to detect that position for instance. Commented Jul 17 at 0:12

9.8 is a large acceleration, like dropping something from the table. Were you moving it that quickly?

An object moving at constant velocity is not accelerating (apart from against gravity...). You can integrate acceleration to get velocity, but as you see, the noise floor is large. Try writing a Velocity output in your code, just add up the acceleration readings (multiplied by delta-t if you like)

I'd recommend first just getting an app that plots a graph of the accelerometer on your phone, and play with that a bit. For example, I've made recordings of planes taking off, integrated them and got roughly the right speed, but I'd say that sort of movement and acceleration is the smallest you can reliably measure with a cheap accelerometer.

• I was quickly sliding the breadboard across the table, about a foot in a second. I didn't move it at a constant velocity, as can be seen by the accelerometer values, and I would think at least initially there would be some consistency in increasing values for the initial acceleration, which is all I want to know. It's hard to believe I wouldn't be able to get such simple information from an accelerometer. Commented Jul 16 at 6:39
• Do try an app with a graph - (Physics Toolbox Pro on Android), it will get you more insight into the accelerometer than your bench test. My app will also save a CSV, then you can do some integration and graphing in excel. I strongly recommend testing your algorithms offline like this, before coding them into your gadget. Commented Jul 16 at 17:26
• An application where a cheap MEMS accelerometer works extremely well is the Nike Foot Pod, which went in your shoe and tracked running distance (in the days before GPS wristwatches). Because your shoe is stationary when it hits the ground, it could integrate over only the 250 ms of quite vigorous acceleration as you take a step, and then reset speed to zero as your foot lands. The opposite would be putting an accelerometer/gyro combination on a bicycle, for example, which would be a complete disaster. The integrated velocity and displacement error will grow without limit. Commented Jul 16 at 17:31
• "9.8 is a large acceleration, like dropping something from the table. Were you moving it that quickly?" To an accelerometer, acceleration and gravity are indistinguishable. Thus it's normal for an accelerometer to see an acceleration of 9.8m/s² when completely stationary. Commented Jul 16 at 20:18
• @simon of course. I meant it as an example of how much acceleration 9.8 really is. To get numbers that size, you need to be waving it around furiously. Commented Jul 16 at 21:20

A few years ago at work, I saw a very similar thing when I wanted to get velocity and acceleration measurements by differentiating a position measurement. One differentiation step was very noisy; two had a noise floor greater than any signal.

The solution was low-pass filtering. Bessel low-pass filters give the best group delay which maintains the response without ringing.

• The low pass filter helped with noise? I'm trying to understand whether it should be possible to discern the direction of movement from the initial data after movement, if I'm only moving along one axis. Commented Jul 16 at 22:58
• That's basically what a low-pass filter is there for - smoothing out any unwanted fast changes in the signal. And this type of noise is basically the definition of unwanted fast changes. Commented Jul 17 at 12:33