On Mon, 26 Jan 2026 21:02:21 +0100, Mirek wrote:
> W dniu 26.01.2026 o 06:22, J.F pisze:
>> Tu cos o większej bezwładności
>> https://www.youtube.com/watch?v=fusr9eTceEo
>>
>> Widać, że dopiero "anti windup" uzdrawia sytuację, ale to może być
>> częściowo fałszywe wrażenie.
>
> Tak, robiłem też anti windup albo integral clamping, ale mi się to
> zachowuje dokładnie tak jak pod koniec filmiku. Gość twierdzi, że
> problemem jest zbyt rzadki okres odświeżania i to by się zgadzało z

Tylko nie wiem, czy zauważasz, że ładne działanie z 2:05 to on ma przy
Kp=500, a kolejne oscylacje są przy Kp=10tys, to jest na mój gust
spory przeskok parametrów. Na oko to jest tam dużo miejsca na
dostrojenie.

No a to ostatnie pokazuje, że częstotliwość przeliczania wewnętrzego
też istotna.

> moimi podejrzeniami. Ja tak sobie kombinowałem, że ten czas między
> pomiarami musi być mniejszy niż silnik jest w stanie przesunąć się o
> jeden krok przy minimalnej, stabilnej prędkości.

Hm, czy to wystarczy?
Bo będzie prędkośc silnika większa, przesunie się np o 10 kroków w
cyklu, z -5 zrobi się +5, i znów prędkość nie będzie minimalna.
No dobra - cykl przetwarzania 200Hz, 5ms, to nie wiem, czy silnik da
radę tak szybko zmienić kierunek ruchu.

No i .. jak częstotliwość duża, to różniczkowanie trzeba przemyśleć,
bo różnica kolejnych odczytów, to będzie raczej typu 0, 1, 0, 0, 0 0,
0, 1, 0, 0, 0, 0, 0, 1.

> Niestety w Pythonie nie
> zrobię tego szybciej, bo o zgrozo najwięcej czasu zajmuje odczytanie
> tego rejestru z PIO. Co ciekawe, od wersji z 22 roku do obecnej ten czas
> zmalał prawie dwukrotnie, ale to wciąż za mało żeby uzyskać tak jak u
> niego 800Hz.

A co to za sprzęt? Bo pod unixem sprzęt przecież chroniony przed
uytkownikiem.

> Fajnie by było przerobić to na C, ale nie wiem czy mi starczy motywacji.

Wydajnio PIO może pozostać kiepska.

A enkoder jak obsługujesz? Bo tam łatwo przekroczyć możliwosci wolneog
programu

J.

do góry

W dniu 27.01.2026 o 13:16, J.F pisze:

> No i .. jak częstotliwość duża, to różniczkowanie trzeba przemyśleć,
> bo różnica kolejnych odczytów, to będzie raczej typu 0, 1, 0, 0, 0 0,
> 0, 1, 0, 0, 0, 0, 0, 1.

No więc jak to jest realizowane? Magia?

> A co to za sprzęt? Bo pod unixem sprzęt przecież chroniony przed
> uytkownikiem.

Nie ma tam żadnego Unixa.
Raspberry Pi Pico. Przecież napisałem na początku.

>
>> Fajnie by było przerobić to na C, ale nie wiem czy mi starczy motywacji.
>
> Wydajnio PIO może pozostać kiepska.

Nie ma szans. Pisałem, że większość czasu zajmuje przeczytanie rejestru
z wartością enkodera. To jest po prostu skopane w microPythonie. Reszta
obliczeń zajmuje tyle co nic.



>
> A enkoder jak obsługujesz? Bo tam łatwo przekroczyć możliwosci wolneog
> programu
>

Pisałem, że program w asemblerze w PIO. On działa sobie zupełnie
niezależnie od głównego rdzenia procesora i nie gubi żadnych kroków i
nie ma żadnego wpływu na program w Pythonie.

Ciężko się z tobą pisze, ile razy można pisać to co było już napisane.
Może nie ciąć w ogóle wypowiedzi? Będziesz czytał całość?

--
Mirek

do góry

W dniu 27.01.2026 o 13:16, J.F pisze:

> Tylko nie wiem, czy zauważasz, że ładne działanie z 2:05 to on ma przy
> Kp=500, a kolejne oscylacje są przy Kp=10tys, to jest na mój gust
> spory przeskok parametrów. Na oko to jest tam dużo miejsca na
> dostrojenie.
>

No właśnie nie ma. Przy Kp=10tyś powinno być przetłumienie, czyli
powinien "hamować" o wiele za wcześnie i wolniutko dochodzić prawie do
celu. Ale nie da się. Masz niedotłumiony, czyli przerzut jest
nieakceptowalny, zwiększasz... zmniejsza się przerzut, ale nadal jest,
zwiększasz dalej i zanim zniknie przerzut pojawiają się te drgania. To,
że w miarę to wygląda przy 2:05 to jest tylko złudzenie. Gdyby było
dobrze to by nie szukał więcej. U mnie też to tak wygląda niekiedy, ale
jak zwiększę dystans to wychodzi znów przerzut. Przy dużo mniejszym
wzmocnieniu da się wytłumić, ale znów błąd ustawiania jest ogromny.


--
Mirek

do góry

On Tue, 27 Jan 2026 20:28:49 +0100, Mirek wrote:
> W dniu 27.01.2026 o 13:16, J.F pisze:
>> Tylko nie wiem, czy zauważasz, że ładne działanie z 2:05 to on ma przy
>> Kp=500, a kolejne oscylacje są przy Kp=10tys, to jest na mój gust
>> spory przeskok parametrów. Na oko to jest tam dużo miejsca na
>> dostrojenie.
>>
> No właśnie nie ma. Przy Kp=10tyś powinno być przetłumienie, czyli
> powinien "hamować" o wiele za wcześnie i wolniutko dochodzić prawie do
> celu. Ale nie da się.

Przy wysokim Kp układ się wzbudza i oscyluje - takie jest ogólne prawo
automatyki :-)

I widziałes reguły Z-N - doprowadź układ do oscylacji w trybie P,
po czym zmniejsz z Kp do 0.6 wartości krytycznej.

Trudno powiedzieć, czy tu Kp=10k jest wartością krytyczną, czy o wiele
za dużo.
Niby wystarczyło zwiększyć częstotliwość obliczen, i przestało
oscylować, ale może wprowadziło to znacznie więcej zmian, niż się
wydaje. No i oscylacje mierzymy tylko z członem P, bez ID.
A tu były włączone.

> Masz niedotłumiony, czyli przerzut jest
> nieakceptowalny, zwiększasz... zmniejsza się przerzut, ale nadal jest,
> zwiększasz dalej i zanim zniknie przerzut pojawiają się te drgania. To,
> że w miarę to wygląda przy 2:05 to jest tylko złudzenie. Gdyby było
> dobrze to by nie szukał więcej. U mnie też to tak wygląda niekiedy, ale
> jak zwiększę dystans to wychodzi znów przerzut. Przy dużo mniejszym
> wzmocnieniu da się wytłumić, ale znów błąd ustawiania jest ogromny.

J.

do góry

On Tue, 27 Jan 2026 19:54:52 +0100, Mirek wrote:
> W dniu 27.01.2026 o 13:16, J.F pisze:
>> No i .. jak częstotliwość duża, to różniczkowanie trzeba przemyśleć,
>> bo różnica kolejnych odczytów, to będzie raczej typu 0, 1, 0, 0, 0 0,
>> 0, 1, 0, 0, 0, 0, 0, 1.
> No więc jak to jest realizowane? Magia?

Trzeba trochę popracować nad programem.
Zsumować z dłuższego okresu, nałożyć jakiś filtr uśredniający ...

>> A co to za sprzęt? Bo pod unixem sprzęt przecież chroniony przed
>> uytkownikiem.
>
> Nie ma tam żadnego Unixa.
> Raspberry Pi Pico. Przecież napisałem na początku.

OK.

>>> Fajnie by było przerobić to na C, ale nie wiem czy mi starczy motywacji.
>>
>> Wydajnio PIO może pozostać kiepska.
>
> Nie ma szans. Pisałem, że większość czasu zajmuje przeczytanie rejestru
> z wartością enkodera. To jest po prostu skopane w microPythonie. Reszta
> obliczeń zajmuje tyle co nic.

Jeśli to jakiś rejestr uC, to dziwne, że sobie nie poradzili z szybkim
czytaniem.
No i czy Pico nie jest ogólnie jakiś powolny, biorąc pod uwagę, że
program jest pamięci szeregowej ?

>> A enkoder jak obsługujesz? Bo tam łatwo przekroczyć możliwosci wolneog
>> programu
>>
> Pisałem, że program w asemblerze w PIO. On działa sobie zupełnie
> niezależnie od głównego rdzenia procesora i nie gubi żadnych kroków i
> nie ma żadnego wpływu na program w Pythonie.

> Ciężko się z tobą pisze, ile razy można pisać to co było już napisane.
> Może nie ciąć w ogóle wypowiedzi? Będziesz czytał całość?

Przegapiłem "Pico", a wtedy PIO niewiele mówi.

J.

do góry

W dniu 27.01.2026 o 23:02, J.F pisze:

> Przy wysokim Kp układ się wzbudza i oscyluje - takie jest ogólne prawo
> automatyki :-)
Zgadza się, gość zwiększył kp i zapewne miał przerzut i oscylacje i
zaczął zwiększać kd żeby wytłumić i zaczęły się te drgania. Zupełnie tak
jak u mnie.

Ja już przeskoczyłem i pisałem o kp a myślałem o kd.

Ale tu znalazłem ciekawy przykład:
https://youtu.be/K4ZRbz28peg
Czyli gość to robi zdecydowanie szybciej i coś z tego wychodzi.
Jest nawet prawie cały kod widoczny - będzie się czym podpierać.
Potem ma jeszcze drugi film z większym silnikiem.


--
Mirek

do góry

W dniu 26.01.2026 o 20:38, J.F pisze:
> On Mon, 26 Jan 2026 14:24:57 +0100, Janusz wrote:
>> W dniu 26.01.2026 o 12:58, J.F pisze:
>>> On Mon, 26 Jan 2026 11:19:49 +0100, Janusz wrote:
>>>> W dniu 26.01.2026 o 06:22, J.F pisze:
>>>>> On Sun, 25 Jan 2026 22:28:26 +0100, Janusz wrote:
>>>>>> W dniu 24.01.2026 o 15:14, Mirek pisze:
>>>
>>>>>> Nie, tam nie ma pid-a, tam sterowanie silnika musi mieć odpowiednią
>>>>>
>>>>> Napisane, że ma.
>>>> Może byc pseudo-pid, czyli niepełny, zauważ że przy pojedynczym ruchu
>>>> niepowtarzalnym pid nie ma sensu, działa dopiero przy powtarzających się
>>>> ruchach.
>>>
>>> Nie bardzo rozumiem.
>> Niżej masz wyjaśnione.
>>
>>>
>>>>>> A pid-a stosuje się do ciągłego sterowania np termostat czy obroty silnika.
>>>>>
>>>>> Tu cos o większej bezwładności
>>>>> https://www.youtube.com/watch?v=fusr9eTceEo
>>>>>
>>>>> Widać, że dopiero "anti windup" uzdrawia sytuację, ale to może być
>>>>> częściowo fałszywe wrażenie.
>>>> Widać że pid w takich zastosowaniach jest bez sensu. Są wersje
>>>> 'wyprzedzające' i one by tu zadziałały, ale zwykły nie, bo on działa na
>>>> podstawie tego co było i to musi jeszcze być ileś iteracji żeby
>>>> odpowiednio 'nazbierał' wartości korekcyjnych.
>>>> Kto się pid-em nie bawił to tego nie wie.
>>>
>>> Nie piszesz o jakiś bardzo nowoczesnych regulatorach?
>> W nowoczesnych to guzik pooglądasz bo wszystko robi procek.
>> Widzisz tylko efekt końcowy, w tych starszych analogowych można było
>> zobaczyć jak to jest zrobione.
>>
>>
>>> Bo taki zwykły, analogowy może nawet, to co ma "nazbierać"?
>> No ale kiedy? podczas jednego skoku i to jeszcze za każdym razem innego?
>> czy też w trakcie skoku jeżeli jest podzielony na drobne kroczki i każdy
>> analizowany z osobna?
>
> Ale regulator PID nic nie "analizuje",
Się czepiasz :) analizuje czy zbiera błędy z poprzednich kroków.

po prostu realizuje funkcje P,
> I, i D, zgodnie z nastawami. Chyba, że piszesz o jakims trybie
> automatycznego strojenia.
To są te wyprzedzające.


>
> To co taki zwykły regulator "zbiera", to jest wartość całki w członie
> I.
No nie, zobacz w program, każdy człon ma swój rejestr w którym są
najczęściej sumowane odchyłki. Potem te rejestry pomnożone przez
współczynniki wzmocnienia każdego członu są sumowane i suma po
normalizacji stanowi wynik pid-a.
Więc nie można mówić tylko o jednej całce.


>
>> Właśnie o czymś w miarę podobnym sugerowałem autorowi, wpierw duży
>> krok-rampa a potem coraz mniejsze kroczki w ramach rampy, wtedy
>> wystarczy zwykły proporcjonalny sterownik.
>
> Proporcjonalny sterownik ma tę wadę, że na koncu prawie zawsze będzie
> błąd.
Ale w każdym kroku może go korygować, a że kroki coraz mniejsze to i
korekcja
dąży do 0.

--
Janusz

do góry

On Wed, 28 Jan 2026 16:45:11 +0100, Janusz wrote:
> W dniu 26.01.2026 o 20:38, J.F pisze:
>> On Mon, 26 Jan 2026 14:24:57 +0100, Janusz wrote:
>>> W dniu 26.01.2026 o 12:58, J.F pisze:
>>>> On Mon, 26 Jan 2026 11:19:49 +0100, Janusz wrote:
>>>>> W dniu 26.01.2026 o 06:22, J.F pisze:
>>>>>> On Sun, 25 Jan 2026 22:28:26 +0100, Janusz wrote:
>>>>>>> W dniu 24.01.2026 o 15:14, Mirek pisze:
>>>>
>>>>>>> A pid-a stosuje się do ciągłego sterowania np termostat czy obroty silnika.
>>>>>>
>>>>>> Tu cos o większej bezwładności
>>>>>> https://www.youtube.com/watch?v=fusr9eTceEo
>>>>>>
>>>>>> Widać, że dopiero "anti windup" uzdrawia sytuację, ale to może być
>>>>>> częściowo fałszywe wrażenie.
>>>>> Widać że pid w takich zastosowaniach jest bez sensu. Są wersje
>>>>> 'wyprzedzające' i one by tu zadziałały, ale zwykły nie, bo on działa na
>>>>> podstawie tego co było i to musi jeszcze być ileś iteracji żeby
>>>>> odpowiednio 'nazbierał' wartości korekcyjnych.
>>>>> Kto się pid-em nie bawił to tego nie wie.
>>>>
>>>> Nie piszesz o jakiś bardzo nowoczesnych regulatorach?
>>> W nowoczesnych to guzik pooglądasz bo wszystko robi procek.
>>> Widzisz tylko efekt końcowy, w tych starszych analogowych można było
>>> zobaczyć jak to jest zrobione.
>>>
>>>
>>>> Bo taki zwykły, analogowy może nawet, to co ma "nazbierać"?
>>> No ale kiedy? podczas jednego skoku i to jeszcze za każdym razem innego?
>>> czy też w trakcie skoku jeżeli jest podzielony na drobne kroczki i każdy
>>> analizowany z osobna?
>>
>> Ale regulator PID nic nie "analizuje",
> Się czepiasz :) analizuje czy zbiera błędy z poprzednich kroków.
>
> po prostu realizuje funkcje P,
>> I, i D, zgodnie z nastawami. Chyba, że piszesz o jakims trybie
>> automatycznego strojenia.
> To są te wyprzedzające.

na razie piszę tylko o automatycznym strojeniu - takie też są.

>> To co taki zwykły regulator "zbiera", to jest wartość całki w członie
>> I.
> No nie, zobacz w program, każdy człon ma swój rejestr w którym są
> najczęściej sumowane odchyłki. Potem te rejestry pomnożone przez
> współczynniki wzmocnienia każdego członu są sumowane i suma po
> normalizacji stanowi wynik pid-a.
> Więc nie można mówić tylko o jednej całce.

Bo tak im wygodniej przeliczać parametry?


To masz tu prosty przykładowy
https://github.com/gastmaier/micropython-simple-pid/
blob/master/simple_pid/PID.py


error = self.setpoint - input_
self._proportional = self.Kp * error
#to nie wymaga żadnej historii

d_input = input_ - (self._last_input if (self._last_input is not None)
else input_)

w skrócie
d_input = input_ - self._last_input

self._derivative = -(self.Kd / self.unit) * d_input / dt
# to wymaga poprzedniej wartośći.

self._integral += (self.Ki * self.unit) * error * dt
self._integral = _clamp(self._integral, self.output_limits) # Avoid
integral windup

#a to istotnie "zbiera" wartosć całki z poprzednich różnic.


output = self._proportional + self._integral + self._derivative

No chyba, że powyzsze sumowanie nazwiesz "zbieraniem".


>>> Właśnie o czymś w miarę podobnym sugerowałem autorowi, wpierw duży
>>> krok-rampa a potem coraz mniejsze kroczki w ramach rampy, wtedy
>>> wystarczy zwykły proporcjonalny sterownik.
>>
>> Proporcjonalny sterownik ma tę wadę, że na koncu prawie zawsze będzie
>> błąd.
> Ale w każdym kroku może go korygować, a że kroki coraz mniejsze to i
> korekcja dąży do 0.

Ale:
-kto powiedział, że całość wykona ten ostatni mały krok?
wyjscie regulatora P może być za słabe, aby tarcie pokonać

-a co będzie, jak będzie jakies stałe obciążenie? Np winda z
pasazerami? Trzeba podać jakies prąd/napięcie na silnik, aby winda
stała, a regulator P bedzie miał niezerowe wyjscie, o ile błąd
jest niezerowy.

Po to jest człon I.

J.

do góry

W dniu 27.01.2026 o 23:21, J.F pisze:

> Trzeba trochę popracować nad programem.
> Zsumować z dłuższego okresu, nałożyć jakiś filtr uśredniający ...
>
O jakim uśrednianiu myślisz?
Tutaj gościu robi jakiś filtr dolnoprzepustowy ale nie do końca kumam po
co i co on ma robić.
https://youtu.be/FJwgDaSsob8
Przepisałem sobie ten filtr do siebie i zacząłem próbować z filtrem i
bez. W zależności od ustawień coś tam niby poprawiał i zmniejszało się
to szarpanie, aż w końcu doszedłem do ustawień, że ustawia się za każdym
razem dokładnie na pozycję, po czym wyłączyłem filtr i szczęka mi
opadła, bo nic się nie zmieniło ;>

Czyli muszę odszczekać: da się ostawić z dokładnością do kroku nawet jak
odświeżanie nie jest zbyt szybkie.
Kp wyszło faktycznie gdzieś w okolicach 0,6 krytycznego, bliżej 0,8. Kd
też większe niż wcześniej dawałem, ki spore, a wcześniej nie dawałem
wcale bo nie mogłem ustabilizować. Teraz efekt jest taki, że ustawia się
co do kroku za każdym razem, ale ostatni krok, dwa mu zajmuje tak ze
sekundę, dwie od pierwszego zatrzymania się silnika. Nie jest do końca
idealnie, bo w zależności od tego czy np. zmienię z 0 na 1000 to ruszy
raz, nie dociągnie tak zatrzyma się na 998 i po sekundzie przejedzie na
999 i 1000. Jak puszczę np, od 0 do 80000 to przeskoczy tak na 80015 i
sekundę, dwie zajmie mu wrócić na 80000. Jeżeli pozycja docelowa
wypadnie pomiędzy zaskokami silnika to zanim ustawi wykona kilka wahań w
zakresie 1-2 kroków. Widać też niesymetrię (silnika?) bo przy dalszych
jazdach w jedną stronę przerzut jest większy a w drugą mniejszy.


--
Mirek

do góry

On Wed, 28 Jan 2026 20:06:10 +0100, Mirek wrote:
> W dniu 27.01.2026 o 23:21, J.F pisze:
>> Trzeba trochę popracować nad programem.
>> Zsumować z dłuższego okresu, nałożyć jakiś filtr uśredniający ...
>>
> O jakim uśrednianiu myślisz?

Załózmy, że pozycja wirnika odczytana w kolejnych pętlach obiegu
regulatora jest

5 5 6 6 6 6 7 7 7 7 8 8 8 8 9 9 9 9 ...

czy to znaczy, że silnik sie kręci "skokami do przodu" ?

Niekoniecznie, może po prostu sie wolno kręci, lub regulator szybko
działa i ma dużo petli na sekunde.

jak policzysz z tego pochodną metodą "nowa wartośc - poprzednia
wartość", to wyjdzie
0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 ...

no i to może byc niezbyt prawdziwe.
A jak to regulator uwzględni, to istotnie wyjdą jakieś skoki.


Z drugiej strony - może ułatwic zatrzymanie po osiągnięciu pozycji,
bo zapewne spowalnia napęd po każdym "kroku enkodera".


> Tutaj gościu robi jakiś filtr dolnoprzepustowy ale nie do końca kumam po
> co i co on ma robić.
> https://youtu.be/FJwgDaSsob8

Z tego co mówi, to:
- różniczkowanie "wzmacnia" wysokie częstotliwości,
- on się boi wzbudzneania

> Przepisałem sobie ten filtr do siebie i zacząłem próbować z filtrem i
> bez. W zależności od ustawień coś tam niby poprawiał i zmniejszało się
> to szarpanie, aż w końcu doszedłem do ustawień, że ustawia się za każdym
> razem dokładnie na pozycję, po czym wyłączyłem filtr i szczęka mi
> opadła, bo nic się nie zmieniło ;>

Może nie jest potrzebny tak naprawde ... silnik dobrze filtruje :-)

> Czyli muszę odszczekać: da się ostawić z dokładnością do kroku nawet jak
> odświeżanie nie jest zbyt szybkie.

A to zależy.
Jakie mniej więcej masz tam parametry - ile kroków na obrót ma
enkoder, jak szybki jest silnik, jakiej prędkości wymagasz
tak jak na tym pierwszym filmie, że silnik wraca do położenia zadanego
w mniej niż ~30 ms ?

> Kp wyszło faktycznie gdzieś w okolicach 0,6 krytycznego, bliżej 0,8. Kd
> też większe niż wcześniej dawałem, ki spore, a wcześniej nie dawałem
> wcale bo nie mogłem ustabilizować. Teraz efekt jest taki, że ustawia się
> co do kroku za każdym razem, ale ostatni krok, dwa mu zajmuje tak ze
> sekundę, dwie od pierwszego zatrzymania się silnika. Nie jest do końca

Zwiększyć Ki ?

> idealnie, bo w zależności od tego czy np. zmienię z 0 na 1000 to ruszy
> raz, nie dociągnie tak zatrzyma się na 998 i po sekundzie przejedzie na
> 999 i 1000. Jak puszczę np, od 0 do 80000 to przeskoczy tak na 80015 i
> sekundę, dwie zajmie mu wrócić na 80000.

tu masz inny efekt - przez długi czas jest odchyłka, nawet duza, i
całka rosnie. potrzebujesz tego "anti-windup", albo - zadawać rosnące
pozycje, nie od razu 80k,

> Jeżeli pozycja docelowa
> wypadnie pomiędzy zaskokami silnika to zanim ustawi wykona kilka wahań w
> zakresie 1-2 kroków. Widać też niesymetrię (silnika?) bo przy dalszych
> jazdach w jedną stronę przerzut jest większy a w drugą mniejszy.

Albo niesymetria regulatora ... choć H-bridge powinieni być
symetryczny.

J.

do góry