Detecting the movement direction using an accelerometer

Click For Summary

Discussion Overview

The discussion revolves around detecting the direction of movement using an accelerometer, particularly in scenarios where the device is placed on a table with the z-axis fixed. Participants explore the challenges of accurately determining movement direction, especially during rapid changes in motion.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • Marcos describes an algorithm that detects movement direction based on the difference between current and previous accelerometer values, but notes it struggles with rapid directional changes.
  • Some participants suggest that without a gyroscope, the accelerometer's effectiveness is limited and emphasize the need for fixed orientation during measurements.
  • There is a discussion about the importance of integrating acceleration to determine velocity, with some participants proposing different integration methods, including the Runge-Kutta method.
  • Marcos expresses a desire to identify movement direction without focusing on velocity, suggesting that patterns in the accelerometer data could be used to develop a more effective algorithm.
  • Concerns are raised about the calibration process and the potential for noise in the accelerometer readings affecting the accuracy of direction detection.
  • Participants discuss the need for mechanical filtering to remove noise and propose adjustments to the integration calculations to improve the algorithm's performance.

Areas of Agreement / Disagreement

Participants do not reach a consensus on the best approach to detect movement direction using an accelerometer. Multiple competing views and methods are presented, with ongoing debate about the effectiveness of different algorithms and the role of velocity in determining direction.

Contextual Notes

Limitations include the dependence on the initial orientation of the device, the potential for noise in the accelerometer data, and unresolved mathematical steps in the proposed algorithms.

marcospassos
Messages
3
Reaction score
0
I'm a few days trying to get the direction of movement using an accelerometer. For my application I need to put an object on the table (z axis fixed) and detect the movements. I know perhaps the accelerometer is not the best sensor for this kind of application but is the sensor that is available on the devices that I need to use.

For example:

- I move it to the right, left, right and then left quickly.
- The expected information: right, left, right, left

The pattern for the movement start is simple: I get the signal and compute the difference between the current value and last value (ignoring small values) and if is negative, than it is moving to the left, if is positive it is moving to the right. So, I've created a stop condition. When I've obtained X numbers of zeros of the difference I understand it is stoped. This algorithm works great and is very accurate.

The big problem is when I'm movig to right and I quickly move to the left. The algorithm cannot detect the change because he is waiting the stop and it doesn't happens.

I've analyzed the data several times, but I can not find a pattern to the end of the movement in order to create an new algorithm.

Bellow are some graphics that I've generated using the data obtained from accelerometer.

http://img31.imageshack.us/img31/9544/graphsjk.jpg

The chart on the left side is a simple and slow movement from the right to the left. In the right side is the problematic situation where the movement is from the right to the left and to the right again.

I would be grateful if you could help me.

Thanks in advance,
Marcos
 
Last edited by a moderator:
Physics news on Phys.org
Without a gyroscope, this will work only if the orientation (all axes) of the device is fixed. You have to know the initial velocity of the object when you start recording the acceleration (presumably zero, if the user is advised to hold the device still for a moment). Then you have to integrate the acceleration to get the velocity. There should be plenty of sample code for this online in any language used on mobile devices.

The pattern for the movement start is simple: I get the signal and compute the difference between the current value and last value (ignoring small values) and if is negative, than it is moving to the left, if is positive it is moving to the right.
That sounds like differentiation. What you have to do is something like this:

current_velocity = velocity_dt_ago + (acceleration_dt_ago + current_acceleration) / (2 * dt)

There a better integration algorithms though. Google for "runge kutta 4".
 
Hello A.T, thanks so much for your reply.

The velocity is not important to me. I just want to know the direction. In fact, I have the direction using my algorithm but it doesn't work when I change quickly. I believe there is a formula or pattern to identify when it occurs through the graph peaks.

http://img403.imageshack.us/img403/831/graphs2.jpg

Observing the following graph I can suggest that at point 1 the object starts moving to the left, because the graphic was stable and started decreasing. At point 2, I believe the movement from the left definitely has stopped and started moving to the right, once the values started increasing. At point 3 the object is stopped again.

As it is possible recognize looking at, I believe is possible create a algorithm for this, using some formula or pattern.

Am I wrong?
 
Last edited by a moderator:
marcospassos said:
The velocity is not important to me. I just want to know the direction.
Velocity is a vector. It tells you the direction as well. You have to apply the intergation to all three components (x,y,z).
marcospassos said:
I believe is possible create a algorithm for this, using some formula or pattern.
Yes, integration.
 
A.T,

I'm trying get it work. What I'm doing:

- First, the algorithm "calibrates" the sensor getting 50 samples and using the average as the offset
- Subtracts the offset from the accelerometer value
- Stores the current value of accelerometer
- Makes comparisons using the speed in order to detect the direction

I think I'm doing something wrong, because doesn't works well. I moved the device from the left to right and then I stoped, it shows: left, right, stoped. Sometimes it shows always right or left.

Can you help me?

My algorithm:


// calibration... offsetX = SUM(50 samples)/50

accX[1] = (x - offsetX);

// Mechanical Filtering (remove some noise)
if((accX[1] < 0.2) && (accX[1] > -0.2)) {
accX[1] = 0;
}

// First X integration:
velocityX[1] = velocityX[0] + accX[0] + (accX[1] -accX[0]);
// Second X integration:
positionX[1] = positionX[0] + velocityX[0] + (velocityX[1] - velocityX[0]);

accX[0] = accX[1];
velocityX[0] = velocityX[1];

if(velocityX[0] < 0)
debug = "left";
else if(velocityX[0] > 0) {
debug = "right" ;
} else {
debug = "stoped";
}
 
marcospassos said:
// First X integration:
velocityX[1] = velocityX[0] + accX[0] + (accX[1] -accX[0]);
// Second X integration:
positionX[1] = positionX[0] + velocityX[0] + (velocityX[1] - velocityX[0]);
Ahhm... you are adding and subtracting the same values there (accX[0] and velocityX[0]).

Simple intergation works like this:
PHP:
velocityX[0] = 0 // we assume the device was static when we started recording acc
positionX[0] = 0

for every sample i > 0:
    dt = time[i-1] - time[i] // if sampling rate is constant simply use 1 / frequency here
    velocityX[i] = velocityX[i-1] + (accX[i] + accX[i-1]) / (2 * dt)   
    positionX[i] = positionX[i-1] + (velocityX[i] + velocityX[i-1]) / (2 * dt)
 

Similar threads

  • · Replies 47 ·
2
Replies
47
Views
5K
Replies
11
Views
24K
  • · Replies 8 ·
Replies
8
Views
4K
  • · Replies 2 ·
Replies
2
Views
1K
Replies
4
Views
1K
  • · Replies 2 ·
Replies
2
Views
10K
  • · Replies 24 ·
Replies
24
Views
2K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 4 ·
Replies
4
Views
9K
  • · Replies 3 ·
Replies
3
Views
2K