Calculating Speed with an accelerometer

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. Analog Devices (ADXL202) and ST have
accelerometers that output a PWM signal that a micro 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?

Ben

 

[martin griffith]

On 7 Mar 2005 13:39:25 -0800, in sci.electronics.design
benn686@hotmail.com wrote:

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. Analog Devices (ADXL202) and ST have
accelerometers that output a PWM signal that a micro 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?

Ben
GPS seems obvious

martin

"An eye for an eye makes the whole world blind"
Gandhi

 

[Rob Gaddi]

Integral of acceleration provides velocity information, subject to
restrictions of the resolution of your measurements and the bandwidth of
your integrator.

Voltage across the drive motor also provides velocity information,
subject to a voltage drop error in the armature resistance when
providing torque (either due to friction (minimal) or acceleration), and
scaled by an unknown constant.

Creative coding in a micro may allow these techniques to cross check
each other.

benn686@hotmail.com wrote:

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. Analog Devices (ADXL202) and ST have
accelerometers that output a PWM signal that a micro 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?

Ben

 

[John Larkin]

On 7 Mar 2005 13:39:25 -0800, benn686@hotmail.com wrote:

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. Analog Devices (ADXL202) and ST have
accelerometers that output a PWM signal that a micro 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?

Ben

Even a 1% acceleration zero error will accumulate rapidly into a big
velocity error. And tilt looks just like acceleration. For a rocket,
with high g's and a short burn time, this would be usable (in fact,
it's done), but for something like a car, probably not.

John

 

[James Meyer]

On 7 Mar 2005 13:39:25 -0800, benn686@hotmail.com wroth:

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.

For a rocket, the easiest way would be to include a small transmitter in

the rocket. The transmitter's output frequency would be doppler shifted due
directly to velocity. A receiver on the ground would measure the shift. Both
transmitter and receiver would need appropriate frequency stability.

Jim

 

On 7 Mar 2005 13:39:25 -0800, benn686@hotmail.com wrote:

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. Analog Devices (ADXL202) and ST have
accelerometers that output a PWM signal that a micro 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?

Ben

Congradulations, you just fell upon the problem with inertial
navigation; that and drift in the gyros. Better components, lower
drift, better tracking.

 

[John Larkin]

On Tue, 08 Mar 2005 00:59:55 GMT, James Meyer <jmeyer@nowhere.net>
wrote:

On 7 Mar 2005 13:39:25 -0800, benn686@hotmail.com wroth:

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.

For a rocket, the easiest way would be to include a small transmitter in
the rocket. The transmitter's output frequency would be doppler shifted due
directly to velocity. A receiver on the ground would measure the shift. Both
transmitter and receiver would need appropriate frequency stability.

Jim

Right. It might be difficult to get an oscillator that's sufficiently
g-insensitive to make this work.

John

 

[Tim Shoppa]

Are there other approaches better suited?

Find somebody with a good radar speed gun, and offer them "I'll give
you this accelerometer if you measure my speed for me".

Tim.

 

[Rich Webb]

On Mon, 07 Mar 2005 20:19:57 -0500, sdeyoreo@hotmail.com wrote:

On 7 Mar 2005 13:39:25 -0800, benn686@hotmail.com wrote:

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. Analog Devices (ADXL202) and ST have
accelerometers that output a PWM signal that a micro 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?

Ben

Congradulations, you just fell upon the problem with inertial
navigation; that and drift in the gyros. Better components, lower
drift, better tracking.

And Kalman filters... ;-)

--
Rich Webb Norfolk, VA

 

[Mac]

On Mon, 07 Mar 2005 13:39:25 -0800, benn686 wrote:

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. Analog Devices (ADXL202) and ST have
accelerometers that output a PWM signal that a micro 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.

This is the understatement of the year.

Anybody have any thoughts on this? Are there other approaches better
suited?

Ben

The accelerometer idea won't work at all, except maybe in a rocket, as
suggested by someone elsewhere in the thread.

I suggest you forget about the accelerometer and use GPS or ultrasonics,
or just use the rotation speed of the axle or motor or something.

--Mac

 

[Ken Smith]

In article <422CDA50.80602@SpamMeSenseless.us.ibm.com>,
Phil Hobbs <pcdh@SpamMeSenseless.us.ibm.com> wrote:
[...]

Inertial navigation of this sort is very much easier for a land vehicle
than for a rocket, because in free fall, the acceleration due to gravity
won't register on the accelerometer--and tiny, tiny errors in finding
the vertical direction have large effects.

I don't think the vehicle case is any easier. You have the lumps and
bumps and jerking around to make sure that any inaccuracy in the ADC gets
found.

When a lump pushes the car up, tips it and shoves it sideways all at once,
you are really screwed unless you have a rotation detector that is quite
good. With out it, the exact same data can come from two very different
events where the car speed and direction are both different between the
cases.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <nu0q211iu4odisd8kqoqlhhhmf2899a483@4ax.com>,
John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
[...]

Right. It might be difficult to get an oscillator that's sufficiently
g-insensitive to make this work.

An atomic clock or Laser may be required.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <sb1q211udssvbu66p8tac6p1qnsk670kj7@4ax.com>,
Rich Webb <bbew.ar@mapson.nozirev.ten> wrote:
[...]

And Kalman filters... ;-)

Kalman filters are nice but they can easily lead you to making pretty
looking lies. GPSes commonly use Kalman filters. Sometimes you'll see a
path like this:

..........................*........................
..........................*........................
.........................*.........................
........................*..........................
......................**...........................
....................**.............................
..................**...............................
................**.................................
.............***...................................
.........****......................................
********..................************************


The GPS'es model for what was going on got very far from the real physics
for a while and then the code realized it screwed up and corrects its
self. I've seen as many a 3 or 4 of these in 8 hours of GPS data.

--
--
kensmith@rahul.net forging knowledge

 

If I went with a GPS approach, would a GPS have enough precision to
resolve between an rc car moving pretty short distances, on the order
of a tens of feet maybe?

If the resolution is there, it seems plausable that changes in position
could be timed.

 

[Mac]

On Mon, 07 Mar 2005 21:50:24 -0800, benn686 wrote:

If I went with a GPS approach, would a GPS have enough precision to
resolve between an rc car moving pretty short distances, on the order
of a tens of feet maybe?

If the resolution is there, it seems plausable that changes in position
could be timed.

The position reported by the GPS has plenty of precision. But there is a
lot of error. How the error varies with time is something I'm not too sure
about, but that is what you need to know. For example, if you imagine
logging positions from a stationary GPS over half an hour, you would
expect that the reported position would wander during that half hour. But
if it never wanders more than a foot or two over the course of a minute,
then GPS might work. If it jumps around 20 feet per second, then it
probably won't work for you.

There are differential GPS's that will definitely work, but for that,
you have to buy two, and they are expensive, and require either a radio
link or data post-processing. These things will give you sub-inch
precision and relative accuracy.

The way they work in the post processing mode is that instead of just
solving for position, they record all the GPS information from all the
satellites they can track. Later the post processing software figures out
the position of the mobile GPS with respect to the stationary one to very
high resolution.

If you have a real-time radio link between the two units, then they
transmit enough information back and forth to do the same thing, but the
mobile unit then does it itself, internally, in real time.

I wonder whether you could just use two regular GPS's, with one on the
vehicle, and one stationary, but nearby. Then whatever hardware is
receiving the messages from the RC car could also receive messages
from the stationary GPS, and subtract the two GPS positions (vector wise)
to get a vector from the known location of the stationary GPS.

There are a lot of reasons why this might not work very well, but it is a
thought. I doubt it would work any worse than a single GPS, which still
might work OK, especially if you have a good view of the sky.

Good luck. Don't let the scope of this project get out of control.
Otherwise you'll never finish! ;-)

--Mac

 

[Barbarian]

All of the GPS receivers that I am familiar with will give you a speed
calculation once per second, not very practicle for an R/C vehicle moving in
fits and spurts.

<benn686@hotmail.com> wrote in message
news:1110261024.376413.303540@z14g2000cwz.googlegroups.com...

If I went with a GPS approach, would a GPS have enough precision to
resolve between an rc car moving pretty short distances, on the order
of a tens of feet maybe?

If the resolution is there, it seems plausable that changes in position
could be timed.

 

[James Meyer]

On Tue, 08 Mar 2005 02:51:37 GMT, Mac <foo@bar.net> wroth:

On Tue, 08 Mar 2005 00:59:55 +0000, James Meyer wrote:

On 7 Mar 2005 13:39:25 -0800, benn686@hotmail.com wroth:

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.

For a rocket, the easiest way would be to include a small transmitter in
the rocket. The transmitter's output frequency would be doppler shifted due
directly to velocity. A receiver on the ground would measure the shift. Both
transmitter and receiver would need appropriate frequency stability.

Jim

There was a thread about this right here in this newsgroup a while back.
IIRC, it is not at all obvious that this is the best approach or that it
will even work.

--Mac

However, it's head and shoulders above an accelerometer approach.

What was the consensus concerning why doppler shift woldn't work?

Jim

 

[James Meyer]

On Tue, 8 Mar 2005 03:04:44 +0000 (UTC), kensmith@green.rahul.net (Ken Smith)
wroth:

In article <nu0q211iu4odisd8kqoqlhhhmf2899a483@4ax.com>,
John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
[...]
Right. It might be difficult to get an oscillator that's sufficiently
g-insensitive to make this work.

An atomic clock or Laser may be required.

--

Bullshit. 2.4 GHz rf sources are readily available. What's the doppler
shift at that frequency for 200 MPH velocities?

Jim

 

[John Woodgate]

I read in sci.electronics.design that James Meyer <jmeyer@nowhere.net>
wrote (in <808r21l6bi20jf2n9g86scqvns003oilv5@4ax.com&gt about
'Calculating Speed with an accelerometer', on Tue, 8 Mar 2005:

On Tue, 8 Mar 2005 03:04:44 +0000 (UTC), kensmith@green.rahul.net (Ken Smith)
wroth:

In article <nu0q211iu4odisd8kqoqlhhhmf2899a483@4ax.com>,
John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
[...]
Right. It might be difficult to get an oscillator that's sufficiently
g-insensitive to make this work.

An atomic clock or Laser may be required.

--

Bullshit. 2.4 GHz rf sources are readily available. What's the doppler
shift at that frequency for 200 MPH velocities?

It's velocity-dependent. You need to specify the relative direction as

well as the speed. (;-)
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

 

[Ken Smith]

In article <808r21l6bi20jf2n9g86scqvns003oilv5@4ax.com>,
James Meyer <the.hand> wrote:

On Tue, 8 Mar 2005 03:04:44 +0000 (UTC), kensmith@green.rahul.net (Ken Smith)
wroth:

In article <nu0q211iu4odisd8kqoqlhhhmf2899a483@4ax.com>,
John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
[...]
Right. It might be difficult to get an oscillator that's sufficiently
g-insensitive to make this work.

An atomic clock or Laser may be required.

--

Bullshit. 2.4 GHz rf sources are readily available. What's the doppler
shift at that frequency for 200 MPH velocities?

Why does 200MPH qualify as the speed we care about? 200MPH is kind of
fast for a over land vehicle.

The g-shift in an oscillator is dependant on the frequency of said
oscillator. ie: it is a constant % change. As a result, increasing the
frequency doesn't help.

You've also neglected the fact that the doppler only gives you the
component along direct line of sight.

Also 2.4GHz is not such a great idea in a cluttered environment. You will
get drop outs and multipathing.

--
--
kensmith@rahul.net forging knowledge