br3ttb, no need to be modest 
I did some minor editing to the font sizes to make the page a little easier to read, hope you don't mind.
Ahh glad it wasn't me being dumb then
Nice to see it up there for all to see 
Here's another vote for the int version.
I'm currently trying to use your library to control motor speeds for a robot. I haven't gotten everything working correctly yet, but I'm concerned that the arduino will not be able to run the methods in this library and still process interrupts at the required frequency (as high as 1700kHz)? How is this done on and industrial motor controller? Do they do the PID math on the physical motor controller, or is it done elsewhere on a main processor?
I want to make sure we're on the same page here. for simplicity's sake, I set up the library so you call .Compute() every cycle. most of the time, the library says "I don't need to recalculate yet" and immediately spits back to the calling routine. the recalculation happens at 1Hz by default, but can be adjusted to be slower or faster using the SetCalcFrequency function.
so most of the time Compute() kicks back "instantly." I don't think there's an interrupt problem there. however, on the cycles where recalculation is occurring I think there may be. I did some bench tests before I published the library the calc speed was about 12 microseconds (8.3kHz.) so it may be possible, if the interrupt pulse is faster than that, and it comes while the pid is calculating, the signal may be missed.
I have no idea how this is done in motor controllers. my experience is on slower moving stuff, and as a consequence it's not a problem for the pid to be "slow" as well.
I am currently working on an integer version of the library (and the crowd goes wild.) it's not going to be anywhere as feature rich as the "full" version, but hopefully it will be much, much faster.
Brett
That's kinda what I was thinking but this clarifies it much more. I think you may right about the possibility of missing pulses while in a calculation but that's one of the many pitfalls of dead-reckoning navigation. However, I don't think it's going to be a big problem because I think my overall error from other factors will outweigh the lost counts here and there. It sounds like your 'full' library may work but I bet the 'lite/int' version would work a lot better!!
Thanks, this has been a big help to me!
This is great! Thanks so much, I am going to try it out soon on an oven controller. I'll let you know how it works out.
I don't mean to nag, but that SetCalcFrequency() really needs to be changed to SetCalcPeriod(). Likewise GetCalcFreq().
IMO it's important to avoid misleading function names, particularly early in the library lifecycle, before the installed base is too large, and there's too much traction.
Apart from that it's a great library.
Thanks!
I think nag might be a little strong. I've taken it as a gentle reminder.
I'm working on the integer (or "lite") form. I'll release it bundled with the pid library, and on both I'm planning on renaming it as "SampleTime", in keeping with the industry standard.
-Brett
ok, so I finished (or thought I finished) the integer form, and I wasn't happy. it was only 1k smaller and 30% faster. not good enough. I'm going to keep working on it, but unfortunately it's going to be a while.
in the mean time, the 0.5 beta has been sitting there with it's flaws. So... I've decided to upload the next version of the beta (v0.6) without the promised integer library. sorry about that.
at any rate, with the bad news out of the way, let's talk about the good news. updated pid library! bonus! I took care of the obvious (and less obvious) snags with the library, and added a very powerful advanced feature.
"snag" fixes:
- CalcFrequency has been changed to SampleTime. finally.
- The library now has a version-specific name: <PID_Beta6.h> This way, you can put up your code, and even 4 years (and 20 revisions) from now, everyone will know which version of the library you used.
- I felt that SetIOLimits was a bit confusing, since for the most part, the input limits will never be changed. I decided to split it into two functions: SetInputLimits and SetOuputLimits. The output limit function was left on the standard function page, while the input limit function is now hidden on the advanced page.
advanced feature:
Feed Forward. good lord is this powerful. essentially it lets you add your own knowledge to what the pid is doing. so, if you know that the controller is about to get hit with a major disturbance, you can help it along, and address the disturbance far more effectively than using just pid alone.
take a second to look at the updated wiki (Arduino Playground - PIDLibrary) and let me know if I missed anything!
Brett
Thanks for your effort on this. One question I have is how would one best invoke a reverse action control function, as required in industrial controllers for working with fail open and fail close control valves?
Thanks
Lefty
how would one best invoke a reverse action control function, as required in industrial controllers for working with fail open and fail close control valves?
change the sign of the P_Param. (I know you know what this means Lefty, but for the benefit of others reading...)
if your P_Param is 3.2 say, and the controller seems to be going in the wrong direction,( i.e. opening when it should be closing,) you would want to change that to a -3.2.
usually it is really obvious that this needs to be changed. the output starts to go the wrong way, which makes your input get farther from setpoint, which makes your output go FARTHER in the wrong direction. the cycle continues until your output is pegged at one of the limits.
I was teaching a class on pid and asked "what happens if you set this wrong?" expecting the answer above. the answer I got was much better: "you get a nickname"
Brett
I have plans to design an autopilot for my boat and have read this post with great interest. Before starting I should want to ask you two questions that has puzzled me:
- I have seen that some boat autopilots does not need a rudder feed-back. I suppose that all PID regulators do need some sort of feed-back. Do you have any idea how they can do this?
- Some autopilot claims that they are adaptive. They can learn the characteristics of the boat. I know you cannot give us an adaptive controller, you told us that, but can you hint to me how this is done. Is it still a PID regulator that is used with some other program tuning the parameters or do they use some other type of controller?
"I have plans to design an autopilot for my boat and have read this post with great interest. Before starting I should want to ask you two questions that has puzzled me:
- I have seen that some boat autopilots does not need a rudder feed-back. I suppose that all PID regulators do need some sort of feed-back. Do you have any idea how they can do this?
- Some autopilot claims that they are adaptive. They can learn the characteristics of the boat. I know you cannot give us an adaptive controller, you told us that, but can you hint to me how this is done. Is it still a PID regulator that is used with some other program tuning the parameters or do they use some other type of controller? "
Well all closed loop controllers need some kind of feedback measurement(s) to function, otherwise it is 'open loop' control, kind of like a steering wheel, where it's up to the human operator to know where the car is aimed at and make adjustments or not.
In the Classic PID controller the feedback is called the 'PV' for process variable. It is the actual measured temperature in a temperature controller, or the actual level measurement in a level controller. For you autopilot steering the feedback would either have to be something that can measure actual heading like a electronic compass or a GPS heading, etc. Measuring the actual rubber angle would work to a degree but wind and current variables could cause a change in heading regardless of the rudder angle. I'm not sure what the standard measurement used in for boat auto pilot controllers. Interesting applications and I would favor GPS but autopilots have been around longer then GPS so there must be other effective measurements.
Lefty
An autopilot use heading information from a fluxgate compass so of course that will be used as a feed-back. However in my understanding of an autopilot it usually consists of two cascaded loops. The first one for heading and the other one for setting the rudder position. The first one use heading as feed-back and the last one a "rudder feed-back unit". Some autopilot manufacturer has taken away the need fro that last unit and I just wander how that can be done.
An autopilot use heading information from a fluxgate compass so of course that will be used as a feed-back. However in my understanding of an autopilot it usually consists of two cascaded loops. The first one for heading and the other one for setting the rudder position. The first one use heading as feed-back and the last one a "rudder feed-back unit". Some autopilot manufacturer has taken away the need fro that last unit and I just wander how that can be done.
Now I understand your question. Yes cascade control where the rubber has it's own PID control function allows one to optimize the controller tuning settings for the rudder controller and the heading controller independently such that the heading controller outputs a 'desired setpoint' to the rubber controller as it's PV measurement.
In such a configuration the rubber controller is said to be the slave controller and the heading controller the master controller. It gives better controllability. However with more the powerful control possibilities with a microprocessor this can all be done inside the micro and could take advantage of feed-forward or adaptive or other 'smart' control algorithms. So I guess it's a trade off, saving the cost of the hardware needed to generate a rudder position measurement while still having good control behavior by compensating by using more advance software control features.
As a hardware guy, I would prefer having actual rubber feedback measurement in that it then is easy to add additional alarm functions if say the rubber linkage was to break and the actual rubber commands were not being performed.
Lefty
- Some autopilot claims that they are adaptive. They can learn the characteristics of the boat. I know you cannot give us an adaptive controller, you told us that, but can you hint to me how this is done. Is it still a PID regulator that is used with some other program tuning the parameters or do they use some other type of controller? "
I don't think you need an adaptive controller for this situation per se. I'm assuming that what they mean when they say "Adaptive" is that you can put it in a big boat or a small boat, and it will figure out if it needs to control aggressively or conservatively. once the controller dials in on what type of control it needs, I would guess that it doesn't do much adapting. this is good news for you. you can use a pid controller and have a tuning period. "this control is a little too aggressive, let me back it off" or whatever. after that, you should be all set.
- I have seen that some boat autopilots does not need a rudder feed-back. I suppose that all PID regulators do need some sort of feed-back. Do you have any idea how they can do this?
ok, first let me put both single-loop and cascade into words.
single loop: "I'm not on heading. let me adjust my signal to the rudder until I get the heading I need"
cascade: "I'm not on heading. I need the rudder to be 5degrees off center. rudder controller, look at the rudder position and adjust until I get what I asked for"
so what's the difference? well, in the first situation, there's no guarantee that you'll get the same rudder position every time you send, say, 50%. actually, it's likely that you won't, because of "slop" or play in the rudder. in the second situation, we have a dedicated controller whose job it is to make sure we get exactly what the heading controller asks for.
so the cascade is more precise because you get the rudder position you want really quickly. does that mean that it won't work the other way? nope. in the single-loop setup, the heading controller is going to keep adjusting it's output until it gets what it wants. so if sometimes centered is 50%, and other times it's 55%, it doesn't really matter. the controller will eventually find the output that gets it what it wants.
the problem is that it will have more trouble getting to the desired heading than the cascaded way. so cascade is more complicated, but if done right it gives you better control.
(a note on nomenclature. the cascaded controllers can be referred to as Master-Slave, Outer-Inner, or Primary-Secondary depending on who you ask.)
hope this helps
Thank you very much br3ttb for your answer. The more expensive autopilots are really adaptive in a way that they automatically figure out the boats characteristics and adjust for that. They can even adjust for changing weather conditions. So my question is do they still use a PID controller with some intelligent program to change Kd, Ki and Kp or do they use some completely different controller? What is exactly an adaptive controller?
So my question is do they still use a PID controller with some intelligent program to change Kd, Ki and Kp or do they use some completely different controller? What is exactly an adaptive controller?
adaptive control is an umbrella term for a controller that changes its behavior on the fly. how do they do this? I have no idea. they could use a neural network and it would fit this definition! (although fitting one on a microcontroller would be an impressive task)
the pid library has been designed with adaptive control in mind. Example 2 on the wiki uses a form of adaptive control, switching between aggressive and conservative tunings on the fly.
so, while I don't know how they do it, I have a feeling you could use pid. as long as you're ok with some experimentation you should be fine. "I know that THESE parameters work well in calm seas, while these work well in 5ft swells. I'll automatically switch between them, or even interpolate between them, depending on the situation I'm in." if that isn't enough you can even bring in some Feed Forward control, but it's probably better to cross that bridge when we come to it.
now I should add here that I'm not a seaman, so I have very limited knowledge of "changing weather conditions" and how they affect the navigation of the boat. my intuition is that the pid library should give you
the tools you need. if not, you've spent 0$ and learned a little about control.
Hi guys, I am a newcomer to the Arduino and this is my first post. I purchased one to do a few chores as part of a Car PC installation and have just about got the main hardware and software elements sorted out enought to actually start putting some stuff together.
I was actually thinking about addng a climate control system to my car while driving earlier today and new there were some intergrative vcontroller solutions out there and now I have found one for the Arduino! By the sound of this thread, this is exactly the sort of software I would need to add climate control.
However, in the case of airconditioning, there are two parameters to adjust, one is the temperature setting and the other is the fan speed. Could this library be adapted to control two variables in unison? to achieve the desired temperature setting?
However, in the case of airconditioning, there are two parameters to adjust, one is the temperature setting and the other is the fan speed. Could this library be adapted to control two variables in unison? to achieve the desired temperature setting?
I don't see why not. you would probably just need to do some Post-Processing on the output. so the pid would still be computing one number, but you would massage it a little. the easiest example of this would be to take the output of the controller and send it to BOTH the fan speed and temp setting. so as the pid output gets larger, you ask for colder air and more of it, simultaneously.
SO:
void setup()
{
pid.SetOutputLimits(0,255); //tell the PID to range the output from 0 to 255 (this is the default range, so this really isn't necessary(
Output = 0; //start the output at ALL off and vary from there
pid.SetMode(AUTO); //turn on the PID
}
void loop()
{
//give the PID the opportunity to compute if needed
Input = //cabin temp
Setpoint = //desired temp
pid.Compute();
FanSpeed = Output;
TempSetting = Output;
}
note, you could also set this output massaging to first speed up the fan, then adjust the temp, or vice-versa, but that would make tuning the controller (finding the right P_Param, I_Param, D_Param) a bit more difficult.
Brett