... | ... | @@ -68,12 +68,12 @@ The sensor platform that was developed in [previous projects](2023%20Altimeter%2 |
|
|
|
|
|
## Arbeitspakete
|
|
|
|
|
|
### Projectlead ( @stcomosc )
|
|
|
#### Projectlead ( @stcomosc )
|
|
|
|
|
|
* manage issues
|
|
|
* watch milestones/deadlines
|
|
|
|
|
|
### Mechanical resp ( @stronjin )
|
|
|
#### 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 )
|
... | ... | @@ -87,7 +87,7 @@ The sensor platform that was developed in [previous projects](2023%20Altimeter%2 |
|
|
* Feuerung nach oben/unten/Seite
|
|
|
* eine/mehrere waagzellen
|
|
|
|
|
|
### Simulation ( @istpankwa )
|
|
|
#### Simulation ( @istpankwa )
|
|
|
|
|
|
* Auswahl der Racket Typen Für die Prototypensimulation
|
|
|
* Erweiterung der Komponente des Model für die Simulation
|
... | ... | @@ -95,13 +95,13 @@ The sensor platform that was developed in [previous projects](2023%20Altimeter%2 |
|
|
* Auswahl der Type und Anzahl der Motoren.
|
|
|
* Durchführung der Simulation Validierung des Modells Model
|
|
|
|
|
|
### Software architect ( @stcomosc )
|
|
|
#### Software architect ( @stcomosc )
|
|
|
|
|
|
* API design (OpenAPI aka swagger 3.1.0)
|
|
|
* UI/UX: Webapp design (nodejs framework Vue)
|
|
|
* Sicherheitsfeatures
|
|
|
|
|
|
### Softwaredevolpment ( @istpankwa @stcomosc @stronjin )
|
|
|
#### Softwaredevolpment ( @stcomosc )
|
|
|
|
|
|
* Prüfstand steuern
|
|
|
* Kalibrierung
|
... | ... | @@ -113,9 +113,9 @@ The sensor platform that was developed in [previous projects](2023%20Altimeter%2 |
|
|
* evtl Anpassung bestehender Projekte (Altimeter und WiFi)
|
|
|
* Websocket Implementierung (Übertragung von Livedaten zur Webapp)
|
|
|
|
|
|
## Anforderungen Prüfstand
|
|
|
## Mechanischer Aufbau ( @stronjin )
|
|
|
|
|
|
### Mechanischer Aufbau
|
|
|
### Anforderungen
|
|
|
|
|
|
**Stabilität und Festigkeit:**
|
|
|
|
... | ... | @@ -141,61 +141,7 @@ Der Prüfstand benötigt präzise Mess- und Kontrollsysteme, um den Betrieb des |
|
|
|
|
|
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.
|
|
|
|
|
|
### Software
|
|
|
|
|
|
* 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
|
|
|
|
|
|
### Messtechnik
|
|
|
|
|
|
* Hinreichende Auflösung
|
|
|
* Hinreichende Datenrate
|
|
|
|
|
|
Daten in OpenRocket sind ung 17Hz und aus dem Datenblatt des Herstellers (siehe https://www.thrustcurve.org/motors/Klima/B4/)
|
|
|
* Wichtigster Parameter: Kraft
|
|
|
|
|
|
zu erwarten sind im peak 25N Schub
|
|
|
|
|
|
### Elektronik
|
|
|
|
|
|
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 auch ohne Webapp ausgelesen werden
|
|
|
* **RAM**
|
|
|
* schwer abzuschätzen
|
|
|
* Messdaten könnten auch direkt auf SD oder in freien Flash bereich (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 (3 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
|
|
|
|
|
|
### Mechanischer Aufbau
|
|
|
### Konzepte
|
|
|
|
|
|
**Milestones 1 : Proof of Concept**
|
|
|
|
... | ... | @@ -229,7 +175,31 @@ Hier wird der Teststand so aufgebaut , dass der Raketenmotor eine Horizontale Sc |
|
|
* **Nachteile:**
|
|
|
* Möglicherweise ungenaue Datenerfassung aufgrund der Nichtlinearität der Schubkurve und der Schwierigkeit, genaue Daten zu erhalten.
|
|
|
|
|
|
### Software
|
|
|
|
|
|
### 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:
|
|
|
|
... | ... | @@ -239,15 +209,35 @@ 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.
|
|
|
|
|
|
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 zB 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, welche wie folgt strukturiert ist:
|
|
|
|
|
|

|
|
|
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:
|
|
|
|
|
|

|
|
|
|
|
|
### Messtechnik
|
|
|
|
|
|
### 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:
|
|
|
|
... | ... | @@ -255,9 +245,55 @@ Kraftmessung: |
|
|
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 maximal 80SPS beträgt.
|
|
|
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 )
|
|
|
|
|
|
### Elektronik
|
|
|
### 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):
|
|
|
|
... | ... | @@ -269,4 +305,34 @@ Die Wahl fiel auf das "[LoRa32 V2.1_1.6](http://www.lilygo.cc/products/lora3)" v |
|
|
|
|
|
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) |
|
|
\ No newline at end of file |
|
|
!!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
|
|
|
|