|
[[_TOC_]]
|
|
[[_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.
|
|
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
|
|
# Project goals
|
|
|
|
|
|
- [ ] Develop and build a rocket motor test stand
|
|
- [ ] Develop and build a rocket motor test stand
|
|
- [ ] Verify the thrust curves of standard 18 mm motors
|
|
- [ ] Verify the thrust curves of standard 18 mm motors
|
|
- [ ] Build and simulate a 35 mm model rocket to verify flight curves
|
|
- [ ] Build and simulate a 35 mm model rocket to verify flight curves
|
|
- [ ] Use altimeter to verify simulation data in real flights
|
|
- [ ] Use altimeter to verify simulation data in real flights
|
|
|
|
|
|
Ideally a team of 3 students shall work on this project.
|
|
Ideally a team of 3 students shall work on this project.
|
|
|
|
|
|
# Background (author: @hda10343)
|
|
# Background (author: @hda10343)
|
|
|
|
|
|
## Model Rocket
|
|
## 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)
|
|
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
|
|
## Flight phases
|
|
|
|
|
|
Model rocket flights can be divided into different flight states \[[1](https://code.fbi.h-da.de/hda10343/dla/-/wikis/Altimeter#sources)\]:
|
|
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
|
|
1. Launch
|
|
2. Powered Flight
|
|
2. Powered Flight
|
|
3. Coasting
|
|
3. Coasting
|
|
4. Recovery
|
|
4. Recovery
|
|
|
|
|
|
## Rocket Motors
|
|
## Rocket Motors
|
|
|
|
|
|
Model rockets are propelled by rocket motors. The achievable flight altitude strongly depends on the thrust characteristics of the rocket motor.
|
|
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.
|
|
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
|
|
## 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.
|
|
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
|
|
## Simulation
|
|
|
|
|
|
The simulation of the rocket flight shall be done with [OpenRocket](https://openrocket.info):
|
|
The simulation of the rocket flight shall be done with [OpenRocket](https://openrocket.info):
|
|
|
|
|
|
 
|
|
{width=600 height=323} 
|
|
|
|
|
|
## Altimeter
|
|
## 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).  
|
|
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)
|
|
{width=352 height=252} {width=380 height=249}
|
|
|
|
|
|
## Meilensteine
|
|
# Report (authors: @stcomosc, @istpankwa, @stronjin)
|
|
|
|
|
|
- %"Proof of Concept"
|
|
## Meilensteine
|
|
- %Prototyp
|
|
|
|
- %"Launch day 2024"
|
|
- %"Proof of Concept":
|
|
|
|
|
|
## Arbeitspakete
|
|
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:
|
|
#### Projectlead ( @stcomosc )
|
|
|
|
|
|
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.
|
|
* manage issues
|
|
- %"Launch day 2024":
|
|
* watch milestones/deadlines
|
|
|
|
|
|
Präsentation der Ergebnisse und Vorführung des Prüfstands sowie Start verschiedener Modellraketen.
|
|
#### Mechanical resp ( @stronjin )
|
|
|
|
|
|
## Arbeitspakete
|
|
* 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 )
|
|
**Projectlead ( @stcomosc )**
|
|
* Steuerelektronik für die Aktivierung und Deaktivierung des Motors
|
|
|
|
* Sicherheitsvorkehrungen : Notabschaltungen , Sicherheitsbarrieren ,......
|
|
* manage issues
|
|
* Halterung + Richtungen für bessere Ergebnisse ( Material wahl . Holz , Plastik oder Alu profil ) 3D Druck
|
|
* watch milestones/deadlines
|
|
* Schutz von Mikrocontroller , etc 3D Druck
|
|
|
|
* DOE (Design of Experiment):
|
|
**Mechanical resp ( @stronjin )**
|
|
* Ablauf einer Messung am Prüfstand
|
|
|
|
* Vergleich verschiedener Konzepte zB:
|
|
* 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 )
|
|
* Feuerung nach oben/unten/Seite
|
|
* Wahl der Temperatur-Sensoren (Sensoren zur Messung der Temperatur innerhalb des Motors und der umgebenden Umgebung )
|
|
* eine/mehrere waagzellen
|
|
* Steuerelektronik für die Aktivierung und Deaktivierung des Motors
|
|
|
|
* Sicherheitsvorkehrungen : Notabschaltungen , Sicherheitsbarrieren ,......
|
|
#### Simulation ( @istpankwa )
|
|
* Halterung + Richtungen für bessere Ergebnisse ( Material wahl . Holz , Plastik oder Alu profil ) 3D Druck
|
|
|
|
* Schutz von Mikrocontroller , etc 3D Druck
|
|
* Auswahl der Racket Typen Für die Prototypensimulation
|
|
* DOE (Design of Experiment):
|
|
* Erweiterung der Komponente des Model für die Simulation
|
|
* Ablauf einer Messung am Prüfstand
|
|
* Auswahl des Antriebssystem für die Durchführung der Simulation
|
|
* Vergleich verschiedener Konzepte zB:
|
|
* Auswahl der Type und Anzahl der Motoren.
|
|
* Feuerung nach oben/unten/Seite
|
|
* Durchführung der Simulation Validierung des Modells Model
|
|
* eine/mehrere waagzellen
|
|
|
|
|
|
#### Software architect ( @stcomosc )
|
|
**Simulation ( @istpankwa )**
|
|
|
|
|
|
* API design (OpenAPI aka swagger 3.1.0)
|
|
* Auswahl der Racket Typen Für die Prototypensimulation
|
|
* UI/UX: Webapp design (nodejs framework Vue)
|
|
* Erweiterung der Komponente des Model für die Simulation
|
|
* Sicherheitsfeatures
|
|
* Auswahl des Antriebssystem für die Durchführung der Simulation
|
|
|
|
* Auswahl der Type und Anzahl der Motoren.
|
|
#### Softwaredevolpment ( @stcomosc )
|
|
* Durchführung der Simulation Validierung des Modells Model
|
|
|
|
|
|
* Prüfstand steuern
|
|
**Software architect ( @stcomosc )**
|
|
* Kalibrierung
|
|
|
|
* Messdaten erfassen (start/stopp Speicherung/abrufen)
|
|
* API design (OpenAPI aka swagger 3.1.0)
|
|
* erste Analyse auf dem board
|
|
* UI/UX: Webapp design (nodejs framework Vue)
|
|
* UI zum steuern (Web/Touchdisplay/Buttons+Display)
|
|
* Sicherheitsfeatures
|
|
* Auswahl "Steuerung" uC/sbc/etc
|
|
|
|
* Auswahl Messtechnik
|
|
**Softwaredevolpment ( @stcomosc )**
|
|
* evtl Anpassung bestehender Projekte (Altimeter und WiFi)
|
|
|
|
* Websocket Implementierung (Übertragung von Livedaten zur Webapp)
|
|
* Prüfstand steuern
|
|
|
|
* Kalibrierung
|
|
## Mechanischer Aufbau ( @stronjin )
|
|
* Messdaten erfassen (start/stopp Speicherung/abrufen)
|
|
|
|
* erste Analyse auf dem board
|
|
### Anforderungen
|
|
* UI zum steuern (Web/Touchdisplay/Buttons+Display)
|
|
|
|
* Auswahl "Steuerung" uC/sbc/etc
|
|
**Stabilität und Festigkeit:**
|
|
* Auswahl Messtechnik
|
|
|
|
* evtl Anpassung bestehender Projekte (Altimeter und WiFi)
|
|
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.
|
|
* Websocket Implementierung (Übertragung von Livedaten zur Webapp)
|
|
|
|
|
|
**Hitzebeständigkeit**
|
|
## Einführung
|
|
|
|
|
|
(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.
|
|
## Mechanischer Aufbau ( @stronjin )
|
|
|
|
|
|
**Vibrationseindämmung:**
|
|
### Anforderungen
|
|
|
|
|
|
(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.
|
|
**Stabilität und Festigkeit:**
|
|
|
|
|
|
**Sicherheitsmaßnahmen:**
|
|
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.
|
|
|
|
|
|
Der Prüfstand muss Sicherheitsvorkehrungen Notfallpläne haben, um Unfälle zu vermeiden und im Falle eines Problems schnell reagieren zu können.
|
|
**Hitzebeständigkeit**
|
|
|
|
|
|
**Mess- und Kontrollsysteme:**
|
|
(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.
|
|
|
|
|
|
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 ? )
|
|
**Vibrationseindämmung:**
|
|
|
|
|
|
**Strukturelle Integrität:**
|
|
(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.
|
|
|
|
|
|
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.
|
|
**Sicherheitsmaßnahmen:**
|
|
|
|
|
|
### Konzepte
|
|
Der Prüfstand muss Sicherheitsvorkehrungen Notfallpläne haben, um Unfälle zu vermeiden und im Falle eines Problems schnell reagieren zu können.
|
|
|
|
|
|
**Milestones 1 : Proof of Concept**
|
|
**Mess- und Kontrollsysteme:**
|
|
|
|
|
|
1. **Vorstellung der Konzepte**
|
|
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 ? )
|
|
|
|
|
|
**Erstes Konzept:** **Vertikale Ausrichtung mit wirkender Schubskraft nach oben**
|
|
**Strukturelle Integrität:**
|
|
|
|
|
|
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 .
|
|
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.
|
|
|
|
|
|
* **Vorteile:**
|
|
### Konzepte
|
|
* Ermöglicht eine Realitätsnahe Simulation des Flugverhaltens
|
|
|
|
* Geringeres Risiko für Personen am Boden, da die Schubkraft nach oben laufen wird.
|
|
**Milestones 1 : Proof of Concept**
|
|
* **Nachteile:**
|
|
|
|
* Erfordert robuste Materialien, um die Stabilität des gesamten Teststands zu gewährleisten.
|
|
1. **Vorstellung der Konzepte**
|
|
|
|
|
|
**Zweites Konzept: Horizontale Ausrichtung mit seitlich gerichteter Feuerung**
|
|
**Erstes Konzept:** **Vertikale Ausrichtung mit wirkender Schubskraft nach oben**
|
|
|
|
|
|
Hier wird der Teststand so aufgebaut , dass der Raketenmotor eine Horizontale Schubskraft entweder in Richtung Rechts oder Links ausübt.
|
|
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:**
|
|
* **Vorteile:**
|
|
* Erlaubt eine störungsfreie Durchführung verschiedener Phasen des Rocket-motor , einschließlich Beobachtung der Feuerung und der Delay-Motor Phase.
|
|
* Ermöglicht eine Realitätsnahe Simulation des Flugverhaltens
|
|
* **Nachteile:**
|
|
* Geringeres Risiko für Personen am Boden, da die Schubkraft nach oben laufen wird.
|
|
* Sicherheitsbedenken im Falle eines Ausfalls, da eine horizontale Ausrichtung potenziell gefährlich für die Umgebung sein könnte.
|
|
* **Nachteile:**
|
|
* Möglicherweise komplizierte Datenerfassung aufgrund der Modellierung.
|
|
* Erfordert robuste Materialien, um die Stabilität des gesamten Teststands zu gewährleisten.
|
|
|
|
|
|
**Drittes Konzept: Vertikale Ausrichtung mit wirkender Schubskraft-Richtung nach unten**
|
|
**Zweites Konzept: Horizontale Ausrichtung mit seitlich gerichteter Feuerung**
|
|
|
|
|
|
* 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.
|
|
Hier wird der Teststand so aufgebaut , dass der Raketenmotor eine Horizontale Schubskraft entweder in Richtung Rechts oder Links ausübt.
|
|
* **Vorteile:**
|
|
|
|
* Minimiert das Risiko für die Umgebung und bietet eine erhöhte Stabilität des Teststands durch die nach unten gerichtete Schubskraft.
|
|
* **Vorteile:**
|
|
* **Nachteile:**
|
|
* Erlaubt eine störungsfreie Durchführung verschiedener Phasen des Rocket-motor , einschließlich Beobachtung der Feuerung und der Delay-Motor Phase.
|
|
* Möglicherweise ungenaue Datenerfassung aufgrund der Nichtlinearität der Schubkurve und der Schwierigkeit, genaue Daten zu erhalten.
|
|
* **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.
|
|
### Proof of Concept
|
|
|
|
|
|
**Drittes Konzept: Vertikale Ausrichtung mit wirkender Schubskraft-Richtung nach unten**
|
|
|
|
|
|
### Prototyp
|
|
* 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.
|
|
### Launch Day 2024
|
|
* **Nachteile:**
|
|
|
|
* Möglicherweise ungenaue Datenerfassung aufgrund der Nichtlinearität der Schubkurve und der Schwierigkeit, genaue Daten zu erhalten.
|
|
|
|
|
|
## Software ( @stcomosc )
|
|
### Proof of Concept
|
|
|
|
|
|
### Anforderungen
|
|
### Prototyp
|
|
|
|
|
|
* Prüfstand steuern
|
|
### Launch Day 2024
|
|
* Kalibrierung (für jede neue Kombination aus Kraftsensor und Messverstärker)
|
|
|
|
* Messdaten erfassen (start/stopp Speicherung/abrufen)
|
|
## Software ( @stcomosc )
|
|
* UI zum steuern (Web/~~Touchdisplay/Buttons+Display~~)
|
|
|
|
* Einfache Bedienung (über UI)
|
|
### Anforderungen
|
|
* ~~verschiedene Experiment-Abläufe einfach erstellen~~
|
|
|
|
* ~~Daten Formatieren~~
|
|
* Prüfstand steuern
|
|
* ~~Kennlinienaufnahme vom Sensor~~
|
|
* Kalibrierung (für jede neue Kombination aus Kraftsensor und Messverstärker)
|
|
|
|
* Messdaten erfassen (start/stopp Speicherung/abrufen)
|
|
|
|
* UI zum steuern (Web/~~Touchdisplay/Buttons+Display~~)
|
|
### Konzepte
|
|
* Einfache Bedienung (über UI)
|
|
|
|
* ~~verschiedene Experiment-Abläufe einfach erstellen~~
|
|
UI:
|
|
* ~~Daten Formatieren~~
|
|
|
|
* ~~Kennlinienaufnahme vom Sensor~~
|
|
1. Buttons und LEDs
|
|
|
|
2. Buttons, LEDs und ein Display
|
|
### Konzepte
|
|
3. Buttons, LEDs, Display und Webapp
|
|
|
|
|
|
UI:
|
|
**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.
|
|
|
|
|
|
1. Buttons und LEDs
|
|
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:
|
|
2. Buttons, LEDs und ein Display
|
|
|
|
3. Buttons, LEDs, Display und Webapp
|
|
Aus den definierten Anforderungen und dem angestrebten Design der Software ergab sich folgender Aufbau:
|
|
|
|
|
|
**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:
|
|
|
|
|
|
### Proof of Concept
|
|
Aus den definierten Anforderungen und dem angestrebten Design der Software ergab sich folgender Aufbau:
|
|
|
|
|
|
|
|

|
|
### Prototyp
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
### Launch Day 2024
|
|
### Prototyp
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
## Messtechnik ( @stcomosc )
|
|
## Messtechnik ( @stcomosc )
|
|
|
|
|
|
### Anforderungen
|
|
### Anforderungen
|
|
|
|
|
|
* Hinreichende Auflösung
|
|
* Hinreichende Auflösung
|
|
* Hinreichende Datenrate (mehr Messpunkte als in OpenRocket)
|
|
* 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/)
|
|
(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
|
|
* Wichtigster Parameter: Kraft\
|
|
zu erwarten sind im peak 25N Schub (für D9 Motor)
|
|
zu erwarten sind im peak 25N Schub (für D9 Motor)
|
|
|
|
|
|
|
|
### Konzepte
|
|
### Konzepte
|
|
|
|
|
|
Kraftmessung:
|
|
Kraftmessung:
|
|
|
|
|
|
1. DMS und Messvertärker bei [HBK](http://www.hbm.com/de/) anfragen (Kooperation denkbar)
|
|
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)
|
|
2. [hx711 ](http://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf)(brückenverstärker) mit wägezelle (1kg maximale Nennlast)
|
|
3. Kofferwaage
|
|
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.
|
|
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
|
|
### Proof of Concept
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
### Prototyp
|
|
## Elektronik ( @stcomosc )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
### Launch Day 2024
|
|
|
|
|
|
Microcontroller:
|
|
|
|
|
|
|
|
* **WiFi** zur Verbindung mit der Webapp über Smartphone/Laptop
|
|
## Elektronik ( @stcomosc )
|
|
* **Ausreichend Flash** (min. 1MB)
|
|
|
|
* Programm (300-400KB)
|
|
### Anforderungen
|
|
* Webapp (300-400KB)
|
|
|
|
* **SD Karte**
|
|
Microcontroller:
|
|
* intern oder externer Leser
|
|
|
|
* Messdaten liegen hier
|
|
* **WiFi** zur Verbindung mit der Webapp über Smartphone/Laptop
|
|
* Datenbank und Kalibriertabellen
|
|
* **Ausreichend Flash** (min. 1MB)
|
|
* Messdaten können auch ohne Webapp ausgelesen werden
|
|
* Programm (300-400KB)
|
|
* **RAM**
|
|
* Webapp (300-400KB)
|
|
* schwer abzuschätzen
|
|
* **SD Karte**
|
|
* Messdaten könnten auch direkt auf SD oder in freien Flash Bereich (z.B. LittleFS)
|
|
* intern oder externer Leser
|
|
* **IOs (min 14)**
|
|
* Messdaten liegen hier
|
|
* 2 x Inputs pro HX711
|
|
* Datenbank und Kalibriertabellen
|
|
* ~~2-3 Inputs für Buttons~~
|
|
* Messdaten können auch ohne Webapp ausgelesen werden
|
|
* 1 x I2C für Display (2 Pins)
|
|
* **RAM**
|
|
* 1-2 Outputs für LEDs
|
|
* schwer abzuschätzen
|
|
* ~~2-3 Outputs für elektr Zündung~~
|
|
* Messdaten könnten auch direkt auf SD oder in freien Flash Bereich (z.B. LittleFS)
|
|
* 1 x SPI für SD Karte (4 Pins MISO, MOSI, SCLK, CS)
|
|
* **IOs (min 14)**
|
|
|
|
* 2 x Inputs pro HX711
|
|
sonstige Elektronik:
|
|
* ~~2-3 Inputs für Buttons~~
|
|
|
|
* 1 x I2C für Display (2 Pins)
|
|
* **automatische elektrische Zündung** des Motors
|
|
* 1-2 Outputs für LEDs
|
|
* extra PCB/Schaltung/Relais?
|
|
* ~~2-3 Outputs für elektr Zündung~~
|
|
* Verundung zweier Signale vom uC minimum
|
|
* 1 x SPI für SD Karte (4 Pins MISO, MOSI, SCLK, CS)
|
|
* Sicherheits-Pin gibt schaltung frei
|
|
|
|
|
|
sonstige Elektronik:
|
|
### Konzepte
|
|
|
|
|
|
* **automatische elektrische Zündung** des Motors
|
|
Microcontroller (alle als dev-boards):
|
|
* extra PCB/Schaltung/Relais?
|
|
|
|
* Verundung zweier Signale vom uC minimum
|
|
1. ESP32
|
|
* Sicherheits-Pin gibt schaltung frei
|
|
2. ESP8266
|
|
|
|
3. microcontroller board + externes WiFi Modul
|
|
|
|
|
|
### Konzepte
|
|
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.
|
|
|
|
|
|
Microcontroller (alle als dev-boards):
|
|
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)
|
|
|
|
|
|
1. ESP32
|
|
!!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)
|
|
2. ESP8266
|
|
|
|
3. microcontroller board + externes WiFi Modul
|
|
### Proof of Concept
|
|
|
|
|
|
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.
|
|
### Prototyp
|
|
|
|
|
|
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)
|
|
### Launch Day 2024
|
|
|
|
|
|
!!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)
|
|
## Simulation ( @istpankwa )
|
|
|
|
|
|
## Proof of Concept
|
|
### Anforderungen
|
|
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.
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
### Proof of Concept
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
### Prototyp
|
|
### Prototyp
|
|
|
|
|
|
### Launch Day 2024 |
|
|
|
\ No newline at end of file |
|
### Launch Day 2024
|
|
|
|
|
|
|
|
|
|
|
|
## Simulation ( @istpankwa )
|
|
|
|
|
|
|
|
### Anforderungen
|
|
|
|
|
|
|
|
|
|
|
|
### Konzepte
|
|
|
|
|
|
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
|
|
|
|
|
|
|
|
### Prototyp
|
|
|
|
|
|
|
|
|
|
|
|
### Launch Day 2024
|
|
|
|
|
|
|