Thanks. I'm a software guy; not a controls engineer. I estimated a temperature control algorithm to take 8 hours to write then discovered that PID might be what I should implement. I should have estimated 8 days ... or weeks. :)
Thanks for this video, it's very intuitive for anyone to understand. I am a high school senior with no calculus experience trying to simulate a quadcopter drone in a game engine and it's working brilliantly thanks to your explanations.
Thanks for these videos. I use PID controllers in a bit of a different setting: game development. They're useful for just about everything in and out of the physics engine and they're kind of my go to "make this thing go here or do this other thing" component and it's cheap computationally as well. But anyway I'd discovered about windup the hard way, I had a number of thrusters controlling a spaceship, each thruster error is based on the velocity and angular velocity compared to the desires velocity and angular velocity. You can make a spaceship of any shape, stick thrusters on it anywhere you want and they'll just figure out how to go by itself, but every once in a while it would just decide to fly off into space sideways. I had narrowed it down to the I parameter and I just disabled that (it's not really necessary here, being a zero-friction environment) but now I understand what's going on with it.
Te olvidas del efecto polarizador que tienen las redes sociales y los algoritmos de recomendación. Cada vez te recomiendan más contenido del que tú crees o que va en contra de lo que tú no crees.
Have you ever tried zeroing out the iTerm when crossing the setpoint? I noticed it's always retaining it's value when overshooting, when it should really help the system to go the opposite direction.
Sir, I am confused with Sampling Time constant. Of course we have to put our PID into a timer instead of infinite loop but, I realized that you didn't add sampling time constant to into your I and D expression. When I surfed on the net, there are some PID controllers which also includes sampling time. What will I am gonna do ?
I gains do not help with overshoot, only correcting steady state/DC error. The P gain being too high will cause overshoot, if there isn't enough D gain to compensate/slow it down
Hello and thank you for informative video. I have couple of questions about integration part. Firstly, should I reset integration once I supply new command (goal)? I was thinking that integrated error no longer stays valid for different command. Secondly, what about systems where set value (command) remains the same (such as desired angle for balancing systems)?
Whether you do that depends on the problem at hand. On a servo system where the command is constantly changing, no, you don't want to do that. On a system where there's are distinct setpoint changes -- maybe. Some practitioners always do, some always don't, and some look at the characteristics of their particular system and make an informed decision.
Or, if you overshoot, why not test the integrator? If you don't reset, then the integral will still be pushing the system to overshoot, instead of bringing it back down to the setpoint. Am I thinking correctly?
It's been a while since I watched this video so I may be wrong, but no one has offered a reply. I am merely a student but I'll do my best... This is a discrete PID controller, not continuous control, which generally implies a fixed sampling rate. Most sensors use I2C or SPI bus to transfer data. The simplest way to read data is to poll the data on each pass in the main loop; however, you'll often be reading the same, unchanged data out of the sensor's buffers. Normally, the sensor can generate an interrupt when new data has been internally captured (which will occur at a fixed rate). So if you have a SISO system such as this, your sampling rate can be determined by the sensor's update speed. However, for a MIMO system, it may be wiser to have a clock generated interrupt to indicate that data must be read from all the sensors and the output on the DACs must be changed.
Sorta kinda. Strictly speaking, a Kalman filter is a linear, time-varying filter that has one output per state, and usually has more than one input. Moreover (and folks forget this part) the only thing really special about it is that it's designed using a specific design methodology that takes the system characteristics into account and designs a filter that's optimal for that system and a specific set of optimization criteria. From that standpoint, no, a band limited derivative is not a Kalman filter. Practical Kalman filters often settle out asymptotically to a non-time-varying version; it's called the "steady state Kalman filter". If you set out to estimate the position and velocity of something like that from noisy position measurements using a Kalman filter, the velocity estimate of the steady-state version of that would be a band limited derivative filter, or something close.
is it just me that think that "anti windup" would more accurately describe something that stopped the integrator when the output of the controller is already at max ?
You know, I just heard the term a long time ago (right after someone saw a controller that I'd implemented without anti-windup, and exhibiting classical symptoms). I've used it since without really thinking about it.
Thanks. I'm a software guy; not a controls engineer. I estimated a temperature control algorithm to take 8 hours to write then discovered that PID might be what I should implement. I should have estimated 8 days ... or weeks. :)
Thanks for this video, it's very intuitive for anyone to understand. I am a high school senior with no calculus experience trying to simulate a quadcopter drone in a game engine and it's working brilliantly thanks to your explanations.
which game you're using for simulation?
Actual practical engineering knowledge...I never knew that was available nowadays. Too much academia, not enough of this. Thanks
Thanks for these videos. I use PID controllers in a bit of a different setting: game development. They're useful for just about everything in and out of the physics engine and they're kind of my go to "make this thing go here or do this other thing" component and it's cheap computationally as well. But anyway I'd discovered about windup the hard way, I had a number of thrusters controlling a spaceship, each thruster error is based on the velocity and angular velocity compared to the desires velocity and angular velocity. You can make a spaceship of any shape, stick thrusters on it anywhere you want and they'll just figure out how to go by itself, but every once in a while it would just decide to fly off into space sideways. I had narrowed it down to the I parameter and I just disabled that (it's not really necessary here, being a zero-friction environment) but now I understand what's going on with it.
Thank you for your video, for the integration wind up the first value is 0?
Te olvidas del efecto polarizador que tienen las redes sociales y los algoritmos de recomendación. Cada vez te recomiendan más contenido del que tú crees o que va en contra de lo que tú no crees.
wow thank you so clearly explained
Have you ever tried zeroing out the iTerm when crossing the setpoint?
I noticed it's always retaining it's value when overshooting, when it should really help the system to go the opposite direction.
Thanks you very much. It is a wonderful contribution.
BEST ON INTERNET
Thanks for this video!
Thanks for these video!! :) it was really useful for me
Thanks for this video too!
Sir, I am confused with Sampling Time constant. Of course we have to put our PID into a timer instead of infinite loop but, I realized that you didn't add sampling time constant to into your I and D expression. When I surfed on the net, there are some PID controllers which also includes sampling time. What will I am gonna do ?
that was very useful thaaaaaaank you
Thank you, you made it very easy. Whare are you from?
Why oscillations occur in the controller output if the PI gains are increased?
I gains do not help with overshoot, only correcting steady state/DC error. The P gain being too high will cause overshoot, if there isn't enough D gain to compensate/slow it down
great video!
Hello and thank you for informative video. I have couple of questions about integration part. Firstly, should I reset integration once I supply new command (goal)? I was thinking that integrated error no longer stays valid for different command. Secondly, what about systems where set value (command) remains the same (such as desired angle for balancing systems)?
Whether you do that depends on the problem at hand. On a servo system where the command is constantly changing, no, you don't want to do that. On a system where there's are distinct setpoint changes -- maybe. Some practitioners always do, some always don't, and some look at the characteristics of their particular system and make an informed decision.
Or, if you overshoot, why not test the integrator? If you don't reset, then the integral will still be pushing the system to overshoot, instead of bringing it back down to the setpoint. Am I thinking correctly?
Great video! Thanks
I'm trying to understant why interrupts are needed when the PID is going into a microcontroller
It's been a while since I watched this video so I may be wrong, but no one has offered a reply. I am merely a student but I'll do my best...
This is a discrete PID controller, not continuous control, which generally implies a fixed sampling rate.
Most sensors use I2C or SPI bus to transfer data. The simplest way to read data is to poll the data on each pass in the main loop; however, you'll often be reading the same, unchanged data out of the sensor's buffers.
Normally, the sensor can generate an interrupt when new data has been internally captured (which will occur at a fixed rate). So if you have a SISO system such as this, your sampling rate can be determined by the sensor's update speed.
However, for a MIMO system, it may be wiser to have a clock generated interrupt to indicate that data must be read from all the sensors and the output on the DACs must be changed.
hey, is band limited derivative somehow connected to a kalman filter ?
Sorta kinda. Strictly speaking, a Kalman filter is a linear, time-varying filter that has one output per state, and usually has more than one input. Moreover (and folks forget this part) the only thing really special about it is that it's designed using a specific design methodology that takes the system characteristics into account and designs a filter that's optimal for that system and a specific set of optimization criteria. From that standpoint, no, a band limited derivative is not a Kalman filter.
Practical Kalman filters often settle out asymptotically to a non-time-varying version; it's called the "steady state Kalman filter". If you set out to estimate the position and velocity of something like that from noisy position measurements using a Kalman filter, the velocity estimate of the steady-state version of that would be a band limited derivative filter, or something close.
could you give me your source code?
is it just me that think that "anti windup" would more accurately describe something that stopped the integrator when the output of the controller is already at max ?
You know, I just heard the term a long time ago (right after someone saw a controller that I'd implemented without anti-windup, and exhibiting classical symptoms). I've used it since without really thinking about it.