spellcheck.

.gitignore

@@ -1,8 +1,3 @@
-
-# Created by https://www.toptal.com/developers/gitignore/api/latex
-# Edit at https://www.toptal.com/developers/gitignore?templates=latex
-
-### LaTeX ###
 ## Core latex/pdflatex auxiliary files:
 *.aux
 *.lof
@@ -305,11 +300,4 @@ TSWLatexianTemp*
 # Uncomment the next line to have this generated file ignored.
 #*Notes.bib
 
-### LaTeX Patch ###
-# LIPIcs / OASIcs
-*.vtc
-
-# glossaries
-*.glstex
-
-# End of https://www.toptal.com/developers/gitignore/api/latex
+/main.pdf

.kile/mechforsch.kilepr.gui

@@ -2,7 +2,16 @@
 kile_livePreviewEnabled=true
 kile_livePreviewStatusUserSpecified=true
 kile_livePreviewTool=LivePreview-PDFLaTeX
-lastDocument=main.tex
+lastDocument=tex/3_Auswahl.tex
+
+[document-settings,item:Einleitung.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
 
 [document-settings,item:main.bib]
 Bookmarks=
@@ -22,9 +31,72 @@ Indentation Mode=normal
 Mode=LaTeX
 Mode Set By User=true
 
+[document-settings,item:tex/1_Einleitung.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
+
+[document-settings,item:tex/2_Konzept.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
+
+[document-settings,item:tex/3_Auswahl.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
+
+[document-settings,item:tex/4_Umsetzung.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
+
+[document-settings,item:tex/5_Evaluation_und_Diskussion.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
+
+[document-settings,item:tex/6_Ausblick.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
+
+[document-settings,item:tex/Einleitung.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
+
 [item:main.bib]
 open=true
-order=1
+order=7
 
 [item:main.tex]
 open=true
@@ -34,18 +106,106 @@ order=0
 open=false
 order=-1
 
-[view-settings,view=0,item:main.bib]
-CursorColumn=14
-CursorLine=109
+[item:tex/1_Einleitung.tex]
+open=true
+order=1
+
+[item:tex/2_Konzept.tex]
+open=true
+order=2
+
+[item:tex/3_Auswahl.tex]
+open=true
+order=3
+
+[item:tex/4_Umsetzung.tex]
+open=true
+order=4
+
+[item:tex/5_Evaluation_und_Diskussion.tex]
+open=true
+order=5
+
+[item:tex/6_Ausblick.tex]
+open=true
+order=6
+
+[view-settings,view=0,item:Einleitung.tex]
+CursorColumn=0
+CursorLine=0
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"4af487415133a6dcd896d70e042ef9ac694f0ea6","ranges":[]}
+TextFolding={"checksum":"","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:main.bib]
+CursorColumn=51
+CursorLine=326
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"8795c48226fb036f16e6bbcfbf55b812c6d43eaa","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
 CursorColumn=0
-CursorLine=455
+CursorLine=105
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"1d8262bd4fab97ca3ac166d2d70ba8518a0c146f","ranges":[]}
+TextFolding={"checksum":"80ccd936ce5ae7dc5995816ffe293139ed94b427","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:tex/1_Einleitung.tex]
+CursorColumn=196
+CursorLine=35
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"99e42b912b320890bab1219df1e7d056e5124a2d","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:tex/2_Konzept.tex]
+CursorColumn=26
+CursorLine=25
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"111913c063e94bf8f1bf4f786b47b20be2773064","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:tex/3_Auswahl.tex]
+CursorColumn=17
+CursorLine=361
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"7aa9002df025f03505dbfc278b329c1fb13f4e2a","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:tex/4_Umsetzung.tex]
+CursorColumn=102
+CursorLine=1001
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"dbda4a467836d9dfaee2833e58221fe122996b5e","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:tex/5_Evaluation_und_Diskussion.tex]
+CursorColumn=18
+CursorLine=168
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"847cd8cf59a779530aa24d2840e2423d2f10200b","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:tex/6_Ausblick.tex]
+CursorColumn=59
+CursorLine=71
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"e964476a9eab203b42b321940c7b6784639e0caf","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:tex/Einleitung.tex]
+CursorColumn=0
+CursorLine=0
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"","ranges":[]}
 ViMarks=

MA.gummi

@@ -0,0 +1,9 @@
+version=0.6.0
+typesetter=pdflatex
+steps=texpdf
+root=/home/yenon/MasterarbeitLaTeX/main.tex
+
+file=/home/yenon/MasterarbeitLaTeX/tex/1_Einleitung.tex
+file=/home/yenon/MasterarbeitLaTeX/tex/2_Konzept.tex
+file=/home/yenon/MasterarbeitLaTeX/tex/3_Auswahl.tex
+file=/home/yenon/MasterarbeitLaTeX/tex/4_Umsetzung.tex

dict.txt

@@ -0,0 +1,64 @@
+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}
+Subtree
+Blackboard
+Subtrees

main.bib

@@ -1,10 +1,3 @@
- 
-@misc{moveitProgress,
-  title = {Fortschritt der Entwicklung von MoveIt 2},
-  url = {https://docs.google.com/spreadsheets/d/1aPb3hNP213iPHQIYgcnCYh9cGFUlZmi_06E_9iTSsOI/edit#gid=0},
-  note = {letzter Zugriff: 5.4.2022},
-}
-
 @misc{quaternion,
   title = {Humane Rigging 03 - 3D Bouncy Ball 05 - Quaternion Rotation},
   url = {https://www.youtube.com/watch?v=4mXL751ko0w},
@@ -29,18 +22,12 @@
   note = {letzter Zugriff: 13.4.2022},
 }
 
-@misc{moveit_docs,
+@misc{moveit-docs,
   title = {MoveIt 2 Documentation},
   url = {https://moveit.picknik.ai/galactic/index.html},
   note = {letzter Zugriff: 13.4.2022},
 }
 
-@misc{sdf,
-  title = {SDFormat Specification},
-  url = {http://sdformat.org/spec},
-  note = {letzter Zugriff: 13.4.2022},
-}
-
 @misc{urdf,
   title = {Tutorial: Using a URDF in Gazebo},
   url = {http://gazebosim.org/tutorials/?tut=ros_urdf},
@@ -137,8 +124,207 @@
   note = {letzter Zugriff: 10.04.2023},
 }
 
+@misc{unity,
+  title = {Unity Real-Time Development Platform | 3D, 2D, VR \& AR Engine},
+  url = {https://unity.com},
+  note = {letzter Zugriff: 10.04.2023},
+}
+
 @misc{unityroboticsofficial,
   title = {Robotics Simulation | Unity},
   url = {https://unity.com/solutions/automotive-transportation-manufacturing/robotics},
   note = {letzter Zugriff: 10.04.2023},
 }
+
+@misc{unreal,
+  title = {The most powerful real-time 3D creation tool - Unreal Engine},
+  url = {https://www.unrealengine.com},
+  note = {letzter Zugriff: 10.04.2023},
+}
+
+@misc{godot,
+  title = {Godot Engine - Free and open source 2D and 3D game engine},
+  url = {https://godotengine.org},
+  note = {letzter Zugriff: 10.04.2023},
+}
+
+@misc{freecad,
+  title = {FreeCAD: Ihr parametrischer 3D-Modellierer},
+  url = {https://www.freecad.org/index.php?lang=de},
+  note = {letzter Zugriff: 21.04.2023},
+}
+
+@misc{xacro,
+  title = {FreeCAD: Ihr parametrischer 3D-Modellierer},
+  url = {https://github.com/ros/xacro},
+  note = {letzter Zugriff: 21.04.2023},
+}
+
+@misc{gazebo,
+  title = {Gazebo},
+  url = {https://staging.gazebosim.org/home},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@misc{gazebo-app,
+  title = {Gazebo},
+  url = {https://app.gazebosim.org/dashboard},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@misc{sdf-format,
+  title = {SDFormat Specification},
+  url = {https://sdformat.org/spec},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@misc{urdf-format,
+  title = {urdf/XML ROS Wiki},
+  url = {http://wiki.ros.org/urdf/XML},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@ARTICLE{1087032,
+  author={Brooks, R.},
+  journal={IEEE Journal on Robotics and Automation},
+  title={A robust layered control system for a mobile robot},
+  year={1986},
+  volume={2},
+  number={1},
+  pages={14-23},
+  doi={10.1109/JRA.1986.1087032}
+}
+
+@misc{cmake,
+  title = {CMake},
+  url = {https://cmake.org/},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@misc{coppelia,
+  title = {Robot simulator CoppeliaSim: create, compose, simulate, any robot - Coppelia Robotics},
+  url = {https://www.coppeliarobotics.com/},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@misc{rigify,
+  title = {Rigify — Blender Manual},
+  url = {https://docs.blender.org/manual/en/3.5/addons/rigging/rigify/index.html},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@misc{gamerig,
+  title = {BlenderBoi/Game_Rig_Tools},
+  url = {https://github.com/BlenderBoi/Game_Rig_Tools},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@misc{cpp,
+  title = {Standard C++},
+  url = {https://isocpp.org},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@misc{python,
+  title = {Welcome to Python.org},
+  url = {https://www.python.org},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@article{DOMBROWSKI2018134,
+title = {Simulation of human-robot collaboration by means of power and force limiting},
+journal = {Procedia Manufacturing},
+volume = {17},
+pages = {134-141},
+year = {2018},
+note = {28th International Conference on Flexible Automation and Intelligent Manufacturing (FAIM2018), June 11-14, 2018, Columbus, OH, USAGlobal Integration of Intelligent Manufacturing and Smart Industry for Good of Humanity},
+issn = {2351-9789},
+doi = {https://doi.org/10.1016/j.promfg.2018.10.028},
+url = {https://www.sciencedirect.com/science/article/pii/S2351978918311442},
+author = {Uwe Dombrowski and Tobias Stefanak and Anne Reimer},
+keywords = {Interactive simulation, collaborative robotics, occupational safety, health, manufacturing ergonomics, modeling, simulation, human factors, smart manufacturing},
+abstract = {In this paper, we show the importance of digital factory tools for the planning of human-robot collaboration (HRC), the associated risk assessment and the safety certification of the entire HRC-application. Referring to the structure of this paper, first we define the requirements of the simulation of human-robot collaboration by means of power and force limiting by inherent design or control. Then we review the state-of-the-art of domain of robotic simulation. We demonstrate how to determine the force and pressure in case of a direct collision between human and robot for industrial safety certification. With the help of a detailed parameter study, we reduce the needed parameters for the simulation of HRC to the relevant factors. Finally, the paper shows how to use the approach of simulation to reduce the time and costs for the implementation of real HRC-scenarios into the factory of tomorrow.}
+}
+
+@article{ffdrobotsim,
+author = {Dombrowski, Uwe and Stefanak, Tobias and Perret, Jérôme},
+year = {2017},
+month = {12},
+pages = {124-131},
+title = {Interactive Simulation of Human-robot Collaboration Using a Force Feedback Device},
+volume = {11},
+journal = {Procedia Manufacturing},
+doi = {10.1016/j.promfg.2017.07.210}
+}
+
+@book{btintro,
+author = { Michele Colledanchise and Petter Ögren },
+title = {Behavior Trees in Robotics and AI - An Introduction},
+year = {2018},
+journal = {CRC Press},
+doi = {https://doi.org/10.1201/9780429489105}
+}
+
+@misc{halo2,
+  title = {GDC 2005 Proceeding: Handling Complexity in the Halo 2 AI},
+  url = {https://www.gamedeveloper.com/programming/gdc-2005-proceeding-handling-complexity-in-the-i-halo-2-i-ai},
+  note = {letzter Zugriff: 18.05.2023},
+}
+
+@misc{ignPlugin,
+  title = {Ignition Gazebo: Create System Plugins},
+  url = {https://gazebosim.org/api/gazebo/2.10/createsystemplugins.html},
+  note = {letzter Zugriff 01.06.2023},
+}
+
+@misc{changesRosII,
+  title = {Changes between ROS 1 and ROS 2},
+  url = {http://design.ros2.org/articles/changes.html},
+  note = {letzter Zugriff 25.06.2023},
+}
+
+@misc{lsp,
+  title = {Official page for Language Server Protocol},
+  url = {https://microsoft.github.io/language-server-protocol/},
+  note = {letzter Zugriff 29.06.2023},
+}
+@misc{gazeboDebug,
+  title = {Ignition Gazebo: Debugging},
+  url = {https://gazebosim.org/api/gazebo/2.10/debugging.html},
+  note = {letzter Zugriff 29.06.2023},
+}
+@misc{rosDebug,
+  title = {How can I run ROS2 nodes in a debugger (e.g. gdb)? - ROS Answers: Open Source Q\&A Forum},
+  url = {https://answers.ros.org/question/267261/how-can-i-run-ros2-nodes-in-a-debugger-eg-gdb/},
+  note = {letzter Zugriff 29.06.2023},
+}
+@misc{mqPosix,
+  title = {mq_overview(7) — Linux manual page},
+  url = {https://man7.org/linux/man-pages/man7/mq_overview.7.html},
+  note = {letzter Zugriff 30.06.2023},
+}
+@misc{mqSystemV,
+  title = {sysvipc(7) — Linux manual page},
+  url = {https://man7.org/linux/man-pages/man7/sysvipc.7.html},
+  note = {letzter Zugriff 30.06.2023},
+}
+@misc{shmem,
+  title = {shm\_overview(7) — Linux manual page},
+  url = {https://man7.org/linux/man-pages/man7/shm_overview.7.html},
+  note = {letzter Zugriff 30.06.2023},
+}
+@misc{websocket,
+  title = {RFC 6455 - The WebSocket Protocol},
+  url = {https://datatracker.ietf.org/doc/html/rfc6455},
+  note = {letzter Zugriff 30.06.2023},
+}
+@misc{ipcBench,
+  title = {goldsborough/ipc-bench: :horse_racing: Benchmarks for Inter-Process-Communication Techniques},
+  url = {https://github.com/goldsborough/ipc-bench},
+  note = {letzter Zugriff 30.06.2023},
+}
+@misc{moveItStudio,
+  title = {MoveIt Studio Developer Platform \& SDK | PickNik},
+  url = {https://picknik.ai/studio/},
+  note = {letzter Zugriff 30.06.2023},
+}

main.out.ps

@@ -2,80 +2,3 @@
 /pdfmark where{pop}
 {/globaldict where{pop globaldict}{userdict}ifelse/pdfmark/cleartomark load put}
 ifelse
-[
-/Title(\376\377\000E\000i\000n\000l\000e\000i\000t\000u\000n\000g)
-/Action/GoTo/Dest(chapter.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000A\000u\000f\000g\000a\000b\000e)
-/Action/GoTo/Dest(chapter.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000L\000\366\000s\000u\000n\000g\000s\000k\000o\000n\000z\000e\000p\000t)
-/Count -4
-/Action/GoTo/Dest(chapter.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000R\000O\000S)
-/Count -2
-/Action/GoTo/Dest(section.3.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000M\000o\000v\000e\000I\000t)
-/Action/GoTo/Dest(subsection.3.1.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e)
-/Action/GoTo/Dest(subsection.3.1.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000G\000a\000z\000e\000b\000o)
-/Count -1
-/Action/GoTo/Dest(section.3.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000S\000e\000n\000s\000o\000r\000e\000n)
-/Action/GoTo/Dest(subsection.3.2.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000R\000o\000b\000o\000t\000e\000r)
-/Action/GoTo/Dest(section.3.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000Z\000u\000s\000a\000m\000m\000e\000n\000f\000a\000s\000s\000u\000n\000g)
-/Action/GoTo/Dest(section.3.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000U\000m\000s\000e\000t\000z\000u\000n\000g)
-/Count -1
-/Action/GoTo/Dest(chapter.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000R\000O\000S)
-/Count -4
-/Action/GoTo/Dest(section.4.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000A\000u\000s\000w\000a\000h\000l\000\040\000d\000e\000r\000\040\000R\000O\000S\000-\000U\000m\000g\000e\000b\000u\000n\000g)
-/Action/GoTo/Dest(subsection.4.1.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000G\000a\000z\000e\000b\000o)
-/Action/GoTo/Dest(subsection.4.1.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000M\000o\000v\000e\000I\000t)
-/Action/GoTo/Dest(subsection.4.1.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000u\000r\000-\000T\000r\000e\000e\000s)
-/Action/GoTo/Dest(subsection.4.1.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000E\000r\000g\000e\000b\000n\000i\000s\000s\000e)
-/Action/GoTo/Dest(chapter.5)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000D\000i\000s\000k\000u\000s\000s\000i\000o\000n)
-/Action/GoTo/Dest(chapter.6)cvn
-/OUT pdfmark

main.tex

@@ -8,29 +8,44 @@ parskip=half,
 \usepackage[ngerman]{babel}
 \usepackage[T1]{fontenc}
 \usepackage{lmodern}
+\usepackage[newfloat=true]{minted}
 \usepackage{csquotes}
 \usepackage[includehead, includefoot, left=3.0cm, right=2.5cm, top=1.5cm, bottom=1.5cm]{geometry}
 \usepackage{acro}
-\usepackage{listings}
-\usepackage[style=numeric,backend=biber]{biblatex}
-%\usepackage[style=numeric,backend=libbib]{biblatex}
+\usepackage[style=numeric,backend=biber,sorting=none]{biblatex}
+\usepackage{notoccite}
 \usepackage{pdfpages}
-\usepackage{scrhack}
 \usepackage{xcolor}
 \usepackage{enumitem}
+\usepackage[onehalfspacing]{setspace}
 \usepackage{hyperref}
 \usepackage{tabularray}
 \usepackage{xurl}
+\usepackage{soul}
+\usepackage{xcolor}
+\usepackage{subcaption}
 \usepackage[strings]{underscore}
 
 \usepackage[letterspace=150]{microtype}
-\usepackage[onehalfspacing]{setspace}
+
 \usepackage[page]{totalcount}
 \usepackage[automark,headsepline=.4pt,plainheadsepline]{scrlayer-scrpage}         % Erstellung von selbst definierten Kopfzeilen
+%\usepackage{scrhack}
+
+\newcommand{\source}[1]{\caption*{Quelle: {#1}} }
+
 \clearpairofpagestyles%\clearscrheadfoot veraltet
 \renewcommand*{\chaptermarkformat}{
   \chaptername~\thechapter\autodot\quad-\quad
 }
+\definecolor{light-gray}{gray}{0.95}
+%\newcommand{\code}[1]{\colorbox{light-gray}{\texttt{#1}}}
+\newcommand{\code}[1]{
+  \begingroup%
+  \sethlcolor{light-gray}%
+  \hl{\texttt{#1}}%
+  \endgroup
+}
 
 \ihead*{\rightmark}
 \ohead*{\thepage}
@@ -61,7 +76,6 @@ parskip=half,
   long=Mensch-Roboter-Kollaboration,
 }
 
-
 \begin{document}
 
 \setcounter{page}{1}
@@ -69,524 +83,33 @@ parskip=half,
 
 \begin{titlepage}
 
-\includepdf[pages=-]{Deckblatt.pdf}
+\includepdf[pages=-]{tex/Deckblatt.pdf}
 
 \end{titlepage}
 
 \tableofcontents
+\listoffigures
 
-\includepdf[pages=-]{Aufgabenstellung.pdf}
+\includepdf[pages=-]{tex/Aufgabenstellung.pdf}
 
 \setcounter{page}{1}
 \pagenumbering{arabic}
 
-
-\chapter{Einleitung}
-\section{Motivation}
-Das Feld der Mensch-Roboter-Kollaboration entwickelt sich mit zunehmender Geschwindigkeit fort.
-Viele Unternehmen bieten neue Lösungen für die unterschiedlichsten Einsatzszenarien der Endanwender.
-
-Dabei ist eine Prüfung des Anwendungsfalls sinnvoll, um etwaige Probleme der Interaktion früh erkennen und beheben zu können.
-Diese Prüfung kann durch eine Simulation, in welcher der konkrete Anwendungsfall abgebildet wird, vereinfacht werden.
-
-Außerdem bietet eine Simulation die Möglichkeit, die Aufgabe des Roboters, ohne dessen Anschaffung, evaluieren zu können.
-Das so gefertigte Modell des Anwendungsfalls könnte später auch als Grundlage für einen digitalen Zwilling dienen.
-Dieser kann später zur Wartung und Fehlerdiagnose des Systems dienen.
-
--MRK häufiger ein Thema
--Anwendungsfälle sollen evaluiert werden
--Erprobung von Szenarien ohne Roboter
-
-->Simulation eine kompletten Szenarios mit Roboter und Mensch
-\section{Stand der Wissenschaft}
-Aktuelle Arbeiten:
-
--Planung von Interaktionen
-
--Parametervergleiche von maschinellen und menschlichen Bewegungen
-
--Vermeidung von Kollisionen und Strategie
-
--Steuerung von Robotern mit Behavior Trees
-
--> Keine allgemeine Simulation einen gesamten Szenarios mit Mensch.
-
-\url{https://www.sciencedirect.com/science/article/pii/S2351978918311442}
-\url{https://www.researchgate.net/publication/319888916_Interactive_Simulation_of_Human-robot_Collaboration_Using_a_Force_Feedback_Device}
-\url{https://elib.dlr.de/120687/1/human_motion_projection.pdf}
-\url{https://www.researchgate.net/publication/220065749_Human-Robot_Collaboration_a_Survey}
-
-\section{Welche Szenarien}
-Die drei Szenarien sollten so gewählt werden, dass vorher genutzte Bestandteile in späteren, komplexeren Szenarien weiter genutzt werden können.
-Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Manipulation von Objekten, besonders in Frage, da diese viele ähnliche Bestandteile haben, jedoch mehrere Szenarien denkbar sind.
-
-Das erste abgebildete Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe handeln, in welcher ein Roboter im Arbeitsbereich eines Menschen Teile fertigt.
-Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit bei Annäherung des Menschen.
-
-Bei dem zweiten Szenario soll der Roboter Teile sortieren und auf ein Fließband legen, falls diese weiter genutzt werden können.
-Der Mensch muss nun nur noch den Ausschuss beseitigen, welcher vom Roboter in eine besondere Zone gelegt wird.
-
-Die dritte simulierte Aufgabe stellt ein Colaborationsszenario dar, in welchem Mensch und Roboter an der selben Aufgabe arbeiten.
-Hierbei soll eine Palette entladen werden, wobei der Roboter nicht jedes Objekt ausreichend manipulieren kann.
-In diesen Fällen muss nun ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
-\section{Welcher Nutzen / Contributions}
-- Erkennen von konzeptionellen Problemen vor Ersteinsatz
-
-- Definition von Interaktion mit einfacheren Strukturen als State-Machines
-\chapter{Konzept}
-Die zu entwickelnde Simulation soll die bisher meißt separaten Zweige der Roboter- und Menschensimulation verbinden.
-Um die beiden Akteuren in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
-Diese Befehle werden dabei von externer Software unter der Verwendung von Behavior Trees und Feedback aus der Simulation generiert.
-
-Die zu erarbeitende Softwareumgebung soll einfach erweiterbar sein, um weitere Modifikationen und die Umsetzung anderer Projekte zuzulassen.
-Hierzu zählt die Austauschbarkeit und Erweiterbarkeit von Komponenten wie der simulierten Welt, dem Roboter oder dem simulierten Mensch.
-Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufgebaut.
-
-\begin{figure}[]
-\includegraphics[]{Konzept_Overview}
-\centering
-\caption{Visualisierung des Konzepts}
-\label{concept_overview}
-\end{figure}
-
-\section{Simulation des Roboters}
-Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
-Außerdem ist die enge Interaktion mit Menschen interessant, was einen für Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
-Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, welcher als Cobot vermarktet wird.
-Cobot ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für MRK-Szenarien noch einmal unterstreicht.
-Er besitzt auch 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.
-Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut wiederspiegeln.
-Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
-
-\section{Simulation des Menschen}
-Der Mensch soll in der Simulation typische Aufgaben erledigen und häufiges Verhalten abbilden können.
-Hierzu werden Animationen verwendet, welche die aktuelle Tätigkeit darstellen.
-Für komplexere Verhaltensweisen können Animationen und andere Aktionen, wie zum Beispiel eine Bewegung und Rotation kombiniert werden, um zum Beispiel die Aktion ``laufen'' auszuführen.
-
-Auch hier wird ein Modell der Person für die Simulation benötigt.
-Außerdem werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.
-Hinzu kommt noch eine Komponente, welche diese Animationen und andere Parameter von außen entgegennehmen kann, um sie in der Simulation ausführen zu können.
-Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Aktionen im Fortschritt überwacht und abgebrochen werden können.
-
-\section{Behavior Trees}
-Häufig wird Verhalten in State-Machines ausgedrückt, welche jedoch einige Nachteile besitzen.
-State-Machines werden ab einer gewissen Größe schnell unübersichtlich.
-Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, welche jedoch essentiell für den Betrieb einer Maschine sind.
-Um diese Probleme zu adressieren, entstand das Konzept der Behavior Trees.
-
-Ein Behavior Tree ist eine Struktur, um Verhalten als ein Baum zu beschreiben.
-Der Ablauf startet vom sogenannten Root, der Wurzel des Baums.
-Von dort an werden sogenannte Nodes, welche je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
-Die Nodes werden untereinander angeordnet, welches die Relation der Nodes zueinander beschreibt.
-Jede Node hat dabei entweder die Root-Node oder eine andere Node über ihr im Baum und eine beliebige Anzahl an Nodes unter sich.
-Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
-\begin{description}
- \item[Aktions-Nodes]
-  beschreiben einzelne ausführbare Aktionen. Mit Hilfe von Parametern kann ihr Verhalten von anderen Nodes beeinflusst werden.
- \item[Dekorations-Nodes]
-  können den Rückgabewert einer anderen Node modifizieren. Häufig existieren hier Negation, garantierter Erfolg und garantierter Fehler.
- \item[Sequenz-Nodes]
-  beschreiben eine nacheinander ausgeführte Abfolge von anderen Nodes, welche mit spezifischen Randbedingungen weiter fortschreitet.
- \item[Fallback-Nodes]
-  werden verwendet, um Verhalten zu definieren, welches nur bei Fehlern in vorherigen Nodes ausgeführt wird.
-\end{description}
-
-In dieser Arbeit sollen BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
-Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, welche in dieser Arbeit bearbeitet werden, abzudecken.
-
-\chapter{Komponenten-/Softwareauswahl}
-\section{Dienstumgebung (ROS2)}
-\subsection{Auswahl}
-Durch eine Dienstumgebung werden häufig benötigte Funktionen bereitgestellt, welche in Programmen genutzt werden können.
-Dabei ist es irrelevant, ob diese für simulierte, aber auch echte Hardware, genutzt werden.
-Bei einer Dienstumgebung für Roboter gehören zu den grundlegendn Aspekten die Nachrichtenübergabe zwischen einzelen interagierenden Programmen, um eine gemeinsame Basis für ein einfach erweiterbares System zu schaffen.
-
-In diesem Bereich sticht ROS als Dienstumgebung für Roboter hervor, da es sich um ein etabliertes, quelloffenes und häufig verwendetes System handelt.
-Es bietet die oben genannten Aspekte und einige weitere Verbesserungen, welche später näher beleuchtet werden.
-Die neuste Version ROS2 bietet dabei einige Verbesserungen im Vergleich zu früheren Version ROS1.
-Ein neues Nachrichtenformat mit Quality of Service kann zum Beispiel Nachrichten vorhalten und über sowohl TCP als auch UDP kommunizieren.
-Außerdem werden nun neben CMake auch andere Buildsysteme unterstützt, unter anderem auch Python.
-
-Generell existieren im Feld der Roboter-Dienstumgebungen keine Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite, jedoch sind andere Systeme mit anderen Nachrichtenformaten denkbar.
-Vor allem die unzähligen ROS-Bibliotheken, welche von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
-
--Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
--ROS2
--Andere (nur) Messagingsysteme
--LCM
--ZeroMQ
-\subsection{Beschreibung}
-ROS2\cite{doi:10.1126/scirobotics.abm6074}, später auch einfach nur ROS genannt, beschreibt sich selbst als ``a meta operating system for robots''\cite{ros-git}.
-Hierbei ist ``operating system'' nicht in seiner herkömmlichen Bedeutung eines vollständigen Betriebssystems zu verstehen.
-Es handelt sich dabei um eine gemeinsame Grundlage für Programme und Daten, welche durch ROS bereitgestellt wird.
-
-Einzelne Bestandteile in der Umgebung sind dabei in Pakete gegliedert.
-Ein Paket kann beliebig viele Daten und Programme beinhalten, welche in zwei Dateien beschrieben werden.
-In CMakeLists.txt befinden sich Buildinstruktionen für den Compiler, falls sich Programme im Paket befinden.
-Außerdem können bestimmte Pfade aus dem Paket exportiert werden, sodass diese später im Workspace verfügbar sind.
-Programme, welche mit anderen Programmen in der Umgebung interagieren, werden in ROS ``Nodes'' genannt.
-
-Zu den Aufgaben von ROS gehören dabei:
-\begin{description}
- \item[Buildumgebung]\hfill \\
-  ROS benutzt colcon \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
-  Hierfür werden CMake und einige Erweiterungen, wie z.B. ament\_cmake eingesetzt.
-
- \item[Workspaceverwaltung]\hfill \\
-  Pakete können in verschiedenen Verzeichnissen installiert werden und müssen für andere Pakete auffindbar sein.
-  ROS nutzt hierfür von colcon generierte Skripte, welche beim Erstellen eines Pakets und eines Workspaces mit angelegt werden.
-  Das Skript des Pakets fügt nur dieses Paket der Umgebung hinzu, das Skript des Workspaces führt alle Skripte der enthaltenen Pakete aus, um diese der Umgebung hinzuzufügen.
-
- \item[Abhängigkeitsverwaltung]\hfill \\
-  ROS kann durch die in den Paketen deklarierten Abhängigkeiten prüfen, ob diese in der aktuellen Umgebung verfügbar sind.
-  Dies vermeidet Abstürze und undefiniertes Verhalten in der Ausführung von Nodes.
-
- \item[Datenübertragung]\hfill \\
-  Nodes müssen miteinander auf einem festgelegten Weg kommunizieren können, um beliebige Verbindungen dieser zu unterstützen.
-  Dieser wird durch ROS in Form mehrerer Bibliotheken für unterschiedliche Sprachen bereitgestellt.
-
- \item[Parameterübergabe]\hfill \\
-  Nodes benötigen häufig problemspezifische Konfiguration, um in vorher nicht bedachten Szenarien eingesetzt werden zu können.
-  ROS stellt diese durch deklarierfähige und integrierte Argumente bereit.
-
- \item[Startverwaltung]\hfill \\
-  In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
-\end{description}
-
-
-\section{Simulationsumgebung (Gazebo)}
-\subsection{Auswahl}
-Als Simulationsumgebung können verschiedene Programme genutzt werden, welche sich in ihrem Funktionsumfang stak unterscheiden.
-Hierfür kommen dedizierte Werkzeuge zur Robotersimulation, aber auch zum Beispiel universell einsetzbare Gameengines in Frage.
-Diese Werkzeuge müssen hierfür auf ihre Tauglichkeit für die gesetzte Aufgabe geprüft werden.
-Auch andere Aspekte sind hierbei zu betrachten, wie Lizenzen oder schwer bewertbare Aspekte wie Nutzerfreundlichkeit.
-Für die Auswahl kommen verschiedene Prgramme in Frage, welche im folgenden weiter beleuchtet werden.
-
-CoppeliaSim, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
-Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
-Der Simulator selbst unterstützt Menschliche Aktoren, jedoch können diese nur Animationen abspielen oder zusammen mit Bewegungen abspielen.
-CoppeliaSim existiert in 3 Versionen, welche sich im Funktionsumfang unterscheiden, jedoch hat nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
-
-Gazebo Ignition ist wie CoppeliaSim eine Robotersimulationsumgebung, jedoch ohne integrierten Editor und direkte ROS-Unterstützung.
-Gazebo setzt wie CoppeliaSim auf Erweiterungen, welche die gewünschten Funktionen einbinden können.
-Zum Beispiel existiert auch eine ROS-Brücke, welche die Anbindung an ROS ermöglicht.
-Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
-Das Projekt ist Open Source, unter der Apache Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
-
-Unity hingegen ist primär eine Grafikengine für Nutzung in Computerspielen.
-Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
-Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
-Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteigerbereich zurückzuführen ist.
-Auch die Optionen zur Menschensimulation sind gut, da diese häufig in Spielen verwendet werden.
-Ein großer Nachteil hingegen ist die Lizenz, welche nur für Einzelpersonen kostenlos ist.
-
-Die Unreal Engine ist wie Unity eine Grafikengine aus dem Spielebereich.
-Auch hier ist die Menschensimulation aufgrund oben genannter Gründe gut möglich.
-Jedoch existiert für Unreal Engine keine offizielle Lösung zur Anbindung an ROS2.
-Die Programmierung der Engine erfolgt in C++, was einer Drittlösung erlaubte, eine ROS-Anbindung für Unreal Engine zu erstellen.
-Die Lizenz der Unreal Engine erlaubt die kostenfreie Nutzung bis zu einem gewissen Umsatz mit der erstellten Software.
-
-Eine weitere Möglichkeit zur Simulation stellt die Grafikengine Godot dar.
-Im Vergleich zu Unity und Unreal Engine ist Godot quelloffene Software unter der MIT-Lizenz.
-Auch hier stellt die Simulation von menschlichen Aktoren eine Standartaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
-Auch für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht offiziell.
-
-Jede der drei Gameengines besitzt ein integriertes Physiksystem, welches die Simulation von starren Körpern und Gelenken erlaubt.
-Aus diesen Funktionen könnte ein Roboterarm aufgebaut werden, welcher dann durch eine der ROS-Brücken der Engines gesteuert werden kann.
-
-Die Wahl der Simulationsumgebung fiel auf Gazebo Ignition, da dieser Simulator bereits im ROS-Framework etabliert ist.
-Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschidlichsten Szenarien.
-
-\subsection{Robotersimulation}
-Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Siimulationsumgebung beschrieben wird.
-Gazebo nutzt hierfür .srdf-Dateien, welche auf xml basieren.
-In diesen werden die einzelnen Glieder des Arms und die verbindenden Gelenke beschrieben.
-
-Jedes Glied des Modells besitzt eine Masse, einen Masseschwerpunkt und eine Trägheitsmatrix für die Physiksimulation in Gazebo.
-Außerdem werden Modelle für die visuelle Repräsentation in Gazebo und die Kollisionserkennung in der Physiksimulation hinterlegt.
-Für beide existieren einfache Modelle wie Zylinder, Boxen und Kugeln.
-Da diese Formen nicht jeden Anwendungsfall abdecken und in der visuellen Repräsentation nicht ausreichen, können auch eigene Modelle hinterlegt werden.
-
-Gelenke werden separat von den Gliedern definiert und verbinden jeweils zwei Glieder miteinander.
-Durch das Aneinanderreihen von mehreren Gliedern und Gelenken kann so jeder Roboteraufbau beschrieben werden.
-Jedes Gelenk besitzt eine Position und Rotation im Raum, um dessen Effekte je nach Typ des Gelenks berechnen zu können.
-Aspekte wie Reibung und Dämpfung können auch für die Physiksimulation angegeben werden.
-Folgende Typen von Gelenken können in urdf genutzt werden:
-\begin{description}
- \item[freie Gelenke]
-  ermöglichen vollständige Bewegung in allen 6 Freiheitsgraden. Sie stellen den normalen Zustand der Gelenke zueinander dar.
- \item[planare Gelenke]
-  erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden für zum Beispiel Bodenkollisionen eingesetzt.
- \item[feste Gelenke]
-  sperren alle 6 Freiheitsgrade und werden häufig zur Plazierung von Objekten in einer Szene genutzt.
- \item[kontinuierliche Gelenke]
-  erlauben die beliebige Rotation um die Achse des Gelenks. Sie sind nur selten in rotierenden Gelenken mit Schleifkontakten zu finden.
- \item[drehbare Gelenke]
-  verhalten sich wie kontinuerliche Verbindungen, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
- \item[prismatische Gelenke]
-  ermöglichen die Bewegung entlang der Achse des Gelenks. Denkbare Anwendungsfälle sind simulierte lineare Aktuatoren.
-\end{description}
-\subsection{Menschensimulation}
-Gazebo besitzt bereits ein einfaches Animationssystem für bewegliche Aktoren, welches auch für Menschen nutzbar ist.
-Es existiert bereits ein Modell eines Menschen mit mehreren Animationen, welche allein abgespielt, oder an Bewegungen gekoppelt werden können.
-Dadurch ist eine Laufanimation realisierbar, welche synchronisiert zur Bewegung abgespielt wird.
-
-Jedoch ist dies nur unter der Bedingung möglich, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
-Dies ist auf die Definition der Pfade, welche die Bewegung auslösen, zurückzuführen.
-Diese können nur in der .sdf-Datei des Aktoren definiert werden, was Veränderungen zur Laufzeit ausschließt.
-Durch diesen Umstand ist der mögliche Simulationsumfang nicht ausreichend.
-
-Um diesen Umstand zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
-Dieses System muss, wie im Konzept beschrieben, Steuerbefehle von außen empfangen, umsetzen und Feedback liefern können.
-
-\section{Roboterumgebung (MoveIt2)}
-MoveIt2 ist das empfohlene ROS2 Paket für Bewegungsplanung von Robotern.
-Das System besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
-Der Nutzer kann mit MoveIt auf mehreren Wegen Steuerbefehle für den Roboter absenden.
-
-Die einfachste Art der Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files, welche durch den Setupassistenten für den Roboter generiert werden.
-Dort können Bewegungen durch das Bewegen von Markierungen oder  in der Simulation geplant und ausgeführt werden.
-
-Da sich ein solches System nur beschränkt zur Automatisierung durch Software eignet, existieren auch noch andere Schnitstellen.
-Für die Sprache Python existierte früher noch das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, welches aber aktuell noch nicht portiert wurde. \cite{moveitpython}
-Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt auf einer abstrakteren Ebene zu interagieren.
-Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, was jedoch Erfahrung mit den verwendeten Datenstrukturen benötigt.
-
-Durch diese Schnittstelle erhält die sogenannte MoveGroup ihre Informationen über die gewünschte Bewegung.
-Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, welche sich um den Roboter befinden.
-Eine solche Erweiterung erlaubt die Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
-
-Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, welcher durch die MoveGroup aufgerufen wird.
-Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an ros_control weitergegeben.
-Dabei können sowohl echte Hardwaretreiber, aber auch simulierte Roboter genutzt werden.
-Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
-
-Im Falle von Gazebo wird ign_ros_control genutzt, welches die benötigten ros_control Controller in die Simulation einbindet.
-Diese können dann wie normale Controller von ros_control genutzt werden.
-
-Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
-
-\chapter{Umsetzung}
-
-\section{Grundlegender Systemaufbau}
-Der grundlegende Systemaufbau musste stark modifiziert werden, wie in Abbildung \ref{umsetzung_overview} zu sehen, um die gesetzten Aufgaben erfüllen zu können.
-Dabei fallen vor allem die überarbeitete Kommunikation mit dem simulierten Menschen und die komplexere Steuerung des Roboterarms auf.
-
-Die komplexere Steuerung des Roboters ist auf die Struktur von MoveIt zurückzuführen, welches in viele einzelne Teilmodule aufgeteilt ist.
-Diese müssen durch ihren modularen Aufbau, welcher für die Vielseitigkeit verantwortlich ist, einzeln konfiguriert werden, um miteinander in Interaktion treten zu können.
-
-Außerdem musste die Kommunikation des Modells des Menschen überarbeitet werden, da die ROS-Kommunikation in Gazebo nur mit Einschränkungen möglich ist.
-
-\begin{figure}[]
-\includegraphics[width=\textwidth]{Umsetzung_Overview}
-\centering
-\caption{Visualisierung des überarbeiteten Konzepts}
-\label{umsetzung_overview}
-\end{figure}
-
--BehaviorTree -> ActorPluginServer -> ActorPluginServer
-
--BehaviorTree -> MoveIt -> ros\_control -> Gazebo
-\section{Mensch}
-\subsection{Übersicht (Diagramme)}
-Das angepasste Verfahren zur Menschensteuerung in der Simulation verwendet mehrere Kommunikationswege.
-Als erstes wird eine Bewegungs- oder Animationsanfrage an den ROS-Action-Server im ActorServer gesendet.
-Wenn die Simulation aktuell keinen Befehl ausführt, wird diese Anfrage akzeptiert, ansonsten wird sie abgebrochen.
-Daraufhin werden die Daten der Anfrage über eine Posix-Message-Queue vom ActorServer an das ActorPlugin in Gazebo gesendet.
-
-Dieses verwendet die Daten, um eine interne State-Machine in den entsprechenden Zustand zu setzen, welcher zur Ausführung des Befehls benötigt wird.
-
-Um Feedback an den Client des ROS-Action-Servers übertragen zu können, werden bei der Ausführung von Befehlen oder Zustandswechseln des ActorPlugins Feedbackdaten über eine separate MessageQueue zurück an den ActorServer übertragen.
-Diese werden durch den ActorServer aufbereitet, da nicht alle Daten für die jeweilige laufende Aktion relevant sind und an den ROS-Action-Client gesendet.
-
-Um diese Befehle in der Simulation auch visuell umsetzen zu können, werden weitere Animationen für das Modell des Menschen benötigt, welche im Kontext der zur erfüllenden Aufgabe relevant sind.
-Dafür muss dan Modell in einen animierbaren Zustand gebracht werden, in welchem dann weitere Animationen erstellt und in die Simulation eingebunden werden können.
-\subsection{Modellierung}
--Rerigging des Actor-Modells
--Animation in eigenem Rig
--Konflikte durch 'verschiedene' Rigs in Animationen
--Erstellung eines neuen Rigify-Rigs
--Erneutes Erstellen von Animationen
--Disconnect Bones in Rig
--Flatten Hierarchy
-\subsection{Programmierung}
-\subsubsection{Message Queue}
-Bei der Implementierung des ActorPlugins stellte sich heraus, dass die nun im ActorServer ausgelagerten Befehle mit den Befehlen im ros_control-Plugin kollidieren.
-Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS, verwenden.
-
-In dieser Bibliothek wird eine globale Instanz angelegt, welche den Zustand des Kommunikationsprotokolls abbildet.
-Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zur Problemen, da kein Synchronisationsmechanismus existiert.
-Die dadurch entstehenden gleichzeitigen Zugriffe auf die selben Ressourcen führen zur Terminierung des Programms.
-
-Eine Anpassung beider Plugins auf die gemeinsame Nutzung einer Ressource ist möglich, erfordert jedoch weitere Anpassungen, welche zeitlich nur schwer planbar sind.
-Die Nutzung eines separaten Dienstes, welcher keinen globalen Kontext benötigt, ist die sicherste Lösung des Problems.
-Durch einen solchen Dienst werden auch in Zukunft keine Plugins gestört, auch wenn sie selbigen Dienst zur Kommunikation verwenden.
-
-Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschielichen Möglichkeiten getroffen.
-Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die Sockets unterstützt, hat jedoch keinen einheitlichen Feedbackmechanismus.
-Die neueren Websockets bieten die Möglichkeit, bidirektional Daten zu übertragen und erlauben somit Feedback an das aufrufende Programm.
-Beide Technologien basieren jedoch auf einem Webserver, welcher auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Serveices ermöglicht.
-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 Terchnologien durch TCP oder UDP und HTTP relativ großen Protokolloverhead, welcher 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.
-Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den Speicher zugreifen können.
-Alle Zugriffe auf den Bereich sind extrem schnell, was diese Technik ideal zur schnellen Datenübertragung zwischen Prozessen macht.
-Durch das erlauben gleichzeitiger Zugriffe kann es hierbei vorkommen, dass die selbe Adresse gleichzeitig von einem Programm gelesen und von einem anderen geschrieben wird.
-Die dabei gelesenen Daten können Schäden aufweisen, weswegen Zugriffe auf den Speicherbereich koordiniert werden müssen.
-
-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.
-Dieser Bereich besitzt ein Identifikationsmerkmal, mit welchem Anwendungen Zugriff auf diesen erlangen können.
-Ein Programm kann in diesem Bereich Nachrichten ablegen, welche durch das andere Programm gelesen werden können.
-Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, aussschließt.
-Hierdurch kommt es zu einem Anstieg an Latenzzeit, jedoch ist dieser ausreichend gering.
-
-Die Wahl des Dienstes fiel auf eine MessageQueue, jedoch existieren unter Linux 2 unabhängige Implementationen.
-Die erste Implementation ist die System V MessageQueue, und verwendet zur Identifikation einfache Integer.
-Eine Spezialität dieser alten Implementation ist das Sortieren der Nachrichten nach Nachrichtentyp in der gleichen Warteschlange.
-Die neuere Implementation der POSIX MessageQueue bietet einige weitere Funktionen, wie zum Beispiel aynchrone Benachrichtigungen bei neuen Nachrichten, Quality of Service und nutzt bis zu 256 Zeichen lange Strings 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 verbessert wurde.
-\subsubsection{ROS-Server}
--Transformieren von ROS2 action server in Message Queue
-
--Eigene state machine
-\subsubsection{Gazebo Plugin}
--Relativ einfache Implementation
-
--Reagiert nur auf Nachrichten, kein Konzept der gesamten Abfolge
-\section{Roboter}
-\subsection{Übersicht (Diagramme)}
-\subsection{Modellierung}
-Erstellung der Robotermodelle aus Herstellerdaten
-
-Kollision und Visualisierung
-\subsection{Details}
-\chapter{Szenarienbasierte Evaluation}
-\section{Simulation des Menschen}
--Animationen und Bewegungen funktionieren
-
--Kollisionen möglich, aber mit Animationen schwer zu synchronisieren
-\section{Bewegung des Roboters}
--Roboter kann sich bewegen
-
--Kollisionen verfügbar
-
--Interaktion technisch möglich, nicht implementiert. (Kooperation MoveIt/Gazebo nötig)
-\section{BehaviorTrees}
-\subsection{Nodes}
--Nodes für implementierte Funktionen verfügbar
-
--Einige andere, technisch relevante Nodes auch implementiert
-\subsection{Kombinieren von Nodes zu einer Request}
--MoveIt Planung benötigt mehrere Parameter, sollen aber in einzelnen Nodes gesetzt werden
-
--Kombination nötig, Beschreibung hier
-\chapter{Diskussion}
-\section{Lessons Learned bei der Umsetzung}
--Viele kleine Unannehmlichkeiten, kombiniert ein großes Problemen
-
--Dokumentation für spätere Projekte
-\subsection{Erstellung des Robotermodells}
--Keine direkten technischen Daten zum Roboter von Kuka
-
--Nur CAD-Dateien der Außenhülle
-
--Schätzung von Spezifikationen anhand Marketingmaterial
-\subsection{Gazebo}
-\subsubsection{Upgrade auf Ignition}
-Gazebo ist zu diesem Zeitpunkt in mehreren, teilweise gleichnamigen Versionen verfügbar, welche sich jedoch grundlegend unterscheiden.
-Ein altes Projekt mit dem früheren Namen Gazebo, welches nun in Gazebo Classic umbenannt wurde,
-die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
-die nächste Version, welche nur noch den Namen Gazebo tragen soll.
-Dies ist darauf zurückzuführen, dass Gazebo Classic und Ignition eine Zeit lang gleichzeitig existierten, jedoch unterschiedliche Funktionen und interne Schnittstellen besitzen.
-
-Das Upgrade von Gazebo Classic auf Gazebo Ignition gestaltete sich aus mehreren Gründen schwierig.
-Dies ist am leichtesten an der geänderten Nutzeroberfläche sichtbar, welche in Ignition nun modular ausgeführt ist.
-Um dieses neue modulare System nutzen zu können, wurde das Dateiformat für die Simulationen angepasst.
-In diesem werden die benötigten Physikparameter, Nutzeroberflächen, Plugins und die Simulationswelt definiert.
-
-Um alte Simulationsdateien zu migieren, empfiehlt sich die Erstellung einer neuen, leeren Welt in Gazebo Ignition,
-sodass alle benötigten Physik, Nuteroberflächen und Pluginreferenzen erstellt werden.
-Danach kann die Welt Stück für Stück in das neue Format übertragen werden, wobei nach jedem Eintrag ein Test zur Funktionsfähigkeit gemacht werden sollte, da sich bestimmte Parameterdeklarationen geändert haben.
-Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler während des Ladevorgangs im Log nicht weiter beschrieben werden.
-
-Auch das alte Plugin musste auf das neue System angepasst werden, was auch hier zu einer kompletten Neuimplementation führte, da die internen Systeme zu große Unterschiede aufwiesen.
-Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, welche auf ein Entity-Component-System umstellte, aber auch sahlreiche kleinere Änderungen
-\subsubsection{Pluginarchitektur}
--Plugins werden im selben Kontext geladen, verwendung von Librarys mit globalem Kontext schwer
-\subsubsection{Doppelte Messagedienste}
--Duplizierung von Messagediensten in ROS und Gazebo
-
--Potentielle Lösung in einer Präsentation angekündigt (mal sehen, ob ich die wiederfinde)
-\subsubsection{Fehlende Animationsgrundlagen}
--Animationen werden als .col bereitgestellt
-
--Enthalten Textur, Mesh und Bones, jedoch nicht verbunden -> schlecht für Animation
-\subsection{ROS2}
-\subsubsection{Nachrichten und deren Echtzeitfähigkeit}
--TCP und UDP verfügbar, jedoch nicht sofort kompatibel
-\subsubsection{Änderung der Compilertoolchain}
--Änderung des Buildsystems von rosbuild auf catkin
-
--Benötigte Änderungen in CMakeFile und package
-\subsection{MoveIt2}
-\subsubsection{Upgrade auf MoveIt2}
--Unterschiede in der Deklaration des Roboters selbst
-
--Änderungen der Deklaration der ros\_control Anbindung
-
--Vorerst kein Setup, manuelle Migration erforderlich
-
-->Lesson learned: Projekte häufig auf Updates prüfen
-\subsubsection{Fehlerhafte Generierung der Roboter}
--Einige Aspekte der Generierung nicht erforderlich oder falsch
-\subsubsection{Controller}
--Controller benötigte Anpassungen und manuelle Tests
-\section{Lessons Learned bei den Szenarien}
-\subsection{Debugging}
--async tty Option
-
--gdb ist ein Muss
-
--``Aufhängen'' von trees
-\chapter{Zusammenfassung und Ausblick}
-\section{Ergebnisse}
-\subsection{Graphische Repräsentation der Szenarien}
--Szenarien graphisch abgebildet
-\subsection{Anpassung der Behavior Trees an Szenarien}
--Trees angepasst
-\section{Diskussion}
--Viele Iterationen benötigt
-
--Funktionstüchtige Simulation der Szenarien
-
--Bewegung der Objekte schwerer als gedacht
-
--Synchronisationsmechanismus Gazebo <-> MoveIt benötigt
-\section{Ausblick}
-\subsection{Umsetzung in anderem Simulator}
--Einfachere ROS Anbindung
--Potentiell einfacher ausbaubar auf Basis einer erweiterbaren Gameengine
--Mangelhafte Dokumentation von Gazebo
-\subsection{Simulation bewegter Objekte}
--Aufgrund von Komplexität des Prozesses nicht integriert
-\subsection{Ergänzung von Umgebungserkennung}
--MoveIt hat Unterstützung
-
--Daten aus Gazebo extrahieren und in MoveIt einbinden
-
--Person in OctoMap erkennen
+\input{tex/1_Einleitung.tex}
+\input{tex/2_Konzept.tex}
+\input{tex/3_Auswahl.tex}
+\input{tex/4_Umsetzung.tex}
+\input{tex/5_Evaluation_und_Diskussion.tex}
+\input{tex/6_Ausblick.tex}
 
 \printbibliography
+\newpage
 \markboth{Anhang}{Anhang}
-\begin{figure}[h]
-\includegraphics[width=14cm]{moveit_pipeline}
-\caption{Visualisierung der MoveIt Pipeline\cite{moveitpipeline}}
+\begin{figure}[ht]
+\includegraphics[width=14cm]{img/moveit_pipeline}
+\caption{Visualisierung der MoveIt Pipeline}
+\source{\cite{moveitpipeline}}
 \label{moveitpipeline}
 \end{figure}
+
 \end{document}          

mechforsch.kilepr

@@ -35,3 +35,39 @@ archive=true
 encoding=
 highlight=
 mode=
+
+[item:tex/1_Einleitung.tex]
+archive=true
+encoding=UTF-8
+highlight=LaTeX
+mode=LaTeX
+
+[item:tex/2_Konzept.tex]
+archive=true
+encoding=UTF-8
+highlight=LaTeX
+mode=LaTeX
+
+[item:tex/3_Auswahl.tex]
+archive=true
+encoding=UTF-8
+highlight=LaTeX
+mode=LaTeX
+
+[item:tex/4_Umsetzung.tex]
+archive=true
+encoding=UTF-8
+highlight=LaTeX
+mode=LaTeX
+
+[item:tex/5_Evaluation_und_Diskussion.tex]
+archive=true
+encoding=UTF-8
+highlight=LaTeX
+mode=LaTeX
+
+[item:tex/6_Ausblick.tex]
+archive=true
+encoding=UTF-8
+highlight=LaTeX
+mode=LaTeX

tex/1_Einleitung.tex

@@ -0,0 +1,69 @@
+\chapter{Einleitung}
+\section{Motivation}
+Die Simulation von Maschinen wird im industriellen Umfeld immer beliebter, um deren Verhalten schon vor der eigentlichen Produktion zu testen.
+Dazu wird ein Modell des gesamten Prozesses in der Simulation geschaffen, der durch die Maschine beeinflusst werden soll.
+Das Modell wird um die Maschine selbst erweitert, die Einfluss auf das System nimmt.
+Die Veränderungen durch die Maschine werden analysiert, und erlauben Rückschlüsse auf die Funktion des Systems.
+Ein solches Modell kann für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
+
+Da in der Realität oftmals Menschen und Maschinen im gleichen Umfeld mit- oder auch zusammenarbeiten, ist es sinnvoll, die Menschen in die Simulation einzubeziehen.
+
+Im wachsenden Feld der Mensch-Roboter-Kollaboration existieren bereits einige Lösungen, um auch die namensgebende Interaktion von Mensch und Roboter zu simulieren.
+Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf in der Simulation bereits vor deren Ausführung fest definiert werden muss.
+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ä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.
+
+\section{Stand der Wissenschaft}
+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}.
+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}.
+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}.
+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}.
+
+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 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.
+
+Das erste Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe befassen, in der ein Roboter im Arbeitsbereich eines Menschen Teile fertigt.
+Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit des Roboters bei Annäherung des Menschen, um Kollisionen zu vermeiden.
+Der Mensch soll in diesem Szenario an einer anderen Aufgabe arbeiten.
+Während dieser Arbeit betritt der Mensch vereinzelt den Arbeitsbereich des Roboters, was die entsprechende Reaktion des Roboters hervorrufen soll.
+
+Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide im selben Raum, jedoch an unterschiedlichen Aufgaben arbeiten.
+Außerdem werden grundlegende Aspekte der Simulation getestet, wie zum Beispiel das Bewegen von Mensch und Roboter und die sicherheitsrelevante Aktion der Geschwindigkeitsanpassung.
+
+Im zweiten Szenario prüft und sortiert der Roboter Teile und legt die fehlerfreien Exemplare auf einem Fließband zur Weiterverarbeitung ab.
+Die Mängelexemplare werden hingegen in einer dafür vorgesehenen Zone abgelegt, von wo sie vom Menschen abtransportiert werden.
+Auch hier soll der Mensch so lange eigenständig arbeiten, bis der Roboter ein aussortiertes Teil ablegt, das transportiert werden muss.
+
+Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in dem Mensch und Roboter an derselben Aufgabe arbeiten.
+Hierbei soll der Roboter eine Palette entladen, wobei er nicht jedes Objekt ausreichend manipulieren kann.
+Dies wird durch zufällige Fehler beim Aufheben, Transport und Ablegen der Objekte abgebildet.
+In diesen Fällen muss ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
+Der Mensch soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren, was durch das Laufen im Raum abgebildet werden soll.
+\section{Contributions}
+Durch diese Arbeit soll in zukünftigen Projekten die Möglichkeit geschaffen werden, konzeptionelle Probleme bei der Erstellung neuer Aufgabenbereiche eines Roboters frühzeitig durch Simulation erkennbar zu machen.
+
+Dazu ist eine schnelle Adaption von sowohl Roboter als auch Mensch auf unterschiedliche Szenarien nötig.
+Die Szenarien sollen dabei durch eine Beschreibungssprache definiert werden.
+Durch deren Struktur soll komplexes Verhalten einfach und überschaubar abbildbar sein, dass dann in der Simulation getestet werden kann.

tex/2_Konzept.tex

@@ -0,0 +1,152 @@
+\chapter{Konzept}
+Die zu entwickelnde Simulation soll die bisher meist separaten Zweige der Roboter- und Menschensimulation verbinden.
+Um die beiden Akteure in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
+Diese Befehle werden dabei von externer Software unter der Verwendung einer Beschreibungssprache und Feedback aus der Simulation generiert.
+
+Hierfür wird die Beschreibungssprache in der Dienstumgebung ausgeführt, in der auch die Bewegungsplanung stattfindet.
+Die Beschreibungssprache kommuniziert direkt mit der Simulation und der Bewegungsplanung des simulierten Menschen.
+Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen Simulation und Bewegungsplanung auch Nachrichten ausgetauscht.
+Der gesamte Vorgang ist in Abbildung \ref{concept_overview} visualisiert.
+
+Die zu erarbeitende Softwareumgebung soll einfach erweiterbar sein, um weitere Modifikationen und die Umsetzung anderer Projekte zuzulassen.
+Hierzu zählt die Austauschbarkeit und Erweiterbarkeit von Komponenten wie der simulierten Welt, dem Roboter oder dem simulierten Mensch.
+Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
+
+\begin{figure}
+\includegraphics{img/MA-Konzept-Übersicht}
+\centering
+\caption{Visualisierung des Konzepts}
+\label{concept_overview}
+\end{figure}
+
+\section{Simulation des Roboters}
+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 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.
+Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst genau abbilden.
+Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
+
+\section{Simulation des Menschen}
+Der Mensch soll in der Simulation typische Aufgaben erledigen und häufiges Verhalten abbilden können.
+Hierzu sollen in der Simulationsumgebung mehrere Animationen verwendet werden, welche die aktuelle Tätigkeit darstellen.
+Für komplexere Verhaltensweisen können Animationen und andere Aktionen, wie zum Beispiel eine Bewegung und Rotation kombiniert werden, um zum Beispiel die Aktion ``Laufen in eine bestimmte Richtung'' auszuführen.
+
+Um diese Animationen erstellen zu können, wird zuerst ein animierbares Modell des Menschen benötigt.
+Das zu erstellende Modell soll dabei um weitere Animationen erweiterbar sein.
+Unterschiedliche Animationen gehen dabei meist von verschiedenen Ursprungszuständen aus.
+Um zwischen diesen Ursprungszuständen wechseln zu können, werden weitere Animationen benötigt.
+
+Die so erstellten Animationen müssen von außerhalb der Simulationsumgebung ausführbar gemacht werden.
+Ein solcher Mechanismus erlaubt die spätere Steuerung der Animation durch die Beschreibungssprache.
+Hierfür muss eine Komponente entwickelt werden, die in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
+Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, soll diese Komponente die Ausführung der Befehle überwachen.
+Da mehrere Befehle nacheinander ausgeführt werden sollen, wird der aktuelle Fortschritt der Aktion zurückgemeldet.
+Außerdem kann durch andere Komponenten in der Simulation der Abbruch einer Aktion des Menschen nötig werden.
+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 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.
+
+Behavior Trees lösen dieses Problem, in dem sie sogenannte Nodes definieren, die in einer übersichtlichen Baumstruktur angeordnet werden.
+Die einzelnen Nodes verändern dabei das System und lösen den Wechsel zu neuen Nodes aus.
+
+Ursprünglich wurde das Konzept der Behavior Trees von Rodney Brooks entwickelt, der diese für mobile Roboter einsetzen wollte. \cite{1087032}
+Das System setzte sich später jedoch zuerst in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten, durch. \cite{isla2005handling}
+
+Der Ablauf eines Behavior Trees startet vom sogenannten Root, der Wurzel des Baums.
+Von dort an werden Nodes, die je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
+Die Nodes werden untereinander angeordnet, was die Relation der Nodes zueinander beschreibt.
+Jede Node ist entweder direkt unter der Root-Node oder einer anderen Node angeordnet.
+Außerdem kann jede Node eine beliebige Anzahl an untergeordneten Nodes besitzen.
+Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unterschieden werden.
+\begin{description}
+ \item[Aktions-Nodes]
+  beschreiben einzelne ausführbare Aktionen, die das System beeinflussen können.
+  Jede Aktion liefert dabei einen Rückgabewert über ihren Erfolg, der durch die darüber liegende Node ausgewertet werden kann.
+ \item[Dekorations-Nodes]
+  können den Rückgabewert einer anderen Node modifizieren.
+  Zumeist wird die Negation des Rückgabewerts verwendet, aber auch das Forcieren eines bestimmten Rückgabewertes ist möglich.
+ \item[Sequenz-Nodes]
+  beschreiben eine nacheinander ausgeführte Abfolge von darunter liegenden Nodes.
+  Sollte eine Node einen Fehler zurückgeben, wird die Ausführung der Sequenz abgebrochen, was wiederum zur Rückgabe eines Fehlers durch die Sequenz selbst führt.
+  Beim erfolgreichen Durchlauf gibt die Sequenz einen Erfolg zurück.
+ \item[Fallback-Nodes]
+  verhalten sich ähnlich wie Sequenz-Nodes, jedoch werden die darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurückgibt.
+  In diesem Fall wird die Ausführung der Fallback-Node mit einem Erfolg abgebrochen.
+  Ein Fehler wird hier zurückgegeben, wenn alle Nodes ohne eine Erfolgsmeldung durchlaufen wurden.
+\end{description}
+
+\begin{figure}
+\includegraphics[]{img/MA-tree-demo}
+\centering
+\caption{Beispiel eines BehaviorTrees}
+\label{concept_tree_demo}
+\end{figure}
+
+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.
+Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, 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.
+Folgender Kontrollfluss findet in diesem Beispiel statt:
+
+\begin{enumerate}
+ \item{
+  In dieser Node wird geprüft, ob die Tür bereits offen ist.
+  Da die Tür nicht offen ist, wird ein Misserfolg zurückgemeldet.
+ }
+ \item{
+  Dieses Ergebnis löst die Ausführung der nächsten untergeordneten Node der Fallback-Node aus.
+  Die so ausgewählte Node soll die Tür öffnen.
+  Der Versuch gelingt und der Erfolg wird an die Fallback-Node übergeben.
+ }
+ \item{
+  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{
+  Dadurch wird die nächste Node in der Sequenz ausgeführt, die prüft, ob die Tür durchlaufen werden kann.
+  Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet.
+ }
+ \item{
+  Der gemeldete Misserfolg der untergeordneten Node bricht die Ausführung der Sequenz mit einem negativen Rückgabewert ab.
+ }
+\end{enumerate}
+
+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.
+
+In dieser Arbeit sollen deshalb BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
+Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, die in dieser Arbeit betrachtet werden, abzudecken.
+
+\section{Virtualisierungsumgebung als Plattform}
+Der Einsatz fest definierter Prozesse in einer stabilen Umgebung ist unerlässlich, um Fehler durch die unvollständige Einrichtung der Umgebung zu vermeiden.
+Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in der das zu entwerfende System ausgeführt wird.
+
+Dadurch können benötigte Programme, Pfade und Umgebungsvariablen in der Virtualisierungsumgebung hinterlegt werden, die diese bei der Ausführung auf einem anderen Grundsystem korrekt abbildet.
+Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da die Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
+
+Ein weiterer Vorteil ist die beschleunigte Entwicklung, weil Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
+Hinzu kommt die einfachere Inbetriebnahme eines bereits entwickelten Systems, da keine Anpassungen am Hostsystem vorgenommen werden müssen.
+
+Natürlich existieren auch Nachteile der Virtualisierung, die mit den Vorteilen abgewogen werden müssen.
+Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, die dann der virtualisierten Anwendung nicht mehr zur Verfügung steht.
+Außerdem muss bei grafischen Systemen die Darstellung der relevanten grafischen Daten auf dem Hostsystem berücksichtigt werden.
+
+Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung beeinflusst das Ergebnis dieser Arbeit zwar nicht direkt, hat aber großen Einfluss auf die Pflege des Gesamtsystems.
+Dies erlaubt zum Beispiel unabhängige, dedizierte Versionen der Softwarekomponenten und die Möglichkeit isolierter Upgrades dieser Komponenten.
+Eine solche Plattform sorgt somit für die Reproduzierbarkeit der Ergebnisse auf verschiedenen Systemen.

tex/3_Auswahl.tex

@@ -0,0 +1,480 @@
+\chapter{Komponenten-/Softwareauswahl}
+Die Auswahl der verwendeten Softwarekomponenten beeinflusst den späteren Entwicklungsprozess nachhaltig.
+
+Alle Komponenten sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
+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 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.
+
+Bei einer Dienstumgebung für Roboter gehört die Nachrichtenübergabe zwischen den einzelnen Programmen zu den grundlegenden Aspekten.
+Diese wird genutzt, um eine gemeinsame Basis für ein erweiterbares System zu schaffen.
+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 infrage kommen, wenn man lediglich die Nachrichtenübergabe zwischen Programmen betrachtet.
+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.
+
+Nutzbare, bereits als Interprozesskommunikation integrierte Systeme sind zum Beispiel Pipes, die Daten zwischen Prozessen über Buffer austauschen.
+Auch die Nutzung von Message Queues oder Shared Memory ist für diesen Einsatzzweck möglich.
+Diese Systeme sind performant, jedoch schwerer zu verwalten.
+Ein Problem dieser Methoden ist die direkte Kommunikation mehrerer Komponenten, da die Art der Kommunikation keine Modifikation von Nachrichten zur Anpassung an andere Szenarien vorsieht.
+
+Eine Alternative stellen Sockets dar, die Daten zwischen mehreren Programmen austauschen können.
+Dabei dient ein Programm als Server, der Anfragen von anderen Programmen, auch Clients genannt, entgegen nimmt.
+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 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.
+
+Im Bereich der Robotik ist ROS \cite{doi:10.1126/scirobotics.abm6074}, bei dem es sich um ein quelloffenes System handelt, als Dienstumgebung etabliert.
+Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standardisierte und erweiterbare Nachrichtendefinitionen gelöst, die von den Programmen in der Umgebung genutzt werden.
+Um diese Nachrichten senden und empfangen zu können, liefert ROS bereits eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
+Zum Beispiel existieren für Python \cite{python}, C und C++ \cite{cpp} entsprechende Implementationen in Form der Pakete \code{rospy}, \code{rclc} und \code{rclcpp}.
+
+Die neuste Version ROS2 bietet mehrere Verbesserungen im Vergleich zu früheren Version ROS1 \cite{changesRosII}.
+Ein neues Nachrichtenformat mit Quality of Service kann beispielsweise Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
+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}.
+
+ROS kann sowohl für simulierte Umgebungen als auch für echte Roboter eingesetzt werden.
+Diese beiden Anwendungsfälle werden durch unterschiedliche Controller realisiert.
+Für simulierte Umgebungen leitet der Controller die Steuerdaten an die Simulationsumgebung weiter.
+Bei dem Einsatz echter Hardware werden die Zielpositionen durch den Controller an die Roboterhardware weitergeleitet.
+
+%-Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
+%-ROS2
+%-Andere (nur) Messagingsysteme
+%-LCM
+%-ZeroMQ
+\subsection{Beschreibung}
+ROS2 \cite{doi:10.1126/scirobotics.abm6074}, im weiteren Verlauf nur ROS genannt, beschreibt sich selbst als ``a meta operating system for robots'' \cite{ros-git}.
+Hierbei ist ``operating system'' nicht in seiner herkömmlichen Bedeutung eines vollständigen Betriebssystems zu verstehen.
+Es handelt sich dabei um eine gemeinsame Grundlage für Programme und Daten, die durch ROS bereitgestellt wird.
+
+Einzelne Bestandteile in der Umgebung sind dabei in Pakete gegliedert, wobei jedes Paket beliebig viele Daten und Programme beinhalten kann.
+Programme, die mit anderen Programmen in der Umgebung über die ROS internen Schnittstellen kommunizieren, werden in ROS ``Nodes'' genannt.
+
+Zu den Aufgaben von ROS zählen folgende Teilbereiche:
+\begin{description}
+ \item[Organisation]\hfill \\
+  Um die einzelnen Teile einer Roboterumgebung zu separieren, werden diese in ROS auf unterschiedliche Pakete aufgeteilt.
+  Jedes Paket enthält dabei eine \code{package.xml}-Datei.
+  In dieser befindet sich eine in XML verfasste Definition des Paketinhalts, die verschiedene Aspekte des Pakets beschreibt.
+
+  Darunter fallen Informationen über das Paket selbst, wie dessen Name, Beschreibung und Version.
+  Außerdem sind Name und Mailadresse des Autors, sowie die gewählte Lizenz des Codes vermerkt.
+  Um das Paket später korrekt ausführen zu können, werden benötigte Pakete für den Kompiliervorgang und die Ausführung in die package.xml-Datei eingetragen.
+
+ \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 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.
+  Hierbei werden alle in der \code{CMakeLists.txt}-Datei angegebenen Programmteile kompiliert.
+
+  Es ist außerdem möglich, bestimmte Pfade des Pakets nach dem Buildvorgang zu exportieren.
+  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 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.
+  Um das Paket im System zu registrieren, muss der Nutzer die generierten Skripte ausführen, was die benötigten Umgebungsvariablen setzt.
+  Hierfür wird meist ein weiteres Skript verwendet, was alle im Workspace befindlichen Pakete nacheinander der Umgebung hinzufügt.
+
+  Dieser Vorgang erlaubt zum Beispiel das Auffinden von Paketen anhand deren Namen im Dateisystem.
+  Das erleichtert die Verwaltung durch die Unabhängigkeit von spezifischen Pfaden im entwickelten System.
+  Außerdem wird die Laufzeitumgebung für alle Programme konfiguriert, was definierte Bibliotheken für diese verfügbar macht.
+
+ \item[Abhängigkeitsverwaltung]\hfill \\
+  ROS kann durch die in den Paketen deklarierten Abhängigkeiten prüfen, ob diese in der aktuellen Umgebung ausführbar sind.
+  Die generierten Warnungen bei fehlenden Paketen helfen dem Anwender, Abstürze und undefiniertes Verhalten bei der Ausführung von Nodes zu vermeiden, die diese Pakete benötigen.
+
+ \item[Datenübertragung]\hfill \\
+  Um Daten zwischen Nodes austauschen zu können, müssen die Nodes miteinander auf einem festgelegten Weg kommunizieren können.
+  Ein solcher Aufbau erlaubt den Austausch von Daten in vorher nicht durch die Entwickler bedachten Anwendungsfällen.
+  Die von ROS gebotene Schnittstelle zur Datenübertragung wird in Form mehrerer Bibliotheken für unterschiedliche Programmiersprachen bereitgestellt.
+
+  Der Datenaustausch geschieht in sogenannten Topics, die Nachrichtenkanäle zwischen den Nodes darstellen.
+  Eine Node kann entweder als Server ein Topic anbieten, was durch andere Nodes gelesen wird, oder als Client auf solche bereitgestellten Topics zugreifen.
+  Durch die Kombination mehrerer Topics ist eine komplexere Interaktion abbildbar, die zum Beispiel Rückgabewerte zum aktuell ausgeführten Steuerbefehl liefert.
+
+ \item[Parameterübergabe]\hfill \\
+  Um Nodes auf neue Anwendungsfälle anpassen zu können, wird ein Konfigurationsmechanismus benötigt.
+  In ROS geschieht dies durch die Übergabe sogenannter Parameter, die durch die Node gelesen werden können.
+  Diese eignen sich zur Übergabe von Informationen, wie zum Beispiel Daten über ein verwendetes Robotermodell.
+  Um neue Konfigurationen zu unterstützen, kann das Umbenennen von Topics einer Node notwendig werden, was auch mit einem Parameter erfolgen kann.
+
+ \item[Startverwaltung]\hfill \\
+  In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
+  Das Einstellen von bestimmten Parametern erlaubt die Anpassung der Funktionen an den gewünschten Anwendungsfall.
+
+\end{description}
+
+Eine solche Umgebung erlaubt die Zerlegung der geplanten Simulation in mehrere Komponenten.
+Die daraus erfolgte Abgrenzung erhöht die Übersichtlichkeit der einzelnen Bestandteile.
+Dies vereinfacht die spätere Wartung des Projekts.
+
+\section{Simulationsumgebung}
+
+\subsection{Auswahl}
+Als Simulationsumgebung eignen sich verschiedenen Programme, die sich hinsichtlich ihres Funktionsumfangs stark unterscheiden.
+Hierfür kommen beispielsweise dedizierte Werkzeuge zur Robotersimulation, aber auch universell einsetzbare Gameengines infrage.
+Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da sich der gebotene Funktionsumfang der Softwares stark unterscheidet.
+Auch andere Aspekte, wie Lizenzen oder die schwer bewertbare Nutzerfreundlichkeit, sind hierbei zu betrachten.
+Eine Auswahl der als Simulationsumgebung infrage kommenden Programme wird hier vorgestellt.
+
+CoppeliaSim \cite{coppelia}, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
+Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
+Der Simulator selbst unterstützt menschliche Aktoren, diese können aber nur Animationen allein oder in Kombination mit einer Bewegung abspielen.
+CoppeliaSim existiert in 3 Versionen, die sich hinsichtlich Funktionsumfang und Lizenz unterscheiden.
+Jedoch besitzt nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
+
+Gazebo Ignition \cite{gazebo} ist wie CoppeliaSim eine Robotersimulationsumgebung, besitzt aber keinen integrierten Editor und direkte ROS-Unterstützung.
+Gazebo setzt wie CoppeliaSim auf Erweiterungen, um zusätzliche Funktionen einbinden zu können.
+So existiert zum Beispiel auch eine ROS-Brücke, die die Anbindung an ROS ermöglicht.
+Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
+Das Projekt ist Open Source, unter der Apache-Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
+
+Unity \cite{unity} hingegen ist primär eine Grafikengine für die Nutzung in Computerspielen.
+Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
+Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
+Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteigerbereich zurückzuführen ist.
+Auch die Optionen zur Menschensimulation sind umfangreich, da diese häufig in Spielen verwendet werden.
+Ein großer Nachteil hingegen ist die Lizenz, die nur für Einzelpersonen kostenfrei ist.
+
+Die Unreal Engine \cite{unreal} ist wie Unity eine Grafikengine aus dem Spielebereich.
+Auch hier ist die Menschensimulation aufgrund oben genannter Gründe gut möglich.
+Jedoch existiert für Unreal Engine keine offizielle Lösung zur Anbindung an ROS2.
+Die Programmierung der Engine erfolgt in C++, was die Erstellung eines Plugins zur ROS-Anbindung der Unreal Engine ermöglichte, die von Nutzern gewartet wird.
+Die Lizenz der Unreal Engine erlaubt die kostenfreie Nutzung bis zu einem gewissen Umsatz mit der erstellten Software.
+
+Eine weitere Möglichkeit zur Simulation stellt die Grafikengine Godot \cite{godot} dar.
+Im Vergleich zu Unity und Unreal Engine ist Godot quelloffene Software unter der MIT-Lizenz.
+Auch hier stellt die Simulation von menschlichen Aktoren eine Standardaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
+Auch für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht offiziell.
+
+Alle vorgestellten Softwares besitzen ein integriertes Physiksystem, dass die Simulation von starren Körpern und Gelenken erlaubt.
+Diese Funktionen erlauben den Aufbau eines Roboterarms, der durch eine ROS-Brücke gesteuert wird.
+
+Um den Fokus dieser Arbeit auf die gestellte Aufgabe zu ermöglichen, ist die Auswahl einer Umgebung mit bereits existierender ROS-Unterstützung sinnvoll.
+Durch diese Einschränkung scheiden sowohl Unreal Engine aber auch Godot aus.
+Sie bieten zwar diese Funktionalität, jedoch werden sie nur durch Nutzer gewartet und sind demzufolge nicht offiziell unterstützt.
+Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese einen Einsatz unter nahezu allen Umständen erlaubt.
+
+Die Wahl der hier zu verwendenden Simulationsumgebung fiel deshalb auf Gazebo Ignition, welche gleichzeitig bereits im ROS-Ökosystem etabliert ist.
+Dabei erlauben die offizielle ROS-Anbindung und die offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
+\subsection{Welt- und Modellbeschreibung}
+Gazebo nutzt das .sdf-Dateiformat, um die Simulationsumbebung zu beschreiben \cite{sdf-format}.
+Dieses Format basiert auf XML und wird zur Definition gesamter Welten, aber auch einzelner Objekte innerhalb dieser Welten benutzt.
+Eine Welt ist in Gazebo eine Umgebung aus mehreren Objekten, welche simuliert werden sollen.
+Die Welt beschreibt außerdem die simulierte Physikumgebung und deren Konstanten, wie zum Beispiel die Gravitation.
+
+Um verschiedene Versionen des Formats zu unterstützen, enthält das einzige sdf-Element die gewünschte Versionsnummer.
+Eine solche Datei kann, wie bereits oben beschrieben, unterschiedliche Daten enthalten.
+Im Falle eines Objekts ist dies eine einzige Instanz von entweder einem Modell, Actor oder Licht.
+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.
+Zudem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
+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}.
+
+Ein Modell enthält einen Roboter oder ein anderes physikalisches Objekt in der Simulation.
+Die Deklaration eines weiteren Untermodells ist möglich, um komplexere Strukturen abbilden zu können.
+Über ein include-Element können auch andere .sdf-Dateien, die nur ein einzelnes Modell enthalten, zu einem Modell hinzugefügt werden.
+
+Jedes Modell wird über eine Translation und Rotation im Simulationsraum verankert.
+Dies geschieht immer relativ zum Referenzsystem des überliegenden Modells.
+Außerdem können im Modell Einstellungen für dessen Physiksimulation vorgenommen werden.
+
+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.
+
+Lichter besitzen einen Lichttyp, der die Ausbreitung des Lichtes im Raum bestimmt.
+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 Punktlichtquellen 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.
+Diese können durch in einem Skript definierte Trajectories ausgeführt werden, was eine einfache, aber statische, Simulation des Menschen erlaubt.
+
+Eine solche Befehlsfolge kann nicht von außerhalb der Simulation zur Laufzeit angepasst werden.
+Diese Funktionalität wurde im Rahmen der Arbeit hinzugefügt.
+
+\subsection{Robotersimulation}
+Für die Robotersimulation wird ein Modell des Roboters benötigt, in dem dieser für die Simulationsumgebung beschrieben wird.
+Gazebo und ROS nutzen hierfür .urdf-Dateien \cite{urdf-format}, die auf XML basieren.
+In diesen werden die einzelnen Glieder des Roboterarms und die verbindenden Gelenke beschrieben.
+
+Jedes Glied des Modells besitzt eine Masse, einen Masseschwerpunkt und eine Trägheitsmatrix für die Physiksimulation in Gazebo.
+Außerdem werden Modelle für die visuelle Repräsentation des Roboters in Gazebo und die Kollisionserkennung in der Physiksimulation hinterlegt.
+Für beide existieren einfache Modelle wie Zylinder, Boxen und Kugeln.
+Da diese Formen nicht jeden Anwendungsfall abdecken und in der visuellen Repräsentation nicht ausreichen, können auch eigene Modelle hinterlegt werden.
+Hierbei werden die Modelle für die Physiksimulation und das Aussehen des Roboters unterschieden.
+
+Gelenke werden separat von den Gliedern definiert und verbinden jeweils zwei Glieder miteinander.
+Durch das Aneinanderreihen von mehreren Gliedern und Gelenken ist die Beschreibung eines beliebigen Roboteraufbaus möglich.
+Jedes Gelenk besitzt eine Position und Rotation im Raum.
+Diese werden für die Berechnung der Effekte genutzt, die vom spezifischen Gelenktyp abhängen.
+Aspekte wie Reibung und Dämpfung können auch hier für die Nutzung in der Physiksimulation beschrieben werden.
+Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
+\begin{description}
+ \item[freie Gelenke]
+  ermöglichen vollständige Bewegung in allen 6 Freiheitsgraden (Rotation und Translation). Sie stellen den normalen Zustand der Glieder zueinander dar.
+ \item[planare Gelenke]
+  erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden zum Beispiel für Oberflächen eingesetzt, auf welchen Objekte gleiten sollen.
+ \item[feste Gelenke]
+  sperren alle 6 Freiheitsgrade und werden häufig zur Fixierung von Objekten in einer Szene genutzt.
+ \item[kontinuierliche Gelenke]
+  erlauben die beliebige Rotation um die Achse des Gelenks. Sie sind nur selten in rotierenden Gelenken mit Schleifkontakten oder anderen frei rotierbaren Übertragungsmechanismen zu finden.
+ \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 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.
+Für diesen existiert bereits ein Modell mit mehreren Animationen, die allein abgespielt, oder an Bewegungen gekoppelt werden können.
+Dadurch ist zum Beispiel eine Laufanimation realisierbar, die synchronisiert zu einer Bewegung abgespielt wird.
+
+Dies setzt jedoch voraus, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
+Der Grund dafür ist auf die Definition der Pfade zurückzuführen, die Aktionen wie Bewegungen und Animationen auslösen.
+Diese können nur als dem Actor untergeordnetes Element in der .sdf-Datei definiert werden, was Veränderungen zur Laufzeit ausschließt.
+Durch diesen Umstand ist der damit realisierbare Simulationsumfang nicht ausreichend, um die gewünschten Szenarien abzubilden.
+
+Um diese Einschränkung zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
+Dieses System muss, wie im Konzept beschrieben, Steuerbefehle von außen empfangen, umsetzen und Feedback liefern können.
+Dafür soll ein ROS Action-Server verwendet werden, der die Befehle entgegennimmt, unter konstantem Feedback ausführt und nach erfolgreicher Ausführung den Empfang des nächsten Befehls zulässt.
+
+Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, die konstant weiter entwickelt wird.
+Dies vereinfacht die Wartung, da bei Updates der Simulationsumgebung nicht die Menschensimulation an den neuen Code angepasst werden muss.
+\section{Roboterumgebung}
+MoveIt2 \cite{moveit-docs} ist das meist genutzte ROS2 Paket für die Bewegungsplanung von Robotern.
+Deshalb existiert eine umfangreiche Dokumentation für die zahlreichen Komponenten, was die Entwicklung neuer Komponenten erleichtert.
+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 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.
+Diese wurden mit dem mitgelieferten Setupassistenten für den Roboter generiert.
+Durch die Ausführung dieser Demo startet RViz, eine Test- und Visualisierungsumgebung für ROS.
+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 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.
+Außerdem können Objekte virtuell mit dem Roboter verbunden werden, wodurch sich diese in RViz mit dem Roboter bewegen.
+Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, um einzelne Bereiche des Systems zu testen.
+
+Um die durch den Setupassistenten generierten Informationen an MoveIt zu übergeben, wird intern ein RobotStatePublisher verwendet.
+Dieser lädt alle Daten des Robotermodells und übergibt sie an andere Programme, die Roboterparameter zur Laufzeit anfordern, unter diesen auch MoveIt selbst.
+
+Durch die vorher erwähnte C++-API erhält die MoveGroup die Informationen über die gewünschte Bewegung.
+Dabei können auch bestimmte Einschränkungen des Arbeitsraums, spezielle Trajektorien oder Limitierungen der Gelenke in der Planung berücksichtigt werden.
+
+Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, die sich um den Roboter befinden.
+Eine solche Erweiterung erlaubt die automatische Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
+
+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 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.
+
+Im Falle von Gazebo wird \code{ign_ros_control} genutzt, dass die benötigten \code{ros_control} Controller in die Simulation einbindet.
+Diese können dann wie normale Controller von \code{ros_control} genutzt werden.
+
+Der Ablauf der Bewegungsplanungspipeline von MoveIt ist im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
+
+\section{Programmiersprache}
+Als Programmiersprache kommen in ROS standardmäßig Python \cite{python} und C++ \cite{cpp} zum Einsatz.
+Beide Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark im Funktionsumfang und im Entwicklungsprozess.
+
+Python ist eine interpretierte Skriptsprache, die zu den hohen Programmiersprachen zählt.
+Sie wird in ROS zum Beispiel in \code{.launch.py}-Dateien eingesetzt, die den Start von Diensten in der Umgebung verwalten.
+Die Sprache kann aber auch für die Programmierung von Nodes innerhalb des ROS-Systems verwendet werden.
+
+C++ hingegen ist eine kompilierte, statisch typisierte, maschinennahe Programmiersprache.
+In ROS wird C++ für Code verwendet, der entweder häufig oder in zeitkritischen Szenarien ausgeführt wird.
+Aus diesem Grund wird C++ in Nodes verwendet, die schnell auf große Datenmengen reagieren müssen.
+
+Die Nutzung eines Kompilierers beschleunigt C++ deutlich im Vergleich zu Python, ist jedoch weniger geeignet für häufige Modifikation.
+Dies ist vor allem in häufig geänderten Programmen ein Nachteil, die nach einer Änderung erneut kompiliert werden müssen.
+Aus diesem Grund wird Python vor allem in .launch.py-Dateien verwendet, welche die Interaktion der anderen Programme in der Umgebung verwalten.
+
+Um die gewünschten Funktionen für die Simulation umzusetzen ist die Verwendung der Programmiersprache C++ nahezu unumgänglich.
+Zum Beispiel sind Gazebo-Plugins in C++ erstellt, was die Nutzung anderer Sprachen stark einschränkt.
+
+Ein weiterer Grund für die Nutzung von C++ ist die hohe Geschwindigkeit, die bei einer hohen Anzahl von Simulationsschritten pro Sekunde benötigt wird.
+Außerdem kann MoveIt2 derzeit nur mit C++ direkt gesteuert werden.
+
+Die Verwendung von C++ für die zu entwickelnden Nodes erscheint deshalb aus oben genannten Gründen naheliegend.
+In den Launch-Skripten wird jedoch Python verwendet werden, da hier die Vorteile einer Skriptsprache überwiegen.
+
+\section{Behavior Trees}
+Zur Verwaltung der Abläufe sollen Behavior Trees genutzt werden, die durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
+Diese Bibliothek wurde in C++ geschrieben, und ist somit in ROS und dem geplanten Konzept integrierbar.
+
+Es existieren viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen der Bibliothek, die im Folgenden vorgestellt werden.
+
+\begin{description}
+  \item[Asynchrone Nodes]
+  sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese in Form verschiedener Zustände der Nodes beim Konzept der Bibliothek mit bedacht wurden.
+  Dies resultiert in Nodes, die ohne spezielle Logik langanhaltende Aktionen ausführen können, ohne die Ausführung des Behavior Trees zu behindern.
+  \item[Reaktives Verhalten] ist ein neues Konzept, um die Handhabung von asynchronen Nodes zu vereinfachen.
+  Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, die die aktuell ausgeführte Aktion beeinflussen können.
+  Darunter fällt die Modifizierung von Parametern der Aktionen, aber auch der vollständige Abbruch einer Aktion durch äußere Einflüsse.
+  \item[Das .xml-Format der Behavior Trees] ermöglicht einen Austausch des Verhaltens, ohne die unterliegenden Programme verändern zu müssen.
+  Dies ist vor allem in kompilierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompilierung bedürfen, was die Iterationszeit für Änderungen verbessert.
+  \item[Plugins] können zum Start geladen werden, um weitere Nodes dem ausgeführten Programm hinzufügen zu können.
+  Dies vereinfacht die Erweiterung um neue Funktionen und das mehrfache Nutzen von Code.
+  \item[Das Blackboard] ist eine Interaktionsebene, die den Datenfluss zwischen den Nodes erlaubt.
+  In diesem System kann unter Verwendung einer Zeichenkette als Identifikator ein Wert in Form einer Referenz hinterlegt werden.
+  Sogenannte Ports erlauben Nodes, Daten aus dem Blackboard zu lesen und auf dieses zu schreiben.
+  \item[Integriertes Logging] erlaubt es, Zustandsänderungen im Behavior Tree zu visualisieren, aufzunehmen und wieder abzuspielen.
+  Dies erleichtert das häufig schwierige Debuggen von Zustandsmaschinen erheblich, da das Verhalten genau untersucht werden kann.
+\end{description}
+
+Behavior Trees werden bei Verwendung von \code{BehaviorTree.CPP} in Form von .xml-Dateien gespeichert.
+Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeports.
+
+Ports können verwendet werden, um Nodes generischer zu gestalten.
+Durch veränderbare Parameter im später erstellten Tree können Nodes ohne Programmänderung verändert werden.
+Falls die Nodes mit Bedacht erstellt wurden, kann so auf viele spezialisierte Nodes verzichtet werden.
+Um dies zu ermöglichen, kann deren Funktion durch mehrere andere Nodes in einem Subtree mit Parametern abgebildet werden.
+Diese in den Ports übertragenen Daten können sowohl aus einem String ausgelesen, aber auch aus dem sogenannten Blackboard entnommen werden.
+
+Um die Übersetzung aus einem String zu ermöglichen, muss eine entsprechende Funktion implementiert werden, die einen String in den gewünschten Zieltyp übersetzt.
+Viele primitive Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von Behavior Tree.Cpp bereits durch native Funktionen unterstützt.
+
+Das Blackboard ist ein System, dass die Nutzung von Variablen als Parameter für Ports erlaubt.
+Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeichert.
+Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des Behavior Trees.
+Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, die zu komplexeren Strukturen zusammengesetzt werden können.
+
+Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Gruppen von Nodes als sogenannte Subtrees abspeichern.
+Diese bilden in ihrer Gesamtheit eine neue Node, die im Behavior Tree eingesetzt werden kann.
+Um den Einsatz von Variablen innerhalb eines Subtrees zu ermöglichen, besitzt jeder Subtree ein separates Blackboard.
+Dadurch kann auch ein Eingriff durch äußere Einflüsse verhindert werden.
+
+Natürlich sollte es auch möglich sein, Variablen an solche Subtrees zu übergeben.
+Diese können, wie auch bei normalen Nodes, als Parameter an den Subtree übergeben werden.
+Die Bibliothek \code{BehaviorTree.CPP} verbindet dann diese Werte und erlaubt die Datenübergabe zum und vom Subtree.
+
+\subsection{Asynchrone Nodes}
+Da nicht jeder Prozess sofort vollständig durchgeführt werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
+Dies geschieht in \code{BehaviorTree.CPP} durch asynchrone Nodes.
+
+Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE einer normalen Node auch die beiden neuen Zustände RUNNING und IDLE.
+Außerdem werden mehrere Funktionen definiert, die den Lebenszyklus der Node definieren.
+
+Wird eine Node durch den Aufruf der \code{onStart}-Funktion gestartet, geht diese in einen der Zustände RUNNING, SUCCESS oder FAILURE über.
+
+Der Zustand RUNNING steht dabei für eine Node, die sich noch in der Ausführung befindet.
+Solange dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand in der neuen \code{onRunning}-Funktion abgefragt.
+
+Der IDLE-Zustand ist ein besonderer Zustand, der nur durch eine vollständige Ausführung erreichbar ist.
+Er wird von der Node angenommen, nachdem deren Ausführung durch SUCCESS oder FAILURE beendet wurde.
+
+Im Falle eines Abbruchs, der durch andere Nodes im Baum ausgelöst werden könnte, muss die Ausführung der Node vorzeitig beendet werden können.
+Dies geschieht mit der neuen \code{onHalted}-Funktion, welche ausgeführt wird, wenn die Ausführung der Node abgebrochen werden soll.
+\subsection{Dateiformat}
+Das in Behavior Tree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
+Jedes Dokument beginnt dabei mit einem Root-Element, dass alle Behavior Trees und eine Referenz auf die ID des Hauptbaumes enthält.
+Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genutzt werden können, die aber sonst nicht vom Hauptbaum unterscheidbar sind.
+
+Jeder Baum beginnt mit einem Behavior Tree-Element, das als Attribut die ID des Baumes besitzen muss.
+Als untergeordnete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
+
+Als Beispiel wird der bereits im Konzept verwendete Behavior Tree (siehe Abbildung \ref{choice_tree_xml}) in die entsprechende XML-Repräsentation umgewandelt.
+Dabei ist zu beachten, dass die Root-Node in der Datei nicht existiert, da diese nur den Eintrittspunkt in die Struktur darstellt.
+Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber auch über den Namen Action mit ihrem Namen als ID-Parameter, referenziert werden.
+\begin{figure}[hpt]
+\includegraphics[width=\textwidth]{img/MA-tree-demo}
+\centering
+\caption{Beispiel eines Behavior Trees}
+\label{choice_tree_demo}
+\end{figure}
+\begin{figure}[hpt]
+\begin{minted}[breaklines,frame=single,linenos]{xml}
+<?xml version="1.0"?>
+<root main_tree_to_execute="demoTree">
+    <Behavior Tree ID="actorTree">
+        <Sequence>
+            <Fallback>
+                <Action ID="IsDoorOpen"/>
+                <Action ID="OpenDoor"/>
+                <Action ID="BreakDoor"/>
+            </Fallback>
+            <CanWalkThrough/>
+            <WalkThrough/>
+        </Sequence>
+    </Behavior Tree>
+</root>
+\end{minted}
+\caption{Beispiel eines Behavior Trees als .xml}
+\label{choice_tree_xml}
+\end{figure}
+
+\section{Virtualisierungsumgebung}
+
+Bei Virtualisierungsumgebungen wird zwischen virtuellen Maschinen und Containerumgebungen unterschieden.
+
+Bei einer virtuellen Maschine (VM) werden alle Komponenten der Maschine simuliert, was die Nutzung anderer Betriebssysteme ermöglicht.
+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 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.
+
+Da bereits eine Linux-Maschine zur Entwicklung vorhanden ist, wäre die Virtualisierung eines weiteren Linux-Kernels nur mit weiterem Performanceverlust verbunden.
+Außerdem soll in der Virtualisierungsumgebung Grafikbeschleunigung genutzt werden, wozu in einer VM eine Grafikkarte an das Zielsystem durchgereicht wird, die dann von der VM exklusiv genutzt wird.
+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 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.
+Der so erstellte Container wird anhand dieser Definition durch den Host erstellt.
+Um diesen Prozess weiter zu beschleunigen, ist auch der Einsatz eines Buildservers möglich, der benötigte Container als Download bereitstellt.
+
+Jeder Container enthält ein eigenes Dateisystem, das aus dem im Buildfile definierten Dateien und einem Overlay besteht.
+In diesem Overlay werden temporär Änderungen gespeichert, die am Container während dessen Laufzeit vorgenommen werden.
+Sofern nicht definiert, werden diese Änderungen beim Neustart des Containers wieder entfernt.
+
+Um dies zu vermeiden, kann entweder ein Volume, eine Art virtuelles Laufwerk in einem Systemverzeichnis des Hostsystems, oder ein ``bind mount'' eingerichtet werden.
+Ein ``bind mount'' ist eine direkte Verbindung zu einem Ort des Host-Dateisystems, dass in den Container hereingereicht wird.
+
+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 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/5_Evaluation_und_Diskussion.tex

@@ -0,0 +1,214 @@
+\chapter{Evaluation und Diskussion}
+
+\section{Grundlagen}
+
+\subsubsection{Auswahl einer geeigneten Umgebung}
+Die Auswahl einer geeigneten Umgebung für die gewünschte Simulation erfolgte in mehreren Auswahlschritten.
+Hierfür wurden mehrere Komponenten einzeln verglichen und ausgewählt.
+Folgende Komponenten wurden für die Umgebung ausgewählt:
+\begin{itemize}
+ \item ROS2 als Dienstumgebung,
+ \item Gazebo Ignition als Simulationssoftware und
+ \item BehaviorTree.CPP als Beschreibungssprache.
+\end{itemize}
+
+Alle Komponenten können prinzipiell miteinander kommunizieren, was den Aufbau einer Simulationsumgebung erlaubt.
+
+\subsubsection{Nutzung der Virtualisierungsumgebung}
+Die auf Docker basierende Virtualisierungsumgebung stellt eine vollständige ROS2-Installation dar.
+In dieser Umgebung sind alle für die Arbeit benötigten Pakete enthalten.
+Der Start der Umgebung erfolgt über das im Projektverzeichnis befindliche \code{start.sh}-Shellskript.
+Dieses Skript wird ohne Parameter ausgeführt.
+
+Beim ersten Start der Umgebung wird automatisch eine neue Containervorlage erstellt.
+Der Start der Umgebung wird mit der Ausgabe \code{ros-ros-1  | Ready to connect.} abgeschlossen, die auch in Abbildung \ref{console-docker-started} sichtbar ist.
+Während der Nutzung der Umgebung muss das Terminal weiter geöffnet bleiben.
+Nach dem Senden eines Terminiersignals durch das Schließen des Terminals oder die Tastenkombination \code{Ctrl+C} wird die Containerumgebung beendet.
+
+\begin{figure}
+\includegraphics[width=\textwidth]{img/MA-Docker-Started}
+\centering
+\caption{Konsole mit gestarteter Virtualisierungsumgebung}
+\label{console-docker-started}
+\end{figure}
+
+Die Verbindung in die ROS-Umgebung erfolgt über SSH in einer separaten Konsole.
+Eine SSH-Verbindung wird mit dem Befehl \code{ssh ros@localhost -p 2222} aufgebaut.
+In dieser Session kann die Hardwarebeschleunigung des Hostsystems automatisch genutzt werden.
+Dies wurde in Abbildung \ref{console-docker-passthrough} durch die Ausführung von \code{glxgears}, einer OpenGL-Anwendung zum Testen der Grafikpipeline, demonstriert.
+
+Das entworfene Containersystem ist mit der bereitgestellten Funktionalität eine Grundlage für die weitere Implementation.
+
+\begin{figure}
+\includegraphics[width=\textwidth]{img/MA-Docker-Passthrough}
+\centering
+\caption{Konsole in der virtuellen Umgebung mit Grafiktests}
+\label{console-docker-passthrough}
+\end{figure}
+
+\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 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.
+Mithilfe dieses modifizierten Modells wurden dann die benötigten Animationen erstellt.
+
+\subsubsection{Steuerung des Menschen}
+
+Durch den Start der Simulation wird selbstständig das erstellte ActorPlugin geladen.
+Der Start des für diese Arbeit implementierten ActorServers erfolgt zeitgleich, um die Anbindung an ROS zu gewährleisten.
+Beide Anwendungen zusammen erlauben das Ausführen von Bewegungen und Animationen während der Laufzeit der Simulation.
+
+Alle für die Simulation des Menschen erstellten Animationen werden automatisch geladen, sobald diese durch das Plugin verwendet werden.
+Dies kann durch die erstellten BehaviorTree-Nodes erfolgen, aber auch durch das Verwenden von Terminalbefehlen zu Testzwecken.
+
+
+\subsubsection{Definition von Verhalten mit einer Beschreibungssprache}
+
+Die Definition von verschiedenen Verhaltensweisen über eine Beschreibungssprache wurde durch die Erstellung neuer Nodes für einen Behavior Tree erreicht.
+Für die Bewegung und Animation des Menschen sind die Nodes ActorMovement und ActorAnimation verfügbar.
+Die Steuerung des Roboters erfolgt durch die RobotMove- und SetRobotVelocity-Node.
+Beide Nodes zur Kontrolle des Roboters starten eine neue Bewegung mit den neuen Parametern.
+Im Falle einer laufenden Bewegung wird diese vorher gestoppt.
+
+Um Bewegungen in Zonen zu ermöglichen, kann die GenerateXYPose-Node zufällige Positionen in einer Zone generieren.
+Die InAreaTest-Node erlaubt eine Auskunft über die Position von Objekten.
+Eine Redefinition von bestehenden Parametern der generierten Pose ist über die OffsetPose-Node möglich.
+
+Eine Wiederaufnahme von unvollendeten Aktionen ist durch die implementierte Interruptable\-Sequence-Node möglich.
+
+Die Entscheidung über die Ausführung einer von mehreren möglichen Aktionen wird mit der WeightedRandom-Node realisiert.
+Um Fehler simulieren zu können, ist der Abbruch von Aktionen nötig.
+Dies wird durch die RandomFailure-Node erreicht.
+
+Eine Kombination dieser neu implementieren und den bereits in BehaviorTree.CPP verfügbaren Nodes kann alle in den Szenarien benötigten Verhaltensweisen darstellen.
+
+\subsection{Erstellen der benötigten Pakete}
+
+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 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.
+Für das manuelle Laden des Workspaces muss der Befehl \code{source /home/ros/workspace/install/setup.bash} in der Konsole ausgeführt werden.
+
+Nach dem Laden des Workspaces ist die Umgebung für die Simulation einsatzbereit.
+
+\section{Simulation der Szenarien}
+Das Starten der Simulation erfolgt über ein Skript innerhalb des \code{ign_world}-Pakets.
+Dieses Skript wird durch den Befehl \code{ros2 launch ign_world gazebo_controller_launch.py} ausgeführt.
+In diesem Skript werden alle für die Simulation benötigten ROS2-Nodes gestartet und konfiguriert.
+
+Durch die Verwendung des optionalen Parameters \code{scene} kann das gewünschte Szenario ausgewählt werden.
+Dieser muss in folgendem Format verwendet werden:
+\code{ros2 launch ign_world gazebo_controller_launch.py scene:=[Coex|Coop|Colab]}.
+Als Standard wird die Option \code{Coex} genutzt, falls der \code{scene}-Parameter nicht spezifiziert wird.
+
+Nach dem Start der Simulationsumgebung ist der Raum vollständig geladen und einsatzbereit (Abbildung \ref{sim-room}).
+Der Roboter befindet sich nach dem Start in der Ausgangsposition, siehe Abbildung \ref{robot-still}.
+
+\begin{figure}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Room}
+\centering
+\caption{Raum in der Simulation}
+\label{sim-room}
+\end{minipage}
+\hspace{.09\textwidth}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Robot-Still}
+\centering
+\caption{Roboterarm in Ausagangslage}
+\label{robot-still}
+\end{minipage}
+\end{figure}
+
+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}
+
+Im Koexistenzszenario interagieren Roboter und Mensch nur im Ausnahmefall.
+Der Roboter simuliert einen Entladevorgang, bei welchem Objekte vom linken Tisch auf den rechten Tisch bewegt werden (Abbildung \ref{coex-move}).
+Die für diesen Zweck implementierten Bewegungsnodes werden in späteren Szenarien weiter verwendet.
+Um den Menschen nicht zu gefährden, wird die Verfahrgeschwindigkeit automatisch an die Aufenthaltszone des Menschen angepasst.
+
+Der Arbeitsvorgang des Menschen besteht aus dem Arbeiten an einer Werkbank und dem Verbringen von Material in das Regal (Abbildung \ref{coex-shelf}).
+In diesem Szenario begibt sich der Mensch nur mit einer Wahrscheinlichkeit von 5\% nach jedem Arbeitsvorgang zum Roboter.
+
+\begin{figure}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Robot-Move}
+\centering
+\caption{Roboter in Bewegung}
+\label{coex-move}
+\end{minipage}
+\hspace{.09\textwidth}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Human-Shelf}
+\centering
+\caption{Mensch am Regal}
+\label{coex-shelf}
+\end{minipage}
+\end{figure}
+
+\subsubsection{Kooperationsszenario}
+
+Eine Ausweitung der Interaktion erfolgt im Kooperationsszenario.
+In diesem werden durch den Roboter Objekte entweder weitergereicht oder aussortiert.
+Nach jedem aussortierten Objekt wird der Mensch gerufen.
+Der Mensch holt die aussortierten Objekte nach dem Erledigen seiner aktuellen Aufgabe ab.
+Diese Interaktion und das in diesem Szenario hinzugefügte Fließband sind in Abbildung \ref{coop-human} dargestellt.
+
+\begin{figure}
+\includegraphics[width=\textwidth]{img/MA-Sim-Human-Coop}
+\centering
+\caption{Mensch am Tisch des Roboters mit Förderband}
+\label{coop-human}
+\end{figure}
+
+\subsubsection{Kollaborationsszenario}
+
+Für das Kollaborationsszenario durchschreitet der Mensch den Raum, was die Kontrolle mehrerer Systeme simuliert.
+Der Roboter bewegt in diesem Szenario Objekte vom linken auf den rechten Tisch, wobei Fehler auftreten können.
+Bei einem Fehler beendet der Mensch seinen Kontrollgang und hebt ein Objekt auf, bringt es zum Roboter zurück und legt es auf dem rechten Tisch ab (Abbildung \ref{colab-drop}).
+Der Roboter bricht den fehlgeschlagenen Vorgang ab und setzt die Arbeit mit dem nächsten Objekt fort.
+
+\begin{figure}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Pickup}
+\centering
+\end{minipage}
+\hspace{.09\textwidth}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Drop}
+\centering
+\end{minipage}
+\caption{Mensch beim Aufhebevorgang}
+\label{colab-drop}
+\end{figure}
+
+\section{Zusammenfassung}
+Es wurden entsprechende Nodes für die Bewegung von Mensch und Roboter geschaffen.
+Mit diesen Nodes wurden alle simulierten Szenarien in einer Beschreibungssprache abgebildet.
+Die vollständige Kontrolle der Endeffektorposition des Roboters und der Bewegung des Menschen in der Simulation sind möglich.
+
+Die dynamische Simulation von Objekten, die durch Roboter und Mensch beeinflusst werden können, wurde im Rahmen dieser Arbeit aus Komplexitätsgründen nicht umgesetzt.
+Einen Überblick über die dafür notwendigen Erweiterungen wird in Sektion \ref{objectsim} skizziert.
+\section{Lessons Learned}
+
+Während der Entwicklung des Projekts wurden zahlreiche Erkenntnisse gesammelt, welche die Entwicklung weiterer Projekte mit dieser Plattform erleichtern können.
+
+\begin{description}
+ \item[Testen einzelner Komponenten]\hfill\\
+  Alle ROS-Nachrichtentypen sind mit Kommandozeilenbefehlen versend- und empfangbar.
+  Um einzelne Teilsysteme zu testen, können so deren Zustände gesetzt und überwacht werden.
+ \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}.
+  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}.
+\end{description}

tex/6_Ausblick.tex

@@ -0,0 +1,81 @@
+\chapter{Ausblick}
+\section{Umsetzung in anderem Simulator}
+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 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 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.
+Diese können für Roboterbewegungen und Menschensimulation verwendet werden.
+
+\section{Simulation bewegter Objekte}\label{objectsim}
+Die Simulation bewegter Objekte benötigt ein neues Gazebo-Plugin, welches mit den bereits entwickelten Komponenten der aktuellen Umgebung interagiert.
+Um ein Objekt mit dem Roboter oder Menschen zu bewegen, muss dieses auf eine von zwei Arten bewegt werden.
+
+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 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.
+Stattdessen muss die aktuelle Position des Armes anhand der Animationsdaten verfolgt werden, um die Position des Objektes an diese anzupassen.
+
+Die unterschiedliche Anbindung von Roboter und Mensch erfordert mehrere Implementationen, welche Zustandsdaten über das Objekt austauschen müssen.
+Um die Objekte zu steuern, muss eine weitere ROS-Anbindung in einem entsprechenden Gazebo-Plugin erfolgen.
+
+Dieses Plugin unterliegt denselben Limitierungen, die auch schon im ActorPlugin beachtet werden mussten.
+Eine weitere Nachrichtenübergabe als Zwischenschritt vor dem eigentlichen ROS-Server ist so unausweichlich.
+
+Dieser Kommunikationsmechanismus muss das Erstellen, Entfernen und Bewegen von Objekten zwischen Roboter, Umgebung und Mensch unterstützen.
+\section{Erweiterung um Umgebungserkennung}
+Eine Ergänzung von simulierten Tiefenkameras zur Umgebungserkennung stellt eine weitere mögliche Ausbaustufe des Projekts dar.
+Mit den Kameras kann eine Tiefenkarte erstellt werden, um die Verfahrgeschwindigkeit des Roboters zu kontrollieren.
+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.
+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}
+Die aktuelle, separate Implementation von ActorServer und ActorPlugin kann durch eine Vereinigung der Implementation verbessert werden.
+Folgende Versuche wurden bereits durchgeführt, führten aber zu keinem Erfolg:
+\begin{itemize}
+ \item{Die Ausführung in einem separaten Thread,}
+ \item{eine Trennung vom Hauptprogramm mittels Fork und}
+ \item{das Weglassen der Initialisierung von rclcpp, da diese später durch ign_ros2_control durchgeführt wird.}
+\end{itemize}
+
+\section{Migration auf die neuste ROS-Version}
+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 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.
+
+\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 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.
+
+Ein Nachteil der Migration wäre jedoch das Wegfallen einiger Funktionen des Editors, welcher in dieser Version unter einer neuen Lizenz vertrieben wird.
+Die Analyse von Logdateien nach der Ausführung und die Überwachung von Bäumen zur Laufzeit sind ohne kostenpflichtige Lizenz nicht mehr möglich.
+
+Eine weitere Alternative ist die Nutzung von MoveIt Studio \cite{moveItStudio}, welches ebenfalls mit Behavior Trees arbeitet.
+Die direkte Integration mit MoveIt vereinfacht die Anbindung an den Roboter, da wichtige Funktionen bereits implementiert sind.
+Jedoch ist die Unterstützung für eigene Befehle nur schlecht dokumentiert.
+Diese werden aber für die Steuerung des Menschen benötigt, was dieses Alternative nur für die Robotersteuerung attraktiv macht.
+
+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 kompiliert werden.
+Bei einer großen Anzahl an Modulen erschwert dieser Umstand die Übersicht über benötigte Module für spezifische Trees.

uml/actor_server_activity.puml

@@ -0,0 +1,13 @@
+@startuml
+start
+
+:Initialisiere MessageQueue;
+if (Graphviz installed?) then (yes)
+  :process all\ndiagrams;
+else (no)
+  :process only
+  __sequence__ and __activity__ diagrams;
+endif
+
+stop
+@enduml

uml/animation_states.puml

@@ -0,0 +1,39 @@
+@startuml animation_states
+hide empty description
+skinparam Shadowing true
+
+[*] --> Standing
+
+state Standing{
+    [*] --> [*]
+    [*] --> standing_extend_arm
+    standing_extend_arm --> standing_retract_arm
+    standing_retract_arm --> [*]
+
+    [*] --> standing_walk
+    standing_walk --> [*]
+}
+Standing -> Standing
+
+state Low{
+    [*] --> [*]
+    [*] --> low_inspect
+    low_inspect --> low_put_back
+    low_inspect --> low_grab
+    low_put_back --> [*]
+    low_grab --> [*]
+}
+
+Low -> Low
+
+'Spacer :D
+state a #transparent;line:transparent;text:transparent
+Low -up[hidden]-> a
+
+Standing -up-> standing_to_low
+standing_to_low -down-> Low
+Low -up-> low_to_standing
+low_to_standing -down-> Standing
+
+
+@enduml

uml/plugin_animation.puml

@@ -0,0 +1,14 @@
+@startuml plugin_animation
+
+start
+
+:Setzen der gewünschten Animation;
+:Berechnung der Animationslänge aus Parametern;
+repeat
+  :Aktualisieren der Animationszeit;
+repeat while (Animationslänge nicht erreicht?) is (J a)
+:Status auf Idle setzen;
+
+stop
+
+@enduml

uml/plugin_connectivity.puml

@@ -0,0 +1,37 @@
+@startuml plugin_connectivity
+skinparam fixCircleLabelOverlapping true
+skinparam SequenceLifeLineBorderColor #B0B0B0
+skinparam SequenceDividerBorderColor Gray
+skinparam SequenceGroupBorderColor Gray
+skinparam sequenceMessageAlign Center
+skinparam ArrowColor #404040
+participant "ROS ActionClient" as client
+participant ActorServer as server
+participant ActorPlugin as plugin
+activate server
+activate plugin
+
+[-> client: neuer ActionClient
+activate client
+
+client -> server: Zielvorgabe
+server -->> client: Antwort auf Zielvorgabe
+
+alt Zielvorgabe akzeptiert?
+server ->> plugin: neuen Status und Ziel setzen
+plugin -->> server: Zustandswechsel bei\nnächstem Simulationsschritt
+group opt par [Abbruch der Aktion]
+client->server: Abbruchanfrage
+server->plugin: Status auf Idle setzen
+plugin -->> server: Zustandswechsel auf Idle
+server-->>client: positive Abbruchantwort
+end
+loop Bis Aktion vollständig ausgeführt oder abgebrochen ist
+plugin -->> server: Feedback
+server -->> client: Feedback
+end
+plugin -->> server: Zustandswechsel auf Idle
+server -->> client: Endnachricht
+end
+destroy client
+@enduml

uml/plugin_movement.puml

@@ -0,0 +1,37 @@
+@startuml plugin_movement
+
+start
+
+:Setzen der gewünschten Animation;
+:Berechnung der Bewegungsparameter;
+:Berechnung der Bewegungslänge;
+
+if (Distanz zu Ziel) then (größer als 0.001m)
+  ->;
+  repeat
+    :Drehen zum Bewegungsziel;
+  repeat while (Zum Bewegungsziel ausgerichtet?) is (Nein)
+  ->Ja;
+  repeat
+    :Bewegen zum Bewegungsziel;
+  repeat while (Bewegungsziel erreicht?) is (Nein)
+  ->Ja;
+else (kleiner als 0.001m)
+endif
+
+if (Zielrotation gegeben) then (>0.001m)
+  repeat
+    :Drehen zum Bewegungsziel;
+  repeat while (Zum Bewegungsziel ausgerichtet?) is (Nein)
+  ->Ja;
+  repeat
+    :Bewegen zum Bewegungsziel;
+  repeat while (Bewegungsziel erreicht?) is (Nein)
+  ->Ja;
+endif
+
+:Status auf Idle setzen;
+
+stop
+
+@enduml

uml/plugin_states.puml

@@ -0,0 +1,21 @@
+@startuml plugin_states
+[*] -> Setup
+Setup : Ersteinrichtung nach
+Setup : Simulationsbeginn
+
+
+
+Setup --> Idle
+Idle: Keine Aktivität
+
+
+Idle -right-> Movement
+Movement: zielgerichtete
+Movement: Bewegung des Actors
+Movement -> Idle
+
+Idle -left-> Animation
+Animation: Animation des Actors
+Animation -> Idle
+
+@enduml

uml/subtree_deposit.puml

@@ -0,0 +1,25 @@
+@startmindmap subtree_deposit
+
+
+skinparam Linetype ortho
+skinparam defaultTextAlignment center
+top to bottom direction
+
+* Sequence
+** WeightedRandom\nWichtung 1:1:1
+*** Laufe zu 1. Regal
+*** Laufe zu 2. Regal
+*** Laufe zu 3. Regal
+
+** WeightedRandom\nWichtung 1:1
+*** Sequence
+**** Animation\nstanding_extend_arm
+**** Animation\nstanding_retract_arm
+
+*** Sequence
+**** Animation\nstanding_to_low
+**** Animation\nlow_inspect
+**** Animation\nlow_put_back
+**** Animation\nlow_to_standing
+
+@endmindmap