Enkoder na osi RA - DIY

[Behlur_Olderys]

@ZbyT w takim razie wydaje się że najlepiej byłoby wykorzystać nadmiar pomiarów do uśrednienia? Np. gdyby robić 4 FPS, z tych 4 pomiarów wyznaczać sumę przesunięć i dopiero tej sumy użyć jako poprawki tylko 1 raz na sekundę...

 

Notabene: wykres dryfu mimo to jest trochę postrzępiony, będzie to przedmiotem następnych inwestygacji. Na razie muszę zrobić w miarę niezawodny mechanizm likwidujący ten dlugoczasowy trend. Całe szczęście pogoda w ten długo weekend wydaje się że będzie dopisywać;)

 

[ZbyT]

być może wystarczą korekty co 2-3 sekundy. To akurat trzeba by przetestować. Chodziło mi o to, że nie ma sensu robić je częściej niż 2 razy na sekundę bo to byłby przerost formy nad treścią. Większe moce obliczeniowe oznaczają większe koszty i większy pobór prądu, co może nieć znaczenie w terenie. Wydaje się, że zysk na prowadzeniu z takiego podejścia byłby żaden

 

poza tym trzeba pamiętać, że schodzenie z dokładnością prowadzenia poniżej 1" i tak nie ma sensu bo mamy seeing, który wprowadzi swoje drgania obrazu na  matrycy. Do tego dojdą inne niedoskonałości mechaniczne samego astrografu czy jego mocowania i cały wysiłek pójdzie psu na budę. Trzeba by to spiąć z jakimś systemem optyki adaptatywnej, a to z kolei jakoś gryzie się z EQ3-2

 

pozdrawiam

[Behlur_Olderys]

Wciąż walczę z odpowiednią kompensacją dryfu zarówno RA (wynikającego z niedokładności określenia skali obrazowania) jak i DEC (ze względu na błąd ustawienia polarnej).

Na dziś efekt jest dość zadowalający (czerwone to DEC, żółte to RA)

 

Nie są to może jakieś super proste linie, ale w przeciągu 1,5h zawierają się mniej więcej +/- 15 sekund łuku, co jest już sporą poprawą wobec "czystego" EQ3-2. Przede wszystkim zostawiony bez nadzoru montaż nie gubi kadru, co udało mi się pierwszy raz od naprawdę długiego czasu

Na wykresie RA widać, że po pewnym czasie zaczęły "wychodzić" górki od PE ślimaka. Świadczy to o zbyt słabej korekcji - będę musiał popracować nad tym, żeby mocniej kontrować te ruchy bez wpadania w oscylacje (takie, jakie pojawiły się na osi DEC - to akurat w dużej mierze "zasługa" luzów na ślimaku DEC).

Wykres błędu enkodera pokazuje, jak rozjeżdża się ostrość, co de facto skutkuje właśnie takim, a nie innym zachowaniem. Tutaj też widać "tętnienia" z okresem 660s charakterystycznym dla przekładni ślimakowej z 130 zębami.

 

 

Podsumowując: enkoder działa, kompensacja długoczasowa w zasadzie działa, do dogrania są szczegóły  Prawdopodobnie będę musiał zaimplementować i odpowiednio ustawić jakiś rodzaj regulatora PI, żeby pozbyć się oscylacji w DEC, oraz poprawić siłę sprzężenia w RA.

 

Na ostatek - mała animacja wycinku kadru (przypominam - skala 0.91"/px, klatki 20s:

 

 

 

[WielkiAtraktor]

1 godzinę temu, Behlur_Olderys napisał:

(czerwone to DEC, żółte to RA)

Będzie prościej, jak opiszesz to w arkuszu, nazwy serii pojawią się w legendzie wykresu

[Behlur_Olderys]

21 minut temu, WielkiAtraktor napisał:

Będzie prościej, jak opiszesz to w arkuszu, nazwy serii pojawią się w legendzie wykresu

No wiem, wiem, jestem taki leniwy

 

[zbuffer]

Mam dla Ciebie jedną sugestię. Zainteresuj się implementacją filtru Kalmana do estymacji prędkości obrotowej osi.
Mimo uśredniania pikseli będziesz się borykał z niepewnością/szumem wynikającymi z detekcji ruchu pasków i samej dokładności wykonania itp. Wystarczy liniowy filtr, w którym zamodelujesz obrót osi jako ruch ze stałą prędkością a enkoder będzie wprowadzał poprawki. Będziesz miał ciągły odczyt ruchu obrotowego z wysoką częstotliwością poprawiny co jakiś czas przez enkoder. Zaletą tego rozwiązania jest możliwość określenia kowariancji pomiaru i modelu czyli statystycznie określasz ich dokładność, zakładając rozkład Gaussowski błędów (co normalnie jest wystarczjącym przybliżeniem). Dodatkowo możesz potem rozwinąć model o dryft i inne składowe które zauważasz.

Filtr Kalmana jest podstawową metodą estymacji wykorzystywaną praktycznie we wszystkich systemach pomiarowych, szczególnie jeśli zachodzi fuzja różnych sensorów. Ale dla jednego sensora też ma sens. Bez FK np. żaden dron by nie działał.

Poszukaj „Kalman Filter” a ja tu podepnę link jak znajdę jeden fajny pdf, który widziałem.

[Behlur_Olderys]

18 minut temu, zbuffer napisał:

Mam dla Ciebie jedną sugestię. Zainteresuj się implementacją filtru Kalmana do estymacji prędkości obrotowej osi.
 

 

Dzięki za sugestię, oczywiście znam filtr Kalmana, robiłem trochę w autonomicznych autach więc ogólnie ogarniam teorię. Model liniowego ruchu sprowadza się do pomnożenia czasu, który upłynął przez prędkość kątową nieba i to jest po prostu wartość zadana w moim regulatorze. Bez enkodera przecież silniki i tak i tak ruszają się z prędkością nominalną. Rzeczywiście można by wprowadzać dodatkowe poprawki do tej prędkości pomiędzy odczytami żeby niejako zasymulować szybszy enkoder. Zobaczę najpierw jednak, czy nie wystarczy po prostu dobrze ustawiony regulator PI. Kiedy miałem enkoder na ślimaku to odczyty z niego były na tyle szybkie, że problem tego typu nie istniał, teraz mam rząd wielkości rzadziej informacje z enkodera, ale to tylko dlatego, że jeszcze nie przesiadłem się na rozwiązanie wbudowane. Tam odczyt zakładam mniej więcej 10Hz, więc poza uśrednianiem odczytów właściwie nie będzie za wiele do roboty.

Pozdrawiam 

[Behlur_Olderys]

Update:

Najnowszy wykres "guidingu":

Zielona - DEC, czerwona - RA. Osie są w sekundach łuku (y) oraz sekundach (x).

 

Jak widać PE jest całkowicie wyeliminowany, pozostaje długoterminowa korekcja. Ten błąd narastający z czasem był wywołany stosowaniem regulatora czysto P i pewnego thresholdu, żeby nie wykonywać zbyt małych korekt. Ten threshold powoduje, że zmiany mniejsze niż 1px nie były brane pod uwagę, ale przez 168 klatek nazbierało się ok. 168 pikseli przesunięcia, więc w sumie program działał dokładnie wg specyfikacji - żadna klatka nie miała pojechanych gwiazdek. Po dodaniu członu I regulator powinien potrafić utrzymać linię żeby była prosta  

Zbliżony kształt obu krzywych sugeruje, że źródło błędu może być to samo dla obu osi - prawdopodobnie błąd alignacji na Polaris.

Pozdrawiam!

[lkosz]

To już chyba możesz zmienić mu nazwę na PEC-szatan

 

Noo taki wynik z użyciem wyłącznie członu proporcjonalnego... brawo. A jak ustawiałeś montaż? Lunetką czy metodą dryfu?

[dobrychemik]

44 minuty temu, lkosz napisał:

To już chyba możesz zmienić mu nazwę na PEC-szatan

 

Noo taki wynik z użyciem wyłącznie członu proporcjonalnego... brawo. A jak ustawiałeś montaż? Lunetką czy metodą dryfu?

Docelowo montaż Bartka powinien się sam ustawiać na biegun.

[Behlur_Olderys]

2 godziny temu, lkosz napisał:

To już chyba możesz zmienić mu nazwę na PEC-szatan

 

Noo taki wynik z użyciem wyłącznie członu proporcjonalnego... brawo. A jak ustawiałeś montaż? Lunetką czy metodą dryfu?

 

Dryfem. Ale ustawiałem miesiąc temu, teraz tylko kładę montaż na zaznaczone miejsca nóżkami. Nie chce mi się codziennie kręcić, więc pewnie z czasem się rozjeżdża...

Projekt nazwałem PEliminator

 

[lkosz]

nooo to jeszcze jest szansa na poprawę, i że to nie są jakieś ugięcia oraz luzy. Trzymam kciuki

[zbuffer]

15 minut temu, Behlur_Olderys napisał:

 

Dryfem. Ale ustawiałem miesiąc temu, teraz tylko kładę montaż na zaznaczone miejsca nóżkami. Nie chce mi się codziennie kręcić, więc pewnie z czasem się rozjeżdża...

 

Nie wiem jak precyzyjny jesteś z tym ustawianiem, ale staram się robić to samo i błędy są w minutach... 

Swoją drogą nie wiem jak kontrolujesz teleskop. Ja używam EKOS'a i szczerze mówiąc ustawianie na Polarną to mniej niż 5 minut bo montaż sam się obraca, robi zdjęcia i pokazuje o ile co poprawić na żywo, odświeżając obraz z kamery. Trochę nieuzasadnione lenistwo nie ustawiać za każdym razem 

Edytowane 19 Lipca 2022 przez zbuffer

[Behlur_Olderys]

4 minuty temu, zbuffer napisał:

Nie wiem jak precyzyjny jesteś z tym ustawianiem, ale staram się robić to samo i błędy są w minutach... 

Swoją drogą nie wiem jak kontrolujesz teleskop. Ja używam EKOS'a i szczerze mówiąc ustawianie na Polarną to mniej niż 5 minut bo montaż sam się obraca, robi zdjęcia i pokazuje o ile co poprawić na żywo, odświeżając obraz z kamery. Trochę nieuzasadnione lenistwo nie ustawiać za każdym razem 

 

Cieszę się że Tobie się udaje lepiej to ogarnąć. Dla mnie ustawienie na biegun nie ma większego znaczenia bo i tak nam zamiar je kompensować softem. Więc nawet dobrze, jak trochę jest. Enkoder powinien sobie radzić nawet jak nie ma ustawienia idealnego. Ja mam za mało czasu na zabawę. Trzeba jeszcze spać... Teleskop kontroluję moim własnym softem, więc oczywiście jest on mniej zaawansowany niż EKOS itp.

 

[zbuffer]

11 minut temu, Behlur_Olderys napisał:

Teleskop kontroluję moim własnym softem, więc oczywiście jest on mniej zaawansowany niż EKOS itp.

Ufff..... czemu nie korzystasz z narzędzi które są standardowe i dają Ci kontrolę nad całym setupem?

To, że masz własny sterownik montażu w niczym nie przeszkadza - po prostu implementujesz driver dla EKOS'a, który będzie sterował Twoim montażem. Napisanie własnego driver'a teleskopu nie jest trudne, tak samo jak fokusera itp.  

[Behlur_Olderys]

33 minuty temu, zbuffer napisał:

Ufff..... czemu nie korzystasz z narzędzi które są standardowe i dają Ci kontrolę nad całym setupem?

To, że masz własny sterownik montażu w niczym nie przeszkadza - po prostu implementujesz driver dla EKOS'a, który będzie sterował Twoim montażem. Napisanie własnego driver'a teleskopu nie jest trudne, tak samo jak fokusera itp.  

 

Bo lubię życie na krawędzi

 

Piszę dużo eksperymentalnego softu. Jakbym miał jeszcze dbać o zgodność z jakimś zewnętrznym programem to bym się zajechał. 

 

Poza tym najwyraźniej do moich celów wystarczy to, co mam. 

 

Równie dobrze mógłbyś zapytać: czemu nie kupię sobie normalnego montażu, guidera, kolorowej kamery i zrobił Łabędzia nr 10000.

 

 

[zbuffer]

Oczywiście Twój wybór, nie rozumiem po co ta ironia...

Przecież poza tym, że budujesz własną wersję montażu, chcesz go używać do robienia zdjęć, więc tak czy inaczej musisz jakoś obsługiwać kamerę, guiding itp. Poza tym jakoś przecież badasz wyniki swojej pracy i mając to zintegrowane w jednym środowisku miałbyś dostęp do zarówno standardowych elementów jak i Twoich własnych rozwiązań. Nie wymaga to aż takiego nakładu pracy. Programuję codziennie i też napisałem wiele własnych rozwiązań, ale są rzeczy, których po prostu głupio nie wykorzystać, szczególnie jakbyś chciał się z kimś tym pomysłem podzielić. Też nie przepadam za integracją z dużym softem napisanym przez kogoś innego, ale jak dokumentacja jest dobra i soft jest open source, uważam że warto. 

BTW też lubię kombinować przy sprzęcie więc nie widzę nic dziwnego w budowaniu swojego enkodera czy montażu, co zresztą planuję. W końcu zabawa nie polega tylko na ładnych fotkach ;-)

[Behlur_Olderys]

Biorąc pod uwagę, że w moim sofcie mam obsługę montażu, enkodera, focusera, goto, kamery i całkowitą elastyczność to raczej zostanę przy tym rozwiązaniu i będę je rozwijał. A jak już będę miał to wszystko opanowane, to wtedy zajmę się dopisywaniem sterownika ASCOM.

 

[zbuffer]

To akurat nie problem bo sterownik może implementować dowolną kombinację interfejsów i być widoczny jako np. fokuser, montaż i stacja pogodowa. Zysk jest taki, że wszystkie narzędzia automatycznie współpracują (tak jest w Indi, ale pewnie Ascom ma coś podobnego, tylko ja Windows’a nie tykam brrr…;-).

 

Ciekawy jestem kiedy napiszesz swoje planetarium…. Ja byłem na tej drodze dawno temu…