Accelerometer readings not consistently increasing during movement

Question

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

Answer 1

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.

Answer 2

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)

Answer 3

The readings are probably correct.

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.

Answer 4

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.