Using an accelerometer to estimate velocity

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am interested in calculating the speed of an object using the data from an accelerometer. I have a LSM303DLM accelerometer and a gyroscope that I am using to estimate the tilt using a complementary filter (using both the accelerometer's and gyroscope's data). Now I need to know the average speed and an estimation of how far the object traveled.

I know that integrating the accelerometer's data might not be too accurate because of the accelerometer's error. However, I'd like to know the speed of my IMU at very small intervals of time (less than one second). I will be accelerating the object that has the accelerometer for small intervals of time, then it will stop for approximately that same time, then it will keep going and so forth. I know when the unit is going to be at rest, so I am planning on resetting the velocity to zero everytime I know it's at rest, then start integrating again for just that small interval of time.

My question is, is the fact that I will be integrating for just short periods of time going to help? I am planning on averaging those speeds later on to know how far the object traveled, displacement=v*t, where v = (v1+v2+...vn)/n and t would be the total elapsed time (that time can be hours). I know that if I continuously double integrate the accelerometer's data, the resulting displacement is going to be unreliable because of the error.

So by integrating for short periods of time, and knowing when the object is at rest to reset the values would help? Or would I have the same problem that the error is going to make the data unreliable?

Thanks in advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know the answer to this, but surely you can simulate the two methods using penil, paper and calculator and work out which gives the bigger error?

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The cheapy accelerometers are inherently noisy, thus will cause errors. Devices such as the mpu6050 do internal processing, but i'm not too sure how successful they are to estimate distance over time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The simple answer is "It depends"

I'd say that firing up Excel(or similar, Matlab if you've got it)) and building a simple "Fixed time step iterative" line-by-line model will answer a lot of questions quickly and easily. You can finesse the model as much as you like by adding parameters for random noise, frequency specific noise and data offsets etc!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should probably add this is how i would do it:

1) Define an "absolute position" characteristic vs time and choose your time step (the smaller the steps, the more processing required for each run, i tend to make this a variable so i can do a quick "looksee run" followed by a full run if the initial output looks good).
2) Calculate the True velocity and acceleration
3) take this True acceleration and feed it into your "accelerometer model calc" (initially, use it as it is to check you model works)
4) Integrate your Accelerometer Accel value to get back to velocity
5) Integrate your velocity to get position

If you model works, your calc's position should equal your absolute position!

Now, you can add all sorts of errors into your accel data (offsets, noise, lags etc) and see exactly what the result it!

Simples!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a range vs resolution tradeoff. The accel is outputting little delta velocities. You need to read these twice as fast as the thing is bouncing. The better the resolution the better. I'd use an external 16bit a/d with internal vref. There is an LT part in a soic but I cant pull the number out right now. And everyone seems to think that Forward Euler integration is "good enough". Just accumulate all the little deltaVs to get V then accumulate all the deltaXs to get X, but a Trapezoidal integrator has less error than an Euler integrator and a 4th or 5th order integrator is more accurate than that, so I think there is an opportunity for some innovation here.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aircraft?
Submarine?
Hovercraft?

Or an object that has a wheel in contact with the ground?

It seems to me that using the data from a physical wheel, or rollerball, (think mouse), will be more accurate, it the terrain is firm, (not sand, etc.).

Can't find it right now, but there was an old Thread on this that discussed the errors in detail.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
So by integrating for short periods of time, and knowing when the object is at rest to reset the values would help? Or would I have the same problem that the error is going to make the data unreliable?

Are you using some filter? If not, you must use.
Short period is dependent on your application. But the better is your filter, the better is your results. The filter try to reduce your error. We like to use excel to analyze the data.

Bob integration is after the filter, or estimator. If you don't have a good estimator your integration result will have errors, more than the integration calculus it self.

This is inertial navigation.

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It will depend upon how long the integration periods will be ( and the accelerometer used ) if there error will be small enough for your application. But, having known stop points will improve the error. The think is, if there are no known velocity points, the integration error continuously sums where as having "known stopped" points means that the error can be zeroed. The cumulative error, therefore, is constrained in the resetting case where it is unconstrained in the continuously summed case. However, simply saying that the error is constrained is not the same as saying it will be small enough.

As has been said above, a good estimator ( filter ) will be needed as well as careful implementation to avoid computational errors.

If each of the movements really is "the same" then averaging them will ( slowly ) improve the error, but if the motions are different, an average will only lead to a further source of error. How similar the movements need to be will depend upon what, precisely, is being measured.

Best way to know for sure is to run some tests and see how much noise is apparent.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

as above.. yes, a well known problem of integration error - common problem is GPS augmentation via dead-reckoning where heading is known from magnetic compass but speed is not. In some car NAV systems, they get speed from the car's systems. Some use an inertial gyro or MEMS to do short term speed estimation, e.g., when under trees, overpass, short tunnel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any idea how many samples per sec in real commercial systems? 10Hz? 100Hz? 1KHz?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all!

Thank you for all of your responses. I finally got to simulate it on Matlab (Octave actually). I started by collecting real data from the accelerometer at known speeds and then worked with those collected samples on Matlab and C++. For those interested in hearing about my progress, here it is:

Like explained in the original post, this project consists of accelerating an object at very short intervals of time, and then stopping it. My approach (which I explained before) is to integrate the acceleration at those small intervals with respect to time. Since I know when the object was moving and when it was at rest it makes it a little bit easier. I wasn't sure that it would work, which is why I created this original post, but the error was relatively minimal (My application doesn't require to to know the exact speed).

These were the results:

Real Speed: 1mph, Averaged speed: 2.3523 mph
Real Speed: 3mph, Averaged speed: 3.4537 mph
Real speed: 5mph, Averaged speed: 5.70581 mph

It seemed to work better at relative high speeds. I still need to experiment more but it's looking pretty good so far.

Check out the following image. I graphed an interval of those samples (right image) and displayed the results of the program (left image):


http://www.myicv.com/media/73_6_3246.png
The blue graph is the one I am integrating, the highest peaks show when the object is moving forward.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What order integration do you use? Euler? Trapezoid? Simpson? Runge-Kutta? How do we decide which to use? The easiest to program? The one that gives the best results?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
What order integration do you use? Euler? Trapezoid? Simpson? Runge-Kutta? How do we decide which to use? The easiest to program? The one that gives the best results?

I am using trapezoidal rule to calculate the integral. This one proved to be a very accurate estimation. All the samples are going to be different than the previous ones, so it makes sense to estimate the integral of the acceleration using trapezoidal rule. If you draw all the samples such that sample[0] ≠ sample[1] (where sample[0] and sample[1] are the two latest samples in an array), connect all the lines and you'll form mostly trapezoids (or triangles, but that's ok because Area = Δt*(sample[0] + sample[1])/2, when sample[1] = 0 for instance it just becomes the area of a triangle...).

Since I rarely see equal samples one after the other, I could safely assume that by using trapezoidal rule I could obtain the best results. And when I say that rarely a sample is going to be equal to the previous one, that means I have never seen that happen (there is always a slight variation even when the accelerometer is at rest). Therefore, I would say that I chose trapezoidal rule for both accuracy and simplicity.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Repeating my prior comment:

Quote:

Aircraft?
Submarine?
Hovercraft?

Or an object that has a wheel in contact with the ground?

The point was this:

If you have a wheel on the ground, then in most cases taping into the odometer data, through the vehicle's data bus, or by directly taping into the sensor, or by adding your own sensor, will be incredibly more accurate than double integrating a low cost MEMs accelerometer.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Repeating my prior comment:

Quote:

Aircraft?
Submarine?
Hovercraft?

Or an object that has a wheel in contact with the ground?

The point was this:

If you have a wheel on the ground, then in most cases taping into the odometer data, through the vehicle's data bus, or by directly taping into the sensor, or by adding your own sensor, will be incredibly more accurate than double integrating a low cost MEMs accelerometer.

JC

True, but unfortunately my application doesn't involve wheels or anything. I needed to measure the displacement and velocity of an object that gets off the ground for a fraction of a second, and does that continuously. The more practical way of doing so was with an accelerometer and gyroscope, even though I knew about the error. Still the error wasn't too bad, I still get pretty good results, really close to the actual speed. I still need to work more on the code, but the logic has proven to work so far! I'll post further results when I get it done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
The cheapy accelerometers are inherently noisy, thus will cause errors. Devices such as the mpu6050 do internal processing, but i'm not too sure how successful they are to estimate distance over time.

I found something very interesting to do a few days ago with a MPU6050 here:

http://stkwans.blogspot.com/2012...

the guy measures rate of earth rotation using mpu-6050. i mean how cool is that!! a $5-10 chip/board being used to do "nasa" stuff...

I have absolutely no idea what he's doing and how its working though...nor do I know the math behind it..

new to mirco electronics

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello agent Icruz. (I assume you also like it shaken? haha) I see your integrated speed is always a little higher than the actual.... does it get better if you test the speed up and down? If you are only testing while its going up or one direction, the error is all positive or negative (difference in area between trapezoid line between points on the curve and the actual curve). Try a 3rd order integrator... simpson's rule... might be more accurate? That would be very interesting.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Hello agent Icruz. (I assume you also like it shaken? haha) I see your integrated speed is always a little higher than the actual.... does it get better if you test the speed up and down? If you are only testing while its going up or one direction, the error is all positive or negative (difference in area between trapezoid line between points on the curve and the actual curve). Try a 3rd order integrator... simpson's rule... might be more accurate? That would be very interesting.

Haha hey Bob, well in my application I need to only measure the acceleration in one direction, so that makes it a little bit easier for me. I also noticed that the error is significantly less when the speed is higher, that might be because I have to integrate during a shorter period of time, thus integrating the error less.

That's a good idea, I will keep improving the code and I will post further results here! Thank you.