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. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
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. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
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. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
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. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
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