Transformacja współrzędnych dla opornych :)

Amatorskie modyfikacje sprzętu i budowa teleskopów

PostVroobel | 03 Lut 2018, 02:26

Witam ponownie,

Jako, że temat związany jest z ATM, wrzucam go tu. Dodam, że taki sam wątek zakładam na sąsiednich forach dla spopularyzowania zagadnienia.

Odkąd zacząłem przekształcać mojego Dobsona w motoDobsona, szukałem lekkostrawnej informacji, jak to wszystko potem zautomatyzować. O ile nie straszna mi elektronika, jakiś tam mikrokomputer, np. Raspberry Pi, czy programowanie, o tyle ciężko było o samą teorię. Długo szukałem na wielu stronach punktu zaczepienia, a kiedy już mi się wydawało, że go znalazłem, to okazało się, że to ślepy zaułek. Omal umknęło mi, że Janusz P. podpowiedział mi (nie tylko z resztą mnie) znakomitą książkę Jeana Meeusa "Astronomical Algorithms".

Wspólnie z kolegą nkmarek opracowaliśmy dwa niezależne systemy, wspierając się nawzajem. Pomyślałem sobie, że przecież nie tylko ja męczyłem się kilka miesięcy nad tym zagadnieniem, dlatego, bazując na wspomnianej książce i "Tabeli Wimmera" (na podstawie której powstaje moja własna zmodyfikowana baza danych) wykonałem skromny serwis przedstawiający moje wyliczenia oraz objaśnienia skomplikowanych wzorów "na żywo".

http://astrovroobel.epizy.com/index.php

Serdecznie zapraszam do lektury.
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

Postxooon | 07 Kwi 2018, 09:17

Witam!
Gratuluję!, świetna robota.
Czytałem Twój blog, to również niewyczerpana kopalnia pomysłów i informacji.
Mam jednak inne doświadczenia dotyczące użycia mikrokontrolera do pozycjonowania w różnych układach współrzędnych.
Mi udało się zachowacćodpowiednią predkość pracy algorytmu z procesorem Atmel i zegarem 16MHz.
Jestem w stanie pozycjonować kilka razy na sekundę. I wprawdzie to arytmetyka 8 bitowa ale według moich szcunków i doświadczeń w zupełności wystarczająca do zastosowań amatorskich. Założyłem ostatecznie pozycjonowanie co ok. 1-1.5 sekundy a "w miedzyczasie" procesor wykonuje i inne czynności - sterowanie silnikami, odczyt czasu ze źródła RTC (Real Time Clock) i inne. Korzystam przy tym z modułowego zegara czasu (PCF8583), który z podtrzymaniem bateryjnym w zupełności wystarcza do pracy.
Przejście do obliczeń na PC gubi mobilność rozwiązania a jest to chyba do pokonania jak pokazują wykonania fabryczne.
Jeśli chodzi o algorytm obliczeń to warto nad nim posiedzieć, w szczególności da się pogrupować operacje i funkcje tak aby nie powtarzały się niepotrzebnie. Warto też korzystać z wbudowanych procedur (o ile są) możliwie niskiego poziomu, które sa zapewne lepiej zoptymalizowane czasowe niż własne pomysły funkcji.
Trzymam kciuki za wynik końcowy ;-)
xooon
 
Posty: 53
Rejestracja: 18 Maj 2017, 15:04

 

PostVroobel | 08 Kwi 2018, 13:14

Spieszę z odpowiedzią w sprawie mobilności. Obecnie walczę z Raspberry Pi - jest to baaardzo mobilna podstawa, jednocześnie bardzo wydajna: mam bazę danych obiektów (docelowo będzie to nieco zmodyfikowana Tabela Wimmera + te kilka gwiazd kalibracyjnych), stronę w PHP przydatną do sprawdzenia położenia obiektów, nawet Stellarium postawiłem i teraz pracuję nad skryptem w Pythonie analogicznym do systemu GOTO. Z dotychczasowego Arduino pozostanie jedynie shield ze sterownikami silników.

Zabawę na PC zacząłem z innego powodu. Zrozumiałem, że moich obliczeń Arduino nie jest w stanie wykonać (choć może się nie postarałem - w końcu Twoje doświadczenia z 8-bitowym kontrolerem mówią coś innego...), więc przemyślałem przesiadkę na RPi. Czekając nań zapoznałem się z teorią (książka) i napisałem tą stronkę w PHP zupełnie przy okazji. Dziś mi się przydaje, może komuś też się przyda, ale kiedy już kupiłem RPi, przeniesienie kodu i postawienie całego środowiska było już tylko kwestią czasu. W efekcie, wizualna cześć setupu ograniczona jest wyświetlaczem LCD 4x20, a to w zupełności wystarcza (na początek, może zainwestuje w OLED).

Niestety, upłynie jeszcze nieco wody, zanim to skończę. Chroniczny brak czasu. A ja mam mnóstwo nowych pomysłów i pewnie emerytury się doczekam prędzej, niż ich realizacji...
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

PostVroobel | 19 Sty 2019, 00:12

Drodzy Koledzy (obojga płci), potrzebuję wsparcia teoretycznego - staram się znaleźć przyczynę błędnego wskazania pozycji Księżyca.

Już kilka dni siedzę nad książką "Astronomical Algorithms" i moim modułem oprogramowania do wyliczania pozycji Księżyca. Pierwsze kodowanie robię zwykle w PHP, potem przenoszę kod do Pythona na Raspberry Pi w teleskopie. Oczywiście na początek biorę przykład z książki (tu konkretnie 12/04/1992 00:00:00, co może jest ważne) i wynik mojego kodu pokazuje mi dokładnie to, co napisał autor książki:

λ = 133° 10' 2.12" (w książce jest 133° 10' 02")
β = -3° 13' 44.85" (w książce jest -3° 13' 45")

α = 8h 58m 45.14s (w książce jest 8h 58m 45.1s )
δ = +13° 46' 0.79" (w książce jest +13° 46' 06")

a więc nie mam tu praktycznie żadnego błędu, To ważne, bo w obliczeniach należy posłużyć się 3-ma tabelami zawierającymi po 60 skomplikowanych funkcji sinus/cosinus ze współczynnikami i 4-ma argumentami (co trzeba uważnie przepisać) liczonymi ze wzorów na bieżąco. Ufff... Tak więc dla wskazanego w książce momentu w czasie jest super. To się jednak znacząco zmienia, kiedy skrypt pobiera datę i czas z komputera, a wynik sprawdzam ze Stellarium. Błąd pojawia się już na etapie sprawdzenia długości λ i szerokości β, nie wspominając już o rektascensji α i deklinacji δ, co widać na zrzucie poniżej. O ile długość λ różni się o 2.5 minuty, a rektascensja α zaledwie o 15 sekund (!), o tyle zarówno szerokość β, jak i deklinacja δ róznią się już o około 33 minuty.

Transformacja współrzędnych dla opornych :): PozycjaKsiężyca.jpg


Może mam braki w teorii (z pewnością mam!), ale posługując się tą samą książką i podanymi w niej przykładami opracowałem moduł śledzenia Śłońca, który zgadza się z wynikami w książce dla podanego momentu w czasie (praktycznie dokładnie) i ze Stellarium dla czasu rzeczywistego z komputera (w granicach kilku sekund). Mogę przełączać skrypt dla Słońca i Księżyca, w tym samym czasie zmieniając obiekt w Stellarium, nie zmieniając żadnej konfiguracji, ani w komputerze, ani w Stellarium - efekt ciągle się utrzymuje: Słońce - OK, Księżyc - nie.

Co jest źle? Czy zapomniałem o jakimś parametrze w Stellarium? Czas i moje położenie mam wprowadzone dokładnie, wg współrzędnych.

Trochę pogrzebałem w sieci i znalazłem podobny wątek: "Are the coordinates of the moon wrong?" (https://answers.launchpad.net/stellariu ... ion/209330), gdzie w odpowiedzi na podobne pytanie gość otrzymuje: "I did some investigation and as results I can say: you are right, because Stellarium shows ecliptical topocentric coordinates, not ecliptical geocentric coordinates." Zatem, różnica jest między topocentrycznym układem współrzędnych (jego środek w miejscu obserwacji) i geocentrycznym układem współrzędnych (którego środek jest w środku Ziemi). Ale dlaczego nie przeszkadzało to w poprawnym wyliczeniu pozycji Słońca?

Nie przechodzę jeszcze na horyzontalny układ współrzędnych, więc moja lokalizacja nie może mieć tu jeszcze znaczenia, jak sądzę.

Proszę o podpowiedź.
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

PostVroobel | 19 Sty 2019, 01:23

Dla kontrastu - sprawdzenie pozycji Słońca:

Transformacja współrzędnych dla opornych :): PozycjaSłońca.jpg


Edit.
Dopiero teraz zauważyłem, że mam nieaktualną wersję Stellarium. Tzn. miałem. Szybka aktualizacja i oto ukazuje się włącznik topocentrycznego układu współrzędnych. Wyłączyłem ten parametr, po czym nagle wszystko zaczyna się zgadzać z dokładnością do kilku/kilkudziesięciu sekund, co mi w zupełności wyrtarcza. Pozostaje zatem dopisać kilka wzorów i można przenosić kod do Maliny. W przypadku sprawdzania pozycji Słońca nic się jakby nie zmienia.

Fajnie jest odpowiedzieć sobie samemu na pytanie. To się często zdarza, kiedy pytając o poradę i tłumacząc to, co robię, nagle doznaję olsnienia. To chyba działa tak, że wtedy widzę to, co robię, a nie to, co chcę uzyskać...

Mam nadzieję, że to się komuś przyda, bo książka Jeana Meeusa to jednak często polecana tu pozycja.
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

Poststarbee | 19 Sty 2019, 02:00

Vroobel napisał(a):Drodzy Koledzy (obojga płci), potrzebuję wsparcia teoretycznego - staram się znaleźć przyczynę błędnego wskazania pozycji Księżyca.

Już kilka dni siedzę nad książką "Astronomical Algorithms" i moim modułem oprogramowania do wyliczania pozycji Księżyca. Pierwsze kodowanie robię zwykle w PHP, potem przenoszę kod do Pythona na Raspberry Pi w teleskopie. Oczywiście na początek biorę przykład z książki (tu konkretnie 12/04/1992 00:00:00, co może jest ważne) i wynik mojego kodu pokazuje mi dokładnie to, co napisał autor książki:

λ = 133° 10' 2.12" (w książce jest 133° 10' 02")
β = -3° 13' 44.85" (w książce jest -3° 13' 45")

α = 8h 58m 45.14s (w książce jest 8h 58m 45.1s )
δ = +13° 46' 0.79" (w książce jest +13° 46' 06")

a więc nie mam tu praktycznie żadnego błędu, To ważne, bo w obliczeniach należy posłużyć się 3-ma tabelami zawierającymi po 60 skomplikowanych funkcji sinus/cosinus ze współczynnikami i 4-ma argumentami (co trzeba uważnie przepisać) liczonymi ze wzorów na bieżąco. Ufff... Tak więc dla wskazanego w książce momentu w czasie jest super. To się jednak znacząco zmienia, kiedy skrypt pobiera datę i czas z komputera, a wynik sprawdzam ze Stellarium. Błąd pojawia się już na etapie sprawdzenia długości λ i szerokości β, nie wspominając już o rektascensji α i deklinacji δ, co widać na zrzucie poniżej. O ile długość λ różni się o 2.5 minuty, a rektascensja α zaledwie o 15 sekund (!), o tyle zarówno szerokość β, jak i deklinacja δ róznią się już o około 33 minuty.

PozycjaKsiężyca.jpg


Może mam braki w teorii (z pewnością mam!), ale posługując się tą samą książką i podanymi w niej przykładami opracowałem moduł śledzenia Śłońca, który zgadza się z wynikami w książce dla podanego momentu w czasie (praktycznie dokładnie) i ze Stellarium dla czasu rzeczywistego z komputera (w granicach kilku sekund). Mogę przełączać skrypt dla Słońca i Księżyca, w tym samym czasie zmieniając obiekt w Stellarium, nie zmieniając żadnej konfiguracji, ani w komputerze, ani w Stellarium - efekt ciągle się utrzymuje: Słońce - OK, Księżyc - nie.

Co jest źle? Czy zapomniałem o jakimś parametrze w Stellarium? Czas i moje położenie mam wprowadzone dokładnie, wg współrzędnych.

Trochę pogrzebałem w sieci i znalazłem podobny wątek: "Are the coordinates of the moon wrong?" (https://answers.launchpad.net/stellariu ... ion/209330), gdzie w odpowiedzi na podobne pytanie gość otrzymuje: "I did some investigation and as results I can say: you are right, because Stellarium shows ecliptical topocentric coordinates, not ecliptical geocentric coordinates." Zatem, różnica jest między topocentrycznym układem współrzędnych (jego środek w miejscu obserwacji) i geocentrycznym układem współrzędnych (którego środek jest w środku Ziemi). Ale dlaczego nie przeszkadzało to w poprawnym wyliczeniu pozycji Słońca?

Nie przechodzę jeszcze na horyzontalny układ współrzędnych, więc moja lokalizacja nie może mieć tu jeszcze znaczenia, jak sądzę.

Proszę o podpowiedź.

Słońce jest odległe od Ziemi o 150 mln km, a Księżyc o niecałe 400 tys km, dlatego kąt paralaksy geocentrycznej dla Słońca jest kilkaset razy mniejszy niż dla Księżyca, a dla Księżyca wynosi on 57'.
ATM 12”/f5, ATM 8"/f7, BM N150/750, MTO 1000, Soligor RT 93/1000; bino: 16x80,10x50, 8x30
 
Posty: 18
Rejestracja: 22 Gru 2008, 12:56
Miejscowość: 50N20E

 

PostVroobel | 19 Sty 2019, 02:05

Tak właśnie to sobie tłumaczę.
Dziękuję za potwierdzenie prawidłowości mojego toku myślenia. :)
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

PostŁukasz_M | 24 Sty 2019, 12:07

Młody Padawanie...
Szczytna inicjatywa i dobre wyniki jednak realizacja strony cokolwiek nie właściwa. PHP jest wygodne ale zrobienie strony samo odświeżającej się co 1 sekundę bardzo obciąża serwer który jak widzę masz prawdopodobnie za darmo. Wystarczy, że Twoją stronę odwiedzi kilka osób na raz i od tak zapomną jej zamknąć i zajmą się czymś innym zostawiając zakładkę otwartą i zacznie to pewnie zawodzić bo serwer ( jego administrator) nie pozwoli Ci na takie obciążanie. Serwery są raczej optymalizowane do serwowania osobnym użytkownikom strony raz na kilkanaście sekund lub nawet minut.
Dodatkowo zwróc uwagę na fakt że wyniki są liczone w oparciu o czas serwera który jak widzę spóźnia się o jakieś 18-19 sekund w tej chwili więc porównywanie tego ze Stellarium działającym według czasu twojego PC już wprowadza różnicę w wynikach. Większość PC synchronizuje się z serwerami czasu NTP a twój serwer najwyraźniej dawno nie był synchronizowany.
W nagłówku strony main.php brakuje deklaracji <!DOCTYPE html> z kolei to co jest w nagłówku index.php jest lekko przestarzałe. Większość przeglądarek obsługuje HTML 5.
Przerób to na JavaScript żeby nie obciążać serwera i używać zegara w komputerze odbiorcy. Wtedy nabierze to nowej jakości.
Broń boże nie pisze tego żeby Cię zniechęcić tylko po to żeby podnieść jakość twojego pomysłu dzielenia się tym ze społecznością astromaniaków.
Pozdrawiam
Łukasz
-----------------------------------------------------------
gutta cavat lapidem non vi, sed saepe cadendo
hominis est errare, insipientis in errore perseverare
feci, quod potui, faciant meliora potentes
per aspera ad astra
Awatar użytkownika
 
Posty: 293
Rejestracja: 14 Paź 2013, 15:38

 

PostVroobel | 24 Sty 2019, 12:43

:)

Dziękuję.

Nie po raz pierwszy nazwano mnie tu Młodym Padawanem, ok, ale wielu z userow z pewnością jest młodszych ode mnie. Ja pamiętam strony internetowe, w których nie było prawie wcale lub nawet w ogóle PHP. Zrobiłem to jako taki sobie bajer, nie jako cel moich starań. Właściwie mogę tą stronę na *.epizy.com zamknąć. Fakt, czas na tym serwerze różni się od mojego, POMIMO synchronizacji z NTP i ustawienia właściwego przesunięcia związanego z krajem zamieszkania.

Tak więc, szkoda mi mojego cennego czasu na poprawki w PHP, którego używam jedynie dla przecwiczenia wzorów. Na moim osobistym XAMPP'ie postawionym na moim osobistym PC czas się zgadza z moim Stellarium. No, ale może tego nie napisałem wcześniej, mogłeś nie wiedzieć.

Celem samym w sobie jest Raspberry Pi i soft w Pythonie, który - jak opisuje w tym watku:

viewtopic.php?f=5&t=49956&p=476404#p476404

radzi sobie perfekcyjnie. 2h idealnie w punkcie to zaj*a precyzja, nawet jak na tak Młodego Padawana, nieprawdaż? :D ;)

Pozwalam sobie na drobniutką swobodę jezykową, ale to pikuś w porównaniu z niektórymi innymi ostatnimi wątkami tu obok... Mam nadzieję, że się nie obrazisz, bo Twoje rady są ok, są konkretne i doskonale się z nimi identyfikuje, jako osoba związana z IT.

Już przedwczoraj zdałem sobie sprawę, że serwer www nie jest mi już potrzebny do ćwiczeń nowych wyliczeń. Choć ma on ładnie i przejrzyście opracowane wyświetlanie wyników, to jednak muszę przekształcać później kod z PHP na Pythona, a to już zajmuje mój cenny czas. Tak więc właściwie tylko mnie do tego zmotywowales.

Jeśli ktoś będzie kiedykolwiek zainteresowany transformacją współrzędnych, to będzie wiedział gdzie mnie znaleźć, jeśli tylko będę mógł pomóc.

Obecnie są opracowane statyczne obiekty DS z uwzględnieniem ruchu własnego, precesji i refrakcji atmosfery oraz Słońce i Księżyc, pozostają jeszcze tylko planety do pełni mojej satysfakcji...
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

PostVroobel | 24 Sty 2019, 13:00

Dodam jeszcze tylko, że nie tylko czas jest dla mnie istotny. Nie jestem na bieżąco i nie ogarnę nowości w kilku różnych językach programowania. Łatwiej jest mi tą stronę zamknąć. Ale naprawdę dziękuję za sugestie.
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

PostŁukasz_M | 24 Sty 2019, 13:34

OK! Awnasujesz!! na Starszego Padawana :D a jak udostępnisz ten działający sprawnie kod całej społeczności to zostaniesz Jedi :D
Nie ma potrzeby usuwać tej strony jest OK choć zmieniłbym przynajmiej ten refresh na np 10 sekund skoro serwer nie trzyma czasu to nie zmieni to nic a odciąży Ci ten serwer. Można też szybko wprowadzić taką tymczasową poprawke czasu na te kilk sekund różnicy. To zajmie 2 minuty.
Pozdrawiam
Łukasz
-----------------------------------------------------------
gutta cavat lapidem non vi, sed saepe cadendo
hominis est errare, insipientis in errore perseverare
feci, quod potui, faciant meliora potentes
per aspera ad astra
Awatar użytkownika
 
Posty: 293
Rejestracja: 14 Paź 2013, 15:38

 

PostVroobel | 24 Sty 2019, 13:39

:D

Może i tak, ale musiałbym wtedy opracować całe to formatowanie wzorów na ekranie, na co nie za bardzo mam teraz ochotę.

Czeka mnie przebudowanie całego softu na Malinie i optymalizacja sterowania silnikami krokowymi, bo o ile działają poprawnie i sobie tam pyrkają razem z tymi moimi ogromnymi przekładniami ślimakowymi, o tyle w kontekście GoTo mogę się zestarzeć czekając na zmianę obiektu odległego o 180 st...
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

PostŁukasz_M | 24 Sty 2019, 13:57

Kod można udostępnić w postaci plików źródłowych jeśli masz tam opisy kodu. Osoby zainteresowane otworzą sobie to w PyCharm lub nawet notepad++ i jak będa się na tym znać to się połapią.
No tak obrót o wieksze kąty powinien trwać kilkanaście - kilkadziesiąt sekund
Pozdrawiam
Łukasz
-----------------------------------------------------------
gutta cavat lapidem non vi, sed saepe cadendo
hominis est errare, insipientis in errore perseverare
feci, quod potui, faciant meliora potentes
per aspera ad astra
Awatar użytkownika
 
Posty: 293
Rejestracja: 14 Paź 2013, 15:38

 

PostVroobel | 24 Sty 2019, 13:59

... a jak zmierzyłem czas pelnego obrotu w osi Az, to wyszło ok. 5 minut przy 200 krokach i 8 mikrokrokach. No i mam zagadkę...
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

PostŁukasz_M | 24 Sty 2019, 14:06

jka osiągniesz 30 sekund na pełen obrót to w połączeniu z obiektami 'bliskimi siebie' z punktu widzenie wspołrzędnych to będzie bardzo dobry wynik. czy twoje silniki, ślimacznice i zębatki wytrzymają 10x przyśpieszenie?
Pozdrawiam
Łukasz
-----------------------------------------------------------
gutta cavat lapidem non vi, sed saepe cadendo
hominis est errare, insipientis in errore perseverare
feci, quod potui, faciant meliora potentes
per aspera ad astra
Awatar użytkownika
 
Posty: 293
Rejestracja: 14 Paź 2013, 15:38

 

PostVroobel | 24 Sty 2019, 14:22

Wytrzymają, bo mam opracowaną tzw. rampę, czyli stopniowe przyspieszanie i zwalnianie. No, ale nie jestem pewien, co oferują dostępne biblioteki. Obecnie steruję "ręcznie" wyjścia GPIO RPi. Arduino, z którym zaczynałem przygodę, ma fajną bibliotekę do przyśpieszania i zwalniania. Muszę pogrzebać, ale to niestety potrwa.

Rozważałem też programowaną konfigurację jumperów sterowników A4988, mógłbym z poziomu Maliny przestawić silniki z 8 mikrokroków na pelne kroki, więc obrót zająłby naprawdę kilkadziesiąt sekund, ale boję się, że na etapie przełączania kroków zgubilbym informację o bieżącym położeniu.
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

Postxooon | 28 Sty 2019, 10:27

Witam!

Pomysł z przestawianiem kroku na sterowniku jest dość oczywisty pod warunkiem zachowania ilosci kroków w danej fazie w relacji modulo aktualnego podziału. Zmniejszenie mikrokroku o stopień to z reguły zwiększenie kroku 2 krotnie więc nawet jak nie uda się dokładnie policzyć ilości kroków brakujących do modulo aktualnego podziału to "zgubi się" co najwyżej połowę wartości podziału o stopień wyżej co pewnie nie ma znaczenia dla położenia teleskopu a po kilkukrotnym zastosowaniu może nawet uśredniać błąd przełączenia do zera. Reasumując, to procedura warta rozważenia.
Dla przybliżonej (ale bardzo realnej oceny) mozliwości dynamicznych napędu stosuję arkusz na stronie:
lx-net.pl/astrop/astrop.php
gdzie, po podstawieniu wartości przekładni uzyskuje się wynik w postaci danych o sterowaniu ale także slew max - maksymalna prędkośc pracy w trybie goto w danej konfiguracji mechaniczno - elektrycznej.
Przykładowo, dla mojej przekładni 1:625, silnika 1.8 stopnia i mikrokroku 1:16 uzyskuję:
- krok sterowania 0.685arcsec/krok
- slew_max - 689
- częstotliwośc sterowania ok. 22.3Hz

Slew_max 689 oznacza, że przybliżona, maksymalna predkośc sterowania wyniesie ok. 689 * 15.041arscec/sek = ok. 10363arcsec/sk czyli prawie 3 stopnie na sek.

xooon
Załączniki
Transformacja współrzędnych dla opornych :): astrop.png
 
Posty: 53
Rejestracja: 18 Maj 2017, 15:04

 

PostVroobel | 28 Sty 2019, 15:20

Ok, dzięki. U mnie jest tylko 1 przekładnia mechaniczna i 1 elektryczna, zarówno dla 8 mikrokroków, jak i dla pełnego kroku otrzymuję slew_max = 480, co daje ok 2*/sek. Ale z czym się to je? Ja nie mam AstroPolota, tylko pisany przez siebie soft oraz nie posiadam montażu paralaktycznego, tylko Dobsona. Mam wrażenie, że ta wiedza mi się nie przyda. Ale chętnie zrozumiem, jaki jest sens fizyczny parametru slew_max.

Ponadto mam wrażenie poparte próbami, że stosując "rampę" i pełny krok, mogę naprawdę szybko zmienić pozycje o 180*, dużo szybciej, niż w 1.5 minuty (2*/sek), o ile to dobrze zrozumiałem.
Pozdrawiam,
Vroobel

* Altair 102EDT F/7 @ Opus Magnum ATM EQ Fork Mount / OnStep / Astroberry
* Altair 102ED F/11 & Vixen A80M + bino @ EQ5

https://www.astrobin.com/users/Vroobel/
Awatar użytkownika
 
Posty: 2324
Rejestracja: 27 Maj 2017, 11:49

 

Postxooon | 28 Sty 2019, 15:51

Witam!

Program faktycznie napisany jest dla AstroPilota ale tylko w części dotyczącej ustawień tego sterownika (jego programowania na zadaną częstotliwość pracy)
Inne wyniki mają charakter uniwersalny jak np. krok sterownia, częstotliwośc sterowania i slew_max i dotyczą każdego napędu mającego określoną przekładnię mechaniczną, jakiś silnik krokowy i określone sterowanie mikrokrokowe.
Dlatego Twój wynik 480 jest jak najbardziej związany z Twoją konfiguracją mechaniczno - elektryczną i możesz się mniej więcej spodziewać, że nie uzyskasz większej prędkości w trybie goto niż 480*15.041arcsec/sek.
Możesz popróbować z innymi konfiguracjami sprawdzając jaki jest sens przeniesienia większości przełożenia na część elektryczną z cześci mechanicznej - podpowiem, że wzrasta slew_max a więc prędkość w trybie goto. I odwrotnie, olbrzymia przekładnia mechaniczna pozwala na użycie silnika krokowego o dużym kroku ale na przestawienia montażu o kilkanaście stopni będziesz czekał kilkanaście minut bo nie da się rozpędzić silnika krokowego w nieskończoność - podobnie jak są granice szybkości jazdy na rowerze lub samochodem. Oczywiście są pewne sposoby na akcję "turbo" - rówież dla silników krokowych ale są one trudniejsze w realizacji.

xooon
 
Posty: 53
Rejestracja: 18 Maj 2017, 15:04

 

ATM

Użytkownicy przeglądający to forum: Tomek8891 oraz 35 gości

AstroChat

Wejdź na chat