Acceleration

Gareth wrote:
> Hi
> 
> I am having trouble ( a lot of trouble ) trying to get meaningful and
> timely acceleration data.
> 
> In essence, I have a wheel speed sensor that picks up around 40 to 100
> pulses per wheel revolution (adjustable). This is captured by a 16bit
> Micro/DSP.
> 
> All I want to assert, with reasonable accuracy is the wheel acceleration.
> My acceleration data at the moment is all over place.
> 
> How can I filter the data in real time so that I can assert wheel
> acceleration? eg. DO I need to implement a Kalman filter or is there a
> faster way of doing this?
> 
> In other words, as a test, I have fitted this setup to a car and steady
> acceleration does not show steady acceleration data - it's all over the
> place. I can see the acceleration component, but is is saturated with
> acceleration spikes.
> 
> 
> 
Gareth,
The methood you describe is very sensitive to any errors in pulse-timing 
caused by road vibration and wheel eccentricity.  Also, if you are 
taking the readings of a driven wheel you will have the influence  of 
the pulsating torque of the engine as well.

I suggest the following:
1. Measure the time between pulses, as you are doing, and compute the 
differences.  This gives you dt/d(theta) for 40 to 100 instants per 
revolution.
2. Compute the difference between these values to give you a set of
d^2t/d(theta)^2 values.  The reciprocal of these gives you a set of 
acceleration values.
3. Average the acceleration values for one complete revolution of the 
wheel at a time to minimise errors due to wheel eccentricity.
4. If you can afford a slower response, put the acceleration values 
through a FIR filter, the longer the better.

Regards,
John

Gareth wrote:


>>
>>You have got a trivial bug somewhere. Fix your code.
>>
> Thanks for the pointer!
> Seriouly though, I have been at this for weeks.

Then you are not trying hard enough. The task is trivial, it had been 
done many times by many people.

> have tried different target systems, different code, Quad Encoders,
> Interrupts, DMA, Capture ports etc  I have even tried buffering all of the
> data, dumping it to a pc and then writing VB code to perform the math - The
> result is always similar.

Did you check if the input signal has nice and clean transitions? It is 
very typical to have the false input capture triggers because of the 
ripples. That can be fixed by the LPF + Shmidt trigger in the hardware 
or by the state machine in the software. The idea is ignore the states 
which last for less then X microseconds.

> I think it has somthing to do with the fact that
> the timer capture value changes slighly from pulse to pulse even with a
> function generator giving a steady square wave.

Of course. The clocks can't be perfectly synchronous.

> This must be due to the
> fact that it is catching the timer increment halfway. I guess that I need
> some kind of filter to quash these differences?

Before falling into the abyss of shamanism and rocket science, fix the 
trivial bugs.



Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

>Gareth wrote:
>> Hi
>> 
>> I am having trouble ( a lot of trouble ) trying to get meaningful and
>> timely acceleration data.
>> 
>> In essence, I have a wheel speed sensor that picks up around 40 to 100
>> pulses per wheel revolution (adjustable). This is captured by a 16bit
>> Micro/DSP.
>> 
>> All I want to assert, with reasonable accuracy is the wheel
acceleration.
>> My acceleration data at the moment is all over place.
>> 
>> How can I filter the data in real time so that I can assert wheel
>> acceleration? eg. DO I need to implement a Kalman filter or is there a
>> faster way of doing this?
>> 
>> In other words, as a test, I have fitted this setup to a car and
steady
>> acceleration does not show steady acceleration data - it's all over
the
>> place. I can see the acceleration component, but is is saturated with
>> acceleration spikes.
>> 
>> 
>> 
>Gareth,
>The methood you describe is very sensitive to any errors in pulse-timing

>caused by road vibration and wheel eccentricity.  Also, if you are 
>taking the readings of a driven wheel you will have the influence  of 
>the pulsating torque of the engine as well.
>
>I suggest the following:
>1. Measure the time between pulses, as you are doing, and compute the 
>differences.  This gives you dt/d(theta) for 40 to 100 instants per 
>revolution.
>2. Compute the difference between these values to give you a set of
>d^2t/d(theta)^2 values.  The reciprocal of these gives you a set of 
>acceleration values.
>3. Average the acceleration values for one complete revolution of the 
>wheel at a time to minimise errors due to wheel eccentricity.
>4. If you can afford a slower response, put the acceleration values 
>through a FIR filter, the longer the better.
>
>Regards,
>John
>

Hi John

Thank you for your reply. Most helpful. Please may I ask you to help me
through your formulas so that I can implement them.

You have given:  A.) dt/d(theta) and B.) d^2t/d(theta)^2 

I take it that in A, dt is the difference in time, what is d(theta)?

Sorry if I am coming accross as dumb, I just need some clarity please.
Do you have any simple working examples that I can play about with?

..Gareth

On Tue, 30 Oct 2007 08:43:31 -0500, Gareth wrote:

>>Hi
>>
>>I am having trouble ( a lot of trouble ) trying to get meaningful and
>>timely acceleration data.
>>
>>In essence, I have a wheel speed sensor that picks up around 40 to 100
>>pulses per wheel revolution (adjustable). This is captured by a 16bit
>>Micro/DSP.
>>
>>All I want to assert, with reasonable accuracy is the wheel
> 
> acceleration.
>>My acceleration data at the moment is all over place.
>>
>>How can I filter the data in real time so that I can assert wheel
>>acceleration? eg. DO I need to implement a Kalman filter or is there a
>>faster way of doing this?
>>
>>In other words, as a test, I have fitted this setup to a car and steady
>>acceleration does not show steady acceleration data - it's all over the
>>place. I can see the acceleration component, but is is saturated with
>>acceleration spikes.
>>
> Sorry, I did'nt fully answer your question:
> Yes, I am using 'always on' interrupts. They capture a timer value on edge
> 
> detection. I manually reset the timer in the ISR. The interrrupt's latency
> 
> on this device is apparently 7 cycles.

Resetting the timer in the ISR is almost certainly a bad idea.  You'll
have some inevitable interrupt latency, and it'll vary, so you're
guaranteeing yourself noise by resetting the timer.  This noise will get
multiplied by a huge amount because you're looking for very small changes.

Instead of resetting the timer, let it free run and calculate the
resulting time deltas using (current value) - (past value).  If you use
registers that are the same width as the timer then your timer rollover
will be automatically compensated for (i.e. if your last read value
was 0xfe00 and you've gone for 768 (0x0300) timer ticks then the
timer performs the operation 0xfe00 + 0x0300 = 0x0100.  Then you
come along and perform the operation 0x0100 - 0xfe00 = 0x300 to get a
measure of time).

That's won't eliminate all your problems -- you are using a technique that
will be exquisitely sensitive to all of your noise sources, and as has
been mentioned elsewhere you have plenty of noise sources to contend with.
About the only things you can do with this is to either improve your
sensor or to recognize that you can't get good instantaneous acceleration
values and filter the heck out of what readings you get.

Kalman filters and alpha-beta filters have been mentioned.  Either of
these will work, but at root both a steady state Kalman and an alpha-beta
filter will give you a 2nd-order bandlimited differentiator on position --
and you can just do that yourself and dink with the values until you get
something that works.  If going through the Kalman or the alpha-beta
construction process helps, then by all means do it, but don't forget what
the end result will inevitably be.

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

On Oct 30, 6:58 am, "Gareth" <gar...@nonick.net> wrote:
> >On Oct 30, 4:12 am, "Gareth" <gar...@nonick.net> wrote:
> >> Hi
>
> >> I am having trouble ( a lot of trouble ) trying to get meaningful and
> >> timely acceleration data.
>
> >> In essence, I have a wheel speed sensor that picks up around 40 to 100
> >> pulses per wheel revolution (adjustable). This is captured by a 16bit
> >> Micro/DSP.
>
> >> All I want to assert, with reasonable accuracy is the wheel
> acceleration.
> >> My acceleration data at the moment is all over place.
>
> >> How can I filter the data in real time so that I can assert wheel
> >> acceleration? eg. DO I need to implement a Kalman filter or is there a
> >> faster way of doing this?
>
> >> In other words, as a test, I have fitted this setup to a car and
> steady
> >> acceleration does not show steady acceleration data - it's all over
> the
> >> place. I can see the acceleration component, but is is saturated with
> >> acceleration spikes.
>
> >You need a higher resolution encoder.  Get the highest number of
> >counts per revolution that will not exceed the counter limits.
> >I recommend you look into a steady state Kalman filter or observer.
>
> >Peter Nachtwey
>
> Hi Peter
>
> Thanks for the reply. I am currently using a resolution of 200nS but can
> go to 25nS. I will try that next. (it's not so simple as the timer
> overflows at low to moderate speeds). How do I implement a steady state
> Kalman filter / where can I find out more information on this?

Dan Simon has a book on Kalman filters.  I don't have it at work so I
can give you the name bit it does have a section on alpha-beta and
alpha-beta-gamma filters that is much easier to implement than the
full blown Kalman filter.

These filters work by sampling at fixed time intervals, not by
sampling the time between the counts.  When sampling at fixed time
increments it is best to have as many counts per revolution as
possible.

Lets say the circumference of the wheel is 1 meter and you have only
100 counts per revolution.  If the update time is 10 milliseconds then
the minimum detectable resolution is dist/T^2 or 0.01m/(0.01s)^2 which
is 100 m/s^2 which is unusable since you aren't going into space,
hopefully.  If you have 10000 counts per rev then you can detect 1 m/
s^2   or 0.00001/(0.01s) = 1 m/s^2.  Here is where the Kalman filter
or alpha-beta-gamma filter comes in because it can smooth out the data
a lot so your resolution is will be about 0.01 to 0.5 m/s^2 depending
on the filter parameters.

You should be able to do these calculations easily in 10
milliseconds.  If not then you may need to increase the period but as
you increase the period the minimum detectable accelerations
decreases.  You didn't say how often you needed an update.  Hopefully
a 10000 count encoder is available.   Actually you should be able to
get by with a 2500 line encoder because the each phase is counted by
the encoder count so it multiplies the lines by four.

So can you count encoder counts instead of the time between the
counts.
Can your counter mulitply the lines by 4?
How often do you need to update the acceleration?
Can you get a high resolution encoder?
What is the circumference of the wheel?

Peter Nachtwey

A lot of folks have mentioned the high degree of sensitivity but I didn't 
see anyone directly mention this:

You say you have a wheel speed sensor.  Is it really a speed sensor or is it 
a position sensor?  For example, determining the times a segmented tach 
wheel changes state is sensing position.

But, I digress from my main point.
If you are really measuring velocity at instants of time then you have to 
difference or differentiate in order to get acceleration.  If you are 
actually measuring position, then you have to differentiate twice to get 
acceleration.

It's well known that differentiation is a "noisy process".  Double 
differentiation ... oh my!  This means that any errors in the process are 
going to be accentuated.  Consider this:  What happens if you differentiate 
a sinusoid?  What happens if you differentiate a noisy sinusoid?  In the 
first case you get a sinusoid.  In the second case you get an even noisier 
sinusoid than the one you started with because all the high frequencies are 
accentuated by the differentiator ( a type of high pass filter).

The best results I've been able to achieve with using a differentiator to 
compute velocity from position did this:
- first lowpass the data as much as you can stand in order to remove input 
noise.
- then differentiate.
- then lowpass again to smooth the result.
This way you can adjust the two lowpass filters separately to get the best 
results.  I suppose that linear systems theory suggests the 
post-differentiator lowpass can be lumped into the input lowpass.  Maybe do 
that after the design is done - if the dynamic range and such things will 
allow it.  I really don't think that I'd try to do all the lowpass filtering 
at the output of the differentiator....

Fred 

Fred Marshall wrote:
> A lot of folks have mentioned the high degree of sensitivity but I didn't 
> see anyone directly mention this:
> 
> You say you have a wheel speed sensor.  Is it really a speed sensor or is it 
> a position sensor?  For example, determining the times a segmented tach 
> wheel changes state is sensing position.
> 
> But, I digress from my main point.
> If you are really measuring velocity at instants of time then you have to 
> difference or differentiate in order to get acceleration.  If you are 
> actually measuring position, then you have to differentiate twice to get 
> acceleration.
> 
> It's well known that differentiation is a "noisy process".  Double 
> differentiation ... oh my!  This means that any errors in the process are 
> going to be accentuated.  Consider this:  What happens if you differentiate 
> a sinusoid?  What happens if you differentiate a noisy sinusoid?  In the 
> first case you get a sinusoid.  In the second case you get an even noisier 
> sinusoid than the one you started with because all the high frequencies are 
> accentuated by the differentiator ( a type of high pass filter).
> 
> The best results I've been able to achieve with using a differentiator to 
> compute velocity from position did this:
> - first lowpass the data as much as you can stand in order to remove input 
> noise.
> - then differentiate.
> - then lowpass again to smooth the result.
> This way you can adjust the two lowpass filters separately to get the best 
> results.  I suppose that linear systems theory suggests the 
> post-differentiator lowpass can be lumped into the input lowpass.  Maybe do 
> that after the design is done - if the dynamic range and such things will 
> allow it.  I really don't think that I'd try to do all the lowpass filtering 
> at the output of the differentiator....

Fred,

Are there any digital velocity sensors? Even for analog, a good one is 
hard to come by. The usual kind of wound tachometer has scalloping from 
the commutator effect and the brush drop can introduce significant 
error. There are ways around these defects. The best I ever used was a 
homopolar generator with mercury "brushes" driving a hall-effect current 
sensor. That was eventually replaced with a two-phase encoder with 2000 
lines per track, yielding 4000 cycles out of an XOR gate.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

"Jerry Avins" <jya@ieee.org> wrote in message 
news:r-SdnUlYoaBba7ranZ2dnUVZ_gGdnZ2d@rcn.net...

>
> Fred,
>
> Are there any digital velocity sensors? Even for analog, a good one is 
> hard to come by. The usual kind of wound tachometer has scalloping from 
> the commutator effect and the brush drop can introduce significant error. 
> There are ways around these defects. The best I ever used was a homopolar 
> generator with mercury "brushes" driving a hall-effect current sensor. 
> That was eventually replaced with a two-phase encoder with 2000 lines per 
> track, yielding 4000 cycles out of an XOR gate.
>


Jerry,

I don't know.  I've only used a 1000 line tach for a phase-locked speed 
servo - which is actually a position servo in the guts of it - since the 
phase lock is on the position of the tach lines.

I think the Navy is still using the differentiating velocity measurizer I 
designed into a tester in the 60's.  It ran off of a film-based 
potentiometer - position sensor.  Wire-wound would have been a disaster! 
The pickoff noise and the motor (being measured) jitter were bad enough!  It 
worked but what a kludge.

Fred

Hello Again.

I must say that I am overwhelmed by the help and feedback that I have
received so far. It has given me ideas to try, which I am busy doing.
The math, I must say, I am finding difficult (Kalman Filters etc) as I
can't seems to find any working examples to adapt / play with. I will try
and adapt the thoery papers I have read, if  a filter is needed at all.

To put it into persepective, the setup is as follows:

The sensor is a Hall Effect digital out sensor (very good and noise
free).
It is a very noisy environment, so there is bound to be noise on the
cables connecting the sensor to my system board.

The system board itself has the digital sensor input coming into a Scmitt
Trigger which the passes the signal directly to the input pin of the DSP.

The wheel has a rolling circumference of 1990mm and the 'vane' has fourty
slots in it (some have 64+ slots), so fourty pluses per revolution. The
Dynamic range needs to be 10MPH to 200MPH (89Hz to 1786 Hz).

The response time for calculating acceleration needs to be as fast as
possible. Currently I am working on 40 pulses per calculation, which
equates to one wheel revolution, idealy I would like to change this to 10
or 20 pulses per solution.

On Oct 31, 2:37 am, "Gareth" <gar...@nonick.net> wrote:
> Hello Again.
>
> I must say that I am overwhelmed by the help and feedback that I have
> received so far. It has given me ideas to try, which I am busy doing.
> The math, I must say, I am finding difficult (Kalman Filters etc) as I
> can't seems to find any working examples to adapt / play with. I will try
> and adapt the thoery papers I have read, if  a filter is needed at all.
>
> To put it into persepective, the setup is as follows:
>
> The sensor is a Hall Effect digital out sensor (very good and noise
> free).
> It is a very noisy environment, so there is bound to be noise on the
> cables connecting the sensor to my system board.
>
> The system board itself has the digital sensor input coming into a Scmitt
> Trigger which the passes the signal directly to the input pin of the DSP.
>
> The wheel has a rolling circumference of 1990mm and the 'vane' has fourty
> slots in it (some have 64+ slots), so fourty pluses per revolution. The
> Dynamic range needs to be 10MPH to 200MPH (89Hz to 1786 Hz).
>
> The response time for calculating acceleration needs to be as fast as
> possible. Currently I am working on 40 pulses per calculation, which
> equates to one wheel revolution, idealy I would like to change this to 10
> or 20 pulses per solution.

I would look at using an acceleromter. They are easy to use.

Peter Nachtwey