PID - jeszcze raz

I jakoś wysyłasz tę powiekszoną liczbę? Binarnie, tekstowo?

Ale jak nie nadąża ... albo funkcja Print czeka, albo cos się z bufora gubi ...

Ale na początku jest zawsze 1926? To musi miec jakis powód.

Pierwsze poderzenie, które bym miał, to jednak to, że cos zatrzymuje główną pętlę,

Ale ciekawe bardzo

J.

W dniu 5.02.2026 o 20:34, Mirek pisze:

Gdyby to był uszkodzony w jednym miejscu enkoder to błąd by siię pojawiał przy mniejszej liczbie kroków bo0 jego rozdzielczość jak pisałeś to 1600 imp/obrót, więc to nie to. Ale jest inny trop, na pi siedzi linux z calym swoim bagażem i tutaj tym 'przeskadzaczem' może być przerwanie zegarowe np co sekundę. Stąd taka powtarzalność, pytanie czy można go wyłączyć w systemie. Albo wybrać inną płytkę, np arduino na avr-e gdzie całkowicie panujemy nad systemem i przepisać program w C i tam uruchomić. Od biedy ESP, ale one też mają jakiego rt-sa który jest nadrzędny nad programem, więc i tam może też być przerwanie które zatrzymuje wszystko.

to by potwierdzało moje przypuszczenia.

Zależą? bo w dwóch przykładach mamy inne liczby wywołań. Ale wywołania skorelowane z czasem ... chyba.

Temat wart dalszego zbadania.

J.

W dniu 6.02.2026 o 20:39, J.F pisze:

No nie do końca są skorelowane, bo tam jest sprawdzanie, czy bufor jest pełny i jak nie jest pełny to nie ma wywołania. Jeśli zrobi co najmniej jeden krok na pętlę, to wywołanie jest co pętlę (1ms) i wtedy faktycznie jakby błąd pojawia się około 2 na sekundę. No ale jeśli kręcę szybciej to błąd jest częściej, a wywołań tyle samo, więc już nie wiem.

Z resztą tak było w pierwszej wersji programu PIO. W drugiej bufor napełnia się na żądanie sm.put(1) i później sm.get(), więc może to być inaczej - i tutaj przyznaję się, że nie sprawdzałem dokładnie czy zachowuje się to identycznie - jak tylko zobaczyłem, że stukanie i błędy są nadal to zacząłem szukać innego rozwiązania.

W dniu 6.02.2026 o 20:32, Mirek pisze:

No to masz sukces, pid-y masz gotowe w C tylko wsadzić funkcję i odpowiednio wywoływać. Nawet ten co wkleiłem jest kompletny i możesz go spokojnie użyć.

W dniu 6.02.2026 o 22:09, Janusz pisze:

Ale nie powinien zatrzymywać licznika micros(), a właściwie time.ticks_us() - bo taki użyłem do sprawdzenia pętli. Pętlę wyzwalam z timera, który też nie powinien mieć czkawki, pętla się wykonuje za każdym wyzwoleniem z timera - to też sprawdzałem. Mimo wszystko zatrzymywanie się pętli pasowało by do objawów. Powinienem to sprawdzić oscyloskopem, albo chociaż na słuch, bo jeśli z

W dniu 8.02.2026 o 12:25, Mirek pisze:

Można to na dwa sposoby spróbować zmierzyć Mierzyć odstęp między tymi zatrzymaniami, zobaczymy jaki to czas, może się do czegoś dopasuje, być może jak "micros()" też się zatrzymuje to przy dłuższym pomiarze mocno nie zafałszuje pomiaru czasu, albo jak wystąpi zatrzymanie wysterować nogą PIO, a jak ruszy to skasować i obserwować przebieg na oscyloskopie. Bedzie okres między zdarzeniami i może uda się uchwycić jak długo ono trwa.

Sensowne byłoby, gdyby pętla nie była wykonywana, jak już jest wykonywana. Cos długiego w pętli - ta czeka, przerwania są albo zablokowane, albo nie uruchamiają pętli.

No ale masz ten licznik micros() - i tak się niby nie dzieje.

Jesli wierzyć odczytom z enkodera, to np zamiast 7 impulsów (w 1ms) zlicza 166, co sugeruje zatrzymanie na ok 23ms.

Choć ten inny test wychwytywał ok 17-18 impulsów. No i to się zdarzało co ok 2500 odczytów ... co 2.5s ?

J.

W dniu 6.02.2026 o 22:11, Janusz pisze:

Do sukcesu jeszcze daleko. Wzorowałem się tym razem na tym:

W dniu 10.02.2026 o 21:32, Mirek pisze:

Szczerze? nie podoba mi sie ten kod, ktoś tu poszedł na skróty względem normalnego pid-a

/* Controller parameters */ #define PID_KP 2.0f #define PID_KI 0.5f #define PID_KD 0.25f

#define PID_TAU 0.02f

#define PID_LIM_MIN -10.0f #define PID_LIM_MAX 10.0f

#define PID_LIM_MIN_INT -5.0f #define PID_LIM_MAX_INT 5.0f

float PIDController_Update(PIDController *pid, float setpoint, float measurement) { float error = setpoint - measurement;

float proportional = pid->Kp * error;

pid->integrator = pid->integrator + 0.5f * pid->Ki * pid->T * (error + pid->prevError);

/* Anti-wind-up via integrator clamping */ if (pid->integrator > pid->limMaxInt) { pid->integrator = pid->limMaxInt; } else if (pid->integrator < pid->limMinInt) { pid->integrator = pid->limMinInt; } /* * Derivative (band-limited differentiator) */ pid->differentiator = -(2.0f * pid->Kd * (measurement - pid->prevMeasurement) /* Note: derivative on measurement, therefore minus sign in front of equation! */ + (2.0f * pid->tau - pid->T) * pid->differentiator) / (2.0f * pid->tau + pid->T);

/* * Compute output and apply limits */ pid->out = proportional + pid->integrator + pid->differentiator;

if (pid->out > pid->limMax) {

pid->out = pid->limMax;

} else if (pid->out < pid->limMin) {

pid->out = pid->limMin;

W dniu 11.02.2026 o 09:22, Janusz pisze:

Nie zrobiłem jeszcze. Tamto jest w Pythonie, a na razie skupiłem się na C, i nie wiem czy już jednej płytki nie zajechałem, bo się jakieś cuda dzieją - nie zawsze wstaje na USB, nie zawsze program rusza po wgrywaniu.

W dniu 11.02.2026 o 09:34, Janusz pisze:

A co mu tam brakuje? Mi nie podoba się tylko ten integrator: pid->integrator = pid->integrator + 0.5f * pid->Ki * pid->T * (error + pid->prevError);

- czyli gościu dodaje obecny error do poprzedniego i dzieli przez dwa... dla wygładzenia? - nie wiem czy ma to jakikolwiek sens przy integratorze, zresztą spróbowałem to wywalić i niewiele się zmienia. No i limit ustawił na sztywno dla integratora - w sumie to nie próbowałem tak, zrobiłem po swojemu, czyli limituje jak w poprzednim cyklu moc zadana na silnik jest maksymalna.

W dniu 11.02.2026 o 18:47, Mirek pisze:

Brakuje I. Czyli nie uzględnia części narastającej błędu z P.

No te stałe które są w kodzie to też kiepski pomysł, widać że strojone pod konkretną rzecz.

nie tyle dla wygładzenia, co dla lepszego całkowania. obecny błąd wynosi np 10, poprzedni wynosił 13, ile dodać do całki za cały okres? średnia z obu wydaje się dobra, zresztą nazywa sie to metoda trapezów.

Na ile to istotne w przypadku PID ... chyba znikomo, może nawet szkodzi, bo na bardzo dokładnej wartości całki wcale nam nie zależy, za to powyzsze wprowadza "opóźnienie", które może byc przyczyną większych problemó.

I zastanowiłbym się nad dalszym rozszerzeniem tego. Całkowanie dużego błedu ma mały sens.

J.

W dniu 12.02.2026 o 14:40, J.F pisze:

No ale teoria sterowania nic o tym nie mówi. Z resztą teraz mam inne problemy. Wygląda na to, że printowanie przez USB w C jednak zakłóca przebieg normalnej pętli. Niby nie muszę printować w czasie działania PID-a, ale fajnie się stroi "na żywo", a podłączenie komputera przez USB wydaje się naturalne i najwygodniejsze. Próbowałem wyrzucić PID-a do osobnego wątku na drugim rdzeniu. Kilka razy mi to zadziałało pięknie, ale za którymś razem zaczęło się coś wieszać, w ogóle nie zgłaszał się na USB albo tak jakby nie ruszał ten drugi rdzeń. Myślałem że flash się już poddaje, bo było wgrywane już z 500 razy, ale podpiąłem nową płytkę i to samo. Najciekawsze jest to, że czasem się uda skompilować i wgrać i ruszy. Dziś wiele nie poszalałem, bo wpadł do naprawy jeszcze falownik - też ciekawy przypadek - może nowy wątek założę.

Wow, a jak to działa na PICO? Bo tam program przecież z szeregowego eproma ... na jeden rdzen za wolno :-)

Przepisują sobie do RAM ? Kod PID krótki.

J.

W dniu 12.02.2026 o 22:36, J.F pisze:

Ta pamięć wcale nie taka wolna jest, do tego jest cachowana, więc pewnie sobie dociąga blokami i jakoś się kręci. Najciekawsze, że ja wcale nie widzę jakiegoś szalonego przyspieszenia dla C w stosunku do MicroPythona. W sumie pod MicroPythonem też używałem drugiego rdzenia i problemów nie było. Przyspieszenie widziałem w Raspberry Pi z Raspbianem, gdzie napisałem sztuka dla sztuki obsługę wyświetlacza LCD 122x32 w Pythonie. Żeby zapalić wszystkie pikselki na czarno to było ze 3 sekundy, potem 3 sekundy na biało, potem się rysowały po kolei cyferki, które chciałem wyświetlić. Po przerobieniu na C po prostu pojawiały się od razu cyferki, a i tak musiałem sygnał strobe wydłużyć, bo nie łapał.

Nie to raczej nie ta architektura.

To byłoby istotnie ciekawe, bo chyba ten Python ciągle nie jest kompilowany na kod ARM, ale ... przecież Ty masz nieobciązony procesor, bo pętla regulatora uruchamiana w przerwaniu.

napisz drugi program, który bedzie funkcję regulatora wywoływał w pętli programowej, i co milion wywołań wypisze cos przez USB, czy diodą mrugnie ... albo nastawe zwiększy o 1.

Zwykły Python na Raspberry jest chyba interpretowany, czy połowicznie kompilowany w locie, cos w stylu Javascriptu. I to szybkie nie jest.

Architektura chyba dobra, tylko RAM mało :-)

Na jedną pętle regulatora powinno jednak starczyc :-)

J.