![]() |
Re: using potentiometer as shaft encoder
Quote:
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. |
Re: using potentiometer as shaft encoder
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 |
$100/$200 electronics spending rule and other electronic suppliers
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. |
Re: using potentiometer as shaft encoder
Quote:
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. |
Re: $100/$200 electronics spending rule and other electronic suppliers
Quote:
|
Re: using potentiometer as shaft encoder
Quote:
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. |
Re: using potentiometer as shaft encoder
Quote:
|
Re: using potentiometer as shaft encoder
Quote:
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? |
Re: Using Digi-Key Shaft Encoders
If you really, really want to use a potentiometer, why not use the Bourns 6639S-1-103 which is available at Digi-Key (search for 6639S-1-103-ND). I'd rather use an encoder.
-Kevin |
Re: Using Digi-Key Shaft Encoders
Quote:
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 |
Re: Using Digi-Key Shaft Encoders
Quote:
-Kevin |
Re: Using Digi-Key Shaft Encoders
Quote:
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. |
Re: Using Digi-Key Shaft Encoders
Quote:
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/...tent/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! |
Re: Using Digi-Key Shaft Encoders
Quote:
|
Re: Using Digi-Key Shaft Encoders
Quote:
Quote:
Quote:
Quote:
Quote:
-Kevin |
| All times are GMT -5. The time now is 10:12. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi