(WS19-01) Wetterballon: Unterschied zwischen den Versionen

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche
(Design)
(Design)
Zeile 179: Zeile 179:
 
====Problem:====
 
====Problem:====
 
Bei den vorhandenen Sensoren sind wir auf kleinere Probleme gestoßen. Alle Sensoren sind bis zu einer Minimaltemperatur von -40°C funktionsfähig. Auf dem Flug werden diese allerdings deutlich unterschritten. Wir haben uns dennoch für den Einsatz dieser Sensoren entschieden, da auf dem Markt keine geeignerten Sensoren zu finden waren. Um Messungenauigkeiten oder gar Ausfälle zu kompensieren, werden wir die Sensoren für den Außeneinsatz mehrfach verbauen. Dabei kann es zu Adresskonflikten der einzelnen Sensoren kommen. Eine Lösung dafür steht noch aus.
 
Bei den vorhandenen Sensoren sind wir auf kleinere Probleme gestoßen. Alle Sensoren sind bis zu einer Minimaltemperatur von -40°C funktionsfähig. Auf dem Flug werden diese allerdings deutlich unterschritten. Wir haben uns dennoch für den Einsatz dieser Sensoren entschieden, da auf dem Markt keine geeignerten Sensoren zu finden waren. Um Messungenauigkeiten oder gar Ausfälle zu kompensieren, werden wir die Sensoren für den Außeneinsatz mehrfach verbauen. Dabei kann es zu Adresskonflikten der einzelnen Sensoren kommen. Eine Lösung dafür steht noch aus.
 +
 +
 +
====Hardware-Architektur====
 +
Eine Skizze der von uns verfolgten Hardwarearchitektur:
 +
 +
[[Datei:HW Architecture.png]]

Version vom 29. November 2019, 12:24 Uhr

Projektbeschreibung

Ziel des Projekts "Wetterballon" ist es, einen Wetterballon starten zu lassen. Diese mit Ballongas gefüllte Latexhülle soll einen Payload, der hauptsächlich aus Sensoren besteht, auf eine Zielhöhe von rund 35 km steigen lassen und während des Auf- und Abstiegs Bild- und Videomaterial sowie verschiedene Messdaten sammeln, speichern und im Idealfall Teile der Daten an eine Basisstation übermitteln. Um den Rest der aufgezeichneten Daten verwenden zu können, ist es wichtig, den Payload nach der Landung wiederfinden zu können. Hierzu sollen verschiedene Ortungsmöglichkeiten verwendet werden.

Grundsätzlich soll auf bereits existierende Hardwaremodule und nur im Notfall auf eigens entwickelte Hardware zurückgegriffen werden. Das Hauptaugenmerk liegt auf der Softwareentwicklung, dem Erkennen von Rückschlägen während des ersten Versuchs und der Vermeidung eben dieser.

Organisation

Teilnehmer

Name Rolle Email
Beckmann, Kai Dozent, Kunde kai.beckmann[at]hs-rm.de
Feller, Manuel Dokumentationsverantwortlicher manuel.feller[at]student.hs-rm.de
Gaida, Jonas QS-Verantwortlicher, Methodikverantwortlicher, Designverantwortlicher jonas.gaida[at]student.hs-rm.de
Müller, Arne Projektleiter, Werkzeugverantwortlicher arne.mueller[at]student.hs-rm.de
Schwarz, Florian Projektleiter, Analyseverantwortlicher florian.schwarz[at]student.hs-rm.de

Werkzeuge

Aufgabe Werkzeug Bemerkung
Versionierung GitLab
Dokumentation GitLab & VS-Wiki
Zeiterfassung Redmine
Simple Kommunikation WhatsApp & Discord
Entwicklungsumgebung Ab Designphase zu klären
Modellierung Modelio

Grober Zeitplan

Phase Zeitraum
Analyse 18.10.2019 - 15.11.2019
Design 08.11.2019 - 22.11.2019
Entwicklung 22.11.2019 - 20.01.2020
Test 20.01.2020 - 03.02.2020
Start 03.02.2020

Phasen und Ergebnisse

Analyse

In der Analysephase wurden die Anforderungen an das Produkt festgestellt und die aus dem Vorjahr bereits verfügbare Hardware katalogisiert und experimentell getestet.

Anforderungen

Im Regelfall entsteht die Liste der Anforderungen durch das Auswerten von Use Cases. Durch die Vorarbeit des Projekts im letzten Jahr standen die Anforderungen in diesem Fall aber schon zur Verfügung und wurden nur noch in eine neue Struktur zusammengefasst.

ID Prio Kategorie Funktion/Modul Beschreibung Abhängigkeit Status Bemerkung
100A110V1 1 Allgemein Flughöhe mindestens 30 km
100A120V1 2 Allgemein Flughöhe mindestens 35 km
100A210V1 1 Allgemein Steiggeschwindigkeit mehr als 5 m/s
100A310V1 2 Allgemein Schutz vor Umwelteinflüssen Hardware vor Luftfeuchtigkeit, Wasser, Temperator und Beschleunigung schützen
100A320V1 1 Allgemein Schutz vor Umwelteinflüssen Messdaten schützen
100A320V1 1 Allgemein Fallgeschwindigkeit maximal 5 m/s unterhalb einer Höhe von 5 km
100A320V1 1 Allgemein Schutz der Umwelt Möglichst geringe Gefährdung bei Landung
100A320V1 1 Allgemein Luftraum Nur inländisch

Da das Ziel des Projekts allerdings die möglichst vollständige Durchführung eines Softwareentwicklungszykluses ist, wurde entschieden, dass die Use Cases trotzdem nachträglich anzufertigen sind.

Inventar

Für die Erfüllung der Anforderungen steht uns folgendes Inventar zur Verfügung.

Anzahl Name Typ Schnittstelle Standardadresse Eignung Einsatzfähigkeit Verbauter Sensor Bemerkung
2 GrovePi0 Adapter GPIO - - - -
1 UV A/UV B Sensor UV I²C 0x10 UV A -40 °C bis +125 °C VEML6075 UV B noch zu klären. Laut Datenblatt nur das Spektrum von 320 bis 400 nm abgedeckt. UV B reicht nur bis 315 nm.
1 Pi Camera V2.1 Kamera - - Bild- & Videoaufnahmen - -
4 High Accuracy Temperature Sensor Temperatur I²C 0x18 Temperatur innen -40 °C bis +125 °C MCP9808 ±0.25°C Messabweichung im relevanten Temperaturbereich.
2 Buzzer Lautsprecher GPIO - Akustisches Signal zur Ortung - -
2 Barometer High Accuracy Barometer I²C 0x76 - - BME280 Druck bei 40 km ~ 8 hpa. Sensor nur für 300 bis 11000 hpa geeignet.
2 IMU 10DOF Kombi 9 Achsen + Barometer I²C 0x68/0x69 Gyroskop & Beschleunigungssensor & Magnetometer -40 °C bis +85 °C MPU-9250 & BME280 Barometer nur bis ca. 9,1 km nutzbar.
3 IMU 9 DOF Kombi 9-Achsen I²C 0x68/0x69 Gyroskop & Beschleunigungssensor & Magnetometer -40 °C bis +85 °C MPU-9250
3 Barometer High Accuracy Barometer I²C 0x76 - -40 °C bis +125 °C HP206C Barometer nur bis ca. 9,1 km geeignet.
1 "UV" Sensor Licht I²C 0x60 Helligkeit -40 °C bis +85 °C Si1145 Nur für Wellenlängen von 400 bis 1000 nm verwendbar. UV im Bereich von 100 bis 380 nm.
1 RFM 95 Funk SPI - LoRaWAN-Übertragung - SX1276 LoRa
0 SHT Humidity Luftfeuchtigkeit I²C 0x44 Luftfeuchtigkeit außen/innen - SHT31
1 TMP 117 Temperatur I²C Temperatur außen

max. ±0.1 °C Abw. bei –20 °C bis +50 °C
max. ±0.15 °C Abw. bei –40 °C bis +70 °C
max. ±0.2 °C Abw. bei –40 °C bis +100 °C
max. ±0.25 °C Abw. bei –55 °C bis +125 °C
max. ±0.3 °C Abw bei –55 °C bis +150 °C

TMP 117
1 USB Camera Bildaufnahmen USB - Bildaufnahmen - - Auflösung für Videoaufnahmen zu gering. Ggf. über Alternative mit höherer Auflösung für Bildaufnahmen nachdenken.
Mögliche Alternativen
Barometer ms5611 10 bis 1200 mbar, -40 bis +85 °C
UVB Sensor ML8511 280 bis 390 nm, -20 to +70 °C
UVB Sensor zopt2202 280 bis 400 nm, -40 bis +70 °C

Hardwaretests

Design

Verbaut werden folgende Sensoren:

Messung Anzahl Name Standardadresse Erfassungsrate Bemerkung
Temperatur innen 1 Grove High Accuracy Temperature Sensor 0x18
Temperatur außen 1 TMP 117 Breakout 0x48
Luftfeuchtigkeit außen 2 SHT 31 0x44
Luftfeuchtigkeit innen 1 SHT 31 0x44
Luftdruck 3 MS5611  ?
9-Achsen 1 IMU 10DOF mit MPU-9250 & BME280 0x68/0x69
Helligkeit 1 Si1145 0x60
UV-A und UV-B 1 ML8511
Kamera Bild 1
Kamera Video 1
GPS 1
LoRaWAN 1
Buzzer 2

Problem:

Bei den vorhandenen Sensoren sind wir auf kleinere Probleme gestoßen. Alle Sensoren sind bis zu einer Minimaltemperatur von -40°C funktionsfähig. Auf dem Flug werden diese allerdings deutlich unterschritten. Wir haben uns dennoch für den Einsatz dieser Sensoren entschieden, da auf dem Markt keine geeignerten Sensoren zu finden waren. Um Messungenauigkeiten oder gar Ausfälle zu kompensieren, werden wir die Sensoren für den Außeneinsatz mehrfach verbauen. Dabei kann es zu Adresskonflikten der einzelnen Sensoren kommen. Eine Lösung dafür steht noch aus.


Hardware-Architektur

Eine Skizze der von uns verfolgten Hardwarearchitektur:

HW Architecture.png