Genaue Spezifikation was wo zu tun ist:

1. Software

1.1. Quarkus Anwendung (4ahif)

  • Konfigfile evaluieren

1.1.1. Daten der I/O Devices vom Koffer

  • Auslesen von Starttaster und Start einleiten

    • LCD-Display Counter Ausgabe und Ansteuerung der Counter LEDs(-Streifen)

  • Schlüsselschalter-stand evaluieren und folglich deaktivierung bestimmter Funktionen

  • Joystick entweder Notfalleingabe (oder zum Steuern von Aktoren der Rakete)

  • Spannung der Zündhardware messen, über Wert des Konfigfiles (Anzahl der Zünder) sollwert Berechnen und wenn zu hoch oder zu niedrig Warnung über Weboberfläche ausgeben und Start nicht Zulassen

Daten der Rakete speichern
Extern

  • Erkennt ob Internetzugang besteht und sendet die Daten an den externen (i guess?) Server

  • Ein Service-Level zB 2 https://assetwolf.com/learn/mqtt-qos-understanding-quality-of-service ist auszuwählen

  • In einem eigenen json-File ist die letzte gesendete Zeile der DB (oder des csv files) einzutragen. (Um sich zu merken was schon extern gespeichert wurde)

    • Dies ist in Form einer Transaktion zu realisieren, zB Verwendung eines lock-Files wegen REENTRANT

  • Müssen Videostreams auch gespeichert werden, (wie)?

Intern

  • Konzept in welcher Form die Daten der Rakete hereinkommen überlegen (von Funkmodulen, Verwender des Koffers müssen sich danach richten)

    • Prof. Ernecker hat alte Raspberrys und WLAN Funkmodule zum testen

  • Schreibt die Daten der Rakete in eine sqlite-db, falls möglich (wird diese korrupt nach einem unsauberen shutdown?), ansonsten in ein csv file ⇒ Aufgabe: testen

    • Einen db-Process mit einem process-kill (kill -9) abgeschossen

    • Anschließend wird kontrolliert ob die sqlite-db noch intakt (konsistent) ist

    • bzw ob eine automatische Reparatur möglich ist

    • Auch in Web Erfahrungen zu diesem Thema suchen

    • Falls nicht möglich evtl. mit einem extra Akku/Powerbank über die der Raspberry noch einen normalen shutdown machen kann?

1.1.2. Testen

  • Die Testkonfiguration ist in einem docker-compose aufzubauen (lokal auf Entwicklungsmaschine) und wird anschließend auf RPi deployed

  • Die Raketenwerte sind zu simulieren/mocken:

    • Primär Luftdruck und Temperatur und Sekundär beliebige Daten wie z.B. Luftqualität, Ozon,.. (auch vom WLAN Modul?)

    • Videostream (nur vom WLAN Modul)

  • Es ist alles ohne "Koffer" zu programmieren (entwickeln, vorführen, testen)

  • Nur hin und wieder auf RPi deployen, um auszuprobieren, ob alles funktioniert

1.2. Webanwendungen (Felix)

1.2.1. Extern

  • Stellt Zugriff auf bisherige Daten, welche auf der externen DB gespeichert sind zur Verfügung.

1.2.2. Für Laptop Lokal

1.2.3. Für Touchdisplay

  • Einstellungen für die Werte im Konfigfile

  • Darstellung von einfachen Daten

  • Warnung ausgeben, wenn der Sollwert der Zündspannung stark über oder unterschritten wird

1.2.4. Testdaten

1.3. Konfigfiles (Alle - jeder das was er braucht)

  • Nutzer sollte nicht direkt auf diese zugreifen können (sondern über Weboberfläche im Koffer)

  • Format überlegen: json, csv,.. ?

  • Einträge:

    • Video ja/nein

    • evtl. Welche Daten man auf dem Touch-Bildschirm ausgeben will?

    • Wie viele Zünder man hat

    • Countdown Zeit

    • Einstellungen welche Aktoren gestoppt werden, wenn Abbruchschalter gedrückt wird

    • Einstellung ob Joystick als Eingabe oder als Steuerung von Aktoren verwendet wird?

    • …​

2. Hardware (Sarah)

  • Liste aller Bauteile anlegen (name, kaufort, preis, benötigte stückzahl, stückzahl vorhanden, datenblatt, versorgungsspannung, verbrauch)

    • auf langfristige Verfügbarkeit der Bauteile achten

  • Anschlüsse aller Bauteile am Raspberry definieren

2.1. Hauptschalter

Raspberry wird hochgefahren, Hauptprogramm wird gestartet (im Boot-Menü einstellen?)

2.2. Stromversorgung

  • Über Netz und Akkus

  • Verbrauch überschlagen und wenn es sich ausgeht einen USV-Hat verwenden

2.3. Zündhardware

  • min. 12V und 2A

  • ohmsche Spannungsmessung für Zündkreis und Zündspannung

2.3.1. Abbruch-Schalter

  • hardwaremäßige Unterbrechung des Zündkabels zu der Kontrolleinheit

  • gleichzeitiges Kurzschließen des Zündkreises

3. Aufgaben Aufteilung

Bis 06.12:

  • Github Milesones & Issues, Besprechung mit Prof. Stütz der Aufgabenaufteilung (ahitm)

  • SQLite auf Raspberry testen und dockern (Sarah, außer jemand anders hat einen Raspberry und möchts gern machen)

Bis Ende Dezember

  • Stromversorgung planung(Sarah)

  • Zündhardware planung (Sarah)

  • Raketenwerte Simulationsprogramm (ahitm)

  • Quarkus Anwendung die mittels MQTT die Raketenwerte empfängt und diese Lokal speichert (ahif)

    • Konzept für Aufbau der Raketenwerte überlegen

Bis Mitte Jannuar

  • Liste der Bauteile (Sarah)

  • In Quarkus Anwendung Einstellungen aus dem Konfigfile für Raketenwerte miteinbeziehen (ahif)

  • Quarkus Anwendung mit Simulationsprogramm testen (ahif)

  • Konzept für die verschiedenen Weboberflächen (Felix)

Bis Ende Jannuar

  • Bauteile einkaufen (Stütz)

  • Planung des Kofferaufbaus abschließen (Sarah)

  • Quarkus Anwendung erweitern → externe Speicherung der Raketendaten (ahif)

Bis Ende Februar

  • Simulationsprogramm Erweiterung - Kofferinputs (ahitm)

  • Quarkus Anwendung erweitern - Kofferinputs über MQTT empfangen und verwenden (ahif)

    • Je nach Einstellungen im Konfigfile müssen die Kofferwerte evaluiert werden

  • Front-End für die erstellung der Config Files (Felix)

Bis Mitte März

  • Quarkus Anwendung mit Simulationsprogramm testen

  • Anzeige der Flugdaten (Felix)

Bis Ende März

  • Quarkus Anwendung - Outputs für Bildschirme bereitstellen (ahif)

    • Lokales Netz aufbauen, Websockets

  • Koffer zusammenbauen (Sarah)

  • Archiv der Flugdaten(Felix)

Bis Mitte April

  • Testwerte Programm mit Phytonanwendung (und mqtt), die die Werte vom Koffer ausließt ersetzen (jemand der phyton kann)

  • Quarkus Anwendung - Joystick Output über Funkmodul (ahif)

  • Aktuellen Stand der Quarkus Applikation auf Koffer testen (je nach Corona, alle oder der der den Koffer daheim hat)

  • Laptop Version der Rocketman Seite(Felix)

systemarchitecture