Thread: Encoder Code
View Single Post
  #29   Spotlight this post!  
Unread 17-10-2007, 23:28
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,188
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: Encoder Code

Quote:
Originally Posted by AdamHeard View Post
I think we'll go with 64 counts. That gives us about 1586 ticks per second (per side) and a res of .17 inches. That leaves plenty of interrupts open for possible future addons.

Does that sound good?
You could cut the number of interrupts you are handling down by about a factor of 4 or 5 and see absolutely no change in performance. I would bet my shiny new iPhone that no FIRST robot ever has, or ever will, be accurate to 0.17". You may want to shoot for a resolution of .5 or 1 inch. It will drop the the cost of your hardware solution and save your programmers a whole bunch of headache. While the amount of interrupts you are looking at are in the theoretical limits of what the PIC can handle, your program will have to be very robust and optimized to not crash the system.