Position and velocity from accelerometer

We have a "cybex" type machine, designed to apply velocity, acceleration
and jerks to the lower limb about the knee.  If one thinks of a clock, the
"Limb Arm" is in the position of the big hand of the clock.  It moves from
the "5"
position to the "9" o'clock position and back again.  The Leg of our
subject is in front of the clock such that the axis of the knee and the
axis of the clock coincide.  When the "Limb arm" swings so does the lower
limb.  At the outer tip of the "Limb Arm" is a one degree of freedom
accelerometer aligned with the tangent to the arc of the movement. Thus
it's output (scaled and multiplied by the length of the arm) measures
angular acceleration.  In addition, there is an encoder mounted on the
"clock shaft"  Both devices (encoder and accelerometer) have proven to be
noisy.  I need accurate values of velocity which I'm trying to obtain by
integrating acceleration to eliminate noise.  There appears to be drift in
the accelerometer such that velocity never returns to zero when 9 o'clock
is reached and is even worse when 5 o'clock is returned to.  The encoder,
on the other hand, fails to capture velocity overshoots during the move.
Work that I've read on Kalman filters say that you can use one transducer
to correct another.  But I have not be able to find out how.  I believe I
understand th basic formula's:
x(t+1) = Ax(t) + Bu(t) + w
y(x) = Cx(t) + n
Where w and n represent noise but how do I use two transducers to correct
the noise in each other?
Jim Fee

Integrating acceleration gives velocity, but the error grows with
time.
Given that the limb length is known, why not use the shaft encoder to
infer position, then differentiate position to give you velocity.

velocity = distance / time. The shaft encoder gives you the limb
angle, from which you can infer the end of limb position. An time you
measure.

The accelerometer is not just measuring angular acceleration, there is
also a gravity component as well.

The accelerometers I have used often have a capacitor that can be
changed to select the low pass rolloff on the analog accelerometer
signal. In the sensors I used a large portion of noise was
proportional to the accelerometer bandwidth. By selecting a lower
filter cutoff, the noise was reduced, at the cost of a slower response
from the accelerometer. Which is often just fine, depending on how
quickly you expect the acceleration to change in your object.

In our application we did end up using a Kalman filter with some
success, but I would suggest trying the easy stuff first?

Cheers
Andrew

"Jim Fee" <fee@gait.aidi.udel.edu> wrote in
news:RYSdnXnD2Mlsxq7anZ2dnUVZ_oKhnZ2d@giganews.com: 

> We have a "cybex" type machine, designed to apply velocity,
> acceleration and jerks to the lower limb about the knee.  If one
> thinks of a clock, the "Limb Arm" is in the position of the big hand
> of the clock.  It moves from the "5"
> position to the "9" o'clock position and back again.  The Leg of our
> subject is in front of the clock such that the axis of the knee and
> the axis of the clock coincide.  When the "Limb arm" swings so does
> the lower limb.  At the outer tip of the "Limb Arm" is a one degree of
> freedom accelerometer aligned with the tangent to the arc of the
> movement. Thus it's output (scaled and multiplied by the length of the
> arm) measures angular acceleration.  In addition, there is an encoder
> mounted on the "clock shaft"  Both devices (encoder and accelerometer)
> have proven to be noisy.  I need accurate values of velocity which I'm
> trying to obtain by integrating acceleration to eliminate noise. 
> There appears to be drift in the accelerometer such that velocity
> never returns to zero when 9 o'clock is reached and is even worse when
> 5 o'clock is returned to.  The encoder, on the other hand, fails to
> capture velocity overshoots during the move. Work that I've read on
> Kalman filters say that you can use one transducer to correct another.
>  But I have not be able to find out how.  I believe I understand th
> basic formula's: x(t+1) = Ax(t) + Bu(t) + w
> y(x) = Cx(t) + n
> Where w and n represent noise but how do I use two transducers to
> correct the noise in each other?
> Jim Fee
> 
> 
> 
> 

Why not just measure angular velocity directly??

http://www.analog.com/en/subCat/0,2879,764%255F801%255F0%255F%255F0%
255F,00.html

These devices tend to be fairly insensitive to eccentricity from the axis 
of rotation.



-- 
Scott
Reverse name to reply

Jim Fee wrote:
> We have a "cybex" type machine, designed to apply velocity, acceleration
> and jerks to the lower limb about the knee.  If one thinks of a clock, the
> "Limb Arm" is in the position of the big hand of the clock.  It moves from
> the "5"
> position to the "9" o'clock position and back again.  The Leg of our
> subject is in front of the clock such that the axis of the knee and the
> axis of the clock coincide.  When the "Limb arm" swings so does the lower
> limb.  At the outer tip of the "Limb Arm" is a one degree of freedom
> accelerometer aligned with the tangent to the arc of the movement. Thus
> it's output (scaled and multiplied by the length of the arm) measures
> angular acceleration.  In addition, there is an encoder mounted on the
> "clock shaft"  Both devices (encoder and accelerometer) have proven to be
> noisy.  I need accurate values of velocity which I'm trying to obtain by
> integrating acceleration to eliminate noise.  There appears to be drift in
> the accelerometer such that velocity never returns to zero when 9 o'clock
> is reached and is even worse when 5 o'clock is returned to.  The encoder,
> on the other hand, fails to capture velocity overshoots during the move.
> Work that I've read on Kalman filters say that you can use one transducer
> to correct another.  But I have not be able to find out how.  I believe I
> understand th basic formula's:
> x(t+1) = Ax(t) + Bu(t) + w
> y(x) = Cx(t) + n
> Where w and n represent noise but how do I use two transducers to correct
> the noise in each other?

There must be more here than I can see. To measure velocity from 
acceleration, integration is necessary. Even digital integrators drift. 
  (How is left as an exercise for the reader. Answer on request.) 
Velocity requires one integration, position two. Ouch!

What does your accelerometer indicate when it is stationary at the 9:00 
position? My best guess is g; how do you correct for that? (The 
acceleration when stationary at 5:00 should be g/2.)

What is noisy about the encoder? Improperly connected, an encoder can 
indicate movement in one direction when it is merely vibrating. There 
are several circuits that eliminate that difficulty. The one with my 
name on the patent also doubles the resolution of any particular 
encoder. If that's not the problem, put the photocell-to-logic-level 
circuit near the encoder. If that's not feasible, at least use shielded 
cable. In the worst cases, use an instrumentation amplifier per channel 
before the Schmitt triggers. (You do use Schmitt triggers, don't you?)

Instrumenting machinery is an art. One of the lessons one learns when 
practicing it is /Don't infer what you can measure./ You have an encoder 
that can measure position. Why even think about using trigonometry on 
the result of a double integration to correct the integrand before the 
next iteration? Another lesson: /If a signal is noisy, find out why./ 
It's likely that once you know, the noise can be easily suppressed. A 
third lesson: /The simpler method is usually more robust./ A Kalman 
filter to deal with noise is not as simple as a transducer with a clean 
signal. Unless you want to measure acceleration, you are likely to be 
better off without without an accelerometer. Given that you operate in a 
gravitational  -- constant acceleration downward -- field, you might 
better get angular acceleration some other way.

If you can't figure out why digital integrators drift in the real world 
but are embarrassed to admit it in public, you are welcome to email me 
privately. My address is valid.

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

Jerry Avins <""jya\"@ieee,org"> writes:

> There must be more here than I can see. To measure velocity from
> acceleration, integration is necessary. Even digital integrators
> drift. (How is left as an exercise for the reader. Answer on request.)

How? I'm assuming that quantization isn't the issue here since
by definition the input to a digital integrator is already digital.
And I can see you'd potentially get overflow, but I wouldn't consider
that "drift."
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://www.digitalsignallabs.com

Jerry Avins <""jya\"@ieee,org"> writes:

> There must be more here than I can see. To measure velocity from
> acceleration, integration is necessary. Even digital integrators
> drift. (How is left as an exercise for the reader. Answer on request.)

How? I'm assuming that quantization isn't the issue here since
by definition the input to a digital integrator is already digital.
And I can see you'd potentially get overflow, but I wouldn't consider
that "drift."
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://www.digitalsignallabs.com

Jerry Avins <""jya\"@ieee,org"> writes:

> There must be more here than I can see. To measure velocity from
> acceleration, integration is necessary. Even digital integrators
> drift. (How is left as an exercise for the reader. Answer on request.)

How? I'm assuming that quantization isn't the issue here since
by definition the input to a digital integrator is already digital.
And I can see you'd potentially get overflow, but I wouldn't consider
that "drift."
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://www.digitalsignallabs.com

Jerry Avins <""jya\"@ieee,org"> writes:

> There must be more here than I can see. To measure velocity from
> acceleration, integration is necessary. Even digital integrators
> drift. (How is left as an exercise for the reader. Answer on request.)

How? I'm assuming that quantization isn't the issue here since
by definition the input to a digital integrator is already digital.
And I can see you'd potentially get overflow, but I wouldn't consider
that "drift."
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://www.digitalsignallabs.com

Jerry Avins <""jya\"@ieee,org"> writes:

> There must be more here than I can see. To measure velocity from
> acceleration, integration is necessary. Even digital integrators
> drift. (How is left as an exercise for the reader. Answer on request.)

How? I'm assuming that quantization isn't the issue here since
by definition the input to a digital integrator is already digital.
And I can see you'd potentially get overflow, but I wouldn't consider
that "drift."
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://www.digitalsignallabs.com

Jerry Avins <""jya\"@ieee,org"> writes:

> There must be more here than I can see. To measure velocity from
> acceleration, integration is necessary. Even digital integrators
> drift. (How is left as an exercise for the reader. Answer on request.)

How? I'm assuming that quantization isn't the issue here since
by definition the input to a digital integrator is already digital.
And I can see you'd potentially get overflow, but I wouldn't consider
that "drift."
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://www.digitalsignallabs.com