Das Gehirn der Rakete: Mikrocontroller

Wenn wir am Nachthimmel den Schweif einer Rakete sehen, denken wir an Feuer, Schub und Newton. Doch im Herzen dieses feuerspeienden Drachens schlägt ein digitales Herz aus Silizium. Eine Rakete ist heute mehr als nur ein Rohr mit Sprengstoff; sie ist ein fliegender Roboter, der in Sekundenbruchteilen über Leben und Tod der Mission entscheidet. Welcher Computer steckt dahinter? Wie "denkt" eine Rakete?

In der frühen Raumfahrt waren Bordcomputer tonnenschwere Monster. Der "Guidance Computer" der Saturn V war ein Meisterwerk der Fädeltechnik, aber schwächer als jeder moderne Taschenrechner. Heute tragen wir mehr Rechenleistung am Handgelenk, als die Apollo-Missionen zur Verfügung hatten. Doch in der Welt der Modell- und High-Power-Raketen gelten eigene Gesetze. Hier geht es nicht um 4K-Grafik oder neuronale Netze für Chatbots, sondern um etwas viel Elementareres: Zuverlässigkeit in der Hölle.

Stell dir vor, du wirst mit 20G in einen Sessel gepresst, während jemand neben dir einen Presslufthammer betreibt und die Außentemperatur in Sekunden von 30°C auf -40°C fällt. Das ist der Arbeitsalltag eines Flight Computers. In diesem Artikel werfen wir einen tiefen Blick unter die Haube. Wir analysieren die "graue Masse" unserer Raketen: Vom einfachen 8-Bit Arduino, der kaum geradeaus rechnen kann, bis hin zu High-End Flight Computern mit Echtzeit-Betriebssystemen, die auch in Mars-Rovern stecken könnten. Und wir beleuchten die rechtlichen Fesseln, die verhindern, dass diese Technologie in falsche Hände gerät.

Aber Vorsicht: Sobald du verstehst, wie diese Systeme arbeiten, wirst du nie wieder "einfach nur" eine Rakete starten wollen. Du wirst Daten wollen.

01. Typen von Flight Computern: Ein Hardware-Vergleich

In der Hobby-Raketen-Szene (und auch bei den Profis) gibt es nicht "den einen" Chip. Es ist wie bei Autos: Man fährt mit einem Traktor nicht auf die Rennstrecke und mit einem Formel-1-Boliden nicht zum Einkaufen. Je nach Mission, Budget und technischem Können greifen wir zu unterschiedlichen Klassen von Mikrocontrollern.

1. Der Einsteiger: Arduino Nano (ATmega328P)

Der Arduino Nano ist der Volkswagen Käfer der Mikrocontroller. Er läuft seit Ewigkeiten, jeder kennt ihn, und man kann fast alles selbst reparieren. Sein Herz, der ATmega328P Chip, ist ein 8-Bit Mikrocontroller.

• Taktfrequenz: 16 MHz. Das sind 16 Millionen Schritte pro Sekunde. Klingt viel, ist aber im Computer-Vergleich Schneckentempo.
• Speicher: 32 KB Flash für Code, 2 KB RAM für Variablen. Das ist weniger als ein leeres Word-Dokument.
• Warum wir ihn lieben: Er ist robust. Er verträgt 5 Volt (moderne Chips sterben bei über 3.3V). Und der Code ist simpel. Für einfache Datenlogger ("Wie hoch war ich?") reicht er völlig aus.
• Das Limit: Sobald man komplexe Mathematik macht (z.B. Kalman-Filter für Sensor-Fusion), geht er in die Knie. Er hat keine "Floating Point Unit" (FPU). Wenn er `3.14159 * 9.81` rechnen muss, muss er das mühsam in Software simulieren, was tausende Taktzyklen kostet.

2. Der Alleskönner: ESP32

Der ESP32 hat die Szene revolutioniert. Er kostet kaum mehr als ein Arduino, ist aber ein Supercomputer im Vergleich.

• Dual Core: Er hat zwei Prozessorkerne mit 240 MHz. Ein Kern kann sich um die Sensoren kümmern, der andere um den Funk.
• Konnektivität: WLAN und Bluetooth sind eingebaut. Das ist genial für Telemetrie! Stell dir vor, deine Rakete steht auf der Rampe und sendet dir ihren Gesundheitszustand ("Batterie 98%, GPS Fix OK") direkt auf dein Smartphone, ganz ohne Kabel.
• Nachteil: Er ist stromhungriger als der Arduino und der Funk-Teil kann empfindliche Sensoren stören, wenn man das Platinen-Layout nicht sauber designt.

3. Das Biest: Teensy 4.1

Wenn du aktive Stabilisierung willst (also bewegliche Finnen, die die Rakete steuern wie eine Sidewinder), brauchst du den Teensy 4.1.

• Geschwindigkeit: 600 MHz! Er kann übertaktet werden auf über 1 GHz (mit Kühlung). Das ist schneller als die ersten Smartphones.
• FPU: Er hat eine Hardware-Einheit für Kommazahlen (Float/Double). Er berechnet komplexe Flugbahnen, während der Arduino noch versucht, die erste Kommastelle zu finden.
• Einsatz: Joe Barnard von BPS Space nutzt diesen Chip für seine senkrecht landenden Modellraketen. Er ist der Gold-Standard für High-Performance.

02. System-Architektur: Wie alles zusammenhängt

Ein schneller Chip allein macht noch keinen Flight Computer. Er ist wie ein Dirigent ohne Orchester. Damit eine Rakete "smart" wird, muss der Controller mit der Außenwelt kommunizieren. Schauen wir uns die Anatomie eines typischen Flugcomputers an.

Die Sinne der Rakete (Sensoren)

Die meisten modernen Flight Computer nutzen MEMS (Micro-Electro-Mechanical Systems). Das sind winzige Maschinen, die in Silizium geätzt sind. Im Inneren eines Beschleunigungssensors (Accelerometer) sind mikroskopische "Kämme", die sich bei Bewegung verbiegen und so die Kapazität ändern.

• IMU (Inertial Measurement Unit): Die Kombination aus Gyroskop (Winkelgeschwindigkeit) und Accelerometer (Beschleunigung). Das Gyro sagt uns: "Wir kippen nach links". Das Accel sagt: "Wir werden schneller". Profi-Tipp: Das Gyroskop driftet mit der Zeit (Integration Error), das Accelerometer ist empfindlich für Vibrationen. Die Kunst ("Sensor Fusion") liegt darin, beides so zu kombinieren, dass die Fehler sich gegenseitig aufheben.
• Barometer: Misst den Luftdruck. Da der Druck mit der Höhe abnimmt, ist dies unser primärer Höhenmesser. Aber Vorsicht: Wenn die Rakete Überschall fliegt (Mach 1+), entstehen Schockwellen vor den Drucklöchern, die das Barometer verwirren können ("Mach Dip"). Eine plötzliche Druckspitze könnte dem Computer vorgaukeln, er sei schon am Boden, und er feuert den Fallschirm bei 1000 km/h aus. Das Resultat nennt man "Schreddern". Deshalb schalten Profi-Computer bei hohem Speed oft auf reine Trägheitsnavigation um oder nutzen eine "Mach Lockout" Logik.
• GPS: Toll für die Bergung ("Wo ist sie gelandet?"), aber schlecht für die Höhe. Standard-GPS hat eine Aktualisierungsrate von 1-10 Hz (mal pro Sekunde). Eine Rakete legt in einer Zehntelsekunde aber schon mal 30 Meter zurück. Zu langsam für die Fallschirmöffnung! Zudem verliert man bei den hohen G-Kräften oft kurzzeitig den "Lock" zu den Satelliten.

Die Muskeln (Pyro-Kanäle)

Das "Denken" nützt nichts, wenn man nicht handeln kann. Die wichtigste Handlung eines Flight Computers ist die Bergung. Dafür gibt es Pyro-Kanäle.

Das sind im Grunde elektronische Schalter (MOSFETs), die einen hohen Strom durch einen Glühdraht jagen. Dieser Glühdraht steckt in einer kleinen Menge Schwarzpulver oder einem E-Match. BUMM! Der Druck stößt die Nase der Rakete ab und der Fallschirm kommt raus. Ein guter Flight Computer hat mindestens zwei Kanäle: Einen für den kleinen Bremsfallschirm (Drogue) am Gipfelpunkt (Apogäum) und einen für den großen Hauptfallschirm bei ca. 100-300 Metern Höhe ("Dual Deployment").

Das Problem ist die Energie: Ein 9V-Block ist hier völlig nutzlos. Er hat einen hohen Innenwiderstand. Wenn der Pyro zündet und 2-3 Ampere zieht, bricht die Spannung des 9V-Blocks sofort zusammen. Der Prozessor stürzt ab ("Brown-out") und der Pyro zündet vielleicht gar nicht richtig. Deshalb nutzen wir LiPo-Akkus (Lithium-Polymer). Sie können extreme Ströme liefern, sind aber empfindlich gegen Kälte und Tiefentladung.

03. Telemetrie: Der Draht zum Boden

Früher hat man den Computer nach dem Flug ausgelesen. Heute wollen wir Live-Daten. Dafür brauchen wir Funk. Aber welches Protokoll?

• WiFi (2.4 GHz): Wie beim ESP32. Gigantische Datenrate (man könnte Video streamen!), aber miserable Reichweite (ein paar hundert Meter). Gut für Startrampen-Checks, schlecht für den Gipfelsturm.
• 433 MHz (LPD/ISM): Der Klassiker. Sehr hohe Reichweite, durchdringt auch Hindernisse gut. Aber die Datenrate ist gering. Man kann nur ein paar Zahlen pro Sekunde senden.
• LoRa (Long Range): Der neue Standard. LoRa nutzt eine Technik namens "Chirp Spread Spectrum". Das Signal wird über eine Breite Frequenz verschmiert. Dadurch kann man das Signal auch dann noch entschlüsseln, wenn es im Rauschen untergeht (unterhalb des Noise Floor). Mit LoRa schaffen wir mit winzigen Sendeleistungen (25mW) locker 10-20 Kilometer Reichweite. Ideal für Raketen!

04. Software Deep Dive: Wenn der Code Leben rettet

Nun zum Code. Wenn du einen Arduino programmierst für eine blinkende LED, ist ein Fehler egal. Bei einer Rakete bedeutet ein Fehler Gefahr für Leib und Leben.

Das Problem mit "Bare Metal"

Anfänger nutzen oft eine einfache Endlos-Schleife (`loop()`). Das nennt man "Bare Metal".

void loop() {
    Lese_Sensoren();
    Berechne_Hoehe();
    Checke_Fallschirm();
    Sende_Telemetrie();
}
            

Wenn `Sende_Telemetrie()` blockiert (z.B. weil der Funkkanal belegt ist), bleibt das ganze System stehen. Die Rakete merkt nicht, dass sie den Gipfelpunkt erreicht hat. Sie fällt ballistisch zu Boden. Erst wenn der Funk fertig ist, zündet der Fallschirm – bei Mach 0.5 auf dem Weg nach unten. Das zerreißt die Rakete ("Zipper").

Die Lösung: RTOS (Real-Time Operating System)
Profi-Systeme nutzen ein Echtzeit-Betriebssystem (wie FreeRTOS). Hier teilt man den Code in "Tasks" auf, die Prioritäten haben.

- Task 1 (CRITICAL): Lese Sensoren, prüfe Sicherheit. Priorität: HOCH.
- Task 2 (LOGGING): Schreibe Daten auf Flash. Priorität: MITTEL.
- Task 3 (COMMS): Sende Telemetrie. Priorität: NIEDRIG.

Der "Scheduler" des RTOS unterbricht den Funk gnadenlos, wenn der Sensor-Task arbeiten muss. So ist garantiert, dass die Fallschirmauslösung immer pünktlich passiert, egal was der Rest des Systems treibt. Das ist der Unterschied zwischen "Gebastelt" und "Engineering".

05. Rechtliches & Politisches: Die dunkle Seite der Macht

Raketentechnik ist klassische "Dual-Use" Technologie. Derselbe Algorithmus, der eine Forschungsrakete sanft landschaftsschonend birgt, kann auch eine Waffe ins Ziel lenken.

Viele der besten Flight Computer (wie die von Altus Metrum oder BPS Space) kommen aus den USA. Dort gelten die ITAR (International Traffic in Arms Regulations). Das heißt: Ein US-Bürger darf diese Teile besitzen. Aber er darf sie ("Export") nicht an einen Nicht-US-Bürger verkaufen oder auch nur die technischen Baupläne zeigen. Das geht so weit, dass US-Studenten an Unis manchmal nicht mit ausländischen Studenten an bestimmten Projekten arbeiten dürfen.

Für uns in Europa bedeutet das: Wir müssen oft kreativ sein. Wir entwickeln eigene Systeme (wie den "Altos" aus Frankreich) oder nutzen Open-Source-Hardware, die global verfügbar ist. Und genau das ist das Schöne daran: Die Beschränkungen zwingen uns dazu, die Technik wirklich zu verstehen, statt sie nur zu konsumieren. Wer seine eigene Flugsoftware schreibt, lernt mehr über Physik und Informatik als jemand, der eine schwarze Box kauft.

06. Dein Weg zur eigenen Mission Control

Du hast jetzt viel über die Theorie gelesen. Über Chips, Taktraten, Sensor-Fusion, Echtzeit-Systeme und Export-Gesetze. Aber all das ist Schall und Rauch im Vergleich zu dem Moment, wenn dein System zum ersten Mal Daten sendet.

Stell dir vor: Es ist ein kalter Samstagmorgen auf dem Flugfeld. Die Rakete steht auf der Startrampe, 100 Meter entfernt. Du sitzt an deinem Klapptisch, den Laptop offen. Auf dem Bildschirm läuft eine Kurve: Der Luftdruck. Er ist stabil. Du siehst den "Heartbeat" deiner Software.

"Countdown läuft! 5... 4... 3..." – Bei Null drückst du nicht nur den Knopf, du siehst den Start in den Daten, bevor der Schall dich erreicht. Die Beschleunigungskurve schießt nach oben (der "Liftoff Spike"). Dann die Höhenkurve, eine perfekte Parabel. Du siehst das Apogäum live auf dem Schirm: "348 Meter". Der Ausstoßladung zündet (du siehst den Druck-Peak im Gehäuse). Die Rakete driftet am Fallschirm, die Höhe sinkt langsam. Landung.

Dieser Moment ist pure Magie. Es ist der Unterschied zwischen "Spielen" und "Ingenieurwesen". Und du kannst das auch. Du brauchst kein Studium dafür, nur Geduld, einen Lötkolben und den richtigen Guide.

"Vom Basteltisch zur Startrampe – Ihr Abenteuer in die Raumfahrttechnik."
Ideal für Teams aus Eltern und Kindern (ab 10 Jahren), MINT-AGs oder Maker.