Mechanical Wheel Encoders?

Technical Electrical
1

My friend Dillon (aka Cmptrgk on these forums) and I are trying to find ways other than time to program next years robot’s autonomous mode. One of the ways we thought we might do this is by using wheel encoders.

However, we are trying to figure out what type of wheel encoder to use. There’s lots of information already on these forums about optical wheel encoders, but I was unable to find much good information about mechanical ones. Please point it out to me if I missed a thread about this while searching. We are considering the use of either mechanical or optical, so my first few questions are:

  1. Would you recommend the use of mechanical or optical sensors?
  2. What are the benefits of one over the other?

But back to the mechanical ones…
We are thinking of making our own.
Attached is a paint sketch that I made of one of our ideas.
Basically, when the gear-like thing underneath the sensor rotates, the button is pushed up and down with the ridges. When the button is pushed up, and electrical contact is made and voltage is detected on one of the robots inputs. (this could also be done vice versa).

  1. What do you think of it?
  2. do you think it is better to make your own or buy one?

I did a little research about mechanical encoders that I could buy from digikey. Note: To find what I am talking about in the following questions, click on “mechanical” under encoder type, then hit “apply filter”. It wont let me link to the results.

I am a little overwhelmed by the choices.

  1. What do you think is the best choice? Do you know of any others from a different but legal part supplier that would work better?

I also am not sure what some stuff means. Some of these questions are probably dumb, but bear with me:

  1. What does “PC Mount” mean? What does it mean to have a horizontal mount or a vertical mount or just a mount?

7)What is the difference between all of the different output types that are listed: what is the difference between binary, gray code, BCD, and serial?

  1. Of the above, what could be used with a FIRST robot?

  2. Under “features”, what do they mean by with or without switch? What does it mean to have a switch?

  3. What does “detent” mean? What is the significance of “yes” or “no” under this column?

and lastly…
Please share your experiences with mechanical encoders. I would appreciate it greatly.

Thank you so much for helping me out with this.
– Jaine

<edit> another question:
11) how many “clicks” per revolution would you recommend? This encoder would be used for the drive train most likely, not for the angle of an arm. (meaning that the encoder doesnt need to be as accurate as one you would use for an arm) </edit>

encoder idea.JPG


encoder idea.JPG

2

Jaine here’s some links that might help you, and if I find more I’ll post them.

Gray code

BCD

Basics of Encoders
This last link has to do with machine tools but it does have some good info on encoders.

Encoder/detent

3

an easier way of fabricating your own encoder (optical) would be to make a circular pattern with sections that alternate black and white (see attached pic). Then use the optical sensor and interrupts to count every time a white section passes the sensor. In my example, a full rotation of the wheel would need 16 clicks of the optical sensor.

  1. how many “clicks” per revolution would you recommend? This encoder would be used for the drive train most likely, not for the angle of an arm.

Most arms do not rotate more that 180 degrees, so you may want to look in a potentiometer or gyro for that.

encoder.jpg


encoder.jpg

4

http://dkc3.digikey.com/PDF/T043/1147-1150.pdf
Grayhill 61K64 Industrial Optical Rotary Encoders are what we plan to use this year. Warning, we have never used these before so I am not sure how well they will work.

5

Really, I don’t have a reason for one over the other.
Pros to Mechanical

  • Not affected by ambient light

Pros to Optical

  • May be slightly easier to stick on the robot (less sensitive to distance between the sensor and the disk)
  • Will never wear out (well, not in your life time) Mechanical switches will probably have to be replaced once in a while. Not a big deal though, they’re cheap, just build it so it’s easy
  • Don’t click at all.

Cons should be obvious with the pros, so I won’t mention them.

I’d personally go with optical, but not for any reason other than the noise. :wink: No preference really though.

They are different coding methods. Only a programmer will really care, but to make everything easy, I’d get a binary one.

It depends on how fast your robot can move, wheel sizes, how accurate you want it, etc., but I’d say somewhere between 16 and 32 as a rough estimate.

6

I don’t know if we have just had a really bad experience, but our team has had 4 Grayhill encoders and 3 of them have broken in some way or another. I would be wary. Two were series 63k. Both still work, but the back came unglued from one.
The other two were series 63t. One of them stopped working electrically and on the other the glass code disk somehow broke. That was probably due to a rather rough installation though. In any case, i am weary of grayhill products.

7

I’ve used the mechanical ones and experimented with the optical ones, both seem to work well, it just depends i guesse on your personal opinion and what you have to work with (money, supplies, space, etc)
I’d say that if you want to try and build your own, go for it, but make sure you have it working now and can translate it to a robot in the build season, i’d also recommend if your going to try and buy something to experiment with it now rather then later, because when we first started integrating alot of sensors into our robots for autonomous, it was trial by fire as we went along and alot of stuff didn’t work out.

8

Kini,
What you are proposing is perfectly OK but the optical sensor with an alternating wheel is the same thing but with less wear and tear on the components. The switch is not likely able to respond above a certain speed as the contacts just can’t go up and down that fast. Lubrication and a special tooth follower is needed as well. There are some encoders that magnetize the gear assy, then use a coil to count the teeth going by. That works just as well as the optical and is not affected by ambient light. Those encoders are not available from normal sources, though and would require you to make the interface. If you use the pattern that Tom suggested with an optical sensor, you can actually sense the change from light to dark (an edge detector) and get twice the resolution. Tom’s diagram shows 16 light and 16 dark segments which properly implemented would produce 32 counts per rev. On a wheel of a circumference of 16 inches (about 5" diameter) you would get resolution of 1/2" robot travel per tick. This is the system we use with a little less resolution, i.e. about 1" per tick.

9

Hi,
At Team 1425, we used mechanical encoders like the kind you suggested, except with a hex bolt and a limit switch. The problem we ran into is that when it went fast enough, the limit switch would bounce, and not give dead accurate readings. An optical sensor (I saw a few clever ones with Banner sensors) using a striped wheel is much more effective.

Sparks

10

first of all, let me say that i have no knowledge on the practical application of encoders. my team has never tried to use them (yet…). but i do have some knowledge in the backround of encoding technology, so here are some answers to your questions:

1+2) i would expect that mechanical encoders would be easier to use, but that depends on what your team is used to. i also agree that they would wear much faster than optical encoders so they would probably have to be replaced every once in a while. mechanical encoders also have some inherited flaws, like maxing out at a certain speed.

  1. first, using the gear teeth as a cam for the encoder would provide much more “clicks per revolution” than you would need, and the speed may surpass the ability of the encoder. convoluted teeth are also an awkward curve to follow, putting a lot of stress on the teeth and the encoder. perhaps you could cut depressions in the side of the gear to make it a little easier to follow, and allowing you to adjust the click rate.

another thing you need to worry about is contact bounce. whenever a mechanical switch is connected to an integrated circuit, such as the FRC, the contact voltage can “bounce” from between high and low anywhere from a few to a few hundred times before reaching a contant state, all in an extremely short period of time. i dont know exactly how this would effect the FRC. maybe the FRC cycles too slowly to even detect the bounce.

  1. binary is just plain base two numbering, where the digit weights correspond to values of 2^n. the binary number 101 is qual to (12^2)+(02^1)+(1*2^0).

grey code is a form of binary, but the actual correlation between the binary expression and the decimal expression does not follow the above scheme. grey code was designed so that only one bit changes for every integral increment or decrement. grey code was made specially for mechanical encoders because changing only one bit at a time minimizes digital errors. if two bits were to change in a single increment, then there is a chance that one bit may be detected before the other, causing the computer to think that the encoder jumped between three different states instead of two.

BCD is binary coded decimal. it functions the same way as regular binary, exept that each nybble (four bits) only goes up to the corresponding decimal value of 9. this way, one nybble can be used to easily express a decimal digit. for example, 7 corresponds to 1011, 5 corresponds to 1001, and 57 corresponds to 10011011

serial? mmm… cocoa puffs…

  1. all of the above can be integrated with the FRC, but they may introduce complications for the programmers.

good luck with the encoders, and please let us know how it works out.

11

Jaine,

1,2&4) I recommend optical encoders. Much easier to use and more reliable (less moving parts).

  1. PC stands for “printed circuit” and is meant to mount on a PC Board. The other common mount is called a “panel” mount. Panel mounts are normally easier for a FIRST team to use. Horizontal and vertical mean exactly what they sound like. Choose one of each and look at the picture.

  2. It varies from year to year according to the rules. Last year, DigiKey was an approved source. There was also cost restraints…

  3. The number of clicks per revolution depends on how many revolutions per second the encoder will see and how you are processing data. The 2004 Bobcat used 256 clicks per revolution on an encoder which rotated at less than 10 revolutions per second (max). This meant that the processor had to update (count) a maximum of 2560 times a second. Not a problem for the PIC18C…

Check out Kevin Watson’s web site for a good example of how to use optical encoders and interrupts with the RC controller.

12

You know what else? if you really want a good encoder that sends something other than pulses to your controller, check out gray encoders. They send out a binary reading based on position, and it’s much more accurate. A gray code is something like 001, then 010, then 011, ect, which makes them easy to read in code.

Sparks

13

In 2003 we mounted optical sensors perpendicular to our wheel sprockets and stickered on reflective material on the sprockets. They worked pretty well, but after a few competitions the mounts got chewed by the chain, so we removed them. In 2004 we used hall-effect sensors, we bought a type of building-toy-thing… (forgot the name) which had really powerful magnets (they were cylindrical, about 5 mm in diameter, i think), we cut the magnets out, drilled holes in our motor couplers and epoxied them in. The probes were glued into the motor mounts, directly above the magnets. It worked well, up to the point we reached very fast speeds, once in a while it works, sometimes it doesn’t.

14

Here’s a picture of our mechanical encoders from last year that sparks was describing earlier. It was basically a limit switch mounted by the hex shaft coming from the drill motor such that it picked up the six points as it spun, after going through the 2:1 right angle gearbox we had 12 counts per rotation. It wasn’t exactly high precision, but it worked alright for us.

Jeff

Encoder.jpg


Encoder.jpg

15

First of all I want to say THANK YOU to everyone who replied to this thread! This information has been EXTREMELY valuable to me.

Second:
Based on what many people in this thread have said, I think Dillon and I are going to use an optical encoder system for simplicity’s sake. It sounds like many teams have had success with them, and they don’t need to be replaced as often as mechanical ones do.

Yes, you are right that in the paint sketch I made there would be way too many clicks per revolution. It was supposed to illustrate the concept more than anything…it wasn’t really supposed to be a precise drawing. Same thing with the convoluted teeth…it’s really hard to make a good paint sketch of a gear! But thank you for the suggestions anyways!

Third:
At our last robotics meeting, I wired up the banner sensor to our robot, and it is working perfectly. I tested to see if it would detect the difference between black and white on the pattern that Tom posted (thanks Tom!), and it did.

We have written a program for it to count stripes, but we haven’t downloaded it yet (We ran out of time last meeting). We decided not to use interrupts, because we are still in the learning process and don’t want to mess up the controller by making mistakes. Instead, we just have a counter that will increment every time it detects a change in the color. Each time the program runs through, it checks the new value that is being read against the value that it last read, so that it doesn’t keep incrementing if the pattern is stationary and it is reading the same color. We also have a debug command so we can see if it is counting right and that everything is happy.

Even though this approach may not be fast enough to count ticks when the robot will be traveling very fast, this seems adequate enough for testing and learning purposes.

And speaking of learning…
Does anyone have an example of code that uses interrupts for an optical encoder like this one? I have read the quadrature encoder white paper, and I have the code examples from there, but since this is not a quadrature encoder setup I would like to see some examples that work before I start experimenting on my own.

All of your help has been greatly valuable to me and my team. This sharing of knowledge is what makes FIRST great.

Thanks,
– Jaine

16

Jaine,
It sounds like you have a really good start on this. If the count becomes erratic at very high speeds, just remake the pattern wheel so that it has less spokes. You rarely will need resolution down to the fraction of an inch. It is far more important that you get valid data than be able to resolve a tenth of an inch movement. When writing your code be aware that the choice of wheel tread material will affect distance traveled. If your tires wear, the circumference changes which may affect your distance. Remember that the errors accumulate the farther you travel.
Nice job so far, keep up the good work.