View Full Version : Using Digi-Key Shaft Encoders
How would I go about programming one of these, and which one would be ideal for positioning a low speed (60 RPM) shaft? Any info is appriciated. Thanx.
Digi-Key Shaft Encoder Pages:
http://dkc3.digikey.com/PDF/T031/0830.pdf
http://dkc3.digikey.com/PDF/T031/0831.pdf
http://dkc3.digikey.com/PDF/T031/0832.pdf
At 60rpm, you can use just about anything as that's only 1 rps, meaning you could, in theory, sample down to 1/40th of a rotation.
As for programming, I'd recommend having a few lines of code to turn the input into a numeric identifier for the current position. Then, just compare that position to the one from the last loop to figure out how far you've rotated in the previous 26ms. The only non-trivial part is going to be dealing with loops (ie position was 4 last time, but now is 1--you need to recognize that in this case 1>4).
Don Reid
19-01-2003, 13:32
Are you trying to measure the position (angle) of a shaft, or the speed of rotation. As Rob says, they will work for speeds like yours.
If you want position or the angle, like for a steering system, then the problem with these is the low resolution. Most have 16-32 "codes" per rotation. This means you can only get the position to +/- 1/32 of a rotation (~11 deg.). To get more resolution, you could connect one with a belt or gears so that the encoder rotated more than the shaft being measured, more complex.
We are trying to feedback angle from the shaft encoder, we are looking at the 256 ticks/rev so our resolution will be fine. We don't need it perfect, just somthing like <10 degrees.
In that case, you should be fine. 60rpm=1rps=9degrees/26ms. Therefore, in theory the Stamp could sample down to approx. 9 degree resolution. That's assuming, of course, that it hits the new position EXACTLY as the controller is sampling, but you should be able to get decent resolution none-the-less.
Yes it all should work fine.
In real life the rule of thumb is to sample at greater than 10 times the max output Frequency. That mean that the Max encoder frequency should be no greater than .26 sec.
Don't you mean .026, That would be 26 milliSeconds.
26mSec is the update rate of the BS that we can't change so the max Freguency of our input is 260mSec or 3.8Hz. If your encoder signal is faster than this you will run the risk of missing pulses.
crazycliffy
20-01-2003, 13:37
so if 26ms is your sampling time. this is about 38.4Hz
then 38.4 / 10 = 3.84 Hz. = 0.26 seconds or 260 ms.
your motors should not rotate faster then 3.84Hz.
Theoretically, you only need a two folds the sample time.
This is also called the nyquist frequency, or aliasing frequency.
WizardOfAz
25-11-2003, 08:33
We are intending to use one of these, or something equivalent to measure steering angle. I've read through the posts above and I don't think the analysis above is correct.
The device generates 256 pulses per revolution. At 60 rpm, 1 rps, this is 4 milliseconds per pulse. Especially with last year's stamp, there's no chance of sampling fast enough to use this device.
With this year's processor, maybe it will work. Has anyone tried? Or measured how often an interrupt can be serviced under "normal" cpu loads? 4 ms is probably only a few hundred instructions, perhaps close to 1000. I'm a bit doubtful that you can do it without totally consuming the cpu.
If you can tolerate less angular resolution and use the 128 or 64 pulse per rev device, seems like you have a lot better chance of making this work.
Or am I missing something here?
Bill
Matt Reiland
25-11-2003, 08:36
To measure steering angle (Unless you want continous rotation) remember a potentiometer works great and is 'absolute'by nature so you don't need a running count or a calibration on power up.
Originally posted by D.Viddy
How would I go about programming one of these, and which one would be ideal for positioning a low speed (60 RPM) shaft? Any info is appriciated. Thanx.
Digi-Key Shaft Encoder Pages:
http://dkc3.digikey.com/PDF/T031/0830.pdf
http://dkc3.digikey.com/PDF/T031/0831.pdf
http://dkc3.digikey.com/PDF/T031/0832.pdf
If you're talking about using the mechanical encoders on these pages, make sure you use the gray scale version. The BCD will screw you up.
If you're talking about the optical encoders, then you have a couple of choices. I think you can rig the RC as a counter. One way would be to tie the encoder into a low priority interrupt and fire an interrupt on each pulse. This may become very band-width intensive though.
There are also chips available which do all the counting and demodulating for you. I haven't looked through digikey to find one, but I'm sure they sell them. I've use HPs (now Agilent's) chips, in particular the HCTL1100, which is far more expensive and powerful than you would need.
Or, you could rig up a counter circuit of your own. Depends on your electrical design skills.
If you need more resolution, you can always attach a measurement gear to your system. This has the added advantage of protecting your encoder from the shocks and abuse that your drive wheels will experience. If you do this, you need to remember to use a fine pitch gear set or an anti-backlash gear to minimize the errors introduced by backlash.
WizardOfAz
25-11-2003, 09:38
Piher makes a continuous rotation pot, the N15 series. Spec sheet here:
http://www.piher-nacesa.com/pdf/n15.pdf
Mouser sells them (mouser.com). For example, mouser part# 531-N15TV-100K. They only do 340 degrees, so you need two of them to get 360 coverage.
The advantage over the optical sensors is
- direct readout (no CPU load)
- easy to program
- cheap @ $3
The disadvantages are
- poor accuracy (3% = 11 degrees)
Bill
WizardOfAz
15-01-2004, 10:10
Piher makes a continuous rotation pot, the N15 series. Spec sheet here:
http://www.piher-nacesa.com/pdf/n15.pdf
Mouser sells them (mouser.com). For example, mouser part# 531-N15TV-100K. They only do 340 degrees, so you need two of them to get 360 coverage.
The advantage over the optical sensors is
- direct readout (no CPU load)
- easy to program
- cheap @ $3
The disadvantages are
- poor accuracy (3% = 11 degrees)
Bill
Actually, there's another disadvantage of these Piher potentiometers - you can't get them from any of the permitted suppliers (newarkinone, future-active, digikey), so I guess you can't use them. Does anybody know of any "out" for this? Does every little $2 or $3 part I might buy at some local electronics store for the robot also have to be obtainable from the listed suppliers? What would seem reasonable to me is that there be a lower limit, maybe $5 or $10 dollars, under which you could buy electronics parts from anybody.
It's too bad if we can't use these Piher pots (for example). They are less than $3 each and make great continuous rotation sensors. I have not yet found anything similar from the listed suppliers.
Bill
Joe Johnson
15-01-2004, 17:18
Actually, there's another disadvantage of these Piher potentiometers - you can't get them from any of the permitted suppliers (newarkinone, future-active, digikey), so I guess you can't use them. Does anybody know of any "out" for this? Does every little $2 or $3 part I might buy at some local electronics store for the robot also have to be obtainable from the listed suppliers? What would seem reasonable to me is that there be a lower limit, maybe $5 or $10 dollars, under which you could buy electronics parts from anybody.
It's too bad if we can't use these Piher pots (for example). They are less than $3 each and make great continuous rotation sensors. I have not yet found anything similar from the listed suppliers.
Bill
As I understand it, we've got only those 3 suppliers. But, I like your idea. I think we should propose it to FIRST (for at least 2005 if not this season).
Anyone up for making the suggestion? Nice and pretty now, nothing like, "you guys really blew it on this 3 supplier's only rule, you can make it up to us by getting half a brain and ..." Remember, we want them to agree with us!
Joe J.
WizardOfAz
16-01-2004, 11:46
Joe, seems like you're a big name, why don't you do it? If not, somebody remind me the approved mechanism for making such suggestions and I'll do it.
Bill
WizardOfAz
16-01-2004, 13:31
Some related questions have already been asked, but not yet answered:
on 1/13:
Q: In the past, items such as wire, switches, and pots were not considered part of the custom circuit and its $200 limit. The rules do not make distinctions between the custom circuit and other robot electronics. Please clarify
and on 1/15 a related question:
Q: We need 5 Victor speed controllers (kit has 4). The extra controller costs >$100. R75 sets individual itemlimit to $400. R71 sets limit of electronic component to $100. Does the Victor speed controller fall under rule R71 or R75?
Neither of these specifically ask about using other suppliers for "trivial" parts, so I guess that question should still be asked.
Joe Johnson
16-01-2004, 16:46
Joe, seems like you're a big name, why don't you do it? If not, somebody remind me the approved mechanism for making such suggestions and I'll do it.
Bill
There isn't really a process. I think you more or less just send them an e-mail (assuming you know them already).
I think I am pretty much tapped out on the "making suggestions" front. My thought was that FIRST was tired of hearing from me, someone new would perhaps get a better hearing.
Joe J.
Craig Putnam
16-01-2004, 21:31
Q: We need 5 Victor speed controllers (kit has 4). The extra controller costs >$100. R75 sets individual itemlimit to $400. R71 sets limit of electronic component to $100. Does the Victor speed controller fall under rule R71 or R75?
See rule <R77> which addresses purchase of additional components from IFI. As I read it you can have whatever you want, but the components are included in the $3500 maximum cost.
[clipped text] ... What would seem reasonable to me is that there be a lower limit, maybe $5 or $10 dollars, under which you could buy electronics parts from anybody.
It's too bad if we can't use these Piher pots (for example). They are less than $3 each and make great continuous rotation sensors. I have not yet found anything similar from the listed suppliers.
I'd like to see the rule amended to say we can purchase compenets that meet the $$$ requirements ($100/$200) that we can obtain from Newark, Digikey, and Future Active OR from a supplier/distributor SUCH THAT the component or comparable component is available from Newark, Digikey, or Future Active.
Does that make sense? This rule would be in the spirit of the GP. If we buy a part from our local distributor and Digikey or the others sell a comparable item (at comparable pricing), I see no advantage that one team could gain.
I'll post on the Q&A and let's see what they think.
WizardOfAz
16-01-2004, 23:35
I'd like to see the rule amended to say we can purchase compenets that meet the $$$ requirements ($100/$200) that we can obtain from Newark, Digikey, and Future Active OR from a supplier/distributor SUCH THAT the component or comparable component is available from Newark, Digikey, or Future Active....
Actually, that IS the rule. See <R71>. It says the parts must be available from the suppliers, not that they have to be bought from them.
Actually, that IS the rule. See <R71>. It says the parts must be available from the suppliers, not that they have to be bought from them.
My mistake, I didn't make my self clear. I posted on the Q&A at usfirt that is a little more clear.
My intent was that a component A manufactured by company X where Digikey, Future, and Newark are not distributors of X. However, they are distributors for company Y (competitor to X) that manufacture component B (comparable to A).
For example, where A and B might be potentiometers with similar ratings and resistor ranges and comparable costs.
Does that make sense?
Kevin Watson
17-01-2004, 19:19
If you really, really want to use a potentiometer, why not use the Bourns 6639S-1-103 (http://www.bourns.com/2/pdfs/6539.pdf) which is available at Digi-Key (http://www.digikey.com) (search for 6639S-1-103-ND). I'd rather use an encoder. (http://www.chiefdelphi.com/forums/showthread.php?t=23192)
-Kevin
WizardOfAz
18-01-2004, 01:07
If you really, really want to use a potentiometer, why not use the Bourns 6639S-1-103 (http://www.bourns.com/2/pdfs/6539.pdf) which is available at Digi-Key (http://www.digikey.com) (search for 6639S-1-103-ND). I'd rather use an encoder. (http://www.chiefdelphi.com/forums/showthread.php?t=23192)
-Kevin
Kevin, thanks for finding that pot. DigiKey shows it as "1 turn", so I had not found it. But in the Bourne link, it's clear that it is continuous rotation and would serve as well as the Piher part. Too bad it costs 4x the Piher one.
My concern about encoders was the CPU utilization, though I didn't much more than guess about this issue. Any estimates what it will take to track an encoder that reads 128 or better pulses per rev?
Bill
Kevin Watson
18-01-2004, 01:34
My concern about encoders was the CPU utilization, though I didn't much more than guess about this issue. Any estimates what it will take to track an encoder that reads 128 or better pulses per rev?How many counts per second? Several hundred per second shouldn't be a problem. While testing my encoder code, I noticed that the controller could keep up with a peak count rate of just over 5,000/counts/second.
-Kevin
Jay Lundy
18-01-2004, 02:44
My concern about encoders was the CPU utilization, though I didn't much more than guess about this issue. Any estimates what it will take to track an encoder that reads 128 or better pulses per rev? Let's assume 15 ft/s with 6 in diameter wheels (very fast).
That's 9.55 rev/s or 1222 cycles/s.
Should be fine.
Also, (818.1 us/cycle) / (.1 us/instruction) = 8180 instructions/cycle
Assuming your int handler takes 10 instructions, 0.122% of your instructions are devoted to 1 of your encoders.
Heh, I think I got carried away with that calculation, but I was curious myself.
If you really, really want to use a potentiometer, why not use the Bourns 6639S-1-103 (http://www.bourns.com/2/pdfs/6539.pdf) which is available at Digi-Key (http://www.digikey.com) (search for 6639S-1-103-ND). I'd rather use an encoder. (http://www.chiefdelphi.com/forums/showthread.php?t=23192)
-Kevin
The 6639S-1-103 Bourns pot is 10K and not available in a 100K. Will adding 90K resistors in series be acceptable to the RC? It seems like we would lose quite a bit of the RC's resolution.
FIRST has promoted the use of sensors the last few years. It seems like many teams are looking for either one of two things here:
1. Some type of encoder/pot to measure steering angle (slow rpm, continuous turn with good resolution ~3°). I like the idea of a continuous pot because it doesn't take up CPU power and takes almost nothing to program, and does not rely on starting postition (absolute). An optical encoder measuring ticks (like a mouse) needs to count not only ticks, but the direction of ticks. PS/2 mice have two optical sensors, and with some programming outside of beginners, these two sensors can measure both position and direction (relative to some starting point).
2. Angular velocity in order to measure speed of shaft rotation, which can then give you the linear distance traveled by the output wheel/belt (C=pi*D).
The http://www.rec.ri.cmu.edu/education/edubot/2004_content/index.htm site has some information listed for encoders, but I didn't find where to obtain their encoders and they were not in the Edubot or KOP. Where do we obtain these parts? The sample programs count the number of ticks in a constant direction, but what about when the wheel changes direction or is attached to steering? The sample code does not address this issue.
Sample code from FIRST or Innovation FIRST would help teams to concentrate on building robots. Not all teams have the resource or knowledge to construct additional electronics that use encoders to measure steering angles, angular velocity, etc. which is in turn converted back to an analog signal readable by the RC analog inputs.
Any help from other teams who have knowledge on how to do any of the above would be appreciated!
WizardOfAz
18-01-2004, 11:12
Let's assume 15 ft/s with 6 in diameter wheels (very fast).
That's 9.55 rev/s or 1222 cycles/s.
Should be fine.
Also, (818.1 us/cycle) / (.1 us/instruction) = 8180 instructions/cycle
Assuming your int handler takes 10 instructions, 0.122% of your instructions are devoted to 1 of your encoders.
Heh, I think I got carried away with that calculation, but I was curious myself.
Hmmm. I'm not going to dive into the details of this I guess, since I'm going to continue down the "pot path" for measuring the angle. But I suspect this calculation is more than a bit optimistic. (1) can you really handle the shaft encoder interrupt in about 10 instructions? (2) are all instructions one cycle with no wait states needed? (3) what about the state save/restore cost of the interrupt? I'll bet it's more like 1% than 0.1%, still not too much load if you don't have a lot of them.
Kevin Watson
18-01-2004, 12:38
The 6639S-1-103 Bourns pot is 10K and not available in a 100K. Will adding 90K resistors in series be acceptable to the RC? It seems like we would lose quite a bit of the RC's resolution.No, you don't need to use the additional 90K. 10Kohms across 5v means that only 0.5mA of static current will flow through the potentiometer for a power dissipation of 2.5mW. The potentiometer is rated far above this value and therefore safe to use.
1. Some type of encoder/pot to measure steering angle (slow rpm, continuous turn with good resolution ~3°)To get good resolution you'll probably need an encoder because the linearity of non-wirewound potentiometers is questionable.
I like the idea of a continuous pot because it doesn't take up CPU power and takes almost nothing to program, and does not rely on starting postition (absolute). Yes, these are good attributes. If you really need the accuracy or just want to learn how robotics engineers do it in the real world, I'd suggest at least looking at an optical encoder. Here are a few ways to get around the starting position problem: 1) Make sure the wheels are straight when you start the robot 2) Use a potentiometer to find the zero position at startup, then use the encoder for steering angle. 3) Have the computer run through a calibration sequence at startup, stepping the steering angle in one direction until a switch is tripped at a pre-determined angle. 4) If your steering mechanism is robust, you can run through a calibration sequence that steps the steering in one direction until you run into a hard stop which causes a sudden increase in motor current that can be detected with the current sensor.
http://www.rec.ri.cmu.edu/education/edubot/2004_content/index.htm site has some information listed for encoders, but I didn't find where to obtain their encoders and they were not in the Edubot or KOP. Where do we obtain these parts?Digi-Key (http://www.digikey.com/) has many. An example is the grayhill 61K128-050 (http://embrace.grayhill.com/embrace/IMAGES/PDF/I-37-41.pdf).
Sample code from FIRST or Innovation FIRST would help teams to concentrate on building robots. See http://kevin.org/frc for an encoder interface example.
-Kevin
Kevin Watson
18-01-2004, 13:02
Hmmm. I'm not going to dive into the details of this I guess, since I'm going to continue down the "pot path" for measuring the angle. But I suspect this calculation is more than a bit optimistic. (1) can you really handle the shaft encoder interrupt in about 10 instructions? (2) are all instructions one cycle with no wait states needed? (3) what about the state save/restore cost of the interrupt? I'll bet it's more like 1% than 0.1%, still not too much load if you don't have a lot of them. It's 40 or 50 instructions total. There are no wait states involved.
-Kevin
I'm having trouble with the links to digikey at the first of this post. Does anyone know the part numbers that the links refer to?
Or alternatively, any recommends for digi-key optical encoders?
Thanks.
If you really, really want to use a potentiometer, why not use the Bourns 6639S-1-103 (http://www.bourns.com/2/pdfs/6539.pdf) which is available at Digi-Key (http://www.digikey.com) (search for 6639S-1-103-ND). I'd rather use an encoder. (http://www.chiefdelphi.com/forums/showthread.php?t=23192)
-KevinI am in heavy deliberation at the moment. I am trying to decide whether or not I wish to use a potentiometer or encoder for something relating to the subject of this thread. I am pretty much at a loss for good reasons (I have never used potentiometers or encoders before), so I am wondering why you have a bias that steers more towards an encoder than to a potentiometer.
I am in heavy deliberation at the moment. I am trying to decide whether or not I wish to use a potentiometer or encoder for something relating to the subject of this thread. I am pretty much at a loss for good reasons (I have never used potentiometers or encoders before), so I am wondering why you have a bias that steers more towards an encoder than to a potentiometer.
Because almost all potentiometers that will find will not revolve all the way around. Also pots wear out very easily when attached to a constantly rotating shaft. Last years controller was too slow for using an encoder. This years processor has no trouble keeping up with a 256 tick encoder. We have ours controlling our motors beautifully right now. Dead recoding is incredably precise with them. It's not a bias, it's just one is better than the other.
It's 40 or 50 instructions total. There are no wait states involved.
-Kevin
I have written my own Interrupt handler for reading the optical encoders. Is there an easy way to see how many instructions the C Code translates to?
steven114
15-02-2004, 18:00
In MPLAB IDE, go to View->Disassembly
Kevin Watson
15-02-2004, 22:56
I have written my own Interrupt handler for reading the optical encoders. Is there an easy way to see how many instructions the C Code translates to?Yes, there certainly is. Have a look at the .lst file that the compiler generates. It's a text file that shows you what assembly and machine code the compiler generated and where it placed it in memory.
-Kevin
Because almost all potentiometers that will find will not revolve all the way around. Also pots wear out very easily when attached to a constantly rotating shaft. Last years controller was too slow for using an encoder. This years processor has no trouble keeping up with a 256 tick encoder. We have ours controlling our motors beautifully right now. Dead recoding is incredably precise with them. It's not a bias, it's just one is better than the other.Ok, thanks.
Kevin Watson
16-02-2004, 03:34
I am in heavy deliberation at the moment. I am trying to decide whether or not I wish to use a potentiometer or encoder for something relating to the subject of this thread. I am pretty much at a loss for good reasons (I have never used potentiometers or encoders before), so I am wondering why you have a bias that steers more towards an encoder than to a potentiometer.As Dylan and others have pointed out, potentiometers have problems when used for positioning/control. Encoders, on the other hand, are designed for this type of application. You can find some example encoder code here (http://kevin.org/frc).
-Kevin
Greg Powers
02-03-2004, 15:21
mechanical or optical encoders? i know the mechanical encoders are alot cheaper and i was wondering how much that degraded quality
does anyone know the pro's con's between the two?
we plan on using them to compensate for steering problems and atonomous and aren't sure which we want.
steven114
02-03-2004, 19:28
Mechanical encoders don't last nearly as long as optical ones do - check the specs on them for that measurement.
Have you read the white paper titled "Quadrature Encoders"?
This should help you a lot. email me if you have any specific questions or comments.
Daniel
sudeepr71
01-01-2005, 20:06
After reading this forum, I still have a few questions.
What exactly is a encoder?
And how can I use it to measure the speed of the robot?
Alan Anderson
02-01-2005, 14:49
What exactly is a encoder?
And how can I use it to measure the speed of the robot?
There are a few different kinds of encoders. What most people here are talking about are "rotary shaft encoders", which can tell you the angular position of a rotating shaft. Usually that's done by counting pulses as it turns. Some encoders have thousands of steps per rotation, giving a very precise measurement. At the other end of the precision scale, last year's TechnoKat robot used six black stripes on the wheel hubs with Banner sensors to measure wheel rotation.
To measure the speed, you just use the difference in position between two measurements at different times.
sudeepr71
02-01-2005, 19:16
At the other end of the precision scale, last year's TechnoKat robot used six black stripes on the wheel hubs with Banner sensors to measure wheel rotation.
To measure the speed, you just use the difference in position between two measurements at different times.
On your last year's robot you used it to see how far to go and then turn or something for the autonomous mode? We tried that and found that it wasn't as accurate as the line following.
So to find the speed, one would have two encoders at different times and subtract them?
WizardOfAz
02-01-2005, 20:11
On your last year's robot you used it to see how far to go and then turn or something for the autonomous mode? We tried that and found that it wasn't as accurate as the line following.
So to find the speed, one would have two encoders at different times and subtract them?
Just one encoder to get distance and speed. You can use the timer support to get an accurate time base and distance/time to get the speed.
Bill
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.