Concept of PID explained

[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!