Skąd dokąd ma skakać w tą i z powrotem ?
No chyba że jest przekombinowany i sam się domyśla co będzie w przyszłości i reaguje na urojone bodźce.

No to weźmy "nieprzekombinowany" regulator PID. Nacałkował sobie uchybu, potem przejechał przez 0 ale dalej ma nacałkowane, więc przez to zero przejeżdża na drugą stronę - zaczyna całkować w drugą stronę i tak w kółko. Człon D i oproy mechaniczne układu wyhamują te oscylacje do poziomu +/- 1 impulsu. A dalej to już się zaczyna zabawa z tarciem statycznym na przykład - efekt wyjątkowo podły, bo skrajnie nieliniowy, i regulatory typu PID bardzo źle sobie z nim radzą.
Są na ten temat publikacje, np:
"Analysis and Model-based Control of Servomechanisms with Friction" Evangelos G. Papadopoulos and Georgios C. Chasparis

Mogą mijać nawet lata i oczywiście nikt nie wie, że silnik stoi w miejscu ...

Jeżeli układ ma stałe czasowe liczone w milisekundach, to przy obrocie z prędkością 0.1obr/s między tyknięciami enkodera mijają te "lata". To nie znaczy, że w regulatorze PID mam mieć człon D zupełnie z d...

To co jest pomiędzy kreskami enkodera jest nieważne, a liczenie tego co jest poniżej dokładności pomiaru nie ma sensu najmniejszego.

Dane pomiędzy obserwacjami są bez znaczenia. Pewnie dlatego napisano setki (tysiące?) publikacji natemat interpolacji. Eh...

Ja Ci chyba już kiedyś pisałem, że nadmiar wiedzy teoretycznej szkodzi.

Wiedza teoretyczna została właśnie przekuta na praktykę. Teraz regulator działa - i działa dobrze. Pzedtem po wprowadzeniu jakiejkolwiek w miarę użytecznej wartości D działał źle - przy małych prędkościach szarpał aż trzeszczało.

[ Dodano: 2012-11-21, 23:32 ]
film


[ Dodano: 2012-11-22, 02:07 ]
Heh, zaimplementowałem i z grubsza wystoriłem regulator PIV. W jego wypadku mam jeszcze problem z drobnymi oscylacjami w spoczynku. Reaguje mniej agresywnie, niż pid, ale pracuje kulturalniej i czas ustalania wydaje się być ciut krótszy. Na razie powinienem się skupić raczej na przetestowaniu zintegrowanych peryferiów procesora (sprzętowa obsługa enkoderów) i budowie płytki 3 (lub 4) osiowej.

czasowa pomiedzy znacznikami enkodera jest znacznie wieksza niż czestość próbkowania to błąd wyznaczania predkosci jest pomijalnie mały

Właśnie wtedy błąd jest olbrzymi Przy trzymaniu stałej pozycji między impulsami mogą mijać nawet sekundy - nikt nie wie, co się wówczas napradę dzieje z silnikiem. Natomiast jak enkoder daje impulsy 10kHz, to już w ciągu 1ms mamy aż 10 próbek, z których można liczyć prędkość.
No nic, zaczynami implementację...

Jeżeli pomiędzy zderzeniami ( sygnałami A,B) przeliczamy filtr, to na jego wejściu musimy dać dane z palca

Właściwie, to z palca jest tylko prędkość - i tego "palca" dotyczy ten wątek - uchyb (z dokładnością do rozdzielczości enkodera) przecież znamy. Swoją drogą, to uchyb nie musi wcale być stały - przecież zadana pozycja też może ulegać zmianom w czasie - maszyna ma się poruszać po jakiejś krzywej, to punkt zadany jest zmienny. Ja zamierzam utrzymać krok całkowania krzywej poniżej okresu PWM - u mnie jest to coś rzędu 30µs.

Komutator ma raczej sporo pól - ale chyba ważniejsze, że tak na wyczucie, to wirnik ma skośne szczeliny - bo silnik nie przeskakuje w żaden zauważalny sposób jak się nim kręci.

teraz "eeee"e a przdtem było "cieniutko".
tylko ze jak złe stemplowanie czasu to i kiepska matematyka

Chyba się słabo rozumiemy. Samo stemplowanie czasu wydarzeń nie wystarczy. Również pomiędzy nimi regulator musi zmieniać swoje wyjście, więc musi pracować na jakimś timerze - praca w pętli głównej programu nie jest najlepszym pomysłem, bo jak przyjdą przerwania komunikacyjne*, to procek może dość długo do pętli głównej nie powrócić.

* komunikację robię tak: jak w FIFO od USARTa znajdę znak końca pakietu, to wywołuję softwareowo przerwanie EXTI4 o niskim priorytecie, na którym pakiet jest przetwarzany. Priorytet jest niski dlatego, że przetwarzanie takiego pakietu może trwać długo.

Dlatego lepsze rozwiązanie to sprawnie działający system przerwań od sygnałów A, B,"0"

Eeeeee.... PID ma całkować nawet, jak uchyb się nie zmienia - wystarczy, że jest niezerowy.

A czy rzuca niemiłosiernie? No, dynamikę to on ma, nie powiem. Ale na małych prędkościach chodzi naprawdę gładziutko - mogę mu zadać prędkość 0.1obr/s i chodzi bezgłośnie.

Witam,
Podczas prac nad sterownikiem serwo napotkałem następujący problem: enkoder pozwala odczytać pozycję (w miarę dokładnie), jednak jego użyteczność w zakresie odczytu prędkości jest ograniczona - przy dużej prędkości częstotliwość zmian wskazania pozycji jest porównywalna z krokiem całkowania, ale przy małych prędkościach wygląda to już cieniutko. Kilka rozwiązań chodzi mi po głowie:
1. Filtr Kalmana - ale tutaj jest problem, bo charakterystyka układu jest zależna od prędkości (tzn. przy większej prędkości mamy większą pewność, więc filtrowanie powinno być mniej agresywne).
2. Taki filtr dyskretny:
v - aktualnie estymowana prędkość
t - czas, który upłynął pomiędzy zmianami wskazania enkodera
d - zmiana wskazania enkodera (-1, 0,+1)
η - stała zaniku prędkości (np. 0.99 czy coś w tym guście)
f(t) - funkcja pewności aktualnego odczytu - funkcja malejąca, wartości z przedziału <0, 1>
W każdym kroku pracy układu wykonujemy następującą operację:
v=ηv
jeżeli d!=0, to
v=v*(1-f(t)) + f(t)*d/t

Jak widać, kiedy nie ma zmiany pozycji enkodera, prędkość sobie powoli zanika, zgodnie z η. Jeżeli natomiast mamy zmianę, to poprzednie wskazanie zanika szybciej na rzecz nowego odczytu d/t. Funkcja f(t) przyjmuje małe wartości dla dużych t, aby nie wprowadzać nagłych "skoków" prędkości przy pojedynczych zliczeniach enkodera.

Co sądzicie o takim podejściu? Czy może ktoś implementował filtrowanie prędkości do PIDa? Jeżeli tak, to co zastosował i czy zadziałało?