[[_TOC_]] # Project Background Model rocket flights can be divided into different flight states [[1](https://code.fbi.h-da.de/hda10343/dla/-/wikis/Altimeter#sources)]:  1. Launch 2. Powered Flight 3. Coasting 4. Recovery In order to detect the different states the altitude of the rocket is commonly used together with acceleration in more advanced products. Altimeter are commonly available but not open for further development: - https://jollylogic.com/products/altimeterthree/ - https://estesrockets.com/product/002246-estes-altimeter/ - https://www.apogeerockets.com/Electronics_Payloads/Altimeters - ... # Project Goal An altimeter is to be designed, build and tested that can detect the maximum flight altitude (apogee) and other flight parameters. The parameters shall be displayed after recovery. The results shall be compared with simulation data [[2](https://code.fbi.h-da.de/hda10343/dla/-/wikis/Altimeter#sources)]. # Requirements 1. fit into 35mm rocket 2. measure altitude 3. measure acceleration 4. detect maximum altitude 5. identify and detect other flight parameters 6. display numerical flight data after landing 7. display graphical flight data after landing # Sources - \[1\] [Development_of_an_Open_Source_model_rocket_simulation-thesis-v20090520.pdf](uploads/7579b3310eab85286d61b2ae37e96c2a/Development_of_an_Open_Source_model_rocket_simulation-thesis-v20090520.pdf) - \[2\] https://openrocket.info # Studentische Ausarbeitung ## 1) Einleitung: Das Altimeter Ein Altimeter, auch Höhenmesser genannt, ist ein Instrument, das zur Messung der Höhe über einem bestimmten Referenzpunkt verwendet wird. Es ist ein unverzichtbares Werkzeug in der Luftfahrt, der Meteorologie, der Geodäsie und anderen wissenschaftlichen Disziplinen. Die Fähigkeit, genaue Höhenmessungen durchzuführen, ist entscheidend für die Navigation, die Wettervorhersage und die wissenschaftliche Forschung. Das Altimeter nutzt verschiedene physikalische Prinzipien, um die Höhe eines Objekts über einem definierten Bezugspunkt zu bestimmen. Je nach Anwendungsbereich und Genauigkeitsanforderungen können unterschiedliche Altimeter-Typen verwendet werden. Die Entwicklung von Altimetern hat im Laufe der Zeit technologische Fortschritte erlebt, von mechanischen Instrumenten bis hin zu elektronischen Sensoren und komplexen Softwarelösungen. Dieser Wiki-Eintrag erläutert die projektbezogene Entwicklung eines Altimeters. Es wird detailliert auf den entwickelten Code, die eingesetzte Hardware sowie die gewonnenen Erkenntnisse und Erfahrungen eingegangen. Von der Entwicklung des Programms bis zur Auswahl der Hardwarekomponenten – es wird der gesamte Entwicklungsprozess beleuchtet und wichtige Lehren aus unserem Projekt geteilt. ## 2) Projektbezug In diesem Projekt wird die maximale Höhe einer Modellrakete erfasst. Hierfür stehen verschiedene Möglichkeiten der Umsetzung zur Verfügung. Der schematischer Verlauf der Flugbahn (Bild 1) einer Modellrakete sieht wie folgt aus:  **Bild 1** 1. Start 2. Angetriebener Flug 3. Gleitflug 4. Ladung Zu erfassende Messgröße ist die Höhe am Apogee. Hierfür wird eine Luftdruckmessung verwendet, mit der die Höhenänderung bestimmt werden kann. Als Markfähiges Referenzmodell, welches diesen Punkt misst wurde ein ESTES Altimeter zugekauft, um unsere Entwicklung zu validieren. ### 2.1 Anforderungen Das selbst entwickelte Altimeter wurde mit einer klaren Zielsetzung entwickelt, um den Anforderungen an eine präzise und umfassende Erfassung von Flugparametern gerecht zu werden. Die Einhaltung dieser Anforderungen war entscheidend, um sicherzustellen, dass unser Altimeter effektiv und zuverlässig arbeitet und wertvolle Daten für das fortlaufenden Projekt liefert. Hier sind die Anforderungen, die wir erfolgreich umgesetzt haben: - [x] 1. **Passform für eine 35mm Rakete:** Unser Altimeter wurde so gestaltet, dass es in den begrenzten Raum einer 35mm-Rakete passt, ohne die Rakete zu wenig wie möglich zu beeinträchtigen. - [x] 2. **Höhenmessung:** Das Altimeter kann die Höhe über dem Startpunkt hinreichend genau erfassen. - [~] 3. **Messung der Beschleunigung:** Nicht umgesetzt, benötigt zusätzlichen Sensor. - [x] 4. **Erkennung der maximalen Höhe:** Das Altimeter erkennt und speichert die maximale erreichte Höhe während des Fluges, was einen wichtigen Indikator für den Flugverlauf darstellt. - [x] 5. **Identifikation und Erfassung weiterer Flugparameter:** Neben der Höhe soll das Altimeter auch andere relevante Flugparameter erkennen und erfassen, die zur umfassenden Analyse des Fluges beitragen. Aktuell ist noch eine Temperaturmessung integriert, weil der verwendete Sensor dies hergibt. Weitere sinnvolle Flugparameter sollten im Rahmen der Sensorfusion integriert werden. - [x] 6. **Numerische Anzeige der Flugdaten nach der Landung:** Nach der Landung kann das Altimeter die erfassten Flugdaten in numerischer Form anzeigen, was eine schnelle und einfache Bewertung des Flugs ermöglicht. - [~] 7. **Grafische Anzeige der Flugdaten nach der Landung:** Nicht umgesetzt. Hierfür sollte eine sinnvolle Displaygröße gewählt werden, um Daten zuverlässig auswerten zu können. Hierbei sollte ein größeres, und somit externes, Display verwendet werden. Dies kann entweder durch nachträgliches auslesen des Sensors oder durch Drahtlose Übertragung nach oder während des Fluges (live) umgesetzt werden. ### 2.2 Herausforderungen Während der Entwicklung entstanden mehrere Herausforderungen: 1. **Die Größe des Sensors:** Der Sensor sollte auch in kurze Raketen passen, was die Länge der Hardware einschränkt. 2. **Druckunterschiede im inneren der Rakete zur Umwelt:** An dem Raketenkörper müssen Druckausgleichslöcher erzeugt werden, damit während des Flugs kein großer Druckunterschied zwischen aktuellen Umgebungsdruck und dem inneren Druck der Rakete entsteht. Genaueres dazu bei „5. Code“ unter „Filter“. 3. **Gewicht:** Der Sensor sollte möglichst wenig Einfluss auf die Flugeigenschaften der Rakete haben. Das Gewicht ist ein wichtiger Parameter damit die Rakete nicht zu sehr an Maximalhöhe verliert. Mehr dazu bei „4. Hardware“ unter „Modelle“. 4. **Modellraketenspezifisches:** Bei der Verwendung von Modellraketen können unerwartete Ereignisse auftreten, welche sich bei Sorgfalt größtenteils, jedoch nicht 100% zuverlässig, verhindern lassen. Mehr dazu bei „6. Lessons Learned“. ## 3) Integration von Modellraketen und Simulation mit OpenRocket zur Altimeter-Validierung Die Entwicklung und Validierung eines Altimeters erfordert einen ganzheitlichen Ansatz, der sowohl praktische Tests als auch präzise Simulationen einschließt. Im Rahmen unseres Projekts haben wir Modellraketen konstruiert und mithilfe des Programms OpenRocket umfangreiche Simulationen durchgeführt, um die Funktionalität und Genauigkeit unseres Altimeters zu überprüfen. ### 3.1 Modellraketen: Praktische Validierung Die Verwendung von Modellraketen bietet eine realitätsnahe Möglichkeit, die Leistung unseres Altimeters unter realen Bedingungen zu testen. Wir haben Modellraketen entworfen und gebaut, die mit unserem Altimeter ausgestattet sind. Durch das Starten und Verfolgen dieser Raketen konnten wir die tatsächlichen Flugdaten sammeln und mit den vom Altimeter erfassten Daten vergleichen. Dies ermöglichte es uns, die Genauigkeit und Zuverlässigkeit unseres Altimeters zu bewerten und mögliche Abweichungen zu identifizieren. ### 3.2 OpenRocket-Simulation: Virtuelle Validierung Die Verwendung von OpenRocket, einer leistungsstarken Simulationssoftware für Modellraketen, erweiterte unsere Validierungsmöglichkeiten. Mit OpenRocket konnten wir detaillierte Modelle unserer Modellraketen erstellen und verschiedene Flugszenarien simulieren. Diese Simulationen ermöglichten es uns, vorab abzuschätzen, wie unser Altimeter in verschiedenen Flugphasen reagieren würde. Wir konnten die erwarteten Flugdaten visualisieren und mit den tatsächlich gemessenen Daten vergleichen, um die Genauigkeit unserer Altimeter-Daten zu überprüfen. ### 3.3 Synergie zwischen Praxis und Simulation Die Kombination von praktischen Modellraketen-Tests und virtuellen Simulationen mit OpenRocket bot uns eine umfassende Methode zur Altimeter-Validierung. Während die Modellraketen-Tests die reale Welt abbildeten und uns direkte Einblicke in die Leistung unseres Altimeters gaben, ermöglichten uns die Simulationen, verschiedene Szenarien zu erkunden und die Erwartungen für den Flugverlauf zu formulieren. Diese Synergie half uns, die Zuverlässigkeit und Genauigkeit unseres Altimeters zu gewährleisten und wertvolle Einblicke in mögliche Verbesserungen zu gewinnen. Die Integration von Modellraketen und OpenRocket-Simulationen in unsere Altimeter-Entwicklung unterstreicht die Bedeutung einer ganzheitlichen und umfassenden Validierung. Dieser Ansatz stellt sicher, dass unser Altimeter nicht nur unter idealen Bedingungen, sondern auch in realistischen Flugszenarien zuverlässig funktioniert und präzise Daten liefert. ## 4) Hardware Die Hardware wurde aus einem bereits zur Verfügung gestellten Repertoire ausgewählt. Zu Beginn und im Laufe des Projekts stellten sich folgende Anforderungen an die Hardware: **Festanforderungen:** (Müssen genau so eingehalten werden) 1. Sensor fest am Hardwareaufbau verlötet 2. Befestigungsmöglichkeit an der Rakete ohne weitere Hilfmittel 3. Akku innerhalb des Aufbaus, um Sturzschäden an den Li-ion Zellen zu vermeiden 4. Modulare Bauweise **Mindestanforderungen** (Dürfen in positive Richtung verbessert werden) 1. Kompakte Bauweise damit auch in kurzen Raketen verwendbar 2. Resetbutton darf nicht aus versehen betätigt werden **Wunschanforderungen** (Müssen nicht erfüllt sein) 1. Akustische Ortbarkeit 2. Ein/Ausschalter ### 4.1 Sensoren und Entwicklungsboard Für den Altimeter wurden ein BMP 388 (+/- 50cm) und ein BMP 390 (+/- 25cm) von Bosch ausgewählt. Diese Messen den absoluten Luftdruck und leiten daraus die Höhe ab. Zudem können sie noch die Temperatur messen. Der Sensor kommuniziert über die I²C Schnittstelle mit dem verwendeten Entwicklungsboard „LILYGO T-Display V1.1“, welcher als Logik eine ESP32 hinterlegt hat. Als Spannungsquelle(Akku) dient ein EEMB LP401730, welcher eine Kapazität von 150mAh und 3,7V aufweist. **Aufstellung:** - [x] ESP32: LILYGO T-Display V1.1 (8,02g) - [x] Adafruit BMP 388 (1,80g) - [x] Adafruit BMP 390 (1,84g) - [x] EEMB LI-ION LP401730-PCM-LD / 3.7V 150mAH (3,78g) ### 4.2 Hardwareaufbau: Performance- und Komfortmodell Für den Hardwarezusammenbau wurde eine Lochrasterplatine verwendet, um alle Bauteile miteinander zu verbinden.  **Bild 2** Bild 2 zeigt den ersten Finalen Hardwareaufbau. Dieser besteht aus einer doppelt beschichteten Lochrasterplatine, an welcher der Sensor BMP 388 fest verlötet wurde. Der Akku ist mit Heißkleber auf der Innenseite der Platine verklebt. Zudem wurde im späteren Verlauf ein Ein/Aus Schalter hinzugefügt, was die Anwendung im Feld erleichtert und ein Beeper eingebaut, welcher zur einfacheren Auffindung dient, wenn die Rakete in hohem Gras oder Feld landet. Durch den Beeper und Ein/Aus Schalter ist die Verwendung sehr komfortabel, daher erhielt es den Namen KomfortModell. Jedoch wurde der Aufbau mit 14,35 gramm insgesamt sehr schwer (mit Entwicklungsboard 22,28 gramm). Um dem entgegen zu wirken entwickelte sich eine zweite Baugleiche Version heraus, die jedoch auf alles Unnötige verzichtet. Es erhielt den Namen PerformanceModell (Bild 3).  **Bild 3** Das PerformanceModell verwendet den performanteren BMP 390. Es verzichtet auf einen Schalter und einen Beeper. Zudem wird eine einseitig beschichtete Lochrasterplatine verwendet. Diese Änderungen verringern das Gewicht um 37% auf 9,11 gramm (mit Entwicklungsboard 17,81 gramm). ## 5) Software Zur Veranschaulichung der implementierten Software wird hier auf die verwendete State Machine und die Filter Einstellungen eingegangen. Für eine detailliertere Beschreibung des Codes siehe Codedokumentation in Gitlab. ### 5.1 State Machine Die State Machine, auch als Zustandsautomat bekannt, ist ein vielseitiges Konzept der Informatik, das in vielen Gebieten Anwendung findet. Ihr Erfolg beruht auf der Fähigkeit, den Zustand eines Systems klar zu definieren und die Übergänge zwischen den Zuständen präzise zu kontrollieren. In der Entwicklung unseres Altimeters spielte das Konzept der State Machine, eine zentrale Rolle. Dieses Konzept ermöglichte es uns, das Verhalten unseres Altimeters in verschiedene Zustände aufzuteilen und die Übergänge zwischen diesen Zuständen zu definieren. **Altimeter State Machine** Unser Ziel ist es, ein Altimeter zu schaffen, das in der Lage ist, präzise Flugdaten zu sammeln und anzuzeigen. Für diesen Anwendungsfall haben wir eine State Machine implementiert, welche durch drei Zustände beschrieben werden kann. Bild 4 stellt grafisch die implementierte State Machine dar:  **Bild 4** Die umgesetzten Zustände sind “Initialization”, “Measure” und “Stop_Measure”. Mit den Events “ev_Button_Pressed” und “ev_Falling” werden die Übergänge zwischen den Zustand realisiert. Das Altimeter startet in dem Zustand “Initialization”, in diesem wird zunächst die Verbindung zu dem Sensor getestet, der Erfolg bzw. der Fehlschlag dieses Tests wird auf dem Display angezeigt. Anschließend werden 30 Messungen durchgeführt, welche als Referenzwerte auf dem Display ausgegeben werden. In diesem Zustand wartet das Programm bis der Benutzer einen der beiden Knöpfe auf dem Entwicklungsboard betätigt. Drückt der Nutzer einen Knopf wird das Event “ev_Button_Pressed” und somit ein Übergang in den Zustand “Measure” ausgelöst. Bei einem Eintritt in diesen Zustand wird die Messung zunächst genullt und anschließend beginnt der Messvorgang, in welchem die maximale Höhe und die maximale Temperatur gemessen und auf dem Display ausgegeben wird. Einerseits kann in diesem Zustand erneut das Event “ev_Button_Pressed” ausgelöst werden, indem der Benutzer einen Knopf betätigt, wodurch die Messung neugestartet wird. Andererseits kann durch das Abfallen des Sensors von 10 Metern unter der maximal gemessenen Höhe das Event “ev_Falling” eintreten, durch dieses Event wird ein Übergang in den Zustand “Stop_Measure” durchgeführt welcher die Messung stoppt. Ist ein Beeper an das Altimeter angeschlossen wird in diesem Zustand der Beeper aktiviert. Durch einen Knopfdruck wird ein Übergang zurück in den Zustand “Measure” bewirkt. ### 5.2 Filter und Methoden Um hinreichend genaue Messdaten zu erhalten ist es notwendig Filter und Methoden der Signalverarbeitung zu verwenden, welche auf die entsprechende Anwendung bzw. Messung abgestimmt sind. Für das entwickelte Altimeter haben wir folgende Methoden verwendet: **1. Überabtastung (Oversampling):** Unter einer Überabtastung versteht man, dass das Signal mit einer höheren Abtastfrequenz erfasst, wird als das Nyquist-Kriterium erfordert. Durch diese Überabtastung werden zusätzliche Abtastwerte generiert, welche zu einer Verbesserung der Signalqualität, Reduzierung von Rauschen und zur Erhöhung der Auflösung beitragen kann. Eine erhöhte Überabtastung führt jedoch auch zu einem höheren Speicherbedarf und erfordert mehr Ressourcen **Auswahl:** Für unser Altimeter haben wir uns für eine **8-fache Überabtastung des Drucks** entschieden, da auf diesem Messwert die Höhenmessung basiert. Die Temperatur wird nicht Überabgetastet, da diese nur eine zusätzliche Messgröße darstellt. **2. Ausgaberate (Output rate):** Die Ausgaberate gibt an mit welcher Geschwindigkeit die Daten aus dem Sensor ausgegeben werden. **Auswahl:** Da unser Anwendungsfall, die Messung der maximalen Höhe einer Modellrakete, eine schnelle Aktualisierung der Höhe erfordert, haben wir uns für eine Ausgaberate von **100 Hz** entschieden. **3. IIR-Filter (Infinite Impulse Response):** Der IIR-Filter ist ein Digitalfilter, der zur Signalverarbeitung verwendet wird. Der IIR-Filter verwendet eine gewisse Anzahl von vorherigen Eingangs- und Ausgangswerten, um den aktuellen Ausgangswert zu berechnen, dadurch entsteht eine Rückkopplung, die zu einer unendlichen Impulsantwort führt. Durch dieses rekursive Verhalten können plötzliche starke Änderungen der Messwerte herausgefiltert werden. Mit der entsprechenden Wahl des Filter-Koeffizienten kann die gewünschte Dämpfung eingestellt werden. Wird der Filter-Koeffizient falsch gewählt kann dies zu einer Instabilität oder einer sehr langsamen Verarbeitung der Messwerte führen. **Sprungantwort mit verschiedenen Filter-Koeffizienten:**  **Bild 5** **Formel IIR-Filter:**  **Bild 6** Quelle: Datasheet BMP390 von www.bosch-sensortec.com **Auswahl:** Da es in unserer Anwendung, wie in “2.2 Herausforderungen” eingeleitet, zu einem starken Druckunterschied zwischen dem Innenraum der Rakete und dem tatsächlichem Umgebungsdruck kam, haben wir einen relativ großen Messfehler festgestellt. Dieser entstand durch die plötzliche starke Änderung des gemessenen Drucks bei Ausstoß der Spitze und damit auch des Altimeters. Um diesen Fehler auszugleichen, wurden einerseits Druckausgleichslöcher in den Rumpf der Rakete gebohrt und andererseits der Filter-Koeffizient so eingestellt (**Koeffizient = 15**), dass die Abweichung der Messung durch den Ausstoß auf lediglich 3 Meter beschränkt wurde. ## 6) Lessons Learned: Vermeidbare Fehler und Anwendungstipps Was alles schief gehen kann (vermutlich auch mehr) sieht man in der Abschlusspräsentation unter _VII. How not to rocket_. Es wird auf jeden dieser Fehlschläge eingegangen, was sie verursacht hat und wie man sie hätte verhindern können. **1. Aledabran im Baum:** Dies war der aller erste Raketenstart. Die Entfernungen zu Bäumen und Waldrändern sollte bewusster abgeschätzt werden und nicht nach "das passt schon". **Es bietet sich an über die in Google Maps angegeben Skala eine erste Abschätzung zu erhalten**. Zudem muss ein nicht unbeachtlicher Zusatzabstand hinzugefügt werden, wenn es windig ist. Die Aldebaran würde nicht im Baum hängen, wenn nicht die Windböe auf halber Landung aufgekommen währe. **2. Uri im Boden:** Dies ist öfter vorgekommen. Die Spitze wurde nicht ausgestoßen und somit wurde kein Fallschirm ausgelöst. Durch den Schwerpunkt der Rakete fliegt diese im Steilflug mit der Spitze voraus in den Boden. **Es ist darauf zu achten, dass die Spitze nach dem reinstecken wieder einfach mit der Hand rausziehbar ist.** Oft Verklemmen die Seile der Fallschirme zwischen Spitze und Raketenkörper, was zu einer Pressverbindung führt. Zudem sollte der Bereich der Spitze, der in die Rakete gesteckt wird nicht lackiert werden. Wir haben bei späteren Modelraketen die Spitze immer in diesem Bereich etwas angeschliffen um den Radius zu verringern, Man kann diesen auch leicht durch Hitzeeinwirkung schrumpfen lassen. **3. Onion ohne Pufferwatte:** Wird die Pufferwatte vergessen, so greift die thermische Energie der Ausstoßladung die inneren Bauteile an. Dies betrifft nicht nur den Fallschirm sondern auch die Schnüre. Die Onion ist die einzige Rakete bei der das Gummiseil bei den letzten Testflügen häufiger abriss. Wir führten **Sichtprüfungen der Schnürre** (Fallschirm und Gummiseil) ein, diese waren aber nicht immer zuverlässig. Falls die Watte vergessen wird und die **Schnürre** mitgenommen aussehen, sollten sie **vorsorglich ausgetauscht werden**. Ansonsten kann es passieren, dass die Spitze aufgrund fehlender Gewichtskraft des Raketenkörpers mit dem Sensor weit abgleitet, was die Gefahr eines Verfangens in Baumkronen erhöht. **4. Uri Fallschirm abgerissen:** Die genauen Ursachen hierfür wurden nie ganz klar. Vermutlich ist es ein Zusammenspiel von ungünstig eingestecktem Fallschirm und darauf drückenden Sensor. **5. Onion angebrannt:** **Die Watte soll möglichst aus einem Stück bestehen, damit diese ganzheitlich ausgestoßen wird.** Es kann sonst dazu kommen, das Wattestücke zurück bleiben und diese anfangen den Raketenkörper anzuglimmen. **Dies kann auch passieren wenn zu viel oder zu wenig Watte verwendet wird!** Wir würden von der Verwendung der Watte abraten und **zu einem Labyrinthsystem übergehen**, welches auch bei größeren Modellraketen auffindbar ist. Wir hätten um einiges mehr Raketen verloren, hätten wir nicht öfter die Watte nach der Landung mit einem Stab rausgedrückt. **6. Randale 2 Absturz:** Gleiche Ursache wie _"2. Uri im Boden"_ **7. Uri abgestürzt:** Bei ungünstigen Umständen kann es dazu kommen, dass der Fallschirm nicht korrekt auslöst, und sich verdreht. Hier sollte darauf geachtet werden, denn **Fallschirm immer! vor jedem Start frei zu drehen** (die Schnürre sollen nicht ineinander hängen). **8. Randale 3 abgebrannt:** Gleiche Ursache wie bei _"5. Onion angebrannt"_. Hierbei wurde ein C Motor verwendet, was eine längere Landezeit zur Folge hat. Dies führte dazu, dass die glimmende Watte mehr Zeit hatte den Raketenkörper anzugreifen und in mit samt der Kevlarschnurr durchgebrannt. **9. Motorblock ausgebrannt:** Dieser Vorfall ist nicht in der Präsentation, jedoch kann es passieren, dass der Motorblock ausbrennt und rausfällt. Die passierte bei der Randale zwei mal und der Onion gegen Ende auch. **Vermutlich ist dies Alterung, kann jedoch auch bei zu frequentierter Startperiode passieren, da die Pape dann nicht abkühlt.** Man kann diesen **reparieren**, indem man einen langen Besenstiel nimmt, doppelseitiges Klebeband und ein Stück in der Größe des Motorblocks aus einem Raketenmotor rausschneidet und dann mit dem Besenstiel in die Rakete schiebt. Wir verwendeten bei der Reparatur 2-Komponenten-Kleber. Ggf. biete es sich an diesen von Anfang an zu verwenden. Hier haben wir jedoch keine Erfahrungswerte.