Using change in magnitude of accelerometer to calculate speed?

I have a wheel (say 60cm in diameter). And I am planning to attach a small board with an AVR and an accelerometer about 10-20cm from the centre.

As the wheel spins, I will get acceleration outwards. When the accelerometer is going up the wheel, it is going against gravity, while going down will be going with gravity.

In theory if I took the magnitude of the acceleration over time and I plotted it, it would look like a sine wave. Which I could then use to determine RPM and hence the speed.

My concern is that at 100 km/h (60 mp/h) that the change in acceleration would become too insignificant and I couldn't determine speed.

EDIT: The accelerometer isn't a necessity, the main objective is measuring the velocity.

EDIT2: I am after the velocity of the wheel. In either RPM or m/s (as i the speed as the wheel moves along the earth)

• why can't you use a gyro or an optical encoder? Commented Mar 18, 2015 at 3:36
• I can use either. I just need a solution to measure the velocity.
– jnd
Commented Mar 18, 2015 at 3:37
• Are you trying to measure linear velocity or angular velocity? If it's linear velocity, don't put it on a wheel. If it's angular velocity, use an optical encoder or something that can measure angular velocity (look up how speedometers work on bikes for inspiration). Commented Mar 18, 2015 at 3:38
• It's a requirement it be attached to the wheel. I wouldn't put it on the wheel either but its a requirement.
– jnd
Commented Mar 18, 2015 at 3:52
• RPMs and m/s are apples and oranges. m/s is a measure of linear velocity, RPM or d/s is a measure of angular velocity. Commented Mar 18, 2015 at 3:57

Your question didn't specify what velocity you're trying to measure, so I'll answer for multiple versions of this question.

First off, integrating acceleration to get velocity leads to drift. This is why [nearly] everything that uses an accelerometer for position/velocity information (and cares about accuracy) also has a GPS to remove those errors. Integration will always lead to errors, though they can be managed.

A better approach is to ask yourself what you're really trying to measure.

Angular Velocity:

Use something better for measuring angular velocity, like an optical encoder (as @kolosy mentioned) or a magnetic sensor (like bicycle speedometers). These each have their pros and cons, but they directly measure distance vs. time and thus directly give you velocity.

Linear Velocity:

Depending on the velocities and precisions involved, use a GPS (if you're going to be moving at a constant rate most of the time and will be going relatively fast), or use an angular-velocity measurement method on a wheel (which never exceeds the limits of static friction with the ground) and multiple that by its circumference.

In short:

Don't integrate unless you have to.

What you're suggesting will, in my opinion, work fine - within its limits.

Let's say you have an 60 cm diameter wheel. At 60 mph it will be turning at 15 rps, so you don't need to worry about an extremely high digitization rate. 100 - 200 samples/sec should be adequate. Centripetal acceleration will be a major problem, since in this case (assuming a position 20 cm from the center) it equals about 177 g's. Superimposed on this will be your +/- 1 g sine wave (and the amplitude of the sine wave will not change with speed). So you'll need about 10 bits of A/D resolution to allow identification of the sine wave.

If you're still interested in the idea, there are at least three other concerns.

The first is the need to balance your wheel - if you don't, it will shake itself apart at speed. You'll need to dynamically balance it, not just static balance. Just like balancing a new tire.

The second is the question of how you're going to communicate the sensor readings. Slip rings? Wireless?

The third is shock and vibration: how do you expect to handle them? If you hit a rough patch of road, your package is in for a very nasty ride. Remember, it's on the wrong side of the suspension.

Alternatives - frankly, I'm not a big fan of mounting anything active on the wheel. I'd be more inclined to put a pair of magnets on opposite sides and use a magnetic detector mounted on the axle housing. Optical sensing is not a real great idea, since the dirt or dust kicked up by the wheels will be a problem, plus mechanically coupling it to the wheel/axle is not trivial.

EDIT Note - I'm assuming that this is not a fifth wheel, added expressly for the purpose of taking data, but rather that it is on of 4 "normal" wheels. If this assumption is wrong, modify my concerns appropriately.

Since you say that you don't have to use an accelerometer, I'd say use a gyro or an encoder. A gyro like an MPU6050 (that's actually a 6DOF sensor, they have only gyros also, but it's the same gyro under the hood) can measure up to 2,000 degrees / second, which is about 10m/s in linear velocity for your 60cm wheel (if it were rolling, that is - that's a bit unclear from your question).

An optical or magnetic encoder would do the same job. You can read more about selection criteria here

• The issue with using a gyro is that at 100km/h I will have 800rpm and thus 5200 degrees per second. Which makes it hard to find a working gyro.
– jnd
Commented Mar 18, 2015 at 4:01

It is certainly possible to use accelerometer to determine RPM (which can be converted to speed and odometer if you know the diameter), but there are some challenges I found and had to solve:

1. You can identify sine-wave produced by gravity (-1g..+1g). It can be seen in two axes, I have X = in the direction of the axis of rotation (reads zero), Y = in the direction of rotation (tangent, this one is ideal, reads -1g..+1g) and Z = towards center of rotation (the sine-wave is shifted by centrifugal force, the higher the speed, which makes it go outside of the range of the accelerometer, rendering it useless).
2. Make sure the Y is really tangental! Even a small angle will shift the data by some percentage of the centrifugal force, which can be 100g and even more (it grows by square of the speed), so, even some fraction of this, can move the data outside of the range (I use 12bit 8g accelerometer).
3. It will probably never be perfectly tangental, so, you will need to calculate long-term average of all the values to get flexible center point (which should be 0g in ideal conditions). You can than track transitions of center+.75g and center-0.75g, to identify half-waves. (Or center+-0.5g, test this yourself.)
4. Bumps and ripples can hide the sine-wave. I had to implement two solutions:
1. Use rubber/silicon or similar material to make the mount a bit flexible, to swallow the energy of tiny hits. My first solution was not mounted so perfectly and I got the problem of not-so-tangental Y, so, I improved the mount but made it too stiff which introduced big bumps and ripples in real data (which could be specific to the application I cannot share more detail about... maybe except: I target train, not a car). Finally, rubber / duct tape + insulation material helped to reduce the ripples.
2. Increase the sampling frequency from 100Hz to 400Hz, averaging two samples (smoothing the data). I got surprised by the fact that the ripples got smaller with higer sampling frequency, I expected them to become shorter in time (because the hit is sub-ms = 1kHz+), but not in space (value - and yet they did + the averaging helped a lot).

Other possible solutions

1. Optical / magnetic sensor + encoder (one sensor would probably be enough but multiple sensors or at least two that are not opposite can give you sense of direction). This would probably be much better than accelerometer, but, may not be viable option for you (and is not for me, the distance between the axis / the mount and any other surface is not constant, solutions that need two pieces, one moving and one not, cannot be used). Optical sensor can get covered by dust, magnetic is susceptible to other forces (Iron everywhere).
2. Gyro could give reasonably accurate speed, but not exact - the sine-wave tracking is exact. Devices using gyro would have to be callibrated to give same values (accelerometer does not need that, the amplitude is not important, software can adjust without callibration - observing minimum and maximum or adjusting the threshold around center for up-down transitions).