Beispielprojekt - Ein Komet bedroht die Erde

Alle Themen in diesem Kapitel:

Vorbereitung

In diesem Beispielprojekt wollen wir das Szenarium Ein Komet bedroht die Erde und deren Rettung programmieren.

Bevor die erste Programmzeile geschrieben wird, solltest Du Dir über die Aufteilunge der Objekte in einem vorgegebenen Szenarium Klarheit verschaffen. In werden die Standorte der wichtigsten Objekte - das sind der Komet bei Spielbeginn, die Rakete und der vermutliche Aufschlagpunkt des Kometen (sollte er nicht von seiner Bahn abgedrängt worden sein!) - relativ zu den Abmessungen des Darstellungsfensters festgelegt. Weiterhin sollte jetzt auch der interne Nullpunkt x_i0, y_i0 unseres Koordinatensystems festgelegt werden.
Die hier gezeigte Anordnung ist selbstverständlich willkürlich, aber mit Bedacht gewählt.

Abb. Aufteilung und Planung des Szenariums

Eine ganz wichtige Festlegung betrifft die Starthöhe des Kometen in Relation zu den Fensterabmessungen F_B (Fensterbreite) und F_H (Fensterhöhe). Damit der Spieler sehen kann, ob die Rakete den Kometen trifft, sollte der Schnittpunkt der (als linear angenommenen) Kometenbahn mit der kritischen Höhe h_krit etwa in der Mitte der Szene liegen. Daraus folgt dann die Starthöhe des Kometen:

()

Nunmehr kann, da der Eintrittswinkel des Kometen bekannt ist, aus dieser Angabe die horizontale Entfernung bis zur Einschlagstelle berechnet werden:

()

Der Wert für l_crash ist nicht zwangsläufig identisch mit dem Ort x_crash! Der kann sich nämlich in Abhängigkeit vom gewählten Koordinatenursprung verändern. In unserem Lösungsvorschlag stimmen sie überein!

Nun noch ein paar Überlegungen zur Wahl des Maßstabes. Grundsätzlich können zwei Wege zur Maßstabsberechnung gegangen werden:

Die y-Koordinate wird zugrunde gelegt, dann wird ein Maßstab M_y ermittelt ().
Die x-Koordinate wird zugrunde gelegt, dann wird ein Maßstab M_x ermittelt ().

()

Bei der Berechnung von M_y wird die Starthöhe des Kometen h'_{0_Komet} als Ausgangswert genommen. Alle mit einem Anstrich versehenen Variablen z.B. h' meinen die auf dem Monitor dargestellten und in Pixel gemessenen Werte.

()

Bei der Berechnung von M_x wird dagegen der horizontale Aufschlagpunkt des Kometen x_crash herangezogen.

Vergleichen wir die beiden Ergebnisse, so stellen wir fest, dass die Unterschiede nicht sehr groß sind. Also entscheiden wir uns für M_x als den allgemein gültigen Maßstab M. Das Ergebnis von übernehmen wir gleich in die setup()-Routine unseres Programms, so wird passend für alle Fensterabmessungen automatisch der richtige Maßstab eingestellt.
Allerdings, allen Fensterabmessungen gerecht zu werden funktioniert nicht. Solange das Verhältnis von F_B zu F_H gleich bleibt, haben wir immer das gleiche Bild vor Augen, anderfalls richtet sich das Szenarium immer nach dem für M_x berechneten Maßstabswert. Das kann bedeuten, dass in y-Richtung einiges verrutscht dargestellt wird.

Schauen wir uns zuletzt noch die Abschätzung der Zeitskalierung an (). Gehen wir davon aus, dass der Komet ein schnell fliegendes Objekt ist, dann sollte die perceptive Höchstgeschwindigkeit mit v_perc = 100 px/s angesetzt werden. Unter dieser Voraussetzung zeigt die Abschätzung, dass eine Zeitskalierung nicht erforderlich ist.

()

Bei der Wahl der sichtbaren Größen für den Kometendurchmesser, die Raketenabmessungen oder die der Skyline habe ich mich nicht von den realen Größen leiten lassen, sondern habe je ein festes Verhältnis in Bezug auf die Fensterabmessungen vorgegeben. Damit erscheinen diese Objekte stets in der gleichen Größe und ändern sich bei Fensteränderungen mit.
Für die Bewegungsberechnungen werden natürlich die realen Größen zugrunde gelegt!

Idealisierte Flug-Bewegungen

Die zweite Aufgabe besteht im wesentlichen aus zwei Teilen:

einem admistrativen Teil, der die Steuerung des Spielablaufs durch den Spieler betrifft und
einem Teil, der sich mit den Bewegungsabläufen der Objekte, also des Kometen und der Rakete befasst.

Für den ersten Aufgabenkomplex werden verschiedene Control-Strukturen benötigt, die als TAB's (processing) oder p5_includes (p5.js) zur Verfügung stehen. Der Bewegungskomplex hält sich ganz eng an die Ausführungen im Kapitel Schräger Wurf. Insofern dürfte die Lösung dieser Aufgabe keine Überraschungen bereiten.
Hinsichtlich der Ausgestaltung des Szenariums gibt es aber doch ein paar wichtige Anmerkungen:

Da uns die Raketengleichungen noch nicht zur Verfügung stehen, werden wir die Rakete wie in JULES VERNES Roman Reise zum Mond" mit einer Kanone abfeuern. Somit kann die Flugbahn der Rakete ebenfalls nach den Gesetzen des schrägen Wurfs berechnet werden.
Damit wir den Flug der Rakete wirklich in Gänze beobachten können, verlangsamen wir die Startgeschwindigkeit der Rakete auf v0_Rakete auf 2000 m/s. Das ist ein Bruchteil dessen, was für einen Start ins All benötigt wird!
Trotz der realtiv geringen Startgeschwindigkeit fliegt die Rakete weit über die kritische Höhe h_krit = 30 km hinaus. Deshalb habe ich die Anfangshöhe des Kometen y0_Komet = 5*h_krit in meinem Beispielprogramm gewählt. Beachte die sich aus dieser Umstellung ergebenden Änderungen hinsichtlich des Maßstabes und der Zeitskalierung!

Mit der Angabe α = 20° für den Eintrittswinkel des Kometen in die Szene können wir noch nicht direkt arbeiten, da diese Angabe den mathematischen Anforderungen nicht genügt.

Zunächst ist der Winkel, der in Grad angegeben ist, in das Bogenmaß umzurechnen. Dafür gibt die Funktion radians() (die Funktion degrees() erfüllt die umgekehrte Aufgabe).
Und weiterhin ist die Winkelangabe nicht auf unser Koordinatensystem bezogen, wie aus zu ersehen ist. Den korrekten Winkelbezug stellen wir durch eine geeignete Transformation her, die darin besteht, dass der angegebene Winkel von 20° vom Vollkreis 360° subtrahiert wird. So können nun die mathematisch korrekt orientierten Geschwindigkeitskomponenten des Kometen berechnet werden:

()

Abb. Zur Bestimmung der Geschwindigkeitskomponenten des Kometen

In dieser Entwicklungsstufe wird zunächst nur der Komet - und das unter idealisierten Bedingungen - bewegt. Es gelten die Gesetze des schrägen Wurfs. Infolge der hohen Geschwindigkeit des Kometen wirkt sich die Gravitation der Erde kaum auf die Flugbahn aus. Erst im letzten Moment gibt es eine sichtbare Abweichung von der Geraden. Zwecks Sichtbarmachung ist die Variable debug = true; zu setzen.

Dynamische Maßstabsanpassung

Wenn der Nutzer den Einschlag des Kometen auf der Erdoberfläche beobachten können soll, dann ist der bisherige Ursprung des internen Koordinatensystems eine schlechte Wahl. Besser wäre es, den Koordinatenursprung in den vermuteten Aufprallort zu verlegen (). Damit müssen natürlich alle absoluten Orte, wir Startort des Kometen, Standort der Rakete etc. neu berechnet werden.
Der Wechsel des Koordinatenursprungs erlaubt uns dann auch, eine dynamische Maßstabsanpassung vorzunehmen. Dank der dynamischen Maßstabsanpassung mittels des BEZIER-Pfades ist es dann möglich, den Kometen stets im Blick zu behalten und den Einschlagsort bei größer werdenden Annäherung des Kometen zunehmend besser sehen zu können. Durch Ausprobieren mit verschiedenen Anker- und Kontrollpunkten sollte es möglich sein, den Focus immer so eingestellt zu haben, dass der Komet und der Einschlagort stets im Blickfeld sind, ohne dass der Komet eine scheinbar rückläufige Bewegung ausführt.

Abb. Dynamische Maßstabsanpassung

Zunächst wollen wir uns den Folgen der Umstellung des Koordinatensystems zuwenden. Infolge der vergrößerten Starthöhe des Kometen auf die fünffache kritische Höhe h_krit ergibt sich die horizontale Entfernung bis zum Einschlag zu:

()

dem soll die darzustellende Einschlagsentfernung l'_crash entsprechen:

()

Unter Berücksichtigung des Randabstandes von 5% ergibt sich damit der neue interne Ursprung des Koordinatensystems:

()

Der neue Startort des Kometen liegt nun im negativen Bereich ...

()

... und entsprechend liegt der Raketenstandort dann bei ...

()

... sowie der Kreuzungspunkt des Kometen mit der kritischen Höhe:

()

Nun zu den Maßstäben. Der Anfangsmaßstab M₀ kann von der vorangegangenen Lösung unverändert übernommen werden. Bleibt noch der Zielmaßstab. Der sollte so bemessen sein, dass das finale Fenster sowohl den Kreuzungspunkt als auch den Einschlagort umfasst. Um sicher zu gehen, verwenden wir hier als Basis die doppelte Entfernung von Kreuzungspunkt zum Einschlagort:

()

M₀ und M₁ sind dann die Werte zwischen denen der Maßstabspfad verläuft. Da beide Werte sehr klein sind, ist für die Pfaddarstellung ein sehr großer zoom-Wert erforderlich!

Es bleibt noch zu überlegen, ob die dynamische Maßstabsanpassung für alle Objekte durchgeführt werden sollte. Beispielsweise für die Rakete. Solange keine eigene Maßstabsanpassung für die Rakete programmiert wurde, die die Rakete z.B. mit größer werdender Höhe verkleinert, ist die Übernahme des vom Kometen gesteuerten Maßstab unangebracht, denn dann würde die Rakete entgegen allen Erfahrungen mit zunehmender Höhe größer werden. Also ist es besser, den Raketenmaßstab unverändert bei dem Anfangsmaßstab M₀ zu belassen.

Nach dem Programmstart fliegt der Komet los und, je nach Wahl der Anker- und Kontrollpunkte, wirkt die dynamische Maßstabsanpassung. Bei der Suche nach einem geeigneten Pfad sollte darauf geachtet werden, dass die Bewegung des Kometen während der Maßstabsänderung nicht scheibar rückläufig wirkt. Sind optimale Einstellungen gefunden, können im unter Teil des Fensters die entsprechenden Werte abgelesen werden. Für die nächste Übung notieren wir diese Werte.

Strömungsreibung und ihre Folgen

Zu Beginn dieser Übung haben wir als erstes die gefundenen Werte für einen optimalen Pfad (Anker- und Kontrollpunkte) der dynamischen Maßstabsänderung in der setup()-Funktion übertragen und das Merkmal visible auf false gesetzt. Damit müssen wir uns mit dieser Thematik nicht weiter befassen.

Jetzt geht es darum, den Reibungseinfluss der Strömung beim Eintritt des Kometen in die Atmosphäre zu berücksichtigen. Die theoretischen Grundlagen findest Du im Kapitel "Strömungsreibung" unter Energetische Betrachtungen und im Kapitel "Kosmische Dimensionen" unter Etwas Wärmelehre.

Weiterhin benötigst Du das Rüstzeug für die numerische Lösung von Differentialgleichungen. Für die vorliegende Aufgabe ist die einfachste Lösung, nämlich das EULER-CAUCHY-Verfahren völlig ausreichend. Da die Anwendung dieses Verfahrens keine besonderen Anforderungen stellt, verzichte ich hier auf weitere Erläuterungen (der Programmcode ist hier aussagekräftig genug).

Hingegen soll die Berechnung der Temperaturentwicklung am Kometen etwas ausführlicher behandelt werden. Diese Entwicklung vollzieht sich in drei (eigentlich 4) Phasen:

Der Komet kommt aus den Tiefen des Weltalls, seine Temperatur außerhalb der Atmosphäre beträgt also 3 °K. Beim Eintritt in die Atmosphäre entsteht Reibungswärme, die den Kometen bis an den Schmelzpunkt (273 °K) der Eiskomponente erwärmt.
Am Schmelzpunkt wird die gesamte zugeführte Energie zum Schmelzen des Eises aufgebraucht. Die Temperatur bleibt im wesentlichen konstant. Allerdings verliert der Komet durch das Abschmelzen des Eises an Masse und damit auch an Größe.
Das gesamte Eis ist abgeschmolzen und es bleibt nur der Steinkern übrig. Seine Temperatur nimmt nun wieder infolge der Reibung zu bis das Schmelzen des Gesteins einsetzt (das wäre jetzt der Eintritt in die 4. Phase!).

Laut Aufgabenstellung setzt sich die Masse des Kometen zu λ Anteilen aus Gestein und zu zu 1-λ Anteilen aus Wassereis zusammen:

Andererseits werden die Massen m_Stein bzw. m_Eis durch ihre Dichte und ihr Volumen bestimmt. Daraus folgen dann die anteiligen Volumina V_Stein und V_Eis:

Das Gesamtvolumen des Kometen ist - nehmen wir Kugelform an - durch seinen Durchmesser gegeben:

So folgt schließlich

Diese Aussage kann dazu verwendet werden, die mittlere Dichte des Kometen zu bestimmen:

oder aber die Gesamtmasse des Kometen:

on/off

Über den Zusammenhang zwischen Volumen und Masse des aus Stein und Eis zusammengesetzten Kometen gibt der nebenstehende Geistesblitz Auskunft.

1. Phase
Alle Masseteile des Kometen werden durch die Energiezufuhr erwärmt. Gestein und Wasser haben aber unterschiedliche spezifische Wärmen, so dass die Energieaufwendungen für beide Anteile unterschiedlich groß sind. Wir gehen davon aus, dass sich innerhalb des Kometen eine gleichmäßige Wärme-Verteilung statt findet.

()

2. Phase
Alle Energie wird zum Schmelzen des Wassereises aufgewendet. Eine Erhöhung der Temperatur kann aus diesem Grund nicht erfolgen. Das dabei entstehende Schmelzwasser wird durch die Strömung abgestreift und führt zu einer Massenreduzierung:

()

Die Massereduktion führt natürlich auch zu einer Volumenreduktion, die den Durchmesser des Kometen verringert:

()

3. Phase
Das Wassereises ist völlig aufgeschmolzen. Es bleibt nur die Gesteinskomponente übrig. Nun kann eine weitere Erhöhung der Temperatur wieder erfolgen:

()

Kollisionserkennung Komet - Rakete

Das differenzierte Erkennen einer Kollision von Komet und Rakete setzt voraus, dass die Kontour der Rakete als Polygon vorliegt. Da der Komet in guter Näherung als kugelförmig (d.h. als Kreis in der 2D-Darstellung) angesehen werden darf, kann hier mit Erfolg die Vektorbasierte Verfahren für Polygone eingesetzt werden. Im Tab "Appendix" (processing) bzw. "pProject_otherStuff.js" (p5.js) findest Du die Definition der Raketenkontur entsprechend .

Mit dem Index i werden die fünf Eckpunkte (schwarz) der Rakete durch ihre x- bzw. y-Koordinaten beschrieben. Erinnere Dich: meine Rakete liegt im Urzustand! Daher beginnt die Kontur in der linken unteren Ecke und wird im Uhrzeigersinn fortgesetzt. Beachte, dass der Anfangspunkt zugleich Endpunkt sein muss, um eine geschlossene Kontur zu erzeugen. Deshalb werden 6 Punkte definiert.

Abb. Wahl der Konturpunkte

Zwischen den Eckpunkten befinden sich die Segmente, die ebenfalls numeriert sind (blaue Pfeile). Ich verwende die Funktion findContact() der Klasse touchPolygon im Tab "collision_v2.0" (processing) bzw. im include pCollision_v2.0.js (p5.js). Im Kollisionsfall, der durch die boolsche Variable TOUCH angezeigt wird, wird über die Variable iMin das Segment angegeben, das mit dem Kometen kollidiert ist. Da der Komet stets von links oben kommt, kann eine Kollision nur an den Segmenten 1 und 2 bzw. 3 und 4 stattfinden. Im Kollisionsfall muss also nur getestet werden, ob iMax ≤ 2 oder iMax > 2 ist, um herauszufinden, ob die Rakete den Kometen oder der Komet die Rakete trifft. Im ersten Fall zerstört die Rakete den Kometen und die Gefahr einer Katastrophe ist gebannt. Im zweiten Fall zerstört der Komet die Rakete und das Unheil nimmt seinen Lauf.

Nun ist die Rakete aber in Bewegung. D.h. die Kontur muss, wenn auch nicht sichtbar, den Bewegungen der sichtbaren Rakete folgen. Während der sichtbare Teil durch die Matrix-Befehle einfach in Bewegung zu setzen ist, gilt dies für die Kontur natürlich nicht. Denn die Matrix-Befehle werden im Grafikprozessor des Computers ausgeführt und stehen für mathematische Berechnungen innerhalb des Programms nicht zur Verfügung. Damit ist klar, dass für die Bewegung der Kontur jeder einzelne Kontur-Punkt bewegt werden muss. Da die Kontur-Punkte als Vektoren verfügbar sind, habe ich in Analogie zu den Matrix-Befehlen, Vektor-Befehle geschrieben, die genau die Operationen rotate() = rotatePoint() , translate() = translatePoint() und statt des scale-Befehls multPoint() und divPoint() erfüllen.

Im zweiten Teil der Aufgabe geht es um die Ermittlung der optimalen Startzeit der Rakete. Beim realen Raketenstart gibt es bekanntlich den Countdown, dabei werden die letzten 10 s vor dem Start rückwärts gezählt. So etwas wird hier auch implementiert. Die Grundlage für den Countdown bildet die Zeit des Treffpunktes von Komet und Rakete, genauer Raketenspitze. Daraus kann dann auf den optimalen Startzeitpunkt der Rakete geschlossen werden (siehe nebenstehenden Bücherstapel). Im vorliegenden Fall dürfen wir die Bewegungen beider Objekte nach den Gleichungen des schrägen Wurfs vornehmen, da die Reibungswirkung am Kometen in der Höhe über 30 km kaum eine Rolle spielt und wir die Raketenbewegung noch als reibungsfrei betrachten wollen.

Basis der Zeitberechnung ist die Zeit für die Kometenbewegung t_Komet, die ja gleich der Spieldauer nach Betätigung des Spielstart-Buttons ist. Die Berechnung des Rendezvous von Komet und Rakete erfolgt aus den Bewegungsgleichungen, wobei sich dann die Startzeit der Rakete t_Rakete aus der Differenz von Flugdauer des des Kometen und die der Rakete bis zum Treffen bestimmen lässt.

Zu Testzwecken habe ich im Debugging-Modus den Start der Rakete mit dem Countdown-Zähler direkt verbunden, so können die unterschiedlichen Treffer-Szenarien erprobt werden. Den Debugging-Mode kannst Du gleich in der ersten Programmzeile einstellen, indem die Variable debug = true gesetzt wird.

Achtung! Sowohl die Berechnung des Kollisionsortes als auch des Kollisionszeitpunktes gehen von den realen Größen- und Ortsverhältnissen aus. Damit es zu keiner Abweichung zwischen den realen Größen und den optischen Größen kommt, sollten für den Bereich der Kollision identische Maßstäbe für alle an der Kollision beteiligten Objekte gelten. Andernfalls kommen die Countdown-Zeit und die optische Kollision nicht zur Deckung!

Die Rakete

Diese Übungsaufgabe bietet keine herausragenden Schwierigkeiten. Alle erforderlichen Maßnahmen sind im Kapitel Raketenantrieb beschrieben.
Die bisher benutzten Bewegungsgleichungen des schrägen Wurfs sind durch die des Raketenantriebs zu ersetzen. Infolge dessen kann die bisher verwendete Berechnung des Kollisionszeitpunktes aber nicht mehr benutzt werden, darum sind die Angaben für den Contdown unzutreffend. In der nächsten Übung soll dann für diese Aufgabe ein anderer Lösungsweg beschritten werden.

Countdown

Raketen dieser Größe und mit diesem Gewicht müssen senkrecht starten, das Abheben der Rakete ist nur so sicher gewährleistet. Uns kommt das sehr entgegen, denn die komplizierten Verhältnisse - Raketenantrieb und Strömungsreibung lassen eine analytische Lösung der Differentialgleichung für die Rakete nicht zu. Daher kann das Rendezvous Rakete - Komet auch nicht mit Hilfe der Fixpunktiteration gefunden werden.

Der Vorteil des senkrechten Raketenstarts liegt für uns darin, dass die x_{Rendezvous_Komet}-Koordinate des Rendezvous für den Kometen feststeht, nämlich dort, wo der Startplatz der Rakete ist. Von dieser Tatsache machen die a - c) Gebrauch. Die rechte Seite der b) ist die Gleichung für die gleichförmige Horizontalbewegung beim schrägen Wurf. Durch Umstellen nach der Zeit (c)), erhalten wir die Zeit, die der Komet bis zu diesem Ort benötigt. Warum gleichförmige Bewegung? Das Treffen Rakete Komet findet in großen Höhen statt, so dass die Strömungsreibung für den Kometen unbedeutend ist und seine Bahn in dieser Höhe nicht beeinflusst.

Abb. Flugbahnen von Komet (blau) und Rakete (grün)

(a-c)

Aus der Zeit des Rendezvous kann mit Hilfe der Gleichung des schrägen Wurfs auch die y_{Rendezvous_Komet}-Koordinate, die natürlich gleich der y_{Rendezvous_Rakete}-Koordinate (a und b)) sein muss. So erhalten wir die Höhe, in die die Rakete steigen muss.

(a, b)

Nachdem wir wissen, wann und wie hoch der Komet senkrecht über dem Raketenstartplatz erscheint, müssen wir nur noch berechnen, wie lange die Rakete bis in diese Höhe benötigt, um dann den optimalen Startzeitpunkt zu bestimmen. Da uns keine analytische Lösung für die Differentialgleichung der Rakete zur Verfügung steht, um die Fixpunktiteration anwenden zu können, müssen wir einen anderen Weg für eine numerische Lösung suchen.
Wir verwenden einfach die numerische Lösung für die Raketenbewegung aus dem Lösungsbeispiel Kollisionserkennung Komet-Rakete und vereinfachen diese in Hinblick auf den senkrechten Fall. So können nun alle Einflussgrößen, die die Flugbahn der Rakete beeinflussen, wie Luftdichte, Raktenantrieb und Raketenmasse, berücksichtigt werden. Vorgabe ist die zu erreichende Flughöhe zuzüglich der Höhe der sichtbaren Raketenspitze.
Jetzt stehen alle Zeitwerte zur Verfügung, so dass der Startzeitpunkt, wie im Bücherstapel, Gl. III dargestellt, berechnet werden kann.

Jetzt stehen alle Zeitwerte zur Verfügung, so dass der Startzeitpunkt, wie im Bücherstapel, Gl. III dargestellt, berechnet werden kann.
Der schräge Raketenstart ist noch in Funktion, die Berechnung des optimalen Startzeitpunkts liefert dann aber falsche Ergebnisse!