Low Res Optical Encoders for Speed Control

[KrazyCarl92]

This summer, Team 20 is revisiting a problem we experienced during the competition season. We had our shooter wheels powered by Banebots RS550s and on speed control with a 360 count encoder on each shaft connected to CAN jags. However, when our jaguars kept having brown-outs in CAN, we switched to PWM control, which meant we could not use the 360 count encoders for speed control at such high rpms (bye-bye shooting accuracy).

So now we are trying to resolve the CAN issues, but in the event that we cannot, we would like to have a back-up plan to get closed loop control with PWM. This would require a different sensor then we are currently using to measure rotation (we are currently using 360 count US Digital E4Ps).

Has anyone had experience with low-resolution optical encoders? And by low resolution I don't mean 64 or 100 counts per revolution, but more like single digits. I found this while searching on Digi-key:

http://www.digikey.com/product-detai...008S-ND/954400

, but I'm accustomed to using 4 pin connections with encoders (power, ground, A channel, B channel), and the ones I am finding all have 6 pins. The additional 2 pins have something to do with a switch according to the datasheets, but I have no clue how to work with that. Has anyone worked with something similar before or does anyone have other suggestions? The reason I'm interested in low-res optical encoders is because we know how to work with them, but I have seen teams with other solutions, so if there are other simple and effective ways to do the task we'd love to hear about those too.

[Thad House]

Our team used a optical sensor with a 1ms response time, and had that going through a flywheel that had 3 holes. At 5000 rpms, that required about a 2ms response time, and it always worked. I know that other teams (341 in particular) used the retroreflective sensors from last years KOP, which worked as well.

[Ether]

Originally Posted by KrazyCarl92

PWM control ... meant we could not use the 360 count encoders for speed control at such high rpms

Why not?

If you put the 360 count encoders on the wheel shaft, that's 24000 counts per second at 4000 wheel rpm. The FPGA can handle 40,000 counts/sec

Use only one channel of the encoder and use the Counter class to trigger on rising edge only.

[KrazyCarl92]

Originally Posted by Ether

Why not?

If you put the 360 count encoders on the wheel shaft, that's 24000 counts per second at 4000 wheel rpm. The FPGA can handle 40,000 counts/sec

We have a 2 axle shooter, so if we had 2 axles reading that fast, could the FPGA handle it? I.E. would that then become 48,000 counts/sec? Also, are there other variables that could affect the FPGA and how it counts the encoders, and where can I read up to learn more about it?

[Ether]

Originally Posted by KrazyCarl92

We have a 2 axle shooter, so if we had 2 axles reading that fast, could the FPGA handle it? I.E. would that then become 48,000 counts/sec?

I believe each FPGA input channel can handle 40,000 counts/sec. Perhaps someone with intimate knowledge of the FPGA could comment.

Also, are there other variables that could affect the FPGA and how it counts the encoders, and where can I read up to learn more about it?

Download a copy of the WPILib C source code and read the descriptions of the methods in the Encoder and Counter classes.

[AllenGregoryIV]

I know we were having issues with the 360 count encoder on our shooter but that may have just been our setup. We end up moving to a cheap IR reflective sensor and piece of white tape and it's worked perfectly.

[Greg McKaskle]

Not that I'm an expert on the API or anything, but looking at the LV implementation, there are four 4x encoders and eight counters that can be used for 1x and 2x. As stated before, they are running on the FPGA and run in parallel along with each other, PWM generation, triggers, etc. So, the encoders will not be an issue.

Greg McKaskle

[cgmv123]

I think the actual number is 39,230.

[KrazyCarl92]

Originally Posted by Ether

Use only one channel of the encoder and use the Counter class to trigger on rising edge only.

Our team uses Java. I'm not much of a programmer as it relates to the robot, but I have a bit of experience.

I notice that all of the constructors for Encoder objects require both an A channel and B channel as arguments, whereas the Counter constructors allow you to specify a single channel. Is this why we would use the Counter class to only count the rising edges? The Counter class doesn't have a getRate method, but would the getPeriod method return values that are useful for what we're trying to do?

And I noticed that 1x, 2x, and 4x counting are mentioned in the descriptions of many of the methods in the Encoder class. Is this something we need to consider when using the Counter class as well?

[Ether]

You could use the getperiod method which returns the elapsed time between the two most recent edges, or you could read raw counts and divide the change in counts by the actual elapsed time since the counts were last read.

Each method has its pros and cons, and teams have been successful with both methods.

One or the other might be more appropriate depending on your encoder speed and the control algorithm you plan to use.

[jspatz1]

We also had trouble with the 360 res quad. US Digital trying to control up to 1500 rpm with pwm. We switched to 100 res single channel, at it worked great.

[Ekcrbe]

I'm not the one to go to for technical answers, but this year, we actually put our encoder on a gear reduction from the shooter so it wasn't running as fast as the shooter, and then compensated accordingly in the calculations.

My 2 hillbilly pennies.

[R.C.]

We are using a 360 count s4 encoder from US Digital, we basically use the same PID loop with feed forward that 341 does.

We were getting our shooter +- 25 rpms pretty easily.

-RC

[BornaE]

While helping team 842 this year, we found that there are issues with using the 360 counts/rev encoders at the speeds we needed. never got around to actually debug what the issue was. They were using about 6/7 feet of wire routed next to motor wires and that may have been an issue. the reading were erratic changing by a a magnitude of 2 when they were graphed.

To resolve this, we removed the plastic disc from the encoder wheel and replaced it with piece of electrical tape on the disk so we had 1 rising and 1 falling edge. We were able to run the control system to achieve the desired RPM using the modified encoders.

Originally Posted by Ether

Why not?

If you put the 360 count encoders on the wheel shaft, that's 24000 counts per second at 4000 wheel rpm. The FPGA can handle 40,000 counts/sec

Use only one channel of the encoder and use the Counter class to trigger on rising edge only.

[KrazyCarl92]

Originally Posted by BornaE

To resolve this, we removed the plastic disc from the encoder wheel and replaced it with piece of electrical tape on the disk so we had 1 rising and 1 falling edge. We were able to run the control system to achieve the desired RPM using the modified encoders.

This is the sort of workaround I'm interested in if we can't do it with a 360 count disc. The only thing that would usually concern me about this approach is a layer of tape (which if I remember correctly is thicker than the plastic disc) could change the tolerance on the encoder for the distance from the sensor to the disc. Was this even an issue, or could it be easily resolved if it does present a problem?