Zdokonalenı rıdıcıho softwaru pro dalekohled BART

Transkript

Univerzita Karlova v Praze
Matematicko-fyzikálnı́ fakulta
DIPLOMOVÁ PRÁCE
Petr Kubánek
Zdokonalenı́ řı́dı́cı́ho softwaru pro dalekohled BART
Katedra softwarového inženýrstvı́
Vedoucı́ diplomové práce: Mgr. Daniel Štourač
Studijnı́ program: informatika
Softwarové inženýrstvı́
Za cenné rady, připomı́nky a trpělivost bych chtěl poděkovat panu magistru
Danielovi Štouračovi.
Za konzultace týkajı́cı́ se zpracovánı́ snı́mků a plánovánı́ pozorovánı́ a za
programy pro astrometrii, patřı́ dı́k panu magistru Martinovi Jelı́nkovi.
Čas pro testovánı́ a pozorovánı́ se systémem BART si našli pan magistr Martin
Topinka, inženýr Martin Nekola, magistr Jan Torman a Ondřej Mikulášı́k. Patřı́
jim za to mé poděkovánı́.
Za knihovnu libnova bych chtěl poděkovat jejı́m autorům, zvláště pak panu
Liamovi Girdwoodovi.
Za programovánı́ a správu systému pro distribuci informacı́ o zdrojı́ch gama
zářenı́ patřı́ dı́k Scottu Barthelmy z Goddardova střediska NASA.
Grantové agentuře AV ČR a Evropské kosmické agentuře pak patřı́ dı́k za
granty, kterými je BART financován.
Prohlašuji, že jsem svou diplomovou práci napsal samostatně a výhradně s
použitı́m citovaných pramenů. Souhlası́m se zapůjčovánı́m práce.
V Praze dne 2. srpna 2003
Petr Kubánek
Obsah
1
2
3
Úvod
1.1 Použı́vánı́ astronomických výrazů . .
1.2 Gama záblesky . . . . . . . . . . . .
1.3 Pozorovánı́ GRB malými dalekohledy
1.4 Princip detekce gama záblesků . . . .
1.5 Náhradnı́ program . . . . . . . . . . .
1.6 RTS1 . . . . . . . . . . . . . . . . .
1.7 RTS2 . . . . . . . . . . . . . . . . .
1.8 BART . . . . . . . . . . . . . . . . .
Specifikace
2.1 Popis dalekohledu . . . . . . . . .
2.1.1 Popis CCD kamery . . . .
2.1.2 Popis montáže . . . . . .
2.1.3 Střecha dalekohledu . . .
2.2 Zpracovánı́ snı́mků . . . . . . . .
2.3 Organizace pozorovánı́ . . . . . .
2.4 Korekce montáže . . . . . . . . .
2.5 Přı́jem zpráv o gama záblescı́ch .
2.6 Náročnost na počı́tačové vybavenı́
Návrh
3.1 Agenty . . . . . . . . . . . . . . .
3.2 Centrálnı́ server . . . . . . . . . .
3.2.1 Přı́klad . . . . . . . . . .
3.3 Priority . . . . . . . . . . . . . .
3.3.1 Možnosti předávánı́ priorit
3.3.2 Závěr . . . . . . . . . . .
3.3.3 Přı́klady . . . . . . . . . .
3.4 Zmenšenı́ chyb montáže . . . . .
3.5 Stavy zařı́zenı́ . . . . . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
4
4
4
4
.
.
.
.
.
.
.
.
.
5
5
5
6
6
7
7
7
7
8
.
.
.
.
.
.
.
.
.
9
9
10
10
11
12
16
17
18
19
3.6
3.7
3.8
4
Centrálnı́ server . . . . . . . . . . . . . . . . .
Zařı́zenı́ . . . . . . . . . . . . . . . . . . . . .
3.7.1 Kamery . . . . . . . . . . . . . . . . .
3.7.2 Montáž . . . . . . . . . . . . . . . . .
3.7.3 Kopule, střecha, meteorologická stanice
Klienti . . . . . . . . . . . . . . . . . . . . . .
3.8.1 Organizace pozorovánı́ . . . . . . . . .
3.8.2 Databáze . . . . . . . . . . . . . . . .
3.8.3 Pořizovánı́ snı́mků . . . . . . . . . . .
3.8.4 Ukládánı́ snı́mků . . . . . . . . . . . .
3.8.5 Monitoring . . . . . . . . . . . . . . .
3.8.6 Dlouhodobá pozorovánı́ . . . . . . . .
3.8.7 Klient pro pozorovánı́ GRB . . . . . .
Implementace
4.1 Cı́lová platforma . . . . . . . . . . . . . .
4.2 Cı́lový jazyk . . . . . . . . . . . . . . . . .
4.3 Protokol . . . . . . . . . . . . . . . . . . .
4.3.1 Formát . . . . . . . . . . . . . . .
4.3.2 Přı́kazy . . . . . . . . . . . . . . .
4.3.3 Odpovědi . . . . . . . . . . . . . .
4.3.4 Zprávy a žádosti serveru . . . . . .
4.3.5 Přenos snı́mků . . . . . . . . . . .
4.4 Přı́kazy protokolu . . . . . . . . . . . . . .
4.4.1 Konvence . . . . . . . . . . . . . .
4.4.2 Obecné návratové hodnoty . . . . .
4.4.3 Centrálnı́ server . . . . . . . . . . .
4.4.4 Zařı́zenı́ - obecná komunikace . . .
4.4.5 Kamera . . . . . . . . . . . . . . .
4.4.6 Montáž . . . . . . . . . . . . . . .
4.5 Přı́klad komunikace . . . . . . . . . . . . .
4.6 Komunikačnı́ knihovna . . . . . . . . . . .
4.6.1 Architektura komunikačnı́ knihovny
4.6.2 devser . . . . . . . . . . . . . . . .
4.6.3 devcli . . . . . . . . . . . . . . . .
4.6.4 devdem . . . . . . . . . . . . . . .
4.6.5 Architektura serveru . . . . . . . .
4.7 Zpracovánı́ snı́mku . . . . . . . . . . . . .
4.8 Rozhrannı́ zařı́zenı́ . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
21
21
23
25
27
27
27
28
29
29
29
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
31
31
32
32
32
33
33
33
33
34
34
35
36
37
37
40
40
40
40
40
40
41
41
5
6
7
Uživatelský manuál
5.1 Kompilace . . . . . . .
5.2 Spouštěnı́, zastavovánı́
5.3 Monitoring . . . . . .
5.4 Přı́stup k databázi . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Jiné systémy, srovnánı́
6.1 Změny oproti RTS1 . . . . . . . . . . .
6.2 RTS 1 . . . . . . . . . . . . . . . . . .
6.3 Ondřejov - ovládánı́ 60cm dalekohledu .
6.4 BOOTES - Španělsko . . . . . . . . . .
6.5 Nightview - Monte Boo, Brno . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
44
44
.
.
.
.
.
49
49
49
51
52
54
Závěr
55
A Zadánı́ projektu
57
B Rozhrannı́ zařı́zenı́
B.1 Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Montáž . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Střecha a meteorologická stanice . . . . . . . . . . . . . . . . . .
59
59
59
60
C Použité prostředky, převzatý kód
C.1 Vývojové prostředky . . . . . . . . . . . . . . . .
C.2 Použité knihovny . . . . . . . . . . . . . . . . . .
C.3 Převzatý a použitý kód, integrovaný přı́mo do RTS2
C.4 Vlastnı́ kód . . . . . . . . . . . . . . . . . . . . .
61
61
61
62
62
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D Časový plán
63
E Databáze
65
F Konfiguračnı́ soubor
69
Název práce: Zdokonalenı́ řı́dı́cı́ho softwaru pro dalekohled BART
Autor: Petr Kubánek
Katedra: Katedra softwarového inženýrstvı́
Vedoucı́ diplomové práce: Mgr. Daniel Štourač
e-mail vedoucı́ho: [email protected]
Abstrakt: BART je malý dálkově ovládaný dalekohled, vybavený optickými CCD
kamerami, umı́stněný v Astronomickém ústavu Akademie věd v Ondřejově. Jeho
cı́lem je pořizovánı́ optických snı́mků oblastı́, v kterých byly detekovány gama
záblesky. Tato práce popisuje jeho nový ovládacı́ systém.
Nový systém je navržen jako sı́t’spolupracujı́cı́ch programů. Tvořı́ ho servery
zařı́zenı́, centrálnı́ server a klienti pro jednotlivé druhy pozorovánı́. Pro jejich
vzájemnou komunikaci je navržen a implementován vlastnı́ komunikačnı́ protokol.
Informace o cı́lech a výsledcı́ch pozorovánı́ jsou udržovány v databázi. Pozice
gama záblesků jsou přijı́many prostřednictvı́m Internetu, vloženy mezi cı́le pozorovánı́ a pokud to podmı́nky dovolı́, po určitou dobu pozorovány. V čase, kdy
nenı́ dalekohled využı́ván pro pozorovánı́ oblastı́ gama záblesků, jsou pozorovány
náhradnı́ cı́le.
V závěru práce je uvedeno srovnánı́ ovládacı́ho systému dalekohledu BART s
několika dalšı́mi systémy pro ovládánı́ dalekohledu.
Klı́čová slova: robotický dalekohled, ovládánı́, optické protějšky gama záblesků
Title: Improvement of the controlling software for BART telescope
Author: Petr Kubánek
Department: Department of Software Engeneering
Supervisor: Mgr. Daniel Štourač
Supervisor’s e-mail address: [email protected]
Abstract: BART is a small remote controlled telescope, equiped with optical CCD
cameras. It’s located in Astronomical Institute of the Czech Academy of Sciences
in Ondřejov. Its scientific target is rapid observation of gama ray burst (GRB)
optical transients. This thesis describes its new control system.
New system is designed as a net of cooperating programs. It’s composed of
device servers, central server and clients for different types of observations. For
their communication is designed and implemented private protocol. Observations
entries requests and results are kept in database. Position of GRBs are received
from the Internet, added to list of possible observations entries, and, if weather
and other conditions permits observation, observed. In idle time, when there is not
any request for GRB observations, secondary targets are observed.
At the end of thesis is comparsion of BART control system with a few other
systems for telescope control.
Keywords: robotic telescope, control, optical transients of gamma ray bursts
Zadánı́ diplomové práce
Navrhněte, implementujte a zdokumentujte ovládánı́ dalekohledu BART (Burst
Afterglow Robotic Telescope) tak, aby umožňovalo:
• řı́zenı́ dalekohledu pomocı́ předem spočı́taného plánu, s možnostı́ jeho přerušenı́ a předánı́ řı́zenı́ jinému pozorovánı́ v přı́padě přı́jmu zprávy o novém
objektu, vhodného k okamžitému pozorovánı́
• snadný přenos řešenı́ na jiné kamery, přı́padně dalekohledy
• on-line zpracovánı́ snı́mků na jiném počı́tači než na počı́tači obsluhujı́cı́m
kameru
Na závěr porovnejte nové ovládánı́ dalekohledu s existujı́cı́mi systémy pro
ovládánı́ dalekohledů.
Je možné využı́t ovladače zařı́zenı́, napsané jako část ročnı́kového projektu
obhájeného v červnu 2000. Ostanı́ kód ročnı́kového projektu nesmı́ být použit.
Dokumentace k práci musı́ obsahovat výčet kódu, převzatého z ročnı́kového projektu.
Pro úspěšné vyřešenı́ je potřeba provést následujı́cı́ práce
• definovat rozhrannı́ pro ovládánı́ zařı́zenı́ a přenos dat z nich, provést jeho
vzorovou implementaci na zařı́zenı́ch, jež jsou k dispozici na dalekohledu
BART.
• vymyslet a naimplementovat plánovač, který bude řı́dit pozorovánı́.
• zabývat se ukládánı́m napozorovaných dat, jejich třı́děnı́m a zajištěnı́m jednoduchého přı́stupu k nim.
• naimplementovat k částem, jež to vyžadujı́, grafické uživatelské rozhrannı́.
Konzultanté
za ASU AV ČR:
Martin Jelı́nek ([email protected])
Renné Hudec ([email protected])
Lenka Šarounová ([email protected])
Jan Soldán ([email protected])
Literatura
Martinez/Klotz - A practical Guide to CCD astronomy
Trueblood/Genet - Telescope control, Willmann-Bell, 1997
Mgr. R.Halı́ř, T.Jı́lek, P.Kubánek, F.Krolluper, F.Kvapil - Detekce astronomických
objektů s proměnnou intenzitou za pomoci robotického teleskopu, Ročnı́kový
projekt MFF UK, Praha, 2000
David Ratledge, The Art and Science of CCD Astronomy
Odkazy
http://www.telescope.org/rti/automated.html přehled automatizovaných dalekohledů
http://lascaux.asu.cas.cz dalekohled BART
http://nova.sourceforge.net/ Projekt NOVA, automatické ovládánı́ dalekohledu
http://www.astro.princeton.edu/˜bakos/HAT The Hungarian Automated Telescope
Kvantitativnı́ požadavky
Po zadánı́ a seznámenı́ se s problémem je rozumné definovat měřitelné veličiny,
kterých by mělo být dosaženo.
- systém musı́ reagovat na GRB zahájenı́m GRB pozorovánı́ do 1 sekundy
- čas, kdy neběžı́ žádné pozorovánı́, nesmı́ přesáhnout 10% celkového pozorovacı́ho času
Kapitola 1
Úvod
Hlavnı́ motivacı́ vzniku této práce bylo napsánı́ vylepšeného ovládacı́ho systému
pro dalekohled BART.
V úvodnı́ kapitole jsou popsány a vysvětleny některé výrazy, použı́vané v
dalšı́m textu.
V druhé kapitole jsou popsány vlasnosti přı́strojů, které má systém ovládat.
Třetı́ kapitola popisuje návrh nového systému. V jejı́ prvnı́ části je navržen
algoritmus pro řešenı́ dvou problémů - předávánı́ priorit a průběžné korekce montáže. Jejı́ druhá část obsahuje popis jednotlivých částı́ nového systému.
Čtvrtá kapitola obsahuje popis implementace, vysvětluje principy uplatněné v
komunikačnı́m protokolu.
Pátá kapitola obsahuje uživatelský manuál.
V šesté kapitole je uvedeno srovnánı́ s nahrazeným systémem řı́zenı́ pozorovánı́. Dále je zde uveden popis několika dalšı́ch programů pro ovládánı́ astronomických programů.
Přı́lohy obsahujı́ zadánı́ půbodnı́ho systému pro řı́zenı́ dalekohledu, popis důležitých hlavičkových souborů, popis použitých programů, časový plán implementace a podrobný popis tabulek obsažených v databázi.
1.1
Použı́vánı́ astronomických výrazů
Pro úspěšné přečtenı́ a pochopenı́ této práce je dobré mı́t základnı́ znalosti astronomických výrazů a v astronomii použı́vaných pozičnı́ch systémů. Výklad těchto
pojmů nenı́ předmětem této práce. Jsou popsány napřı́klad v [RTS1–2000] nebo v
[Pokorný–1995].
1
2
KAPITOLA 1. ÚVOD
1.2
Gama záblesky
Gama zářenı́ je nejenergičtějšı́ elektromagnetické zářenı́. Gama Ray Burst, zkráceně GRB, česky gama záblesky jsou prudké a krátké výtrysky tohoto zářenı́,
přicházejı́cı́ k nám z vesmı́ru. Záblesky trvajı́ od několika milisekund po několik
tisı́c sekund. Gama zářenı́ nepronikne zemskou atmosférou - gama záblesky tedy
musı́me hledat pomocı́ přı́strojů na družicı́ch.
Staršı́ družice (napřı́klad družice COMPTON GRO) poskytovaly polohu zdroje
gama záblesku pouze přibližně, s chybou velikosti několika stupňů, nové (HETE,
INTEGRAL, Swift) umı́ najı́t polohu zdroje gama záblesku poměrně přesně chyba určenı́ polohy dosahuje maximálně několika desı́tek úhlových minut.
Optickým protějškem gama záblesku se rozumı́ podezřelý objekt ve směru
gama záblesku pozorovaný ve viditelném spektru. Optický protějšek je podle
současné pozorovacı́ statistiky pozorován u zhruba poloviny gama záblesků. Je
pozorovatelný déle než gama záblesk - po dobu několika dnů až několika měsı́ců.
dny. V průměru je detekován jeden gama záblesk denně. Z různých důvodů (počası́, umı́stěnı́ na neviditelné části oblohy, malá jasnost, ..) u většiny z nich nenı́
možno dohledat jejich optické protějšky. Optický dosvit známe u několika desı́tek
GRB. To je množstvı́ nedostačujı́cı́ pro vytvořenı́ důvěryhodné statistiky, která
by definitivně potvrdila či vyvrátila veškeré teoretické modely objasňujı́cı́ původ
gama záblesků.
Nenı́ jasné, jaké jevy produkujı́ záblesky kratšı́ než 2 sekundy. Některé z
teoretických modelů předpokládajı́ katastrofické srážky, následované výbuchem.
Při srážce vzniká gama zářenı́, při výbuchu z nárazů rozpı́najı́cı́ se obálky pak
pocházı́ optické zářenı́. Optický protějšek by měl být pozorovatelný o trochu
později než gama záblesk. Z extrapolace naměřených optických protějšků gama
záblesků vyplývá, že by mohl mı́t po krátkou dobu dostatečnou jasnost, aby byl
viditelný i triedrem či malým dalekohledem.
Jasnějšı́ je situace u GRB delšı́ch než 2 sekundy - jsou zřejmě projevy zániku
hmotných hvězd - kolapsarů.
1.3
Pozorovánı́ GRB malými dalekohledy
Proč má smysl pozorovat oblasti, ve kterých byly detekovány gama záblesky,
malými dalekohledy, které jsou podobné tomu ondřejovskému? Důvody jsou následujcı́:
• velké dalekohledy pozorujı́ podle předem daného plánu, nemajı́ moc volnosti
pro přı́padné přerušenı́ pozorovánı́
1.4. PRINCIP DETEKCE GAMA ZÁBLESKŮ
3
• malé dalekohledy jsou levné, lze jich tedy postavit vı́ce a pozorovat z vı́ce
mı́st. Pozorovánı́m z vı́ce mı́st se zvýšı́ pravděpodobnost úspěšného pozorovánı́
Pro úspěšné pozorovánı́ je třeba splnit následujı́cı́ podmı́nky:
• na pozorovacı́m stanovišti musı́ být jasno a noc, objekt musı́ být ihned nad
obzorem
• pole, které se pozoruje, nesmı́ být v blı́zkosti Měsı́ce; tato podmı́nka se stává
kritickou pro pozorovánı́ v čase kolem úplňku.
• dalekohled musı́ být správně ustaven
• celý systém musı́ správně přijmout údaje o poloze GRB z pozemnı́ho střediska, zpracovávajı́cı́ho údaje z družic, správně reagovat a pozorovánı́ provést
Každý dalekohled navı́c, který je v provozu, tak má svůj význam. Zvětšuje
pravděpodobnost rychlého zachycenı́ objektu na souřadnicı́ch gama záblesku.
1.4
Princip detekce gama záblesků
Gama zářenı́ procházı́ poměrně snadno hmotou. Optika pro jeho obor neexistuje.
Nelze tedy použı́t konstrukce použı́vané pro optické nebo rádiové detektory.
Gama teleskopy či přı́padně detektory pracujı́ na dvou principech:
• pro vytvořenı́ obrazu použı́vajı́ masku
• ze znalosti času nesměrové detekce na dvou a vı́ce pozicı́ch dopočı́távajı́
poluhu zdroje
COMPTON GRO a družice IPN1 byly vybaveny nesměrovými nebo částečně
směrovými detektory, nové družice - HETE, Integral a Swift jsou vybaveny detektorem s maskou.
1
InterPlanetary Network, družice NASA a dalšı́ch agentur umı́stněné v různých mı́stech slunečnı́ soustavy
4
KAPITOLA 1. ÚVOD
1.5
Náhradnı́ program
Protože nelze očekávat detekci gama záblesku každou noc, je vhodné pro dalekohled navrhnout náhradnı́ program. Nejvhodnějšı́ je monitoring několika vybraných
zdrojů, s počı́tánı́m jejich přesné fotometrie 2 .
Fotometrie se dělı́ na asboslutnı́ a relativnı́. Relativnı́ spočı́vá v porovnávánı́ jasnosti jedné hvězdy oproti několika referenčnı́m hvězdám na sérii snı́mků,
pořı́zených stejným přı́strojem při pokud možno stejných atmosférických prodmı́nkách. Absolutnı́ fotometrie spočı́vá v měřenı́ jasnosti všech hvězd na snı́mků,
vypočtenı́m jejich přı́strojové magnitudy, ze znalosti jasnosti kalibračnı́ch hvězd
dopočtenı́m jejich absolutnı́ magnitudy.
Absolutnı́ fotometrie je náročnějšı́ než relativnı́ fotometrie. Systém je navržen tak, aby umožňoval pořizovánı́ snı́mků jak pro absolutnı́, tak pro relativnı́
fotometrii.
1.6
RTS1
Jako RTS1 je označován starý systém řı́zenı́ dalekohledu, vyvinutý v rámci ročnı́kového projektu studentů MFF UK. Zkratka RTS znamená Remote Telescope
System.
1.7
RTS2
Tı́mto názvem je označována nová verze RTS, naprogramovaná autorem této
diplomové práce.
1.8
BART
Zkratka BART znamená Burst Alert Robotic Telescope. Touto zkratkou je označován ondřejovský dalekohled.
2
měřenı́ jasnosti hvězd
Kapitola 2
Specifikace
2.1
Popis dalekohledu
Dalekohled se skládá z montáže, optiky a detekčnı́ch přı́strojů. Nad dalekohledem
je umı́stěna střecha.
Úkolem montáže je pohybovat optickou částı́ dalekohledu. Montáž může být
vybavena čidly, která umožňujı́ zı́skat informaci o orientaci montáže v prostoru.
Montáž je většinou vybavena detekčnı́mi přı́stroji. Detekčnı́ přı́stroje se skládajı́ z detektoru a optické části.
Nejdostupnějšı́m detektorem je lidské oko. Pro pozorovánı́ nočnı́ oblohy jsou
vhodnějšı́ CCD kamery - nevyžadujı́ přı́tomnost pozorovatele u dalekohledu, majı́
vysokou citlivost a zı́skaná data je možné archivovat a dodatečně zpracovat.
2.1.1
Popis CCD kamery
CCD prvek si můžeme představit jako matici fotoodporů. Při dopadu fotonu na
CCD prvek se jeho energie přeměnı́ na elektrický náboj. Ten je poté změřen a A/D
převodnı́kem převeden na digitálnı́ signál. Vyčı́tánı́ CCD je pojem, označujı́cı́
digitalizaci jednotlivých řádků a jejich přenos.
Astronomické CCD kamery jsou většinou černobı́lé, barevné snı́mky lze zı́skat
kombinacı́ snı́mků pořı́zených s použitı́m různých filtrů.
CCD čipy použı́vané v astronomii se podstatně nelišı́ od běžných CCD čipů,
použı́vaných v digitálnı́ch fotoaparátech. CCD kamery jsou většinou připojovány
k počı́tači. Připojenı́ je realizováno bud’to přes standartnı́ porty, jakými je napřı́klad paralerlnı́, sériový, či v poslednı́ době USB port, nebo přes speciálnı́ kartu
připojenou ke sběrnici počı́tače.
Při vyčı́tánı́ kamery je potřeba přenést data v řádu megabajtů. Vyčı́tánı́ a
5
6
KAPITOLA 2. SPECIFIKACE
následnou digitalizaci je potřeba provést v co nejkratšı́m časovém okamžiku1 .
Kamery většinou nejsou vybaveny bufferem, data v nich obsažená jsou tedy rovnou
po digitalizaci posı́lány počı́tači, který je musı́ přijmout. CPU vyčı́tacı́ho počı́tače je
značně vytı́ženo cykly čekajı́cı́mi na data, nemůže tedy přidělit ostatnı́m procesům
přı́liš mnoho času.
2.1.2
Popis montáže
Montáže, které nejsou vybaveny motory pro změnu své orientace, nelze automatizovat.
Montáže s motory je potřeba nejdřı́ve propojit s počı́tačem. Vzhledem k malému objemu přenášených dat se většina montážı́ připojuje přes sériový port počı́tače.
Při zadávánı́ souřadnic je rozumné zadávat absolutnı́ souřadnice daného objektu, tedy rektascenzi a deklinaci. Pro výpočet polohy, na kterou se má nastavit,
pak montáž potřebuje znát mı́stnı́ hvězdný čas. Ten je možné vypočı́tat ze světového času a zeměpisné délky.
Při zjišt’ovánı́ polohy montáže je možné použı́t bud’to relativnı́, nebo absolutnı́
čı́tače. Relativnı́ čı́tače jsou jednodušı́ a levnějšı́, absolutnı́ složitějšı́ a dražšı́.
Relativnı́ čidla počı́tajı́ změnu polohy. Změnu polohy je možné počı́tat bud’to
přı́mo z doby chodu, přı́padně počtu cyklů ovládacı́ch motorů, nebo přesněji
pomocı́ zpětnovazebnı́ch čidel, umı́stěných na osách montáže. Zpětnovazebnı́ čidla
detekujı́ změnu pozice opticky nebo elektromechanicky.
Relativnı́ čidla je potřeba před začátkem pozorovánı́ nastavit. Některé systémy
motorů s čidly jsou po zapnutı́ schopny najı́t pevnou pozici, označovanou většinou jako home pozici, u které vědı́, jaké má souřadnice. Tyto pak nenı́ potřeba
nastavovat.
Absolutnı́ čidla jsou většinou řešena elektromechanicky, napřı́klad jako velmi
jemný potenciometr.
Dostupné motory, absolutnı́ i relativnı́ čidla, jejich přesnost a cena je velmi
dobře popsána v [Trueblood, Genet–1997] na stránkách 159 až 222.
2.1.3
Střecha dalekohledu
Nad dalekohledem se nacházı́ střecha či kopule. Jejı́m úkolem je chránit dalekohled
v přı́padě nepřı́znivého počası́.
Pokud se jedná o kopuli, je potřeba natáčet jejı́ štěrbinu2 do směru, který
sleduje dalekohled.
1
Při delšı́m vyčı́tánı́ jsou poslednı́ vyčtené řádky světlejšı́ než prvnı́. Toto zesvětlánı́ je způsobeno tepelným šumem
2
otvor, kterým je vidět ven
2.2. ZPRACOVÁNÍ SNÍMKŮ
7
Střecha či kopule jsou většinou řı́zeny vlastnı́ logikou, která dokáže s počı́tačem
komunikovat přes sériový port.
2.2
Zpracovánı́ snı́mků
Pořı́zené snı́mky je potřeba uložit a zpracovat.
Od pořı́zeného snı́mku je odečten temný snı́mek. Vzniklý snı́mek je pak vydělen hodnotami flat fieldu 3 . Toto zpracovánı́ je popsáno v [Martinez, Klotz–1996]
a [Ratledge, David–1998].
Dále je potřeba zjistit přesnou polohu snı́mku a zaznamenat ji ve formě WCS4
hlavičky.
2.3
Organizace pozorovánı́
V systému je udržován seznam možných cı́lů pozorovánı́. U každého cı́le je
evidováno, kolikrát byl pozorován a s jakým výsledkem.
U každého snı́mku je evidováno, jestli se jedná o obyčejný nebo korekčnı́
snı́mek a okolnosti jeho vzniku.
Obyčejné snı́mky jsou spojeny s konkrétnı́m cı́lem pozorovánı́. Korekčnı́
snı́mky nejsou vázány na cı́le pozorovánı́.
2.4
Korekce montáže
Montáž dalekohledu z různých důvodů a přı́čin nemusı́ najet přesně na mı́sto,
které jı́ bylo zadáno. U dalekohledů s pozorovateli je pozorované pole obsluhou
srovnáváno s katalogy a přı́padná chyba opravena.
U automatických dalekohledů se musı́me bez inteligentnı́ho pozorovatele obejı́t. Kontrolu správnosti najetı́ montáže lze provést pouze z pořı́zených dat.
2.5
Přı́jem zpráv o gama záblescı́ch
Jak již bylo uvedeno, gama záblesky jsou detekovány družicemi. Z nich jsou
informace s jistým časovým zpožděnı́m, závislém na pozici družice, přijmuty
3
český ekvivalent k tomuto názvu zřejmě neexistuje; jedná se o nesaturovaný světlý snı́mek,
který se použı́vá pro korekci nelinearit jednotlivých pixelů
4
World Coordinate System, definuje způsob zaznamenánı́ polohu referenčnı́ho bodu snı́mku,
jeho rektascenze a deklinace, úhlových rozměrů pixelu, rotace snı́mku a členů korekčnı́ho polynomu
8
KAPITOLA 2. SPECIFIKACE
pozemnı́ sledovacı́ stanicı́.
Většina detekcı́ je pak předávána do GSCF, NASA 5 .
Z tohoto mı́sta jsou převzaté, přı́padně dopočı́tané polohy záblesků celosvětově
distribuovány. Pro předávánı́ poloh se použı́vali vždy prostředky, dostupné v dané
době - v sedmdesátých letech minulého stoletı́ to byl dálnopis a pošta, v letech
osmdesátých k nim přibylo modemové spojenı́, které bylo v poslednı́ dekádě
minulého stoletı́ vytlačeno přenosem zpráv přes Internet.
Zprávy je možné pomocı́ Internetu přijı́mat dvěmi protokoly - jednak pomocı́
privátnı́ho protokolu implementovaného nad TCP/IP protokolem, jednak pomocı́
e-mailu. Předávánı́ zpráv přes TCP/IP protokol je rychlejšı́, ale zaručuje doručenı́
zprávy o gama záblesku pouze v přı́padě, že spojenı́ funguje. Přı́jem zpráv pomocı́
e-mailu je kvůli nutnosti posı́lat e-mail přes několik mailserverů pomalejšı́. Na
druhou stranu garantuje doručenı́ zprávy o gama záblesku i v přı́padě, že přijı́macı́
stanice nenı́ trvale připojena do Internetu.
Od konce roku 2002 je v činosti druhý systém pro zası́lánı́ zpráv o GRB.
Předává pouze zprávy o detekci na družici Integral. Použı́vá vlastı́ binárnı́ protokol
postavený nad UTP, s přijı́macı́mi stanicemi je spojen prostřednictvı́m Internetu.
2.6
Náročnost na počı́tačové vybavenı́
Finančnı́ zdroje astronomických ústavů i astronomů nejsou neomezené. Systém by
jich tedy měl vyžadovat co nejméně. Lze napřı́klad použı́t vyřazených počı́tačů,
které majı́ dostatečný výpočetnı́ výkon.
Nároky na provoz a údržbu systému by měly být co možná nejmenšı́.
5
Goddard Space Flight Center, Goddardovo středisko pro kosmické lety, National Aeronautic
and Space Administration, Národnı́ úřad pro letectvı́ a vesmı́r
Kapitola 3
Návrh
3.1
Agenty
Jak je uvedeno v popisu CCD kamery, při vyčı́tánı́ docházı́ ke značnému zatı́ženı́
počı́tače řı́dı́cı́ho vyčı́tánı́. Je tedy vhodné mı́t minimálně dvě, navzájem spojená
zařı́zenı́, z nichž jedno řı́dı́ vyčı́tánı́ z kamery a druhé se stará o zpracovánı́ snı́mků.
Systém vycházı́ z teorie agentů. Nad společným komunikačnı́m rozhranı́m běžı́
malé jednoúčelové procesy-agenty1 s, které vykonávajı́ svoji specifickou činnost,
a komunikujı́ s ostatnı́mi agenty.
Struktura agentů odpovı́dá zařı́zenı́m a procesům přı́tomných u dalekohledu.
Je možné uvažovat o následujı́cı́ch typech agentů:
• agent pro ovládánı́ kamery
• agent pro ovládánı́ montáže
• agent pro ovládánı́ střechy a meteorologické stanice
• agent pro řı́zenı́ pozorovánı́
Agenty pro řı́zenı́ pozorovánı́ budou v dalšı́m textu označovány jako klienti.
Je vhodné je rozdělit na agenty pro:
• dlouhodobé pozorovánı́
• rychlé pozorovánı́ GRB
• monitoring a správu systému
1
agenty jsou považovány za neživotné, protože se jedná o zařı́zenı́
9
10
KAPITOLA 3. NÁVRH
Jako zařı́zenı́ budeme označovat agenty ovládajı́cı́ zařı́zenı́, tedy agenty pro
kameru, montáž a střechu.
Klienti mohou migrovat z jednoho počı́tače na druhý, zařı́zenı́ migrovat nemohou. V návrhu se pro jednoduchost s migracı́ nepočı́tá.
Pro komunikaci mezi jednotlivýmy agenty použijeme standartnı́ dostupné komunikačnı́ médium se známým protokolem. Umožnı́me tak přı́padné zapojenı́
jiných druhů zařı́zenı́ či klientů.
3.2
Centrálnı́ server
Existujı́ funkce systému, které je rozumné spravovat centrálně. Jedná se vždy
o funkce, které se na všech zařı́zenı́ch chovajı́ stejně. Jako vhodný přı́klad může
posloužit autentifikace - při použitı́ veřejného uživatelského jména a tajného hesla
je vhodné zajistit, aby klientovi stačilo jedno uživatelské jméno a jedno heslo.
Dalšı́m přı́kladem může být seznam zařı́zenı́ obsažených v systému. Tyto funkce
jsou dále označovány jako centrálnı́ funkce.
Funkce, které je potřeba volat na jednotlivých zařı́zenı́ch, jsou označovány
jako lokálnı́ funkce.
Centrálnı́ funkce jsou prováděny agentem - centrálnı́m serverem. Pro prováděnı́ lokálnı́ch funkcı́ je použito přı́mé spojenı́ mezi agentem a zařı́zenı́m.
3.2.1
Přı́klad
Na diagramu 3.1 je zobrazena konfigurace systému BART.
Na montáži LX200, vyráběné firmou Meade, jsou přichyceny dvě CCD kamery
SBIG typu ST8, vybavené širokoúhlou optikou. Na hlavnı́m dalekohledu je pak
umı́stněna kamera ST9. Posuvná střecha dalekohledu je ovládána ručně.
Systém se skládá z počı́tače se jménem lascaux, na kterém běžı́ databázový
server, centrálnı́ server, všechny agenty, které řı́dı́ pozorovánı́ (pro přı́jem zpráv o
gamma záblescı́ch, pro dlouhodobá pozorovánı́), a monitoring.
Dále systém obsahuje tři počı́tače pro obsluhu kamer, k jednomu z nich je
současně připojena montáž. Jejich jména jsou volena podle typu kamer - c0, c1
pro širokoúhlé kamery a cnf1 pro kameru umı́stněnou v ohnisku dalekohledu.
BACODINE a IBAN jsou systémy pro zası́lánı́ zpráv o gama záblesku.
Do systému se může připojit monitorovacı́ klient z libovolného mı́sta na Internetu2 .
2
vnitřnı́ sı́t’, spojujı́cı́ lascaux s počı́tači pro ovládánı́ kamer, je nedostupná zvenčı́ - je chráněna
před přı́padnými útoky z Internetu pomocı́ překladu sı́t’ových adres - NAT. Pro připojenı́ monitorovacı́ch, přı́padně jiných klientů, je potřeba na lascaux nastavit forwarding jednotlivých TCP portů
na počı́tače ve vnitřnı́ sı́ti, a v konfiguračnı́ch souborech kamer je potřeba změnit název počı́tače
3.3. PRIORITY
11
Obrázek 3.1: Přehled agentů - BART
3.3
Priority
Každá funkce, která může být agentem volána, je prvkem právě jedné z následujı́cı́ch dvou množin:
množina informačnı́ch funkcı́ obsahuje funkce, které poskytujı́ informace o stavu
zařı́zenı́
množina exekučnı́ch funkcı́ obsahuje funkce, které měnı́ stav zařı́zenı́
Informačnı́ funkce mohou být volně přı́stupné. Vı́ce klientů je může volat
ve stejnou dobu. Za jejich správné provedenı́ je odpovědný ovladač zařı́zenı́.
Vykonávánı́ informačnı́ch funkcı́ trvá krátkou dobu. Nelze je přerušit.
Exekučnı́ funkce nemohou být volně přı́stupné3 . Exekučnı́ funkce lze v libovolný okamžik přerušit.
Systém použı́vá exkluzivnı́ho přı́stupu k exekučnı́m funkcı́m - nanejvýše jeden
klient může volat exekučnı́ funkce, ostatnı́ klienti při volánı́ exekučnı́ funkce obdržı́
3
napřı́klad nenı́ vhodné, aby jeden klient pohyboval dalekohledem a druhý exponoval kamery
12
KAPITOLA 3. NÁVRH
chybovou zprávu, oznamujı́cı́, že funkci nemohou zavolat. Je pak na nich, aby se
rozhodli, jak budou dále postupovat.
Je třeba zajistit výběr klienta, který bude mı́t exkluzivnı́ přı́stup. Máme dvě
možnosti:
1. připravit plán pozorovánı́ tak, aby klient s exkluzivnı́m přı́stupem byl vždy
pouze jeden
2. v průběhu pozorovánı́ určovat klienta s exkluzivnı́m přı́stupem
Detekci gama záblesků nenı́ možné předpovědět. Proto nenı́ možné dopředu
připravit plán pozorovánı́. Prvnı́ možnost tedy nelze použı́t.
Mechanismus na určenı́ vhodného klienta bude vypadat takto:
• každý klient vlastnı́ čı́slo, vyjadřujı́cı́ jak moc trvá na exkluzivnı́m přı́stupu
- prioritu
• při připojenı́ nového klienta je jeho priorita nastavena na základnı́ hodnotu
• klient může svoji prioritu zvyšovat, nebo snižovat
• klient s nejvyššı́ prioritou má přı́stup k exekučnı́m funkcı́m
• přı́stup k exekučnı́m funkcı́m nelze zı́skat zvýšenı́m priority na stejnou
hodnotu, jako má aktuálnı́ klient s přı́stupem k exekučnı́m funkcı́m
• pokud má vı́ce klientů stejnou, nejvyššı́ prioritu, klient, který zı́ská přı́stup
k exekučnı́m funkcı́m je zvolen náhodně
Je dobré si uvědomit, že poslednı́ možnost může nastat pouze v přı́padě, že
klient s nejvyšı́ prioritou se bud’to odpojı́ od systému, nebo snı́žı́ svoji prioritu.
3.3.1
Možnosti předávánı́ priorit
K zařı́zenı́ se mohou hlásit a nastavovat svoji prioritu novı́ klienti, připojenı́ klienti
mohou svoji prioritu měnit, exekučnı́ funkce mohou trvat delšı́ dobu4 . Bude tedy
docházet k situacı́m, kdy na zařı́zenı́ pro jednoho klienta běžı́ exekučnı́ funkce,
zatı́mco druhý klient žádá o změnu priority, po jejı́mž provedenı́ by se stal klientem
s nejvyššı́ prioritou - viz diagram 3.2.
Nemá smysl čekat s ukončenı́m aktivnı́ exekučnı́ funkce do okamžiku, kdy
klient s vyššı́ prioritou požádá o vykonánı́ exekučnı́ funkce - je rozumné očekávat,
že požadavek o vykonánı́ exekučnı́ funkce bude následovat hned za požadavkem
3.3. PRIORITY
13
Obrázek 3.2: Nový klient žádajı́cı́ o změnu priority
na změnu prioritu. Za cenu značného nárůstu složitosti kódu by systém zı́skal něco
málo času. Viz diagram 3.3.
Je tedy vhodné již při změně priority zajistit, že zařı́zenı́ bude připraveno
přijı́mat exekučnı́ funkce - zařı́zenı́ nesmı́ při předávánı́ priority provádět exekučnı́
funkce.
Je potřeba rozlišit dva přı́pady, jak požadavek na změnu priority ošetřit:
1. okamžitě ukončit volánı́ právě prováděné exekučnı́ funkce a změnit pořadı́
priorit
2. počkat, ukončit exekučnı́ funkce, poté změnit pořadı́ priorit
Prvnı́ přı́pad bude použit, pokud dorazı́ neodkladné nové pozorovánı́, přı́padně
bude třeba uskutečnit nějaké periodické měřenı́ opravdu v daný čas - těžko lze
připustit, aby pozorovánı́ optických dosvitů gama záblesků bylo zpožděno byt’
o několik málo desı́tek sekund, které rozhodujı́ o úspěchu či neúspěchu pozorovánı́.
Motivace druhého přı́padu spočı́vá v možnosti nechat doběhnout právě prováděné pozorovánı́ tak, abychom i z přerušeného pozorovánı́ zı́skali výsledky.
4
typickým přı́kladem je přesun dalekohledu
14
KAPITOLA 3. NÁVRH
Obrázek 3.3: Ukončenı́ exekučnı́ funkce odložené do nového volánı́
Je napřı́klad škoda, pokud jednu sekundu před ukončenı́m vyčı́tánı́ kamery zı́ská
exkluzivnı́ přı́stup jiný klient se zhruba stejnou prioritou - takto ztratı́me výsledek
několikaminutového experimentu. Přitom stačı́ s předánı́m priority chvı́li počkat,
než bude vyčten celý snı́mek.
Dalšı́ zajı́mavou možnostı́ je dovyčtenı́ kamery v průběhu přesunu montáže
na pozici nového cı́le - s ukončenı́m vyčı́tánı́ mohu počkat do okamžiku, kdy
dalekohled dosáhne nové pozice.
Nabı́zejı́ se následujı́cı́ možnosti, jak dlouho čekat:
1. předem danou dobu
2. počkat na dokončenı́ probı́hajı́cı́ exekučnı́ funkce
3. počkat na dokončenı́ probı́hajı́cı́ho bloku exekučnı́ch funkcı́
Prvnı́ řešenı́ nepřinášı́ žádné výhody. V náhodných přı́padech se podařı́ pozorovanı́ dokončit, v ostatnı́ch pouze ztratı́me čas.
Druhý přı́pad může také vést ke ztrátě času - napřı́klad tı́m, že expozice doběhne, nezı́ská systém žádný použitelný výsledek, jelikož naexponovaný snı́mek
3.3. PRIORITY
15
nebude vyčten - zabránı́ v tom přı́tomnost klientu s vyššı́ prioritu. Toto je znázorněno na diagramu 3.4.
Obrázek 3.4: Čekánı́ do ukončenı́ aktuálnı́ expozice
Lze namı́tnou, že problém s vyčı́tánı́m naexponovaného snı́mku je možné vyřešit použitı́m funkce, která nejdřı́ve snı́mek naexponuje a následně vyčte. Pozorovánı́ ale mohou pro alespoň částečnou použitelnost vyžadovat provedenı́ několika
funkcı́, volaných na několika různých zařı́zenı́ch. Přı́kladem může být pořı́zenı́
druhého snı́mku na jiných souřadnicı́ch, než byl pořı́zen prvnı́ snı́mek. Přidánı́m
nové funkce tento přı́pad nevyřešı́me.
Pouze třetı́ přı́pad přinášı́ užitek - se změnou priority se čeká tak dlouho, dokud
nenı́ dokončena část pozorovánı́, z přerušovaného pozorovánı́ máme k dispozici
výsledky, dalekohled bude optimálně využit.
Za definovánı́ začátku a konce bloku je zodpovědný klient. Definovánı́ bloků
probı́há po zařı́zenı́ch, bloky se na jednotlivých zařı́zenı́ch systému nemusı́ shodovat.
16
KAPITOLA 3. NÁVRH
Obrázek 3.5: Čekánı́ do ukončenı́ aktuálnı́ho bloku
3.3.2
Závěr
• Použijeme priorit. Komunikace mezi klienty a zařı́zenı́mi obsahuje přı́kazy
pro zahájenı́ a ukončenı́ bloku.
• Priorita se měnı́ bud’ okamžitě (vhodné pro reakci na GRB), nebo s čekánı́m
do ukončenı́ bloku (vhodné pro dlouhodobý plánovač).
• Žádost o prioritu je předávána na centrálnı́ server, který ji distribuuje zařı́zenı́m. Ta pak informujı́ klienty o splněnı́ žádosti.
3.3. PRIORITY
3.3.3
17
Přı́klady
Řešenı́ dokončenı́ vyčtenı́ kamery a současného zahájenı́ přesunu na novou pozici
vypadá následovně:
• prioritu má klient A
• A požádá kameru o zahájenı́ vyčı́tánı́
• A ukončı́ na montáži blok
• o prioritu požádá klient B
• B obdržı́ prioritu na montáži
• B provede přesun montáže na novou pozici
• kamera ukončı́ vyčı́tánı́
• A ukončı́ na kameře blok
• B obdržı́ prioritu na kameře
• B zahájı́ expozici na kameře
V následujı́cı́m přı́kladu je popsáno předávánı́ priorit mezi třemi klienty. Klientem col, který pořizuje barevné snı́mky oblohy, pro které potřebuje snı́mek
pořı́zený přes tři filtrová kola R V a I. Klientem var , který monitoruje proměnnou
hvězdu, pro který je třeba nasnı́mat dva snı́mky. A klientem grbc, který hledá optické protějšky gama záblesku, který okamžitě po obdrženı́ zprávy o gama záblesku
nasměruje dalekohled na novou pozici a začne pozorovat.
• prioritu má klient col
• col zahájı́ expozici prvnı́ho snı́mku ve filtru R
• col vyčte prvnı́ snı́mek
• col zahájı́ expozici druhého snı́mku ve filtru V
• o prioritu požádá var
• col vyčte druhý snı́mek
• col zahájı́ expozici třetı́ho snı́mku ve filtru I
• col zahájı́ vyčı́tánı́ třetı́ho snı́mku
18
KAPITOLA 3. NÁVRH
• col ukončı́ na montáži blok
• var obdržı́ prioritu na montáži
• var zahájı́ přesun montáže na novou pozici
• col dokončı́ vyčtenı́ třetı́ho snı́mku
• col ukončı́ na kameře blok
• var obdržı́ na kameře prioritu
• var v přı́padě, že se montáž ještě stále pohybuje, počká do ukončenı́ přesunu
• var zahájı́ expozici prvnı́ho snı́mku na kameře
• var zahájı́ vyčı́tánı́ kamery
• grbc obdržı́ zprávu o gama záblesku
• grbc zjistı́, že pozice gama záblesku je pozorovatelná
• o prioritu požádá grbc
• dojde k ukončenı́ vyčı́tánı́ kamery
• var obdržı́ zprávu o odejmutı́ priority
• grbc obdržı́ na montáži i kameře prioritu
• grbc zahájı́ přesun montáže
• grbc počká na ukončenı́ přesunu montáže
• grbc zahájı́ expozici na kameře
3.4
Zmenšenı́ chyb montáže
Přesnost najı́žděnı́ montáže ovlivňujı́ jednak systematické pravidelné chyby, jednak náhodné poruchy. Možné chyby a jejich přı́činy jsou přesně a úplně popsány v
[Trueblood, Genet–1997], v následujı́cı́m textu se omezı́me pouze na jejich shrnutı́
a na návrch jejich zmenšenı́.
Systematické chyby závisı́ na pozici montáže. Lze je přesně spočı́tat a lze pro
ně určit funkci, která je bude modelovat.
Náhodné chyby vznikajı́ hlavně nepřesnostı́ snı́mačů polohy montáže. Jejich
průběh nelze modelovat.
3.5. STAVY ZAŘÍZENÍ
19
V současné době lze dı́ky existenci velkých hvězdných katalogů a rychlých
počı́tačů dopočı́tat skutečnou pozici středu snı́mku v čase nepřesahujı́cı́m čas
expozice. Je tedy možné realizovat zpětnou vazbu, která vypadá následovně:
• najed’ na pozici ~x
• pořid’ snı́mek hvězdného pole
• detekuj na snı́mku hvězdy
• s pomocı́ nepřesných souřadnic z dalekohledu urči přesnou polohu středu
snı́mku ~y
• vypočti chybu ~δ = ~x − ~y , změn hodnoty čı́tačů dalekohledu.
Pozice montáže pak bude neustále opravována, velikost náhodné chyby bude
po dopočtenı́ pozice snı́mku nulována.
3.5
Stavy zařı́zenı́
Každé zařı́zenı́ a centrálnı́ server má pole stavů. Stav je bitová maska. Podle stavu
zařı́zenı́ lze rozpoznat, jestli zařı́zenı́ provádı́ dlouhotrvajı́cı́ funkce. O změně stavu
jsou informováni všechni připojenı́ klienti.
Zařı́zenı́ majı́ navı́c jeden speciálnı́ stav. Ten určuje, zda má klient přı́stup k
exekučnı́m funkcı́m. Změna tohoto stavu je oznamována pouze procesům, kterých
se změna týká.
3.6
Stavový diagram
on označenı́ pro množinu stavů, ve kterých je systém v normálnı́m provozu.
standby označenı́ množiny stavů, ve kterém systém čeká na pozorovánı́. Je aktivován napřı́klad v situaci, kdy je kompletně zatažená obloha, ale snı́mky z
meteorologické družice dávajı́ šanci na vyjasněnı́ v průběhu noci. Systém se
připravuje na pozorovánı́ (chladı́ kamery, otvı́rá střechu), pozorovacı́ klienti
neposı́lajı́ požadavky na pozorovánı́.
off stav, ve kterém je celý systém vypnutý. Důvodem pro vypnutı́ může být
napřı́klad zaručeně nepřı́znivé počası́ (sněhová vánice, bouře), přı́padně
technické problémy.
20
KAPITOLA 3. NÁVRH
Obrázek 3.6: Stavový diagram centrálnı́ho serveru
day den. Protože dalekohled je určen pro astronomické pozorovánı́, neběžı́ žádné
úlohy. Lze pouze uvažovat o prováděnı́ výpočetně náročných úkolů souvisejı́cı́ch se zpracovánı́m dat z minulých pozorovánı́.
evening večer. Systém se připravuje na pozorovánı́. Přechod do tohoto stavu
sloužı́ jako informace pro zařı́zenı́, aby se připravila k pozorovánı́. Napřı́klad
se začne s chlazenı́m kamer, otevře se střecha. Stav začı́ná v pevně danou
dobu před západem Slunce, trvá do západu Slunce (sunset).
dusk soumrak. Systém je připraven na pozorovánı́. Obloha je světlá, nemá smysl
provádět dlouhodobá pozorovánı́. Lze provádět pozorovánı́ jasných objektů
- pokud dojde v tomto okamžiku ke gama záblesku, má význam ho pozorovat. Jinak je vhodné pořizovat kalibračnı́ snı́mky. Trvá od západu Slunce do
začátku civilnı́ho soumraku5 .
night noc. Systém je plně připraven na pozorovánı́, obloha je temná. Pozoruje se.
Stav trvá po dobu civilnı́ho soumraku, nautického soumraku a astronomické
noci, tedy v čase, kdy je Slunce vı́ce jak 6 stupňů pod obzorem.
dawn rozbřesk. Stav podobný soumraku, vhodný pro pozorovánı́ jasných objektů nebo pořizovánı́ kalibračnı́ch snı́mků. Trvá od konce astronomického
soumraku po východ Slunce (sunrise).
morning ráno. Stav pro ukončenı́ pozorovánı́. Vypı́ná se chlazenı́ kamer, parkuje
dalekohled, zavı́rá střecha, zpracovávajı́ korekčnı́ snı́mky. Trvá od východu
Slunce po pevně určenou dobu.
5
civilnı́ soumrak nastává v okamžiku, kdy je Slunce 6 stupňů pod obzorem
3.7. ZAŘÍZENÍ
21
3.7
Zařı́zenı́
3.7.1
Kamery
Stavový diagram kamer
Obrázek 3.7: Stavový diagram CCD kamery
noexposure na daném čipu neprobı́há žádná expozice
exposing probı́há expozice
data na kameře jsou k dispozici data, která je potřeba vyčı́st
reading probı́há vyčı́tánı́ dat
Chlazenı́ kamer
Všechny novějšı́ astronomické CCD kamery majı́ zabudované chlazenı́. Chlazenı́
snižuje teplotu CCD čipu, a tı́m snižuje hodnotu temného proudu.
Temný proud je tvořen nábojem, který se nashromáždı́ na čipu vlivem teplotnı́ch efektů - tedy i v přı́padě, když na čip nedopadá světlo. Při pořizovánı́ dennı́ch
snı́mků můžeme jeho efekt zanedbat - snı́mky majı́ krátké expozičnı́ doby a vysoký odstup signál/šum. Pro astronomické snı́mky, které jsou pořizovány dlouhou
expozičnı́ dobou a vyznačujı́ se malým odstupem signálu od šumu, je potřeba hodnotu temného proudu co nejvı́ce snı́žit. Úroveň temného proudu závisı́ na absolutnı́
teplotě čipu, rozdı́l mezi teplotou čipu a teplotou okolnı́ho prostředı́ ji neovliňuje.
Teplotnı́ regulace je většinou tvořena peltiérem a ventilátorem. Peltiér přenášı́
teplo z malé plochy čipu na ventilátor, ventilátor pak zlepšuje distribuci tepla do
okolı́. Teplotnı́ regulace bývá občas doplněna o možnost chlazenı́ vodou, přı́padně
zkapalněným plynem.
Expozici i vyčtenı́ snı́mku je vhodné provádět při konstantnı́ teplotě - neměnı́ se
pak úroveň temného proudu. Změny teploty CCD čipu trvajı́ nenulový čas, teplota
atmosféry se po západu Slunce v průběhu noci změnı́ většinou pouze o několik
stupňů. Po každé změně teploty je třeba vyčkat, než se dostatečně prochladı́ celý
CCD čip.
22
KAPITOLA 3. NÁVRH
Provoz RTS1 ukázal, že nemá smysl teplotu čipu v průběhu noci měnit. Systém
původně obsahoval kód, který se snažil optimalizovat cı́lovou teplotu chlazenı́ čipu
tak, aby se přı́kon chlazenı́ držel v rozmezı́ doporučovaného výrobcem čipu. Při
zpětné kontrole snı́mků pořı́zených v průběhu změny teploty se ukázalo, že snı́mky
nemajı́ lineárnı́ průběh pozadı́ - prostředek snı́mku má hodnoty temného proudu
vyššı́ než okraje pole. Tato nelinerita je způsobena rozdı́lnou teplotou okraje a
středu CCD čipu.
Aby bylo temných snı́mků potřeba co nejméně, je vhodné pořizovat snı́mky
na co nejmenšı́m počtu teplot. U systému BART se osvědčily pětistupňové kroky.
Nastavenı́ teploty kamery
Obrázek 3.8: Stavový diagram chlazenı́ CCD kamery
Před začátkem pozorovánı́ je spuštěno chlazenı́ na maximálnı́ výkon. V okamžiku začátku pozorovánı́ je zjištěna aktuálnı́ teplota CCD čipu ccd, která je
zaokrouhlena směrem nahoru k nejbližšı́mu stupni step a na tuto teplotu je nastaveno chlazenı́. Obsluha má možnost teplotu a výkon chlazenı́ kontrolovat, a podle
potřeby měnit. Po skončenı́ pozorovánı́ nebo při vypnutı́ systému je chlazenı́ vypnuto.
Chlazenı́ má tedy následujı́cı́ stavy:
shutdown chlazenı́ je vypnuto
max chlazenı́ běžı́ na maximálnı́ hodnotu, ventilátor běžı́
temp chlazenı́ se snažı́ udržet teplotu čipu na nastavené hodnotě.
Dostupné informace
• chlazenı́ kamery - cı́lová teplota, procentnı́ vyjádřenı́ výkonu, teplota čipu,
teplota okolı́
• velikost snı́maného pole
• velikost výřezu ze snı́maného pole
3.7. ZAŘÍZENÍ
3.7.2
23
Montáž
Stavy montáže
Obrázek 3.9: Stavový diagram montáže
parked montáž je zaparkována
tracking pohyb montáže sleduje pohyb hvězdné oblohy
moving montáž se pohybuje
Korekce
Korekce jsou počı́tány z pozice dalekohledu v době expozice a skutečné pozice
středu snı́mků, zjištěné dodatečnou astrometriı́. Označme ~a pozici dalekohledu v
době expozice, ~b dodatečně zjištěnou pozici, pak zjištěná chyba ~δ je rovna ~a − ~b.
Pokud máme jenom jednu korekci, stačı́ změnit o tuto hodnotu čı́tače dalekohledu,
~ − ~δ, kde a‘
~ je aktuálnı́ pozice dalekohledu v době
tedy nastavit je na hodnotu a‘
aplikace korekce.
Pořı́zené snı́mky budeme čı́slovat. Čı́slo snı́mku je v dalšı́m textu uváděno v
dolnı́m indexu. Dolnı́ index u chyby značı́, že byla spočı́tána ze snı́mku, jehož
čı́slo se rovná hodnotě dolnı́ho indexu.
Korekce jsou dopočı́távány v různém pořadı́ a jejich výpočet trvá různě dlouhou dobu. Může nastat tato situace:
• zjistı́me orientaci dalekohledu a~1 , zı́skáme z CCD kamery snı́mek img1
• dalekohledem přejedeme na novou pozici a~2
• zjistı́me orientaci dalkohledu a~2 , zı́skáme snı́mek img2
• dopočı́táme chybu δ~1 , změnı́me o jejı́ hodnotu čı́tače dalekohledu
• dalekohledem přejedeme na novou pozici a~3
24
KAPITOLA 3. NÁVRH
• dopočı́táme chybu δ~2
V tomto okamžiku je potřeba změnit hodnoty čı́tače o δ~2 - δ~1 . V přı́padě, že
je aktuálně exponován snı́mek m, je potřeba změnit čı́tače při přı́chodu korekce
spočı́tané ze snı́mku a o
m−1
P ~
δ~m −
δi
i=a
Bylo by vhodné, aby ovládánı́ montáže nemuselo být informováno o probı́hajı́cı́
expozici. Úkolem montáže nenı́ hlı́dat, co kamery na nı́ umı́stněné vykonávajı́.
Mı́sto obrázků se proto pomocı́ globálnı́ proměnné correction mark čı́slujı́
korekce. Jejı́ hodnota je na počátku nastavena na nulu. Dále je k dispozici pole δ
délky l, které je na počátku vynulováno.
Při expozici je z ovládánı́ montáže zjištěno čı́slo poslednı́ korekce - hodnota
correction mark. Toto čı́slo je uloženo spolu s názvem snı́mku do zásobnı́ku, ze
kterého jsou snı́mky odebı́rány pro vypočı́tánı́ astrometrie a z nı́ plynoucı́ chyby
najı́žděnı́ montáže. Korekčnı́ čı́slo je zjišt’ováno spolu s orientacı́ montáže, která
se ukládá do snı́mku, a z které se počı́tá chyba najı́žděnı́.
Po dopočı́tánı́ chyby je jejı́ hodnota, spolu s přiřazeným čı́slem korekce j,
odeslaná na ovládánı́ montáže. Pokud platı́, že j < correction mark − l, je
hodnota chyby ignorována a nenı́ dále zpracovávána. K hodnotě chyby se přičte
hodnota uložená v poli δ na pozici j mod l6 , dostaneme tı́m hodnotu ω. Toto je
opravená hodnota korekce, která se odešle na montáž. Od každého člena pole δ
odečteme hodnotu ω. Nakonec zvětšı́me hodnotu correction mark o jedničku a
prvek z pole δ s indexem correction mark mod l vynulujeme.
Tento postup zaručuje, že v poli δ jsou uchovávány hodnoty korekcı́ chyb.
Na pozici i je vždy uchovávána hodnota korekce pro chybu z dalšı́ho snı́mku
pořı́zeného s korekčnı́m čı́slem i.
Popsaný postup správně opravuje hodnoty chyb o hodnoty všech chyb aplikovaných mezi pořı́zenı́m snı́mku a okamžikem ukončenı́ jeho zpracovánı́. Součet
těchto hodnot je obsažen v poli δ pod přı́slušným indexem.
• aktuálnı́ poloha dalekohledu - rektascenze, deklinace
• azimutové souřadnice - azimut, výška nad obzorem
• mı́stnı́ hvězdný čas
6
operátor mod značı́ zbytek po celočı́selném dělenı́
3.7. ZAŘÍZENÍ
25
• světový čas - UT
• zeměpisná poloha dalekohledu - zeměpisná délka, zeměpisná šı́řka
• čı́slo korekce
3.7.3
Kopule, střecha, meteorologická stanice
Je nutné zajistit zavřenı́ střechy při špatném počası́. Dalekohled je citlivý a drahý
přı́stroj, který může být povětrnostnı́mi vlivy poškozen. Dalkohled je potřeba
chránit zejména před vlhkem a nárazovým větrem.
Střechu je pořeba v přı́padě zjištěnı́ nepřı́znivých povětrnostnı́ch podmı́nek
zavřı́t. Pro zajištěnı́ nejvyššı́ možné spolehlivosti je vhodné spojit meteorologickou
stanici s ovládánı́m střechy do jednoho celku. Systém je pouze informován o
zavřenı́ střechy na přı́kaz meteorologické stanice.
Pro dalekohled s otočnou kopulı́ je potřeba zajistit natáčenı́ kopule, a jejı́
parkovánı́. Kopule se parkuje na danou pozici.
Stavy střechy, kouple
WEATHER_BAD
WEATHER_GOOD
ROOF_OPEN
opened
ROOF_OPENING
close
ROOF_CLOSING
closed
open
ROOF_CLOSED
DOME_STILL
DOME_PARKED
DOME_MOVING
Obrázek 3.10: Stavový diagram střechy, kopule
roof open střecha je otevřená
26
KAPITOLA 3. NÁVRH
roof closed střecha je zavřená
roof opening střecha se otvı́rá
roof closing střecha se zavı́rá
weather good počası́ umožňuje pozorovánı́
weather bad počası́ neumožňuje pozorovánı́
dome still kopule se nepohybuje, je srovnána s pozicı́ dalkohledu
dome moving kopule se pohybuje
dome parked kopule je zaparkována tak, jak nařizujı́ bezpečnostnı́ předpisy
pozice štěrbiny
3.8. KLIENTI
3.8
3.8.1
27
Klienti
Organizace pozorovánı́
Pozorovánı́ jsou řazena do epoch. Dělenı́ na epochy je vhodné z následujı́cı́ch
důvodů:
• upořádánı́ pozorovacı́ho systému se čas od času měnı́. Do systému jsou
přidávány nové kamery, snı́mky z těchto nových kamer majı́ jiné vlasnosti
než snı́mky ze starých kamer
• nenı́ možné předpokládat, že by se podařilo uložit všechny snı́mky na jeden
pevný disk. Dělenı́m na epochy je možné snı́mky archivovat na sı́t’ové disky,
přı́padně páskové archivačnı́ boxy
3.8.2
Databáze
Klient má přı́stup do databáze. V databázi jsou obsaženy tabulky pro:
epoch epochy
targets cı́le pozorovánı́
types popis typů pozorovánı́, informace specifické pro určité typy pozorovánı́
jsou ukládány do samostatných tabulek, základnı́ verze systému obsahuje
tabulky ot pro přı́ležitostné cı́le (opportunity targets) a grb pro GRB.
observations zprávy o průběhu jednotlivých pozorovánı́
images snı́mky
darks, flats korekčnı́ snı́mky
cameras, mounts pomocné tabulky pro evidenci konfigurace zařı́zenı́
medias pomocná tabulka pro ukládánı́ informacı́ o médiı́ch, určených pro archivovánı́ snı́mků, informacı́ o tom, jestli je daná cestě dostupná
Na obrázku 3.11 je diagram závislostı́ mezi tabulkami. Celá databáze je navržena kolem vazby mezi tabulkami targets, observations a images.
Databáze je využı́vána plánovačem, který z tabulky targets a přı́padně dalšı́ch
provázaných tabulek čte údaje o možných cı́lech pozorovánı́, a ukládá do nı́
informace o průběhu pozorovánı́. Klient pro přı́jem zpráv o GRB do databáze
ukládá údaje o obdrženém GRB.
Dále je využı́vána pro ukládánı́ informacı́ o napozorovaných snı́mcı́ch.
28
KAPITOLA 3. NÁVRH
Obrázek 3.11: Diagram závislostı́ databáze
3.8.3
Pořizovánı́ snı́mků
Při pořizovánı́ snı́mků je odpovědnostı́ klienta si k nim opatřit potřebné informace,
které uložı́ do hlavičky snı́mku. Jedná se zejména o pozici dalekohledu v době
pořı́zenı́ snı́mku.
Pořizovánı́ snı́mků probı́há z pohledu klienta následovně:
• počkej na stav montáže TRACKING a stav kamery NOEXPOSURE
• zahaj na kameře expozici
• shromáždi všechny informace, vztahujı́cı́ se k začátku expozice, potřebná
pro uloženı́ do hlavičky snı́mku
• počkej na stav kamery DATA
• zahaj na kameře vyčı́tánı́; od tohoto okamžiku je možné pohybovat s dalekohledem
• počkej na dokončenı́ vyčı́tánı́
• ulož snı́mek
• zajisti zpracovánı́ snı́mku
Zpracovánı́ snı́mku většinou poběžı́ i po zahájenı́ dalšı́ expozice. Protože nám
toto zpracovánı́ poskytne údaje o chybě v určenı́ pozice snı́mku, je vhodné mı́t
možnost se zpracovánı́m snı́mků komunikovat až do jeho ukončenı́.
Před pořı́zenı́m prvnı́ho snı́mku je potřeba do databáze pozorovánı́ zanést
informaci o začátku pozorovánı́ nového pole, po ukočenı́ vyčı́tánı́ poslednı́ho
snı́mku je třeba zanést informace o ukončenı́ pozorovánı́ tohoto pole. V přı́padě,
že se podařı́ snı́mek opatřit astrometriı́, je potřeba ho přidat do databáze snı́mků.
3.8. KLIENTI
3.8.4
29
Ukládánı́ snı́mků
Snı́mky jsou ukládány do souboru s názvem ve tvaru YYYYMMDDhhmmss.
Název odpovı́dá světovému času zahájenı́ expozice - YYYY vyjadřuje roky, MM
měsı́ce, DD dny, hh hodiny, mm minuty a ss sekundy.
Snı́mky, u kterých se nepodařı́ dodatečným zpracovánı́m určit jejich přesné
souřadnice, jsou ukládány do podadresáře v adresáři /trash, odpovı́dajı́cı́mu názvu
kamery.
Snı́mky, u kterých se podařı́ určit jejich přesnou polohu, jsou ponechávány
v adresáři /images. Tento adresář je členěn na podadresáře pro epochy, názvy
detektorů a čı́sla polı́.
Napřı́klad snı́mek umı́stněný do souboru s celou cestou /images/ 002/ C0/ 04323/ 20030412230405.fits
byl pořı́zen ve druhé epoše, detektorem C0, pro pole s čı́slem 4323. Jeho expozice
začala 12. dubna 2003 ve 23 hodin, 4 minuty, 5 vteřin světového času.
Temné snı́mky a flat fieldy jsou použitelné pouze kolem doby svého pořı́zenı́.
Proto jsou ukládány do struktury, která umožňuje snadno a rychle dohledat k
danému datu korekčnı́ snı́mek - temné snı́mky do adresářu odpovı́dajı́cı́ch roku
a měsı́ci pořı́zenı́, flat fieldy do adresářů odpovı́dajı́ch roku, měsı́ci, dni a době
pořı́zenı́ snı́mku. Formát názvu souboru je stejný jako u obyčejných snı́mků,
obsahuje tedy datum a čas pořı́zenı́ snı́mku. Temné snı́mky jsou ukládány do
podadresářu adresáře /darks, flat fieldy jsou ukládány do podadresářů adresáře
/flats.
3.8.5
Monitoring
Monitoring poskytuje informace o stavu a hodnotách všech zařı́zenı́ připojených
do systému.
Dále umožňuje volat funkce připojených zařı́zenı́ a provádět manuálnı́ expozice. Při manuálnı́m ostřenı́ přı́strojů je vhodné vyčı́tat pouze část CCD. Vyčı́tánı́
je potom rychlejšı́ a uživatel může kameru rychleji zaostřit.
3.8.6
Dlouhodobá pozorovánı́
Úkolem tohoto klienta je zajistit využitı́ dalekohledu v době, kdy neprobı́há pozorovánı́ gama záblesku klientem pro pozorovánı́ gama záblesku. Pracuje proto s
nižšı́ prioritou než má klient pro pozorovánı́ gama záblesku.
Klient vybı́rá cı́le pozorovánı́ z tabulky, která obsahuje seznam možných cı́lů
pozorovánı́. Vybrané pozorovánı́ nechá proběhnout, počká na jeho dokončenı́ a
vybere dalšı́ vhodné pozorovánı́.
Pořadı́, ve kterém jsou cı́le pro systém BART vybı́rány, je určeno následovně:
30
KAPITOLA 3. NÁVRH
• pokud existuje zpráva o gama záblesku, který je vı́ce jak 20 stupňů nad
obzorem, a který byl aktualizován před méně než třemi dny7 , je vybrán
tento cı́l. Pokud je podobných cı́lů vı́ce, je vybrán ten, který je nejvýše nad
obzorem.
• pokud existuje snı́mek mladšı́ než půl hodiny s astrometriı́8 , a existuje přı́ležitostný cı́l (ot), který je vı́ce jak 10 stupňů nad obzorem, nenı́ na severu9 ,
pro který existuje za poslednı́ noc menšı́ počet snı́mků, než je minimálnı́
cı́l, a který nebyl pozorován před menšı́m časem, než je nejmenšı́ rozestup,
je tento vybrán. Pokud existuje podobných cı́lů vı́ce, jsou vybı́rány podle
rozdı́lné priority, počtu pořı́zených snı́mků, výšce nad obzorem a počtu
požadovaných cı́lů.
• jinak je vybráno pole z přehlı́dkových polı́, které nenı́ na severu, je v předem
definované výšce nad obzorem, a má nejmenšı́ počet zařazených snı́mků.
Dále je tento klient zodpovědný za pořizovánı́ kalibračnı́ch snı́mků v průběhu
soumraku a rozbřesku.
Pro jiné systémy může být algoritmus výběru snı́mku definován odlišně.
3.8.7
Klient pro pozorovánı́ GRB
Tento klient se stará o rychlé pozorovánı́ GRB. Většinu času pouze čeká na přijetı́
zprávy o GRB.
Po přijetı́ souřadnic záblesku je uložı́ do databáze cı́lů. Dále zjistı́, zda je mı́sto
záblesku pozorovatelné či nikoliv.
Pokud toto mı́sto pozorovatelné nenı́, pokračuje v čekánı́ na dalšı́ GRB. Za
provedenı́ opožděného pozorovánı́ GRB je zodpovědný klient pro řı́zenı́ dlouhodobého pozorovánı́.
Pokud je GRB pozorovatelný, změnı́ svoji prioritu na nastavenou úroveně,
počká na potvrzenı́ změny priority od montáže, zahájı́ přesun montáže, počká na
potvrzenı́ změny priority od kamery a zahájı́ na kameře standartnı́m postupem
expozici.
Po pořı́zenı́ předem daného počtu snı́mků snı́žı́ svoji prioritu na původnı́ úroveň
a čeká na dalšı́ zprávy o GRB. Znovu je věcı́ plánovače pro dlouhodobá pozorovánı́
zajistit pozorovánı́ mı́sta s GRB po delšı́ době. Toto pozorovánı́ je nutné pro
přı́padnou relativnı́ fotometrii pohası́najı́cı́ho optického protějšku.
7
toto kritérium zaručuje, že nebudou vybı́rány GRB, u kterých je minimálnı́ šance na detekci
optického protějšku
8
t.j. alespoň občas jsou vidět hvězdy
9
oblast pro dalekohled těžko přı́stupná, v které může dojı́t k zachycenı́ kabelů a následnému
zničenı́ krokových motorů
Kapitola 4
Implementace
4.1
Cı́lová platforma
Cı́lovou platformou jsou počı́tače založené na Intelovské architektuře x86.
Použı́vaným operačnı́m systémem je GNU Linux. Byly zkoumány distribuce
RedHat, Mandrake a Debian. Dı́ky propracovanému balı́kovacı́mu systému se jako
nejlepšı́ jevı́ Debian. Ten je nasazován na všechny nové počı́tače.
Komunikace mezi agenty použı́vá sı́t’ový protokol TCP/IP.
4.2
Cı́lový jazyk
Většina kódu je napsána v jazyce C, tedy bez použitı́ objektů. Databázové operace
jsou popsány v jazyce SQL. Webovské stránky jsou psané v jazyce PHP. Integračnı́
části kódu jsou psány v bash skriptech.
4.3
Protokol
V následujı́cı́m textu je za server označován proces, který čeká na spojenı́. Jako
klient je pak označován proces, který spojenı́ otvı́rá.
Je potřeba rozlišovat klienty pro jednotlivé činnosti (monitoring, ..) s klienty
v protokolu.
Proces centrálnı́ho serveru vystupuje v protokolu pouze jako sever.
Klientské procesy vystupujı́ v protokolu vždy jako klienty. Zařı́zenı́, na které
se připojujı́, jsou servery.
Zařı́zenı́ vystupujı́ při komunikaci s centrálnı́m server jako klient. Při komunikaci mezi zařı́zenı́mi se jedno chová jako klient a druhé jako server.
31
32
4.3.1
KAPITOLA 4. IMPLEMENTACE
Formát
Komunikace může probı́hat bud’ pomocı́ binárnı́ch nebo textových zpráv.
Binárnı́ komunikace je těžká pro pochopenı́ při pohledu zvenčı́, vyžaduje
použı́vánı́ přesných volánı́. Binárnı́ komunikace je svázána s architekturou, na
které funguje. Při jejı́m přı́jmu na jiné architektuře je většinou zapotřebı́ ji nejdřı́ve
konvertovat.
Textové rozhrannı́ lze při pohledu zvenčı́ snadno pochopit. Je náročnějšı́ na
systémové prostředky než binárnı́ komunikace - jsou přenášena delšı́ data, přijaté
přı́kazy je potřeba před zpracovánı́m detekovat.
Systém použı́vá pro přenos přı́kazů a zpráv textové komunikace. Pro přenos
binárnı́ch dat (snı́mků) se použı́vá binárnı́ho formátu.
Bloky komunikace v textovém rozhrannı́ jsou ukončovány značkou konce
řádky. Bud’to se použı́vá znaků platných v protokolu Telnet [RFC854] - tedy
znaku CR následovaného znakem LF, nebo pouze znaku LF.
Jednotlivé položky řádku jsou oddělovány nejméně jednı́m znakem mezera.
4.3.2
Přı́kazy
Přı́kazy posı́lá klient serveru. Prvnı́ položkou řádku je název přı́kazu. Název přı́kazu je následován parametry.
Na jedné řádce je možné poslat několik přı́kazů. Jako jejich oddělovač sloužı́
střednı́k.
4.3.3
Odpovědi
Server na přı́kazy odpovı́dá. Odpověd’serveru je vždy zakončena řádkou, začı́najı́cı́
znakem ’+’ nebo ’-’ a pokračujı́cı́ stavovým kódem složeným ze třı́ čı́slic. Server
začne dalšı́ přı́kaz přijatý od klienta zpracovávat až po odeslánı́ zakončovacı́ řádky.
Pokud je prvnı́m znakem zakončovacı́ řádky ’+’, přı́kaz byl úspěšně vykonán.
Pokud je tı́mto znakem ’-’, přı́kaz skončil chybou. Podle stavového kódu lze pak
rozlišit, o jakou chybu se jednalo.
Řádky obsahujı́cı́ proměnné začı́najı́ malým pı́smenem. Posı́lá je server klientovi, většinou jako reakci na přı́kaz a tedy před tı́m, než oznámı́ ukončenı́ přı́kazu.
Prvnı́ položka je název proměnné, druhá jejı́ hodnota.
Napřı́klad po dotazu na pozici montáže může montáž odpovědět ra 10, což
znamená, že je v rektascenzi nastavena na 10 stupňů.
4.4. PŘÍKAZY PROTOKOLU
4.3.4
33
Zprávy a žádosti serveru
Řádky, které posı́lá server klientovi a které začı́najı́ velkým pı́smenem obsahujı́
bud’to zprávy, nebo žádosti serveru. Mohou se vyskytovat kdykoliv v průběhu
komunikace klienta se serverem. Klient jejich přı́jem nepotvrzuje.
Stavové zprávy
Začı́najı́ znakem ’S’, a obsahujı́ název stavu, jeho novou hodnotu a doplňujı́cı́
komentář.
Otevřenı́ datového spojenı́
Žádosti pro otevřenı́ nového datového spojenı́ začı́najı́ pı́smenem D. Poté následuje
řetězec connect, jméno nebo IP adresa a port, na který se má klient připojit. Poslednı́
je délka bloku přenášených dat.
Klient by se po přijetı́ této žádosti měl pokusit o navázánı́ spojenı́ na danou
sı́t’ovou adresu.
Zprávy
Zprávy začı́najı́ pı́smenem M, za kterým následuje text zprávy.
Informačnı́ zprávy
Začı́najı́ pı́smenem I. Informujı́ klienta o změně hodnot stavu serveru, a o připojených klientech.
4.3.5
Přenos snı́mků
Snı́mky se přenášejı́ přes datové spojenı́. Přenos začı́ná hlavičkou, ve které je
uvedena velikost a formát snı́mku.
4.4
4.4.1
Přı́kazy protokolu
Konvence
Tučně je vysázeno jméno přı́kazu a jméno návratové hodnoty. Návratové hodnoty
lze nalést v souboru include/status.h.
Kurzı́vou a v [hranatých závorkách] jsou vysázeny parametry přı́kazu. V [hranatých závorkách] jsou vysázeny hodnoty proměnných.
34
4.4.2
Obecné návratové hodnoty
Zařı́zenı́ vracı́ 0, pokud požadovaná operace proběhla úspěšně. Pokud přı́kaz neexistuje, nebo klient nenı́ autorizován pro prováděnı́ daného přı́kazu, vracı́ hodnotu
DEVDEM E COMMAND. Pokud je pro přı́kaz zadán nesprávný počet parametrů,
vracı́ hodnotu DEVDEM E PARAMSVAL.
4.4.3
Inicializačnı́ přı́kazy
login [jméno uživatele] zahájı́ proces přihlášenı́ do systému
E:DEVDEM E COMMAND klient je již přihlášen nebo registrován
E:DEVDEM E SYSTEM nenı́ možné přihlásit dalšı́ho uživatele
password [heslo] přihlásı́ uživatele do systému
logged as [čı́slo spojenı́] čı́slo spojenı́ na straně serveru, použı́vané pro dalšı́ autentifikaci
I status num [počet stavů]
I status [čı́slo stavu] [název stavu] [současná hodnota stavu]
E:DEVDEM E SYSTEM heslo neodpovı́dá
register [jméno zařı́zenı́] [typ zařı́zenı́] [host]:[port] zaregistruje nové zařı́zenı́
E:DEVDEM E SYSTEM zařı́zenı́ se stejným jménem je již zaregistrováno
Informačnı́ přı́kazy
info vypı́še informace o připojených zařı́zenı́ch a připojených klientech
user [id] [priorita] [*—-] [jméno uživatele] [popis prováděnné činnosti] informace o připojeném klientu - jeho čı́slo, priority, zda je klientem s nejvyšı́ prioritou
či ne, a stručný popis, o jakého klienta se jedná
device [čı́slo zařı́zenı́] [jméno zařı́zenı́] [host]:[port] [typ zařı́zenı́] informace o
připojeném zařı́zenı́
key [jméno zařı́zenı́] vyžádá si klı́č pro autorizaci
authorization key [jméno zařı́zenı́] [klı́č] autorizačnı́ klı́č pro dané zařı́zenı́
E:DEVDEM E SYSTEM zařı́zenı́ neexisuje
priority [nová priorita] změnı́ prioritu daného spojenı́
old priority [hodnota priority] současná priorita spojenı́
actual priority [čı́slo spojenı́ držı́cı́ho prioritu] [hodnota jeho priority] spojenı́ s
4.4. PŘÍKAZY PROTOKOLU
35
největšı́ prioritou
new priority [čı́slo spojenı́ držı́cı́ prioritu] [hodnota priority] spojenı́ s prioritou
po provedenı́ změny
E:DEVDEM E PRIORITY pokud změna priority nemohla proběhnout
prioritydeferred [nová priorita] provede odloženou změnu priroty
on změnı́ stav serveru na jeden z operačnı́ch stavů, v závislosti na aktuálnı́m čase
a datu
standby přepne server do jednoho ze stavů ”standby” režimu
ready pokud je server ve standby režimu, přepne ho do jednoho ze stavů ”on”
režimu
off změnı́ stav serveru na ”off”
4.4.4
Zařı́zenı́ - obecná komunikace
Pokud nenı́ klient autorizován, vracı́ všechna komunikace hodnotu DEVDEM E SYSTEM.
Pokud dojde při vykonávánı́ přı́kazu k chybě v komunikaci se zařı́zenı́m, vracı́
se hodnota DEVDEM E HW.
auth [čı́slo spojenı́] [autentifikačnı́ klı́č] provede autorizaci
I status num [počet stavů]
I status [čı́slo stavu] [jméno stavu] [hodnota stavu] informace o stavu zařı́zenı́
E:DEVDEM E SYSTEM pokud autorizace neproběhla
ready zjistı́, jestli je zařı́zenı́ připojeno. Je možné volat opakovaně.
help vypı́še nápovědu
exit ukončı́ spojenı́
blockstart informuje zařı́zenı́ o začátku bloku, nutné pro provedenı́ odložené
změny priority
E:DEVDEM E SYSTEM pokud je spojenı́ již v bloku
blockcheck odložená změna priority je možná
E:DEVDEM E SYSTEM pokud nenı́ spojenı́ v bloku
36
blockend ukončenı́ bloku pro odloženou změnu priority
E:DEVDEM E SYSTEM pokud spojenı́ nenı́ v bloku
4.4.5
Kamera
info vypı́še informace o kameře
type [typ kamery]
serial [sériové čı́slo kamery]
chips [počet čipů kamery]
temperature regulation [0 — 1 — 2] stav chazenı́ kamery - chlazenı́ vypnuto,
chladı́m na maximálnı́ výkon, držı́m teplotu chlazenı́
temperature setpoint [teplota] teplota, na kterou se kamera snažı́ chladit
air temperature [teplota] hodnota teplotnı́ho čidla, udávajı́ teplotu vzduchu
ccd temperature [teplota] teplota CCD čipu
cooling power [promile výkonu] hodnota chlazenı́
fan [0—1] stav větráku kamery
chipinfo [čı́slo čipu] vracı́ informace o daném čipu
chip [čı́slo čipu] width [šı́řka] šı́řka čipu
chip [čı́slo čipu] height [výška] výška čipu
chip [čı́slo čipu] binning vertical [vertikálnı́ binning]
chip [čı́slo čipu] binning horizontal [horizontálnı́ binning]
chip [čı́slo čipu] pixelX [rozměr pixelu v ose X]
chip [čı́slo čipu] pixelY [rozměr pixelu v ose Y]
chip [čı́slo čipu] gain [zisk v e/ADU1 ]
expose [čı́slo čipu] [světlý/tmavý snı́mek] [expozičnı́ čas] zahájı́ na daném čipu
expozici
stopexpo [čı́slo čipu] ukončı́ expozici
binning [čı́slo čipu] [vertikálnı́ binning] [horizontálnı́ binning] změnı́ binning
čipu
readout [čı́slo čipu] zahájı́ vyčı́tanı́ čipu
D connect [čı́slo spojenı́] [host]:[port] [velikost dat] informace o nutnosti navázat
datové spojenı́ na daný port
Přı́kaz skončı́ až po úspěšném navázánı́ spojenı́.
1
velikost dopadnuté energie, potřebné k zvýšenı́ hodnoty pixelu o jedničku
4.5. PŘÍKLAD KOMUNIKACE
37
stopread [čı́slo čipu] ukončı́ vyčı́tánı́ daného čipu
cooltemp [temperature] nastavı́ teplotu chlazenı́ čipu
4.4.6
Montáž
set [RA] [DEC] nastavı́ pozici montáže
move [RA] [DEC] zahájı́ přesun montáže na novou pozici
info vypı́še informace o montáži
type [typ dalekohledu]
serial number [sériové čı́slo montáže]
ra [RA]
hodnota rektascenze montáže dec [DEC] hodnota deklinace montáže
park dec [DEC] parkovacı́ deklinace
longtitude [zeměpisná délka] zeměpisná délka dalkohledu
latitude [zeměpisná šı́řka] zeměpisná šı́řka dalekohledu
siderealtime [čas] mı́stnı́ hvězdný čas v okamžiku pozorovánı́
localtime [čas] občanský čas v mı́stě pozorovánı́
correction mark [čı́slo korekce] čı́slo poslednı́ proběhnuté korekce
park zaparkuje dalekohled
4.5
Přı́klad komunikace
Máme jedno zařı́zenı́, které se jmenuje C0 a je CCD kamerou. K tomuto zařı́zenı́
se připojuje jeden klient, který je chce provádět ostřenı́ kamery. Po svém připojenı́ se pokusı́ zı́skat prioritu, změnı́ teplotu chlazenı́ kamery a provede expozici
následovanou vyčtenı́m zı́skaného snı́mku.
Jméno uživatele je petr, jeho heslo je 123456.
Kamera je umı́stěna na počı́tači se jménem c0, jejı́ server běžı́ na portu 5556.
Datové porty začı́najı́ portem 5557.
V následujı́cı́m přı́kladu značı́ k klienta, S centrálnı́ server a C0 kameru.
Komunikace a je jejı́ směr je značena pomocı́ ¿.
Napřı́klad:
k > S - command 1
38
znamená text ”command 1” poslaný klientem centrálnı́mu serveru.
C0 > S - register C0 3 c0:5556
S > C0 - I status num 1
S > C0 - I status 0 server st 2
Centrálnı́ server sdělil kameře, že má jeden stav, jeho jméno je server st a jeho
hodnota je rovná 1.
S > C0 - +000 Success
k > S - login petr
S > k - +000 Success
k > S - password 123456
S > k - logged as 0
S > k - I status num 1
S > k - I status 0 server st 2
k > S - info
S > k - user 0 petr -1 S > k - device 0 C0 c0:5556 3
Je připojen jeden uživatel - to je naše spojenı́, a jedno zařı́zenı́ - C0.
k > S - key C0
S > k - authorization key 23456
Klient požádal o autorizačnı́ klı́č.
k > C0 - auth 0 23456
C0 > S - authorize 0 23456
S > C0 - authorization ok 0
S > C0 - +000 Success
Server potvrdil pravost klı́če pro klienta.
C0 > k - I status num 3
C0 > k - I status 0 img chip 0
C0 > k - I status 1 trc chip 0
C0 > k - I status 2 priority 0
C0 > k - +000 Success
4.5. PŘÍKLAD KOMUNIKACE
39
Klient byl autorizován, kamera mu sdělila počet, názvy a hodnoty stavů.
k > C0 - ready
k > C0 - info
C0 > k - type ST8
C0 > k - serial 819901486
C0 > k - chips 2
C0 > k - temperature regulation 0
C0 > k - temperature setpoint 1000.0
C0 > k - air temperature 17.39
C0 > k - ccd temperature 13.51
C0 > k - cooling power 0
C0 > k - fan 0
Klient zı́skal informace o kameře.
k > C0 - cooltemp -10
Klient nastavil teplotu chlazenı́.
k > C0 - expose 0 1 120
C0 > k - S img chip 1 exposure chip started
C0 > k - S img chip 4 exposure chip finished
k > C0 - readout 0
C0 > k - D connect 8 C0:5565 3145784
Klient vytvořı́ datové spojenı́ a začne na něm přijı́mat data. Délka dat určených
k přijmutı́ je 3145784 bytů.
C0 > k - S img chip 2 reading chip started
C0 > k - S img chip 0 reading chip finished
Server odeslal poslednı́ data, klient musı́ přečı́st všechna data z datového
spojenı́ a porovnat je s délkou dat, kterou obdržel na začátku spojenı́.
40
4.6
Komunikačnı́ knihovna
Komunikačnı́ knihovna musı́ splňovat následujı́cı́ požadavky:
• umožňovat přenos velkých objemů binárnı́ch dat
• klást malé nároky na systémové prostředky
Systém použı́vá vlastnı́ komunikačnı́ knihovny.
4.6.1
Architektura komunikačnı́ knihovny
Knihovna se skládá z následujı́cı́ch částı́:
devser knihovna pro server
devcli knihovna pro klienty
devdem knihovna pro zařı́zenı́
4.6.2
devser
Sloužı́ pro serverovou stranu spojenı́. Poskytuje funkce nutné pro přečtenı́ přı́kazu
a zpracovánı́ přı́kazu, poslánı́ odpovědi a zakončovacı́ řádky přı́kazu.
4.6.3
devcli
Sloužı́ pro klientskou stranu spojenı́. Poskytuje funkce pro navázánı́ komunikace
se serverem, poslánı́ přı́kazu na server, zpracovánı́ a přečtenı́ odpovědı́ ze serveru.
Zpracovává všechny požadavky a zprávy serveru, poskytuje funkce pro přı́jem dat
a funkce volané při změně stavu.
Udržuje komunikaci s centrálnı́m serverem, zjišt’uje stavy a počet zařı́zenı́.
4.6.4
devdem
Integruje devcli a devdem. Poskytuje podporu pro zařı́zenı́.
4.6.5
Architektura serveru
Pro každé nové spojenı́ je vytvářen a spouštěn nový proces. Pro synchronizaci
procesů a jejich vzájemnou komunikaci jsou použity prostředky IPC.
Pro déletrvajı́cı́ operace je vytvářeno nové vlákno. Vlákna jsou vytvářena
pomocı́ knihovny pthread.
4.7. ZPRACOVÁNÍ SNÍMKU
4.7
41
Zpracovánı́ snı́mku
Pro zpracovánı́ snı́mků je volán shellovský skript. Pokud se na jeho výstupu
vyskytne řádka s údaji o skutečné pozici snı́mku a velikosti chyby, je chyba
poslána na dalekohled.
Snı́mek se po vyčtenı́ řadı́ do zásobnı́ku, z kterého je odebı́rán kódem pro
zpracovánı́ snı́mků. Je zaručeno, že pro klienta poběžı́ pouze jeden proces pro
zpracovánı́ snı́mků.
O detekci hvězd se v systému BART stará program sextractor. Jeho konfiguraci
provedl Martin Jelı́nek.
O srovnánı́ detekovaných hvězd s katalogem se stará balı́k Opera, vyvinutý v
Madridu a upravený Martinem Jelı́nkem.
4.8
Rozhrannı́ zařı́zenı́
Každý typ agenta obsluhujı́cı́ zařı́zenı́ definuje hlavičku s funkcemi, které použı́vá.
Jako ovladač označujeme knihovnu, která funkce z hlavičky implementuje.
Pod model zařı́zenı́ se rozumı́ fyzický druh zařı́zenı́. Modelem zařı́zenı́ je napřı́klad kamera ST-8 od firmy SBIG nebo kamera Apogee 16E od firmy Apogge.
Při vytvářenı́ binárnı́ho kódu agenta pro zařı́zenı́ se slinkuje ovladač s obecným
kódem serveru. Vzniklý kód implementuje komunikačnı́ protokol pro určitý model
zařı́zenı́.
Okomentované rozhrannı́ pro jednotlivá zařı́zenı́ je uvedeno v přı́loze B.
42
Kapitola 5
Uživatelský manuál
5.1
Kompilace
Makefile jsou vytvářeny standartnı́mi balı́ky Automake a Autoconfig (pokud
možno verze rovné nebo vyššı́ než 2.50).
Chceme-li makefile znovu vytvořit, stačı́ v adresáři rts2 zadat přı́kazy aclocal,
autoconf a automake. Tyto dva přı́kazy je bezpodmı́něčně nutné zadat v kódu,
staženém z CVSka.
Po staženı́ zdrojového kódu stačı́ v přı́kazové řádce zadat:
./configure
Konfiguračnı́ skript prověřı́ cı́lový systém. Jeho prováděnı́ se ukončı́ chybovou hláškou popisujı́cı́ chybu v přı́padě, že systém neobsahuje všechny potřebné
knihovny.
Dále je potřeba přeložit binárnı́ kód a nainstalovat vytvořená data. To se děje
pomocı́
make
make install
Pro make install je vhodné mı́t rootovské oprávněnı́.
5.2
Spouštěnı́, zastavovánı́
Pro spuštěnı́ serverů sloužı́ inicializačnı́ skript rts2, uložený v adresáři /etc/init.d.
Konfigurace systému se děje pomocı́ souborů umı́stěných v /etc/rts2.
Servery je možné pouštět i manuálně. Každý server spuštěný s parametrem -h
vypı́še krátkou nápovědu.
Všechny binárnı́ soubory jsou obvykle instalovány do adresáře /usr/local/bin.
Toto umı́stněnı́ lze změnit nastavenı́m argumentu prefix při volánı́ configure
skriptu.
43
44
KAPITOLA 5. UŽIVATELSKÝ MANUÁL
Pro přı́klad lze uvést procesy, které běžı́ u dalekohledu BART:
jméno počı́tače popis
lascaux
rts2-centrald (centrálnı́ server), rts2-planc (dlouhodobé pozorovánı́), rts2-grbc (reakce na gama záblesky), rts2-mon
rts2-camd se jménem C0 (obsluha kamery C0, širokoúhlé
c0
kamery přichycené na dalekohledu, tato kamera sloužı́ pro
zpětnou korekci chyb montáže), rts2-teld se jménem T0
(obsluha dalekohledu T0)
rts2-camd se jménem C1 (obsluha kamery C1, širokoúhlé
c1
kamery pověšené na dalekohledu)
rts2-camd se jménem CNF1 (obsluha kamery CNF1 - kacnf1
mera na hlavnı́m dalekohledu)
5.3
Monitoring
Monitorovacı́ klient zobrazuje stav všech zařı́zenı́ připojených na centrálnı́ server.
Pomocı́ monitorovacı́ho klienta lze zadávat přı́kazy pro prováděnı́ funkcı́ na
zařı́zenı́. Přı́kazy pro centrálnı́ server lze psát přı́mo, přı́kazy pro zařı́zenı́ se pı́šı́ ve
tvaru [jméno zařı́zenı́].[přı́kaz] {parametry}. Jméno zařı́zenı́ lze zjistit z panelu s
informacemi o zařı́zenı́. Text přı́kazu se zobrazuje v hornı́ řádce. Pokud nezadáme
jméno zařı́zenı́, přı́kaz je odeslán na centrálnı́ server.
K dispozici jsou tyto klávesové zkratky:
F2 převede server do stavu off, ekvivalent přı́kazu off
F3 převede server do stavu standby, ekvivalent přı́kazu standby
F4 převede server do stavu on, ekvivalent přı́kazu on
F5 zaktualizuje údaje o všech připojených zařı́zenı́, překreslı́ obrazovku
F10 ukončı́ monitorovacı́ program
Monitorovacı́ klient zobrazuje v pravém dolnı́m rohu aktuálnı́ komunikaci
mezi monitorovacı́m klientem a jednotlivými servery.
5.4
Přı́stup k databázi
Přı́stup k databázi je možný přes webovské rozhranı́. Snı́mky z BARTa jsou takto
dostupné na http://lascaux.asu.cas.cz/bartdb.
5.4. PŘÍSTUP K DATABÁZI
45
Obrázek 5.1: Obrazovka nmonitoru
Obrázek 5.2: Formulář pro přihlášenı́
Pokud chceme v databázi měnit údaje, přı́padně stahovat existujı́cı́ snı́mky, je
potřeba se nejdřı́ve přihlásit. Pro přihlášenı́ je potřeba znát své přihlašovacı́ jméno
a heslo. Přihlášenı́ je možné pomocı́ formuláře 5.2.
Obrázek 5.3 ukazuje, jak vypadá seznam napozorovaných cı́lů.
Po vybránı́ odkazu na konkrétnı́ cı́l se objevı́ formulář 5.4 s rozpisem pořı́zených snı́mků pro konkrétnı́ cı́l pozorovánı́.
Stránka 5.5 pak ukazuje výpis pořı́zených pozorovánı́.
Pokud jsme přihlášeni, je možné pomocı́ zatrhávacı́ch tlačı́tek určovat, které
46
Obrázek 5.3: Stránka s výpisem cı́lů pozorovánı́
snı́mky chceme stáhnout. Přes tlačı́tko download je pak možné zı́skat snı́mky ve
formě tgz balı́ku.
5.4. PŘÍSTUP K DATABÁZI
Obrázek 5.4: Stránka s formulářem pro konkrétnı́ cı́l pozorovánı́
47
48
Obrázek 5.5: Stránka s výpisem pozorovánı́
Obrázek 5.6: Obrazovka s výpisem snı́mků
Kapitola 6
Jiné systémy, srovnánı́
6.1
Změny oproti RTS1
Změny jsou sumarizovány v tabulce 6.1.
Správnost modulárnı́ koncepce byla ověřena ve Španělsku, kde bylo během
zhruba dvou hodin integrováno a odzkoušeno ovládánı́ nové montáže Paramount,
ke které byly poskytnuty nı́zkoúrovňové ovladače.
Systém je poměrně jedinečný integracı́ kamery a dalekohledu tak, že snı́mky
jsou automaticky opatřovány souřadnicemi. Přestože se tato úloha jevı́ jako triviálnı́, značné procento světových dalekohledů nenı́ touto integracı́ vybaveno.
6.2
RTS 1
Zadánı́ pro ročnı́kový projekt je možné nalézt v přiloze.
Současný kód je napsaný v jazyce [Python–2002]. Kód je plně funkčnı́ a
splňuje základnı́ požadavky, které na něj byly v zadánı́ projektu kladeny:
• ovládá dalekohled a kameru
• umı́ přijı́mat zprávy o nových gama záblescı́ch
• v rozumný čas 2 dokáže přerušit právě probı́hajı́cı́ pozorovánı́ a věnovat se
pozorovánı́ s vyššı́ prioritou
• vytvářı́ archiv snı́mků
• umı́ pořizovat automaticky temné snı́mky
2
maximálně do pěti minut, záležı́ na průběhu expozice
49
50
KAPITOLA 6. JINÉ SYSTÉMY, SROVNÁNÍ
RTS1 (ročnı́kový projekt)
RTS2 (diplomová práce)
monolit
modulárnı́
od návrhu vázáno na konkrétnı́ daleko- nenı́ vázáno na konkrétnı́ dalekohled,
hled, změny možné, ale náročné
změny možné a relativně snadné
Python, bash
C, bash, perl, PHP, SQL
kolem 5 tisı́c řádků Pythonu
kolem 13 tisı́c vlastnı́ch řádků zdrojového
kódu v jazyce C1 , celkem s převzatým kódem (ovladače kamer, přı́jem GRB zpráv)
kolem 25 tisı́c C řádků
pouze WWW rozhrannı́
WWW rozhranı́, textový monitoring
textové databáze
(post)relačnı́ databáze - PostgreSQL
bez astrometrie snı́mků
s astrometriı́ snı́mků
bez zpětné vazby přes astrometrii
se zpětnou vazbou přes astrometrii
bez automatického pořizovánı́ flat-fieldu s automatickým pořizovánı́ flat-fieldu
přerušitelný po dokončenı́ operace na ka- přerušitelný v jakýkoliv okamžik
meře (vyčtenı́ snı́mku, dokončenı́ expozice) či přesunu dalekohledu
nejasně definované stavy, neobsahuje standby a off stavy
stavy pro flat-filedy, standbay, off
verzován dodatečně v CVSku
v CVSku verzován od počátku
součástı́ projektu byly v praxi nikdy nepo- systém využı́vá pro tyto úkoly dostupné
užité matlabovské algoritmy pro detekci balı́ky pro zpracovánı́ astronomických
hvězd, planetek a optických protějšků
snı́mků
kolem tisı́ce řádků Matlabovského kódu nespočı́tané množstvı́ zdrojových řádků
pro zpracovánı́ snı́mků
cizı́ch balı́ků pro astrometrii, prohlı́ženı́
snı́mků, zpracovánı́ snı́mků
Tabulka 6.1: Srovnánı́ RTS1 a RTS2
Dále poskytuje dvě užitečné funkce, jejichž nutnost se prokázala při rutinnı́m
pozorovánı́. Nebyly v zadánı́ ročnı́kového projektu, a byly doimplementovány
autorem diplomové práce po obhájenı́ projektu. Jedná se o:
• možnost automaticky zahájit pozorovánı́ při západu Slunce, včetně automatického chlazenı́ kamer
• parkovánı́ dalekohledu po skončenı́ pozorovánı́
Hlavnı́m problémem současného kódu je jeho monoličnost. Program je dělen
do modulů, které mı́vajı́ do 1000 řádek kódu. Toto dělenı́ ale nenı́ domyšleno do
všech detailů, v kódu se vyskytuje několik cyklických závislostı́ mezi moduly.
6.3. ONDŘEJOV - OVLÁDÁNÍ 60CM DALEKOHLEDU
51
Obrázek 6.1: Graf závislostı́ rts-1
Python si s cyklickými závislostmi poradı́ 3 . Jejich výskyt činı́ kód nepřehledným,
změny se v kódu provádějı́ velmi těžko a nenı́ lehké zjistit všechny jejich důsledky.
Současné řešenı́ RTS1 umožňuje pouštět expozici na jiném počı́tači než na
počı́tači řı́dı́cı́m pozorovánı́. Experimentálně ověřená možnost spočı́vá ve vytvořenı́ ssh spojenı́ na počı́tač, ke kterému je připojena kamera. Přes toto spojenı́ se
kamera řı́dı́ 4 , data se ukládajı́ bud’ na lokálnı́ disk, nebo na sdı́lený sı́t’ový disk.
6.3
Ondřejov - ovládánı́ 60cm dalekohledu
Ondřejovský 60cm dalekohled sloužı́ pro pozorovánı́ planetek a proměnných
hvězd.
Montáž dalekohledu je vybavena senzory. Dalekohled má kupuly se štěrbinou,
3
4
před provedenı́m každého importu si překladač ověřı́, že již nebyl importován
kamery se z Pythonovkého kódu ovládajı́ pomocı́ přesměrovánı́ standardnı́ho vstupu a výstupu
52
natáčenı́ kopule a pohyb dalekohledu ovládá počı́tač běžı́cı́ pod operačnı́m systémem MS DOS. Pro každou noc je připraven seznam cı́lů, z kterých je možné
vybı́rat dalšı́ pozorovánı́.
Vyčı́tánı́ kamery běžı́ pod operačnı́m systémem Windows, je ovládáno ručně.
Snı́mky jsou ukládány na pevný disk, který je přı́stupný ze sı́tě.
Zpracovánı́ snı́mků se děje v poloautomatickém režimu. U dalekohledu je
umı́stěn server sloužı́cı́ pro ukládánı́ naměřených světelných křivek.
Pořı́zené snı́mky jsou archivovány na CD-ROM. Lze je dohledat z pozorovacı́ch protokolů.
Nevýhody:
• nenı́ vyřešena integrace dalekohledu a kamer
• nenı́ možné plně automatické pozorovánı́
6.4
BOOTES - Španělsko
Ve Španělsku, pod organizacı́ INTA5 , existuje podobný projekt jako na Ondřejově.
Jedná se také o dalekohledy Meade, kamery SBIG. Ovládánı́ v současné době, po
pětiletém vývoji, běžı́ na heterogennı́ sı́ti s OS Windows a Linux.
Ovládánı́ tvořı́ několik samostatných procesů. Jsou to:
TCM Telescope Control Module - řı́dı́ podle předem generovaného plánu pohyb
dalekohledu. Dalekohledem pohybuje pouze v okamžiku, kdy nedocházı́
k žádné expozici. O expozici je informován do OTM prostřednictvı́m komunikace po TCP/IP soketu. Při přı́chodu zprávy o záblesku okamžitě přesouvá dalekohled na novou pozici, bez ohledu na právě probı́hajı́cı́ expozice.
Napsán v jazyce C, běžı́ na Linuxu.
DCM Dome Control Module - ovládá střechu, kontroluje stav počası́ pomocı́
meteorologické věže, hlásı́ stav střechy a počası́ přes SMS bránu, hlásı́
otvı́ránı́ a zavı́ránı́ střechy TCM. Napsán pod LabView, běžı́ na Windows
98.
OTM Optical Transient Monitor - řı́dı́ snı́mkovánı́. Součástı́ programu jsou funkce
pro automatické pořizovánı́ a zpracovánı́ kalibračnı́ch snı́mků. V současné
době se použı́vá pouze na pořizovánı́ snı́mků (jak kalibračnı́ch, tak obyčejných), jejich dalšı́ zpracovánı́ řı́dı́ linuxovská pipeline. Psán v Borland C++
Builderu s použitı́m knihovny OWL, běžı́ na Windows 98.
5
INTA - Institucion National Technica in Astrofizica
6.4. BOOTES - ŠPANĚLSKO
53
IAM Image Analysis Monitor - pipeline postavená na programech z Opery, umožňujı́cı́ zpracovánı́ snı́mků, jejich astrometrii a fotometrii. V současné době
se použı́vá pouze na astrometrii. Psán kombinacı́ linuxových prostředků
(základ v jazyce C, řı́zenı́ přes Bashovské a Perl skripty).
Obrázek 6.2: Schéma komunikace systému BOOTES
Nevýhody:
• neexistence jednotı́cı́ho protokolu
• dalekohled nemůže kontrolovat kamery, průměrná doba mezi ukončenı́m
přesunu dalekohledu a pořı́zenı́m prvnı́ho snı́mku bude o trochu většı́ než
jedna polovina celkové doby na expozici a vyčtenı́ snı́mku6
• nestabilita Windowsovského vyčı́tače SBIGovských kamer, daná vlastnostmi GUI a poměrně složitým kódem.
• nemožnost vyčı́tat dvě kamery na jednom počı́tači současně, empiricky ověřená - OS Windows nezvládá korektně přidělovánı́ času na CPU a podobné
6
Po přesunu na novou pozici může být kamera v jakémkoliv stavu. V nejlepšı́m přı́padě dokočila
vyčtenı́ CCD čipu a právě se chystá zahájit novou expozici, v nejhoršı́m dokončila expozici, bude
vyčı́tat, poté pořı́dı́ temný snı́mek a teprve poté bude exponovat. Protože kamery exponujı́ v
pevných intervalech, nejhoršı́ přı́pad trvá 2*interval pro pořı́zenı́ jednoho snı́mku
54
pokusy vedou k pádu systému. V současné konfiguraci řešena současnou
expocı́ dvou kamer, a jejich následným postupným vyčı́tánı́m, druhý snı́mek
je velmi zašuměný.
• neřešı́ problémy s ostřenı́m kamer
• neumı́ pořizovat flat-fieldy - časy začátku expozic jsou do OTM vkládány
pomocı́ textového konfiguračnı́ho souboru
6.5
Nightview - Monte Boo, Brno
Program umožňuje ovládánı́ SBIGovských kamer. Použı́vá vlastnı́ protokol pro
jejich ovládánı́ přes Internet, je rozdělen na klientskou a serverovou část. Nekombinuje ovládánı́ dalekohledu, na to je program Telescope control.
Umožňuje v pohodlném GUI řı́dit expozici kamer, umı́ základnı́ zobrazovánı́
snı́mku.
Nevýhody
• s kamerou nenı́ možné komunikovat při posı́lánı́ dat.
• nenı́ řešena integrace dalekohledu s kamerou
• nenı́ řešena automatizace pozorovánı́
Kapitola 7
Závěr
Cı́le diplomové práce, vytyčené v zadánı́, se mně podařilo splnit. K implementaci grafického rozhrannı́ nedošlo, textový klient se ukázal jako lepšı́ řešenı́. K
zobrazovánı́ snı́mků je možné použı́t dostupné zobrazovače, napřı́klad DS9 nebo
SkyCat. Ty rozsahem svých funkcı́ vysoce předčı́ vše, co byl student schopen za
omezený čas vyhrazený pro diplomovou práci naprogramovat.
Začátek doby reakce na gama záblesk, to jest doby potřebné k převzetı́ kontroly
nad zařı́zenı́m, je u montáže podstatně kratšı́ než jedna sekunda, u kamer dosahuje
jedné sekundy.
Systém ztrácı́ méně jak 10% času. Ověřenı́ je možné vidět v databázi, na stránce
statistiky noci, do které se lze nejlépe dostat přes ročnı́ statistiku. Chod systému
je podstatně stabilnějšı́ než byl chod systému RTS1. Po odstraněnı́ problémů s
uvolňovánı́m IPC prostředků a přepsánı́m přı́stupu k databázi do knihovny, která
je reentrantnı́, se nestalo, že by systém během nočnı́ho pozorovánı́ spadl.
Systém ukládá všechny potřebné informace do databáze. Ve srovnánı́ s RTS1,
které ukládalo informace do textových souborů, je práce s databázı́ jednodužšı́.
Systém řı́dı́ v současné době dalekohled BART v Ondřejově. Na léto je naplánované jeho nasazenı́ ve Španělska na dalekohledy spadajı́cı́ pod BOOTES a na
nový ondřejovský 50cm dalekohled. Dalšı́m cı́lem je jeho použitı́ pro připravovaný
infračervený dalekohled BOOTES-IR.
Dı́ky práci jsem byl schopen ověřit si své teoretické znalosti, nabyté při studiu,
v praxi. Pochopil jsem systém automake a autoconfig, prohloubil své znalosti
v několika programovacı́ch jazycı́ch. Netvrdı́m, že jsem si vždy zvolil nejlepšı́
cestu, ze zpětného pohledu je zřejmé, že některé věci jsem mohl vymyslet či
naprogramovat lépe.
Vývoj systému tı́mto neskončil. V dalšı́ verzi by měla umožňovat koordinaci
pozorovánı́ mezi vı́ce dalekohledy a společný přı́stup do databáze snı́mků.
Součástı́ systému je real-time implementacı́ zpětné vazby mezi pořı́zenými
snı́mky a montážı́. Tato zpětná vazba je dost ojedinělá - jediný dalšı́ systém, o
55
56
KAPITOLA 7. ZÁVĚR
kterém je autorovi známo, že tutu zpětnou vazbu použı́vá, je současný systém na
dalekohledu BOOTES. Pro něj byla doprogramována Martinem Jelı́nkem. Systém
na BOOTESu je ovšem značně jednoduššı́, neprovádı́ monitoring objektů v rozsahu, který je prováděn na dalekohledu BART. Pro BART bylo ze zpětnou vazbou
tohoto druhu počı́táno od jeho návrhu.
Je nutné zdůraznit, že k implemetaci podobné zpětné vazby nemohlo do poměrně nedávné doby dojı́t vzhledem k těmto faktorům:
• neexistence nebo nedostupnosti dostatečně rychlých počı́tačů
• neexistenci médiı́ schopných uchovávat a přistupovat k několika GB dat,
potřebných pro uloženı́ celooblohového katalogu
• neexistence systémů s CCD kamerou a širokoúhlým objektivem - velké
dalekohledy, které majı́ zorné pole několik málo stupňů, majı́ montáže dostatečně přesné na to, aby se bez podobné korekce obešly
Systém RTS1 byl prezentován na několika astronomických konferencı́ch, pro
schopnost kontinuálnı́ho pozorovánı́ po několik měsı́ců byl velmi ceněn a byl
jednı́m z mála, ne-li jediným robotickým systémem, který vydržel pozorovat po
dobu dvou let. Nový systém má šanci na podobný výsledek navázat.
Je nutné přiznat, že BART je provozován po takto dlouho dobu i dı́ky těmto
faktorům:
• dostupnosti lidské obsluhy pro řešenı́ přı́padných problémů
• malé finačnı́ náročnosti - až do 1. července 2003 nebyl autor zaměstnancem
ASU AV, dalekohled byl obsluhován studenty astronomie, kteřı́ za svoji činnost pobı́rali minimálnı́ finačnı́ prostředky. Podobný poloamatérský provoz
je u malých dalekohledů běžný.
Přı́loha A
Zadánı́ projektu
Název: Detekce astronomických objektů s proměnnou intenzitou za pomoci robotického teleskopu
1. Účastnı́cı́ projektu
• Vedoucı́: Mgr. Radim Halı́ř, [email protected]
• Konzultanti:
– RNDr. René Hudec, ASU AV ČR Ondřejov, [email protected]
– Dr. Ing. Jan Soldán, ASU AV ČR Ondřejov, [email protected]
– Bc. Lenka Šarounová, ASU AV ČR Ondřejov, [email protected]
• Řešitelé:
–
–
–
–
Tomáš Jı́lek, [email protected]
Petr Kubánek, [email protected]
Filip Krolupper, [email protected]
František Kvapil, [email protected]
• Týmová adresa: [email protected]
2. Vypsánı́ projektu: zimnı́ + letnı́ semestr 1999/2000
3. Zadánı́: Navrhněte a naimplementujte software pro vyhledávánı́ optických
protějšků gama záblesků. Na vstupu je zpráva z mezinárodnı́ho centra sledujı́cı́ pomocı́ družic umı́stěných na oběžné dráze gama záblesky. Na výstupu
z programu je odpověd’, zda se v cı́lové oblasti vyskytuje či nevyskytuje
objekt podezřelý z toho, že by mohl být pozůstatkem gama záblesku a jeho
přı́padné souřadnice a magnituda. K problému patřı́ též evidence napozorovaných dat, přı́stup k nim a dalšı́ ”rozumné” úkoly.
57
58
PŘÍLOHA A. ZADÁNÍ PROJEKTU
4. Základnı́ části projektu
• komunikace s robotickým teleskopem (nastavenı́, sejmutı́ snı́mku, zjištěnı́ stavu, atd.)
• plánovač pozorovánı́ včetně zpracovánı́ mailů z družic detekujı́cı́ch
gama záblesky
• evidence provedených pozorovánı́
• zpracovánı́ snı́mků včetně automatické detekce zajı́mavých objektů
(předzpracovánı́ snı́mků pomocı́ průměrovánı́ a flatfield/darkfield korekcı́, radiometrická a geometrické kalibrace, hledánı́ objektů s proměnnou intenzitou)
• (volitelně) analýza zı́skaných dat: zı́skánı́ souřadnic objektů, astrometrie, fotometrie, ...
5. Požadavky na realizaci
• platforma UNIX se snahou o platformnı́ nezávislost, snaha využı́t dostupné SW prostředky:
– SW pro ovládánı́ teleskopu (od Jan Soldána, komunikace pomocı́
emailu)
– skriptovacı́ jazyky Python resp. Perl (např. pro plánovač)
– numerické systémy Matlab/Ocstave/Scilab (zpracovánı́ snı́mků)
– ”low-level” programovánı́ v C
• dokumentace v systému TeX, pravděpodobně anglicky
• součástı́ projektu bude i řešenı́ relevantnı́ch teoretických problémů.
• přı́padné výsledky by měly být publikovány ve formě odborných
článků.
Přı́loha B
Rozhrannı́ zařı́zenı́
B.1
Kamera
extern int camera_init (char *device_name, int camera_id);
extern void camera_done ();
extern int camera_info (struct camera_info *info);
extern int camera_fan (int fan_state);
extern int camera_expose (int chip, float *exposure, int light);
extern int camera_end_expose (int chip);
extern int camera_binning (int chip_id, int vertical, int horizontal);
extern int camera_readout_line (int chip_id, short start, short length,
void *data);
extern int camera_dump_line (int chip_id);
extern int camera_end_readout (int chip_id);
extern
extern
extern
extern
B.2
int
int
int
int
camera_cool_max (); /* try to max temperature */
camera_cool_hold (); /* hold on that temperature */
camera_cool_shutdown (); /* ramp to ambient */
camera_cool_setpoint (float coolpoint); /* set direct setpoint */
Montáž
extern int telescope_init (const char *device_name, int telescope_id);
59
60
PŘÍLOHA B. ROZHRANNÍ ZAŘÍZENÍ
extern void telescope_done ();
extern int telescope_info (struct telescope_info *info);
extern
extern
extern
extern
int
int
int
int
telescope_move_to (double ra, double dec);
telescope_set_to (double ra, double dec);
telescope_correct (double ra, double dec);
telescope_stop ();
extern int telescope_park ();
extern int telescope_off ();
B.3
Střecha a meteorologická stanice
extern int dome_init (const char *device_name, int dome_id);
extern void dome_done ();
extern int dome_info (int *dome_info);
extern int dome_open ();
extern int dome_close ();
extern int dome_stop ();
extern int dome_move_roof (float ra, float dec);
extern int dome_park_roof ();
extern int dome_stop_roof ();
Přı́loha C
Použité prostředky, převzatý kód
C.1
Vývojové prostředky
Pro psanı́ veškerého kódu jsem použı́val editor vim.
Makefile jsou generovány prostřednictvı́m balı́ků Autoconfig a Automake.
Konfiguračnı́ skript pro autoconfig byl vytvořen ze skriptu generovaného programem autoscan, který je součástı́ autoconfigu.
Všechny programy jsou verzovány v CVS. Verzovánı́ doporučuje kniha
[Trueblood, Genet–1997]. Výhody verzovánı́ se ukázaly při souběžném vývoji
na vı́ce počı́tačı́ch. Kodovánı́ probı́halo na třech počı́tačı́ch v Ondřejově, několika
osobnı́ch počı́tačı́ch v Praze, a na počı́tači ve Španělsku.
Pro generovánı́ webovských stránek jsou použity PHP skripty. Pro jejich správnou funkci je potřeba mı́t naistalovanou verzi PHP vyššı́ než 4.3.
Skripty běžı́ pod HTTP serverem Apache.
Databáze je spravována pomocı́ post-relačnı́ databáze PostgreSQL.
C.2
Použité knihovny
Pro výpočet astronomických souřadnic je použita knihovna [libnova]. V této
knihovně bylo autorem opraveno několik chyb a implementováno několik nových funkcı́. Přesný přehled oprav je možné zı́skat z CVS repository libnovy,
dostupného i přes jejı́ webovské stránky.
Pro zápis a čtenı́ snı́mků do formátu fits je použita knihovna fitsio. Pro práci s
WCS informacemi obsaženými v hlavičkách snı́mku je použita knihovna libwsc.
Pro zobrazovánı́ informacı́ na terminálu je použita knihovan ncurses.
Pro přı́stup na databázi jsou použity knihovny, obsažené v distribuci PostgreSQL.
61
62
PŘÍLOHA C. POUŽITÉ PROSTŘEDKY, PŘEVZATÝ KÓD
C.3
Převzatý a použitý kód, integrovaný přı́mo do
RTS2
Z kódu systému RTS1 byl převzat kód pro řı́zenı́ montáže LX200. Pro RTS1 byl
tento kód autorem přepsaný ze zdrojového kódu pluginu do programu XEphem,
napsaném v jazyce C do jazyka Python. Pro potřeby RTS2 byl autorem znovu
mı́rně upraven a přepsán zpět do jazyka C.
Od magistra Martina Jelı́nka z Ondřejovské observatoře pocházı́ knihovna pro
ovládánı́ CCD kamer firmy SBIG, knihovna pro ovládánı́ montáže Paramount,
portovaná ze zdrojových kódů určených pro OS Windows do kódu přeložitelného na Linuxu. Od Martina Jelı́nka a kolegů ze Španělska pocházı́ též balı́k pro
astronometrii, autor této diplomové práce přispěl malou měrou k jeho stabilitě
opravenı́m chyby v knihovně libwcs.
Od Scotta Barthelmy, Michaela Robbinse (oba pracujı́ v Goddardově středisku
řı́zenı́ vesmı́rných letů NASA) a Jamesa Kuypera (zaměstnance University of
Michigan) pocházı́ klient pro přı́jem GRB žádostı́, autorem této diplomové práce
modifikovaného a začleněného do kódu grbc.
Od zaměstnanců ISDC1 pocházı́ kód klienta pro přı́jem UDP paketů s informacemi o GRB detekovaných družicı́ Integral, který byl též začleněn do kódu
grbc.
C.4
Vlastnı́ kód
Všechen ostatnı́ kód, tedy knihovny pro sı́t’ovou komunikaci, kód plánovače, centrálnı́ho serveru, serverů všech zařı́zenı́, agentů pro zpracovánı́ GRB požadavků,
monitorovacı́ agenty, SQL skripty pro vytvořenı́ a přı́stup do databáze, kód PHP
stránek umožňujı́cı́ přı́stup do databáze, byl navržen a napsán výlučně autorem
této diplomové práce.
1
Integral Science Data Center
Přı́loha D
Časový plán
listopad 2001 začátek hledánı́ tématu diplomové práce
březen 2002 schválenı́ tématu diplomové práce
duben 2002 začátek vývoje komunikačnı́ knihovny, začátek verzovánı́ v CVSku
srpen 2002 centrálnı́ server
listopad 2002 implementace a testy serverů pro kamery a dalekohled, databáze
snı́mků
prosinec 2002 prvnı́ dennı́ pozorovánı́
leden 2003 nmonitor, grbc, prvnı́ celonočnı́ pozorovánı́
únor 2003 odstavenı́ RTS1 z BARTa
duben 2003 dokončovacı́ práce, oprava chyb, dopisovánı́ a kompletace dokumentace, integrace knihovny pro montáž Paramount
červenec 2003 implemetace pro BOOTES1, laděnı́, zavedenı́ pozorovacı́ch cı́lů
srpen 2003 implementace pro BOOTES2, odevzdánı́ diplomové práce
63
64
PŘÍLOHA D. ČASOVÝ PLÁN
Přı́loha E
Databáze
Přesnou strukturu datábaze - zvláště pak datové typy jednotlivých položek - je
možné nalézt v SQL skriptech, sloužı́cı́ch pro vytvořenı́ databáze, které jsou v
adresáři sql.
V následujı́cı́m textu jsou primárnı́ klı́če značeny značkou ?. Indexované pole
jsou pak značeny pomocı́ ∗.
Tabulka epoch
? epoch id
epoch start
epoch end
identifikace epochy
začátek epochy
konec epochy
Tabulka targets
? tar id
type id
tar name
tar ra
tar dec
tar comment
čı́slo cı́le
typ pozorovánı́
jméno cı́le
rektascenze cı́le
deklinace cı́le
komentář
Tabulka types
? type id
type description
čı́slo typu
popis
65
66
PŘÍLOHA E. DATABÁZE
Tabulka observations
∗ tar id
? obs id
∗ obs start
obs duration
čı́slo cı́le
čı́slo pozorovánı́
datum zahájenı́ pozorovánı́
délka trvánı́ pozorovánı́
Tabulka images
? img id
img name
∗ img date
img exposure
img temperature
img filter
astrometry
∗ obs id
camera name
mount name
epoch id
media id
čı́slo snı́mku
jméno snı́mku
datum pořı́zenı́ snı́mku
délka expozice
teplota CCD čipu
použitý filtr
pozice snı́mku
jméno kamery
jméno montáže
čı́slo epochy
médium, na kterém je snı́mek umı́stněn
Tabulka darks, flats
dark name
∗ dark date
dark exposure
dark temperature
camera name
jméno snı́mku
datum pořı́zenı́ snı́mku
délka expozice
teplota CCD čipu
jméno kamery
Tabulka flats obsahuje stejná pole, pouze jejich prefix je flat.
Tabulka cameras
? camera name
camera desc
jméno kamery
popis kamery
67
Tabulka mounts
? mount name
mount long
mount lat
mount alt
mount desc
jméno montáže
zeměpisná délka montáže
zeměpisná šı́řka montáže
nadmořská výška montáže
popis montáže
Tabulka grb
tar id
? grb id
grb seqn
grb date
grb last update
čı́slo GRB
aktálnı́ čı́slo pořadı́ zprávy
datum pozorovánı́ GRB
datum poslednı́ změny stavu GRB
Tabulka ot
tar id
ot imgcount
ot minpause
ot priority
počet snı́mků požadovaných za jednu noc
minimálnı́ rozestup mezi snı́mky
priorita pozorovánı́
Tabulka medias
?med id
med path
med mounted
identifikačnı́ čı́slo média
cesta, na které je médium namontováno
logická hodnota, určujı́cı́, jestli je dané médium namontováno
V databázi je definován uživatelský typ, který sloužı́ pro ukládánı́ informace o
poloze snı́mku. Je odvozen ze struktury, použı́vané v knihovně libwcs. Obsahuje
informace o poloze referenčnı́ho bodu snı́mku, jeho souřadnicı́ch, rozměrech pixelu, rotaci snı́mku a parametry korekčnı́ho polynomu, který sloužı́ pro výpočet
souřadnic ostatnı́ch bodů na snı́mku.
V databázi jsou dále implementovány funkce, sloužı́cı́ jednak k obsluze uživatelského typu pro ukládánı́ souřadnic snı́mku, a jednak k transformacı́m ekliptikálnı́ch souřadnic na horizontálnı́, a výpočet vzdušné hmoty.
68
PŘÍLOHA E. DATABÁZE
Přı́loha F
Konfiguračnı́ soubor
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
This is example config file, created for El Arenosillo
I.N.T.A observatory (BOOTES1)
${Id}
Comments are denoted by # and runs till end of line.
Should be located at $(PREFIX)/etc/rts2.conf, where
$(PREFIX) is standart prefix, which you pass to
./configure script
Values names and values are separated by =
Values which are numbers are handled as numbers,
values which are string are handled in program as string.
So for example if you give name = 123, and rts2 expected, that name
is string, default will be used (you give name as double)
Reasonable defaults are build into code. But don’t complain, if they
doesn’t fits your need.
String values can be given at ””, but escaping (yet) doesn’t work,
so don’t give something like ”\ntest”.
Petr Kubanek, <[email protected]>
###############################################################
# Client information section
# script to call for astrometry processing
astrometry = ”/home/petr/rts2/src/plan/img_process %s 2>/dev/null”
# Which telescope program should control
69
70
PŘÍLOHA F. KONFIGURAČNÍ SOUBOR
telescope_name = ”T0”
# group, which will become owner of images
group = ”images”
# Site coordinates
longtitude = 6.733
latitude = 37.1
###############################################################
# State transition section - when given state stars, ends, ..
# Sun is below horizont, when
# is below that value.
day_horizont = 1
# Night starts, when sun gets
night_horizont = -6.0
# Evening time - time to cool
evening_time = 7600
# Time to cool off cameras in
morning_time = 1800
its calculated altitude
below that value
cameras in seconds
seconds
###############################################################
# GRB - Gamma Ray Burts receiving section
# enables Integral receiving
grbc.iban = ”N”
# enables GCN Bacodine receiving as server
grbc.bacodine = ”N”
# enables GCN Bacodine receiving as client
# (bacofwd needs to run on other computer)
grbc.bacoclient = ”Y”
# bacodine port for server (negotiated with GCN)
bacodine.port = 5152
# bacoclient is tweaked bacoserver to run as client,
# accessing to bacofwd
# bacoclient port address (bacofwd server port)
bacoclient.port = 23
# bacodine hostname (bacofwd server address)
bacoclient.server = ”disc.ua.es”
# bacodine hostname (bacofwd server address)
71
#bacoclient.server = ”lascaux.asu.cas.cz”
# login throught proxy?
bacoclient.proxy = ”Y”
# proxy username
bacoclient.user = ”yyyy”
# proxy password
bacoclient.password = ”xxxx”
# proxy end string
bacoclient.proxy_end = ”Login Accepted”
#################################################################
# planc - scheduler
# see selector.h for details, SELECTOR_AIRMASS is 1,
# SELECTOR_ALTITUDE is 2, SELECTOR_HETE is 3, SELECTOR_GPS is 4
planc_selector = 4
# every n picture will be dark image
dark_frequency = 20
# every n picture will be hete picture (don’t put 0 there)
hete.frequency = 1
# every n picture will be galactic plan scan
gps.frequency = 2
# in seconds, gps will be taken every 3.5 *
#86400 = 3 and half days
gps.interval = 302400
#################################################################
# CAMERA section - informations about cameras
# image flip - almost every lens flip the image
flip = 1
# camera rotang
C0.rotang = 2.45
# camera xplate scale
C0.xplate = 103
# camera yplate scale
C0.yplate = 103
# camera filter name
C0.filter = ”R”
C4-F50.rotang
C4-F50.xplate
C4-F50.yplate
C4-F50.filter
=
=
=
=
179.6
35.8
35.8
”I”
72
PŘÍLOHA F. KONFIGURAČNÍ SOUBOR
Literatura
[Trueblood, Genet–1997] Mark Trueblood, Russell Merle Genet - Telescope Control, Willmann-Bell 1997
[Martinez, Klotz–1996]
Martinez/Klotz - A practical Guide to CCD Astronomy
[Ratledge, David–1998] David Ratledge - The Art and Science of CCD Astronomy, Springer London 1997
[RFC854]
Telnet RFC - http://www.rfc.net/rfc854.html
[RTS1–2000]
Mgr. Radim Halı́ř. Tomáš Jı́lek, Filip Krolupper, Petr
Kubánek, František Kvapil - Detekce astronomických
objektů s proměnnou intenzitou za pomoci robotického
teleskopu, studentský projekt na MFF UK.
[Pokorný–1995]
Zbyněk Pokorný - Skripta pro AK I, Hvězdárna a Planetárium hl. m. Prahy
[GCN]
Gamma Coordinate Network - http://gcn.gsfc.nasa.gov
[Python–2002]
Python home page - http://www.python.org
[ncurses]
Knihovna
nCurses
http://www.gnu.org/software/ncurses
[libnova]
Knihovna libnova - http://libnova.sf.net
[fitsio]
Knihovna FITS IO - Flexible Image Transport System
Input/Output
[libWCS]
World Coordinate System Subroutines - tdcwww.harvard.edu/software/wcstools/libwcs.wcs.html
[PostgreSQL]
PostgreSQL - http://www.postgresql.org
[PHP]
PHP - http://www.php.net
73
-
74
LITERATURA
[Automake]
Automake - http://www.gnu.org/software/automake
[Autoconfig]
Autoconfig - http://www.gnu.org/software/autoconfig
[CVS]
CVS
Concurent
http://www.cvshome.org
[ViM]
ViM - Vi iMproved - http://www.vim.org
[Apache]
Apache - http server - http://httpd.apache.org
Version
System
-
Seznam obrázků
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
Přehled agentů - BART . . . . . . . . . . . . . . . . .
Nový klient žádajı́cı́ o změnu priority . . . . . . . . .
Ukončenı́ exekučnı́ funkce odložené do nového volánı́
Čekánı́ do ukončenı́ aktuálnı́ expozice . . . . . . . . .
Čekánı́ do ukončenı́ aktuálnı́ho bloku . . . . . . . . .
Stavový diagram centrálnı́ho serveru . . . . . . . . . .
Stavový diagram CCD kamery . . . . . . . . . . . . .
Stavový diagram chlazenı́ CCD kamery . . . . . . . .
Stavový diagram montáže . . . . . . . . . . . . . . . .
Stavový diagram střechy, kopule . . . . . . . . . . . .
Diagram závislostı́ databáze . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
13
14
15
16
20
21
22
23
25
28
5.1
5.2
5.3
5.4
5.5
5.6
Obrazovka nmonitoru . . . . . . . . . . . . . . . .
Formulář pro přihlášenı́ . . . . . . . . . . . . . . .
Stránka s výpisem cı́lů pozorovánı́ . . . . . . . . .
Stránka s formulářem pro konkrétnı́ cı́l pozorovánı́
Stránka s výpisem pozorovánı́ . . . . . . . . . . .
Obrazovka s výpisem snı́mků . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
46
47
48
48
6.1
6.2
Graf závislostı́ rts-1 . . . . . . . . . . . . . . . . . . . . . . . . .
Schéma komunikace systému BOOTES . . . . . . . . . . . . . .
51
53
75
.
.
.
.
.
.
.
.
.
.
.
.

Zdokonalenı rıdıcıho softwaru pro dalekohled BART

Transkript

Podobné dokumenty

Kompletní ceník

Kompletní ceník

Praktikum z operacnıch systému˚ Jméno: I. Strucné odpovedi 1

Cesta kolem Orientu