Jak zamontować enkoder do EQ3-2?

[apolkowski]

Ciekawe jaka musiałaby być nieosiowość koła zębatego żeby dać taki błąd.

[Behlur_Olderys]

Mały update: implementacja najprostszego, proporcjonalnego kontrolera z progiem 1 kroku enkodera niweluje błąd okresowy do poziomu +/-1 krok (+/- 6" na osi RA, gdyby przełożenie było przezroczyste) 

 

Wykres mówi sam za siebie - żółty wykres z włączonym kontrolerem, zielony - bez. Oś X to sekundy. Oś Y to hipotetyczne sekundy łuku na osi RA.

 

 

Zostało mi sprawdzić choćby na Stellarium, problem w tym, że jeden piksel na ekranie widziany z 3m to ok. 17". Więc tego typu błędy będą na granicy zauważalności przy teście robionym w pokoju  Liczę na to, że aliasing wykorzystany przy wyświetlaniu gwiazd pozwoli na pomiary subpixelowe, jak w guiderze...

 

Ale to już nie dziś

 

 

Edytowane 11 Listopada 2020 przez Behlur_Olderys

[Behlur_Olderys]

Mały update: (proszę bez złotych łopat, po prostu wolno mi idzie ta zabawa )

 

W poprzednim poście pokazałem wykres błędu enkodera. Daje się go zminimalizować do poziomu +/-1 podziałka. W międzyczasie wymieniłem enkoder z inkrementalnego na absolutny z rozdzielczością 4096, a więc ok.2.5"/podziałka.

 

Wymieniłem też cały soft i kontroler montażu, oraz silniki

 

Za to udało mi się zmierzyć charakterystykę PE na gwiazdach - przy użyciu obiektywu Tair3s 300mm i kamerki QHY462C.

 

 

Tak to wygląda: niebieskie to błąd Ra, czerwone to Dec.

Miałem dość dobre ustawienie na biegun, jak na balkon bez widoku na północ  więc obyło się bez odejmowania regresji liniowej.

Widać, że w DEC mamy jakiś mechaniczny problem, może ugięcie, może coś innego ale taki dryf to żaden problem w porównaniu do sinusoidy z RA. 

 

Zastosowanie feedbacku na enkoderze nie wyeliminowało oczywiście PE ślimaka, ale sprowadziło go do bardzo ładnej, gładkiej i przede wszystkim powtarzalnej formy.

 

Wystarczy teraz tylko trochę matematyki i programowania żeby do takiej charakterystyki (funkcji kąta na niebie do kąta na ślimaku) wypracować funkcję odwrotną, i użyć jej do wygenerowania sterowania: tablicy prędkości prowadzenia w zależności od wskazania enkodera. 

 

...

 

Zobaczymy, czy się uda, może za pół roku znowu się dowiemy

 

 

 

Na marginesie: dawno nie czułem takiego technicznego zwycięstwa, jak w momencie gdy arkusz wyrenderował mi ten wykres  Nie spodziewałem się że będzie aż tak regularny! Pewnie przy odrobinie wyobraźni można by zgadnąć kształt ślimaka

 

[lkosz]

Za 8 miesięcy to raczej aluminiowa łyżeczka, a nie łopada

 

Będziesz pisać do tego jakiś algorytm PID, czy jakoś inaczej to rozwiążesz?

[Behlur_Olderys]

25 minut temu, lkosz napisał:

Będziesz pisać do tego jakiś algorytm PID, czy jakoś inaczej to rozwiążesz?

 

Niepotrzebne jest PID. 
Silniki mają przełożenie jakieś 0.6"/mikrokrok. Enkoder ma rozdzielczość 2.5". Czyli właściwie pomiędzy odczytem 1234 a 1235 na enkoderze maksymalnie błąd może być rzędu 4 kroków steppera. W praktyce to są ułamki kroku, gdy z tych ułamków zbierze się cały krok to robię korektę o 1 krok do przodu lub do tyłu.

 

Czyli sam feedback enkoder-krokowiec to "binarne P" w którym maksymalne sterowanie to 1 krok, a znak błędu decyduje o tym, czy do przodu, czy do tyłu

 

Praktycznie:

Doba gwiazdowa trwa 86164s.

Jeden obrót ślimaka to 662.8s (130 zębów w EQ3-2).

Jedna podziałka enkodera to teoretycznie^* 162ms (4096 podziałek)

 

Jeśli w danym momencie upłynęło 252.048s, to enkoder powinien przekręcić się już o 1555 podziałek.

Sprawdzam teraz odczyt enkodera: jak jest mniej niż 1555 to robię krok do przodu, a jak jest więcej niż 1555 to krok do tyłu.

 

 

 

 

Natomiast jeśli chodzi o eliminację sinusa w ogóle to tutaj wracamy do gwiazdki ^* ze słowa "teoretycznie".

Skoro sterowanie z teoretycznie wyliczoną prędkością 1 podziałka enkodera / 162ms daje nam taki piękny sinus, to trzeba zmodyfikować ten czas (162ms).

Jeśli na wykresie PE mamy tendencję wzrostową (czyli kąt rośnie szybciej, niż niebo się obraca) to należy ten czas wydłużyć.

Jeśli na wykresie mamy spadek (kąt rośnie za wolno) to trzeba ten czas skrócić.

Sumarycznie jednak wciąż wszystkie 4096 interwałów powinno dodawać się do 662.8s (4096*162ms).

 

Do zrobienia pozostaje mi wyliczenie tych interwałów i zaimplementowanie LUT (liczba ms/podziałka dla danego wskazania enkodera) zamiast na sztywno wbitego 162ms do procedury robiącej feedback.

Jestem dobrej myśli

 

Właściwie powinno to być pomnożenie 162ms przez znormalizowane wagi zależne od pochodnej dfi/dalfa, gdzie fi to kąt na niebie, a alfa to kąt na ślimaku. Jak będę miał jakiś konkretny wzór to się podzielę, ale pewnie sprowadzi się to do empirycznego wyznaczenia jakiegoś współczynnika

[lkosz]

Noo ciekaw jestem wyników. Niedokładność prowadzenia samego montażu też będziesz później korygować, czy już wstawisz sprzężenie zwrotne na guidingu?

[Behlur_Olderys]

13 minut temu, lkosz napisał:

Niedokładność prowadzenia samego montażu też będziesz później korygować

Tzn?

 

Właśnie to, co teraz mi zostało do zrobienia to niedokładność prowadzenia samego montażu  Czy może masz coś innego na myśli? 

 

Przypominam:

Wykres, który zaprezentowałem (niebieski sinus) to dryf gwiazd w osi RA zmierzony realnie wczoraj na kawałku gwiazdozbioru Herkulesa w przeciągu ok. godziny 

Po zaimplementowaniu funkcji odwrotnej (czyli ten LUT pełniący rolę PEC) w kontrolerze będę oczekiwał, że wykres dryfu gwiazd będzie w dużej mierze linią prostą, zależną tylko od dokładności ustawienia na biegun.

 

Co to więcej do korygowania?

 

Wiadomo - mrzonki teoretyka, i w praktyce może i trzeba będzie mieć ten guider. Zwłaszcza, że ustawienie na biegun na moim balkonie to droga przez mękę. Jeszcze mi się marzy większa skala...  Ale to zupełnie inna bajka.

 

[lkosz]

Mogłem jednak poprzednią wersję pytania dać bardziej zrozumiałe to było... Tak to widzę: jest napęd ze sprzężeniem zwrotnym na ślimaku, czyli korygujesz błędy przekładni, od sterownika do wału. Dodatkowo będzie korekcja wał - niebo wynikająca z niebieskiego wykresu, widzę to już jako ekstrapolację z założeniem że będzie się wyłącznie powtarzać. EQ3 ma tam jednak jakieś luzy, ustawienie na biegun bywa niedokładne, obiekty na niskich elewacjach mogą uciekać, wówczas guiding wykaże poprawki wynikłe nie tyle z błędu okresowego, tylko różne losowe odchylenia. Czyli rozumiem, że zakładasz z góry pewne odchyłki w czasie, a nie korygujesz aż do całkowitego zniwelowania błędu?

Edytowane 30 Lipca 2021 przez lkosz

[Behlur_Olderys]

9 minut temu, lkosz napisał:

Czyli rozumiem, że zakładasz z góry pewne odchyłki w czasie, a nie korygujesz aż do całkowitego zniwelowania błędu?

 

No tak, oczywiście. Po pierwsze błąd na pewno do zera się nie da wyczyścić: nawet w idealnym przypadku mam przecież skończoną dokładność enkodera, a więc lepiej niż te +/-2.5" jest fizycznie niewykonalne.

 

Po drugie tak jak mówisz: błąd ustawienia na Polaris, dyspersja, drgania, wiatr, źle wyważony setup, ugięcia itp. zostają wciąż w grze. Oczywiście nie wszystko da się guidingiem załatwić, ale nie zmienia to faktu, że jakieś błędy zawsze są

 

Tak czy inaczej zmniejszenie "nominalnego" PE z +/-30" do powiedzmy +/-5" bez użycia guidera to byłby moim zdaniem bardzo dobry wynik dla EQ3-2... I to jest mój cel.

 

 

 

[Behlur_Olderys]

Odświeżam temat:

Sukces!

 

 

...no może taki połowniczy sukces, ale ogólnie udało się mi zrobić to, co chciałem

 

Zacznę od wykresów, które wszystko opowiadają:

 

 

Przed włączeniem "ślepej" korekcji na enkoderze:


Po instalacji enkodera i załączeniu korekcji "na ślepo":

 

 

 

 

I wreszcie po - testowej i nieudolnej, ale jednak - korekcji prędkości ślimaka względem tego, co zarejestrowano wcześniej:

(RMS ok. 4")

 

Wiem, są piki, są szarpnięcia, ale wydaje się, że z takim PE można powoli się zaprzyjaźnić i jechać naprawdę długie klatki np. Samyangiem 135mm. No i ustawianie na biegun jest *dużo* łatwiejsze metodą dryfu. Ogólnie uważam, że jest miejsce do poprawy i będę chciał popracować nad adaptatywną wersją tego algorytmu - tj. po każdej sesji update'ować program sterujący tak, żeby zawsze podstawą do korekcji były ostatnie pomiary. Ale na razie jest dobrze

 

 

 

 

Matematyka polega na wyznaczeniu funkcji zmierzonej prędkości nieba względem realnego odczytu ślimaka na enkoderze.

Ta funkcja mówi, o ile ruszy się naprawdę montaż przy przesunięciu ślimaka o stały kąt na enkoderze.

Idealnie powinno to być 1296000"/(130*4096) = ok. 2.434. 

bo 130 zębów ma ślimak, 4096 odczytów daje enkoder, a cały obrót to 1296000 sekund łuku.

Zasadniczo policzenie tej funkcji sprowadza się do policzenia pochodnej z bezwzględnej, zmierzonej pozycji montażu po "tikach" enkodera. Jest to mechanicznie mówiąc model przekroju ślimaka - jego niesymetryczności. 

 

Realnie jest to funkcja zmieniająca się mniej więcej tak:

 

Niezbyt duże wahania a już psują

 

 

Jest to w uproszczeniu pochodna tego wykresu - czyli błędu prowadzenia względem odczytu enkodera:

 

 

Po obliczeniu realnej prędkości ślimaka w zależności od kąta wystarczyło wyliczyć interwały, w jakich należy oczekiwać kolejnych "tików" enkodera. W przypadku idealnym te interwały są zawsze równe, ale po korekcji są zmodyfikowane, żeby pozycja "na niebie" i pozycja "wg ślimaka" się pokryły. Oczywiście służę wyjaśnieniami, gdyby ktoś był bardziej zainteresowany.

 

Pozdrawiam

 

 

[kuba_527]

W dniu 30.07.2021 o 13:11, Behlur_Olderys napisał:

udało mi się zmierzyć charakterystykę PE na gwiazdach - przy użyciu obiektywu Tair3s 300mm i kamerki QHY462C.

Wykorzystałeś do tego soft do guide (PHD) czy jakiś własny software? Szukam czegoś do pomiaru falowania powietrza/seeingu przy większych fps (logowanie jak gwiazdka skacze w kadrze i jakaś statystyka).

Trzymam kciuki za dalsze sukcesy
 

[Behlur_Olderys]

2 godziny temu, kuba_527 napisał:

Wykorzystałeś do tego soft do guide (PHD) czy jakiś własny software? Szukam czegoś do pomiaru falowania powietrza/seeingu przy większych fps (logowanie jak gwiazdka skacze w kadrze i jakaś statystyka).

Trzymam kciuki za dalsze sukcesy
 

Użyłem do tego DSS:

Nagrywam normalnie Sharpcapem fotki co 6s.

Wkładam to do DSS, który alignuje zdjęcia i oblicza ich przesunięcia z subpikselową precyzją.

A potem mielę wyniki skrypcikiem w pythonie.

 

 

W przypadku jednej gwiazdki w polu widzenia zrobiłbym tak:

okroił FOV tylko do tej jednej, mierzonej gwiazdki

zamienił zdjęcie na mono (jeśli jeszcze nie jest)

obliczył środek masy (czyli średnia ważona kawałka w którym jest gwiazda przy czym wartości uśredniane to połoźenie pixela a waga to jego wartość)

Taki środek masy to już bardzo fajna, precyzyjna metryka.

Kiedyś pisałem do tego soft, python + numpy robią cuda.

 

Pozdrawiam