Angular position measurement using accelerometer - DSP approaches?

Avoid typing the same text again and again
Stop wasting your time on mouse movements
Open favorite web pages with a single hotkey press
Record keystrokes and play them back with a single hotkey press
------------------------------
http://www30.webSamba.com/SmartStudio
------------------------------
EnergyKey   Save yourself from repetitive tasks

Thanks Fred.

>
> John,
>
> Instead of presuming a solution and asking only about the algorithm, maybe
> ask: "How would you do it with only the sensor that's available?"
Ok fair enough, I'm all ears :)

> After all those perpendicular transformations, do I understand that the axis
> of rotation is parallel with the ground?
Yes yes yes. I really should have stated that at the very beginning!.
The machine is mounted  in such a way that we can gaurantee the axis of
rotation is parallel with the ground. I'm sure there will be some small
alignment error though.

> An approach would be to postulate all of the signal components:
>
> - gravity
> - centrifugal acceleration
> - terms due to misalignment unless it's guaranteed to be perfect.
Also angular acceleration. I think all the other terms will effectively
be noise. I can't accurately quantify them - we are setting up a demo
to measure that.

> Once the likely signal structure is known then it's easier to imagine the
> types of signal processing things that might be needed.
>
> You said you wanted angular position.  One way is to measure the affect of
> gravity, isn't it?  that gives you a result that is only ambiguous as to
> quadrant - as long as you have a maximum gravity reference and as long as
> you can accurately subtract everything else.  Then all you have to do is
> resolve the quadrant which seems a simple matter of knowing the rotation
> direction and whether the measurement occurs before or after the positive or
> negative peak.  The sign of the measurement tells you which 2 of 4 quadrants
> to resolve completely then.
I think you can resolve to better than just a quadrant. E.g the max
value will occured at specific position.


> You say that the machine is rotating - so may one assume that you mean it
> rotates at some relatively fixed angular velocity?  Or, does it simply move
> from one angle to another and stop?
> This likely affects how signals will be constructed.
Original statement was from 10Hz to 50 Hz rotation rate.

> Just arm-waving thoughts:
>
> With constant angular velocity, gravity will be a sinusoid.
> With constant angular velocity, centrifugal acceleration will be a constant.
Yes this is the concept. But even if angular velocity is changing (say
at a constant rate :) ) then the "gravity" will still be approx
sinusoidal.

> So, given the sinusoid, you are interested in its phase - which is directly
> proportional to angular position.
Yes agree.

> You want to know the phase to an accuracy of 10 degrees or 1/36th of a
> rotation or to an accuracy of 1/(50*36) = 0.5555msec.   So, I'd consider
> using 1/(50*50) or 0.4msec or less as a data rate.  So, this probably
> implies a sample rate of greater than 5kHz which is 50Hz x 50 x 2.
The sensor has an analog bandwidth of 2.2kHz. Will sample at 10ksps to
start with.

> If you are going to pass the data through a filter at 5kHz sample rate then
> there would be precious little delay possible as measured in sample times
> unless you are willing to have the resulting output delayed.  I get the
> impression that the output has to be in real time.  So, that lets out any
> filtering I believe.
Yes the output has to be in real time, but if the angular velocity is
realtively constant then would the filter delay still be a problem...

> The only hope for filtering is a filter that would not delay the signal for
> more than 0.5msec.  This implies a filter with frequency transitions that
> are not narrower than 2000Hz.  Not much help here I'm afraid.
>
> Your implementation is sorta like having a tachometer that outputs only a
> couple of blips per rotation.  How do you get good resolution between blips?
> You don't.
I don't quite agree. If I know the max and min acc value, and that the
angular velocity is changing only slowly, and I know the sensor output
varies in a sinusoid manner, then I can work backwards and figure out
the position.
(Can also add more accelerometers but thats an expensive solution).

> You might differentiate to get velocity but I don't recommend it because
> differentiation is noisy.  Maybe offset the accelerometer and measure
> centrifugal acceleration?
>
> If you're stuck on the accelerometer approach then you might do something
> like this:
>
> Subtract out a constant that is generated to approximate the centrifugal
> acceleration term. Presumably this is a function of angular velocity.
> Presumably this can be a longer term estimating process if the angular
> accelerations aren't too great - if the angular velocity is relatively
> stable.

> The subtraction can be relatively instantaneous.
>
> Then, the magnitude of the sinusoid in the signal remains.  If you know the
> peak value then the angle can be estimated from the instantaneous value and
> the peak.
>
> I'd get a tachometer with a bunch of segments instead - or, better yet, a
> shaft encoder.
Have ruled these out because of the environment and physical
constraints on the machine.

Many thanks for your ideas/questions/comments etc. 
Regards
John

<john.dsp0@gmail.com> wrote in message 
news:1150096545.979541.240860@g10g2000cwb.googlegroups.com...
> Thanks Fred.
>
>>
>> John,
>>
>> Instead of presuming a solution and asking only about the algorithm, 
>> maybe
>> ask: "How would you do it with only the sensor that's available?"
> Ok fair enough, I'm all ears :)
>
>> After all those perpendicular transformations, do I understand that the 
>> axis
>> of rotation is parallel with the ground?
> Yes yes yes. I really should have stated that at the very beginning!.
> The machine is mounted  in such a way that we can gaurantee the axis of
> rotation is parallel with the ground. I'm sure there will be some small
> alignment error though.
>
>> An approach would be to postulate all of the signal components:
>>
>> - gravity
>> - centrifugal acceleration
>> - terms due to misalignment unless it's guaranteed to be perfect.
> Also angular acceleration. I think all the other terms will effectively
> be noise. I can't accurately quantify them - we are setting up a demo
> to measure that.
The bias that you see due to misalignment*angular velocity will depend (as I 
think Jerry inferred) on the radius from the axis of rotation to your 
accelerometer. The angular acceleration term will also depend on this ( I 
think) - are you expecting to mount this on the side of an accessible shaft 
or on a surface close to but normal to the axis of rotation?  If so this 
also ought to minimise the power associated with a fair bit of bearing slop 
and gear chatter.
>
>> Once the likely signal structure is known then it's easier to imagine the
>> types of signal processing things that might be needed.
>>
>> You said you wanted angular position.  One way is to measure the affect 
>> of
>> gravity, isn't it?  that gives you a result that is only ambiguous as to
>> quadrant - as long as you have a maximum gravity reference and as long as
>> you can accurately subtract everything else.  Then all you have to do is
>> resolve the quadrant which seems a simple matter of knowing the rotation
>> direction and whether the measurement occurs before or after the positive 
>> or
>> negative peak.  The sign of the measurement tells you which 2 of 4 
>> quadrants
>> to resolve completely then.
> I think you can resolve to better than just a quadrant. E.g the max
> value will occured at specific position.
>
>
>> You say that the machine is rotating - so may one assume that you mean it
>> rotates at some relatively fixed angular velocity?  Or, does it simply 
>> move
>> from one angle to another and stop?
>> This likely affects how signals will be constructed.
> Original statement was from 10Hz to 50 Hz rotation rate.
>
>> Just arm-waving thoughts:
>>
>> With constant angular velocity, gravity will be a sinusoid.
>> With constant angular velocity, centrifugal acceleration will be a 
>> constant.
> Yes this is the concept. But even if angular velocity is changing (say
> at a constant rate :) ) then the "gravity" will still be approx
> sinusoidal.
>
>> So, given the sinusoid, you are interested in its phase - which is 
>> directly
>> proportional to angular position.
> Yes agree.
>
>> You want to know the phase to an accuracy of 10 degrees or 1/36th of a
>> rotation or to an accuracy of 1/(50*36) = 0.5555msec.   So, I'd consider
>> using 1/(50*50) or 0.4msec or less as a data rate.  So, this probably
>> implies a sample rate of greater than 5kHz which is 50Hz x 50 x 2.
> The sensor has an analog bandwidth of 2.2kHz. Will sample at 10ksps to
> start with.
>
>> If you are going to pass the data through a filter at 5kHz sample rate 
>> then
>> there would be precious little delay possible as measured in sample times
>> unless you are willing to have the resulting output delayed.  I get the
>> impression that the output has to be in real time.  So, that lets out any
>> filtering I believe.
> Yes the output has to be in real time, but if the angular velocity is
> realtively constant then would the filter delay still be a problem...
If you have upper limits on your angular acceleration then you may be able 
to calulate how much of your positional inaccuracy to budget to lack of 
knowledge of the angular acceleration since your filtered estimate center of 
phase.
>
>> The only hope for filtering is a filter that would not delay the signal 
>> for
>> more than 0.5msec.  This implies a filter with frequency transitions that
>> are not narrower than 2000Hz.  Not much help here I'm afraid.
>>
>> Your implementation is sorta like having a tachometer that outputs only a
>> couple of blips per rotation.  How do you get good resolution between 
>> blips?
>> You don't.
> I don't quite agree. If I know the max and min acc value, and that the
> angular velocity is changing only slowly, and I know the sensor output
> varies in a sinusoid manner, then I can work backwards and figure out
> the position.
> (Can also add more accelerometers but thats an expensive solution).
>
>> You might differentiate to get velocity but I don't recommend it because
>> differentiation is noisy.  Maybe offset the accelerometer and measure
>> centrifugal acceleration?
>>
>> If you're stuck on the accelerometer approach then you might do something
>> like this:
>>
>> Subtract out a constant that is generated to approximate the centrifugal
>> acceleration term. Presumably this is a function of angular velocity.
>> Presumably this can be a longer term estimating process if the angular
>> accelerations aren't too great - if the angular velocity is relatively
>> stable.
>
>> The subtraction can be relatively instantaneous.
>>
>> Then, the magnitude of the sinusoid in the signal remains.  If you know 
>> the
>> peak value then the angle can be estimated from the instantaneous value 
>> and
>> the peak.
>>
>> I'd get a tachometer with a bunch of segments instead - or, better yet, a
>> shaft encoder.
> Have ruled these out because of the environment and physical
> constraints on the machine.
I have to agree with Fred that you should really, really be sure that you 
don't want a tacho solution , you can get some nice laser based tachos to 
sense the distance to a lightweight profiled disk or a band glued round a 
shaft - not very sensitive to dirt and oil as the reflecting surface is 
under slick clear plastic which maybe can be wiped in motion? Alternatively 
non-contacting magnetic resolvers and one or more pick up coils nearby might 
be a possibility.
You mention battery powering your accelerometer sensor - how do you get your 
signals out?


>
> Many thanks for your ideas/questions/comments etc.
> Regards
> John
> 

Un bel giorno john.dsp0@gmail.com digit�:

> No we don't have an independent way. From what I understand a rate gyro
> is just a 3 dimensional accelerometer.

Not at all, they work differently as they measure different things.
Triaxial accelerometers can't measure angular speeds.

Your work would be much easier if you use a gyroscope to determine the
angular speed, so that you can calculate the centripetal force and remove
it from the acceleration. With your accelerometer you will read an
acceleration module composed as follows:

atot=acent+agrav*cos(theta)

Where acent is the centripetal acceleration, agrav is gravitational
acceleration (9.81 m/s^2) and theta is the angular position in respect to
the accelerometer positive direction. And you can calculate acent as
follows:

acent=omega^2*r

Where omega is the angular speed and r is the distance of the accelerometer
from the center of rotation. Thus,

theta=arccos((atot-omega^2*r)/9.81)

-- 
asd

john.dsp0@gmail.com wrote:
> Thanks Tim, my response below.
> 
>>>My crude algorithm was to find the max/min acceleration points and this
>>>tells you when the sensor is aligned with the gravity field, and thus
>>>position. Is this a sensible first approach? or way too simplistic?
>>
>>I would choose the zero crossings around average, myself.  If I could
>>know the rotation rate (maybe with an accompanying rate gyro?) I would
>>demodulate it with a sine wave.
> 
> I didn't state it, but as well as knowing the position we also want to
> know the rotation rate and I was hoping this would also be an output of
> the algorithm. The time between zero crossings as you put it, or the
> max/min acc values would give the rotation rate - assuming a constant
> angular velocity.
> Demodulate it...Which means multiply I think, ... so I get the sum and
> difference frequencies...Ok I need go read about demodulation to get
> this one.
> 
> 
>>How will you measure this acceleration?  Do you have an independent way
>>of measuring the rotation rate?  Here again, a rate gyro would be a cool
>>thing (actually, a rate gyro with an accelerometer both feeding into a
>>Kalman filter would be way cool, but it would probably be gross overkill
>>for +/-10 degrees, and a steep learning curve for you).
> 
> No we don't have an independent way. From what I understand a rate gyro
> is just a 3 dimensional accelerometer. I was thinking 1D to keep costs
> down.
> 
No, gyros and accelerometers are completely different beasts.  And when 
you're planning on 'keeping costs down' think about your production 
volumes -- spending $25000 worth of an engineers time to keep a $25 part 
out of your system only makes sense if you've got a solid 500/year units 
to sell (assuming a 2-year ROI).

It did occur to me while reading this thread this morning that you could 
monitor your centrifugal force with a second accelerometer to give you a 
speed estimate.

But this only makes a difference if you expect quick accelerations -- if 
you can count on your acceleration being slow compared to your desired 
sampling rate (probably something like no more than 5 to 10 degrees over 
one of your desired sampling intervals) then you should be able to build 
speed measurement into your algorithm.
> 
-- snip --

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

john.dsp0@gmail.com wrote:
>> Only if the rotation velocity is negligible. It's easy to swing a pail
>> of water by its bail over your head without spilling any. What's the
>> slowest you can go without spilling water when the bottom of the pail is
>> straight up? Will the radial acceleration still yield the data you want?
>> (I think so.)
> 
> Hi Jerry,
> Ok, so the reason the water doesn't spill is because the centripetal
> acceleration > acceleration due to gravity. In theory I agree with you,
> the centripetal acceleration will be roughly constant and the measured
> acceleration due to gravity will still vary as the bucket swings
> around. Problem is gravity is 1 g, and the centripetal acceleration for
> our geometry can be 100g and higher.

How well can you null it by mounting the accelerometer normal to it? 
About .1 degree off perpendicular will bring that 100 g down to less 
than .2 g. Id the cross-coupling of the accelerometer that good?

> I figured that mounting the sensor perpendicular to the centripetal
> acceleration nulls out most of that. (sure there will be some sensor
> alignment error so some centripetal acceration will appear in the
> measurement, but will be now greatly attenuated.
> 
> I can't quite see the advantage of measuring the centripetal
> acceleration? What do I gain?

The radial acceleration due to rotation is constant for any fixed speed 
and radius. (Minimize it by minimizing the radius.) You don't need to 
know the radial acceleration. It will disappear when differentiating. 
You do need to think about the effect of vibration caused by imbalance 
in the rotating member. If the mounting isn't equally stiff in all 
directions, the actual motion will be elliptical. The orientation of the 
ellipses axes will affect the result. Is that the influence of vibration 
that concerned you?

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

john.dsp0@gmail.com wrote:
> Once again, many thanks for you comments jerry. My response below.
> 
> Jerry Avins wrote:
>> john.dsp0@gmail.com wrote:
>>> Hi,
>>> We have an application where we need to measure the angular
>>> position(relative to the floor) of a rotating portion of an industrial
>>> machine. Standard problem but we believe our application has
>>> constraints the make it tricky. Our idea is to use an
>>> accelerometer(e.g. analog devices imems sensor) mounted on the rotating
>>> object, with its senstive access perpendicular to the centripetal
>>> acceleration, and measure acceleration due to gravity only.
>>> (Acceleration due to gravity is always directed downwards towards the
>>> center of the earth). Although we are embedded experts, we are not DSP
>>> experts, and I'm interested in any feedback people may have on our
>>> idea.
>> I don't understand. Unless you know that your sensor is on the axis of
>> rotation, how will you separate the centrifugal acceleration from
>> gravity? (I think I know an impractical way, not worth detailing.)
> I think we have a disconnect here, not sure how to resolve it without a
> diagram ;) What do you mean by "On the axis of rotation"? The sensor is
> actually mounted so that it is perpendicular to the centripetal
> acceleration. It doesn't measure any centripetal/centrifugal
> acceleration. It will only measure gravity and angular
> acceleration(although ignore the angular acc for now - assume its
> constant).

   ...

You haven't told us what's rotating, but there is an axis about which it 
rotates. If your sensor is centered in that axis, the only forces acting 
on it (at constant angular velocity) will be gravity and vibration. If 
it is mounted well away from the center of rotation, then you can hope 
to null the radial acceleration, but you need to about cross coupling if 
the radial acceleration. Even in stereo receivers, cross-channel 
isolation isn't infinite.

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

> How well can you null it by mounting the accelerometer normal to it?
> About .1 degree off perpendicular will bring that 100 g down to less
> than .2 g. Id the cross-coupling of the accelerometer that good?
Yes this was the orignal idea. Mount the sensor so that it is normal to
the centripetal acceleration. You have made me realise that there are a
range of orientations that will achieve this, but in our case the pcb
is mounted such that only 1 makes sense. (The axis of rotation is
normal to the PCB) There will be an alignment error, datasheet specs
1=2E5 degrees and I can only guess what error we introduce when mounting
on the PCB.

> The radial acceleration due to rotation is constant for any fixed speed
> and radius. (Minimize it by minimizing the radius.) You don't need to
> know the radial acceleration. It will disappear when differentiating.
> You do need to think about the effect of vibration caused by imbalance
> in the rotating member. If the mounting isn't equally stiff in all
> directions, the actual motion will be elliptical. The orientation of the
> ellipses axes will affect the result. Is that the influence of vibration
> that concerned you?
Yes yes yes. Exactly this. The rotating object won't be perfectly
balanced. I'm worried about the noise this introduces being at the same
frequency of the signal we are trying to extract, hence possibly making
it a difficult/impossible? signal processing task?

One of the design goals will be to keep the electronics as close to the
axis of rotation as possible to 1)minimes the g forces experienced by
the electronics and 2) reduce the unbalancing effect of adding our
electronics to the rotating object.

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

> You haven't told us what's rotating, but there is an axis about which it
> rotates. If your sensor is centered in that axis, the only forces acting
> on it (at constant angular velocity) will be gravity and vibration. If
> it is mounted well away from the center of rotation, then you can hope
> to null the radial acceleration, but you need to about cross coupling if
> the radial acceleration. Even in stereo receivers, cross-channel
> isolation isn't infinite.

Ok I get it now. It may or may not be possible with our physical
geometry but I can see that we should be aiming for as close to the
axis of rotation as possible. The radial acceleration will be
relatively constant(I hope) when compared to the rotation rate so we
don't need to eliminate the radial acceleration totally. Just attenuate
it enough so that it doesn't cause the sensor to saturate/go out of
range.

> It did occur to me while reading this thread this morning that you could
> monitor your centrifugal force with a second accelerometer to give you a
> speed estimate.
I like it. Possibly we will use a 2D sensor anyways so get the
centrfugal acceleration for free anyhow. Could be dynamic range issues
though, depending on the sensor location of course. The centrifugal acc
is much much higher than gravity, unless the sensor is mounted very
close to the axis of rotation.


> But this only makes a difference if you expect quick accelerations -- if
> you can count on your acceleration being slow compared to your desired
> sampling rate (probably something like no more than 5 to 10 degrees over
> one of your desired sampling intervals) then you should be able to build
> speed measurement into your algorithm.
> >
> -- snip --
>
> --
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com
>
> Posting from Google?  See http://cfaj.freeshell.org/google/
>
> "Applied Control Theory for Embedded Systems" came out in April.
> See details at http://www.wescottdesign.com/actfes/actfes.html