Den aktuellsten funktionierenden Code sowie eine kurze readme findet man hier:
https://www.dropbox.com/sh/jr5v4vd3foqb44i/dzrGwc2V6j

Hallo liebe Forengemeinde,

ich möchte hier mein Projekt zu einem selbst konzipierten und programmierten Altimeter vorstellen. Wie viele andere (vor allem Wasserraketler), war ich lange auf der Suche nach einer Möglichkeit den Fallschirm sauber im Gipfelpunkt auszulösen. Da die meisten elektronischen Bergungssysteme für Raucher gedacht sind (µMad, BearAltimeters, Salt(?)) haben wir Wasserraketler es oft schwer. Pyroladungen können bei uns nur schwer verwendet werden. Deshalb: selber machen!

Das Problem
Wer einen Timer (ob elektronisch oder Federmotor) benutzt, kennt das Problem: nur wenn man vorher die Flugzeit kennt, löst der Fallschirm im richtigen Zeitpunkt aus. Genauer sind Systeme die den Gipfelpunkt durch fortlaufende Messungen erkennen und den Fallschirm dann auswerfen. Die Ansprüche an ein solches System sind hoch. So dürfen zumal keine hohen Verzögerungen zwischen Messung und Messwertverarbeitung auftreten und es müssen Sicherheitsmechanismen geschaffen werden, die eine Fehlerkennung des Gipfelpunktes (false-positive) unterdrücken. Auch darf der Gipfelpunkt nicht 'übersehen' werden (false-negative).

Die Idee
Arduino. Die Arduino-Plattform ist einen Mikrokontrollerfamilie, die sehr einfach zu programmieren ist und viele Bauteile bereits auf den Platinen vorgelötet sind. Der Anschluss an den Computer erfolgt einfach per USB Verbindung, es sind keine besonderen Adapter zur Programmierung des Chips notwendig. Desweiteren sind für Arduinos viele Sensoren verfügbar mit denen man einen Gipfelpunkt erkennen könnte (sogenannte Breakout Boards oder Shields). Die Hersteller dieser Sensoren liefern häufig bereits vorprogrammierte Methoden für ihre Produkte, so muss man das Auslesen der Analogen Sensordaten nicht selbst programmieren. Es ist auch kein Problem, Modellbauservos mit einem Arduino anzusteuern. Billig sind sie zu guter Letzt auch noch.
Alles weitere ist einfach: Mit der Barometrischen Höhenformel lässt sich die Flughöhe über Normalnull einzig und allein mit dem Luftdruck errechnen. Man braucht also keine weiteren Sensoren als einen hochauflösenden Luftducksensor.

Die Vorteile gegenüber anderen Systemen
Dieses System ist deutlich günstiger als ein Altimax oder ähnliches.
Dadurch, dass der Gipfelpunkt messtechnisch erkannt wird, ist es nicht nötig Simulationen vorher durchzuführen um zu wissen wann der Fallschirm bestenfalls ausgelöst werden soll. Dieses System bietet zusätzlich zum korrekten Fallschirmauswurf, auch die Möglichkeit die Flugbahn auf eine SD-Karte zu schreiben.

Die Nachteile
Man muss ein wenig selber Löten, sich die Einzelteile selbst besorge, das Programm aufspielen und vielleicht zwei Variablen im Code ändern.

Was muss das System können?
Ich habe mich im Vorfeld viel belesen und mit George Katz (AirCommandRockets) Rücksprache gehalten, welche Probleme bei solch einem System auftreten können. Wichtig erschienen mir nun folgende Punkte
1) Messfrequenz
Um den Gipfelpunkt schnell erkennen zu können, muss die Luftdruckmessung so oft wie möglich durchgeführt werden. Bestenfalls über 100 mal pro Sekunde.
2) Filterung der Messdaten
Da die Messdaten des Luftdrucksensors stark schwanken können, muss ein mathematischer Weg gefunden werden um die Messdaten zu glätten. Es darf auf keinen Fall vorkommen, dass der Gipfelpunkt auf der Startrampe, oder gar im Steigflug erkannt wird.
3) Erweiterbarkeit
Das gesamte System soll erweiterbar sein, sodass weitere Servomotoren für einen zweiten Fallschirm oder eine Stufentrennung angeschlossen werden können. Es soll auch Platz für andere Sensortypen bleiben, wie zum Beispiel ein Beschleunigungssensor oder ein Magnetfeldsensor. Zusätzliche Sensoren können eine gewisse Redundanz bieten.

Die Bauteile
Nach einiger Recherche habe ich mich für folgende Bauteile entschieden.
Mikrokontroller: Arduino Nano (ca. 10€, ebay)
Luftdrucksensor: BMP 085, 5V Version (ca 2€, ebay)
Servomotor: MC1811 (ca 5€, Conrad)
Lautsprecher: Gefunden in meiner Restekiste "PC Zubehör"
SD Karten Board: (ca 3€, ebay)
SD Karte: hatte ich auch herumliegen. Werde aber eine kleinere besorgen
9V Block: (ca 2€)



Wichtig: Wer dieses Projekt nachbauen möchte muss bei der Beschaffung der Bauteile aufpassen. Da die Arduino Hardware Open-Source ist, gibt es viele Nachbauten der Boards. Diese sind vom Prinzip her auch kompatibel mit allen andern Arduino Bauteilen. Allerdings wird häufig der Bootloader auf diese Boards nicht aufgespielt, sodass die Programmierung der Klone erheblich erschwert wird. Wer sich unsicher über die Zusammenstellung der richtigen Bauteile ist, kann mich gerne kontaktieren.

Die Implementierung
Dank meiner Java-Kenntnisse fiel mir die Programmierung des Arduinos in C nicht schwer. Darüber hinaus gibt es viele vorgefertigte Bibliotheken, die das Programmieren weiter vereinfachen. Das einzige was ich nur noch tun musste, war if-Abfragen und ein paar for-Schleifen richtig einsetzen. Der gesamte Code lässt sich in folgendem Flussbild (englisch) stark vereinfacht zusammenfassen.


Dazu werden durch einfaches Ableiten aus der Höhenänderung die vertikale Geschwindigkeit sowie die Beschleunigung errechnet. All diese Daten werden auf eine SD-Karte geschrieben. Die maximale Flughöhe wird nach der Landung über einen Lautsprecher ausgegeben. Beispiel:
Maximale Höhe ist 152m.
Ausgabe:
Piiiiiep.
Pause.
Piep. Piep. Piep. Piep. Piep.
Pause.
Piiiiiep. Piiiiep.
Lange Pause. Wiederholung.

Was noch in Planung ist
Ich möchte dieses System in Zukunft auch für Stufentrennungen verwenden. Dazu ist es notwendig einen anderen Servomotor bei maximaler Geschwindigkeit (kurz nach Brennschluss) zu betätigen. Hierzu wird aber kaum weiterer Code notwendig sein. Dazu möchte ich noch einen Kalman Filter einbauen. Bei dem Kalman Filter handelt es sich um einen mathematischen Satz, der die physikalischen Grundlagen (Wurfparabel) mit in die Filterung einbezieht und somit die Messwerte verifiziert und vollkommen falsche Werte ignoriert. Dadurch würde auch ein Totalausfall des Sensors nicht zu einem Absturz führen.
Vor kurzem bin ich auf ein Arduino Breakoutboard gestoßen, welches ein 3-Achsen Accelerometer mit einem Gyroskop verbindet. Dieses Breakoutboard könnte erheblich zur Redundanz beitragen, da ein Gyroskop auch in der Schwerelosigkeit stabil bleibt und das Kippen der Rakete im Gipfelpunkt erkennen kann. Der Gipfelpunkt könnte somit durch zwei voneinander unabhängige Messverfahren (Luftdruck und Neigung) erkannt werden. Das Accelerometer kann benutzt werden um den Brennschluss - und somit den Zeitpunkt zur Stufentrennung - zu erkennen.

Geändert von mattgolt am 17. August 2013 um 18:11

Heute: Testen des ersten Prototyps.


Auf einem Steckbrett habe ich den ersten Prototyp zusammengebastelt.


Trotz der Wuselei funktioniert erstmal alles so wie es soll. Ich hab den Höhenmesser in einem kleinen Karton untergebracht und dann die Luft mit einem Staubsauger abgesaugt.

Erste Ergebnisse:


Bei diesem Testlauf wurde der Gipfelpunkt korrekterweise bei 59m erkannt. Leider ist mir heute auch aufgefallen, dass der Arduino nicht genug Strom liefern kann um den/die Servos zu betätigen. Entweder besorge ich schwächere Servos oder ich löte einen entsprechenden Spannungsteiler, mit dem ich den Servo direkt am 9V Block betreiben kann.

Die Schaltung sieht vorerst so aus. (Für den Servo fehlt noch der Spannungsteiler)

Geändert von mattgolt am 17. August 2013 um 17:14

Hi mattgolt,

erstmal schön das sich auch noch andere mit Raketenspezifischen Arduinoprojekten beschäftigen.

Ein paar Sachen zu deinem Code:

1. Messfrequenz:
Wenn ich das richtig wird jedes mal wenn die void loop() von vorne beginnt eine neue Messung gestartet. In der loop hast du viele If-Abfragen ... das bedeutet dass die Laufzeit deiner Schleife nicht konstant ist und somit auch die Höhe nicht mit konstanter Frequenz geloggt wird. Ein zeitdiskretes Signal wird aber üblicherweise zu bestimmten periodischen Zeitpunkten definiert.

2. Aufbau void loop()
Bei jedem durchlaufen der loop werden die einzelnen Events geprüft. Das macht die loop imho nur unötig langsam und ist auch nicht nötig. z.B. Starterkennung: Es reicht wenn man alle 1-5ms überprüft ob ein Start erfolgt ist. In 1-5ms bewegen sich auch sehr stark beschleunigte Raketen nur ein paar cm weiter.
Stichwort zum Aufbau der loop: Finite State Machine / Endlicher Automat

3. Variablen Deklaration
Deine ganzen Zeitvariablen sind als Double deklariert. Fließkommazahlen sind unötig hier da millis() eh nur Ganzzahlen zurückgibt. Unsigned long wäre die richtige wahl für die Zeitvariablen

4. Event- und Gipfelpunkterkennung
Wenn ich nichts übersehen habe wird die so nicht funktionieren. Die Routine erkennt den Gipfelpunkt wenn x mal die derzeitige Höhe unter der letzte Höhe lag. Bedingt durch das Rauschen des Sensors kann es im Aufstieg durchaus vorkommen das die letzte Höhe größer als die derzeitige ist. Im dümmsten Fall wird der Gipfel noch mitten im Aufstieg erkannt.
Deine Routine muss richtigerweise überprüfen ob x-mal !!hintereinander!! die derzeitige Höhe unter der Letzten lag.
Auch die Erkennung der anderen Events wie z.B. Starterkennung erkennen ihr Event wenn nur ein Messwert größer, kleiner oder je nach dem als der letzte Wert ist. Auch hier sollte gefiltert werden.
Ein simpler gleitender Durchschnitt sollte reichen.

5. Kleinigkeiten
-Setz die Zuweisung initalTime = millis() in void setup() ganz ans Ende von setup(). Jetzt stehen dahinter noch einige serial.print und SD-Karten Operationen. Die sind nicht die schnellsten und verschieben dir somit die berechnete Zeit um ihre Ausführungsdauer.
- Um den Brennschluss zu erkennen ist es nicht so gut die Beschleunigung aus den Geschwindigkeitsdaten zu errechnen und nach dem Nulldurchgang zu suchen. Alle Ungenauigkeiten die in den Geschwindigkeitsdaten drin sind werden dadurch nur verstärkt. Such lieber nach der maximalen Geschwindigkeit.
-Deine Methode der nummerischen Differenzierung ist nicht besonders genau. Eine viel bessere Schätzung der Steigung erhält man wenn man die Steigung der Gerade berechnet die durch einen Punkt vor der Messung und einen Punkt nach der Messung geht (und das ohne zusätzlichen Rechenaufwand ). Geschwindigkeitsbasierte Auswertungen hinken zwar um eine Messung hinterher aber bei ausreichend großer Messfrequens sollte das kein Problem sein. Siehe hierzu: Jörn Loviscach - Ableitung von Messreihen schätzen

Das wars was mir auf den ersten Blick am Code aufgefallen ist .

Ein extra Spannungwandler für die Servos wäre sicher nicht schlecht da größere Servos (um die du nicht herumkommst wenn du Stufentrennung damit machen möchtest) schon ordentlich Strom ziehen(vorallem wenn mal einer blockiert). Ein 9V Block ist da schnell mal leer.

Ansonsten echt cooles Projekt und ich bin gespannt wie es weitergeht.
Viele Grüße
Thomas

Geändert von schmidi093 am 18. August 2013 um 15:36

Vielen dank für die sehr hilfreiche Kritik. Ich hab den gesamten Code aufgeräumt und in einzelne Methoden zerlegt. Folgendes hab ich ändern/verbessern können:

Zitat:

---

Original geschrieben von schmidi093
1. Messfrequenz:
Wenn ich das richtig wird jedes mal wenn die void loop() von vorne beginnt eine neue Messung gestartet. In der loop hast du viele If-Abfragen ... das bedeutet dass die Laufzeit deiner Schleife nicht konstant ist und somit auch die Höhe nicht mit konstanter Frequenz geloggt wird. Ein zeitdiskretes Signal wird aber üblicherweise zu bestimmten periodischen Zeitpunkten definiert.

2. Aufbau void loop()
Bei jedem durchlaufen der loop werden die einzelnen Events geprüft. Das macht die loop imho nur unötig langsam und ist auch nicht nötig. z.B. Starterkennung: Es reicht wenn man alle 1-5ms überprüft ob ein Start erfolgt ist. In 1-5ms bewegen sich auch sehr stark beschleunigte Raketen nur ein paar cm weiter.
Stichwort zum Aufbau der loop: Finite State Machine / Endlicher Automat

---

Danke für das Stichwort, ich habe vorher schon nach einer Möglichkeit gesucht, die verschiedenen Methoden zeitgesteuert aufzurufen. Implementiert habe ich jetzt eine FSM die die Messwerte alle 37ms (war bisher das Minimum was ich erreichen konnte) aufruft.

Zitat:

---

Original geschrieben von schmidi093
4. Event- und Gipfelpunkterkennung
Wenn ich nichts übersehen habe wird die so nicht funktionieren. Die Routine erkennt den Gipfelpunkt wenn x mal die derzeitige Höhe unter der letzte Höhe lag. Bedingt durch das Rauschen des Sensors kann es im Aufstieg durchaus vorkommen das die letzte Höhe größer als die derzeitige ist. Im dümmsten Fall wird der Gipfel noch mitten im Aufstieg erkannt.
Deine Routine muss richtigerweise überprüfen ob x-mal !!hintereinander!! die derzeitige Höhe unter der Letzten lag.
Auch die Erkennung der anderen Events wie z.B. Starterkennung erkennen ihr Event wenn nur ein Messwert größer, kleiner oder je nach dem als der letzte Wert ist. Auch hier sollte gefiltert werden.
Ein simpler gleitender Durchschnitt sollte reichen.

---

Das Problem mit dem x-mal !hintereinander! Messen war mir durchaus bewusst. Wenn man es so wie du vorgeschlagen hast implementiert, hätte man aber folgendes Problem. Wenn durch Messungenauigkeiten im Sinkflug die Maximalhöhe nicht x-mal hintereinander unterschritten wird, löst der Fallschirm nie aus. Diese Routine wurde allerdings ersetzt, s.u.

Zitat:

---

Original geschrieben von schmidi093
5. Kleinigkeiten
-Deine Methode der nummerischen Differenzierung ist nicht besonders genau. Eine viel bessere Schätzung der Steigung erhält man wenn man die Steigung der Gerade berechnet die durch einen Punkt vor der Messung und einen Punkt nach der Messung geht (und das ohne zusätzlichen Rechenaufwand ).

---

Die "richtige" nummerische Differenzierung war vorher nicht möglich, da ich keinen konstanten zeitlichen Abstand zwischen den Messwerten hatte. Aber jetzt funktionierts .

Meine Tests haben gezeigt, dass die erste Ableitung (Geschwindigkeit) nun recht gut bestimmt werden kann. Zumindest der Nulldurchgang liegt immer richtig.

Die Methode zur Gipfelpunkterkennung nutzt nun also nichtmehr die Höhenänderung, sondern sucht nach dem Nulldurchgang der Geschwindigkeit. Um Fehlzündungen vorzubeugen wird der Gipfel erst ab einer minimalen Höhe erkannt (derzeitig 2 m für den Testbetrieb, später schätzungsweise 10m).

Allerdings haben meine Tests heute wieder einmal gezeigt, dass ein Staubsauger nicht besonders gut geeignet ist für die Simulation einens Druckabfalls während des Fluges. Der Druckabfall ist so stark, dass Geschwindigkeiten von über 1000m/s gemessen werden. Einen "Gipfelpunkt" bekommt man eher selten, meist ist es ein "Gipfelplateau". Ich beginne jetzt mit dem Zusammenlösten einer Platine, damit ich erste Wurftests mit dem Altimeter durchführen kann.

Den aktualisierte Code findet man unter dem Link aus dem ersten Post. Ein neues Fließdiagram folgt.

Gruß,

Geändert von mattgolt am 20. August 2013 um 13:20

Das schaut schon mal gut aus Matthis.

Im Code vom Boris ist meine Höhenausgabe enthalten. Diese gibt jede beliebige Höhe aus (also auch mehr als 1000 Meter).

Die Gipfelpunkerkennung nur durch feststellen eines Druckanstiegs zu machen ist sehr riskant, es gibt viele Dinge die im Flug zu einem leichten Druckanstieg führen können, ausserdem trifft man so nie genau den Gipfel sondern kommt immer zu spät. Für erste Versuche ist das aber sicher sinnvoll, du solltest aber schon gründlich über die Implementierung nachdenken, z.B. Die Gipfelerkennung erst nach Ablauf bestimmter Flugphasen freischalten.

Wegen Servos kann ich noch sagen, dass man nie weiss welche Servos die Anwender einsetzen, im Extremfall sind das grosse Servos, 1A ziehen die locker, wenn dann so ein Servo unter Spannung 10 Minuten auf der Rampe steht, muss deine Schaltung das auch aushalten, Regler werden dabei ziemlich heiss, das musst Du also vorher checken. Ich habe da früher Prototypen genabt, die schlapp machten und dann durch die Hitze ausfielen, die Rakete fliegt dann im Ernstall ohne Altimeter los.

Sind so Dinge an die man am Anfang des Höhenmesserbauerlebens nicht denkt ;-)

Louis