Goto page Previous 1, 2, 3, 4, 5
Mirek
Guest
Wed Feb 11, 2026 7:38 pm
W dniu 11.02.2026 o 09:22, Janusz pisze:
Quote:
no dobra a zrobiłeś te pomiary czasu tych zakłóceń o których pisałem w
innej części wątku? zlokalizowałeś już powód tych zakłóceń odczytu
enkodera?
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.
--
Mirek
Mirek
Guest
Wed Feb 11, 2026 7:47 pm
W dniu 11.02.2026 o 09:34, Janusz pisze:
Quote:
Szczerze? nie podoba mi sie ten kod, ktoś tu poszedł na skróty względem
normalnego pid-a
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.
--
Mirek
Janusz
Guest
Thu Feb 12, 2026 10:41 am
W dniu 11.02.2026 o 18:47, Mirek pisze:
Quote:
W dniu 11.02.2026 o 09:34, Janusz pisze:
Szczerze? nie podoba mi sie ten kod, ktoś tu poszedł na skróty
względem normalnego pid-a
A co mu tam brakuje?
Brakuje I. Czyli nie uzględnia części narastającej błędu z P.
Quote:
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.
No te stałe które są w kodzie to też kiepski pomysł, widać że strojone
pod konkretną rzecz.
--
Janusz
J.F
Guest
Thu Feb 12, 2026 3:40 pm
On Wed, 11 Feb 2026 18:47:57 +0100, Mirek wrote:
Quote:
W dniu 11.02.2026 o 09:34, Janusz pisze:
Szczerze? nie podoba mi sie ten kod, ktoś tu poszedł na skróty względem
normalnego pid-a
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.
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ó.
Quote:
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.
I zastanowiłbym się nad dalszym rozszerzeniem tego.
Całkowanie dużego błedu ma mały sens.
J.
Mirek
Guest
Thu Feb 12, 2026 8:48 pm
W dniu 12.02.2026 o 14:40, J.F pisze:
Quote:
I zastanowiłbym się nad dalszym rozszerzeniem tego.
Całkowanie dużego błedu ma mały sens.
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żę.
--
Mirek
J.F
Guest
Thu Feb 12, 2026 11:36 pm
On Thu, 12 Feb 2026 19:48:36 +0100, Mirek wrote:
Quote:
W dniu 12.02.2026 o 14:40, J.F pisze:
I zastanowiłbym się nad dalszym rozszerzeniem tego.
Całkowanie dużego błedu ma mały sens.
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,
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.
Mirek
Guest
Fri Feb 13, 2026 12:31 am
W dniu 12.02.2026 o 22:36, J.F pisze:
Quote:
Wow, a jak to działa na PICO?
Bo tam program przecież z szeregowego eproma ... na jeden rdzen za
wolno :-)
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ł.
Quote:
Przepisują sobie do RAM ?
Nie to raczej nie ta architektura.
--
Mirek
J.F
Guest
Fri Feb 13, 2026 8:55 am
On Thu, 12 Feb 2026 23:31:55 +0100, Mirek wrote:
Quote:
W dniu 12.02.2026 o 22:36, J.F pisze:
Wow, a jak to działa na PICO?
Bo tam program przecież z szeregowego eproma ... na jeden rdzen za
wolno :-)
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.
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.
Quote:
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ł.
Zwykły Python na Raspberry jest chyba interpretowany, czy połowicznie
kompilowany w locie, cos w stylu Javascriptu.
I to szybkie nie jest.
Quote:
Przepisują sobie do RAM ?
Nie to raczej nie ta architektura.
Architektura chyba dobra, tylko RAM mało :-)
Na jedną pętle regulatora powinno jednak starczyc :-)
J.
Goto page Previous 1, 2, 3, 4, 5