spellcheck.

.kile/mechforsch.kilepr.gui

@@ -2,7 +2,7 @@
 kile_livePreviewEnabled=true
 kile_livePreviewStatusUserSpecified=true
 kile_livePreviewTool=LivePreview-PDFLaTeX
-lastDocument=main.tex
+lastDocument=tex/3_Auswahl.tex
 
 [document-settings,item:Einleitung.tex]
 Bookmarks=
@@ -139,67 +139,67 @@ TextFolding={"checksum":"","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.bib]
-CursorColumn=18
+CursorColumn=51
 CursorLine=326
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"4baf2bb15fceb5c9f2aabf1cf70c4c7dba5ec9f5","ranges":[]}
+TextFolding={"checksum":"8795c48226fb036f16e6bbcfbf55b812c6d43eaa","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
 CursorColumn=0
-CursorLine=96
+CursorLine=105
 Dynamic Word Wrap=false
 JumpList=
 TextFolding={"checksum":"80ccd936ce5ae7dc5995816ffe293139ed94b427","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/1_Einleitung.tex]
-CursorColumn=68
+CursorColumn=196
-CursorLine=43
+CursorLine=35
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"75bcf6c0e7387bff6aee008e1995bfd43ba5a46b","ranges":[]}
+TextFolding={"checksum":"99e42b912b320890bab1219df1e7d056e5124a2d","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/2_Konzept.tex]
-CursorColumn=39
+CursorColumn=26
-CursorLine=116
+CursorLine=25
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"03b463289e4adf34859cce5e79432be3ca9c3f53","ranges":[]}
+TextFolding={"checksum":"111913c063e94bf8f1bf4f786b47b20be2773064","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/3_Auswahl.tex]
-CursorColumn=0
+CursorColumn=17
-CursorLine=446
+CursorLine=361
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"0163bec2d59ee0fdc7502865f6859d4fffa2ee1b","ranges":[]}
+TextFolding={"checksum":"7aa9002df025f03505dbfc278b329c1fb13f4e2a","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/4_Umsetzung.tex]
-CursorColumn=14
+CursorColumn=102
-CursorLine=915
+CursorLine=1001
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"f6689d8b4009907e1b500952fcd8c46a3c8d88d0","ranges":[]}
+TextFolding={"checksum":"dbda4a467836d9dfaee2833e58221fe122996b5e","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/5_Evaluation_und_Diskussion.tex]
-CursorColumn=82
+CursorColumn=18
-CursorLine=135
+CursorLine=168
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"f0868d9f15eec0ec90ab265f5c740a42a7b52d9b","ranges":[]}
+TextFolding={"checksum":"847cd8cf59a779530aa24d2840e2423d2f10200b","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/6_Ausblick.tex]
-CursorColumn=28
+CursorColumn=59
-CursorLine=66
+CursorLine=71
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"08c80e4a421859760de9f6abca5d28d188b891d5","ranges":[]}
+TextFolding={"checksum":"e964476a9eab203b42b321940c7b6784639e0caf","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/Einleitung.tex]

dict.txt

@@ -0,0 +1,61 @@
+ActorPlugin
+ROS
+MessageQueue
+ActorServer
+Koexistenzszenario
+Kooperationsszenario
+Kollaborationsszenario
+State
+Actor
+Actors
+Behavior
+Tree
+Gazebo
+MoveIt
+REST-API
+ActorPlugins
+ROS-Topic
+ROS-Topics
+rclcpp
+Feedbackmechanismus
+rclcpp
+ros
+control
+Kompiliervorgang
+Feedbacknachrichten
+Movement
+Idle
+actor
+action
+server
+Movement
+Interface
+Node
+Success
+SUCCESS
+Failure
+Nodes
+Pose
+ActorAnimation
+ActorMovement
+animation_name
+animation_speed
+animation_distance
+target
+FAILURE
+velocity
+WeightedRandom
+WeightedRandom-Node
+ReactiveSequence
+Sequence
+Verfahrgeschwindigkeit
+Octomap
+Octomaps
+ign
+Trees
+Kuka
+kuka
+iisy
+IDLE
+MOVEMENT
+state}

tex/1_Einleitung.tex

@@ -13,7 +13,7 @@ Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf
 Dies erlaubt lediglich die Reproduktion des geplanten Bewegungsablaufes, aber nicht dessen Variation im Prozess, ausgelöst durch Ereignisse in der Simulation.
 Um eine solche Funktionalität bereitzustellen, müssen die Bewegungsabläufe sowohl von Roboter als auch Mensch zur Laufzeit der Simulation gesteuert werden können.
 
-Diese Steuerung soll durch eine eingängliche Beschreibungssprache erfolgen, die einfach erweitert und auf neue Szenarien angepasst werden kann.
+Diese Steuerung soll durch eine eingängige Beschreibungssprache erfolgen, die einfach erweitert und auf neue Szenarien angepasst werden kann.
 Um die Funktionalität zu demonstrieren, sind 3 unterschiedliche Testszenarien in der Simulationsumgebung abzubilden.
 Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwischen Mensch und Roboter simulieren.
 
@@ -21,25 +21,25 @@ Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwis
 Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen Teilaspekten der Simulation eines Mensch-Roboter-Kollaborationsszenarios.
 
 Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere
-Projekte dar.\cite{DOMBROWSKI2018134}
+Projekte dar \cite{DOMBROWSKI2018134}.
 Hierbei wird die erwünschte Interaktion betrachtet und aus den gewonnenen Daten werden Einschränkungen generiert.
 Diese Einschränkungen können in der Interaktion verwendet werden, um zum Beispiel Verletzungen des Menschen durch den Roboter auszuschließen.
 
-Ein anderer Weg der Kollisionsvermeidung ist die Planung der maximal zurücklegbaren Distanz eines Menschen aus seiner aktuellen Position.\cite{ffdrobotsim}
+Ein anderer Weg der Kollisionsvermeidung ist die Planung der maximal zurücklegbaren Distanz eines Menschen aus seiner aktuellen Position \cite{ffdrobotsim}.
 Dafür werden die maximalen Beschleunigungen einzelner Körperteile ermittelt, um diese während der Interaktion zu überwachen.
 Sollte ein Mensch den Roboter erreichen können, muss dieser in der dafür benötigten Zeit stoppen können.
 Dies sorgt für eine Geschwindigkeitsanpassung im Nahfeld, da hier schnellere Bewegungen möglich sind.
 
-Es existieren auch zahlreiche Ansätze, die Bewegungs- und Interaktionsplanung eines Roboters mit Beschreibungssprachen abzudecken.\cite{btintro}
+Es existieren auch zahlreiche Ansätze, die Bewegungs- und Interaktionsplanung eines Roboters mit Beschreibungssprachen abzudecken \cite{btintro}.
 Dabei kommt es auf die Umsetzung in der Beschreibungssprache, aber auch auf Anforderungen an das System an, um zum Beispiel das Abbrechen von Aktionen zu ermöglichen.
 
-In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetzt, um verschiedene Systeme, wie zum Beispiel die Steuerung von Nichtspielercharakteren, zu beschreiben.\cite{halo2}
+In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetzt, um verschiedene Systeme, wie zum Beispiel die Steuerung von Nichtspielercharakteren, zu beschreiben \cite{halo2}.
 
 Eine vollständige Umsetzung einer erweiterbaren Simulation mit Mensch und Roboter, gesteuert durch eine Beschreibungssprache, konnte bei der Recherche zu dieser Arbeit jedoch nicht gefunden werden.
 
 \section{Auswahl der Szenarien}
 Die drei zu modellierenden Szenarien sollten so gewählt werden, dass spätere komplexere Szenarien auf einfacheren Vorgängern aufsetzen und deren Funktionen weiter nutzen und ergänzen.
-Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders in Frage.
+Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders infrage.
 Diese besitzen viele ähnliche Bestandteile, die in mehreren Umständen nutzbar sind.
 Das erlaubt den Einsatz von wenigen Animationen in vielen Szenarien.
 Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das Begutachten eines Objekts, welche jeweils nur eine ähnliche Bewegungsabfolge des beteiligten Menschen sind.

tex/2_Konzept.tex

@@ -23,7 +23,7 @@ Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
 Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
 Außerdem ist die enge Interaktion mit Menschen gewünscht, was für einen auf Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
 Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, der als Cobot vermarktet wird.
-Die Bezeichnung als Cobot\cite{cobot} ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
+Die Bezeichnung als Cobot \cite{cobot} ist dabei ein Kofferwort aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
 Der Roboter besitzt einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
 
 Um den Kuka iisy in der Simulation verwenden zu können, muss ein Modell des Roboterarms erstellt werden.
@@ -49,7 +49,7 @@ Außerdem kann durch andere Komponenten in der Simulation der Abbruch einer Akti
 Die Weitergabe eines Abbruchbefehls soll demzufolge auch über die geplante Komponente realisiert werden können.
 
 \section{Behavior Trees als Beschreibungssprache}
-Bislang wird das Verhalten von Akteuren in Simationsumgebungen, darunter Roboter und Menschen, häufig in Form von State-Machines ausgedrückt.
+Bislang wird das Verhalten von Akteuren in Simulationsumgebungen, darunter Roboter und Menschen, häufig in Form von State-Machines ausgedrückt.
 Diese besitzen jedoch einen großen Nachteil, der vor allem bei komplexeren Abläufen hervortreten kann.
 Dabei handelt es sich um die Übersichtlichkeit, die bei einer wachsenden State-Machine leicht verloren geht.
 Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, was zu Fehlern im späteren Betrieb führen kann.
@@ -93,10 +93,10 @@ Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unters
 Das in Abbildung \ref{concept_tree_demo} visualisierte Beispiel zeigt die Abfolge, um eine Tür zu öffnen und zu durchschreiten.
 Die Ausführung des Baumes beginnt an der Root-Node, wobei die Zahlen über den Nodes die Reihenfolge der Rückgabewerte angeben.
 
-Von dort aus wird als erstes die Sequenz-Node ausgeführt, die drei untergeordnete Nodes besitzt.
+Von dort aus wird als Erstes die Sequenz-Node ausgeführt, die drei untergeordnete Nodes besitzt.
 Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, ausgeführt.
 
-Daraus resultierend wird als erstes die linke Fallback-Node, die ihrerseits untergeordnete Nodes besitzt, ausgeführt.
+Daraus resultierend wird zuerst die linke Fallback-Node, die ihrerseits untergeordnete Nodes besitzt, ausgeführt.
 Da der Rückgabewert der Fallback-Node von den unter ihr befindlichen Nodes bestimmt wird, werden diese nacheinander ausgeführt.
 
 Von diesem Punkt an beginnen die Rückgaben, die das weitere Verhalten beeinflussen.
@@ -113,7 +113,7 @@ Folgender Kontrollfluss findet in diesem Beispiel statt:
   Der Versuch gelingt und der Erfolg wird an die Fallback-Node übergeben.
  }
  \item{
-  Da die untergeornete Node eine erfolgreiche Ausführung meldet, wird die Ausführung der Fallback-Node mit einem erfolgreichen Rückgabewert beendet.
+  Da die untergeordnete Node eine erfolgreiche Ausführung meldet, wird die Ausführung der Fallback-Node mit einem erfolgreichen Rückgabewert beendet.
   Aus diesem Grund wird die Node ``Tür eintreten'' nicht mehr ausgeführt.
  }
  \item{
@@ -125,7 +125,7 @@ Folgender Kontrollfluss findet in diesem Beispiel statt:
  }
 \end{enumerate}
 
-Dieser Ablauf würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.
+Dieser Ablauf würde nun von neuem beginnen, da die Root-Node ihre untergeordnete Node ohne Berücksichtigung des Rückgabewertes neu startet.
 
 Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich neue Verhalten implementieren.
 Dies erlaubt die schnelle Anpassung des Verhaltens der gesteuerten Systeme.

tex/3_Auswahl.tex

@@ -5,7 +5,7 @@ Alle Komponenten sollen später in der entwickelten Softwareumgebung ihre jeweil
 Alle diese Teilbereiche können dann zu einer Simulation verbunden werden, die das gesamte Problemfeld abdeckt.
 
 Wie bereits in Abbildung \ref{concept_overview} dargestellt, ist für die Erfüllung der Aufgaben eine Dienst- und eine Simulationsumgebung erforderlich.
-Dieses Kapitel beschreibt die Auswahl der Umgebungen und der in diesen laufenden Prozesse.
+Dieses Kapitel beschreibt die Auswahl der Umgebungen und alle in den Umgebungen laufenden Prozesse.
 \section{Dienstumgebung}
 Die Dienstumgebung bestimmt maßgeblich, wie Software im Entwicklungsprozess geschrieben wird.
 Durch sie werden häufig benötigte Funktionen bereitgestellt, die Programme innerhalb der Umgebung nutzen können.
@@ -15,8 +15,8 @@ Diese wird genutzt, um eine gemeinsame Basis für ein erweiterbares System zu sc
 Außerdem sind Werkzeuge zur Parameterübergabe an Teilsysteme sinnvoll, um die Einstellungen an einer Stelle gesammelt anpassen zu können.
 
 \subsection{Auswahl}
-Es existieren mehrere Systeme, die als Dienstumgebung für Roboter in Frage kommen, wenn man lediglich die Nachrichtenübergabe zwischen Programmen betrachtet.
+Es existieren mehrere Systeme, die als Dienstumgebung für Roboter infrage kommen, wenn man lediglich die Nachrichtenübergabe zwischen Programmen betrachtet.
-Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist potentiell als ein Roboterframework einsetzbar.
+Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist potenziell als ein Roboterframework einsetzbar.
 
 Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition der Nachrichten, die über das System ausgetauscht werden.
 
@@ -30,7 +30,7 @@ Dabei dient ein Programm als Server, der Anfragen von anderen Programmen, auch C
 Die Kommunikation zwischen Client und Server ist bidirektional möglich, was kompliziertere Protokolle ermöglicht.
 
 Alle diese Lösungen besitzen einen gemeinsamen Nachteil in deren Nachrichtendefinition.
-Dieser Nachteil besteht in der potentiellen Variabilität dieser Kommunikationsmechanismen.
+Dieser Nachteil besteht in der potenziellen Variabilität dieser Kommunikationsmechanismen.
 Bei einem ausreichend großen Projekt treten so unweigerlich Unterschiede in der Handhabung von Nachrichten auf, die es zu berücksichtigen gilt.
 Durch solche Unterschiede kann es zu Inkompatibilitäten zwischen Programmen kommen, was sich auf die universelle Nutzbarkeit der Programme negativ auswirkt.
 
@@ -44,7 +44,7 @@ Ein neues Nachrichtenformat mit Quality of Service kann beispielsweise Nachricht
 Außerdem werden neben CMake \cite{cmake} auch andere Buildsysteme unterstützt, was die Verwendung von Python erlaubt.
 
 Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
-Vor allem die Vielzahl von ROS-Bibliotheken, die von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
+Vor allem die Vielzahl von ROS-Bibliotheken, die von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär \cite{rospackages}.
 
 ROS kann sowohl für simulierte Umgebungen als auch für echte Roboter eingesetzt werden.
 Diese beiden Anwendungsfälle werden durch unterschiedliche Controller realisiert.
@@ -78,7 +78,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
  \item[Buildumgebung]\hfill \\
   ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
   Zu deren Konfiguration wird eine \code{CMakeLists.txt}-Datei erstellt, die den Buildprozess beschreibt.
-  In dieser sind die Buildinstruktionen für den Kompiler enhalten, mit welchen die im Paket befindlichen Programme kompiliert werden.
+  In dieser sind die Buildinstruktionen für den Compiler enthalten, mit welchen die im Paket befindlichen Programme kompiliert werden.
   Der Aufruf des \code{ament_cmake}-Makros in dieser ergänzt den Kompiliervorgang um weitere Parameter aus der \code{package.xml}-Datei.
 
   Nach diesen Vorbereitungsschritten kann CMake das Paket kompilieren.
@@ -88,7 +88,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
   Diese sind dann später im erstellten Workspace für die Nutzung durch andere Programme verfügbar.
 
  \item[Workspaceverwaltung]\hfill \\
-  Gruppen von Paketen werden zur einfacheren Handhabung in sogenannen “Workspaces” zusammengefasst.
+  Gruppen von Paketen werden zur einfacheren Handhabung in sogenannten ``Workspaces'' zusammengefasst.
   Diese vereinfachen das Auffinden der enthaltenen Pakete durch Skripte, die diese im System registrieren.
   Die Erstellung der Skripte erfolgt anhand der bereits beschriebenen \code{CMakeLists.txt}-Datei.
   Das Programm \code{colcon} analysiert diese und generiert die Skripte.
@@ -190,8 +190,8 @@ Andernfalls können in der Datei eine oder mehrere Welten definiert werden.
 
 Eine Welt definiert in Gazebo den kompletten Aufbau des Simulators.
 Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten der Simulationsumgebung.
-Außerdem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
+Zudem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
-Letzendlich ist die Definition mehrerer Modelle, Aktoren und Lichter in der Welt möglich.
+Letztendlich ist die Definition mehrerer Modelle, Aktoren und Lichter in der Welt möglich.
 Diese können auch aus anderen URIs stammen, die in der Welt deklariert wurden.
 Dies erlaubt zum Beispiel das Laden von vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek \cite{gazebo-app}.
 
@@ -203,7 +203,7 @@ Jedes Modell wird über eine Translation und Rotation im Simulationsraum veranke
 Dies geschieht immer relativ zum Referenzsystem des überliegenden Modells.
 Außerdem können im Modell Einstellungen für dessen Physiksimulation vorgenommen werden.
 
-Ein Modell enhält meist mindestens ein Link-Element, dass zur Darstellung von dessen Geometrie verwendet wird.
+Ein Modell enthält meist mindestens ein Link-Element, dass zur Darstellung von dessen Geometrie verwendet wird.
 Mehrere Link-Elemente können dabei mit der Welt oder anderen Link-Elementen über Joint-Elemente verbunden werden.
 Diese Joint-Elemente können jedoch nicht von außerhalb gesteuert werden, was das Dateiformat ungeeignet für Roboterdefinitionen macht.
 
@@ -211,7 +211,7 @@ Lichter besitzen einen Lichttyp, der die Ausbreitung des Lichtes im Raum bestimm
 Die erste Art ist direktionales Licht, dass parallel zur gewünschten Achse auftrifft.
 Solche Lichter werden vor allem zur grundlegenden Raumausleuchtung genutzt.
 Weiterhin sind Punktlichtquellen verfügbar, deren Licht von einer Position im Raum ausgeht.
-Neben den Punklichtquellen existieren auch noch Spots, die außerdem nur einen gewissen Winkel ausleuchten.
+Neben den Punklichtquellen existieren auch noch Spots, die nur einen gewissen Winkel ausleuchten.
 
 Die Actor-Komponente wird für animierte Modelle in der Simulation eingesetzt.
 Sie besteht aus einem Namen für das Modell, einer Skin, welche das Aussehen des Modells definiert und mehreren Animationen.
@@ -249,7 +249,7 @@ Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
  \item[drehbare Gelenke]
   verhalten sich wie kontinuierliche Gelenke, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
  \item[prismatische Gelenke]
-  ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Sie werden zur Umsetzung von Linearaktuatore in der Simulation verwendet.
+  ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Sie werden zur Umsetzung von Linearaktuatoren in der Simulation verwendet.
 \end{description}
 \subsection{Menschensimulation}
 Gazebo besitzt bereits ein simples Animationssystem für bewegliche Aktoren, dass auch für Menschen nutzbar ist.
@@ -273,7 +273,7 @@ Deshalb existiert eine umfangreiche Dokumentation für die zahlreichen Komponent
 Außerdem sind zahlreiche direkte Integrationen mit anderen ROS-Paketen verfügbar, was die Nutzung dieser zusammen mit MoveIt erlaubt.
 Aufgrund dieser Eigenschaften ist MoveIt eine vorteilhafte Bewegungsplanungsumgebung für dieses Projekt.
 
-MoveIt besteht aus mehreren Komponmenten, die in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
+MoveIt besteht aus mehreren Komponenten, die in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
 Der Nutzer kann mit MoveIt auf verschiedenen Wegen Steuerbefehle für den Roboter absenden, die durch die Software umgesetzt werden.
 
 Die erste Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files möglich.
@@ -282,7 +282,7 @@ Durch die Ausführung dieser Demo startet RViz, eine Test- und Visualisierungsum
 In der Demo können Roboterbewegungen unter Zuhilfenahme von Markierungen in RViz geplant und ausgeführt werden.
 
 Da sich eine Bewegungsplanung in einer Nutzeroberfläche nur beschränkt zur Automatisierung durch Software eignet, müssen die der Demo zugrundeliegenden Schnittstellen genutzt werden.
-Für die Sprache Python existierte für die Vorgängerversion von MoveIt das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, aber für MoveIt2 noch nicht portiert wurde\cite{moveitpython}.
+Für die Sprache Python existierte für die Vorgängerversion von MoveIt das moveit_commander Paket, welches den Zugriff auf MoveIt in Python erlaubt, aber für MoveIt2 noch nicht portiert wurde \cite{moveitpython}.
 
 Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt2 direkt zu interagieren.
 Dabei können sowohl die Planung und die Ausführung von Bewegungen ausgelöst aber auch Exklusionszonen eingerichtet werden.
@@ -301,7 +301,7 @@ Eine solche Erweiterung erlaubt die automatische Nutzung von Kollisionsvermeidun
 Die Planung der Bewegung wird durch einen der in MoveIt implementierten Solver realisiert, der durch die MoveGroup aufgerufen wird.
 Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an die \code{ros_control} Controller des Roboters weitergegeben.
 
-Diese Abstaktion erlaubt die Nutzung von sowohl simulierten, aber auch echten Robotern.
+Diese Abstraktion erlaubt die Nutzung von sowohl simulierten, aber auch echten Robotern.
 Dazu werden für echte und simulierte Roboter unterschiedliche ros_control Controller verwendet.
 Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
 
@@ -448,7 +448,7 @@ Bei einer virtuellen Maschine (VM) werden alle Komponenten der Maschine simulier
 Dies beinhaltet auch die Abstraktion von Speichermedien und anderen Geräten.
 Eine virtualisierte Umgebung erzeugt kleine Performanceverluste durch die Abstraktion.
 
-Eine Containerumgebung nutzt den Kernel des Hostsystems mit, was die Virtualisierug auf die Ebenen über dem Betriebssystem beschränkt.
+Eine Containerumgebung nutzt den Kernel des Hostsystems mit, was die Virtualisierung auf die Ebenen über dem Betriebssystem beschränkt.
 Die auszuführende Umgebung muss also mit dem Systemkernel lauffähig sein, um in einem Container ausgeführt werden zu können.
 Die Performanceverluste dieser Umgebung sind kleiner als die einer virtuellen Maschine, da grundlegende Teile des Systems nicht mehrfach ausgeführt werden müssen.
 
@@ -457,7 +457,7 @@ Außerdem soll in der Virtualisierungsumgebung Grafikbeschleunigung genutzt werd
 In einer Containerumgebung kann die Grafikeinheit des Hostsystems mit genutzt werden, indem das durch das Hostsystem bereits abstrahierte Gerät in den Container hereingereicht werden.
 
 Diese Punkte sprechen für die Nutzung einer Containerumgebung.
-Docker ist eine etablierte Umgebung für die Ausführung von Containern, die auf Grund der extensiven Dokumentation und Verfügbarkeit auf allen gängigen Linux-Systemen ausgewählt wurde.
+Docker ist eine etablierte Umgebung für die Ausführung von Containern, die aufgrund der extensiven Dokumentation und Verfügbarkeit auf allen gängigen Linux-Systemen ausgewählt wurde.
 
 Ein Container wird in Docker über sogenannte Build-Files definiert.
 Das Build-File enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.
@@ -475,6 +475,6 @@ Docker-Compose stellt eine Erweiterung von Docker dar.
 Diese Erweiterung verwaltet die Inbetriebnahme der Container über ein spezielles Dateiformat.
 Eine solche Funktion erlaubt das wiederholte Einrichten von Containern mit gleichen Parametern.
 In dieser Datei werden weitere Optionen angegeben, die in die Umgebung des laufenden Containers eingreifen.
-Dazu gehört zum Beispiel das automatisierte Übergeben von Umgebungsvariablen, Einrichten von Netzwekumgebungen und Erstellen von Volumes und ``bind mounts''.
+Dazu gehört zum Beispiel das automatisierte Übergeben von Umgebungsvariablen, Einrichten von Netzwerkumgebungen und Erstellen von Volumes und ``bind mounts''.
 
 Diese Automatisierung erleichtert die initiale Einrichtung eines Containers auf einem neuen System, da alle benötigten Aspekte leicht angepasst werden können.

tex/4_Umsetzung.tex

@@ -63,7 +63,7 @@ popd || exit
 \end{figure}
 
 Dieses Skript nutzt \code{colcon}, um alle Pakete in \code{~/workspace}-Verzeichnis zu erstellen.
-Dabei wird auch eine \code{compile_commands.json}-Datei im build-Unterordner erstellt, die von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden.
+Dabei wird auch eine \code{compile_commands.json}-Datei im \code{build}-Unterordner erstellt, die von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden.
 Um eine Nutzung in allen Entwicklungsumgebungen zu erlauben, wurde diese zusätzlich in das Hauptverzeichnis des Workspaces gelinkt.
 Dies ist notwendig, da einige Entwicklungsumgebungen nur dort nach dieser Datei suchen.
 
@@ -72,7 +72,7 @@ Um trotzdem alle wichtigen Informationen zu erhalten, kommt der Event-Handler \c
 Durch diesen werden die Ausgaben gruppiert, und erst nach einen vollständigen Kompiliervorgang eines Pakets nacheinander ausgegeben.
 Dies ermöglicht es, aufgetretene Fehler einfacher auf ein bestimmtes Paket zurückführen zu können, ohne das gesamte Log zu durchsuchen.
 Hierbei ist es hilfreich, dass die verbleibenden Kompiliervorgänge abgebrochen werden, falls der Kompiliervorgang eines Pakets fehlschlägt.
-Dadurch befindet sich der Fehlers immer im letzten Paket der Ausgabe, da alle anderen Prozesse abgebrochen und nicht ausgegeben werden.
+Dadurch befindet sich der Fehler immer im letzten Paket der Ausgabe, da alle anderen Prozesse abgebrochen und nicht ausgegeben werden.
 
 \section{Entwicklungsumgebung}
 
@@ -86,12 +86,12 @@ Die Entwicklungsumgebung kann eine interne Repräsentation des geschriebenen Cod
 Diese Repräsentation kann genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen.
 Um dies zu erreichen, muss für jede unterstützte Sprache Code geschrieben werden, der in die Entwicklungsumgebung integriert wird.
 
-Als Alternative existiert das Language Server Protocol, kurz LSP\cite{lsp}, dass eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Infomationen über den Code an die Entwicklungsumgebung zu übergeben.
+Als Alternative existiert das ``Language Server Protocol'', kurz LSP \cite{lsp}, dass eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Informationen über den Code an die Entwicklungsumgebung zu übergeben.
 Dies erlaubt einer Entwicklungsumgebung, nur noch den benötigten Server der Sprache zu starten, um Informationen über den Code in einem standardisierten Protokoll zu erhalten.
 
 Der große Vorteil des LSP ist, dass eine Entwicklungsumgebung alle Funktionen der Programmiersprache vollständig unterstützt, solange das Protokoll vollständig implementiert wurde und ein entsprechender Server für die Sprache existiert.
 
-Bestimmte Funktionen, die beim Design des LSP nicht bedacht wurden, können einfacher in einer interner Implementation umgesetzt werden.
+Bestimmte Funktionen, die beim Design des LSP nicht bedacht wurden, können einfacher in einer internen Implementation umgesetzt werden.
 Deswegen besitzen Entwicklungsumgebungen mit interner Coderepräsentation häufig mehr Funktionen, spezialisieren sich jedoch auf bestimmte Sprachen.
 
 In diesem Projekt wurden mehrere Entwicklungsumgebungen mit den jeweils unterschiedlichen Verfahren eingesetzt.
@@ -103,8 +103,8 @@ Dazu wird beim Start einer Verbindung zu einem entfernten System dieser Server a
 Die anfängliche Entwicklung wurde mit PyCharm und CLion durchgeführt, da diese durch ihre interne Codeanalyse die ROS-Umgebung ohne Konfiguration nutzen konnten.
 Jedoch sind diese Umgebungen sehr ressourcenintensiv, was die gleichzeitige Ausführung erheblich verlangsamt.
 
-Daher wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce, verwendet.
+Daher wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce (siehe Abbildung \ref{lapce}), verwendet.
-Der dafür notwenige LSP-Server wird durch eine Veränderung des Buildscripts automatisch im Container installiert.
+Der dafür notwendige LSP-Server wird durch eine Veränderung des Buildscripts automatisch im Container installiert.
 Unter Verwendung dieser neuen Server kann Lapce die Codevervollständigung und Codeanalyse wie PyCharm und CLion durchführen.
 Gleichzeitig wird der Ressourcenverbrauch gesenkt, da nur ein einziger Editor benötigt wird.
 
@@ -116,14 +116,14 @@ Gleichzeitig wird der Ressourcenverbrauch gesenkt, da nur ein einziger Editor be
 \end{figure}
 \newpage
 \section{Verwendete Datentypen}\label{datatypes}
-In diesem Projekt werden viele unterschiedliche Datentypen sowohl für den Datenaustauch zwischen Nodes, als auch in der internen Implementation der Nodes verwendet.
+In diesem Projekt werden viele unterschiedliche Datentypen sowohl für den Datenaustausch zwischen Nodes, als auch in der internen Implementation der Nodes verwendet.
 Diese Datentypen sind größtenteils aus der Programmiersprache C++ bekannt, jedoch werden auch weitere Typen aus eigenem Code oder eingebundenen Bibliotheken verwendet.
 Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Implementation verwendeten Datentypen hier zusammengefasst und beschrieben.
 \begin{description}
   \item[Pose]
   ist einer der häufigsten Datentypen im Umgang mit Gazebo.
   Der Pose-Datentyp enthält die Information über die Lage und Rotation eines Objekts im Raum.
-  Die Daten werden als relative Werte im Bezug auf das übergeornete Objekt gespeichert.
+  Die Daten werden als relative Werte in Bezug auf das übergeordnete Objekt gespeichert.
   Objekte wie der Mensch liegen in der Hierarchie der Simulation direkt unter der Welt, deren Pose sich direkt im Nullpunkt und ohne Rotation befindet.
   Durch diesen Umstand sind die Koordinaten des Menschen absolut, da sie nicht durch die Welt verschoben und rotiert werden.
   \item[Area]
@@ -156,7 +156,7 @@ Zuerst wird ein Stellplatz für den Roboter benötigt.
 Dieser sollte an einer Ecke des Raumes positioniert werden, was zu höheren Verfahrgeschwindigkeiten führt.
 Das ist durch die dynamische Verfahrgeschwindigkeit bedingt, die bei geringerer Distanz zum Menschen abnimmt.
 
-Des weiteren werden eine Arbeits- und Lagerstätte für den Menschen benötigt, die in den Szenarien genutzt werden sollen.
+Des Weiteren werden eine Arbeits- und Lagerstätte für den Menschen benötigt, die in den Szenarien genutzt werden sollen.
 Im Koexistenzszenario soll der Mensch nur an diesen Stellen seine Arbeit verrichten, sich jedoch seltener dem Roboter nähern, um dessen Fortschritt zu begutachten.
 Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch für die fehlerhaften Teile verwendet werden.
 Diese Teile werden durch den Roboter aussortiert und durch den Menschen in das Lager verbracht.
@@ -215,9 +215,9 @@ An diesem Punkt könnte die Animation des Modells mit dem importierten Skelett b
 Diese fehlenden Knochen werden für einige der gewünschten Animationen benötigt und müssten hinzugefügt werden.
 Da das importierte Skelett noch andere Fehler aufwies, wurde es verworfen.
 
-Um ein neues, passendes Skelett zu erstellen, wurde mit dem ``Rigify''\cite{rigify}-Plugin ein standartisiertes Menschenskelett generiert.
+Um ein neues, passendes Skelett zu erstellen, wurde mit dem ``Rigify'' \cite{rigify}-Plugin ein standardisiertes Menschenskelett generiert.
 Dieses neue Skelett kann an das bereits vorhandene Modell angepasst werden.
-Um eine bessere Übersicht zu ermöglichen, sollten zuerst alle nicht benötigten Skeletteile, wie zum Beispiel für Gesichtsanimationen, entfernt werden.
+Um eine bessere Übersicht zu ermöglichen, sollten zuerst alle nicht benötigten Skelettteile, wie zum Beispiel für Gesichtsanimationen, entfernt werden.
 Danach müssen die Knochen durch Verschiebung und Skalierung an die richtigen Positionen im Modell gebracht werden.
 
 Dabei muss auf die Ausrichtung der Knochen zueinander geachtet werden.
@@ -227,7 +227,7 @@ Der Grund dafür ist das Kreuzprodukt, dass im oben genannten Fall ein Nullvekto
 
 Deshalb muss bei der Platzierung darauf geachtet werden, dass der Startpunkt A des ersten und der Endpunkt C des zweiten Knochens auf einer Gerade liegen.
 Der Verbindungspunkt B der beiden Knochen wird vorerst auf dieser Gerade platziert.
-Dieser muss senkrecht zu dieser Gerade und der gewünschten Biegeachse verschoben werden, wie in Abbildung \ref{bend} gezeigt.
+Dieser muss senkrecht zu dieser Gerade und der gewünschten Beugeachse verschoben werden, wie in Abbildung \ref{bend} gezeigt.
 
 \begin{figure}
 \begin{minipage}{.45\textwidth}
@@ -318,7 +318,7 @@ Für die neuen Animationen werden die erstellten Steuerknochen verwendet, welche
 Die Verwendung des hier erstellten, verbesserten und animierten Rigs ist in vielen Grafikengines, darunter auch Gazebo, noch nicht möglich.
 Es bedarf einer zusätzlichen Anpassung des Skeletts, bei der die neu erstellte Knochenstruktur aufgelöst wird, da Gazebo keine Constraints unterstützt.
 
-Um aus einem existierenden, vollständig verbundenen Skelett ein Skelett ohne verbundene Knochen zu extrahieren, exisitiert ein weiteres Plugin mit dem Namen ``Game_Rig_Tools''\cite{gamerig}.
+Um aus einem existierenden, vollständig verbundenen Skelett ein Skelett ohne verbundene Knochen zu extrahieren, existiert ein weiteres Plugin mit dem Namen ``Game_Rig_Tools'' \cite{gamerig}.
 Dieses separiert die neuen Steuerknochen wieder vom ursprünglichen Modell, damit in diesem nur noch die deformierenden Knochen enthalten sind.
 
 Alle erstellten Animationen der Steuerknochen müssen in direkte Bewegungen der deformierenden Knochen des Modells umgewandelt werden.
@@ -349,7 +349,7 @@ Wird diese Modifikation nicht vorgenommen, sind die Modelle um 90 Grad verdreht.
 Zuletzt muss im mit 5 markierten Animations-Reiter noch eine weitere Einstellung vorgenommen werden.
 Die mit 6 markierte Einstellung bewirkt, dass alle Bewegungen der exportierten Knochen mit gespeichert werden, auch wenn diese sich nicht bewegen.
 Da sich einige Knochen in der Animation in einer konstanten Pose befinden, exportiert Blender diese nicht.
-Dies führt zu Fehlern, falls die Knochen von der Standartposition abweichen.
+Dies führt zu Fehlern, falls die Knochen von der Standardposition abweichen.
 Ein solcher Fehler äußert sich in Gazebo durch verdrehte Knochen während der Animation.
 
 \begin{figure}
@@ -384,20 +384,19 @@ Diese Kollisionen führt zu einem Crash, wenn beide Plugins in der Simulation ge
 Der Crash geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS-Topics, verwenden.
 
 In dieser Bibliothek wird eine globale Instanz angelegt, die den Zustand des Kommunikationsprotokolls abbildet.
-Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zur Problemen, da kein Synchronisationsmechanismus existiert.
+Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zu Problemen, da kein Synchronisationsmechanismus existiert.
 Die dadurch entstehenden gleichzeitigen Zugriffe auf dieselben Ressourcen führen zur Terminierung des Programms.
 
-Nachdem die Fehlerursache ermittelt war, stellte sich heraus, daß der Konflikt allein durch Modifikation des ActorPlugins nicht aufzulösen ist.
+Nachdem die Fehlerursache ermittelt war, stellte sich heraus, das der Konflikt allein durch Modifikation des ActorPlugins nicht aufzulösen ist.
 
-Eine Anpassung beider Plugins auf die gemeinsame Nutzung der Bibliothek ist möglich, erfordert aber potentiell weitreichende Neuimplementationen, die zeitlich im Rahmen dieser Arbeit nicht umsetzbar waren.
+Eine Anpassung beider Plugins auf die gemeinsame Nutzung der Bibliothek ist möglich, erfordert aber potenziell weitreichende Neuimplementationen, die zeitlich im Rahmen dieser Arbeit nicht umsetzbar waren.
 Die Nutzung eines separaten Nachrichtendienstes, der keinen globalen Kontext benötigt, ist die sicherste und schnellste Lösung des Problems.
 Eine solche Implementation erfordert jedoch zusätzliche Logik, um die beiden Dienste ineinander übersetzen zu können.
 
 Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschiedlichen Möglichkeiten getroffen.
-Webdienste, wie zum Beispiel REST-API's und Websockets werden von vielen Sprachen nativ untersützt, was diese universell einsetzbar macht.
+Webdienste, wie zum Beispiel REST-API's und Websockets werden von vielen Sprachen nativ unterstützt, was diese universell einsetzbar macht.
 
-Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die Hyper Text Transfer Protocol, auch HTTP genannt, unterstützt.
+Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die das ``Hyper Text Transfer Protocol'', auch HTTP genannt, unterstützt.
-da diese zur Kommunikation genutzt werden
 Das HTTP besitzt jedoch keinen einheitlichen Feedbackmechanismus.
 Dieser müsste entweder durch kontinuierliche Abfragen des aktuellen Status, auch ``polling'' genannt, oder eine lang anhaltende Request realisiert werden.
 Eine Verwendung von kontinuierlichen Abfragen ist zwar mit fast jeder Programmiersprache möglich, jedoch ist die Reaktionszeit des Systems an die Antwortzeit des Servers gebunden.
@@ -406,18 +405,18 @@ Der Einsatz einer lang anhaltenden Request umgeht dieses Problem, jedoch müssen
 Das neuere Websocket-Protokoll \cite{websocket} bieten die Möglichkeit, bidirektional Daten zu übertragen.
 Dadurch können Aktionsanfragen und Feedback auf dem gleichen Kanal übertragen werden, was das Protokoll übersichtlicher macht.
 Beide Technologien basieren auf einem Webserver, der auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Services ermöglicht.
-Die Portnummer kann zwar geändert werden, ist jedoch nicht einfach mit einer Komponente assoziierbar, was sie zu einer ``Magischen Zahl'' macht.
+Die Portnummer kann zwar geändert werden, ist jedoch nicht einfach mit einer Komponente assoziierbar, was sie zu einer ``magischen Zahl'' macht.
 Dies sorgt für schlechte Lesbarkeit in einem wichtigen Teil des Kontrollflusses.
 Außerdem besitzen beide Technologien durch TCP oder UDP und HTTP relativ großen Protokolloverhead, der bei den hohen Updateraten der Gazebo-Simulation zu Problemen führen könnte.
 
-Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen.\cite{shmem}
+Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen \cite{shmem}.
 Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den gleichen Speicherbereich zugreifen können.
 Alle Zugriffe auf den Bereich sind extrem schnell, da sie den Arbeitsspeicher des Systems nie verlassen, was diese Technik ideal zur Datenübertragung zwischen Prozessen macht.
 Durch das Erlauben gleichzeitiger Zugriffe kann es vorkommen, dass beide Programme gleichzeitig versuchen, Änderungen am Speicher vorzunehmen.
 Diese gleichzeitige Modifikation, auch ``race condition'' genannt, kann zu Fehlern führen, wenn die Zugriffe auf den Bereich nicht kontrolliert werden.
 
 Die letzte betrachtete Methode ist die Verwendung einer Message Queue.
-Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustauch reserviert.
+Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustausch reserviert.
 Dieser Bereich besitzt ein Identifikationsmerkmal, dass es Anwendungen erlaubt, Zugriff auf diesen zu erlangen.
 Ein Programm kann in diesem Bereich Daten ablegen, die durch andere Programme gelesen und geschrieben werden können.
 Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, ausschließt.
@@ -428,9 +427,9 @@ Die Angaben zu den Durchsätzen der verschiedenen Datenübertragungsmechanismen
 Als Nachrichtendienst wurde die MessageQueue ausgewählt, da die integrierten Funktionen die Entwicklung erleichtern und die Geschwindigkeit ausreichend für das Einsatzszenario ist.
 Jedoch existieren unter Linux 2 unabhängige Implementationen von MessageQueues mit unterschiedlichen Funktionen.
 
-Die erste Implementation ist die System V MessageQueue\cite{mqSystemV}, und verwendet zur Identifikation einfache Ganzzahlen.
+Die erste Implementation ist die System V MessageQueue \cite{mqSystemV} und verwendet zur Identifikation einfache Ganzzahlen.
 
-Die neuere Implementation der MessageQueue ist die POSIX-MessageQueue.\cite{mqPosix}
+Die neuere Implementation der MessageQueue ist die POSIX-MessageQueue \cite{mqPosix}.
 Sie bietet einige weitere Funktionen, wie zum Beispiel asynchrone Benachrichtigungen bei neuen Nachrichten, Quality of Service und nutzt bis zu 256 Zeichen lange Zeichenketten zur Identifikation.
 
 Die ausgewählte Implementation ist die neuere POSIX-Implementation einer Message Queue, da diese basierend auf den Erfahrungen mit der System V Implementation entwickelt wurde.
@@ -467,7 +466,7 @@ Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die H
   Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT zurückgewiesen werden.
  }
  \item{
-  Um Feedback während der Ausführung der Aktion geben zu können, exisitiert die dritte Funktion.
+  Um Feedback während der Ausführung der Aktion geben zu können, existiert die dritte Funktion.
   Diese erhält als Parameter ein Objekt, mit dem Feedback- und Endnachrichten an den Client gesendet werden können.
  }
 \end{itemize}
@@ -484,7 +483,7 @@ Der Server wartet den Zustandswechsel des Plugins ab und bestätigt dem Client d
 Ab diesem Zeitpunkt ist eine Terminierung der Anfrage durch den Client möglich.
 Dies geschieht durch eine Abbruchanfrage, welche sofort bearbeitet wird.
 Für den Abbruch wird der Status des Plugins über die MessageQueue auf IDLE gesetzt, was alle laufenden Aktionen sofort beendet.
-Der Zustandswechsel des Plugins wird abgewartet, um bei erreichen des IDLE-Zustands die Abbruchanfrage zu bestätigen.
+Der Zustandswechsel des Plugins wird abgewartet, um bei Erreichen des IDLE-Zustands die Abbruchanfrage zu bestätigen.
 
 Solange die Aktion läuft, werden periodisch Feedbacknachrichten über die MessageQueue an den Server gesendet.
 Der Server bringt diese in ein neues Format und leitet sie an den Client weiter.
@@ -504,11 +503,11 @@ Der Code des Plugins ist dabei im Paket \code{ign_actor_plugin} organisiert, das
 Das Plugin wird durch den Startvorgang und später von den empfangenen Nachrichten in folgende Zustände versetzt werden:
 \begin{description}
  \item[Setup]
-  wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simualtionumgebung im Plugin zu hinerlegen, so dass diese in den anderen Zuständen genutzt werden können.
+  wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simulationsumgebung im Plugin zu hinterlegen, sodass diese in den anderen Zuständen genutzt werden können.
  \item[Idle]
   definiert den Zustand, der nach erfolgreicher Ausführung eines Befehls angenommen wird.
  \item[Movement]
-  bedeutet die Ausführung einer Bewegung in potentiell mehreren Schritten.
+  bedeutet die Ausführung einer Bewegung in potenziell mehreren Schritten.
  \item[Animation]
   entspricht der Ausführung einer Animation an der aktuellen Position des Actors.
   Diese kann durch einen Skalierungsfaktor beschleunigt oder verlangsamt werden.
@@ -537,8 +536,8 @@ Die wichtigsten Komponenten für die Funktion des Plugins sind dabei:
 \end{description}
 
 Durch das Verändern dieser Komponenten kann die gewünschte Funktionalität des Plugins erreicht werden.
-Diese Veränderungen müssen zu jedem Simulationschritt erneut vorgenommen werden, um einen flüssigen Ablauf zu gewährleisten.
+Diese Veränderungen müssen zu jedem Simulationsschritt erneut vorgenommen werden, um einen flüssigen Ablauf zu gewährleisten.
-Um dies zu erreichen, können im Plugin bestimmte Interfaces mit entsprechenden Funktionen implementiert werden.\cite{ignPlugin}
+Um dies zu erreichen, können im Plugin bestimmte Interfaces mit entsprechenden Funktionen implementiert werden \cite{ignPlugin}.
 Diese Funktionen werden später in der Simulation aufgerufen.
 Folgende Funktionen werden von Gazebo unterstützt:
 \begin{description}
@@ -560,20 +559,20 @@ Jede dieser Funktionen ist in einem Interface mit dem Präfix \code{ISystem} def
 Für Gazebo muss das Plugin noch registriert werden, was mit dem \code{IGNITION_ADD_PLUGIN}-Makro geschieht.
 Mit diesen Vorbereitungsschritten wird das Plugin von Gazebo verwendbar gemacht.
 
-Das ActorPlugin benötigt für seine Funktion das übergeornete Simulationsobjekt, dass durch das Plugin beeinflusst werden soll.
+Das ActorPlugin benötigt für seine Funktion das übergeordnete Simulationsobjekt, dass durch das Plugin beeinflusst werden soll.
 Dies erfordert die Implementation des \code{ISystemConfigure}-Interfaces für das ActorPlugin.
 Außerdem soll die simulierte Person bewegt werden. Da dieser Vorgang während der Simulationszeit ablaufen soll, muss hierfür das \code{ISystemUpdate}-Interface genutzt werden.
 
-Als erstes wird durch das Laden des Plugins die Configure-Funktion aufgerufen.
+Als Erstes wird durch das Laden des Plugins die Configure-Funktion aufgerufen.
 Da das Plugin erst durch Gazebo geladen werden muss, kann davon ausgegangen werden, dass alle benötigten Message Queues bereits durch den ActorServer erstellt wurden.
 Trotz dieses Umstandes wartet das Plugin auf deren Erstellung, um bei Konfigurationsfehlern auffälliges Verhalten zu zeigen.
 Im Log wird diese Aktion vermerkt, um das Debugging zu erleichtern.
 Nach dem erfolgreichen Aufbau der Verbindung wird ein Thread gestartet, der die eingehenden Nachrichten verarbeitet.
-Dabei wird zuerst ein Sperre gesetzt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
+Dabei wird zuerst eine Sperre gesetzt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
 Alle in der Anfrage gespeicherten Daten werden übernommen und der gewünschte State gesetzt.
-Nach dem Entfernen der Sperre wird im nächsten Simulationschritt die gewünschte Aktion durchgeführt.
+Nach dem Entfernen der Sperre wird im nächsten Simulationsschritt die gewünschte Aktion durchgeführt.
 
-Das Setzen aller obrigen Zustände ist dabei möglich, jedoch werden nur Idle, Animation und Movement genutzt.
+Das Setzen aller obigen Zustände ist dabei möglich, jedoch werden nur Idle, Animation und Movement genutzt.
 Der Idle-Zustand kann zum Beenden eines anderen Zustands eingesetzt werden, falls dieser abgebrochen werden soll.
 Die Zustände Animation und Movement werden gesendet, falls neue Ziele gesetzt werden sollen.
 Da beide Zustände Animationen verwenden, wird bei deren erster Ausführung in der Update-Funktion die gewünschte Animation gesetzt.
@@ -631,7 +630,7 @@ Hierzu wird ein Mutex verwendet, der die Auswertung neuer Nachrichten verhindert
 Parallel werden alle eingehenden Feedback-Nachrichten der Message Queue des ActorPlugins in Feedback für die aktuell laufende Action umgewandelt.
 
 Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
-Zuerst werden Animationsname und -diztanz benötigt, um die richtige Animation auszuwählen und die Bewegung mit der Animation zu synchronisieren.
+Zuerst werden Animationsname und -distanz benötigt, um die richtige Animation auszuwählen und die Bewegung mit der Animation zu synchronisieren.
 Als Feedbacknachricht erhält der Client die aktuelle Pose des Actors im Simulationsraum.
 
 Soll eine Animation über den ActionServer abgespielt werden, wird neben dem Animationsnamen noch die Animationsgeschwindigkeit als Parameter benötigt.
@@ -745,7 +744,7 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
   Hierfür wird überprüft, ob die X und Y-Werte der Pose in einem der Dreiecke liegen, welche die Area definieren.
   Der Rückgabewert ist das Ergebnis dieser Überprüfung, wobei SUCCESS bedeutet, dass sich die Pose in der Area befindet.
   \item[OffsetPose]
-  wird genuzt, um eine Pose im Raum zu bewegen und/oder deren Orientierung zu verändern.
+  wird genutzt, um eine Pose im Raum zu bewegen und/oder deren Orientierung zu verändern.
   Falls der \code{offset} Parameter gesetzt ist, wird dieser mit dem \code{input} Parameter summiert.
   Außerdem wird die Orientierung der Pose auf den \code{orientation} Parameter gesetzt, falls dieser vorhanden ist, was den ursprünglichen Wert überschreibt.
   \item[InterruptableSequence]
@@ -775,16 +774,16 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
 \begin{description}
   \item[ActorAnimation]
   wird verwendet, um dem simulierten Menschen eine auszuführende Animation zu senden.
-  Die Node benötigt zur Ausführung einen Animationsname, der im \code{animation_name} Parameter angegeben wird.
+  Die Node benötigt zur Ausführung einen Animationsnamen, der im \code{animation_name} Parameter angegeben wird.
   Ein optionaler \code{animation_speed} Parameter gibt die Ausführungsgeschwindigkeit vor.
   Der Rückgabewert ist SUCCESS, wenn die komplette Ausführung gelang, oder FAILURE, falls diese abgebrochen oder abgelehnt wurde.
   \item[ActorMovement]
   funktioniert wie eine ActorAnimation, sendet jedoch eine Bewegungsanfrage.
   Auch für diese wird ein Animationsname benötigt, der im \code{animation_name} Parameter definiert wird.
-  Jedoch wird für die Synchronisation zur Bewegung ein Disztanzwert benötigt, der in einem Animationsdurchlauf zurückgelegt wird.
+  Jedoch wird für die Synchronisation zur Bewegung ein Distanzwert benötigt, der in einem Animationsdurchlauf zurückgelegt wird.
   Dieser wird im \code{animation_distance} Parameter übergeben.
   Eine Zielpose wird im \code{target} Parameter gesetzt.
-  Eine Besonderheit dieses Paramerters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
+  Eine Besonderheit dieses Parameters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
 \end{description}
 
 \subsubsection{Roboterspezifische Nodes}
@@ -870,7 +869,7 @@ Dies wird durch eine über dem Test angeordnete Inverter-Node erreicht.
 Nach diesem Schritt kann die Geschwindigkeitsanpassung vorgenommen werden, falls diese nötig ist.
 Dies wird durch eine If-Then-Else Node erreicht.
 Als Bedingung wird ein Test auf den Aufenthalt des Menschen in der Warnzone verwendet.
-Wenn der Mensch sich in dieser befindet, wird die Geschwingigkeit auf 10\% gesetzt.
+Wenn der Mensch sich in dieser befindet, wird die Geschwindigkeit auf 10\% gesetzt.
 Sonst wird die Geschwindigkeit wieder auf 100\% erhöht.
 
 Nach dieser Sequenz kann der spezifische Teil für die gewünschte Applikation hinzugefügt werden.
@@ -952,6 +951,7 @@ Der normale Arbeitsvorgang ist ein linearer Ablauf und wird von einer Sequence-N
 In dieser werden nacheinander die beiden Subtrees ``WorkOnBench'' und ``DepositToShelf'' ausgeführt.
 Das Bewegen in die Sicherheitszone wird auch durch eine Sequence-Node erreicht.
 Diese enthält eine GenerateXYPose-Node, um ein Ziel in der Sicherheitszone auszuwählen und eine ActorMovement-Node, um die Bewegung auszulösen.
+Der Baum für diese Interaktion wird in Abbildung \ref{tree_actor_coex} dargestellt.
 
 \begin{figure}
 \includegraphics[width=\textwidth]{img/MA-tree-actor-coex}
@@ -975,7 +975,7 @@ Dies erfolgt durch eine ActorMovement-Node, welche den Mensch zum rechten Tisch
 Nach dieser werden zwei ActorAnimation-Nodes ausgeführt, welche die Animationen ``standing_extend_arm'' und ``standing_retract_arm'' durchführen.
 Dies simuliert den Griff auf den Tisch, um das Objekt aufzuheben.
 Um das Objekt im Schrank zu verstauen, wird der bereits definierte Subtree ``DepositToShelf'' genutzt.
-
+Der Behavior Tree für die Kooperation des Menschen ist in Abbildung \ref{tree_actor_coop} dargestellt.
 
 \begin{figure}
 \includegraphics[width=\textwidth]{img/MA-tree-actor-coop}
@@ -991,15 +991,15 @@ Falls der Mensch nicht vom Roboter gerufen wird, soll dieser im Raum herumwander
 Für die Festlegung einer Baumstruktur ist es wichtig, ob der Mensch sofort, oder erst nach dem Vollenden seiner Arbeit dem Roboter zu Hilfe kommt.
 In diesem Fall soll er seine Arbeit unterbrechen, um auch diese Möglichkeit zu demonstrieren.
 
-Ein solches Verhalten lässt sich mit Hilfe einer Fallback- mit untergeordneter ReactiveSequence-Node modellieren.
+Ein solches Verhalten lässt sich mithilfe einer Fallback- mit untergeordneter ReactiveSequence-Node modellieren.
 In der ReactiveSequence wird zuerst überprüft, ob der Mensch gerufen wurde.
 Da dieser Zustand die ReactiveSequence abbrechen soll, wird die verantwortliche AmICalled-Node mit einer Inverter-Node versehen.
-In der ReactiveSequence kann eine weitere Sequence nach der Inverter-Node angeornet werden.
+In der ReactiveSequence kann eine weitere Sequence nach der Inverter-Node angeordnet werden.
 
 Diese Sequence-Node enthält den Teil des Baumes, der ausgeführt werden soll, solange der Mensch nicht gerufen wird.
 In diesem Fall wird mit einer WeightedRandom-Node eine von drei GenerateXYPose-Nodes ausgewählt.
 Diese geben jeweils Ziele in der sicheren Zone, Warnzone und Sicherheitszone zurück.
-Nach der WeightedRandom-Node wird eine ActorMovement-Node genutzt, welche den Mensch zu dem ausgewählen Ziel bewegt.
+Nach der WeightedRandom-Node wird eine ActorMovement-Node genutzt, welche den Mensch zu dem ausgewählten Ziel bewegt.
 
 Neben der ReactiveSequence unter der Fallback-Node wird eine weitere Sequence angeordnet.
 Hier wird die gewünschte Aktionsfolge bei Ruf durch den Roboter definiert.
@@ -1014,6 +1014,7 @@ Auch hier wird zum Ablegen eine weitere Animationsfolge aus zwei ActorAnimation-
 Dabei wird zuerst ``standing_extend_arm'' abgespielt, gefolgt von ``standing_retract_arm''.
 
 Als letzte Aktion wird der Ruf nach dem Menschen durch eine SetCalledTo-Node auf false zurückgesetzt.
+Dieser Behavior Tree ist in Abbildung \ref{tree_actor_colab} dargestellt.
 
 \begin{figure}
 \includegraphics[width=\textwidth]{img/MA-tree-actor-colab}

tex/5_Evaluation_und_Diskussion.tex

@@ -49,11 +49,11 @@ Das entworfene Containersystem ist mit der bereitgestellten Funktionalität eine
 \subsubsection{Erstellung der benötigten Modelle}
 Für den simulierten Menschen und Roboter werden verschiedene Modelle benötigt.
 Das Robotermodell wurde aus Herstellerdaten exportiert und in Blender nachbearbeitet.
-Eine Definition des Roboters wurde für Gazebo und MoveIt erstellt, um die Zusammenhänge der einzelnen Armglieder und die physikalische Eigenschaften der Gelenke festzulegen.
+Eine Definition des Roboters wurde für Gazebo und MoveIt erstellt, um die Zusammenhänge der einzelnen Armglieder und die physikalischen Eigenschaften der Gelenke festzulegen.
 
 Für das Modell des Menschen wurde eine bereits in Gazebo enthaltene Animation als Grundlage verwendet.
 Das in dieser enthaltene Modell wurde angepasst, um das Erstellen weiterer Animationen zu vereinfachen.
-Mit Hilfe dieses modifizierten Modells wurden dann die benötigten Animationen erstellt.
+Mithilfe dieses modifizierten Modells wurden dann die benötigten Animationen erstellt.
 
 \subsubsection{Steuerung des Menschen}
 
@@ -87,8 +87,8 @@ Eine Kombination dieser neu implementieren und den bereits in BehaviorTree.CPP v
 
 \subsection{Erstellen der benötigten Pakete}
 
-Alle benötigten Pakete müssen vor der ersten Ausführung der Simulation kompilliert werden.
+Alle benötigten Pakete müssen vor der ersten Ausführung der Simulation kompiliert werden.
-Dies wird durch das Ausführen des \code{build.sh}-Skripts im Verzeichnis \code{\textasciitilde/workspace} des Container ausgelöst.
+Dies wird durch das Ausführen des \code{build.sh}-Skripts im Verzeichnis \code{\textasciitilde/workspace} des Containers ausgelöst.
 Nach diesem Vorgang muss der Workspace neu geladen werden, damit die jetzt verfügbaren Pakete registriert werden.
 
 Die kann sowohl durch einen erneuten Aufbau der SSH-Verbindung erfolgen, da bei Start der Session die entsprechende Datei geladen wird, oder manuell geschehen.
@@ -125,7 +125,7 @@ Der Roboter befindet sich nach dem Start in der Ausgangsposition, siehe Abbildun
 \end{minipage}
 \end{figure}
 
-Alle beschriebenen Szenarien sind mit Außnahme des Fließbandes aus dem Kooperationsszenario als Behavior Trees umgesetzt.
+Alle beschriebenen Szenarien sind mit Ausnahme des Fließbandes aus dem Kooperationsszenario als Behavior Trees umgesetzt.
 Diese werden nach dem Start einer Simulation ausgeführt und definieren das Verhalten von Roboter und Mensch.
 
 \subsubsection{Koexistenzszenario}
@@ -208,7 +208,7 @@ Während der Entwicklung des Projekts wurden zahlreiche Erkenntnisse gesammelt,
  \item[Überprüfung auf Updates]\hfill\\
   Die regelmäßige Prüfung von verwendeten Bestandteilen auf Updates kann helfen, neue oder verbesserte Funktionen einzusetzen.
  \item[Verwendung eines Debuggers]\hfill\\
-  Viele Nodes in ROS können über Kommandozeilenparameter im Debugmodus ausgeführt werden.\cite{rosDebug}
+  Viele Nodes in ROS können über Kommandozeilenparameter im Debugmodus ausgeführt werden \cite{rosDebug}.
   Da Programme wie Gazebo aber über weitere Launch-Files eingebunden werden, ist dies hier nicht möglich.
-  Eine Lösung ist in diesem Fall der separate Start der Gazebo-Umgebung in einem Debugger.\cite{gazeboDebug}
+  Eine Lösung ist in diesem Fall der separate Start der Gazebo-Umgebung in einem Debugger \cite{gazeboDebug}.
 \end{description}

tex/6_Ausblick.tex

@@ -1,13 +1,13 @@
 \chapter{Ausblick}
 \section{Umsetzung in anderem Simulator}
-Die Umsetzung des gleichen Problems in einem anderen Simulator bietet die Möglichkeit, weitere Simulationsplatformen zu testen und miteinander zu vergleichen.
+Die Umsetzung des gleichen Problems in einem anderen Simulator bietet die Möglichkeit, weitere Simulationsplattformen zu testen und miteinander zu vergleichen.
 Hierbei ist vor allem die Anbindung an ROS interessant, welche mit Gazebo mit nur einem Plugin gleichzeitig funktioniert.
 
 Eine verbesserte Anbindung an ROS würde die schnellere Entwicklung von Komponenten und Szenarien erlauben.
 Da diese für viele andere Simulatoren erst geschaffen werden muss, kann von Anfang an der Fokus auf Erweiterbarkeit gelegt werden.
 
-Je nach gewählter Umgebung ist es potentiell nötig, bestimmte Basisfunktionen neu zu implementieren, falls diese noch nicht unterstützt werden.
+Je nach gewählter Umgebung ist es potenziell nötig, bestimmte Basisfunktionen neu zu implementieren, falls diese noch nicht unterstützt werden.
-Moderne Gameengines sind für diesen Einsatzzweck geeignet, da diese viele Bestandteile einer Simulationsplatform bereits enthalten.
+Moderne Gameengines sind für diesen Einsatzzweck geeignet, da diese viele Bestandteile einer Simulationsplattform bereits enthalten.
 Außerdem ist die hohe Verfügbarkeit von Tutorials und Dokumentation für diese weitläufig eingesetzten Engines vorteilhaft.
 
 Mitgelieferte Werkzeuge bekannter Engines wie Unity, Unreal Engine und Godot beinhalten ausgereifte Physik- und Animationssysteme.
@@ -19,7 +19,7 @@ Um ein Objekt mit dem Roboter oder Menschen zu bewegen, muss dieses auf eine von
 
 Die Bewegung von Objekten mit dem Roboter ist möglich, da dieser mit der gegenwärtigen Implementation aus mehreren Physikobjekten besteht.
 Das zu  bewegende Objekt kann somit dem Objekt des Endeffektors als Unterobjekt hinzugefügt werden.
-Der daraus resultierende Übergang in lokale Koordinaten kann potentielle Umrechnung anhand der Transformationen vorhergehender Armteile erfordern.
+Der daraus resultierende Übergang in lokale Koordinaten kann potenzielle Umrechnung anhand der Transformationen vorhergehender Armteile erfordern.
 
 Eine Bewegung mit dem Menschen erfordert vor allem bei Animationen einen anderen Mechanismus.
 Da der Mensch nicht aus einzelnen Physikobjekten besteht, ist die Anbringung als Unterobjekt nicht möglich.
@@ -38,7 +38,7 @@ Mit den Kameras kann eine Tiefenkarte erstellt werden, um die Verfahrgeschwindig
 MoveIt implementiert für diesen Verwendungszweck bereits sogenannte Octomaps.
 Diese Octomaps repräsentieren die Belegung eines Raums durch Objekte mit gleichseitigen Würfeln.
 
-Der Einsatz dieser OctoMaps zum Ausweichen von Hindernissen ist bereits in der Bewegungsplanung implementiert.
+Der Einsatz dieser Octomaps zum Ausweichen von Hindernissen ist bereits in der Bewegungsplanung implementiert.
 Für die Reduktion der Verfahrgeschwindigkeit muss der erwartete Raum mit dem aktuellen Raum verglichen werden.
 Daraus kann die Distanz zu einem unerwarteten Objekt berechnet werden, um die Verfahrgeschwindigkeit dementsprechend anzupassen.
 \section{Zusammenführung von ActorPlugin und ActorServer}
@@ -54,7 +54,7 @@ Folgende Versuche wurden bereits durchgeführt, führten aber zu keinem Erfolg:
 Die neuste ROS-Version bietet keine expliziten Vorteile der Umgebung selbst, jedoch sind in dieser mehr Pakete verfügbar.
 In der für das Projekt genutzten Umgebung befinden sich mehrere Pakete, die so auf eine neuere Version gebracht werden könnten.
 Jedoch ist der Aufwand einer Migration nur schwer abschätzbar.
-Dies führte zu der Entscheidung, diesen Prozesses in dieser Arbeit nicht durchzuführen.
+Dies führte zu der Entscheidung, diesen Prozess in dieser Arbeit nicht durchzuführen.
 
 Ein Vorteil dieser Maßnahme ist die Möglichkeit, das Paket \code{gz_ros2_control} aus einer offiziellen Paketquelle zu beziehen.
 Dieses Paket stellt das Gazebo-Plugin für den Roboter bereit und muss so nicht manuell auf dem neusten Stand gehalten werden.
@@ -62,7 +62,7 @@ Dieses Paket stellt das Gazebo-Plugin für den Roboter bereit und muss so nicht
 \section{Verbesserung der Behavior Trees}
 Eine weitere mögliche Verbesserung ist der Ausbau der Implementation der Behavior Trees.
 
-Ein Update auf die neuste Version, die während der Entwicklung diese Projektes erschienen ist, würde die verbesserte Nutzung von asynchronen Nodes erlauben.
+Ein Update auf die neuste Version, die während der Entwicklung dieses Projektes erschienen ist, würde die verbesserte Nutzung von asynchronen Nodes erlauben.
 Die Integration von Pre- und Post-Conditions erlaubt die Ausführung von Events vor und nach dem Ausführen einer Node.
 Weitere universelle Node-Parameter vereinfachen den Aufbau von Bäumen durch die Vereinfachung von Schleifen und Bedingungen.
 
@@ -77,5 +77,5 @@ Diese werden aber für die Steuerung des Menschen benötigt, was dieses Alternat
 Die Anpassung der aktuellen Implementation für größere Projekte ist eine weitere Option.
 Um die Übersichtlichkeit des Projekts zu erhöhen, werden häufig separate Module verwendet.
 Diese können einzelne Funktionen bereitstellen, die separat von anderen Modulen agieren.
-Alle Module müssen aktuell im Buildfile deklariert und mit in das Programm kompilliert werden.
+Alle Module müssen aktuell im Buildfile deklariert und mit in das Programm kompiliert werden.
 Bei einer großen Anzahl an Modulen erschwert dieser Umstand die Übersicht über benötigte Module für spezifische Trees.