Need help with shaft encoders

[edthegeek]

Our team is thinking about using shaft encoders on our 2007 FRC chassis. We need something with ok resolution, does not have to be great (it its within 4 inches of a set distance, its good enough). Does anybody have any idea as to where to get encoders compatible with the RC and how to program them?

[MattD]

Kevin Watson has an Encoder FAQ on his site, along with example code. Hopefully you should be able to find what you need there.

[Kevin Sevcik]

I've found a rather large selection at US Digital. They have some reasonably priced ones, and they'll make up just about whatever you'd like. You do have to give them a little lead time, however.

[Jared Russell]

Grayhill and US Digital both have reasonably priced options.

Make sure whatever you get uses 5VDC power, and you'll need quadrature output to get direction as well as speed. Also make sure you don't get anything with a CPR (counts per revolution) too high (>1024 or so), or you can crash the RC.

As for programming with encoders, Kevin's code will let you read things like encoder counts, velocity, etc., but you need to figure out what you want to do with it in order to use that data. For example, if you need to drive 10 feet and stop, you could either wait until you count up to however many ticks equals 10 feet and then kill the power, or you could use a feedback controller to precisely reach the exact position you want down to a fraction of an inch.

It all depends on what you need it for, how much precision you need, and the ability of your programmers.

[mluckham]

Originally Posted by MattD

Kevin Watson has an Encoder FAQ ...

His code is great, I was able to very easily adapt it to a different encoder - as long as they have "phases" (two signal wires outputting pulses) - one wire is connected to a Digital Input to trigger an interrupt, the other wire goes to a second DI which the software checks for a HI or LO state, thus determining direction of rotation.

The difficulty with encoders seems to be how to attach them to motors, shafts, whatever. And they aren't cheap. The US Digital E4 Encoder http://www.usdigital.com/products/e4/index.shtml seems like good value for the price, with the encoder wheel and electronics mounted stably inside a housing.

[Gdeaver]

Don't forget the vex encoders. They're cheap and your team may all ready have them if they bought into vex. They do not give direction, but may be good enough to navigate a fixed distance in auto mode.

[Alan Anderson]

Originally Posted by mluckham

His code is great, I was able to very easily adapt it to a different encoder - as long as they have "phases" (two signal wires outputting pulses) - one wire is connected to a Digital Input to trigger an interrupt, the other wire goes to a second DI which the software checks for a HI or LO state, thus determining direction of rotation.

We easily adapted Kevin's encoder code to work with the gear tooth sensors from last year's kit of parts. They only have a single output. All it took was removing the part of the interrupt code which checks the second phase. We replaced that check with a flag which reflects the currently commanded direction of the motors (it works okay except at very low power where the wheel might actually be forced by friction with the carpet to turn in the opposite direction than desired).

The difficulty with encoders seems to be how to attach them to motors, shafts, whatever. And they aren't cheap. The US Digital E4 Encoder http://www.usdigital.com/products/e4/index.shtml seems like good value for the price, with the encoder wheel and electronics mounted stably inside a housing.

Have you actually used the E4 or E4P encoders? I'd be grateful to hear how you mounted them (pictures would be wonderful) and how well they worked.

[Gdeaver]

Looking at the US digital picture of the mention encoder, there is no bearing for the code wheel. This means that the user must provide the shaft and there are limits on shaft wobble and alignment. The Grayhills I believe include a high quality bearing and with the proper coupling can be more tolerant of misalignment and slop. I believe this means that to use these encoders a team would have to add a shaft, take off gear and bearings to the KOP trans. A bearing and shaft type encoder could be add to the KOP trans at the output shaft with a mounting bracket attached to the frame with a flexible coupling. While the Grayhills are more expensive, the time and effort maybe less for the mounting.

[Kevin Sevcik]

US Digital does offer the standard sort of encoders with shafts coming off them as well, in fact. Also, we were trying to use the E4 encoders with our custom transmissions last year, but ran out of time for coding and such. So they're mounted, but we haven't gotten around to testing them to see how well they work. For the record, though, they went on pretty easily. Though, of course, we had the shaft customized, etc. to make it easy.

Also, the specifications make them look a little tolerant to play in the system. They specify +-.02 in of axial play and .01 in of off axis tolerance. I don't think .01 inch is a ridiculously tight tolerance really.

[Phalanx]

Here's some real time experiences with shaft encoders.

In 2006 we attempted to use the VEX Encoders on our robots drive wheels and we found that under stress, under load, under heavy vibration they didn't count accurately or reliably so we abandoned using them.

Later on in the year we obtained a pair of H1-50 encoders from USDigital. It took about 5 days for us to get them via UPS ground so your mileage may vary. We found them to be highly reliable on the same robot and the same conditions we used for the Vex ones. I would higly recommend getting the cables they have for them too it makes life much easier when you only have to put hoods and pins on ONE end to connect on the RC. Additionally we may also look at using the E4 or the E4P series from USDitigal as well for 2007, but that has yet to be determined.

Also USDigitals Tech Support staff was very knowledgeable, very helpful and there is good dictionary of terms there, and some nice high level explanations.

We did not use Kevin's Encoder code, what we used instead was based on this whitepaper found here so you may also want to download and read this whitepaper on using quadrature encoders. We found it very helpful, insightful, and should help you understand the workings better.

http://www.chiefdelphi.com/media/papers/1490

PS. There is one minor bug, and one major bug in the sample code, in the initialization functions, but our crack team here found them and corrected them, so it all worked out great in the end.