PID Regler in Software verbessern

[Sina A. (sinapse)]

hallo,

man findet immer so schönen code im netz für einen PID regler der form

esum = esum + e
y = Kp * e + Ki * Ta * esum + Kd * (e – ealt)/Ta
ealt = e

hier wird der I anteil in esum aufkummuliert. sprich die messwerte 
werden addiert, was ja eine treppenfunktion ergibt. wenn man nun bessere 
integratoren verwenden möchte, z.B. mithilfe der Trapezregel, würde man 
ja eine verbesserung der integrationsschätzung erreichen, bei kaum 
merkbarer erhöhung des rechenaufwands (gehen wir mal von einem 32bitter 
mit FPU aus und nicht von einer 8bitter gurke).

das gleiche beim D anteil. hier wird über den differenzenquotienten die 
steigung ermittelt. will man diese schätzung verbessern z.b. mit finite 
difference (https://en.wikipedia.org/wiki/Finite_difference), hat man 
auch keinen merkbar höheren aufwand.

Allerdings beruhen beide methoden darauf, dass man sich mindestens einen 
vorhergehenden bzw. einen nachfolgenden messwert anschauen muss. der I 
bzw. D anteil würde also ein ergebnis immer um einen Takt versetzt 
ausspucken, da dieser immer auf den nachfolgenden wert warten muss.

müsste man dann auch den P anteil um einen takt verzögern, damit sich 
alle drei PID werte auf denselben zeitpunkt beziehen?

spielt eine verzögerung von einem Takt keine rolle (also P eilt ID immer 
einen Takt voraus, wäre nicht schlimm)?

wird mit der besseren schätzung kein merkbarer vorteil erbracht? ist es 
gar viel schlechter wegen der verzögerung?


bin mir nicht sicher ob man überhaupt pauschal antworten geben kann auf 
meine fragen, aber wenn ja würds mich freuen. Fragen zielen eigentlich 
insgesamt darauf ab, ob man den code oben so belassen kann ohne lange 
drueber nachdenken zu muessen, weil doch eh kaum optimierungen erreicht 
werden an dieser stelle.

danke schonmal fürs lesen

thx

[C Programmierer (Gast)]

Ich denke das wichtigste ist erstmal, dass du den Code eines idealen PID 
Reglers hast. Ein realer PID-Regler hat aber noch entweder einen 
Tiefpass vor dem Differenziator oder vor dem ganzen Regler. Und ein 
tiefpassgefilteter Differentiator ist das gleiche wie ein konstanter 
Faktor minus eines Tiefpass. Damit bekommt man schonmal die 
Differentiation aus der Implementierung.

Für die Trapezmethode des Integrators musst du natürlich auch den alten 
Eingangswert des Integrators benutzen.

[Wolfgang (Gast)]

C Programmierer schrieb:
> Damit bekommt man schonmal die Differentiation aus der Implementierung.

Bei einem Abtastsystem verkommt die Differentiation zu einer simplen 
Differenz zweier aufeinanderfolgender Abtastwerte.
Warum soll man die in der Implementierung weg haben wollen?

[Stefan H. (cheeco)]

Hallo Sina,

Du hast das Problem schon richtig erkannt - man erkauft sich die 
"schönere" Trapezintegration mit der Verzögerung  von einem Takt - was 
sich wiederum auf die Geschwindigkeit deines Reglers auswirkt.

Das Stichwort für dich zum Weiterlesen ist Diskretisierung eines 
PID-Reglers (Euler-Forward, Euler-Backward, Tustin's method).

http://ecee.colorado.edu/shalom/Emulations.pdf
http://controlsystemslab.com/discrete-time-pid-controller-implementation/
http://www2.ensc.sfu.ca/people/faculty/saif/ctm/extras/PID_Bilinear.html


ABER: Einen wirklichen Einfluß auf das Regelverhalten haben die 
verschiedenen Methoden nur, wenn man sich ein einem Grenzbereich des 
Reglers bewegt. Das heißt im Umkehrschluß dass man mit anderen 
Maßnahmen, beispielsweise einer Erhöhung der Abtastfrequenz, wesentlich 
mehr erreichen kann.

Was man wirklich "verbessern" könnte wäre eine Begrenzung der 
Rauschverstärkung. Besonders bei kleinen Abtastzeiten wird der 
Differenzenquotient bei Rauschen "Kd * (e – ealt)/Ta" sehr groß. Dies 
kann man vermeiden, wenn man statt einem D-Glied ein DT1-Glied 
verwendet:

https://www.tutorials.de/threads/c-pidt1-regler.364675/

Auf der anderen Seite würde ich einfach mal versuchen, wie weit Du mit 
der Standardformulierung oben kommst.

Grüße,

Stefan

[Sina A. (sinapse)]

wer hätte das gedacht... noch mehr lesestoff xD

vielen dank. Das hört sich schwer danach an, als würden dort alle 
Antworten verborgen liegen. ich schau es mir mal an.

lg

[C Programmierer (Gast)]

Wolfgang schrieb:
> Bei einem Abtastsystem verkommt die Differentiation zu einer simplen
> Differenz zweier aufeinanderfolgender Abtastwerte.
> Warum soll man die in der Implementierung weg haben wollen?

Weil das zu einem hektischen Verhalten führt und der Differentiator 
damit praktisch immer auf 0 gesetzt werden muss und man sich damit auch 
den Quellcode und die Rechenzeit sparen kann.

[Lurchi (Gast)]

Bei der Ableitung kann bzw. sollte man sich schon noch ein paar gedanken 
machen. Die ideale Ableitung ist nichtzurealisieren - man braucht eine 
zusätzliche Filterung bzw. Begrenzung der Bandbreite nach oben. Im 
einfachsten Fall macht man das durch die Wahl einer passenden nicht zu 
hohen Abtastrate. Dann hat man auch oft keine Probleme mit zu viel 
Rauschen.  Wenn die Abtastrate höher ist oder höher gewählt werden soll. 
bzw. ggf. auch nicht konstant ist, muss man sich da eine etwas andere 
Näherung für die Ableitung suchen. Auf Werte aus der Zukunft kann man 
dabei aber natürlich nicht zurückgreifen - einfach alles Verzögern ist 
dabei auch keine ideale Lösung. Da gibt es bessere Näherungen, die dann 
halt ein paar mehr Werte aus der Vergangenheit berücksichtigen.

So schlimm ist das mit dem Rauchen des differenzgliedes in der Regel 
nicht: auch wenn man sich da einiges an Rauschen einfängt und der 
Ausgabewert dann etwas unruhig wird, mittelt die Regelstrecke das ganz 
gut wieder raus. Das zusätzliche Rauschen hat schließlich keinen Beitrag 
bei kleinen Freqenzen, sondern bei passendem Abgleich in der Regel nur 
da, wo das zu regelnde System schon als Tiefpass wirkt.