Jeder der Markus und Daniel kennt, weiß, dass der Bau der Sternwarte nicht das Ende unseres Universums sein wird. Schon damals haben wir von einem automatischen Dach und einer guten Fernsteuerung unserer Hardware geträumt.
Nun, einen großen Teil dieses Traumes haben wir bereits erfüllt:
{youtube}9FmutisjJ4c{/youtube}
Kaum war unser System auf diesen Stand, steht auch die nächste Idee in den Startlöchern und wartet auf ihre Umsetzung: Die Automatisierung.
Klar. Wenn ich per Klick auf einen Button PHD starten kann, dann kann das doch auch mein PC für mich alleine erledigen? Und wenn ich per Texteingabe "NGC 1058" und einem Klick auf einen Button zu NGC1058 schwenken kann, dann kann das doch auch mein PC für mich alleine erledigen?
Natürlich!
Der Plan
Eine Webseite, in der Aufnahmepläne erstellt werden. Auf dieser Seite sollen Pakete aus Aktionen verfügbar sein. Eine Aktion ist z.B. "PHD Starten". Auf eine Aktion folgt eine Reaktion, zum Beispiel "Prüfe, ob PHD gestartet ist" und damit verbunden eine Folgeaktion. Eine Folgeaktion kann eine Aktion wie z.B. "Guiding Starten" oder ein Status wie z.B. "Abgeschlossen". Das Ganze wird in Paketen verschnürt. Nun lassen sich beispielsweise die Pakete "Teleskop vorbereiten", "Guiding starten" und andere Pakete zu einem großen Paket verbinden. Zum Beispiel "Sternwarte bereitstellen", "Technik Markus vorbereiten" und "Aufnahme Markus starten".
An einer anderen Stelle wird eine Aufnahmeserie (z.B. 10 x 600s ISO 800, 10x 300s ISO 800, ...) und ein Objekt (z.B. NGC 1058) und ein Zeitraum (z.B. 01.10.2015 bis 20.10.2015, jeweils von 01:00 bis 04:00 Uhr) definiert, welche dann zusammen mit einem Paket als "Aufnahmesession" gewählt werden.
Die Sternwarte selber beherbergt einen Server auf denen diese Daten liegen. Wenn dann bestimmte Bedingungen erfüllt sind (Wetter API meldet OK, Allsky-Cam erkennt Sterne, Wettersensor meldet OK, ...) kann dieser Server selbstständig die vorbereiteten Pakete starten und damit das Dach öffnen, die Computer einschalten, Teleskope und Technik einschalten, Software starten und einstellen, Teleskope auf Ziel ausrichten, Plate Solving durchführen, Guiding einrichten, Aufnahme starten und währenddessen das System überwachen und im Fehlerfall oder Wetterumschwung und Ähnliches reagieren und die Sternwarte herunterfahren.
Zwei Komponenten: Hardware und Hardware
Wie funktioniert so eine Automatisierung aber konkret?
Für die Umsetzung gibt es zwei wesentliche Komponenten. Die eine betrachtet die Sternwarte als Ganzes und ist im wesentlichen für die Organisation und Steuerung des Daches und der Stromanschlüsse zuständig. Diese Funktion übernimmt der Sternwarten-Server oder TMW-Server, wie er passend genannt wird.
Die andere Komponente steht im 1:n Verhältnis mit dem TMW-Server und behandelt die Steuerung der Computer. Anders ausgedrückt: Für jedes System in der Sternwarte (Markus PC + Teleskop + ... und Daniels PC + Teleskop + ...) gibt es diese Komponente. Wir nennen diese Komponente wieder passend TMW-Client. Er kommuniziert nicht nur mit dem Server, sondern hält auch Verbindungen mit entsprechender Software wie PHD oder SGPro.
Der TMW-Server und die TMW-Clients sprechen eine vorher definierte Sprache (Protokoll) und arbeiten über HTTP-API-Schnittstellen miteinander. Die Clients übernehmen alle "persönlichen" Aufgaben - also beispielsweise die Steuerung des Teleskopes und der Kamera des jeweiligen Systemes. Der TMW-Server hingegen hält den "Gesamtplan" bereit und überprüft regelmäßig, ob die Clients noch machen, was sie gerade sollen und ob sie überhaupt noch erreichbar sind.
Der Server und die Clients arbeiten dafür eng zusammen und benötigen für jeden erdenklichen Fall eine Fallback-Lösung. An dieser Stelle tauchen auch die meisten Fragezeichen auf. Jeder erfahrene Astrofotograf weiß, an wie vielen Stellen es haken kann und was alles schief gehen kann. Zudem sind wir auf Grund unserer eingesetzten Technik auch an diese Gebunden: Hat EQMod Einschränkungen, haben wir diese Einschränkungen auch. Hat EQMod Macken, haben wir diese auch. Und für jede Einschränkung und jede Macke benötigen wir Lösungen und Fallback-Aktionen.
Die Programmierung des Systems ist erst mal nicht so aufwändig. HTTP-API-Schnittstellen (REST) sind sehr leicht umzusetzen und Software-Komponenten lassen sich meist über ähnliche Schnittstellen bedienen und erhalten ihre Steuerung mittels professioneller Klick-Bots. Die Grundfunktionen sind soweit auch fertig. Hier erwartet uns jetzt "nur noch" die Definition des gemeinsamen Protokolles und die Umsetzung der Reaktionen auf die Aktionen und die damit verbundenen Folgeaktionen. Außerdem stellen wir unser System von BackyardEOS um auf SGPro.
Es bleibt also noch viel zu tun.