Akwizycja i przetwarzanie obrazów w systemie do profesjonalnych badań astronomicznych

Transkrypt

1 Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Systemów Elektronicznych Michał Jegier Nr albumu Praca dyplomowa magisterska Akwizycja i przetwarzanie obrazów w systemie do profesjonalnych badań astronomicznych Promotor pracy: Dr inż. Krzysztof Poźniak Warszawa 2006

2 Streszczenie Akwizycja i przetwarzanie obrazów w systemie do profesjonalnych badań astronomicznych Nowe podejście w badaniach astronomicznych polega na monitorowaniu dużych obszarów nieba z dużą rozdzielczością czasową, co umożliwia badanie szybkozmiennych obiektów astronomicznych. Różni się ono od podejścia tradycyjnego, w którym rejestrowany jest bardzo mały wycinek nieba, a czas naświetlania jest bardzo długi. Nowe podejście reprezentuje projekt Pi of the Sky, którego głównym zadaniem jest badanie błysków optycznych stowarzyszonych z błyskami promieniowania gamma, które należą do klasy obiektów szybkozmiennych pojawiają się w losowych punktach całego nieba i trwają zazwyczaj kilka sekund. Zadanie to wymagało skonstruowania odpowiedniego sprzętu, który monitorowałby dużą część nieba oraz opracowania oprogramowania, które byłoby zdolne do transferu i analizy dużego strumienia danych. Niniejsza praca stanowi realizację części systemu oprogramowania projektu Pi of the Sky, odpowiedzialnej za sterowanie systemem akwizycji danych i transfer danych. Zaprezentowane zostały także metody przetwarzania i polepszania jakości zarejestrowanych obrazów, a także procedury ich graficznej wizualizacji. 2

3 Abstract Image acquisition and processing in professional astronomical survey system New approach in astronomical surveys is based on monitoring of large part of the sky with high temporal resolution, what enables studying of fast variable astronomical objects. This approach is the opposite to the traditional one, in which small part of the sky is observed and the exposition time is very long. New approach is represented also by the Pi of the Sky project. It s main goal is to study optical flashes following gamma-ray bursts. These flashes are fast-variable phenomena they appear randomly in the sky and last usually a few seconds. To fulfill the project s goal it was necessary to construct an appropriate equipment to monitor large part of the sky and software to transfer and analyze large stream of data. This thesis presents realization of part of software for the Pi of the Sky project, that is responsible for data acquisition system control and data transfer. Also methods for processing, improving the quality and graphical visualization of the acquired images are presented. 3

4 Spis treści 1. WSTĘP Błyski promieniowania gamma Historia obserwacji Perspektywa obserwacji naziemnych Koncepcja eksperymentu Pi of the Sky Przegląd rozwiązań dotyczących sprzętu stosowanych w profesjonalnych instrumentach pomiarowych w astronomii Konstrukcja mechaniczna teleskopu w projekcie Pi of the Sky i konstrukcja podzespołów elektronicznych Przegląd rozwiązań dotyczących oprogramowania stosowanych w profesjonalnych instrumentach pomiarowych w astronomii Oprogramowanie teleskopu w projekcie Pi of the Sky GENEZA, CEL I ZAŁOŻENIA PRACY Założenia ogólne dotyczące sprzętu i oprogramowania System operacyjny Protokół komunikacji Założenia dotyczące modułów opracowanego oprogramowania System komunikacji, sterownik urządzenia USB dla systemu Linux Program do obsługi kamer Program do nakładania na siebie obrazów Interfejs graficzny KONCEPCJA PRACY Sterownik urządzenia USB w systemie Linux Program do obsługi kamer Program do nakładania na siebie obrazów Interfejs graficzny REALIZACJA SYSTEMU KOMUNIKACJI KAMERY Z KOMPUTEREM Podstawy użytkowania sterowników w systemie Linux. Skrypty startowe Klasy urządzeń Pliki urządzeń. Numer główny (major) i podrzędny (minor) urządzenia System plików urządzeń Ładowanie i odładowanie sterownika Implementacja sterownika w systemie Linux Kompilacja sterownika Modułowa budowa jądra Licznik użycia modułu Urządzenia USB i ich obsługa w jądrze systemu Linux Podstawowe funkcje zaimplementowane w sterowniku Funkcje wspomagające debugowanie Tryb jądra i użytkownika Czasomierze w jądrze systemu Linux i odświeżanie watchdoga urządzenia Implementacja funkcji ioctl w sterowniku Debugowanie i testowanie sterownika

5 5. REALIZACJA PROGRAMU DO OBSŁUGI KAMER Implementacja nakładki i programu do obsługi kamer Testowanie i debugowanie programu REALIZACJA PROGRAMU DO NAKŁADANIA NA SIEBIE OBRAZÓW Ogólny sposób postępowania i wykorzystania algorytmów Podstawowe uwarunkowania dla algorytmów uśredniania obrazów Algorytmy Algorytm znajdowania przyporządkowania gwiazd pomiędzy dwoma obrazami Algorytm transformujący obraz Obsługa i uruchamianie programu Testowanie i wyniki działania programu Podsumowanie REALIZACJA INTERFEJSU GRAFICZNEGO DO PRZEGLĄDANIA OBRAZÓW Opis implementacji interfejsu graficznego Opis klas i komponentów Klasa MyComponent i JScrollPane Klasa ImagePanel Java Native Interface Java Web Start Obsługa programu Testowanie i debugowanie programu Podsumowanie TESTY SYSTEMU Obserwacje błysków Obserwacje gwiazd zmiennych Obserwacje meteorów Podsumowanie PODSUMOWANIE PODZIĘKOWANIA LITERATURA DODATKI Użycie zmiennych symbolicznych i wyprowadzenie wzorów użytych w programie do nakładania obrazów Spis komend programu do nakładania obrazów Spis rysunków Spis tabel

6 1. Wstęp Aktualny trend w budowie instrumentów pomiarowych w astronomii polega na konstruowaniu teleskopów, które mają coraz większą siłę rozdzielczą, powiększenie i zasięg. Obrazy rejestrowane przez teleskopy stanowią odwzorowanie bardzo niewielkich wycinków nieba. Teleskopy zwierciadlane mając coraz większą średnicę lustra, sięgającą już dziesiątek metrów, muszą stanowić bardzo duże, wielotonowe konstrukcje. Teleskopy te osiągają bardzo dobre parametry nie tylko dzięki swojej konstrukcji, ale także dzięki długiemu czasowi naświetlania. Skala czasowa zarejestrowanych zjawisk jest rzędu kilkudziesięciu sekund, albo minut. Wszystko to powoduje, że możliwe jest monitorowanie tylko niewielkiego obszaru nieba, w sposób statyczny, korzystając z wcześniej ustalonego harmonogramu obserwacji. Tymczasem istnieje cała klasa zjawisk astronomicznych, które umykają dotychczasowym metodom badawczym. Zachodzą one losowo na całym niebie i mogą znaleźć się w polu widzenia dużych teleskopów tylko przez przypadek. Zjawiska te trwają bardzo krótko i z powodu dużej bezwładności teleskopów bardzo trudno nakierować je w punkt nieba, w którym zjawiska te wystąpiły, nie wspominając o tym, że w większości pozostają one niezauważone. Zjawiska te obejmują gwiazdy szybkozmienne, poszukiwanie asteroidów zbliżających się do Ziemi, wybuchy supernowych i poświaty optyczne po błyskach promieniowania gamma. W celu rejestracji tych obiektów konieczne jest monitorowanie całego nieba, z odpowiednio krótkim czasem naświetlania. Ogromny postęp techniczny pozwala na zrealizowanie tego celu. Zbudowany w projekcie Pi of the Sky [1] zespół teleskopów soczewkowych (lunet) umożliwia obejście opisanych ograniczeń cechujących duże teleskopy. Dzięki odpowiedniemu 6

7 oprogramowaniu i sprzętowi możliwe jest monitorowanie całego nieba albo szybkie nakierowywanie zespołu teleskopów na żądany punkt nieba oraz odpowiednia selekcja i redukcja ilości danych odrzucanie danych niepotrzebnych, co przy obserwacji całego nieba staje się podstawowym problemem. System ten został zaprojektowany w celu rozwiązania jednej z obecnie najbardziej nurtujących tajemnic astronomii: zjawiska błysków promieniowania gamma Błyski promieniowania gamma Błyski promieniowania gamma (ang. Gamma Ray Bursts, GRB) to zjawiska astronomiczne, których charakterystyczną cechą jest emisja wysokoenergetycznego promieniowania gamma. Zjawiska te pod względem ilości wypromieniowanej energii są najpotężniejszymi znanymi zjawiskami we Wszechświecie. Przy założeniu, że źródło emituje promieniowanie w sposób izotropowy, energia promieniowania szacowana jest na w przybliżeniu J [2] podczas maksymalnie kilkuset sekund. Dla porównania energię podobnej wielkości Słońce wypromieniowuje podczas całego swojego życia (ok. 10 miliardów lat). Długość błysku gamma wynosi zaś od 0,01 sekundy do kilkuset sekund. Obecnie wykrywa się około 1 błysku dziennie, co ma także odbicie w sposobie oznaczania błysków: błysk oznacza się literami GRB, a następnie podaje się datę w formacie rok-miesiącdzień. Jeśli wykryto dwa błyski w ciągu tego samego dnia, dodaje się przyrostek A dla pierwszego błysku, B dla drugiego, itd. Szacuje się, że błysków jest w rzeczywistości 2-3 dziennie, tylko niektóre nie są rejestrowane. Charakterystykę błysków gamma ustalano przez wiele lat podczas żmudnych obserwacji, co opisano w rozdziale 1.2. Ustalono między innymi, że chociaż większość energii błysku jest niesiona przez promieniowanie gamma, występuje także promieniowanie o większej długości fali w zakresie fal rentgenowskich, zakresie widzialnym i zakresie fal radiowych. Charakterystyki błysków są bardzo zróżnicowane, co pokazuje rys. 1. Błyski dzielą się na dwie grupy: dłuższe (powyżej 2 sekund) i krótsze (poniżej 2 sekund) (rys. 4). 7

8 Rys. 1. Przykładowe wykresy natężenia promieniowania gamma obiektów GRB w zależności od czasu. Źródło: [3]. Stworzono wiele modeli próbujących wyjaśnić, dlaczego tak ogromne energie są wypromieniowywane w tak krótkim czasie, a także w jaki sposób powstają poświaty w innych zakresach promieniowania. Wspólną częścią tych modeli jest powtarzanie następującego schematu: wpierw występuje zjawisko o charakterze zderzenia dwóch obiektów astronomicznych lub implozji jednego obiektu prowadzące do wyemitowania dużych ilości energii, a następnie energia ta jest przekształcana w promieniowanie gamma i w promieniowanie w zakresie rentgenowskim, widzialnym i radiowym. W przypadku grupy krótszych błysków gamma najbardziej popularny jest model tzw. centralnego silnika [2]. Model ten zakłada, że dochodzi do zderzenia dwóch gwiazd neutronowych, dwóch czarnych dziur lub gwiazdy neutronowej i czarnej dziury, obracających się wcześniej wokół siebie w układzie podwójnym. Powstaje pojedyncza czarna dziura otoczona dyskiem materii. W czarnej dziurze i w dysku materii jest zmagazynowana przeogromna ilość energii. Materia z dysku jest następnie formowana w dżety (strumienie) materii w postaci plazmy (rys. 2). Dokładny sposób formowania jest przedmiotem spekulacji swoją rolę pełnić tu może pole magnetyczne i rotacja czarnej dziury. Formowanie ma w każdym razie charakter eksplozji wyrzucającej materię z prędkością bliską prędkości światła. W dżetach mogą znajdować się szybsze i wolniejsze fale materii, które po zderzeniu się ze sobą emitują promieniowanie gamma. Model, w którym występują dżety materii i promieniowania, a nie promieniowanie emitowane w sposób izotropowy, znalazł potwierdzenie w obserwacjach specyficznych zmian natężenia światła poświat optycznych niektórych błysków gamma. W przypadku dłuższych błysków najbardziej prawdopodobny jest model zakładający, że promieniowanie gamma powstaje podczas eksplozji bardzo 8

9 masywnych gwiazd jako supernowych i przekształcenie się ich w gwiazdy neutronowe lub czarne dziury (model istnieje także w wersji z produkcją dżetów materii). Ten model został potwierdzony przez obserwacje widma promieniowania zakresu widzialnego i znalezienie linii absorpcyjnych charakterystycznych dla supernowych (rys. 3). Rys. 2. Wybuch supernowej połączony ze zjawiskiem błysku gamma wizja artysty. Widoczne dwa dżety materii i promieniowania oraz dysk akreacyjny. Źródło:[4]. Rys. 3. Wykres analizy widmowej promieniowania w zakresie optycznym dla GRB i dla dwóch supernowych. Widoczne duże podobieństwo kształtu charakterystyk promieniowania. Źródło: [2]. 9

10 Pozytywne zweryfikowanie pewnych modeli lub ich odrzucenie może nastąpić jednak dopiero po dokonaniu odpowiednich obserwacji w większej ilości tak, aby można było znaleźć statystyczne właściwości badanych zjawisk Historia obserwacji Historia obserwacji błysków promieniowania gamma rozpoczęła się 2 czerwca 1967 roku, gdy jeden z satelitów wojskowych VELA wykrył promieniowanie gamma. Satelity te były zaprojektowane do wykrywania prób łamania zakazu testów broni jądrowej w kosmosie. Jednak kształt impulsu promieniowania gamma był inny, niż przewidywany dla wybuchu jądrowego. Astronomowie zaczęli szukać odpowiedzi na podstawowe pytania: gdzie występują zjawiska błysków gamma (w naszej galaktyce, czy poza nią), jakie są źródła promieniowania gamma i w jaki sposób wypromieniowywana jest energia w postaci promieniowania gamma. Aby odpowiedzieć na te pytania, powstało wiele teorii, a każda odmienna od poprzedniej. W 1978 roku satelity posiadające detektory promieniowania gamma połączono w tzw. sieć międzyplanetarną. Dane z tych satelitów uzupełniały się nawzajem. Do sieci tej zostały dołączone wtedy: Prognoz 7 (ZSSR), Helios 2 (Niemcy), Pioneer Venus Orbiter (USA), Wenera 11 i 12 (ZSSR), Kosmos (ZSSR), Vela 5 i 6 (USA). Sieć ta działa do dzisiaj i dostarcza wyniki, korzystając z danych z różnych innych satelitów, które były umieszczane w kosmosie. Wyniki te jednak nie dostarczyły wiedzy o śródgalaktycznym lub pozagalaktycznym pochodzeniu błysków gamma. Prawdziwy przełom nastąpił dopiero w 1991 roku, gdy pracę zaczęły instrumenty BATSE, umieszczone na satelicie CGRO (Compton Gamma Ray Observatory). BATSE pozwolił na dokładne zmierzenie kształtów i czasów trwania impulsów promieniowania i pokazał, że są one zróżnicowane. Pozwoliło to na wyznaczenie rozkładu czasów trwania błysków gamma. Okazało się, że można zaliczyć je do dwóch grup: do grupy o czasie trwania poniżej 2 sekund, w której najwięcej błysków miało czas trwania równy 0,3 sekundy i do grupy o czasie trwania powyżej 2 sekund, w której najwięcej błysków miało czas trwania równy 50 sekund (rys. 4). Promieniowanie w grupie krótszych błysków jest twardsze (ma wyższą energię). 10

11 Rys. 4. Rozkład czasu trwania błysków GRB. Źródło: [5]. Ważną cechą instrumentów BATSE była precyzyjność pomiaru położenia błysku gamma sięgająca 4 do 10 stopni. Pozwoliło to na wyznaczenie rozkładu występowania błysków na niebie. Rozkład ten okazał się być izotropowy (rys. 5). Było to prawie ostatecznym argumentem za pozagalaktycznym pochodzeniem błysków gamma (pochodzenie śródgalaktyczne odznaczałoby się rozkładem błysków na niebie skupionym wokół naszej galaktyki, Drogi Mlecznej). Rys. 5. Rozkład błysków zarejestrowanych przez satelitę BATSE na niebie. Źródło: [6]. 11

12 Kolejny przełom nastąpił dzięki satelicie BepoSax wystrzelonym w 1996 roku. Był on wyposażony w detektor promieniowania gamma, kamerę rentgenowską szerokokątną (40 stopni) i precyzyjną (o rozdzielczości 3 minut kątowych). Ten zestaw instrumentów umożliwił zaobserwowanie po raz pierwszy poświaty w zakresie promieniowania rentgenowskiego. Później za pomocą kamery precyzyjnej wyznaczono precyzyjne położenie błysku GRB970508, co umożliwiło teleskopom naziemnym zaobserwowanie poświaty radiowej i poświaty w zakresie widzialnym. Ta obserwacja umożliwiła pomiar przesunięcia widma ku czerwieni 1, a wynik pomiaru był jednoznacznym dowodem, że błyski gamma są pochodzenia pozagalaktycznego. Zmierzone charakterystyki kolejnych błysków (zarówno charakterystyki natężenia promieniowania, jak i widma) utwierdziły astronomów w przekonaniu, że błyski gamma o czasie trwania powyżej 10 sekund pochodzą od wybuchu supernowych. Informacje z tego satelity były transmitowane przez sieć dystrybucji współrzędnych GRB (Grb Coordinate Network, GCN). Sieć ta ma za zadanie alarmowanie o przypadkach wystąpienia zjawiska błysku gamma wszystkich zainteresowanych. Alarmy te (inaczej trygery) pochodzą z wielu źródeł (rys. 6). Sieć GCN działa do dzisiaj. Rys. 6. Rysunek poglądowy struktury sieci GCN. Źródło: [7]. 1 przesunięcie ku czerwieni zjawisko obserwowane w astronomii polegające na tym, że linie widmowe docierające z odległych obiektów astronomicznych są przesunięte ku czerwieni głównie wskutek rozszerzania się Wszechświata. Zjawisko to wykorzystano do pomiaru odległości na odległościach kosmologicznych. Przesunięcie jest wprost proporcjonalne do odległości od obiektu i można wyrazić je wzorem z = λ O / λ E -1, gdzie λ O to długość fali obserwowanego prążka widma, λ E to długość fali prążka widma emitowanego przez obiekt. Obecnie najdalsze obserwowalne obiekty we Wszechświecie posiadają z równe ok. 10 i więcej. 12

13 Satelitami rejestrującymi promieniowanie gamma były także HETE-2 i Integral. W 2004 roku zaczął działać satelita Swift, specjalnie przeznaczony do badania błysków gamma. Jest on wyposażony w trzy instrumenty: detektor promieniowania gamma (pole widzenia: 2 steradiany), detektor promieniowania rentgenowskiego (o rozdzielczości 4 minut kątowych) oraz teleskop zakresu widzialnego i ultrafioletowego. Działanie satelity jest następujące: w ciągu kilku sekund satelita potrafi ustalić położenie błysku na podstawie danych z detektora gamma i detektora promieniowania rentgenowskiego. Wtedy teleskop jest nakierowywany na to położenie i w ciągu sekund wykonywane są zdjęcia w zakresie widzialnym. Użyteczność teleskopu jest ograniczona przez zbyt długi czas nakierowywania teleskopu i jego zdolność do wykrywania gwiazd tylko do 17 magnitudo 2. Nie jest więc możliwe wykrywanie poświaty widzialnej krótkich błysków gamma. Tym niemniej ten satelita jest doskonałym źródłem trygerów dla innych instrumentów przede wszystkim naziemnych Perspektywa obserwacji naziemnych Obserwacje naziemne błysków gamma nie mogą być prowadzone w zakresie promieniowania gamma zakres gamma jest całkowicie tłumiony przez atmosferę, Całkowite tłumienie dotyczy także zakresu promieniowania rentgenowskiego i ultrafioletowego. Możliwa jest tylko obserwacja poświat błysku w zakresie widzialnym i radiowym. Obserwacje takie są ważne, gdyż dostarczają informacji, których nie da się wywnioskować tylko z zarejestrowanego promieniowania gamma. Przykładowo obserwacje poświaty błysku w zakresie widzialnym pozwalają na bardzo dokładne znalezienie położenia błysku na niebie (bardzo dobra rozdzielczość przestrzenna instrumentów optycznych, w przeciwieństwie do detektorów gamma). Obserwacje widma poświaty umożliwiają więc stwierdzenie, że błysk pochodzi od danego obiektu astronomicznego, np. supernowej. Umożliwiają także pomiar przesunięcia widma ku czerwieni, a więc pomiar odległości obiektu. 2 magnitudo jednostka miary stosowana w astronomii do oznaczania jasności gwiazd. Inne oznaczenia tej wielkości to mag, m lub m. Polska nazwa to wielkość gwiazdowa. Według definicji m = m R 2,5 log I/I R, gdzie m R to jasność obserwowana gwiazdy odniesienia, I R to obserwowane natężenie światła gwiazdy odniesienia, I to obserwowane natężenie światła rozpatrywanej gwiazdy. Przykładowe jasności ciał niebieskich w tych jednostkach: Słońce: -26 m, Księżyc w pełni -13 m, najjaśniejsza gwiazda na niebie - Syriusz: -1,44 m, gwiazda najbliższa Słońca - Proxima Centauri: 11 m. 13

14 Takich obserwacji dokonują teleskopy optyczne. Pole widzenia tradycyjnych teleskopów jest bardzo wąskie, co oznacza, że muszą one być nakierowywane na konkretny punkt na niebie. Współrzędne tego punktu są przekazywane z satelity podczas generowania trygera. Przesuwanie wielotonowych konstrukcji teleskopów zajmuje dłuższy czas. W końcu czas naświetlania musi być długi, aby uzyskać odpowiednią jakość obrazu / uzyskać naświetlenie odpowiednie dla zarejestrowania nawet słabszych obiektów. Tak więc w przypadku wykrycia błysku gamma następuje cały proces podejmowania decyzji o wygenerowaniu trygera, nakierowaniu teleskopu i zarejestrowaniu obrazu. Wszystko to powoduje, że od momentu pojawienia się błysku do zarejestrowania poświaty optycznej może upłynąć od kilku minut nawet do kilku godzin. Po takim czasie możliwe jest, że poświata optyczna całkowicie zaniknie (w tym przypadku długie czasy naświetlania są właściwie korzystne, ponieważ można zaobserwować słabsze obiekty). Pomimo kilkudziesięciu obserwacji poświaty optycznej, obserwacje te wciąż dotyczą drugiej grupy błysków tych o czasie trwania powyżej 2 sekund. Właśnie tę lukę w obserwacjach mają wypełnić małe teleskopy zautomatyzowane. Obecnie teleskopy takie są eksploatowane w ramach eksperymentów BOOTES [8], MASTER [9], RAPTOR [10] i ROTSE [11] (rys. 7). Teleskopy te mają optykę o krótkiej ogniskowej i mają szerokie pole widzenia. Czekają one na trygery z sieci GCN i potrafią szybko nakierować się na dany punkt na niebie. Dokładność nakierowania nie musi być duża z powodu ich szerokiego pola widzenia. Także czułość nie musi być bardzo duża obserwacje mają następować bardzo szybko po trygerze, a więc wtedy, gdy poświata optyczna ma jeszcze duże natężenie. Jednakże do tej pory jedyna udana obserwacja poświaty krótkiego błysku gamma była dokonana przez ROTSE dla błysku GRB

15 Rys. 7. Teleskop eksperymentu ROTSE. Okazuje się, że chociaż bezwładność małych teleskopów nie stanowi już dużej przeszkody, to występuje nadal duże opóźnienie przy rozsyłaniu sygnału trygera z satelity w sieci GCN. Ponadto nawet małe automatyczne teleskopy nie pozwalają na dokonanie obserwacji poświaty optycznej podczas błysku gamma i obszaru nieba przed błyskiem. Obserwacje te są kluczowe dla rozstrzygnięcia, jaki jest prawidłowy model powstawania zjawiska błysków gamma. Właśnie dlatego potrzebne jest nowe podejście do obserwacji polegające na wykorzystaniu własnego trygera błysku Koncepcja eksperymentu Pi of the Sky Głównym celem eksperymentu Pi of the Sky jest opracowanie metod badania poświaty optycznej błysków gamma z rozdzielczością czasową rzędu sekund. Do tego celu służy teleskop automatyczny, którego kamery w wersji docelowej będą miały w swoim polu widzenia prawie całe niebo nad horyzontem (w opisywanej wersji prototypowej 20 stopni x 20 stopni). W odróżnieniu od innych małych teleskopów, których cel naukowy jest podobny, teleskop użyty w projekcie ma możliwość prowadzenia obserwacji błysków wykrytych samodzielnie z własnego trygera błysku, a nie tylko obserwacji błysków, dla których został wygenerowany 15

16 tryger z satelity. Cel ten osiągnięto przez ciągłe monitorowanie całego obszaru nieba i wykrywanie zjawisk mających znamiona błysku. Wykrywanie błysków napotyka na olbrzymie trudności. W założeniu wystarczy sprawdzić, czy na obecnej klatce znajduje się obiekt (gwiazda), którego nie było na poprzednich klatkach. Jednak na niebie można zaobserwować wiele zjawisk, które wyglądają podobnie do tych poszukiwanych. Skala wystąpień zjawisk, których wykrywanie nie jest celem eksperymentu, jest o wiele rzędów wyższa od wystąpień zjawisk pożądanych. Do zjawisk niepożądanych należą: zjawiska naturalne: wpływ promieniowania kosmicznego na czujnik CCD, meteory, planetoidy, księżyc, chmury przesłaniające i odsłaniające gwiazdy, co pozoruje błysk zjawiska spowodowane działalnością człowieka: światła przelatujących samolotów, refleksy światła słonecznego od satelitów. Na normalnym zdjęciu nieba pozyskiwanym w projekcie znajduje się także około gwiazd. Metody obróbki tego olbrzymiego strumienia danych dotyczącego obiektów znajdujących się na zdjęciu są oparte na doświadczeniach pochodzących z eksperymentów fizyki cząstek elementarnych. W eksperymentach tych wykorzystuje się wielostopniowy system redukcji danych. Na pierwszych stopniach systemu redukcji danych ze strumienia danych odrzucane są przypadki, które bezbłędnie i szybko można zakwalifikować jako nieinteresujące. Każdy kolejny stopień zajmuje się przypadkami coraz trudniejszymi do analizy, a analiza pojedynczego przypadku trwa coraz dłużej. Dłuższa analiza pojedynczego przypadku jest dopuszczalna, ponieważ liczba przypadków w strumieniu danych się zmniejsza. Po rozpoznaniu danego zdarzenia jako błysk zachowywane są odpowiednie dane dotyczące błysku wraz z odpowiednimi fragmentami zdjęcia nieba, na którym błysk występuje. Tryger z satelity pełni w tym przypadku tylko rolę potwierdzenia wystąpienia błysku. Zbudowany teleskop składający się z dwóch kamer ma charakter prototypowy. Docelowo niebo ma obserwować instrument składający się z 2 zespołów (co zapewnia koincydencję, patrz poniżej) po 16 kamer. Całkowite pole widzenia tego instrumentu obejmować będzie ponad π steradianów, stąd nazwa projektu Pi of the Sky. 16

17 1.5. Przegląd rozwiązań dotyczących sprzętu stosowanych w profesjonalnych instrumentach pomiarowych w astronomii Do zastosowań w astronomii dostępne jest wiele kamer komercyjnych od wielu producentów. Kamery te w większości nie spełniają szczególnych wymagań projektu Pi of the Sky. Wśród niepożądanych cech kamer komercyjnych można wymienić: wysoki koszt kamery, niewystarczająco wytrzymałe migawki, długi czas odczytu czujnika CCD (czyli długi czas martwy podczas zczytywania z czujnika obraz nie może być rejestrowany, a czujnik jest przesłonięty migawką). Ponadto niewiele kamer posiada chłodzenie czujnika CCD, co skutkuje dużymi szumami termicznymi. W niektórych kamerach komercyjnych używany był jeszcze przestarzały protokół komunikacji za pomocą portu drukarki LPT za wolny do zastosowań opisywanego projektu. Brak podstawowych funkcji sprzętu wymaganych w projekcie przemawiał za zbudowaniem własnych kamer Konstrukcja mechaniczna teleskopu w projekcie Pi of the Sky i konstrukcja podzespołów elektronicznych Docelowo konstrukcja teleskopu ma się składać z 16 identycznych modułów kamer. Kamery zostaną umieszczone w miejscach nadających się do przeprowadzania obserwacji astronomicznych, tzn. takich, w których warunki pogodowe są stabilne (małe zachmurzenie nieba, brak opadów) i ruchy powietrza w atmosferze są niewielkie (oddalenie od miast, brak zanieczyszczeń powietrza). W miejscu umieszczenia prototypu teleskopu warunki pogodowe są jednak nieraz skrajnie niekorzystne. Z tego powodu konieczne jest takie zaprojektowanie kamer, aby były odporne na różne warunki pogodowe. Kamery będą pracować nienadzorowane, a więc projekt teleskopu musi zapewniać ich bezawaryjność, zdalne włączanie i wyłączanie oraz zdalną kontrolę nad systemem. Zbudowany specjalnie dla projektu Pi of the Sky prototyp teleskopu zawiera dwie kamery na montażu paralaktycznym. Montaż paralaktyczny posiada dwie osie: godzinową (skierowaną na północny biegun nieba) i deklinacyjną (prostopadłą do 17

18 godzinowej). Taka konfiguracja montażu umożliwia łatwe prowadzenie teleskopu i nakierowywanie go na wybrany punkt nieba. Dwie kamery umieszczone na montażu przedstawia rys. 8. Osłona przeciwodblaskowa Montaż Rys. 8. Dwie kamery umieszczone na montażu. Wersja prototypowa. Główne podzespoły kamery to: Osłona przeciwodblaskowa (rys. 8) Obiektyw (rys. 9) Silnik krokowy z kołem zębatym (rys. 9) Służy do regulacji ogniskowania optyki kamery. Podgrzewanie optyki Podgrzewanie optyki jest zrealizowane za pomocą rezystorów podgrzewających 18

19 obudowę, dzięki czemu unika się kondensacji pary wodnej z powietrza na optyce. Czujniki temperatury i wilgotności (rys. 9) Monitorowane są temperatury zarówno wewnątrz, jak i na zewnątrz urządzenia. Pozwala to na ustalenie optymalnych warunków pracy urządzenia. Obiektyw Przekładnia zębata Czujnik wilgotności i temperatury zewnętrznej Silnik krokowy Rys. 9. Widok zewnętrznych podzespołów kamery. Migawka Służy do przesłaniania czujnika CCD podczas odczytu obrazu z czujnika. Z powodu niewystarczającej niezawodności migawek komercyjnych, zastosowano migawkę własnej produkcji (rys. 10). Silnik liniowy Rys. 10. Migawka symulacja komputerowa. 19

20 Mechanizm napędzający migawkę został wykonany z silnika liniowego, pochodzącego z dysku twardego. Do ramienia silnika przymocowano materiał nieprzepuszczający światła. Czujnik CCD Czujnik CCD442A firmy Fairchild Semiconductor, o rozdzielczości 2048*2048 pikseli i rozmiarze piksela 15 µm x 15 µm. Podzespoły elektroniczne (rys. 11) Rys. 11. Schemat blokowy podzespołów elektronicznych kamery. Podzespoły elektroniczne są rozmieszczone w 2 komorach (rys. 12). Górna komora jest hermetycznie zamknięta i wypełniona gazem szlachetnym. Znajdujący się w niej czujnik CCD i tor analogowy elektroniki są dzięki temu odizolowane od wpływów środowiska. W dolnej komorze znajduje się tor cyfrowy elektroniki. Takie rozgraniczenie podzespołów elektronicznych pozwala uniknąć zakłóceń wprowadzanych przez pracę toru cyfrowego. 20

21 Hermetyczna komora górna Radiator Komora dolna Rys. 12. Widok rozmieszczenia podzespołów mechanicznych i elektronicznych kamery. Ogniwa Peltiera, radiator z wentylatorem Podzespoły te zapewniają obniżenie temperatury czujnika CCD o około 35 C poniżej temperatury otoczenia. Ogniwa Peltiera działają jak pompa cieplna, a odprowadzenie ciepła do atmosfery zapewnia radiator z wentylatorem. Ogniwa Peltiera wyposażono w układ automatycznej stabilizacji temperatury w celu zapewnienia niezmiennych warunków pracy czujnika CCD. Z 2 kamerami współpracują 2 komputery PC wyposażone w procesory Pentium IV - 2,4 GHz, 1 GB RAM i złącza USB, służące do połączenia komputera z kamerą. Wyposażenie stanowią także włączniki prądu, którymi można sterować przez Internet. Szczegółowy opis podzespołów elektronicznych można znaleźć w [12] Przegląd rozwiązań dotyczących oprogramowania stosowanych w profesjonalnych instrumentach pomiarowych w astronomii Do obsługi profesjonalnych instrumentów pomiarowych w astronomii używane jest własne autorskie oprogramowanie, ponieważ sprzęt jest prawie zawsze 21

22 konstrukcją autorską. Szczegóły budowy używanego oprogramowania nie są publikowane, znane są natomiast funkcje, jakie ono wykonuje. W szybkich teleskopach zrobotyzowanych oprogramowanie jest przystosowane do przetwarzania dużej ilości danych, ponieważ dąży się do tego, aby rozdzielczość czasowa, rozdzielczość obrazów i rozdzielczość kwantowania były jak najwyższe. W celu zmniejszenia wielkości strumienia danych stosuje się kompresję obrazów, a stosowana kompresja jest bezstratna, aby podczas kompresji nie utracić ważnych szczegółów. W najnowszych teleskopach oprogramowanie zaprojektowane jest do pracy automatycznej i działa w czasie prawie rzeczywistym. Niewielkie odchyłki od działania w czasie rzeczywistym wynikają z bardzo dużego strumienia przetwarzanych danych. Standardową funkcją oprogramowania jest wykonywanie astrometrii (procedury znajdowania gwiazd) i fotometrii (procedury pomiaru jasności gwiazd). Do przeglądania i obróbki obrazów wykorzystywane są profesjonalne aplikacje np. DaoPhot i IRAF. System operacyjny dla oprogramowania to prawie zawsze system Unix lub jego pochodne, a przede wszystkim system Linux. Oprogramowanie teleskopów mających podobny cel naukowy do projektu Pi of the Sky nie posiada funkcji automatycznego wykrywania błysków, co poważnie ogranicza potencjał odkrywczy podobnych projektów. Oprogramowanie w projekcie Pi of the Sky ma wykonywać całkowicie nowe zadania, konieczne stało się więc opracowanie własnego oprogramowania. Przy tworzeniu oprogramowania korzystano z doświadczeń projektu ASAS [13]. Wykorzystano także niektóre biblioteki udostępnione przez twórców tego projektu Oprogramowanie teleskopu w projekcie Pi of the Sky Teleskop jest sterowany przez komputer umieszczony w kopule teleskopu, zaś drugi komputer znajduje się w pomieszczeniu sterującym. Teleskop może działać całkowicie autonomicznie, bez interwencji człowieka, ale wszystkie jego parametry mogą być także zmieniane przez Internet. Każdej nocy oprogramowanie generuje specjalny skrypt, który zawiera rozkazy dotyczące planowanej pracy teleskopu. 22

23 Teleskop jest konfigurowany tak, aby jego pole widzenia pokrywało się (jeśli to tylko możliwe) z polem widzenia satelitów Swift, Integral lub HETE. Dwukrotnie w ciągu nocy wykonywane jest przeszukanie całego nieba, trwające 2 x 20 minut. System nasłuchuje alarmów z sieci GCN. Po otrzymaniu alarmu podąża w odpowiednie miejsce na niebie (jeśli miejsce to nie znajduje się już w polu widzenia teleskopu, albo nie jest poza zasięgiem teleskopu). Czas ekspozycji w teleskopie jest ustalony na 10 sekund, a zdjęcia są robione w sposób ciągły. Po przetransportowaniu zdjęć z obydwu kamer do pamięci RAM, podejmowana jest analiza online 3 (odbywająca się podczas akwizycji danych). Analiza ta ma na celu znalezienie błysków i opisano ją poniżej. Następnie obrazy są zapisywane na dysk, do wykorzystania w przypadku gdyby alarm z sieci GCN nadszedł z dużym opóźnieniem. Jeśli znaleziono kandydatów na błysk trwający do kilku sekund, na dysk zapisywane są wycinki obrazów o rozmiarze 100x100 pikseli, dla 7 klatek poprzedzających i następujących po badanej klatce. Obrazy są przesyłane na drugi komputer, w celu ich analizy pod kątem błysków trwających kilka minut i wykonania analizy offline (odbywającej się po zakończeniu akwizycji danych, w ciągu dnia). W ciągu dnia pierwszy komputer wykonuje szybką fotometrię (pomiar jasności gwiazd). Drugi komputer wykonuje dokładną fotometrię. Pomiary te są zapisywane w bazie danych i mogą służyć do późniejszego badania jasności gwiazd zmiennych itp. Poprzez wykonanie analizy końcowa ilość danych do zapisu na dysku zostaje zredukowana z 30 GB do 2 GB dla jednej nocy. Do analizy danych online wykorzystywany jest wspomniany już wcześniej wielostopniowy system redukcji danych, bazujący na procedurach używanych w eksperymentach fizyki cząstek elementarnych. W analizie tej obraz jest wpierw specjalnie preparowany filtrowany za pomocą filtra wyostrzającego (górnoprzepustowego). Następnie wykonywane jest progowanie odrzucane są wszystkie piksele poniżej pewnego progu, a więc piksele tła (cięcie Tn) i piksele dla których jasność jest w przybliżeniu niezmienna (cięcie Tv). Generowana jest lista znajdujących się na obrazie obiektów, dla których będzie przeprowadzona bardziej szczegółowa analiza (cięcia Minprev i dalsze). Objętość listy jest następnie zmniejszana na kolejnych stopniach (cięciach) analizy. Najważniejsze cięcia przedstawiono w tabeli nr 1. 3 W niniejszej pracy wyrazy pochodzenia obcego oznaczono kursywą. 23

24 Nazwa cięcia Maxall Tn Sposób działania Odrzuca piksele przesycone, o wartości większej od zadanej (np ). Progowanie odrzucanie pikseli tła Tv Progowanie odrzucanie pikseli, których jasność jest niezmienna Minprev Przypadek jest odrzucany, gdy wartość jego pikseli jest mniejsza od pewnej wartości. Locmax Overlap Hot Ifmore Coinc Sat Star Track Shape Final Akceptowane są obiekty, które stanowią lokalne maksimum obrazu. Jeśli jeden błysk jest traktowany jako kilka oddzielnych obiektów na liście, są one łączone w jeden obiekt. Eliminuje efekt aparaturowy objawiający się na obrazie jako pojedyncze jasne piksele. Chmury na niebie, intensywne oświetlenie nieba i smugi pojawiające się po przelocie samolotu mogą powodować wykrycie wielu przypadków błysków na małym obszarze. Jeśli występują błyski (powyżej 20) na pewnym obszarze (kwadracie o rozmiarze 150 x 150 pikseli), przypadki te są odrzucane. Na obrazach znajdują się obiekty powstałe na skutek oddziaływania promieniowania kosmicznego na czujnik CCD oraz powstałe na skutek fluktuacji pikseli. Przypadki te są odrzucane poprzez sprawdzenie koincydencji pomiędzy obydwoma kamerami. Obiekty znajdujące się na obrazie z tylko jednej kamery są odrzucane. Refleks światła słonecznego od satelity może pozorować błysk podobny do szukanych. Jeśli błysk znajduje się tylko na jednej klatce, sprawdzane jest, czy w danym miejscu nie znajduje się satelita. Wykorzystywany jest katalog satelitów dostępny w Internecie. Gwiazdy mogą objawiać się jako błyski, jeśli zostały wcześniej przesłonięte przez chmury. Aby potwierdzić, że są to jednak stałe gwiazdy, a nie błyski, obiekty są porównywane z katalogiem gwiazd projektu ASAS [13]. Satelity poruszając się w polu widzenia kamery błyskają częstokroć kilkakrotnie. Jeśli uda się połączyć wykryte błyski linią prostą, naśladując trasę przelotu satelity, błyski te są odrzucane. Dodatkowo zakłada się, że prędkość satelity jest niezmienna, a więc błyski znajdują się w równej odległości na obrazie. Odrzucane są przypadki odbiegające w określony sposób od kształtu okrągłego. W chwili obecnej jest to analiza wzrokowa wykonywana przez człowieka, wspomagana komputerowo. Wykonywana jest optymalizacja procedur ostatecznego potwierdzania błysków, zastępująca analizę wzrokową. Tabela nr 1. Zestawienie cięć strumienia danych dotyczącego zdarzeń błysków. 24

25 Jak można zaobserwować na poniższym wykresie (rys. 13), w trakcie działania trzech pierwszych cięć ilość danych jest redukowana średnio o pięć rzędów wielkości. Cięcia te działają najszybciej i odrzucają przypadki, które nie pozostawiają wątpliwości, że nie są błyskami. Analiza ta przebiega także najszybciej w przeliczeniu na jeden obiekt. Rys. 13. Liczba obiektów znalezionych na zdjęciach z jednej kamery (oś pionowa), w rozbiciu na poszczególne poziomy selekcji (oś pozioma) dla wybranych nocy. Źródło: [14] Dzięki zastosowanemu systemowi redukcji danych eksperyment potrafi samodzielnie wykryć błyski w ilości kilku kilkudziesięciu dziennie, co jest wartością dopuszczalną do analizy przez człowieka, podczas której następuje ostateczne potwierdzenie, czy znaleziony błysk jest poświatą po błysku promieniowania gamma. Cały system oprogramowania i sprzętu jest kontrolowany przez dedykowany program zarządzający Piman. Piman kieruje wszystkimi modułami akwizycji i obróbki danych. Strukturę i interakcje pomiędzy różnymi modułami przedstawia rys

26 Rys. 14. Struktura modułów oprogramowania Pi of the Sky. Źródło: [16] Moduły pełnią następujące zadania: Pishell środowisko pozwalające wydawać interaktywne komendy z linii poleceń Scripts przed każdą nocą obserwacyjną generuje skrypty zawierające harmonogram obserwacji Cron demon systemowy pozwalający zaprogramować wywołanie komend w odpowiednim czasie Runscript program uruchamiający skrypty zewnętrzne z systemu operacyjnego PiMan moduł odpowiedzialny za komunikację pomiędzy wszystkimi innymi modułami DAQ (Data AcQuisition) system akwizycji danych: sterowanie kamerami, odczyt danych i analiza danych online Mount program sterujący montażem teleskopu GCN interfejs dla trygerów otrzymywanych z sieci GCN HETE interfejs pozwalający na podążanie za polem widzenia satelity HETE Do komunikacji pomiędzy modułem Piman i pozostałymi modułami wykorzystywane jest środowisko CORBA. 26

27 2. Geneza, cel i założenia pracy Realizacja systemu kamer wymagała opracowania własnego dedykowanego oprogramowania. Oprogramowanie to musiało zostać dostosowane funkcjonalnie do specyficznych zadań aparatury projektu Pi of the Sky. Głównym celem niniejszej pracy była realizacja części oprogramowania kluczowej dla działania kamery, odpowiedzialnej za komunikację i obsługę kamery. Wykonano także niektóre procedury przetwarzania danych po ich akwizycji oraz procedury wizualizacji, niezbędne w budowanym systemie akwizycji danych. Założono, że niektóre opracowane moduły oprogramowania będą mogły służyć jako odrębne i samodzielne oprogramowanie, ale będzie także możliwe ich wykorzystanie w module DAQ (rys. 14 i rys. 15). Ogólne założenia dotyczące zarówno sprzętu, jak i oprogramowania oraz szczegółowe założenia dla następujących modułów wykonanych w niniejszej pracy: Sterownik urządzenia USB Program do obsługi kamer Program do nakładania na siebie obrazów Interfejs graficzny przedstawiono poniżej. 27

28 Rys. 15. Podmoduły modułu DAQ i inne wykorzystywane w systemie. Podmoduły wykonane w zakresie niniejszej pracy przedstawione są zielonym kolorem Założenia ogólne dotyczące sprzętu i oprogramowania Zarówno system oprogramowania, jak i sprzętu został wykonany przy przestrzeganiu następujących założeń ogólnych: 1. Cały teleskop będzie znajdować się w miejscu trudno dostępnym dla człowieka i będzie działać bez stałego nadzoru człowieka, dlatego niezbędna jest jego wysoka niezawodność. Konieczna jest automatyzacja diagnozowania problemów i obsługiwania błędów systemu bez konieczności ludzkiej interwencji, redundancja zasobów komputerowych i elastyczna konfiguracja. 28

29 2. Minimalizacja kosztu pojedynczej kamery. Minimalizacja kosztu jest konieczna, ponieważ w eksperymencie będzie wykorzystywane wiele modułów kamer (w wersji prototypowej 2 kamery, w wersji docelowej 2 zespoły po 16 kamer). 3. System akwizycji danych musi zbierać i dokonywać selekcji danych bez udziału człowieka. 4. Akwizycja danych musi przebiegać w czasie rzeczywistym System operacyjny Podstawowym problemem, przed którym stanął zespół projektu Pi of the Sky był wybór systemu operacyjnego i interfejsu komunikacyjnego pomiędzy urządzeniem kamery i komputerem. Kryteria, którymi kierowano się podczas wyboru systemu operacyjnego, były następujące: 1. Dostępność kodu źródłowego systemu operacyjnego 2. Dostępność kodu źródłowego sterowników 3. Niezawodność systemu operacyjnego 4. Możliwość administracji systemem bez obecności człowieka na miejscu, zdalnie 5. Kompatybilność i możliwość obsługi sprzętu różnego rodzaju 6. Koszt systemu operacyjnego Wybór sprowadza się praktycznie do dwóch systemów: Windows i Linux. Większość powyższych kryteriów spełniał system Linux. Kod źródłowy jego jądra jest powszechnie dostępny. Jądro ma budowę modułową, przez co można je łatwo modyfikować i dodawać do niego nowe funkcje. Dostępne są także przykłady kodu źródłowego sterowników w systemie Linux. Dla systemu tego dostępna jest także duża ilość darmowego oprogramowania typu open source, które później zostało wykorzystane w projekcie. 29

30 Protokół komunikacji Protokół komunikacji powinien mieć następujące cechy: 1. Odpowiednio duża prędkość przesyłania danych (rozmiar jednego obrazu to ok. 8 MB, a jego przesyłanie powinno trwać maksymalnie 1 sekundę) 2. Tani w implementacji sprzętowej 3. Musi posiadać tryb zapewniający niezawodność transmisji i weryfikację danych 4. Musi być obsługiwany przez wybrany system operacyjny 5. Musi wykorzystywać bezpośredni dostęp do pamięci komputera (DMA) z powodu dużej ilości danych przesyłanych z kamery do pamięci Do wyboru możliwe były trzy protokoły: USB 2.0, FireWire i Gigabit Ethernet. Protokół USB 1.1 odrzucono z góry, ponieważ jego prędkość była zbyt niska. W chwili wyboru wszystkie trzy protokoły były nowością, tzn. nie znajdowały się w powszechnym użyciu. Protokół Gigabit Ethernet posiadał wystarczającą prędkość, ale jego koszt implementacji w sprzęcie był bardzo wysoki i dlatego protokół został odrzucony. Implementacja tego protokołu planowana jest w następnych wersjach kamery. Z dwóch pozostałych protokołów (USB 2.0 i FireWire) lepiej rozwinięte oprogramowanie w systemie operacyjnym Linux posiadał USB 2.0. Prędkość USB 2.0 wynosi ok. 60 MB/s, a więc spełniony jest warunek odpowiednio dużej prędkości. Dzisiaj protokół ten stanowi standard komunikacji różnych urządzeń Założenia dotyczące modułów opracowanego oprogramowania System komunikacji, sterownik urządzenia USB dla systemu Linux System komunikacji, a także sterownik dla wybranego systemu operacyjnego (Linux) i protokołu komunikacji (USB 2.0) musiał spełniać następujące warunki: 1. Niezawodność komunikacji 2. Możliwość wznawiania komunikacji, implementacja timeout ów 30

31 3. Odporność na usterki mechaniczne (np. uszkodzenie kamery, wyciągnięcie wtyczki przewodu) 4. Wiele kamer obsługiwanych przez 1 komputer 5. Monitorowanie i ustawianie parametrów kamery w czasie rzeczywistym 6. Możliwość działania zdalnego i automatycznego, ale także w trybie ręcznym 7. Możliwość dokonywania zdalnych zmian w oprogramowaniu systemu komunikacji Program do obsługi kamer W programie do obsługi kamer miały zostać wykorzystane wszystkie możliwości sterownika i zaimplementowane wszystkie komendy urządzenia kamery. Ponadto program ten musiał spełniać następujące założenia: 1. Zapis danych na dysk w postaci obrazów w formacie FITS (opis formatu FITS patrz rozdział 7.2.2) 2. Możliwość łatwych zmian w celu testowania 3. Możliwość użytkowania jako podmoduł modułu DAQ Program do nakładania na siebie obrazów Program ten miał pełnić ważne zadanie polepszenia parametrów obrazów zarejestrowanych przez sprzęt. Program ten musiał spełniać następujące założenia: 1. Odczyt obrazów z formatu FITS 2. Możliwość uruchamiania i ustawiania wszystkich parametrów działania programu z linii poleceń. To założenie zmodyfikowano później na możliwość ładowania wszystkich parametrów działania programu z pliku konfiguracyjnego. 3. Zwiększenie zasięgu 4. Polepszenie jakości obrazów 5. Możliwość użytkowania jako podmoduł modułu DAQ Interfejs graficzny W toku prac nad projektem Pi of the Sky okazało się, że brakuje narzędzia do graficznej wizualizacji uzyskanych danych, a przede wszystkim zarejestrowanych 31

32 obrazów. Istnieje wiele programów do przeglądania obrazów w formacie FITS [23] formacie powszechnie używanym do przechowywania obrazów astronomicznych, ale żaden z nich nie obsługuje formatu kompresji używanego w projekcie. Używany format kompresji bezstratnej stosuje kodowanie Rice a, a opis algorytmu wykorzystującego to kodowanie oraz jego właściwości można znaleźć np. w [15]. Wiele z programów do przeglądania obrazów jest programami graficznymi sensu stricte, a więc nie umożliwiają przeglądania opisów dołączonych do obrazów astronomicznych w postaci tzw. kluczy, ani nie umożliwiają wizualizacji obrazów w sposób wymagany w astronomii. Rzeczą oczywistą jest, że żaden z tych programów nie ma możliwości sterowania sprzętem użytkowanym w projekcie Pi of the Sky i bezpośredniej wizualizacji zarejestrowanych obrazów. Opisywany interfejs graficzny jest zaczątkiem programu, który wypełnia tę lukę. Program ten musiał spełniać następujące założenia: 1. Możliwość uruchamiania pod systemami Windows i Linux 2. Budowa modułowa, możliwość rozbudowy programu w celu zbudowania interfejsu do obsługi kamer 3. Możliwość wywoływania przez interfejs procedur opracowanego modułu akwizycji danych dostępnych w języku C++ 4. Możliwość odczytywania plików FITS, także skompresowanych w standardzie używanym przez projekt Pi of the Sky wykorzystanie dostępnej implementacji procedury dekompresji w języku C++ dla systemu Linux 5. Wyświetlanie obrazów oraz opisów obrazów 6. Możliwość manipulacji obrazem, zmiana sposobu wyświetlania obrazu: zmiana zakresu dynamicznego wyświetlania obrazu (zwiększenie kontrastu), zmiana powiększenia, przewijanie 7. Wyświetlanie wartości wskazanych myszą 32

33 3. Koncepcja pracy Rysunek modułu DAQ wraz z podziałem na podmoduły i zaznaczeniem, które podmoduły zostały wykonane w niniejszej pracy, przedstawia rys. 15. Niektóre programy mogą funkcjonować samodzielnie, poza modułem DAQ, co także zaznaczono na rysunku. Koncepcje realizacji modułów wykonanych w niniejszej pracy przedstawiono poniżej Sterownik urządzenia USB w systemie Linux Początkowo w celu wypełnienia założeń dotyczących systemu komunikacji z kamerą (rozdział 2.2.1) czynione były próby użycia programu w trybie użytkownika, np. libusb [17]. Programy tego rodzaju zapewniają bibliotekę procedur do komunikacji za pomocą USB. Okazało się, że programy te miały ograniczone możliwości, a przede wszystkim nie obsługiwały trybu USB 2.0 (tylko USB 1.1). O użyciu dedykowanego sterownika w systemie Linux przesądziła konieczność implementacji odświeżania watchdoga urządzenia przez sterownik. Pierwsza wersja sterownika była przeznaczona dla jądra w wersji 2.4, ale zdecydowano o użyciu jądra systemu Linux w wersji 2.6, chociaż decyzja ta była w sprzeczności z założeniem o niezawodności systemu (rozdział 2.2.1, punkt 1), ponieważ jądro 2.6 było wtedy jeszcze nowością. Zrealizowany sterownik implementuje wszystkie komendy normalnie implementowane w sterowniku urządzenia USB. Sterownik ten wyróżnia implementacja odświeżania watchdoga w sterowniku i specyficzny (inny od 33

34 zwyczajnego) przydział komend urządzenia fizycznego do funkcji read 4 (odczyt) / write (zapis) i ioctl (kontrola urządzenia) sterownika. W warstwie sprzętowej kamery zaimplementowano tzw. watchdoga (sprzętowy układ nadzorujący), który powoduje reset kamery, gdy przez określony czas (timeout) nie są odbierane żadne dane z komputera. Jest to zabezpieczenie w przypadku nieprawidłowego działania komputera lub kamery. Z tego powodu konieczne jest wysyłanie danych do kamery, niezależnie od tego, czy pracuje ona, czy nie w ten sposób dokonywane jest podtrzymywanie pracy kamery. Jest to zadanie dla sterownika. Jeśli wykonywane byłoby to z poziomu aplikacji użytkownika, wtedy przebieg pracy mógłby wyglądać następująco: po uruchomieniu systemu sterownik ładuje się do jądra. program użytkowy jest uruchamiany o wiele później, niż wynosi timeout watchdoga watchdog resetuje kamerę prowadzi to do odładowania sterownika i jego ponownego załadowania aplikacja użytkownika traci kontrolę nad sterownikiem z powodu ciągłego odładowywania i ładowania sterownika. Dopiero po jakimś czasie następuje stabilizacja, ale przynajmniej parę cykli odładowania i załadowania sterownika jest wykonane (nie jest to wskazane z powodu specyficznych trudności z ładowaniem sterowników, co opisano w rozdziale 4.3, Debugowanie i testowanie sterownika ). Oznaczałoby to także, że aplikacja użytkownika musiałaby być skomplikowana (zawsze wielowątkowa - jeden wątek główny i jeden na podtrzymywanie watchdoga), a także, że wątki te musiałyby się ze sobą komunikować, aby watchdog nie wysłał niepotrzebnie danych, np. w trakcie wysyłania sekwencji poleceń, co prowadziłoby do przekłamania danych. Koncepcja implementacji odświeżania watchdoga w sterowniku przewiduje wysyłanie do kamery 1 bajtu danych (np. komendy Włącz chłodzenie czujnika CCD lub specjalnej pustej komendy) co ustalony czas wyłącznie wtedy, gdy dane nie są transferowane. Dzięki temu pogodzono założenie o odporności systemu na usterki mechaniczne (rozdział 2.2.1, punkt 3) z założeniem o niezawodności systemu 4 W niniejszej pracy nazwy funkcji, nazwy klas, fragmenty kodu, wyniki działania programów przedstawiono za pomocą czcionki specjalnej. 34

35 i możliwości wznawiania komunikacji (rozdział 2.2.1, punkt 1 i 2), w tym wypadku na skutek błędu sprzętowego kamery. W sterowniku dla jądra systemu Linux ustalony jest zwyczajowo pewien przydział komend urządzenia fizycznego do funkcji read / write i ioctl sterownika. Nie ma oczywiście obowiązku, aby trzymać się dokładnie wytyczonego przydziału. Odczyt użytecznych danych (w naszym przypadku - obrazów) powinien zachodzić po wywołaniu funkcji read sterownika. Użyteczne dane powinny być wysyłane do urządzenia za pomocą funkcji write sterownika (w naszym przypadku mógłby to być strumień oprogramowania firmware). Po wywołaniu funkcji ioctl sterownika, powinny być wykonywane odpowiednie funkcje urządzenia, nie kojarzone bezpośrednio z transferem danych (np. komenda: Włącz chłodzenie czujnika CCD ). W opisywanym sterowniku przyporządkowanie komend urządzenia do wspomnianych funkcji jest inne i zostało zdeterminowane tym, że taka implementacja upraszczała strukturę sterownika i umożliwiała łatwe dodawanie komend w kolejnych wersjach kamery. W wykonanej realizacji sterownika za pomocą funkcji write wysyła się komendy do urządzenia kamery (w postaci sekwencji bajtów). Za pomocą funkcji read odczytuje się odpowiedzi na te komendy. Odczyt użytecznych danych (obrazów) wykonywany jest za pomocą funkcji ioctl. Dzięki temu endpointy (wydzielone kanały transferu danych w magistrali USB, opisywane w sterowniku pewną strukturą danych, opis w rozdziale 4.2.4) używane przez funkcje read / write pozostają niezmiennie takie same, a inny endpoint używany jest tylko przy wywołaniu funkcji ioctl. W funkcji ioctl zaimplementowane są funkcje znane i sprawdzone. Nowe funkcje można dodawać nie w sterowniku, ale w programie do obsługi kamer poprzez dodanie sekwencji bajtów komend i zapisanie tej sekwencji do pliku urządzenia. Eliminuje to konieczność modyfikacji sterownika przez użytkowników sterownika, którzy przez nieprawidłową modyfikację kodu sterownika mogliby doprowadzić do awarii jądra systemu. Wykorzystanie funkcji sterownika w sposób opisany powyżej ma oczywiście wpływ na koncepcję programu do obsługi kamer (rozdział 3.2). Z założenia o niezawodności sterownika (rozdział 2.2.1, punkt 1) i o dokonywaniu zdalnych zmian w systemie (rozdział 2.1, punkt 1) wynika, że konieczne jest zdalne ładowanie firmware kamery. Zdalne ładowanie firmware do 35

36 kamery może zostać wykorzystane w przypadku wykrycia usterek kamery, gdy znajdzie się ona w docelowym miejscu eksperymentu. Jest to najtrudniejsze zadanie dotyczące zmian w systemie. Załadowanie firmware do urządzenia kamery wymaga specjalnych działań. Podczas ładowania firmware, kamera jest całkowicie uzależniona od komputera, nie może wykonywać swoich normalnych funkcji, a nieprawidłowe załadowanie może nawet prowadzić do niemożności użytkowania kamery. Dlatego konieczne było zaimplementowanie specjalnych operacji, które wymagają współpracy zarówno sprzętu, jak i sterownika w celu całkowitego wyeliminowania błędów ładowania Program do obsługi kamer Kod programu do obsługi kamer napisano w języku C++. Koncepcja tego programu jest zdeterminowana przez to, że musi on wykorzystywać wszystkie możliwości sterownika i implementować wszystkie komendy urządzenia kamery. W celu spełnienia założenia o możliwości połączenia programu do obsługi z modułem DAQ (rozdział 2.2.2, punkt 3), podzielono kod programu do obsługi kamer na bibliotekę procedur związanych z obsługą sprzętu (nakładkę na sterownik) i procedurę główną programu. Do zapisu pozyskanych danych zdecydowano się na użycie biblioteki fitsio [23], która pozwala na zapis danych w formacie danych astronomicznych FITS Program do nakładania na siebie obrazów Cechą systemu akwizycji obrazów astronomicznych Pi of the Sky jest rejestracja obrazów z krótkim czasem naświetlania równym zazwyczaj ok sekund. Pozwala to na obserwację zjawisk szybkozmiennych, ale krótki czas naświetlania powoduje, że obiekty astronomiczne o niewielkiej jasności nie są rejestrowane - giną w szumie tła. Sposobem na pokonanie tego problemu tzn. wydobycie obiektów o niewielkiej jasności z szumu tła, zmniejszenie szumu tła i tzw. zwiększenie zasięgu jest odpowiednia manipulacja zarejestrowanymi obrazami. 36

37 Manipulacja ta ma na celu stworzenie pojedynczego obrazu i zasymulowanie długiego czasu naświetlania przy wykorzystaniu wielu obrazów o krótkim czasie naświetlania. Procedura ta jest stosowana w automatycznym procesie analizy w module DAQ, może być także stosowana do ręcznego wydobycia potrzebnych danych. Polega ona na tym, że jeśli wykonano wiele kolejnych pomiarów jasności danego punktu na niebie (a właściwie obszaru tak niewielkiego, że można mówić o punkcie), można obliczyć średnią tych pomiarów. Jak wiadomo, średnia arytmetyczna z pomiarów danej (niezmiennej podczas pomiarów) wielkości jest o wiele lepszym estymatorem tej wielkości niż jeden pomiar, przy spełnieniu odpowiednich warunków. Uzyskany obraz jest mniej zaszumiony kosztem rozdzielczości czasowej pomiarów. Metoda ta jest standardowo używana w miernictwie i zadaniem programu było jej zaimplementowanie. Niebo na kolejnych obrazach jest przesunięte względem pierwszego obrazu w serii na skutek pozornego ruchu nieba. Program musi uwzględniać to przesunięcie przy uśrednianiu pomiarów tych samych obszarów nieba. Implementacji programu dokonano w C Interfejs graficzny Interfejs graficzny spełniający założenia wykorzystania procedury dekompresji w C++ (rozdział 2.2.4, punkt 4) oraz działający pod systemami Linux i Windows (rozdział 2.2.4, punkt 1) musi korzystać z języka opisu komponentów graficznych przenośnego pomiędzy systemami Linux i Windows oraz musi być zdolny do wywoływania podprogramów napisanych w innych językach. Interfejsy graficzne mające funkcje podobne do opracowanego mogą być tworzone przykładowo przy użyciu następujących narzędzi: Kompilator GNU GCC i Perl / TCL / TK (do obsługi graficznej) dla Linuksa Kompilator Microsoft Visual C++ i Perl / TCL / TK (do obsługi graficznej) dla Windows W ten sposób zaimplementowano np. program do wizualizacji obrazów astronomicznych Audela [24]. 37

38 Połączenie wymienionych technologii jest korzystne pod tym względem, że technologia łączenia języków skryptowych takich jak Perl z C++ jest znana i umożliwia łatwe debugowanie programów. Wadą tego rozwiązania jest brak narzędzi (środowisk zintegrowanych) do tworzenia interfejsów graficznych, co bardzo spowalnia proces tworzenia interfejsu. Coraz więcej programów tworzonych jest przy użyciu języka Java, C++ i technologii Java Native Interface (jako spoiwa pomiędzy językiem Java i C++). Właśnie tej konfiguracji narzędzi / technologii używa zrealizowany interfejs graficzny. Wadą JNI jest utrudnione debugowanie procedur napisanych w C++, ale w tym wypadku używane są procedury, które sprawdzono wielokrotnie i nie wymagają one dalszych testów. Dzięki użyciu Javy możliwe jest intensywne wykorzystanie dostępnych w tym środowisku optymalizowanych procedur obróbki graficznej obrazów, dzięki czemu cały interfejs graficzny jest bardzo szybki przy przetwarzaniu i wyświetlaniu obrazów. Do czytania plików FITS nie użyto biblioteki fitsio zaimplementowanej w C++ i nie użyto interfejsu JNI do sprzężenia kodu w Javie i w C++, ale wykorzystano bibliotekę zaimplementowaną w Javie [33], przeznaczoną do tego celu, co uprościło strukturę całego programu. Problemem okazały się trudności w kompilacji i błędy w działaniu samej procedury dekompresji dostępnej w języku C++ w systemie Linux przy przenoszeniu jej do systemu Windows. Jeśli program nie był od początku pisany dla obydwu systemów Windows i Linux, mogą pojawić się problemy z kompatybilnością skompilowanych programów. Przykładowo w kompilatorze Visual C++ (dla Windows) niektóre funkcje mają inne działanie, niż w kompilatorze GNU C++ (dla Linuksa). Rozwiązaniem było zastosowanie odpowiednich kompilatorów. W celu ułatwienia użytkownikowi obsługi interfejsu wprowadzono możliwość uruchamiania interfejsu za pomocą technologii Java Web Start. Funkcjonalność dostarczana przez tę technologię wykraczała poza założenia przyjęte dla programu, ale została użyta, ponieważ znacznie ułatwia użytkowanie programów przez użytkownika wspomaga pobieranie, wersjonowanie, instalację i uruchamianie programu. 38

39 4. Realizacja systemu komunikacji kamery z komputerem Zbudowanie systemu komunikacji kamery z komputerem polegało na opracowaniu dedykowanego sterownika dla systemu Linux, skryptów do ładowania sterownika oraz opracowaniu kolejności ładowania i odładowywania sterownika w przypadku problemów z komunikacją. Sterownik został wpierw zrealizowany dla jądra w wersji 2.4, a później dla jądra w wersji 2.6. Opis sterownika koncentruje się na sterowniku dla jądra 2.6. W opisie znajdują się podstawowe informacje o jądrze systemu Linux, uzupełniane szczegółowymi informacjami dotyczącymi implementacji sterownika. Taka forma opisu jest konieczna, ponieważ sterownik stanowi właściwie część jądra i nie da się oddzielić opisu implementacji sterownika od opisu jądra. Zakres funkcji jądra, które możnaby opisać jest bardzo obszerny i dlatego w niniejszej pracy ograniczono się do podstawowych informacji. Bardziej szczegółowy opis można znaleźć w [18], [19] i [20] Podstawy użytkowania sterowników w systemie Linux. Skrypty startowe. W niniejszym podrozdziale przedstawiono podstawowe informacje o sterownikach: ich podział względem urządzeń, które obsługują; sposób dostępu aplikacji użytkownika do sterownika oraz polecenia ładowania i odładowywania sterownika wykorzystywane w skryptach startowych i sterujących modułu DAQ. 39

40 Klasy urządzeń W systemie Linux wprowadzono podział sterowników na pewne klasy urządzeń. Podział ten determinuje stopień wsparcia działania sterownika przez jądro, sposób komunikacji pomiędzy aplikacją użytkownika i sterownikiem oraz sterownikiem i fizycznym urządzeniem. Wyróżnia się między innymi następujące klasy urządzeń: Urządzenie znakowe, z którego można pobrać lub wysłać do niego strumień danych. Strumień danych może być tak niewielki, jak 1 znak. Urządzenie blokowe, do którego można uzyskać dostęp, adresując je numerem bloku. Najmniejsza ilość pobranych / wysłanych danych jest taka, jak wielkość bloku danych. Bloki odwzorowują fizyczną strukturę dysku twardego, urządzenia pamięci masowej itd. Urządzenie USB. Stanowi podzbiór wśród urządzeń znakowych. Sterownik obsługujący klasę urządzenia USB może wywoływać procedury jądra pozwalające na obsługę fizycznego urządzenia USB. Funkcją wyróżniającą urządzenie USB i realizowaną przez jądro jest możliwość ładowania sterownika na żądanie, np. wtedy, gdy urządzenie USB zostanie fizycznie podłączone podczas działania komputera (tzw. hotplug). Niniejszy sterownik został opracowany w oparciu o funkcje jądra dostępne dla klasy urządzeń znakowych USB Pliki urządzeń. Numer główny (major) i podrzędny (minor) urządzenia Każda aplikacja użytkownika może w wygodny sposób uzyskać dostęp do sterownika i do urządzenia, co wyróżnia system Linux wśród niektórych innych systemów. Możliwe jest nawet bezpośrednie wysłanie danych do urządzenia z shella, z linii poleceń. Sprawę dostępu rozwiązano w ten sposób, że każde urządzenie (fizyczne lub emulowane) jest mapowane do specjalnego pliku urządzenia, który może być otworzony przez aplikację użytkownika. Następnie transfer danych dokonuje się za pomocą operacji zapisu / odczytu z tego pliku. 40

41 Pliki urządzeń znajdują się w katalogu /dev. Część spisu urządzeń przedstawiono poniżej (uzyskany po wydaniu komendy ls -al): crw mjegier root 5, 1 wrz 6 13:15 console brw-rw root root 3, 65 wrz hdb1 crw-rw-rw- 1 root root 1, 3 wrz null crw-rw root root 108, 0 wrz 6 13:15 ppp crw-rw mjegier uucp 4, 64 wrz ttys0 Pierwsza litera w pierwszej kolumnie oznacza typ urządzenia: c - znakowe, b - blokowe. Następne litery oznaczają prawa dostępu. W następnych kolumnach podana jest liczba dowiązań twardych do pliku, właściciel pliku, grupa, numer główny urządzenia, numer podrzędny urządzenia, czas lub data modyfikacji oraz nazwa pliku. W jaki sposób utworzyć połączenia pomiędzy aplikacją użytkownika, plikiem urządzenia i sterownikiem? W jądrze wersji 2.4 konieczne jest wpierw utworzenie pliku urządzenia. Przykładowo następujący skrypt (wykonany z prawami roota): major=180 mknod /dev/usb/pikam0 c $major 208 mknod /dev/usb/pikam1 c $major 209 mknod /dev/usb/pikam2 c $major 210 mknod /dev/usb/pikam3 c $major 211 mknod /dev/usb/pikam4 c $major 212 chgrp pi /dev/usb/pikam* chmod g+w /dev/usb/pikam* tworzy w katalogu /dev/, podkatalogu usb/ serię urządzeń pikam0... pikam4, które są urządzeniami znakowymi (parametr c ), posiadają wspólny numer główny urządzenia ( 180 ) i kolejne numery podrzędne ( ). Następnie zmieniana jest grupa pliku urządzenia na pi i nadawane są prawa dostępu. Bez tych 2 ostatnich czynności sterownik byłby niedostępny dla użytkowników. Tak więc dostęp do danego urządzenia może być ograniczany w sposób podobny jak dostęp do plików. Jeśli plik urządzenia nie zostanie utworzony przed załadowaniem sterownika, sterownik nie będzie dostępny. Podczas tworzenia pliku urządzenia konieczne jest podanie numeru głównego i podrzędnego urządzenia. 41

42 Numer główny urządzenia stanowi jego identyfikator w systemie i jest to (w uproszczeniu) numer tablicy wskaźników do funkcji obsługiwanych przez sterownik. Sterownik rejestruje się w systemie przy ładowaniu podając ten sam numer główny. Właśnie numer główny pozwala na skojarzenie aplikacji użytkownika, pliku urządzenia i sterownika. Po odwołaniu się przez aplikację użytkownika do nazwy pliku w systemie plików, system wybiera tablicę wskaźników do funkcji obsługiwanych przez sterownik (struktura file_operations), posługując się przy tym numerem głównym urządzenia i na tej podstawie może wywołać odpowiednie funkcje sterownika. Numer podrzędny nie jest bezpośrednio wykorzystywany przez jądro Linux. Przekazywany jest do sterownika i może być wykorzystany przez sterownik dowolnie. Zazwyczaj kolejny numer podrzędny oznacza kolejne urządzenie tego samego typu obsługiwane przez sterownik (w przykładzie powyżej utworzono pięć takich urządzeń). Jednakże numer podrzędny nie zawsze musi oznaczać kolejnego urządzenia. Może to być to samo urządzenie, a kolejny numer może włączać inną funkcjonalność (np. urządzenie o numerze podrzędnym 1 - stary interfejs poleceń; urządzenie o numerze 2 - nowy interfejs poleceń). Sterownik musi sam we własnym zakresie przechowywać dane dla kolejnych urządzeń i przywoływać dane posługując się przekazanym przez jądro numerem podrzędnym. Dobrym podejściem do tego problemu jest zdefiniowanie w kodzie sterownika struktury, w której znajdą się wszystkie zmienne wymagane dla urządzenia. Dla kolejnych urządzeń pojawiających się w systemie należy alokować dynamicznie tę strukturę, a wskaźnik do tej struktury odpowiednio kojarzyć z numerem podrzędnym urządzenia, a następnie, gdy to wymagane, na podstawie numeru podrzędnego uzyskiwać dostęp do danych przy użyciu tego wskaźnika. Dzięki wykorzystaniu numerów podrzędnych system Linux ładuje tylko jeden sterownik dla jednego rodzaju urządzenia nie ładuje sterownika dla kolejnych wystąpień tego samego urządzenia System plików urządzeń Pewnym krokiem w celu ułatwienia zarządzania sterownikami, pozbycia się konieczności używania skryptów podobnych do wyżej opisanego jest System plików 42

43 urządzeń (Device Filesystem) wprowadzony jako standard w jądrze 2.6. Pozwala on na tworzenie pliku urządzenia i nadawanie praw dostępu przez sam sterownik. Pliki urządzeń mogą być tworzone dynamicznie przy podłączaniu urządzenia i usuwane przy jego odłączaniu. Nie trzeba uruchamiać skryptu tworzącego pliki urządzeń, opisanego powyżej i nie ma potrzeby przydzielania numeru głównego i podrzędnego - są one przydzielane automatycznie. Zrealizowany sterownik dla jądra 2.6 korzysta z Systemu plików urządzeń (Device Filesystem) Ładowanie i odładowanie sterownika Ładowanie modułu przez użytkownika sprowadza się do wywołania z linii poleceń (lub w skrypcie) polecenia insmod z odpowiednimi parametrami, np.: insmod pikam.o BufferAddress=150 sensorx=2048 sensory=2062 gdzie pikam.o to nazwa skompilowanego modułu, a pozostałe parametry to parametry przekazywane bezpośrednio do modułu. Chociaż dostęp sterownika do pliku na dysku, np. pliku konfiguracji jest problematyczny, istnieje jednak możliwość konfiguracji sterownika przez przekazanie parametrów przy ładowaniu sterownika. Polecenie insmod po sprawdzeniu kilku warunków wstępnych sprawdza wersjonowanie modułu opisane w rozdziale Jeśli wersje jądra i sterownika się zgadzają, wykonywane jest linkowanie modułu z jądrem. Następnie wywoływana jest funkcja inicjalizacji sterownika init, zaimplementowana w sterowniku (opisana w rozdziale 4.2.5). W funkcji tej sterownik wykonuje swoje procedury inicjalizacji, a także wywołuje funkcje inicjalizacji struktur jądra. Odładowanie sterownika polega na wywołaniu z linii poleceń (lub w skrypcie) polecenia: rmmod pikam 43

44 Jest to proces prostszy od ładowania. Sterownik jest odładowywany, gdy licznik użycia modułu jest równy zero, co opisano w rozdziale Wywoływana jest funkcja exit, zaimplementowana w sterowniku (opisana w rozdziale 4.2.5). Dalsze szczegóły procedury ładowania i odładowywania sterownika przedstawiono także w rozdziale Implementacja sterownika w systemie Linux W niniejszym podrozdziale opisane jest miejsce sterownika w jądrze systemu Linux i wpływ różnych założeń przyjętych w jądrze systemu Linux na strukturę i sposób realizacji sterownika. Szczegółowo opisano funkcje charakterystyczne dla urządzeń USB, a w szczególności dla urządzenia kamery projektu Pi of the Sky Kompilacja sterownika Implementacji modułów jądra powszechnie dokonuje się w języku C, ponieważ w tym języku dokonano implementacji kodu jądra. Preferowanym kompilatorem jest gcc. Parametry kompilacji przekazywane są zazwyczaj w plikach konfiguracyjnych programu do automatyzacji kompilacji make. Dokładne omówienie parametrów kompilacji można znaleźć w literaturze ([18]). Należy tutaj jedynie wspomnieć, że w pliku konfiguracyjnym muszą zostać dołączone pliki nagłówkowe jądra poprzez podanie odpowiedniego katalogu do przeszukania (źródła jądra znajdują się zazwyczaj w katalogu /usr/src/linux). Sterownik może odwoływać się tylko do funkcji zdefiniowanych w tych plikach nagłówkowych, nigdy nie może się odwoływać do funkcji ze standardowych bibliotek języka C Modułowa budowa jądra Jądro ma budowę modułową. Oznacza to, że pewne części kodu wykonywalnego w postaci modułów można dołączyć do jądra już po jego załadowaniu. Ułatwia to proces opracowywania sterowników. Istnieje wciąż możliwość dołączenia kodu sterownika do kodu jądra na stałe (skompilowania kodu sterownika razem z kodem jądra). 44

45 Jądro zajmuje się całą stroną techniczną załadowania sterownika do jądra. Problem stanowi zgodność sterownika z innymi funkcjami w jądrze, a dokładniej to, czy wywołuje on funkcje, które są obecne w danej wersji jądra. Gdy sterownik jest wkompilowywany w jądro, weryfikacja, czy sterownik wywołuje prawidłowe funkcje, z prawidłową liczbą argumentów i z właściwymi typami danych, następuje na etapie kompilacji. Jaki jest więc mechanizm weryfikacji przy ładowaniu skompilowanego modułu, gdy kod języka C zawierający dane dotyczące typów nie jest dostępny? Występują tu dwa sposoby weryfikacji. Jądro posiada spis funkcji jądra, które dany sterownik może wywołać, tzw. tabelę symboli jądra. Tabela ta zawiera wszystkie udostępniane przez jądro funkcje i jest aktualizowana po każdym załadowaniu dowolnego modułu. Możliwa jest odmowa załadowania modułu do jądra, jeśli wywołuje on funkcje, których w jądrze nie ma (np. wywołuje funkcje z nowszych wersji jądra). Drugi sposób obejmuje sprawdzanie sum kontrolnych generowanych podczas kompilacji na podstawie liczby argumentów i typów danych. Wszystkie funkcje jądra posiadają przypisane sumy kontrolne. Także ładowany sterownik udostępnia swoje sumy kontrolne. Jeśli nie zgadzają się one ze sobą, następuje odmowa załadowania. Sposób ten nazywany jest wersjonowaniem modułów. Dzięki wersjonowaniu można uniknąć konieczności kompilacji opracowywanego sterownika dla każdej kolejnej wersji jądra (np , 2.6.7, 2.6.8), które różnią się od siebie nieznacznie. Sterownika nie da się załadować w przypadku, gdy wystąpiła rzeczywista zmiana deklaracji funkcji (i jej suma kontrolna) jądra (dla realizowanego sterownika wystąpiło to przy ładowaniu do wersji rozwojowej jądra 2.5). Jeśli podczas uruchamiania sterownika z różnymi jądrami występują problemy z wersjonowaniem modułów, rozwiązaniem jest dokładne przestrzeganie procedury kompilacji sterownika i kompilacja sterownika z kodem źródłowym jądra zgodnym z używanym jądrem Licznik użycia modułu W sterowniku dla jądra 2.4, w funkcji open sterownika wywoływanej przy otwieraniu pliku urządzenia przez aplikację użytkownika, konieczna jest 45

46 inkrementacja licznika użycia modułu. Zazwyczaj jest to liczba określająca ilość otworzeń pliku urządzenia, chociaż wartość tą można zwiększać i zmniejszać w sposób dowolny, uważając tylko, aby nie prowadziło to do nieprawidłowego działania. Liczba ta mówi jądru, czy może ono odładować sterownik. Jeśli liczba ta jest równa zero, jądro przyjmuje, że sterownik nie jest używany i może zostać odładowany. Kluczową sprawą jest zwiększenie tej wartości natychmiast po pojawieniu się urządzenia fizycznego, czy też otworzeniu pliku urządzenia. W przeciwnym razie sterownik może być odładowany bez przestrzegania procedur bezpiecznego wyłączania urządzenia (np. podczas zamykania systemu). W jądrze 2.4 użycie makra MOD_INC_USE_COUNT (zwiększenie wartości licznika) i MOD_DEC_USE_COUNT (zmniejszenie wartości licznika) jest obligatoryjne. W jądrze 2.6 nie jest to obligatoryjne (tzn. wartość jest automatycznie zwiększana przed wejściem do funkcji open), chociaż nie jest zabronione (szczególnie jeśli ma być zachowana kompatybilność ze starszymi jądrami). Zwiększenie wartości licznika bez odpowiadającego mu zmniejszenia powoduje, że modułu nie można odładować. Może się tak stać nie tylko z powodu nieumieszczenia w kodzie odpowiadającej sobie ilości poleceń zwiększenia i zmniejszenia wartości licznika. Dzieje się tak zawsze, gdy aplikacja użytkownika lub sterownik spowoduje błąd (np. błąd dostępu do pamięci, typu Segmentation Fault), a to z kolei powoduje natychmiastowe zaprzestanie wykonywania kodu aplikacji. Wartość licznika użycia nie zostanie nigdy prawidłowo zmniejszona, ponieważ plik urządzenia nie zostanie zamknięty przez aplikację. Jedynym rozwiązaniem jest ponowne uruchomienie systemu albo napisanie specjalnej funkcji sterownika, która po wywołaniu zeruje licznik użycia. Implementacja tej funkcji jest dobrą praktyką programistyczną i wspomaga debugowanie sterownika. Została ona zaimplementowana w opisywanym sterowniku jako jedna z komend funkcji ioctl Urządzenia USB i ich obsługa w jądrze systemu Linux Do komunikacji urządzenia kamery z komputerem wybrano magistralę USB. USB właściwie nie jest magistralą, ale zbiorem połączeń typu punkt-punkt o topologii drzewa. Każde urządzenie może być podłączone do komputera (hosta 46

47 USB), w którym znajduje się tzw. root hub, czyli korzeń w topologii drzewa połączeń USB. Komunikacja jest zawsze inicjalizowana przez huba urządzenie samo nie może zacząć transmisji, ale dopiero po odpytaniu przez huba (tzw. polling). Podłączanie może odbyć się nawet wtedy, gdy komputer jest włączony (tzw. hotplug). Ta podstawowa cecha urządzeń USB determinuje budowę dedykowanych sterowników USB w systemie Linux. W sterowniku USB konieczna jest implementacja funkcji inicjalizacji dostępnych w innych sterownikach (standardowe nazwy: init, open) wywoływanych przy ładowaniu i otwieraniu sterownika, a także funkcji wywoływanych przy podłączaniu urządzenia USB do hosta USB (standardowa nazwa: probe). Chociaż struktura fizyczna magistrali i urządzenia USB jest stosunkowo prosta, struktura logiczna urządzenia może być bardzo skomplikowana. Struktura logiczna protokołu USB urządzenia może być podzielona na wiele jednostek logicznych według następującego schematu: Urządzenia mają jedną lub więcej konfiguracji. Konfiguracje mają jeden lub więcej interfejsów. Interfejsy posiadają jedno lub więcej ustawień. Interfejsy posiadają zero lub więcej punktów transferu danych (endpointów) Do każdej struktury logicznej urządzenia i danych w niej zawartych można uzyskać dostęp ze sterownika Linuksa, za pomocą określonych funkcji. Struktur logicznych (konfiguracje, interfejsy, ustawienia) używa się w sterownikach w ten sposób, że np. jeśli urządzenie wymaga załadowania firmware, można to osiągnąć po włączeniu jednej konfiguracji, a normalne działanie zachodzi w drugiej konfiguracji. Z kolei kolejne funkcje urządzenia można wybierać komunikując się z urządzeniem przy użyciu różnych interfejsów. W opisywanym urządzeniu kamery znajduje się tylko jedna konfiguracja i jeden alternatywny interfejs. Punkty transferu danych urządzenia (tzw. endpointy) można przyrównać do kanałów transferu danych, wydzielonych w strukturze logicznej protokołu komunikacji urządzenia. Są one opisywane udostępnianą przez jądro strukturą danych (typu usb_endpoint_descriptor), a informacje zawarte w tej strukturze umożliwiają rzeczywisty transfer danych. Jeden endpoint umożliwia jednokierunkowy przepływ 47

48 danych. W celu otrzymania łącza dwukierunkowego potrzebne są dwa endpointy: wysyłania do urządzenia i odbierania z urządzenia. W strukturze danych opisu endpointu znajduje się informacja, jaki jest jego typ. Typ endpointu może być zdefiniowany jako jeden z następujących: Control: Służy do konfiguracji urządzeń. Każde urządzenie posiada endpoint o numerze 0x00 tego typu, służący przy podłączaniu urządzenia do hosta do konfiguracji urządzenia i znajdowania opisu właściwości urządzenia. W opisywanym urządzeniu kamery ten tryb jest stosowany ponadto do transferu firmware układu FPGA w kierunku z komputera do kamery i odwrotnie. Interrupt: Służy do transportu małej ilości danych, ale przy gwarantowanym czasie przesyłu danych (małe opóźnienia). Typowymi urządzeniami używającymi tego trybu są klawiatury i myszy. W opisywanym urządzeniu kamery nie używany. Bulk: Służy do transportu dużej ilości danych - czas przesyłu nie jest gwarantowany, ale gwarantowane jest, że wszystkie dane dotrą do odbiorcy i zostaną uporządkowane we właściwej kolejności (spełnione jest założenie: rozdział 2.1.2, punkt 3). W opisywanym urządzeniu kamery ten tryb jest stosowany do transferu obrazów. Isochronous: Służy do transportu maksymalnej możliwej ilości danych, ale nie jest gwarantowane, że wszystkie dane dotrą do odbiorcy. Typowymi urządzeniami używającymi tego trybu są urządzenia audio (głośniki), w których można zezwolić na utratę danych. W opisywanym urządzeniu kamery nie używany. Do punktów transferu dane są wysyłane w pakietach. Maksymalny rozmiar pakietu jest zdeterminowany konstrukcją urządzenia i może być równy 8, 16, 32, 64, 128, 256, 512, 1024 bajtów. Sterownik dowiaduje się o rozmiarze pakietów odbieranych / wysyłanych przez endpoint ze wspomnianej struktury danych opisu endpointu (typu usb_endpoint_descriptor). Jeśli rozmiar danych jest większy od rozmiaru pakietu, dane są rozdzielane przez jądro na pakiety i dopiero później transmitowane. W opisywanym urządzeniu kamery, dla endpointu transferu danych w trybie bulk, rozmiar pakietu wynosi 512 bajtów (w trybie USB 2.0) lub 64 bajty (w trybie USB 1.1). 48

49 Opisywany sterownik pozyskuje informacje dotyczące interfejsów i ustawień interfejsów oraz pozyskuje wspomniane struktury opisu endpointów podczas podłączania urządzenia, a następnie wykorzystuje je w celu właściwego skonfigurowania transferu. Konfiguracja ta ma miejsce głównie w funkcji probe, wywoływanej podczas podłączania urządzenia i opisanej dalej w rozdziale Podstawowe funkcje zaimplementowane w sterowniku Rys. 16. Schemat poglądowy działania sterownika obsługującego urządzenie USB. Nad strzałkami zamieszczono nazwy wywoływanych funkcji. Kierunek strzałki oznacza, który komponent wywołuje funkcję, np. funkcja init jest wywoływana przez system operacyjny (po załadowaniu sterownika za pomocą polecenia insmod), a zaimplementowana w sterowniku. 49

50 Sterownik obsługujący urządzenie USB musi spójnie obsługiwać trzy ciągi zdarzeń (rys. 16): Załadowanie i odładowanie sterownika wykonywane przez system operacyjny lub skrypt użytkownika (rys. 16, oznaczone kolorem fioletowym). Otworzenie pliku, wykonywanie operacji na pliku i zamknięcie pliku urządzenia (rys. 16, oznaczone kolorem zielonym). Podłączenie, użytkowanie i odłączenie urządzenia USB (rys. 16, oznaczone kolorem niebieskim). Każde z powyższych zdarzeń wymaga zaimplementowania jednej lub kilku funkcji w sterowniku. Ponieważ zdarzenia mogą zachodzić w różnej kolejności, działanie tych funkcji musi być odpowiednio synchronizowane (zazwyczaj za pomocą semaforów). W zamieszczonych opisach użyto standardowych nazw funkcji, ale nazwy te mogą być dowolnie zdefiniowane. Funkcje te są wywoływane przez jądro i są opisane poniżej. Funkcje wywoływane przez jądro przy ładowaniu i odładowywaniu sterownika: static int init init(void) Funkcja ta wywoływana jest przez jądro jako pierwsza po załadowaniu sterownika do pamięci. W tej funkcji sterownik informuje jądro, jakie funkcje może ono wywołać (a więc jakiej klasy jest urządzenie klasy urządzeń opisano w rozdziale 4.1.1), przekazując wskaźniki odpowiednich funkcji, a następnie kończy swoje działanie. Taki przebieg działania odzwierciedla ogólny sposób działania sterownika, który nie wykonuje swoich działań w sposób ciągły tak jak normalna aplikacja, ale rejestruje się w jądrze, informuje, jakie funkcje tego sterownika może wywołać jądro i następnie czeka na wywołania. Niniejszy sterownik rejestruje się w jądrze jako urządzenie USB za pomocą funkcji usb_register. Podczas rejestracji przekazywane do jądra są standardowo wskaźniki do funkcji probe i disconnect (funkcje opisano poniżej), a także identyfikator producenta (Vendor ID) i identyfikator produktu (Product ID) urządzenia USB w strukturze usb_device_id. 50

51 Jądro przewiduje zdolność do obsługi urządzenia przez sterownik porównując identyfikator producenta i identyfikator produktu podłączonego urządzenia z identyfikatorami dostarczonymi przez sterownik. Jeśli identyfikatory są równe, wywoływana jest funkcja probe. Po identyfikatory te należy zgłosić się do odpowiedniej organizacji. W opisywanym urządzeniu używane są jednak identyfikatory producenta modułu USB. Oprócz identyfikatorów, przy wybieraniu sterownika jądro może użyć takich informacji jak wersja urządzenia, klasa urządzenia, interfejs. static void exit exit(void) Funkcja ta jest wywoływana przed odładowaniem sterownika. W opisywanym sterowniku w tej funkcji wywoływana jest funkcja usb_deregister, która odrejestrowuje wcześniej zarejestrowane urządzenie USB. Jeśli urządzenie USB jest fizycznie podłączone, wcześniej wywoływana jest funkcja disconnect (opisana poniżej). Urządzenie zostanie prawidłowo odłączone (tzn. jest zachowywana kolejność wywoływania właściwych funkcji sterownika), nawet jeśli wyłączanie urządzenia zachodzi na drodze programowej, np. podczas zamykania systemu. Funkcje wywoływane przez jądro podczas podłączania i odłączania urządzenia USB: static int probe (struct usb_interface *interface, const struct usb_device_id *id) Funkcja ta wywoływana jest przez system obsługi USB jądra, gdy na podstawie danych dostarczonych w funkcji init jądro stwierdzi, że dany sterownik jest zdolny do obsługi danego urządzenia. Jeśli sterownik nie ma jednak zamiaru obsługiwać urządzenia, może zwrócić wartość sygnalizującą błąd ENODEV (błąd braku urządzenia). Po zaakceptowaniu urządzenia sterownik w funkcji probe dynamicznie alokuje strukturę danych (opisaną wcześniej w rozdziale 4.1.2) dla każdej kolejnej instancji tego samego urządzenia. Należy podkreślić, że w przypadku urządzenia USB alokację tę należy przeprowadzić w funkcji probe, a nie open, ponieważ urządzenie pojawia się w systemie już przy wywołaniu funkcji probe. Następnie lokalna 51

52 struktura danych jest inicjalizowana i zapamiętywane są informacje o podłączonym urządzeniu, aby później móc się z nim skomunikować. Opisywane urządzenie kamery posiada tylko jeden interfejs i dlatego wystarczy sprawdzić tylko identyfikator producenta i urządzenia, aby mieć pewność, że sterownik obsługuje właściwy interfejs. W sterowniku wybierane jest następnie to ustawienie interfejsu. Dla tego ustawienia można uzyskać opis wszystkich wejściowych i wyjściowych punktów transferu danych (endpointów). Dla każdego punktu rezerwowany jest bufor o odpowiedniej wielkości. Dla danych wyjściowych (zapisu) konieczne jest także zarejestrowanie struktury danych URB (USB request block) opisującej transfer danych protokołu USB i umożliwiającej asynchroniczny transfer danych. Następnie alokowany i przypisywany do URB jest bufor danych. Wielkość alokowanego bufora jest uzależniona od rozmiaru pakietu. Rozmiar pakietu jest pozyskiwany za pomocą odpowiednich funkcji jądra, co opisano także w rozdziale Następnie inicjalizowany jest czasomierz odświeżający watchdoga w kamerze, opisany rozdziale W końcu po pomyślnym wykonaniu wszystkich operacji inicjalizacji, gdy sterownik i urządzenie są gotowe do obsługi wszelkich żądań użytkownika, wywoływana jest funkcja usb_register_dev, która rejestruje fizyczne urządzenie USB w jądrze jako urządzenie znakowe. Funkcja ta dokonuje skojarzenia sterownika z plikiem urządzenia o numerze głównym (pliki urządzeń opisano w rozdziale 4.1.2). Sterownik otrzymuje także numer minor urządzenia i dopiero od tej chwili możliwe jest otwieranie pliku urządzenia, a więc dostęp aplikacji użytkownika do sterownika. Rejestrowane są funkcje pliku urządzenia, które może wywołać aplikacja użytkownika (przekazywane w strukturze file_operations, co opisano także poniżej). Struktura danych, która została zaalokowana, jest kojarzona odpowiednio z interfejsem urządzenia USB (opis interfejsu jest przekazywany przez jądro za pomocą argumentu typu usb_interface) i z otrzymanym właśnie numerem podrzędnym minor urządzenia USB, co umożliwi później do niej dostęp sterownikowi zarówno po podaniu interfejsu, jak i numeru minor. Na wszelkie wcześniejsze próby otwarcia pliku urządzenia za pomocą funkcji open aplikacja użytkownika dostaje odpowiedź ENODEV (błąd braku urządzenia). 52

53 static void disconnect (struct usb_interface *interface) Na podstawie argumentu typu usb_interface funkcja odnajduje lokalną strukturę danych urządzenia, zaalokowaną w funkcji probe. Skojarzenie struktury danych urządzenia z interfejsem urządzenia USB jest przerywane (informacja o interfejsie przekazywana przez jądro za pomocą argumentu typu usb_interface). Następnie kasowany jest czasomierz odświeżający watchdoga (w sposób opisany w rozdziale 4.2.8). Za pomocą funkcji usb_deregister_dev odrejestrowywane jest urządzenie USB, co powoduje że numer podrzędny minor urządzenia USB jest zwracany do puli, którą dysponuje jądro. Następnie sterownik czeka na zakończenie jakichkolwiek transferów, jakie mogą jeszcze trwać. Jeśli wcześniej wywołana została funkcja release i struktura danych alokowana w funkcji probe nie jest już potrzebna, struktura ta jest kasowana. Wszystkie operacje są synchronizowane za pomocą odpowiednich semaforów opuszczanych na początku działania i podnoszonych po zakończeniu działania funkcji disconnect, aby zapobiec kolizji z funkcją write (aby nie rozpoczęła ona zapisu, gdy urządzenie zostało odłączone) i z funkcją open (aby nie dopuściła do otworzenia pliku urządzenia przez aplikację użytkownika, gdy urządzenie zostało już odłączone). Funkcje write i open mogą być wywoływane przez program do obsługi kamer, który próbuje ponownie nawiązać komunikację. Funkcje wywoływane przy otwieraniu i zamykaniu pliku urządzenia: Przez aplikację użytkownika wywoływane mogą być tylko te funkcje sterownika, które są dostępne dla aplikacji, tzn. takie, dla których zdefiniowano operacje plikowe pliku urządzenia (rys. 16, oznaczone kolorem żółtym), do którego przypisany jest sterownik. Strukturę file_operations zdefiniowaną w plikach nagłówkowych jądra sterownik wypełnia wskaźnikami do funkcji sterownika i rejestruje tą strukturę w funkcji probe. Ilość pozycji w tej strukturze zwiększała się z biegiem czasu, ale zazwyczaj używane są tylko podstawowe. Jeśli dany sterownik nie posiada danej funkcji (większość sterowników rejestruje tylko podstawowe funkcje), wtedy wskaźnik do tej funkcji jest równy NULL. Jeśli zostanie wywołana 53

54 funkcja, dla której wskaźnik wynosi NULL, jądro zwraca do aplikacji użytkownika kod błędu. Jest dobrą praktyką programistyczną, aby funkcje, które może wywołać aplikacja użytkownika, zwracały kody błędu odzwierciedlające przyczynę powstania błędu. W niniejszym sterowniku praktyka ta jest przestrzegana, tzn. sterownik nie sygnalizuje ciągle tego samego błędu, jeśli jego przyczyny są różne. Kody błędu mają w jądrze wartości ujemne, należy więc stosować wartości predefiniowane w jądrze ze znakiem minus, np. EINVAL (błąd nieprawidłowej wartości). Kody błędu są także odpowiednio obsługiwane przez program do obsługi kamer (rozdział 5), gdzie przyczyna błędu jest odczytywana z globalnej zmiennej errno. int (*open) (struct inode *, struct file *) Ta funkcja sterownika jest pierwszą, która jest wywoływana przez aplikację użytkownika. Może ona nie być zaimplementowana (jej wskaźnik w strukturze operacji plikowych będzie równy NULL). Otwieranie pliku urządzenia przez aplikację użytkownika kończy się wtedy zawsze sukcesem, ale sterownik nie jest informowany o otwarciu pliku urządzenia. W funkcji open opisywanego sterownika zapamiętywane jest jedynie, że plik danego urządzenia został otworzony. Informacja ta jest wykorzystywana później podczas działania innych funkcji sterownika. int (*release) (struct inode *, struct file *) Podobnie jak przy funkcji open, implementację tej funkcji można pominąć. Ta funkcja jest wywoływana przy zamknięciu pliku urządzenia przez aplikację użytkownika za pomocą funkcji close. Nazwa release, a nie close odzwierciedla fakt, że funkcja jest wywoływana, gdy zostaną zamknięte wszystkie deskryptory pliku, używane przez różne wątki. W funkcji release opisywanego sterownika kasowana jest struktura danych alokowana w funkcji probe, jeśli ta funkcja jest ostatnią wywołaną do obsługi konkretnego urządzenia (w zależności od kolejności zdarzeń i wywołania funkcji release lub disconnect kasowanie struktury następuje w jednej lub drugiej funkcji). 54

55 Funkcje wywoływane przy użytkowaniu urządzenia: ssize_t (*read) (struct file *, char *, size_t, loff_t *) Funkcja ta odczytuje dane z urządzenia. Trzeci argument typu size_t oznacza żądanie, ile bajtów danych ma dostarczyć urządzenie. Wartość zwrócona przez tę funkcję to ilość bajtów, które urządzenie rzeczywiście dostarczyło. Wartość ta może być mniejsza od wartości żądanej. Należy uwzględniać to w aplikacji użytkownika, ponieważ w przeciwnym razie może to być źródłem nieprawidłowego działania programu. W opisywanym sterowniku funkcja ta zazwyczaj wywołuje funkcję usb_bulk_msg systemu obsługi USB w jądrze, która wysyła żądanie pobrania danych z urządzenia i oczekuje, aż transfer się zakończy (operacja asynchroniczna). Zgodnie z koncepcją realizacji sterownika (rozdział 3.1) do funkcji read przyporządkowano zadanie transferu odpowiedzi na komendy urządzenia kamery, a więc zadanie inne niż standardowe. ssize_t (*write) (struct file *, const char *, size_t, loff_t *) Funkcja ta wysyła dane do urządzenia. Wartość zwrócona przez tę funkcję to ilość bajtów, które rzeczywiście wysłano do urządzenia. W opisywanym sterowniku funkcja ta wypełnia strukturę URB, kopiuje dane do bufora przypisanego do struktury USB, zgłasza do jądra żądanie zapisu, wywołując funkcję usb_submit_urb systemu obsługi USB w jądrze i nie czekając, aż zapis się zakończy, przekazuje sterowanie do aplikacji użytkownika (operacja asynchroniczna). Właściwy zapis jest już wykonywany przez system obsługi USB w jądrze. Dzięki temu wykonywanie programu do obsługi kamer może być szybsze. Dzięki zastosowaniu odpowiedniego blokowania wywołań funkcji sterownika za pomocą semaforów, nie jest możliwy kolejny zapis i odczyt, dopóki bieżący zapis się nie zakończy. W każdym wywołaniu tej funkcji wysyłanie komendy powodującej odświeżanie watchdoga kamery jest opóźniane (rozdział 4.2.8). Zgodnie z koncepcją realizacji sterownika (rozdział 3.1) do funkcji write przyporządkowano zadanie transferu komend do urządzenia kamery, a więc zadanie inne niż standardowe. Komendy kamery opisano w rozdziale 5. 55

56 int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long) Zwyczajowym zadaniem tej funkcji jest wykonywanie funkcji urządzenia specyficznych dla urządzenia, które nie mają charakteru ani zapisu, ani odczytu. W trzecim i czwartym argumencie tej funkcji aplikacja użytkownika przekazuje polecenia zdefiniowane dla każdego sterownika indywidualnie. Dla opisywanego sterownika przykładem operacji wykonywanej za pomocą funkcji ioctl jest programowanie pamięci EEPROM urządzenia oraz włączanie i wyłączanie systemu podtrzymywania watchdoga urządzenia kamery. Włączanie i wyłączanie systemu podtrzymywania watchdoga to operacja, która powoduje zmianę wewnętrznego stanu i działania sterownika, a nie fizycznego urządzenia. Zgodnie z koncepcją realizacji sterownika (rozdział 3.1) do funkcji ioctl przyporządkowano także operacje transferu danych. Spis komend możliwych do wykonania za pomocą funkcji ioctl zamieszczono w rozdziale Funkcje wspomagające debugowanie Debugowanie modułu jądra jest zadaniem utrudnionym. Normalnie nie ma możliwości używania debuggerów do debugowania sterownika. Instalacja odpowiednich debuggerów wymaga specjalnych zabiegów. Problemem jest także to, że sterownik pracuje w trybie jądra. Sterownik nie ma więc możliwości otworzenia własnego pliku na dysku. Nie ma także możliwości bezpośredniego drukowania komunikatów na ekranie. Najpowszechniej stosowanym rozwiązaniem tych trudności jest użycie funkcji printk. Funkcja ta jest podobna do funkcji printf, standardowej funkcji języka C. Umożliwia ona w ograniczonym zakresie użycie formatowanego drukowania danych np. wywołanie funkcji: printk("ez_write_to_eprom - result:%i\n", result); wydrukuje liczbę typu int. Funkcja printk umieszcza dane w buforze cyklicznym. Gdy bufor zostanie przepełniony, jest zapisywany od początku. Dzięki temu uzyskiwana jest 56

57 oszczędność pamięci, ale istnieje także możliwość utraty danych. Długość bufora używanego w jądrze jest zazwyczaj wystarczająca, ale mimo wszystko komunikaty debugowania nie mogą być zbyt długie (bufor może zostać napełniony przez kilka modułów przed jego opróżnieniem). Dane z bufora cyklicznego są zczytywane przez demon systemowy klogd i umieszczane w pliku rejestru systemowego (plik /var/log/messages). Jeśli demon ten nie działa, dane nie zostaną umieszczone w pliku. Widać to szczególnie wyraźnie, gdy demon nie zdąży wykonać swego zadania, ponieważ przed opróżnieniem bufora cyklicznego komputer zawiesi się. Aby zminimalizować ryzyko utraty danych służących do debugowania, w opisywanym sterowniku po każdym wywołaniu printk wywoływana jest funkcja schedule. Funkcja schedule powoduje, że proces korzystający ze sterownika przechodzi w stan uśpienia, a scheduler systemu dokonuje ponownego przydziału czasu procesora dla innego procesu. Dzięki temu zazwyczaj uruchamiany jest demon klogd i dane są zapisywane na dysk. Ten sposób nie jest do końca bezpieczny (w skrajnym przypadku funkcja schedule może nigdy nie powrócić i sterownik nigdy nie wznowi działania), ale jest powszechnie stosowany. Inne metody debugowania obejmują np. wykorzystywanie konsoli komunikującej się przez port szeregowy, dzięki czemu wszystkie komunikaty drukowane przez printk trafiają na drugi komputer. W tym przypadku nie było jednak potrzeby korzystania z tych zaawansowanych technik debugowania Tryb jądra i użytkownika Sterownik, a także cały kod jądra, pracuje w trybie jądra, a wszystkie pozostałe aplikacje pracują w trybie użytkownika. Jest to podyktowane potrzebą utrzymywania dwóch różnych poziomów ochrony w systemie. W trybie użytkownika wszystkie operacje dostępu do zasobów (pamięci, dysku, portów wejścia / wyjścia) są sprawdzane pod kątem, czy wykonująca je aplikacja użytkownika ma do tego prawo. Po zweryfikowaniu, że dana aplikacja posiada prawo do wykonania pewnej operacji, przechodzi ona w tryb jądra w celu wykonania tej operacji. W trybie jądra wykonywane są więc operacje, które wcześniej zostały odpowiednio zweryfikowane. 57

58 Przełączanie z trybu użytkownika na tryb jądra i z powrotem jest rozwiązane na drodze sprzętowej. W procesorze znajduje się specjalny rejestr, który sygnalizuje, jaki jest tryb. Także wszystkie strony pamięci oznaczone są jako wykonywalne w trybie użytkownika lub jądra i należą one do swoich własnych przestrzeni adresowych użytkownika i jądra. Każda aplikacja użytkownika ma własną wirtualną przestrzeń adresową, która nie zachodzi na fizyczną przestrzeń adresową jądra obydwie przestrzenie adresowe są rozłączne i nie zachodzą na siebie (poza pewnymi wyjątkami). Stanowi to pewien problem, ponieważ sterownik musi odwoływać się do pamięci użytkownika w sposób pośredni. Nie jest wskazane pobranie wskaźnika do pamięci z przestrzeni użytkownika, translacja na wskaźnik z przestrzeni jądra, bezpośredni zapis danych przez jądro w przestrzeni użytkownika i odwrotnie, ponieważ nie są wykonywane wtedy żadne operacje sprawdzające. Standardowy i sprawdzony sposób to skopiowanie danych przez funkcje specjalne jądra copy_to_user (kierunek pamięć jądra pamięć użytkownika) oraz copy_from_user (kierunek pamięć użytkownika pamięć jądra). Większość transferów w sterowniku zostało zrealizowane za pomocą funkcji copy_to_user i copy_from_user. Funkcje te sprawdzają, czy dana strona w przestrzeni użytkownika znajduje się rzeczywiście w fizycznej pamięci RAM, a nie została zrzucona na dysk (pamięć wirtualna). Jeśli strona pamięci została zrzucona na dysk, podejmowane są działania, aby znalazła się z powrotem w fizycznej pamięci RAM. Funkcje te sprawdzają także, czy wskaźniki z przestrzeni użytkownika są prawidłowe jeśli nie, kopiowanie nie jest wykonywane. Transfer danych przykładowo w kierunku z urządzenia przebiega następująco: transfer z urządzenia do pamięci sterownika, kopiowanie z pamięci sterownika do pamięci aplikacji użytkownika. Transfer danych jest w tym wypadku zawsze obciążony dodatkowym kopiowaniem danych. Nie przeszkadza to w przypadku transferów niewielkiej długości. Większe transfery mogą wprowadzać duże opóźnienia, niepotrzebnie obciążać procesor i zwiększać zajętość pamięci. Aby tego uniknąć, podjęto próbę wprowadzenia bezpośrednich transferów wejścia / wyjścia. Bezpośrednie transfery 58

59 wejścia / wyjścia polegają na tym, że transfer następuje bezpośrednio do bufora w przestrzeni adresowej aplikacji użytkownika. Implikuje to konieczność wcześniejszej translacji adresów przestrzeni użytkownika na adresy wirtualne przestrzeni adresowej jądra. Osiąga się to za pomocą wywołania funkcji get_user_pages i kmap. Funkcja get_user_pages dostarcza listę stron z przestrzeni użytkownika, a funkcja kmap dokonuje właściwej translacji na adresy wirtualne przestrzeni adresowej jądra. Okazało się jednak, że ponieważ następuje każdorazowa alokacja i translacja adresów z przestrzeni adresowej użytkownika na przestrzeń adresową jądra, transfer bezpośredni nie przynosi tak dużych zysków, jak tego oczekiwano, a jego użytkowanie dla programu do obsługi kamer i modułu DAQ jest bardziej skomplikowane od użytkowania transferu wykonywanego przy użyciu funkcji copy_to_user i copy_from_user Czasomierze w jądrze systemu Linux i odświeżanie watchdoga urządzenia Zgodnie z koncepcją realizacji sterownika (rozdział 3.1), w sterowniku należało zaimplementować odświeżanie watchdoga. Jest to zadanie wykonywane cyklicznie, w rytmie ustalonym przez wartość wyzwolenia watchdoga (obecnie 8 sekund). Wśród sposobów cyklicznego wykonywania zadań w jądrze systemu Linux należy wymienić kolejki zadań, tasklety i czasomierze (timery). W przypadku cyklicznego wywoływania funkcji, co ściśle określony okres czasu, najprostsze jest użycie czasomierza (timera). Na początku należy zainicjalizować timer (za pomocą funkcji init_timer), a następnie dodać go do sortowanej listy timerów utrzymywanej przez system (za pomocą funkcji add_timer). Lista ta jest sprawdzana 100 razy na sekundę i jeśli spełniony jest warunek, że ustawiony wcześniej czas upłynął wywoływana jest przypisana timerowi funkcja. Przy inicjalizacji podaje się czas, za jaki timer ma zadziałać, tzn. kiedy ma być wywołana przypisana funkcja. Czas podaje się nie w postaci godzina:minuta:sekunda tylko w jednostkach zwanych jiffy. Jeden jiffy jest to jednostka czasu, którą definiuje się następująco: 59

60 1 jiffy = 1 sekunda / HZ, gdzie HZ to wartość zdefiniowana w plikach nagłówkowych jądra, zazwyczaj 100, oznaczająca ilość tyknięć zegara systemowego na sekundę (jeśli konieczna jest zmiana wartości HZ, konieczna jest kompilacja jądra) System utrzymuje zmienną o nazwie jiffies, która jest zwiększana za każdym tyknięciem zegara systemowego. Wartość jiffies stanowi absolutną ilość tyknięć zegara systemowego od uruchomienia systemu. Przy podawaniu czasu zadziałania czasomierza (timeoutu) należy podać jego wielkość absolutną, a więc użyć wzoru: TA = jiffies + TIMEOUT*HZ gdzie TA oznacza wielkość absolutną timeoutu, TIMEOUT równy jest 8 sekund (okres wyzwalania watchdoga) i podawany jest w sekundach, a HZ jest równe 100. Po wywołaniu funkcji przypisanej timerowi, konieczne jest jego ponowne zainicjalizowanie w tej funkcji tak, aby absolutny limit czas czasomierza oznaczał kolejne odświeżenie watchdoga. Reinicjalizacja watchdoga i zmiana timeoutu jest także wykonywana w funkcji write sterownika, dzięki czemu wysyłanie danych służących odświeżaniu watchdoga następuje tylko wtedy, gdy to konieczne. Należy także zwrócić uwagę na procedurę kasowania czasomierza. Kasowanie czasomierza jest wykonywane przy odładowywaniu sterownika lub po wykonaniu komendy funkcji ioctl: STOP_WATCHDOG_REFRESH. W funkcji wywoływanej przez czasomierz dokonywana jest jego ponowna inicjalizacja, więc należy pamiętać, aby przed skasowaniem zabronić ponownej inicjalizacji timera i dodawania do sortowanej listy timerów. Następnie czas wywołania obecnego czasomierza jest modyfikowany na 1 jiffy (1/100 sekundy) i wywoływana jest funkcja kasująca czasomierz po zsynchronizowaniu (czyli po wywołaniu funkcji przypisanej do czasomierza). Jeśli ta procedura nie byłaby wykonywana, na skasowanie czasomierza należałoby czekać, aż wystąpi jego zaprogramowany timeout. Jeśli konieczne jest ponowne uruchomienie odświeżania watchdoga, można wykonać komendę funkcji ioctl: RESTART_WATCHDOG_REFRESH. 60

61 Implementacja funkcji ioctl w sterowniku W sterowniku zaimplementowano funkcję ioctl, która akceptuje następujące komendy: Komenda / definicja w pliku nagłówkowym sterownika: RESET_EVERYTHING STOP_WATCHDOG_REFRESH RESTART_WATCHDOG_REFRESH Opis Powoduje reset procesora kamery. Pozwala na zatrzymanie odświeżania watchdoga, opisane w rozdz Pozwala na wznowienie odświeżania watchdoga, opisane w rozdz GET_DATA_FROM_EP0x86 Pozwala na przełączenie się z domyślnego endpointu odbiorczego kamery 0x81 (umożliwiającego odczyt odpowiedzi na komendy wysłane do kamery) na endpoint 0x86 (umożliwiający odczyt obrazów) i odczyt danych. SIMPLE_TRANSPORT_ON Umożliwia bezpośredni transport danych do pamięci w przestrzeni adresowej użytkownika, opisane w rozdz UPLOAD_PROGRAM_FROM_ DEV_TO_COMP DOWNLOAD_PROGRAM_FROM_ COMP_TO_CAM Pozwala na transmisję pliku firmware z kamery do komputera. Umożliwia to wykonanie kopii zapasowej oprogramowania firmware urządzenia. Odświeżanie watchdoga musi być w tym czasie wyłączone. Pozwala na transmisję pliku firmware z komputera do kamery. Odświeżanie watchdoga musi być w tym czasie wyłączone. HALT_CAMERA_PROCESSOR Zatrzymuje procesor kamery podczas transmisji pliku firmware. START_CAMERA_PROCESSOR Uruchamia procesor kamery po zakończeniu transmisji pliku firmware. ZERO_MODULE_COUNT Tabela nr 2. Spis komend dla funkcji ioctl. Powoduje wyzerowanie licznika użycia modułu w celu umożliwienia odładowania modułu. Zgodnie z koncepcją realizacji sterownika (rozdział 3.1), w funkcji ioctl zaimplementowano komendy służące do odczytu danych. 61

62 Funkcja read wykorzystuje do odczytu za pomocą magistrali USB domyślnie endpoint 0x81, a funkcja write wykorzystuje do zapisu domyślnie endpoint 0x01. Są to endpointy typu bulk. Podczas wykonywania niektórych z komend zaimplementowanych w funkcji ioctl zmieniany jest numer, a także typ endpointu (np. w komendzie GET_DATA_FROM_EP0x86 na endpoint 0x86 typu bulk, w komendzie UPLOAD_PROGRAM_FROM_DEV_TO_COMP na endpoint 0x00 typu control). Dzięki zaimplementowaniu niektórych komend w funkcji ioctl struktura logiczna sterownika jest prostsza, ponieważ nie ma konieczności pilnowania w funkcji write sterownika, czy endpoint jest prawidłowy dla danej komendy. Uproszczenie kodu sterownika (częściowo kosztem zwiększenia komplikacji programu do obsługi kamer opisanego w rozdziale 5) otrzymuje się także dzięki temu, że w ioctl zaimplementowane są komendy przetestowane, o których wiadomo, że nie zmienią się w następnych wersjach firmware kamery. Większość zmienianych / nowych komend dotyczy wysyłania / odbioru danych z endpointów 0x01 / 0x81, a więc modyfikacja istniejącego kodu zachodzi przez prostą zmianę odpowiedniego ciągu bajtów z numerami komend wysyłanego w programie do obsługi kamer. Nie jest konieczna modyfikacja funkcji ioctl, tworzenie nowych definicji komend i ingerencja w kod sterownika jądra Debugowanie i testowanie sterownika Moduł sterownika pikam debugowano za pomocą metod opisanych w rozdziale Przebieg działania kodu sterownika monitorowano poprzez rejestr systemowy zawierający komunikaty wygenerowane w sterowniku za pomocą funkcji printk. Działanie sterownika było sprawdzone podczas wielu wielogodzinnych testów, gdy kamera wykonywała serie zdjęć. Działanie sterownika sprawdzano za pomocą programu do obsługi kamer, opisanego w rozdziale 5, tam też przedstawiono możliwości użycia sterownika przez programy. Właściwe działanie sterownika zostało do końca usprawnione i zweryfikowane. Rozwiązano także problem z ładowaniem sterownika. Nieprawidłowe zachowanie się sterownika i systemu Linux polegało na tym, że po załadowaniu sterownika komunikacja nie była nawiązywana, jeśli przewód USB kamery był podłączony przed włączeniem komputera. Tym samym praca kamery była możliwa tylko po podłączeniu kamery do komputera po włączeniu komputera 62

63 (hotplug), czyli w trybie, który uważa się zazwyczaj za podstawową zaletę USB. W naszym przypadku takie zachowanie sterownika było niedopuszczalne, ponieważ cały system miał działać automatycznie, być nienadzorowany przez człowieka i niemożliwe było ręczne ponowne podłączenie urządzenia. Dokładne zbadanie problemu pokazało, że sterownik nawiązuje prawidłowo komunikację w trybie USB 1.1, co jest normalnym zachowaniem, ale podczas negocjacji i przechodzenia do komunikacji w trybie USB 2.0 komunikacja jest zrywana. Rozwiązanie tego problemu polegało na odładowywaniu sterownika USB 2.0 systemu Linux, a pozostawieniu sterownika USB 1.1 (w systemie Linux różne wersje protokołu USB są obsługiwane przez różne sterowniki). Szczegółowa kolejność działań była następująca: odładowanie sterownika protokołu USB 2.0. załadowanie modułu sterownika kamery pikam.o, poczekanie na nawiązanie komunikacji w trybie USB 1.1. załadowanie sterownika protokołu USB 2.0, poczekanie na nawiązanie komunikacji w trybie USB 2.0. Problemy podobne do powyższego nękają także np. komercyjne zewnętrzne dyski twarde podłączane za pomocą USB i jedyne rozwiązanie zalecane przez producentów to ponowne podłączenie urządzenia. Końcowe testy sterownika zostały wykonane w obserwatorium testowym w Brwinowie pod Warszawą (rozdział 8) i zostały zakończone pomyślnie. 63

64 5. Realizacja programu do obsługi kamer Do testowania, debugowania, a później także do obsługi kamer została utworzona nakładka na sterownik (zgodnie z koncepcją realizacji tego programu, rozdział 3.2.), która umożliwia łatwe wykonywanie kolejnych operacji, dba o kolejność i synchronizację czasową kolejnych komend. Klasa nakładki wykorzystywana jest w module DAQ (rys. 15), jako jeden z modułów / bibliotek. Ponadto opracowano program wykorzystujący nakładkę, który pozwala na bezpośrednią obsługę kamery. Program do obsługi służył do rozwijania kolejnych funkcji kamery np. odświeżania watchdoga i ładowania firmware u kamery. Służył także do testowania komunikacji i sterownika kamery (opisanego w rozdziale 4) oraz do dobrania optymalnych parametrów działania urządzenia Implementacja nakładki i programu do obsługi kamer Program do obsługi posiada interfejs w trybie tekstowym i umożliwia wykonywanie poleceń wydanych za pomocą klawiatury. Schemat działania programu i sposób interakcji ze sterownikiem przedstawiono na rys

65 Rys. 17. Sposób interakcji programu do obsługi kamer ze sterownikiem. Poniżej przedstawiono spis poleceń programu do obsługi kamer. Stanowi on także menu główne programu do obsługi kamer, wyświetlane na ekranie. W nawiasach podano krótki opis poszczególnych funkcji. 0. Exit (Wyjście) 1. Check Temperature (Sprawdź temperaturę) 2. Cooling ON (Chłodzenie WŁ) 3. Cooling OFF (Chłodzenie WYŁ) 4. Open Shutter (DoMeasure) (Wykonaj pomiar) 5. GetData (Transfer danych) 6. Save image (Zachowanie obrazu) 7. Change Temperature (Zmiana temperatury) 8. Change Shutter Time (Zmiana czasu otwarcia migawki) 9. Move Focus Motor (Włącz silnik ogniskowania) 10. Reset EPLD (Reset EPLD) 11. Change Gain (Zmiana wzmocnienia) 13. Reset (Reset) 14. Change Readout Speed (Zmień prędkość odczytu) 15. Download firmware to device (no halting/restarting) - file usb.bin (Wysłanie firmware do urządzenia) 16. Send single byte ( to send more then 1 byte use 43 ) (Wyślij 1 bajt) 65

66 17. ID of camera (Pobierz ID kamery) 18. Upload firmware from device (no halting/restarting) (Przesłanie firmware z urządzenia) 19. Restart camera (Restart procesora kamery) 20. Halt Camera (Zatrzymanie procesora kamery) 21. Restart Watchdog Refresh (Restart odświeżania watchdoga) 22. Halt Watchdog Refresh (Zatrzymanie odświeżania watchdoga) 23. Prepare to Download: start with: finish with:19 21 (Przygotowanie do wysłania firmware) 24. Refresh Full Status (Odświeżenie całego statusu) 25. Take Picture (Zrobienie zdjęcia) 26. Set LNA Gain 8/20 (Zmiana wzmocnienia LNA) 27. Altera download: start with: finish with: 19 (Wysłanie firmware Altery) 28. Reboot Device (Ponowne uruchomienie urządzenia) 29. Open Shutter (Otworzenie migawki) 30. Read chip to RAM on-board (Odczyt czujnika CCD do pamięci) 31. Start Frame (Rozpoczęcie transferu klatki) 32. Read Chip With Closed Shutter (Odczyt czujnika CCD z zamkniętą migawką) 33. Clean CCD (Czyszczenie CCD) 34. Take 100 images (Wykonanie 100 zdjęć) 35. Test mode ON (Tryb testowy WŁ) 36. Test mode OFF (Tryb testowy WYŁ) 37. Shutter open mode (Tryb otwarcia migawki) 38. Shutter normal mode (Tryb normalny migawki) 39. Change Gain and Offset (Zmiana wzmocnienia i offsetu wzmacniacza) 40. Change ADC configuration register 0 (Zmiana rej. konfiguracji 0) 41. Change ADC configuration register 1 (Zmiana rej. konfiguracji 1) 42. Wait for temperature (Czekaj na odczyt temperatury) 43. Send bytes to camera (Wyślij bajty do kamery) Zrozumienie znaczenia większości powyższych poleceń nie stanowi problemu ich znaczenie jest oczywiste. Wśród poleceń znajdują się polecenia złożone, ale także takie, które pozwalają na wykonywanie tylko pewnych kroków z poleceń złożonych. Funkcje w klasie nakładki na sterownik stanowią prawie dokładne odzwierciedlenie poleceń w powyższym spisie. Program do obsługi kamer jest więc programem prostym, zajmuje się odczytem danych i poleceń wprowadzanych przez użytkownika, a następnie, bez wykonywania dalszych operacji, wywołuje funkcje nakładki. Wartości ustawiane za pomocą niektórych poleceń są zapamiętywane w wynikowym pliku obrazu FITS w postaci kluczy i wartości (klucze przedstawiono w tabeli nr 3, ostatnia kolumna) (opis formatu pliku FITS patrz rozdział 7.2.2). Funkcje w klasie nakładki dokonują translacji (rys. 17) wywołań tych funkcji na komendy kamery, które przedstawiono w tabeli nr 3. 66

67 Opis Konfiguracja procesora sygnału wizyjnego Czas otwarcia migawki Jednostka : 10ms Rozpoczęcie sekwencji pomiarowej Sterowanie silnikiem ostrości Komenda, bajt nr 1 bajt nr 2 bajt nr 3 Klucz FITS 0x01 Adres rejestru procesora Zakres 0..7 Wartość do zapisania do rejestru 0x02 MSB LSB EXPTIME 0x03 0x04 0x01 Ilość kroków w lewo 0x02 Ilość kroków w prawo 0x03 Okres pomiędzy krokami (jednostka: 10ms) 0x04 Uruchom silnik 0x05 Zatrzymaj silnik 0x06 Włącz zasilanie silnika 0x04 Sterowanie silnikiem ostrości 0x07 Wyłącz zasilanie silnika Sterowanie binningiem 0x05 0x01 Włącz binning 0x02 Wyłącz binning Sterowanie trybem MPP Sterowanie chłodzeniem Rozpoczęcie transferu danych pomiarowych Reset FPGA, bufory USB Żądanie statusu urządzenia Ustala prędkość odczytu CCD Rozpoczęcie sekwencji czyszczenia CCD Wzmocnienie przedwzmacniacza Sterowanie ogrzewaniem optyki 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x01 Włącz tryb MPP 0x02 Wyłącz tryb MPP 0x01 Włącz chłodzenie CCD 0x02 Wyłącz chłodzenie CCD 0x03 Ustaw temperaturę 0x00 Status i wartości temperatur 0xAA Wartości wilgotności (12 bajtów) Ustawienia częstotliwości zegarowych dla CCD 0x01 Wzmocnienie x20 0x02 Wzmocnienie x8 0x01 Ogrzewanie włączone 0x02 Ogrzewanie wyłączone FOCUS ABINN MPP COOLING Emulowany reset kamery Wysyła wersję kamery Pusta komenda, używana do odświeżania watchdoga Wysłanie firmware do procesora Altera 0xFD - - 0xEF 0xFC 0xDD Tabela nr 3. Najważniejsze komendy kamery. 67

68 Przykładowo włączenie chłodzenia czujnika CCD polega na wysłaniu ciągu 2 bajtów przez wywołanie funkcji: SendBytes_2(0x07, 0x01); gdzie pierwszy bajt: 0x07 Sterowanie chłodzeniem ; 0x01 Włącz chłodzenie CCD, co można odczytać z tabeli nr 3. Należy zwrócić uwagę, że w klasie nakładki na sterownik zdefiniowano funkcje SendBytes_1, SendBytes_2, itd., które wysyłają odpowiednio dokładnie jeden, dwa i więcej bajtów danych do kamery. Zdefiniowanie tych funkcji pozwala na dokładniejszą kontrolę nad poleceniami, a przede wszystkim na dopilnowanie, aby każdy ciąg komend miał odpowiednią długość. Funkcje te przeprowadzają zapis do pliku urządzenia, wywołując standardową funkcję języka C - write, która z kolei jest mapowana do funkcji write sterownika. Jak wspomniano, same nazwy poleceń w menu programu do obsługi kamer tłumaczą ich działanie, ale poniżej zamieszczono uwagi dotyczące niektórych funkcji i działania programu. Przed uruchomieniem programu do obsługi kamer konieczne jest załadowanie sterownika kamery (uruchomienie odpowiedniego skryptu). Może być konieczne użycie specjalnej sekwencji ładowania i odładowywania sterownika, opisanej w rozdziale 4.3, Debugowanie i testowanie sterownika. Po uruchomieniu program otwiera plik urządzenia kamery, wykonując funkcję: fd=open("/dev/usb/pikam0",o_rdwr); przy czym funkcja open to tym razem standardowa funkcja C, zdefiniowana w pliku nagłówkowym "fcntl.h", fd oznacza deskryptor pliku, pierwszy argument funkcji oznacza ścieżkę do pliku urządzenia, drugi argument oznacza, że program będzie dokonywać zapisu i odczytu pliku. Wywołanie tej funkcji jest następnie tłumaczone na wywołanie funkcji open sterownika. Po otwarciu program może wykonywać polecenia wydawane przez użytkownika. Przy wyjściu z programu plik /dev/usb/pikam0 jest zamykany. Niektóre z wykonywanych funkcji zaimplementowano w specyficzny sposób, wynikły podczas testowania kamery lub ze specyfiki zastosowania urządzenia. 68

69 W funkcjach dotyczących otwierania / zamykania migawki i robienia zdjęć rozgraniczono przypadek robienia zdjęć z otwartą i zamkniętą migawką. Zdjęcia z otwartą migawką wykonuje się w celu rejestracji badanego obiektu. Zdjęcia z zamkniętą migawką wykonuje się w celu rejestracji tzw. dark frame, czyli obrazu, w którym odwzorowany jest offset strukturalny wprowadzany do obrazu przez czujnik CCD kamery. Obraz ten następnie odejmuje się od zarejestrowanych obrazów nieba. Zdjęcia z zamkniętą migawką wykonuje się także w celu wyczyszczenia czujnika CCD czyszczenie CCD polega na zczytaniu ładunków wygenerowanych przez ruchy termiczne elektronów. W tym przypadku dane nie są nawet transferowane do komputera. Jeśli czujnik CCD nie jest chłodzony, może być konieczne dwukrotne czyszczenie czujnika. Funkcje w kamerze zaimplementowano w sposób ułatwiający ich wykonywanie przez komputer. W odniesieniu do migawki oznacza to, że otwieranie i zamykanie migawki nie zachodzi po wydaniu dwóch odrębnych komend. Implikowałoby to konieczność odmierzania czasu pomiędzy otwarciem i zamknięciem migawki przez komputer. Dokładny pomiar może być trudny do wykonania mogą na niego wpływać np. opóźnienia spowodowane przez duże obciążenie komputera. W zastosowanym rozwiązaniu wpierw ustawia się w kamerze czas otwarcia migawki, a następnie wyzwala pomiar, w którym otwarcie i zamknięcie migawki następuje automatycznie. Czas jest mierzony przez kamerę. To, czy pomiar na pewno się zakończył, ustala się przez odpytywanie kamery po minięciu czasu przeznaczonego na pomiar (odpytywanie cykliczne, jeśli to konieczne). W dość podobny sposób steruje się silnikami krokowymi ogniskowania optyki wpierw ustawia się prędkość i ilość kroków do wykonania, a dopiero potem włącza się zasilanie silników. Oddzielnego omówienia wymaga ładowanie firmware do układu FPGA (rys. 11) kamery. Firmware odpowiada za wiele podstawowych funkcji kamery zawiera np. sekwencje sygnałów sterujących elektroniki. Firmware należy ładować zgodnie z kolejnością wskazaną w punkcie 23. menu programu do obsługi kamer, a dokładnie: Zatrzymanie odświeżania watchdoga konieczne, aby w tym czasie nie nastąpiło odświeżenie watchdoga, a więc wysłanie zbędnego bajtu danych, co 69

70 spowodowałoby przekłamanie programu firmware. Wysłanie bajtu odświeżenia watchdoga może w tym wypadku nastąpić mimo ograniczenia, że normalnie odświeżanie watchdoga jest odkładane na później, jeśli występuje transfer na magistrali USB. Przygotowanie do wysłania oprogramowania ta komenda powoduje wejście procesora kamery w nieskończoną pętlę, dzięki czemu nie wykonywany jest żaden program dotyczący monitorowania parametrów kamery, a więc nie jest wywoływany żaden podprogram z FPGA. Zatrzymanie procesora kamery Transfer pliku skompilowanego firmware do kamery Restart procesora kamery czynność odwrotna do zatrzymania procesora kamery Restart odświeżania watchdoga - czynność odwrotna do zatrzymania odświeżania watchdoga Taka sekwencja ładowania firmware została ustalona na podstawie prób, w których dążono do uzyskania maksymalnej niezawodności tego procesu. Prawidłowe załadowanie firmware do kamer można zweryfikować przez odczytanie wersji firmware. Przed załadowaniem firmware pamięć jest standardowo wypełniana wartościami 0xff, a następnie nadpisywana przez firmware. Jeśli jako wersja firmware zostanie odczytane ciąg wartości 0xff załadowanie oprogramowania nie powiodło się Testowanie i debugowanie programu Testy programu skupiały się na sprawdzeniu, czy sekwencje komend zapisane w programie są prawidłowe i czy wysyłane są we właściwej kolejności. Sprawdzono także, czy program podejmuje właściwie działania po zerwaniu komunikacji. Badano, czy program dostarcza prawdziwych danych z czujników pomiarowych kamery. Obrazy zebrane podczas działania programu poddawano wzrokowej ocenie w celu stwierdzenia, czy ich rejestracja i transfer są prawidłowe. Wszystkie testy laboratoryjne wypadły prawidłowo. Testy końcowe przeprowadzono na stanowiskach testowych, w warunkach takich, jak docelowe (rozdział 8). 70

71 6. Realizacja programu do nakładania na siebie obrazów Koncepcja programu do nakładania obrazów (rozdział 3.3) mówi o uśrednianiu kolejnych pomiarów tego samego obszaru nieba w celu zmniejszenia wariancji uśrednionego pomiaru. Uśrednianie wartości pomiarów (na podstawie wzoru 6.1) zachodzi dla wszystkich pikseli na obrazie i pozwala na zwiększenie zasięgu (zwiększenie możliwości wykrywania słabszych gwiazd na obrazie) pozyskanych obrazów. Na skutek pozornego ruchu nieba jest ono na kolejnych obrazach przesunięte względem pierwszego obrazu w serii. Zaimplementowany program nakłada na siebie i uśrednia obrazy po uwzględnieniu tego przesunięcia Ogólny sposób postępowania i wykorzystania algorytmów Program pobiera jako dane wejściowe obrazy astronomiczne z odpowiadającymi listami gwiazd znajdujących się na obrazie, wygenerowanymi przez system analizy online w module DAQ. W module DAQ wpierw znajdowane są współrzędne gwiazd (x, y) na obrazie, a następnie wyznaczane są dla nich współrzędne niebieskie 5 (ra, dec). Współrzędne można wyznaczyć dzięki temu, że 5 współrzędne niebieskie współrzędne sferyczne pozwalające oznaczać położenie obiektów na niebie, określane przez układ odniesienia: oś i płaszczyznę do niej prostopadłą przechodzącą przez środek sfery niebieskiej (środek Ziemi). W niniejszej pracy używa się współrzędnych równikowych, dla których oś pokrywa się z osią obrotu sfery niebieskiej (celuje w kierunku bieguna północnego), a płaszczyzna z płaszczyzną równika niebieskiego. Rektastencja (ra) obiektu jest odpowiednio zmierzonym kątem w układzie odniesienia w zakresie od 0 do 360 lub od 0 h do 24 h. Deklinacja (dec) obiektu jest odpowiednio zmierzonym kątem w tym układzie odniesienia w zakresie od 0 do 90 i od 0 do

72 podczas akwizycji wiadomo jest, w który punkt nieba wycelowany jest teleskop. Jeśli ma zostać uśrednione wiele obrazów w serii, program postępuje w taki sposób, że wybiera do dopasowywania zawsze pierwszy obraz odniesienia i kolejny obraz z pozostałych. Program wczytuje 2 listy gwiazd z tych dwóch obrazów zawierające dla każdej gwiazdy następujące parametry: x, y (współrzędne gwiazdy na obrazie); magnitudo (jasność gwiazdy na obrazie); ra, dec (współrzędne niebieskie gwiazdy). Gwiazdy z dwóch list muszą zostać odpowiednio do siebie przyporządkowane. Problemem jest jednak to, że aby przyporządkować do siebie odpowiadające sobie gwiazdy, konieczna jest znajomość ich wzajemnego rozmieszczenia na kolejnych obrazach, a więc znajomość transformaty, którą należy zastosować do drugiego obrazu, aby otrzymać obraz podobny do pierwszego. Ale aby obliczyć transformatę, konieczna jest znajomość odpowiedniego przyporządkowania do siebie gwiazd. Aby obejść tę trudność, konieczne jest szukanie wśród wszystkich możliwych przyporządkowań gwiazd i sprawdzanie, czy takie przyporządkowanie jest prawidłowe. Przy sprawdzaniu kolejnych możliwych przyporządkowań gwiazd stosowane są takie warunki ograniczające, aby kroków algorytmu było jak najmniej. Szczegółowy opis tego algorytmu znajduje się w rozdziale Po znalezieniu przyporządkowania (rys. 18c) obliczana jest transformata określająca ułożenie obrazów względem siebie. Transformatę tę wylicza się według wzorów , rozdział 6.2. Drugi obraz jest nakładany na obraz odniesienia przy użyciu wyliczonej transformaty (dokładny opis algorytmu w rozdziale 6.3.2), a następnie są one uśredniane (rys. 18d). Należy pamiętać, że wyznaczone współrzędne położeń środków gwiazd podlegają fluktuacjom spowodowanym np. drganiami atmosfery. Na kolejnych obrazach pojawiają się także różne dodatkowe obiekty (meteory, samoloty, itd.). Algorytm wyznaczania transformaty musi być odporny na te utrudnienia. Wzrok ludzki wykonuje wspomniane przyporządkowanie gwiazd na poziomie nerwu wzrokowego, gdzie znajdowane są charakterystyczne cechy obydwu obrazów (np. trzy gwiazdy o podobnej jasności ułożone w linii prostej). Oko ludzkie nie potrafi znaleźć jednak przyporządkowania, gdy na obrazie znajduje się zbyt wiele gwiazd (zbyt wiele szczegółów do przetworzenia) i nie potrafi w takim wypadku stwierdzić, że np. obrazy te nie są do siebie podobne. Niniejszy algorytm nie ma możliwości takich jak oko ludzkie, ponieważ w oku rozpoznawanie zachodzi w sposób wysoce równoległy. Tym niemniej sekwencyjne wykonywanie kolejnych 72

73 kroków znajdowania przyporządkowania gwiazd do siebie prowadzi (być może po dużej liczbie kroków) do znalezienia odpowiedniego przyporządkowania, albo do stwierdzenia, że takie przyporządkowanie nie istnieje. a) pierwszy obraz x 1n, y 1n c) b) drugi obraz x 2n, y 2n d) x 1n, y 1n 10 x 1n, y 1n Rys. 18. Wizualizacja działania programu do nakładania obrazów wykonana w programie MATLAB. W objaśnieniach umieszczono oznaczenia współrzędnych gwiazd używane w przedstawionych wzorach. a), b) Dwa różne obrazy tego samego fragmentu nieba na wejściu procedury uśredniania. Obraz a) służy jako obraz odniesienia. c) Znalezienie przyporządkowania gwiazd. d) Znalezienie transformaty metodą najmniejszych kwadratów, nałożenie na siebie obrazów i ich uśrednienie. Można zauważyć wpływ fluktuacji położeń gwiazd z dwóch obrazów na szerokość połówkową odpowiadających gwiazd na obrazie wynikowym rys. d). 73

74 6.2. Podstawowe uwarunkowania dla algorytmów uśredniania obrazów W niniejszym podrozdziale podano podstawowe zależności, na podstawie których wykonano uśrednianie obrazów i badano uśrednione obrazy wynikowe (wzory ), badano wariancję szumu próbkowania dla pojedynczych obrazów (wzór 6.4) oraz obliczano transformatę przy użyciu metody najmniejszych kwadratów (wzory ). Dla n niezależnych pomiarów tej samej wielkości w niezmiennych warunkach (w opisywanym algorytmie dla pikseli reprezentujących ten sam obszar nieba na n obrazach), przy rozkładzie błędu każdego z pomiarów określonego rozkładem Gaussa o takich samych parametrach, estymator wartości oczekiwanej mierzonej wielkości jest równy: n 1 E( x ) = x sr = n x i (6.1) i= 1 gdzie E (x) to estymator wartości oczekiwanej pomiaru, x sr to wartość średnia pomiaru, xi to wartość otrzymana w jednym pomiarze. Estymator wartości oczekiwanej jest równy średniej arytmetycznej z prowadzonych pomiarów. Dla wykonanych pomiarów wariancję można obliczyć wg wzoru: n 1 2 V ( x ) = [ n xi -E(x)] (6.2) i= 1 gdzie V (x) to wariancja pomiaru, E (x) to wartość oczekiwana pomiaru, xi to wartość otrzymana w jednym pomiarze. Estymator w postaci średniej arytmetycznej z wielu pomiarów jest lepszy, ponieważ wariancja tego estymatora jest mniejsza od wariancji pojedynczego pomiaru i wyraża się wzorem [21]: ( x ) = V ( x) 1 V sr n oraz: D x = V ( ) ( ) sr x sr ( x ) = D( x) 1 D sr n (6.3) 74

75 V ( x ) gdzie sr to wariancja średniej arytmetycznej wartości wielu pomiarów, V ( x) wariancja wartości jednego pomiaru, D ( x sr ) to odchylenie standardowe średniej arytmetycznej wartości wielu pomiarów, D ( x) to odchylenie standardowe wartości jednego pomiaru. to Jeśli są wykonywane niezależne pomiary w niezmiennych warunkach, ale różnymi kamerami, tak jak w projekcie Pi of the Sky, konieczna jest normalizacja zarejestrowanych obrazów, ponieważ jasności obrazów z różnych kamer mogą być różne. Jednocześnie szum na obrazach z różnych kamer może mieć różną wariancję. Jeśli na pierwszym i drugim obrazie wykonano dwa pomiary x 1 i x 2 tej samej wielkości x i V(x 1 ) < V(x 2 ), może się okazać, że wariancja wartości średniej może być większa od V(x 1 ). Wtedy uśrednianie obrazów jest wogóle nieuzasadnione. Zostanie tutaj obliczone, o ile większa musi być wariancja V(x 2 ) od wariancji V(x 1 ), aby to zaszło. x + 1 x 2 2 ( x ) = V V sr 2 Ponieważ V ( ax) = a V ( x) i V ( x1 + x2 ) = V ( x1 ) + V ( x2 ) 1 V sr V x sr = V x1 + V 4 ( x ) = V ( x x ) ( ) [ ( ) ( x )] 2, mamy: Załóżmy, że wariancja drugiego pomiaru jest większa od wariancji pierwszego pomiaru o współczynnik Po podstawieniu: ( ) ( ) Gdy V x sr > V x 1 czyli: a 2, a więc ( x ) a V ( ) 2 a i > 1 1 V sr V =. [ ] 2 ( x ) = V ( x ) a V ( x ) 2 x1, nie ma sensu wykonywanie uśredniania serii pomiarów: 2 1+ a V 1 > 4 ( x ) V ( x ) 1 1 a 2 > 3 i a > 3 (6.4) 75

76 Jeśli uśredniane są dwa obrazy i wariancja szumu drugiego obrazu jest większa 3 razy od wariancji szumu pierwszego obrazu, nie należy korzystać z uśredniania, a do dalszej analizy użyć pierwszego obrazu, który ma najmniejszą wariancję szumu. Należy pamiętać, że wzór 6.4 ma zastosowanie tylko do dwóch obrazów oraz do dwóch obrazów uzyskanych jako wynik uśredniania dwóch serii obrazów. Dla większej ilości obrazów można wyprowadzić analogiczne wzory. Pomiary dla danego punktu na niebie znajdują się na kolejnych obrazach w danej serii. Przyjmijmy, że ten punkt, a właściwie niewielki obszar nieba, stanowi także pewien piksel na obrazie odniesienia. Zazwyczaj okazuje się, że na następnych obrazach w serii nie występuje pomiar jasności dla dokładnie tego samego obszaru nieba (piksela), co spowodowane jest przez pozorny ruch nieba. Ten sam obszar nieba może być na drugim obrazie usytuowany w najrozmaitszy sposób względem pierwszego obrazu. Jak to przekłada się na związki panujące pomiędzy kolejnymi dwoma obrazami? Przyjmijmy za punkty odniesienia na kolejnych obrazach pewne punkty na niebie (np. środki tych samych gwiazd). Obrazy mogą być przesunięte względem siebie (środek gwiazdy jest przesunięty na kolejnych obrazach o pewną liczbę pikseli, także wartość niecałkowitą), obrazy mogą być obrócone względem siebie (środki dwóch gwiazd na kolejnych obrazach nie tworzą linii równoległych), obrazy mogą być poddane transformacji nieliniowej, co spowodowane jest przez niedokładności wprowadzone przez optykę kamer i rzutowanie sfery nieba na płaski obszar przetwornika CCD (trójkąty wyznaczone przez środki tych samych gwiazd nie są do siebie podobne). Aby otrzymać właściwe wzajemne ustawienie pikseli na dwóch rozpatrywanych obrazach, należy wyznaczyć transformatę, jaką trzeba zastosować w stosunku do drugiego obrazu, aby otrzymać obraz jak najbardziej podobny do obrazu odniesienia. Transformatę tę wyznacza się na podstawie cech obydwu obrazów, a właściwie na podstawie związków panujących pomiędzy punktami odniesienia (środkami gwiazd) na obydwu obrazach. Nieliniowości są na tyle małe, że można nie uwzględniać ich podczas obliczeń, a więc do opisania zależności pomiędzy dwoma obrazami stosowana jest transformata liniowa. Dla transformaty liniowej, dla każdego punktu na obrazie (a w szczególności dla środków gwiazd) obowiązują następujące zależności: 76

77 x1'= a x2 - b y2 + c y1'= a y2 +b x2 + d (6.5) oraz: R = 2 a + b 2 cos α = a/r; sin α = b/r gdzie x 2, y 2 współrzędne punktu na drugim obrazie; x 1 ', y 1 ' obliczone współrzędne punktu dopasowanego do pierwszego obrazu (odniesienia); a, b, c, d współczynniki transformaty; c przesunięcie wzdłuż osi x; d przesunięcie wzdłuż osi y; α kąt obrotu pomiędzy obrazami; R współczynnik skali. Poszukiwane są współczynniki a, b, c, d transformaty danej wzorem 6.5. Korzystając z wyznaczonych współrzędnych dużej ilości gwiazd na obydwu obrazach można obliczyć najlepszą transformatę w sensie najmniejszego błędu średniokwadratowego ([22]). Błąd średniokwadratowy definiuje się tutaj jako średnią odległość dla wszystkich gwiazd pomiędzy gwiazdą z pierwszego obrazu i gwiazdą otrzymaną wskutek zastosowania transformacji drugiego obrazu i wyraża się wzorem: n 1 k = 0 (x 1k - x 1k ') 2 + (y 1k - y 1k ') 2 n (6.6) gdzie y 1k, x 2k to rzeczywiste współrzędne gwiazdy na pierwszym obrazie z dopasowywanej pary o numerze k; x 1k ', y 1k ' to obliczone współrzędne gwiazdy dopasowanej do pierwszego obrazu (odniesienia) z dopasowywanej pary o numerze k; n oznacza liczbę dopasowywanych gwiazd. Po znalezieniu minimum wyrażenia na błąd średniokwadratowy, zakładając: n= liczba dopasowywanych gwiazd oraz: n 1 n 1 n 1 S x1 = k= 0 n 1 x 1k, S x1x1 = k= 0 n 1 x 1k *x 1k, S y1y2 = k= 0 n 1 y 1k *y 2k, S x2 = k= 0 n 1 x 2k, S x1x2 = k= 0 n 1 x 1k *x 2k, S y2y2 = k= 0 n 1 y 2k *y 2k, S y1 = k= 0 n 1 y 1k, S x2x2 = k= 0 n 1 x 2k *x 2k, S x1y2 = k= 0 n 1 x 1k *y 2k, S y2 = k= 0 y 2k, S y1y1 = k= 0 y 1k *y 1k, S y1x2 = k= 0 y 1k *x 2k, 77

78 otrzymujemy: n *(S x1x2 y1y2 y1 y2 x1 x2 a = (6.7) n *(S x2x2 y2y2 + S + S y2y2 x2x2 ) -S ) -S x2 y2 *S *S x2 y2 -S -S y2 x2 *S *S n *(Sy1x2 -Sx1y2) + Sx1 *Sy2 -Sy1 *Sx2 b = (6.8) n *(S + S ) -S *S -S *S c = (S x1 -a*s x2 +b*s y2 )/n (6.9) d = (S y1 -a*s y2 -b*s x2 )/n (6.10) y2 x2 Powyższe wzory otrzymano przy użyciu programu MATLAB. Przy obliczeniach użyto zmiennych symbolicznych. Wyprowadzenia wzorów zamieszczono w dodatku Należy zwrócić uwagę, że obliczenia numeryczne wg wzorów 6.7, 6.8, 6.9 i 6.10 są podatne na błędy numeryczne. Jest to spowodowane faktem, że kolejne człony tych wyrażeń osiągają bardzo duże wartości i wykonywana jest na nich operacja dodawania i odejmowania. Wiadomo, że rozdzielczość liczb zmiennoprzecinkowych jest ograniczona, a przy odejmowaniu i dodawaniu precyzja jest tracona z powodu konieczności uzyskania równych mantys kolejnych liczb (dopiero wtedy dodanie lub odjęcie liczb jest możliwe). W tym przypadku najprostszym sposobem na poprawienie stabilności numerycznej jest zastosowanie do obliczeń liczb typu double (cecha dla tego zapisu liczb jest dłuższa) zamiast liczb typu float. Błędy obliczeń numerycznych znajdują swoje odzwierciedlenie w wielkości obliczonego błędu średniokwadratowego dla wzajemnego położenia gwiazd na dwóch obrazach. W skrajnych przypadkach przy zastosowaniu zmiennych typu float był on większy o ok. 0,5 piksela, co uniemożliwiało normalne zakończenie algorytmu (warunki zakończenia algorytmu nie mogły zostać spełnione). Zazwyczaj zwiększenie błędu było niewielkie. Przykładowo dla zmiennych typu double błąd średniokwadratowy był równy 0,1461 piksela, a dla zmiennych typu float błąd był równy 0,1463 piksela różnica wynosi 0,0002 piksela. 78

79 6.3. Algorytmy W niniejszym podrozdziale przedstawiono algorytmy wykorzystywane w programie Algorytm znajdowania przyporządkowania gwiazd pomiędzy dwoma obrazami Poniżej opisano szczegóły algorytmu znajdowania przyporządkowania pomiędzy gwiazdami na dwóch obrazach. Przedstawiono kolejne kroki algorytmu i warunki ograniczające. Warunki ograniczające w algorytmie dobrano eksperymentalnie (podano wartości domyślne), ale w razie potrzeby można je zmienić. Poniższa procedura jest przeprowadzana dla pierwszego obrazu odniesienia i dla każdego kolejnego obrazu w serii: 1. Znalezienie / załadowanie listy położeń gwiazd i ich jasności dla dwóch obrazów. 2. Sortowanie gwiazd na obydwu listach względem ich jasności. 3. Wybór pary gwiazd na pierwszym obrazie i na drugim obrazie (zaczynając od najjaśniejszych gwiazd ich położenie można znaleźć z największą dokładnością) i sprawdzenie, czy spełniają wszystkie warunki: ich jasność jest podobna, warunek (A) odległość pomiędzy gwiazdami jest podobna, warunek (B) odległość pomiędzy gwiazdami jest większa od 10 pikseli, warunek (C). Jeśli wszystkie warunki nie są spełnione, przejdź do Obliczenie transformaty przy użyciu znalezionej pary gwiazd. 5. Sprawdzenie, czy transformata opisuje prawidłowo obrazy: transformacja współrzędnych wszystkich gwiazd na drugim obrazie przy użyciu znalezionej transformaty i sprawdzenie, czy gwiazdy na drugim obrazie po transformacie znajdują się w odległości do 2 pikseli od gwiazd na pierwszym obrazie, warunek (G). Jeśli warunki (D), (E), (F), (G) nie są spełnione, przejdź do Obliczenie końcowej transformaty przy użyciu metody najmniejszych kwadratów. Jeśli nie jest spełniony warunek błędu średniokwadratowego (H), przejdź do 3. 79

80 Decyzja, czy dana transformata jest odpowiednia, jest dokonywana po uwzględnieniu następujących warunków / parametrów domyślnych, które można także odpowiednio ustawić: (A) Odchyłka jasności (magnitudo) dla gwiazd dopasowanych do siebie (domyślnie: poniżej 30%) (B) Tolerancja skali pomiędzy parami gwiazd (domyślnie: poniżej 5%) (C) Minimalna odległość gwiazd w parze (domyślnie: powyżej 10 pikseli; pomaga to uniknąć transformat z dużymi błędami spowodowanymi błędami w wyznaczaniu położeń poszczególnych gwiazd) (D) Procent gwiazd należący do obydwu obrazów (domyślnie: powyżej 50%) (E) Procent dopasowanych gwiazd (domyślnie: powyżej 70%) (F) Minimalna liczba dopasowanych gwiazd (domyślnie: powyżej 3, tzn. obrazy nie będą do siebie dopasowane, gdy tylko jedna para gwiazd zostanie dopasowana) (G) Maksymalne odchylenie gwiazdy na pierwszym obrazie od gwiazdy na drugim obrazie w pikselach (domyślnie: poniżej 2 pikseli) (H) Końcowy błąd średniokwadratowy dla dopasowanych gwiazd (domyślnie: poniżej 1 piksela) W opisywanej powyżej wersji algorytmu, do obliczeń wykorzystywane są tylko współrzędne (x, y) gwiazd na obrazie (tę metodę przyporządkowania do siebie gwiazd włącza się komendą METHOD IMAGECOMPARE, co opisano w dodatku 12.2). Dla wybranych parametrów domyślnych możliwe jest, że algorytm nie zakończy się sukcesem. W tym wypadku można zmienić powyższe warunki ograniczające tak, aby zakończenie algorytmu było bardziej prawdopodobne (np. zwiększyć dopuszczalny końcowy błąd średniokwadratowy, warunek (H)). Dla analizy błysków online można zapewnić, że algorytm zawsze zakończy się sukcesem, wykorzystując dodatkowo współrzędne niebieskie (ra, dec) gwiazd, gdy te są dostępne (zmieniając metodę przyporządkowania do siebie gwiazd komendą METHOD RADECCOMPARE, co opisano w dodatku 12.2). W ten sposób można także znacząco przyspieszyć działanie programu. W przypadku tej metody wielokrotne wykonywanie kroków 3, 4, 5, 6 algorytmu zastąpione jest wtedy jednokrotnym przyporządkowaniem do siebie gwiazd na podstawie ich współrzędnych niebieskich. 80

81 Przy porównywaniu współrzędnych niebieskich, należy wziąć pod uwagę następujące trudności: Przy obliczaniu odległości we współrzędnych niebieskich należy uwzględnić przejście współrzędnych deklinacji z 24 h na 0 h Przy dokładnych obliczeniach odległości (kątowych) we współrzędnych niebieskich należy stosować specjalne wzory Przy przeliczaniu współrzędnych niebieskich (ra, dec) na współrzędne obrazu (x, y) należy uwzględnić to, że współrzędne nieba skalują się różnie na współrzędne obrazu na różnych fragmentach obrazu Aby uniknąć wymienionych trudności przy sprawdzaniu, czy gwiazdy z drugiego obrazu po transformacji mają swoje odpowiedniki na pierwszym obrazie, zastosowano sprawdzanie warunków po przeliczeniu współrzędnych niebieskich na współrzędne obrazu. Oznacza to, że algorytm sprawdza warunki narzucone w pikselach po wyliczeniu tych warunków ze współrzędnych niebieskich. Wartości współrzędnych przyporządkowanych gwiazd są wykorzystywane przy obliczaniu współczynników a, b, c i d transformaty wg wzorów 6.7, 6.8, 6.9 i Algorytm transformujący obraz Po znalezieniu transformaty drugi obraz jest poddawany tej transformacie. W celu nałożenia dwóch obrazów na siebie przy użyciu wyliczonej transformaty, należy wyliczyć wartości pikseli odpowiadających pierwszemu obrazowi odniesienia z pikseli drugiego obrazu. Taką sytuację ilustruje rys. 19. Wartość piksela oznaczonego szarym kolorem (rys. 19, na obrazie nr 1) można wyliczyć jako średnią ważoną wartości z odpowiadających pikseli a, b, c i d (rys. 19, na obrazie nr 2). Podobnie można wyliczyć wartości wszystkich pikseli na obrazie nr 1. 81

82 Rys. 19. Rysunek poglądowy nakładania się na siebie pikseli na dwóch obrazach. Wartość odpowiadającą szaremu pikselowi na obrazie nr 1 można obliczyć jako średnią ważoną pikseli a, b, c, d z obrazu nr 2. Wagi średniej ważonej są wprost proporcjonalne do pól obszarów pikseli a, b, c, d nachodzących na piksel na obrazie pierwszym. Pola te można obliczyć dokładnie, traktując piksele jak figury geometryczne, ale dla dowolnego piksela jest to zadanie dość skomplikowane. Można także użyć metody nadpróbkowania (oversamplingu) [25]. Metoda ta jest prosta i zapewnia dokładność, którą można zwiększać odpowiednio do potrzeb. Jeszcze inne znane metody są szybsze (np. tzw. interpolacja bisześcienna), ale na skutek stosowanych przybliżeń, wprowadzają błędy niepożądane np. przy wykonywaniu pomiaru jasności gwiazd na obrazach po transformacji. W tym przypadku tych metod nie można użyć. Zastosowana metoda polega na tym, że każdy piksel na drugim obrazie jest dzielony na podpiksele (przykładowo 8 x 8 = 64 podpikseli). Współrzędne każdego podpiksela są przeliczane za pomocą znalezionej transformaty i znajdowane są współrzędne odpowiedniego piksela na pierwszym obrazie. Wartość podpiksela z drugiego obrazu jest dodawana do odpowiedniego piksela pierwszego obrazu. Nie jest to jednak wykonywane bezpośrednio, ponieważ suma dodanych wartości jest jeszcze odpowiednio skalowana (w podanym przypadku 64 podpikseli jest dzielona przez 64). Podpiksele z drugiego obrazu, które nie mają odpowiadających pikseli na pierwszym obrazie, są pomijane. Algorytm transformowania obrazów jest powtarzany dla wszystkich obrazów w serii. Wszystkie obrazy przetransformowane za pomocą znalezionej transformaty są dodawane do pierwszego obrazu i uśredniane. 82

83 6.4. Obsługa i uruchamianie programu Program uruchamia się z linii poleceń, podając jako opcję nazwę pliku konfiguracyjnego. Treść tego pliku jest następująca (przykładowo): :OUTFILE #Komentarz rotated_image.fit :FIRSTFILE :FLIP_AST_Y k2a_060521_00810.fit :MOVE k2b_060521_00813.fit :NO_FLIP_AST_Y k2b_060521_00810.fit Każdy z plików (rotated_image.fit, k2a_060521_00810.fit, itd.) poprzedzony jest odpowiednimi komendami. Komendy zaczynają się od znaku dwukropka ":". Wszystkie komendy są opisane w dodatku Testowanie i wyniki działania programu Wpierw przetestowano poprawność obliczonych wzorów. Wzory zweryfikowano pod kątem poprawności za pomocą symulacji w programie MATLAB, a następnie w docelowym programie w języku C++. Dokonano tego po włączeniu trybu testowego, naniesieniu znaczników na obrazy wejściowe i wizualnej ocenie, czy znaczniki oraz inne szczegóły obrazów znalazły się we właściwych miejscach, a więc obrazy zostały prawidłowo przetransformowane. Uśrednioną sumę przykładowych obrazów wraz ze znacznikami przedstawia rys

84 Rys. 20. Dwa dodane i uśrednione obrazy przy użyciu metody nie używającej współrzędnych niebieskich do dopasowywania gwiazd (METHOD IMAGECOMPARE). Ciemniejszy obszar obszar, gdzie znajduje się tylko jeden obraz wejściowy, jaśniejszy obszar obszar sumy obydwu obrazów. Widoczne są także zakłócenia wprowadzane przez kamerę na brzegach obrazów (z obydwu obrazów składowych) Zamieszczono znaczniki służące do testowania działania programu (dwa czarne krzyżyki w środkowej części obrazu) są one przesunięte względem siebie tak, jak opisuje to wyliczona transformata. Liczba gwiazd należących do obydwu obrazów jednocześnie: 270 Liczba dopasowanych gwiazd: 203 Współczynniki transformaty: a: , b: , c: , d: Błąd średniokwadratowy: piksela Kąt i skala transformaty: α = 0,067 ; R = 1,0033 Współrzędne (x: 0, y: 0) znajdują się w lewym dolnym rogu Następnie przetestowano program pod kątem błędów wprowadzanych podczas próbkowania w algorytmie transformującym obraz (rozdział 6.3.2). Sposób powstawania tych błędów przedstawiono na rys. 21. Rozpatrując, jak do wartości jasnoszarego piksela z obrazu nr 1 dodawane są wartości ciemnoszarych podpikseli znajdujących się na liniach oddzielających piksele obrazu nr 2 (rys. 21), 84

85 widzimy, że wartość odpowiadająca docelowemu pikselowi jasnoszaremu jest obarczona błędem, ponieważ podpiksele ciemnoszare nie mogą dobrze oddać kształtu pikseli z obrazu nr 2. Błąd dla jasnoszarego piksela jest wprost proporcjonalny do ilości ciemnoszarych podpikseli na pikselu jasnoszarym, z kolei ich ilość jest odwrotnie proporcjonalna do kwadratu częstotliwości nadpróbkowania. Dokładna wielkość błędu jest trudna do oszacowania, ponieważ na jednym pikselu jasnoszarym znajduje się różna ilość podpikseli ciemnoszarych, a błędy wprowadzane przez poszczególne podpiksele częściowo się znoszą. Rys. 21. Rysunek poglądowy nakładania się na siebie pikseli z dwóch obrazów z zaznaczonymi podpikselami i sposobem powstawania błędów próbkowania. Dlatego przeprowadzono badania różnych częstotliwości nadpróbkowania dla różnych obrazów. Dla podanych przykładów (tabela nr 4) przedstawiono wartość rzeczywistą i przewidywaną odchylenia standardowego szumu próbkowania. Wartość przewidywaną wyliczono ze wzoru a/n 2, gdzie n próbkowanie, a odchylenie standardowe dla próbkowania n = 1 (w przypadku obrazu nr 2 współczynnik a wyliczono odpowiednio stosując wzór dla próbkowania n = 4, aby unaocznić szczególnie wysoki błąd dla próbkowania n = 1 i n =2). Z badań tych wynika, że błąd zachowuje się zgodnie z przewidywaniami im wyższe nadpróbkowanie, tym mniejszy błąd i błąd jest odwrotnie proporcjonalny do kwadratu próbkowania. Dla próbkowania n = 1 i n = 2 (obraz nr 2) błąd jest szczególnie wysoki. Jest to spowodowane niekorzystnym ułożeniem pikseli z obydwu obrazów wobec siebie. Analogiczne zjawisko leży u podstaw tzw. efektu mory. W celu unaocznienia skali błędu podano także wartość średnią całego obrazu. Należy pamiętać, że niektóre wartości pikseli są znacznie większe od tej wartości średniej obrazu, a więc błąd próbkowania dla tych pikseli będzie także znacznie większy. 85

86 Obraz nr 1 Obraz nr 2 Wartość średnia obrazu odniesienia 2681, ,81 Próbkowanie (n): Przewidywane odchylenie standardowe szumu próbkowania Rzeczywiste odchylenie standardowe szumu próbkowania Przewidywane odchylenie standardowe szumu próbkowania Rzeczywiste odchylenie standardowe szumu próbkowania 1 14,76 14,76 20,94 98,78 2 7,38 9,17 10,47 98,69 4 3,69 3,72 5,23 5,23 8 1,85 2,45 2,62 4, ,92 1,10 1,31 3, ,46 0,55 0,65 3, ,23 0,33 0,33 3, ,12 0,18 0,16 0, ,06 0,08 0,08 0, ,03 0,03 0,04 0,29 Tabela nr 4. Wartości średnie badanych obrazów i odchylenie standardowe szumu próbkowania w zależności od częstotliwości próbkowania. Jako obrazu odniesienia użyto obrazu z częstotliwością próbkowania n = Dla obrazu nr 2, w przypadku próbkowania n=1, wartość odchylenia standardowego szumu jest równa 98 odchylenie wprowadzane przez próbkowanie jest tak duże, że uśrednianie obrazów przy takim próbkowaniu może być nieuzasadnione. Wzór 6.4 nakłada warunek na dokładność obliczania wartości pikseli przy wykonywaniu transformaty obrazu. Obliczenia te wprowadzają dodatkowy szum próbkowania. Jeśli suma wariancji szumu próbkowania i szumu drugiego obrazu poddanego transformacji będzie trzykrotnie większa od wariancji szumu pierwszego obrazu, wtedy warunek dany wzorem 6.4 nie będzie spełniony, a więc uśrednianie nie będzie uzasadnione. W takim przypadku należy zwiększyć częstotliwość próbkowania. Końcowe testy dotyczyły kluczowej funkcji programu tzn. czy wraz ze wzrostem ilości uwzględnionych pomiarów maleje wariancja szumu wartości średniej tych pomiarów (wg. wzoru 6.3). Przykładowe wyniki przedstawiono w tabeli nr 5 i na rys. 22. W celu lepszego zobrazowania przedstawiono pomiary odchylenia standardowego szumu (rozumianego jako pierwiastek z wariancji szumu), a nie wariancji. 86

87 ilość obrazów n Odchylenie standardowe szumu Zmierzone n przewidywane wg wzoru 6.3 odchylenie standardowe szumu ,7 225,7 2 1,41 159,6 190,2 6 2,45 92,2 80,6 10 3,16 71,3 66,8 15 3,87 58,3 83,2 20 4,47 50,5 74,1 30 5,48 41, ,16 36,6 0 Tabela nr 5. Zmierzone odchylenie standardowe szumu i przewidywane odchylenie standardowe szumu, nadpróbkowanie 512x512 (błędy próbkowania można zaniedbać), rozdzielczość obrazu wynikowego: 256x256 pikseli w tabeli przedstawiono odchylenia standardowe szumu dla 256*256=65536 uśrednionych pomiarów szumu odchylenie standardowe szumu I II III IV ilosc klatek Rys. 22. Wykres zmierzonego odchylenia standardowego szumu (kolor niebieski) i przewidywanego odchylenia standardowego szumu (kolor czerwony). Kwadraty (kolor czarny) przedstawiają wartości odchylenia standardowego szumu pojedynczych obrazów. Wartości liczbowe niektórych pomiarów przedstawiono w tabeli nr 5. Wykres podzielono na cztery obszary (opis w tekście głównym). Rzeczywiste wariancje szumu dla wszystkich obrazów obliczono wg zmodyfikowanego wzoru 6.2, przyjmując za wartości pomiarów xi kolejne wartości pikseli rozpatrywanego obrazu, a za wartości oczekiwane pomiaru E ) wartości (xi odpowiednich pikseli z obrazu wynikowego, uzyskanego po uśrednieniu 38 obrazów. 87

88 Należy zwrócić uwagę, że wartość oczekiwana pomiaru nie jest w tym przypadku równa średniej arytmetycznej wszystkich pikseli i jest inna dla każdego kolejnego piksela. Modyfikacja wzoru 6.2 polega na uwzględnieniu tego faktu. Przewidywane odchylenie standardowe szumu obliczono wg wzoru 6.3. Przy obliczaniu przewidywanego odchylenia standardowego, jako wartość bazową (V(x)) przyjęto odchylenie standardowe szumu dla pierwszego obrazu. Można zauważyć, że ogólnie zmierzone wartości odchylenia standardowego są zgodne z wartościami przewidywanymi, ale nie do końca. W czwartym obszarze na rys. 22 odchylenie zmierzone jest mniejsze od przewidywanego. Jest to skutek używania przy obliczeniach wariancji wartości średniej estymowanej, zamiast rzeczywistej wartości średniej. W estymatorze wariancji zastąpiono rzeczywistą wartość średnią jej estymatą, a taki estymator wariancji jest obciążony. W obszarze czwartym wartości obydwu obrazów (badanego oraz wynikowego, używanego jako estymator wartości średniej) są skorelowane, więc odchylenie standardowe szumu badanego obrazu jest pomniejszone o część skorelowaną z obrazem wynikowym, która jest tym większa im wyższy numer obrazu. W efekcie odchylenie standardowe szumu zmierzone dla obrazu powstałego po uśrednieniu 38 obrazów w serii jest równe zero. W obszarze drugim (odchylenia zmierzone niższe od przewidywanych) widać wpływ nagłego zmniejszenia się odchyleń pojedynczych obrazów (obrazy nr 7, 8, 9, czarne kwadraty na rys. 22), a w obszarze trzecim (odchylenia zmierzone wyższe od przewidywanych) widać wpływ nagłego zwiększenia się odchyleń pojedynczych obrazów (obrazy nr 12 15, czarne kwadraty na rys. 22). Nie oznacza to bynajmniej, że należy zakończyć analizę na obrazie nr 9, gdzie znajduje się lokalne minimum odchylenia. Zaburzenia, które zwiększają odchylenie, mają charakter lokalny, a więc powodują tylko nieznaczne pogorszenie własności obrazu wynikowego, który będzie później analizowany. Rys. 23a przedstawia właśnie takie lokalne zaburzenie. Jest to obraz nr 14 z serii, której statystykę przedstawiono na rys. 22 i jest na rys. 22 oznaczony krzyżykiem. Jego odchylenie standardowe szumu ma wartość będącą lokalnym maksimum w serii. Na rys. 23a można zobaczyć ślad po przelocie meteoru w lewym górnym rogu obrazu. Dla porównania przedstawiono także uśrednione 38 obrazów, gdzie to zaburzenie nie jest już widoczne (rys. 23b). 88

89 a) b) Rys. 23. Zdjęcia poddawane analizie odchylenia standardowego szumu. a) pojedyncze zdjęcie, nr 14 z serii, z widocznym zaburzeniem w postaci przelotu meteoru. b) uśredniona seria zdjęć, na której to zaburzenie nie jest już widoczne. Przedstawiony powyżej przykład analizy statystycznej obrazu udowadnia, że wnioski z takiej analizy muszą być odpowiednio zinterpretowane. Opisane lokalne zaburzenia na obrazie nie dyskwalifikują obrazu uzyskanego po uśrednieniu serii obrazów do dalszej analizy. Obraz ten jest ponownie poddawany procedurze astrometrii i fotometrii, a więc procedurze znajdowania położeń gwiazd i ich jasności. Dzięki temu, że szum na całym obrazie się zmniejsza, zwiększa się zasięg wykrywane są gwiazdy o mniejszej jasności. Przedstawiono to na rys. 24. Rys. 24. Wykres jasności znajdowanych gwiazd (oś pionowa, magnitudo) w zależności od ilości obrazów (oś pozioma, liczba obrazów), z których obliczono uśredniony obraz wynikowy. Dla obrazu wynikowego wykonywana jest procedura znajdowania gwiazd i ich jasności. 89

90 Z przeprowadzonych testów wynika, że zwiększenie zasięgu praktycznie nie występuje, gdy seria ma powyżej 40 obrazów. Na koniec przedstawiono napotkane problemy i właściwości procedury uśredniania obrazów. Obliczony błąd średniokwadratowy (zdefiniowany tak jak we wzorze 6.6) dla dwóch klatek jest mniejszy niż rzeczywisty, co potwierdzono w symulacji w środowisku MATLAB. Wynika to z tego, że procedura znajdowania błędu średniokwadratowego wykorzystująca metodę najmniejszych kwadratów oblicza inny obrót obrazu (parametr α) i współczynnik skali (parametr R), niż w rzeczywistej transformacie (widoczne jest to np. dla transformaty dla obrazu z rys. 20, gdzie obliczony współczynnik skali R jest większy od 1). Zmniejszenie wielkości błędu jest rzędu dziesiątych części piksela. Szerokość połówkowa 6 gwiazd zwiększa się dość znacząco na uśrednionym obrazie wynikowym. Wartość błędu dla tej samej pojedynczej gwiazdy na kolejnych obrazach ma rozkład gaussowski, a kierunek i zwrot wektora błędu jest losowy o rozkładzie równomiernym. Występowanie tego błędu powoduje zwiększenie szerokości połówkowej gwiazd na uśrednionym obrazie wynikowym. Jest to widoczne jako rozmycie gwiazd (rys. 25 i rys. 26). Rozmycie to może być jednak do pewnego stopnia pomocne wskutek rozmycia polepsza się podobieństwo kształtu profilu gwiazdy do gaussowskiego i wykrywanie gwiazd w procedurze astrometrii przebiega łatwiej. Zazwyczaj należy normalizować jasność dodawanych obrazów, jeśli pochodzą one z dwóch (wielu) kamer dostarczających obrazy o różnych jasnościach. Uśrednianie wielu obrazów w serii powoduje, że na obrazie wynikowym może znajdować się wiele niepożądanych artefaktów zebranych ze wszystkich obrazów. Największą grupę wśród takich artefaktów stanowią jasne piksele (hot pixels) wywołane oddziaływaniem promieniowania kosmicznego na czujnik CCD. Zazwyczaj na pojedynczym obrazie jasne piksele mają maksymalną wartość jasności i nawet na obrazie powstałym po uśrednieniu wielu obrazów pojedynczych można je zaobserwować i są one wykrywane przez procedurę astrometrii. Rozmycie i ilość niepożądanych artefaktów zwiększające się wraz z liczbą uśrednionych obrazów ogranicza długość serii obrazów do ok szerokość połówkowa ang. FWHM Full Width at Half Maximum, maksymalna szerokość profilu gwiazdy w połowie wysokości profilu. 90

91 Rys. 25. Obraz wynikowy powstały po uśrednieniu serii 38 obrazów progi wyświetlania: 2800 i 3200 (normalne progi wyświetlania: 0 i 65535). Rys. 26. Pojedynczy obraz progi wyświetlania: 2800 i 3200 (normalne progi wyświetlania: 0 i 65535). 91

92 6.6. Podsumowanie Opracowany program pozwala na zwiększenie zasięgu i na polepszenie jakości obrazów. Dzięki trybowi dopasowywania do siebie gwiazd opartego na współrzędnych niebieskich (komenda METHOD RADECCOMPARE) program działa szybko i jego działanie zawsze kończy się sukcesem. Umożliwia to jego użycie w procedurze automatycznego znajdowania błysków. Przyjęta metoda obracania obrazów (przy użyciu nadpróbkowania) pozwala na dokładną transformację jednego obrazu, aby był zorientowany tak, jak drugi oraz na uśrednienie obrazów. Dzięki programowi powiększono zasięg sprzętu o ponad 1 magnitudo, przy zmniejszeniu rozdzielczości czasowej dokonywanych pomiarów. 92

93 7. Realizacja interfejsu graficznego do przeglądania obrazów W celu wyświetlenia zarejestrowanych obrazów dokonano implementacji odpowiedniego programu w języku Java i C Opis implementacji interfejsu graficznego Na rys. 27 przedstawiono diagram klas interfejsu, zapisany w języku UML [26]. Na diagramie przedstawiono w rozwiniętej postaci zależności klasy panela ImagePanel, pozwalającego na wyświetlanie obrazów. Program wykorzystuje także klasę panela CameraPanel, który ma służyć do bezpośredniej obsługi kamery z interfejsu graficznego. Ta funkcjonalność programu będzie jeszcze rozwijana. Na rys. 28 pokazano przykład działania interfejsu wraz z oznaczonymi używanymi komponentami Opis klas i komponentów Większość komponentów graficznych w Javie dziedziczy po klasie JComponent, która dziedziczy po klasie Container, dlatego komponenty mogą służyć jako pojemniki dla kolejnych komponentów [27]. Kolejne komponenty - potomki dodaje się do rodzica za pomocą odpowiedniej funkcji. W przypadku komponentów graficznych uzyskiwana jest w ten sposób struktura komponentów, w której każdy kolejny komponent - potomek znajduje się (zazwyczaj) na rodzicu. Dokładny układ komponentów - potomków jest ustalany przez tzw. zarządcę rozkładu (layout manager). Wymusza on odpowiednie ułożenie komponentów względem siebie, także podczas zmiany rozmiarów rodzica. 93

94 W niniejszym programie zaimplementowano w wielu przypadkach subclassing komponentów (czyli utworzenie komponentu przez dziedziczenie po komponencie standardowym np. JComponent, w którym pewne jego zachowania są inne od standardowych) [28]. Rys. 27. Diagram klas interfejsu graficznego w języku UML. 94

95 Rys. 28. Przykładowe wykorzystanie interfejsu graficznego do przeglądania obrazów. Zamieszczono opisy komponentów interfejsu. Na dolnym rysunku widoczny jest opis oglądanego obrazu FITS. 95

96 Klasa MyComponent i JScrollPane Komponent MyComponent i komponent umożliwiający przewijanie potomka JScrollPane zostaną opisane razem, ponieważ w niniejszym interfejsie współpracują ze sobą. Komponenty te są wykorzystywane w klasie ImagePanel i służą do wyświetlania obrazu w powiększeniu i przewijania obrazu, jeśli jego rozmiar jest większy niż obszar możliwy do wyświetlenia. Parametry obszaru, który będzie rzeczywiście wyświetlany (m.in. rozmiar tego obszaru), są dostępne przez klasę JViewPort. Relacje pomiędzy klasą JScrollPane, MyComponent i JViewPort przedstawia rys. 29. Rys. 29. Relacje pomiędzy klasą JScrollPane, MyComponent i JViewPort. Na podstawie [28]. Aby było możliwe narysowanie czegokolwiek przy wykorzystaniu JScrollPane, należy wykonać subclassing komponentu JComponent i dodać ten komponent do JScrollPane jako potomka. Taką realizacją subclassingu standardowej klasy JComponent jest klasa MyComponent. MyComponent nadpisuje następujące funkcje z JComponent: update(graphics g) wywołuje funkcję paint paint(graphics g) odrysowuje zawartość komponentu, w tym wypadku ustawiony obraz i implementuje następujące własne funkcje: - setzoom (int zoomvalue_inpercents) ustawia powiększenie - setimage (BufferedImage bi) ustawia obraz do wyświetlania - MyComponent (JScrollPane sp) konstruktor 96

97 Ponadto implementuje interfejs MouseMotionListener i eksportuje własny interfejs MyComponentMouseListener. Opis sposobu implementacji funkcji i interfejsu przedstawiono poniżej. Funkcja update jest wywoływana przez system, aby odrysować zawartość komponentu. Odrysowuje ona tło i wywołuje funkcję paint, która wykonuje właściwe odrysowanie. Funkcja update została nadpisana, aby wywoływać paint bezpośrednio, bez odrysowywania tła. Zmniejsza to migotanie podczas wielokrotnego odrysowywania. Zadaniem funkcji paint jest odpowiednie odrysowanie obrazu ustawionego do wyświetlania za pomocą funkcji setimage. Funkcja paint z klasy MyComponent zajmuje się tylko odpowiednim powiększeniem i wyświetleniem odpowiedniego fragmentu obrazu, przy czym współpracuje z JScrollPane. Pozostałe aspekty wyświetlania (zamiana przestrzeni kolorów z monochromatycznego 16-bitowego na RGB, wizualizacja progów wyświetlania obrazu, przerzucenie obrazu względem osi Y) są obsługiwane przez klasę ImagePanel przed przekazaniem obrazu do klasy MyComponent za pomocą funkcji setimage. Taki podział zadań jest podyktowany tym, że ImagePanel wykonuje wszystkie najbardziej czasochłonne operacje, a MyComponent wykonuje tylko końcowe, krótko trwające operacje, dzięki czemu przeglądanie obrazu jest szybkie. W przeciwieństwie do wielu dostępnych gotowych komponentów wyświetlających obrazy, MyComponent wyświetla tylko ten fragment, który rzeczywiście musi być wyświetlony, a nie próbuje odrysować całego obrazu. Ponadto powiększony / pomniejszony obraz nie jest buforowany w pamięci, a duża prędkość działania jest mimo tego zachowana, dzięki bezpośredniemu zapisowi na ekranie bez buforowania. Po wywołaniu przez system, funkcja paint ustala, jakie są wymiary MyComponent i jakie są rzeczywiste współrzędne całego obrazu (rys. 29). Dzięki temu może obliczyć, jakie powiększenie zostało ustawione przez użytkownika, a następnie przez funkcję setzoom (opis poniżej). Następnie paint pobiera z JViewport współrzędne fragmentu obrazu do wyświetlenia. Jeśli powiększenie jest różne od 1, używana jest funkcja dokonująca jego transformaty (powiększenia lub pomniejszenia) i odrysowująca obraz, w przeciwnym razie dokonywane jest normalne odrysowanie bez transformaty, dzięki czemu jest zapewnione, że obraz zostanie odrysowany dokładnie. Jest to ważne, ponieważ programy do wyświetlania obrazów astronomicznych nie tylko wyświetlają obrazy, 97

98 ale wyświetlają wartość, która znajduje się pod kursorem myszy konieczne jest więc, aby wyświetlanie było przewidywalne. W przeciwnym razie konieczne byłoby wyświetlanie obrazu piksel po pikselu, co negatywnie wpłynęłoby na wydajność. Z tego względu przy powiększaniu obrazu jeden piksel jest mapowany na całkowitą ilość pikseli, np. 2, 3,..., 20 pikseli (powiększenie 200, 300,..., 2000%). W niektórych przeglądarkach obrazów jeśli obraz zostanie powiększony i przewinięty za pomocą pasków przewijania o niecałkowitą ilość powiększonego piksela (np. wyświetlanie obrazu zaczyna się w połowie powiększonego piksela obrazu), występuje nieprzyjemny efekt obcinania obrazu o jeden powiększony piksel. W celu uniknięcia tego efektu wszystkie obliczenia współrzędnych fragmentu obrazu do wyświetlania są zaokrąglane w górę. Należy podkreślić, że dzięki odpowiedniemu zaimplementowaniu funkcji paint uniknięto implementowania interfejsu Scrollable. Implementacja tego interfejsu przez np. listy i tabele zapewnia ich odpowiednie zachowanie podczas przewijania. W tym przypadku implementacja tego interfejsu nie jest konieczna, ponieważ przewijanie obrazu wykorzystywane jest tylko w podstawowym zakresie. W funkcji SetZoom ustawiane jest powiększenie obrazu. Osiąga się to przez odpowiednią zmianę rozmiaru komponentu MyComponent (tzn. rozmiary komponentu = rozmiary obrazu * powiększenie). Komponent JScrollPane automatycznie dostosowuje swoje zachowanie do rozmiaru swojego potomka MyComponent, a więc: automatycznie wyświetla poziomy lub pionowy suwak przewijania, jeśli rozmiary obrazu są większe od rozmiaru obszaru wyświetlania oraz zmienia zakres przewijania suwaków i sposób ich wyświetlania. Za pomocą funkcji SetImage ustawiany jest obraz, który ma być wyświetlany. Obraz musi należeć do klasy BufferedImage, ponieważ ta klasa umożliwia np. powiększanie obrazu i jego bezpośredni zapis na ekran, bez buforowania. Ten format zapewnia też możliwość wyboru formatu przechowywania obrazu w pamięci, np. możliwe jest przechowywanie obrazu w formacie oryginalnym (w przypadku formatu FITS dane są zapisane w szesnastobitowych zmiennych typu unsigned short), a nie narzuconym (np. ośmiobitowe zmienne reprezentujące model RGB). Dzięki temu, że zdefiniowany jest konstruktor MyComponent (JScrollPane sp), wymuszono wywołanie konstruktora z argumentem typu JScrollPane, a nie wywołanie domyślnego konstruktora 98

99 bezargumentowego. Zapewniono tym, że MyComponent będzie używany z odpowiednim rodzicem instancją klasy JScrollPane. MyComponent implementuje interfejs MouseMotionListener i eksportuje interfejs MyComponentMouseListener, tzn. po wywołaniu funkcji mousemouved(int x, int y) (x, y współrzędne myszy) z interfejsu MouseMotionListener przez system, ta funkcja wywołuje funkcję mousemouved(int x, int y) (x, y współrzędne piksela na obrazie) komponentów, które zaimplementowały interfejs MyComponentMouseListener. Takie postępowanie jest konieczne w celu uzyskania enkapsulacji klasy, a więc stanu, w którym wszystkie dane są dostępne poprzez wywołanie metod klasy, a nie bezpośrednio. Interfejs MouseMotionListener (rys. 27) pozwala na monitorowanie ruchów myszy (w obrębie tego komponentu) i pozwala na uzyskanie współrzędnych położenia kursora myszy. Te współrzędne nie są jednak tożsame z położeniem piksela wskazywanego na obrazie przez kursor. Należy w tym wypadku uwzględnić powiększenie i przesunięcie obrazu w oknie. Zadanie obliczenia właściwych współrzędnych i przekazania ich do komponentów wykonuje interfejs MyComponentMouseListener. Komponent MyComponent jest komponentem, który zajmuje się wszystkimi aspektami wyświetlania i powiększania obrazu, jak również obsługi myszy. Dzięki całkowitemu zamknięciu pewnej funkcjonalności w tym komponencie, może on współpracować z komponentem JScrollPane lub samodzielnie i być użyty ponownie w innych programach Klasa ImagePanel W celu wypełnienia założeń dotyczących interfejsu (rozdział 2.2.4, punkt 2), przy tworzeniu programu przyjęto zasadę, że główne okno programu udostępnia swoje zasoby (pasek menu JMenuBar, zarządcę zakładek JTabbedPane) kolejnym panelom (zakładkom), a panele mogą wykorzystywać te zasoby w dowolny sposób. Dzięki takiej budowie rozwijanie interfejsu jest łatwiejsze i polega na dodawaniu kolejnych rodzajów paneli. Użytkownik może włączyć i wyłączyć panel dowolnego rodzaju. Poniżej opisany jest jeden z nich: panel klasy ImagePanel. Klasa panela ImagePanel dziedziczy po standardowej klasie JPanel. 99

100 Funkcjonalność tego panela obejmuje: Wczytanie obrazu astronomicznego w formacie FITS, także skompresowanego (dekompresja obrazów możliwa pod Linuksem i pod Windows) Wczytanie opisu tego obrazu Przygotowanie obrazu do wyświetlenia Obsługa funkcji zmiany progów wyświetlania obrazu (ramka Image thresholds, rys. 28), zmiany powiększenia (ramka Zoom, rys. 28) oraz wyświetlania położenia kursora myszy i wartości przez niego wskazywanej (ramka Mouse pointer, rys. 28). Dzięki temu, że zdefiniowany jest konstruktor klasy panela ImagePanel (JMenuBar, JTabbedPane), wymuszono wywołanie konstruktora z argumentem typu JMenuBar, JTabbedPane, a nie wywołanie domyślnego konstruktora bezargumentowego. ImagePanel uzyskuje dostęp do odpowiednich zasobów w postaci paska menu JMenuBar, który może modyfikować i zarządcy zakładek JTabbedPane, na którego zmiany może reagować. Modyfikacja paska menu polega na tym, że panel dodaje własne menu (w tym przypadku menu Image, rys. 28), gdy jest aktywowany i kasuje je, gdy jest deaktywowany. Jest to realizacja koncepcji tzw. menu dynamicznych. W jaki sposób panel ImagePanel dowiaduje się o aktywacji i deaktywacji? Zachodzi to przez implementację interfejsu zmiany stanu ChangeListener, eksportowanego przez klasę JTabbedPane.SingleSelectionModel. Za każdym razem, gdy zakładka zmienia swój stan z nieaktywnej na aktywną lub na odwrót, wywoływane są funkcje statechanged interfejsu ChangeListener, implementowane przez wszystkie panele zakładek. Jeśli występuje zmiana stanu z nieaktywnego na aktywny, panel dodaje menu do paska menu, w przeciwnym razie kasuje menu z paska. Przyporządkowanie własnego menu do każdego z paneli powoduje, że każde menu po jego wybraniu automatycznie wywołuje funkcję obsługi menu z właściwego panela. Po wybraniu opcji menu Open Image / Otwórz obraz i po wyborze pliku z rozszerzeniem fit jest on otwierany za pomocą klasy Fits z pakietu Nom.tam.fits [33]. Pakiet ten stanowi implementację obsługi plików FITS w języku Java. Jeśli wybrany zostanie wybrany plik z rozszerzeniem fitc, plik taki jest 100

101 wcześniej rozkompresowywany przez wywołanie funkcji rodzimej za pomocą interfejsu JNI, co opisano w rozdziale 7.3. FITS (Flexible Image Transport System Elastyczny system transportu obrazów) jest formatem danych stosowanym w astronomii do przechowywania i transportu danych. Format ten różni się od innych popularnych formatów graficznych pod kilkoma względami. Jednym z nich jest to, że plik FITS oferuje możliwość dołączenia do danych opisu w postaci tekstowej w formie czytelnej dla człowieka. Drugim jest to, że możliwe jest składowanie danych w postaci tablic jedno- dwu- i trójwymiarowych. Niniejszy program obsługuje tylko tablice dwuwymiarowe, ponieważ tylko te są używane w projekcie. Pojedynczy plik FITS składa się z jednostek heder / dane (header / data unit, HDU). W hederze opis danych jest zapisany za pomocą sekwencji rekordów o stałej długości 80 znaków. Mają one ogólną formę: KLUCZ = WARTOŚĆ / Komentarz Długość sekwencji rekordów musi być wielokrotnością 2880 bajtów, w razie potrzeby brakujące rekordy są zapełniane rekordami z kluczem o wartości COMMENT. Ostatni rekord ma klucz o wartości END. Heder musi zostać wczytany do programu, ponieważ zawiera dane, w jaki sposób należy wyświetlić dany plik, a w szczególności zawiera rekordy: BITPIX = 16 / number of bits per data pixel (rozdzielczość danych w bitach na piksel warunkuje typ danych, w tym przypadku typ short) NAXIS = 2 / number of data axes (iluwymiarowa jest tablica danych, w tym przypadku tablica 2-wymiarowa) NAXIS1 = 2062 / length of data axis 1 NAXIS2 = 2048 / length of data axis 2 (rozdzielczość obrazu wzdłuż obydwu osi) BZERO = / offset data range to that of unsigned short (offset danych, który należy dodać do danych oryginalnych, w tym przypadku oznacza zakres danych równy zakresowi typu unsigned short) 101

102 Także inne rekordy są wczytywane i wyświetlane na zakładce Fits keys (rys. 28). Dopiero wyświetlenie nagłówka pliku FITS umożliwia użytkownikowi normalną pracę z tym plikiem, ponieważ zawarte są w nim niezbędne informacje, takie jak współrzędne niebieskie środka obrazu, data ekspozycji, czas naświetlania, itd. Po wczytaniu obrazu musi być on przekonwertowany do postaci możliwej do wyświetlenia przez funkcje Javy. Pierwszą wykonywaną operacją jest stworzenie obiektu klasy BufferedImage, standardowo dostępnej w środowisku Java. Klasa ta pozwala na bezpośrednie i efektywne wyświetlanie danych obrazu uporządkowanych w różny sposób. Dołącza się do niej klasy pozwalające na ustalenie właściwości obrazu. O uporządkowaniu danych w danym pikselu decyduje raster (klasa Raster). W tym przypadku w rastrze znajdują się piksele 16-bitowe. O tym, jak będzie wyświetlany kolor, decyduje klasa modelu koloru ColorModel. W tym przypadku jest to model wyświetlania w odcieniach szarości, 16-bitowy. Możliwe jest także zastosowanie indeksowanego modelu kolorów IndexColormodel, co umożliwia zastosowanie tzw. map kolorów, pozwalających na jeszcze lepszą wizualizację zarejestrowanych obrazów. Niestety zastosowanie tego modelu kolorów jest znacznie utrudnione przez błąd (bug) Javy, powodujący powstanie wyjątku, gdy obraz z tym modelem kolorów posiada powiększenie różne od 1. Po utworzeniu obiektu BufferedImage jest on zapełniany danymi z pliku FITS. W tej chwili wykonywane jest przerzucenie obrazu względem osi Y (ale nie względem osi X). W ten sposób symulowana jest właściwość obrazu w standardzie FITS, że punkt (0, 0) znajduje się w lewym dolnym rogu obrazu, a nie w lewym górnym rogu. Wykonywane jest także żądane rozciągnięcie histogramu jasności obrazu [25]. Wartości minimum i maksimum wartości histogramu ustawia użytkownik (wartości w ramce Image thresholds, rys. 28). Wartości pomiędzy minimum i maksimum histogramu są skalowane pomiędzy jasnością minimalną (R: 0, G: 0, B: 0), a jasnością maksymalną (R: 255, G: 255, B: 255). Wartości poniżej minimum są wyświetlane jako piksel o jasności minimalnej, a powyżej maksimum jako piksel o jasności maksymalnej. Pozwala to na polepszenie zakresu dynamicznego obrazu, a więc polepszenie kontrastu, dzięki czemu użytkownik ma możliwość uwidocznienia żądanych szczegółów. 102

103 Obraz spreparowany w powyższy sposób jest przekazywany do komponentu MyComponent, gdzie następnie może być jeszcze powiększony przy wyświetlaniu. Dzięki zastosowaniu klasy BufferedImage można uniknąć ponownego alokowania pamięci dla obrazu po każdej operacji systemu obsługi grafiki obraz końcowy jest umieszczany nie w pamięci, lecz bezpośrednio na ekranie, po wykonaniu wszystkich operacji graficznych w komponencie MyComponent w jednym kroku. Klasa ImagePanel implementuje wiele interfejsów pozwalających jej na śledzenie zmian parametrów w kontrolkach służących do opisanych powyżej manipulacji parametrami obrazu (przykładowo klasa nasłuchuje zmian położenia suwaka komponentu JScrollBar, z ramki Image thresholds służącego do zmiany progów wyświetlania, rys. 28) i odpowiednią reakcję na te zmiany. Parametry te są składowane bezpośrednio w kontrolkach, nie są kopiowane do innych zmiennych programu. Ułatwia to zachowanie spójności działania programu, dzięki temu, że wykorzystywane są zawsze dane spójne z ustawieniem użytkownika Java Native Interface Kluczową funkcjonalnością programu jest przeglądanie obrazów zarejestrowanych i skompresowanych podczas akwizycji danych. W tym celu konieczna jest dekompresja tych obrazów (plików z rozszerzeniem fitc). Procedura kompresji / dekompresji była dostępna w bibliotekach udostępnionych przez projekt ASAS. Była ona zaimplementowana w języku C, a kompilowana pod systemem Linux. Konieczne było znalezienie sposobu na wywoływanie tej procedury z poziomu Javy. Jedną z możliwości było takie zmodyfikowanie kodu w języku C, aby komunikował się z aplikacją w Javie za pomocą TCP/IP. Wymagałoby to jednak implementacji obsługi TCP/IP. Wadą tego rozwiązania byłoby także utrudnione uruchamianie programu rodzimego w języku C z aplikacji w Javie, zaletą byłoby odseparowanie aplikacji w Javie od procesu rodzimego, dzięki czemu wszelkie błędy w tym procesie nie wpływałyby na aplikację Javy. Inną możliwość udostępnia Java Native Interface (JNI). JNI umożliwia integrację procedur napisanych w dowolnym rodzimym języku programowania z wirtualną maszyną Javy. Integracja taka wymaga odpowiednich modyfikacji zarówno w kodzie 103

104 Javy, jak i w kodzie rodzimym. Wpierw należy stworzyć klasę w Javie, która zawiera metodę rodzimą (tutaj Uncompress): public class FitCuncompressClass { public FitCuncompressClass() {} public native int Uncompress(String Filename); static {System.loadLibrary("FitCuncompressClass");} } Deklaracja metody rodzimej musi zawierać modyfikator native. Nie można umieścić definicji tej funkcji w Javie, ponieważ jest ona dokonywana w języku C. Polecenie System.loadLibrary ("FitCuncompressClass") powoduje załadowanie odpowiedniej biblioteki rodzimej. Rzeczywista nazwa używana przez loader bibliotek Javy w systemie Windows to FitCuncompressClass.dll, a w systemie Linux to libfitcuncompressclass.so. Odpowiednia biblioteka dla danego systemu musi znajdować się w ścieżce przeszukiwania bibliotek, zawsze innej dla różnych systemów. Stanowi to często problem, ponieważ użytkownik musi dopilnować, aby biblioteka rodzima znajdowała się w odpowiednim katalogu. W tym przypadku biblioteki zostały umieszczone w archiwum jar, zaś odnośnik do tych bibliotek jest przekazywany za pomocą pliku jnlp wykorzystywanego przez Java Web Start (co opisano w rozdziale 7.4). W pliku jar znajdują się biblioteki dla systemu Windows i Linux tak, że loader bibliotek może wybrać właściwą. W jaki sposób można utworzyć biblioteki? Należy w tym celu posłużyć się narzędziem javah, dostarczanym standardowo z dystrybucją Javy. Po skompilowaniu klasy FitCuncompressClass należy wydać polecenie: javah jni tryer.fitcuncompressclass Należy podkreślić, że wymagane jest podanie nazwy pakietu (tryer), w przeciwnym razie loader klas nie odnajdzie przy ładowaniu skompilowanej biblioteki. Powstanie plik nagłówkowy języka C tryer_fitcuncompressclass.h z deklaracją metody Uncompress. Następnie w oparciu o plik nagłówkowy należy stworzyć plik tryer_fitcuncompressclass.c w języku C z definicją metody 104

105 Uncompress. Do tego celu zaadaptowano dostępną procedurę dekompresji. Powstałe pliki kompiluje się z opcjami takimi, aby powstała biblioteka dynamiczna: Polecenia dla systemu Windows (kompilator mingw): - kompilacja gcc -c -fpic -D_JNI_IMPLEMENTATION_ -I" C:\Program Files\Java\jdk1.5.0_07\include" -I"C:\Program Files\Java\jdk1.5.0_07\include\win32" tryer_fitcuncompressclass.c - linkowanie gcc -shared -o FitCuncompressClass.dll tryer_fitcuncompressclass.o ucompr.o fitsio.o astutil.o ricecomp.o Polecenia dla systemu Linux (kompilator GCC): - kompilacja gcc -c -fpic -D_JNI_IMPLEMENTATION_ -I"/root/Java/jdk1.5.0_07/include" -I"/root/Java/jdk1.5.0_07/include/linux" tryer_fitcuncompressclass.c - linkowanie gcc -shared -o libfitcuncompressclass.so tryer_fitcuncompressclass.o ucompr.o fitsio.o astutil.o ricecomp.o Znaczenie użytych opcji jest następujące: -c skompiluj pliki źródłowe -o stwórz plik wynikowy o podanej nazwie -I przeszukuj podaną ścieżkę w poszukiwaniu plików źródłowych -fpic generacja kodu tzw. Position Independent Code -D zdefiniuj makro Tak powstałe biblioteki są gotowe do pracy z Javą. Przy implementacji funkcji rodzimych należy pamiętać, aby zwracać specjalną uwagę na poprawność ich implementacji, ponieważ błąd może spowodować zawieszenie wirtualnej maszyny Javy (zazwyczaj JNI nie generuje żadnych wyjątków, gdy wystąpi błąd w programie rodzimym generuje wyjątki tylko po napotkaniu błędu w kodzie Javy). 105

106 W tym przypadku zaadoptowane funkcje były już wielokrotnie sprawdzone. Dla każdego systemu, w którym uruchamiana będzie aplikacja Javy, konieczne jest dostarczenie biblioteki rodzimej dla tego systemu. O ile ekstrakcja procedury dekompresji z kodu źródłowego bibliotek projektu ASAS i kompilacja rodzimej biblioteki dynamicznej dla systemu Linux nie stanowiła problemu, to dla systemu Windows okazała się być pewnym problemem. Kod procedury dekompresji okazał się niekompatybilny z kompilatorem Microsoft Visual C++. Niekompatybilny był nie tylko sposób kodowania i dołączone biblioteki (co można łatwo poprawić), ale także sposób wykonywania poszczególnych funkcji. Konieczne było więc znalezienie alternatywnego kompilatora, a także emulatora Linux pod Windows. Najbardziej znanym jest Cygwin [29], ale dla tego emulatora problemem jest konieczność ładowania biblioteki dynamicznej Cygwin, a JNI może mieć problemy z załadowaniem bibliotek odwołujących się nawzajem do siebie [30]. Kompilatorem zgodnym z GNU/POSIX i nie wymagającym dołączania żadnych dodatkowych bibliotek dynamicznych jest MinGW (Minimalist GNU for Windows) [32]. Kompilator ten umożliwił skompilowanie procedury dekompresji praktycznie bez zmian w stosunku do kodu kompilowanego pod Linuksem. Dokonane zmiany obejmowały: - Dodanie definicji typów u_short jako unsigned short, u_int jako unsigned int, u_char jako unsigned char. - Dodanie flagi O_BINARY do flag przekazywanych funkcją open przy otwieraniu pliku. W Windows istnieją dwa tryby otwierania plików: tekstowy oraz binarny i należy sprecyzować, który tryb ma być używany (w systemie Linux występuje tylko tryb binarny). Używany domyślnie w Windows tryb tekstowy prowadził do błędnego wczytywania binarnych plików skompresowanych obrazów Java Web Start Cała aplikacja, włącznie z bibliotekami rodzimymi, została przygotowana do uruchamiania za pomocą technologii Java Web Start [31]. Technologia ta, jak i 106

107 wszystkie opisane poniżej narzędzia są dostępne standardowo w dystrybucjach Javy. Pozwala ona użytkownikom na pobieranie, instalację i uruchamianie aplikacji Javy. W tekstowym pliku z rozszerzeniem jnlp umieszczonym na serwerze aplikacji znajduje się opis wszelkich bibliotek koniecznych do uruchomienia programu, żądanie wersji maszyny wirtualnej Javy, żądanie poziomu zabezpieczeń, itp. Dokładny opis tego pliku można znaleźć w [31]. Odnośnik umożliwiający pobieranie tego pliku należy umieścić na stronie internetowej. Po pobraniu pliku z rozszerzeniem jnlp przez użytkownika, przeglądarka internetowa uruchamia ten plik za pomocą programu obsługującego Java Web Start. Na podstawie pliku z rozszerzeniem jnlp pobierane są odpowiednie pliki składowe programu: pliki wykonywalne, biblioteki rodzime, itd. Muszą być one umieszczone w archiwum jar. Java Web Start dba o dostarczenie środowiska uruchomieniowego Javy w wersji opisanej w pliku jnlp jeśli na komputerze użytkownika znajduje się wersja niższa niż wymagana, środowisko to jest automatycznie pobierane. Dodatkowo sprawdzana jest także wersja archiwum jar, za pomocą którego dystrybuowany jest program jeśli istnieje wersja nowsza, jest ona automatycznie pobierana. Java Web Start zapewnia, że uruchamiane programy będą wykonywane w sposób bezpieczny dla komputera użytkownika, tzn. m.in.: Aplikacja nie może korzystać z lokalnego dysku twardego Aplikacja nie może korzystać z bibliotek rodzimych W celu przygotowania programu do uruchamiania za pomocą Java Web Start, konieczne było umieszczenie wszystkich plików w archiwum jar. Aby obejść powyższe ograniczenia związane z uruchamianiem programów w bezpieczny sposób, a przede wszystkim zapewnić możliwość ładowania bibliotek rodzimych, konieczne było utworzenie archiwum jar w specjalny sposób podpisanie ich certyfikatem. Użyto certyfikatu uwierzytelnionego przez siebie tzw. fake certificate, ponieważ uzyskanie certyfikatu od odpowiedniej organizacji certyfikującej jest kosztowne. Aby stworzyć archiwum jar z bibliotekami rodzimymi, uwierzytelnione certyfikatem: 107

108 Do wygenerowania certyfikatu użyto narzędzia keytool: keytool -genkey -alias FileSigner -keystore SignApplication.jks -keypass haslo -dname "CN=Pi of the Sky" -storepass haslo Znaczenie użytych opcji jest następujące: -genkey -alias -keystore -keypass -storepass -dname nakazuje generację certyfikatu dostęp do certyfikatu następuje za pomocą podanego aliasu certyfikat jest składowany w podanym pliku hasło chroniące klucz prywatny certyfikatu hasło chroniące plik certyfikatu nazwa posiadacza certyfikatu Do stworzenia archiwum jar użyto narzędzia jar: jar cf "C:\bibl_natywne.jar" FitCuncompressClass.dll libfitcuncompressclass.so Znaczenie użytych opcji jest następujące: c utwórz archiwum f po tej opcji należy podać nazwę archiwum Pozostałe pozycje to nazwy plików, które będą dodane do archiwum. Podpisano archiwum wcześniej utworzonym certyfikatem: jarsigner -keystore SignApplication.jks -storepass haslo -keypass haslo "C:\bibl_natywne.jar" FileSigner Znaczenie użytych opcji zostało opisane powyżej. Ostatnim krokiem jest zmiana typu mime dla pliku jnlp, który jest sygnalizowany przez serwer aplikacji przy pobieraniu pliku, dzięki czemu przeglądarka internetowa na komputerze użytkownika może rozpoznać, jaki typ zawartości jest właśnie transferowany i podjąć odpowiednie działania (w tym wypadku uruchomienie Java Web Start). 108

109 7.5. Obsługa programu Obsługa programu jest bardzo prosta i składa się z następujących kroków: Uruchomienie programu ze strony internetowej za pomocą Java Web Start Po uruchomieniu programu, wybór panela z żądanymi funkcjami (np. przeglądarka obrazów) Wybór funkcji z menu panela (w przypadku przeglądarki obrazów: wybór pliku do przeglądania i zmiana parametrów wyświetlania obrazu) Testowanie i debugowanie programu Program przetestowano pod różnymi dystrybucjami systemu Linux i pod Windows XP. Znaleziono przy tym pewne usterki samego środowiska uruchomieniowego Javy, jak opisywana wcześniej usterka związana z powiększaniem obrazu, w którym model kolorów to IndexColormodel. Usterki te nie wpływają znacząco na funkcjonalność programu. Także sam proces uruchamiania aplikacji przez Java Web Start może się czasami nie udać (np. nieudana weryfikacja podpisów archiwum jar) i jest to także znana usterka środowiska Javy. Użytkownik musi wtedy spróbować uruchomić program ponownie. Wszystkie inne funkcje programu związane z dekompresją i wyświetlaniem obrazów działały prawidłowo Podsumowanie Opracowany program jest programem o średnim stopniu komplikacji, ale dzięki umiejętnemu użyciu dostępnych technologii i standardowych komponentów środowiska Java wykonuje on dość skomplikowane zadania. Udowodniono przydatność Javy przy implementowaniu interfejsów graficznych dla programów napisanych w języku C / C++. Stanowi to nową perspektywę dla projektu Pi of the Sky, co może skutkować opracowaniem nowego interfejsu graficznego do bezpośredniej obsługi kamer, zamiast interfejsu tekstowego. 109

110 8. Testy systemu Testy poszczególnych modułów oprogramowania wykonanych w niniejszej pracy zostały umieszczone w rozdziałach opisujących te moduły. Jednakże najbardziej miarodajnym testem jest test całego systemu, w warunkach, do których system został zaprojektowany. Testy takie zostały przeprowadzone wpierw w Brwinowie pod Warszawą (rys. 30), a następnie w docelowej lokalizacji eksperymentu, w Las Campanas w Chile (rys. 31). Rys. 30. Stanowisko testowe systemu w Brwinowie pod Warszawą. 110

111 Rys. 31. Stanowisko w Las Campanas Observatory, Chile, , Las Campanas. Od lewej do prawej: kontener ASAS z aparaturą Pi of the Sky, kopuła teleskopu ASAS 10, pomieszczenie sterujące. Podczas całego okresu działania prototypu każda z dwóch kamer wykonała około 1 miliona zdjęć. Wykonano wiele interesujących obserwacji, a niektóre uzyskane wyniki opublikowano Obserwacje błysków W czasie działania eksperymentu od do satelity zarejestrowały 89 błysków gamma. Poniższe zestawienie przedstawia obserwacje optyczne wykonane w projekcie Pi of the Sky, odpowiadające błyskom zarejestrowanym przez satelity. Ilość GRB Obserwacja w projekcie zarejestrowanych przez satelity Pi of the Sky 1 aparatura wyłączona 4 chmury 40 w ciągu dnia 18 nieosiągalny (półkula północna) 8 nieosiągalny (poniżej horyzontu) 16 poza polem widzenia 2 w polu widzenia 89 razem Tabela nr 6. Statystyka obserwacji w projekcie Pi of the Sky w reakcji na trygery GRB. 111

112 Jak można zauważyć, błysków w polu widzenia jest 2, a poza polem widzenia jest 16. Prawdopodobnie większość tych błysków byłaby zarejestrowana, gdyby obserwację prowadziły 2 zespoły po 16 kamer tak jak będzie to w systemie docelowym. Obecnie, w przypadku błysku poza polem widzenia, kamery przesuwają się w żądane położenie po otrzymaniu trygera z sieci GCN. Nie zaobserwowano żadnej poświaty optycznej błysku GRB, ale wyznaczono limity dla jasności błysku. Limity przed, w czasie i po błysku opublikowano w publikacjach sieci GCN [34], co przedstawia następująca tabela. Błysk GRB, w kolejności chronologicznej Przed błyskiem W czasie błysku (t 0 ) Po błysku Publikacja GCN GRB040825A >10m dla t<t 0 t-11s >12m >9,5m dla t>t 0 +7s GCN 2677 GRB040916B >13,0m dla t>t 0 +17min GCN 2725 GRB >11,5m dla t>t 0 +30min GCN 2862 GRB >12m dla t<t 0-108min GCN 2970 GRB >11m dla t<t 0-33min GCN 3146 GRB >11,5m >11m >11,5m GCN 3240 GRB >12,5m dla t>t 0 +60s GCN 3526 Tabela nr 7. Najważniejsze obserwacje GRB w projekcie Pi of the Sky. Pogrubioną czcionką oznaczono w tabeli nr 7 dwa obiekty, które znalazły się w polu widzenia, w czasie ich wystąpienia. Jest to pierwsza tego typu obserwacja. Oprócz obserwacji błysków GRB po trygerze z satelitów, system zarejestrował błyski po wykryciu ich przez własny system detekcji błysków. Wykryto ok. 100 błysków na pojedynczych klatkach o ekspozycji 10 sekund. Nie można wykluczyć, że są to refleksy światła słonecznego od satelitów. Zaobserwowano 6 błysków na 2 klatkach. Ich pochodzenie pozostaje nieznane. Jeden z takich błysków przedstawia rys. 32. Rys. 32. Błysk zaobserwowany w czasie testów aparatury Pi of the Sky :27 UT w miejscu galaktyki LEDA

113 Wykryto 1 błysk na 11 klatkach, który okazał się być rozbłyskiem gwiazdy rozbłyskowej CN Leo. Wykres jasności błysku przedstawia rys. 33. Rys. 33. Wykres jasności gwiazdy rozbłyskowej CN Leo. Potencjał naukowy projektu Pi of the Sky jest jednak większy od wyłącznie obserwacji błysków Obserwacje gwiazd zmiennych Podczas analizy offline wykonywanej w ciągu dnia dokonywane są pomiary jasności gwiazd. Pomiary te są katalogowane. Wykonano pomiary ok gwiazd, po ok pomiarów dla każdej gwiazdy. Przykładowe wykresy jasności dla gwiazd zmiennych przedstawia rys

114 Rys. 34. Przykładowe krzywe jasności (oś pionowa) gwiazd w zależności od czasu (oś pozioma). 114

115 8.3. Obserwacje meteorów Chociaż meteory same w sobie nie stanowią celu badań projektu Pi of the Sky, ich systematyczna rejestracja, a następnie analiza rozkładu na niebie może prowadzić do odkrycia rojów meteorów o niewielkiej gęstości. Spektakularny przykład ewolucji śladu meteoru w atmosferze przedstawia rys. 35. Rys. 35. Ewolucja śladu meteoru w atmosferze. Ekspozycje 10-sekundowe z przerwami po 2 sekundy (czas martwy wymagany do odczytu czujnika CCD) Podsumowanie Testy pokazały, że system jest zdolny do akwizycji wartościowych danych. Niezawodność systemu ilustruje fakt, że w okresie od końca czerwca 2004 do końca czerwca 2005 roku stracono mniej nocy z powodów problemów technicznych z aparaturą (utracono możliwość obserwacji 1 błysku), niż z powodu złej pogody i zachmurzonego nieba (utracono możliwość obserwacji 4 błysków). 115