Basic Speedometer using Accelerometer

[datamstr]

Hi all,

Anyone build a basic speedometer using a Freescale Accelerometer?

I have not yet worked with any of the accelerometers, but am guessing that it should not be too difficult to build.

Thanks,

David

[rocco]

Hi David,

Actually, it is not very easy to get it right, and may not be as accurate as most speedometer applications would need.

The accelerometer only measures acceleration, not velocity. So if you are moving at a constant speed, the accelerometer reads zero. The only way to deduce velocity is to perform an integration of the acceleration, but the accuracy of the integration is hampered by the inherent gain-error and output-offset of the sensor.

The gain-error will cause the calculated velocity to be slightly different from the real velocity, and this error will also be integrated, leaving you with a potentially large velocity error. And even if you do get to a correct velocity (with careful calibration), integrating output-offset will then cause the calculated value to drift away from the real value.

And then there are the rounding errors in the math, with will accumulate in the integration process if you're not careful.

It can be done, but you would need:

1) an accelerometer that is very stable over temperature and probably voltage, and

2) a means to calibrate the final product for gain-error and output-offset, and

3) a mathematical algorithm that insures that errors are not integrated into the final result.

Hope that helps and good luck.

[datamstr]

Hi Rocco,

Thanks so much for your input!

I can easily get by with at least a 10% error in speed detection for this application, so perhaps it is possible to do.

I could run a cable and sensor to one of the vehicle wheels, but I would rather not since the precision is not required.

Sounds like an interesting project!

Thanks,

David

[PeterHouse]

I have played with this in the past and you most likely will not be happy. The integration errors are hideous while you are traveling at a constant velocity. Hills and grades will also be an issue since the acceleration sensor cannot distinguish between acceleration due to gravity and acceleration due to speed. Run a wire to the wheel or to the driveshaft if you can and count revolutions - you will sleep better at night. For a couple of hundred dollars you can purchase a device used by amateur racers that will illustrate some of these issues. Check out http://www.gtechpro.com I couldn't tell if they still show speed over distances longer than a 1/4 mile. Good Luck, Peter

[rocco]

---

PeterHouse wrote:
. . . Hills and grades will also be an issue since the acceleration sensor cannot distinguish between acceleration due to gravity and acceleration due to speed.

---

. . . and I didn't even think of this issue. That means that, as you go uphill at a constant speed, the displayed velocity will increase as the integrator will think you are accelerating. And then decrease as you go downhill. I don't see an easy solution to this. You can use a clinometer to compensate for the grade, but all the clinometers I have used are sensitive to acceleration (they interpret acceleration as being off-level), so have the same problem.

[bigmac]

Hello,

I think that the issue of hills needs to be kept in perspective.  I will assume that the accelerometer is aligned within the vehicle so that gravitational acceleration, when the vehicle is level, is present in the z-axis, and that the x- and y- axes have negligible gravitational components.  I will also assume that the forward acceleration is in the y-axis, and the lateral x-axis does not need to be measured.

The gravitational component in the y-axis will therefore become a significant component only for relatively steep gradients.  Additionally, the gravitational component would usually remain constant for significantly longer periods that the transient acceleration of the vehicle.  It should therefore be possible to mostly separate the transient component from the gravitational component, with suitable processing of the raw data, to achieve high-pass filtering.

Regards,

Mac

[rocco]

. . . Oh man . . .

I just wrote a large post, spelling out the trigonometry necessary to do what Mac suggested (subtracting gravity out of the raw data), and also spelling out where that algorithm will likely go wrong.

And when I clicked "Preview", Lithium said something like "can't process your request" and threw it all away.    Dang!

Maybe I'll try again tomorrow.

[Lundin]

Couldn't you simply add a MEMS gyro to the PCB as well?

[rocco]

OK, let's try again:

What Mac suggested could work, but probably not much better, and certainly not easily. One idea would be to treat X, Y and Z as generating a vector in 3-D space, and then subtracting out the gravity vector, leaving you with the acceleration vector.

One nice thing about gravity is that is constant. As a vector, you could know its magnitude (with careful calibration), and just need to resolve its direction. If you start with gravity being entirely on the Z axis when level, and through calibration normalize it's value to 1, then you could determine its angle from level (without its direction) by applying the inverse-cosine to the Z sample data. You could then calculate and remove the gravitational component from X and Y, if you can make a good estimation of the direction of tilt. Since the velocity you wish to measure is along Y, then any X value would be from gravity as well, and with that you can estimate the angle along the X axis. With more trig, you can then estimate the angle along the Y axis, except for its direction. You could use trend information to try to track its direction (or Lundin's suggestion).

However, the effect of tilt on Z will be small, so unless your Z data is sampled at high resolution (like 24-bits), the angle you calculate will be rough, and therefore the effect on Y will not be very accurate, and those errors will integrate into the final velocity.

Lundin's suggestion could simplify the tracking of tilt, but they won't tell you when you are level or off-level. They give you the rate-of-rotation though, and that could help you find the angle from level more accurately. Since the challenge with Mac's suggestion is not integrating the error from a poorly-resolved angle, the gyros may help a lot.

Keep in mind that MEMS gyros pose the same challenge as MEMS accelerometers: Their output needs to be integrated, with gain-error and offset-error removed, to derive an angle. I have not used MEMS gyros, but have used FOG gyros, fed through 24-bit ADCs into a DSP to track rotation.

[datamstr]

A big THANKS to all for your help!

David