PID control loops - closed loop feedback

[Salik Syed]

I am planning to use PID on the arm for our end of year mini-game bot
(we make a mini game w/ the robotic class (sadly only 7 students one being a moderator) split into 2 teams w/ a 2X2X3'
80 lbs robot its really cool)
any ways for ours (i'm not sure if this will work)
I will basically just put a gyro on the arm and
compare the "wanted speed" to the real speed and
then just add a bit to the PWM (dependent on how close real is to wanted)
to calibrate it just move the gyro away from or closer to the joint!
to get the real speed i'm just going to multiply the accel*time/looptime + previous...that
should probly give me speed..
Will this work? Also i'm using the PBasic controller so i'll have to learn that a bit...
do i have to keep loop time constant or not...does it really matter that mucH?
This part really bugs me out because i read about everyone keeping loop times constant and
what not but on the Edubot controller I just wrote the code...heck to loop time and
everything worked (for our little autonomous gyro guidance thing)
IF it does matter a LOT
i might take a educontroller and connect it to the maincontroller so it can receive
gyro inputs and then simply output the amount to add to the PWM through dig_out which
plugs into dig in on the RC

Also can someone explain why it matters so much (in reality ) do the loop times really
vary by so much that it would greatly affect operation (i imagine if it loops so quickly
it wouldn't matter...the differences would be averaged out to a menial number??)

Thanks!

[KenWittlief]

if you are matching rotational speed then the amount of time the loop takes doenst matter

its when you are integrating it to get angles that the loop time alters the output - and even that averages out if the loop is not the same every time

I wouldnt worry about the loop speed - PID loops always have some trial and error testing to get the constants right

sounds like fun.

[Salik Syed]

Also...this is kind of a side question...if i integrate twice...wouldn't i get a 0-254 value? (from the gyro) ...that is Total V? ....i guess it wouldn't be so hard to convert to an angle given that its 150 deg/sec...but i don't really trust that so I'm thinking i'll not convert to degrees (useless anyways)...
just wondeing...

[KenWittlief]

Im not sure what you mean by integrating the sensor twice?

the output of a yaw rate sensor is degrees/second

when you integrate its somewhat like multipling by seconds, so you end up with degrees (in units that do not directly read out in degrees, you would need a constant added in if you want actually degrees, or radians, or whatever standard unit you want

but if you integrate that again? Im not sure what that gives you? degreeSeconds?!

I dont know what that would be measuring?

[Salik Syed]

degree seconds? i thought it would give the degree angle of the arm ...like a potentiometer... (degree/seconds * seconds = degrees ) right?



btw this is the actual code it hasn't been compiled or tested yet just theory...just notepad:

p2_y=armin;
targetv=armin;   //just temporary...

//////get gyro input conv to 8bit

(int)gyroin10bit=Get_Analog_Value(rc_anlg_in01);
gyroval=gyroin10bit/4;

////convert gyro values to usable values....
armaccel=gyroval-127;


///integrate
realv=(armaccel+realv)/time; 
time++;
//////////////



if((hicutoff+targetv)>realv>(locutoff+targetv))
	{
	armout=(targetv-realv)/proportion;
	}
pwm03=pwm03+armout;

One more thing... What is this about integral and derivative.... I get the proportional part (basically multiplying by how much change the input produces.."Gain" )
but why integrate the error....i don't get this and how it works ? i read some stuff about how it is an automatic reset which doesn't quite make sense to me...... Also can someone explain the derivative...part...

[Salik Syed]

OKay...nevermind...i figured out what it does......now for the derivative ....the longer an error has stayed the more it adds...

[KenWittlief]

I think I understand your statements now.

when you intergrate the sensor output you are changing the 'signal' from degrees/second to degrees

so now you can create an error signal by subtracting that from what the operator is commanding (desired angle)

and do a PID feedback with intergral, proprotional and deriviative (or differentail) components

so you would not really be intergating the sensor single twice - you would be integrating it once to get the angle

then if you wanted tight feedback you could integrate the error signal over time.

[Salik Syed]

yeah...i know i'm not gonna integrate twice...just once..(see code) but i was just wondering...
I've tweaked the code to include an integral term, now i'm wondering how to do the derivative...its hard because i'm trying to read ahead in the textbook...(we haven't learned derivitves yet!) ..... and then apply it to this....all the articles I find on PID are a bit too complex...
btw... we also did the whole tape interpolation thing for autonomous..we didn't use it because we didn't need the precision, we used a gyro to track heading, then tape for distance, we didn't have a legal gyro at times so i also implemented a timer that would measure time between the tape being seen and calculate dist to a much finer degree then 1/6 wheel circumfrence...alot like what u did...

[KenWittlief]

derivative is easy. its the delta or change since the last loop

create a new variable to keep track of the 'last_error' signal - then compair the current error signal to the last one - thats the derivate - you are interested in how fast the error signal is changing

which can be due to the driver making a sudden change, or the bot moving suddenly.

[Salik Syed]

okay....i get it now
Thanks!

[Salik Syed]

Heres our PID code so far...the constants u multiply by really have to be tweaked once the actual robot is built ! ... P+I+D should not be over 127 or under -127...so i'll have to definitely calibrate it A LOT
IF( any one spots obvious mistakes ...(not like syntax error type mistakes) ){please tell me...}

////get joystick input/////////////// 
p2_y=armin;
targetv=armin;   //just temporary...

//////get gyro input conv to 8bit

(int)gyroin10bit=Get_Analog_Value(rc_anlg_in01);
gyroval=gyroin10bit/4;

////convert gyro values to usable values....
armaccel=gyroval-127;


///integrate
realv=(armaccel+realv)/time; 

//////////////


//////////Calculate the proportional.....
if((hicutoff+targetv)>realv>(locutoff+targetv))
	{
	armout=(targetv-realv)*proportion; /// as the real gets closer to target pwm addition is lowered...
/// this is basically "Gain"
	}

/////////////calculate the integral of the error....
error=realv-targetv;
errorint=(error+errorint/time)*intprop;

/////calculate  the derivative of the error;
derivative=(lasterror-error)*devprop;


///////////////////Output;////////////////////

if(tripped!=1)
{
pwm03=armout+errorint+derivative+127;
}

///////update time
time++;

////update error 
lasterror=error;


////motor heating control....
///basically take current sensor values and make sure not too much
//is being drawn or else it will let down on the motors


(int)current=(Get_Analog_Value(rc_anlg_in02))/4;
///+127 = 100 amps...... so + or - 50 = 40 AMPS!!! I set it to "trip" at 27 amps
/// since we have 30 amps breakers ... so that you don't trip the actual breaker.!
//// divide current by .79 to get anlgreading-127~!  so 100/.79+127=254!

if(current>161 || <93)
{
pwm03=p2_y;
tripped=1;
}

I also added some code in to ensure that if we have a large weight on the arm at a not so great angle the motors won't over heat and trip the breaker....
Am I doing the Proportional correctly? It says Gain= Input / Ouput ... but in stead i just compare the target to the actual...thats not exactly the same but should give me the result i'm looking for (to lower speed when target is closer to actual)?? Correct me if i'm wrong please....

[Max Lobovsky]

Originally Posted by TedP

Some Simple Benefits (and Cons) of Feedback Control

Being able to count on a controller to deliver a very simple task is so important. This allows the driver to simply "suggest" a speed with his or her joystick and the robot will handle all the rest. The driver can then get up the step at a slow speed, for example. Rather than running straight into the step, the driver holds the joystick constant and the feedback controller figures out how to get up the step to maintain its own speed.

Additionally, for that same reason, a real feedback controller actually makes the torque-speed curve of a motor almost entirely horizontal (within a certain range). This actually can be dangerous because the robot will perform CONSISTENTLY under ANY BATTERY POWER and it may be easy to forget to monitor it's battery life.

Plus, these controllers are extremely robust. People spend hours dealing with open-loop filters on joystick inputs and often come up with odd non-linear controllers which have no easy way to optimize. The linear feedback control system uses the motors own natural low-pass effects to smooth out its own input. The linear feedback control system needs very little tweaking to be operational, and will do its hardest to perform as close to optimally as possible even on a low battery or when facing an odd load.

However, there is a much stronger dependence on hardware. There is a tremendous increase in complexity. There simply are costs for all the things that the feedback gains you.


Anyway, I hope that code might help some people. I'm afraid my post might be too long to help pepole directly, but hopefully some will read it. The system works great on our robot; I hope it can help yours.

TedP, let me start by saying that was an excellent post that explained several things i wasn't clear about. I know that you said for most applications in FIRST, a simple linear PID loop does the trick, but i have a drive system application in which i need an accurate velocity needs to be reached pretty quickly (much quicker than a simple skid steer design requires) and also needs to be accurate and fast for a pretty wide range of velocities. Maybe the best way would be to use some more complex non linear feedback loop, but i thought that maybe a simpler solution would be to use both an open loop (a calibration curve) and a linear feedback loop. We are starting this project now, so time to tweak all the coefficients and the calibration curve is not a major consideration. Is there any reason against doing something like this, or were you just saying that, in general, a linear PID feedback loop should do the trick, and that open-loop systems take too much time?