|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
PID vs Normal loops
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 Code:
#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;
}
|
|
#2
|
||||
|
||||
|
Re: PID vs Normal loops
Quote:
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. |
|
#3
|
||||
|
||||
|
Re: PID vs Normal loops
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. |
|
#4
|
|||
|
|||
|
Re: PID vs Normal loops
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. Last edited by Tom Bottiglieri : 10-12-2007 at 11:20. |
|
#5
|
||||
|
||||
|
Re: PID vs Normal loops
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.
|
|
#6
|
||||||
|
||||||
|
Re: PID vs Normal loops
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.
|
|
#7
|
|||||
|
|||||
|
Re: PID vs Normal loops
Quote:
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 |
|
#8
|
||||
|
||||
|
Re: PID vs Normal loops
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: Code:
/*******************************************************************************
* 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);
}
Code:
/*******************************************************************************
* 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);
Code:
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); Code:
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)); 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. |
|
#9
|
|||||
|
|||||
|
Re: PID vs Normal loops
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 |
|
#10
|
||||
|
||||
|
Re: PID vs Normal loops
Quote:
|
|
#11
|
||||
|
||||
|
Re: PID vs Normal loops
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
|
|
#12
|
||||
|
||||
|
Re: PID vs Normal loops
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. |
|
#13
|
||||
|
||||
|
Re: PID vs Normal loops
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. |
|
#14
|
||||
|
||||
|
Re: PID vs Normal loops
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.
|
|
#15
|
||||
|
||||
|
Re: PID vs Normal loops
Quote:
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 |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Hobbies, normal and unusual | Jill1022 | Chit-Chat | 61 | 29-04-2005 08:33 |
| PID control loops - closed loop feedback | KenWittlief | Technical Discussion | 56 | 26-04-2004 21:27 |
| Well, is it normal for me not to be in FIRST Robotics and post here? | JKis6622 | Chit-Chat | 3 | 13-03-2004 15:46 |
| PID Control Loops | ttedrow | Programming | 7 | 05-12-2002 12:03 |
| Programming Loops | Mike o. | Programming | 5 | 26-03-2002 11:24 |