... | ... | @@ -17,13 +17,13 @@ Ideally a team of 3 students shall work on this project. |
|
|
|
|
|
A standard 35 mm model rocket shall be used in test flights and simulation: [List of available rockets](https://www.raketenmodellbau-klima.de/Raketenmodellbau/Raketenbausaetze/Quick-Easy.htm?shop=raketenklima&SessionId=&a=catalog&t=23&c=65&p=65)
|
|
|
|
|
|
{width=492 height=369}
|
|
|
{width="492" height="369"}
|
|
|
|
|
|
## Flight phases
|
|
|
|
|
|
Model rocket flights can be divided into different flight states \[[1](https://code.fbi.h-da.de/hda10343/dla/-/wikis/Altimeter#sources)\]:
|
|
|
|
|
|
{width=417 height=374}
|
|
|
{width="417" height="374"}
|
|
|
|
|
|
1. Launch
|
|
|
2. Powered Flight
|
... | ... | @@ -34,43 +34,112 @@ Model rocket flights can be divided into different flight states \[[1](https://c |
|
|
|
|
|
Model rockets are propelled by rocket motors. The achievable flight altitude strongly depends on the thrust characteristics of the rocket motor.
|
|
|
|
|
|
{width=487 height=365}
|
|
|
{width="487" height="365"}
|
|
|
|
|
|
The rocket motors that are commercially available are standardized and have predefined thrust characteristics over time.
|
|
|
|
|
|
{width=444 height=317}
|
|
|
{width="444" height="317"}
|
|
|
|
|
|
{width=701 height=258}
|
|
|
{width="701" height="258"}
|
|
|
|
|
|
## Motor Test Stand
|
|
|
|
|
|
In order to verify the motor characteristics and choose the correct motors for a project, a motor test stand shall be designed to measure these characteristics and other data associated with a model rocket motor. The test stand shall be able to test standard size motors (18 mm diameter) but also larger motors in the future. It shall be able to measure thrust and ejection forces over time. The motor shall be electrically started and the data shall be recorded with an adequate measurement rate.
|
|
|
|
|
|
{width=580 height=260}
|
|
|
{width="580" height="260"}
|
|
|
|
|
|
## Simulation
|
|
|
|
|
|
The simulation of the rocket flight shall be done with [OpenRocket](https://openrocket.info):
|
|
|
|
|
|
{width=600 height=323} 
|
|
|
{width="600" height="323"} 
|
|
|
|
|
|
## Altimeter
|
|
|
|
|
|
The sensor platform that was developed in [previous projects](2023%20Altimeter%20WLAN) shall be used for in-flight data recording. It shall be modified if necessary (hardware and software).
|
|
|
|
|
|
{width=352 height=252} {width=380 height=249}
|
|
|
{width="352" height="252"} {width="380" height="249"}
|
|
|
|
|
|
# Report (authors: @stcomosc, @istpankwa, @stronjin)
|
|
|
|
|
|
## Einführung
|
|
|
|
|
|
Insgesamt sind im Rahmen dieses Projekts Messsungen an folgenden Motoren der Firma Klima durchgeführt worden:
|
|
|
- B4-4: 11 Messungen
|
|
|
- C6-5: 12 Messungen
|
|
|
- D9-7: 2 Messungen
|
|
|
Insgesamt sind im Rahmen dieses Projekts Messsungen an folgenden Motoren der Firma Klima durchgeführt worden:
|
|
|
|
|
|
- B4-4: 11 Messungen
|
|
|
- C6-5: 12 Messungen
|
|
|
- D9-7: 2 Messungen
|
|
|
|
|
|
## Anleitung (author: @stcomosc)
|
|
|
|
|
|
### Webapp
|
|
|
|
|
|
{width=777 height=303}
|
|
|
|
|
|
**Nullen**
|
|
|
|
|
|
Nach ungefähr zehn Sekunden ist der Moving Average Filter in der Webapp mit Werten gefüllt und man kann auf "TARE" klicken. Der aktuelle Filterwert wird unten in das Feld "offset" übernommen und kann mit "set values" an die Steuerung übertragen werden. Dieser Wert bleibt bis zum nächsten Hochfahren des Microcontroller bestehen.
|
|
|
|
|
|
**Kalibrieren**
|
|
|
|
|
|
Der Standardwert des Kalibrierfaktors ist speizifisch für unsere Kombination aus Messverstärker und Wägezelle. Wenn jedoch eine andere Kombination benutzt wird, muss ein neuer Faktor bestimmt werden:
|
|
|
|
|
|
1. Auflegen des ersten bekannten Gewichts
|
|
|
2. Eintragen des bekannten Gewichts in gramm im ersten Feld ("weight 1 \[g\]")
|
|
|
3. 10 Sekunden warten
|
|
|
4. Auf den "set" Button neben dem Feld klicken
|
|
|
5. Für ein zweites Gewicht die Schritte 1. bis 4. entsprechend wiederholen
|
|
|
6. Der nun angezeigte Wert unter den beiden Feldern kann in das Feld "factor \[raw to N\]" eingetragen werden
|
|
|
7. Mit "set values" wird der Wert an die Steuerung übertragen
|
|
|
|
|
|
Für eine spätere Verwendung des Wertes bietet es sich an diesen zu notieren
|
|
|
|
|
|
{width=146 height=303}
|
|
|
|
|
|
**Parameter einer Messung einstellen**
|
|
|
|
|
|
Im ersten Feld wird der Dateinam eingtragen
|
|
|
|
|
|
Das erste Drop-Down-Menü beinhaltet eine Auswahl an Motoren und eine letzte Option "other", wenn der Motor auf dem Prüfstand nicht aufgelistet ist.
|
|
|
|
|
|
Im darunter liegenden Auswahlfeld wird die Richtung, in der der Motor feuert ausgewählt. Da unser Prüfstand hauptsächlich zur Seite feuert, ist das auch der Standardwert.
|
|
|
|
|
|
Falls einem nach mehr prosa zu Mute ist, kann man untersten Feld einen Kommentar schreiben. Hauptsächlich ist es für den Fall gedacht, wenn keines der aufgelisteten Motortypen auf den im Prüfstand Eingespannten zutrifft.
|
|
|
|
|
|
"reset values" setzt alle Felder auf die Werte der Steuerung zurück
|
|
|
|
|
|
"save" überträgt die eingetragenen Werte auf die Steuerung
|
|
|
|
|
|
**Starten/Stoppen von Messungen**
|
|
|
|
|
|
**Daten auf der SD-Karte**
|
|
|
|
|
|
**Info-Panel**
|
|
|
|
|
|
{width=111 height=232}
|
|
|
|
|
|
### Messungen
|
|
|
|
|
|
Vor jeder Messreihe:
|
|
|
|
|
|
1. Prüfstand möglichst eben auf feuerfestem Untergrund platzieren
|
|
|
2. In Schubrichtung und Gegenrichtung darf sich kein brennbares Material befinden
|
|
|
3. Gegen Verrutschen und Umkippen sichern
|
|
|
4. Wägezelle kalibrieren und nullen
|
|
|
|
|
|
Ablauf einer Messung:
|
|
|
|
|
|
1. Motor in Spannvorrichtung befestigen
|
|
|
2. In Schubrichtung prüfen, ob er sicher eingespannt ist
|
|
|
3. Einzigartigen Dateinamen in Webapp vergeben und Motor-Typ eintragen
|
|
|
4. "Save" clicken
|
|
|
5. Zündschnur vorbereiten
|
|
|
6. Umgebung prüfen
|
|
|
7. Messung starten
|
|
|
8. Anzünden
|
|
|
9. Nach ausbrennen: Messung stoppen
|
|
|
10. Motor vorsichtig (kann heiß sein!) aus Spannvorrrichtung entfernen
|
|
|
|
|
|
## Meilensteine
|
|
|
|
|
|
- %"Proof of Concept":
|
... | ... | @@ -229,28 +298,28 @@ Aus den definierten Anforderungen und dem angestrebten Design der Software ergab |
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
Im Proof of Concept wurde die Software so weit entwickelt, dass man Messdaten auf einer SD-Karte speichern kann und es wurde die Kommunikation zwischen einem Client und dem Prüfstand über WLAN realisiert. So war es möglich, dass man zum Einen die aktuellen rohen Messdaten auf einer rudimentären Version der Webapp sehen und zum Anderen eine Messung starten und stoppen konnte. Nachteil war, dass nur eine Messung abgespeichert werden konnte und das Format nur den jeweiligen Zeitstempel und die rohen Messdaten beinhaletete.
|
|
|
Zur Indikation über den Zustand des Prüfstandes wurde die eingebaute (grüne) LED benutzt, welche über ihr Blinkintervall zwei Zustände signalisiert:
|
|
|
Im Proof of Concept wurde die Software so weit entwickelt, dass man Messdaten auf einer SD-Karte speichern kann und es wurde die Kommunikation zwischen einem Client und dem Prüfstand über WLAN realisiert. So war es möglich, dass man zum Einen die aktuellen rohen Messdaten auf einer rudimentären Version der Webapp sehen und zum Anderen eine Messung starten und stoppen konnte. Nachteil war, dass nur eine Messung abgespeichert werden konnte und das Format nur den jeweiligen Zeitstempel und die rohen Messdaten beinhaletete.\
|
|
|
Zur Indikation über den Zustand des Prüfstandes wurde die eingebaute (grüne) LED benutzt, welche über ihr Blinkintervall zwei Zustände signalisiert:
|
|
|
|
|
|
- 0,5s: Normalzustand
|
|
|
- 0,2s (schnelles Blinken): laufende Messung
|
|
|
|
|
|
Die blinkende LED ist auch ein guter Indikator für einen pünktlichen zeitlichen Ablauf des Programms.
|
|
|
Als Entwicklungsstand für das Proof of Concept kann das Issue #59 sowie der commit dbe07a6c herangezogen werden.
|
|
|
Die blinkende LED ist auch ein guter Indikator für einen pünktlichen zeitlichen Ablauf des Programms.\
|
|
|
Als Entwicklungsstand für das Proof of Concept kann das Issue #59 sowie der commit dbe07a6c herangezogen werden.
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
Ziel mit dem Prototypen Prüfstand war es, dass man Messdaten effizient aufnehmen kann. Aus diesem Grund stand vor allem die Webapp im Vordergrund der weiteren Entwicklung und die der Firmware ordnet sich dem unter. Entsprechend wurde die API auf dem ESP32 wurde so angepasst, dass sie den Anforderungen in der laufenden Entwicklung gerecht wird. Hier hat sich die Entscheidung, dass die Webapp auch unabhängig (also lokal auf einem Rechner) laufen kann, als sehr nützlich erwiesen. So musste eine neue Version der Webapp nicht jedes mal neu auf den ESP32 geladen werden, sondern konnte bequem erst nach abgeschlossener Entwicklung auf den ESP32 geladen werden.
|
|
|
Die Anforderung, dass man Teile des Prüfstands auch nur über Buttons und das eingebaute Display steuern kann, wurde nicht umgesetzt. Grund hierfür war, dass die Webapp so gut funktionierte, dass die Bedienung über die Webapp als ausreichend angesehen wurde. Zusätzlich hat die Ansteuerung des Displays nicht so zuverlässig über die getesteten Bibliotheken funktioniert und hat den Prozessor so belastet, dass die Messungen und andere Aufgaben nicht mehr ordnungsgemäß durchgeführt werden.
|
|
|
Ziel mit dem Prototypen Prüfstand war es, dass man Messdaten effizient aufnehmen kann. Aus diesem Grund stand vor allem die Webapp im Vordergrund der weiteren Entwicklung und die der Firmware ordnet sich dem unter. Entsprechend wurde die API auf dem ESP32 wurde so angepasst, dass sie den Anforderungen in der laufenden Entwicklung gerecht wird. Hier hat sich die Entscheidung, dass die Webapp auch unabhängig (also lokal auf einem Rechner) laufen kann, als sehr nützlich erwiesen. So musste eine neue Version der Webapp nicht jedes mal neu auf den ESP32 geladen werden, sondern konnte bequem erst nach abgeschlossener Entwicklung auf den ESP32 geladen werden.\
|
|
|
Die Anforderung, dass man Teile des Prüfstands auch nur über Buttons und das eingebaute Display steuern kann, wurde nicht umgesetzt. Grund hierfür war, dass die Webapp so gut funktionierte, dass die Bedienung über die Webapp als ausreichend angesehen wurde. Zusätzlich hat die Ansteuerung des Displays nicht so zuverlässig über die getesteten Bibliotheken funktioniert und hat den Prozessor so belastet, dass die Messungen und andere Aufgaben nicht mehr ordnungsgemäß durchgeführt werden.\
|
|
|
Eine weitere nicht umgesetzte Anforderung war die Möglichkeit, verschiedene Experiment-Abläufe einfach erstellen zu können. Hierfür war die Zeit zu knapp und die Anforderung wurde als nicht so wichtig angesehen.
|
|
|
|
|
|
Nach einem ersten Probaluf mit vier Motoren ist direkt aufgefalllen, dass man einen zusätzlichen Scritt in der Webapp einfügen sollte, bevor eine Messung gestartet wird. Uns ist es nämlich passiert, dass eine Messung unbeabsichtigt gestartet wurde, was die vorherige Messung überschrieben hat. Diesen Stand der Software kann man in commit 87d5b97e nachvollziehen.
|
|
|
Bei unserer nächsten Messreihe, welche auch die größte war, wurde diese Änderung umgesetzt und hat sich als sehr nützlich erwiesen.
|
|
|
Das Design der Software in Kombination mit dem des Prüfstands hat es uns ermöglicht einen sehr effizienten Ablauf der Messreihe zu realisieren. So konnten wir rund 20 Motoren in nur einer Stunde vermessen.
|
|
|
|
|
|
### Launch Day 2024
|
|
|
Nach einem ersten Probaluf mit vier Motoren ist direkt aufgefalllen, dass man einen zusätzlichen Scritt in der Webapp einfügen sollte, bevor eine Messung gestartet wird. Uns ist es nämlich passiert, dass eine Messung unbeabsichtigt gestartet wurde, was die vorherige Messung überschrieben hat. Diesen Stand der Software kann man in commit 87d5b97e nachvollziehen.\
|
|
|
Bei unserer nächsten Messreihe, welche auch die größte war, wurde diese Änderung umgesetzt und hat sich als sehr nützlich erwiesen.\
|
|
|
Das Design der Software in Kombination mit dem des Prüfstands hat es uns ermöglicht einen sehr effizienten Ablauf der Messreihe zu realisieren. So konnten wir rund 20 Motoren in nur einer Stunde vermessen.
|
|
|
|
|
|
Zwischen der vorher beschrieben Messreihe und dem Launch Day wurden nur wenige Änderungen vorgenommen. Die Buttons auf der Webapp waren zu klein und wurden größer gemacht und eine Routine hinzugefügt, welche ein Starten der Messung verhindert, wenn keine SD-Karte eingelegt ist.
|
|
|
### Launch Day 2024
|
|
|
|
|
|
Zwischen der vorher beschrieben Messreihe und dem Launch Day wurden nur wenige Änderungen vorgenommen. Die Buttons auf der Webapp waren zu klein und wurden größer gemacht und eine Routine hinzugefügt, welche ein Starten der Messung verhindert, wenn keine SD-Karte eingelegt ist.
|
|
|
|
|
|
## Messtechnik ( author: @stcomosc )
|
|
|
|
... | ... | @@ -274,8 +343,8 @@ Da die hinreichenden Anforderungen an die Messtechnik unklar sind (fehlende Refe |
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
Da wir möglichst schnell Messungen mit 80SPS durchführen wollten, war es naheliegend, die Platine schon für das Proof of Concept zu modifizieren.
|
|
|
Folgende Schritte waren dafür nötig:
|
|
|
Da wir möglichst schnell Messungen mit 80SPS durchführen wollten, war es naheliegend, die Platine schon für das Proof of Concept zu modifizieren. Folgende Schritte waren dafür nötig:
|
|
|
|
|
|
1. HX711 mit Heißluft auslöten
|
|
|
2. Trace zwischen Pin 15 und 16 durchtrennen
|
|
|
3. HX711 wieder einlöten
|
... | ... | @@ -285,8 +354,8 @@ Die Modifikation war erfolgreich und der Messvertärker konnte auf 80SPS umgebau |
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
Um auch die stärkeren Motoren vermessen zu können und keine Wägezelle mit höherer Nennlast zur Verfügung stand, musste vorher die Linearität des Messaufbaus überprüft werden. Am besten ging das mit dem Softwarestand ab dem Prototypen, da hier bereits schon eine Kalibrier-Routuine und ein direktes Ablesen der Messwerte über die Webapp möglich waren.
|
|
|
Innerhalb der Nennlast wurde die Linearität mit Referenzgewichten aus dem Labor überprüft und es gab keine nennswerte Abweichung. Nur ein Quantisierungsrasuchen überlagert mit einem Rauschen von ca. 0,2g war zu beobachten.
|
|
|
Um auch die stärkeren Motoren vermessen zu können und keine Wägezelle mit höherer Nennlast zur Verfügung stand, musste vorher die Linearität des Messaufbaus überprüft werden. Am besten ging das mit dem Softwarestand ab dem Prototypen, da hier bereits schon eine Kalibrier-Routuine und ein direktes Ablesen der Messwerte über die Webapp möglich waren.\
|
|
|
Innerhalb der Nennlast wurde die Linearität mit Referenzgewichten aus dem Labor überprüft und es gab keine nennswerte Abweichung. Nur ein Quantisierungsrasuchen überlagert mit einem Rauschen von ca. 0,2g war zu beobachten.\
|
|
|
Zur Bestimmung der Linearität außerhalb der Nennlast von 1kg wurden verschiedene Gewichte an der Wägezelle befestigt und die ausgegebenen Werte mit einer Küchenwaage verglichen. Als Gewichte wurden 1kg, 1,5kg, 2kg und 3kg verwendet, welche aus mit Wasser gefüllten Flaschen bestanden. Unser Aufbau gab ein Gewicht von 3,063kg aus und auf der Küchenwaage wurden 3,069kg abgelesen. Dies entspricht einer Abweichung von 0,2%. Wichtig war auch, dass die Werte nach einer Entlastung wieder auf den Ausgangswert 0g zurückgingen, um eine plastische Verformung der Wägezelle auszuschließen. Da dies der Fall war, konnte die Linearität des Messaufbaus im Rahmen unserer Möglichkeiten festgestellt werden.
|
|
|
|
|
|
### Launch Day 2024
|
... | ... | @@ -344,12 +413,12 @@ Das Pinout findet man [hier](https://github.com/lnlp/pinout-diagrams/blob/main/L |
|
|
|
|
|
Von Anfang an wurde das Board von LILYGO wie folgt mit dem HX711 verbunden:
|
|
|
|
|
|
LILYGO | HX711
|
|
|
--- | ---
|
|
|
GPIO 22 | DT (DOUT)
|
|
|
GPIO 23 | SCK
|
|
|
5V | VCC
|
|
|
GND | GND
|
|
|
| LILYGO | HX711 |
|
|
|
|--------|-------|
|
|
|
| GPIO 22 | DT (DOUT) |
|
|
|
| GPIO 23 | SCK |
|
|
|
| 5V | VCC |
|
|
|
| GND | GND |
|
|
|
|
|
|
## Simulation ( @istpankwa )
|
|
|
|
... | ... | @@ -363,4 +432,4 @@ GND | GND |
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
## Auswertung ( author: @stcomosc ) |
|
|
## Auswertung ( author: @stcomosc ) |
|
|
\ No newline at end of file |