Skocz do zawartości

Regulator PID - wątpliwości


Pomocna odpowiedź

Widzę, że umknęła tobie zasadnicza własność regulatora PID. Otóż wartość sygnału sterującego w następnym kroku obliczasz na podstawie wzoru:

nowa wartość = kp * uchyb + ki * całka + kd * różniczka

gdzie kp - waga członu proporcjonalnego, ki - waga członu całkującego, kd - waga członu różniczkującego

Jak słusznie zauważyłeś - niektóre układy wymagają większego wpływu poszczególnych składników, a inne mniejszego. Na tym właśnie polega dobór nastaw.

Jest dokładnie tak jak pisze Gandalf. LF wystarczająco dobrze przejedzie tor z samym członem P. Człon D doda tylko dynamikę na zakrętach. Natomiast wiele osób, w tym ja uważa, że człon I jest zbędny w LF'ch.

W takich obiektach w grę wchodzi tylko dobór nastaw metodą prób i błędów. Nie widzę sensu identyfikowania obiektu jedną z dostępnych metod 'tabelkowych'...

Sygnał sprzężenia zwrotnego (z czujników linii) w LFie ma bardzo małą rozdzielczość. Nawet jeżeli zastosujesz 20 czujników to i tak nie oznacza to 20 bitowej rozdzielczości. Możesz dzięki temu uzyskać jedynie kilka kombinacji w zależności od szerokości rozstawienia.

Nie do końca. Nie buduję już linefolowerów, ale kiedyś znalazłem w internecie linefollowera który miał kilkaset stanów na 8 czujnikach. Konstruktor wykorzystał (albo przynajmniej tak deklarował) tą własność transoptorów, że na granicy napięcie na wyjściu czujnika (wejściu ADC) zmienia się "płynnie" . Testowałem to tylko na pojedynczym czujniku i rzeczywiście, zmienia się to płynnie, ale prawdopodobnie przy prędkości dzisiejszych linefollowerów odczytanie tych małych różnic jest niemożliwe.

GAndaLF uznałem to równanie za oczywiste i dlatego go nie napisałem. Z resztą chyba napisałem już, że jeździłem na całym algorytmie PID. A na temat członu I słyszałem wiele opinii, żadnej z nich nie podzielam, bo nie mam jeszcze doświadczenia w dobieraniu tych nastaw, ale na pewno sobie zdanie na ten temat wyrobię.

Podsumowując, bilans dotychczasowych moich wątpliwości jest nadal wysoki. O ile odnośnie członu I mogę już przeboleć tą teoretyczną ułomność zbyt wolnego reagowania całki w układach słabo dostrojonych, to jeśli chodzi o człon D to nie dostałem jednoznacznej, namacalnej odpowiedzi.

Jeżeli uznałeś to równanie za oczywiste dziwi mnie twoja reakcja na wieść o wagach poszczególnych członów 😋

Człon I powoduje przyspieszenie odpowiedzi układu kosztem wzrostu przeregulowania, może też powodować niestabilność. Jest bardzo przydatny w powolnych procesach takich jak na przykład kontrola temperatury. Jak ktoś wyżej słusznie zauważył jego przydatność w line followerach jest wątpliwa i często stosuje się samą regulację PD. Natomiast o co ci chodzi w "teoretycznej ułomności całki w układach słabo dostrojonych" to nie mam pojęcia 😋

Dobra, nie chce mi się jeszcze raz prowadzić mojego (zapewne niepoprawnego 😋) wywodu na temat członu I. W każdym razie go będę próbował dostrajać na końcu.

Nadal nie wiem jak to jest z członem D. Teraz już chyba nie ma wątpliwości, że nie ma sensu interpretować go jako iloczynu stałej oraz zmiany uchybu teraźniejszego do tego, co był w poprzedniej pętli, bo po prostu zbyt długo mam ten sam stan czujników. Próbowałem w takim razie zinterpretować w ten sposób, by zamiast tej różnicy dać odwrotność ilości pętli, w których był poprzedni uchyb. W ten sposób, jeżeli będziemy długo jechać na jakiejś wartości uchybu, to reakcja silników wyliczona z członu D będzie mniejsza, niż przy małej ilości pętli, czyli szybko zmieniającym się uchybie. Problem w tym, że jest to funkcja 1 przez x, więc traci swoją liniowość. Jak to wygląda w teorii? Czy dopuszcza się taką nieliniową interpretację członu D?

W praktyce wygląda to tak, że spełnia (przynajmniej przy małej prędkości, dla jakiej testowałem) on swoją rolę całkiem dobrze. Od razu widać poprawę przy chwili poprawiania wartości stałej Kd.

Właśnie dlatego pisałem o normalizowaniu nastaw względem częstotliwości. Jak często wykonujesz pętle i masz te same wartości na czujnikach w kolejnych iteracjach to waga członów powinna być mniejsza.

Na przykład przy częstotliwości 50MHz robot będzie miał niewielkie zmiany pomiędzy uchybami w poszczególnych pętlach. Jeżeli masz częstotliwość procesora 10MHz to prosto stwierdzić, że te zmiany będą proporcjonalnie większe i w międzyczasie będzie mniej odczytów z takimi samymi wartościami. Dlatego żeby przy obu częstotliwościach zapewnić takie samo sterowanie nastawy przy 50MHz powinny być 5x mniejsze niż przy 10MHz. To, że posiadasz większą ilość próbek będzie dla ciebie pomocą, ponieważ możesz płynniej reagować na zmiany. A nawet jeśli w danej iteracji człon różniczkujący nie będzie miał wpływu to masz jeszcze człon proporcjonalny który działa w każdej iteracji jeżeli uchyb jest niezerowy

Nie jestem o tym przekonany. Wątpię, czy nawet duża waga członu D będzie miała znaczenie przy jednostkowych zmianach uchybu ze względu na bezwładność silników, ale sprawdzę oba sposoby i dam znać, co według mnie lepiej wyszło.

Tak, czytałem. Ale szczerze Ci powiem, że nie do końca mieści się to w moim rozumieniu słowa 'praktyczne'. Według mnie, jest to przystępnymi słowami przedstawiona teoria i zależności teoretyczne odnośnie tego regulatora. Praktyką dla mnie jest kawałek kodu lub coś w tym stylu. Ale oczywiście czytałem 🙂

Może Ty mi Sabre powiesz, jak to jest z tą interpretacją sytuacji zmiany wartości uchybu na jednej z na przykład tysiąca pętli? Według mnie człon w stylu:

Turn+= ... + StalaDerivate*(Error-LastError);

(przy oczywiście założeniu stałości częstotliwości wykonywania algorytmu) nie ma sensu... Przez 999 pętli ten człon nie ma wpływu, zaś na jedną pętlę powiedzmy trwającą 1 mikrosekundę pójdzie sygnał na silniki, więc silniki tego w ogóle nie odczują... Jak to jest? Nie lepiej zrobić coś w tym stylu:

Turn+= ... + StalaDerivate*(Error - ZapamietanyLastError)/IloscPetliLastError

Jeżeli jest szybka zmiana uchybu człon będzie miał większy wpływ, niż przy zmianach wolnych. I oczywiście jest zachowany znak przyrostu (czasami jest wiekszy od zera, czasami mniejszy). Dobrze rozumuję?

danioto, powiem tak, nie bez przyczyny ja Kd mam powyżej 1000, przy Kp mniejszym niż 20.

D liczę w taki sposób jak ty Kd*(Error-LastError)

Kiedyś testowałem jakiś inny sposób wyliczania uchybu, ale wróciłem do sprawdzonego z bardzo dużym Kd i działa to u mnie, moje lfr jeżdżą płynnie i dobrze reagują na kąty proste z samego PIDa.

Ok, dzięki. Popróbuję.

A czy byłby sens w kontroli nie tylko wartości uchybu, ale również i wypełnienia sygnału PWM silników? Chociaż chyba nie, bo to jest przecież wartość zwracana z regulatora PID. Tak tylko głośno myślę. 🙂

Możesz robić taką kontrolę obrotów silników tylko musisz zdawać sobie sprawę na co się porywasz. Ja bym to widział jako zastosowanie dwóch PIDów kaskadowo i dodatkowych enkoderów do kontroli rzeczywistej prędkości silników. Wtedy pierwszy PID oblicza wartość zadaną PWM na podstawie czujników linii, a wyjście było by wartością zadaną dla następnego PIDa tym razem używającego do sprzężenia zwrotnego informacji o aktualnej prędkości przeliczonej na PWM jaki jej odpowiada.

Najlepiej najpierw się pobaw z pojedynczą pętlą sterowania zanim się weźmiesz za takie urozmaicenia.

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
×
×
  • Utwórz nowe...