Enkoder na osi RA - DIY

[Behlur_Olderys]

Cześć,

Jak być może niektórzy wiedzą, od jakiegoś czasu skupiam swoje siły na opracowaniu taniego i w miarę dokładnego enkodera inkrementalnego który mierzyłby błąd prowadzenia bezpośrednio na osi RA montażu.

Pozwala to całkowicie odciąć się od mechanicznych błędów wszystkich przekładni, i zostawia do korekcji co najwyżej jakieś ugięcia, refrakcję czy też dryf, czyli łagodne, gładkie i powolne funkcje czasu, które łatwo kompensować.

 

Konstrukcja opiera się o koło enkodera z drukarki sprzężonym z wałkiem osi RA. Takie koła mają zazwyczaj pomiędzy 900 a 1800 "tików" na obrót (cpr = count per rotation = zliczenia na obrót). Są to precyzyjne, promieniście ułożone czarne paski o gęstości najczęściej 180-300 lpi (lines per inch = linii na cal.)

 

Przykładowa ilustracja:

(ze strony https://forum.arduino.cc/t/printer-optical-encoder-for-steering-wheel/912041)

 

Na przykład 300lpi odpowiada parze pasków czarny-biały o szerokości 0,084mm. 

Koło którego używam jest dość spore, ma 1800cpr przy rozdzielczości 200lpi. Daje to 720" pomiędzy kolejnymi czarnymi paskami. 

 

Aby uzyskać zakładaną dokładność przynajmniej na poziomie 10", a więc mowa o rozdzielczości 120 000 punktów na obrót lub lepszej, należałoby interpolować odczyt przynajmniej 72x. Po nieudanych próbach z transformatą sin/cos -> tan wykorzystując zwykły optyczny komponent z drukarki zdecydowałem się na podejście "mikroskopowe". 

 

Na koło skierowana jest kamerka z obiektywem o ogniskowej kilku mm pozwalający przy niewielkiej odległości od matrycy uzyskać powiększenie w okolicach 3.5:1, zatem np. dla piksela 3,75um mamy z grubsza 1um na obiekcie. Daje to rozdzielczość około 140px na parę pasków, a więc ok. 6-5 sekund łuku na piksel.

Żeby dodatkowo polepszyć SNR pomiaru można zliczać wszystkie piksele paska wzdłuż osi pionowej, co teoretycznie powinno drastycznie poprawić dokładność, natomiast biorąc pod uwagę niedoskonałość optyki, układu, i różne inne przeszkody pojawiające się w tego typu powiększeniach można powiedzieć że operowalna rozdzielczość to ok. 1". Zatem wspaniale jak na domowej roboty enkoder.

 

Problem pojawia się w tym, że 1" łuku "trwa" na niebie 1/15s. To dosyć mało czasu na ściągnięcie obrazu z kamery i dokonanie wszystkich niezbędnych obliczeń, dlatego na razie zdecydowałem się na ograniczenie szybkości pomiarów do 1fps, co jest wygodne do testowania i rozwoju. W trakcie przygotowania mam dedykowany układ kamera-mikroprocesor który pozwoli zwiększyć tą prędkość do 10fps, ale o tym innym razem.

 

Na razie z braku spójnej dokumentacji fotograficznej skupię się na wstępnych wynikach.

Zależało mi na sprawdzeniu na ile w ogóle odczyty z enkodera mają przełożenie na realne błędy prowadzenia montażu.

 

Napisałem w tym celu odpowiedni soft który oblicza na bieżąco przesunięcie między klatkami, które schodzą z głównej kamery, jak i odczyty z enkodera. Porównanie tych dwóch wyników powinno dać odpowiedź na pytanie, czy w ogóle taki układ ma szansę działać.

 

Montaż działał bez żadnego nadzoru przez ok. 40min. Poniżej przedstawiam wyniki dopasowane do siebie liniowo. "error" to pomiar z enkodera, a "error RA" to pomiar przesunięcia gwiazdy.

 

 

Jak widać zgodność w zakresie wysokich częstotliwości jest bardzo dobra. Gorzej z trendem długoczasowym: nie wystarczy pojedyncza empiryczna wartość współczynnika nachylenia, trzeba będzie ją co jakiś czas poprawiać żeby wykresy się nie rozjeżdżały. I mam nadzieję że to pokażę w następnym odcinku

 

 

[szuu]

fajny przykład na to jak masowa dostępność danego uniwersalnego komponentu ("kamerka", "komputer") powoduje że mimo olbrzymiej nadmiarowości i "marnotrawstwa" taka konstrukcja może okazać się łatwiejsza a nawet tańsza od konstrukcji "rozsądnej technologicznie" ale specjalizowanej.

 

54 minuty temu, Behlur_Olderys napisał:

Problem pojawia się w tym, że 1" łuku "trwa" na niebie 1/15s. To dosyć mało czasu na ściągnięcie obrazu z kamery i dokonanie wszystkich niezbędnych obliczeń

 

a może nie czasu za mało tylko pikseli za dużo?

najbardziej prymitywny enkoder pobiera tylko 2 piksele, ty pobierasz N, optimum może zawierać się gdzieś pomiędzy tymi dwoma wartościami

[Behlur_Olderys]

@szuu

Jestem w trakcie przygotowania bardziej dedykowanego sprzętu: będzie to mikrokontroler ESP32 z kamerką + obudowa wydrukowana od @Krzysztof z Bagien (notabene poprzednią, czarną zawdzięczam @Gość na chwilę  ) Obraz o wymiarach 100x400 będzie pobierany mniej więcej 10 razy na sekundę, a algorytm zdąży policzyć przesunięcie zanim następna klatka zejdzie - całe szczęście są tam dwa rdzenie 280 MHz  Niestety mechanicznie i optycznie jest to delikatne do zgrania, ale hardware, algorytm i implementację na FreeRTOS już mam.

 

[MaciejW]

Świetny pomysł z kamerką, ciekawe czy zamiast obiektywu możnaby użyć diody laserowej z drugiej strony enkodera, aby cień pasków był rzucany na matryce, ale boję się o efekty dyfrakcyjne.

[calla]

Pytanie czy to w ogóle muszą być paski, czy randomowo rozłożone kropki nie byłyby wystarczające, z 100x400 px jest dość dużo danych do liczenia przesunięcia, o ile to nie jest zbyt wymagające obliczeniowo. Wtedy taki pasek (albo koło)  możnaby chyba w miarę łatwo samodzielnie sfabrykować

[Behlur_Olderys]

@calla

Pewnie tak, ale koło do enkodera z drukarki można kupić hurtowo za 5zł więc....

 

Można też samemu naświetlić w jakimś przybytku poligraficznym, bez problemu i całkiem dokładnie, ale kosztowo wychodzi drożej i więcej zachodu - been there, done that...

 

Poza tym paski są łatwe do ogarnięcia przy redukcji danych: progowanie i różniczkowanie po kierunku prostopadłym do pasków. Dodatkowo stała odległość kątowa między paskami pozwala na zgrubną kalibrację. Losowy wzór nie ma tych zalet.

 

@MaciejW mam nawet laser kupiony, taki z grubym promieniem, z aliex, ale chyba jednak nie będzie potrzebny. Obraz jest dość ostry w obiektywie, zwłaszcza w niebieskim świetle (fizyka!) - podświetlam tarczę LED-em od spodu.

[Krzysztof z Bagien]

[Piotr4d]

7 godzin temu, Behlur_Olderys napisał:

Gorzej z trendem długoczasowym: nie wystarczy pojedyncza empiryczna wartość współczynnika nachylenia...

 

7 godzin temu, Behlur_Olderys napisał:

i zostawia do korekcji co najwyżej jakieś ugięcia, refrakcję czy też dryf, czyli łagodne, gładkie i powolne funkcje czasu, które łatwo kompensować.

czyli klasyczny guiding i tak będzie potrzebny?

[Behlur_Olderys]

Jeszcze garść fotek z dotychczasowego setupu - obudowa od @Gość na chwilę. Zamiast porządnego wałka - szpilka M5, za długa ale już nie chciało mi się piłować. Do wału przymocowane sprzęgło od @Krzysztof z Bagien - musiałem usunąć lunetkę, ale i tak z niej nie korzystam na balkonie. Enkoder z jakiejś drukarki HP. Do tego "przyspawana" przedłużka 1.25", kamera T7C oraz najgorsze użycie Arduino: jako zasilacz do modułu diody LED RGB która (na niebiesko) oświetla mi od spodu enkoder. Całkowita fuszerka - z pozoru, a jednak jakie wyniki! Tym bardziej napawa nadzieją, że "porządny" setup - znacznie mniejszy, bardziej zwarty i elegancki - będzie "robił robotę"

 

 

 

11 minut temu, Piotr4d napisał:

czyli klasyczny guiding i tak będzie potrzebny?

 

Raczej nie - przynajmniej w moim wypadku wydaje się, że wystarczy np. co 1 klatkę sprawdzać przesunięcie kadru i skorygować. Dla mnie nieporuszone klatki 1-2 minutowe to i tak będzie powód do świętowania - mówimy o skali 0,91"/px. Tak czy inaczej zakładam brak fizycznego, dodatkowego zestawu guider + kamera, wystarczyć ma materiał z kamery głównej.

 

Notabene: bardzo liczę na to, że nieregularności wprowadza nieco sfatygowane i pokrzywione koło enkodera, oraz ogólnie mechaniczne niedoskonałości, ugięcia itp. - np. strasznie słabe mocowanie do montażu - to tylko kawałki blachy 1mm...

W nowej wersji koło enkodera to będzie nówka nieśmigana, a docelowo pewnie zamówię gdzieś porządne, sztywne kawałki aluminium do umocowania całości, poza tym "prawdziwy" wałek 10mm i odpowiednie łożyska + sprzęgło, mocowanie kamery będzie załatwione zupełnie inaczej, więc zakładam lepszą powtarzalność. Patrząc na wykres z pierwszego posta myślę, że 80% uzysk dla klatek 5-minutowych już teraz wydaje się całkiem realny. No, ale może niepotrzebnie się tak nakręcam, bo póki wszystko jest (jeszcze) na papierze to jestem optymistą, a przy testach na gwiazdach okaże się, jak bardzo to tylko moje pobożne życzenia  

 

[Semeno]

Trzymam kciuki...

Ja ze swoim jestem na czekaniu na nowy ślimak, jestem ciekaw jak wyjdzie.

Ale twój to inna bajka...

[Piotr4d]

15 minut temu, Behlur_Olderys napisał:

wystarczyć ma materiał z kamery głównej.

 

 

19 minut temu, Behlur_Olderys napisał:

wydaje się, że wystarczy np. co 1 klatkę sprawdzać przesunięcie kadru i skorygować

Czyli taki niby guiding (choć nazwa jest może nie adekwatna), bo korekty i tak jakieś będą, to czy błąd długookresowy z wykresy z pierwszego postu nie traci na znaczeniu przy klatkach do 2minut. 

[apolkowski]

Rozważałeś liniowy sensor CCD zamiast kamery?

[Behlur_Olderys]

1 godzinę temu, apolkowski napisał:

Rozważałeś liniowy sensor CCD zamiast kamery?

 

Rozważałem - ba! nawet miałem taki prototyp i go testowałem!

 

Miałem tylko linijkę 1x128 CDD o kiepskiej charakterystyce (duży szum).

 

Wyniki były bardzo niedokładne - może +/- 10" w jednym pomiarze, teraz teoretycznie mam możliwość zejść poniżej 1".

Kalibracja koszmarna, geometria układu musiała być bardzo dokładna, czuła na kąt nachylenia - a teraz wystarczy tak "na oko wszystko ustawić i gra

Algorytm bardzo skomplikowany: myślałem o nim po nocach, w pracy, rysowałem i liczyłem cały czas, a potem i tak nic się nie zgadzało i wychodziło 10 nowych niewiadomych, współczynników empirycznych itp...

 

...i koniec końców zarzuciłem temat. Ale to było dawno temu. Może teraz, bogatszy w doświadczenia, lepiej bym to zrobił, na dłuższej linijce, porządnie i elegancko... ale już mi się nie chce  Obraz z kamerki jest milion razy bardziej wymowny i wygodny.

 

EDITED:
Na poparcie moich słów - pojedyncza ekspozycja (bez debayera) T7C, 640x960

[MateuszW]

7 godzin temu, Behlur_Olderys napisał:

Notabene: bardzo liczę na to, że nieregularności wprowadza nieco sfatygowane i pokrzywione koło enkodera, oraz ogólnie mechaniczne niedoskonałości, ugięcia itp. - np. strasznie słabe mocowanie do montażu - to tylko kawałki blachy 1mm...

Po części na pewno tak, więc będzie lepiej, ale na pewno jest też drugi efekt - tolerancja wykonania tarczy enkodera plus jakieś błędy z geometrii obiektywu i obrazu. Gdyby z tarczy za kilka zł dało się zinterpolować idealnie pozycję np co do 1", to produkcja enkoderów po kilka tyś zł nie miałyby sensu  One różnią się nie tylko ilością prążków, ale przede wszystkim precyzją wykonania. Tak więc, żeby przekroczyć kolejny poziom dokładności, będziesz musiał zmierzyć charakterystykę swojego enkodera i uwzględnić ją w obliczeniach. Czyli coś jak PEC, ale nie dla przekładni, a układu pomiarowego. Taką charakterystykę zbierzesz albo guiderem (z ograniczeniem do seeingu plus wspomniane przez Ciebie "błędy" atmosfery i ugięć), albo używając wzorcowego enkodera - metoda najlepsza, ale jak wiadomo kosztowna - miałaby sens przy produkcji takich urządzeń  Można też pomyśleć o trzeciej metodzie - zrobić idealny napęd do enkodera, żeby zmierzyć obrót przy obrocie niezakłóconym błędami montażu. To oczywiście wymaga idealnej przekładni (czyli drogie), ale można też użyć sztuczek, jak bardzo długa dźwignia popychana na końcu, gdzie idealną przekładnię stanowi jej długość właśnie (ale tu z kolei nie da się zrobić całego obrotu - trzeba by było to zbierać kawałkami). Po zebraniu charakterystyki trzeba by też zapewnić, aby startować enkoder zawsze w ustalonej pozycji - bo charakterystyka będzie różna dla każdego zęba - ogólnie da się to ogarnąć jakimś zgrubnym czujnikiem "home".

 

Gorąco trzymam kciuki za jak najlepsze efekty  

[WielkiAtraktor]

6 godzin temu, MateuszW napisał:

Tak więc, żeby przekroczyć kolejny poziom dokładności, będziesz musiał zmierzyć charakterystykę swojego enkodera i uwzględnić ją w obliczeniach. Czyli coś jak PEC, ale nie dla przekładni, a układu pomiarowego. Taką charakterystykę zbierzesz albo guiderem (z ograniczeniem do seeingu plus wspomniane przez Ciebie "błędy" atmosfery i ugięć)

 

A jakby wycelować we w miarę odległą ścianę z cegieł (czy inny powtarzalny wzór)? Wtedy przynajmniej seeing i atmosfera odpadną. (Przy idealnym prowadzeniu wzór powinien przesuwać się jednostajnie w polu widzenia, pozostaje pomierzyć odchyłki).

Edytowane 13 Czerwca 2022 przez WielkiAtraktor

[zbuffer]

Ciekawe eksperymenty. Gratuluję zapału i trzymam kciuki!

 

Kilka rzeczy mnie zastanawia.

1. Używasz kamerki i nie wykorzystujesz kompletnie faktu, że obraz jest 2d. Naprawdę nie warto zainwestować trochę w wydruk/grawer sinusoidy/cosinusoidy na kole?

2. Planujesz tą kamerę z optyką skalibrować (używając np. klasycznej szachownicy)? Dystorsja Ci wprowadzi kolejne błędy.

3. Aby skalibrować ten enkoder musisz mieć inny sensor, który mierzy o rząd wielkości dokładniej.... to raczej będzie trudne.

 

Generalnie zastanawiam się czy sens ma używanie sensora, który sam w sobie będzie miał błąd okresowy, do korygowania innego błędu okresowego. 

Nie lepiej użyć prostego enkodera absolutnego na osi ślimaka i po prostu nagrać PEC'a w oparciu o guiding, i potem go precyzyjnie odtwarzać. Wystarczył by oczywiście nawet pojedynczy impuls ale z enkoderem absolutnym nie trzeba by tyle przewijać montażu na początku. Można by taki zewnętrzny PEC oprzeć o mikrokontroler i po USB połączyć z komputerem. Potem napisać driver, który będzie grał rolę guider'a - tzn. będzie odbierał pulsy, które mają iść do montażu i je modyfikował dodając PEC.

 

Ja osobiście będę się mierzył z enkoderem RA w niedalekiej przyszłości, bo kupiłem w tym celu używany enkoder sin/cos za 170 eur. 

Mam jednak zamiar zmienić całą elektronikę montażu na własny projekt oparty o FPGA, bo chcę mieć bezpośrednią kontrolę nad napędami i przy okazji dodać kilka gadżetów. Poza tym soft montażu jest generalnie kiepski i brakuje wielu rzeczy (iOptron ieq45).

Jak coś zacznę robić to na pewno stworzę wątek na forum, w celu utrzymania motywacji

 

 

[count.neverest]

A co z sensorem, który można znaleźć w telefonie? IMX682 czy IMX586 dałby ponad 4 krotnie wyższą rozdzielczość w stosunku do T7. 

[Behlur_Olderys]

11 godzin temu, MateuszW napisał:

Gdyby z tarczy za kilka zł dało się zinterpolować idealnie pozycję np co do 1", to produkcja enkoderów po kilka tyś zł nie miałyby sensu

Te tarcze są robione dla prostych enkoderów z maską i czteroma fotodiodami, i rzeczywiście, tym sposobem nie ma szans.

Ale dla moich potrzeb nie jest istotna w ogóle jakość wykonania tego koła, bowiem liczę jedynie przesunięcie - różnicę pomiędzy dwoma kolejnymi obrazami. Gotowe koło jest wygodne, ale właściwie mógłbym użyć - tak jak mówił @calla dowolnego, nawet randomowego wzoru, kosztem nieco bardziej skomplikowanych obliczeń. Ważne, żeby tarcza była sztywna, i tyle.

Jedyne co jest skrajnie istotne w tym momencie to skala odwzorowania (czynnik liniowo wpływający na jakość odczytu) oraz czysty tor optyczny - bez rys, kropek, brudów itp. Prawdopodobnie najlepiej byłoby jeszcze podzielić obraz przez flat, to dałoby się spokojnie zrobić. Skala odwzorowania będzie zależała od odległości tarcza - obiektyw - matryca i ew. ugięć, więc zależy od jakości mechanicznej układu.

 

 

 

2 godziny temu, zbuffer napisał:

1. Używasz kamerki i nie wykorzystujesz kompletnie faktu, że obraz jest 2d. Naprawdę nie warto zainwestować trochę w wydruk/grawer sinusoidy/cosinusoidy na kole?

 

Możesz rozwinąć myśl? Jak miałoby to wyglądać? Moim zdaniem wykorzystuję 2D, bo uśredniam przesunięcie po całej długości paska, co zwiększa dokładność.

 

2 godziny temu, zbuffer napisał:

2. Planujesz tą kamerę z optyką skalibrować (używając np. klasycznej szachownicy)? Dystorsja Ci wprowadzi kolejne błędy.

Nie planowałem. Zobaczę, jaką dokładność da się uzyskać bez tego, a potem, jeśli nie będę zadowolony, to będę szukał alternatyw.... albo zajmę się zwykłym guidingiem

 

2 godziny temu, zbuffer napisał:

3. Aby skalibrować ten enkoder musisz mieć inny sensor, który mierzy o rząd wielkości dokładniej.... to raczej będzie trudne.

Nie muszę go kalibrować bardziej dokładnie, niż tak, żeby gwiazdka którą fotografuję nie ruszała się z miejsca... prawda?

 

2 godziny temu, zbuffer napisał:

Generalnie zastanawiam się czy sens ma używanie sensora, który sam w sobie będzie miał błąd okresowy, do korygowania innego błędu okresowego. 

Nie lepiej użyć prostego enkodera absolutnego na osi ślimaka i po prostu nagrać PEC'a w oparciu o guiding, i potem go precyzyjnie odtwarzać. Wystarczył by oczywiście nawet pojedynczy impuls ale z enkoderem absolutnym nie trzeba by tyle przewijać montażu na początku. Można by taki zewnętrzny PEC oprzeć o mikrokontroler i po USB połączyć z komputerem. Potem napisać driver, który będzie grał rolę guider'a - tzn. będzie odbierał pulsy, które mają iść do montażu i je modyfikował dodając PEC.

Już to robiłem, nie podobało mi się to - było zbyt skomplikowane, przynajmniej w moim wykonaniu. Tutaj conieco w temacie:

 

 

@count.neverest

W nowszym designie będę używał OV2640 z pikselem 2.2um

[zbuffer]

3 godziny temu, Behlur_Olderys napisał:

Możesz rozwinąć myśl? Jak miałoby to wyglądać? Moim zdaniem wykorzystuję 2D, bo uśredniam przesunięcie po całej długości paska, co zwiększa dokładność.

Hmm... najpierw przyszło mi na myśl żeby wykorzystać sinusoidę zamiast pasków, bo wtedy masz ciągłą zmianę wartości a nie tylko impulsy. Jednak rozumiem, że koło z drukarki jest tanie i jest to zaleta rozwiązania. 

 

Jeśli chodzi o uśrednianie, o którym mówisz, to w jakimś sensie może wyeliminować błędy losowe - defekty w paskach - ale z drugiej strony nie wyeliminuje błędu systematycznego, który wynika z dystorsji obiektywu i który musisz skalibrować. Inaczej Twoje uśrednianie może być gorsze niż wybranie pikseli z jednego rzędu czy kilku sąsiednich, w miejscu w którym dystorsja jest niska.

 

Myślę jednak że użycie 2D ma inna przewagę. Zamiast robić naiwne uśrednianie jakichś gradientów, które nigdy nie będą perfekcyjnie równolegle do kolumn CCD, i walczyć z wieloma defektami w paskach które widzę na załączonej klatce z kamery, mógłbyś spróbować zastosować optical flow. Jest to metoda estymacji ruchu obrazu. Wykorzystywana jest np. w analizie modalnej z wykorzystaniem kamer. Rozdzielczość pomiaru sięga 1/100 wielkości piksela.

Nie wiem czy to ma szansę działać na wspomnianym mikrokontrolerze, może potrzebne jest FPGA, ale mógłbyś spróbować z komputerem na początek. Główna zaleta jest taka, że nie ma znaczenia jak te paski wyglądają, właściwie może to być dowolna tekstura.

 

Szybkie wyszukiwanie dało mi taki wynik na ten temat:

https://learnopencv.com/optical-flow-in-opencv/

 

3 godziny temu, Behlur_Olderys napisał:

 

Już to robiłem, nie podobało mi się to - było zbyt skomplikowane, przynajmniej w moim wykonaniu. Tutaj conieco w temacie:

 

Prześledziłem mniej więcej i jedno czego nie rozumiem to dlaczego czekasz aż błąd przekroczy krok silnika zamiast używać sterowania mikrokrokowego? 

Druga sprawa to że ja bym oparł odtwarzanie o czas a nie enkoder, bo i tak nie ma on wystarczającej rozdzielczości. Dla mnie enkoder byłby użyteczny żeby rozpocząć odtwarzanie w odpowiednim momencie i dlatego zastosowałbym absolutny.

 

Edytowane 13 Czerwca 2022 przez zbuffer

[MateuszW]

3 godziny temu, Behlur_Olderys napisał:

Ale dla moich potrzeb nie jest istotna w ogóle jakość wykonania tego koła, bowiem liczę jedynie przesunięcie - różnicę pomiędzy dwoma kolejnymi obrazami. Gotowe koło jest wygodne, ale właściwie mógłbym użyć - tak jak mówił @calla dowolnego, nawet randomowego wzoru, kosztem nieco bardziej skomplikowanych obliczeń. Ważne, żeby tarcza była sztywna, i tyle.

Tak, możesz użyć nawet randomowego wzoru pod warunkiem, że... znasz jego dokładny kształt  Nie możesz zakładać, że paski w kółku są np w równych odstępach, bo na pewno występują tutaj odchyłki wynikające z dokładności wykonania. Ten efekt przekłada się potem na długookresowy błąd. Tak samo dystorsja obiektywu - jeśli mierzysz przesunięcia o więcej niż kilka pikseli, to zaczyna ona wpływać na dokładność.

No ale po kolei - jak poprawienie mechaniczne tego układu da niewystarczający efekt, to będziesz miał kolejną rzecz do sprawdzenia i uwzględnienia  

[calla]

Godzinę temu, zbuffer napisał:

 

Szybkie wyszukiwanie dało mi taki wynik na ten temat:

https://learnopencv.com/optical-flow-in-opencv/

 

 

 

Kiedyś się bawiłem, i jakoś tam działa, tylko trochę się oblicza. ciekawe jakby tu działało

[WielkiAtraktor]

W ImPPG używam korelacji fazowej , ale nie wiem, czy do takiego wymagającego dokładności zastosowania się nada (mnie wystarcza, że do animacji jest „na oko” płynnie).

Edytowane 13 Czerwca 2022 przez WielkiAtraktor

[Behlur_Olderys]

6 minut temu, WielkiAtraktor napisał:

W ImPPG używam korelacji fazowej , ale nie wiem, czy do takiego wymagającego dokładności zastosowania się nada (mnie wystarcza, że do animacji jest „na oko” płynnie).

 

Na pierwszy rzut oka nie wydaje się jakoś nadzwyczaj dokładne, ale może przy zastosowaniu jakichś subpixelowych tricków byłoby spoko.

Problem z FFT to że trzeba ją liczyć dla całego obrazu co trochę zajmuje. A tak naprawdę to przecież z góry wiem, że poza pikselami stanowiącymi brzeg paska nic więcej w obrazie się nie zmienia....

[Behlur_Olderys]

Update:

Po kilku uciążliwych bitwach z softwarem zrozumiałem, że nie potrafię sensownie napisać wielowątkowej aplikacji w Pythonie, zresztą nie ma tam prawdziwej równoległości. Tymczasem sprzężenie zwrotne ze sterownikiem montażu musi działać jak najszybciej. Wobec tego wydzieliłem kluczowe komponenty: czytanie encodera i śledzenie gwiazd do osobnych procesów. Okazuje się, że dzięki temu działają one znacznie lepiej.

Tak czy inaczej, po ręcznej kalibracji, udało mi się naświetlić 200x10s galaktyki Igła. Kamera T7C działała z prędkością 2fps, co jest dość wolno, bo przecież niebo przebiega wtedy ok 7", a skala na moim zdjęciu to 0,91". Uzyskałem takie dwa wykresy:

 

 

Górny wykres pokazuje samą pętlę sprzężenia zwrotnego z enkoderem: sterownik montażu wysyłając komendy-poprawki co 0.5s jest w stanie "zmusić" go do podążania za wskazaniem enkodera z dokładnością do +/- 2". Przede mną eksperymenty z mniejszą stałą czasową - liczę na osiągnięcie +/-1", choć pewnie sporo zależy od samej mechaniki mojego wysłużonego EQ3-2.

 

Dolny wykres jest znacznie bardziej interesujący. Jest wyskalowany w pikselach, przy czym przypominam skalę mojego setupu (SW130/650+QHY462C) - 0,91"/px. Czerwona linia to dryf DEC wynikający z niedokładnego ustawienia na biegun. Podczas 2000s sesji praktycznie połowa kadru mi zjechała w dół. Niebieska linia to dryf RA. Jak widać, pomijając moment w ok. 1000s, wykres jest bardzo gładki.

Świadczy to o tym - jak wspominałem - że enkoder świetnie koryguje błędy montażu w zakresie wysokich częstotliwości, natomiast pozostaje dryf długoczasowy wynikający - chociażby - z tego, że tarcza enkodera jest trochę powyginana.

Wydaje się więc, że jeśli tylko uda się mi opracować algorytm "wyciągania" dryfu z przesunięć zdjęć z głównej kamery uzyskam całkowicie płaskie wykresy (no, wiadomo, może +/- 2" ale to wciąż EQ3-2 bez guidingu! )

Jestem optymistą dlatego, że wydaje mi się, iż problem skorygowania prędkości montażu raz na kilka minut jest kilka rzędów wielkości prostszym zadaniem niż korekcja pozycji co pół sekundy

Ogólnie algorytm już mam tylko zostało trochę klejenia programów taśmą klejącą itp...

 

Igła jaka mi wyszła nie jest może piękna, ale jest piękną pamiątką tego testu  Oczywiście filtr 850nm.

 

 

[ZbyT]

Godzinę temu, Behlur_Olderys napisał:

 

Tak czy inaczej, po ręcznej kalibracji, udało mi się naświetlić 200x10s galaktyki Igła. Kamera T7C działała z prędkością 2fps, co jest dość wolno, bo przecież niebo przebiega wtedy ok 7", a skala na moim zdjęciu to 0,91".

 

 

częstotliwość korekt jest chyba nawet więcej niż wystarczająca

w końcu sam napęd prowadzi dobrze czyli kolejne mikrokroki wykonuje z dokładnością kwarcu, a my wprowadzamy jedynie drobne korekty spowodowane nieidealnym prowadzeniem wynikającym z kolei z niedokładności mechanicznych

 

dla EQ3-2 PE to jakieś 60" łuku przy okresie trwającym ponad 10 minut czyli średnio odchyłka od idealnego prowadzenia to 0,1" /sekundę. Przy 2 korektach w ciągu sekundy daje to potrzebną przeciętną korektę na poziomie 0,05". Nawet jeśli rzeczywiste niedokładności prowadzenia są 5 razy większe to i tak niezbędna przeciętna korekta to ledwo 0,25" czyli wyraźnie poniżej skali zdjęcia. Moim zdaniem ze sporym zapasem. W przypadku guide korekty są nawet rzadziej bo co 2-3 sekundy i to całkowicie wystarcza

 

pozdrawiam