Problems with PID- PLEASE HELP!!!

[thinkpad]

Hey,

We are a rookie team and have been desperately (but unsuccessfully) trying to get the autonomous code provided by Mr. Watson to work.

Right now coming to the basics, when we ask the scripting code to drive 1500 mm, wait 20000 ms and then stop, the robot wheels just keep on driving. We are using the grayhill 63R128 encoders along with the ADXRS150 gyro. The gyro and the encoders work fine independently, but when put together in the Navigation code we get completely unpredicted results. We are not even on turning as of yet so i am not much worried about the gyro right now.

What could be wrong here? Has any other team who has had success with this please let us know what changes u needed to make in order to get things to work? We test this by putting the robot mobility on 4- 2" by 4" wooden stilts, can this make a difference despite the fact that the encoders are hooked up right?


Being a rookie we are completely clueless about this as we spent a lot of time making our mobility system and are short on time. Please help!

Thanks in advance,
vick.

PS. Let me inform you that I have tried searching for a similar post but didnt find anything, so if you have seen anything similar please post the link, thanks

[Tom Bottiglieri]

Originally Posted by thinkpad

Hey,


Right now coming to the basics, when we ask the scripting code to drive 1500 mm, wait 20000 ms and then stop

I dont understand what this does for you, maybe that is your error?

[thinkpad]

Originally Posted by Tom Bottiglieri

I dont understand what this does for you, maybe that is your error?

I am sorry I did not completely understand your question. I wanted to say that when i put this code in the commands.h file:

struct commands command_list[] = {
{CMD_GYRO_BIAS, 0, 0, 0},
{CMD_DRIVE, 1500, 0, 0},
{CMD_WAIT, 20000, 0, 0},
{CMD_STOP, 0, 0, 0},
{NULL, 0, 0, 0}
};
the robot just keeps on going forward for a long time without stopping at all. If you meant something else please let me know.

Thanks.

[Kevin Watson]

Originally Posted by thinkpad

I am sorry I did not completely understand your question. I wanted to say that when i put this code in the commands.h file:

struct commands command_list[] = {
{CMD_GYRO_BIAS, 0, 0, 0},
{CMD_DRIVE, 1500, 0, 0},
{CMD_WAIT, 20000, 0, 0},
{CMD_STOP, 0, 0, 0},
{NULL, 0, 0, 0}
};
the robot just keeps on going forward for a long time without stopping at all. If you meant something else please let me know.

Thanks.

Sounds like a sign problem. Make sure that when both motors are commanded forward, they spin in the direction that will propel the 'bot forward. This is done by setting the sign on these #defines in pid.h:

#define LEFT_DIR (-1)
#define RIGHT_DIR (1)

Next make sure the PID software properly detects the rotational direction by setting the sign on these #defines in encoder.h:

#define LEFT_ENCODER_TICK_DELTA -1
#define RIGHT_ENCODER_TICK_DELTA 1

When you're done, the encoder count will increase as the 'bot drives forward.

-Kevin

[thinkpad]

Originally Posted by Kevin Watson

Sounds like a sign problem. Make sure that when both motors are commanded forward, they spin in the direction that will propel the 'bot forward. This is done by setting the sign on these #defines in pid.h:

#define LEFT_DIR (-1)
#define RIGHT_DIR (1)

Next make sure the PID software properly detects the rotational direction by setting the sign on these #defines in encoder.h:

#define LEFT_ENCODER_TICK_DELTA -1
#define RIGHT_ENCODER_TICK_DELTA 1

When you're done, the encoder count will increase as the 'bot drives forward.

-Kevin

Thanks for responding Mr. Watson.

I just double-checked the code and it is set as per your reccomendations, but we get the same undesired results.

Is there a way to see the readings of the encoder counts in the PID files, i tried adding in printf statements in the PID.c file where the encoder count values are being called:
long int Get_Encoder_Count(int motor)
{
if (motor == 0)
{
temp = Get_Left_Encoder_Count();
printf("/rLeft count: %5d", (int)temp);
return (temp);
}
else if (motor == 1)
{
temp = Get_Right_Encoder_Count();
printf("/rRight count: %5d", (int)temp);
return (temp);
}

but this just prints out the values of Right count: 0 and Left count: 0. Can anyone tell why this can be?

I know i am being annoying, but we are really desperate about this, so please keep the inputs flowing.

Thanks for your suport,
Vick.

[Kevin Watson]

Originally Posted by thinkpad

Thanks for responding Mr. Watson.

I just double-checked the code and it is set as per your reccomendations, but we get the same undesired results.

Is there a way to see the readings of the encoder counts in the PID files, i tried adding in printf statements in the PID.c file where the encoder count values are being called:
long int Get_Encoder_Count(int motor)
{
if (motor == 0)
{
temp = Get_Left_Encoder_Count();
printf("/rLeft count: %5d", (int)temp);
return (temp);
}
else if (motor == 1)
{
temp = Get_Right_Encoder_Count();
printf("/rRight count: %5d", (int)temp);
return (temp);
}

but this just prints out the values of Right count: 0 and Left count: 0. Can anyone tell why this can be?

I know i am being annoying, but we are really desperate about this, so please keep the inputs flowing.

Thanks for your suport,
Vick.

How did you hook up the encoders (electrically and mechanically)?

-Kevin

[Alan Anderson]

Originally Posted by thinkpad

Is there a way to see the readings of the encoder counts in the PID files, i tried adding in printf statements in the PID.c file where the encoder count values are being called:
[...]
but this just prints out the values of Right count: 0 and Left count: 0. Can anyone tell why this can be?

The most likely reason is that the values really are zero. That would happen if your encoders aren't being processed correctly. How do you have the Grayhill encoders wired? Have you added code that disables the interrupts on their digital input pins?

Earlier you said that the encoders work when you're not also using the gyro. How did you determine this?

[thinkpad]

Originally Posted by Kevin

How did you hook up the encoders (electrically and mechanically)?

-Kevin

Originally Posted by Alan Anderson

The most likely reason is that the values really are zero. That would happen if your encoders aren't being processed correctly. How do you have the Grayhill encoders wired? Have you added code that disables the interrupts on their digital input pins?

Earlier you said that the encoders work when you're not also using the gyro. How did you determine this?

Electrically it is hooked up as per the recommendations on the encoder.c file. 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 can let you know the exact parameters of the calculation tomorrow morning as a mechanical engineering mentor did those calculations and i am not certain of those from the top of my head.

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.

[Kevin Watson]

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.

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

[thinkpad]

Originally Posted by Kevin Watson

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.


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

That makes sense Mr. Watson, i will try that out lowering the speed first thing tomorrow morning, and let you know of the results. As far as the speed, i was unable to measure it in a numerical value but I am going to say it was VERY fast so this makes more sense altogether.

I am sorry i don't understand what you meant by going to an encoder with a lower CPR. Do you recommend we get any other encoder in place of the Grayhill 63R128 ? I will talk to the mechanical guys to consider moving the encoders to the final shaft as well.

Thanks,
Vick.

[kaszeta]

Originally Posted by thinkpad

I am sorry i don't understand what you meant by going to an encoder with a lower CPR. Do you recommend we get any other encoder in place of the Grayhill 63R128 ?

Exactly. If your pulse per rev is too high, you need an encoder with a lower pulse rate (for example, a Grayhill 61K64 which has half the pulse rate), or you need to set a speed limit. Our team's test bot is doing the latter at the moment, since one of our 64 pulse encoders is broken and we had to sub in 128 pulse encoders, which trigger interrupts a bit too quickly for the controller to keep up.

(As a note, make sure you have a spare, as the Grayhill encoders aren't the most robust encoders out there, a bad blow to the shaft can take one out, and from experience, having to re-write the code in the pits to limp along without an encoder is not fun)

[thinkpad]

Hey,

I got the mechanical guys to put the encoders on the output chain of the wheel, and the current calculated counts per wheel revolution are 299 counts/ wheel revolution. It does work for driving a fixed length in a straight line right now, but it is at relatively lower speed that we will have on our final robot mobility. Is this counts per revolution OK (hopefully not overkill like before, especially if we want high speeds)?

Now I am trying to get the robot to turn (using the gyros), is there a variable where we can calibrate the turning speed as per our gearboxes? We have a tank like mobility system so the turning isn’t very sharp, so when i ask the scripting to turn 90 deg (1500 miliradians), I can see the motors are spinning at different rate, but since it is encountering a lot of friction I was wondering if it is possible to make it turn sharper?

Thanks for all the assistance you’ve provided so far, it is really appreciated, it is amazing even a rookie team can have a good autonomous, all because of your generous help.

Regards,
Vick.