View Single Post
  #9   Spotlight this post!  
Unread 07-02-2005, 01:10
Kevin Watson's Avatar
Kevin Watson Kevin Watson is offline
La Caņada High School
FRC #2429
Team Role: Mentor
 
Join Date: Jan 2002
Rookie Year: 2001
Location: La Caņada, California
Posts: 1,335
Kevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond repute
Re: Problems with PID- PLEASE HELP!!!

Quote:
Originally Posted by thinkpad
...Mechanically it is hooked up to the motor shaft (which of course is not same to the final gear output on the wheel). We compensated for this by calculating the gear ratio and converting these in a relationship to the counts per revolution of the wheel, which with our custom gearbox comes to around 1245 counts per wheel revolution.
I'll bet you're spinning the encoders too fast as 1245 counts per wheel revolution is overkill. If you spin the encoders too fast the software will think the shaft is spinning in the opposite direction that it actually is. This is mentioned in the readme.txt:

** IMPORTANT **
On a 40MHz PIC18F8520, this software can track peak encoder
count rates as high as a few thousand counts per second, which
should be more than adequate for most applications. To meet
your performance expectations, selecting the proper Counts Per
Revolution (CPR) parameter of your encoder is very important.
If the CPR is too high, the robot controller will spend too
much time counting encoder "ticks" and not enough time on
other tasks. At the extreme, you will see very wacky behavior
in your robot controller including corrupted data, the red-
light-of-death or the controller may even think the robot is
traveling in a direction that it isn't. Selecting a CPR that
is too low will not give you the resolution you desire. The
CPR should be optimized to minimize the number of interrupts
your robot controller will have to service yet meet your
resolution expectations (yes, millimeter position resolution
to too much to ask for).

To test this theory out, find these #defines in pid.h:

/* These define the motor control settings.
The max and min values are the greatest and smallest pwm
values that you want to use on your motors. */
#define MAX_PWM 182
#define MIN_PWM 82

And set the values to something like 152/112 and test again. This will lower the maximum shaft velocity to a value that the encoders can (hopefully) track. If the control loop suddenly starts to work, you found your problem. You'll probably need to go to a much lower CPR encoder or move the encoders to the output shaft.


Quote:
Originally Posted by thinkpad
I can say the encoders are working because i tried out the frc_encoder code (available from Mr. Watson's website) with the encoders hooked up. The wheels were manually rotated, and the encoders responded as they were supposed to and their measurements are consistent with out gear ratios.
You were also spinning the wheel at a much lower angular rate than the software was doing. Testing the 'bot unloaded (up on blocks) just made it worse because the wheels could spin-up faster than the 38Hz control loop could control. Just out of curiosity, how fast were the wheels spinning?

-Kevin
__________________
Kevin Watson
Engineer at stealth-mode startup
http://kevin.org