Écriture d'un terme dérivé filtré du contrôleur PID dans le code C ++

6

Partout où je regarde, que ce soit un PID, une piste, un contrôle du décalage ou toute autre chose, il y a des schémas Simulink avec des fonctions de transfert. Tout cela est intéressant pour la simulation de la réponse système, mais je dois actuellement implémenter un contrôle PID avec un terme dérivé filtré dans un dispositif médical strictement certifié, contrôlé par une puce avec un code C ++ le contrôlant.

Maintenant, si nous prenons le contrôleur PID dans son domaine de fréquence comme

$$ C (s) = k_ \ mathrm {P} + \ frac {k_ \ mathrm {I}} {s} + k_ \ mathrm {D} s = \ frac {s (s)} {e (s)} , $$

nous pouvons mettre en œuvre que

$$ y (t) = k_ \ mathrm {P} e (t) + k_ \ mathrm {I} \ int_ {0} ^ {t} e (\ tau) d {e} (t), \ quadro (0) = 0, $$

que nous pouvons écrire en pseudo-code comme

integral += error*dt
derivative = (error - prevError) / dt
y = kp*error + ki*integral + kd*derivative
prevError = error

Cependant, maintenant nous prenons le contrôle PID filtré comme

$$ C (s) = k_ \ mathrm {P} + \ frac {k_ \ mathrm {I}} {s} + k_ \ mathrm {D} \ frac {sN} {s + N} $$

Le mieux que je puisse penser est de créer inverse Laplace

$$ y (t) = k_ \ mathrm {P} e (t) + k_ \ mathrm {I} \ int_ {0} ^ {t} e (\ tau) d \ tau + k_ \ mathrm {D} \ left (N \ delta (t) - N ^ 2e ^ {- Nt} \ droite) e (t), \ quad (0) = 0, $$

mais qu'est-ce que cela représente vraiment? Intégrer via $ dt $ est une chose, mais tout ce que je peux voir dans le $ e ^ {- Nt} $, c’est le fait qu’après quelques secondes, peu importe ce que je ferai, j’aurai juste une autre constante proportionnelle. Devrais-je réinitialiser l'heure à un moment donné? Et nous n'avons même pas encore écrit cela en C ++.

Quelle est la bonne approche?

bluecore
la source
Êtes-vous sûr de vouloir appliquer un dérivé à une erreur? De nombreux algorithmes commerciaux appliquent une action dérivée à la PV, afin de ne PAS lancer la sortie lors du changement de point de consigne.
OldUgly

Réponses:

1

Eh bien, je ne sais pas si cela est correct, mais la seule chose qui me vienne à l’esprit après la nuit de sommeil et une douche matinale est la suivante:

Mon inverse, Laplace, est faux, car je n'ai pas rendu compte de l'erreur entrée $ e (t) $ qui est une variante du temps. Par conséquent, si nous examinons la partie dérivée de la fonction de transfert du contrôleur, nous pouvons écrire

$$ C_ \ mathrm {D} (s) = \ frac {sN} {s + N}. $$

Maintenant, nous prenons quelle que soit l'entrée d'erreur et nous recréons la sortie en tant que

$$ y_ \ mathrm {D} (s) = \ frac {sN} {s + N} e (s) \ implique sy_ \ mathrm {D} (s) + Ny_ \ mathrm {D} (s) = Nse ( s), $$

qui peut être transformé en domaine temporel en tant que

$$ \ dot {y} _ \ mathrm {D} (t) + Ny_ \ mathrm {D} (t) = N \ dot {e} (t). $$

La solution pour cette équation différentielle est

$$ y_ \ mathrm {D} (t) = \ mathrm {constant} \ times e ^ {- Nt} + e ^ {- Nt} \ int_0 ^ tN \ dot {e} (\ tau) e ^ {N \ tau} d \ tau, \ quad y_ \ mathrm {D} (0) = 0, \ quad e (0) = e_0. $$

Cela pourrait être implémenté dans le code, mais je n'ai pas envie que le temps absolu $ t $ soit là, car nous parlons de système embarqué avec une mémoire finie et une horloge d'environ 120 MHz.

L’autre option consiste à discrétiser l’équation différentielle comme

$$ \ frac {y_ \ mathrm {D} n - y_ \ mathrm {D} ^ {n - 1}} {\ Delta t} + Ny_ \ mathrm {D} ^ {n} = N \ frac {e ^ n - e ^ {n - 1}} {\ Delta t}, \ quad n \ in \ mathbb {N}, $$

donc

$$ y_ \ mathrm {D} ^ n (1 + N \ Delta t) = N \ gauche (e ^ n - e ^ {n - 1} droite) + y_ \ mathrm {D} ^ {n - 1} , \ quad y_ \ mathrm {D} ^ 0 = 0, \ quad e ^ 0 = e_0, $$

où $ n $ est le pas de temps, ne pas pouvoir au $ n $. À partir de là, nous pouvons calculer le $ y_ \ mathrm {D} ^ n $, le résumer aux deux autres constantes du contrôleur et l’alimenter à l’entrée des actionneurs.

Le problème, c’est que je suis actuellement confronté au fait qu’un système embarqué devra résoudre une équation différentielle, en temps réel. Je ne sais pas si c'est la bonne approche dans l'industrie, alors je serais heureux si quelqu'un pouvait proposer une solution différente. Les problèmes que je vois avec cela sont nombreux - les équations discrétisées sont fondamentalement des avants Euler, est-ce que cela peut causer des problèmes? Runge-Kutta ne devrait-il pas être utilisé?

bluecore
la source
Runga-kutta est une méthode numérique permettant de résoudre les ODE, pas pour la discrétisation.
WG-
Bien sûr, mais vous discrétisez la formule d'une manière différente, et ... je veux résoudre un ODE.
bluecore
0

Veuillez vérifier la référence suivante http://www.ifac-control.org/publications/list-of-professional-briefs/pb_wittenmark_etal_final.pdf , en particulier la page 50. Je pense que cela devrait vous aider complètement.

WG-
la source
1
Afin d’éviter les ruptures de liens, veuillez développer votre réponse pour inclure les informations pertinentes contenues dans le lien fourni, au moins les points les plus essentiels. N'hésitez pas à citer directement à partir de la source.
Wasabi