WebbotLib PID library functions

[Webbot]

For a while now I have had a PID skeleton in the library.

Looks like this

Code: [Select]

/*
 *  A generic PID controller based on pseudo code from Wikipedia:
 *  http://en.wikipedia.org/wiki/PID_controller
 *
    previous_error = 0
integral = 0
start:
error = setpoint - actual_position
integral = integral + (error*dt)
derivative = (error - previous_error)/dt
output = (Kp*error) + (Ki*integral) + (Kd*derivative)
previous_error = error
wait(dt)
goto start
 *
 */

#ifndef PID_H_
#define PID_H_

typedef struct s_pid {
float kP; // proportional scale factor
float kI; // integral scale factor
float kD; // derivative scale factor
float   integral; // The sum of the integral component
float setPoint; // The desired output position
float prevError; // The previous error amount
TICK_COUNT lastTime; // The last time I was called by setActual
} PID;

// Update the PID with the desired target position - the setPoint
void pidSetTarget(PID* pid,float setPoint);

// Update the PID with the actual position and return the new output
float pidSetActual(PID* pid,float actual);

// Construct a new PID controller
#define MAKE_PID(kP,kI,kD) {kP,kI,kD,(float)(0.0),(float)(0.0),(float(0.0),(TICK_COUNT)0}

#endif /* PID_H_ */


Anyone care to flush this out into something useful? Pseudo code in header is a start point.

Or is each PID just so tailored that it cannot be made generic?

[Admin]

Include it in the manual, document it with an actual code example, and people will use it.

[madsci1016]

I can help you with it. (Is there anything I can't do?)

First off, you should let the user define bounds for the output. For example, my heading PD (I skipped the I, usually it's more hassle tuning the system gains with an I then it's worth) controller outputs a differential speed for my right and left drive motors. This differential value can't exceed +/- 120 (no matter how large the error) or it causes problems for other parts of my code.

Any chance I can look at the source for the computations? Or Am I mis-understanding your question, and you actually haven't written it yet?

[Admin]

my heading PD (I skipped the I, usually it's more hassle tuning the system gains with an I then it's worth)

Good point, I always skip the I too. I recommend also adding a PD only option.

[madsci1016]

Good point, I always skip the I too. I recommend also adding a PD only option.

I was going to say that, but you could always just set I to 0 and save Webbot from having to code a whole separate structure without an I. 

[Webbot]

Yep - its a 'hang yourself question'

The existing code is non-existent - just the code comments listed previously which are there as an aide memoire to me. But then you've all opened up the source file in WebbotLib and seen that - right ?

And thats's why it ain't in the manual - nor used by anybody. It doesn't exist!

here's why:-

WebbotLib is Open Source - this means that as well as you being able to see MY code, that you folk can actually contribute to it as well for other folks use. The more the merrier.

I've never needed to write a PID function. I get the basics - but then you'll all beat me up with practical problems and documentation issues - right?
What better than examples from the real world.

I know that the 'I' component can be tricky - but can always be set to zero.

So if someone can submit a working example purely in a 'h' file then it can be passed around the WebbotLib community as an addition to the main WebbotLib and refined if required.

Once the 'h' file is stable then I'll build it into the library for others to use. Your name will appear in the h file as a credit - but nowhere else. And you may then then become the main support person for your code.

So if you want to step up and give it a go then great - welcome onboard - welcome to WebbotLib.

[madsci1016]

you'll all beat me up with practical problems and documentation issues

Who, me? Never! 

I'll take a crack at it, when I feel more comfortable with the lib's functions, and my programming skill. Until then, anyone else is welcome to beat me to the punch.

But like i said, your base model is lacking fields already. Is this PID.h compiled into the .a files already? Meaning if i wanted to change what is passed into those functions or add to the struct, i would have to write new ones with slightly different names.

[Webbot]

The pid.h is used by nobody - its also not used by anything else,  since there is only an 'h' file and no code then there is also nothing in the lib.

Its just a placeholder.

So you can do what you want to it.

I'll take a crack at it

Excellent!

Now I get to comment on someone else's code !
 

Over to you

[madsci1016]

I'm getting close to a beta version and need some testers. Anyone with a simple control system willing to test for me?

[madsci1016]

This is a question for Webbot and anyone else who would like to comment.

Do you see a reason to keep the PID controller all float type? All the PID controllers i ever wrote where integers except for the gains. It seems to me that having all the values passed in/out as well as used in the PID code as floats is an awful lot of overhead.

Is it worth it to keep this all floats? If anyone had a control system that operated in decimal places, they could always scale it up (*100) / down to use the PID code.


EDIT: nevermind, doesn't seem to make that much different as i watch my MCU loading gauge. 

[Admin]

MCU loading gauge

a what?

[Webbot]

Just a guess but he may have implemented my suggestion regarding showing CPU busy vs idle time and realised that floating point is still fast enough to not overload his program.

But 'madsci' - yes there is another benefit to sticking to integers if its possible - it saves a few kb by not needing the floating pont library - good for smaller processors.

[madsci1016]

Guess correct, i have a % processor load as Webbot suggested, and saw no difference with floating point calcs.

Webbot, we couldn't ditch floating point numbers altogether as the gains will always have to be floating point, so i don't think there's a benefit to switching the rest.

My pid.h is ready for some beta testers if i can get any. I tested it on SAGAR and used it as my heading PID controller and didn't find any bugs.

The controller is a bit complex to setup so i will have to write up an explanation for my tester, here's the struct for it.

Code: [Select]

typedef struct s_pid {
float kP; // proportional scale factor
float kI; // integral scale factor
float kD; // derivative scale factor
float   inMax; //input maximum
float   inMin; //input min
float   inSpan;         //the span of input, calculated by pre-processor macro to avoid work for MCU
float   outMax; //max PID output
float   outMin; //min PID output
float   Ilimit; //limit to avoid wind-up
boolean isCircular; //is this a circular system, like a compass or cont rotation actuator?
float   integral; // The sum of the integral component
float setPoint; // The desired output position
float prevError; // The previous error amount
TICK_COUNT lastTime; // The last time I was called by setActual
} PID;

Any takers?

Once i get the bugs worked out of this, I'm going to write a Labview program that lets you easily 'tune' the controller. You will be able to put the PID loop in 'tuning mode' on you robot with a link to your pc, and run the labview program. It will plot the actual and setpoint over time on the same graph and allow you to change the controller gains on the fly, until you find the gains that give you a stable system.

[Webbot]

Webbot, we couldn't ditch floating point numbers altogether as the gains will always have to be floating point, so i don't think there's a benefit to switching the rest.

Only suggested it as you proposed it was an option. But always thought float would be needed.

I'm a 'taker' - don't have stuff to try it with particularly but would be good to have some form of sanity check on the code (which I'm sure is fine!)
eg do you have a MAKE_PID that sets up the structure with the minimum of effort etc etc.
and maybe a MAKE_PD which is the same but sets kI to zero.

[madsci1016]

In email.