Thread: Encoder Code
View Single Post
  #32   Spotlight this post!  
Unread 18-10-2007, 15:16
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,113
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
Re: Encoder Code

Quote:
Originally Posted by emersont49 View Post
The reasons for using (or not using) PWMs 13 through 16 have never been clear.
The twelve "master-generated" PWM signals can only be changed when the regular communication happens between the two CPUs every 26.2 milliseconds. The original reason to use the four "user-generated" PWM signals was to be able to update them more often than that if necessary. The reason not to use them was that they were prone to jittery operation if the user program had interrupts enabled, including turning on Victor speed controllers when the code requested they be off. You can see why it might not be good to use them for drivetrain motors.

With Kevin's new stable PWM code, there's a new reason to use them: it's possible to get better resolution than the standard PWM outputs. If you want extra-precise control of servo position, you can essentially concentrate the 255 discrete steps into a smaller range of travel. This works great for controlling the CMUCam tilt/pan assembly and getting much better information on exactly which direction the green target light is from the robot.