Q about Motion Control system, noise & sampling rates.

On Wed, 16 Jun 2004 14:39:35 -0500, Jay wrote in comp.arch.embedded:

I have two questions:

1. How many encoder counts are you dealing with per second?

1. 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

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 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.

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.

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

Jay wrote in comp.arch.embedded:

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.)

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.

1. 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.

2. Can you make the moves at a very slow speed?

1. 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.

Designing with the Nios (Part 1): Second-Order, Closed-Loop Servo Control.

Keep us posted George

Thanks everyone for your responses. I'll make a few changes and report back how it works.

Best regards, Jay.