Concept of PID explained

[eugenebrooks]

Originally Posted by billbo911

Besides, I know many of you will have input as to why it will or will not work and, I'm hoping, ways to improve it. So here goes:

Your computed values for a PID system are best declared as int to avoid problems with overflow when assigning variables. For instance, in the assignment:
PosError3 = (p3_y - PosFdbk1);
a value larger than 127 can produce a negative result when stored in PosError3, providing for undesired behavior of the control system.

The same goes for DriveCmd3, in the assignment
DrvCmd3 = (127 + PosError3);
in general, although this instance might not be producing undesired results.

Your code implements a P control system, providing for two discrete
signals for smaller values of the error and an upper bound for large values of the error. It is suitable for a system that has a lot of friction, for instance something driven by a screw. The mechanical friction provides any required damping in this case. Our robot, this year, had this kind of drive system for the arm, and as a result we used a P control system with a one stage minimum for small errors. The Fisher Price motors were prone to smoke and it was better to have them "jump into the window," so to speak, and then be cleanly shut off. If they sat stalled they could burn up, and we did smoke one of the 6 volt motors this way.

You shift the value returned by Get_Analog_Value down by two bits, losing two bits of precision in the deal. This loss of precision can be a problem when implementing the arithmetic in a full PID control system, especially when doing subtraction involved in the D and I signals. It is better practice to shift the 8 bit values returned from the OI up by two bits, although for your specific code it is of no concern.

If your system does not have enough mechanical friction to damp oscillation, you will need to implement at least the D control signal. You can also scale and apply limits to the P, I and D signals imdependently before adding them. This allows you to easily tune each signal, without affecting the others. You will know if this is an issue when you try your code out on a given mechanical system. If you can't get rid of oscillation you will need to add a D signal, back down on the gain of the P signal, or both.

It is best to take care of the dead band of a given victor, and the conversion to an 8 bit unsigned value for the pwm controller, somewhat separately from the PID code after the full blown PID signal has been developed. The dead band of a victor can change when swapping a part, or if "recalibration" should occur (students can do that sort of thing). You can easily measure the minimum and maximum pwm signals that do not activate the motor, and update them in this section of the code without changing the PID control code above it.

Ultimately, every system is different, and the things that you need to do in order to control it can be, as a result, different. There is no limit to the phase space for being creative.

Have fun,
Eugene

[billbo911]

Eugene,
Thanks for the input. I truly appreciate any I can get! Your description of the code and how it is affected by mass and friction match exactly my thoughts and intent for this code. I understand that the adjustments thrown in for compensation of the Victors deadband characteristics are fairly generic and will not be accurate for all Victors, let alone one that has been "experimented" on by a curious student. (But, I gotta' say, I love their willingness to try something without really knowing the result. I just wish they would let me know before they try it on the competition robot )
Maybe in the next re-write I can move it outside this code and place it in a separate function.

As for the declaration of the two variables as "char" instead of "int":
The maximum range of PosError3 is -254 to 254. This is limited by they following code to -127 to 127 before it is used to create DrvCmd3. At the point DrvCmd3 is created, it can only take on a values of 0 to 254. (Again, I am new to C so here is where I may be mistaken) Both of these ranges of values can be represented by a "char" as well as a "int". I chose the "char" just to save a little memory space. I guess as sloppy as this code is, that really doesn't matter.

Either way, I have seen lots of coding examples where "int" is used as more of a standard, even though a "char" would work. Oh well, I'm still learning, and your input really helps.
Thanks again!!!!

[eugenebrooks]

Originally Posted by billbo911

As for the declaration of the two variables as "char" instead of "int":
The maximum range of PosError3 is -254 to 254.
This is limited by they following code to -127 to 127 before it is used to create DrvCmd3. At the point DrvCmd3 is created, it can only take on a values of 0 to 254. (Again, I am new to C so here is where I may be mistaken) Both of these ranges of values can be represented by a "char" as well as a "int". I chose the "char" just to save a little memory space. I guess as sloppy as this code is, that really doesn't matter.

Either way, I have seen lots of coding examples where "int" is used as more of a standard, even though a "char" would work. Oh well, I'm still learning, and your input really helps.
Thanks again!!!!

The range of PosError3, declared as a char, is -128 to 127.
The range of the expression assigned to it is larger. When you
assign 254, for instance, and read the value back from PosError3,
you will get -2, not the value intended. Looking at your code,
it looks like the result would be a pwm signal in the dead band,
instead of full forward. Assigning 128 will be read as -128,
and in this case your code will cause the motor to go full speed
in the wrong direction.

In the case of DrvCmd3, you have the same problem, but you are
saved by the fact that the computer takes the misinterpreted 8 bits
and blindly shoves them into the unsigned char, pwm03, so the result is
the one you expect.

As I noted, the issue a visible bug for PosError3, but does not manifest
itself as a bug for DrvCmd3. If you, or someone else, were to modify
the code to somehow test the value of DrvCmd3 and manipulate it
before assigning it to pwm03, the additional bug would surface.

A table of widths, and range, of integer types on the robot controller
can be found in "An introduction to C programming for FIRST robotics
applications." See "C programming for the robot controller"
at the web address
http://srvhsrobotics.org/index.php?g...tarticle&cat=2
for the latest version.

I hope this is helpful...

Eugene

[ConKbot of Doom]

Thanks, this helped out a lot, I have a feeling that even though I am graduating this year, I'm going to be doing the code for our team next year. No one to really pass on the knowlege to. Hopefully we gan get someone that can at least solder good, and make up sensors for the bot. We didn't use any this year. Not even any limit switches. Though it I had it my way, it would have been otherwise.

[billbo911]

Originally Posted by eugenebrooks

The range of PosError3, declared as a char, is -128 to 127.
The range of the expression assigned to it is larger. When you
assign 254, for instance, and read the value back from PosError3,
you will get -2, not the value intended. Looking at your code,
it looks like the result would be a pwm signal in the dead band,
instead of full forward. Assigning 128 will be read as -128,
and in this case your code will cause the motor to go full speed
in the wrong direction.

In the case of DrvCmd3, you have the same problem, but you are
saved by the fact that the computer takes the misinterpreted 8 bits
and blindly shoves them into the unsigned char, pwm03, so the result is
the one you expect.

As I noted, the issue a visible bug for PosError3, but does not manifest
itself as a bug for DrvCmd3. If you, or someone else, were to modify
the code to somehow test the value of DrvCmd3 and manipulate it
before assigning it to pwm03, the additional bug would surface.

A table of widths, and range, of integer types on the robot controller
can be found in "An introduction to C programming for FIRST robotics
applications." See "C programming for the robot controller"
at the web address
http://srvhsrobotics.org/index.php?g...tarticle&cat=2
for the latest version.

I hope this is helpful...

Eugene

After reading through the Integer Types and their Properties section of the paper you linked to and re-reading the IFI Programming Reference Guide and the MPLAB Compiler Users Guide, I see my error . With out a doubt, "int" should be used for both DrvCmd3 and PosError3.


Curiosity question here.
I noted significant differences between your paper and the IFI documents when it came to variable types and their ranges, primarily "int". Again I'm pleading ignorance here as I'm so new to coding. Why are they different?

Again, Thanks for your help! It would not have been fun trying to figure out where we/I had gone wrong with the code with out your input.

[eugenebrooks]

Originally Posted by billbo911

Curiosity question here.
I noted significant differences between your paper and the IFI documents when it came to variable types and their ranges, primarily "int". Again I'm pleading ignorance here as I'm so new to coding. Why are they different?

There are two tables in the paper. Table 1 is for EiC, the freely available
C interpreter used in the paper as a learning tool. Int is a 32 bit object
in EiC, with the associated signed and unsigned range. Table 2 is for
the C18 compiler used for the robot controller, where int is a 16 bit
type, with the associated signed and unsigned range. The text discusses
the issue. I hope that Table 2 is consistent with the data in IFI documents,
and the MPLAB C18 compiler documentation, it has been checked in
the past.

If you note a difference, please identify the document and page number.

[billbo911]

Originally Posted by eugenebrooks

There are two tables in the paper. Table 1 is for EiC, the freely available
C interpreter used in the paper as a learning tool. Int is a 32 bit object
in EiC, with the associated signed and unsigned range. Table 2 is for
the C18 compiler used for the robot controller, where int is a 16 bit
type, with the associated signed and unsigned range. The text discusses
the issue. I hope that Table 2 is consistent with the data in IFI documents,
and the MPLAB C18 compiler documentation, it has been checked in
the past.

If you note a difference, please identify the document and page number.

Sorry for the confusion. I did not look beyond Table 1. I assumed, and there lies the problem, that the first table I came across covered what I was looking for.

Either way, you were correct about the "int" declaration, it would have worked regardless which table I looked at.

Thanks again.

[DarKCroNo]

is there a way to apply this concept onto easy C? Sorry but it's our rookie year and we have no clue what we're in for, but basically we have gone for a design of 3 wheels, 2 being powered by a motor and running on an axle, and 1 in the front being steered by another motor, but the problem that arises is that after steering the motor to the left what I want to do is when the joystick is back at the centre position I would like the wheel to also move back into the centre position. I've been doing alot of research on PID closed loops, but all I've been getting is the theory behind it and I have no clue how to apply the programming for it. We went with easyC and I'm wondering if it works with it. Thanks in advance!