SparkFun Forums

[enliteneer]

Im thinking of a senior project for next year, and thought of making a
module that calculates velocity and then can transmit the data
wirelessly. I could demonstrate it on a r/c car, rocket, etc.

The wireless data transmission isnt the problem, the speed calculation
is what Im thinking about. For example, the SerAccel v3 module here at SparkFun, can output a PWM signal that the PIC could then count over time and determine velocity.

But since theres no absolute reference coming from the accelerometer,
it seems like the calculated velocity could easily get out of sync over
time and with stop/go bumpy acceleration.

Anybody have any thoughts on this? Are there other approaches better
suited? Or how the drift/noise can be minimized?

Erich

[sparky]

Hi Erich,

I can't tell you how to build it, but I can warn against some things.

All accelerometers are plagued with error. Even the new iMEM ADXL320s are pretty amazing and quiet, but if you look really closely, they vary over time.

Integrate accel once and get velocity.
Integrate velocity and get distance.

The problem is the small errors. Leave your accel sitting for a few minutes, an hour, and come back. Your distance measurement will read a few miles, and the velocity will be at 0.6c (speed of light). Integrating even a small error leads to problems.

To off set this, you need a second sensor - usually GPS. The two keep each other in check and you can actually get some pretty impressive readings when the loop is working.

Good luck and let us know what you come across in your research,
-Nathan

[awright]

Integrating an accelerometer signal to get velocity is very practical, especially when you are considering relatively short time periods like a rocket flight or R/C car operation with limited duration.

As an analog man, I recommend electronic integration on-board, then telemetering the instantaneous velocity signal to give a continuous velocity display or recording.

Integration over limited time periods is quite practical. The limitations are low end frequency response and offset voltages. Naturally, even a small DC error, integrated over a long period, results in a large "velocity" signal. That is why you need very low DC offset in your accelerometer signal and it's amplifier. Similarly, poor low-frequency response in your signal conditioning chain results in errors because it would cause steady-state acceleration to be ignored (although it is an open question how long you could maintain steady-state acceleration in a model car or rocket).

The solution is an accelerometer with very low DC offset followed by an amplifier/integrator with very low DC offset referred to its input. Auto-zero op amps and chopper amps would be good choices for minimum DC error.

High frequency response of your signal conditioning chain is not generally a problem so long as it is well above the frequency range of the actual acceleration being measured. This would have to be carefully evaluated for any motion with sudden accelerations/decelerations, like rocket flights or R/C cars involving impacts (collisions).

The other method of limiting error in your velocity signal is to clamp the velocity signal at zero volts before the start of motion, since you know that velocity is zero at that time. The clamp is released immediately before motion starts. This is an elementary operation for an electronically initiated device, like a rocket flight or R/C car, in which the clamp (relay or S/H amp or FET or?) holding the output at zero is opened as part of the launch or start signal.

For an integrator, clamping is generally best accomplished by placing a short or low resistance across the integrating capacitor until the start of motion. Since the voltage across the integrating capacitor is exactly the velocity signal, holding it at zero with a short assures that you have a zero velocity signal at zero velocity. That avoids the speed-of-light problem mentioned in one of the posts. After the start of motion, the DC error controls the velocity error, and that is controlled by the quality of your amplifier chain.

See the numerous app notes on analog integrators by National, Analog Devices, TI, Burr-Brown, etc., etc. You have lots of excellent options.

A good test for your system is to start your integrator and see how well it remains at zero with no motion. Another is to go through a period of motion and see if you get close enough to zero signal after motion ceases.

Calibration is not easy, as you would, ideally observe the velocity signal at a known, constant velocity and scale the result. Getting constant, accurately known straight-line velocity is not rudimentary. One method is to drop the device and calculate the instantaneous velocity at known times after start. Very accurate so long as velocity is low enough that air resistance is insignificant (and you haven't crashed into the ground).

awright

[Oznog]

It is not just a static offset in the accelerometer, but an offset which varies with temp. You can actually map out the offset at various temps and make a compensation chart combined with a thermistor reading the accelerometer temp. This helps a lot, but if the temp changes quickly there may be lead or lag between the thermistor's reading and the accelerometer reading. The best thing is to spend the power to heat the device up to a fixed temp with tight feedback control.

Offset errors are almost invariably smaller in devices with smaller ranges. A possible trick here is to combine a small range accelerometer with a wide range one in some cases. The small range one is used to calibrate both the zero and scale errors of the large one while the reading is within its range.

While a rocket may be able to get away with single axis, a car is in trouble here for off-axis errors. If you park on an upward slope, it will think it's accelerating. There may be some trouble with side acceleration as well as the vehicle is turned.

The rocket has a nice benefit that if it's not at several g's of acceleration you can assume this reading is the 0 g offset point. Cars, nope.

This gets so tricky that you definitely need uControllers to manage the tricks.

[awright]

Well, Oznog, you're correct, but I thought erich was trying to demonstrate measurement of velocity in a toy rocket or model R/C car, not trying to drop a payload on on a target from a submarine. I don't know how sophisticated he has to or wants to get for his class project, but I suspect that you may be suggesting a rather complex effort more suited to commercial product R&D than for a class project. (But I have to admit, it's been 4 decades since I did a class project and things may have gotten a lot more sophisticated since then.)

With reasonable design, I don't think he would have any serious thermal drift problems over the duration of a toy rocket impulse or even a few minutes of R/C car operation. Enclosing the circuitry in a little foam insulation and letting temperature stabilize before starting motion could reduce short-term thermal drift significantly. I think thermal issues would be mainly associated with rocket flight due to lapse rate, not R/C car operation, and toy rocket impulse duration is typically less than a second. You aren't going to get much useful information after apogee due to unknown orientation. Providing a constant temperature environment is clearly superior, but requires significant power which would be difficult to provide in a toy rocket due to battery weight. Same weight (and complexity) issue for a GPS receiver on-board.

Additionally, while the gravity vector is a factor, it's going to be pretty negligible for an R/C car where ups and downs will pretty much average out unless he's hill climbing. (And don't park on a slope.) I'm also not convinced that lateral acceleration will be much of a problem. Cross-axis sensitivity is usually a few percent, at most, and would tend to average out unless the car was going in circles in one direction for long periods.

I guess erich would have to define his goals and specifications to be able to decide on the complexity of the project he's willing to undertake. The cross-axis and slope problems are inherent in accelerometer-based velocity measurement independent of whether integration is analog or digital.

Rocket velocity measurement would be less prone to cross-axis and gravity vector problems because, unless things get out of hand, axial acceleration will be much higher than any possible lateral acceleration, and you always hope it's going to be going in only one direction for the duration of the burn. (If it isn't, do you care about velocity?) Obviously, the accelerometer signal will have to be nulled out for 1 G in vertical orientation on the pad.

awright

[assadij]

This is only a suggestion as I haven't done this just yet!
Analog integration sounds good but there are limitations: Integrator saturates, you also need resetting circuitry.
My suggestion is to do everything digitaly and save yourself space, and time.

Use and analogue input to directly read accelerometer's output (use a lowpass filter to elliminate antialiasing!).
Then in your software :
Use a digital filter (band-pass) to remove DC offset and upper useless frequencies (you need to know what's the minimum and maximum acceleration to determine upper and lower cut-off frequencies).
Integrate the digital filter's output to calculate velocity.

NOTE:
Besides the fact that you may have problems with sensor erros, there's another issue! Gravity and centripetal forces will affect your calculation nomatter what! You will have to use 3 accelerometers to sense acceleration in 3 dimentions (x,y,z). Then you'll have to put some extra effort to do some calculations to calculate the velocity (remember there's a 1g gravity always present and must be considered). If you only use 1 dimentional acceleration, then you must not take turns, go up/down steep hills, or pick up your toy and move it around