Pytanie:
Zapisywanie przefiltrowanego terminu pochodnego regulatora PID do kodu C ++
bluecore
2016-07-13 20:24:23 UTC
view on stackexchange narkive permalink

Wszędzie, gdzie patrzę, czy to PID, wyprowadzenie, kontrola opóźnienia czy cokolwiek innego, są schematy Simulink z funkcjami transferu. To wszystko jest dobre dla symulacji odpowiedzi systemu, jednak obecnie muszę zaimplementować sterowanie PID z przefiltrowanym terminem pochodnym w ściśle certyfikowanym urządzeniu medycznym, które jest kontrolowane przez mikroprocesor z kontrolującym go kodem C ++.

Teraz, jeśli weźmiemy kontroler PID w jego dziedzinie częstotliwości jako

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

możemy to zaimplementować jako

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

które możemy zapisać w pseudokodzie jako 

  integra + = error * dtderivative = (error - prevError) / dty = kp * błąd + ki * całka + kd * pochodnaprevError = błąd

Jednak teraz bierzemy filtrowaną kontrolę PID jako

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

Najlepsze, co przychodzi mi do głowy polega na utworzeniu odwrotności Laplace'a jako

$$ 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} \ right) e (t), \ quad e (0) = 0, $$

ale co to naprawdę oznacza? Całkowanie przez $ dt $ to jedno, ale wszystko, co widzę w $ e ^ {- Nt} $, to fakt, że po kilku sekundach, bez względu na to, co zrobię, będę miał tylko kolejną stałą proporcjonalności. Czy powinienem kiedyś zresetować czas? I jeszcze nie zapisaliśmy tego w C ++.

Jakie jest właściwe podejście?

Czy na pewno chcesz zastosować pochodną do błędu? Wiele komercyjnych algorytmów stosuje różniczkowanie do PV, aby NIE wyrzucać wyjścia przy zmianie wartości zadanej.
Dwa odpowiedzi:
bluecore
2016-07-14 15:49:12 UTC
view on stackexchange narkive permalink

Cóż, nie mam pojęcia, czy to prawda, ale jedyne, co przyszło mi do głowy po nocnym śnie i porannym prysznicu, to:

Mój odwrotny Laplace się myli, ponieważ ja nie uwzględnił błędu wejściowego $ e (t) $, czyli wariantu czasowego. Dlatego, jeśli spojrzymy na pochodną część funkcji przenoszenia kontrolera, możemy napisać

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

Teraz bierzemy wszelkie dane wejściowe błędu i ponownie tworzymy wynik jako

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

które można przekształcić w dziedzinę czasu jako

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

Rozwiązanie tego równania różniczkowego to

$$ y_ \ mathrm {D} (t) = \ mathrm {stała} \ 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. $$

Można to zaimplementować w kodzie, ale nie podoba mi się absolutny czas $ t $ tam, ponieważ mówimy o systemie wbudowanym ze skończoną pamięcią i zegarem około 120 MHz.

Inną opcją jest dyskretyzacja równania różniczkowego jako

$$ \ 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}, $$

dlatego

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

gdzie $ n $ to krok czasu, nie potęga $ n $. Na tej podstawie możemy obliczyć $ y_ \ mathrm {D} ^ n $, zsumować go z dwoma pozostałymi stałymi sterownika i podać na wejście siłowników.

Problem w tym, że obecnie stoję przed faktem, że system wbudowany będzie musiał rozwiązywać równanie różniczkowe w czasie rzeczywistym. Nie wiem, czy jest to właściwe podejście w branży, więc byłbym zadowolony, gdyby ktoś mógł wskazać inne rozwiązanie. Widzę z tym wiele problemów - dyskretyzowane równania są zasadniczo naprzód Eulera, czy może to powodować pewne problemy? Czy nie powinno się używać Runge-Kutty?

Runga-kutta to numeryczna metoda rozwiązywania równań różniczkowych, a nie dyskretyzacja.
Oczywiście, ale dyskretyzujesz formułę w inny sposób i ... chcę rozwiązać ODE.
WG-
2016-07-14 18:55:04 UTC
view on stackexchange narkive permalink

Sprawdź poniższy odnośnik http://www.ifac-control.org/publications/list-of-professional-briefs/pb_wittenmark_etal_final.pdf, zwłaszcza na stronie 50. Myślę, że to powinno pomóc całkowicie.

Aby uniknąć gnicia linków, rozszerz swoją odpowiedź o istotne informacje z podanego linku, przynajmniej najważniejsze punkty. Zapraszam do cytowania bezpośrednio ze źródła.


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...