Optymalne strojenie PID dla silnika z enkoderem na Pi Pico zjawiska oscylacji?

Thu Feb 05, 2026 9:34 pm   

W dniu 5.02.2026 o 08:38, J.F pisze:


Nie stuka, bo Kp jest niewielkie - przy Kd=0 musi być niewielkie dla
stabilności. Ale przy takim niewielkim wystarczy wprowadzić niewielkie
Kd i już słychać stukanie.



Przecież pisałem - dodaję stałą liczbę co cykl.




To bez znaczenia. błędy są czy się je printuje czy nie. Stuka tak czy siak.




Nic nie czeka. Pętla ma 1ms czy drukuję czy nie. Bufor drukowania chodzi
osobno i fakt, nie nadąża jak za dużo drukuję na raz, ale to nadal nie
zmienia czasu pętli.


Dobra, dziś spędziłem nad tym kilka godzin.
Generalnie wygląda na to, że te błędy to są jakieś skumulowane
(zbuforowane?) impulsy z enkodera.
Czyli:
W pierwszej kolumnie mamy licznik odczytów z fifo PIO, w drugiej
odczytaną wartość, w trzeciej różnicę do poprzedniej - żeby było łatwo
patrzeć.
Teraz steruję PWM minimalnie żeby tylko się silnik kręcił (pid nie
działa - daję stałą wartość do PWM) i mamy:
(tylko interesujący fragment)

1922 1922 1
1923 1923 1
1924 1924 1
1925 1925 1
1926 1928 3
1927 1929 1

kręcimy trochę szybciej i mamy:

1920 10714 7
1921 10722 8
1922 10730 8
1923 10738 8
1924 10746 8
1925 10753 7
1926 10919 166
1927 10926 7

Dodatkowo - testowałem to trzy razy - wartość mimo tych błędów odpowiada
położeniu enkodera. Enkoder daje 800 impulsów na obrót* - zadaję mu
800000 kroków, błędy sobie radośnie stukają a on po tych 100 obrotach
staje dokładnie tam gdzie był w zerze.
Czyli na mój gust są to kroki, które powinny się pojawić po jednym
gdzieś we wcześniejszych odczytach ale się nie pojawiają.
Czy są to kolejne cyfry złożone w liczbę, tak jak się wydawało?
- nie, to tylko przypadek.
Czy liczba 1926 odczytów ma tu jakieś znaczenie?
- Tak jest tylko na początku, potem już różnie.
Tutaj odczyty tylko błędów, czyli printuje jeśli różnica do poprzedniej
większa od 10 (pokrywa się ze stukaniem), druga kolumna tym razem co ile
odczytów:

17329 2515 18
19848 2519 18
22361 2513 17
24882 2521 18
27398 2516 17
29914 2516 18
32435 2521 18
34947 2512 17
37470 2523 18
39977 2507 17

Czyli coś źle działa i nie wiemy dlaczego. Nawet nie mam teorii jak taki
błąd mógłby powstać.
Próbowałem wgrywać nowego MicroPythona, najnowsze jakieś nieoficjalne
wydania, następnie najstarsze jakie tylko mam - dzieje się to samo.

Znalazłem jeszcze to:
https://forums.raspberrypi.com/viewtopic.php?t=378082
Skopiowałem tą klasę, odpaliłem i już się zacząłem cieszyć, bo okazało
się, że jednak z tamtym odczytem było coś nie tak, bo mój enkoder ma
jednak 1600 imp/obrót (stąd gwiazdka wcześniej)... ale błędy i stukanie
nadal jest.

Trudno mi to komentować, dlatego powstrzymam się.


--
Mirek

Fri Feb 06, 2026 2:02 am   

On Thu, 5 Feb 2026 20:34:51 +0100, Mirek wrote:

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.

Fri Feb 06, 2026 3:50 pm   

W dniu 5.02.2026 o 20:34, Mirek pisze:

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.



--
Janusz

Fri Feb 06, 2026 9:15 pm   

W dniu 6.02.2026 o 14:50, Janusz pisze:



Przerwania owszem, mogły by taki efekt robić, ale musiały by zatrzymywać
też licznik micros() to raz, dwa - to by były bardzo dziwne przerwania,
bo nie są stałe w czasie a trochę jakby zależą od liczby wywołań sm.get().


--
Mirek

Fri Feb 06, 2026 9:32 pm   

W dniu 6.02.2026 o 01:02, J.F pisze:


W ogóle nie wysyłam. Co pętlę dodaje tą stałą do pozycji zadanej dla PID.



No to się gubi i tego najwyżej nie zobaczę. Ale nie ma wpływu na pętlę.
Uwierz, że się nie gubi. Jeśli printuję za dużo to potem nawet po
zatrzymaniu programu dane lecą na terminal aż mi się znudzi i go zamknę.
Dlatego nie printuję za dużo, bo to nie ma sensu.



No ciekawe to jest, że oczywiście nikt na świecie tego nie odkrył albo
tylko u mnie się to objawiło.
Zrobiłem obsługę tego enkodera w C. Oczywiście straciłem kilka godzin,
bo kiedy zadziałał enkoder to znowu PWM nie chciało działać, no ale nie
ważne - wygląda na to że teraz tego błędu nie ma. PID-a jeszcze nie
przerobiłem - ciąg dalszy nastąpi.



--
Mirek

Fri Feb 06, 2026 9:39 pm   

On Fri, 6 Feb 2026 20:15:09 +0100, Mirek wrote:

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

Temat wart dalszego zbadania.

J.

Fri Feb 06, 2026 9:52 pm   

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.


--
Mirek

Fri Feb 06, 2026 11:09 pm   

W dniu 6.02.2026 o 20:15, Mirek pisze:

za mini system,
może on coś miesza tym bardziej że jak piszesz w innym miejscu
przepisałeś na C to masz stabilne odczyty.


będzie kumulacja
czyli coś podobnego co masz teraz przy zliczaniu impulsów z enkodera.


to raz, dwa - to by były bardzo dziwne przerwania,

patrzeć a nie wiem czy jest w ogóle do tego dostęp.



--
Janusz

Fri Feb 06, 2026 11:11 pm   

W dniu 6.02.2026 o 20:32, Mirek pisze:

odpowiednio wywoływać. Nawet ten co wkleiłem jest kompletny i możesz go
spokojnie użyć.

--
Janusz

Sun Feb 08, 2026 1:25 pm   

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
1ms robi się nagle 10ms to powinno to być słychać jako trzask.

--
Mirek

Sun Feb 08, 2026 4:07 pm   

W dniu 8.02.2026 o 12:25, Mirek pisze:

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.



--
Janusz

Sun Feb 08, 2026 6:48 pm   

On Sun, 8 Feb 2026 12:25:28 +0100, Mirek wrote:

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 ?

256*10ms ?
Nie ma jakiegoś przerwania 100Hz ?

J.

Tue Feb 10, 2026 10:32 pm   

W dniu 6.02.2026 o 22:11, Janusz pisze:


Wzorowałem się tym razem na tym:
https://github.com/pms67/PID/blob/master/PID.c
I tutaj też jest filtr na D i o dziwo ten filtr mi zadziałał, tzn byłem
uparty, i po tym jak zwiększyłem stałą czasową tak, że zaczął wprowadzać
oscylacje, zwiększyłem radykalnie kd i okazało się, że z filtrem można
jeszcze zwiększać, a bez filtra już nie.
Mimo wszystko nie jest tak, jak powinno być. Nie udaje mi się szybko
zejść do zerowego błędu bez kołysania, a jeśli już to przypadkiem raz na
kilka jazd. W ogóle mam wrażenie jakby teraz pod C strasznie szumi ten
PWM, nie stuka, ale szum jest taki jak audio na 4-ech bitach. To tak
wygląda, jakby człon P dawał normalne PWM, natomiast D daje szpile
losowo i jakoś to się stabilizuje. Jakoś, bo to dojście do zerowego
błędu wygląda tak, że np, jest +1, prawie stoi, narasta pisk, trzask i
jest na -12. znowu narasta, trzask i jest +2. Za którymś razem jak mi
się nie znudzi to stanie na 0.
A ja chciałbym żeby mi to chodziło tak jak na końcu tego filmu:
https://www.youtube.com/watch?v=qC7hrYJVvD8
Ciągle mam nadzieję, że znajdę jakąś wyspę stabilności.


--
Mirek

Wed Feb 11, 2026 10:22 am   

W dniu 10.02.2026 o 21:32, Mirek pisze:

innej części wątku? zlokalizowałeś już powód tych zakłóceń odczytu enkodera?


--
Janusz

Wed Feb 11, 2026 10:34 am   

W dniu 10.02.2026 o 21:32, Mirek pisze:

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;

}

--
Janusz