Thanks everyone for your responses. I'll make a few changes and report
back how it works.
Best regards,
Jay.
Reply by George●June 18, 20042004-06-18
Jay <127.0.0.1@garbage.gar> wrote in message news:<cMuAc.46706$bO6.7290@fe39.usenetserver.com>...
> Hi Jack,
>
> In article <60l4d0dmn92bsh7jvnkaasgd11h14s6ian@4ax.com>,
> jackklein@spamcop.net says...
>
> > I have two questions:
> >
> > 1. How many encoder counts are you dealing with per second?
> >
> > 2. Why are you working with instantaneous frequency?
>
> Answer to 1: The speed of the motor is controllable between 0 to 200 Hz,
> 2000 counts/rev with quadrature counting (500 line).
>
> Answer to 2: I had a bit of a brain hickup. I'm actually doing something
> like what you outlined where I use a counter, acrue pulses and see how
> many have come in my sampling interval.
>
> The timing technique I mentioned in my original mail is something I
> tried to use to measure the jitter of the encoder signal numerically
> within the FPGA/uC circuit (i.e. see how the period changes from encoder
> pulse to encoder pulse). This method is NOT used my control-loop.
>
> > I don't know why you think you need some sort of band pass filter
> > either.
>
> I wanted to low-pass filter the error signal since the variance in how
> many counts I get per sample interval can be large. My issue was dealing
> with the fact that I'm recieving data from a system that's purely
> digital in nature and I didn't want to get any aliasing if I implemented
> a filter.
>
> > The usual strategy to use with a discrete digital input signal like an
> > encoder signal is to count them. Every 10 ms (100 Hz), you take the
> > count since the last time, and use that directly for your velocity.
>
> Ok, I understand what you're saying. With respect to applying a
> traditional digital filter (FIR/IIR/moving average) should I just "do
> it" and not worry about aliasing?
>
> Regards,
> Jay.
You should also look at the overall system.
1. Is the system acurate with respect to encoder pulses. If you make
100 small slow moves back and forth, do you always return to the same
position. If not you'rehaving counting errors.
2. Can you measure open loop response of the system. You might find
some some mechanical component is not stiff enough and is creating the
changes (oscillations) in the encoder inputs.
3. Can you make the moves at a very slow speed?
4. In stead of the micro could you add an OP-AMP to do the P of the
PID loop. If that works then you've got problems with the micro
running the loop.
I just published an article on using FPGAs for 2nd order motion
systems. It may give you some pointers. www.circuitcellar.com
Designing with the Nios (Part 1): Second-Order, Closed-Loop Servo
Control.
Keep us posted
George
Reply by Robert Scott●June 18, 20042004-06-18
Jay wrote in comp.arch.embedded:
> Hi,
>
> I have my motion control-system setup for a velocity loop. Encoder pulse
> periods are timed to calculate instaneous frequency and are subtracted
> from a reference value to form an error signal. The timing and error
> generation occurs in an FPGA, the control-loop is implemented as a PID
> in a uC which samples the error register in the FPGA at 100 Hz.
>
> My issus is regarding noise: I have a lot of jitter on my encoder
> signals (due to mechanical vibrations I think) which causes the error
> signal to jump around quite a bit......
Look closely at the resolution of your velocity measurment. That I
believe is where your noise is coming from - not from mechanical
vibration. If you try to infer velocity over too short a time
interval, then the +/- 1 count variation in encoder counts can
represent a substantial velocity change.
One solution is to extend the time period over which velocity samples
are taken. The limiting factor here is that if you wait too long then
the delay will affect closed-loop dynamics. Another solution is to
measure velocity a different way. Instead of measuring how many
encoder pulses arrive in a fixed length of time, measure how much time
elapses for a fixed number of encoder pulses. Of course you will have
to handle the limiting case of very slow velocities in a special way,
but that was going to be the hardest case regardless of the method
used. There is essentially no limit to the resolution with which you
can measure time.
-Robert Scott
Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)
Reply by Paul Burke●June 18, 20042004-06-18
Jay wrote:
>
> Ok, I understand what you're saying. With respect to applying a
> traditional digital filter (FIR/IIR/moving average) should I just "do
> it" and not worry about aliasing?
>
I think the question you are asking is more a brain tangle than anything
else (as I think you suggested). Consider your 100Hz- sampled count. If
you have jitter of say 150Hz on the input, but of small (say a few
counts) magnitude, this will only affect the totalised count acquired in
the sample period. So if you are stationary, your total at the end of
the period could be the "true" position plus or minus a few counts. The
fact that, between the samples, it goes positive and negative several
times will be invisible to you. Similarly, when moving, the sample
increment between periods will vary by a few counts, but the high
frequency variations are forgotten about when the sample is taken.
So it is not the frequency of the jitter that matters, but its
magnitude, assuming of course that the quadrature decoder and the
counter can cope with the jitter frequency.
The result will be a noisy position/velocity signal, but no aliasing.
You must, of course, ensure that either you filter your output to ensure
that you don't have aliasing because of the 100Hz sampling, or that the
system mechanics will do that for you.
Paul Burke
Reply by Jay●June 18, 20042004-06-18
Hi Jack,
In article <60l4d0dmn92bsh7jvnkaasgd11h14s6ian@4ax.com>,
jackklein@spamcop.net says...
> I have two questions:
>
> 1. How many encoder counts are you dealing with per second?
>
> 2. Why are you working with instantaneous frequency?
Answer to 1: The speed of the motor is controllable between 0 to 200 Hz,
2000 counts/rev with quadrature counting (500 line).
Answer to 2: I had a bit of a brain hickup. I'm actually doing something
like what you outlined where I use a counter, acrue pulses and see how
many have come in my sampling interval.
The timing technique I mentioned in my original mail is something I
tried to use to measure the jitter of the encoder signal numerically
within the FPGA/uC circuit (i.e. see how the period changes from encoder
pulse to encoder pulse). This method is NOT used my control-loop.
> I don't know why you think you need some sort of band pass filter
> either.
I wanted to low-pass filter the error signal since the variance in how
many counts I get per sample interval can be large. My issue was dealing
with the fact that I'm recieving data from a system that's purely
digital in nature and I didn't want to get any aliasing if I implemented
a filter.
> The usual strategy to use with a discrete digital input signal like an
> encoder signal is to count them. Every 10 ms (100 Hz), you take the
> count since the last time, and use that directly for your velocity.
Ok, I understand what you're saying. With respect to applying a
traditional digital filter (FIR/IIR/moving average) should I just "do
it" and not worry about aliasing?
Regards,
Jay.
Reply by Jack Klein●June 17, 20042004-06-17
On Wed, 16 Jun 2004 14:39:35 -0500, Jay <127.0.0.1@garbage.gar> wrote
in comp.arch.embedded:
> Hi,
>
> I have my motion control-system setup for a velocity loop. Encoder pulse
> periods are timed to calculate instaneous frequency and are subtracted
> from a reference value to form an error signal. The timing and error
> generation occurs in an FPGA, the control-loop is implemented as a PID
> in a uC which samples the error register in the FPGA at 100 Hz.
>
> My issus is regarding noise: I have a lot of jitter on my encoder
> signals (due to mechanical vibrations I think) which causes the error
> signal to jump around quite a bit.
>
> So, is there any reasonable way to remove the jitter using digital
> filters (FIR, IIR?) and not run into aliasing probelms due to sampling?
>
> Since the data "starts out" digitally, I don't have any bandlimiting
> low-pass filter as I would if this were an analog signal going to an
> A/D. Using a scope, I think I can safely say the encoder counts jitter
> at a frequency > 100 Hz.
>
> My thinking is the jittering causes an FM effect on the encoder input
> frequency so I'd want as high of a sampling rate as possible for a
> filter, since I can't attenuate above Fs/2.
>
> I'm guessing if I want an FIR/IIR filter I'd need to run it at 5 MHz+,
> but since the data is only available on encoder ticks, what would I be
> sampling between encoder ticks? The "all digital" aspect is a bit of a
> mind bender.
>
> I know a lot of people deal with noise by implementing moving average
> filters, is this an alternative? How would this get around aliasing?
>
> Suggestions highly appreciated!
>
> Jay.
I have two questions:
1. How many encoder counts are you dealing with per second?
2. Why are you working with instantaneous frequency?
Here are things I know about encoders (particularly quadrature
encoders):
They are not mechanically perfect. For example, if you supplied a
perfect velocity to one and measured the difference between the four
quadrature edges, most likely you would find the intervals rather
unequal.
I don't know why you think you need some sort of band pass filter
either.
The usual strategy to use with a discrete digital input signal like an
encoder signal is to count them. Every 10 ms (100 Hz), you take the
count since the last time, and use that directly for your velocity.
Since there is a digitization error of +/-1 to this counting
technique, the larger the number of encoder counts there are in the
interval, the less jitter there will be in the count. If there are
1000 counts/second (10 counts per 100 Hz period), the error will be
+/- 10%. If there are 10,000 counts/second (100 counts per 100 Hz
period), the digitization error will be only +/-1%.
Summing the counts over the control loop interval also automatically
averages out any jitter between the individual pulses.
It might be possible to apply analog filtering techniques to something
like encoder counts, I suppose. I've never tried it and the only
person I know who did got it horribly wrong.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply by Jay●June 16, 20042004-06-16
Hi,
I have my motion control-system setup for a velocity loop. Encoder pulse
periods are timed to calculate instaneous frequency and are subtracted
from a reference value to form an error signal. The timing and error
generation occurs in an FPGA, the control-loop is implemented as a PID
in a uC which samples the error register in the FPGA at 100 Hz.
My issus is regarding noise: I have a lot of jitter on my encoder
signals (due to mechanical vibrations I think) which causes the error
signal to jump around quite a bit.
So, is there any reasonable way to remove the jitter using digital
filters (FIR, IIR?) and not run into aliasing probelms due to sampling?
Since the data "starts out" digitally, I don't have any bandlimiting
low-pass filter as I would if this were an analog signal going to an
A/D. Using a scope, I think I can safely say the encoder counts jitter
at a frequency > 100 Hz.
My thinking is the jittering causes an FM effect on the encoder input
frequency so I'd want as high of a sampling rate as possible for a
filter, since I can't attenuate above Fs/2.
I'm guessing if I want an FIR/IIR filter I'd need to run it at 5 MHz+,
but since the data is only available on encoder ticks, what would I be
sampling between encoder ticks? The "all digital" aspect is a bit of a
mind bender.
I know a lot of people deal with noise by implementing moving average
filters, is this an alternative? How would this get around aliasing?
Suggestions highly appreciated!
Jay.