Avionik ist ein Kofferwort aus dem lateinischen Wort Aves (Vogel) und Elektronik, und bezeichnet zunächst jede elektronische Funktionseinheit eines Flugkörpers. Damit eine Rakete ihre Mission erfüllen kann, zum Beispiel eine Nutzlast in einen definierten Orbit um die Erde zu bringen, muss eine unter bestimmten Bedingungen optimale Bahn verfolgt werden. Mögliche Ziele der Optimierung sind eine Minimierung der Belastung des Flugkörpers, eine wirtschaftliche Nutzung des Treibstoffs und das präzise Erreichen des Orbits. Zur Lösung dieser Aufgabe müssen Messungen, Berechnungen und Steuerbefehle ausgeführt werden, um in Echtzeit die Lage der Rakete zu regeln.
Eine Avionik hat daher Aufgaben, die von der Mission des Flugkörpers abhängen, ganz allgemein gehören dazu Messungen, Regel- und Steueraufgaben und Telemetrie. Ein wesentliches Problem ist die Stabilität des Bordrechners an sich, da ein Ausfall meist mit dem Verlust der Rakete und Daten verbunden ist. Es müssen daher im Design Maßnahmen vorgesehen werden, um Abstürze unwahrscheinlich zu machen, im Notfall einen autonomen und schnellen Reboot zu ermöglichen und durch Redundanz den Ausfall von Subsystemen zu kompensieren.
Um Probleme rechtzeitig erkennen und darauf reagieren zu können führt die Avionik eine interne Diagnostik des Flugkörpers aus, die man in Anspielung auf die Aufgaben in der Hauswirtschaft als Housekeeping bezeichnet. Überwacht werden unter anderem Spannungen, Ströme, Temperaturen und Drücke an ausgewählten Positionen, Widerstände von Pyros, Treibstoffmengen, korrekter Sitz von Steckern und die totale Strahlendosis. Diese Daten werden zyklisch per Telemetrie an die Bodenstation gemeldet um einen Überblick über den Zustand des Flugkörpers zu geben und die Analyse von Fehlfunktionen zu ermöglichen. Besonders während der Startvorbereitungen ist eine kontinuierliche Überprüfung von großer Bedeutung da hier ein Abbruch der Mission noch problemlos möglich ist. Auch während des Flugs ist es erforderlich auf signifkante Fehlfunktionen reagieren zu können um die Durchführung der Mission zu gewährleisten oder einen kontrollierten Abbruch einleiten zu können.
Das Projekt RedQueen soll Schritt für Schritt durch Experimente mit den Raketen der Arguna-Reihe eine Avionik zur Bahn- und Lageregelung aufbauen. Der Name ist eine Anspielung auf die
rote Königin in Lewis Carolls Buch Through the Looking-Glass, and What Alice Found There. Beim Wettlauf mit der roten Königin fragt Alice, warum sie trotz aller Anstrengung stets am selben Ort verharren. Diese erwidert:
“Now, HERE, you see, it takes all the running YOU can do, to keep in the same place.”
Gleichzeitig steht Red als Abkürzung für redundant.
Die geplanten Meilensteine für die Entwicklung der RedQueen sind (vereinfacht):
- Messungen von Zeit und Observablen durchführen (Experimente und Housekeeping)
- Meßdaten permanent speichern (Datenlogger)
- Daten per Funk an die Bodenstation weiterleiten (Telemetrie)
- Datenanalyse zur Modellierung der Trajektorie (Integration der Bewegungsgleichung)
- Ansteuerung von einfachen Aktoren für Bergung und Flugabbruch
- Bidirektionale Verbindung zur Übermittlung von Kommandos (Vollduplex)
- Ansteuerung von Steuertriebwerken
- Lageregelung im Flug
Jede Generation der Avionik umfasst Verbesserungen und zusätzliche Funktionen und baut auf der vorherigen Stufe auf. Der verfolgte Ansatz ist dabei divide et impera, indem für jede definierte Aufgabe ein Hardwaremodul und dedizierte Software entwickelt wird. Sowohl Hard- als auch Software verfolgen den modularen Ansatz, im Falle der Hardware durch physikalisch getrennte Einheiten, in der Software durch objektorientierte Programmierung. Die Module werden über RS-485 zur Avionik vernetzt, um Gewicht zu sparen, eine störsichere Kommunikation zu garantieren und die Wartung zu vereinfachen.
Nach einigen Iterationen wurde entschieden die Module der RedQueen mit dem P8X32A aka Propeller von Parallax zu implementieren, einem robusten Microcontroller mit acht unabhängig arbeitenden Ker
nen. Jeder Kern oder Cog ist identisch aufgebaut, verfügt über zwei Timer und einen Videogenerator, kann auf alle 32 Pins zugreifen und ist über den Hub mit einem gemeinsamen Speicher verbunden, dem Hub RAM. Diesen Hub kann man sich als rotierenden Schalter vorstellen, der wie ein Verteiler im Ottomotor jeden Cog für einen Zyklus mit dem Hub RAM verbindet. Von dieser Metapher leitet sich auch der Name des Chips ab.
Da Interrupts fehlen, es keinen impliziten Stack gibt und darüber hinaus jeder Cog über einen isolierten Programmspeicher von 512 Byte Länge verfügt, ist der Programmablauf deterministisch solange keine äußeren Zustände abgefragt werden. Deterministisch bedeutet hier, dass die Reaktion der Rechenmaschine auf einen Satz von Eingaben vorhersehbar ist, insbesondere wieviel Zeit verstreichen wird. Die Maschine, die den Browser berechnet mit dem diese Seite dem Leser sichtbar gemacht wird, ist nicht deterministisch. Wer das nicht sofort einsieht sollte sich überlegen, warum ein Browser häufig Eingaben des Nutzers scheinbar ignoriert. Für die Reaktion der Avionik in Echtzeit ist deterministisches Verhalten Voraussetzung. Gleichzeitig unterstützt der Propeller implizit das objektorientierte Paradigma, indem jeder aktive Cog einem Objekt entspricht. Diese Eigenschaft beschleunigt die Entwicklung und Fehlersuche mit diesem Chip ungemein.
Der Propeller benötigt nicht viel Peripherie zum Arbeiten, im wesentlichen nur einen EEPROM für sein Programm, einen (optionalen) Quarz, Spannungsregler und Stecker um mit der übrigen Schaltung verbunden zu werden. Der Propeller arbeitet nominal mit 3.3V Betriebsspannung, durch 1k Widerständen können seine Pins direkt mit Logik verbunden werden, die Standard TTL-Pegel verwendet. Das besondere an diesem Microcontroller ist seine Wandlungsfähigkeit, die eine schnelle Anpassung an ein konkretes Problem ermöglicht. Anstatt für bestimmte Aufgaben vom Hersteller vorgegebene Submaschinen mit fester Pinbelegung zu haben, meist serielle Schnittstellen, Timer und ADC/DACs, wird die Funktion der Pins erst durch die Software definiert. Insofern ähnelt der Propeller einem FPGA, ist jedoch erheblich intuitiver in SPIN zu programmieren, einer von Parallax entwickelten Hochsprache, die einen Mix von Basic, C, Python und Pascal darstellt. Es gibt darüber hinaus eine wachsende Liste von weiteren Programmiersprachen, für die bereits Compiler implementiert worden sind.
Diese inhärente Wandlungsfähigkeit des Propellers legt die Entwicklung eines universellen Moduls zur Datenverarbeitung nahe, das durch individuelle Software an die vorliegende Aufgabe angepasst werden kann. Eine Modifizierung des Codes kann durch Reprogrammierung sogar während des laufenden Betriebs erfolgen, da der Propeller seine Software nur einmal während des Bootvorgangs vom EEPROM in den Hub RAM kopiert und anschließend der EEPROM als normale Peripherie per I²C zur Verfügung steht. Dadurch ist es möglich Algorithmen zu entwerfen, die über eine serielle Schnittstelle und ein entsprechendes Protokoll eine Reprogrammierung des EEPROM erlauben, ohne den laufenden Betrieb zu stören. Das ist eine überaus wichtige Eigenschaft für eine Avionik, da Veränderungen in der Hardware beim Zusammenbau des Flugmodells ab einem bestimmten Zeitpunkt nicht oder nur sehr schwer möglich sind. Bei Satelliten ist es sogar üblich im Flugmodell nur relativ einfache Funktionalität zu implementieren und erst im Laufe der Zeit den verbesserten Code per Telemetrie im Flug nachzuladen. Dadurch ist es möglich Veränderungen an der Hardware zu detektieren und wenn möglich zu kompensieren.
Die
erste Version einer für allgemeine Zwecke verwendbaren Datenver-arbeitungseinheit (Data Processing Unit – DPU) wurde ab 2008 mit dem Proto-Board von Parallax entwickelt und 2010 als gedruckte Schaltung implementiert. Die erste Version der DPU besitzt als Verbindung zur Außenwelt zwei 10polige Wannenstecker als universelle 8-Bit Ports (Port A und B), vier- und sechs-polige Western-Stecker jeweils für eine serielle Kamera und ein GPS-Modul oder äquivalente serielle Module, einen Stecker für eine SD Speicherkarte zur permanenten Datenspeicherung, sowie einen Ausgang für Composite zur Ansteuerung eines Monitors über eine SMB Buchse. Die quadratischen Abmessung der Platine von 60x60mm² sind durch die Abmessungen der Raketen der Arguna-Reihe motiviert und ermöglichen einen horizontalen Einbau zus
ammen mit anderen Modulen der gleichen Abmessung als Platinenstapel. Basierend auf den Erfahrungen der Flugkampagnen wurde die DPU und die Erweiterungsmodule für analoge Datenerfassung, GPS und Telemetrie weiterentwickelt. Diese Fortschritte werden wir hier im Blog in einer Reihe von Artikeln genauer präsentieren.