(WS19-01)Wetterballon Test

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Modultests

Aufgrund der Strukturierung unserer Anwendung gibt es keine klare Grenze zwischen Modul- und Integrationstests, da bereits ab einem frühen Zeitpunkt auch einzelne Sensoren im Zusammenspiel mit dem Master getestet wurden. Lediglich in der Anfangsphase des Projektes, bevor es einen Prototyp für den Master gab, wurden einzelne Sensoren angeschlossen und auf Funktionalität geprüft. Dies könnte man als Modultests beschreiben, allerdings waren diese "Tests" meist experimenteller Natur, da wir uns erst einmal mit der Hardware zurechtfinden mussten. Daher gab es in dieser Phase keine kontrollierten und protokollierten Tests.

Des Weiteren waren Unit-Tests mittels eines automatisierten Programms geplant. Dieses Vorhaben konnte am Ende leider nicht in die Tat umgesetzt werden, da der Betrieb der Software eine Vielzahl von Problemen verursacht hat. Das zeitraubenste dieser Probleme war, dass wegen eines Missverständnisses zunächst eine falsche Lizensierungstechnik verwendet wurde. Daraufhin kam es zu Schwierigkeiten bei der Simulierung der verwendeten Bibliothek auf dem Testrechner. Als das Testprogramm dann wenige Tage vor dem geplanten Start auf einem anderen Rechner, mit funktionierender Simulation, installiert wurde, kam es zu einem weiteren Fehlerzustand. Dieser war nicht kurzfristig zu lösen, weshalb entschieden wurde, das Vorhaben zu Gunsten von dringenderen Angelegenheiten abzubrechen.

Integrationstests

Sobald eine erste Implementierung des Masters vorlag, konnten wir einzelne Sensoren an einen Pi anschließen und tatsächliche Tests in einem realitätsnahen Umfeld testen. Hierbei ging es hauptsächlich darum, die Basisfunktionalität der Sensoren sicherzustellen. So wurde z. B. der Höhensensor auch mal mit nach Hause genommen, um zu überprüfen, ob dieser in verschiedenen Umgebungen plausible Messwerte liefert. Das Ergebnis dieser Tests schlägt sich in der Liste der verbauten Sensoren nieder, da wir durch sie in der Lage waren, festzustellen, welche Sensoren sich für den Einsatz im Payload eigenen.

Höhensensor-Simulator

Zum Testen der Master-Phasenwechsellogik und dem Abschätzen der anfallenden Datenmenge wurde ein virtueller Höhen-Sensor implementiert, der abhängig der verstrichenen Zeit eine Höhe berechnet und zurückgibt.

Herleitung der Höhenformel

Ansatz: Der Flug wird in 4 Phasen unterteilt, Start, Ascension, Descension und Recovery. Der jeweilige Höhenverlauf wird durch eine Geradengleichung angenähert und die jeweilige Gleichung abhängig von der Zeit gewählt.

Gegebene Parameter sollen sein:

  • t_s: zeitliche Länge der Startphase
  • h_p: Platzhöhe/maximale Höhe
  • v_a: Aufstiegsgeschwindigkeit
  • v_d: Abstiegsgeschwindigkeit

Die 4 Phasen werden mit folgenden Zeitmarken getrennt:

  • Start endet mit t_s
  • Ascension mit t_p
  • Descension mit t_l

Ungefähres Aussehen:

Height Sim Function Shape.png

Die allgemeine Formel für eine Geradengleichung lautet f(x) = m*x+c. Auf eine Höhenformel in Abhängigkeit der Zeit übertragen wird daraus h(t) = v*t+h_0.

Herleitung Start Phase Formel

In dieser Phase wird die Höhe als 0 angenommen.

Ergebnis: h_s(t) = 0,\;t \in [0, t_s].

Herleitung Ascension Phase Formel

Die Phase startet mit zeitlicher Verschiebung t_s, daher muss die allgemeine Formel mittels Kenntnissen aus der Analytik (Verschiebung einer Geraden auf der x-Achse) angepasst werden: h(t) = v*(t-t_{offset})+h_0.

Daraus ergibt sich: h_a(t) = v_a*(t-t_s),\;t \in (t_s, t_p]

Herleitung von t_p:

h_a(t_p) = h_p = v_a*(t_p-t_s)

\iff t_p = t_s + \frac{h_p}{v_a}

Ergebnis: h_a(t) = v_a*(t-t_s),\;t \in (t_s, t_s + \frac{h_p}{v_a}]

Herleitung Descension Phase Formel

Um nahtlos an die Ascension Phase anzuschließen, muss die Gerade um t_p nach rechts und um h_p nach oben verschoben werden:

h_d(t) = v_d*(t-t_p)+h_p = v_d*(t-t_s - \frac{h_p}{v_a})+h_p = v_d*(t-t_s)-\frac{h_p*v_d}{v_a}+h_p = v_d*(t-t_s)+(1-\frac{v_d}{v_a})*h_p,\;t \in (t_s + \frac{h_p}{v_a}, t_l]

Herleitung von t_l:

h_d(t_l) = 0 = v_d*(t_l-t_p)+h_p

\iff t_l = -\frac{h_p}{v_d} + t_p = t_s + \frac{h_p}{v_a} - \frac{h_p}{v_d} = t_s + h_p*(\frac{1}{v_a} - \frac{1}{v_d})

Ergebnis: h_d(t) = v_d*(t-t_s)+(1-\frac{v_d}{v_a})*h_p,\;t \in (t_s + \frac{h_p}{v_a}, t_s + h_p*(\frac{1}{v_a} - \frac{1}{v_d})]

Herleitung Recovery Phase Formel

Wie auch in der Startphase wird die Höhe 0 angenommen.

Ergebnis: h_r(t) = 0,\;t > t_s + h_p*(\frac{1}{v_a} - \frac{1}{v_d})

Abschluss Formel

Die Zusammenfassung aller voriger Formeln, die lediglich den Parameter t und die gegebenen Parameter enthält:


h(t) = \left\{
    \begin{array}{ll}
        h_s(t) = 0 &, t \in [0, t_s] \\
        h_a(t) = v_a*(t-t_s) &, t \in (t_s, t_s + \frac{h_p}{v_a}] \\
        h_d(t) = v_d*(t-t_s)+(1-\frac{v_d}{v_a})*h_p &, t \in (t_s + \frac{h_p}{v_a}, t_s + h_p*(\frac{1}{v_a} - \frac{1}{v_d})] \\
        h_r(t) = 0 &, t > t_s + h_p*(\frac{1}{v_a} - \frac{1}{v_d})
    \end{array}
\right.

Real-Time-Clock

Im Laufe der Zeit funktionierte die RTC nicht mehr richtig und warf IO-Fehler. Um Konflikte mit dem ebenfalls auf I2C zugreifenenden Masters auszuschließen, wurde dessen Service deaktiviert, was das Problem leider nicht löste. Recherche im Internet ergab (hier), dass diese Fehlermeldung nicht kritisch wäre und so wurde dieser Fehler zunächst ignoriert, insbesondere weil zu diesem Zeitpunkt das korrekte Funktionieren der RTC (noch) nicht wichtig war und andere Aufgaben höhere Priorität hatten.

Mit Implementierung des Watchdogs und auf Zeitstempel basierte Benennung von Fotos und Videos änderte sich das. Leider wurde das nicht mehr korrekte Verhalten der RTC übersehen, was nach Neustart durch Watchdog und ungünstigem Zeitverhalten zum Überschreiben vorhandener Fotos führen kann.

GPS + LTE-Anbindung

Die Speicherung und Übertragung der GPS-Koordinaten wurden mehrfach erfolgreich getestet. Auffällig war allerdings, dass das GPS-Modul nach einem Neustart auch an einem guten Standort sehr viel Zeit (manchmal dutzende Minuten) benötigt, um valide Satelliten-Signale zu empfangen/auszuwerten.

Programm-Freeze

Mit zunehmender Anzahl an Sensoren und der Anbindung der Kameras wurde ein Problem mit der Programm-Stabilität festgestellt.

Problembeschreibung: Nach einer variablen Zeitdauer, die abhängig der angeschlossenen Gerätezahl und Auslastung ist, hängt sich der Master mit 100 % CPU-Last auf. Der Speichernutzung bleibt während der Laufzeit stabil und steigt auch nicht beim Freeze. Die CPU-Temperatur ist ebenfalls unaufällig.

Versuche mit Height-Sim:

  1. Alles getrennt bis auf HAT -> kein Problem, läuft durch bis Recovery (66 min)
  2. Alles getrennt bis auf HAT -> kein Problem, läuft durch bis Recovery (ganze Nacht)
  3. HAT + I2C-Sensoren -> kein Problem, läuft durch bis Recovery (66 min)
  4. HAT + I2C-Sensoren + Buzzer + Raspicam -> Freeze nach 45 min
  5. HAT + I2C-Sensoren + Buzzer + Raspicam, cycle_len aller Sensoren auf 1ms, Videolänge auf 15 min begrenzt -> CPU-Last normal bei 50%, Freeze nach 5 min
  6. HAT + I2C-Sensoren + Buzzer, cycle_len aller Sensoren auf 1ms -> CPU-Last normal bei 50%, Freeze nach 31 min

Beobachtung: Je höher die Auslastung des Systems im Normalzustand ist, desto schneller tritt dieser Fehlerzustand auf.

Maßnahmen: Da der Fehler nicht gefunden werde konnte, wurden zur Umgehung des Problems Watchdog und Watchpuppy implementiert.

Systemtests

Nachdem der Master und ein Großteil der verwendeten Sensoren implementiert war, konnten organisierte Tests mit dem kompletten System durchgeführt werden.

Aufzugfahrt

In einem ersten Test wurde das System im Aufzug vom 4. Stock des Informatikgebäudes ins 2. Untergeschoss und wieder zurück gefahren, um die Funktionalität des Höhensensors zu testen. Folgende Daten wurden dabei aufgezeichnet:

Aufzug Höhe.PNG

Die Ausgangshöhe von ~280 Metern deckt sich mit verschiedenen Online-Quellen. Die zurückgelegte Distanz von ~18 Metern bei sechs Stockwerken ist ebenfalls plausibel. Der Test wurde daher als Erfolg eingestuft.

Wärmetests

Von der vorherigen Gruppe wussten wir bereits, dass bei der Verwendung von Handwärmern Vorsicht geboten ist. Dort sind Teile der Halterung, die aus Kunststoff bestanden, im Flug geschmolzen. Es wurde daher ein Test mit einigen Handwärmern durchgeführt, um festzustellen, welche Temperaturen erreicht werden. Folgende Daten wurden dabei aufgezeichnet:

Pads Temp.PNG

Wie man sieht, steigt die Temperatur im inneren des Payloads auf bis zu 53 °C an, was in etwa den Minusgraden entspricht, die in Teilen der Atmosphäre, die wir durchfliegen, herrschen. Da außerdem keine Schäden am Payload oder der verwendeten Technik festgestellt wurden, wurde die Menge an Handwärmern für ausreichend befunden.

Das Abfallen der Temperatur zu Beginn der Aufzeichnung ist höchstwahrscheinlich auf ein Öffnen der Box zurückzuführen, wodurch kalte Luft, z. B. durch ein geöffnetes Fenster, in die Box gelangt ist.

Kältetests

Neben den wärmsten möglichen Temperaturen sollten auch die kältesten möglichen Temperaturen getestet werden. Hierfür wurde das System zunächst im Gefrierfach getestet, da dies der kälteste Ort war, der uns zur Verfügung stand. Während der Haupt-Testsphase kam dann die Idee auf, einen Kältetest mit Trockeneis durchzuführen, um tatsächlich die Temperaturen zu simulieren, denen das System ausgesetzt sein wird.

Icetest.jpg

Folgende Daten wurden dabei aufgezeichnet:

Innentemperatur:

Ice Temp.PNG

Außentemperatur:

Ice Temp Innen.PNG

Man sieht, dass die Temperatur innerhalb des Payloads bei einer Außentemperatur von -60 °C lediglich auf -20 °C herabfällt. Aufgrund der fortgeschrittenenZeit am Tag der Durchführung wurde der Test zu diesem Zeitpunkt beendet und das System keiner längeren Kältephase ausgesetzt. Wir haben das Ergebnis dennoch dahingehend interpretiert, dass wir die Zahl der Handwärmer für den tatsächlichen Aufstieg noch einmal reduzieren konnten. Schäden an Payload und Technik konnten auch bei diesem Test nicht festgestellt werden.

In den Diagrammen gibt es einige Auffälligkeiten, die hier erklärt werden sollen: Die zwischenzeitlichen Temperaturanstiege sind auf ein Öffnen der Box zwecks Verbesserung des Testaufbaus zurückzuführen. Der plötzliche Temperaturabfall um 18:55 Uhr liegt daran, dass der äußere Temperatursensor sich zunächst innerhalb der Styroporwand befand und deshalb nicht korrekt aufgezeichnet hat. Durch das Öffnen der Box gelang die Kälte außerdem ins Innere, was die endgültigen Messwerte eventuell verfälscht hat.

Batteriepack

Es wurde weiterhin festgestellt, dass der Pi nicht mehr auf Verbindungsversuche von außen reagiert und sich schließlich aufhängt, wenn die angeschlossene Spannung unter 4,3 V fällt. Um dies zu vermeiden, wurde die Zahl der Batterien von vier auf acht erhöht.

Abnahmetests

Im Gegensatz zu einem klassischen Softwareprojekt gab es bei uns keine Abnahme im Sinne einer Übergabe des Systems an einen Kunden. Stattdessen hat der Start des Ballons diesen Platz im Projektablauf eingenommen. Um so gut wie möglich für den Start vorbereitet zu sein, konnten lediglich überprüft werden, ob die Anforderungen, die zu Beginn des Projekts aufgestellt wurden, erfüllt sind.

Anforderungsabdeckung.pdf