Reply by Scott Seidman●November 11, 20072007-11-11
Peter Nachtwey <pnachtwey@comcast.net> wrote in
news:x7mdndjpdc98vajanZ2dnUVZ_r-vnZ2d@comcast.com:
> Jerry Avins wrote:
>> Velocity should be no problem with
>> high-enough encoder resolution. Even acceleration might be practical,
>
> We do it all the time but it requires an accurate model.
>
>> but why calculate what can be measured?
>
> Often the customer doesn't have an accelerometer or they will not
> survive in an industrial environment
>
> I have a 2,000-line encoder
>> sitting in my "junk box". It dates back to the 1980s, and it's
accurate
>> enough for doubling the resolution with another pair of comparators.
> It is standard practice to count each phase so the 2000 line encoders
> will generate 8000 counts per revolution.
>
> Companies like BEI have encoders with 512,000 lines per revolution and
> higher. I think they use an interpolation scheme to get that
> resolution. It certainly can't be done with optical techniques alone.
> One can calculate an angular acceleration with one of high resolution
> encoders very easily.
>
> Peter Nachtwey
>
Another interesting option, now that you bring BEI into the picture, is
to use absolute encoders instead of relative encoders. It things are
moving so fast you're worried about missing ticks, this is certainly a
way to go.
--
Scott
Reverse name to reply
Reply by Jerry Avins●November 10, 20072007-11-10
Peter Nachtwey wrote:
...
> It is standard practice to count each phase so the 2000 line encoders
> will generate 8000 counts per revolution.
Certainly, but with four comparators instead of the two normally used to
square up the signal, I got 16000 counts per revolution. I showed that
to BEI when I first did it and I think they ran with it.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Peter Nachtwey●November 9, 20072007-11-09
Jerry Avins wrote:
> Velocity should be no problem with
> high-enough encoder resolution. Even acceleration might be practical,
We do it all the time but it requires an accurate model.
> but why calculate what can be measured?
Often the customer doesn't have an accelerometer or they will not
survive in an industrial environment
I have a 2,000-line encoder
> sitting in my "junk box". It dates back to the 1980s, and it's accurate
> enough for doubling the resolution with another pair of comparators.
It is standard practice to count each phase so the 2000 line encoders
will generate 8000 counts per revolution.
Companies like BEI have encoders with 512,000 lines per revolution and
higher. I think they use an interpolation scheme to get that
resolution. It certainly can't be done with optical techniques alone.
One can calculate an angular acceleration with one of high resolution
encoders very easily.
Peter Nachtwey
Reply by Jerry Avins●November 9, 20072007-11-09
pnachtwey wrote:
> On Nov 9, 9:29 am, Jerry Avins <""jya\"@ieee,org"> wrote:
>> Peter Nachtwey wrote:
>>> "Jim Fee" <f...@gait.aidi.udel.edu> wrote in message
>>> news:RYSdnXnD2Mlsxq7anZ2dnUVZ_oKhnZ2d@giganews.com...
>>>> We have a "cybex" type machine, designed to apply velocity, acceleration
>>>> Where w and n represent noise but how do I use two transducers to correct
>>>> the noise in each other?
>>> One accelerometer must be mounted at the end of the leg. The other must be
>>> mounted at the knee and must rotate with the leg. This allows one to
>>> subtract the forces or acceleration due to gravity. The encoder should help
>>> take care of the offsets in the accelerometer or between the two
>>> accelerometers.
>> How much information do you think subtracting one large number from
>> another and twice integrating the result will provide?
>> I don't see where
>> the encoder fits into that scheme. What does it do?
> Provide position feed back, what else? Why does one need to integrate
> twice when there is position feed back?
I thought you might be buying into the OP's scheme. We agree.
> Integrating once will do for
> the velocity and that can be 'averaged' with the velocity calculated
> from the position feed back. When the encoder detects the position
> isn't changing then the accelerometer offsets can be zeroed out. The
> OP is correct about multiple feed back devices providing a better
> estimate of the current state. A steady state Kalman filter with
> both position and acceleration feed back input will do.
I think calculating the correction for gravity from the known position
or zeroing it out with a second accelerometer must depend strongly on
the system and the resources. Velocity should be no problem with
high-enough encoder resolution. Even acceleration might be practical,
but why calculate what can be measured? I have a 2,000-line encoder
sitting in my "junk box". It dates back to the 1980s, and it's accurate
enough for doubling the resolution with another pair of comparators.
> We have made use of two accelerometers and a position feedback to do
> motion control for those very challenging systems with a low natural
> frequency and low damping factor. Higher order feed back can make a
> big difference the ability to control these challenging systems.
Yup!
> I don't understand why noise should be a big problem. One should be
> able to get very good acceleration values out of the A to D converter
> after applying and offset and scale. In our case +/- 5g is mapped to
> +/- 32767 A to D counts. That is plenty of resolution and a count or
> two of noise will not hurt. Encoders shouldn't never be noisy. The
> main problem with encoders is the quantizing.
But the OPs encoders are noisy. He needs to fix the basics before
seeking sophisticated workarounds for poor implementation.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by pnachtwey●November 9, 20072007-11-09
On Nov 9, 9:29 am, Jerry Avins <""jya\"@ieee,org"> wrote:
> Peter Nachtwey wrote:
> > "Jim Fee" <f...@gait.aidi.udel.edu> wrote in message
> >news:RYSdnXnD2Mlsxq7anZ2dnUVZ_oKhnZ2d@giganews.com...
> >> We have a "cybex" type machine, designed to apply velocity, acceleration
> >> Where w and n represent noise but how do I use two transducers to correct
> >> the noise in each other?
>
> > One accelerometer must be mounted at the end of the leg. The other must be
> > mounted at the knee and must rotate with the leg. This allows one to
> > subtract the forces or acceleration due to gravity. The encoder should help
> > take care of the offsets in the accelerometer or between the two
> > accelerometers.
>
> How much information do you think subtracting one large number from
> another and twice integrating the result will provide?
> I don't see where
> the encoder fits into that scheme. What does it do?
Provide position feed back, what else? Why does one need to integrate
twice when there is position feed back? Integrating once will do for
the velocity and that can be 'averaged' with the velocity calculated
from the position feed back. When the encoder detects the position
isn't changing then the accelerometer offsets can be zeroed out. The
OP is correct about multiple feed back devices providing a better
estimate of the current state. A steady state Kalman filter with
both position and acceleration feed back input will do.
We have made use of two accelerometers and a position feedback to do
motion control for those very challenging systems with a low natural
frequency and low damping factor. Higher order feed back can make a
big difference the ability to control these challenging systems.
I don't understand why noise should be a big problem. One should be
able to get very good acceleration values out of the A to D converter
after applying and offset and scale. In our case +/- 5g is mapped to
+/- 32767 A to D counts. That is plenty of resolution and a count or
two of noise will not hurt. Encoders shouldn't never be noisy. The
main problem with encoders is the quantizing.
Peter Nachtwey
Reply by Jerry Avins●November 9, 20072007-11-09
Peter Nachtwey wrote:
> "Jim Fee" <fee@gait.aidi.udel.edu> wrote in message
> news:RYSdnXnD2Mlsxq7anZ2dnUVZ_oKhnZ2d@giganews.com...
>> We have a "cybex" type machine, designed to apply velocity, acceleration
>> Where w and n represent noise but how do I use two transducers to correct
>> the noise in each other?
>
> One accelerometer must be mounted at the end of the leg. The other must be
> mounted at the knee and must rotate with the leg. This allows one to
> subtract the forces or acceleration due to gravity. The encoder should help
> take care of the offsets in the accelerometer or between the two
> accelerometers.
How much information do you think subtracting one large number from
another and twice integrating the result will provide? I don't see where
the encoder fits into that scheme. What does it do?
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Tim Wescott●November 9, 20072007-11-09
On Thu, 08 Nov 2007 17:36:53 -0500, Randy Yates wrote:
> Jerry Avins <""jya\"@ieee,org"> writes:
>
>> Randy Yates wrote:
>>> 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."
>>
>> The integrator alone doesn't drift, but the combination of integrator
>> and transducer. For one reason or another, the LSB can be
>> uncertain. (Nature tends to be maximally unkind. You call it Murphy's
>> Law. I call it IPOIO: innate perversity of inanimate objects.)
>>
>> The way incremental encoders are connected by the unwary, the "CW" and
>> "CCW" pulses don't occur at the same shaft angle, but are offset by
>> half a quantized angle increment. For reciprocating motion, that can
>> lead to a slow drift. For an unfortunate small-amplitude oscillation,
>> it can lead to a disastrous false indication of continuous motion. My
>> circuit (and a more complicated state machine) give CW and CCW pulses
>> at the same shaft position. The difference is the direction from which
>> that position is approached. That solves most of the annoying
>> difficulties that seem small enough to let slide until they become
>> large ones when the brass show up for a demo.
>
> Jerry,
>
> The depth and bredth of your knowledge of engineering across a variety
> of technologies is ... *scary*.
>
> Are you sure there isn't some way we could hook you up to a few
> Terrabytes of disk space do a data dump before you go away?
Datafan, ala the "Beyond the Blue Event Horizon" universe?
Ready to be vastened?
--
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
Reply by Peter Nachtwey●November 9, 20072007-11-09
"Jim Fee" <fee@gait.aidi.udel.edu> wrote in message
news:RYSdnXnD2Mlsxq7anZ2dnUVZ_oKhnZ2d@giganews.com...
> We have a "cybex" type machine, designed to apply velocity, acceleration
> Where w and n represent noise but how do I use two transducers to correct
> the noise in each other?
One accelerometer must be mounted at the end of the leg. The other must be
mounted at the knee and must rotate with the leg. This allows one to
subtract the forces or acceleration due to gravity. The encoder should help
take care of the offsets in the accelerometer or between the two
accelerometers.
Peter Nachtwey
Reply by Jerry Avins●November 9, 20072007-11-09
Randy Yates wrote:
> Jerry Avins <""jya\"@ieee,org"> writes:
>> [...]
>> The way incremental encoders are connected by the unwary, the "CW" and
>> "CCW" pulses don't occur at the same shaft angle, but are offset by
>> half a quantized angle increment.
>
> Are you referring to what used to be called "optical shaft encoders?"
> The one I used some 27 years ago had two signals, A and B. Both are
> square waves when the shaft is rotated at a constant angular velocity.
> The phase of B leads A by 90 degrees in one direction and lags A by
> 90 degrees in the other direction.
Yes.
> My up/dn detector was a D flip-flop with the clock being the A signal
> and the B feeding the D input.
That is subject to the errors I've been describing. One company with an
interferometer fringe-counter went bankrupt for relying on it. That was
early on. Now it's old hat.
>> For reciprocating motion, that can
>> lead to a slow drift.
>
> I think I see this - if the shaft is in just the wrong position, you'll
> get a positive edge on A for rotation of X radians and a negative edge
> for a rotation of -X radians. If you're using positive-edge triggering
> based on the A signal, you'll miss the -X rotations. (X is less than
> one angular quantization step).
>
>> For an unfortunate small-amplitude oscillation, it can lead to a
>> disastrous false indication of continuous motion.
>
> You mean if the A signal was glitching? Yeah, I see that.
>
>> My circuit (and a more complicated state machine) give CW and CCW
>> pulses at the same shaft position. The difference is the direction
>> from which that position is approached. That solves most of the
>> annoying difficulties that seem small enough to let slide until they
>> become large ones when the brass show up for a demo.
>
> I couldn't decode your state table in the adjacent post. For one thing,
> what's the difference between "CW" and "cw"?
No difference. I try to be consistent, but I corrected only Scott's
spacing, not the letters he used. My state table is simply an edit of
Scott's with tabs replaced by spaces. One way to achieve it is a state
machine. Another way is with a flip-flop (the first stage of an up-down
counter) and two XOR gates. I'll draw the circuit with ASCII art if you
care or send you the patent number. You can see that every transition of
either track counts up or down (CW or CCW) depending on how it's
traversed. A two-phase 50-line encoder counts through 200 states per
revolution. (Give me the raw photocell outputs before comparators square
them, and I can double that.)
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Randy Yates●November 9, 20072007-11-09
Jerry Avins <""jya\"@ieee,org"> writes:
> [...]
> The way incremental encoders are connected by the unwary, the "CW" and
> "CCW" pulses don't occur at the same shaft angle, but are offset by
> half a quantized angle increment.
Are you referring to what used to be called "optical shaft encoders?"
The one I used some 27 years ago had two signals, A and B. Both are
square waves when the shaft is rotated at a constant angular velocity.
The phase of B leads A by 90 degrees in one direction and lags A by
90 degrees in the other direction.
My up/dn detector was a D flip-flop with the clock being the A signal
and the B feeding the D input.
> For reciprocating motion, that can
> lead to a slow drift.
I think I see this - if the shaft is in just the wrong position, you'll
get a positive edge on A for rotation of X radians and a negative edge
for a rotation of -X radians. If you're using positive-edge triggering
based on the A signal, you'll miss the -X rotations. (X is less than
one angular quantization step).
> For an unfortunate small-amplitude oscillation, it can lead to a
> disastrous false indication of continuous motion.
You mean if the A signal was glitching? Yeah, I see that.
> My circuit (and a more complicated state machine) give CW and CCW
> pulses at the same shaft position. The difference is the direction
> from which that position is approached. That solves most of the
> annoying difficulties that seem small enough to let slide until they
> become large ones when the brass show up for a demo.
I couldn't decode your state table in the adjacent post. For one thing,
what's the difference between "CW" and "cw"?
--
% Randy Yates % "She tells me that she likes me very much,
%% Fuquay-Varina, NC % but when I try to touch, she makes it
%%% 919-577-9882 % all too clear."
%%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO
http://www.digitalsignallabs.com