|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
The different parameters in the launch of a model rocket shall be verified using a motor test stand, rocket flight simulation and test launches with sensors on board. The results shall be presented during the 2024 DLA Launch Day.
|
|
|
|
|
|
|
|
# Project goals
|
|
|
|
|
|
|
|
- [ ] Develop and build a rocket motor test stand
|
|
|
|
- [ ] Verify the thrust curves of standard 18 mm motors
|
|
|
|
- [ ] Build and simulate a 35 mm model rocket to verify flight curves
|
|
|
|
- [ ] Use altimeter to verify simulation data in real flights
|
|
|
|
|
|
|
|
Ideally a team of 3 students shall work on this project.
|
|
|
|
|
|
|
|
# Background (author: @hda10343)
|
|
|
|
|
|
|
|
## Model Rocket
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Flight phases
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
## Rocket Motors
|
|
|
|
|
|
|
|
Model rockets are propelled by rocket motors. The achievable flight altitude strongly depends on the thrust characteristics of the rocket motor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The rocket motors that are commercially available are standardized and have predefined thrust characteristics over time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Simulation
|
|
|
|
|
|
|
|
The simulation of the rocket flight shall be done with [OpenRocket](https://openrocket.info):
|
|
|
|
|
|
|
|
 
|
|
|
|
|
|
|
|
## 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).  
|
|
|
|
|
|
|
|
# Report (authors: @stcomosc, @istpankwa, @stronjin)
|
|
|
|
|
|
|
|
## Meilensteine
|
|
|
|
|
|
|
|
- %"Proof of Concept"
|
|
|
|
- %Prototyp
|
|
|
|
- %"Launch day 2024"
|
|
|
|
|
|
|
|
## Arbeitspakete
|
|
|
|
|
|
|
|
#### Projectlead ( @stcomosc )
|
|
|
|
|
|
|
|
* manage issues
|
|
|
|
* watch milestones/deadlines
|
|
|
|
|
|
|
|
#### Mechanical resp ( @stronjin )
|
|
|
|
|
|
|
|
* Wahl der Kraft/Druck-sensoren bzw. Anzahl der zu benutzende Sensoren. (Je mehr der Motor stark ist , desto grösser wird der Anzahl an Sensoren sein )
|
|
|
|
* Wahl der Temperatur-Sensoren (Sensoren zur Messung der Temperatur innerhalb des Motors und der umgebenden Umgebung )
|
|
|
|
* Steuerelektronik für die Aktivierung und Deaktivierung des Motors
|
|
|
|
* Sicherheitsvorkehrungen : Notabschaltungen , Sicherheitsbarrieren ,......
|
|
|
|
* Halterung + Richtungen für bessere Ergebnisse ( Material wahl . Holz , Plastik oder Alu profil ) 3D Druck
|
|
|
|
* Schutz von Mikrocontroller , etc 3D Druck
|
|
|
|
* DOE (Design of Experiment):
|
|
|
|
* Ablauf einer Messung am Prüfstand
|
|
|
|
* Vergleich verschiedener Konzepte zB:
|
|
|
|
* Feuerung nach oben/unten/Seite
|
|
|
|
* eine/mehrere waagzellen
|
|
|
|
|
|
|
|
#### Simulation ( @istpankwa )
|
|
|
|
|
|
|
|
* Auswahl der Racket Typen Für die Prototypensimulation
|
|
|
|
* Erweiterung der Komponente des Model für die Simulation
|
|
|
|
* Auswahl des Antriebssystem für die Durchführung der Simulation
|
|
|
|
* Auswahl der Type und Anzahl der Motoren.
|
|
|
|
* Durchführung der Simulation Validierung des Modells Model
|
|
|
|
|
|
|
|
#### Software architect ( @stcomosc )
|
|
|
|
|
|
|
|
* API design (OpenAPI aka swagger 3.1.0)
|
|
|
|
* UI/UX: Webapp design (nodejs framework Vue)
|
|
|
|
* Sicherheitsfeatures
|
|
|
|
|
|
|
|
#### Softwaredevolpment ( @stcomosc )
|
|
|
|
|
|
|
|
* Prüfstand steuern
|
|
|
|
* Kalibrierung
|
|
|
|
* Messdaten erfassen (start/stopp Speicherung/abrufen)
|
|
|
|
* erste Analyse auf dem board
|
|
|
|
* UI zum steuern (Web/Touchdisplay/Buttons+Display)
|
|
|
|
* Auswahl "Steuerung" uC/sbc/etc
|
|
|
|
* Auswahl Messtechnik
|
|
|
|
* evtl Anpassung bestehender Projekte (Altimeter und WiFi)
|
|
|
|
* Websocket Implementierung (Übertragung von Livedaten zur Webapp)
|
|
|
|
|
|
|
|
## Mechanischer Aufbau ( @stronjin )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
**Stabilität und Festigkeit:**
|
|
|
|
|
|
|
|
Der Prüfstand muss stark genug sein, um den Kräften standzuhalten, die während des Raketenmotorbetriebs auftreten. Dies bedeutet, dass sowohl die Struktur des Prüfstands als auch die Befestigung des Raketenmotors stabil und fest sein müssen.
|
|
|
|
|
|
|
|
**Hitzebeständigkeit**
|
|
|
|
|
|
|
|
(in Beziehung mit dem Material-Wahl ) Raketenmotoren erzeugen hohe Temperaturen, daher muss der Prüfstand hitzebeständig sein, um Schäden zu vermeiden und die Sicherheit zu gewährleisten.
|
|
|
|
|
|
|
|
**Vibrationseindämmung:**
|
|
|
|
|
|
|
|
(Gute Material-Wahl in Basis kann das vehindern ) Raketenmotoren erzeugen starke Vibrationen während des Betriebs. Der Prüfstand muss diese Vibrationen absorbieren oder isolieren, um die umliegende Infrastruktur nicht zu beschädigen und genaue Messungen zu ermöglichen.
|
|
|
|
|
|
|
|
**Sicherheitsmaßnahmen:**
|
|
|
|
|
|
|
|
Der Prüfstand muss Sicherheitsvorkehrungen Notfallpläne haben, um Unfälle zu vermeiden und im Falle eines Problems schnell reagieren zu können.
|
|
|
|
|
|
|
|
**Mess- und Kontrollsysteme:**
|
|
|
|
|
|
|
|
Der Prüfstand benötigt präzise Mess- und Kontrollsysteme, um den Betrieb des Raketenmotors zu überwachen, Daten zu sammeln und den Motor gegebenenfalls zu steuern oder abzuschalten (Bessere Sicherheit ==\> Kontroll über App ? )
|
|
|
|
|
|
|
|
**Strukturelle Integrität:**
|
|
|
|
|
|
|
|
Die Struktur des Prüfstands muss so konstruiert sein, dass sie sowohl dem Druck als auch der Zugkraft standhält, die durch den Rückstoß des Raketenmotors in beide Richtungen entstehen.
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
**Milestones 1 : Proof of Concept**
|
|
|
|
|
|
|
|
1. **Vorstellung der Konzepte**
|
|
|
|
|
|
|
|
**Erstes Konzept:** **Vertikale Ausrichtung mit wirkender Schubskraft nach oben**
|
|
|
|
|
|
|
|
Hier wird der Teststand so aufgebaut, dass der Raketenmotor die Schubkraft nach oben ausübt. (Raketenausstoss nach unten Nb: unterhalb dem Sensor ) der Kraft Sensor wird oben Positioniert .
|
|
|
|
|
|
|
|
* **Vorteile:**
|
|
|
|
* Ermöglicht eine Realitätsnahe Simulation des Flugverhaltens
|
|
|
|
* Geringeres Risiko für Personen am Boden, da die Schubkraft nach oben laufen wird.
|
|
|
|
* **Nachteile:**
|
|
|
|
* Erfordert robuste Materialien, um die Stabilität des gesamten Teststands zu gewährleisten.
|
|
|
|
|
|
|
|
**Zweites Konzept: Horizontale Ausrichtung mit seitlich gerichteter Feuerung**
|
|
|
|
|
|
|
|
Hier wird der Teststand so aufgebaut , dass der Raketenmotor eine Horizontale Schubskraft entweder in Richtung Rechts oder Links ausübt.
|
|
|
|
|
|
|
|
* **Vorteile:**
|
|
|
|
* Erlaubt eine störungsfreie Durchführung verschiedener Phasen des Rocket-motor , einschließlich Beobachtung der Feuerung und der Delay-Motor Phase.
|
|
|
|
* **Nachteile:**
|
|
|
|
* Sicherheitsbedenken im Falle eines Ausfalls, da eine horizontale Ausrichtung potenziell gefährlich für die Umgebung sein könnte.
|
|
|
|
* Möglicherweise komplizierte Datenerfassung aufgrund der Modellierung.
|
|
|
|
|
|
|
|
**Drittes Konzept: Vertikale Ausrichtung mit wirkender Schubskraft-Richtung nach unten**
|
|
|
|
|
|
|
|
* Hier wird der Teststand so aufgebaut, dass der Raketenmotor die Schubkraft nach unten ausübt. (Raketenausstoss nach oben Nb: über dem Sensor ). Der Kraft-Sensor wird auf eine Stabiles Platform unten gefixt.
|
|
|
|
* **Vorteile:**
|
|
|
|
* Minimiert das Risiko für die Umgebung und bietet eine erhöhte Stabilität des Teststands durch die nach unten gerichtete Schubskraft.
|
|
|
|
* **Nachteile:**
|
|
|
|
* Möglicherweise ungenaue Datenerfassung aufgrund der Nichtlinearität der Schubkurve und der Schwierigkeit, genaue Daten zu erhalten.
|
|
|
|
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|
|
|
|
|
|
## Software ( @stcomosc )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
* Prüfstand steuern
|
|
|
|
* Kalibrierung (für jede neue Kombination aus Kraftsensor und Messverstärker)
|
|
|
|
* Messdaten erfassen (start/stopp Speicherung/abrufen)
|
|
|
|
* UI zum steuern (Web/~~Touchdisplay/Buttons+Display~~)
|
|
|
|
* Einfache Bedienung (über UI)
|
|
|
|
* ~~verschiedene Experiment-Abläufe einfach erstellen~~
|
|
|
|
* ~~Daten Formatieren~~
|
|
|
|
* ~~Kennlinienaufnahme vom Sensor~~
|
|
|
|
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
UI:
|
|
|
|
|
|
|
|
1. Buttons und LEDs
|
|
|
|
2. Buttons, LEDs und ein Display
|
|
|
|
3. Buttons, LEDs, Display und Webapp
|
|
|
|
|
|
|
|
**Entscheidung fällt auf 3**. Da für das UI sowohl einfache Bedienmethoden über Buttons (low level Backup oder Schnellzugriff) als auch komplexere Anforderungen erfüllt werden müssen, fiel die Wahl auf eine Kombination aus Buttons, LEDs, einem kleinen Display und einer Webapp.
|
|
|
|
|
|
|
|
Die Funktion der **Buttons** wäre, dass man zB in einem Experiment den nächsten Schritt auswählt oder ein Experiment abbricht. Diese Buttons weden direkt am Prüfstand angebracht und sind vom Versuchsleiter/Bediener gut zu erreichen. In Kombination mit den **LEDs** und einem **kleinen Display** lässt sich auf einen Blick direkt der Zustand des Prüftstands erkennen. Die **Webapp** bietet die selben Interaktionsmöglichkeiten mit einem erweitertem Funktionsumfang: z.B. zum Erstellen eines Experiments, Verwalten der Kalibrierdaten oder Abrufen vergangener Versuche. Die Idee ist, dass man in der Webapp aus veschiedenen vorprogrammierten Experiment-Bausteinen ein Experiment aufbaut, welches dann gefahren werden kann auf dem Prüfstand. Die Webapp interagiert mit dem microcontroller über eine API, deren Umsetzung weiter unten erläutert wird:
|
|
|
|
|
|
|
|
Aus den definierten Anforderungen und dem angestrebten Design der Software ergab sich folgender Aufbau:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Messtechnik ( @stcomosc )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
* Hinreichende Auflösung
|
|
|
|
* Hinreichende Datenrate (mehr Messpunkte als in OpenRocket)
|
|
|
|
(Daten in OpenRocket sind ungefähr 17Hz und aus dem Datenblatt des Herstellers übernommen, siehe z.B. https://www.thrustcurve.org/motors/Klima/B4/)
|
|
|
|
* Wichtigster Parameter: Kraft
|
|
|
|
zu erwarten sind im peak 25N Schub (für D9 Motor)
|
|
|
|
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
Kraftmessung:
|
|
|
|
|
|
|
|
1. DMS und Messvertärker bei [HBK](http://www.hbm.com/de/) anfragen (Kooperation denkbar)
|
|
|
|
2. [hx711 ](http://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf)(brückenverstärker) mit wägezelle (1kg maximale Nennlast)
|
|
|
|
3. Kofferwaage
|
|
|
|
|
|
|
|
Da die hinreichenden Anforderungen an die Messtechnik unklar sind (fehlende Referenz oder Erfahrungswerte) und die zweite Option bereits im Labor vorhanden ist, wird diese Kombination zunächst betrachtet. Weitere Untersuchungen sind nötig, die Wahl der Wägezelle und des HX711 als Meßvertsärker zu evaluieren. Untersucht werden soll die Liniariät des Messaufbaus - auch jenseits der Nennlast von 1kg - und die maximale Datenrate, die laut [Datenblatt](https://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf) maximal 80SPS beträgt. Die angebotene Platine von Sparkfun bietet eine einfache Möglichkeit, diese Datenrate umzuschalten (siehe auf dem [Schaltplan](https://cdn.sparkfun.com/assets/f/5/5/b/c/SparkFun_HX711_Load_Cell.pdf) *SJ2* und *R5*). Die uns zur Verfügung stehende Platine hat diese Möglichkeit nicht und wird im späteren Verlauf des Projekts aus diesem Grund modifiziert.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Elektronik ( @stcomosc )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
Microcontroller:
|
|
|
|
|
|
|
|
* **WiFi** zur Verbindung mit der Webapp über Smartphone/Laptop
|
|
|
|
* **Ausreichend Flash** (min. 1MB)
|
|
|
|
* Programm (300-400KB)
|
|
|
|
* Webapp (300-400KB)
|
|
|
|
* **SD Karte**
|
|
|
|
* intern oder externer Leser
|
|
|
|
* Messdaten liegen hier
|
|
|
|
* Datenbank und Kalibriertabellen
|
|
|
|
* Messdaten können auch ohne Webapp ausgelesen werden
|
|
|
|
* **RAM**
|
|
|
|
* schwer abzuschätzen
|
|
|
|
* Messdaten könnten auch direkt auf SD oder in freien Flash Bereich (z.B. LittleFS)
|
|
|
|
* **IOs (min 14)**
|
|
|
|
* 2 x Inputs pro HX711
|
|
|
|
* ~~2-3 Inputs für Buttons~~
|
|
|
|
* 1 x I2C für Display (2 Pins)
|
|
|
|
* 1-2 Outputs für LEDs
|
|
|
|
* ~~2-3 Outputs für elektr Zündung~~
|
|
|
|
* 1 x SPI für SD Karte (4 Pins MISO, MOSI, SCLK, CS)
|
|
|
|
|
|
|
|
sonstige Elektronik:
|
|
|
|
|
|
|
|
* **automatische elektrische Zündung** des Motors
|
|
|
|
* extra PCB/Schaltung/Relais?
|
|
|
|
* Verundung zweier Signale vom uC minimum
|
|
|
|
* Sicherheits-Pin gibt schaltung frei
|
|
|
|
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
Microcontroller (alle als dev-boards):
|
|
|
|
|
|
|
|
1. ESP32
|
|
|
|
2. ESP8266
|
|
|
|
3. microcontroller board + externes WiFi Modul
|
|
|
|
|
|
|
|
Die Wahl fiel auf das "[LoRa32 V2.1_1.6](http://www.lilygo.cc/products/lora3)" von LILYGO, da es zum einen alle Anforderungen erfüllt und es schon im Labor zur Verfügung stand. Im Gegensatz zu den anderen ESP32 boards im Labor, hat das von LILYGO deutlich mehr Ausgänge, einen eingebauten SD-Karten-Leser und ein kleines Display ist auch schon integriert. Die verbaute LoRa Peripherie wird in diesem Projekt wahrscheinlich keine Relevanz haben.
|
|
|
|
|
|
|
|
Das Pinout findet man [hier](https://github.com/lnlp/pinout-diagrams/blob/main/LoRa%20development%20boards/TTGO%20LoRa32%20V2.1.6%20Pinout%20(LLP).pdf)
|
|
|
|
|
|
|
|
!!WICHTIG!!: Wenn man dieses Board flashen will, muss die SD Karte entfernt sein. (Der Grund für dieses Verhalten ist nicht bekannt und auch online gibt es hierzu keine Information)
|
|
|
|
|
|
|
|
## Proof of Concept
|
|
|
|
Diente dazu, die Wahl der Komponenten zu überprüfen und erste Erfahrungen mit den Raketenmotoren zu sammeln. Hierfür wurde ein einfacher Aufbau gewählt, der die Funktionalität des Prüfstands und der Software demonstriert.
|
|
|
|
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|
|
|
|
|
|
## Simulation ( @istpankwa )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
The different parameters in the launch of a model rocket shall be verified using a motor test stand, rocket flight simulation and test launches with sensors on board. The results shall be presented during the 2024 DLA Launch Day.
|
|
|
|
|
|
|
|
# Project goals
|
|
|
|
|
|
|
|
- [ ] Develop and build a rocket motor test stand
|
|
|
|
- [ ] Verify the thrust curves of standard 18 mm motors
|
|
|
|
- [ ] Build and simulate a 35 mm model rocket to verify flight curves
|
|
|
|
- [ ] Use altimeter to verify simulation data in real flights
|
|
|
|
|
|
|
|
Ideally a team of 3 students shall work on this project.
|
|
|
|
|
|
|
|
# Background (author: @hda10343)
|
|
|
|
|
|
|
|
## Model Rocket
|
|
|
|
|
|
|
|
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}
|
|
|
|
|
|
|
|
## 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}
|
|
|
|
|
|
|
|
1. Launch
|
|
|
|
2. Powered Flight
|
|
|
|
3. Coasting
|
|
|
|
4. Recovery
|
|
|
|
|
|
|
|
## Rocket Motors
|
|
|
|
|
|
|
|
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}
|
|
|
|
|
|
|
|
The rocket motors that are commercially available are standardized and have predefined thrust characteristics over time.
|
|
|
|
|
|
|
|
{width=444 height=317}
|
|
|
|
|
|
|
|
{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}
|
|
|
|
|
|
|
|
## Simulation
|
|
|
|
|
|
|
|
The simulation of the rocket flight shall be done with [OpenRocket](https://openrocket.info):
|
|
|
|
|
|
|
|
{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}
|
|
|
|
|
|
|
|
# Report (authors: @stcomosc, @istpankwa, @stronjin)
|
|
|
|
|
|
|
|
## Meilensteine
|
|
|
|
|
|
|
|
- %"Proof of Concept":
|
|
|
|
|
|
|
|
diente dazu, die Wahl der Komponenten zu überprüfen und erste Erfahrungen mit den Raketenmotoren zu sammeln. Hierfür wurde ein einfacher Aufbau gewählt, der die Funktionalität des Prüfstands und der Software demonstriert.
|
|
|
|
- %Prototyp:
|
|
|
|
|
|
|
|
ist ein fertiger mechanischer Aufbau und die Software befindet sich in einem ausgereiften Zustand. So können verwendbare Messungen für die spätere Auswertung angefertigt werden.
|
|
|
|
- %"Launch day 2024":
|
|
|
|
|
|
|
|
Präsentation der Ergebnisse und Vorführung des Prüfstands sowie Start verschiedener Modellraketen.
|
|
|
|
|
|
|
|
## Arbeitspakete
|
|
|
|
|
|
|
|
**Projectlead ( @stcomosc )**
|
|
|
|
|
|
|
|
* manage issues
|
|
|
|
* watch milestones/deadlines
|
|
|
|
|
|
|
|
**Mechanical resp ( @stronjin )**
|
|
|
|
|
|
|
|
* Wahl der Kraft/Druck-sensoren bzw. Anzahl der zu benutzende Sensoren. (Je mehr der Motor stark ist , desto grösser wird der Anzahl an Sensoren sein )
|
|
|
|
* Wahl der Temperatur-Sensoren (Sensoren zur Messung der Temperatur innerhalb des Motors und der umgebenden Umgebung )
|
|
|
|
* Steuerelektronik für die Aktivierung und Deaktivierung des Motors
|
|
|
|
* Sicherheitsvorkehrungen : Notabschaltungen , Sicherheitsbarrieren ,......
|
|
|
|
* Halterung + Richtungen für bessere Ergebnisse ( Material wahl . Holz , Plastik oder Alu profil ) 3D Druck
|
|
|
|
* Schutz von Mikrocontroller , etc 3D Druck
|
|
|
|
* DOE (Design of Experiment):
|
|
|
|
* Ablauf einer Messung am Prüfstand
|
|
|
|
* Vergleich verschiedener Konzepte zB:
|
|
|
|
* Feuerung nach oben/unten/Seite
|
|
|
|
* eine/mehrere waagzellen
|
|
|
|
|
|
|
|
**Simulation ( @istpankwa )**
|
|
|
|
|
|
|
|
* Auswahl der Racket Typen Für die Prototypensimulation
|
|
|
|
* Erweiterung der Komponente des Model für die Simulation
|
|
|
|
* Auswahl des Antriebssystem für die Durchführung der Simulation
|
|
|
|
* Auswahl der Type und Anzahl der Motoren.
|
|
|
|
* Durchführung der Simulation Validierung des Modells Model
|
|
|
|
|
|
|
|
**Software architect ( @stcomosc )**
|
|
|
|
|
|
|
|
* API design (OpenAPI aka swagger 3.1.0)
|
|
|
|
* UI/UX: Webapp design (nodejs framework Vue)
|
|
|
|
* Sicherheitsfeatures
|
|
|
|
|
|
|
|
**Softwaredevolpment ( @stcomosc )**
|
|
|
|
|
|
|
|
* Prüfstand steuern
|
|
|
|
* Kalibrierung
|
|
|
|
* Messdaten erfassen (start/stopp Speicherung/abrufen)
|
|
|
|
* erste Analyse auf dem board
|
|
|
|
* UI zum steuern (Web/Touchdisplay/Buttons+Display)
|
|
|
|
* Auswahl "Steuerung" uC/sbc/etc
|
|
|
|
* Auswahl Messtechnik
|
|
|
|
* evtl Anpassung bestehender Projekte (Altimeter und WiFi)
|
|
|
|
* Websocket Implementierung (Übertragung von Livedaten zur Webapp)
|
|
|
|
|
|
|
|
## Einführung
|
|
|
|
|
|
|
|
## Mechanischer Aufbau ( @stronjin )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
**Stabilität und Festigkeit:**
|
|
|
|
|
|
|
|
Der Prüfstand muss stark genug sein, um den Kräften standzuhalten, die während des Raketenmotorbetriebs auftreten. Dies bedeutet, dass sowohl die Struktur des Prüfstands als auch die Befestigung des Raketenmotors stabil und fest sein müssen.
|
|
|
|
|
|
|
|
**Hitzebeständigkeit**
|
|
|
|
|
|
|
|
(in Beziehung mit dem Material-Wahl ) Raketenmotoren erzeugen hohe Temperaturen, daher muss der Prüfstand hitzebeständig sein, um Schäden zu vermeiden und die Sicherheit zu gewährleisten.
|
|
|
|
|
|
|
|
**Vibrationseindämmung:**
|
|
|
|
|
|
|
|
(Gute Material-Wahl in Basis kann das vehindern ) Raketenmotoren erzeugen starke Vibrationen während des Betriebs. Der Prüfstand muss diese Vibrationen absorbieren oder isolieren, um die umliegende Infrastruktur nicht zu beschädigen und genaue Messungen zu ermöglichen.
|
|
|
|
|
|
|
|
**Sicherheitsmaßnahmen:**
|
|
|
|
|
|
|
|
Der Prüfstand muss Sicherheitsvorkehrungen Notfallpläne haben, um Unfälle zu vermeiden und im Falle eines Problems schnell reagieren zu können.
|
|
|
|
|
|
|
|
**Mess- und Kontrollsysteme:**
|
|
|
|
|
|
|
|
Der Prüfstand benötigt präzise Mess- und Kontrollsysteme, um den Betrieb des Raketenmotors zu überwachen, Daten zu sammeln und den Motor gegebenenfalls zu steuern oder abzuschalten (Bessere Sicherheit ==\> Kontroll über App ? )
|
|
|
|
|
|
|
|
**Strukturelle Integrität:**
|
|
|
|
|
|
|
|
Die Struktur des Prüfstands muss so konstruiert sein, dass sie sowohl dem Druck als auch der Zugkraft standhält, die durch den Rückstoß des Raketenmotors in beide Richtungen entstehen.
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
**Milestones 1 : Proof of Concept**
|
|
|
|
|
|
|
|
1. **Vorstellung der Konzepte**
|
|
|
|
|
|
|
|
**Erstes Konzept:** **Vertikale Ausrichtung mit wirkender Schubskraft nach oben**
|
|
|
|
|
|
|
|
Hier wird der Teststand so aufgebaut, dass der Raketenmotor die Schubkraft nach oben ausübt. (Raketenausstoss nach unten Nb: unterhalb dem Sensor ) der Kraft Sensor wird oben Positioniert .
|
|
|
|
|
|
|
|
* **Vorteile:**
|
|
|
|
* Ermöglicht eine Realitätsnahe Simulation des Flugverhaltens
|
|
|
|
* Geringeres Risiko für Personen am Boden, da die Schubkraft nach oben laufen wird.
|
|
|
|
* **Nachteile:**
|
|
|
|
* Erfordert robuste Materialien, um die Stabilität des gesamten Teststands zu gewährleisten.
|
|
|
|
|
|
|
|
**Zweites Konzept: Horizontale Ausrichtung mit seitlich gerichteter Feuerung**
|
|
|
|
|
|
|
|
Hier wird der Teststand so aufgebaut , dass der Raketenmotor eine Horizontale Schubskraft entweder in Richtung Rechts oder Links ausübt.
|
|
|
|
|
|
|
|
* **Vorteile:**
|
|
|
|
* Erlaubt eine störungsfreie Durchführung verschiedener Phasen des Rocket-motor , einschließlich Beobachtung der Feuerung und der Delay-Motor Phase.
|
|
|
|
* **Nachteile:**
|
|
|
|
* Sicherheitsbedenken im Falle eines Ausfalls, da eine horizontale Ausrichtung potenziell gefährlich für die Umgebung sein könnte.
|
|
|
|
* Möglicherweise komplizierte Datenerfassung aufgrund der Modellierung.
|
|
|
|
|
|
|
|
**Drittes Konzept: Vertikale Ausrichtung mit wirkender Schubskraft-Richtung nach unten**
|
|
|
|
|
|
|
|
* Hier wird der Teststand so aufgebaut, dass der Raketenmotor die Schubkraft nach unten ausübt. (Raketenausstoss nach oben Nb: über dem Sensor ). Der Kraft-Sensor wird auf eine Stabiles Platform unten gefixt.
|
|
|
|
* **Vorteile:**
|
|
|
|
* Minimiert das Risiko für die Umgebung und bietet eine erhöhte Stabilität des Teststands durch die nach unten gerichtete Schubskraft.
|
|
|
|
* **Nachteile:**
|
|
|
|
* Möglicherweise ungenaue Datenerfassung aufgrund der Nichtlinearität der Schubkurve und der Schwierigkeit, genaue Daten zu erhalten.
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|
|
## Software ( @stcomosc )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
* Prüfstand steuern
|
|
|
|
* Kalibrierung (für jede neue Kombination aus Kraftsensor und Messverstärker)
|
|
|
|
* Messdaten erfassen (start/stopp Speicherung/abrufen)
|
|
|
|
* UI zum steuern (Web/~~Touchdisplay/Buttons+Display~~)
|
|
|
|
* Einfache Bedienung (über UI)
|
|
|
|
* ~~verschiedene Experiment-Abläufe einfach erstellen~~
|
|
|
|
* ~~Daten Formatieren~~
|
|
|
|
* ~~Kennlinienaufnahme vom Sensor~~
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
UI:
|
|
|
|
|
|
|
|
1. Buttons und LEDs
|
|
|
|
2. Buttons, LEDs und ein Display
|
|
|
|
3. Buttons, LEDs, Display und Webapp
|
|
|
|
|
|
|
|
**Entscheidung fällt auf 3**. Da für das UI sowohl einfache Bedienmethoden über Buttons (low level Backup oder Schnellzugriff) als auch komplexere Anforderungen erfüllt werden müssen, fiel die Wahl auf eine Kombination aus Buttons, LEDs, einem kleinen Display und einer Webapp.
|
|
|
|
|
|
|
|
Die Funktion der **Buttons** wäre, dass man zB in einem Experiment den nächsten Schritt auswählt oder ein Experiment abbricht. Diese Buttons weden direkt am Prüfstand angebracht und sind vom Versuchsleiter/Bediener gut zu erreichen. In Kombination mit den **LEDs** und einem **kleinen Display** lässt sich auf einen Blick direkt der Zustand des Prüftstands erkennen. Die **Webapp** bietet die selben Interaktionsmöglichkeiten mit einem erweitertem Funktionsumfang: z.B. zum Erstellen eines Experiments, Verwalten der Kalibrierdaten oder Abrufen vergangener Versuche. Die Idee ist, dass man in der Webapp aus veschiedenen vorprogrammierten Experiment-Bausteinen ein Experiment aufbaut, welches dann gefahren werden kann auf dem Prüfstand. Die Webapp interagiert mit dem microcontroller über eine API, deren Umsetzung weiter unten erläutert wird:
|
|
|
|
|
|
|
|
Aus den definierten Anforderungen und dem angestrebten Design der Software ergab sich folgender Aufbau:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|
|
## Messtechnik ( @stcomosc )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
* Hinreichende Auflösung
|
|
|
|
* Hinreichende Datenrate (mehr Messpunkte als in OpenRocket)\
|
|
|
|
(Daten in OpenRocket sind ungefähr 17Hz und aus dem Datenblatt des Herstellers übernommen, siehe z.B. https://www.thrustcurve.org/motors/Klima/B4/)
|
|
|
|
* Wichtigster Parameter: Kraft\
|
|
|
|
zu erwarten sind im peak 25N Schub (für D9 Motor)
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
Kraftmessung:
|
|
|
|
|
|
|
|
1. DMS und Messvertärker bei [HBK](http://www.hbm.com/de/) anfragen (Kooperation denkbar)
|
|
|
|
2. [hx711 ](http://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf)(brückenverstärker) mit wägezelle (1kg maximale Nennlast)
|
|
|
|
3. Kofferwaage
|
|
|
|
|
|
|
|
Da die hinreichenden Anforderungen an die Messtechnik unklar sind (fehlende Referenz oder Erfahrungswerte) und die zweite Option bereits im Labor vorhanden ist, wird diese Kombination zunächst betrachtet. Weitere Untersuchungen sind nötig, die Wahl der Wägezelle und des HX711 als Meßvertsärker zu evaluieren. Untersucht werden soll die Liniariät des Messaufbaus - auch jenseits der Nennlast von 1kg - und die maximale Datenrate, die laut [Datenblatt](https://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf) maximal 80SPS beträgt. Die angebotene Platine von Sparkfun bietet eine einfache Möglichkeit, diese Datenrate umzuschalten (siehe auf dem [Schaltplan](https://cdn.sparkfun.com/assets/f/5/5/b/c/SparkFun_HX711_Load_Cell.pdf) _SJ2_ und _R5_). Die uns zur Verfügung stehende Platine hat diese Möglichkeit nicht und wird im späteren Verlauf des Projekts aus diesem Grund modifiziert.
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|
|
## Elektronik ( @stcomosc )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
Microcontroller:
|
|
|
|
|
|
|
|
* **WiFi** zur Verbindung mit der Webapp über Smartphone/Laptop
|
|
|
|
* **Ausreichend Flash** (min. 1MB)
|
|
|
|
* Programm (300-400KB)
|
|
|
|
* Webapp (300-400KB)
|
|
|
|
* **SD Karte**
|
|
|
|
* intern oder externer Leser
|
|
|
|
* Messdaten liegen hier
|
|
|
|
* Datenbank und Kalibriertabellen
|
|
|
|
* Messdaten können auch ohne Webapp ausgelesen werden
|
|
|
|
* **RAM**
|
|
|
|
* schwer abzuschätzen
|
|
|
|
* Messdaten könnten auch direkt auf SD oder in freien Flash Bereich (z.B. LittleFS)
|
|
|
|
* **IOs (min 14)**
|
|
|
|
* 2 x Inputs pro HX711
|
|
|
|
* ~~2-3 Inputs für Buttons~~
|
|
|
|
* 1 x I2C für Display (2 Pins)
|
|
|
|
* 1-2 Outputs für LEDs
|
|
|
|
* ~~2-3 Outputs für elektr Zündung~~
|
|
|
|
* 1 x SPI für SD Karte (4 Pins MISO, MOSI, SCLK, CS)
|
|
|
|
|
|
|
|
sonstige Elektronik:
|
|
|
|
|
|
|
|
* **automatische elektrische Zündung** des Motors
|
|
|
|
* extra PCB/Schaltung/Relais?
|
|
|
|
* Verundung zweier Signale vom uC minimum
|
|
|
|
* Sicherheits-Pin gibt schaltung frei
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
Microcontroller (alle als dev-boards):
|
|
|
|
|
|
|
|
1. ESP32
|
|
|
|
2. ESP8266
|
|
|
|
3. microcontroller board + externes WiFi Modul
|
|
|
|
|
|
|
|
Die Wahl fiel auf das "[LoRa32 V2.1_1.6](http://www.lilygo.cc/products/lora3)" von LILYGO, da es zum einen alle Anforderungen erfüllt und es schon im Labor zur Verfügung stand. Im Gegensatz zu den anderen ESP32 boards im Labor, hat das von LILYGO deutlich mehr Ausgänge, einen eingebauten SD-Karten-Leser und ein kleines Display ist auch schon integriert. Die verbaute LoRa Peripherie wird in diesem Projekt wahrscheinlich keine Relevanz haben.
|
|
|
|
|
|
|
|
Das Pinout findet man [hier](https://github.com/lnlp/pinout-diagrams/blob/main/LoRa%20development%20boards/TTGO%20LoRa32%20V2.1.6%20Pinout%20(LLP).pdf)
|
|
|
|
|
|
|
|
!!WICHTIG!!: Wenn man dieses Board flashen will, muss die SD Karte entfernt sein. (Der Grund für dieses Verhalten ist nicht bekannt und auch online gibt es hierzu keine Information)
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|
|
## Simulation ( @istpankwa )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
### Launch Day 2024 |
|
|
\ No newline at end of file |
