Abschlussdokumentation im Rahmen des Projekts Marine Observation Platform for Surfaces 2

Abteilung Business Engineering Systeme verstehen und optimieren

Themensteller: Betreuer:

Prof. Dr.-Ing. Axel Hahn Dipl.-Inform. Sascha Hornauer

vorgelegt von: Hauke Evers, Nils Giza, Uwe Wilko Grünefeld, Dennis Koers, Markus Alexander Lehmann, Philipp Mählmeyer, David Reiher, Philipp Rudolph, Liliane Anick Tchoua Tsafack, Bastian Veltin, Daniel Weinberg, Sven Wiegand Abgabetermin:

31.03.2014

Inhaltsverzeichnis 1. Einleitung......................................................................................................................................... 1 1.1.Motivation..................................................................................................................................1 1.2.Ziele und Problemstellung.........................................................................................................2 1.3.Anforderungsdefinition..............................................................................................................2 1.3.1.Funktionale Anforderungen............................................................................................... 3 1.3.2.Nicht-funktionale Anforderungen......................................................................................3 1.4.Aufbau der Abschlussdokumentation........................................................................................ 5 2. Projektplanung..................................................................................................................................6 2.1.Vorgehensweise..........................................................................................................................6 2.2.Projektplan.................................................................................................................................7 2.3.Kostenkalkulation......................................................................................................................8 3. Software..........................................................................................................................................11 3.1.Bahnplanung............................................................................................................................ 11 3.1.1.Konzept............................................................................................................................ 11 3.1.2.Offboard Funktionen........................................................................................................14 3.1.3.Priorisierung.....................................................................................................................17 3.1.4.Verwendete Bibliotheken................................................................................................. 18 3.1.4.1.Wegpunktberechnung...............................................................................................18 3.1.4.2.Darstellung............................................................................................................... 18 3.1.5.Fazit..................................................................................................................................19 3.2.Steuerung................................................................................................................................. 21 3.2.1.Ansatz für einen besseren Steueralgorithmus.................................................................. 21 3.2.1.1.Kursabweichung berechnen..................................................................................... 21 3.2.1.2.PI-Regler.................................................................................................................. 22 3.2.1.3.XTE.......................................................................................................................... 23 3.2.2.Evaluation........................................................................................................................ 24 3.3.Android Application................................................................................................................ 24 3.4.Erweiterung der Offboard-Software zur Sensorenunterstützung.............................................25 3.4.1.Messdaten anzeigen......................................................................................................... 26 3.4.2.Sensoren verwalten.......................................................................................................... 26 3.4.3.Sensoren suchen...............................................................................................................26 3.4.4.MySQL Datenbank.......................................................................................................... 27 4. Kommunikation..............................................................................................................................29 4.1.Kommunikation zwischen Onboard- und Offboard-Software.................................................29

4.2.Sensorkommunikation............................................................................................................. 29 4.3.WLAN Access Point................................................................................................................31 4.4.Entwurf der XBee-Antenne..................................................................................................... 32 5. Hardware........................................................................................................................................ 33 5.1.Rumpf...................................................................................................................................... 33 5.1.1.Problemstellung............................................................................................................... 33 5.1.2.Konzept............................................................................................................................35 5.1.3.Heck................................................................................................................................. 36 5.1.3.1.Modellierung............................................................................................................36 5.1.3.2.Umsetzung................................................................................................................37 5.1.3.3.Materialliste Heckkonstruktion................................................................................38 5.1.4.Bug...................................................................................................................................39 5.1.4.1.Modellierung............................................................................................................39 5.1.4.2.Umsetzung................................................................................................................40 5.1.4.3.Materialliste Bugkonstruktion..................................................................................41 5.1.5.Otterboxenkonzept...........................................................................................................41 5.1.5.1.Komponentendiagramm........................................................................................... 42 5.1.5.2.Umsetzung................................................................................................................42 5.1.5.3.Materiallisten der Boxen..........................................................................................42 5.1.5.4.Verkabelung des Sensorboards.................................................................................43 5.1.6.Sensorkäfigkonzept..........................................................................................................44 5.1.6.1.Modellierung............................................................................................................45 5.1.6.2.Umsetzung................................................................................................................45 5.1.6.3.Materialliste Sensorkäfig..........................................................................................46 5.1.6.4.Materialliste Sensoren.............................................................................................. 46 5.1.7.Auftriebsberechnung........................................................................................................46 5.1.7.1.Otterboxen................................................................................................................47 5.1.7.2.Schwimmkörper....................................................................................................... 47 5.1.7.3.Materialliste Schwimmkörper.................................................................................. 48 5.1.8.Ausblick........................................................................................................................... 48 5.2.Sensorik................................................................................................................................... 49 5.2.1.Problemstellung............................................................................................................... 49 5.2.2.Vorgehen...........................................................................................................................50 5.2.3.Systemarchitektur.............................................................................................................51 5.3.Busleitung................................................................................................................................52

5.4.Raspberry Pi.............................................................................................................................54 5.5.Arduino Uno............................................................................................................................ 55 5.6.BeagleBone..............................................................................................................................58 5.6.1.Umstieg vom BeagleBone White zum BeagleBone Black .............................................58 5.6.2.Die Navigations- und Kommunikationsinstrumente........................................................59 5.6.2.1.Neudesign.................................................................................................................59 5.6.2.2.Das GPS................................................................................................................... 59 5.6.2.3.Das Sparkfun Sensorboard....................................................................................... 59 5.6.2.4.Das XBee-Modul......................................................................................................60 5.6.2.5.Die Ansteuerung der Navigationsinstrumente..........................................................60 5.6.3.Ansteuerung der Navigationsinstrumente - Device Tree Overlays..................................60 5.6.4.Kompilieren und Laden eines Device-Trees....................................................................62 5.6.5.Universal Asynchronous Receiver Transmitter................................................................62 5.6.6.Pulsmodulation.................................................................................................................63 5.6.7.Analoge Inputs.................................................................................................................64 5.6.8.Im Betrieb auftretende Probleme..................................................................................... 64 5.7.Fazit......................................................................................................................................... 65 6. Fazit................................................................................................................................................ 66 7. Anhang............................................................................................................................................68 7.1.Bedienungsanleitung................................................................................................................68 7.2.Offboard-Software...................................................................................................................68 7.3.Installation und Voraussetzungen............................................................................................ 68 7.3.1.Benutzeroberfläche.......................................................................................................... 69 7.3.1.1.Einstieg.....................................................................................................................69 7.3.1.2.Funktionalsbereiche..................................................................................................70 7.3.1.3.Menü.........................................................................................................................72 7.3.1.4.Toolbar......................................................................................................................73 7.3.1.5.Statusleiste................................................................................................................74 7.3.2.Bedienung........................................................................................................................ 74 7.3.2.1.Erstellen und bearbeiten einer Mission.................................................................... 74 7.3.2.2.Durchführen eine Mission........................................................................................77 7.3.2.3.Evaluieren einer Missionsdurchführung.................................................................. 78 7.3.2.4.Manuelle Steuerung..................................................................................................80 7.3.2.5.Sensoren verwalten...................................................................................................82 7.4.MOPS Aufbau..........................................................................................................................84

7.4.1.Aufladen der Batterie.......................................................................................................84 7.4.2.Zusammenbau des Bugsegments..................................................................................... 85 7.4.3.Zusammenbau des Hecksegments....................................................................................87 7.4.4.Anbringen der Motoren....................................................................................................90 7.4.5.Verkabelung der Boxen....................................................................................................92 7.4.6.Anbringen der Auftriebskörper........................................................................................95 7.4.7.Befestigung des Sensorkäfigs.......................................................................................... 95 7.4.8.Anbringen der Plane.........................................................................................................96 7.5.Installation BeagleBone...........................................................................................................96 7.5.1.Netzwerkkonfiguration.................................................................................................... 97 7.5.2.Device Tree Konfiguration...............................................................................................97 7.5.3.MOPS Software Installation............................................................................................ 98 7.6.Raspberry Pi Installation..........................................................................................................98 7.6.1.MySQL-Datenbank..........................................................................................................98 7.6.2.Treiber, Kommunikations- / Python-Skripte....................................................................99 7.6.3.Arduino Installation....................................................................................................... 100 7.7.Raspberry Pi, Arduino und Bus vorbereiten..........................................................................100 7.8.Sonstige Dokumente..............................................................................................................101 7.8.1.Materialliste Werkzeug.................................................................................................. 101 7.8.2.Materialliste Sonstige Kosten........................................................................................ 101 7.8.3.Materialliste Recycling.................................................................................................. 102 7.8.4.BeagleBone Cape Schaltplan.........................................................................................104 7.8.5.BeagleBone Cape Boardplan......................................................................................... 105 7.8.6.Komponentendiagramm.................................................................................................106 7.8.7.Projektplan..................................................................................................................... 107 8. Literaturverzeichnis...................................................................................................................... 111

Tabellenverzeichnis Tabelle 1: Funktionale Anforderungen für den MOPS2.......................................................................3 Tabelle 2: Nicht-Funktionale Anforderungen für den MOPS2............................................................4 Tabelle 3: Kleingruppenaufteilung.......................................................................................................7 Tabelle 4: Gesamtkosten.......................................................................................................................8 Tabelle 5: Priorisierung der Funktionen.............................................................................................17 Tabelle 6: Regler Parameter...............................................................................................................23 Tabelle 7: Einstellungen PI Regler.....................................................................................................24 Tabelle 8: Python Befehle...................................................................................................................30 Tabelle 9: Netzwerkkonfiguration......................................................................................................32 Tabelle 10: XBee-Antenne.................................................................................................................32 Tabelle 11: Vor- und Nachteile des Rumpfkörpers.............................................................................35 Tabelle 12: Materialliste Heckkonstruktion *....................................................................................38 Tabelle 13: Materialliste Bug.............................................................................................................41 Tabelle 14: Materiallisten der Boxen..................................................................................................42 Tabelle 15: Verkabelung des Sensorboards........................................................................................43 Tabelle 16: Verkabelung auf dem BeagleBone...................................................................................44 Tabelle 17: Materialliste Sensorkäfig.................................................................................................46 Tabelle 18: Materialliste Sensoren.....................................................................................................46 Tabelle 19: Eigenschaften der Otterboxen..........................................................................................47 Tabelle 20: Berechnung des Auftriebs................................................................................................47 Tabelle 21: Eigenschaften der Schwimmkörper.................................................................................48 Tabelle 22: Materialliste Schwimmkörper.........................................................................................48 Tabelle 23: NMEA2000 Bauteile.......................................................................................................53 Tabelle 24: Kabelspezifikation...........................................................................................................54 Tabelle 25: Status Dioden Arduino Cape...........................................................................................57 Tabelle 26: Adressen der UART Pins.................................................................................................63 Tabelle 27: Duty Werte des Motorcontrollers.....................................................................................63 Tabelle 28: Adressen der PWM Pins..................................................................................................63 Tabelle 29: Raspberry Pi Kontroll LEDs............................................................................................88 Tabelle 30: Arduino Uno Kontroll LEDs...........................................................................................89 Tabelle 31: Pin-Verbindung Sensorboard...........................................................................................90 Tabelle 32: Steckverbindungen..........................................................................................................93

Abbildungsverzeichnis Abbildung 1: MOPS2 auf dem Wasser.................................................................................................1 Abbildung 2: Verteilung der Kosten...................................................................................................10 Abbildung 3: Ablaufdiagramm...........................................................................................................13 Abbildung 4: Hundekurve..................................................................................................................21 Abbildung 5: Kurskorrektur...............................................................................................................22 Abbildung 6: Kursausgleich...............................................................................................................23 Abbildung 7: XTE Berechnung..........................................................................................................24 Abbildung 8: Android Application.....................................................................................................25 Abbildung 9: Datenbankschema.........................................................................................................28 Abbildung 10: Entwicklung des Rumpfkörpers.................................................................................36 Abbildung 11: Heckkonstruktion.......................................................................................................37 Abbildung 12: Bugkonstruktion.........................................................................................................39 Abbildung 13: Antennenkonstruktion................................................................................................40 Abbildung 14: Sensorboard 9 DOF Razer IMU.................................................................................43 Abbildung 15: Verkabelung auf dem BeagleBone.............................................................................44 Abbildung 16: Sensorkäfig.................................................................................................................45 Abbildung 17: SDI-12 Bussystem......................................................................................................52 Abbildung 18: Busleitung...................................................................................................................53 Abbildung 19: Arduino Uno Cape......................................................................................................56 Abbildung 20: Schaltplan Arduino Cape............................................................................................56 Abbildung 21: Benutzeroberfläche im Startzustand...........................................................................70 Abbildung 22: Reiter zur Auswahl des Hauptfunktionsbereiches......................................................71 Abbildung 23: Reiter zur Auswahl des missionsbezogenen Funktionsbereiches...............................71 Abbildung 24: Reiter zur Auswahl der jeweiligen Planungsliste.......................................................72 Abbildung 25: Menüleiste am oberen Rand der Anwendung............................................................72 Abbildung 26: Toolbar bei Startzustand der Software.......................................................................74 Abbildung 27: Statusleiste am unteren Rand der Anwendung...........................................................74 Abbildung 28: Dialog zum Erstellen / Bearbeiten eines Wegpunktes................................................75 Abbildung 29: Dialog für Bereichsauswahl.......................................................................................76 Abbildung 30: Bedienelemente in der Listenansicht für Wegpunkte.................................................76 Abbildung 31: Dialog mit Fehlermeldung.........................................................................................77 Abbildung 32: Bereich zur Durchführung und Überwachung einer Mission....................................78 Abbildung 33: Funktionsbereich der Messdatenerfassung.................................................................79 Abbildung 34: Funktionsbereich der Log-Daten-Erfassung..............................................................80

Abbildung 35: Optionen zur Fernsteuerung.......................................................................................81 Abbildung 36: Grafische Fernsteuerung............................................................................................81 Abbildung 37: Dialog zur Verwaltung der Sensoren..........................................................................83 Abbildung 38: Dialog zur Suche nach verfügbaren Sensoren............................................................84 Abbildung 39: Alukonstruktion ohne Otterboxen und Schwimmerkörper........................................85 Abbildung 40: Blaue Batteriebox.......................................................................................................86 Abbildung 41: Schwarze Otterbox mit Gewichten............................................................................87 Abbildung 42: Rote Elektronikbox....................................................................................................88 Abbildung 43: Gelbe Elektronikbox..................................................................................................89 Abbildung 44: Grüne Elektronikbox..................................................................................................90 Abbildung 45: Befestigung der Motoren am Optimisten...................................................................91 Abbildung 46: Befestigung des Stabilisierungsprofils.......................................................................92 Abbildung 47: Verkabelung Otterboxen.............................................................................................93 Abbildung 48: Verkabelung Backbord bzw. Busleitungen.................................................................94 Abbildung 49: Befestigung der Schwimmkörper...............................................................................95 Abbildung 50: Befestigung der Plane.................................................................................................96

Verzeichnis der Abkürzungen und Akronyme AIN AIS BB CAN GPIO GPS I2C IMO MOPS NMEA PWM SCL SDA SDI12 UART USB WLAN XTE

Analog Input Device Automatic Identification System BeagleBone Controller Area Network General Purpose Input/Output Global Positioning System Inter-integrated Circuit Internationale Seeschifffahrts-Organisation Marine Observation Platform for Surfaces National Marine Electronics Association Pulsweitenmodulation Serial Clock Serial Data Signal Serial Data Interface at 1200 Baud Universal Asynchronous Receiver Transmitter Universal Serial Bus Wireless Local Area Network Cross Track Error (Querabweichung)

1. Einleitung 1.1. Motivation Die Projektgruppe Marine Observation Platform for Surfaces 2 (MOPS2) wurde von insgesamt 12 Studenten der (Wirtschafts-) Informatik im Rahmen ihres Masterstudiums über den Zeitraum von einem Jahr durchgeführt. Angeknüpft wird dabei an die Ergebnisse der vorherigen Projektgruppe MOPS. Dieses Dokument stellt den Abschlussbericht dar, der die Zielsetzung, die erarbeiteten Konzepte und die erreichten Ziele der Projektgruppe näher darstellt und erläutert. Für die Ergebnisse der vorherigen Projektgruppe, auf welchen aufgesetzt wird, verweisen wir auf deren Abschlussbericht [AB].

Abbildung 1: MOPS2 auf dem Wasser

1.2. Ziele und Problemstellung Ziel ist die Weiter- und teilweise Neuentwicklung eines autonomen Wasserfahrzeuges, welches in der Lage ist, Messungen von Wasserparametern einzuholen. Auftraggeber dieses Projektes ist Prof. Dr. Zielinski vom Institut für Chemie und Biologie des Meeres der Universität Oldenburg 1. Die grundlegenden Anforderungen des Projektes wurden vom Auftraggeber vorgegeben. Der Einsatzbereich und das Szenario wurde im Vergleich zu der vorherigen Projektgruppe erweitert. Der neue Einsatzbereich des MOPS ist die Wesermündung. Hierbei soll der MOPS beispielsweise nach Vertiefungsarbeiten durch Baggerschiffe die ausgebaggerten Bereiche autonom abfahren, um in diesem Gebiet mittels Sensoren Messungen von Schweb- und Trübstoffen innerhalb des Wassers vorzunehmen. Dazu soll es möglich sein ganze Bereiche innerhalb der Planungssoftware zu markieren, welche vom MOPS anschließend autonom abgefahren werden. Da in der Wesermündung ein reger Schiffsverkehr herrscht, ist es zusätzlich erforderlich, Sperrgebiete wie z.B. Fahrrinnen zu definieren, welche vom MOPS nicht befahren werden dürfen.

1.3. Anforderungsdefinition Im Folgenden werden die funktionalen und nicht-funktionalen Anforderungen tabellarisch aufgelistet. Die Anforderungen wurden zu Beginn der Projektgruppe gemeinschaftlich diskutiert und festgelegt. Dabei wurden auch die Anforderungen der alten Projektgruppe berücksichtigt und zum Teil übernommen und angepasst.

1 http://www.icbm.de/marine-sensorsysteme

2

1.3.1.Funktionale Anforderungen ID

Name

Beschreibung

FA00

Manuelle Steuerung

Der MOPS2 muss über eine Software manuell gesteuert werden können.

FA01

Missionen erledigen

Der MOPS2 muss eine vorher festgelegte Mission autonom abfahren können.

FA02

Missionen verwalten

Die MOPS2-Software muss in der Lage sein Missionen zu verwalten.

FA03

Sensoren verwalten

Die MOPS2-Software muss in der Lage sein Sensoren zu verwalten.

FA04

Messungen durchführen

Der MOPS2 muss in der Lage sein autonom Messungen durchzuführen.

FA05

Messungen exportieren

Die MOPS2-Software muss die Möglichkeit bieten, die durchgeführten Messungen in ein allgemein bekanntes Format zu exportieren.

Tabelle 1: Funktionale Anforderungen für den MOPS2

1.3.2.Nicht-funktionale Anforderungen

ID

Name

Beschreibung

NFA00

Schwimmfähigkeit

Der MOPS2 sollte auch bei einer Wellenhöhe von 1,5 Metern noch schwimmfähig sein.

NFA01

Größe

Der MOPS2 sollte aus Transportgründen eine kleine Größe aufweisen, damit er auch mit einem kleinen Anhänger transportiert werden kann.

NFA02

Gewicht

Der MOPS2 sollte in einsatzbereitem Zustand von weniger als 5 Personen getragen werden können. Darüber hinaus sollte das Gewicht so gering wie möglich gehalten werden um Energie zu sparen.

NFA03

Einsatzbereitschaft

Der MOPS2 soll innerhalb von 15 Minuten ohne Spezialwerkzeug zusammengebaut werden können. Außerdem soll dies auch von einem kleinen Team von beispielsweise nur zwei Personen bewerkstelligt werden können.

3

NFA04

Einsatzzeit

Der MOPS2 sollte mindestens 8 Stunden lang einsetzbar sein.

NFA05

Manövrierfähigkeit

Der MOPS2 sollte wendig sein und die Manövrierfähigkeit soll nicht unnötig eingeschränkt sein, damit auch in kleinen, engen Gewässern bspw. Flüssen Wegpunkte gezielt angefahren werden können.

NFA06

Sensortiefe

Die Sensoren, im besonderen der Trübungssensor, sollen in genau 1 Meter Tiefe angebracht werden.

NFA07

Kollisionsverhütung

Der MOPS2 sollte Kollisionen bei autonomen Betrieb (siehe FA01) vermeiden.

NFA08

Auffindbarkeit

Der MOPS2 sollte immer auffindbar sein, auch wenn es bei einer Mission (siehe FA01) zu Problemen kommt.

NFA09

Schlepp- und Bergbarkeit

Ergänzend zu NFA08 sollte der MOPS2 auch im Fehlerfall schlepp- und bergbar sein.

NFA10

Wartbarkeit

Der MOPS2 sollte einfach zu warten sein.

NFA11

Flexibilität der Sensorik

Die Sensoren sollten sich leicht austauschen und verändern lassen.

NFA12

Sicherheit

Der MOPS2 sollte für den Anwender sicher bedienbar sein.

NFA13

Steuerungsreichweite

Der MOPS2 sollte über mehrere 100 Meter über eine beliebige Verbindung erreichbar sein.

NFA14

Robustheit

Der MOPS2 sollte auch an den Rumpf schlagende Wellen ohne Einbussen der Funktionstüchtigkeit überstehen und auch bei größeren Wellen nicht kentern.

NFA15

Sicherheit der Ladung

Der MOPS2 sollte auch beim Kentern keine Ladung (Elektronik, Batterien, usw.) verlieren.

NFA16

Umweltschutz

Der MOPS2 soll auch in Naturschutzgebieten eingesetzt werden können und darf deshalb keine umweltschädlichen Stoffe verbaut haben oder an die Umwelt abgeben.

Tabelle 2: Nicht-Funktionale Anforderungen für den MOPS2

4

1.4. Aufbau der Abschlussdokumentation Nach der Einleitung mit den allgemeinen Zielen der Projektgruppe folgt im nächsten Abschnitt ein Überblick

über

die

Projektplanung

inklusive

der

Kleingruppenorganisation

und

einer

Kostenkalkulation. Anschließend folgen detaillierte Darstellungen der erarbeiteten Konzepte, der durchgeführten Tätigkeiten und der erreichten Ziele, aufgeteilt in die Abschnitte Software, Sensoren, Kommunikation und Hardware. Zusätzlich wurde ein Benutzerhandbuch erstellt, welches die Bedienung der Software, den Aufbau und die Konfiguration der Hardware beschreibt. Zum Abschluss erfolgt noch ein allgemeines Fazit und ein Ausblick.

5

2. Projektplanung Dieser Abschnitt beschäftigt sich mit der Projektplanung. Zunächst wird die allgemeine Vorgehensweise beschrieben, gefolgt von einem Projektplan und der Projektorganisation. Abschließend erfolgt noch eine Kostenkalkulation.

2.1. Vorgehensweise Um möglichst flexibel beim Erstellungsprozess zu bleiben, wurde Prototyping mit verschiedenen Ausprägungen verwendet. Im Allgemeinen ist Prototyping [EO] ein iteratives Entwicklungsmodell, welches klare Vor- und Nachteile besitzt. Das iterative Vorgehen erlaubt es, schnelles Feedback zu jedem Durchgang zu bekommen und den Prototypen frühzeitig anzupassen. Beim evolutionären Prototyping wird als erster Prototyp ein Programm mit den wichtigsten Funktionalitäten entwickelt, welches daraufhin dem Benutzer gezeigt wird. Der Benutzer sorgt durch sein Feedback dafür, dass in der nächsten Iterationsstufe seine Wünsche berücksichtigt werden. Durch dieses Vorgehen, wird zusätzlicher Aufwand durch die eventuell nötigen Anpassungen bezüglich des Feedbacks erzeugt, aber es kann schnell festgestellt werden, ob die Entwicklung in eine gewünschte Richtung geht. In dem Fall der Projektgruppe hat sich das Vorgehensmodell Evolutionärer Prototyp als sinnvoll erwiesen, weil durch den Austausch zwischen Anwendern und Entwicklern der Software ein benutzerzentrierter Entwicklungsprozess geführt werden konnte, wodurch die lauffähige Version in jeder Iterationsstufe, um weitere Funktionen ergänzt werden konnte. Ebenso wurden bei der Erstellung des Rumpfs, die Grundfunktionen schnell bereitgestellt und mit Feedback aus den einzelnen Gruppen erweitert. So sind besonders Funktionen entwickelt worden, welche direkt für andere Gruppen wichtig sind. Die Sensorik wurde mit einer anderen Unterart des Prototyping entwickelt. Hier kam experimentelles Prototyping zum Einsatz. Zunächst wurden verschiedene Möglichkeiten zur Umsetzung erarbeitet und gesammelt. Anschließend wurde daraus ein Konzept erstellt und umgesetzt. Dieses Konzept wurde dann in weiteren Iterationen durch die gesammelten Erfahrungen fortlaufend erweitert.

6

2.2. Projektplan Nach einer anfänglichen Seminar- und allgemeinen Orientierungsphase wurde die gesamte Projektgruppe in die verschiedenen Kleingruppen Bahnplanung, Sensoren, Steuerung, Rumpf und Dokumentation, später auch BeagleBone aufgeteilt.

Die einzelnen Kleingruppen haben

verschiedene Aufgaben selbstständig in Absprache mit den anderen Kleingruppen bearbeitet. Der Projektplan stellt einen Überblick über die durchgeführten Aufgaben der Kleingruppen dar. Im Anhang ist dieser abgebildet. Die Tabelle 3 zeigt eine Übersicht über die verschiedenen Kleingruppen. Die Aufteilung hat sich im Laufe des Projektes gelegentlich etwas verschoben, da sich durch unterschiedliche Ereignisse die Randbedingungen geändert haben und eine höhere Priorisierung einzelner Bereiche nötig wurde. Auf Grund dieses Umstandes sind Beteiligte in mehr als einer Gruppe tätig gewesen und somit auch mehrfach an dieser Stelle aufgeführt. Eine Besonderheit stellt dabei die Kleingruppe BeagleBone dar. Zu Beginn der Projektgruppe wurde ein Wechsel auf eine neue BeagleBone-Version und die Erstellung eines neuen Capes nicht eingeplant. Diese Kleingruppe wurde während des Verlaufs kurzfristig aufgrund der Erfordernisse gebildet. Dies führte dazu, dass Arbeiten an der Bahnplanung und der Steuerung zwischenzeitlich zurückgestellt wurden.

BeagleBone

Hauke Evers, David Reiher, Philipp Rudolph, Bastian Veltin, Sven Wiegand

Bahnplanung

Hauke Evers, Bastian Veltin, David Reiher

Sensoren

Uwe Grünefeld, Markus Lehman, Liliane Anick Tchoua Tsafack, Daniel Weinberg

Rumpf

Nils Giza, Dennis Koers, Philipp Mählmeyer, (Uwe Grünefeld)

Steuerung

Philipp Rudolph, Sven Wiegand, David Reiher

Dokumentation

Alle

Tabelle 3: Kleingruppenaufteilung

7

2.3. Kostenkalkulation

Gruppierung

Bezeichnung

Kosten (€)

Rumpfkonstruktion

Heckkonstruktion

46,4

Bugkonstruktion

46,8

Schwimmkörper

57,6

Otterboxen

134,5

Kosten der Rumpfkonstruktion

284,76

Prozentualer Anteil der Rumpfkonstruktion am Gesamtwert 2

6,23%

Sensorkonstruktion

Sensoren

2295

Busleitung

539,6

Sensorkäfig

89,4

Kosten für Sensorkonstruktionen

2924

Prozentualer Anteil der Sensorkonstruktion am Gesamtwert 2

63,99%

Elektronik

BeagleBone

45

Raspberry Pi

34

Raspberry Pi Gehäuse

7,49

Arduino Uno

22,99

Sabertooth Dual 60A 6V - 30V

166,31

W-LAN Stick

14,95

USB A auf B Kabel

3,99

Kosten der Elektronikkomponenten

294,73

Prozentualer Anteil der Elektronikkomponenten am Gesamtwert 2

6,45%

Werkzeuge

489,41

Sonstige Kosten

154,01

Materialien von MOPS 1

1065,73

Prozentualer Anteil des Recyclings am Rumpf am Gesamtwert 2

23,32%

Gesamtkosten

4146,91

Gesamtwert 1 des MOPS2 (ohne Werkzeuge)

3503,49

Gesamtwert 2 des MOPS2 (ohne Werkzeuge und Recycling)

4569,22

Tabelle 4: Gesamtkosten

8

In Tabelle 4 sind alle Kosten, die während der Projektgruppe angefallen sind, aufgelistet. Dazu wurden folgende Gruppierungen vorgenommen: 1. Rumpfkonstruktion: Zu dieser Gruppierung gehören die Heck- und Bugkonstruktion, die Schwimmkörper und die Otterboxen. Die genaue Zusammensetzung dieser Unterkategorien sind in Materialliste Heckkonstruktion Kapitel 5.1.3.3, Materialliste Bugkonstruktion, Materialliste Schwimmkörper Kapitel 5.1.4.3. wiederzufinden. In der Rumpfkonstruktion sind fünf Otterboxen verbaut. Hier muss erwähnt werden, dass in dieser Konstruktion keine recycelten Materialien des MOPS1 aufgeführt sind. Zusammen sind hier für Realisierung Kosten in Höhe von 284,76€ aufgetreten. 2. Sensorkonstruktion: Zu dieser Gruppierungen gehören jegliche Materialien und damit einschließlich die Sensoren selbst, die einen Großteil der Kosten (2295€) ausmachen (siehe Kapitel 5.1.6.4. Materialliste Sensoren). Zu dem ist die Bus-Leitung mit wasserdichten Steckern relativ teuer (siehe Kapitel 5.3. Bus-Leitung). Der Sensorkäfig wurde aus Aluminiumprofilen eigenständig zusammengebaut und nehmen damit einen geringen Anteil an die Kosten für die Sensorkonstruktion ein (siehe Kapitel 5.1.6.3. Materialliste Sensorkonstruktion). 3. Elektronik: Zur Elektronik gehören die verbauten Komponenten in den Otterboxen. Dazu gehören, das Arduino, das BeagleBone Black, das Raspberry Pi und Gehäuse, der Motorcontroller Sabertooth 2x60, ein W-LAN Stick, ein Kabel. Kleinere Komponenten wie z.B. eine Relais wurden hier nicht mit eingerechnet. Darüber hinaus gibt es noch weitere Kostenpunkte: 1. Werkzeuge: Um den MOPS2 zu planen, konstruieren und zu erstellen benötigte die Projektgruppe Werkzeuge, die gewisse Anforderungen erfüllen mussten. In der Materialliste Werkzeuge im Anhang 7.8.1. sind alle Werkzeuge aufgelistet. Mit Kosten von 489,41€ ist dies ein erheblicher Faktor in der Gesamtkostenkalkulation als sekundärer Kostenfaktor, da dieser nicht im Gesamtwert 1 oder 2 mit einberechnet wird. 2. Sonstige Kosten: Unter sonstige Kosten sind grundlegende elektronische Bauteile wie LEDs, Widerstände, etc. und Gegenstände, welche vor Ort aus einem Baumarkt besorgt werden konnten, aufgeführt. Die vollständige Materialliste Sonstige Kosten ist ebenfalls im Anhang aufgeführt (7.8.2.). 3. Recycling: Ein gewünschter Faktor stellt das Wiederverwerten von Materialien des MOPS1 dar. Hierzu wurden während der gesamten Planung des MOPS2 Ideen, Konzepte und Modelle entwickelt, inwiefern Materialien des MOPS1 verändert und für unsere Zwecke 9

angeordnet werden können. Dieses Konzept zieht sich durch den gesamten Prozess der Entwicklung sowohl bei Hardware- als auch Softwareentscheidungen. Dadurch konnten 56% der alten Materialien wiederverwendet werden, das entspricht einem Materialwert von 1065,73€. Eine genaue Auflistung ist im Anhang unter 7.8.3. Materialliste Recycling zu finden. Im unteren Teil der Auflistung der Gesamtkosten mit 4146,91€ sind neben den Gesamtkosten der Projektgruppe mit 4196,41€ auch der Gesamtwert des MOPS2 mit Recycling 4569,22€ (siehe Gesamtwert 2) und ohne Recycling 3503,49€ (siehe Gesamtwert 1) wiederzufinden. Darüber hinaus gibt das Abbildung 2 - Verteilung der Kosten eine Übersicht über die prozentualen Anteile der Kosten der Gruppierungen (Rumpf-, Sensorkonstruktion, Elektronikkomponenten und Recycling) im Verhältnis zum Gesamtwert 2 mit Recycling und ohne Werkzeuge an. Hierbei ist festzuhalten, dass gerade die Sensorkonstruktion den größten Anteil mit 64% des Gesamtwerts 2 annimmt. Da die Sensoren einen besonderen Stellenwert in der Projektgruppe besitzen und diese die gewünschten Sensoren von Prof. Dr. Zielinski sind, konnte hier nicht angesetzt werden, um Kosten zu sparen. Im Gegenzug dazu stellen die wiederverwendeten Materialien einen Anteil von 23% des Gesamtwerts 2 dar. Durch diesen hohen Anteil wurde der Kostenaufwand so gering wie möglich gehalten.

Abbildung 2: Verteilung der Kosten

10

3. Software Dieses Kapitel beinhaltet die Beschreibung der Software-relevanten Ergebnisse. Zunächst wird Bezug auf die Änderungen und Erweiterungen der Offboard-Software genommen. Es wurde ein Konzept erstellt, eine Priorisierung vorgenommen und schließlich Funktionen mit hohem funktionalen Mehrwert entwickelt und umgesetzt. Ein weiterer wichtiger Softwarebereich ist die Steuerung

und

ihre

Verbesserungen.

Der

im

Rahmen

der

Projektgruppe

verbesserte

Steuerungsalgorithmus wird ausführlich erläutert und es findet eine kleine Evaluation zur Wahl der Parameter statt. Abgeschlossen wird das Kapitel mit der Beschreibung einer im Rahmen der Projektgruppe entwickelten Android-Anwendung, welche es dem Benutzer ermöglicht den MOPS manuell zu steuern und wichtige Hardwarekomponenten neu zu starten

3.1. Bahnplanung Aufgabe der Bahnplanung ist es, die Route, welche der MOPS im Laufe der Mission fahren soll, zu planen und die Durchführung der Mission zu überwachen. Hierzu wurde von der vorherigen Projektgruppe MOPS bereits eine Software, im Folgenden Offboard-Software genannt, entwickelt. Die Offboard-Software ermöglicht es Wegpunkte anzulegen, diese an den MOPS zu übertragen und die Durchführung einer Mission zu überwachen. Im Rahmen der Projektgruppe MOPS2 wurde diese Software um zusätzliche Funktionen erweitert. Der folgende Abschnitt beschäftigt sich mit dem neu erstellten erweiterten Konzept der Offboard-Software. Anschließend werden die einzelnen Funktionen, welche sich aus dem Konzept ableiten, dargestellt und priorisiert. Des Weiteren werden im Abschnitt “Verwendete Bibliotheken” kurz die zur Realisierung der zusätzlichen Funktionen verwendeten Bibliotheken dargestellt. Zum Abschluss wird ein Fazit der Bahnplanung gezogen und ein Ausblick auf weitere mögliche umsetzbare Funktionen gegeben.

3.1.1.Konzept Die Abbildung 3 - Ablaufdiagramm zeigt den konzeptuellen Ablauf der MOPS Missionsplanung. Die Missionsplanung startet damit, dass die MOPS-Eigenschaften wie Tiefgang, Geschwindigkeit und Wendekreis eingelesen werden. Diese werden aus einer Datei geladen, können aber innerhalb der Software auch angepasst werden. Anschließend werden die Umgebungsinformationen eingelesen. Dies sind Daten aus OpenSeaMap-Karten, Strömungskarten, Seekarten und

11

Informationen aus einem Online-AIS-Dienst. Mit Hilfe der eingelesenen Informationen wird eine Umgebung erzeugt, die auch dem Nutzer angezeigt wird. Der Nutzer hat die Möglichkeit, durch die Ebenen-basierte Darstellung einzelne Ebenen ein- oder auszublenden. Anschließend kann der Nutzer die Route planen, indem er einzelne Messpunkte einträgt, nicht befahrbare Bereiche definiert, eine Linienmessung einträgt oder einen Messbereich angibt. Das System erzeugt automatisch Wegpunkte in der richtigen Reihenfolge in den gewünschten Abständen. Außerdem hat der Nutzer hier die Möglichkeit, nachdem die Wegpunkte automatisch erzeugt wurden, Änderungen an diesen durchzuführen. Die Wegpunkte können verschoben, gelöscht oder geändert werden. Mit den aktualisierten Daten und allen verfügbaren Informationen berechnet das Tool mittels eines Bahnplanungsverfahren eine optimale Route, welche anschließend inklusive der Umgebung an den MOPS übertragen wird.

12

Abbildung 3: Ablaufdiagramm

13

3.1.2.Offboard Funktionen Die in der Tabelle 5 dargestellten Funktionen sind aus dem Ablaufdiagramm (siehe Abbildung 3) abgeleitet. Hierbei wird jede Funktion namentlich genannt und kurz beschrieben. Zusätzlich ist angegeben, ob diese Funktion im Rahmen der Projektgruppe umgesetzt wurde. Aufschluss darüber, warum Funktion umgesetzt oder nicht umgesetzt wurden, erfolgt in der anschließend dargestellten Priorisierung.

Name der Funktion

Kurzbeschreibung

Umgesetzt

Eigenschaften des MOPS Bearbeiten

Wendekreis, Geschwindigkeit und andere Informationen können bearbeitet und abgespeichert werden.

Nein

Strömungskarten

Strömungsinformationen können in die Bahnplanung mit einbezogen werden.

Nein

Framework zum Darstellen der Das ebenenbasierte Framework kann zur Umgebungsinformationen Darstellung verschiedener Informationen (Strömung, Gezeiten, Wetter) genutzt werden.

Nein

Seekarten

Seekarten können eingelesen und dargestellt werden.

Nein

Online-AIS-Informationen

AIS-Informationen können von Webdiensten auf Wunsch eingeblendet werden.

Nein

Windgeschwindigkeiten

Windgeschwindigkeiten können von einem Webdienst abgerufen und weiter verwendet werden.

Nein

Anbindung AIS

Ein AIS-System kann ausgelesen und verarbeitet werden.

Nein

Kollisionsvermeidung

Nahende Kollisionen werden erkannt und die Route wird neu geplant.

Nein

Usability Allgemein

- An möglichst allen Stellen, an denen es sinnvoll und möglich ist Keylistener, zum Beispiel “Enter” zum Bestätigen eines Eingabedialoges. - Menüeinträge und Buttons, deren Aktionen im aktuellen Zustand nicht möglich sind, deaktivieren. - Darstellungsfehler in Text und Grafiken beheben

Ja

14

Toolbar

Eine Toolbar mit Buttons für die wichtigsten Interaktionsmöglichkeiten wird integriert. So werden umständliche Menünavigationen vermieden.

Ja

Look & Feel

Das standardmäßige Java-Look&Feel wird durch das Look&Feel des aktuell genutzten Betriebssystems ersetzt. Dadurch ergibt sich für den Nutzer ein homogener und angenehmer Gesamteindruck.

Ja

Socketimplemtierung zur Zusammenarbeit mit der Sensorengruppe Kommunikation mit der für die (Socketimplementierung in der OnboardSensoren verantwortlichen Software) Software

Ja

Automatisches Optimieren und Die Route kann auf Wunsch automatisch optimiert Ja Berechnen der Route werden. Mindestradius eines Wegpunktes

Für Wegpunkte muss ein Mindestradius erforderlich sein. Bei fehlender Eingabe oder einem Wert kleiner als dem minimal erforderlichen (als globale Konstante definiert) wird eine Fehlermeldung ausgegeben und der Wegpunkt nicht angelegt.

Ja

Radius grafisch darstellen

Der Radius eines Wegpunktes wird grafisch auf der Missionskarte dargestellt. Ist zusätzlich eine Verweildauer eingestellt, wird der entsprechende Kreis farblich hervorgehoben.

Ja

Bessere Darstellung von GPSStatus-Wegpunkten

Es soll ein neues, besser erkennbares Icon für die GPS-Status-Wegpunkte eingeführt werden.

Ja

Korrekte Ausrichtung der Grafik für die aktuelle Position

Die Ausrichtung der Grafik, welche die aktuelle Position des Wasserfahrzeugs repräsentiert soll korrekt ausgerichtet, je nach Fahrtrichtung, angezeigt werden. Daraus ergab sich außerdem der Bedarf nach einer neuen, sich von den Wegpunkten unterscheidenden Grafik.

Ja

Linienmessungen

Eine Linienmessung wird mit einem Start- und Endpunkt eingetragen.

Ja

Sperrgebiete

Nicht befahrbares Terrain kann markiert werden und wird nicht befahren.

Ja

Bereichsmessungen

Eine Bereichsmessung kann durch Aufziehen eines Rechtecks eingetragen werden. Die Wegpunkte werden automatisch berechnet.

Ja

Sperrgebietvermeidung

Die Route kann auf Wunsch automatisch um Sperrgebiete herumgelegt werden. Hierfür werden

Ja

15

zusätzliche Wegpunkte angelegt. Optimierung der Route

Die Route kann so optimiert werden, dass während der Mission ein möglichst kurzer Weg gefahren wird.

Ja

Übertragung der Route an den MOPS anpassen

Zusätzliche Routeninformationen können übertragen werden.

Ja

Undo-Redo

Undo-Redo Funktionen für das leichtere Wegpunkte Bearbeiten.

Ja

Toolbar

Es gibt eine Toolbar, die die wesentlichen Funktionen stets erreichbar macht.

Ja

Wegpunkte durch anklicken auf Karte selektierbar

Wird auf die Grafik eines Wegpunktes in der Karte oder dem entsprechenden Listeneintrag geklickt, wird dieser sowohl in der Liste als auch optisch (siehe nächster Punkt) selektiert.

Ja

Hervorheben von selektierten Wegpunkten

Ausgewählte Wegpunkte werden hervorgehoben dargestellt.

Ja

Wegpunkte durch Doppelklick editierbar

Wird auf die Grafik eines Wegpunktes in der Karte oder dem entsprechenden Listeneintrag doppelt geklickt, öffnet sich für diesen der Bearbeitungsdialog.

Ja

Drag & Drop von Wegpunkten

Per Drag & Drop können Wegpunkte direkt auf der grafischen Karte verschoben werden.

Ja

Änderung der Route durch verschieben der Wegpunkte in der Liste

Die Reihenfolge der Wegpunkte kann durch verschieben dieser in der Liste angepasst werden.

Ja

Kontextmenüs für Wegpunkte

Per Rechtsklick auf einen Wegpunkt wird ein Kontextmenüs zum Interagieren (Bearbeiten, Löschen) geöffnet.

Ja

Menüs überarbeiten

Nicht mögliche Optionen werden in den Menüs ausgegraut, um die Benutzerfreundlichkeit zu erhöhen.

Ja

Darstellung der Wegpunkte

Auf der Karte werden Weg- und Messpunkte durch unterschiedliche Farben besser unterscheidbar gemacht.

Ja

Darstellung der Wegpunkte in Listenansicht

Die Messungen werden in verschiedenen Tabs angezeigt und können dort auch bearbeitet werden.

Ja

Darstellung der Bearbeitungspanels

Das Bearbeitungspanel und seine Buttons wurden neu aufgeteilt, um die Übersichtlichkeit zu

Ja

16

erhöhen. Zusammenführung von Die Tabs für die Missionsplanung und Planungs- und Monitoringkarte -überwachung wurden zusammengeführt. So ist nur noch eine interaktive Karte vorhanden, wodurch (aus dem Internet) zu ladende Daten reduziert werden. Zusätzlich ist hierdurch immer gegeben, dass bei Planung und Überwachung der selbe Kartenausschnitt mit der selben ZoomEinstellung zu sehen ist.

Ja

Rückgängig

Wie aus gängigen Anwendungen bekannt, ist es Ja möglich gewisse Aktionen, wie das Anlegen eines neuen Wegpunktes, rückgängig zu machen. Dies geschieht über einen Menüeintrag, Toolbar-Button oder die Tastenkombination STRG+Z.

Wiederherstellen

Wie aus gängigen Anwendungen bekannt, ist es möglich zuvor Rückgängig gemachte Aktionen wiederherzustellen. Dies geschieht über einen Menüeintrag, Toolbar-Button oder die Tastenkombination STRG+Y.

Ja

Tabelle 5: Priorisierung der Funktionen

3.1.3.Priorisierung Um alle geplanten Funktionen in eine sinnvolle Reihenfolge zu bringen, wurde eine Priorisierung vorgenommen. Die zusätzliche Bearbeitung der Umgebung - dazu zählen Sperrbereiche, Linienmessungen und Bereichsmessungen - wurden hoch priorisiert, da sie einen direkten funktionalen Mehrwert für die Offboard-Software vorweisen. Hierzu zählt auch die optionale Optimierung der Route mittels eines Optimierungsverfahrens, um eine möglichst kurze Gesamtwegstrecke zu erreichen. Ein weiteres Augenmerk wurde auf die Verbesserung des bestehenden Softwaresystems gelegt, um die Betriebsstabilität zu erhöhen und die Usability zu verbessern. Darunter fallen viele kleinere Änderungen an der Benutzeroberfläche oder das Ausgrauen von nicht verwendbaren Buttons, die in der Menge aber eine effizientere Bedienung bei der Bearbeitung eines typischen Workflows ermöglichen. Zur Verbesserung wurden nicht nur eigene Ideen entwickelt, sondern auch das Feedback von anderen Gruppenmitgliedern, welche die Software vor und während den Testfahrten bedient haben, eingeholt und anschließend verwendet. Damit wird eine benutzerzentrierte Entwicklung angestrebt, welche wiederum Folgen für die Priorisierung hat.

17

3.1.4.Verwendete Bibliotheken Zur Umsetzung der zusätzlichen Funktionalitäten werden Java Bibliotheken verwendet, welche im folgenden kurz beschrieben sind.

3.1.4.1. Wegpunktberechnung

Für die automatische Berechnung von Wegpunkten, z.B. im Rahmen der Linien- und Bereichsmessungen, sind verschiedene Funktionen nötig, um Winkel und Abstände zwischen zwei Wegpunkten zu berechnen und um Wegpunktprojektionen vorzunehmen. Hierfür wird die Bibliothek Geocalc [GC] verwendet. Diese Bibliothek erfüllt die von uns benötigten Anforderungen.

3.1.4.2. Darstellung

Die Bibliothek JXMapkit wird zur Darstellung der OpenStreetMap-Karte 2 mit einem Overlay von OpenSeaMap-Daten3 verwendet, welche für die Planung von Missionen auf Gewässern relevant sind. Die Entscheidung für diese Bibliothek wurde von der vorherigen Projektgruppe getroffen. Im Rahmen dieser Projektgruppe hinzugefügte Funktionen im Bereich der Darstellung (Sperrbereiche, Linienmessungen, usw.) ließen sich damit ebenfalls umsetzen. Zusätzlich bietet die Bibliothek Methoden, die benötigt werden, um mit den Wegpunkten arbeiten und zu interagieren. Da die Position der Wegpunkte in geographischen Koordinaten, welche aus Längen- und Breitengrad bestehen, vorliegen, werden vor allem Umrechnungsmethoden benötigt. Diese ermöglichen unter anderem eine einfache Umrechnung zwischen den geographischen Koordinaten und einer Position auf der Karte, welche in Pixeln, angegeben wird und für die korrekte Darstellung benötigt wird.

2 http://www.openstreetmap.de 3 http://www.openseamap.org

18

3.1.5.Fazit Dieser Abschnitt enthält ein kurzes Fazit und stellt dar, welche zusätzlichen Funktionen noch umgesetzt werden könnten, wenn die Projektgruppe nicht durch den Faktor Zeit begrenzt wäre. Bei der Umsetzung der neuen Funktionen, welche sich aus dem Erarbeiteten Konzept ergeben, wurde nach der Reihenfolge der Priorisierung vorgegangen. Aufgrund von Zeitgründen und der zusätzlichen Tätigkeiten der Gruppenmitglieder in der BeagleBone-Gruppe konnten nicht alle Funktionen umgesetzt werden. Umgesetzt wurden zunächst diverse Funktionen, welche die Möglichkeiten der Missionsplanung erweitern wie z.B das Durchführen von Bereichsmessungen und das Anlegen von Sperrgebieten. Zu diesem Bereich zählt auch die Möglichkeit, die Route mit Hilfe eines Optimierungsverfahrens zu optimieren. Des Weiteren wurden Funktionen umgesetzt, welche die Bedienbarkeit der Software erleichtern. Hierzu zählt die Änderung der Benutzeroberfläche und das Ausgrauen im Moment nicht verwendbarer Buttons. Diese Änderungen führen zu einer flüssigeren Bedienung der Software. Im Folgenden werden einige nicht umgesetzte Funktionen aus dem Konzept beschrieben. Eine davon ist es, die Eigenschaften des MOPS zu bearbeiten. Die Idee ist es zusätzliche Informationen wie zum Beispiel den Wendekreis oder die maximale Geschwindigkeit über den MOPS innerhalb der Offboard-Software darzustellen und für weitere Berechnungen bei der Routenoptimierung zu verwenden. Eine weitere Funktion ist es, die Windgeschwindigkeiten sowie die Windrichtung bei einem OnlineDienst abzurufen und in die

Routenoptimierung einzubeziehen. Ein geeigneter Dienst ist

OpenWeatherMap4. Dort treten bei weniger Aufrufen pro Tag keinerlei Kosten an und es ist möglich, für definierte Koordinaten Wetterdaten abzufragen. Ein Framework zur Darstellung der Umgebungsinformationen ist eine weitere Funktion aus dem Konzept. Das Framework basiert auf Ebenen und jede Ebene stellt eine neue Datenquelle dar. Denkbare Ebenen sind Seekarten, Strömungskarten oder aktuelle Windgeschwindigkeiten, die zum einen zusätzliche Informationen für den Planenden einer Mission darstellen und zum anderen zur automatischen Routenoptimierung verwendet werden können. Die Kollisionsverhütung soll mit Hilfe von AIS bewerkstelligt werden. AIS ist ein Funksystem, das zum Austausch von Navigations- und anderen Schiffsdaten verwendet wird. Es ist ein seit dem Dezember 2000 anerkannter, verbindlicher Standard der Internationalen SeeschifffahrtsOrganisation. Dabei sollen AIS-Daten im Vorfeld von einem Online-AIS-Dienst wie beispielsweise

4 http://www.opentheatermap.org

19

MarineTraffic5 abgerufen werden. Damit ist es möglich Daten über andere Verkehrsteilnehmer zu verarbeiten, ohne selber einen AIS-Empfänger zu besitzen. Dabei ist zu beachten, dass die dort vorhandenen Daten teilweise schon mehrere Stunden alt sind und dabei nicht als zuverlässige Kollisionsvermeidung verwendet werden können. Eine weitere Möglichkeit wäre es einen AIS-Empfänger auf dem MOPS zu verbauen, um auf andere Verkehrsteilnehmer, die einen AIS-Sender besitzen, reagieren zu können. Es soll lediglich ein Empfänger verwendet werden, weil ein vollständiges AIS, mit dem gesendet und empfangen werden kann, sehr teuer und die Daten schwer in Echtzeit auf der derzeitigen Hardware zu nutzen ist. Um die AIS-Daten Onboard zu verarbeiten, kann der Java AIS Decoder 6 verwendet werden , welches ein Open Source Projekt darstellt, welches 6 Bit ASCII Datensätze dekodieren kann.

5 http://www.marinetraffic.com 6 http://sourceforge.net/projects/aisdecoder/

20

3.2. Steuerung In diesem Abschnitt beschäftigen wir uns mit der Thematik, einen optimalen Steuerkurs zu berechnen, um das Schiff automatisch zu einer gegebenen Zielkoordinate zu manövrieren. Umwelteinflüsse, wie Wind und Wellen, können den aktuellen Kurs immer wieder verfälschen. Dies sorgt dafür, dass der Fahrtverlauf des Bootes einer Hundekurve ähnelt (siehe Abbildung 4). Im folgenden wird ein Ansatz gezeigt, welcher die Hundekurve vermeidet und das Ziel effizient erreicht.

Abbildung 4: Hundekurve

3.2.1.Ansatz für einen besseren Steueralgorithmus Folgend werden die einzelnen Bestandteile des neuen Steueralgorithmus kurz aufgeführt und erläutert. Diese Bestandteile wurden durch Analyse des Problems und Schrittweise Annäherung an eine optimale Lösung erarbeitet. Diese sollten die Steuerung annähernd optimal regeln können, ohne dabei zu viel Rechenaufwand durch überflüssige oder wenig effektive Bestandteile zu verursachen.

3.2.1.1. Kursabweichung berechnen

Um so schnell wie möglich eine Kursabweichung zu bemerken, verwenden wir den Magnetkompass des Sensorboards.

21

Abbildung 5: Kurskorrektur Um den Kurs über Grund zu erhalten, sichern wir uns bei Erhalt eines neuen GPS-Signals die Differenz zwischen Kurs über Grund und Kompasskurs.

3.2.1.2. PI-Regler

esum=esum+e

Eq. 1

y=Kp∗e+Ki∗Ta∗esum

Eq. 2

Der PI- Regler besteht aus einem Regelkreis, welcher dafür sorgt, einen Fehler (e) auszugleichen. Hierfür besitzt er zwei Komponenten, welche miteinander addiert werden: Zum einen ein proportional wirkender Regler, welcher die Regelabweichung mit einem Verstärkungsfaktor Kp multipliziert und zum anderen einen integral wirkender Regler, welche alle Regelabweichungen über eine Abtastzeit Ta aufsummiert und die Summe mit dem Faktor Ki multipliziert. Dem Fehlerglied e wird somit die Kursdifferenz zwischen Soll- und Ist-Kurs (siehe Abbildung 6) übergeben. Dies bewirkt, dass das Boot parallel zur Soll-Strecke fährt

22

Abbildung 6: Kursausgleich Die Parameter für den Regler können während der Fahrt in der „mops.config“ angepasst werden. Diese sind: Navigation.CourseDifferentialController.rudderP

Kp

Navigation.CourseDifferentialController.rudderI

Ki

Navigation.CourseDifferentialController.rudderMaxI

Maximal erlaubter Wert für esum

Tabelle 6: Regler Parameter

3.2.1.3. XTE

Um das Gefährt zurück auf die Soll-Strecke zu bekommen, addieren wir auf den Wert des PIReglers noch einen weiteren Wert dazu, welcher das Gefährt wieder auf den Sollkurs bringt. So verhindern wir, dass sich das Wasserfahrzeug in ein gesperrtes Gebiet oder in zu flache Gewässer begibt. Bei dem Wert handelt es sich um die Querabweichung in Metern von der aktuellen Route zur erwünschten Route (siehe Abbildung 7). Mathematisch lässt sich diese Abweichung wie folgt berechnen:

xte=asin(sin (d13/ R)∗sin ( B12− B13))∗R

Eq. 3

d13=Distanz zwischen Start und aktueller Position

Eq. 4

B12= Bearing zwischen Start und aktueller Position

Eq. 5

B13=Bearing zwischen Start und Endpunkt

Eq. 6

R=Erdradius in Metern

Eq. 7

23

Abbildung 7: XTE Berechnung

3.2.2.Evaluation Eine Gegenüberstellung mit dem alten Steueralgorithmus ergab, dass die Hunderkurve ausgelöscht wurde. Nach Erkennung des Abtriebs bewirkt XTE, dass das Boot auf der Sollstrecke bleibt. Durch experimentieren ergaben sich folgende Werte für den PI Regler: P – Teil

1,5

I – Teil

0,01

I – Max

50

Tabelle 7: Einstellungen PI Regler

3.3. Android Application Zur manuellen Steuerung des MOPS2 wurde eine Android-App entwickelt. Die Notwendigkeit und damit auch die Zielsetzung der App war es, ein zuverlässiges Tool zur Verfügung zu haben, das ein schnelles Eingreifen in die Steuerung des MOPS2 ermöglicht. Die Wahl der Android-Plattform für ein kleines Tool zur manuellen Steuerung wurde aufgrund der hohen Verbreitung getroffen. Darüber hinaus sind Android-Geräte meist mobiler als ein Notebook und ermöglichen damit die Steuerung mit einer Hand. Die Android-App baut nicht auf die Onboard-Software auf, sondern greift über eine SSHVerbindung direkt auf das Betriebssystem zu. Damit ist die Android-App unabhängig von jeglicher Software. Die App kann jeden der zwei Motoren unabhängig steuern und ermöglicht das Neustarten des XBee-Funkmoduls, Sensorboards und des BeagleBones. Trotz der Unabhängigkeit von jeglicher Software konnte es zu einem Problem mit der Onboard-Software kommen, weil es 24

möglich war, dass beide gleichzeitig versuchen zu steuern. Dabei muss nicht nur die manuelle Steuerung durch die Software berücksichtigt werden, sondern auch der Zugriff durch die OnboardSoftware bei aktuell laufender Mission. Um diesen Konflikt zu vermeiden, wurde eine Lock-Datei eingeführt, die beim Zugriff durch die App auf dem BeagleBone erzeugt wird und der OnboardSoftware jeglichen Zugriff auf die Motorensteuerung untersagt.

Abbildung 8: Android Application

3.4. Erweiterung der Offboard-Software zur Sensorenunterstützung Um die Verwendung der Sensoren zu ermöglichen, wurden auch einige Anpassungen in der Offboard-Software vorgenommen werden, die nachfolgend etwas ausführlicher erklärt werden sollen.

25

3.4.1.Messdaten anzeigen Zur sinnvollen Integration der Messdaten in die Software, wurde ein neuer Reiter “Messdaten” erstellt, der dem Anwender eine komplette Auflistung aller Messdaten ermöglicht. Zu diesem Zweck sieht der Anwender die Messdaten in einer Tabelle dargestellt. Er hat die Möglichkeit die Daten aus der Datenbank des Raspberry Pi zu laden (eine detaillierte Beschreibung der MySQLDatenbank befindet sich im nächsten Abschnitt). Alle Messdaten können nur bei einer WLANVerbindung geladen werden, da es sich um eine große Datenmenge handeln kann. Bei einer XBeeVerbindung werden nur die letzten Messdaten geladen, um die Messung im laufenden Betrieb überprüfen zu können. Jede Zeile in der Tabelle stellt eine Messung dar. Durch Anklicken einer Tabellenzelle können weiterführende Informationen zum Sensor, Parameter oder dem Messort aufgerufen werden. Sind die Messdaten geladen, dann gibt es zusätzlich die Möglichkeit diese als XML-Datei zu exportieren oder alle Messungen dauerhaft zu löschen.

3.4.2.Sensoren verwalten Damit eine übersichtliche Verwaltung der Sensoren möglich ist, wurde eine eigene Sensorverwaltung entwickelt, die über den Menüpunkt “Optionen” und dann den Eintrag “Sensorverwaltung” zu erreichen ist. Hier können Sensoren und Parameter angezeigt, erstellt, bearbeitet und gelöscht werden. Darüber hinaus gibt es die Möglichkeit Parameter einem Sensor zuzuweisen. Jeder Sensor, der durch eine spätere Mission verwendet werden soll, muss in der Sensorverwaltung eingetragen sein. Die Sensorverwaltung ist aber nicht dafür zuständig, aktuell angeschlossene Sensoren zu erkennen. Dieser Teil wurde ausgelagert, weil die Sensorverwaltung sich ausschließlich auf die MySQL-Datenbank beziehen soll und zur Verwaltung der aktuell angeschlossenen Sensoren Informationen notwendig sind, die nicht Teil der Datenbank sind.

3.4.3.Sensoren suchen Um aktuell angeschlossene Sensoren zu verwalten, gibt es einen eigenen Bereich in der OffboardSoftware, der direkt mit den Sensoren über die im Abschnitt Kommunikation beschriebene Schnittstelle kommuniziert. Es gibt einen eigenen Dialog, der unter dem Menüpunkt “Optionen” und dann den Eintrag “Sensoren suchen” zu finden ist. Das Suchen der Sensoren stellt die Schnittstelle zwischen der Mission und der Datenbank dar. Die Liste der aktuell angeschlossenen Sensoren wird dauerhaft gespeichert und beim Aktualisieren der angeschlossenen Sensoren erneuert. Sollte ein Sensor gefunden werden, der noch nicht in der Datenbank gelistet ist, so wird 26

das Hinzufügen über die Sensorverwaltung automatisch angestoßen. Beim Übertragen der Mission an die Onboard-Software wird zusätzlich geprüft, ob die in der Mission verwendeten Sensoren auch tatsächlich angeschlossen sind, um eine fehlerhafte Mission zu verhindern.

3.4.4.MySQL Datenbank Die Datenbank (vgl. Abbildung 9) ist auf dem Raspberry Pi installiert und enthält detaillierte Informationen über die Sensoren, Messparameter und durchgeführten Messungen. Die Datenbank wurde mit dem Ziel entworfen, eine vollständige Datensammlung zu schaffen, die später als alleinige Analyse der Messdaten ausreicht und die es nicht zwingend erforderlich macht, dass Daten aus zusätzlichen Quellen mit einbezogen werden müssen. Die Tabelle „time_location“ ergänzt die Messdaten um den genauen Zeitpunkt sowie die GPS Position während der durchgeführten Messung. In der Tabelle „sensors“ werden die verfügbaren Sensoren definiert. Diese müssen manuell in die Datenbank eingetragen werden. Zu den Sensoren gehören die entsprechenden Messparameter der Tabelle „sensors_parameters“, die ein spezieller Sensor messen kann. Die Definition eines Parameters wird in Tabelle „parameters“ vorgenommen. Diese Aufteilung ist sinnvoll, da verschiedene Sensoren auch gleiche Messparameter haben können. Beispielsweise können alle aktuell verwendeten Sensoren die Temperatur in Celsius messen. Die durchgeführten Messungen werden in der Tabelle „measurements“ persistent abgespeichert und enthalten alle relevanten Informationen der Messung. Der Abruf dieser Daten wird im folgenden Abschnitt Kommunikation erläutert.

27

Abbildung 9: Datenbankschema

28

4. Kommunikation Dieses Kapitel beschreibt die Kommunikation zwischen den Komponenten des MOPS und der Außenwelt. Neben der bereits vorhandenen XBee-Schnittstelle wurde der MOPS um einen WLAN Access Point erweitert, um eine einfache Möglichkeit zu schaffen, direkt über eine SSH Verbindung mit der Onboard-Software zu kommunizieren. Der WLAN-Accesspoint wird mit Hilfe des Raspberry Pi umgesetzt, welches über Ethernet mit dem BeagleBone und über eine serielle USBVerbindung mit dem Arduino Uno verbunden ist. Das Arduino Uno greift wiederum auf den SDI-12 Bus zu und fungiert als Bindeglied zwischen dem Raspberry PI und dem SDI-12 Bus. Es empfängt Befehle und leitet diese, sobald sie vollständig empfangen wurden, auf den Bus weiter. Wird eine Antwort empfangen, wird diese zurück an das Raspberry PI gesendet. Zur Steuerung und Verwaltung der Sensoren können über einen Socket, durch ein eigens entwickeltes Protokoll, die in Kapitel 4.2. - Sensorkommunikation beschriebenen Befehle an das Raspberry PI gesendet werden.

4.1. Kommunikation zwischen Onboard- und Offboard-Software Zur Kommunikation zwischen der Onboard- und der Offboard-Software gibt es zwei Möglichkeiten. Es ist möglich per WLAN oder per XBee Funk mit dem MOPS2 zu kommunizieren. Die Verbindungen werden dabei jeweils von der Offboard-Software aus initiiert. Das Protokoll und die Software zur Kommunikation wurde bereits von der vorherigen Projektgruppe MOPS erstellt und von uns mit kleinen Anpassungen weiterverwendet. Details zur Kommunikation können dem Abschlussbericht der vorherigen Projektgruppe entnommen werden [AB].

4.2. Sensorkommunikation An das Raspberry Pi können verschiedene Befehle über eine Socket-Verbindung gesendet werden, die die Informationen mit Hilfe des Arduino Uno bei den Sensoren abfragen (vgl. Tabelle 8). Diese Kommunikationssoftware wurde in der Programmiersprache C, auf dem Arduino Uno und in Python, auf dem Raspberry PI geschrieben. Während die Software auf dem Arduino Uno sehr einfach gehalten ist und lediglich Befehle, die über eine serielle Schnittstelle empfangen werden, über SDI-12 weiterleitet, ist die in Python geschriebene Software sehr komplex. Die Software besteht aus einem Manager und zwei Komponenten, die als Threads implementiert sind. Einer dieser Threads dient der Aktualisierung der GPS-Koordinaten und der aktuellen GPS-Zeit, diese 29

Daten werden von dem BeagleBone mit Hilfe eines Threads abgerufen und zusammen mit den Daten der Sensoren in die Datenbank abgelegt. Der zweite Thread dient der Kommunikation, durch ihn können die in der nachfolgenden Tabelle genannten Befehle ausgeführt werden. Die Kommunikation ist eine Multi-Client-Kommunikation, sodass mehrere Clients gleichzeitig Befehle an das Raspberry PI senden können. Um dies zu gewährleisten, wird für jede Verbindung ein neuer Thread angelegt. Da nur ein Befehl gleichzeitig an das Arduino Uno gesendet werden kann und die Befehle ggf. eine hohe Ausführungszeit haben, kann es vorkommen das ein Thread auf einen anderen warten muss.

Befehle

Erläuterung

Rückgabewert

list_sensors();

Gibt die Adressen aller angeschlossenen Sensoren zurück

IDs

readdress_sensor(old_id, new_id);

Ermöglicht das Neuadressieren eines Sensors

True, False

is_sensor_online(id);

Prüft ob ein Sensor online ist

True, False

measurement_all_parameter(id);

Startet eine Messung aller Parameter des Sensors „id“

IDs der Datenbankeinträge

measurements_all_parameter(ids);

Startet eine Messung aller in „ids“ angegebenen Sensoren

IDs der Datenbankeinträge

info_of_sensor();

Enthält alle Informationen der nachfolgenden Befehle

String

Tabelle 8: Python Befehle

Zur Realisierung der Socket-Kommunikation mit dem BeagleBone Black wurde ein auf Python basiertes Protokoll auf dem Raspberry Pi entwickelt, um Messungen über das Arduino Uno zu starten und die Sensoren zu administrieren. Des Weiteren holt sich das Raspberry Pi selbstständig über eine Socketverbindung mit dem BeagleBone Black die aktuellen GPS-Koordinaten. Das Protokoll ist im Folgenden in der erweiterten Backus-Naur-Form angeben. •

Nachricht = AufrufName [Parameter] [NachrichtenID] “;“

•

AufrufName = (Buchstabe, Zahl)+

•

Parameter = “(“ [ParameterAnfang] “)“

30

•

ParameterAnfang = ParameterWort [Parameterfoot]

•

Parameterfoot = “,“ ParameterWort [Parameterfoot]

•

ParameterWort = (Buchstabe, Zahl)+

•

NachrichtenID = “[“ (Zahl)+ “]“

•

Buchstabe = „A“ | … | „Z“ | „a“ | … | „z“;

•

Zahl = „0“ | „1“ | „2“ | „3“ | „4“ | „5“ | „6“ | „7“ | „8“ | „9“

Die Antworten des Raspberry Pi‘s sehen folgendermaßen aus: •

Antwort = ( Positiv | Negativ )“;“

•

Positiv = „r“ [NachrichtenID] “{“ [Response] “}“

•

Negativ = „e“ [NachrichtenID] “{“ [Errorexplanation] “}“

•

Response = response Responsefoot

•

NachrichtenID = “[]“ | “[“ (Zahl)+ “]“

•

Responsefoot = “,“ response [Responsefoot]

•

Buchstabe = „A“ | … | „Z“ | „a“ | … | „z“;

•

Zahl = „0“ | „1“ | „2“ | „3“ | „4“ | „5“ | „6“ | „7“ | „8“ | „9“

•

Responsewort = (Buchstabe | Zahl)*

•

Errorexplanation = (Buchstabe | Zahl)*

„Response“ ist die Antwort der Sensoren oder eine durch das Raspberry Pi erstellte Antwort. In „Errorexplanation“ ist ggf. eine entsprechende Fehlerbeschreibung vorhanden.

4.3. WLAN Access Point Zum Einrichten einer WLAN Schnittstelle wurde auf dem Raspberry Pi ein WLAN Access Point erstellt. Dabei übernimmt „hostapd”, ein Linux Treiber für WLAN Access Points, die Erstellung des kabellosen Netzwerks und „iw” die einfache Konfiguration des WLAN Sticks. „iw“ ist zwar ein „nl80211“ basiertes CLI-Konfigurationsprogramm für WLAN Geräte, funktioniert allerdings auch mit dem hier verwendeten WLAN Stick mit einem Realtek „RTL8188CUS“ Chip. Die Weiterleitung des Traffics in das Netzwerk wird über „iptables“ realisiert. Als DNS-Forwarder wird „dnsmasq“ eingesetzt. Alle zugehörigen Konfigurationsdateien befinden sich im Repository unter

dem

Pfad:

“\mops2\hardware\raspberry\config”.

31

Die

daraus

resultierende

Netzwerkkonfiguration ist in Tabelle 9 abgebildet. Der WLAN Stick sollte nur auf den Channels 1, 6 oder 12 betrieben werden.

Name

IP

Hostname

MAC-Adresse

Raspberry Pi

192.168.42.1

raspberry

44-33-4C-6C-0B-87

BeagleBone Black

192.168.42.2

BeagleBone

00-0F-C9-22-05-99

Tabelle 9: Netzwerkkonfiguration

4.4. Entwurf der XBee-Antenne In der folgenden Tabelle 10 - XBee-Antenne werden Kabel-spezifische Größen angegeben und die Länge des Massegeflechts und der Innenleiter der Antenne ermittelt. Die Berechnung erfolgt nach dem Standard für DVB-T Antennen [DTA].

Kabeltyp

50 Ohm RG58U

benötigte Frequenz

868 MHz

Lambda

Lichtgeschwindigkeit / Frequenz = 299792 km/s / 868 MHz = ca. 34,54cm

Länge Massegeflecht

Lambda * 0,95/4 = ca. 8,20cm

Lange Innenleiter

Lambda * 0,97/4 = ca. 8,38cm

Tabelle 10: XBee-Antenne

32

5. Hardware Dieses Kapitel umfasst alle Hardware-Komponenten. Dazu zählt der komplette Rumpf mit allen verbauten Teilen, die Sensorik sowie eine kurze Beschreibung zu der gesamten eingesetzten Elektronik wie bspw. die Busleitung und das Raspberry PI. Ein abschließendes Fazit zu den aufgeführten Teilen sollen erreichte, aber vor allem auch noch wünschenswerte Fortschritte aufdecken.

5.1. Rumpf Das nächste Kapitel beschäftigt sich mit der Entwicklung des Rumpfes und den dazugehörigen Elemente wie z.B. dem Aluminiumrahmen oder dem Sensorkäfig. Dafür wird zunächst der Optimist als Rumpfkörper vorgestellt und auf die Fragestellung eingegangen, welche Vor- und Nachteile diese Form gegenüber dem von MOPS1 verwendeten Trimaran besitzt. Anschließend wird kurz angerissen, welches Konzept bei unserem Vorgehen vorlag. Im dritten Abschnitt werden alle Komponenten mit ihren jeweiligen Aufgaben und Funktionalitäten vorgestellt und beschrieben, wie sie miteinander in Verbindung stehen. Für die Veranschaulichung wurden diverse Modelle und Diagramme erstellt. Der dritte Teil bezieht sich auf die Eigenschaften des MOPS. Es wird das Verhalten auf dem Wasser analysiert und einige Berechnungen angestellt. Im abschließenden Teil werden einige der im Kapitel 1.3. vorgestellten Anforderungen mit den Ergebnissen gegenübergestellt und dadurch konzipiert, welche Anforderungen erfüllt wurden und welche noch ausstehen.

5.1.1.Problemstellung Der Grund, warum ein alternatives Rumpfkonzept überlegt werden musste, liegt an den Schwierigkeiten, die der alte Trimaran hervorbrachte. Zum einen sind hier die hinderlichen Transportmöglichkeiten sowohl zum Einsatzort als auch ins Wasser zu benennen. Dafür sind vor allem die unhandlichen Teile und das hohe Gewicht der einzelnen Komponenten verantwortlich. Zum anderen führt der nicht reibungslose Aufbauprozess zu einem hohen Zeitaufwand, der bei einem Forschungsprojekt nicht unbedingt zur Verfügung steht. Des Weiteren ist die Rumpfform nicht optimal, sodass eine ungünstige Platzierung des Gewichts bei wenig Spielraum sofort eine Debalancierung des ganzen Trimarans zur Folge hätte. Das wohl größte Problem ist durch die

33

Erweiterung des Einsatzortes auf die Wesermündung zu begründen. Aufgrund der fehlenden Hochseetauglichkeit des Trimarans müsste spätestens an dieser Stelle ein Umdenken stattfinden. Der Rumpf in Form eines Optimisten konnte einige dieser Schwierigkeiten sofort oder mit nur wenig Aufwand lösen. Dennoch bringt auch dieser Nachteile mit sich. Allgemeine Vor- und Nachteile dieser Rumpfart wurden ausgearbeitet und in Tabelle 11 - Vor- und Nachteile des Rumpfkörpers veranschaulicht. Ein großes Manko des Trimarans war die fehlende Hochseetauglichkeit. Ein Optimist ist auch nicht unbedingt für hohe Gewässer geschaffen, es lässt sich aber durch einige Erweiterungen eine gewisse Hochseetauglichkeit erreichen, die für unsere Zwecke als ausreichend zu betrachten ist. Zum Beispiel wurde über den gesamten Rumpf eine Plane gezogen, damit alle Stellen wasserdicht sind. So kann auch bei starkem Wellengang kein Wasser zu der Elektronik gelangen, die zusätzlich noch durch die Otterboxen geschützt ist. Die hohe erforderliche Antriebsleistung wird durch zwei am Heck angebrachte Rhino-VX 34 aufgetan. Auf dem ersten Blick kommt einem das autonome Wassergefährt mit der Rumpfform eines Optimisten sehr unhandlich und stämmig vor. Bei weiteren Überlegungen wird aber klar, dass gerade diese große Fläche viel Raum für optimierte Platzausnutzung bietet. So blieb im Endeffekt kaum eine freie Fläche ungenutzt. Zudem wurde bei der Anordnung der Segmente drauf geachtet, dass der Körperschwerpunkt relativ zentral liegt. Der schwierigen Befestigung der Motoren aufgrund des Plastikmantels des Optimisten wurde mit Holzbrettern entgegnet, die an der Oberseite des Hecks auf beiden Seiten befestigt wurden und wo die Motoren letztendlich ihren Halt finden. Weitere Probleme und Nachteile konnten über durchdachte Konstruktionen und Schritte ebenfalls behoben werden, welche weiter unten aufgeführt werden.

34

Vorteile

Nachteile

Alt bewährtes Wassergefährt

Keine Hochseetauglichkeit (durch verschiedene Maßnahmen aber realisierbar)

Kein großer Kostenaufwand bei der Beschaffung

Hohe Antriebsleistung erforderlich

Keine großen Handgriffe erforderlich

Eventuell zu große Fläche (kleinere Fläche hätte für unsere Zwecke ausgereicht)

Gute Beförderung (sowohl zum Einsatzort als auch auf die Wasseroberfläche)

Leichte Verschiebung des Gleichgewichts

Bereits vorgefertigte Materialien, die einen Einsatz weiter erleichtern

Schwierige Befestigung der Motoren (aufgrund der Plastikumrahmung des Optimisten)

Große, nutzbare Fläche (Platz für weitere Antriebskörper, Solarpanels etc.)

Schwierigkeiten bei der Wahl nach möglichen Konzepten für die Sensoren (Löcher können nur sehr schwer oder gar nicht wieder geschlossen werden)

Viel Spielraum für optimierte Konzepte (Ausgleich des Gleichgewichtsproblems)

Schwierige Befestigung der Alu-Profile (aufgrund der vielen unebenen Stellen und des Plastikmantels des Optimisten, welcher schnell zu reißen droht)

Außenboarder können weiter verwendet werden (Anbringung am Heck) Tabelle 11: Vor- und Nachteile des Rumpfkörpers

5.1.2.Konzept Damit die aufgeführten Anforderungen im angemessenen Rahmen erfüllt werden konnten, wurden zahlreiche Konzepte entwickelt, wie sie in Abbildung 10 in chronologischer Reihenfolge zu erkennen sind. Zunächst wurde eine Heck-Konstruktion erstellt, damit die Motoren und die Elektronik in den Rumpf angebracht werden konnte. Zum Zwecke der wasserdichten und sicheren Aufbewahrung dieser Elektronik wurde in der Konstruktion Platz für drei Otterboxen eingeräumt. Die Batteriebox wurde für die erste Testfahrt vorerst mit Seilen an den vorderen Teil des Bugs befestigt. Damit wurde auch ein Gewichtsausgleich für die schweren Motoren geschaffen. Die darauf folgenden Denkvorgänge beliefen sich auf die sichere Aufbewahrung des Akkumulators. Dafür wurde erneut eine Aluminium-Konstruktion angefertigt, die am Bug montiert wurde. Dieses Aluminium-Gerüst besitzt Platz für zwei Batterieboxen, sodass bei Bedarf neben dem verwendeten Bleiakku ein weiterer Akkumulator eingesetzt werden kann. Zudem mussten Ideen gesammelt und 35

ausgereift werden, die die Ladung auf im Falle einer Kenterung nicht untergehen lässt. Die Idee, die die Nutzung von KG-Rohren als Schwimmkörper vorsieht, wurde dabei schnell wieder verworfen, da das Eigengewicht der Rohre zu schwer war, um mit ihren Luftumfang ausreichend Auftrieb zu bewirken. Im späteren Verlauf wurden Schwimmkörper eingebaut, die dem MOPS2 auch im Falle einer Kenterung genügend Auftrieb geben. Die Berechnungen dazu befinden sich in Kapitel 5.1.7.. Das letzte Konzept handelte um die Platzierung der Sensoren. Dieses Thema umreißt auch den Einlass der Sensoren ins Wasser. Da festgelegt wurde, keine größeren Löcher in den Rumpf zu bohren, die sich später nicht mehr verschließen lassen, wurde beschlossen, die Sensoren vorne am Bug ins Wasser zu lassen. Für den sicheren Einlass ins Wasser sorgt ein Sensorkäfig, wie er in Kapitel 5.1.6. beschrieben wird. Weiterhin ist zu erwähnen, dass für alle Aluminium-Konstruktionen ausschließlich Alu-Profile verbaut wurden, die von der Projektgruppe MOPS für den alten Trimaran genutzt wurden.

Abbildung 10: Entwicklung des Rumpfkörpers

5.1.3.Heck In diesem Kapitel wird die Rahmenkonstruktion im Heck auf Grundlage einer 3D-Modellierung veranschaulicht. Zur Konkretisierung erfolgt eine Beschreibung der Umsetzung mithilfe einer detaillierten Materialliste.

5.1.3.1. Modellierung

In der Abbildung 11 - Heckkonstruktion ist die Rahmenkonstruktion für das Heck des MOPS2 in einem 3D-Modell virtualisiert. Dabei ist ein Rahmen aus Aluminiumprofilen mit Winkeln, Gelenken und T-Stücken entwickelt worden. Die Maße des Rahmens sind 96,5cm x 100cm x 30cm (L x B x H).

36

Abbildung 11: Heckkonstruktion 5.1.3.2. Umsetzung

Das Gerüst aus Aluminium-Stangen, die mithilfe von Winkeln miteinander verbunden sind, wurde so konstruiert, dass mittig drei wasserdichte Otterboxen (420 x 245 x 270mm [L x B x H]) Platz finden. In diesen Boxen ist die Elektronik verbaut und über Steckverbindungen miteinander verknüpft (siehe Kapitel 5.1.5.2.). Damit diese Elektronikboxen auch im Falle von starkem Wellengang oder gar einer Kenterung nicht über Bord gehen, wurde eine weitere Aluminiumstange quer über diese Behälter gelegt und durch ein Gelenk am vorderen und am hinteren Ende der Konstruktion befestigt. Indem nur eine Schraube zwischen den beiden Winkeln gelöst wird, ist es auch weiterhin möglich, an die Boxen zu gelangen. Die Boxen werden innerhalb des Rahmens von vier Stangen getrennt, die durch TVerbindungsstücken an den beiden Alu-Profilen angebracht sind, welche den hinteren Teil mit dem vorderen Teil miteinander verbinden. Zwischen diesen Trennstangen ist etwas Platz, damit die Gürtelschnallen bei der Anbringung der Schwimmkörper nicht wegrutschen können. Die gesamte Konstruktion ist mit vier Schrauben M10 vorne an der Trennwand aus Holz und hinten mit weiteren zwei Schrauben M10 am oberen Teil des Optimisten am Rumpf befestigt. So konnte umgangen werden, weitere Löcher in den Rumpf zu bohren. Zusätzlich wurde darauf geachtet, dass 37

die jeweils höchsten Stellen eine Ebene darstellen, damit eine Erweiterung durch bspw. Solarpanels problemlos erfolgen kann.

5.1.3.3. Materialliste Heckkonstruktion

In Tabelle 12 - Materialliste Heckkonstruktion * sind die einzelnen Materialien für die Rahmenkonstruktion im Heck aufgelistet. Bezeichnung

Kosten pro Stück (€)

Anzahl

Kosten (€)

Winkel 30 x 30

2,60

12

31,20

Winkel 30 x 60

0

6

0

Gelenk 30 x 30

12,80

1

12,80

T-Verbindungsstück

1,90

8

15,20

Nutenstein

0

48

0

Schraube M5 1cm

0

48

0

Schraube M10 6cm

0

3

0

Schraube M10 10cm

0

6

0

Mutter M10

0

11

0

Alu-Profil (11,5cm)

0

2

0

Alu-Profil (27cm)

0

4

0

Alu-Profil (36cm)

0

4

0

Alu-Profil (37,5cm)

0

1

0

Alu-Profil (43,5cm)

0

1

0

Alu-Profil (66cm)

0

1

0

Alu-Profil (78cm)

0

1

0

Alu-Profil (79cm)

0

2

0

Alu-Profil (100cm)

0

1

0

Gesamtkosten

59,2

Tabelle 12: Materialliste Heckkonstruktion * * Bei einigen Materialien sind keine Kosten aufgeführt, da sie entweder Bestandteil des Trimarans der vorherigen Projektgruppe MOPS oder Zubehör bei einer anderen Bestellung waren. 38

5.1.4.Bug In diesem Kapitel wird die Rahmenkonstruktion im Bug auf Grundlage einer 3D-Modellierung veranschaulicht. Zur Konkretisierung erfolgt eine Beschreibung der Umsetzung mithilfe einer detaillierten Materialliste.

5.1.4.1. Modellierung

In den Abbildungen 12 - Bugkonstruktion und 13 - Antennenkonstruktion ist die Rahmenkonstruktion für das Bug des MOPS in 3D-Modellen virtualisiert. Dabei ist ein Rahmen aus Aluminiumprofilen mit Winkeln und Gelenken entwickelt worden. Die Maße der Bugkonstruktion betragen 49,5cm x 71,5cm x 25,5cm (L x B x H).

Abbildung 12: Bugkonstruktion

39

Abbildung 13: Antennenkonstruktion

5.1.4.2. Umsetzung

Bei der Bug-Konstruktion wurde explizit darauf geachtet, dass der benutzte Akkumulator mit einem Gewicht von ca. 28 kg einen sicheren Halt im Rumpf hat. Dafür wurde wiederum jeweils eine Aluminium-Stange über beide Batterieboxen gelegt, welche die Akkumulatoren bei allen vorstellbaren Zuständen im Rumpf halten soll. Das Gerüst an sich, das ebenfalls aus Alu-Profilen besteht, ist sowohl oben als auch unten mit der Heck-Konstruktion durch Schrauben M12 stark befestigt. Zudem wurde das Gewicht von zwei Bleiakkus und einem Sensorkäfig eingeplant, weshalb die Konstruktion sehr zentral im Optimisten gelegen ist, um einen ausbalancierten Körperschwerpunkt zu erreichen.

40

5.1.4.3. Materialliste Bugkonstruktion

In Tabelle 13 - Materialliste Bug sind die einzelnen Materialien für die Rahmenkonstruktion im Bug aufgelistet. Bezeichnung

Kosten pro Stück (€)

Anzahl

Kosten (€)

Winkel 30 x 30

2,6

22

57,2

Winkel 30 x 60

0

2

0

Gelenk 30 x 30

12,8

4

51,2

Nutenstein

0

44

0

Schraube M5 1cm

0

44

0

Montageschelle

2,79

4

11,16

Alu-Profil (4,5cm)

0

2

0

Alu-Profil (15cm)

0

2

0

Alu-Profil (31cm)

0

2

0

Alu-Profil (42cm)

0

4

0

Alu-Profil (46,5cm)

0

2

0

Alu-Profil (48,5cm)

0

2

0

Alu-Profil (61cm)

0

1

0

Alu-Profil (71cm)

0

1

0

Gesamtkosten

119,56

Tabelle 13: Materialliste Bug

5.1.5.Otterboxenkonzept Das Konzept der Otterboxen umfasst die Sicherung und den Schutz der Elektronikkomponenten des MOPS2 vor Wasser, Stößen, und anderen Gefahren. Diese Boxen werden in den Rahmenkonstruktionen des Hecks und Bugs verbaut. Im Folgenden ist ein Komponentendiagramm der Elektronikkomponenten in den einzelnen Boxen veranschaulicht und es folgt eine Beschreibung der Realisierung mit der zugehörigen Materialliste.

41

5.1.5.1. Komponentendiagramm

siehe Anhang 7.8.6. - Komponentendiagramm

5.1.5.2. Umsetzung

Die einzelnen elektronischen Bestandteile wurden aufgrund negativer Wechselwirkungen auf die drei Otterboxen im Bug verteilt. Durch die starken Magnetfelder, die vom Motorcontroller, der Spule der Not-Aus-Schaltung und der großen Anzahl an Kabeln verursacht werden, wird die Messgenauigkeit des Sensorboards und des GPS-Moduls gestört. Deshalb wurden die verursachenden Komponenten in einer separaten Otterbox untergebracht. Box 1 enthält die Leistungselektronik mit Motorcontroller und Relais. Über das Relais und den Zug-Not-Aus-Schalter kann die Stromzufuhr unterbrochen werden. In Box 2 befinden sich das Raspberry Pi mit einem WLAN-Stick und das Arduino Uno samt Cape. Das BeagleBone mit dem dazugehörigen Cape, XBee-Modul, Sensorboard und GPS-Modul befinden sich in Box 3. 5.1.5.3. Materiallisten der Boxen

In Tabelle 14 - Materiallisten der Boxen werden die einzelnen Komponenten innerhalb der drei Elektronikboxen aufgeführt. Box 1 (rot)

Motorcontroller Not-Aus-Schaltung

Box 2 (gelb)

Raspberry Pi Arduino Uno WLAN-Stick Arduino Cape

Box 3 (grün)

BeagleBone XBee-Modul Sensorboard GPS-Modul BeagleBone Cape

Tabelle 14: Materiallisten der Boxen

42

5.1.5.4. Verkabelung des Sensorboards

Das Sensorboard 9 DOF Razer IMU ist mit einer Pinverbindung auf dem BeagleBone-Cape angebracht. In Abbildung 14 - Sensorboard 9 DOF Razer IMU ist das Sensorboard mit der Verkabelung, die in Tabelle 15 - Verkabelung des Sensorboards aufgeführt ist, abgebildet.

Kabeltyp

Sensorboard-Eingänge

braun

GNX

weiß

3,3 V

gelb

TXO

Tabelle 15: Verkabelung des Sensorboards

Abbildung 14: Sensorboard 9 DOF Razer IMU In Abbildung 15 - Verkabelung auf dem BeagleBone ist die Verbindung abgebildet, die in Tabelle 16 - Verkabelung auf dem BeagleBone aufgeführt ist. Die X-Symbole sind von oben nach unten aufsteigend durchgezählt.

43

Kabeltyp / Pin

Eingänge

braun

X1

kein Pin

O1

weiß

X2

grün

X3

gelb

X4

kein Pin

X5

Tabelle 16: Verkabelung auf dem BeagleBone

Abbildung 15: Verkabelung auf dem BeagleBone

5.1.6.Sensorkäfigkonzept Unsere Idee ist es die Sensoren vor jeglichen Gefahren in einer Käfigkonstruktion zu schützen. Dazu wurden die übrig geblieben Aluminiumprofile recycelt. Im diesem Kapitel wird diese Käfigkonstruktion mithilfe von 3D-Modellen visualisiert und auf Basis dieser Modelle die Umsetzung beschrieben.

44

5.1.6.1. Modellierung

In der Abbildung 16 - Sensorkäfig ist die Rahmenkonstruktion für die Sensoren des MOPS2 in einem 3D-Modell virtualisiert. Dabei ist ein Rahmen aus Aluminiumprofilen mit Winkeln und TStücken entwickelt worden. Die Maße des Rahmens sind 16cm x 16cm x 30cm (L x B x H). Mit Hilfe von Montageschellen werden die Sensoren in der Mitte des Käfigs festgehalten.

Abbildung 16: Sensorkäfig

5.1.6.2. Umsetzung

Der Sensorkäfig ist ein Gerüst, ebenfalls bestehend aus Alu-Profilen und Winkeln, das den Sensoren ausreichend Schutz gewährleisten soll, wenn diese unter Wasser Daten sammeln. Er wird an vorderster Stelle mit Seilen am Optimisten ins Wasser gelassen, wodurch verhindert wird, dass Löcher in den Rumpfboden gebohrt werden müssen, und bietet Platz für vier Sensoren mit einer Länge von jeweils 15cm und einem Durchmesser von 2,6cm. Die Seile sind dabei weit außen am Bug befestigt. So wird abgewandt, dass der Käfig im Wasser rotiert und sich dadurch die Kabel verdrehen. Die Sensoren sind mithilfe von jeweils zwei Montageschellen an den horizontalen Aluminium-Stangen befestigt. Damit die Ergebnisse nicht durch beispielsweise der Bildung von Luftblässchen verfälscht werden, sitzen die Sensoren etwas tiefer als die horizontalen Alu-Profile, aber werden dennoch von den äußeren Alu-Profilen geschützt

45

5.1.6.3. Materialliste Sensorkäfig

In Tabelle 17 - Materialliste Sensorkäfig sind die einzelnen Materialien für den Sensorkäfig aufgelistet.

Bezeichnung

Kosten pro Stück (€)

Anzahl

Kosten (€)

Winkel 30 x 30

2,60

24

62,40

Nutenstein N6

0

48

0

Schraube M4

0

48

0

Alu-Profil (10cm)

0

8

0

Alu-Profil (30cm)

0

4

0

Montageschelle

2,79

4

11,16

Atlantik Compact Schot

1,29/m

12m

15,48

Gesamtkosten

89,04

Tabelle 17: Materialliste Sensorkäfig

5.1.6.4. Materialliste Sensoren

Bezeichnung

Anzahl

Kosten (€)

Hersteller / Lieferant

turbidity sensor

1

1737

TriOS Mess- und Datentechnik

conductivity/Temp sensor

1

558

TriOS Mess- und Datentechnik

Gesamtkosten

2295

Tabelle 18: Materialliste Sensoren

5.1.7.Auftriebsberechnung Der MOPS2 hat aufgrund des Rumpfkörpers eines Optimist die Eigenschaft, dass bei zu hohem Wellengang der Rumpf kentern kann. Im Notfall darf der Rumpf nicht untergehen, da wichtige Messdaten verloren gehen würden. Hierzu wurde berechnet, wie viel Auftrieb vorhanden sein muss, damit der Rumpf immer an der Wasseroberfläche schwimmt. Die Idee ist es, die vorhandenen, wasserdichten Otterboxen, in denen die Elektronikkomponenten befestigt sind, auszunutzen und

46

zusätzlich den Rumpf mit Schwimmkörper zu erweitern. In den folgenden Unterkapiteln werden die Berechnungen des Auftriebs der Otterboxen und der Schwimmkörper aufgeführt und beschrieben.

5.1.7.1. Otterboxen

Im Folgenden werden die Eigenschaften der Otterboxen aufgeführt und der Auftrieb der drei Elektronikboxen berechnet.

angegebene Außenmaße

42cm x 24,5cm x 27cm (L x B x H)

angegebene Innenmaße

36cm x 18,5cm x 22cm (L x B x H)

Eigengewicht

0,8kg

Anzahl

5

Tabelle 19: Eigenschaften der Otterboxen Auftrieb von Luft

1kg / Liter

Berechnung Auftrieb

Luftvolumen * Auftrieb von Luft - Eigengewicht

Berechnetes Luftvolumen

36cm * 18,5cm * 22cm = 14652cm3 = 14,652 Liter

Auftrieb einer Otterbox

14,652 Liter * 1kg / Liter - 0,8kg = ca. 13,8kg

Tabelle 20: Berechnung des Auftriebs

Der Auftrieb der drei Elektronik-Boxen beträgt etwa 41,4kg.

5.1.7.2. Schwimmkörper

Die Schwimmkörper gleichen durch ihren hohen Auftrieb den schweren Akku und das Gegengewicht wieder aus. Die Eigenschaften und der Auftrieb der Körper werden in der Tabelle 21 - Eigenschaften der Schwimmkörper dargestellt bzw. berechnet.

47

Material

PVC

Länge

80cm

Durchmesser

30cm

angegebenes Volumen

55 Liter

Eigengewicht

0,2kg

Anzahl

2

Auftrieb eines Schwimmkörpers

55 Liter * 1kg / Liter - 0,2kg = 55,8kg

Tabelle 21: Eigenschaften der Schwimmkörper

Der Auftrieb beider Schwimmkörper zusammen beträgt somit 109,6kg.

5.1.7.3. Materialliste Schwimmkörper

In Tabelle 22 - Materialliste Schwimmkörper sind die einzelnen Materialien aufgelistet, die für die Befestigung der Auftriebskörper benötigt werden.

Bezeichnung

Kosten pro Stück (€)

Anzahl

Kosten (€)

Auftriebskörper PVC

14,95

2

29,90

Gurtband mit Schnellverschluss (100cm)

4,95

4

18,80

Führungshaken

2,09

4

8,36

Gesamtkosten

57,06

Tabelle 22: Materialliste Schwimmkörper

5.1.8.Ausblick Die eingangs speziell für die Hardware aufgeführten Anforderungen wurden allesamt durch die unterschiedlichen,

beschriebenen

Ausführungen

erfüllt.

Es

gibt

allerdings

einige

Anforderungsgebiete, die Optimierungsbedarf aufweisen. Vor allem die Hochseetauglichkeit des MOPS2 ist noch nicht komplett ausgereift und könnte durch einige Schritte optimiert werden. Es ist z.B. möglich, das Planenkonzept weiter zu entwickeln. Momentan wird dafür provisorisch eine normale Abdeckplane genutzt, die durch ein Seil und ein Spanngurt am Optimisten fest gemacht 48

wird. Diese Montagearbeit verlangsamt den ansonsten sehr schnellen Aufbauprozess deutlich und beachtet den Platzbedarf des Antennenkabels nicht. Zudem findet die Elektronik in den Otterboxen zwar einen sicheren und wasserdichten Halt, allerdings sind einige Komponenten lediglich mit Schrauben an ein Holzstück verschraubt und sind weiter ungeschützt. Vor allem für das BeaglebBone konnte keine Schutzhülle besorgt werden, da die zusätzlich befestigten Teile die allgemeinen Gehäuse unbrauchbar machen und eine Eigenentwicklung erfordern. Es wurden ebenfalls einige Gedanken bezüglich der Aufbewahrung des Sensorkäfigs im Bug angestellt, wenn dieser keinen Einsatz findet, welche momentan noch nicht umgesetzt wurden. Des Weiteren wurde die Einbindung von einer alternativen Antriebs- oder Energiequelle noch nicht weiter berücksichtigt. Es wurde zwar eigens für die Anbringung von Solarpanels am oberen Deck Platz freigehalten, für dessen Umsetzung war am Ende jedoch zu wenig Zeit.

5.2. Sensorik Dieser Abschnitt beschreibt die Entwicklung des Sensorkonzepts. Dazu werden zunächst die Problemstellung, das Vorgehen sowie die Systemarchitektur dargestellt. Die verwendeten Komponenten der Systemarchitektur werden in den nachfolgenden Kapiteln detailliert erläutert.

5.2.1.Problemstellung Hauptziel des MOPS2 ist es als Forschungsfahrzeug auf Meeren und Gewässern Messdaten zu gewünschten Untersuchungsobjekten zu sammeln. Die Aufgabe der Sensorik ist dabei diese Daten auf geeignete Art und Weise zu messen, weiterzugeben und die aufgenommenen Sensordaten über eine Schnittstelle abrufbar zu gestalten. Die Sensorkonfiguration des MOPS1 diente bisher ausschließlich der Steuerung und Navigation. Da auf dem eingesetzten BeagleBone dadurch bereits mehr als die Hälfte der verfügbaren UART Schnittstellen durch Inertialsensor, GPS und XBee-Modul belegt waren, musste ein System entwickelt werden, um den MOPS2 mit beliebig vielen Schnittstellen für die Messsensorik zu erweitern.

49

5.2.2.Vorgehen Zur Realisierung einer Anschlussmöglichkeit für beliebig viele Sensoren wird in der aktuellen Konfiguration ein Bussystem eingesetzt. Das Bussystem bildet dabei die Schnittstelle zwischen zwei vorgegebenen Systemen. Es gibt zum einen das BeagleBone White, das von der alten Projektgruppe als Kernelement für den MOPS ausgesucht wurde, und zum anderen die Messsensorik, die durch Prof. Dr. Zielinski vorgegeben wird. Ein Bussystem muss diese beiden Systeme auf geeignete Art und Weise verknüpfen und sollte zudem mindestens drei Sensoren gleichzeitig unterstützen. Des Weiteren sollte das Bussystem robust sein und auch mit Störungen der Sensoren umgehen können. Bussysteme haben grundsätzlich den Vorteil eines geringen Verdrahtungsaufwands

durch eine gemeinsame Datenleitung sowie den Wegfall einer

kostenintensiven bzw. aufwändigen Sternverdrahtung. Dazu wurden verschiedene Bussysteme (CAN, I²C, RS485) auf ihre Tauglichkeit hin untersucht. CAN (Controller- Area- Network) ist ein zwischen 1983 und 1986 von Bosch und Intel entwickeltes nachrichtenorientiertes asynchrones Zweidraht-Bussystem, das aufgrund der Konzeption eine bessere Störsicherheit als I²C besitzt. Durch eine Bitarbitrierung werden Zugriffsrechte ermittelt und Kollisionen vermieden. Insgesamt bietet CAN die Möglichkeit 536870912 Identifier bei einer maximalen Übertragungsrate von 1 Mbit/s zu verwalten, wobei die Kabellänge je nach Übertragungsrate zwischen maximal 6,7 Kilometern und minimal 40 Metern liegt [ME]. Sensoren mit CAN Schnittstelle sind größtenteils für den industriellen Einsatz konzipiert. I²C (Inter-Integrated Circuit) ist ein von Phillips entwickeltes, synchrones bidirektionales zwei Draht, Master-Slave Bussystem. I²C kann auch als Multimasterbus eingesetzt werden. Um Datenverfälschung

oder

-kollision

zu

verhindern

unterstützt

I²C

im

Multimasterbus

Kollisionsbehandlung und Zugriffsarbitrierung. Ein weiterer Vorteil von I²C ist es, dass Nodes während des laufenden Betriebs ausgetauscht oder ergänzt werden können. Als Nodes bezeichnet man Slave-Geräte im Bussystem. I²C bietet theoretisch die Möglichkeit 127 Nodes und ein Master zu haben. Bei dem zwei-adrigen Kabel handelt es sich zum einen um SDA (Datenleitung) und SCL (Taktleitung). Als Datenübertragung sind mindestens 100kbit/s möglich, dabei werden von I²C aber auch andere schnellere Modi unterstützt. Ein großer Nachteil von I²C ist die Störanfälligkeit. Verfügt das Bussystem über unterschiedliche Signalkanäle, die nicht alle Teil derselben Platine sind und Abwehrmechanismen implementiert haben, kommt es zu einer gegenseitigen Beeinflussung [NXP12]. I2C Sensoren sind im Gegensatz i.d.R. lediglich als Sensorchips verfügbar und dementsprechend für Einsatz zur Erforschung des Meeres ungeeignet. Diese Sensoren könnten die Navigation und Messung der Umgebung unterstützen. 50

Da nach Aussage von Prof. Dr. Zielinski in der Meeresforschung aktuell noch RS232/485 gängige Sensorschnittstellen sind, wurde zunächst ein Bussystem mit RS485 Schnittstellen für das BeagleBone geplant. RS485 ist ein 2-Draht-Bus. Die Kommunikation erfolgt dabei nach dem Master-Slave Prinzip, bei dem eine Kommunikation von dem Master, der durch das BeagleBone realisiert wird, durch eine Anfrage initialisiert wird. Dabei steht nur ein Übertragungsweg zur Verfügung, sodass eine Kommunikation nur zwischen dem Master und einem Teilnehmer stattfinden kann [WuT]. Aufgrund verschiedener Probleme mit der Zuverlässigkeit des BeagleBones, sowie zur Lastreduktion bei der Verarbeitung der Messdaten, komplexen Datenbankabfragen und Erhöhung der Störsicherheit der verteilten Systeme wurde die komplette Sensorik auf ein Raspberry Pi ausgelagert. Es wurden Sensoren mit RS485 und SDI-12 Schnittstelle zur Verfügung gestellt und damit die Realisierung des Bussystems geplant. Mit der zunächst verwendeten RS485-Schnittstelle auf dem Raspberry Pi konnte keine Kommunikation realisiert werden, obwohl Messungen mit einem Oszilloskop eindeutig RS485-konforme Datenströme auf dem Bus nachgewiesen haben. Daher wurde mithilfe eines Arduino UNO eine SDI-12 Schnittstelle für das Raspberry Pi umgesetzt. In folgenden Abschnitten wird die aktuelle Systemarchitektur ausführlich dargestellt.

5.2.3.Systemarchitektur Die Systemarchitektur des MOPS besteht aus einem BeagleBone Black, Raspberry Pi Modell B und einem Arduino Uno (vgl. Abbildung 17). Dabei repräsentiert das BeagleBone Black das Onboard-System (vgl. Kapitel 5.6.). Die Schnittstelle zur Außenwelt wurde über einen WLAN Access Point auf dem Raspberry Pi realisiert (vgl. Kapitel 5.4.). Das Arduino Uno bindet die Sensoren über SDI-12 in die Systemarchitektur ein. Die Busleitung wurde mit NMEA2000 Kabeln, die speziell für den maritimen Einsatz konzipiert wurden, realisiert (vgl. Kapitel 5.5.).

51

Abbildung 17: SDI-12 Bussystem Als Busprotokoll wurde SDI-12 verwendet. SDI-12 ist ein Akronym für „Serial Data Interface at 1200 Baud“. Es ist ein einfach realisierbares Master-Slave Bussystem und unterstützt bis zu 62 Sensoren. Des Weiteren ist es ein so genannter 1-Draht Bus. Das heißt die Kommunikation findet über eine serielle Datenleitung statt. Neben der Datenleitung gibt es in SDI-12 noch eine 12V Stromleitung sowie die Erdung. Die Kommunikation wird durch das Aussenden einer Adresse gestartet. Dabei antwortet nur der Sensor mit der entsprechenden Adresse. Alle übrigen Sensoren verbleiben im Standby Modus, der i.d.R. weniger Strom verbraucht, was hinsichtlich der hier eingesetzten Stromversorgung über eine 12V Batterie von Vorteil ist. Ein besonderer Vorteil im Vergleich zu anderen Bussystemen ist, dass die Kommunikation für Menschen lesbar ist, da sie im ASCII-Zeichensatz erfolgt und so leicht debuggt werden kann [SDI12].

5.3. Busleitung NMEA20007 ist ein auf CAN basierendes Bussystem und wird vorwiegend in der Schifffahrt eingesetzt. Daher haben wir uns für folgende Konfiguration (vgl. Abbildung 18) auf dem MOPS entschieden. Die NMEA2000 Kabel sollten zunächst mit einem RS485 Bussystem genutzt werden, was allerdings wie eingangs erläutert fehlschlug. Daher wurden sie im SDI-12 Bussystem, aufgrund ihrer besonderen Eignung für den maritimen Einsatz, wiederverwertet. Es kann eine maximale Spannungsversorgung über das Bussystem von 60V bei 4A erfolgen [SVB].

7 https://www.nmea.org

52

Abbildung 18: Busleitung Die verwendeten NMEA2000 Bauteile sind in Tabelle 23 dargestellt. Bezeichnung

Artikel Nr.

Anzahl

Kosten (€)

NMEA2000-Micro Kabel (in Meter)

60531

8

64,00

NMEA2000-Micro T-Stück

60535

4

87,60

NMEA2000-Micro Abschlusswiderstand männlich

60537

1

11,90

NMEA2000-Micro Abschlusswiderstand weiblich

60538

1

11,90

NMEA2000-Micro Stecker männlich

60533

10

179,00

NMEA2000-Micro Stecker weiblich

60532

6

113,40

NMEA2000-Micro Stromversorgungskabel

60546

1

43,90

NMEA2000-Micro Wanddurchführung

60534

4

27,90

Gesamtkosten

539,60

Tabelle 23: NMEA2000 Bauteile Da NMEA2000 eigentlich ein auf CAN basierendes Bussystem ist, ist in der nachfolgenden Tabelle die NMEA2000 Kabelspezifikation und Verwendung mit SDI-12 dargestellt.

53

Kabelfarbe

Name

SDI-12

weiß

CAN_High

-

blau

CAN_Low

SDI-12 Datenleitung (0-5V)

Grau/Silber

Erde

Abschirmung

rot

V+

Stromversorgung 12V

schwarz

V-

Stromversorgung GND

Tabelle 24: Kabelspezifikation Bei jedem Aufbau sollte mit einem Durchgangsprüfer sichergestellt werden, dass bei keinem Kabel eine Verbindung mit der Erdung besteht (außer bei GND), weil sonst ein Kabel beschädigt ist.

5.4. Raspberry Pi Der Raspberry Pi ist ein kreditkartengroßer Einplatinencomputer. Entwickelt wurde er von der britischen Raspberry Pi Foundation. Die Platine enthält ein Ein-Chip-System von Broadcom mit einem 700-MHz-ARM11-Prozessor, sowie 512 MB Arbeitsspeicher. Das verwendete Modell B hat zusätzlich eine Ethernet-Schnittstelle und einen zweiten USB-Anschluss. Als Betriebssystem wird eine angepasste Version von Debian Wheezy verwendet. Eine eigene Festplatten-Schnittstelle ist nicht vorhanden, daher wird stattdessen eine 8GB große SD-Speicherkarte benutzt. Für die Kommunikation mit der Außenwelt bietet der Raspberry Pi folgende Schnittstellen: •

2x USB 2.0 Host-Anschlüsse

•

1x Composite Video-Ausgang

•

1x HDMI-Ausgang (Video & Audio)

•

1x 3,5mm Klinke-Audio-Ausgang

•

1x SD-/MMC-Karten-Slot (Unterstützung für SDIO und SDHC)

•

1x Ethernet-Port (10/100 MBit)

•

21x GPIO-Pins, teilweise gedacht als UART, SPI und I2C

Des Weiteren besitzt das Raspberry Pi frei programmierbare GPIO’s (General Purpose Input/Output), worüber beispielsweise LEDs angesteuert werden können. Zur Programmierung der GPIO's existieren bereits eine Vielzahl an Bibliotheken für verschiedene Programmiersprachen. Die Stromversorgung wird über einen Micro-USB Anschluss mit 5V/1A realisiert. 54

5.5. Arduino Uno Der Arduino Uno R3 ist der so genannte Standard-Arduino. Die meisten Bibliotheken sind für ihn entwickelt worden. Er ist der neuste, der am längsten weiterentwickelten Arduino-Reihe. Eine frühere Version des Arduino Uno (Arduino USB) ist das Board gewesen, welches als erstes Arduino genannt wurde. In der aktuellen Revision 3 besitzt der Uno 14 Digitale I/O Pins sowie 6 analoge Eingänge. Er besitzt eine Spannungsregelung und darf mit 12V über einen Hohlstecker versorgt werden, kann aber auch an bereits geregelte 5V angeschlossen werden und besitzt folgende Charakteristika: •

32K Flash (0,5 werden vom Bootloader verwendet.)

•

2K SRAM

•

1K EEPROM

•

16 MHz (Prozessortakt)

Neben dem USB-B Anschluss verfügt der Uno noch über folgende Schnittstellen: •

Klinkenbuchse (2.1mm , 6-20 V möglich)

•

SPI

•

I²C

•

ICSP

Zur Realisierung einer einfachen Anschlussmöglichkeit der SDI-12 Busleitungen wurde ein kleines „Cape“ (vgl. Abbildung 19 und 20) für das Arduino entwickelt. Die Dioden geben dabei Auskunft über den aktuellen Status und das Senden und Empfangen von Daten (vgl. Tabelle 25). Gleichzeitig dient das Cape als Spannungsversorgung des Raspberry Pis. Auf dem Arduino Cape wurde der Abschlusswiderstand auf 180 Ohm verringert. Damit entspricht die Busleitung nicht mehr der Spezifikation. Der Widerstand musste verringert werden, da mit Hilfe eines Oszilloskops festgestellt wurde, dass die Flanken bzw. Täler der Datensignale nicht mehr maschinell erkennbar waren. Durch die Verringerung des Widerstandes wird der Übergang von High zu Low deutlicher und somit wieder erkennbar.

55

Abbildung 19: Arduino Uno Cape

Abbildung 20: Schaltplan Arduino Cape

56

LED

Verwendung

LED1 RED

Stromversorgung

LED2 RED

-

LED3 BLUE

Befehl empfangen ; Seriell / USB (aufblinken)

LED4 WHITE

-

LED5 BLUE

Antwort empfangen und an USB weitergeleitet ; SDI-12, Seriell / USB (toggle)

LED6 WHITE

-

LED7 RED

+5V, 3A Spannungsversorgung Raspberry PI

Tabelle 25: Status Dioden Arduino Cape

57

5.6. BeagleBone Das BeagleBone ist ein kleiner, günstiger Einplatinen-Computer von Texas Instruments mit ARMArchitektur, welcher als Kommandozentrale verwendet wird. Es koordiniert die LangstreckenFunkverbindung und kümmert sich um die Navigation.

Als Basis hierfür dient die Linux-

Distribution “Angström”. Diese ist speziell für eingebettete Systeme entwickelt und steht unter der Open Source Lizenz GPL. Das BeagleBone weißt folgende Eigenschaften auf [BB]: ● 1 GHz Sitara Prozessor ● 512 MB DDR3 Ram ● 2 GB Flash Speicher ● 3D Graphik Beschleuniger ● 2x USB ● 1x HDMI ● 2x 46 pin header ● 1x 10/100 Ethernet ● 5V Spannungsversorgung Im Folgenden wird zunächst der Umstieg vom BeagleBone White zum BeagleBone Black dargestellt. Anschließend erfolgt ein Überblick über die an das BeagleBone angeschlossenen Komponenten. Darauf folgend wird die Ansteuerung der Komponenten dargestellt und es wird auf im Betrieb auftretende Probleme und Lösungen eingegangen. Der Abschnitt wird mit einem Fazit abgeschlossen.

5.6.1.Umstieg vom BeagleBone White zum BeagleBone Black Von der vorherigen Projektgruppe wurde ein BeagleBone White verwendet. Aufgrund eines Hardwaredefektes war dieses nicht mehr einsatzbereit. Da das BeagleBone White nicht mehr produziert wird, wurde der Umstieg auf das Folgemodell BeagleBone Black beschlossen und umgesetzt. Das BeagleBone Black ist zukunftssicherer und weitgehend kompatibel mit der bisherigen Entwicklung.

58

5.6.2.Die Navigations- und Kommunikationsinstrumente Die, für die Navigation und Kommunikation benötigten Instrumente, werden mit dem Cape - einer Platine, welche auf das BeagleBone gesteckt wird - des BeagleBones verbunden (vgl. auch Abschnitt 5.1. - Rumpf). Da das alte Cape ebenfalls einige Defekte aufwies, wurde beschlossen dieses neu zu erstellen.

5.6.2.1. Neudesign

Um die Stabilität des Systems zu fördern, hat sich die Gruppe dazu entschlossen das BeagleBoneCape zu erneuern. Hierfür wurde mit Hilfe der Software “Eagle” aus dem alten Cape, welches auf einer Lochrasterkarte zusammengelötet war, ein Schaltplan rekonstruiert und entworfen. Auf Grundlage dieser Pläne (siehe Anhang 7.8.4. - BeagleBone Cape Schaltplan und Anhang 7.8.5. BeagleBone Cape Boardplan) wurde eine Platine geätzt, mit der alle Navigationsinstrumente verbunden sind. Die Navigationsinstrumente werden im Folgenden erläutert.

5.6.2.2. Das GPS

Das GPS-Modul NL-652ETTL der Firma Navilock besitzt einen u-blox-6-Chipsatz, welches eine sehr hohe Update-Rate (1-5HZ)8 und eine Genauigkeit von 2,5 Meter besitzt. Die Kommunikation mit dem Modul erfolgt über die UART-5 Schnittstelle. Es sendet im Sekundentakt NMEA 0183 Nachrichten. Diese Nachrichten werden zusätzlich an einen Socket geleitet. Somit können diverse Clients, wie z.B das Raspberry Pi, auf die aktuellen NMEA 0183 Nachrichten zugreifen.

5.6.2.3. Das Sparkfun Sensorboard

Das 9DOF Razor Sensorboard von Sparkfun besitzt 9 Freiheitsgrade, welche durch die 3 Sensoren ermöglicht wird: •

ITG-3200: (MEMS triple-axis gyro)

•

ADXL345 (triple-axis accelerometer)

•

HMC5883L (triple-axis magnetometer)

8 für weitere Details siehe http://www.navilock.de/produkte/G_61844/merkmale.html

59

Vor der Inbetriebnahme ist zu beachten, dass sich die Sensoren kalibrieren müssen. Um diese durchzuführen, können wir den MOPS2 beispielsweise eine Acht fahren lassen. Die Sensoren kalibrieren sich dann automatisch. Das Sensorboard sendet die Daten im Sekundentakt über die Schnittstelle UART 2.

5.6.2.4. Das XBee-Modul

Um eine hohe Kommunikationsreichweite zu erreichen, verwenden wir ein XBee-PRO®868 RF -Modell der Firma Digi International Inc. Die XBee Kommunikation erfolgt mit 24 kbps über UART 4.

5.6.2.5. Die Ansteuerung der Navigationsinstrumente

Die Sensoren des BeagleBones werden über die GPIO-Schnittstellen angesprochen. Diese lassen sich so konfigurieren, sodass sie per UART ansprechbar sind. Durch den Umstieg auf eine neue Ångström Distribution mit Kernel 3.8, ist es nicht mehr möglich, die Schnittstellen des BeagleBones ohne vorherige Deklaration anzusprechen. Es werden nun Device Trees verwendet, welche in der Theorie die Arbeit mit Capes vereinfachen sollen.

5.6.3.Ansteuerung der Navigationsinstrumente - Device Tree Overlays Aufbau eines Device Tree Overlays anhand UART5: 1. /* 2. * example init hardware for BeagleBone black 3. * 4. */ 5. /dts-v1/; 6. /plugin/; 7. 8. /{ 9.

compatible = "ti,BeagleBone", "ti,BeagleBone-black";

10.

part-number = "cape";

11.

version = "00A0";

60

12. 13.

fragment@0 {

14.

target = ;

15.

__overlay__ {

16.

pinctrl_uart5_pins: pinmux_uart5_pins {

17.

pinctrl-single,pins =
;

22.

};

23.

};

24.

};

25. 26.

fragment@1 {

27.

target = ;

/* das GPS ist an UART 5 angeschlossen, muss aber über

angesprochen werden */ 28.

__overlay__ {

29.

status = "okay";

30.

pinctrl-names = "default";

31.

pinctrl-0 = ;

32. 33.

}; };

34. 35. }; Die Zeile mit "compatible" beschreibt, welche Geräte mit dem Cape kompatibel sind. Die Angaben unter Identifizierung sind für den Dateinamen des DeviceTrees von hoher Bedeutung. Die Datei muss später -.dts lauten, damit der Kernel die Datei später findet und richtig einlesen kann. Nutzer des BeagleBone Blacks müssen zudem die Version auf "000A0" setzen, da es sonst zu Problemen kommen kann. Im Fragment 0 werden diverse Overlays, hierbei handelt es sich eigentlich um die benötigten Pins, festgelegt. Jedes Overlay bekommt einen eindeutigen Namen, über das er später konfiguriert werden kann. Das "target" ist hierbei der "am33x_pinmux", ein Controller des Kernels. Der 61

Controller spricht mittels pinctrl-single driver die einzelnen Schnittstellen an. In dem pinctrl-singleBlock werden nun die Offsets und die Modi der Pins eingefügt. Eine Übersicht über die Ports des Headers P8 und P9 befindet sich im Anhang. Nachdem die Pins konfiguriert wurden, müssen sie noch aktiviert werden. Hierfür muss wieder ein neues Fragment erstellt werden (Fragment 2), welches das jeweilige target und die passende Verlinkung zu dem Overlay in Fragment 0 besitzt.

5.6.4.Kompilieren und Laden eines Device-Trees Ist der Device Tree vollständig angelegt, kann er mit folgendem Befehl kompiliert werden: dtc – O dtb – o cape – 00A0.dtbo – b 0 - @ cape – 00A0.dts Anschließend muss die kompilierte Datei in das firmware Verzeichnis kopiert werden: cp cape – 00A0.dtbo /lib/firmware/ Um das Cape zu laden reicht nun das folgende Kommando: echo cape > /sys/devices/bone_capemgr.8/slots Um sicherzugehen, dass das Cape geladen wurde, genügt der Befehl: cat /sys/devices/bone_capemgr.8/slots Dort sollte sich dann der Name des DeviceTrees wiederfinden.

5.6.5.Universal Asynchronous Receiver Transmitter Die UART-Schnittstellen lassen sich nun wie im oberen Beispiel konfigurieren. Hierfür werden folgende Offsets und Modi benötigt:

62

Beschreibung

Offset

Modi

UART2 RX

0x150

1

UART2 TX

0x154

1

UART4 RX

0x070

6

UART4 TX

0x074

6

UART5 RX

0x0C4

4

UART5 TX

0x0C0

4

Tabelle 26: Adressen der UART Pins

5.6.6.Pulsmodulation Die Pulsmodulation (PWM) wird verwendet, um der Motorsteuerung die Steuerungssignale beider Motoren mitzuteilen. Das Steuerungssignal wird über einen Tiefpass von 50Hz moduliert. Das entspricht

einer

maximalen

Abtastungsrate

(duty)

von

0.2s=2000000ns.

Die Motorsteuerung ist so eingestellt, dass er auf einen Abtastungsbereich von [ 1000000,2000000] ns hört wobei gilt: Duty 1000000ns 1500000ns 2000000ns

Funktion -100% 0% 100%

Bedeutung Motorgeschwindigkeit maximal (Rückwärts) Mittelstellung (Leerlauf) Motorgeschwindigkeit maximal (Vorwärts)

Tabelle 27: Duty Werte des Motorcontrollers Um PWM in unserem DeviceTree nutzen zu können, müssen wir für jeden PWM Ausgang ein Overlay erstellen: Beschreibung

Offset

Modi

PWM Signal für Backboardmotor

0x020

4

PWM Signal für Steuerboardmotor

0x024

4

Tabelle 28: Adressen der PWM Pins

63

Außerdem müssen die Ausgänge aktiviert werden. Hierbei ist es wichtig, dass die Polarity auf 0 gesetzt wird. Ist der DeviceTree eingebunden, lässt sich der Tastgrad manuell wie folgt setzen: Backboard: echo $value > /sys/devices/ocp.2/pwm_P8_13.12/duty Steuerboard: echp $value > /sys/devices/ocp.2/pwm_P8_19.13/duty

5.6.7.Analoge Inputs Analoge Inputs (AIN) werden von uns verwendet, um den aktuellen Ladestand der Batterie zu ermitteln . Die Konfiguration hält sich an das folgende Tutorial: Die DeviceTree Konfiguration ist aus dem BB-ADC-Cape übernommen, welches sich im Verzeichnis /lib/firmware befindet. Die Werte der AIN Pins können anschließend über den Pfad /sys/devices/platform/omap/tsc/ainX gelesen werden. Die zu lesenden Werte liegen im Wertebereich von 0 bis 1,8 Volt.

5.6.8.Im Betrieb auftretende Probleme Ein Problem welches im laufenden Betrieb auftreten kann ist dass das BeagleBone nicht richtig startet. Erkennbar ist dies dadurch, dass nur die LED für die Spannungsversorgung blau leuchtet, aber keine anderen LEDs. Behoben werden kann dies durch wegnehmen und wiederherstellen der kompletten Spannungsversorgung des MOPS2. Des Weiteren gab es Probleme mit der Erkennung und der Konfiguration eines USB-WLAN Sticks, was zu der Entscheidung führte die WLAN Verbindung mit Hilfe des Raspberry Pi zu realisieren und das BeagleBone per Ethernet Verbindung mit dem Raspberry Pi zu verbinden.

64

5.7. Fazit Insgesamt ist es uns gelungen durch den Umstieg auf das BeagleBone Black und die Herstellung eines neuen Capes eine stabile Plattform zur Steuerung des MOPS zu erstellen. Lediglich vereinzelt treten noch kleinere Probleme auf (siehe Kapitel 5.6.8. - Im Betrieb auftretende Probleme). Durch den Umstieg auf die neue BeagleBone Version und dem damit verbundenen Wechsel des Linux Kernels kam es zu einigen Herausforderungen. Eine Hauptherausforderung bei der Neuinstallation und der Neugestaltung der Hardwareansteuerung war die oftmals nur mangelhaft verfügbare Dokumentation. Eine große Herausforderung stellte die WLAN-Verbindung dar. Ursprünglich war vorgesehen, und wie bereits beim BeagleBone White im Einsatz, das BeagleBone als WLAN Accesspoint zu nutzen. Allerdings ist die Hardwareerkennung und Netzwerkkonfiguration des verwendeten Linux Systems noch mit einigen Fehlern behaftet, was dazu führte, dass die WLAN Verbindung oftmals erst nach mehreren Neustarts problemlos hergestellt werden konnte. Aus diesem Grunde wurde sich dafür entschieden den WLAN Accesspoint mit dem Raspberry Pi zu realisieren und das BeagleBone per Ethernet mit diesem zu verbinden, was insgesamt zu einer zuverlässigen Verbindung führte. Zusätzliche Probleme betrafen die Robustheit des BeagleBone Black. So ist dieses sehr empfindlich gegen Spannungsschwankungen und andere äußere Einflüsse, was zu Defekten einzelner Komponenten führen kann, welche einen Austausch des BeagleBone zu Folge haben. Trotz der Probleme und Herausforderungen ist es uns gelungen die komplette für Steuerung und Kommunikation notwendige Hardware an das BeagleBone anzuschließen und an die Software anzubinden. Zudem wurden Möglichkeiten geschaffen, einzelne Hardwarebauteile separat an- und auszuschalten, was die Stabilität und Zuverlässigkeit des Gesamtsystems erhöht und zur Vermeidung von kompletten Systemneustarts bei auftretenden Fehlern führt. Für eine Weiterentwicklung des MOPS ist allerdings zu überlegen ob man anstelle des BeagleBone eine robustere und zuverlässigere Hardwareplattform zur Navigation und Kommunikation des MOPS einsetzt.

65

6. Fazit Im folgenden Kapitel wird ein allgemeines Fazit gegeben, in dem die erreichten Gruppenergebnisse kurz zusammengefasst und geschildert werden. Zunächst wurde innerhalb der Rumpfgruppe ein komplett neues modulares Konzept zum Unterbringung aller nötigen Komponenten erstellt. Der Aluminiumrahmen bietet Erweiterbarkeit und die Otterboxen nötigen Schutz vor der Witterung. Außerdem ist durch das modulare Konzept die Leistungselektronik von den anderen Hardwarekomponenten getrennt, was wiederum zu einer verbesserten Zuverlässigkeit der Hardware fuhrt. Durch die Neuanschaffung des Optimisten wurde auf eine erprobte und unserer Meinung nach besseren Rumpfform gesetzt, welche sehr gut im Wasser liegt und eine höhere maximale Geschwindigkeit aufweist. Der neu entwickelte Sensorkäfig bietet die Möglichkeit, die Sensoren sicher im Wasser zu bedienen. Bei dem Offboard-Softwaresystem wurde ein Augenmerk auf Verbesserungen der bestehenden Konzepte gelegt. Als wichtigstes eigenständiges Ergebnis zahlt die zusätzliche Erweiterung der Software um das Anlegen von Sperrgebieten, Linien- und Bereichsmessungen. Außerdem haben viele kleinere Änderungen, welche als Feedback der Anwender eingeflossen sind, die Usability und Nachvollziehbarkeit erhöht. Ein weiterer, wichtiger Punkt ist das automatische Optimieren der Route, wodurch es dem Anwender möglich ist, die Wegpunkte automatisch in eine sinnvolle Reihenfolge zu bringen. Des Weiteren wurde die Software mit einer Sensorverwaltung erweitert. Durch diesen neu geschaffenen Bereich können nun angeschlossene Sensoren eingelesen, bearbeitet und schließlich verwendet werden. Zusätzlich wurde eine Android-Anwendung entwickelt, mit deren Hilfe es möglich ist den MOPS2 manuell zu steuern und kritische Komponenten wie das BeagleBone neu zu starten. Auch in Bezug auf den eigentlichen Steueralgorithmus ergaben sich Fortschritte. Wird der MOPS2 vom eigentlichen Kurs abgetrieben, lenkt die Steuerung dagegen um den Kurs zu halten. Außerdem sorgt sie dafür, dass der MOPS2 nicht von der vorgeschriebenen Route abweicht. Der MOPS2 fährt somit nicht mehr ungewollt in flache oder gesperrte Gewässer. Durch den Wechsel von dem BeagleBone White auf die neue Version BeagleBone Black konnte eine zukunftssichere Plattform für die Navigation geschaffen werden. Durch die neue KernelVersion wird die derzeitige Konfiguration auch in zukünftigen Versionen verwendbar sein. Außerdem wurde durch das neue Entwerfen eines Hardware-Capes zusätzliche Stabilität erzeugt. Insgesamt treten in diesem Bereich deshalb nur noch kleinere Probleme auf. Innerhalb der Arbeitsgruppe “Sensoren” ist ein komplett neues Sensorkonzept erarbeitet, entwickelt

66

und auch umgesetzt worden. Dadurch ist jetzt möglich über das SDI12 Bussystem Sensoren zu betreiben und wie in den Anforderungen definiert, Messungen durchzuführen. Durch die modulare Entwicklung ist auch das Verwenden weiterer Sensoren möglich. Insgesamt ist zu sagen, dass es eine herausfordernde Projektgruppe für alle Beteiligten war, die für uns Studierende viele neue Arbeitsbereiche umfasst hat. Durch die freie Arbeitsweise und die selbst organisierte Arbeitsteilung konnten viele Kompetenzen erlangt werden. Es ist uns gelungen den MOPS1 auf eine neue Version zu verbessern, sodass der Name MOPS2 durchaus angebracht ist, weil die zusätzlichen Funktionen, Konzepte und Verbesserungen das Projekt vorwärts gebracht haben.

67

7. Anhang 7.1. Bedienungsanleitung Die nächsten Abschnitte enthalten eine Aufbau-, Installations- und Bedienungsanleitung für den MOPS2. Zunächst erfolgt eine Bedienungsanleitung der Offboard-Software. Anschließend wird der Aufbau des MOPS2 erläutert. Darauf folgend folgen Anleitungen für eine Neuinstallation und Konfiguration des BeagleBone, des Raspberry Pi und des Arduino.

7.2. Offboard-Software Im Folgenden wird die Benutzeroberfläche der Offboard-Software, also der Software zur Planung und Überwachung von Missionen, grob erklärt und die grundsätzlichen Schritte aufgezeigt, welche nötig sind, um eine Mission zu erstellen, durchzuführen und anschließend zu evaluieren. Hierfür werden teilweise Screenshots des aktuellen Stands der Software genutzt. Zunächst wird allerdings aufgezeigt, welche Voraussetzung für den Betrieb der Software erfüllt sein müssen und welche Schritte für die Inbetriebnahme der Software nötig sind.

7.3. Installation und Voraussetzungen Um die Software nutzen zu können, sind nur wenige Schritte notwendig. Für die Installation der eigentlichen

Software

muss

lediglich

der

Dateiordner,

in

welchem

die

Datei

MOPSConfigurationTool.jar enthalten ist, von dem in diesem Dokument beiliegenden Datenträger an einen beliebigen Ort auf dem ausführenden Computer kopiert werden. Um die Software anschließend verwenden zu können, muss auf dem Computer eine Java-Laufzeitumgebung der Version 7 oder höher installiert und eingerichtet sein. “Innerhalb der Software besteht die Möglichkeit das Wasserfahrzeug über einen Gamecontroller der Playstation 3 der Firma Sony (bspw. DualShock) fernzusteuern. Soll diese Funktionalität Anwendung finden, ist es notwendig, dass die Treiber dieses Gerätes vor dem Start der Anwendung installiert werden. Da die Firma Sony den Einsatz des Controllers an herkömmlichen Computern nicht unterstützt, muss auf Treiber von Drittanbietern zurückgegriffen werden. Eine gute Möglichkeit stellt das Projekt MotioninJoy dar. Neben den Gamecontrollern der Playstation 3 werden auch die der Xbox 360 der Firma Microsoft unterstützt. Anleitungen zur Installation der jeweiligen Treiber sind beispielsweise im Wiki des Projektes zu finden.” [AB] 68

Um die Anwendung nach erfolgreicher Einrichtung zu starten, muss die zuvor kopierte Datei ‘MOPSConfigurationTool.jar’ ausgeführt werden. Auf einem System mit einem WindowsBetriebssystem reicht hierfür ein Doppelklick auf das Dateisymbol aus. Alternativ dazu kann die Datei durch den Befehl “java -jar MOPSConfigurationTool.jar” mittels der Konsole (cmd) gestartet werden. Unter Linux-basierten Betriebssystemen kann die Software durch analoges vorgehen gestartet werden.

7.3.1.Benutzeroberfläche Im Folgenden wird die Benutzeroberfläche der Missionsplanungssoftware dargestellt und kurz erläutert. Es wird auf die wichtigsten Bedienelemente eingegangen und die Möglichkeiten sowie die Abläufe beim Erstellen, Durchführen und Evaluieren einer Mission aufgeführt.

7.3.1.1. Einstieg

Wurde die Software wie weiter oben beschrieben gestartet, wird die Benutzeroberfläche dargestellt. Über diese ist es dem Benutzer möglich, mit der Software und auch eingeschränkt direkt mit dem MOPS2 zu interagieren. Beim Start wird zunächst immer die Missionskarte im Planungsmodus dargestellt. Es werden einige Reiter, welche im folgenden Abschnitt näher beschrieben werden, dargestellt, mit denen es möglich ist zwischen verschiedenen Funktionsbereichen der Software zu wechseln. Am oberen Rand des Anwendungsfensters befindet sich das Menü, welches verschiedene Aktionen und Einstellungsmöglichkeiten beinhaltet. Einige elementare Funktionen sind, zu einfacheren Handhabung, in die etwas darunter platzierte Toolbar ausgelagert. Aktuell nicht mögliche Aktionen sind dabei ausgegraut. Am unteren Rand der Software ist eine Statusleiste zu sehen, welche Auskunft über die Verbindungszustände der Software gibt. Auf das Menü, die Toolbar und die Statusleiste wird ebenfalls in den folgenden Abschnitten näher eingegangen. Auf der linken Seite über der Statusleiste werden in eckigen Klammern die Koordinaten der aktuellen Position des Mauszeigers angezeigt, wenn dieser sich über der Karte befindet.

69

Abbildung 21: Benutzeroberfläche im Startzustand

7.3.1.2. Funktionalsbereiche

Die Benutzeroberfläche bietet drei verschiedene Gruppierungen von Reitern zum Wechseln zwischen verschiedenen Funktionsbereichen. Die in Abbildung 7.2 markierten Reiter repräsentieren die drei Hauptfunktionsbereiche: Mission, Messdaten und Log-Daten. Über den ersten erreicht man die grafische Missionskarte, auf welcher die Mission geplant, durchgeführt und die Durchführung nachverfolgt werden kann. Im Bereich Messdaten lassen sich Daten der vom MOPS2 durchgeführten Messungen anzeigen und exportieren. Im letzten Hauptbereich Log-Daten werden aktuelle missionsbezogene Log-Ausgaben des MOPS2 gesammelt und angezeigt.

70

Abbildung 22: Reiter zur Auswahl des Hauptfunktionsbereiches Ist der erste Reiter und somit der Funktionsbereich Mission ausgewählt, so wird eine große Karte angezeigt. Die Karte kann mit gedrückt gehaltener rechter Maustaste verschoben werden und der Ausschnitt entweder mit den unten links befindlichen Steuerelementen oder dem Mausrad vergrößert und verkleinert werden. Auf der rechten Seite ist ein Bereich mit Bedienelementen platziert, welcher ebenfalls verschiedene Funktionsbereiche bietet. Diese sind durch die Reiter Planung und Durchführung repräsentiert. Beide Funktionsbereiche beziehen sich hier auf die selbe Karte und Mission, weshalb sie im selben Hauptbereich Mission untergebracht sind. Auf die unterschiedlichen Inhalte und Bedienelemente wird in den Abschnitten Durchführen- und Erstellen und bearbeiten einer Mission eingegangen.

Abbildung 23: Reiter zur Auswahl des missionsbezogenen Funktionsbereiches Auf der Karte ist das anlegen, bearbeiten und löschen von Wegpunkten, Bereichsmessungen, Linienmessungen und Sperrgebieten möglich (siehe Abschnitt 7.3.2.1. - Erstellen und bearbeiten einer Mission). Sollten bereits solche Missionselemente vorhanden sein, so werden diese in der jeweiligen Liste auf der rechten Seite dargestellt. Für die vier unterschiedlichen Elemente gibt es jeweils eine eigene Liste und Bedienelemente zur Interaktion mit diesen. Die Ansicht kann durch Auswahl des entsprechenden Reiters innerhalb des Planungsreiters gewechselt werden.

71

Abbildung 24: Reiter zur Auswahl der jeweiligen Planungsliste 7.3.1.3. Menü

Die am oberen Rand der Benutzeroberfläche befindliche Menüleiste beinhaltet verschiedene Funktionalitäten und Einstellungsmöglichkeiten, welche folgend kurz erklärt werden.

Abbildung 25: Menüleiste am oberen Rand der Anwendung

Datei: Bietet Möglichkeiten zum anlegen einer neuen Mission (ACHTUNG: Die aktuelle Mission wird verworfen, wenn diese nicht gespeichert ist.), sowie zum importieren und exportieren von Missionen. Importieren entspricht dem Laden einer zuvor gespeicherten Mission und exportieren entspricht dem speichern einer Mission. Außerdem können hier Verläufe - d.h. Aufzeichnungen der Positionen des MOPS2 während einer Mission - gespeichert und später bei Bedarf wieder geladen werden. Schlussendlich ist noch eine Funktion zum Beenden der Software vorhanden. Bearbeiten: Beinhaltet die Funktionen zum Rückgängig machen von Änderungen an der Mission, wie zum Beispiel dem Anlegen eines Wegpunktes, und dem Wiederherstellen von rückgängig gemachten Änderungen. Kommunikation: Da sich in diesem Menü nichts essentielles zur Vorgängerversion geändert hat, sei an dieser Stelle an das Handbuch im Abschlussbericht der Projektgruppe MOPS1 verwiesen. Extras:

Mit dem Eintrag Tile-Update

kann eine Aktualisierung der lokal gespeicherten

Kartenausschnitte, aus welchen sich die Karte zusammensetzt, angestoßen werden. Dies ist

72

sinnvoll, wenn aktuelleres Kartenmaterial online vorhanden sein sollte. Der Vorgang kann im anschließend angezeigten Statusfenster bei Bedarf wieder abgebrochen werden. Die Funktion Route optimieren versucht die Reihenfolge der Wegpunkte möglichst optimal anzupassen. Die aktuell vorhandene Optimierungsart Basis Optimierung fängt beim Startwegpunkt, also dem ersten in der Liste, an und wählt dann sukzessiv immer den Wegpunkt als nächsten aus, welcher am nächsten am vorhergehenden liegt. Die Funktion Meide gesperrte Bereiche führt Streckenabschnitte, die einen gesperrten Bereich durchlaufen, auf kürzestem Wege um diese gesperrten Bereiche herum, in dem zusätzliche Wegpunkte in der nähe einiger Kanten des Sperrbereichs erstellt werden. Ansicht: Dieses Menü bezieht sich auf die grafische Darstellung auf der Karte. Route zeichnen gibt an, ob die einzelnen Wegpunkte mit einer schwarzen Linie verbunden werden sollen. Das Untermenü MOPS Verlauf bezieht sich hingegen auf die GPS Punkte, welche Positionen des MOPS während einer Mission repräsentieren. Hier kann ausgewählt werden, ob lediglich die aktuelle Position des MOPS durch eine pfeilförmige Grafik oder der gesamte Verlauf durch Fahnensymbole dargestellt werden soll. Anhand der Option GPS Punkte verbinden können diese analog zu den Wegpunkten miteinander verbunden werden. Der letzte Eintrag löscht alle bis dahin vom MOPS empfangenen GPS Punkte. Optionen: Bietet verschiedene Möglichkeiten zur Einstellung der Software. So lässt sich die Sendeleistung des XBee, welche ausschlaggebend für die Reichweite ist, in mehreren Stufen einstellen, sowie das Gamepad kalibrieren, um dessen korrekte Funktion zu gewährleisten. Im Offline-Modus wird die Karte nicht aus dem Internet nachgeladen, sondern die lokal gespeicherten Kartenausschnitte verwendet. Die Funktion Nach Sensoren suchen bietet die Möglichkeit abzufragen, welche Sensoren aktuell an den MOPS angeschlossen sind. Dies funktioniert nur, wenn eine Verbindung zum MOPS vorhanden ist. Unter Sensorverwaltung lassen sich diese dann einsehen und bearbeiten.

7.3.1.4. Toolbar

Die Toolbar enthält einige Buttons, die die elementarsten Funktionen enthalten. Dadurch wird einem für häufig nötige Interaktionen ein einfacherer Weg geboten als über die Menüleiste. Sollten Funktion im aktuellen Moment nicht sinnvoll oder nicht möglich sein, so sind die entsprechenden Buttons ausgegraut.

73

Abbildung 26: Toolbar bei Startzustand der Software 1 = Neue Mission 2 = Mission exportieren 3 = Mission importieren 4 = Rückgängig 5 = Wiederherstellen

6 = Mission starten 7 = Mission stoppen 8 = Tile-Update 9 = Route optimieren 10 = Meide gesperrte Bereiche

7.3.1.5. Statusleiste

In der am unteren Rand der Benutzeroberfläche befindlichen Statusleiste werden die aktuellen Verbindungszustände grafisch dargestellt. Auf der linken Seite befinden sich die Statusanzeigen für die W-LAN und die XBee Verbindungen.

Abbildung 27: Statusleiste am unteren Rand der Anwendung

Eine rote Anzeige bedeutet hier, dass keine Kommunikationsverbindung zum MOPS auf dem jeweiligen Kanal besteht. Eine gelbe Anzeige bedeutet, dass diese Verbindung aktuell aufgebaut wird. Wird die Anzeige grün dargestellt, so besteht eine Verbindung zum MOPS. Die Anzeige Online auf der rechten Seite visualisiert die Verbindung der Anwendung zum Internet. Ist die Anzeige grün, so wird die Karte aus dem Internet geladen, ist sie hingegen rot, dann werden keine Kartendaten aus dem Internet nachgeladen. Zweiteres ist vor allem bei schlechten Internetverbindungen, wie mobilen Verbindungen, empfehlenswert.

7.3.2.Bedienung 7.3.2.1. Erstellen und bearbeiten einer Mission

Befindet man sich in der Ansicht Karte/Mission und Planung ist es möglich eine Mission zu planen. Durch verschieben und Einstellen der Zoomstufe der Karte kann der gewünschte Bereich angezeigt 74

werden. Anschließend können auf der Karte neue Wegpunkte platziert werden. Dafür muss ein Doppelklick auf die ungefähre gewünscht Position des Wegpunktes ausgeführt werden. Anschließend öffnet sich ein ein Dialog zum Erstellen / Bearbeiten eines Wegpunktes. Die Position des Mauszeiger im Moment des Doppelklicks wird zunächst als in die Beiden oberen Felder für die Koordinaten des neuen Wegpunktes eingetragen, können hier aber noch manuell eingestellt werden. Zusätzlich ist die Angabe eines Radius möglich. Der Radius beschreibt den Umkreis um den Wegpunkt, in welchem der Wegpunkt als erreicht gilt. Da die GPS-Werte eine gewisse Ungenauigkeit aufweisen ist ein Mindestwert von 4 Metern erforderlich. Die Verweildauer gibt an, wie lange an diesem Wegpunkt gewartet wird, bevor der nächste angefahren wird. So können Messungen über einen gewissen Zeitraum an diesem Wegpunkt durchgeführt werden. Während dem Verweilen manövriert der MOPS autonom soweit wie es nötig ist, um in dem angegeben Radius zu bleiben. Im Feld Name kann ein Bezeichner für den Wegpunkt angegeben werden, mit welchem dieser anschließend in der Liste und auf der Karte bezeichnet wird. Im Abschnitt Sensoren können die für diesen Wegpunkt gewünschten Sensoraktivitäten eingestellt werden. Ist der jeweilige Sensor ausgewählt so wird dieser, sofern dies nicht vorher schon geschehen ist, beim Erreichen oder Verlassen des Wegpunktes aktiviert. Analog dazu wird dieser bei nicht aktiviertem Eintrag deaktiviert.

Abbildung 28: Dialog zum Erstellen / Bearbeiten eines Wegpunktes Wird die der Mauszeiger verschoben, während ein die linke Maustaste gehalten wird, so kann ein Rechteck aufgespannt werden. Wird anschließend die linke Maustaste losgelassen, so öffnet sich ein 75

Dialog, in welchem gewählt werden kann, ob ein Sperrgebiet, eine Bereichsmessung oder eine Linienmessung erstellt werden soll. Wird Bereichsmessung gewählt, werden innerhalb des gewählten Rechtecks in eingestellten Abständen Wegpunkte gesetzt. Im Falle der Linienmessung werden Wegpunkte in eingestellten Abständen verteilt auf einer geraden Strecke zwischen dem Start- und Endpunkt des Rechteck-Aufspannens verteilt. Sperrgebiete werden als rote halbtransparente Rechtecke auf der Karte dargestellt.

Abbildung 29: Dialog für Bereichsauswahl Nachdem Elemente auf der Karte platziert wurden, können diese anschließend bearbeitet oder entfernt werden. Dafür gibt es mehrere Möglichkeiten: Zum einen gibt es am unteren Ende der jeweiligen Listenansicht Bedienelemente zum Löschen und Entfernen der jeweiligen Elemente. Zum anderen können Wegpunkte auch durch anklicken, direkt auf der Karte selektiert und per Drag & Drop verschoben werden. Durch einen Rechtsklick auf einen Wegpunkt auf der Karte öffnet sich außerdem ein Kontextmenü welches ebenfalls Funktionen zum löschen oder bearbeiten des jeweiligen Wegpunktes bereitstellt.

Abbildung 30: Bedienelemente in der Listenansicht für Wegpunkte Anhand des Bedienelements Reset kann eine Mission komplett gelöscht werden. Sollte eine Mission fertiggestellt sein und soll wie im Nachfolgenden Abschnitt beschrieben ausgeführt werden, so muss diese zuvor an den MOPS übertragen werden. Dafür ist die Schaltfläche Mission übertragen im unteren rechten Bereich der Planungsansicht vorhanden. Sollte keine Verbindung

76

zum MOPS bestehen oder ein Fehler bei der Übertragung auftreten, so wird Dialog mit einer Fehlermeldung geöffnet.

Abbildung 31: Dialog mit Fehlermeldung

7.3.2.2. Durchführen eine Mission

Durch auswählen des Reiters Durchführung wird zum Bereich der Missionsdurchführung gewechselt. Hier kann die zuvor übertragene Mission gestartet, gestoppt und fortgesetzt werden. Aktuell laufende Missionen werden auf der Karte, je nach Einstellungen im Menü Ansicht, visualisiert. Die aktuelle Position, sowie der Verlauf der empfangen Position, MOPS werden ausschließlich in dieser Ansicht angezeigt. Im oberen Bereich werden verschiedene während einer Mission interessante Telemetriedaten angezeigt. Für eine genauere Beschreibung wird auf das Handbuch der vorangegangen Projektgruppe MOPS1 verwiesen. Die Schaltfläche Über akt. GPS-Pos. zentrieren sorgt dafür, dass die Kartenansicht über der letzten Position des MOPS zentriert wird. Darunter befinden sich die Optionen zur Fernsteuerung, welche in einem späteren Abschnitt erläutert werden. Wird die am unteren Ende liegende Schaltfläche Notaus betätigt, so werden die Motoren des MOPS augenblicklich ausgeschaltet und alle anderen Befehle gestoppt.

77

Abbildung 32: Bereich zur Durchführung und Überwachung einer Mission

7.3.2.3. Evaluieren einer Missionsdurchführung

Messdaten Im Reiter Messdaten hat der Anwender die Möglichkeit die Messdaten aus der Datenbank auszulesen. Dazu kann der Anwender einfach den Button “Messungen aktualisieren” anklicken. Möchte man zusätzliche Informationen angezeigt bekommen, so lassen sich diese mit einem Klick auf eine Zelle in der Tabelle anzeigen. Der Klick auf eine Sensor-Zelle liefert ein Dialog mit Sensor-Informationen, die Parameter-, die Wert- und die Einheit-Zellen zeigen Informationen zum Parameter an und ein Klick auf eine Ort-Zelle öffnet den Browser mit OpenStreetMap an genau der angegebenen Position. Darüber hinaus gibt es die Möglichkeit Messungen zu löschen und alle angezeigten Messungen in ein gewünschtes Format zu exportieren. Zur Zeit wird nur das XML-Format unterstützt. 78

Abbildung 33: Funktionsbereich der Messdatenerfassung Log-Daten Der Funktionsbereich, der über den Reiter Log-Daten zu erreichen ist, bietet die Möglichkeit die vom MOPS empfangenen Log-Daten einzusehen. Diese lassen sich anschließend durch die Buttons am unteren Rand speichern, bei Bedarf erneut laden oder zurücksetzen. Für eine detailliertere Beschreibung der eingehenden Log-Daten sei an dieser Stelle erneut auf das Benutzerhandbuch der Abschlussdokumentation der vorangegangenen Projektgruppe MOPS1 verwiesen.

79

Abbildung 34: Funktionsbereich der Log-Daten-Erfassung

7.3.2.4. Manuelle Steuerung

Die Software bietet zusätzlich die Möglichkeit den MOPS2 manuell fernzusteuern. Hierfür gibt es im Funktionsbereich Durchführung die Möglichkeit zwischen drei Optionen zu wählen.

80

Abbildung 35: Optionen zur Fernsteuerung Wird Gamepad gewählt, dann besteht bei angeschlossenem und korrekt installiertem Gamepad die Möglichkeit den MOPS mit diesem zu steuern. Zuvor sollte eine Gamepadkalibrierung durchgeführt werden. Wird die Option Graphisch selektiert öffnet sich ein Dialog, welcher die Steuerelemente beinhaltet.

Abbildung 36: Grafische Fernsteuerung Durch Verschieben des vertikalen Schiebereglers kann anschließend die Schubkraft geregelt werden. Dies ist sowohl vorwärts, als auch rückwärts gerichtet möglich. Mit dem horizontalen Schieberegler, kann der MOPS2 dann in die jeweilige Richtung gelenkt werden.

81

7.3.2.5. Sensoren verwalten

Die Sensorverwaltung erlaubt es die Sensoren in der Datenbank hinzuzufügen, zu bearbeiten und wieder zu löschen. Dazu ist die Sensorverwaltung in drei Bereiche aufgeteilt. Der erste Bereich erlaubt es Sensoren hinzuzufügen, zu bearbeiten und wieder zu löschen, der zweite Bereich erlaubt es Parameter hinzuzufügen, zu bearbeiten und zu löschen und der dritte und letzte Teil schließlich kombiniert die Parameter mit den entsprechenden Sensoren. Auch hier können Einträge hinzugefügt, bearbeitet und wieder gelöscht werden. Um Einträge in einem der drei Bereich zu bearbeiten oder zu löschen muss der entsprechende Eintrag vorher ausgewählt werden.

82

Abbildung 37: Dialog zur Verwaltung der Sensoren Das Sensor suchen erlaubt es nach aktuell verfügbaren Sensoren zu suchen und diese anschließend in einer Mission zu verwenden. Dazu kann klickt man im Dialog Sensoren suchen einfach auf suchen und wartet einen kleinen Moment. Sollten Sensoren gefunden werden, die noch nicht in der Datenbank eingetragen wurden, so wird man anschließend aufgefordert diese Sensoren in der Datenbank einzutragen. Später können dann in der Sensorverwaltung noch Parameter eingetragen und zugeordnet werden. 83

Abbildung 38: Dialog zur Suche nach verfügbaren Sensoren

7.4. MOPS Aufbau Dieser Abschnitt befasst sich mit der Inbetriebnahme des MOPS2. Im folgenden finden Sie die nötigen Schritte in einer Bauanleitung.

7.4.1.Aufladen der Batterie Zuerst sollte überprüft werden, ob die Batterie voll aufgeladen ist, damit die maximale Fahrzeit des MOPS2 ausgeschöpft werden kann. Die Batterie zeigt über die runde Kontrollanzeige den Ladezustand an. Dabei umfasst die Batterie drei Status:

84

Green Eye - Charge over 65%, BATTERY PROPERLY CHARGED Black Eye - Charge under 65%, DISCHARGED BATTERY NEEDS TO BE RECHARGED Electrolyte level too low, BATTERY MUST BE REPLACED Beim Aufladen der Batterie sollte die Funktion Pb aufladen und 5A Stromstärke eingestellt werden. Das Ladegeräte sollte im Regelfall die Batterie erkennen und automatisch die Spannung einstellen. Es muss dennoch beachtet werden, dass die Batterie nicht mit mehr als 14,4V geladen wird, da aus diesem Vorgang Beschädigungen der Batterie resultieren. Es sollte bedacht werden, dass der Ladevorgang mehrere Stunden in Anspruch nimmt. Es empfiehlt sich die Batterie einen Tag vorher zu kontrollieren und aufzuladen. Beim Entladen der Batterie muss darauf geachtet werden, dass die Spannung niemals unter 11V fällt.

Abbildung 39: Alukonstruktion ohne Otterboxen und Schwimmerkörper

7.4.2.Zusammenbau des Bugsegments Liste der benötigten Teile 1x Batteriebox (blau) 1x obere Abdeckung 85

1x unteres Gehäuse 4x Gummihalterungen 1x Batteriesteckverbindung mit zwei Klemmen 1x Vetus Marine Batterie 12 v 108 AH 1x M6 Sechskantmutter DIN934, A2 1x Sechskantschraube DIN933, A2 Edelstahl, M6 x 60mm Der erste Schritt beim Zusammenbau des Bugsegments ist die Zusammensetzung der Batteriebox (blau). Dazu wird die Batterie in das untere Gehäuse (mit der blauen Markierung) eingesetzt. Sollte die Kontrollanzeige der Batterie nicht grün sein, empfehlen wir das Aufladen der Batterie (siehe Kapitel 7.4.1. - Aufladen der Batterie). Als nächstes wird die rote Klemme der Steckverbindung an den Pluspol und die schwarze Klemme an den Minuspol der Batterie geklemmt. Danach wird die obere Abdeckung auf das untere Gehäuse gesteckt. Es muss darauf geachtet werden, dass das obere Gehäuse alle Seiten abdeckt und richtig befestigt wird. Dazu müssen die 4 Gummihalterungen an den Haken des unteren Gehäuses und den Noppen des oberen Gehäusen angebracht werden. Nach dem korrekten Schließen der Box kann diese vorne rechts bei der blauen Markierung eingesetzt werden. Danach wird die Querstange über die Batteriebox umgeklappt. Die Stange befindet sich nun auf der Rahmenstange in der Mitte des Rumpfs. Hier wird nun die M6 Sechskantschraube durch die Öffnung der Querstange und die Winkel an der Rahmenstange geführt und mit einer Sechskantmutter M6 verschraubt. Als letztes wird die Batteriesteckverbindung durch die Öffnung im Brett in der Mitte des Rumpfs gezogen, um diese Steckverbindung später mit der Box 1 Leistungselektronik (rot) zu verbinden..

Abbildung 40: Blaue Batteriebox

86

Abbildung 41: Schwarze Otterbox mit Gewichten

7.4.3.Zusammenbau des Hecksegments Liste der benötigten Teile 1x Box 1 Leistungselektronik (rot) 1x Motorcontroller Sabertooth 2x60 1x Relais 1x Steckverbindung mit Klemmen 2x Steckverbindung 1x Box 2 Raspberry Pi (gelb) 1x Arduino Uno 1x Raspberry Pi 1x Box 3 BeagleBone (grün) 1x BeagleBone Black 1x Cape für das BeagleBone 1x XBee Pro 868 1x Sensorboard 9DOF Razer IMU 1x GPS Navilock NL-652ETTL 1x M6 Sechskantmutter DIN934, A2 1x Sechskantschraube DIN933, A2 Edelstahl, M6 x 60mm

87

In Box 1 Leistungselektronik (rot) befinden sich die benötigten Teile für die Steuerung der Motoren einschließlich der Not-Aus-Komponente. Über die Eingänge M1a, M1b und M2a, M2b sind die Motoren angeschlossen. Der Notaus liegt direkt an den Eingängen B+ und B-. Über die Eingänge S1 und S2 werden die PWM-Werte geschrieben. Box 1 Leistungselektronik (rot) muss nun an die rot markierte Stelle im MOPS angebracht werden.

Abbildung 42: Rote Elektronikbox In Box 2 Raspberry (gelb) befinden sich die Komponenten, um die Sensordaten aufzunehmen und zu verarbeiten. Das Raspberry steuert das Arduino Uno über den USB-Eingang und speichert die Sensordaten. Über das Ethernet ist das Raspberry mit dem BeagleBone verbunden, darüber hinaus stellt das Raspberry das WLAN-Signal. Es verfügt über verschiedene Kontroll-LEDs.

Kürzel

Diode

Farbe

Beschreibung

ACT

D5

grün

SD Card Access

PWR

D6

rot

3,3 V Power present

FDX

D7

grün

Full Duplex, LAN connected

LNK

D8

grün

Link Activity

100

D9

gelb

100 M/bit Lan connected

Tabelle 29: Raspberry Pi Kontroll LEDs

88

Abbildung 43: Gelbe Elektronikbox Das Arduino Uno stellt die Anfragen an die Sensoren über das Bus-System. Auf dem Arduino Uno befindet sich ein Cape mit dem die Stromversorgung geregelt wird. Es verfügt darüber hinaus über verschiedene Kontroll-LEDs. Die Box kann nun geschlossen und an der vorgesehenen Stelle (gelb) platziert werden.

LED

Verwendung

LED1 RED

Stromversorgung

LED2 RED LED3 BLUE

Befehl empfangen, Serial / USB (aufblinken)

LED4 WHITE LED5 BLUE

Antwort empfangen, SDI-12 (toogle)

LED6 WHITE Tabelle 30: Arduino Uno Kontroll LEDs

In Box 3 BeagleBone (grün) befindet sich die Hardware auf der die Onboard-Software läuft und den MOPS2 mit einem geeigneten Algorithmus autonom manövrieren lässt. Mit Hilfe des aufgesteckten Capes lassen sich das GPS, das Sensorboard und das XBee verwenden. Die Antenne ist mit einem RP-SMA Stecker mit dem XBee-Modul verbunden. Hierüber werden per Funk Steuersignale wie z.B. Missionspunkte zum MOPS 2 geschickt. Das Sensorboard von Sparkfun steckt über die folgende Pin-Verbindung auf dem BeagleBone. 89

Anschluss

Kabel

x1

braun

o1

kein Kabel

x2

weiß

x3

grün

x4

gelb

o2

kein Kabel

Tabelle 31: Pin-Verbindung Sensorboard

Außerdem ist das GPS-Modul Navilock NL-652ETTL mit dem BeagleBone verbunden. Die Box sollte nun geschlossen und an der grünen Stelle gestellt werden.

Abbildung 44: Grüne Elektronikbox

7.4.4.Anbringen der Motoren Liste der benötigten Teile 2x Rhino-VX-34 1x Stabilisierungsprofil 2x Schiffsschrauben 1x Schlüssel für die Schiffsschrauben

90

Die Rhino-VX-34 werden am Heck des MOPS 2 an der Markierung von außen fest angeschraubt. Bevor die Motoren nun in der Höhe verstellt werden, müssen die Schiffsschrauben angebracht bzw. kontrolliert werden. Dazu wird die Schiffsschraube mit der Einkerbung nach außen auf die Motoren gesteckt und mit Hilfe des Schlüssels befestigt. Sind die Schiffsschrauben bereits verbaut, sollte dennoch kontrolliert werden, ob diese fest sitzen. Nun werden die Motoren in ihrer Höhe verstellt. Dazu muss die Schraube an der Stange gelöst werden und bis auf die Markierung eingestellt werden. Nachdem beide Motoren in ihrer Höhe verstellt und befestigt sind. Wird die Ausrichtung der Motoren mit Hilfe des roten Druckknopfs auf 90 Grad zum MOPS 2 eingestellt (unterste Rastereinstellung).

Abbildung 45: Befestigung der Motoren am Optimisten

91

Abbildung 46: Befestigung des Stabilisierungsprofils

7.4.5.Verkabelung der Boxen Liste der benötigten Teile 2x M6 Sechskantschraube DIN912, A2 2x Nutenstein N6 mit Federkugel, stahlverzinkt 1x Stromkabel blau - rot Um den MOPS 2 einsatzbereit zu machen, werden nun die Motoren mit den Elektronikboxen und der Batteriebox verbunden. Dazu wurde für jede Steckverbindung eine eindeutige Farbe gewählt, damit keine Störungen auftreten können. Als erstes sollte nun der Not-Aus-Schalter gezogen werden, um die Gefahr eines laufenden Motors abzuwenden. Dazu wird einmal an der Schnur des Schalters gezogen.

92

Komponente 1

Komponente 2

Steckverbindung

Motor gelb

Box 1 Leistungselektronik (rot)

gelb - gelb

Motor grün

Box 1 Leistungselektronik (grün)

grün - grün

Batterie blau

Kabel blau

blau - blau

Kabel rot

Box 1 Leistungselektronik (rot)

rot - rot

Tabelle 32: Steckverbindungen

Der Not-Aus-Schalter wird nun an dem Aluminiumprofil zur Sicherung der Boxen 1, 2 und 3 mit Hilfe von zwei M6 Sechskantschrauben und zwei Nutensteine N6 von oben befestigt. Nachdem alle Boxen verkabelt sind, kann nun der Not-Aus-Schalter wieder betätigt werden, um den MOPS2 scharf zu stellen. Ab nun könnte der MOPS-2 theoretisch Missionen entgegennehmen.

Abbildung 47: Verkabelung Otterboxen

93

Abbildung 48: Verkabelung Backbord bzw. Busleitungen

94

7.4.6.Anbringen der Auftriebskörper Liste der benötigten Teile 4x Befestigungsgurte 2x Auftriebskörper Zum Befestigen der Auftriebskörper werden beide Befestigungsgurte benötigt. Hierzu werden die Gurte durch den unteren Rahmen der Bugkonstruktion direkt zwischen zwei Aluminiumstreben und durch Halterungen an der Innenseite im Rumpf geführt. Anschließend werden die Gurte zusammengesteckt wie in der unteren Abbildung 49 - Befestigung der Schwimmkörper zu sehen.

Abbildung 49: Befestigung der Schwimmkörper

7.4.7.Befestigung des Sensorkäfigs Liste der benötigten Teile 1x Sensorkäfig 2x Seile Zum Befestigen des Sensorkäfigs werden die Seile durch die Öffnungen am Heck des Rumpfs gezogen und mit einem Knoten befestigt. Danach werden diese Seile durch die Öffnungen am oberen Rand der Profile des Sensorkäfigs geführt und mit einem Knoten befestigt. Durch die Anordnung der beiden Seile wird ein Rotieren des Sensorkäfigs und damit ein Abreißen dessen verhindert.

95

7.4.8.Anbringen der Plane Liste der benötigten Teile 1x Plane 1x Seil 1x Spannhaken Zunächst wird die Plane mit dem Loch zur Heckseite ausgelegt und dann mit dem Loch zuerst über die Antenne gestülpt. Danach kann die Plane komplett über den Rumpf gelegt werden. Um die Plane zu fixieren wird das Seil von außen um die Plane gelegt und mit einem Spannhaken zusammengehalten (siehe Abbildungen 50 - Befestigung der Plane).

Abbildung 50: Befestigung der Plane

7.5. Installation BeagleBone Auf dem BeagleBone Black wird Angström Linux in der Version 20130620 mit dem Linux-Kernel 3.8.13 eingesetzt. Das Betriebssystem wird dabei auf der SD-Karte installiert. Das Betriebssystem wird dabei nach den offiziellen Instruktionen installiert. Wichtig ist dabei, dass das BeagleBone so konfiguriert wird, dass automatisch von der SD-Karte gebootet wird. Mittels des Packetmanagers OPKG müssen die folgenden Pakete nachinstalliert werden. ● dhcp-client ● connman-tools ● sqlite ● socat

96

Der Befehl zur Installation lautet opkg install [Packetname]. Als Java Laufzeitumgebung wird das openjdk verwendet. Die Installation erfolgt nach der Anleitung unter „Doing Java Development – BeagleBone“ 9. Sind die offiziellen Paketquellen nicht verfügbar, stehen alternative Paketquellen zur Verfügung10.

7.5.1.Netzwerkkonfiguration Das BeagleBone ist über eine statische Ethernet-Adresse erreichbar, die folgendermaßen konfiguriert ist: ● IP: 192.168.8.2 ● Netzmaske: 255.255.255.0 ● Gateway: 192.168.8.1 ● Nameserver: 8.8.8.8 Die Konfiguration der IP Adresse wird über das Tool connman folgendermaßen vorgenommen: cd /usr/lib/connman/test ./set-ipv4-method ethernet_9059af5d8985_cable manual 192.168.8.2 255.255.255.0 192.168.8.1 /sbin/route add default gw 192.168.8.1 echo "nameserver 8.8.8.8" >> /etc/resolv.conf

7.5.2.Device Tree Konfiguration Zum Zugriff auf die DeviceTrees muss die Gnublin API installiert werden. Zusätzlich müssen der HDMI Ausgang und die seriellen Schnittstellen deaktiviert werden. Eine Anleitung dafür findet sich unter „Device Tree Overlays - Introduction to the BeagleBone Black Device Tree“ 11. Damit der Device Tree beim Systemstart geladen wird, muss die Datei cape-00A0.dtbo in das Verzeichnis /lib/firmware/ kopiert werden.

9 http://BeagleBone.cameon.net/home/doing-java-development 10 http://feeds.angstrom-distribution.org/feeds/v2012.05/ipk/eglibc/armv7a/base/ 11 http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays

97

7.5.3.MOPS Software Installation Die MOPS Software muss in das Verzeichnis /home/root/app installiert werden. Alle benötigten Dateien befinden sich im git-Repository. Die Dateien onboard.jar und start.sh müssen in dieses Verzeichnis kopiert werden. Zusätzlich müssen die Unterverzeichnisse config, db und log angelegt werden. Das Verzeichnis config muss die Dateien communication.properties und mops.properties enthalten. Zusätzlich werden einige Skripte benötigt. Hierzu muss Verzeichnis mops/software/scripts aus dem git muss nach /home/root ausgecheckt werden. In

/etc/systemd/system/

müssen

die

Dateien

inithw.service

und

rtc.service

aus

mops/software/scripts/systemd aus dem git kopiert werden. Die Datei mops.service aus mops/software/scripts/systemd muss nach /lib/systemd/service kopiert werden. Anschließend muss der Dienst mit systemctl enable mops.service aktiviert werden. Die MOPS Software startet nun automatisch nach Start des BeagleBones.

7.6. Raspberry Pi Installation Zur Neuinstallation des Raspberry Pi’s wird zunächst die aktuelle Version von Raspbian, welches auf Debian Wheezy basiert, benötigt. Nachfolgend wird die Installation und Konfiguration der benötigten Komponenten beschrieben. Die Installation des WLAN Access Points wurde bereits im entsprechenden Kapitel beschrieben (vgl. Kapitel 4.3.).

7.6.1.MySQL-Datenbank Die auf dem Raspberry PI installierte MySQL-Datenbank kann mit Hilfe von apt-get installiert werden. Die Struktur der Datenbank, mit weiteren Erläuterungen und Abbildungen befindet sich unter “mops2\software\Sensoren\Database”.

98

7.6.2.Treiber, Kommunikations- / Python-Skripte Auf dem Raspberry PI wurde eine komplexe Software entwickelt, die aus mehreren Komponenten besteht,

vergleiche

“\mops2\software\Sensoren\Code\RaspberryPI”. Um die

Software

zu

verwenden muss Python 2.7, das PySerial Packet und der mysql-connector-python-1.1.6. installiert worden sein. Python und das PySerial Packet können mit Hilfe von apt-get installiert werden, wohingegen der mysql-connector-python-1.1.6. als tar-Archiv heruntergeladen, entpackt und den Anweisungen auf der entsprechenden Homepage folgend, installiert werden muss. Die Software wird durch ausführen des SensorManager gestartet. Dieser startet und initiiert zwei Threads. Zum einen den GPSSocketThread, der kontinuierlich GPS Daten durch einen Socket von dem BeagleBone abfragt, die Daten kommen im NMEA Format an und werden durch die pynmea2 Bibliothek geparst und zum anderen den CommunicationThread. Der CommunicationThread initiiert nicht nur die Hardwaretreiber, er stellt auch eine Verbindung mit der MySQL-Datenbank her und bereitet sich auf eingehende Verbindungen vor. Die multithreadfähige Software kann von mehreren Clients gleichzeitig Befehle empfangen. Dazu wird pro eingehender Verbindung ein ClientCommunicationThread gestartet, dieser Thread nimmt Befehle entgegen, verarbeitet sie, führt sie aus und gibt Rückmeldungen an die Clients. Wobei nur ein ClientCommunicationThread gleichzeitig auf die Hardwaretreiber zugreifen kann. Die komplette Software ist fehlertolerant implementiert worden, sodass Fehler in den einzelnen Threads nicht zum Absturz der gesamten Software führen. Selbst schwerwiegende oder kritische Fehler

lassen

die

Software

nicht

abstürzen.

Tritt

ein

solcher

Fehler

in

einem

ClientCommunicationThread auf, wird nur dieser Thread beendet und die gesamte Software wird nicht beeinträchtigt. Treten Fehler im GPSSocketThread oder CommunicationThread auf, so schließt die Software automatisch alle Verbindungen und fährt sich sauber herunter. Um Fehler und die Software im normalen Betrieb nachvollziehen zu können, sind weitreichende Logfiles und LogAnweisungen integriert worden. Zum Testen der Funktionalitäten und der Interaktion mit anderen Komponenten, auch ohne das Raspberry PI, wurde für die Hardwaretreiber (Comm_py_arduino) und den GPSSocketThread austauschbare Simulationen, sowie ein Testfall geschrieben. Diese befinden sich im selben Verzeichnis wie die genannten Bestandteile.

99

7.6.3.Arduino Installation Wie schon in Kapitel 5.5. beschrieben bildet das Arduino Uno das Bindeglied zwischen dem SDI12 Bus und dem Raspberry PI. D.h. via USB / Serial ankommende Befehle werden auf den Bus geschrieben, sobald diese vollständig bei dem Arduino angekommen sind. Über den Bus ankommende Rückmeldungen werden sofort via USB / Serial an das Raspberry PI gesendet. Dementsprechend klein ist die Software, die diese Kommunikation umsetzt. Für eine Neuinstallation des Arduino Uno wird die Arduino IDE Software verwendet. Nach der Installation dieser Software kann die in C geschriebene Software mit Hilfe der Arduino IDE auf das Arduino

übertragen

werden.

Die

Software

befindet

sich

in

folgendem

Pfad:

“\mops2\software\Sensoren\Code\Arduino\Arduino_USB_Communication”. Bei der Installation ist darauf zu achten, dass die SDI-12 Library in der Arduino IDE eingebunden wurde. Die Library befindet sich unter “\mops2\software\Sensoren\Code\Arduino\SDI-12 Library”.

7.7. Raspberry Pi, Arduino und Bus vorbereiten Der nachfolgende Abschnitt gibt Aufschluss über den Aufbau der zweiten Box, in der das Raspberry Pi und das Arduino Uno untergebracht sind. Das Raspberry Pi ist mit einem USB-Kabel mit dem Arduino Uno und mit einem Ethernetkabel mit dem BeagleBone verbunden. Es bezieht seinen Strom über eine zweiadrige Leitung von dem Arduino Cape (5V, 3A max). Das Arduino Cape ist mit dem Bussystem verbunden und bezieht seinen Strom, genauso wie das Arduino Uno selbst, von dem Bus (60V bei 4A max. [SVB]). Vor der Inbetriebnahme des Bussystems, dies umfasst auch die Spannungsversorgung, muss um Kurzschlüsse und Fehler innerhalb des Bussystems zu vermeiden, geprüft werden, ob eine der in der Tabelle 24 - Kabelspezifikation aufgeführten Leitungen mit der Abschirmungsleitung verbunden sind. Da die Abschirmungsleitung sowohl beim BeagleBone, als auch bei der Stromversorgung mit der GND Leitung verbunden ist, sind vor dem Test alle Stecker an den beschriebenen Stellen zu entfernen. Die eigentliche Prüfung kann dann mit Hilfe eines Durchgangsprüfers erfolgen. Während der Prüfung sollten auch die Sensoren entfernt werden, da diese ihrerseits ebenfalls eine Erdung der Abschirmungsleitung gegen die GND Leitung durchführen können, da die Abschirmung eines Bus, sowohl am Anfang, als auch am Ende der Busleitung geerdet sein sollte. Eine solche Erdung der Abschirmung trägt zur Datensicherheit und Unempfindlichkeit der Datenleitungen bei.

100

7.8. Sonstige Dokumente 7.8.1.Materialliste Werkzeug Bezeichnung

Anzahl

Kosten (€)

Hersteller / Lieferant

Platinenhalter

1

2,95

reichelt.de

Dremel

1

69,95

reichelt.de

Heißklebepistolen inklusive zwei Stangen

1

4,8

reichelt.de

Multimeter

1

41,95

reichelt.de

Lötstation

1

47,95

reichelt.de

Entlötlitze

1

14,45

reichelt.de

Werkzeugkoffer

1

66,95

reichelt.de

Kappsäge

1

135,53

amazon.de

Gewindeschneidsatz

1

27,25

amazon.de

Metalbohrerset

1

10,98

amazon.de

Akku-Schrauber

1

66,65

reichelt.de

Gesamtkosten

489,41

7.8.2.Materialliste Sonstige Kosten Bezeichnung

Anzahl

Lüsterklemmen

Kosten (€)

Hersteller / Lieferant

2,29

Obi

Lautsprecher Kabel in m

2,5

7,90

Obi

Maschinenschrauben M6 x 100

4

4,36

Obi

Kabelbinder

3,89

Obi

Klebestick Cristal

4,29

Obi

1 x Gewindestange

1

3,59

Obi

Aluminiumfolie

1

1,59

Edeka

Superseal Stecker 2-polig

4

9,20

Ebay

Sikaflex 291i 300ml

1

12,10

amazon.de

Platinenhalter

1

2,95

reichelt.de

Testplatinen-Set

1

26,20

reichelt.de

101

Lochrasterplatine

5

4,95

reichelt.de

Widerstand-Set

1

8,10

reichelt.de

Transistoren

1

9,15

reichelt.de

Kondensatoren

1

7,10

reichelt.de

Dioden

1

10,75

reichelt.de

Lötzinn

1

2,60

reichelt.de

Silberdraht (dick)

1

2,10

reichelt.de

Silberdraht (dünn)

1

3,20

reichelt.de

LED (blau)

10

1,60

reichelt.de

LED (rot)

10

3,60

reichelt.de

LED (weiß)

10

1,20

reichelt.de

Draht (blau)

1

0,77

reichelt.de

Draht (schwarz)

1

0,77

reichelt.de

Draht (rot)

1

0,87

reichelt.de

Sockel (14-polig)

3

0,90

reichelt.de

Sockel (16-polig)

3

0,93

reichelt.de

Sockel (18-polig)

3

0,78

reichelt.de

Sockel (20-polig)

3

1,05

reichelt.de

Sockel (22-polig)

3

1,83

reichelt.de

Jumper 1

3

5,50

reichelt.de

Jumper 2

5

7,90

reichelt.de

Gesamtkosten

154,01

7.8.3.Materialliste Recycling Bezeichnung

Anzahl

Kosten (€) Hersteller / Lieferant

Rhino VX 34 Motoren

2

333,00

bootsmotoren4you.de

8m Cordial Speakerkabel 2 x 4,0 mm CLS 1 240

19,20

amazon.de

CircuitCo BeagleBone

1

80,02

watterott.com

Navilock NL-652ETTL GPS Modul

1

32,55

amazon.de

Sparkfun 9 Degrees of Freedom - Razor IMU (SEN-10736)

1

96,00

sparkfun.com

102

Dimension-Engineering Sabertooth dual 60 A motor driver

1

159,00

lipoly.de

Profil 6 30 mm x 30 mm leicht, 9505 mm

1

226,33

item Industrietechnik GmbH

Winkelsatz 6 60 mm x 60 mm

4

23,51

item Industrietechnik GmbH

Winkelsatz 6 30 mm x 30 mm

8

32,11

item Industrietechnik GmbH

Nutenstein 6 M6

40

64,01

item Industrietechnik GmbH

Verwertung der MOPS 2 Gruppe

1065,73

Ausgaben der Gruppe MOPS 1

1892,40

Prozentuale Verwertung der MOPS 2 Gruppe

56%

103

7.8.4.BeagleBone Cape Schaltplan

104

7.8.5.BeagleBone Cape Boardplan

105

7.8.6.Komponentendiagramm

106

7.8.7.Projektplan

107

Anfang

Ende

9

8

7

6

Projekt: MOPS_Projektplan_fina Datum: Don 27.03.14

11

Mon Don 19.12.13 01.07.13 Mon 03.06.13Die 01.04.14

Nur Dauer Manueller Sammelrollup Manueller Sammelvorgang Nur Anfang Nur Ende

Meilenstein

Sammelvorgang

Projektsammelvorgang

Inaktiver Vorgang

Inaktiver Meilenstein

Seite 1

Manueller Vorgang

Unterbrechung

Mrz

Inaktiver Sammelvorgang

1. Quartal Jan

Vorgang

Konzept erstellen Mon Don 01.08.13 03.06.13 Raspberry pi Son 04.08.13 Don 28.11.13 installieren und konfigurieren

Käfig für die Boxenerstellen Sensoren

Konzept erstellen Mon Fre 28.06.13 03.06.13 Sensorkäfig Mon Fre 28.02.14 erstellen 06.01.14 Kabel erstellen Mon 01.07.13Fre 21.03.14

4

5

Mon 01.04.13Die 30.04.13

Ideen Mon Fre 31.05.13 sammeln/Konzepte01.04.13 erstellen Rumpf Mon 03.06.13Die 01.04.14

Seminarphase

Orientierungsphase Mon 01.04.13Fre 31.05.13

Vorgangsmodus Vorgangsname

3

2

1

10

Nr. Mai

3. Quartal Jul Nov

Manueller Fortschritt

In Arbeit

Stichtag

Externer Meilenstein

Externe Vorgänge

Sep

1. Quartal Jan Mrz

Mai

3. Quartal Jul

Sep

Konzept erstellen Mon Mon 01.07.13 03.06.13 Linienmessungen Mon 01.07.13Fre 12.07.13

BereichsmessungenMon 15.07.13Fre 19.07.13

Speergebiete

Verbesserung des Die 07.01.14 Mon 24.03.14 Look And Feels

18

20

21

22

Projekt: MOPS_Projektplan_fina Datum: Don 27.03.14

19

17

16

Nur Dauer Manueller Sammelrollup Manueller Sammelvorgang Nur Anfang Nur Ende

Meilenstein

Sammelvorgang

Projektsammelvorgang

Inaktiver Vorgang

Inaktiver Meilenstein

Seite 2

Manueller Vorgang

Unterbrechung

Mrz

Inaktiver Sammelvorgang

1. Quartal Jan

Vorgang

Mon 22.07.13Fre 28.02.14

Mon 03.06.13Die 01.04.14

Son 01.09.13 Fre 28.03.14

Konzept erstellen Mon Die 30.07.13 03.06.13 Optimierten Mit 31.07.13 Fre 28.02.14 Steuerungsalgorithmus implementieren und testen Bahnplanung Mon 03.06.13Mon 31.03.14

14

13

15

Ende

Son 05.01.14 Don 20.03.14

Anfang

Arduino installieren und konfigurieren Bussystem erstellen Steuerung

Vorgangsmodus Vorgangsname

12

Nr. Mai

3. Quartal Jul Nov

Manueller Fortschritt

In Arbeit

Stichtag

Externer Meilenstein

Externe Vorgänge

Sep

1. Quartal Jan Mrz

Mai

3. Quartal Jul

Sep

Anfang

Ende

Nur Dauer Manueller Sammelrollup Manueller Sammelvorgang Nur Anfang Nur Ende

Meilenstein

Sammelvorgang

Projektsammelvorgang

Inaktiver Vorgang

Inaktiver Meilenstein

Seite 3

Manueller Vorgang

Unterbrechung

Mrz

Inaktiver Sammelvorgang

1. Quartal Jan

Vorgang

Mon 31.03.14

Mon 01.07.13

Mon Fre 31.01.14 19.08.13 Mon Fre 31.01.14 19.08.13 Mon 03.06.13Mon 31.03.14

ZwischenberichtMon erstellen 03.06.13 AbschlussberichtMon erstellen 06.01.14

Erstellen eines neuen Capes Installation und Konfiguration Dokumentation

Verbesserung der Mon Mon 31.03.14 Usability 06.01.14 BeagleBone Mon 19.08.13Mon 31.03.14

Vorgangsmodus Vorgangsname

Projekt: MOPS_Projektplan_fina Datum: Don 27.03.14

29

28

27

26

25

24

23

Nr. Mai

3. Quartal Jul Nov

Manueller Fortschritt

In Arbeit

Stichtag

Externer Meilenstein

Externe Vorgänge

Sep

1. Quartal Jan Mrz

Mai

3. Quartal Jul

Sep

8. Literaturverzeichnis [AB]

Abschlussbericht PG MOPS - http://www-is.informatik.unioldenburg.de/~dibo/pg_fb10/endberichte/2013/PG-MOPS.pdf (zuletzt aufgerufen am: 28.03.2014) [BB] Beagleboard:BeagleBoneBlack – eLinux.org http://elinux.org/Beagleboard:BeagleBoneBlack#BeagleBone_Black_Features (zuletzt aufgerufen am: 24.03.2014) [DTA] DVB-T Antennen – VDR Wiki - http://www.vdr-wiki.de/wiki/index.php/DVBT_Antennen (zuletzt aufgerufen am: 21.02.2014) [EO] Prototyping in der Software Entwicklung - http://www.ergo-online.de/site.aspx? url=html/software/software_entwicklung_prototyp/protot_konzept.htm (zuletzt aufgerufen am: 23.03.2014) [GC] grumlimited/geocalc – Github - https://github.com/grumlimited/geocalc (zuletzt aufgerufen am: 27.03.2014) [ME] ME-Meßsysteme GmbH: CAN Bus Grundlagen, o. Jahr – http://www.mesysteme.de/canbus.html (zuletzt aufgerufen am: 29.03.2014) [NXP12] NXP B.V.: I2C-bus specification and user manual, 2012 – http://www.nxp.com/documents/user_manual/UM10204.pdf (zuletzt aufgerufen am: 29.03.2014) [SDI12] SDI-12 Support Group: SDI-12 A Serial-Digital Interface Standard for MicroprocessorBased Sensors, 2013 - http://www.sdi-12.org/current%20specification/SDI12_version1_3%20Januar%2026,%202013.pdf (zuletzt aufgerufen am: 29.03.2014) [SVB] http://www.svb.de/media/117365/pdf/datasheet_en_2013-04-18.pdf (zuletzt aufgerufen am: 30.03.2014) [WuT] ME-Meßsysteme GmbH: RS485-Bussysteme, o. Jahr – http://www.wut.de/e-6wwww11-apde-000-php (zuletzt aufgerufen am: 29.03.2014)

111

Abschließende Erklärung Wir versichern hiermit, dass wir unsere Abschlussdokumentation selbständig und ohne fremde Hilfe angefertigt haben, und dass wir alle von anderen Autoren wörtlich übernommenen Stellen wie auch die sich an die Gedankengänge anderer Autoren eng anliegenden Ausführungen unserer Arbeit besonders gekennzeichnet und die Quellen zitiert haben. Oldenburg, den 31.03.2014

________________________________________ ______________________________________ Hauke Evers

Nils Giza

________________________________________ ______________________________________ Uwe Wilko Grünefeld

Dennis Koers

________________________________________ ______________________________________ Markus Alexander Lehmann

Philipp Mählmeyer

________________________________________ ______________________________________ David Reiher

Philipp Rudolph

________________________________________ ______________________________________ Liliane Anick Tchoua Tsafack

Bastian Veltin

________________________________________ ______________________________________ Daniel Weinberg Sven Wiegand

112