Calculating Speed with an accelerometer

[James Beck]

In article <pan.2005.03.08.02.51.36.678287@bar.net>, foo@bar.net says...

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


I think that the LDRS uses such a system.

It is how they get accurate measurements on the 1200MPH models some of
these guys have.

Jim

 

I don't think the accelerometer is a bad idea, its a senior project
afterall, here are some suggestions

1) You could limit the r/c car to travel on a smooth flat surface
2) Use a big heavy slow r/c car and soft mount your electronics on the
car with foam
3) If you want to get carried away add a analog devices gyro to your
dual axis ADXL202 accelerometer and you have a complete 2 dimensional
inertial navigation system which is a very good learning experience.
Basic idea is the gyro tells you what direction your pointing in the
then you determine your acceleration in that direction with the dual
axis accelerometer you are using. Integrate that to get your velocity
and position.
4) Take 64 or so readings of the gyro and accelerometers and average
them before using them, this will lower the noise level. Since your
integrating the accelerometer outputs, any noise left will tend to
averaged out (its the constant offsets that kill you)

The drift of analog devices gyros are good to about 70deg/hour (after
some simple calibration), so you should have plenty of accuracy for a
few minute demo before the car gets lost and doesn't know where it is.
The car should be able to drive itself around a simple maze in this
time too.

 

[John Fields]

On Tue, 08 Mar 2005 12:57:54 GMT, James Meyer <jmeyer@nowhere.net>
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?

---
If the observer is aligned axially with the direction of travel of the
transmitter,


fC
f' = ---------
C +/- v


where f is the frequency of the CW carrier radiated by the transmitter
f' is the oserved frequency
C is 3.0E9 m/s, and
v is the velocity of the transmitter.


So, at with v = 200MPH (89.3 m/s)


2.4E9Hz * 3.0E9m/s
f' = --------------------- = f +/- 71Hz.
3.0E9m/s +/- 89.3m/s


--
John Fields

 

[John Larkin]

On Tue, 08 Mar 2005 12:57:54 GMT, James Meyer <jmeyer@nowhere.net>
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?

Jim

Around 700 Hz. So if the oscillator pulls 70 Hz at max g-force, the
velocity error is 10%. 70 Hz is 0.03 PPM. You won't find a small
oscillator that will hold 0.03 PPM with even 1G of acceleration
change.

So un-bullshit.

John

 

[John Larkin]

On Tue, 08 Mar 2005 12:54:17 GMT, James Meyer <jmeyer@nowhere.net>
wrote:

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

Do the math.

John

 

[John Fields]

On Tue, 08 Mar 2005 10:12:42 -0600, John Fields
<jfields@austininstruments.com> wrote:

On Tue, 08 Mar 2005 12:57:54 GMT, James Meyer <jmeyer@nowhere.net
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?

---
If the observer is aligned axially with the direction of travel of the
transmitter,


fC
f' = ---------
C +/- v


where f is the frequency of the CW carrier radiated by the transmitter
f' is the oserved frequency
C is 3.0E9 m/s, and
v is the velocity of the transmitter.


So, at with v = 200MPH (89.3 m/s)


2.4E9Hz * 3.0E9m/s
f' = --------------------- = f +/- 71Hz.
3.0E9m/s +/- 89.3m/s

---
Oops...

C = 3.0E8, so f' ~ f +/- 700Hz.

--
John Fields

 

[Spehro Pefhany]

On Tue, 08 Mar 2005 08:17:06 -0800, the renowned John Larkin
<jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

On Tue, 08 Mar 2005 12:57:54 GMT, James Meyer <jmeyer@nowhere.net
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?

Jim



Around 700 Hz. So if the oscillator pulls 70 Hz at max g-force, the
velocity error is 10%. 70 Hz is 0.03 PPM. You won't find a small
oscillator that will hold 0.03 PPM with even 1G of acceleration
change.

So if you flip it over on the bench it will change twice that?

Easy enough to try.


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Rich Grise]

On Tue, 08 Mar 2005 12:54:17 +0000, James Meyer wrote:

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.

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.

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

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

The amount of Doppler shift at any sane velocity is less than the

stability/accuracy of any practical oscillator.

Cheers!
Rich

 

[John Larkin]

On Tue, 08 Mar 2005 12:17:09 -0500, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:

On Tue, 08 Mar 2005 08:17:06 -0800, the renowned John Larkin
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

On Tue, 08 Mar 2005 12:57:54 GMT, James Meyer <jmeyer@nowhere.net
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?

Jim



Around 700 Hz. So if the oscillator pulls 70 Hz at max g-force, the
velocity error is 10%. 70 Hz is 0.03 PPM. You won't find a small
oscillator that will hold 0.03 PPM with even 1G of acceleration
change.

So if you flip it over on the bench it will change twice that?

That's exactly the way oscillators are tested for g sensitivity. Gotta
do all directions, of course.

John

 

[Heath Hunnicutt]

On 2005-03-07, benn686@hotmail.com <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.

This sounds like fun!

| 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.

A number of posters have mentioned that there is an issue with using a
2D-accelerometer and not being able to detect rotation in the
measurement plane. A really neat web site that has what looks like a
great hobbyist part to solve this is www.sparkfun.com . Their
accelerometer catalog pages are here:
http://www.sparkfun.com/shop/index.php?shop=1&cart=194972&cat=71&

Scroll down to the IMU Combo Board. Note that they have a link under
that product to:

http://autopilot.sourceforge.net/rev2.2.html

Which is a GPL-licensed project creating autopilot software and
hardware for an R/C helicopter. The software has a Kalman filter and
utilizes GPS as well as INS and magnetic heading detection.

sparkfun.com has some really amazingly neat stuff, if you ask me. I
haven't ordered anything yet, but I will.

| 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.

Some systems have tables of the earth's magnetic field declination for
the locale and use a three-axis magnetometer.

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

I have theories but no practice on this. It would be great if you
shared your practice back to this ng or to the autopilot-devel list.

My armchair advice would be: filter vibrations mechanically first, by
using hard rubber mounts for the sensor board. Then filter vibrations
with an R/C network and DC output with a decoupling cap.

Have fun!

Heath

 

[Mac]

On Tue, 08 Mar 2005 15:06:43 +0000, James Beck wrote:

In article <pan.2005.03.08.02.51.36.678287@bar.net>, foo@bar.net says...
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


I think that the LDRS uses such a system.
It is how they get accurate measurements on the 1200MPH models some of
these guys have.

Jim

I don't know what ldrs is. A google search didn't really enlighten me. It
obviously is some kind of rocket society, but I didn't see anything about
using oscillators and Doppler effects for estimating altitude.

--Mac

 

[Ken Smith]

In article <oenr215p5ctd5tjlq5ne0l7f3q75s30oec@4ax.com>,
Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote:

On Tue, 08 Mar 2005 08:17:06 -0800, the renowned John Larkin
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:
[...]

Around 700 Hz. So if the oscillator pulls 70 Hz at max g-force, the
velocity error is 10%. 70 Hz is 0.03 PPM. You won't find a small
oscillator that will hold 0.03 PPM with even 1G of acceleration
change.

So if you flip it over on the bench it will change twice that?

Yes, almost exactly. It usually is the direction that puts the disk of
the crystal horizontal that gives the biggest change.

Also, crystals tend to shift the first time you run them through shake and
environmental testing. I'd expect that the crystal will shift if the RC
car is allowed to crash into a wall.


--
--
kensmith@rahul.net forging knowledge

 

[Mac]

On Tue, 08 Mar 2005 07:14:56 -0800, bungalow_steve wrote:

I don't think the accelerometer is a bad idea, its a senior project
afterall, here are some suggestions

1) You could limit the r/c car to travel on a smooth flat surface

This might work. You will still need to deal with bias (offset).

2) Use a big heavy slow r/c car and soft mount your electronics on the
car with foam

I don't see what good the foam does. I would rather have the thing rigidly
mounted to a rigid frame rolling on very hard wheels. Any freedom of
motion between the accelerometer and the vehicle will just lead to errors.

3) If you want to get carried away add a analog devices gyro to your
dual axis ADXL202 accelerometer and you have a complete 2 dimensional
inertial navigation system which is a very good learning experience.
Basic idea is the gyro tells you what direction your pointing in the
then you determine your acceleration in that direction with the dual
axis accelerometer you are using. Integrate that to get your velocity
and position.

Touching a hot soldering iron is a great learning experience, too.

4) Take 64 or so readings of the gyro and accelerometers and average
them before using them, this will lower the noise level. Since your
integrating the accelerometer outputs, any noise left will tend to
averaged out (its the constant offsets that kill you)

The drift of analog devices gyros are good to about 70deg/hour (after
some simple calibration), so you should have plenty of accuracy for a
few minute demo before the car gets lost and doesn't know where it is.
The car should be able to drive itself around a simple maze in this
time too.

The gyros might be OK for providing yaw information over the short term,
but I still don't think the accelerometers will work very well.

Everybody comes into a project with a different set of skills and
experiences. It is my opinion that unless the OP has a lot of talent or
some really good people on his team, he needs to keep it simple or he will
not submit a working project at the end of the allowed period.

If the floor is even half a degree out of level, the error will be totally
intolerable after 60 seconds. If my calculation is correct, the velocity
error will be something like 5 meters per second,(using v = at, with a
being 9.8m/s * sin(0.5 deg)) and the distance error, using d=0.5at^2 is
over 100 feet.

If he really wants to do telemetry, maybe he could just put a microphone
on an RC car, digitize the audio, and send it over the wireless link. It
would sort of be a spy-mobile. A camera might be even better.

Or why not just take speed off of the axle or motor?

I'm just trying to save Ben's butt.

If an accelerometer MUST be used, some ground truth needs to be applied to
rein in the drift. Maybe the car could be stopped periodically (every
couple of seconds) at which point a message would be sent to the
u-controller, somehow, telling it that the current bias readings
on the accelerometer should be zeroed out.

--Mac

 

[Ken Smith]

In article <GLnXd.761$ut5.191@newsfe2-gui.ntli.net>,
Roger Hamlett <rogerspamignored@ttelmah.demon.co.uk> wrote:
[...]

I think you could do this, by phase locking the onboard oscillator, to a
distant radio station. Given you are looking for vertical motion, which
would be perpendicular to the radio signals, this should give the required
stability.

The phase of a received RF signal changes as you get near the surface of
the earth. Since the goal is to measure the distance this would normally
be purely a confounding effect. You may want to check to see if the phase
relationship between two signals could give you the needed information.

--
--
kensmith@rahul.net forging knowledge

 

[Mac]

On Tue, 08 Mar 2005 06:17:29 +0000, Barbarian wrote:

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.

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.

There are lots of GPS receivers with much more frequent updates. They

might be too expensive, though. A slow GPS combined with full inertial
sensors might actually work, too, since the GPS data can pull the IMU back
toward reality. But I think the scope of the project would then be too
large to be realistic, unless Ben buys a packaged combination of IMU and
GPS.

--Mac

 

[Roger Hamlett]

The phase of a received RF signal changes as you get near the surface of
the earth. Since the goal is to measure the distance this would
normally
be purely a confounding effect. You may want to check to see if the
phase
relationship between two signals could give you the needed information.
Or you could just calculate an adjustment for this. It is a fairly well

measured effect.

Best Wishes

 

[James Beck]

In article <pan.2005.03.09.04.26.40.360674@bar.net>, foo@bar.net says...

On Tue, 08 Mar 2005 15:06:43 +0000, James Beck wrote:

In article <pan.2005.03.08.02.51.36.678287@bar.net>, foo@bar.net says...
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


I think that the LDRS uses such a system.
It is how they get accurate measurements on the 1200MPH models some of
these guys have.

Jim

I don't know what ldrs is. A google search didn't really enlighten me. It
obviously is some kind of rocket society, but I didn't see anything about
using oscillators and Doppler effects for estimating altitude.

--Mac


LDRS : Large and Dangerous Rocket Society.

I saw the unit being used on one of the Discovery Channel specials.

Jim

 

[Thomas Magma]

OK now we're thinking outside the box!

I like the microphone idea. I'll just add onto it if I may.
The RC car will have a certain pitch at different velocities...so why not
just FFT (and filter) the sound of the car to determine velocities. Even
when the batteries start to die, the sound of the gears will remain constant
based on any given velocity.

You could use just a pick-up mic to listen to the car, or for extended
range, use a cheap wireless mic.

Thomas


"Mac" <foo@bar.net> wrote in message
newsan.2005.03.09.04.55.20.663415@bar.net...

On Tue, 08 Mar 2005 07:14:56 -0800, bungalow_steve wrote:

I don't think the accelerometer is a bad idea, its a senior project
afterall, here are some suggestions

1) You could limit the r/c car to travel on a smooth flat surface

This might work. You will still need to deal with bias (offset).

2) Use a big heavy slow r/c car and soft mount your electronics on the
car with foam

I don't see what good the foam does. I would rather have the thing rigidly
mounted to a rigid frame rolling on very hard wheels. Any freedom of
motion between the accelerometer and the vehicle will just lead to errors.

3) If you want to get carried away add a analog devices gyro to your
dual axis ADXL202 accelerometer and you have a complete 2 dimensional
inertial navigation system which is a very good learning experience.
Basic idea is the gyro tells you what direction your pointing in the
then you determine your acceleration in that direction with the dual
axis accelerometer you are using. Integrate that to get your velocity
and position.

Touching a hot soldering iron is a great learning experience, too.

4) Take 64 or so readings of the gyro and accelerometers and average
them before using them, this will lower the noise level. Since your
integrating the accelerometer outputs, any noise left will tend to
averaged out (its the constant offsets that kill you)

The drift of analog devices gyros are good to about 70deg/hour (after
some simple calibration), so you should have plenty of accuracy for a
few minute demo before the car gets lost and doesn't know where it is.
The car should be able to drive itself around a simple maze in this
time too.

The gyros might be OK for providing yaw information over the short term,
but I still don't think the accelerometers will work very well.

Everybody comes into a project with a different set of skills and
experiences. It is my opinion that unless the OP has a lot of talent or
some really good people on his team, he needs to keep it simple or he will
not submit a working project at the end of the allowed period.

If the floor is even half a degree out of level, the error will be totally
intolerable after 60 seconds. If my calculation is correct, the velocity
error will be something like 5 meters per second,(using v = at, with a
being 9.8m/s * sin(0.5 deg)) and the distance error, using d=0.5at^2 is
over 100 feet.

If he really wants to do telemetry, maybe he could just put a microphone
on an RC car, digitize the audio, and send it over the wireless link. It
would sort of be a spy-mobile. A camera might be even better.

Or why not just take speed off of the axle or motor?

I'm just trying to save Ben's butt.

If an accelerometer MUST be used, some ground truth needs to be applied to
rein in the drift. Maybe the car could be stopped periodically (every
couple of seconds) at which point a message would be sent to the
u-controller, somehow, telling it that the current bias readings
on the accelerometer should be zeroed out.

--Mac

 

[Ken Smith]

In article <6pAXd.1558$gM2.1344@newsfe3-gui.ntli.net>,
Roger Hamlett <rogerspamignored@ttelmah.demon.co.uk> wrote:

The phase of a received RF signal changes as you get near the surface of
the earth. Since the goal is to measure the distance this would
normally
be purely a confounding effect. You may want to check to see if the
phase
relationship between two signals could give you the needed information.
Or you could just calculate an adjustment for this. It is a fairly well
measured effect.

Yes it is well measured, but that is mainly because it varies from place
to place. If it didn't, people wouldn't still be measuring it.

--
--
kensmith@rahul.net forging knowledge

 

[Mac]

On Wed, 09 Mar 2005 16:29:29 +0000, James Beck wrote:

In article <pan.2005.03.09.04.26.40.360674@bar.net>, foo@bar.net says...
On Tue, 08 Mar 2005 15:06:43 +0000, James Beck wrote:

In article <pan.2005.03.08.02.51.36.678287@bar.net>, foo@bar.net says...
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


I think that the LDRS uses such a system.
It is how they get accurate measurements on the 1200MPH models some of
these guys have.

Jim

I don't know what ldrs is. A google search didn't really enlighten me. It
obviously is some kind of rocket society, but I didn't see anything about
using oscillators and Doppler effects for estimating altitude.

--Mac


LDRS : Large and Dangerous Rocket Society.
I saw the unit being used on one of the Discovery Channel specials.

Jim

OK, well, that is interesting, but if you were trying to convince me that
the LDRS uses local oscillators on their rockets, then detects Doppler
shift from the ground, you haven't exactly succeeded. I will have to
reserve judgement. ;-)

--Mac