Re: High speed encoder with slotted / flat end... can't find one.
 

The equation is 4th order, we tried 2nd also. I don't have the data, for some reason it's on the desktop of one of the team laptops and not with the code, I probably can't get it soon.

The resulting equation is in the LabVIEW code I posted to CD-Media. The constants are:
-4th order = 3.038921E-10
-3rd order = -1.8893034681E-6
-2nd order = 0.003990997414888
-1st order = -2.710486371347
There is no intercept, the equation runs through the origin. The input is the desired speed in RPM, the output is a motor power which is divided by 1000 to produce a pct (0-1 range) number. This equation is obviously only valid with this particular mechanical system. The second order function was similar, but the R/R^2 values weren't quite as good as the 4th order function, so we used the 4th order function. The 3rd order function did not follow the curve very well, and was overall not as good as either the 2nd or 4th order functions.

Initially, we scaled the input to 0-1 range, and used the Excel default of two decimal places. The accuracy of this was nowhere near enough, so we scaled the input by 1000 and increased the precision to include many more decimal places (as Excel rounds by decimal places, not significant digits). Looking back, we probably would be OK with as few as 4 digits, but 2 is definitely not enough.

Re: High speed encoder with slotted / flat end... can't find one.
 

I plotted:

3.038921E-10*X⁴ - 1.8893034681E-6*X³ + 0.003990997414888*X² - 2.710486371347*X

... and got this graph. Are you using just the rightmost part of the graph?


Try the following model instead of a polynomial:

Y = p1 + p2/(X-p3)

You can do that in Excel as explained here.

Re: High speed encoder with slotted / flat end... can't find one.
 

Can you elaborate on this procedure? The thing I'm really interested in here is when you pick a throttle point... how long do you hold it in that position to get a reading. For us the shooter wheel took some time to gain momentum given a constant voltage, where the more voltage... the more time it took for the momentum to take effect.

Re: High speed encoder with slotted / flat end... can't find one.
 

To get the data for a feedforward term, you want the steady-state open-loop value. So you hold the voltage until the speed stops changing, then record your data point. You do this open-loop.

The purpose of the feedforward is to anticipate the required steady-state value required. Then you add your closed-loop terms to make the dynamic response acceptable, and to compensate for load and supply voltage variations that were not present when you recorded your feedforward data.

Re: High speed encoder with slotted / flat end... can't find one.
 

Thanks Ether that really explains it...

Ok if I read this correctly... for fixed point type of rotary systems like a turret or arm (logomotion). You would linearize the victor of the motors while they are still free moving, before you restrict its movement to its fixed point function. Does that sound right?

(Once I understand this I'm going to finally get the arm working) :)

Re: High speed encoder with slotted / flat end... can't find one.
 

I don't know. I'm having trouble understanding your sentence.

Re: High speed encoder with slotted / flat end... can't find one.
 

Ok how about this... how would obtain throttle points from say an arm or turret?

Re: High speed encoder with slotted / flat end... can't find one.
 

Position control (like for a turret) and speed control (like for a shooter wheel, what we have been discussing here) are different problems.

If you are trying to control the position of a turret, just use the position PID provided in the WPILib. Feedforward is not appropriate for a position controller where the load is essentially zero at the target position.

Re: High speed encoder with slotted / flat end... can't find one.
 

A moving average filter is a low-pass filter. I think what you are saying is that you found an IIR (infinite impulse response) low-pass filter performed better than an FIR (finite impulse response) low-pass filter in your application.

Add our team to the list of those that found using a low count per revolution solution (in our case, two pieces of reflective tape and a 2011 KOP line sensor) and using the built-in getRate() function based on timing consecutive edges performed well (less than 1% p-p variation with a simple low-pass filter). Our design methodology was that if we are only running PID at 200Hz (using a Jaguar), then we want a maximally stable speed measurement every 5 milliseconds. At the speeds our shooter was running at, taking two speed measurements per wheel revolution is very close to this ballpark.

Re: High speed encoder with slotted / flat end... can't find one.
 

If you're running your PID at 200 HZ, or once every 5 milliseconds, then I understand why you'd want a maximally stable speed measurement every 5 milliseconds.

2 counts per revolution, at a speed of 4000 rpm, nets you 66.67 rps. That's 66.67*2= 133.34 counts per second. That's .6667 counts every 5 ms. So how many loops were accumulating? It seems like 75 - 100 ms would be reasonable to reduce the error of being part-way between counts (+/- 1.5% at 100 ms). So 15-20 loops worth of counts?

Something I didn't mention is that we are using a low-pass filter of sorts. We use the labview coerce function and set a max and minimum that limits the amount of change from reading to reading.

Re: High speed encoder with slotted / flat end... can't find one.
 

The coerce function sounds similar to kalman filter in behavior... we run PID once every 10ms but our PID works different where it multiplies error times the delta time. I found this to get better results... which roughly tuned yields 4% from a PD solution with no victor linearization. Looking forward to getting better results with that change. Oh and it's a coicedence that our target speed was 341 radians per second. :)

Re: High speed encoder with slotted / flat end... can't find one.
 

When you use GetRate, there is no "error of being part-way between counts".

The FPGA has a timer which measures the elapsed time between counts. When you call the GetRate method, the FPGA reports the speed based on that elapsed time, not elapsed time between calls to the function.

If the speed is 6000 rpm or higher, you are guaranteed to get a new reading every 5ms, when using a wheel with two counts per rev.

Re: High speed encoder with slotted / flat end... can't find one.
 

In what way do you think it is similar?

Re: High speed encoder with slotted / flat end... can't find one.
 

I see now. So the getrate will return an accurate rate in that situation. So, then, my next question:

Does that mean that if I were to use getrate with an extremely high-count encoder, the time returned will only be the last two counts it sees? Or does it average between calls? How does getrate calculate the rate?

Answer: Correct me if I'm wrong, but a couple posts I just read suggest that the getrate calculation does report only the rate between the last two ticks. In which case, having the longest period between ticks that still gives you new data for each loop would give you the most accurate rate calculation. Am I interpretting this correctly?

Re: High speed encoder with slotted / flat end... can't find one.
 

Yes. That's why GetRate is so noisy for high-count encoders. The tolerance of the locations of the edges relative to the spacing between edges is high, so you get jitter.

In the C++ implementation of WPILib (but not the LabVIEW or Java implementations), GetRate does do some averaging in an attempt to reduce the noise, at least according to this post.