PID vs Normal loops

[3DWolf]

One of my mentors assigned me a project for off season so we could get some better arm controllage going on, and he said to use a PID loop.

I'm still fairly new to C++ so bear with me.

While I know little to nothing on Integrals and Derivatives, this is confusing to me. I understand that PID loops are used to narrow things from point A to point B without overshooting or gyrating while going as fast as possible.

I found some old PID code for our drive system last year, but I can't really make heads or tails of it.

And all the while, I don't really see a need for all that math, couldn't you do something such as

#include <math.h>

#define p1 = pwm01; //Pot 1
#define p2 = pwm02; //Pot 2
#define dvr = pwm03; //Motor

int dist;
void Correct();
int Clamp(int var, int lBound, int mBound);

void Correct(){
	if (!p1 == p2){
		while (p1 > p2){
			dist = Abs(p1 - p2);
			dvr = 127 + Clamp(dist, 127, 255);
		}
		while (p1 < p2){
			dist = Abs(p1 - p2);
			dvr = 127 - Clamp(dist, 0, 127);
		}
	}
}

int Clamp(int var, int lBound, int mBound){
	if (var < lBound)
		return lBound;
	if (var > mBound)
		return mBound;
	else
		return var;
}

[Dave Flowerday]

Originally Posted by 3DWolf

And all the while, I don't really see a need for all that math, couldn't you do something such as

What you've shown here is the "P" portion of a PID loop (the motor output is proportional to the difference between where you are and where you want to go).

This is where most people start when working on a control loop, and in some cases it will be good enough. What you will likely find, however, is that when p1 starts to get close to p2, your motor output will be so small that the motor may not actually move. Your instinct may then be to multiply "dist" by 2 to make the motor run faster, but if you keep doing this you'll eventually get to the point where your arm continuously overshoots it's target (this would be the equivalent of increasing the "P" constant in a PID loop).

PID is all about trying to make a control loop that moves a motor to a desired position as quickly as possible but also have it stop when it's supposed to without overshooting.

[JesseK]

Your code works in theory, but ties up the processor for the duration of that while loop such that the only thing that works on the robot in the while loop is the dvr variable.

Because of this, and limited previous FRC programming experiences, I believe while loops are not possible on a PIC processor.

[Tom Bottiglieri]

Read this. It helped me out A LOT! http://www.embedded.com/2000/0010/0010feat3.htm

In math, function line is whatever is on your graph in the present, the derivative is the slope of a line at any point in time, and the integral is how much area fits under a curve in a given time range.

In robots, the present (P term) is where you are right now, the integral (I term) is where you have been, and the derivative (D term) is how fast you are getting to where you are going. If you know these three things, you can decrease the amount of time it takes to get to your set point, and decrease overshoot and settling time once you get there.

Doing control without the I and D terms is like driving a car with no rear view mirror or speedometer. Sure you know where you are on the road, but you have no idea when to speed up or apply the brakes.

[Adam Y.]

Originally Posted by Dave Flowerday

PID is all about trying to make a control loop that moves a motor to a desired position as quickly as possible but also have it stop when it's supposed to without overshooting.

Has anyone tried any other alternatives? I've read that PID is not necessarily the best but it's relative simplicity makes very useful. You can create a PID controller out of analog components.

[Joe Ross]

Kevin Watson published a working example of PID for the FIRST controller in his 2005 code. http://www.kevin.org/frc/2005/ Download the navigation_frc2005_01_22.zip and looks at the pid.c and .h files.

[dtengineering]

Originally Posted by JesseK

Your code works in theory, but ties up the processor for the duration of that while loop such that the only thing that works on the robot in the while loop is the dvr variable.

Because of this, and limited previous FRC programming experiences, I believe while loops are not possible on a PIC processor.

You are correct that this particular implementation ties up the processor, but perhaps I can clarify a few points regarding PICs and while loops.

First of all, it is important to keep in mind that the RC is one application of one particular variant of PIC microprocessor. PICs come in all shapes and sizes and speeds with all sorts of different I/O options. You can program them in many different languages... from assembly to C to Java to BASIC.

In FIRST, however, we focus on the PIC in the RC, specifically the user PIC, programmed in C for easy compatibility with the default code provided by IFI (we don't touch the master PIC which handles radio communications and such). You will see in the default code reference to "while(1)" meaning that the code is running in an endless while loop. This is one big difference between programming the RC and programming a PC. In the RC you have a loop that restarts every 17ms, while on a PC you have more flexibility on timing for most applications. So whatever you do... while loops, for next loops, if thens... whatever... needs to be accomplished in 17ms or less.

So in this case, you are correct that this particular implementation of a while loop would not be good practice on the RC because there is no guarantee that it will finish within the 17ms period. However that does not mean that PICs are incapable of performing while loops... they can "while" as well as any processor... it is just that the structure within the RC means that you have to be careful about creating any loops that won't finish in 17ms or less.

Well... that was supposed to help clear things up...

Jason

[lukevanoort]

I'm surprised nobody has mentioned it yet, but another good PID resource is Matt Krass's whitepaper on the topic.

Once you understand PID and start to code with it, I would reccommend writing a generalized function for PID, and then use a typedef structure to store the data for each application of the PID code. That was probably a bit confusingly worded, so here's an example. This is the PID code that ran on our 2007 robot in the offseason (you really don't want to see the code during the season... it was really bad and never worked right)
pid.c:

/*******************************************************************************
* FILE NAME: pid.c
*
* DESCRIPTION:
*  This file contains a generic PID function, and functions necessary to 
*  make the PID work.  
*
* USAGE:
*  You can either modify this file to fit your needs, or remove it from your 
*  project and replace it with a modified copy. 
*
*******************************************************************************/
#include "ifi_aliases.h"
#include "ifi_default.h"
#include "ifi_utilities.h"
#include "pid.h"
#include "user_routines.h"



void PID_Initialize (PID_STRUCT* pid_info, int Kp_value, int Ki_value, int Kd_value, int imax_value)
{
//intialize ze values of ze pid structair
pid_info->Kp = Kp_value;
pid_info->Ki = Ki_value;
pid_info->Kd = Kd_value;
pid_info->imax = imax_value;
}


unsigned char PID (PID_STRUCT* pid_info, int error)
{
int P;
int I;
int D;

P = (((long)error * (pid_info->Kp))/ 1000);
I = (((long)(pid_info->error_sum) * (pid_info->Ki)) / 10000);
D = (((long)(error - (pid_info->last_error)) * (pid_info->Kd)) / 10);

pid_info->last_error = error;

if(!disabled_mode)
pid_info->error_sum += error;

if (I > pid_info->imax)
	pid_info->error_sum = pid_info->imax;
else if (I < -pid_info->imax)
	pid_info->error_sum = -pid_info->imax;


return Limit_Mix(2000 + 132 + P + I - D);
}

pid.h

/*******************************************************************************
* FILE NAME: pid.h
*
* DESCRIPTION:
*  This file contains a generic PID function, and functions necessary to 
*  make the PID work.  
*
* USAGE:
*  You can either modify this file to fit your needs, or remove it from your 
*  project and replace it with a modified copy. 
*
*******************************************************************************/

typedef struct {
	int Kp; // In tenths
	int Ki; // In thousandths
	int Kd; // In tenths
	int last_error;
	int error_sum;
	int imax;
} PID_STRUCT;


void PID_Initialize (PID_STRUCT* pid_info, int Kp_value, int Ki_value, int Kd_value, int imax_value);
unsigned char PID (PID_STRUCT* pid_info, int error);

Now what this code does is let you just write PID code once to save time. So, say I wanted to use this code to make a PID loop for both sides of the drivesystem as well as a lift. I would then add

PID_Initialize(&auton_lift, Kp_lift, Ki_lift, Kd_lift, imax_lift);
PID_Initialize(&auton_left_drive, Kp_l_dr, Ki_l_dr, Kd_l_dr, imax_l_dr);
PID_Initialize(&auton_right_drive, Kp_r_dr, Ki_r_dr, Kd_r_dr, imax_r_dr);

to initialize the PID for those robot parts. (The initialization would probably be put in the User_Initialization() function in user_routines.c. Then to run PID on these functions, all that is needed is to type

		LIFT_MOTOR = PID(&auton_lift, (Get_ADC_Result(LIFT_POT) - LIFT_UNF));
LEFT_DRIVE = PID(&auton_left_drive, (Get_Encoder_1_Count(LEFT_ENCODER) - LEFT_GOAL));
RIGHT_DRIVE = PID(&auton_right_drive, (Get_Encoder_1_Count(RIGHT_ENCODER) - RIGHT_GOAL));

which is much easier than writing three seperate PID functions. If you are controlling one thing with PID, it probably would make sense to just write your PID function specific to that thing, but if you are controlling more (I believe seven things were intended to be controlled by PID on our 2007 robot... only one actually ended up using PID though; most other uses of PID got nixed due to sensor failure or lack of debug time) then this is a much cleaner, more efficient, and faster way to code.

If you don't understand the above, don't worry. I definitely wouldn't have when I first started programming FIRST robots. So, if it doesn't make sense now, come back and read it again after you learn more about C and PID; it should make sense then. (If not, PM me)

PS: If you are familiar with an object-oriented language, the above is basically an attempt to code in C using OOP principles.

[EricS-Team180]

Originally Posted by Adam Y.

Has anyone tried any other alternatives?

You can try a Bang-bang_control as an alternative. It works like a thermostat on a furnace. What you pick as a controller really, really, really (did I say really?) depends on the application. In 2006, we used a bang-bang controller on the turret of our poof ball shooter for 2 competitions. Then we switched it to a PID for Nationals. In the end, they both worked, but we got better shooting accuracy with the PID.

Eric

[Adam Y.]

Originally Posted by EricS-Team180

You can try a Bang-bang_control as an alternative. It works like a thermostat on a furnace. What you pick as a controller really, really, really (did I say really?) depends on the application. In 2006, we used a bang-bang controller on the turret of our poof ball shooter for 2 competitions. Then we switched it to a PID for Nationals. In the end, they both worked, but we got better shooting accuracy with the PID.

Eric

Sorry. I was a little vague on the question. I meant has anyone tried other feedback loops. Theoretically anything is possible.

[slavik262]

Actually, another member of my code team wrote an amazing PID library that will do all of this for you in very few lines of code. I'll see if I can get this to you within the next few days

[3DWolf]

OK so maybe the while statement wouldn't work all too well, but couldn't you use an inverted scale type of thing, that the lower the error, the greater the modifier on it would be? I see the risk of that overshooting, but if it's balanced right I don't see why it should.
But then again, with the code I posted, it won't overshoot it, it will just reach it, VERY VERY VERY slowly. 128 speed isn't much, but then again your error is going to be such that much won't be needed.

[ay2b]

Originally Posted by Adam Y.

Has anyone tried any other alternatives?

There's another one which a former math/CS prof at Stanford is working on. I've read a draft of the paper, but it's not ready to be published yet. I'm hoping that it'll be ready for use this season, but it might not be.

I can't go into all the details, because I don't have them in my head (and don't yet fully grok them when on paper in front of me), but at a high level, the concept is this, assuming one dimensional control:

- All motion is a sine wave.
- First derivative of position is velocity; second derivative is acceleration; third derivative is jerkiness
- The derivative of a sine wave is a sine wave
- There are four variables that define a sine wave - frequency, amplitude, phase and offset

(here's where the magic comes in: )

It's possible to map position, velocity, acceleration and jerkiness to the four variables defining the sine wave. You can then place various constraints on three of those variables, and then solve the corresponding differential equation to find a path that meets all those constraints. You re-solve this every clock tick and execute the plan, and it should give you smooth, damped motion control, without the need for the "tuning" that PID control requires.

Unfortunately, I can't answer any questions about this or explain in more detail, because I simply don't know. But I'm hoping to learn, and once I get this new algorithm working in an FRC controller, I'll be sure to let everyone know.

[Dave Flowerday]

Originally Posted by 3DWolf

But then again, with the code I posted, it won't overshoot it, it will just reach it, VERY VERY VERY slowly. 128 speed isn't much, but then again your error is going to be such that much won't be needed.

I suggest you go ahead and try it out - you will likely learn a lot in the process. You will most likely find that it won't reach it. Remember, there is a deadband in the Victor speed controllers (sending them a 128 will not cause them to run at all) and with speeds that low the forces of friction in the system will be larger than the value you are sending to the motor.

[Qbranch]

Originally Posted by Adam Y.

Sorry. I was a little vague on the question. I meant has anyone tried other feedback loops. Theoretically anything is possible.

After the 2007 season ended, I had a heart->heart with PID on our '07 chassis. I was sick and tired of watching PID "get from one place to another as fast as possible". Call me a control freak, but I want to be able to call the shots for not only where something sits, but also how fast things accelerate, what the top run speed is, as well as how fast they decelerate.

Hence, an augmentation of the PID controller. I don't have the code with me, but let me explain to you how it works. First, I tuned up a really nice, very touchy PID. Touchy being it really goes nuts with a little bit of error (in the order of an inch). Then, here's where things get cool: I feed a stream of interim coordinates into the PID to generate trapezoidal velocity control while still arriving at the target. This is very useful for extreme long travels with large masses (like driving a robot from its starting position and arriving (smoothly) at the rack).

I think you can kind of understand how this works: if a stream of coordinates is fed into a pid loop at a constant interval (each time the PID updates, in my case @100Hz) you feed a new, short range target into the PID. These targets are no more than a fraction of an inch apart in my case, remember they get fed in at a rate of 100Hz. That occurs during the acceleration phase: these ramps can be precalculated or calculated at acceleration execution time... all you need is a little 1/2*A*T^2 action. When acceleration or deceleration is complete, you switch to a constant position delta so as to keep the speed constant. Deceleration functions the same way as acceleration.

Now, you may be thinking "hey, that's best suited for autonomous runs where distances can be pre calculated. what if my final target changes dynamically?"

Well, I'm working on that one. My goal is to have a fully mathematical (no precalculation) formula set that handles acceleration, constant run speed, and deceleration. v2 that I'm working on now isn't ready yet, but it operates on a summation of three PID loops, one watches acceleration, one watches velocity, and one watches position simultaneously. To decide which should be listened to, a selection structure is set up which lets whatever PID routine has the lowest power output solution access to the motor. Everything but one part works beautifully in simulation: i'm still trying to figure out how to hande deceleration without the interim-position method explained above.

Next on the list to be explored is state-space control which allows feedback from multiple sensors to factor into a single control loop and plant (motor or otherwise) action... but I might have to wait to have my curiosity satisfied till i'm in college a little while... I'm not sure how to do a Laplace Transform...

Questions? Post!

-q