Raspberry Pi – cz. 1

Po kilku miesiącach od rozpoczęcia prac nad oprogramowaniem dla Raspberry Pi na spokojnie mogę zacząć pisać o tym maleńkim, bo w rozmiarze karty kredytowej, komputerku. Komputer to słowo nie na wyrost, ponieważ ma on na pokładzie 4-rdzeniowy 64-bitowy procesor taktowany zegarem 1.2GHz, 1GB RAM, slot na kartę microSD, grafikę HD z wyjściem HDMI full size, gniazdo RJ-45 i WiFi, Bluetooth 4-tej generacji, 4 porty USB 2.0, ale przede wszystkim kilkadziesiąt wejść/wyjść (GPIO), w tym obsługę magistrali I2C, oraz kilka nieco mniej istotnych dla mnie funkcji. Stoi obecnie na nim system Linux oparty na Debianie, dedykowany dla Maliny: Raspbian, a na nim serwer MySQL, oprogramowanie w PHP liczące współrzędne obiektów DS i Słońca, zaczątki zmodyfikowanej „Tabeli Wimera” w roli bazy danych obiektów oraz, co najważniejsze, oprogramowanie w języku Python do obsługi śledzenia obiektów, czyli trackingu. I to wszystko już działa ale mnóstwo jeszcze pracy przede mną, zanim osiągnę zadowalający mnie efekt. Ale od początku…

RaspberryPi

Z poprzedniego projektu opartego o Arduino została jedynie płytka z osadzonymi sterownikami silników krokowych A4988, wyświetlacz LCD 4×20 i kabelki. Przed uruchomieniem Rasperry Pi musiałem wyposażyć system w stabilizator napięcia (przetwornicę), który z 12V zasilania daje wymagane 5.1V. Pojawił się też pomysł użycia gamepad’a w technologii BT, co zbliża mnie do bezprzewodowości. Naturalnie zmieniło się również oprogramowanie, tym razem w języku Python, które ewoluowało od funkcji podstawowych, takich jak obsługa wyświetlacza, bazy danych w MySQL i BT do konkretnych funkcji odpowiedzialnych za poszczególne etapy procesu obserwacji i przygotowania się do niego. Zmienia się również zakres rodzajów obiektów, jakie zamierzam gromadzić w bazie danych. Ostatnia oryginalna wersja „Tabeli Wimera” zawiera atrakcyjne obiekty głębokiego nieba, jak gromady otwarte, galatkyki, mgławice, asteryzmy i układy wielokrotne, ale ja dorzucam od siebie listę jasnych gwiazd w roli „markerów” (które posłużą mi do kalibracji systemu automatycznego naprowadzania teleskopu na obiekt) oraz Słońce, a niebawem znajdą się tam również Księżyc i planety Układu Słonecznego. O ile mam już oprogramowane śledzenie ruchu Słońca po nieboskłonie, o tyle Księżyc i planety będą musiały poczekać, aż skończę wszystkie niezbędne funkcje. W kolejce czekają wyłączniki krańcowe osi Alt oraz motofocusera. Krańcówki osi Alt nie są krytyczne, najwyżej pasek zębaty przeskoczy na zębatce silnika, ale przeskakiwanie zębatki w wyciągu okularowym w jego krańcowych pozycjach może owocować koniecznością zakupu nowego wyciągu.

Kilka tygodni temu połączyłem Malinę z płytką sterowników, tzw. shield’em. Postanowiłem wykorzystać ten shield, ponieważ gromadzi on na swym pokładzie 3 gniazda sterowników i 3 zestawy jumper’ów do konfiguracji ilości mikrokroków na pełny krok silnika oraz wejście zasilania silników 12V. Wyjąłem Arduino z jego podstawki, odnalazłem piny odpowiedzialne za kierunki i kroki poszczególnych silników i parę innych wejść, następnie połączyłem je uniwersalnymi przewodami z wybranymi pinami GPIO Maliny. Przy okazji okazało się, że shield stale ma aktywne stany „enable”, więc bez przerabiania obwodu musiałem opracować inny sposób wyłączania silników: wystarczy odłączyć +5V z Maliny zasilające logikę sterowników. Obecnie, nie mając jeszcze opracowanego naprowadzania na cel, włączam w programie śledzenie wybranego obiektu i przy wyłączonych silnikach naprowadzam teleskop ręcznie, następnie podaję +5V, a wtedy silniki wykonują swoje mikrokroki, podążając za obiektem.

skrzynka

Pierwszego dnia bezchmurnego nieba wykonalem test na gwieździe Arktur, a kilka dni później zweryfikowałem wyniki na Wedze i układzie wielokrotnym Double Double w gwiazdozbiorze Lutni. Byłem zachwycony czasem utrzymywania się obiektu w polu widzenia teleskopu, jak na „pierwszy strzał”: obserwując wtedy Arktura móglbym cieszyć się widokiem gwiazdy średnio jakieś 25 minut w powiększeniu 51x, a Wegę i Double Double – po małej poprawce softu – mniej więcej tak samo długo, tyle że w ponad 4-krotnie większym powiększeniu, bo aż 211x. Jak łatwo policzyć, obiekt porusza się w polu okularu ponad 4-krotnie szybciej. Jak na amatorski, zbudowany od podstaw i bez specjalnego projektu napęd, to niezły wynik. Zupełnie wystarczający do tego, aby ustawić obiekt w środku pola i pokazać go komuś bez konieczności pilnowania, żeby nie uciekał. Obiekt, nie ten ktoś…

No, ale kiedy już nacieszyłem się utrzymywaniem się obiektu w polu, przyszło małe rozczarowanie: dokładność prowadzenia jest niezadowalająca. Obiekt skacze wokół swego średniego położenia, zamiast płynnie się przesuwać, gdyż liczba mikrokroków jest zbyt mała. Przypomnę, że w osi Az mam 139 tys. kroków na jeden pełny obrót teleskopu, a w osi Alt – nieco ponad 93 tys. To trochę mało. Dlatego właśnie na próbę zamówiłem na eBay dwa sterowniki DRV8825, które mają identyczne wyprowadzenia, jak A4988, ale zdaje się, że odwrócone fazy silnika, więc tylko odwrócę wtyczki. Sterowniki te pozwalają zdefiniować 32 mikrokroki. Zapewne znalazłyby się sterowniki o 64 mikrokrokach, ale wraz ze wzrostem mikrokroków maleje wartość momentu obrotowego i może dojść do sytuacji, że obciążony lekko nierównomiernie teleskop upadnie do pozycji poziomej, bo silnik nie utrzyma go swą samohamownością. Jeśli wymiana sterowników nie da zadowalających efektów, to wymienię silniki na identyczne, tyle że z krokiem podstawowym 0.9°, a nie 1.8°, jak dotychczas. To będzie dawało 400 kroków na pełny obrót silnika, a nie 200, a zatem, w najlepszym przypadku uzyskam 400×32=12800 mikrokroków (przy obecnych 3200), a co dalej idzie, około 550400 kroków na pełny obrót teleskopu, zamiast 139000! To już z pewnością powinno wystarczyć.

OK, niezależnie od tego, ile minut obiekt utrzymuje się w okularze, czy kamerze, nie utrzymuje się stale. Śledzenie = załączone silniki, więc nie mogę ot tak sobie przesunąć teleskopu, żeby obiekt znów znalazł się w centrum pola. Przyszła więc pora na funkcję korekty pozycji o 1 mikrokrok w każdą stronę. To samo dotyczy motofocuser’a – kiedy prowadzenie jest włączone i zachce mi się wstawić soczewkę Barlow’a, zmienić okular lub zastąpić go kamerą LifeCam Studio, nie jestem w stanie ustawić ostrości. Wprowadziłem więc mikroruchy w osi Az i Alt wykorzystując istniejący w kontrolerze BT grzybek oraz regulację ostrości z użyciem dwóch nie używanych w czasie prowadzenia przycisków. Pojedyncze naciśnięcie każdego z tych przycisków powoduje wykonanie przez silnik 1 mikrokroku.

20180508_071117

Właściwie pozostał mi jeszcze jeden nie używany dotąd przycisk i zanim zdałem sobie z tego sprawę, miałem już dla niego zastosowanie. Okazało się bowiem, że ostrzenie krok po kroku przy zmianie, jaką jest dodanie Barlow’a, jest niewykonalne, bo trzeba np. przejść z jednego prawie krańcowego położenia wyciągu do drugiego. Niezbędna stała się funkcja wykonująca określoną liczbę kroków. To bardzo ważna funkcja, która znajdzie zastosowanie w pracach nad GOTO. Na tym etapie potrzebne jest rozpędzenie silnika od 0 do prędkości pozwalającej na w miarę szybkie pokonanie odległości (lub kąta), co zajmie jakąś liczbę mikrokroków, utrzymanie tej maksymalnej prędkości przez kolejna liczbę kroków (zwykle dużo większą) i wyhamowanie silnika w sposób analogiczny do rozpędzania. Rozpędzanie i hamowanie uzyskałem angażując odpowiednio po 200 kroków w funkcję 1/x oraz 1/(200-x), dlatego proces ten ma sens dla przebiegów większych lub równych 400 kroków. Te nieliniowe funkcje sprawują się wyśmienicie i nie powodują szarpania, ale rozważałem różne inne funkcje, jak sinus, czy odwrotność kwadratu. Tak więc, po naciśnięciu pewnego przycisku każdy impuls dla focusera kończy się 400-ma krokami, w obu kierunkach. Okazało się to bardzo przydatną w praktyce funkcją.

Po blisko dwóch miesiącach zabawy z Maliną pora podsumować oprogramowanie:

  • Całkowite uniezależnienie od klawiatury, myszy, ekranu i innego komputera, autostart oprogramowania,
  • Oczekiwanie na włączenie kontrolera BT,
  • Setup w postaci menu w oparciu o kontroler BT i LCD 4×20 znaków,
  • „Tabela Wimera” jako źródło atrakcyjnych obiektów głębokiego nieba w postaci bazy danych MySQL, odczyt danych z bazy,
  • 3-poziomowy wybór obiektu (gwiazdy w roli „markerów”, Słońce i wybrane do testow obiekty głębokiego nieba z „Tabeli Wimera”),
  • Proces obliczania pozycji obiektu z dokładnością kilku-kilkudziesięciu sekund kątowych, wyświetlanie współrzędnych Az i Alt na LCD,
  • Sterowanie silnikami krokowymi – śledzenie obiektu zgodnie z obliczeniem powyżej, pozwalające na około 25-minutowe utrzymanie obiektu w polu okularu przy powiększeniu 211x,
  • Funkcja ręcznej korekty położenia obiektu w polu okularu/kamery,
  • Obsługa focusera (zgrubna i dokładna),
  • Obsługa wznowienia programu po wyjściu z niego,
  • Obsługa bezpiecznego zamknięcia systemu Raspbian po zakończeniu obserwacji.

Pozostało do zrobienia:

  • Poprawienie dokładności prowadzenia poprzez wymianę sterowników A4988 na DRV8825, ewentualnie dodatkowo wymiana silników 200- na 400-krokowe,
  • Obsługa wyłączników krańcowych focusera i osi Alt,
  • GOTO, czyli kalibracja i samodzielne ustawienie teleskopu na wybrany z bazy cel,
  • Uzupełnienie bazy danych wszystkimi obiektami z ostatniej wersji „Tabeli Wimera” i dodatkowo danymi o rocznym ruchu własnym obiektów DS,
  • Opracowanie kolejnych części oprogramowania odpowiedzialnych za ruch Księżyca i planet,
  • Ograniczenie wyboru obiektów do ram czasowych podanych w Tabeli przez Wimera,
  • Zakup i obsługa przyzwoitego odbiornika GPS, jako źródło bieżącego położenia i czasu,
  • Wprowadzenie anglojęzycznych opisów do bazy obiektów,
  • Wymiana niebiesko-białego LCD 4×20 na czerwony lub wyposażenie istniejącego w czerwony filtr, ewentualnie wymiana LCD na wyświetlacz OLED z powodu ograniczenia miejsca i sporej bezwładnosci,
  • Mocowanie i lutowanie komponentów na stałe, w tym wyświetlacza (docelowego) w wieku skrzynki na elektronikę,
  • Setup w języku angielskim.
Reklamy