Skip to content

improve anti-windup #59

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from
Closed

improve anti-windup #59

wants to merge 5 commits into from

Conversation

mestrode
Copy link

small change, huge effect
The controller stability can be improved by limiting the charge level of the accumulator to the value needed to reach "output=limit".
While the output is limited, the controller is not able to react. But when the system will be release, the integrator will start to discharge at a lower value.
Considering the proportional part for limitation will enable the controller to return quicker into contentious mode.
There are several ways to realize anti-windup schemes, but this small improvement is quite easy to implement.

small change, huge effect
The controller stability can be improved by limiting the charge level of the accumulator to the value needed to reach "output=limit".
While the output is limited, the controller is not able to react. But when the system will be release, the integrator will start to discharge at a lower value.
Considering the proportional part for limitation will enable the controller to return quicker into contentious mode.
There are several ways to realize anti-windup schemes, but this small improvement is quite easy to implement.
@askuric
Copy link
Member

askuric commented Mar 11, 2021

Thanks for the pull request, finally some control theory talks! :D
I've been thinking about this, I agree that double limiting first integrator and then output is not the best approach.

But are you sure that this is a good approach, I am not sure that it will produce the same effect. I mean it will work but i have a feeling that it will not be a good solution in all the cases. In this case the proportional value can easily "restart" the integrator just because of a small spike of an error (depending on the P gain).

Maybe we should limit the output only and instead of keeping the previous value of the integrator error use the previous output value?

Or maybe we should just writhe the pid as a one differential equation and make discretise it with tustin and limit only the output?

What are your takes on this?

The derivative part will be zero in short term. So avoid discharging integrator by derivative component just reacting on noise
@mestrode
Copy link
Author

Thank you for your fast response!

maybe we should just writhe the pid as a one differential equation and make discretise it with tustin and limit only the output?

I prefer the easy readable code. You can clearly understand what happened step by step. And also it's possible to evaluate the behavior in a spreadsheet (like I did to to check my answer, since I currently have no working dev system / hardware). So lets avoid using a complicated diff-equation, but understand whats happen inside the current code.
Btw: what does mean "with tustin"?

Maybe we should limit the output only and instead of keeping the previous value of the integrator error use the previous output value?

In this case the integrator would also sum up the proportional share in the accumulator, so the continuous mode will be affected.

But lets stay at this thought: A common approach is back calculation. The accumulator will be dynamically limited to the value, just needed to fulfill "output=limit". This is archived by integrator = integral_prev + I * error * Ts - surplus where the surplus is just the difference of surplus = output_lim - output. In other words the surplus which is suppressed by the output limiter. Finally all parts (proportional, integrator and differential) sum up the output to precisely the value of limit. Here you can not only consider the absolute limiter but also the rate limiter.

I did that in a different way in my second commit. You're question started me to think about it, again. :-)

But to answer your main question: You're right, but see this form the perspective of control stability.
May the proportional part will react on a spike and the anti windup will be caused to "discharge" the integrator. So after that, the controller need some time to reach limitation again, refilling the accumulator. May you can say this is a small disadvantage, cause in the mean time the full output value is not used. - But it proves (and ensures), the controller is really working free. Cause if you have a really noisy system, everything is about control stability. But then, to be stuck into limitation for longer period is a root cause for stability problems. With the current anti-windup, the integrator has not only a wanted limitation but also some unwanted effect of saturation. This affects the control stability in a bad way, cause the time of being limited is inadvertently extended.

I mean: It's better to operate near to the limit, but not to be clamped on the limit.
Keep in mind, we're talking about pushing the boundary for stable operation for the controller. Beyond the limitation the controller is simply not able to do anything

Good thought: I removed the derivative part for integral_prev calculation in my new proposal. It will be zero, soon, and may just caused by noise.

BTW: Usually the derivative part of a controller is rarely used, since it decreases stability and won't improves step response behavior. This is cause there are rarely systems with relevant dead-time to be controlled.

Since the integrator is a huge filter (accumulator), there is no advantage to filter the input signal of it.

To use this type filtering may improves control stability when applied on the proportional part. But this will delay the response time by 1/2 (?) control step (may you don't care in your use case).
@mestrode mestrode closed this May 13, 2021
@askuric
Copy link
Member

askuric commented May 13, 2021

Hey @mestrode,

Please do not close this PR. I'd like to come back to it very soon.
Sorry for the delay, it is mostly due to the current release.

Give me a few days to come back to you about the anti-windup.

@askuric askuric reopened this May 13, 2021
@IhorNehrutsa
Copy link

Improving the Beginner’s PID: Reset Windup
http://brettbeauregard.com/blog/2011/04/improving-the-beginner%e2%80%99s-pid-reset-windup/

@askuric
Copy link
Member

askuric commented Jul 24, 2021

Thanks for the link @IhorNehrutsa ,
Actually everything in this link is already implemented in the library in the PIDController class.
@mestrode has very well pointed our that this is not the best solution and it is true.

I am really planning to come back to this topic soon, at the moment it is a bit out of scope.

My big concerns for anti-windup is for the current control, because we have two axis of the current control d and q and each of them will set the voltage d and q. And sum of these vectors should never exceed the maximum power supply dc voltage magnitude.

askuric added a commit that referenced this pull request Sep 16, 2021
askuric added a commit that referenced this pull request Sep 16, 2021
@mestrode mestrode closed this by deleting the head repository Feb 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants