Poprawa prowadzenia EQ3-2 za pomocą enkodera - finał

[Behlur_Olderys]

Chciałbym przedstawić najlepsze wyniki, jakie do tej pory osiągnąłem w ramach podsumowania dwóch poprzednich tematów w tej samej sprawie. Na razie tylko wykres - na zachętę - jest dosyć oczywisty

 

EDITED:

dla fanów jednoliczbowych parametrów:

RMS przed = 18,5"

RMS po = 6,1"
Więc możemy spokojnie mówić o 3x lepszym prowadzeniu

 

 

 

Ogólna dyskusja była trochę tutaj:

 

 

 

a także tutaj:

 

 

 

Będę miał więcej czasu to dopiszę technikalia  

Pozdrawiam!

 

[Herbert West]

Focie, technikalia- wrzucaj. Jestem pod wrażeniem!

[Behlur_Olderys]

Technikalia są takie:

 

Montaż EQ3-2 kupiony z drugiej ręki. 

Przesmarowany, wyczyszczony, nowe podkładki z teflonu.

Wymienione silniki na steppery 17HS4401S + przekładnia 1:5,18 + pasek 1:2 do wału silnika. Koszt około 300zł za dwie osie.

Enkoder 12b absolutny na osi RA+sprzęgiełko + customowe mocowanie. Koszt około 200zł

Steppery chodzą w 1/16 mikrokroku na driverach DRV8825.

Całość w sterowniku RAMPS 1.5 (albo 1.6 już nie pamiętam) do drukarek 3D + Arduino Mega jako mikrokontroler.

Koszt zestawu arduino + ramps + drivery ok. 150zł

Jeszcze trochę poszło na złączki, kable, gniazda i wtyki, ale to powiedzmy 50zł.

 

Razem jakieś 700zł - ale powiedzmy, że choćby i 1000zł za całościową modyfikację. Jestem zadowolony

 

 

Dodatkowo niezliczona (w sensie nie liczyłem, ale nie było tego aż tak dużo, na pewno więcej, niż chciałem  ) ilość godzin spędzonych na rozkminę, analizę i przygotowanie danych.

 

Korekcja:

Steppery chodzą ze stałą, teoretyczną prędkością a enkoder wprowadza korekty porównując czas jaki upłynął od rozpoczęcia śledzenia i aktualną pozycję enkodera (obie wartości "zawijane" co pełen okres).

Na początku trzeba zadać enkoderowi pracę "liniową" czyli stałe przyrosty enkodera w stałych inkrementach czasu. Czyli stała prędkość równa teoretycznej sidereal.

Mierzymy tak przez kilka okresów błąd periodyczny.

Następnie uśredniamy kilka okresów i korelujemy je ze zmierzonymi (soft wypluwa mi to na COM) odczytami enkodera.

W tym momencie tworzy się model prędkości. 

X to przesunięcie przewidywane z pominięciem PE

T1 to czas pomiędzy kolejnymi zliczeniami enkodera z pominięciem PE

omega_t to prędkość sidereal

Y to przesunięcie zmierzone na obrazku

T2 to czas pomiędzy zliczeniami z poprawką na PE

omega_r to realna, zmierzona charakterystyka prędkości ślimaka

 

Mamy wtedy proste wzory, z których wyliczamy, jaki czas (T2) powinien upłynąć pomiędzy kolejnymi zliczeniami enkodera, żeby nadrobić PE:

T1*omega_t = X  // w idealnym przypadku 

T1*omega_r = Y  // przy mierzeniu błędu

T2*omega_r = X // T2 powinno korygować błąd

Zatem:

T2 / T1 = X / Y -> T2 = T1 * ( X / Y).

Jak widać, do wyznaczenia T2 czyli poprawkowych czasów wystarczy znać przesunięcie nieba oczekiwane i zmierzone. Robię to w excelu ale mam też program w pythonie który to liczy, jeszcze go poprawiam...

Jest kilka niuansów tych obliczeń, z chęcią odpowiem na każde pytanie

Zmodyfikowane czasy T2 wrzucam do kontrolera i tyle.

 

Dodatkowo przy okazji powstał sterowanik ASCOM alpaca (czyli API restowe) do montażu pozwalający na sterowanie z poziomu SharpCapa.

 

 

 

Poglądowe zdjęcia na montowanie enkodera oraz całość montażu.

 

 

 

A co w planach?

- wymiana driverów DRV8825 na jakieś lepsze

- być może mocowanie enkodera da się zrobić jeszcze ładniej

- pudełko na elektronikę z prawdziwego zdarzenia (to jest jak wiadomo tymczasowo pudełko po ASI120mm)

- sterownik ASCOM dorobić żeby było normalne GoTo, guiding

- porządna architektura programu na Arduino (na razie to dosyć brzydki zlepek funkcji któych boję się dotykać )

- stalowe nogi zamiast tych aluminiowych

[Herbert West]

Fantastyczna robota, wzorowy ATM... czy raczej AMM. +1 za pudełko na elektronikę, wskazany jednak upgrade w postaci worka foliowego na to pudełko ;-) Ciekawe jakie efekty byś miał traktując w ten sposób coś mechanicznie wyższej klasy, typu HEQ5 albo EQ6. Przypuszczam, że dobre.

[Behlur_Olderys]

1 minutę temu, Herbert West napisał:

Fantastyczna robota, wzorowy ATM... czy raczej AMM. +1 za pudełko na elektronikę, wskazany jednak upgrade w postaci worka foliowego na to pudełko ;-) Ciekawe jakie efekty byś miał traktując w ten sposób coś mechanicznie wyższej klasy, typu HEQ5 albo EQ6. Przypuszczam, że dobre.

 

 

 

Przypuszczam, że już nie tak spektakularne, bo te montaże chyba "same z siebie" już jeżdżą lepiej niż EQ3-2 - przynajmniej tak wszyscy mówią.

Inna sprawa: na ile można rzeczywiście wymienić w HEQ5 silniki albo zamontować enkoder na osi ślimaka? 

Z trzeciej strony: eq-32 można kupić za < 1000zł. Nie jest mi go żal wiercić itp. A już HEQ5 zadbany to jakieś 4koła, wolałbym już nie modyfikować

 

Zresztą im dalej w las tym bardziej oczywista potrzeba guidingu, tego się nie przeskoczy za bardzo. Jeszcze nie jestem pewien, na ile w ogóle można zrealizować pożenienie mojej idei korekcji enkoderem z guidingiem. Wydaje mi się wejściem na dwa poziomy trudności wyżej. Bez przepisania programu sterującego nie będę się za to zabierał. Całe szczęście ostatnio programuję mikroprocesory w pracy więc wiem, jak to powinno wyglądać żeby było porządnie.

 

 

 

 

PS
Pudełko jest zamykane na klapkę, widać na dole zdjęcia  Nie domyka się do końca ale wiesz... jest ok

[bacHor]

To pudełeczko to znak firmowy tego projektu. Nie sądziłem, że będzie Ci służyć tak długo. Najbardziej zasłużony karton jaki widziałem

Gratulacje za efekty pracy i upór! 

[Behlur_Olderys]

No tak, @bacHor, przecież ja już na zlocie z tym złomem się obnosiłem, damn, przecież to był maj

 

Tyle mi zeszło

 

Ostatecznie wszystko zaczęło działać gdy zauważyłem 2 rzeczy:

mocowanie enkodera wcale nie było takie stabilne, bo z blachy 1mm. Przez to kiwało się lekko przy obrocie i wprowadzało sztuczny błąd. Wymieniłem je wczoraj na 2mm. 

 

A po drugie: okazuje się, że kamera ustawiona w SharpCapie na 6s robi klatki trwające 5,63s!!! DSS też tego nie widzi, ale widać to dopiero na timestampach plików. To też wczoraj zauważyłem i naprawiłem, nigdy nie przypuszczałbym, że różnica będzie taka duża...

 

 

Tak czy inaczej mogę teraz spokojnie uznać projekt za skończony sukcesem. 

I zabrać się za następny

 

[lkosz]

No obudowa jest urocza udało się opanować te przerwania mieszające w równomierności kroków?

[Behlur_Olderys]

36 minut temu, lkosz napisał:

No obudowa jest urocza udało się opanować te przerwania mieszające w równomierności kroków?

 

Nie, po prostu rekompensuję je minimalnie szybciej kręcąc silnikami

 

Teraz ta cała afera z przerwaniami wydaje mi się to jedną ze ślepych uliczek. Oczywiście, mają one minimalny wpływ, ale tego nie widać na pojedynczych fotkach, być może wprowadza minimalny obsuw w całości, ale ze względu na dosyć dużą powtarzalność wszystkich sterowań koniec końców jest to po prostu minimalne liniowe zaburzenie, najprostsze do eliminacji. 

 

Jak widać, byłem wtedy w nastroju szukać winowajcy wszędzie tylko nie w SharpCapie

 

Zresztą wiele rzeczy również poprawiłem:

Pomijanie kroków w RA zamiast kręcenie w drugą stronę (co jest bezcelowe, bo niebo się przecież rusza)

Wiadomości diagnostyczne wysyłam już raz na 20 obrotów pętli, a nie za każdym razem.

Zwiększenie siły korekcji przez sprawdzanie pozycji co krok, a nie raz na kilka kroków. 

Już nie mówię o kilku oczywistych błędach które na chwilę cofały mnie w rozwoju, jak np. błędne copy &paste w kodzie, czy wprowadzania przez omyłkę odwrotności korekcji