Success with encoders

[smclean1969]

We have had some problems with getting an encoder working on our robots. Our team stood up in 2011 and it wasn't essential to have an encoder for Logomotion but it was a critical part of a successful shooter for Rebound Rumble.

The problem we had with the Kit of Parts encoder was the shooter RPMs being up in the 1000+ range, there were some vibrations that were causing the encoder to misread the encoder disk. I wanted to see if other teams had experience a similar problem.

Also, for the teams that don't use the KOP encoder, what type of encoder are they using?

thanks,

[Mark McLeod]

I've always liked using enclosed models like the Grayhill 61K, 63K/R (example (http://www.digikey.com/product-detail/en/63KS100/63KS100-ND/300006)) (spec sheet: ShaftEncoder_128CountPerRev.pdf (http://www.chiefdelphi.com/forums/attachment.php?attachmentid=2547&d=1098204545)) .
A 63R is guaranteed for 10 years of continuous use at 5000rpm. We're still running them on a robot from 2004.
For drive train or shooter type applications look for encoders with a high rotational life, ball bearings, etc.
Lighter duty applications can use cheaper alternatives by using bearing sleeves, lower rpm ratings, etc.

Depending on the application you might consider absolute or incremental, quadrature, BCD, etc.
Both digital and analog models are easy to deal with and the FRC cRIO is setup to handle them. Other connection methods (I2C, SPI,) tend to cost more. PWM outputs don't really work with FRC without the added complication of custom circuit pre-processing.

Do be careful to match the counts-per-revolution to the application and the capabilities of the cRIO to handle the maximum counts-per-second you design for.

[Ether]

http://www.chiefdelphi.com/forums/showpost.php?p=1044904&postcount=2

[topgun]

I've always liked using enclosed models like the Grayhill 61K, 63K/R (example (http://www.digikey.com/product-detail/en/63KS100/63KS100-ND/300006)).
A 63R is guaranteed for 10 years of continuous use at 5000rpm. We're still running them on a robot from 2004.
For drive train or shooter type applications look for encoders with a high rotational life, ball bearings, etc.
Lighter duty applications can use cheaper alternatives by using bearing sleeves, lower rpm ratings, etc.


How do you typically incorporate these encoders into your robot? gears, timing belts, etc? Pictures would help.

Thanks.

- T

[Mk.32]

We are currently using an KOP encoder in our off season robot, so far it has been working mostly. Our problem is more so our PID code..

[rees2001]

I've always liked using enclosed models like the Grayhill 61K, 63K/R (example (http://www.digikey.com/product-detail/en/63KS100/63KS100-ND/300006)).
A 63R is guaranteed for 10 years of continuous use at 5000rpm. We're still running them on a robot from 2004.
For drive train or shooter type applications look for encoders with a high rotational life, ball bearings, etc.
Lighter duty applications can use cheaper alternatives by using bearing sleeves, lower rpm ratings, etc.

Depending on the application you might consider absolute or incremental, quadrature, BCD, etc.
Analog models are easy to deal with and the FRC cRIO is setup to handle them. Other connection methods tend to cost more.

Do be careful to match the counts-per-revolution to the application and the capabilities of the cRIO to handle the maximum counts-per-second you design for.

Where is the like button?

I prefer the greyhill's. They work well with kids that my not understand the robustness of the KOP encoders.

[Phalanx]

We used the KOP encoders for our shooter which ran up to about 4500RPM without any issues.

In years past when encoders weren't in the KOP we used the "H" series from USDigital with good success.

http://www.usdigital.com/products/encoders/incremental/rotary/shaft/H1

[Mk.32]

Is there documentation on how to wire/program an Analog encoder such as an greyhill?

[Mark McLeod]

How do you typically incorporate these encoders into your robot? gears, timing belts, etc? Pictures would help.

Several different ways.
You just have to avoid side loads on the encoder shaft, so usually we use an L bracket to hold the encoder and a flexible coupler, e.g., a short segment of pneumatic tubing, as a coupler directly to a shaft, as if you were replacing the KOP encoder on an AndyMark gearbox.
We've also used a hardware shaft coupler available from McMaster and elsewhere.

Here's a photo (http://www.chiefdelphi.com/media/photos/19506) of a mount (from our 2004 robot) using plastic gears to couple to a drive train.

We've also used a sprocket w/ #25 chain on a special purpose turret. The sprocket has to be supported at both ends on a separate shaft, so the encoder doesn't carry any load.

Is there documentation on how to wire/program an Analog encoder such as an greyhill?
The Grayhill model I mentioned is a digital input. (I went back and reworded a little to avoid that implication)

Here's an example of an analog encoder (http://amci.com/pdfs/rotary-encoders/me15-rotary-encoder.pdf) with 10-bit resolution that's rated for 20,000 rpm. It is terribly expensive (but under the FRC $ limit), so I wouldn't recommend it. But it'll give you an idea of how simple the wiring and use is.
The wiring pinout is on page 12.

[Mk.32]

Several different ways.
You just have to avoid side loads on the encoder shaft, so usually we use an L bracket to hold the encoder and a flexible coupler, e.g., a short segment of pneumatic tubing, as a coupler directly to a shaft, like you would to replace the KOP encoder on an AndyMark gearbox.
We've also used a hardware shaft coupler available from McMaster and elsewhere.

Here's a photo (http://www.chiefdelphi.com/media/photos/19506) of a mount (from our 2004 robot) using plastic gears to couple to a drive train.

We've also used a sprocket w/ #25 chain on a special purpose turret. The sprocket has to be supported at both ends on a separate shaft, so the encoder doesn't carry any load.


The Grayhill model I mentioned is a digital input.

Oh my bad, then could I just use the encoder class built into the JAVA api to run it?

[Mark McLeod]

Oh my bad, then could I just use the encoder class built into the JAVA api to run it?
Yes, that works seamlessly with a Quadrature output-type, like the Grayhill 63R.

[Hugh Meyer]

It is absolutely critical that run out be very small and end play in the shaft be near zero. The distance the encoder wheel is set from the sensor is very important. You need to look at the signal with a scope. If everything is not just right the sensor will drop out one or the other of the A or B channel. This creates errors. It is important that the sensor base is used with the correct line count encoder wheel. If the two do not match then the relationship between the A and B signals will not be 90 degrees.

We mounted a KOP sensor on the CIM motor for our drive train. It was reading in the 4800 RPM range just fine once we got everything aligned properly. Attached is a photo.

We used the larger brother of the KOP sensor for the shooter. We used a 3/8" shaft. The sensor is larger, and seems easier to mount. Attached is a photo with the cap removed. Here is a link:

http://usdigital.com/products/encoders/incremental/rotary/kit/E7P

-Hugh

[billbo911]

Here's an example of an analog encoder (http://amci.com/pdfs/rotary-encoders/me15-rotary-encoder.pdf) with 10-bit resolution that's rated for 20,000 rpm. It is terribly expensive (but under the FRC $ limit), so I wouldn't recommend it. But it'll give you an idea of how simple the wiring and use is.
The wiring pinout is on page 12.


US Digital (usdigital.com) has this (http://usdigital.com/products/encoders/absolute/rotary/shaft/MA3) analog version that only runs around $67. It has a 15K RPM limit, with a +/- 1 deg of accuracy. It can be treated like a potentiometer for all intents and purposes, but is actually an absolute shaft encoder.

Depending on what you are trying to do with it, this may also be an option.

[Mark McLeod]

That's a more reasonable example of an analog encoder.
I was actually thinking of its predecessor the MA2, but didn't know what the new model # was.
That model is quite tiny and great for compact spaces.

It's a less complicated interface dealing with it as if it were an infinite rotation potentiometer (without the drawback of a pot dead spot).

There are also interface circuits to be had that can turn a digital absolute encoder into an analog input.

[Travis Hoffman]

This is a rather expensive but proven bulletproof product:

http://usdigital.com/products/encoders/incremental/rotary/hollow-bore/HB5M

We used it to monitor our shooter RPM. Installed very simply. Reliable, stress-free operation all season long.

[Tom Bottiglieri]

We use US Digital shaft encoders, with the ball bearing option. The bushing option is cheaper, but is less robust. These things are pretty bulletproof so long as you don't smash things into them or give them unreasonable side load.

We use these on our drive: http://usdigital.com/products/encoders/incremental/rotary/shaft/S4

And used these on our shooter due to the lower CPR: http://usdigital.com/products/encoders/incremental/rotary/shaft/S5

In retrospect, the S4 would have been fine for the shooter.

[smclean1969]

Thank you for everyone's inputs. I really appreciate it and we'll be putting this to good use in the upcoming season. One thing we're learning is where to spend money and where to save. Given the importance of having a reliable shooter this past season, having a working encoder was critical to having a successful shooter.

You can see from the attached photo, we did a custom encoder that has worked with maybe 25% reliability. This was a ton of work to have an unreliable system. So, we'll probably be purchasing several of these encoders and testing them all for the reliability and versatility.

thank you,