Changes up to 07.06

.kile/mechforsch.kilepr.gui

@@ -113,51 +113,51 @@ TextFolding={"checksum":"","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.bib]
-CursorColumn=39
+CursorColumn=1
-CursorLine=124
+CursorLine=257
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"739b41a3d0418be76fb9832856bf61b41b8246a1","ranges":[]}
+TextFolding={"checksum":"d388fe775e2de092b50ce9dbaa861869ee036db3","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
-CursorColumn=45
+CursorColumn=68
-CursorLine=176
+CursorLine=32
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"158329202f028c3e1d1437e81256f8ab37c5f9c3","ranges":[]}
+TextFolding={"checksum":"88153af05e2be709e828e4e8a1a9f54b756bcefe","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/1_Einleitung.tex]
-CursorColumn=0
+CursorColumn=114
-CursorLine=19
+CursorLine=46
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"8adc2060163a9c199c7a904534fb248831564ce4","ranges":[]}
+TextFolding={"checksum":"052cc01250adb0f5e3ea2eff211696be3fc560ae","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/2_Konzept.tex]
 CursorColumn=0
-CursorLine=0
+CursorLine=115
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"0c6fe8907e6bb50811600d85d72851fe402f8c80","ranges":[]}
+TextFolding={"checksum":"462cd841a4ae5cfb2a0372ff60c2f3b89035b3ea","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/3_Auswahl.tex]
-CursorColumn=157
+CursorColumn=99
-CursorLine=266
+CursorLine=364
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"e90e925eeab38e92c6b17256a2993fc4a01f29c8","ranges":[]}
+TextFolding={"checksum":"9cca06e103193ebce1a74b19ba51648376b36a4b","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/4_Umsetzung.tex]
-CursorColumn=27
+CursorColumn=0
-CursorLine=138
+CursorLine=452
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"d54709e0d3b00c46d9571f297ab62aa6064e7f7c","ranges":[]}
+TextFolding={"checksum":"dd8e7caf4d43ea72300c447784e10addb44c0e7e","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/Einleitung.tex]

_minted-main/391704321A86D34384492C034ECA3CFA82CA0C42AFE0759A4F1491A6B69BC02A.pygtex

@@ -0,0 +1,6 @@
+\begin{Verbatim}[commandchars=\\\{\}]
+\PYG{c+ch}{\PYGZsh{}!/bin/bash}
+\PYG{n+nb}{pushd}\PYG{+w}{ }\PYG{l+s+s2}{\PYGZdq{}}\PYG{k}{\PYGZdl{}(}dirname\PYG{+w}{ }\PYG{l+s+s2}{\PYGZdq{}}\PYG{n+nv}{\PYGZdl{}0}\PYG{l+s+s2}{\PYGZdq{}}\PYG{k}{)}\PYG{l+s+s2}{\PYGZdq{}}\PYG{+w}{ }\PYG{o}{||}\PYG{+w}{ }\PYG{n+nb}{exit}
+colcon\PYG{+w}{ }build\PYG{+w}{ }\PYGZhy{}\PYGZhy{}event\PYGZhy{}handlers\PYG{+w}{ }console\PYGZus{}cohesion+\PYG{+w}{ }\PYGZhy{}\PYGZhy{}cmake\PYGZhy{}args\PYG{+w}{ }\PYGZhy{}DCMAKE\PYGZus{}EXPORT\PYGZus{}COMPILE\PYGZus{}COMMANDS\PYG{o}{=}ON\PYG{+w}{ }\PYGZhy{}G\PYG{+w}{ }Ninja
+\PYG{n+nb}{popd}\PYG{+w}{ }\PYG{o}{||}\PYG{+w}{ }\PYG{n+nb}{exit}
+\end{Verbatim}

_minted-main/86994E17E7B794407C4C28872F16EC061EC630FA6AA4A122E827A2E31B1A68E1.pygtex

@@ -0,0 +1,16 @@
+\begin{Verbatim}[commandchars=\\\{\}]
+\PYG{c+cp}{\PYGZlt{}?xml version=\PYGZdq{}1.0\PYGZdq{}?\PYGZgt{}}
+\PYG{n+nt}{\PYGZlt{}root}\PYG{+w}{ }\PYG{n+na}{main\PYGZus{}tree\PYGZus{}to\PYGZus{}execute=}\PYG{l+s}{\PYGZdq{}demoTree\PYGZdq{}}\PYG{n+nt}{\PYGZgt{}}
+\PYG{+w}{    }\PYG{n+nt}{\PYGZlt{}BehaviorTree}\PYG{+w}{ }\PYG{n+na}{ID=}\PYG{l+s}{\PYGZdq{}actorTree\PYGZdq{}}\PYG{n+nt}{\PYGZgt{}}
+\PYG{+w}{        }\PYG{n+nt}{\PYGZlt{}Sequence\PYGZgt{}}
+\PYG{+w}{            }\PYG{n+nt}{\PYGZlt{}Fallback\PYGZgt{}}
+\PYG{+w}{                }\PYG{n+nt}{\PYGZlt{}Action}\PYG{+w}{ }\PYG{n+na}{ID=}\PYG{l+s}{\PYGZdq{}IsDoorOpen\PYGZdq{}}\PYG{n+nt}{/\PYGZgt{}}
+\PYG{+w}{                }\PYG{n+nt}{\PYGZlt{}Action}\PYG{+w}{ }\PYG{n+na}{ID=}\PYG{l+s}{\PYGZdq{}OpenDoor\PYGZdq{}}\PYG{n+nt}{/\PYGZgt{}}
+\PYG{+w}{                }\PYG{n+nt}{\PYGZlt{}Action}\PYG{+w}{ }\PYG{n+na}{ID=}\PYG{l+s}{\PYGZdq{}BreakDoor\PYGZdq{}}\PYG{n+nt}{/\PYGZgt{}}
+\PYG{+w}{            }\PYG{n+nt}{\PYGZlt{}/Fallback\PYGZgt{}}
+\PYG{+w}{            }\PYG{n+nt}{\PYGZlt{}CanWalkThrough/\PYGZgt{}}
+\PYG{+w}{            }\PYG{n+nt}{\PYGZlt{}WalkThrough/\PYGZgt{}}
+\PYG{+w}{        }\PYG{n+nt}{\PYGZlt{}/Sequence\PYGZgt{}}
+\PYG{+w}{    }\PYG{n+nt}{\PYGZlt{}/BehaviorTree\PYGZgt{}}
+\PYG{n+nt}{\PYGZlt{}/root\PYGZgt{}}
+\end{Verbatim}

_minted-main/default.pygstyle

@@ -0,0 +1,101 @@
+
+\makeatletter
+\def\PYG@reset{\let\PYG@it=\relax \let\PYG@bf=\relax%
+    \let\PYG@ul=\relax \let\PYG@tc=\relax%
+    \let\PYG@bc=\relax \let\PYG@ff=\relax}
+\def\PYG@tok#1{\csname PYG@tok@#1\endcsname}
+\def\PYG@toks#1+{\ifx\relax#1\empty\else%
+    \PYG@tok{#1}\expandafter\PYG@toks\fi}
+\def\PYG@do#1{\PYG@bc{\PYG@tc{\PYG@ul{%
+    \PYG@it{\PYG@bf{\PYG@ff{#1}}}}}}}
+\def\PYG#1#2{\PYG@reset\PYG@toks#1+\relax+\PYG@do{#2}}
+
+\@namedef{PYG@tok@w}{\def\PYG@tc##1{\textcolor[rgb]{0.73,0.73,0.73}{##1}}}
+\@namedef{PYG@tok@c}{\let\PYG@it=\textit\def\PYG@tc##1{\textcolor[rgb]{0.24,0.48,0.48}{##1}}}
+\@namedef{PYG@tok@cp}{\def\PYG@tc##1{\textcolor[rgb]{0.61,0.40,0.00}{##1}}}
+\@namedef{PYG@tok@k}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@kp}{\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@kt}{\def\PYG@tc##1{\textcolor[rgb]{0.69,0.00,0.25}{##1}}}
+\@namedef{PYG@tok@o}{\def\PYG@tc##1{\textcolor[rgb]{0.40,0.40,0.40}{##1}}}
+\@namedef{PYG@tok@ow}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.67,0.13,1.00}{##1}}}
+\@namedef{PYG@tok@nb}{\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@nf}{\def\PYG@tc##1{\textcolor[rgb]{0.00,0.00,1.00}{##1}}}
+\@namedef{PYG@tok@nc}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.00,1.00}{##1}}}
+\@namedef{PYG@tok@nn}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.00,1.00}{##1}}}
+\@namedef{PYG@tok@ne}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.80,0.25,0.22}{##1}}}
+\@namedef{PYG@tok@nv}{\def\PYG@tc##1{\textcolor[rgb]{0.10,0.09,0.49}{##1}}}
+\@namedef{PYG@tok@no}{\def\PYG@tc##1{\textcolor[rgb]{0.53,0.00,0.00}{##1}}}
+\@namedef{PYG@tok@nl}{\def\PYG@tc##1{\textcolor[rgb]{0.46,0.46,0.00}{##1}}}
+\@namedef{PYG@tok@ni}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.44,0.44,0.44}{##1}}}
+\@namedef{PYG@tok@na}{\def\PYG@tc##1{\textcolor[rgb]{0.41,0.47,0.13}{##1}}}
+\@namedef{PYG@tok@nt}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@nd}{\def\PYG@tc##1{\textcolor[rgb]{0.67,0.13,1.00}{##1}}}
+\@namedef{PYG@tok@s}{\def\PYG@tc##1{\textcolor[rgb]{0.73,0.13,0.13}{##1}}}
+\@namedef{PYG@tok@sd}{\let\PYG@it=\textit\def\PYG@tc##1{\textcolor[rgb]{0.73,0.13,0.13}{##1}}}
+\@namedef{PYG@tok@si}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.64,0.35,0.47}{##1}}}
+\@namedef{PYG@tok@se}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.67,0.36,0.12}{##1}}}
+\@namedef{PYG@tok@sr}{\def\PYG@tc##1{\textcolor[rgb]{0.64,0.35,0.47}{##1}}}
+\@namedef{PYG@tok@ss}{\def\PYG@tc##1{\textcolor[rgb]{0.10,0.09,0.49}{##1}}}
+\@namedef{PYG@tok@sx}{\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@m}{\def\PYG@tc##1{\textcolor[rgb]{0.40,0.40,0.40}{##1}}}
+\@namedef{PYG@tok@gh}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.00,0.50}{##1}}}
+\@namedef{PYG@tok@gu}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.50,0.00,0.50}{##1}}}
+\@namedef{PYG@tok@gd}{\def\PYG@tc##1{\textcolor[rgb]{0.63,0.00,0.00}{##1}}}
+\@namedef{PYG@tok@gi}{\def\PYG@tc##1{\textcolor[rgb]{0.00,0.52,0.00}{##1}}}
+\@namedef{PYG@tok@gr}{\def\PYG@tc##1{\textcolor[rgb]{0.89,0.00,0.00}{##1}}}
+\@namedef{PYG@tok@ge}{\let\PYG@it=\textit}
+\@namedef{PYG@tok@gs}{\let\PYG@bf=\textbf}
+\@namedef{PYG@tok@gp}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.00,0.50}{##1}}}
+\@namedef{PYG@tok@go}{\def\PYG@tc##1{\textcolor[rgb]{0.44,0.44,0.44}{##1}}}
+\@namedef{PYG@tok@gt}{\def\PYG@tc##1{\textcolor[rgb]{0.00,0.27,0.87}{##1}}}
+\@namedef{PYG@tok@err}{\def\PYG@bc##1{{\setlength{\fboxsep}{\string -\fboxrule}\fcolorbox[rgb]{1.00,0.00,0.00}{1,1,1}{\strut ##1}}}}
+\@namedef{PYG@tok@kc}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@kd}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@kn}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@kr}{\let\PYG@bf=\textbf\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@bp}{\def\PYG@tc##1{\textcolor[rgb]{0.00,0.50,0.00}{##1}}}
+\@namedef{PYG@tok@fm}{\def\PYG@tc##1{\textcolor[rgb]{0.00,0.00,1.00}{##1}}}
+\@namedef{PYG@tok@vc}{\def\PYG@tc##1{\textcolor[rgb]{0.10,0.09,0.49}{##1}}}
+\@namedef{PYG@tok@vg}{\def\PYG@tc##1{\textcolor[rgb]{0.10,0.09,0.49}{##1}}}
+\@namedef{PYG@tok@vi}{\def\PYG@tc##1{\textcolor[rgb]{0.10,0.09,0.49}{##1}}}
+\@namedef{PYG@tok@vm}{\def\PYG@tc##1{\textcolor[rgb]{0.10,0.09,0.49}{##1}}}
+\@namedef{PYG@tok@sa}{\def\PYG@tc##1{\textcolor[rgb]{0.73,0.13,0.13}{##1}}}
+\@namedef{PYG@tok@sb}{\def\PYG@tc##1{\textcolor[rgb]{0.73,0.13,0.13}{##1}}}
+\@namedef{PYG@tok@sc}{\def\PYG@tc##1{\textcolor[rgb]{0.73,0.13,0.13}{##1}}}
+\@namedef{PYG@tok@dl}{\def\PYG@tc##1{\textcolor[rgb]{0.73,0.13,0.13}{##1}}}
+\@namedef{PYG@tok@s2}{\def\PYG@tc##1{\textcolor[rgb]{0.73,0.13,0.13}{##1}}}
+\@namedef{PYG@tok@sh}{\def\PYG@tc##1{\textcolor[rgb]{0.73,0.13,0.13}{##1}}}
+\@namedef{PYG@tok@s1}{\def\PYG@tc##1{\textcolor[rgb]{0.73,0.13,0.13}{##1}}}
+\@namedef{PYG@tok@mb}{\def\PYG@tc##1{\textcolor[rgb]{0.40,0.40,0.40}{##1}}}
+\@namedef{PYG@tok@mf}{\def\PYG@tc##1{\textcolor[rgb]{0.40,0.40,0.40}{##1}}}
+\@namedef{PYG@tok@mh}{\def\PYG@tc##1{\textcolor[rgb]{0.40,0.40,0.40}{##1}}}
+\@namedef{PYG@tok@mi}{\def\PYG@tc##1{\textcolor[rgb]{0.40,0.40,0.40}{##1}}}
+\@namedef{PYG@tok@il}{\def\PYG@tc##1{\textcolor[rgb]{0.40,0.40,0.40}{##1}}}
+\@namedef{PYG@tok@mo}{\def\PYG@tc##1{\textcolor[rgb]{0.40,0.40,0.40}{##1}}}
+\@namedef{PYG@tok@ch}{\let\PYG@it=\textit\def\PYG@tc##1{\textcolor[rgb]{0.24,0.48,0.48}{##1}}}
+\@namedef{PYG@tok@cm}{\let\PYG@it=\textit\def\PYG@tc##1{\textcolor[rgb]{0.24,0.48,0.48}{##1}}}
+\@namedef{PYG@tok@cpf}{\let\PYG@it=\textit\def\PYG@tc##1{\textcolor[rgb]{0.24,0.48,0.48}{##1}}}
+\@namedef{PYG@tok@c1}{\let\PYG@it=\textit\def\PYG@tc##1{\textcolor[rgb]{0.24,0.48,0.48}{##1}}}
+\@namedef{PYG@tok@cs}{\let\PYG@it=\textit\def\PYG@tc##1{\textcolor[rgb]{0.24,0.48,0.48}{##1}}}
+
+\def\PYGZbs{\char`\\}
+\def\PYGZus{\char`\_}
+\def\PYGZob{\char`\{}
+\def\PYGZcb{\char`\}}
+\def\PYGZca{\char`\^}
+\def\PYGZam{\char`\&}
+\def\PYGZlt{\char`\<}
+\def\PYGZgt{\char`\>}
+\def\PYGZsh{\char`\#}
+\def\PYGZpc{\char`\%}
+\def\PYGZdl{\char`\$}
+\def\PYGZhy{\char`\-}
+\def\PYGZsq{\char`\'}
+\def\PYGZdq{\char`\"}
+\def\PYGZti{\char`\~}
+% for compatibility with earlier versions
+\def\PYGZat{@}
+\def\PYGZlb{[}
+\def\PYGZrb{]}
+\makeatother
+

main.aux

@@ -0,0 +1,347 @@
+\relax 
+\providecommand*\new@tpo@label[2]{}
+\providecommand\babel@aux[2]{}
+\@nameuse{bbl@beforestart}
+\catcode `"\active 
+\abx@aux@refcontext{nty/global//global/global}
+\providecommand\hyper@newdestlabel[2]{}
+\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument}
+\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined
+\global\let\oldnewlabel\newlabel
+\gdef\newlabel#1#2{\newlabelxx{#1}#2}
+\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}}
+\AtEndDocument{\ifx\hyper@anchor\@undefined
+\let\newlabel\oldnewlabel
+\fi}
+\fi}
+\global\let\hyper@last\relax 
+\gdef\HyperFirstAtBeginDocument#1{#1}
+\providecommand\HyField@AuxAddToFields[1]{}
+\providecommand\HyField@AuxAddToCoFields[2]{}
+\providecommand\BKM@entry[2]{}
+\catcode 95\active
+\@writefile{toc}{\acswitchoff }
+\@writefile{lof}{\acswitchoff }
+\@writefile{lot}{\acswitchoff }
+\babel@aux{ngerman}{}
+\abx@aux@cite{0}{moveitpipeline}
+\abx@aux@segm{0}{0}{moveitpipeline}
+\BKM@entry{id=1,dest={636861707465722E31},srcline={1}}{5C3337365C3337375C303030455C303030695C3030306E5C3030306C5C303030655C303030695C303030745C303030755C3030306E5C30303067}
+\BKM@entry{id=2,dest={73656374696F6E2E312E31},srcline={2}}{5C3337365C3337375C3030304D5C3030306F5C303030745C303030695C303030765C303030615C303030745C303030695C3030306F5C3030306E}
+\BKM@entry{id=3,dest={73656374696F6E2E312E32},srcline={19}}{5C3337365C3337375C303030535C303030745C303030615C3030306E5C303030645C3030305C3034305C303030645C303030655C303030725C3030305C3034305C303030575C303030695C303030735C303030735C303030655C3030306E5C303030735C303030635C303030685C303030615C303030665C30303074}
+\abx@aux@cite{0}{DOMBROWSKI2018134}
+\abx@aux@segm{0}{0}{DOMBROWSKI2018134}
+\@writefile{toc}{\contentsline {chapter}{\numberline {1}Einleitung}{1}{chapter.1}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {1.1}Motivation}{1}{section.1.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {1.2}Stand der Wissenschaft}{1}{section.1.2}\protected@file@percent }
+\abx@aux@cite{0}{ffdrobotsim}
+\abx@aux@segm{0}{0}{ffdrobotsim}
+\abx@aux@cite{0}{btintro}
+\abx@aux@segm{0}{0}{btintro}
+\abx@aux@cite{0}{halo2}
+\abx@aux@segm{0}{0}{halo2}
+\BKM@entry{id=4,dest={73656374696F6E2E312E33},srcline={38}}{5C3337365C3337375C303030575C303030655C3030306C5C303030635C303030685C303030655C3030305C3034305C303030535C3030307A5C303030655C3030306E5C303030615C303030725C303030695C303030655C3030306E}
+\@writefile{toc}{\contentsline {section}{\numberline {1.3}Welche Szenarien}{2}{section.1.3}\protected@file@percent }
+\BKM@entry{id=5,dest={73656374696F6E2E312E34},srcline={59}}{5C3337365C3337375C303030575C303030655C3030306C5C303030635C303030685C303030655C303030725C3030305C3034305C3030304E5C303030755C303030745C3030307A5C303030655C3030306E5C3030305C3034305C3030302F5C3030305C3034305C303030435C3030306F5C3030306E5C303030745C303030725C303030695C303030625C303030755C303030745C303030695C3030306F5C3030306E5C30303073}
+\@writefile{toc}{\contentsline {section}{\numberline {1.4}Welcher Nutzen / Contributions}{3}{section.1.4}\protected@file@percent }
+\BKM@entry{id=6,dest={636861707465722E32},srcline={1}}{5C3337365C3337375C3030304B5C3030306F5C3030306E5C3030307A5C303030655C303030705C30303074}
+\BKM@entry{id=7,dest={73656374696F6E2E322E31},srcline={22}}{5C3337365C3337375C303030535C303030695C3030306D5C303030755C3030306C5C303030615C303030745C303030695C3030306F5C3030306E5C3030305C3034305C303030645C303030655C303030735C3030305C3034305C303030525C3030306F5C303030625C3030306F5C303030745C303030655C303030725C30303073}
+\abx@aux@cite{0}{cobot}
+\abx@aux@segm{0}{0}{cobot}
+\@writefile{toc}{\contentsline {chapter}{\numberline {2}Konzept}{4}{chapter.2}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {2.1}Simulation des Roboters}{4}{section.2.1}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {2.1}{\ignorespaces Visualisierung des Konzepts\relax }}{4}{figure.caption.3}\protected@file@percent }
+\providecommand*\caption@xref[2]{\@setref\relax\@undefined{#1}}
+\newlabel{concept_overview}{{2.1}{4}{Visualisierung des Konzepts\relax }{figure.caption.3}{}}
+\BKM@entry{id=8,dest={73656374696F6E2E322E32},srcline={33}}{5C3337365C3337375C303030535C303030695C3030306D5C303030755C3030306C5C303030615C303030745C303030695C3030306F5C3030306E5C3030305C3034305C303030645C303030655C303030735C3030305C3034305C3030304D5C303030655C3030306E5C303030735C303030635C303030685C303030655C3030306E}
+\BKM@entry{id=9,dest={73656374696F6E2E322E33},srcline={46}}{5C3337365C3337375C303030425C303030655C303030685C303030615C303030765C303030695C3030306F5C303030725C3030305C3034305C303030545C303030725C303030655C303030655C303030735C3030305C3034305C303030615C3030306C5C303030735C3030305C3034305C303030425C303030655C303030735C303030635C303030685C303030725C303030655C303030695C303030625C303030755C3030306E5C303030675C303030735C303030735C303030705C303030725C303030615C303030635C303030685C30303065}
+\@writefile{toc}{\contentsline {section}{\numberline {2.2}Simulation des Menschen}{5}{section.2.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2.3}Behavior Trees als Beschreibungssprache}{5}{section.2.3}\protected@file@percent }
+\abx@aux@cite{0}{1087032}
+\abx@aux@segm{0}{0}{1087032}
+\abx@aux@cite{0}{isla2005handling}
+\abx@aux@segm{0}{0}{isla2005handling}
+\BKM@entry{id=10,dest={73656374696F6E2E322E34},srcline={110}}{5C3337365C3337375C303030565C303030695C303030725C303030745C303030755C303030615C3030306C5C303030695C303030735C303030695C303030655C303030725C303030755C3030306E5C303030675C303030735C303030755C3030306D5C303030675C303030655C303030625C303030755C3030306E5C303030675C3030305C3034305C303030615C3030306C5C303030735C3030305C3034305C303030505C3030306C5C303030615C303030745C303030665C3030306F5C303030725C3030306D}
+\@writefile{lof}{\contentsline {figure}{\numberline {2.2}{\ignorespaces Beispiel eines BehaviorTrees\relax }}{7}{figure.caption.4}\protected@file@percent }
+\newlabel{concept_tree_demo}{{2.2}{7}{Beispiel eines BehaviorTrees\relax }{figure.caption.4}{}}
+\@writefile{toc}{\contentsline {section}{\numberline {2.4}Virtualisierungsumgebung als Platform}{7}{section.2.4}\protected@file@percent }
+\BKM@entry{id=11,dest={636861707465722E33},srcline={1}}{5C3337365C3337375C3030304B5C3030306F5C3030306D5C303030705C3030306F5C3030306E5C303030655C3030306E5C303030745C303030655C3030306E5C3030302D5C3030302F5C303030535C3030306F5C303030665C303030745C303030775C303030615C303030725C303030655C303030615C303030755C303030735C303030775C303030615C303030685C3030306C}
+\BKM@entry{id=12,dest={73656374696F6E2E332E31},srcline={7}}{5C3337365C3337375C303030445C303030695C303030655C3030306E5C303030735C303030745C303030755C3030306D5C303030675C303030655C303030625C303030755C3030306E5C30303067}
+\BKM@entry{id=13,dest={73756273656374696F6E2E332E312E31},srcline={14}}{5C3337365C3337375C303030415C303030755C303030735C303030775C303030615C303030685C3030306C}
+\@writefile{toc}{\contentsline {chapter}{\numberline {3}Komponenten-/Softwareauswahl}{9}{chapter.3}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {3.1}Dienstumgebung}{9}{section.3.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.1}Auswahl}{9}{subsection.3.1.1}\protected@file@percent }
+\abx@aux@cite{0}{doi:10.1126/scirobotics.abm6074}
+\abx@aux@segm{0}{0}{doi:10.1126/scirobotics.abm6074}
+\abx@aux@cite{0}{python}
+\abx@aux@segm{0}{0}{python}
+\abx@aux@cite{0}{cpp}
+\abx@aux@segm{0}{0}{cpp}
+\abx@aux@cite{0}{cmake}
+\abx@aux@segm{0}{0}{cmake}
+\abx@aux@cite{0}{rospackages}
+\abx@aux@segm{0}{0}{rospackages}
+\BKM@entry{id=14,dest={73756273656374696F6E2E332E312E32},srcline={51}}{5C3337365C3337375C303030425C303030655C303030735C303030635C303030685C303030725C303030655C303030695C303030625C303030755C3030306E5C30303067}
+\abx@aux@cite{0}{doi:10.1126/scirobotics.abm6074}
+\abx@aux@segm{0}{0}{doi:10.1126/scirobotics.abm6074}
+\abx@aux@cite{0}{ros-git}
+\abx@aux@segm{0}{0}{ros-git}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.2}Beschreibung}{10}{subsection.3.1.2}\protected@file@percent }
+\abx@aux@cite{0}{colcon}
+\abx@aux@segm{0}{0}{colcon}
+\abx@aux@cite{0}{cmake}
+\abx@aux@segm{0}{0}{cmake}
+\BKM@entry{id=15,dest={73656374696F6E2E332E32},srcline={109}}{5C3337365C3337375C303030535C303030695C3030306D5C303030755C3030306C5C303030615C303030745C303030695C3030306F5C3030306E5C303030735C303030755C3030306D5C303030675C303030655C303030625C303030755C3030306E5C303030675C3030305C3034305C3030305C3035305C303030475C303030615C3030307A5C303030655C303030625C3030306F5C3030305C303531}
+\BKM@entry{id=16,dest={73756273656374696F6E2E332E322E31},srcline={111}}{5C3337365C3337375C303030415C303030755C303030735C303030775C303030615C303030685C3030306C}
+\abx@aux@cite{0}{coppelia}
+\abx@aux@segm{0}{0}{coppelia}
+\@writefile{toc}{\contentsline {section}{\numberline {3.2}Simulationsumgebung (Gazebo)}{12}{section.3.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.2.1}Auswahl}{12}{subsection.3.2.1}\protected@file@percent }
+\abx@aux@cite{0}{gazebo}
+\abx@aux@segm{0}{0}{gazebo}
+\abx@aux@cite{0}{unity}
+\abx@aux@segm{0}{0}{unity}
+\abx@aux@cite{0}{unreal}
+\abx@aux@segm{0}{0}{unreal}
+\abx@aux@cite{0}{godot}
+\abx@aux@segm{0}{0}{godot}
+\BKM@entry{id=17,dest={73756273656374696F6E2E332E322E32},srcline={156}}{5C3337365C3337375C303030575C303030655C3030306C5C303030745C3030302D5C3030305C3034305C303030755C3030306E5C303030645C3030305C3034305C3030304D5C3030306F5C303030645C303030655C3030306C5C3030306C5C303030625C303030655C303030735C303030635C303030685C303030725C303030655C303030695C303030625C303030755C3030306E5C30303067}
+\abx@aux@cite{0}{sdf-format}
+\abx@aux@segm{0}{0}{sdf-format}
+\abx@aux@cite{0}{gazebo-app}
+\abx@aux@segm{0}{0}{gazebo-app}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.2.2}Welt- und Modellbeschreibung}{14}{subsection.3.2.2}\protected@file@percent }
+\BKM@entry{id=18,dest={73756273656374696F6E2E332E322E33},srcline={192}}{5C3337365C3337375C303030525C3030306F5C303030625C3030306F5C303030745C303030655C303030725C303030735C303030695C3030306D5C303030755C3030306C5C303030615C303030745C303030695C3030306F5C3030306E}
+\abx@aux@cite{0}{urdf-format}
+\abx@aux@segm{0}{0}{urdf-format}
+\BKM@entry{id=19,dest={73756273656374696F6E2E332E322E34},srcline={222}}{5C3337365C3337375C3030304D5C303030655C3030306E5C303030735C303030635C303030685C303030655C3030306E5C303030735C303030695C3030306D5C303030755C3030306C5C303030615C303030745C303030695C3030306F5C3030306E}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.2.3}Robotersimulation}{15}{subsection.3.2.3}\protected@file@percent }
+\BKM@entry{id=20,dest={73656374696F6E2E332E33},srcline={238}}{5C3337365C3337375C303030525C3030306F5C303030625C3030306F5C303030745C303030655C303030725C303030755C3030306D5C303030675C303030655C303030625C303030755C3030306E5C30303067}
+\abx@aux@cite{0}{moveit-docs}
+\abx@aux@segm{0}{0}{moveit-docs}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.2.4}Menschensimulation}{16}{subsection.3.2.4}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3.3}Roboterumgebung}{16}{section.3.3}\protected@file@percent }
+\abx@aux@cite{0}{moveitpython}
+\abx@aux@segm{0}{0}{moveitpython}
+\BKM@entry{id=21,dest={73656374696F6E2E332E34},srcline={279}}{5C3337365C3337375C303030505C303030725C3030306F5C303030675C303030725C303030615C3030306D5C3030306D5C303030695C303030655C303030725C303030735C303030705C303030725C303030615C303030635C303030685C30303065}
+\abx@aux@cite{0}{python}
+\abx@aux@segm{0}{0}{python}
+\abx@aux@cite{0}{cpp}
+\abx@aux@segm{0}{0}{cpp}
+\BKM@entry{id=22,dest={73656374696F6E2E332E35},srcline={303}}{5C3337365C3337375C303030425C303030655C303030685C303030615C303030765C303030695C3030306F5C303030725C3030305C3034305C303030545C303030725C303030655C303030655C30303073}
+\@writefile{toc}{\contentsline {section}{\numberline {3.4}Programmiersprache}{18}{section.3.4}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3.5}Behavior Trees}{18}{section.3.5}\protected@file@percent }
+\BKM@entry{id=23,dest={73756273656374696F6E2E332E352E31},srcline={352}}{5C3337365C3337375C303030415C303030735C303030795C3030306E5C303030635C303030685C303030725C3030306F5C3030306E5C303030655C3030305C3034305C3030304E5C3030306F5C303030645C303030655C30303073}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.5.1}Asynchrone Nodes}{20}{subsection.3.5.1}\protected@file@percent }
+\BKM@entry{id=24,dest={73756273656374696F6E2E332E352E32},srcline={369}}{5C3337365C3337375C303030445C303030615C303030745C303030655C303030695C303030665C3030306F5C303030725C3030306D5C303030615C30303074}
+\BKM@entry{id=25,dest={73656374696F6E2E332E36},srcline={408}}{5C3337365C3337375C303030445C3030306F5C303030635C3030306B5C303030655C303030725C3030302D5C303030435C3030306F5C3030306D5C303030705C3030306F5C303030735C303030655C3030305C3034305C303030615C3030306C5C303030735C3030305C3034305C303030565C303030695C303030725C303030745C303030755C303030615C3030306C5C303030695C303030735C303030695C303030655C303030725C303030755C3030306E5C303030675C303030735C303030755C3030306D5C303030675C303030655C303030625C303030755C3030306E5C30303067}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.5.2}Dateiformat}{21}{subsection.3.5.2}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {3.1}{\ignorespaces Beispiel eines BehaviorTrees\relax }}{21}{figure.caption.5}\protected@file@percent }
+\newlabel{choice_tree_demo}{{3.1}{21}{Beispiel eines BehaviorTrees\relax }{figure.caption.5}{}}
+\@writefile{lof}{\contentsline {figure}{\numberline {3.2}{\ignorespaces Beispiel eines BehaviorTrees als .xml\relax }}{22}{figure.caption.6}\protected@file@percent }
+\newlabel{choice_tree_xml}{{3.2}{22}{Beispiel eines BehaviorTrees als .xml\relax }{figure.caption.6}{}}
+\@writefile{toc}{\contentsline {section}{\numberline {3.6}Docker-Compose als Virtualisierungsumgebung}{22}{section.3.6}\protected@file@percent }
+\BKM@entry{id=26,dest={636861707465722E34},srcline={1}}{5C3337365C3337375C303030555C3030306D5C303030735C303030655C303030745C3030307A5C303030755C3030306E5C30303067}
+\BKM@entry{id=27,dest={73656374696F6E2E342E31},srcline={20}}{5C3337365C3337375C303030445C3030306F5C303030635C3030306B5C303030655C303030725C3030302D5C303030435C3030306F5C3030306D5C303030705C3030306F5C303030735C30303065}
+\@writefile{toc}{\contentsline {chapter}{\numberline {4}Umsetzung}{24}{chapter.4}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.1}{\ignorespaces Visualisierung des überarbeiteten Konzepts\relax }}{24}{figure.caption.7}\protected@file@percent }
+\newlabel{umsetzung_overview}{{4.1}{24}{Visualisierung des überarbeiteten Konzepts\relax }{figure.caption.7}{}}
+\@writefile{toc}{\contentsline {section}{\numberline {4.1}Docker-Compose}{25}{section.4.1}\protected@file@percent }
+\BKM@entry{id=28,dest={73656374696F6E2E342E32},srcline={68}}{5C3337365C3337375C303030455C3030306E5C303030745C303030775C303030695C303030635C3030306B5C3030306C5C303030755C3030306E5C303030675C303030735C303030755C3030306D5C303030675C303030655C303030625C303030755C3030306E5C30303067}
+\@writefile{toc}{\contentsline {section}{\numberline {4.2}Entwicklungsumgebung}{26}{section.4.2}\protected@file@percent }
+\BKM@entry{id=29,dest={73656374696F6E2E342E33},srcline={109}}{5C3337365C3337375C303030565C303030655C303030725C303030775C303030655C3030306E5C303030645C303030655C303030745C303030655C3030305C3034305C303030445C303030615C303030745C303030655C3030306E5C303030745C303030795C303030705C303030655C3030306E}
+\@writefile{toc}{\contentsline {section}{\numberline {4.3}Verwendete Datentypen}{27}{section.4.3}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {4.2}{\ignorespaces Entwicklungsumgebung Lapce\relax }}{28}{figure.caption.8}\protected@file@percent }
+\newlabel{lapce}{{4.2}{28}{Entwicklungsumgebung Lapce\relax }{figure.caption.8}{}}
+\BKM@entry{id=30,dest={73656374696F6E2E342E34},srcline={138}}{5C3337365C3337375C303030535C303030695C3030306D5C303030755C3030306C5C303030615C303030745C303030695C3030306F5C3030306E5C303030735C303030775C303030655C3030306C5C30303074}
+\@writefile{toc}{\contentsline {section}{\numberline {4.4}Simulationswelt}{29}{section.4.4}\protected@file@percent }
+\BKM@entry{id=31,dest={73656374696F6E2E342E35},srcline={177}}{5C3337365C3337375C3030304D5C303030655C3030306E5C303030735C303030635C30303068}
+\BKM@entry{id=32,dest={73756273656374696F6E2E342E352E31},srcline={178}}{5C3337365C3337375C3030305C3333345C303030625C303030655C303030725C303030735C303030695C303030635C303030685C30303074}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.3}{\ignorespaces Geplanter Raum\relax }}{30}{figure.caption.9}\protected@file@percent }
+\newlabel{room-plan}{{4.3}{30}{Geplanter Raum\relax }{figure.caption.9}{}}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.4}{\ignorespaces Umsetzung in Blender\relax }}{30}{figure.caption.9}\protected@file@percent }
+\newlabel{room-finished}{{4.4}{30}{Umsetzung in Blender\relax }{figure.caption.9}{}}
+\BKM@entry{id=33,dest={73756273656374696F6E2E342E352E32},srcline={191}}{5C3337365C3337375C3030304D5C3030306F5C303030645C303030655C3030306C5C3030306C5C303030695C303030655C303030725C303030755C3030306E5C30303067}
+\abx@aux@cite{0}{rigify}
+\abx@aux@segm{0}{0}{rigify}
+\@writefile{toc}{\contentsline {section}{\numberline {4.5}Mensch}{31}{section.4.5}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.5.1}Übersicht}{31}{subsection.4.5.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.5.2}Modellierung}{31}{subsection.4.5.2}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {4.5}{\ignorespaces Knochen des Modells\relax }}{32}{figure.caption.10}\protected@file@percent }
+\newlabel{person-bones}{{4.5}{32}{Knochen des Modells\relax }{figure.caption.10}{}}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.6}{\ignorespaces Armaturen des Modells\relax }}{32}{figure.caption.10}\protected@file@percent }
+\newlabel{person-armature}{{4.6}{32}{Armaturen des Modells\relax }{figure.caption.10}{}}
+\BKM@entry{id=34,dest={73756273656374696F6E2E342E352E33},srcline={272}}{5C3337365C3337375C303030455C303030785C303030705C3030306F5C303030725C303030745C3030305C3034305C303030645C303030655C303030725C3030305C3034305C3030304D5C3030306F5C303030645C303030655C3030306C5C3030306C5C303030615C3030306E5C303030695C3030306D5C303030615C303030745C303030695C3030306F5C3030306E5C303030655C3030306E}
+\abx@aux@cite{0}{gamerig}
+\abx@aux@segm{0}{0}{gamerig}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.7}{\ignorespaces Visualisierung der generierten Beugeachse\relax }}{34}{figure.caption.11}\protected@file@percent }
+\newlabel{bend}{{4.7}{34}{Visualisierung der generierten Beugeachse\relax }{figure.caption.11}{}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.5.3}Export der Modellanimationen}{34}{subsection.4.5.3}\protected@file@percent }
+\BKM@entry{id=35,dest={73756273656374696F6E2E342E352E34},srcline={326}}{5C3337365C3337375C303030505C303030725C3030306F5C303030675C303030725C303030615C3030306D5C3030306D5C303030695C303030655C303030725C303030755C3030306E5C30303067}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.8}{\ignorespaces Vorbereitung zum Export mit GameRig\relax }}{36}{figure.caption.12}\protected@file@percent }
+\newlabel{export-prepare}{{4.8}{36}{Vorbereitung zum Export mit GameRig\relax }{figure.caption.12}{}}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.9}{\ignorespaces Benötigte Exporteinstellungen in Blender\relax }}{36}{figure.caption.13}\protected@file@percent }
+\newlabel{export-settings}{{4.9}{36}{Benötigte Exporteinstellungen in Blender\relax }{figure.caption.13}{}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.5.4}Programmierung}{37}{subsection.4.5.4}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Message Queue}{37}{subsubsection*.15}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Nachrichten}{38}{subsubsection*.17}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline ActorPlugin}{39}{subsubsection*.19}\protected@file@percent }
+\BKM@entry{id=36,dest={73656374696F6E2E342E36},srcline={438}}{5C3337365C3337375C303030525C3030306F5C303030625C3030306F5C303030745C303030655C30303072}
+\BKM@entry{id=37,dest={73756273656374696F6E2E342E362E31},srcline={439}}{5C3337365C3337375C3030305C3333345C303030625C303030655C303030725C303030735C303030695C303030635C303030685C30303074}
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline ActorServer}{40}{subsubsection*.21}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {4.6}Roboter}{40}{section.4.6}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.6.1}Übersicht}{40}{subsection.4.6.1}\protected@file@percent }
+\BKM@entry{id=38,dest={73756273656374696F6E2E342E362E32},srcline={447}}{5C3337365C3337375C3030304D5C3030306F5C303030645C303030655C3030306C5C3030306C5C303030695C303030655C303030725C303030755C3030306E5C30303067}
+\abx@aux@cite{0}{freecad}
+\abx@aux@segm{0}{0}{freecad}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.10}{\ignorespaces Rohdaten aus .stl-Datei\relax }}{41}{figure.caption.22}\protected@file@percent }
+\newlabel{robot_raw}{{4.10}{41}{Rohdaten aus .stl-Datei\relax }{figure.caption.22}{}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.6.2}Modellierung}{41}{subsection.4.6.2}\protected@file@percent }
+\BKM@entry{id=39,dest={73756273656374696F6E2E342E362E33},srcline={494}}{5C3337365C3337375C3030304D5C3030306F5C303030765C303030655C303030495C303030745C3030305C3034305C303030325C3030305C3034305C3030304B5C3030306F5C3030306E5C303030665C303030695C303030675C303030755C303030725C303030615C303030745C303030695C3030306F5C3030306E}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.11}{\ignorespaces Visuelles Modell\relax }}{42}{figure.caption.23}\protected@file@percent }
+\newlabel{robot_visual}{{4.11}{42}{Visuelles Modell\relax }{figure.caption.23}{}}
+\@writefile{lof}{\contentsline {figure}{\numberline {4.12}{\ignorespaces Kollisionsmodell\relax }}{42}{figure.caption.23}\protected@file@percent }
+\newlabel{robot_collision}{{4.12}{42}{Kollisionsmodell\relax }{figure.caption.23}{}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.6.3}MoveIt 2 Konfiguration}{42}{subsection.4.6.3}\protected@file@percent }
+\BKM@entry{id=40,dest={73756273656374696F6E2E342E362E34},srcline={509}}{5C3337365C3337375C303030495C3030306E5C303030745C303030655C303030675C303030725C303030615C303030745C303030695C3030306F5C3030306E5C3030305C3034305C3030306D5C303030695C303030745C3030305C3034305C303030475C303030615C3030307A5C303030655C303030625C3030306F}
+\BKM@entry{id=41,dest={73656374696F6E2E342E37},srcline={521}}{5C3337365C3337375C303030425C303030655C303030685C303030615C303030765C303030695C3030306F5C303030725C3030305C3034305C303030545C303030725C303030655C303030655C30303073}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.6.4}Integration mit Gazebo}{43}{subsection.4.6.4}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {4.7}Behavior Trees}{43}{section.4.7}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Allgemein nutzbare Nodes}{44}{subsubsection*.25}\protected@file@percent }
+\BKM@entry{id=42,dest={73756273656374696F6E2E342E372E31},srcline={595}}{5C3337365C3337375C303030535C303030755C303030625C303030745C303030725C303030655C303030655C30303073}
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Menschenspezifisch}{45}{subsubsection*.27}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Roboterspezifisch}{45}{subsubsection*.29}\protected@file@percent }
+\BKM@entry{id=43,dest={73756273656374696F6E2E342E372E32},srcline={599}}{5C3337365C3337375C303030565C303030655C303030725C303030685C303030615C3030306C5C303030745C303030655C3030306E5C3030305C3034305C303030645C303030655C303030735C3030305C3034305C303030525C3030306F5C303030625C3030306F5C303030745C303030655C303030725C30303073}
+\BKM@entry{id=44,dest={73756273656374696F6E2E342E372E33},srcline={601}}{5C3337365C3337375C303030565C303030655C303030725C303030685C303030615C3030306C5C303030745C303030655C3030306E5C3030305C3034305C303030645C303030655C303030735C3030305C3034305C3030304D5C303030655C3030306E5C303030735C303030635C303030685C303030655C3030306E}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.7.1}Subtrees}{46}{subsection.4.7.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.7.2}Verhalten des Roboters}{46}{subsection.4.7.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.7.3}Verhalten des Menschen}{46}{subsection.4.7.3}\protected@file@percent }
+\BKM@entry{id=45,dest={636861707465722E35},srcline={101}}{5C3337365C3337375C303030535C3030307A5C303030655C3030306E5C303030615C303030725C303030695C303030655C3030306E5C303030625C303030615C303030735C303030695C303030655C303030725C303030745C303030655C3030305C3034305C303030455C303030765C303030615C3030306C5C303030755C303030615C303030745C303030695C3030306F5C3030306E}
+\BKM@entry{id=46,dest={73656374696F6E2E352E31},srcline={102}}{5C3337365C3337375C303030535C303030695C3030306D5C303030755C3030306C5C303030615C303030745C303030695C3030306F5C3030306E5C3030305C3034305C303030645C303030655C303030735C3030305C3034305C3030304D5C303030655C3030306E5C303030735C303030635C303030685C303030655C3030306E}
+\BKM@entry{id=47,dest={73656374696F6E2E352E32},srcline={106}}{5C3337365C3337375C303030425C303030655C303030775C303030655C303030675C303030755C3030306E5C303030675C3030305C3034305C303030645C303030655C303030735C3030305C3034305C303030525C3030306F5C303030625C3030306F5C303030745C303030655C303030725C30303073}
+\BKM@entry{id=48,dest={73656374696F6E2E352E33},srcline={112}}{5C3337365C3337375C303030425C303030655C303030685C303030615C303030765C303030695C3030306F5C303030725C303030545C303030725C303030655C303030655C30303073}
+\BKM@entry{id=49,dest={73756273656374696F6E2E352E332E31},srcline={113}}{5C3337365C3337375C3030304E5C3030306F5C303030645C303030655C30303073}
+\BKM@entry{id=50,dest={73756273656374696F6E2E352E332E32},srcline={117}}{5C3337365C3337375C3030304B5C3030306F5C3030306D5C303030625C303030695C3030306E5C303030695C303030655C303030725C303030655C3030306E5C3030305C3034305C303030765C3030306F5C3030306E5C3030305C3034305C3030304E5C3030306F5C303030645C303030655C303030735C3030305C3034305C3030307A5C303030755C3030305C3034305C303030655C303030695C3030306E5C303030655C303030725C3030305C3034305C303030525C303030655C303030715C303030755C303030655C303030735C30303074}
+\@writefile{toc}{\contentsline {chapter}{\numberline {5}Szenarienbasierte Evaluation}{47}{chapter.5}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {5.1}Simulation des Menschen}{47}{section.5.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {5.2}Bewegung des Roboters}{47}{section.5.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {5.3}BehaviorTrees}{47}{section.5.3}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.3.1}Nodes}{47}{subsection.5.3.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.3.2}Kombinieren von Nodes zu einer Request}{47}{subsection.5.3.2}\protected@file@percent }
+\BKM@entry{id=51,dest={636861707465722E36},srcline={121}}{5C3337365C3337375C303030445C303030695C303030735C3030306B5C303030755C303030735C303030735C303030695C3030306F5C3030306E}
+\BKM@entry{id=52,dest={73656374696F6E2E362E31},srcline={122}}{5C3337365C3337375C3030304C5C303030655C303030735C303030735C3030306F5C3030306E5C303030735C3030305C3034305C3030304C5C303030655C303030615C303030725C3030306E5C303030655C303030645C3030305C3034305C303030625C303030655C303030695C3030305C3034305C303030645C303030655C303030725C3030305C3034305C303030555C3030306D5C303030735C303030655C303030745C3030307A5C303030755C3030306E5C30303067}
+\BKM@entry{id=53,dest={73756273656374696F6E2E362E312E31},srcline={126}}{5C3337365C3337375C303030455C303030725C303030735C303030745C303030655C3030306C5C3030306C5C303030755C3030306E5C303030675C3030305C3034305C303030645C303030655C303030735C3030305C3034305C303030525C3030306F5C303030625C3030306F5C303030745C303030655C303030725C3030306D5C3030306F5C303030645C303030655C3030306C5C3030306C5C30303073}
+\BKM@entry{id=54,dest={73756273656374696F6E2E362E312E32},srcline={132}}{5C3337365C3337375C303030455C303030725C303030775C303030655C303030695C303030745C303030655C303030725C303030755C3030306E5C303030675C3030305C3034305C303030645C303030655C303030735C3030305C3034305C303030525C3030306F5C303030625C3030306F5C303030745C303030655C303030725C3030306D5C3030306F5C303030645C303030655C3030306C5C3030306C5C303030735C3030305C3034305C3030306D5C303030695C303030745C3030305C3034305C3030304D5C3030306F5C303030765C303030655C303030495C30303074}
+\BKM@entry{id=55,dest={73756273656374696F6E2E362E312E33},srcline={136}}{5C3337365C3337375C303030475C303030615C3030307A5C303030655C303030625C3030306F}
+\@writefile{toc}{\contentsline {chapter}{\numberline {6}Diskussion}{48}{chapter.6}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {6.1}Lessons Learned bei der Umsetzung}{48}{section.6.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {6.1.1}Erstellung des Robotermodells}{48}{subsection.6.1.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {6.1.2}Erweiterung des Robotermodells mit MoveIt}{48}{subsection.6.1.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {6.1.3}Gazebo}{48}{subsection.6.1.3}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Upgrade auf Ignition}{48}{subsubsection*.31}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Pluginarchitektur}{49}{subsubsection*.33}\protected@file@percent }
+\BKM@entry{id=56,dest={73756273656374696F6E2E362E312E34},srcline={183}}{5C3337365C3337375C303030525C3030304F5C303030535C30303032}
+\BKM@entry{id=57,dest={73756273656374696F6E2E362E312E35},srcline={190}}{5C3337365C3337375C3030304D5C3030306F5C303030765C303030655C303030495C303030745C30303032}
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Fehlende Animationsgrundlagen}{50}{subsubsection*.35}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {6.1.4}ROS2}{50}{subsection.6.1.4}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Nachrichten und deren Echtzeitfähigkeit}{50}{subsubsection*.37}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Änderung der Compilertoolchain}{50}{subsubsection*.39}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {6.1.5}MoveIt2}{50}{subsection.6.1.5}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Upgrade auf MoveIt2}{50}{subsubsection*.41}\protected@file@percent }
+\BKM@entry{id=58,dest={73656374696F6E2E362E32},srcline={203}}{5C3337365C3337375C3030304C5C303030655C303030735C303030735C3030306F5C3030306E5C303030735C3030305C3034305C3030304C5C303030655C303030615C303030725C3030306E5C303030655C303030645C3030305C3034305C303030625C303030655C303030695C3030305C3034305C303030645C303030655C3030306E5C3030305C3034305C303030535C3030307A5C303030655C3030306E5C303030615C303030725C303030695C303030655C3030306E}
+\BKM@entry{id=59,dest={73756273656374696F6E2E362E322E31},srcline={204}}{5C3337365C3337375C303030445C303030655C303030625C303030755C303030675C303030675C303030695C3030306E5C30303067}
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Fehlerhafte Generierung der Roboter}{51}{subsubsection*.43}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\nonumberline Controller}{51}{subsubsection*.45}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {6.2}Lessons Learned bei den Szenarien}{51}{section.6.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {6.2.1}Debugging}{51}{subsection.6.2.1}\protected@file@percent }
+\BKM@entry{id=60,dest={636861707465722E37},srcline={210}}{5C3337365C3337375C3030305A5C303030755C303030735C303030615C3030306D5C3030306D5C303030655C3030306E5C303030665C303030615C303030735C303030735C303030755C3030306E5C303030675C3030305C3034305C303030755C3030306E5C303030645C3030305C3034305C303030415C303030755C303030735C303030625C3030306C5C303030695C303030635C3030306B}
+\BKM@entry{id=61,dest={73656374696F6E2E372E31},srcline={211}}{5C3337365C3337375C303030455C303030725C303030675C303030655C303030625C3030306E5C303030695C303030735C303030735C30303065}
+\BKM@entry{id=62,dest={73756273656374696F6E2E372E312E31},srcline={212}}{5C3337365C3337375C303030475C303030725C303030615C303030705C303030685C303030695C303030735C303030635C303030685C303030655C3030305C3034305C303030525C303030655C303030705C303030725C3030305C3334345C303030735C303030655C3030306E5C303030745C303030615C303030745C303030695C3030306F5C3030306E5C3030305C3034305C303030645C303030655C303030725C3030305C3034305C303030535C3030307A5C303030655C3030306E5C303030615C303030725C303030695C303030655C3030306E}
+\BKM@entry{id=63,dest={73756273656374696F6E2E372E312E32},srcline={214}}{5C3337365C3337375C303030415C3030306E5C303030705C303030615C303030735C303030735C303030755C3030306E5C303030675C3030305C3034305C303030645C303030655C303030725C3030305C3034305C303030425C303030655C303030685C303030615C303030765C303030695C3030306F5C303030725C3030305C3034305C303030545C303030725C303030655C303030655C303030735C3030305C3034305C303030615C3030306E5C3030305C3034305C303030535C3030307A5C303030655C3030306E5C303030615C303030725C303030695C303030655C3030306E}
+\BKM@entry{id=64,dest={73656374696F6E2E372E32},srcline={216}}{5C3337365C3337375C303030445C303030695C303030735C3030306B5C303030755C303030735C303030735C303030695C3030306F5C3030306E}
+\BKM@entry{id=65,dest={73656374696F6E2E372E33},srcline={224}}{5C3337365C3337375C303030415C303030755C303030735C303030625C3030306C5C303030695C303030635C3030306B}
+\BKM@entry{id=66,dest={73756273656374696F6E2E372E332E31},srcline={225}}{5C3337365C3337375C303030555C3030306D5C303030735C303030655C303030745C3030307A5C303030755C3030306E5C303030675C3030305C3034305C303030695C3030306E5C3030305C3034305C303030615C3030306E5C303030645C303030655C303030725C303030655C3030306D5C3030305C3034305C303030535C303030695C3030306D5C303030755C3030306C5C303030615C303030745C3030306F5C30303072}
+\BKM@entry{id=67,dest={73756273656374696F6E2E372E332E32},srcline={229}}{5C3337365C3337375C303030535C303030695C3030306D5C303030755C3030306C5C303030615C303030745C303030695C3030306F5C3030306E5C3030305C3034305C303030625C303030655C303030775C303030655C303030675C303030745C303030655C303030725C3030305C3034305C3030304F5C303030625C3030306A5C303030655C3030306B5C303030745C30303065}
+\BKM@entry{id=68,dest={73756273656374696F6E2E372E332E33},srcline={231}}{5C3337365C3337375C303030455C303030725C303030675C3030305C3334345C3030306E5C3030307A5C303030755C3030306E5C303030675C3030305C3034305C303030765C3030306F5C3030306E5C3030305C3034305C303030555C3030306D5C303030675C303030655C303030625C303030755C3030306E5C303030675C303030735C303030655C303030725C3030306B5C303030655C3030306E5C3030306E5C303030755C3030306E5C30303067}
+\@writefile{toc}{\contentsline {chapter}{\numberline {7}Zusammenfassung und Ausblick}{52}{chapter.7}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {7.1}Ergebnisse}{52}{section.7.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.1.1}Graphische Repräsentation der Szenarien}{52}{subsection.7.1.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.1.2}Anpassung der Behavior Trees an Szenarien}{52}{subsection.7.1.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {7.2}Diskussion}{52}{section.7.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {7.3}Ausblick}{52}{section.7.3}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.3.1}Umsetzung in anderem Simulator}{52}{subsection.7.3.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.3.2}Simulation bewegter Objekte}{52}{subsection.7.3.2}\protected@file@percent }
+\abx@aux@cite{0}{octomap}
+\abx@aux@segm{0}{0}{octomap}
+\BKM@entry{id=69,dest={73756273656374696F6E2E372E332E34},srcline={237}}{5C3337365C3337375C3030305A5C303030755C303030735C303030615C3030306D5C3030306D5C303030655C3030306E5C303030625C303030725C303030695C3030306E5C303030675C303030655C3030306E5C3030305C3034305C303030765C3030306F5C3030306E5C3030305C3034305C303030415C303030635C303030745C3030306F5C303030725C303030505C3030306C5C303030755C303030675C303030695C3030306E5C3030305C3034305C303030755C3030306E5C303030645C3030305C3034305C303030415C303030635C303030745C3030306F5C303030725C303030535C303030655C303030725C303030765C303030655C30303072}
+\BKM@entry{id=70,dest={73756273656374696F6E2E372E332E35},srcline={244}}{5C3337365C3337375C303030535C303030655C303030705C303030615C303030725C303030695C303030655C303030725C303030655C3030306E5C3030305C3034305C303030645C303030655C303030725C3030305C3034305C303030535C303030755C303030625C303030745C303030725C303030655C303030655C303030735C3030305C3034305C303030695C3030306E5C3030305C3034305C303030655C303030695C303030675C303030655C3030306E5C303030655C3030305C3034305C303030445C303030615C303030745C303030655C303030695C303030655C3030306E}
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.3.3}Ergänzung von Umgebungserkennung}{53}{subsection.7.3.3}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.3.4}Zusammenbringen von ActorPlugin und ActorServer}{53}{subsection.7.3.4}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.3.5}Separieren der Subtrees in eigene Dateien}{53}{subsection.7.3.5}\protected@file@percent }
+\abx@aux@cite{0}{moveitpipeline}
+\abx@aux@segm{0}{0}{moveitpipeline}
+\abx@aux@cite{0}{moveitpipeline}
+\abx@aux@segm{0}{0}{moveitpipeline}
+\gdef\minted@oldcachelist{,
+  default.pygstyle,
+  86994E17E7B794407C4C28872F16EC061EC630FA6AA4A122E827A2E31B1A68E1.pygtex,
+  391704321A86D34384492C034ECA3CFA82CA0C42AFE0759A4F1491A6B69BC02A.pygtex}
+\ACRO{total-barriers}{1}
+\providecommand\totalcount@set[2]{}
+\totalcount@set{page}{56}
+\@writefile{lof}{\contentsline {figure}{\numberline {7.1}{\ignorespaces Visualisierung der MoveIt Pipeline \cite {moveitpipeline}\relax }}{56}{figure.caption.47}\protected@file@percent }
+\newlabel{moveitpipeline}{{7.1}{56}{Visualisierung der MoveIt Pipeline \protect \cite {moveitpipeline}\relax }{figure.caption.47}{}}
+\ACRO{usage}{ros=={0}}
+\ACRO{usage}{fsm=={0}}
+\ACRO{usage}{mrk=={0}}
+\abx@aux@read@bbl@mdfivesum{615C50B9B95C7B88A6BAC6B451B896D1}
+\abx@aux@defaultrefcontext{0}{gamerig}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{1087032}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{cmake}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{cobot}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{colcon}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{btintro}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{ffdrobotsim}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{DOMBROWSKI2018134}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{freecad}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{gazebo}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{gazebo-app}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{halo2}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{ros-git}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{godot}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{isla2005handling}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{doi:10.1126/scirobotics.abm6074}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{moveit-docs}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{moveitpython}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{moveitpipeline}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{octomap}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{rospackages}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{rigify}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{coppelia}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{sdf-format}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{cpp}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{unreal}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{unity}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{urdf-format}{nty/global//global/global}
+\abx@aux@defaultrefcontext{0}{python}{nty/global//global/global}
+\global\@namedef{scr@dte@chapter@lastmaxnumwidth}{10.84041pt}
+\global\@namedef{scr@dte@section@lastmaxnumwidth}{18.37155pt}
+\global\@namedef{scr@dte@subsection@lastmaxnumwidth}{26.88818pt}
+\global\@namedef{scr@dte@figure@lastmaxnumwidth}{23.84654pt}
+\@writefile{toc}{\providecommand\tocbasic@end@toc@file{}\tocbasic@end@toc@file}
+\@writefile{lof}{\providecommand\tocbasic@end@toc@file{}\tocbasic@end@toc@file}
+\gdef \@abspage@last{63}

main.bbl

@@ -19,6 +19,74 @@
 
 \refsection{0}
   \datalist[entry]{nty/global//global/global}
+    \entry{gamerig}{misc}{}
+      \field{sortinit}{A}
+      \field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{Arminando/GameRig: GameRig is an auto rigging for games addon for Blender. Built on top of Rigify, it adds rigs, metarigs and additional functionality that enable game engine friendly rig creation. Open source and can be used for personal and commercial projects.}
+      \verb{urlraw}
+      \verb https://github.com/Arminando/GameRig
+      \endverb
+      \verb{url}
+      \verb https://github.com/Arminando/GameRig
+      \endverb
+    \endentry
+    \entry{1087032}{article}{}
+      \name{author}{1}{}{%
+        {{hash=3d750c4d36f30d3cb25be30be5c1870b}{%
+           family={Brooks},
+           familyi={B\bibinitperiod},
+           given={R.},
+           giveni={R\bibinitperiod}}}%
+      }
+      \strng{namehash}{3d750c4d36f30d3cb25be30be5c1870b}
+      \strng{fullhash}{3d750c4d36f30d3cb25be30be5c1870b}
+      \strng{bibnamehash}{3d750c4d36f30d3cb25be30be5c1870b}
+      \strng{authorbibnamehash}{3d750c4d36f30d3cb25be30be5c1870b}
+      \strng{authornamehash}{3d750c4d36f30d3cb25be30be5c1870b}
+      \strng{authorfullhash}{3d750c4d36f30d3cb25be30be5c1870b}
+      \field{sortinit}{B}
+      \field{sortinithash}{d7095fff47cda75ca2589920aae98399}
+      \field{labelnamesource}{author}
+      \field{labeltitlesource}{title}
+      \field{journaltitle}{IEEE Journal on Robotics and Automation}
+      \field{number}{1}
+      \field{title}{A robust layered control system for a mobile robot}
+      \field{volume}{2}
+      \field{year}{1986}
+      \field{pages}{14\bibrangedash 23}
+      \range{pages}{10}
+      \verb{doi}
+      \verb 10.1109/JRA.1986.1087032
+      \endverb
+    \endentry
+    \entry{cmake}{misc}{}
+      \field{sortinit}{C}
+      \field{sortinithash}{4d103a86280481745c9c897c925753c0}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{CMake}
+      \verb{urlraw}
+      \verb https://cmake.org/
+      \endverb
+      \verb{url}
+      \verb https://cmake.org/
+      \endverb
+    \endentry
+    \entry{cobot}{misc}{}
+      \field{sortinit}{C}
+      \field{sortinithash}{4d103a86280481745c9c897c925753c0}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 18.4.2022}
+      \field{title}{Cobots: der intelligente Roboter als Kollege}
+      \verb{urlraw}
+      \verb https://www.kuka.com/de-de/future-production/mensch-roboter-kollaboration/cobots
+      \endverb
+      \verb{url}
+      \verb https://www.kuka.com/de-de/future-production/mensch-roboter-kollaboration/cobots
+      \endverb
+    \endentry
     \entry{colcon}{misc}{}
       \field{sortinit}{c}
       \field{sortinithash}{4d103a86280481745c9c897c925753c0}
@@ -32,6 +100,175 @@
       \verb https://colcon.readthedocs.io/en/released/
       \endverb
     \endentry
+    \entry{btintro}{book}{}
+      \name{author}{2}{}{%
+        {{hash=db7c35906ea6fb15b4ad802938cde9b5}{%
+           family={Colledanchise},
+           familyi={C\bibinitperiod},
+           given={Michele},
+           giveni={M\bibinitperiod}}}%
+        {{hash=ebd3acb81e2d857e368ec17c18bec591}{%
+           family={Ögren},
+           familyi={Ö\bibinitperiod},
+           given={Petter},
+           giveni={P\bibinitperiod}}}%
+      }
+      \strng{namehash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
+      \strng{fullhash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
+      \strng{bibnamehash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
+      \strng{authorbibnamehash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
+      \strng{authornamehash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
+      \strng{authorfullhash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
+      \field{sortinit}{C}
+      \field{sortinithash}{4d103a86280481745c9c897c925753c0}
+      \field{labelnamesource}{author}
+      \field{labeltitlesource}{title}
+      \field{journaltitle}{CRC Press}
+      \field{title}{Behavior Trees in Robotics and AI - An Introduction}
+      \field{year}{2018}
+      \verb{doi}
+      \verb https://doi.org/10.1201/9780429489105
+      \endverb
+    \endentry
+    \entry{ffdrobotsim}{article}{}
+      \name{author}{3}{}{%
+        {{hash=f2dc35051dfb5b500d5402c64759f099}{%
+           family={Dombrowski},
+           familyi={D\bibinitperiod},
+           given={Uwe},
+           giveni={U\bibinitperiod}}}%
+        {{hash=68eeb042550b17c611d6249fcb1e14a7}{%
+           family={Stefanak},
+           familyi={S\bibinitperiod},
+           given={Tobias},
+           giveni={T\bibinitperiod}}}%
+        {{hash=9ec1975d8ae166000acc0cce4dcb58d7}{%
+           family={Perret},
+           familyi={P\bibinitperiod},
+           given={Jérôme},
+           giveni={J\bibinitperiod}}}%
+      }
+      \strng{namehash}{e4d9514f8a853c3f8392ba05b5ad0d42}
+      \strng{fullhash}{e4d9514f8a853c3f8392ba05b5ad0d42}
+      \strng{bibnamehash}{e4d9514f8a853c3f8392ba05b5ad0d42}
+      \strng{authorbibnamehash}{e4d9514f8a853c3f8392ba05b5ad0d42}
+      \strng{authornamehash}{e4d9514f8a853c3f8392ba05b5ad0d42}
+      \strng{authorfullhash}{e4d9514f8a853c3f8392ba05b5ad0d42}
+      \field{sortinit}{D}
+      \field{sortinithash}{6f385f66841fb5e82009dc833c761848}
+      \field{labelnamesource}{author}
+      \field{labeltitlesource}{title}
+      \field{journaltitle}{Procedia Manufacturing}
+      \field{month}{12}
+      \field{title}{Interactive Simulation of Human-robot Collaboration Using a Force Feedback Device}
+      \field{volume}{11}
+      \field{year}{2017}
+      \field{pages}{124\bibrangedash 131}
+      \range{pages}{8}
+      \verb{doi}
+      \verb 10.1016/j.promfg.2017.07.210
+      \endverb
+    \endentry
+    \entry{DOMBROWSKI2018134}{article}{}
+      \name{author}{3}{}{%
+        {{hash=f2dc35051dfb5b500d5402c64759f099}{%
+           family={Dombrowski},
+           familyi={D\bibinitperiod},
+           given={Uwe},
+           giveni={U\bibinitperiod}}}%
+        {{hash=68eeb042550b17c611d6249fcb1e14a7}{%
+           family={Stefanak},
+           familyi={S\bibinitperiod},
+           given={Tobias},
+           giveni={T\bibinitperiod}}}%
+        {{hash=db67f8b79eeeb57441d27000b23d527e}{%
+           family={Reimer},
+           familyi={R\bibinitperiod},
+           given={Anne},
+           giveni={A\bibinitperiod}}}%
+      }
+      \strng{namehash}{6b4730d5f57faa6cb0e5bcbbd4041102}
+      \strng{fullhash}{6b4730d5f57faa6cb0e5bcbbd4041102}
+      \strng{bibnamehash}{6b4730d5f57faa6cb0e5bcbbd4041102}
+      \strng{authorbibnamehash}{6b4730d5f57faa6cb0e5bcbbd4041102}
+      \strng{authornamehash}{6b4730d5f57faa6cb0e5bcbbd4041102}
+      \strng{authorfullhash}{6b4730d5f57faa6cb0e5bcbbd4041102}
+      \field{sortinit}{D}
+      \field{sortinithash}{6f385f66841fb5e82009dc833c761848}
+      \field{labelnamesource}{author}
+      \field{labeltitlesource}{title}
+      \field{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.}
+      \field{issn}{2351-9789}
+      \field{journaltitle}{Procedia Manufacturing}
+      \field{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}
+      \field{title}{Simulation of human-robot collaboration by means of power and force limiting}
+      \field{volume}{17}
+      \field{year}{2018}
+      \field{pages}{134\bibrangedash 141}
+      \range{pages}{8}
+      \verb{doi}
+      \verb https://doi.org/10.1016/j.promfg.2018.10.028
+      \endverb
+      \verb{urlraw}
+      \verb https://www.sciencedirect.com/science/article/pii/S2351978918311442
+      \endverb
+      \verb{url}
+      \verb https://www.sciencedirect.com/science/article/pii/S2351978918311442
+      \endverb
+      \keyw{Interactive simulation,collaborative robotics,occupational safety,health,manufacturing ergonomics,modeling,simulation,human factors,smart manufacturing}
+    \endentry
+    \entry{freecad}{misc}{}
+      \field{sortinit}{F}
+      \field{sortinithash}{2638baaa20439f1b5a8f80c6c08a13b4}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 21.04.2023}
+      \field{title}{FreeCAD: Ihr parametrischer 3D-Modellierer}
+      \verb{urlraw}
+      \verb https://www.freecad.org/index.php?lang=de
+      \endverb
+      \verb{url}
+      \verb https://www.freecad.org/index.php?lang=de
+      \endverb
+    \endentry
+    \entry{gazebo}{misc}{}
+      \field{sortinit}{G}
+      \field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{Gazebo}
+      \verb{urlraw}
+      \verb https://staging.gazebosim.org/home
+      \endverb
+      \verb{url}
+      \verb https://staging.gazebosim.org/home
+      \endverb
+    \endentry
+    \entry{gazebo-app}{misc}{}
+      \field{sortinit}{G}
+      \field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{Gazebo}
+      \verb{urlraw}
+      \verb https://app.gazebosim.org/dashboard
+      \endverb
+      \verb{url}
+      \verb https://app.gazebosim.org/dashboard
+      \endverb
+    \endentry
+    \entry{halo2}{misc}{}
+      \field{sortinit}{G}
+      \field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 18.05.2023}
+      \field{title}{GDC 2005 Proceeding: Handling Complexity in the Halo 2 AI}
+      \verb{urlraw}
+      \verb https://www.gamedeveloper.com/programming/gdc-2005-proceeding-handling-complexity-in-the-i-halo-2-i-ai
+      \endverb
+      \verb{url}
+      \verb https://www.gamedeveloper.com/programming/gdc-2005-proceeding-handling-complexity-in-the-i-halo-2-i-ai
+      \endverb
+    \endentry
     \entry{ros-git}{misc}{}
       \field{sortinit}{G}
       \field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
@@ -45,6 +282,40 @@
       \verb https://github.com/ros2/ros2
       \endverb
     \endentry
+    \entry{godot}{misc}{}
+      \field{sortinit}{G}
+      \field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 10.04.2023}
+      \field{title}{Godot Engine - Free and open source 2D and 3D game engine}
+      \verb{urlraw}
+      \verb https://godotengine.org
+      \endverb
+      \verb{url}
+      \verb https://godotengine.org
+      \endverb
+    \endentry
+    \entry{isla2005handling}{misc}{}
+      \name{author}{1}{}{%
+        {{hash=04a4610505a94b6883df923efb3f2f3e}{%
+           family={Isla},
+           familyi={I\bibinitperiod},
+           given={D},
+           giveni={D\bibinitperiod}}}%
+      }
+      \strng{namehash}{04a4610505a94b6883df923efb3f2f3e}
+      \strng{fullhash}{04a4610505a94b6883df923efb3f2f3e}
+      \strng{bibnamehash}{04a4610505a94b6883df923efb3f2f3e}
+      \strng{authorbibnamehash}{04a4610505a94b6883df923efb3f2f3e}
+      \strng{authornamehash}{04a4610505a94b6883df923efb3f2f3e}
+      \strng{authorfullhash}{04a4610505a94b6883df923efb3f2f3e}
+      \field{sortinit}{I}
+      \field{sortinithash}{8d291c51ee89b6cd86bf5379f0b151d8}
+      \field{labelnamesource}{author}
+      \field{labeltitlesource}{title}
+      \field{title}{Handling complexity in the halo 2 ai. GDC 2005 Proceedings}
+      \field{year}{2005}
+    \endentry
     \entry{doi:10.1126/scirobotics.abm6074}{article}{}
       \name{author}{5}{}{%
         {{hash=7b84d10a03303cd00f198fefb38a5da3}{%
@@ -100,6 +371,19 @@
       \verb https://www.science.org/doi/abs/10.1126/scirobotics.abm6074
       \endverb
     \endentry
+    \entry{moveit-docs}{misc}{}
+      \field{sortinit}{M}
+      \field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 13.4.2022}
+      \field{title}{MoveIt 2 Documentation}
+      \verb{urlraw}
+      \verb https://moveit.picknik.ai/galactic/index.html
+      \endverb
+      \verb{url}
+      \verb https://moveit.picknik.ai/galactic/index.html
+      \endverb
+    \endentry
     \entry{moveitpython}{misc}{}
       \field{sortinit}{M}
       \field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
@@ -126,6 +410,19 @@
       \verb https://github.com/ros-planning/moveit2_tutorials/blob/humble/_static/images/moveit_pipeline.png
       \endverb
     \endentry
+    \entry{octomap}{misc}{}
+      \field{sortinit}{O}
+      \field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 13.4.2022}
+      \field{title}{OctoMap}
+      \verb{urlraw}
+      \verb https://octomap.github.io
+      \endverb
+      \verb{url}
+      \verb https://octomap.github.io
+      \endverb
+    \endentry
     \entry{rospackages}{misc}{}
       \field{sortinit}{P}
       \field{sortinithash}{ff3bcf24f47321b42cb156c2cc8a8422}
@@ -139,6 +436,110 @@
       \verb http://packages.ros.org/ros2/ubuntu/pool/main/
       \endverb
     \endentry
+    \entry{rigify}{misc}{}
+      \field{sortinit}{R}
+      \field{sortinithash}{5e1c39a9d46ffb6bebd8f801023a9486}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{Rigify — Blender Manual}
+      \verb{urlraw}
+      \verb https://docs.blender.org/manual/en/3.5/addons/rigging/rigify/index.html
+      \endverb
+      \verb{url}
+      \verb https://docs.blender.org/manual/en/3.5/addons/rigging/rigify/index.html
+      \endverb
+    \endentry
+    \entry{coppelia}{misc}{}
+      \field{sortinit}{R}
+      \field{sortinithash}{5e1c39a9d46ffb6bebd8f801023a9486}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{Robot simulator CoppeliaSim: create, compose, simulate, any robot - Coppelia Robotics}
+      \verb{urlraw}
+      \verb https://www.coppeliarobotics.com/
+      \endverb
+      \verb{url}
+      \verb https://www.coppeliarobotics.com/
+      \endverb
+    \endentry
+    \entry{sdf-format}{misc}{}
+      \field{sortinit}{S}
+      \field{sortinithash}{b164b07b29984b41daf1e85279fbc5ab}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{SDFormat Specification}
+      \verb{urlraw}
+      \verb https://sdformat.org/spec
+      \endverb
+      \verb{url}
+      \verb https://sdformat.org/spec
+      \endverb
+    \endentry
+    \entry{cpp}{misc}{}
+      \field{sortinit}{S}
+      \field{sortinithash}{b164b07b29984b41daf1e85279fbc5ab}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{Standard C++}
+      \verb{urlraw}
+      \verb https://isocpp.org
+      \endverb
+      \verb{url}
+      \verb https://isocpp.org
+      \endverb
+    \endentry
+    \entry{unreal}{misc}{}
+      \field{sortinit}{T}
+      \field{sortinithash}{9af77f0292593c26bde9a56e688eaee9}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 10.04.2023}
+      \field{title}{The most powerful real-time 3D creation tool - Unreal Engine}
+      \verb{urlraw}
+      \verb https://www.unrealengine.com
+      \endverb
+      \verb{url}
+      \verb https://www.unrealengine.com
+      \endverb
+    \endentry
+    \entry{unity}{misc}{}
+      \field{sortinit}{U}
+      \field{sortinithash}{6901a00e45705986ee5e7ca9fd39adca}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 10.04.2023}
+      \field{title}{Unity Real-Time Development Platform | 3D, 2D, VR \& AR Engine}
+      \verb{urlraw}
+      \verb https://unity.com
+      \endverb
+      \verb{url}
+      \verb https://unity.com
+      \endverb
+    \endentry
+    \entry{urdf-format}{misc}{}
+      \field{sortinit}{u}
+      \field{sortinithash}{6901a00e45705986ee5e7ca9fd39adca}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{urdf/XML ROS Wiki}
+      \verb{urlraw}
+      \verb http://wiki.ros.org/urdf/XML
+      \endverb
+      \verb{url}
+      \verb http://wiki.ros.org/urdf/XML
+      \endverb
+    \endentry
+    \entry{python}{misc}{}
+      \field{sortinit}{W}
+      \field{sortinithash}{4315d78024d0cea9b57a0c6f0e35ed0d}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 23.04.2023}
+      \field{title}{Welcome to Python.org}
+      \verb{urlraw}
+      \verb https://www.python.org
+      \endverb
+      \verb{url}
+      \verb https://www.python.org
+      \endverb
+    \endentry
   \enddatalist
 \endrefsection
 \endinput

main.bcf

@@ -2361,13 +2361,41 @@
     <bcf:datasource type="file" datatype="bibtex" glob="false">main.bib</bcf:datasource>
   </bcf:bibdata>
   <bcf:section number="0">
-    <bcf:citekey order="1" intorder="1">rospackages</bcf:citekey>
+    <bcf:citekey order="1" intorder="1">moveitpipeline</bcf:citekey>
-    <bcf:citekey order="2" intorder="1">doi:10.1126/scirobotics.abm6074</bcf:citekey>
+    <bcf:citekey order="2" intorder="1">DOMBROWSKI2018134</bcf:citekey>
-    <bcf:citekey order="3" intorder="1">ros-git</bcf:citekey>
+    <bcf:citekey order="3" intorder="1">ffdrobotsim</bcf:citekey>
-    <bcf:citekey order="4" intorder="1">colcon</bcf:citekey>
+    <bcf:citekey order="4" intorder="1">btintro</bcf:citekey>
-    <bcf:citekey order="5" intorder="1">moveitpython</bcf:citekey>
+    <bcf:citekey order="5" intorder="1">halo2</bcf:citekey>
-    <bcf:citekey order="6" intorder="1">moveitpipeline</bcf:citekey>
+    <bcf:citekey order="6" intorder="1">cobot</bcf:citekey>
-    <bcf:citekey order="7" intorder="1">moveitpipeline</bcf:citekey>
+    <bcf:citekey order="7" intorder="1">1087032</bcf:citekey>
+    <bcf:citekey order="8" intorder="1">isla2005handling</bcf:citekey>
+    <bcf:citekey order="9" intorder="1">doi:10.1126/scirobotics.abm6074</bcf:citekey>
+    <bcf:citekey order="10" intorder="1">python</bcf:citekey>
+    <bcf:citekey order="11" intorder="1">cpp</bcf:citekey>
+    <bcf:citekey order="12" intorder="1">cmake</bcf:citekey>
+    <bcf:citekey order="13" intorder="1">rospackages</bcf:citekey>
+    <bcf:citekey order="14" intorder="1">doi:10.1126/scirobotics.abm6074</bcf:citekey>
+    <bcf:citekey order="15" intorder="1">ros-git</bcf:citekey>
+    <bcf:citekey order="16" intorder="1">colcon</bcf:citekey>
+    <bcf:citekey order="17" intorder="1">cmake</bcf:citekey>
+    <bcf:citekey order="18" intorder="1">coppelia</bcf:citekey>
+    <bcf:citekey order="19" intorder="1">gazebo</bcf:citekey>
+    <bcf:citekey order="20" intorder="1">unity</bcf:citekey>
+    <bcf:citekey order="21" intorder="1">unreal</bcf:citekey>
+    <bcf:citekey order="22" intorder="1">godot</bcf:citekey>
+    <bcf:citekey order="23" intorder="1">sdf-format</bcf:citekey>
+    <bcf:citekey order="24" intorder="1">gazebo-app</bcf:citekey>
+    <bcf:citekey order="25" intorder="1">urdf-format</bcf:citekey>
+    <bcf:citekey order="26" intorder="1">moveit-docs</bcf:citekey>
+    <bcf:citekey order="27" intorder="1">moveitpython</bcf:citekey>
+    <bcf:citekey order="28" intorder="1">python</bcf:citekey>
+    <bcf:citekey order="29" intorder="1">cpp</bcf:citekey>
+    <bcf:citekey order="30" intorder="1">rigify</bcf:citekey>
+    <bcf:citekey order="31" intorder="1">gamerig</bcf:citekey>
+    <bcf:citekey order="32" intorder="1">freecad</bcf:citekey>
+    <bcf:citekey order="33" intorder="1">octomap</bcf:citekey>
+    <bcf:citekey order="34" intorder="1">moveitpipeline</bcf:citekey>
+    <bcf:citekey order="35" intorder="1">moveitpipeline</bcf:citekey>
   </bcf:section>
   <!-- SORTING TEMPLATES -->
   <bcf:sortingtemplate name="nty">

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,7 +22,7 @@
   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},
@@ -131,12 +124,30 @@
   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},
@@ -149,6 +160,12 @@
   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},
@@ -160,3 +177,102 @@
   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 = {Arminando/GameRig: GameRig is an auto rigging for games addon for Blender. Built on top of Rigify, it adds rigs, metarigs and additional functionality that enable game engine friendly rig creation. Open source and can be used for personal and commercial projects.},
+  url = {https://github.com/Arminando/GameRig},
+  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},
+}

main.blg

@@ -1,15 +1,15 @@
 [0] Config.pm:307> INFO - This is Biber 2.19
 [0] Config.pm:310> INFO - Logfile is 'main.blg'
-[44] biber:340> INFO - === Sa Apr 15, 2023, 22:14:36
+[45] biber:340> INFO - === Do Mai 25, 2023, 12:54:44
-[51] Biber.pm:419> INFO - Reading 'main.bcf'
+[55] Biber.pm:419> INFO - Reading 'main.bcf'
-[88] Biber.pm:979> INFO - Found 6 citekeys in bib section 0
+[95] Biber.pm:979> INFO - Found 29 citekeys in bib section 0
-[95] Biber.pm:4419> INFO - Processing section 0
+[102] Biber.pm:4419> INFO - Processing section 0
-[100] Biber.pm:4610> INFO - Looking for bibtex file 'main.bib' for section 0
+[108] Biber.pm:4610> INFO - Looking for bibtex file 'main.bib' for section 0
-[101] bibtex.pm:1713> INFO - LaTeX decoding ...
+[109] bibtex.pm:1713> INFO - LaTeX decoding ...
-[107] bibtex.pm:1519> INFO - Found BibTeX data source 'main.bib'
+[120] bibtex.pm:1519> INFO - Found BibTeX data source 'main.bib'
-[131] UCollate.pm:68> INFO - Overriding locale 'de-DE' defaults 'variable = shifted' with 'variable = non-ignorable'
+[173] UCollate.pm:68> INFO - Overriding locale 'de-DE' defaults 'variable = shifted' with 'variable = non-ignorable'
-[131] UCollate.pm:68> INFO - Overriding locale 'de-DE' defaults 'normalization = NFD' with 'normalization = prenormalized'
+[173] UCollate.pm:68> INFO - Overriding locale 'de-DE' defaults 'normalization = NFD' with 'normalization = prenormalized'
-[131] Biber.pm:4239> INFO - Sorting list 'nty/global//global/global' of type 'entry' with template 'nty' and locale 'de-DE'
+[173] Biber.pm:4239> INFO - Sorting list 'nty/global//global/global' of type 'entry' with template 'nty' and locale 'de-DE'
-[131] Biber.pm:4245> INFO - No sort tailoring available for locale 'de-DE'
+[173] Biber.pm:4245> INFO - No sort tailoring available for locale 'de-DE'
-[136] bbl.pm:660> INFO - Writing 'main.bbl' with encoding 'UTF-8'
+[216] bbl.pm:660> INFO - Writing 'main.bbl' with encoding 'UTF-8'
-[137] bbl.pm:763> INFO - Output to main.bbl
+[220] bbl.pm:763> INFO - Output to main.bbl

main.lof

@@ -0,0 +1,27 @@
+\acswitchoff 
+\babel@toc {ngerman}{}\relax 
+\addvspace {10\p@ }
+\addvspace {10\p@ }
+\contentsline {figure}{\numberline {2.1}{\ignorespaces Visualisierung des Konzepts\relax }}{4}{figure.caption.3}%
+\contentsline {figure}{\numberline {2.2}{\ignorespaces Beispiel eines BehaviorTrees\relax }}{7}{figure.caption.4}%
+\addvspace {10\p@ }
+\contentsline {figure}{\numberline {3.1}{\ignorespaces Beispiel eines BehaviorTrees\relax }}{21}{figure.caption.5}%
+\contentsline {figure}{\numberline {3.2}{\ignorespaces Beispiel eines BehaviorTrees als .xml\relax }}{22}{figure.caption.6}%
+\addvspace {10\p@ }
+\contentsline {figure}{\numberline {4.1}{\ignorespaces Visualisierung des überarbeiteten Konzepts\relax }}{24}{figure.caption.7}%
+\contentsline {figure}{\numberline {4.2}{\ignorespaces Entwicklungsumgebung Lapce\relax }}{28}{figure.caption.8}%
+\contentsline {figure}{\numberline {4.3}{\ignorespaces Geplanter Raum\relax }}{30}{figure.caption.9}%
+\contentsline {figure}{\numberline {4.4}{\ignorespaces Umsetzung in Blender\relax }}{30}{figure.caption.9}%
+\contentsline {figure}{\numberline {4.5}{\ignorespaces Knochen des Modells\relax }}{32}{figure.caption.10}%
+\contentsline {figure}{\numberline {4.6}{\ignorespaces Armaturen des Modells\relax }}{32}{figure.caption.10}%
+\contentsline {figure}{\numberline {4.7}{\ignorespaces Visualisierung der generierten Beugeachse\relax }}{34}{figure.caption.11}%
+\contentsline {figure}{\numberline {4.8}{\ignorespaces Vorbereitung zum Export mit GameRig\relax }}{36}{figure.caption.12}%
+\contentsline {figure}{\numberline {4.9}{\ignorespaces Benötigte Exporteinstellungen in Blender\relax }}{36}{figure.caption.13}%
+\contentsline {figure}{\numberline {4.10}{\ignorespaces Rohdaten aus .stl-Datei\relax }}{41}{figure.caption.22}%
+\contentsline {figure}{\numberline {4.11}{\ignorespaces Visuelles Modell\relax }}{42}{figure.caption.23}%
+\contentsline {figure}{\numberline {4.12}{\ignorespaces Kollisionsmodell\relax }}{42}{figure.caption.23}%
+\addvspace {10\p@ }
+\addvspace {10\p@ }
+\addvspace {10\p@ }
+\contentsline {figure}{\numberline {7.1}{\ignorespaces Visualisierung der MoveIt Pipeline \cite {moveitpipeline}\relax }}{56}{figure.caption.47}%
+\providecommand \tocbasic@end@toc@file {}\tocbasic@end@toc@file 

main.out.ps

@@ -25,7 +25,7 @@ ifelse
 /OUT pdfmark
 [
 /Title(\376\377\000K\000o\000n\000z\000e\000p\000t)
-/Count -3
+/Count -4
 /Action/GoTo/Dest(chapter.2)cvn
 /OUT pdfmark
 [
@@ -37,16 +37,20 @@ ifelse
 /Action/GoTo/Dest(section.2.2)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
+/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s\000\040\000a\000l\000s\000\040\000B\000e\000s\000c\000h\000r\000e\000i\000b\000u\000n\000g\000s\000s\000p\000r\000a\000c\000h\000e)
 /Action/GoTo/Dest(section.2.3)cvn
 /OUT pdfmark
 [
+/Title(\376\377\000V\000i\000r\000t\000u\000a\000l\000i\000s\000i\000e\000r\000u\000n\000g\000s\000u\000m\000g\000e\000b\000u\000n\000g\000\040\000a\000l\000s\000\040\000P\000l\000a\000t\000f\000o\000r\000m)
+/Action/GoTo/Dest(section.2.4)cvn
+/OUT pdfmark
+[
 /Title(\376\377\000K\000o\000m\000p\000o\000n\000e\000n\000t\000e\000n\000-\000/\000S\000o\000f\000t\000w\000a\000r\000e\000a\000u\000s\000w\000a\000h\000l)
-/Count -4
+/Count -6
 /Action/GoTo/Dest(chapter.3)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000D\000i\000e\000n\000s\000t\000u\000m\000g\000e\000b\000u\000n\000g\000\040\000\050\000R\000O\000S\0002\000\051)
+/Title(\376\377\000D\000i\000e\000n\000s\000t\000u\000m\000g\000e\000b\000u\000n\000g)
 /Count -2
 /Action/GoTo/Dest(section.3.1)cvn
 /OUT pdfmark
@@ -60,7 +64,7 @@ ifelse
 /OUT pdfmark
 [
 /Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000s\000u\000m\000g\000e\000b\000u\000n\000g\000\040\000\050\000G\000a\000z\000e\000b\000o\000\051)
-/Count -3
+/Count -4
 /Action/GoTo/Dest(section.3.2)cvn
 /OUT pdfmark
 [
@@ -68,76 +72,121 @@ ifelse
 /Action/GoTo/Dest(subsection.3.2.1)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000R\000o\000b\000o\000t\000e\000r\000s\000i\000m\000u\000l\000a\000t\000i\000o\000n)
+/Title(\376\377\000W\000e\000l\000t\000-\000\040\000u\000n\000d\000\040\000M\000o\000d\000e\000l\000l\000b\000e\000s\000c\000h\000r\000e\000i\000b\000u\000n\000g)
 /Action/GoTo/Dest(subsection.3.2.2)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000M\000e\000n\000s\000c\000h\000e\000n\000s\000i\000m\000u\000l\000a\000t\000i\000o\000n)
+/Title(\376\377\000R\000o\000b\000o\000t\000e\000r\000s\000i\000m\000u\000l\000a\000t\000i\000o\000n)
 /Action/GoTo/Dest(subsection.3.2.3)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000R\000o\000b\000o\000t\000e\000r\000u\000m\000g\000e\000b\000u\000n\000g\000\040\000\050\000M\000o\000v\000e\000I\000t\0002\000\051)
+/Title(\376\377\000M\000e\000n\000s\000c\000h\000e\000n\000s\000i\000m\000u\000l\000a\000t\000i\000o\000n)
+/Action/GoTo/Dest(subsection.3.2.4)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000R\000o\000b\000o\000t\000e\000r\000u\000m\000g\000e\000b\000u\000n\000g)
 /Action/GoTo/Dest(section.3.3)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
+/Title(\376\377\000P\000r\000o\000g\000r\000a\000m\000m\000i\000e\000r\000s\000p\000r\000a\000c\000h\000e)
 /Action/GoTo/Dest(section.3.4)cvn
 /OUT pdfmark
 [
+/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
+/Count -2
+/Action/GoTo/Dest(section.3.5)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000A\000s\000y\000n\000c\000h\000r\000o\000n\000e\000\040\000N\000o\000d\000e\000s)
+/Action/GoTo/Dest(subsection.3.5.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000D\000a\000t\000e\000i\000f\000o\000r\000m\000a\000t)
+/Action/GoTo/Dest(subsection.3.5.2)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000D\000o\000c\000k\000e\000r\000-\000C\000o\000m\000p\000o\000s\000e\000\040\000a\000l\000s\000\040\000V\000i\000r\000t\000u\000a\000l\000i\000s\000i\000e\000r\000u\000n\000g\000s\000u\000m\000g\000e\000b\000u\000n\000g)
+/Action/GoTo/Dest(section.3.6)cvn
+/OUT pdfmark
+[
 /Title(\376\377\000U\000m\000s\000e\000t\000z\000u\000n\000g)
-/Count -4
+/Count -7
 /Action/GoTo/Dest(chapter.4)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000G\000r\000u\000n\000d\000l\000e\000g\000e\000n\000d\000e\000r\000\040\000S\000y\000s\000t\000e\000m\000a\000u\000f\000b\000a\000u)
+/Title(\376\377\000D\000o\000c\000k\000e\000r\000-\000C\000o\000m\000p\000o\000s\000e)
 /Action/GoTo/Dest(section.4.1)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000M\000e\000n\000s\000c\000h)
+/Title(\376\377\000E\000n\000t\000w\000i\000c\000k\000l\000u\000n\000g\000s\000u\000m\000g\000e\000b\000u\000n\000g)
-/Count -3
 /Action/GoTo/Dest(section.4.2)cvn
 /OUT pdfmark
 [
+/Title(\376\377\000V\000e\000r\000w\000e\000n\000d\000e\000t\000e\000\040\000D\000a\000t\000e\000n\000t\000y\000p\000e\000n)
+/Action/GoTo/Dest(section.4.3)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000s\000w\000e\000l\000t)
+/Action/GoTo/Dest(section.4.4)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000M\000e\000n\000s\000c\000h)
+/Count -4
+/Action/GoTo/Dest(section.4.5)cvn
+/OUT pdfmark
+[
 /Title(\376\377\000\334\000b\000e\000r\000s\000i\000c\000h\000t)
-/Action/GoTo/Dest(subsection.4.2.1)cvn
+/Action/GoTo/Dest(subsection.4.5.1)cvn
 /OUT pdfmark
 [
 /Title(\376\377\000M\000o\000d\000e\000l\000l\000i\000e\000r\000u\000n\000g)
-/Action/GoTo/Dest(subsection.4.2.2)cvn
+/Action/GoTo/Dest(subsection.4.5.2)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000E\000x\000p\000o\000r\000t\000\040\000d\000e\000r\000\040\000M\000o\000d\000e\000l\000l\000a\000n\000i\000m\000a\000t\000i\000o\000n\000e\000n)
+/Action/GoTo/Dest(subsection.4.5.3)cvn
 /OUT pdfmark
 [
 /Title(\376\377\000P\000r\000o\000g\000r\000a\000m\000m\000i\000e\000r\000u\000n\000g)
-/Action/GoTo/Dest(subsection.4.2.3)cvn
+/Action/GoTo/Dest(subsection.4.5.4)cvn
 /OUT pdfmark
 [
 /Title(\376\377\000R\000o\000b\000o\000t\000e\000r)
 /Count -4
-/Action/GoTo/Dest(section.4.3)cvn
+/Action/GoTo/Dest(section.4.6)cvn
 /OUT pdfmark
 [
 /Title(\376\377\000\334\000b\000e\000r\000s\000i\000c\000h\000t)
-/Action/GoTo/Dest(subsection.4.3.1)cvn
+/Action/GoTo/Dest(subsection.4.6.1)cvn
 /OUT pdfmark
 [
 /Title(\376\377\000M\000o\000d\000e\000l\000l\000i\000e\000r\000u\000n\000g)
-/Action/GoTo/Dest(subsection.4.3.2)cvn
+/Action/GoTo/Dest(subsection.4.6.2)cvn
 /OUT pdfmark
 [
 /Title(\376\377\000M\000o\000v\000e\000I\000t\000\040\0002\000\040\000K\000o\000n\000f\000i\000g\000u\000r\000a\000t\000i\000o\000n)
-/Action/GoTo/Dest(subsection.4.3.3)cvn
+/Action/GoTo/Dest(subsection.4.6.3)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000D\000e\000t\000a\000i\000l\000s)
+/Title(\376\377\000I\000n\000t\000e\000g\000r\000a\000t\000i\000o\000n\000\040\000m\000i\000t\000\040\000G\000a\000z\000e\000b\000o)
-/Action/GoTo/Dest(subsection.4.3.4)cvn
+/Action/GoTo/Dest(subsection.4.6.4)cvn
 /OUT pdfmark
 [
 /Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
-/Count -1
+/Count -3
-/Action/GoTo/Dest(section.4.4)cvn
+/Action/GoTo/Dest(section.4.7)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000A\000s\000y\000n\000c\000h\000r\000o\000n\000e\000\040\000N\000o\000d\000e\000s)
+/Title(\376\377\000S\000u\000b\000t\000r\000e\000e\000s)
-/Action/GoTo/Dest(subsection.4.4.1)cvn
+/Action/GoTo/Dest(subsection.4.7.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000V\000e\000r\000h\000a\000l\000t\000e\000n\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000s)
+/Action/GoTo/Dest(subsection.4.7.2)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000V\000e\000r\000h\000a\000l\000t\000e\000n\000\040\000d\000e\000s\000\040\000M\000e\000n\000s\000c\000h\000e\000n)
+/Action/GoTo/Dest(subsection.4.7.3)cvn
 /OUT pdfmark
 [
 /Title(\376\377\000S\000z\000e\000n\000a\000r\000i\000e\000n\000b\000a\000s\000i\000e\000r\000t\000e\000\040\000E\000v\000a\000l\000u\000a\000t\000i\000o\000n)
@@ -172,7 +221,7 @@ ifelse
 /OUT pdfmark
 [
 /Title(\376\377\000L\000e\000s\000s\000o\000n\000s\000\040\000L\000e\000a\000r\000n\000e\000d\000\040\000b\000e\000i\000\040\000d\000e\000r\000\040\000U\000m\000s\000e\000t\000z\000u\000n\000g)
-/Count -4
+/Count -5
 /Action/GoTo/Dest(section.6.1)cvn
 /OUT pdfmark
 [
@@ -180,18 +229,22 @@ ifelse
 /Action/GoTo/Dest(subsection.6.1.1)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000G\000a\000z\000e\000b\000o)
+/Title(\376\377\000E\000r\000w\000e\000i\000t\000e\000r\000u\000n\000g\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000m\000o\000d\000e\000l\000l\000s\000\040\000m\000i\000t\000\040\000M\000o\000v\000e\000I\000t)
 /Action/GoTo/Dest(subsection.6.1.2)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000R\000O\000S\0002)
+/Title(\376\377\000G\000a\000z\000e\000b\000o)
 /Action/GoTo/Dest(subsection.6.1.3)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000M\000o\000v\000e\000I\000t\0002)
+/Title(\376\377\000R\000O\000S\0002)
 /Action/GoTo/Dest(subsection.6.1.4)cvn
 /OUT pdfmark
 [
+/Title(\376\377\000M\000o\000v\000e\000I\000t\0002)
+/Action/GoTo/Dest(subsection.6.1.5)cvn
+/OUT pdfmark
+[
 /Title(\376\377\000L\000e\000s\000s\000o\000n\000s\000\040\000L\000e\000a\000r\000n\000e\000d\000\040\000b\000e\000i\000\040\000d\000e\000n\000\040\000S\000z\000e\000n\000a\000r\000i\000e\000n)
 /Count -1
 /Action/GoTo/Dest(section.6.2)cvn
@@ -224,7 +277,7 @@ ifelse
 /OUT pdfmark
 [
 /Title(\376\377\000A\000u\000s\000b\000l\000i\000c\000k)
-/Count -3
+/Count -5
 /Action/GoTo/Dest(section.7.3)cvn
 /OUT pdfmark
 [
@@ -239,3 +292,11 @@ ifelse
 /Title(\376\377\000E\000r\000g\000\344\000n\000z\000u\000n\000g\000\040\000v\000o\000n\000\040\000U\000m\000g\000e\000b\000u\000n\000g\000s\000e\000r\000k\000e\000n\000n\000u\000n\000g)
 /Action/GoTo/Dest(subsection.7.3.3)cvn
 /OUT pdfmark
+[
+/Title(\376\377\000Z\000u\000s\000a\000m\000m\000e\000n\000b\000r\000i\000n\000g\000e\000n\000\040\000v\000o\000n\000\040\000A\000c\000t\000o\000r\000P\000l\000u\000g\000i\000n\000\040\000u\000n\000d\000\040\000A\000c\000t\000o\000r\000S\000e\000r\000v\000e\000r)
+/Action/GoTo/Dest(subsection.7.3.4)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000S\000e\000p\000a\000r\000i\000e\000r\000e\000n\000\040\000d\000e\000r\000\040\000S\000u\000b\000t\000r\000e\000e\000s\000\040\000i\000n\000\040\000e\000i\000g\000e\000n\000e\000\040\000D\000a\000t\000e\000i\000e\000n)
+/Action/GoTo/Dest(subsection.7.3.5)cvn
+/OUT pdfmark

main.tex

@@ -8,10 +8,10 @@ parskip=half,
 \usepackage[ngerman]{babel}
 \usepackage[T1]{fontenc}
 \usepackage{lmodern}
+\usepackage{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{pdfpages}
 \usepackage{scrhack}
@@ -23,6 +23,8 @@ parskip=half,
 \usepackage{soul}
 \usepackage{xcolor}
 \usepackage{inconsolata}
+\usepackage{subcaption}
+
 \usepackage[strings]{underscore}
 
 \usepackage[letterspace=150]{microtype}
@@ -72,7 +74,6 @@ parskip=half,
   long=Mensch-Roboter-Kollaboration,
 }
 
-
 \begin{document}
 
 \setcounter{page}{1}
@@ -85,6 +86,7 @@ parskip=half,
 \end{titlepage}
 
 \tableofcontents
+\listoffigures
 
 \includepdf[pages=-]{tex/Aufgabenstellung.pdf}
 
@@ -150,7 +152,7 @@ Danach kann die Welt Stück für Stück in das neue Format übertragen werden, w
 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
+Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, welche auf ein Entity-Component-System umstellte, aber auch Veränderungen an den verwendeten Objekten innerhalb dieses Systems.
 \subsubsection{Pluginarchitektur}
 Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
 Jedoch existiert damit jedes Plugin im selben Prozess, was bei der Nutzung von Bibliotheken, welche nicht für die mehrfache Nutzung im selben Prozess entsprechend ausgelegt wurden, zu Problemen führen kann.
@@ -239,12 +241,14 @@ Natürlich ist die Einführung eines weiteren Nachrichtendienstes ein Bruch der
 
 -Potentielle Integration von ROS als Messagedients in Gazebo
 
+\subsection{Separieren der Subtrees in eigene Dateien}
 
 \printbibliography
+\newpage
 \markboth{Anhang}{Anhang}
 \begin{figure}[ht]
 \includegraphics[width=14cm]{img/moveit_pipeline}
-\caption{Visualisierung der MoveIt Pipeline\cite{moveitpipeline}}
+\caption{Visualisierung der MoveIt Pipeline \protect \cite{moveitpipeline}}
 \label{moveitpipeline}
 \end{figure}
 \end{document}          

main.toc

@@ -4,76 +4,85 @@
 \contentsline {section}{\numberline {1.1}Motivation}{1}{section.1.1}%
 \contentsline {section}{\numberline {1.2}Stand der Wissenschaft}{1}{section.1.2}%
 \contentsline {section}{\numberline {1.3}Welche Szenarien}{2}{section.1.3}%
-\contentsline {section}{\numberline {1.4}Welcher Nutzen / Contributions}{2}{section.1.4}%
+\contentsline {section}{\numberline {1.4}Welcher Nutzen / Contributions}{3}{section.1.4}%
 \contentsline {chapter}{\numberline {2}Konzept}{4}{chapter.2}%
 \contentsline {section}{\numberline {2.1}Simulation des Roboters}{4}{section.2.1}%
 \contentsline {section}{\numberline {2.2}Simulation des Menschen}{5}{section.2.2}%
 \contentsline {section}{\numberline {2.3}Behavior Trees als Beschreibungssprache}{5}{section.2.3}%
-\contentsline {section}{\numberline {2.4}Virtualisierungsumgebung als Platform}{6}{section.2.4}%
+\contentsline {section}{\numberline {2.4}Virtualisierungsumgebung als Platform}{7}{section.2.4}%
-\contentsline {chapter}{\numberline {3}Komponenten-/Softwareauswahl}{7}{chapter.3}%
+\contentsline {chapter}{\numberline {3}Komponenten-/Softwareauswahl}{9}{chapter.3}%
-\contentsline {section}{\numberline {3.1}Dienstumgebung (ROS2)}{7}{section.3.1}%
+\contentsline {section}{\numberline {3.1}Dienstumgebung}{9}{section.3.1}%
-\contentsline {subsection}{\numberline {3.1.1}Auswahl}{7}{subsection.3.1.1}%
+\contentsline {subsection}{\numberline {3.1.1}Auswahl}{9}{subsection.3.1.1}%
-\contentsline {subsection}{\numberline {3.1.2}Beschreibung}{8}{subsection.3.1.2}%
+\contentsline {subsection}{\numberline {3.1.2}Beschreibung}{10}{subsection.3.1.2}%
-\contentsline {section}{\numberline {3.2}Simulationsumgebung (Gazebo)}{9}{section.3.2}%
+\contentsline {section}{\numberline {3.2}Simulationsumgebung (Gazebo)}{12}{section.3.2}%
-\contentsline {subsection}{\numberline {3.2.1}Auswahl}{9}{subsection.3.2.1}%
+\contentsline {subsection}{\numberline {3.2.1}Auswahl}{12}{subsection.3.2.1}%
-\contentsline {subsection}{\numberline {3.2.2}Robotersimulation}{10}{subsection.3.2.2}%
+\contentsline {subsection}{\numberline {3.2.2}Welt- und Modellbeschreibung}{14}{subsection.3.2.2}%
-\contentsline {subsection}{\numberline {3.2.3}Menschensimulation}{11}{subsection.3.2.3}%
+\contentsline {subsection}{\numberline {3.2.3}Robotersimulation}{15}{subsection.3.2.3}%
-\contentsline {section}{\numberline {3.3}Roboterumgebung (MoveIt2)}{12}{section.3.3}%
+\contentsline {subsection}{\numberline {3.2.4}Menschensimulation}{16}{subsection.3.2.4}%
-\contentsline {section}{\numberline {3.4}Behavior Trees}{13}{section.3.4}%
+\contentsline {section}{\numberline {3.3}Roboterumgebung}{16}{section.3.3}%
-\contentsline {subsection}{\numberline {3.4.1}Asynchrone Nodes}{14}{subsection.3.4.1}%
+\contentsline {section}{\numberline {3.4}Programmiersprache}{18}{section.3.4}%
-\contentsline {section}{\numberline {3.5}Docker-Compose als Virtualisierungsumgebung}{15}{section.3.5}%
+\contentsline {section}{\numberline {3.5}Behavior Trees}{18}{section.3.5}%
-\contentsline {chapter}{\numberline {4}Umsetzung}{16}{chapter.4}%
+\contentsline {subsection}{\numberline {3.5.1}Asynchrone Nodes}{20}{subsection.3.5.1}%
-\contentsline {section}{\numberline {4.1}Grundlegender Systemaufbau}{16}{section.4.1}%
+\contentsline {subsection}{\numberline {3.5.2}Dateiformat}{21}{subsection.3.5.2}%
-\contentsline {section}{\numberline {4.2}Verwendete Datentypen}{16}{section.4.2}%
+\contentsline {section}{\numberline {3.6}Docker-Compose als Virtualisierungsumgebung}{22}{section.3.6}%
-\contentsline {section}{\numberline {4.3}Mensch}{18}{section.4.3}%
+\contentsline {chapter}{\numberline {4}Umsetzung}{24}{chapter.4}%
-\contentsline {subsection}{\numberline {4.3.1}Übersicht}{18}{subsection.4.3.1}%
+\contentsline {section}{\numberline {4.1}Docker-Compose}{25}{section.4.1}%
-\contentsline {subsection}{\numberline {4.3.2}Modellierung}{18}{subsection.4.3.2}%
+\contentsline {section}{\numberline {4.2}Entwicklungsumgebung}{26}{section.4.2}%
-\contentsline {subsection}{\numberline {4.3.3}Programmierung}{19}{subsection.4.3.3}%
+\contentsline {section}{\numberline {4.3}Verwendete Datentypen}{27}{section.4.3}%
-\contentsline {subsubsection}{\nonumberline Message Queue}{19}{subsubsection*.3}%
+\contentsline {section}{\numberline {4.4}Simulationswelt}{29}{section.4.4}%
-\contentsline {subsubsection}{\nonumberline Nachrichten}{21}{subsubsection*.5}%
+\contentsline {section}{\numberline {4.5}Mensch}{31}{section.4.5}%
-\contentsline {subsubsection}{\nonumberline ActorServer}{21}{subsubsection*.7}%
+\contentsline {subsection}{\numberline {4.5.1}Übersicht}{31}{subsection.4.5.1}%
-\contentsline {subsubsection}{\nonumberline Gazebo Plugin}{22}{subsubsection*.9}%
+\contentsline {subsection}{\numberline {4.5.2}Modellierung}{31}{subsection.4.5.2}%
-\contentsline {section}{\numberline {4.4}Roboter}{22}{section.4.4}%
+\contentsline {subsection}{\numberline {4.5.3}Export der Modellanimationen}{34}{subsection.4.5.3}%
-\contentsline {subsection}{\numberline {4.4.1}Übersicht}{22}{subsection.4.4.1}%
+\contentsline {subsection}{\numberline {4.5.4}Programmierung}{37}{subsection.4.5.4}%
-\contentsline {subsection}{\numberline {4.4.2}Modellierung}{22}{subsection.4.4.2}%
+\contentsline {subsubsection}{\nonumberline Message Queue}{37}{subsubsection*.15}%
-\contentsline {subsection}{\numberline {4.4.3}MoveIt 2 Konfiguration}{23}{subsection.4.4.3}%
+\contentsline {subsubsection}{\nonumberline Nachrichten}{38}{subsubsection*.17}%
-\contentsline {subsection}{\numberline {4.4.4}Details}{24}{subsection.4.4.4}%
+\contentsline {subsubsection}{\nonumberline ActorPlugin}{39}{subsubsection*.19}%
-\contentsline {section}{\numberline {4.5}Behavior Trees}{24}{section.4.5}%
+\contentsline {subsubsection}{\nonumberline ActorServer}{40}{subsubsection*.21}%
-\contentsline {subsubsection}{\nonumberline Allgemein nutzbare Nodes}{24}{subsubsection*.11}%
+\contentsline {section}{\numberline {4.6}Roboter}{40}{section.4.6}%
-\contentsline {subsubsection}{\nonumberline Menschenspezifisch}{25}{subsubsection*.13}%
+\contentsline {subsection}{\numberline {4.6.1}Übersicht}{40}{subsection.4.6.1}%
-\contentsline {subsubsection}{\nonumberline Roboterspezifisch}{26}{subsubsection*.15}%
+\contentsline {subsection}{\numberline {4.6.2}Modellierung}{41}{subsection.4.6.2}%
-\contentsline {section}{\numberline {4.6}Docker-Compose}{26}{section.4.6}%
+\contentsline {subsection}{\numberline {4.6.3}MoveIt 2 Konfiguration}{42}{subsection.4.6.3}%
-\contentsline {chapter}{\numberline {5}Szenarienbasierte Evaluation}{28}{chapter.5}%
+\contentsline {subsection}{\numberline {4.6.4}Integration mit Gazebo}{43}{subsection.4.6.4}%
-\contentsline {section}{\numberline {5.1}Simulation des Menschen}{28}{section.5.1}%
+\contentsline {section}{\numberline {4.7}Behavior Trees}{43}{section.4.7}%
-\contentsline {section}{\numberline {5.2}Bewegung des Roboters}{28}{section.5.2}%
+\contentsline {subsubsection}{\nonumberline Allgemein nutzbare Nodes}{44}{subsubsection*.25}%
-\contentsline {section}{\numberline {5.3}BehaviorTrees}{28}{section.5.3}%
+\contentsline {subsubsection}{\nonumberline Menschenspezifisch}{45}{subsubsection*.27}%
-\contentsline {subsection}{\numberline {5.3.1}Nodes}{28}{subsection.5.3.1}%
+\contentsline {subsubsection}{\nonumberline Roboterspezifisch}{45}{subsubsection*.29}%
-\contentsline {subsection}{\numberline {5.3.2}Kombinieren von Nodes zu einer Request}{28}{subsection.5.3.2}%
+\contentsline {subsection}{\numberline {4.7.1}Subtrees}{46}{subsection.4.7.1}%
-\contentsline {chapter}{\numberline {6}Diskussion}{29}{chapter.6}%
+\contentsline {subsection}{\numberline {4.7.2}Verhalten des Roboters}{46}{subsection.4.7.2}%
-\contentsline {section}{\numberline {6.1}Lessons Learned bei der Umsetzung}{29}{section.6.1}%
+\contentsline {subsection}{\numberline {4.7.3}Verhalten des Menschen}{46}{subsection.4.7.3}%
-\contentsline {subsection}{\numberline {6.1.1}Erstellung des Robotermodells}{29}{subsection.6.1.1}%
+\contentsline {chapter}{\numberline {5}Szenarienbasierte Evaluation}{47}{chapter.5}%
-\contentsline {subsection}{\numberline {6.1.2}Gazebo}{29}{subsection.6.1.2}%
+\contentsline {section}{\numberline {5.1}Simulation des Menschen}{47}{section.5.1}%
-\contentsline {subsubsection}{\nonumberline Upgrade auf Ignition}{29}{subsubsection*.17}%
+\contentsline {section}{\numberline {5.2}Bewegung des Roboters}{47}{section.5.2}%
-\contentsline {subsubsection}{\nonumberline Pluginarchitektur}{30}{subsubsection*.19}%
+\contentsline {section}{\numberline {5.3}BehaviorTrees}{47}{section.5.3}%
-\contentsline {subsubsection}{\nonumberline Doppelte Messagedienste}{30}{subsubsection*.21}%
+\contentsline {subsection}{\numberline {5.3.1}Nodes}{47}{subsection.5.3.1}%
-\contentsline {subsubsection}{\nonumberline Fehlende Animationsgrundlagen}{30}{subsubsection*.23}%
+\contentsline {subsection}{\numberline {5.3.2}Kombinieren von Nodes zu einer Request}{47}{subsection.5.3.2}%
-\contentsline {subsection}{\numberline {6.1.3}ROS2}{30}{subsection.6.1.3}%
+\contentsline {chapter}{\numberline {6}Diskussion}{48}{chapter.6}%
-\contentsline {subsubsection}{\nonumberline Nachrichten und deren Echtzeitfähigkeit}{30}{subsubsection*.25}%
+\contentsline {section}{\numberline {6.1}Lessons Learned bei der Umsetzung}{48}{section.6.1}%
-\contentsline {subsubsection}{\nonumberline Änderung der Compilertoolchain}{30}{subsubsection*.27}%
+\contentsline {subsection}{\numberline {6.1.1}Erstellung des Robotermodells}{48}{subsection.6.1.1}%
-\contentsline {subsection}{\numberline {6.1.4}MoveIt2}{31}{subsection.6.1.4}%
+\contentsline {subsection}{\numberline {6.1.2}Erweiterung des Robotermodells mit MoveIt}{48}{subsection.6.1.2}%
-\contentsline {subsubsection}{\nonumberline Upgrade auf MoveIt2}{31}{subsubsection*.29}%
+\contentsline {subsection}{\numberline {6.1.3}Gazebo}{48}{subsection.6.1.3}%
-\contentsline {subsubsection}{\nonumberline Fehlerhafte Generierung der Roboter}{31}{subsubsection*.31}%
+\contentsline {subsubsection}{\nonumberline Upgrade auf Ignition}{48}{subsubsection*.31}%
-\contentsline {subsubsection}{\nonumberline Controller}{31}{subsubsection*.33}%
+\contentsline {subsubsection}{\nonumberline Pluginarchitektur}{49}{subsubsection*.33}%
-\contentsline {section}{\numberline {6.2}Lessons Learned bei den Szenarien}{31}{section.6.2}%
+\contentsline {subsubsection}{\nonumberline Fehlende Animationsgrundlagen}{50}{subsubsection*.35}%
-\contentsline {subsection}{\numberline {6.2.1}Debugging}{31}{subsection.6.2.1}%
+\contentsline {subsection}{\numberline {6.1.4}ROS2}{50}{subsection.6.1.4}%
-\contentsline {chapter}{\numberline {7}Zusammenfassung und Ausblick}{32}{chapter.7}%
+\contentsline {subsubsection}{\nonumberline Nachrichten und deren Echtzeitfähigkeit}{50}{subsubsection*.37}%
-\contentsline {section}{\numberline {7.1}Ergebnisse}{32}{section.7.1}%
+\contentsline {subsubsection}{\nonumberline Änderung der Compilertoolchain}{50}{subsubsection*.39}%
-\contentsline {subsection}{\numberline {7.1.1}Graphische Repräsentation der Szenarien}{32}{subsection.7.1.1}%
+\contentsline {subsection}{\numberline {6.1.5}MoveIt2}{50}{subsection.6.1.5}%
-\contentsline {subsection}{\numberline {7.1.2}Anpassung der Behavior Trees an Szenarien}{32}{subsection.7.1.2}%
+\contentsline {subsubsection}{\nonumberline Upgrade auf MoveIt2}{50}{subsubsection*.41}%
-\contentsline {section}{\numberline {7.2}Diskussion}{32}{section.7.2}%
+\contentsline {subsubsection}{\nonumberline Fehlerhafte Generierung der Roboter}{51}{subsubsection*.43}%
-\contentsline {section}{\numberline {7.3}Ausblick}{32}{section.7.3}%
+\contentsline {subsubsection}{\nonumberline Controller}{51}{subsubsection*.45}%
-\contentsline {subsection}{\numberline {7.3.1}Umsetzung in anderem Simulator}{32}{subsection.7.3.1}%
+\contentsline {section}{\numberline {6.2}Lessons Learned bei den Szenarien}{51}{section.6.2}%
-\contentsline {subsection}{\numberline {7.3.2}Simulation bewegter Objekte}{32}{subsection.7.3.2}%
+\contentsline {subsection}{\numberline {6.2.1}Debugging}{51}{subsection.6.2.1}%
-\contentsline {subsection}{\numberline {7.3.3}Ergänzung von Umgebungserkennung}{33}{subsection.7.3.3}%
+\contentsline {chapter}{\numberline {7}Zusammenfassung und Ausblick}{52}{chapter.7}%
-\contentsline {subsection}{\numberline {7.3.4}Zusammenbringen von ActorPlugin und ActorServer}{33}{subsection.7.3.4}%
+\contentsline {section}{\numberline {7.1}Ergebnisse}{52}{section.7.1}%
+\contentsline {subsection}{\numberline {7.1.1}Graphische Repräsentation der Szenarien}{52}{subsection.7.1.1}%
+\contentsline {subsection}{\numberline {7.1.2}Anpassung der Behavior Trees an Szenarien}{52}{subsection.7.1.2}%
+\contentsline {section}{\numberline {7.2}Diskussion}{52}{section.7.2}%
+\contentsline {section}{\numberline {7.3}Ausblick}{52}{section.7.3}%
+\contentsline {subsection}{\numberline {7.3.1}Umsetzung in anderem Simulator}{52}{subsection.7.3.1}%
+\contentsline {subsection}{\numberline {7.3.2}Simulation bewegter Objekte}{52}{subsection.7.3.2}%
+\contentsline {subsection}{\numberline {7.3.3}Ergänzung von Umgebungserkennung}{53}{subsection.7.3.3}%
+\contentsline {subsection}{\numberline {7.3.4}Zusammenbringen von ActorPlugin und ActorServer}{53}{subsection.7.3.4}%
+\contentsline {subsection}{\numberline {7.3.5}Separieren der Subtrees in eigene Dateien}{53}{subsection.7.3.5}%
 \providecommand \tocbasic@end@toc@file {}\tocbasic@end@toc@file 

tex/1_Einleitung.tex

@@ -1,63 +1,63 @@
 \chapter{Einleitung}
 \section{Motivation}
-Das Feld der Mensch-Roboter-Kollaboration entwickelt sich mit zunehmender Geschwindigkeit fort.
+Die Simulation von Maschinen wird im industriellen Umfeld immer beliebter, um deren Verhalten schon vor der eigentlichen Produktion zu testen.
-Viele Unternehmen bieten neue Lösungen für die unterschiedlichsten Einsatzszenarien der Endanwender.
+Dazu wird ein Modell des gesamten Prozesses in der Simulation geschaffen, der durch die Maschine beeinflusst werden soll.
+Das Modell wird dann um die Maschine selbst erweitert, welche Einfluss auf das System nimmt.
+Die Veränderungen durch die Maschine werden nun analysiert, und erlauben Rückschlüsse auf die Funktion des Systems.
+Ein solches Modell kann nun für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
 
-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.
+Im wachsenden Feld der Mensch-Roboter-Kollaboration existieren bereits einige Lösungen, um auch die namensgebende Interaktion von Mensch und Roboter simulieren zu können.
-Das so gefertigte Modell des Anwendungsfalls könnte später auch als Grundlage für einen digitalen Zwilling dienen.
+Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf in der Simulation bereits vor deren Ausführung fest definiert werden muss.
-Dieser kann später zur Wartung und Fehlerdiagnose des Systems genutzt werden.
+Dies erlaubt die Reproduktion des genauen Bewegungsablaufes, aber nicht verschiedene Variationen im gesamten Prozess, welche durch die Ereignisse in der Simulation ausgelöst werden.
+Um eine solche Funktionalität bereitstellen zu können, muss der Bewegungsablauf von sowohl Roboter und Mensch zur Laufzeit der Simulation gesteuert werden.
 
--MRK häufiger ein Thema
+Dies soll durch eine eingängliche Beschreibungssprache ermöglicht werden, die einfach erweitert und auf neue Szenarien angepasst werden kann.
--Anwendungsfälle sollen evaluiert werden
+Um diese Funktionalität zu demonstrieren, sollen 3 unterschiedliche Testszenarien in der Simulationsumgebung abgebildet werden.
--Erprobung von Szenarien ohne Roboter
+Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwischen Mensch und Roboter simulieren.
 
-->Simulation eine kompletten Szenarios mit Roboter und Mensch
 \section{Stand der Wissenschaft}
-Aktuelle Arbeiten:
+Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen Teilaspekten einer solchen Simulation.
 
--Planung von Interaktionen
+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 nun in der Interaktion verwendet werden, um Verletzungen durch den Roboter auszuschließen.
 
--Parametervergleiche von maschinellen und menschlichen Bewegungen
+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 überwachen zu können.
+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.
 
--Vermeidung von Kollisionen und Strategie
+Es existieren auch zahlreiche Wege, 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.
 
--Steuerung von Robotern mit Behavior Trees
+In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetzt, um verschiedene Systeme, wie zum Beispiel die Steuerung von Nichtspielercharakteren, zu beschreiben.\cite{halo2}
 
--> Keine allgemeine Simulation einen gesamten Szenarios mit Mensch.
+Eine vollständige Umsetzung einer erweiterbaren Simulation mit Mensch und Roboter, gesteuert durch eine Beschreibungssprache konnte nicht gefunden werden.
-
-\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 zu modellierenden Szenarien sollten so gewählt werden, dass in vorherigen Szenarien genutzte Bestandteile in späteren, komplexeren Szenarien weiter genutzt werden können.
-Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten, besonders in Frage, da diese viele ähnliche Bestandteile haben, jedoch mehrere Szenarien denkbar sind.
+Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders in Frage, da diese viele ähnliche Bestandteile haben, jedoch mehrere Umstände denkbar sind, in welchen diese verwendet werden können.
-Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das begutachten eines Objekts, welche alle nur eine Bewegungsabfolge eines Menschen sind.
+Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das Begutachten eines Objekts, welche alle nur eine Bewegungsabfolge des beteiligten Menschen 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.
+Das erste Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe befassen, 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, um Kollisionen zu vermeiden.
+Der Mensch soll in diesem Szenario auch arbeiten, jedoch nur vereinzelt den Arbeitsbereich des Roboters betreten, um diesen zu beobachten.
 
-Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide an unterschiedlichen Aufgabe, jedoch im selben Raum, arbeiten.
+Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide an unterschiedlichen Aufgaben, jedoch im selben Raum, 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 guten Exemplare auf einem Fließband zur Weiterverarbeitung ab.
 Die Mängelexemplare werden hingegen in einer besonderen Zone abgelegt, von wo sie vom Menschen abtransportiert werden.
-
+Auch hier soll der Mensch solange eigenständig arbeiten, bis der Roboter ein aussortiertes Teil ablegt, welches weiter transportiert werden muss.
-In diesem Szenario wird das vorhergegangene Szenario um weitere Aspekte ergänzt, was dieses zu einem
 
 Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario 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.
-Dies resultiert in  Problemen beim Aufheben, Transport und Ablegen der Objekte.
+Dies resultiert in Problemen beim Aufheben, Transport und Ablegen der Objekte.
 In diesen Fällen muss nun ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
+Dieser soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren, was durch das Laufen im Raum abgebildet werden soll.
 \section{Welcher Nutzen / 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 Konfiguration von sowohl Roboter als auch Mensch auf unterschiedliche Szenarien nötig, welche durch eine Beschreibungssprache definiert werden sollen.
 Durch deren einfache Struktur soll komplexes Verhalten einfach und überschaubar definierbar sein, welches dann in der Simulation getestet werden kann.
-- Erkennen von konzeptionellen Problemen vor Ersteinsatz
-
-- Definition von Interaktion mit einfacheren Strukturen als State-Machines

tex/2_Konzept.tex

@@ -3,10 +3,10 @@ Die zu entwickelnde Simulation soll die bisher meißt separaten Zweige der Robot
 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ürht, welche auch die Bewegungsplanung bereitstellt.
+Hierfür wird die Beschreibungssprache in der Dienstumgebung ausgeführt, in welcher auch die Bewegungsplanung stattfindet.
-Die Beschreibungssprache kommunitziert direkt mit dem simulierten Menschen in der Simulation und der Bewegungsplanung.
+Die Beschreibungssprache kommuniziert direkt mit der Simulation und Bewegungsplanung des simulierten Menschen.
 Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen diesen auch Nachrichten ausgetauscht.
-Der gesamte Vorgang ist dabei in Abbildung \ref{concept_overview} visualisiert.
+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.
@@ -23,8 +23,8 @@ Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
 Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
 Außerdem ist die enge Interaktion mit Menschen 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 Mensch-Roboter-Kollaboration noch einmal unterstreicht.
+Die Bezeichnung als Cobot\cite{cobot} ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
-Er besitzt auch einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
+Der Roboter 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 abbilden.
@@ -35,36 +35,47 @@ Der Mensch soll in der Simulation typische Aufgaben erledigen und häufiges Verh
 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 benötigt.
+Um diese Animationen erstellen zu können, wird zuerst ein animierbares Modell des Menschen benötigt.
-Dieses Modell soll dabei die Möglichkeit bieten, um weitere Animationen erweitert werden zu können.
+Dieses Modell soll dabei um weitere Animationen erweiterbar sein.
 Es werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.
 
-Die so erstellten Animationen müssen nun von außerhalb der Simulationsumgebung ausführbar gemacht werden, um diese später mite einer Beschreibungssprache steuern zu können.
+Die so erstellten Animationen müssen nun von außerhalb der Simulationsumgebung ausführbar gemacht werden, um diese später mit einer Beschreibungssprache steuern zu können.
 Hierfür muss eine Komponente entwickelt werden, welche in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
 Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Anfragen im Fortschritt überwacht und abgebrochen werden können.
 
 \section{Behavior Trees als Beschreibungssprache}
-Häufig wird das Verhalten von Akteuren in einer Simulationsumgebung mit State-Machines ausgedrückt, welche jedoch einige Nachteile besitzen.
+Bislang wird das Verhalten von Akteuren in Simationsumgebungen, darunter Roboter und Menschen, häufig in Form von State-Machines ausgedrückt.
-State-Machines werden ab einer gewissen Größe schnell unübersichtlich.
+Diese besitzen jedoch einen großen Nachteil, welcher vor allem bei komplexeren Abläufen hervortreten kann.
-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.
+Dabei handelt es sich um die Übersichtlichkeit, welche bei einer wachsenden State-Machine leicht verloren geht.
-Um diese Probleme zu adressieren, wurde das Konzept der Behavior Trees entwickelt.
+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.
 
-Ein Behavior Tree ist eine Struktur, um Verhalten als ein Baum zu beschreiben.
+Behavior Trees lösen dieses Problem, in dem sie sogenannte Nodes definieren, welche in einer übersichtlichen Baumstruktur angeordnet werden.
-Der Ablauf startet vom sogenannten Root, der Wurzel des Baums.
+Die einzelnen Nodes verändern dabei das System und lösen den Wechsel zu neuen Nodes aus.
-Von dort an werden sogenannte Nodes, welche je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
+
+Ursprünglich wurde das Konzept von Rodney Brooks entwickelt, welcher diese für mobile Roboter einsetzen wollte. \cite{1087032}
+Das System setzte sich jedoch erst später 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, 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 sich im Baum und eine beliebige Anzahl an Nodes unter sich.
+Jede Node ist entweder direkt unter der Root-Node oder einer anderen Node angeordnet.
-Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
+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 können.
 \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, welcher durch die darüber liegende Node ausgewertet werden kann.
  \item[Dekorations-Nodes]
   können den Rückgabewert einer anderen Node modifizieren.
-  Häufig existieren hier Negation, garantierter Erfolg und garantierter Fehler.
+  Häufig existieren hier die Negation, aber auch das forcieren eines bestimmten Rückgabewertes für die unterliegende Node.
  \item[Sequenz-Nodes]
-  beschreiben eine nacheinander ausgeführte Abfolge von anderen Nodes, welche mit spezifischen Randbedingungen weiter fortschreitet.
+  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]
-  werden verwendet, um Verhalten zu definieren, welches nur bei Fehlern in vorherigen Nodes ausgeführt wird.
+  verhalten sich ähnlich zu Sequenz-Nodes, jedoch werden darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurück gibt.
+  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}[]
@@ -76,27 +87,38 @@ Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
 
 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.
-Von dort an wird als erstes die Sequenz-Node ausgeführt, welche 3 untergeordnete Nodes besitzt.
+Von dort an wird als erstes die Sequenz-Node ausgeführt, welche drei untergeordnete Nodes besitzt.
 
-Die linke untergeordnete Node wird als erstes ausgeführt, ist jedoch eine weitere Fallback-Node mit weiteren untergeordneten Nodes.
+Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, ausgeführt.
-Diese werden auch von links nach rechts ausgeführt, bis die erste Node ein positives Ergebnis zurück gibt.
+Daraus resultierend wird als erstes die linke Node ausgeführt, diese ist jedoch eine Fallback-Node mit weiteren untergeordneten Nodes.
+Da der Rückgabewert der Fallback-Node von den in ihr befindlichen Nodes bestimmt wird, werden diese nun nacheinander ausgeführt.
+Hier gelten die oben genannten Regeln für Fallback-Nodes.
 In diesem Fall wird geprüft, ob die Tür bereits offen ist.
 Da dies nicht der Fall ist, wird die nächste Node ausgeführt, welche die Tür öffnen soll.
-Dieser Versuch gelingt, weshalb die Ausführung der Fallback-Node beendet wird.
+Dieser Versuch gelingt, weshalb die Ausführung der Fallback-Node mit einem Erfolg beendet wird.
 
 Dadurch wird die nächste Node in der Sequenz ausgeführt, welche prüft, ob die Tür durchlaufen werden kann.
-Da dies nicht möglich ist, wird ein Misserfolg gemeldet, welcher die Ausführung der Sequenz abbricht.
+Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet, welcher die Ausführung der Sequenz abbricht.
-Diese würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node immer neu startet.
+Diese würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.
 
 Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich so einfach 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, welche in dieser Arbeit bearbeitet werden, abzudecken.
+Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, welche in dieser Arbeit betrachtet werden, abzudecken.
 
 \section{Virtualisierungsumgebung als Platform}
 Aufgrund von vorheriger Erfahrung mit involvierten Einrichtungsprozessen, ist der Einsatz fest definierter Umgebungen unerlässlich.
-Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in welcher das zu entwerfende System ausgeführt wird.
+Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in der das zu entwerfende System ausgeführt wird.
 
-Durch diesen Zwischenschritt können benötigte Programme, Pfade und Umgebungsvariablen in der Virtualisierungsumgebung hinterlegt werden, welche diese bei der Ausführung auf einem anderen Grundsystem korrekt abbilden kann.
+Dadurch können benötigte Programme, Pfade und Umgebungsvariablen in der Virtualisierungsumgebung hinterlegt werden, welche diese bei der Ausführung auf einem anderen Grundsystem korrekt abbildet.
-Dies erhöht die Zuverlässigkeit der Umgebung, da alle Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden können.
+Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da alle Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
+
+Ein weiterer Vorteil ist die beschleunigte Entwicklung, da Ä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, welche mit den Vorteilen abgewogen werden müssen.
+Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, welche der virtualisierten Anwendung nicht mehr zur Verfügung steht.
+Außerdem muss bei grafischen Systemen bedacht werden, wie die darzustellenden Daten vom Hostsystem angezeigt werden können.
+
+Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung stellt einen wichtigen Schritt in der Entwicklung des Gesamtsystems dar.

tex/3_Auswahl.tex

@@ -1,34 +1,47 @@
 \chapter{Komponenten-/Softwareauswahl}
-Die Auswahl der verwendeten Softwarekomponenten ist ein wichtiger Schritt der Entwicklung, da diese Entscheidungen den späteren Entwicklungsprozess nachträglich beeinflussen.
+Die Auswahl der verwendeten Softwarekomponenten ist ein wichtiger Schritt der Entwicklung.
-Hierfür werden Komponenten ausgewählt, welche die im Konzept besprochenen Teilbereiche abdecken und miteinander verbunden werden können.
+Diese Entscheidungen beeinflussen die späteren Entwicklungsprozess nachhaltig.
 
-\section{Dienstumgebung (ROS2)}
+Im nachfolgenden findet die Auswahl der Komponenten statt.
+Diese sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
+Alle diese Teilbereiche können dann zu einer Simulation vebunden werden, welche das gesamte Problemfeld abdeckt.
+
+Wie bereits in Abbildung \ref{concept_overview} dargestellt, ist für die Erfüllung der Aufgaben eine Dienst- und eine Simulationsumgebung erforderlich.
+Dieses Kapitel beschreibt die Auswahl der Umgebungen und der in diesen laufenden Prozesse.
+\section{Dienstumgebung}
 Die Dienstumgebung bestimmt maßgeblich, wie Software im Entwicklungsprozess geschrieben wird.
-Durch sie werden häufig benötigte Funktionen bereitgestellt, welche in Programmen in der Umgebung genutzt werden können.
+Durch sie werden häufig benötigte Funktionen bereitgestellt, welche durch die Programme innerhalb der Umgebung genutzt werden können.
 
-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.
+Bei einer Dienstumgebung für Roboter gehören zu den grundlegenden Aspekten die Nachrichtenübergabe zwischen einzelen interagierenden Programmen, um eine gemeinsame Basis für ein einfach erweiterbares System zu schaffen.
+Außerdem sind Werkzeuge zur Einstellungsübergabe an Teilsysteme sinnvoll, um diese einfach an einer Stelle anpassen zu können.
 
 \subsection{Auswahl}
-Es existieren mehrere Systeme, welche als Dienstumgebung für Roboter in Frage kommen, wenn es nur um die Nachrichtenübergabe zwischen Programmen geht.
+Es existieren mehrere Systeme, die als Dienstumgebung für Roboter in Frage kommen, wenn es lediglich um die Nachrichtenübergabe zwischen Programmen geht.
 Jede Lösung, welche Nachrichten zwischen Prozessen austauschen kann, ist ein potentieller Kanidat für ein Roboterframework.
 
 Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition der Nachrichten, welche über das System ausgetauscht werden.
 
-Nutzbare, bereits als IPC integrierte Systeme sind zum Beispiel Pipes, welche Daten zwischen Prozessen über Buffer austauschen.
+Nutzbare, bereits als Interprozesskommunikation integrierte Systeme sind zum Beispiel Pipes, welche Daten zwischen Prozessen über Buffer austauschen.
 Auch die Nutzung von Message Queues und Shared Memory ist hierfür denkbar.
 Diese Systeme sind performant, jedoch nicht einfach zu verwalten, da sie von einer direkten Kommunikation von 2 oder mehr Komponenten, welche exakt für diesen Zweck entwickelt wurden, ausgehen.
 
-Eine Alternative stellen Sockets dar, welche Daten zwischen zwei Programmen austauschen können.
+Eine Alternative stellen Sockets dar, welche Daten zwischen mehreren Programmen austauschen können.
+Dabei dient ein Programm als Server, welches 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 potentiellen Variation zahlreicher Kommunikationsmechanismen, welche zum Datenaustausch über all diese möglichen Systeme verwendet werden können.
+Bei einem ausreichend großen Projekt treten so unweigerlich Unterschiede in der Handhabung auf, die es zu berücksichtigen gilt.
 
-In diesem Bereich sticht ROS als Dienstumgebung für Roboter hervor, da es sich um ein etabliertes, quelloffenes und häufig verwendetes System handelt.
+In diesem Bereich sticht ROS\cite{doi:10.1126/scirobotics.abm6074} als Dienstumgebung für Roboter hervor, da es sich um ein etabliertes und quelloffenes System handelt.
-Es bietet die oben genannten Aspekte und einige weitere Verbesserungen, welche später näher beleuchtet werden.
+Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standartisierte und erweiterbare Nachrichtendefinition gelöst, welche von den Programmen in der Umgebung genutzt werden.
+Um diese Nachrichten zu senden und empfangen liefert ROS eine eigene Implementation des Protokolls für zum Beispiel Python\cite{python} und C++\cite{cpp}, welche mehrere Arten der Nachrichtenübergabe unterstützten.
 
 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.
+Ein neues Nachrichtenformat mit Quality of Service kann zum Beispiel Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
-Außerdem werden nun neben CMake auch andere Buildsysteme unterstützt, unter anderem auch Python.
+Außerdem werden nun neben CMake\cite{cmake} auch andere Buildsysteme unterstützt, was zum Beispiel die Verwendung von Python erlaubt.
 
-Generell existieren im Feld der Roboter-Dienstumgebungen keine Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
+Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
 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}
 
 ROS kann für sowohl simulierte Umgebungen, aber auch für echte Roboter eingesetzt werden, da beide Anwendungsfälle durch Programme an die Umgebung angebunden werden können.
@@ -44,88 +57,114 @@ ROS2\cite{doi:10.1126/scirobotics.abm6074}, später auch einfach nur ROS genannt
 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.
+Einzelne Bestandteile in der Umgebung sind dabei in Pakete gegliedert, wobei jedes Paket beliebig viele Daten und Programme beinhalten kann.
-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.
+Jedes Paket enthält dabei eine \code{package.xml}-Datei, welche durch die Paketverwaltung genutzt wird.
+In dieser befindet sich eine in XML verfasste Definition des Paketinhalts, welche verschiedene Aspekte des Pakets beschreibt.
+
+Darunter fallen Informationen über den das Paket selbt, 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 außerdem benötigte Pakete für die Erstellung und Ausführung des Pakets eingetragen.
+
+Falls C++ zur Entwicklung des Pakets verwendet wird, befindet sich außerdem eine \code{CMakeLists.txt}-Datei im Paket.
+In  befinden sich die Buildinstruktionen für den Compiler für die im Paket befindlichen Programme.
+Durch einen Aufruf von \code{ament_cmake} werden andere Parameter aus der \code{package.xml}-Datei ergänzt.
+
 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.
+Programme, welche mit anderen Programmen in der Umgebung über die ROS internen Schnittstellen kommunizieren, 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.
+  ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
-  Hierfür werden CMake und einige Erweiterungen, wie z.B. ament\_cmake eingesetzt.
+  Zu deren Konfiguration werden CMake\cite{cmake} und einige Erweiterungen, wie zum Beispiel das oben erwähnte \code{ament_cmake} eingesetzt.
+  Anhand dieser Dateien werden die fertiggestellten Pakete dann im Workspace installiert, damit diese später verwendet werden können.
 
  \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.
+  Das Skript des Pakets fügt nur dieses Paket der Umgebung hinzu, das Skript des Workspaces führt alle Skripte der in diesem enthaltenen Pakete aus, um diese allesamt 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.
+  ROS kann durch die in den Paketen deklarierten Abhängigkeiten prüfen, ob diese in der aktuellen Umgebung ausführbar sind.
-  Dies vermeidet Abstürze und undefiniertes Verhalten in der Ausführung von Nodes.
+  Die generierten Warnungen bei fehlenden Paketen vermeiden Abstürze und undefiniertes Verhalten in der Ausführung von Nodes, welche diese benötigen.
 
  \item[Datenübertragung]\hfill \\
-  Nodes müssen miteinander auf einem festgelegten Weg kommunizieren können, um beliebige Verbindungen dieser zu unterstützen.
+  Um Daten zwischen Nodes austauschen zu können, müssen miteinander auf einem festgelegten Weg kommunizieren können.
-  Dieser wird durch ROS in Form mehrerer Bibliotheken für unterschiedliche Sprachen bereitgestellt.
+  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, welche 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, welche zum Beispiel Rückgabewerte zum aktuell ausgeführten Steuerbefehl liefert.
 
  \item[Parameterübergabe]\hfill \\
-  Nodes benötigen häufig problemspezifische Konfiguration, um in vorher nicht bedachten Szenarien eingesetzt werden zu können.
+  Um Nodes auf neue Anwendungsfälle anpassen zu können, wird ein Konfigurationsmechanismus benötigt.
-  ROS stellt diese durch deklarierfähige und integrierte Argumente bereit.
+  In ROS geschieht dies durch die Übergabe sogenannter Parameter, welche durch die Node gelesen werden können.
+  Diese eignen sich zur Übergabe von Informationen, wie zum Beispiel einem Robotermodell, aber auch um die Topics der Nodes umbenennen zu können.
 
  \item[Startverwaltung]\hfill \\
   In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
+  Dabei werden diese mit den gewünschten Parametern versehen, welche verschiedene Eigenschaften der Node an die aktuelle Umgebung anpassen können.
+
 \end{description}
+Durch eine solche Umgebung kann die gewünschte Simulation einfacher in mehrere Komponenten zerlegt werden, was die spätere Wartung des Projekts vereinfacht.
 
 \section{Simulationsumgebung (Gazebo)}
 
 \subsection{Auswahl}
-Als Simulationsumgebung können verschiedene Programme genutzt werden, welche sich in ihrem Funktionsumfang stak unterscheiden.
+Als Simulationsumgebung eignen sich verschiedenen Programme, die sich hinsichtlich ihres Funktionsumfangs stark unterscheiden.
-Hierfür kommen dedizierte Werkzeuge zur Robotersimulation, aber auch zum Beispiel universell einsetzbare Gameengines in Frage.
+Hierfür kommen dedizierte Werkzeuge zur Robotersimulation, aber auch beispielsweise universell einsetzbare Gameengines in Frage.
-Diese Werkzeuge müssen hierfür auf ihre Tauglichkeit für die gesetzte Aufgabe geprüft werden.
+Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da der gebotene Funktionsumfang der Softwares sich stark unterscheidet.
-Auch andere Aspekte sind hierbei zu betrachten, wie Lizenzen oder schwer bewertbare Aspekte wie Nutzerfreundlichkeit.
+Auch andere Aspekte, wie Lizenzen oder schwer bewertbare Aspekte wie Nutzerfreundlichkeit, sind hierbei zu betrachten.
-Für die Auswahl kommen verschiedene Prgramme in Frage, welche im folgenden weiter beleuchtet werden.
+Eine Auswahl der als Simulationsumgebung in Frage kommenden Programme werden hier vorgestellt.
 
-CoppeliaSim, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
+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, 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 Ignition\cite{gazebo} 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.
+Unity\cite{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.
+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 einer Drittlösung erlaubte, eine ROS-Anbindung für Unreal Engine zu erstellen.
+Die Programmierung der Engine erfolgt in C++, was die Erstellung eines Plugins zur ROS-Anbindung der Unreal Engine ermöglichte, welche 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 dar.
+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 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.
+Alle vorgestellten Softwares besitzten 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.
+Aus diesen Funktionen kann ein Roboterarm aufgebaut werden, welcher dann durch eine ROS-Brücke gesteuert werden kann.
 
-Die Wahl der Simulationsumgebung fiel auf Gazebo Ignition, da dieser Simulator bereits im ROS-Framework etabliert ist.
+Um den Entwicklungsvorgang zu beschleunigen, ist die Auswahl einer Umgebung mit bereits existierender ROS-Unterstützung sinnvoll.
-Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschidlichsten Szenarien.
+Durch diese Einschränkung scheiden sowohl Unreal Engine aber auch Godot aus, welche nur durch Nutzer unterstützt werden.
-\subsection{Verwendete Dateiformate}
+Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese in nahezu allen Umständen eingesetzt werden kann.
+
+Die Wahl der Simulationsumgebung fiel deshalb auf Gazebo Ignition, welches gleichzeitig bereits im ROS-Ökosystem etabliert ist.
+Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
+\subsection{Welt- und Modellbeschreibung}
 Um die Simulationsumgebung zu beschreiben, nutzt Gazebo das .sdf-Dateiformat\cite{sdf-format}.
-Dieses Format basiert auf XML und wird zur definition gesamter Welten, aber auch einzelner Objekte benutzt.
+Dieses Format basiert auf XML und wird zur Definition gesamter Welten, aber auch einzelner Objekte innerhalb dieser Welten benutzt.
 
 Um verschiedene Versionen des Formats zu unterstützen, enthält das einzige sdf-Element die gewünschte Versionsnummer.
-In diesem befinden sich entweder ein Modell, Actor oder Licht, oder mindestens eine Welt.
+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 Aubau des Simulators.
 Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten der Simulationsumgebung.
@@ -140,89 +179,134 @@ Die Deklaration eines weiteren Untermodells ist möglich, um komplexere Struktur
 
 Jedes Modell wird über eine Translation und Rotation im Simulationsraum verankert, wobei das Referenzsystem des überliegenden Modells genutzt wird.
 Außerdem können im Modell Einstellungen für dessen Physiksimulation vorgenommen werden.
-Für unbewegliche Modelle sollte ein \code{static}-Element auf 1 gesetzt werden, um dieses unbeweglich zu machen.
 
+Ein Modell enhält meißt mindestens ein Link-Element, welches 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 dieses Dateiformat ungeeignet für Roboterdefinitionen macht.
+
+Lichter besitzen einen Lichttyp, welcher die Ausbreitung des Lichtes im Raum bestimmt.
+Die erste Art ist direktionales Licht, welches parallel zur gewünschten Achse auftrifft, welches vor allem zur grundlegenden Raumausleuchtung genutzt werden kann.
+Außerdem existieren noch Punktlichtquellen, welche von einer Position im Raum ausgehen und Spots, welche außerdem noch nur einen gewissen Winkel abdecken.
+
+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 Simulation eines Menschen erlaubt.
+Eine solche Befehlsfolge kann jedoch nicht von außerhalb der Simulation zur Laufzeit angepasst werden, was weitere Entwicklungsarbeit erforderlich macht.
 
 \subsection{Robotersimulation}
 Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Simulationsumgebung beschrieben wird.
-Gazebo nutzt hierfür .srdf-Dateien, welche auf xml basieren.
+Gazebo und ROS nutzen hierfür .urdf-Dateien\cite{urdf-format}, welche auf XML basieren.
-In diesen werden die einzelnen Glieder des Arms und die verbindenden Gelenke beschrieben.
+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 in Gazebo und die Kollisionserkennung in der Physiksimulation hinterlegt.
+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 kann so jeder Roboteraufbau beschrieben werden.
+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, um dessen Effekte je nach Typ des Gelenks berechnen zu können.
+Jedes Gelenk besitzt eine Position und Rotation im Raum, um dessen Effekte, welche vom Gelenktyp abhängen, berechnen zu können.
-Aspekte wie Reibung und Dämpfung können auch für die Physiksimulation angegeben werden.
+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 genutzt 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. Sie stellen den normalen Zustand der Gelenke zueinander dar.
+  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 für zum Beispiel Bodenkollisionen eingesetzt.
+  erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden zum Beispiel für Bodenkollisionen eingesetzt.
  \item[feste Gelenke]
-  sperren alle 6 Freiheitsgrade und werden häufig zur Plazierung von Objekten in einer Szene genutzt.
+  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 kontinuerliche Gelenke, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
+  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. Denkbare Anwendungsfälle sind simulierte lineare Aktuatoren.
+  ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Sie werden zur Umsetzung von Linearaktuatore in der Simulation verwendet.
 \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.
+Für diesen existiert bereits ein Modell 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 setzt jedoch voraus, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
-Dies ist auf die Definition der Pfade, welche die Bewegung auslösen, zurückzuführen.
+Der Grund dafür ist auf die Definition der Pfade, welche die Bewegung auslösen, zurück zu führen.
 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 mögliche Simulationsumfang nicht ausreichend.
+Durch diesen Umstand ist der somit realisierbare Simulationsumfang nicht ausreichend, um die gewünschten Szenarien abzubilden.
 
-Um dieses Problem zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
+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, welcher die Befehle entgegennimmt, unter konstantem Feedback ausführt und nach Erfolgreicher Ausführung den Empfang des nächsten Befehlts zulässt.
 
-Ein solches System sollte als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, welche konstant weiter entwickelt wird.
+Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, welche konstant weiter entwickelt wird.
 Dies erlaubt die einfachere Wartung, da bei Updates der Simulationsumgebung nicht die Menschensimulation an den neuen Code angepasst werden muss.
-\section{Roboterumgebung (MoveIt2)}
+\section{Roboterumgebung}
-MoveIt 2 ist das empfohlene ROS2 Paket für Bewegungsplanung von Robotern.
+MoveIt2\cite{moveit-docs} ist das meist genutzte ROS2 Paket für Bewegungsplanung von Robotern.
-Das System besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
+Deshalb existiert viel Dokumentation für die zahlreichen Komponenten, was die Entwicklung erleichtert und zahlreiche direkte Integrationen mit anderen ROS-Paketen, wodurch diese einfacher zusammen genutzt werden können.
-Der Nutzer kann mit MoveIt auf mehreren Wegen Steuerbefehle für den Roboter absenden.
+Diese Eigenschaften machen das Paket als Roboterumgebung für dieses Projekt extrem attraktiv.
 
-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.
+MoveIt besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
-Dort können Bewegungen durch das Bewegen von Markierungen oder  in der Simulation geplant und ausgeführt werden.
+Der Nutzer kann mit MoveIt auf verschiedenen Wegen Steuerbefehle für den Roboter absenden, welche durch die Software umgesetzt werden.
 
-Da sich ein solches System nur beschränkt zur Automatisierung durch Software eignet, existieren auch noch andere Schnitstellen.
+Die einfachste Art der Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files, welche durch einen mitgelieferten Setupassistenten für den Roboter generiert werden.
-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}
+Durch die Ausführung dieser Demo startet RViz, eine Test- und Visualisierungsumgebung für ROS.
+Darin können Roboterbewegungen unter Zuhilfenahme von Markierungen in RViz geplant und ausgeführt werden.
 
-Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt auf einer abstrakteren Ebene zu interagieren.
+Da sich eine solche Bewegungsplanung 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 MoveIt noch das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, welches 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 kann sowohl die Planung und Ausführung von Bewegungen ausgelöst werden, 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, jedoch ist so kein einfacher Zugriff auf erweiterte Optionen möglich.
 
-Aus einem Robotermodell können nun die Informationen, welche von MoveIt über den zu kontrollierenden Roboter benötigt werden, generiert werden.
+Um die durch den Setupassistenten generierten Informationen an MoveIt zu übergeben, wird intern ein RobotStatePublisher verwendet.
-Diese werden über einen RobotStatePublisher an MoveIt übergeben, welches daraus das Robotermodell für die Bewegungsplanung generiert.
+Dieser läd alle Daten des Robotermodells und gibt sie an andere Programme weiter, welche diese zur Laufzeit anfordern, unter diesen auch MoveIt selbst.
 
 Durch die vorher erwähne 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, welche sich um den Roboter befinden.
+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 Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
+Eine solche Erweiterung erlaubt die automatische 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 \code{ros_control} weitergegeben.
+Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an die \code{ros_control} Controller des Roboters weitergegeben.
-Dabei können sowohl echte Hardwaretreiber, aber auch simulierte Roboter genutzt werden.
+
+Diese Abstaktion erlaubt die Nutzung von sowohl simulierten, aber auch echten Robotern.
+Hiefür kann einfach ein anderer \code{ros_control} Controller geladen werden, welcher entweder die simulierte oder echte Hardware ansteuert.
 Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
 
 Im Falle von Gazebo wird \code{ign_ros_control} genutzt, welches die benötigten \code{ros_control} Controller in die Simulation einbindet.
 Diese können dann wie normale Controller von \code{ros_control} genutzt werden.
 
-Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
+Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} im Anhang visualisiert.
+
+\section{Programmiersprache}
+Als Programmiersprache kommen in ROS standartmäßig Python\cite{python} und C++\cite{cpp} zum Einsatz.
+Diese beiden Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark in Funktionsumfang und Entwicklungsprozess.
+
+Python ist eine interpretierte Skriptsprache, welche zu den hohen Programmiersprachen zählt.
+Sie wird in ROS zum Beispiel in .launch.py-Dateien eingesetzt, welche 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 kompillierte, statisch typisierte, maschinennahe Programmiersprache.
+In ROS wird C++ für Code verwendet, welcher entweder häufig oder in zeitkritischen Szenarien ausgeführt wird.
+Aus diesem Grund wird C++ in Nodes verwendet, welche 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, welche dann wieder kompilliert werden müssten.
+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 umsetzen zu können, ist die Programmierung in C++ nötig.
+Da zum Beispiel Gazebo-Plugins auf C++ als Programmiersprache ausgelegt sind, was die Nutzung anderer Sprachen stark erschwert.
+Ein Grund dafür ist die hohe Geschwindigkeit, welche bei einer hohen Anzahl an Simulationsschritten pro Sekunde benötigt wird.
+Außerdem kann MoveIt2 zur aktuellen Zeit 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 BehaviorTrees genutzt werden, welche durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
-Diese Bibliothek wurde in C++ geschrieben, und ist somit einfach in ROS integrierbar.
+Diese Bibliothek wurde in C++ geschrieben, und ist somit einfach in ROS und dem geplanten Konzept integrierbar.
 
 Es existieren aber auch viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen, welche im folgenden vorgestellt werden.
 
@@ -232,12 +316,14 @@ Es existieren aber auch viele Beispiele und eine gute Dokumentation über die er
   Dies resultiert in Nodes, welche ohne spezielle Logik langanhaltende Aktionen ausführen können, ohne die Ausführung des BehaviorTrees zu behindern.
   \item[Reaktives Verhalten] ist ein neues Konzept, um die Handhabung von asnchronen Nodes zu vereinfachen.
   Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, welche aktuell ausführende Aktionen beeinflussen können.
-  \item[Das .xml-Format] ermöglicht einen einfachen Austausch des Verhaltens, ohne die unterliegende Programmierung verändern zu müssen.
+  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 einfachen Austausch des Verhaltens, ohne die unterliegende Programme verändern zu müssen.
   Dies ist vor allem in kompillierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompillierung 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 mehrfachen Nutzen von Code.
-  \item[Datenfluss] zwischen den Nodes erlaubt es, von außen konfigurierbares Verhalten der Nodes zu erreichen.
+  \item[Das Blackboard] ist eine Schicht, welche den Datenfluss zwischen den Nodes erlaubt.
-  Diese können dabei sowohl statisch, als auch dynamisch über sogenannte Ports mit Informationen versorgt werden.
+  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 Zustandsmaschienen erheblich, da das Verhalten genau untersucht werden kann.
 \end{description}
@@ -245,12 +331,15 @@ Es existieren aber auch viele Beispiele und eine gute Dokumentation über die er
 BehaviorTrees werden in \code{BehaviorTree.CPP} als .xml-Dateien gespeichert.
 Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeports.
 
-Solche Ports können verwendet werden, um Nodes generischer gestalten zu können.
+Ports können verwendet werden, um Nodes generischer zu gestalten.
-So kann auf feste Parameter in den Nodes selber verzichtet werden, was das erstellen mehrerer Nodes für ähnliche Funktionalitäten verhindert.
+Durch veränderbare Parameter im später erstellten Tree können Nodes ohne Programmänderung verändert werden.
-Diese Daten können sowohl aus einem String ausgelesen werden, falls die ensprechende Funktion, welche diese in den Zieltyp übersetzt, implementiert wurde.
+Falls die Nodes mit Bedacht erstellt wurden, kann so auf viele spezialisierte Nodes verzichtet werden, da deren Funktionen aus einfacheren Nodes mit variablen Parametern abgebildet werden kann.
-Aber sie können auch aus dem sogenannten Blackboard entnommen werden.
+Diese in den Ports übertragenen Daten können sowohl aus einem String ausgelesen, aber auch aus dem sogenannten Blackboard entnommen werden.
 
-Das Blackboard ist ein System, welches die Nutzung von Variablen als Parameter für Ein- und Ausgänge erlaubt.
+Um die Übersetzung aus einem String zu ermöglichen, muss eine entsprechende Funktion implementiert werden, welche diesen String in den gewünschten Zieltyp übersetzt.
+Viele einfache Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von BehaviorTree.Cpp bereits durch mitgelieferte Funktionen unterstützt.
+
+Das Blackboard ist ein System, welches 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 BehaviorTrees.
 Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, welche zu komplexeren Strukturen zusammengesetzt werden können.
@@ -258,34 +347,40 @@ Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzb
 Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Nodes als sogenannte SubTrees abspeichern.
 Diese bilden dann in ihrer Gesamtheit eine neue Node, welche im BehaviorTree eingesetzt werden kann.
 Um den Einsatz von Variablen innerhalb eines SubTrees zu ermöglichen, besitzt jeder SubTree ein separates Blackboard.
-Dadurch kann ein Eingriff in äußere Funktionalität verhindert werden.
+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, einfach als Parameter an den SubTree übergeben werden.
 Die Bibliothek \code{BehaviorTree.CPP} verbindet dann diese Werte und erlaubt die Datenübergabe zu und von dem SubTree.
 
 \subsection{Asynchrone Nodes}
-Da nicht jeder Prozess in einem einzigen Durchlauf des BehaviorTrees abgebildet werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
+Da nicht jeder Prozess sofort vollständig durchgeführt werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
-Dies geschieht in in \code{behaviortree_cpp_v3} durch asynchrone Nodes.
+Dies geschieht in \code{BehaviorTree.CPP} durch asynchrone Nodes.
 
-Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE auch noch die beiden anderen Zustände RUNNING und IDLE.
+Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE einer normalen Node auch noch die beiden neuen Zustände RUNNING und IDLE.
+Außerdem werden mehrere Funktionen definiert, welche den Lebenszyklus der Node darstellen.
+
+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, welche sich noch in der Ausführung befindet.
-So lang dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand abgefragt.
+So lang 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, welcher nur durch eine vollständige Ausführung erreichbar ist.
-Er wird von der Node angenommen, nachdem ein RUNNING Zustand durch entweder SUCCESS oder FAILURE beendet wurde und darf sonst nicht verwendet werden.
+Er wird von der Node angenommen, nachdem deren Ausführung durch SUCCESS oder FAILURE beendet wurde.
 
+Im Falle eines Abbruchs, welcher durch andere Nodes im Baum ausgelöst werden könnte, muss die Ausführung der Node vorzeitig beendet werden.
+Dies geschieht mit der neuen \code{onHalted}-Funktion, welche die Ausführung der Node abbrechen kann.
 \subsection{Dateiformat}
-Das verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
+Das in BehaviorTree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
 Jedes Dokument beginnt dabei mit einem Root-Element, welches alle BehaviorTrees und eine Referenz auf die ID des Hauptbaumes enthält.
 Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genuzt werden können, diese aber sonst nicht vom Hauptbaum unterscheidbar sind.
 
 Jeder Baum beginnt mit einem BehaviorTree-Element, welches als Attribut die ID des Baumes besitzen muss.
 Als untergeornete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
 
-Zur besseren Visualisierung der XML-Struktur wurde hier die bereits aus dem Konzept bekannte Baumstruktur, hier noch einmal unter Abbildung \ref{choice_tree_demo} zu sehen, in XML umgewandelt.
+Zur besseren Visualisierung der XML-Struktur wurde hier die bereits aus dem Konzept bekannte Baumstruktur, hier noch einmal in Abbildung \ref{choice_tree_demo} zu sehen, umgewandelt.
-Dabei ist zu beachten, dass die Root-Node nicht in der Struktur existiert.
+Die resultierende Datei ist in Abbildung \ref{choice_tree_xml} abgebildet.
+Dabei ist zu beachten, dass die Root-Node nicht in der Struktur 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/tree_demo}
@@ -294,39 +389,41 @@ Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber au
 \label{choice_tree_demo}
 \end{figure}
 \begin{figure}[hpt]
-\begin{lstlisting}[]
+\begin{minted}[breaklines,frame=single,linenos]{xml}
 <?xml version="1.0"?>
 <root main_tree_to_execute="demoTree">
     <BehaviorTree ID="actorTree">
         <Sequence>
             <Fallback>
-                <Action ID="IsDoorOpen"\>
+                <Action ID="IsDoorOpen"/>
-                <Action ID="OpenDoor"\>
+                <Action ID="OpenDoor"/>
-                <Action ID="BreakDoor"\>
+                <Action ID="BreakDoor"/>
             </Fallback>
-            <CanWalkThrough\>
+            <CanWalkThrough/>
-            <WalkThrough\>
+            <WalkThrough/>
         </Sequence>
     </BehaviorTree>
 </root>
-\end{lstlisting}
+\end{minted}
 \caption{Beispiel eines BehaviorTrees als .xml}
 \label{choice_tree_xml}
 \end{figure}
 
 \section{Docker-Compose als Virtualisierungsumgebung}
-Docker ist eine Virtualisierungsumgebung für Anwendungen, welche die komplette Umgebung für deren Ausführung bereitstellen.
+Docker ist eine Virtualisierungsumgebung für Anwendungen, welche die komplette Umgebung für deren Ausführung bereitstellt.
-Dadurch wird die Inbetriebnahme von Anwendungen, welche spezielle Umgebungen für ihre Ausführung benötigen, ermöglicht.
+Dadurch wird die Inbetriebnahme von Anwendungen, welche spezielle Umgebungen für ihre Ausführung benötigen auf beliebigen Systemen ermöglicht.
 
-Dies wird durch den Einsatz von sogenannten Containern erreicht, welche durch Buildfiles definiert werden.
+Dies wird durch den Einsatz von sogenannten Containern erreicht.
-Ein Buildfile enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.
+Ein solcher Container wird über sogenannte Build-Files definiert.
-Die so erstellten Container können entweder lokal oder auf einem Server für die Verwendung bereitgehalten werden.
+Ein 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 ausführenden Rechner erstellt.
+Um diesen Prozess weiter zu beschleunigen, ist auch der Einsatz eines Buildservers möglich, welcher benötigte Container als Download bereitstellt.
 
-Ein solcher Container enthält ein eigenes Dateisystem, welches aus dem im Buildfile definierten Dateien und einem Overlay besteht.
+Jeder Container enthält ein eigenes Dateisystem, welches aus dem im Buildfile definierten Dateien und einem Overlay besteht.
 In diesem Overlay werden Änderungen gespeichert, welche am Container während der 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 im \code{/var/lib/docker} Verzeichnis, oder ein ``bind mount'' in der compose.yml-Datei eingerichtet werden.
+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, welche in den Container hereingereicht wird.
 
 Docker-Compose stellt eine Erweiterung von Docker dar, welche die Inbetriebnahme der Container über ein spezielles Dateiformat verwaltet.

tex/4_Umsetzung.tex

@@ -17,10 +17,101 @@ Anhand der hier genannten Änderungen wurde die Übersicht des Systems angepasst
 \label{umsetzung_overview}
 \end{figure}
 
+\section{Docker-Compose}
+Um Docker für die Verwaltung einer ROS-Installation verwenden zu können, müssen einige Anpassungen vorgenommen werden.
+Da viele Anwendungen, unter anderem auch die Simulationsumgebung, eine Desktopumgebung benötigen, muss eine Zugriffsmöglichkeit geschaffen werden.
+
+Diese Möglichkeiten können nicht durch Docker allein gelöst werden, da Befehle auf dem Hostsystem ausgeführt werden müssen, um die gewünschten Funktionen zu aktivieren.
+Um diese Modifikationen trotzdem reproduzierbar zu machen, wurde ein Shellscript geschrieben, welches zum Starten des Containers verwendet wird.
+
+Dieses Skript erstellt zuerst die benötigten Verzeichnisse für den Container, falls diese noch nicht existieren.
+Danach werden die SSH-Keys des Hosts in den Container kopiert, um eine SSH-Verbindung zu ermöglichen.
+Dieser Umweg über SSH ist nötig, da die benötigten Umgebungsvariablen für ROS sonst nicht in allen Fällen gesetzt werden können.
+
+Außerdem werden die benötigten Zugriffe auf den lokalen X-Server durch den Container anhand dessen Hostname erlaubt.
+Diese Änderung erlaubt es dem Container, Fenster auf dem Desktop anzeigen zu können, solange die benötigten SysFS-Dateien hereingereicht werden.
+Dies geschieht durch Einträge in der compose.yml-Datei, welche diese als ``bind mount'' in den Container hereinreicht.
+
+Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repräsentation im SysFS unter \code{/dev/dri} hineingereicht werden.
+Der Zugriff auf die Desktopumgebung, welcher bereits entsperrt wurde, wird nun durch das mounten von \code{/tmp/.X11-unix} erreicht.
+Dabei handelt es sich um den Unix-Socket des X11 Displayservers.
+
+Zum Starten des Containers muss der Befehl \code{./start.sh} im Verzeichnis der Containerinstallation ausgeführt werden, welcher die obengenannten Schritte ausführt und den Container startet.
+Eine Verbindung zum Container kann aufgebaut werden, nachdem die Meldung \code{ros_1 | Ready to connect.} in der Konsole erscheint.
+
+Dafür muss ein SSH-Client eingesetzt werden, welcher eine Verbindung zu der lokalen Netzadresse des Systems mit dem Benutzer \code{ros} aufbauen kann.
+Der Port des SSH-Servers wird dabei durch die Deklaration im docker-compose.yaml an das Hostsystem durchgereicht.
+Hierbei ist zu beachten, dass der SSH-Server im Container auf Port 2222 ausgeführt wird, was bei der Verbindung beachtet werden muss.
+
+Nach der Verbindung wird automatisch die ROS2-Umgebung eingerichtet, welche sofort nach Verbindungsaufbau genutzt werden kann.
+Um die erstellten Pakete zu kompillieren, kann das Skript \code{build.sh} im \code{workspace}-Verzeichnis verwendet werden.
+
+\begin{minted}[breaklines,frame=single]{bash}
+#!/bin/bash
+pushd "$(dirname "$0")" || exit
+colcon build --event-handlers console_cohesion+ --cmake-args -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -G Ninja
+popd || exit
+\end{minted}
+
+Dieses Skript nutzt \code{colcon}, um alle Pakete in \code{~/workspace}-Verzeichnis zu erstellen.
+Dabei wird auch eine \code{compile_commands.json}-Datei im build-Unterordner erstellt, welche von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden.
+Um eine Nutzung in allen Umgebungen zu erlauben, wurde diese in das Hauptverzeichnis gelinkt, da einige Umgebung nur dort nach dieser Datei suchen.
+
+
+Da der Kompilliervorgang parallel abläuft, erscheinen Informationen zu allen Paketen gleichzeitig, was das Finden eines Fehlers erschwert.
+Um trotzdem alle wichtigen Informationen zu erhalten, kommt der Event-Handler \code{console_cohesion+} zum Einsatz, welcher die Ausgaben neu formatiert.
+Durch diesen werden die Ausgaben gruppiert, und erst nach einen vollständigen Kompilliervorgang eines Pakets nacheinander ausgegeben.
+Dies ermöglicht es, aufgetretene Fehler einfacher auf ein bestimmtes Paket zurückführen zu können, ohne das gesamte Log zu durchsuchen.
+Hierbei ist es hilfreich, dass die verbleibenden Kompilliervorgänge abgebrochen werden, falls der Kompilliervorgang eines Pakets fehlschlägt.
+Dadurch befindet sich der Fehlers immer im letzten Paket der Ausgabe, da alle anderen Prozesse abgebrochen und nicht ausgegeben werden.
+
+\section{Entwicklungsumgebung}
+
+Ein einfacher Texteditor ist für das Schreiben von ROS-Packages ausreichend und bietet bei der Arbeit mit Containern sogar einen großen Vorteil.
+Das Editieren von Dateien ist mit einem Texteditor auch von außerhalb des Containers möglich.
+Jedoch besitzt ein Texteditor nur wenige Funktionen einer vollständigen Entwicklungsumgebung, welche den Prozess der Softwareentwicklung beschleunigen.
+Um diese Funktionen bieten zu können, analysieren Entwicklungsumgebungen den geschriebenen Code.
+Dies geschieht meißt auf eine von zwei unterschiedlichen Weisen.
+
+Die Entwicklungsumgebung kann eine interne Repräsentation des geschriebenen Codes generieren.
+Diese Repräsentation kann nun genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen.
+Um dies zu erreichen, muss für jede unterstützte Sprache Code geschrieben werden, welcher in die Entwicklungsumgebung integriert werden muss.
+
+Als Alternative existiert das Language Server Protocol, kurz LSP, welches eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Infomationen über den Code an die Entwicklungsumgebung zu übergeben.
+Dies erlaubt einer Entwicklungsumgebung, nur noch den benötigten Server der Sprache zu starten, um Informationen über den Code in einem standartisierten Protokoll zu erhalten.
+
+Der große Vorteil des LSP ist, dass eine Entwicklungsumgebung alle Funktionen der Programmiersprache vollständig unterstützt, solange das Protokoll vollständig implementiert wurde und ein entsprechender Server für die Sprache existiert.
+
+Jedoch können bestimmte Funktionen, welche beim Design des LSP nicht bedacht wurden, einfacher in interner Implementation umgesetzt werden.
+Deswegen haben Entwicklungsumgebungen mit interner Coderepräsentation häufig mehr Funktionen, spezialisieren sich jedoch auf bestimmte Sprachen.
+
+In diesem Projekt wurden mehrere Entwicklungsumgebungen mit den jeweils unterschiedlichen Verfahren verwendet.
+Um diese mit dem Docker-Container verwenden zu können, müssen diese Umgebungen die Entwicklung auf entfernten Systemen unterstützten, da der Container vom ausführenden System getrennt ist.
+
+Um dies zu ermöglichen, wird ein Teil der Entwicklungsumgebung im Container ausgeführt, um mit dem inneren Kontext der Maschine arbeiten zu können.
+Dazu wird beim Start einer Verbindung zu einem entfernten System dieser Server auf das Zielsystem übertragen und gestartet.
+
+Die anfängliche Entwicklung wurde mit PyCharm und CLion durchgeführt, da diese durch ihre interne Codeanalyse die ROS-Umgebung ohne Konfiguration nutzen konnten.
+Jedoch sind diese Umgebungen sehr ressourcenintensiv, was die gleichzeitige Ausführung erheblich verlangsamt.
+
+Aus diesem Grund wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce, verwendet.
+Dazu wurden dem Container die benötigten LSP-Server hinzugefügt und konfiguriert, um diese mit Lapce nutzen zu können.
+Unter Verwendung dieser neuen Server kann Lapce nun Codevervollständigung und Codeanalyse wie PyCharm und CLion durchführen.
+Dabei wird auch der Ressourcenverbrauch gesenkt, da nur ein einziger Editor benötigt wird.
+
+\begin{figure}[hpt]
+\includegraphics[width=\textwidth]{img/MA-Umsetzung-Lapce}
+\centering
+\caption{Entwicklungsumgebung Lapce}
+\label{lapce}
+\end{figure}
+
 \section{Verwendete Datentypen}
-In der Implementation werden unterschiedliche Datentypen verwendet.
+In diesem Projekt werden viele unterschiedliche Datentypen verwendet.
+Diese Datentypen sind größtenteils aus der Programmiersprache C++ bekannt, jedoch werden auch weitere Typen aus eigenem Code oder eingebundenen Bibliotheken verwendet.
+Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Implementation verwendeten Datentypen hier zusammengefasst und beschrieben.
 \begin{description}
-  \item[geometry_msgs::msg::Pose]
+  \item[Pose]
   ist einer der häufigsten Datentypen im Umgang mit Gazebo. Dieser Datentyp enthält die Information über die Lage und Rotation eines Objekts im Raum.
   Diese werden als relative Werte im Bezug auf das übergeornete Objekt gespeichert.
   Objekte wie der Mensch liegen in der Hierarchie der Simulation direkt unter der Welt, welche sich direkt im Nullpunkt und ohne Rotation befindet.
@@ -44,7 +135,7 @@ In der Implementation werden unterschiedliche Datentypen verwendet.
   Der \code{animationSpeed} Parameter beschreibt entweder die Abspielgeschwindigkeit der Animation, oder die Distanz, welche pro Animationsdurchlauf zurückgelegt wird.
   Außerdem wird im Falle einer Bewegung der Parameter \code{target} vom Typ Pose verwendet, um die Endposition und Rotation des Actors zu bestimmen.
 \end{description}
-\section{Welt}
+\section{Simulationswelt}
 Die Welt der Simulation wird im Paket \code{ign_world} zur Verfügung gestellt.
 In diesem Paket sind sowohl die Geometrien der Welt, aber auch die benötigten Dateien zum Starten der Simulation enthalten.
 
@@ -60,27 +151,26 @@ Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch
 Eine Nutzung im Kollaborationsszenario ist nicht nicht geplant, da der Mensch den Roboter überwachen und dessen Fehler korrigieren soll.
 
 Der so geplante Raum wurde in Blender modelliert und als .stl-Datei exportiert, um sie in die Welt einbinden zu können.
-Für das Kooperationsszenario wurde ein weiterer Raum mit Förderband erstellt, welcher nur dort genutzt wird.
+Für das Kooperationsszenario wurde ein Förderband moddeliert, welches in diesem Szenario dem Raum hinzugefügt wird.
-Der so erstellte Raum wird nun in einer separaten .sdf-Datei referenziert, welche
 
-Diese Entscheidung limitiert wie der Raum in die Simulation eingebunden wird, da mehrere unterschiedliche Räume je nach ausgewähltem Szenario geladen werden müssen.
+Der so erstellte Raum wird in einer .sdf-Datei als Modell referenziert, um diesen später in die Simulation einbinden zu können.
-Hierfür wird, wie später auch für den Roboter selbst, das Paket \code{ros_gz_sim} verwendet.
+Das Förderband erhält ein eigenes Modell in einer weiteren Datei, welche zur Laufzeit in die Simulation geladen wird.
+Für beide wird, wie später auch für den Roboter selbst, das Paket \code{ros_gz_sim} verwendet.
 Dieses veranlasst mit dem \code{create}-Programm das Erstellen der übergebenen Datenstruktur in Gazebo.
 
-
 \begin{figure}[hpt]
 \begin{minipage}{.45\textwidth}
 \includegraphics[width=\textwidth]{img/MA-Umsetzung-Welt-Plan.drawio}
 \centering
 \caption{Geplanter Raum}
-\label{roomplan}
+\label{room-plan}
 \end{minipage}
-\hspace{.1\textwidth}
+\hspace{.09\textwidth}
 \begin{minipage}{.45\textwidth}
 \includegraphics[width=\textwidth]{img/MA-Umsetzung-Welt-Blender}
 \centering
 \caption{Umsetzung in Blender}
-\label{roomfinished}
+\label{room-finished}
 \end{minipage}
 \end{figure}
 
@@ -89,11 +179,14 @@ Dieses veranlasst mit dem \code{create}-Programm das Erstellen der übergebenen
 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.
+Daraufhin werden die Daten der Anfrage in Form des \code{ActionMessage}-Typs ü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.
+Anhand der \code{ActionMessage} wird die State-Machine im ActorPlugin in den richtigen Zustand für die angefragte Aktion gesetzt.
+Um diese ausführen zu können, wird der gewünschte Animationsname, aber auch andere Parameter für die Aktion aus der Nachricht übernommen.
 
-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.
+Das Feedback an den Client des ROS-Action-Servers wird bei Zustandswechseln und während laufenden Aktionen des ActorPlugins generiert.
+Dabei wird der aktuelle Zustand mitsamt einigen weiteren Daten, in diesem Fall die Position des Actors und der aktuelle Fortschritt der Aktion an den ActorServer gesendet.
+Dies geschieht über eine zweite MessageQueue, welche den \code{FeedbackMessage}-Datentyp überträgt.
 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.
@@ -103,63 +196,176 @@ Um neue Animationen für den Menschen in der Simulation erstellen zu können, mu
 Dafür wurde eine der inkludierten Animationen in Blender geöffnet und das visuelle Modell kopiert.
 
 Dieses Modell war auf Grund von vielen inneren Falten nur schlecht für Animationen geeignet, weshalb das Modell an diesen Stellen vereinfacht wurde.
-Eine solches Vorgehen beugt Anomalien bei der Animation durch unterschiedliche Verschiebung der Strukturen vor, welche vom inneren des Modells hervortreten können.
+Eine solches Vorgehen beugt späteren Anomalien bei der Animation des Modells vor.
+Diese entstehen durch unterschiedliche Verschiebung der Strukturen, welche aus dem inneren des Modells hervortreten, wenn dieses bewegt wird.
 
-Nun musste das visuelle Modell mit neuen Animationsknochen versehen werden, da die in der Animation vorhandenen Knochen nicht verbunden sind.
-Diese Knochen bilden ein Skelett, welches zur Animation bewegt werden kann.
 
-In Blender können sogenannte Constraints verwendet werden, um die Gelenke in Gruppen zusammenzufassen und genauer zu spezifizieren.
-Dazu wurde das Plugin ``Rigify'' verwendet, welches ein komplettes Skelett generiert und konfiguriert.
 
-Dieses generierte Skelett kann nun an das Modell angepasst werden.
+An diesem Punkt könnte die Animation des Modells mit dem importierten Skelett beginnen, jedoch fehlen diesem viele Knochen, wie zum Beispiel für Finger und Zehen, aber auch Rotationsknochen für Arme und Beine.
+Diese fehlenden Knochen werden jedoch für einige der gewünschten Animationen benötigt und müssten hinzugefügt werden.
+Da das importierte Skelett noch andere Fehler aufwies, wurde dieses verworfen.
+
+Um ein neues, passendes Skelett zu erstellen, wurde mit dem ``Rigify''\cite{rigify}-Plugin ein standartisiertes Menschenskelett generiert.
+Dieses neue Skelett kann nun an das bereits vorhandene Modell angepasst werden.
 Um eine bessere Übersicht zu ermöglichen, sollten als erstes alle nicht benötigten Skeletteile, wie zum Beispiel für Gesichtsanimationen, entfernt werden.
-Danach werden alle Knochen dem visuellen Modell angepasst.
+Nun müssen die Knochen durch Verschiebung und Skalierung an die richtigen Positionen im Modell gebracht werden.
+
 Dabei muss auf die Ausrichtung der Knochen zueinander geachtet werden.
-Das Kreuzprodukt der Vektoren beider Knochensegmente ist die Richtung der Beugeachse, welche sich im Verbindungspunkt beider Knochen befindet.
+Das Kreuzprodukt der Vektoren beider Knochensegmente bestimmt die Richtung der Beugeachse, welche sich im Verbindungspunkt beider Knochen befindet.
 Ist diese nicht richtig ausgerichtet, wenn zum Beispiel beide Knochen auf einer Gerade liegen, verbiegen sich Gelenke bei der Verwendung von inverser Kinematik zur Positionsvorgabe falsch.
+Der Grund dafür ist das Kreuzprodukt, welches im oben genannten Fall ein Nullvektor ist, wodurch keine Beugeachse bestimmt werden kann.
 
-Das hier erstellte, verbesserte Rigify-Skelett kann nun einfacher animiert werden.
+Deswegen muss bei der Platzierung darauf geachtet werden, dass der Startpunkt A des ersten und der Endpunkt C des zweiten Knochens auf einer Gerade liegen.
-Dies liegt vor allem an neuen Markierungen in Blender, welche durch mehrere Constraints viele andere Knochen beeinflussen.
+Der Verbindungspunkt B der beiden Knochen wird nun vorerst auf dieser Gerade platziert.
-Beispielswise können Fuß- und Handmarkierungen gesetzt werden, welche die Rotation des Fußes oder der Hand, aber auch gleichzeitig die inverse Kinematik des gesamten Beins oder Arms automatisieren.
+Dieser muss nun senkrecht zu dieser Gerade und der gewünschten Biegeachse verschoben werden, wie in Abbildung \ref{bend} gezeigt.
-Selbiges gilt für neue Markierungen, welche zum Beispiel Hüft- und Kopfbewegungen vereinfachen.
 
-Das Exportieren eines solchen Rigs ist jedoch schwierig, da viele Grafikengines keine verschachtelten Skelette verstehen.
+\begin{figure}[hpt]
-Dies ist auch der Grund, warum die Skelette beim initialen Import mitgelieferter Animationen nicht verbunden waren.
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Umsetzung-Person-Bones}
+\centering
+\caption{Knochen des Modells}
+\label{person-bones}
+\end{minipage}
+\hspace{.09\textwidth}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Umsetzung-Person-Armature}
+\centering
+\caption{Armaturen des Modells}
+\label{person-armature}
+\end{minipage}
+\end{figure}
 
-Um aus einem existierenden, vollständig verbundenen Skelett einzelne Knochen zu extrahieren exisitiert ein weiteres Plugin mit dem Namen ``GameRig''.
+\begin{figure}[hpt]
-Dieses separiert die Knochen wieder, um die Animationen für Grafikengines exportieren zu können.
+\includegraphics[width=.8\textwidth]{img/MA-Umsetzung-Joint}
+\centering
+\caption{Visualisierung der generierten Beugeachse}
+\label{bend}
+\end{figure}
 
-Nach dieser Veränderung kann die Animation als Collada-Animation exportiert werden.
+Das neu erstellte Skelett ist in Abbildung \ref{person-bones} visualisiert.
-Dabei muss darauf geachtet werden, dass die vorwärts gerichtete Achse auf die richtige Achse gestellt ist.
+
-Außerdem ist es später einfacher, wenn nur eine Animation in jeder Datei vorhanden ist.
+Um eine bessere Verformung bei der Bewegung von Knochen zu erreichen, wird das so genannte ``weight painting'' eingesetzt.
-Dies ist dem Fakt geschuldet, dass diese anderen Animationen zwar verfügbar sind, jedoch aber nur durch einen Index unterscheidbar sind, der von der Reihenfolge der exportierten Animationen abhängig ist.
+Hierfür werden für jeden Knochen entweder automatisch oder manuell Teile des Meshes mit Gewichten versehen.
+Je höher die Wichtung, desto stärker ist die Verformung an dieser Stelle, wenn der Knochen bewegt oder skaliert wird.
+
+Da das Animieren aller Knochen einzeln sehr zeitaufwändig ist, werden diese in Gruppen zusammengefasst.
+Hierfür werden in Blender sogenannte Constraints eingesetzt, welche Knochen automatisch durch eingestellte Bedingungen positionieren können.
+
+Durch das Verwenden von Rigify und einem standartisierten Skelett ist die Generierung der Constraints einfach.
+Hierfür können die in dem Skelett enthaltenen Informationen vom Plugin genutzt werden, um alle häufig genutzten Constraints automatisch zu generieren.
+In diesem Schritt werden auch neue Knochen eingefügt, welche das Skelett durch Constraints beeinflussen.
+Das neue Animationsmodell, visualisiert in Abbildung \ref{person-armature}, kann nun für Animationen genutzt werden.
+
+Hierfür sehen mehrere Knochengruppen zur Verfügung, welche typische Animationsmethoden abdecken.
+
+In Rot sind hier Knochen markiert, welche für inverse Kinematik genutzt werden, in diesem Fall Arme und Beine.
+Diese Knochen geben gewünschte Ausrichtung und die Zielposition des untersten Knochens vor.
+Aus diesen Angaben wird die wirkliche Position der Knochen berechnet, welche durch die Constraints automatisch auf diese übertragen wird.
+
+Orange gefärbte Knochen werden für generelle Einstellungen von Fingern, Handfläche und Zehen genutzt.
+Die Handfläche kann so gekrümmt werden, wodurch sich alle Finger mit der Krümmung mitbewegen.
+Ein Abknicken aller Zehen kann durch die Rotation des Hilfsknochens an den Zehen erreicht werden.
+Die Finger können auch einzeln rotiert und eingeknickt werden.
+Hierbei wird der Grad des Einknickens nicht durch eine Rotation des Knochens ausgedrückt, da diese bereits durch die Rotation des Fingers selbst benutzt wird.
+Anstatt der Rotation wird die Skalierung des Knochens eingesetzt, wobei ein kleinerer Knochen eine stärkere Knickung aller Fingerglieder bewirkt.
+
+Die gelben Knochen beeinflussen die generelle Pose des Modells.
+Der Quader in der Hüfte gibt die gewünschte Höhe des Modells vor, welche auch für die inverse Kinematik benutzt wird.
+Die anderen Knochen beeinflussen die Rotation des Beckens, der Wirbelsäule, der Schultern und des Kopfes.
+
+Das hier erstellte, verbesserte Rigify-Skelett kann nun durch den Einsatz der neuen Constraints einfacher animiert werden.
+Jedoch ist das Exportieren eines solchen Rigs ist schwierig, da viele Grafikengines verschachtelten Skelette und Constraints nicht verwenden können.
+
+\subsection{Export der Modellanimationen}
+
+Um aus einem existierenden, vollständig verbundenen Skelett einzelne Knochen zu extrahieren, exisitiert ein weiteres Plugin mit dem Namen ``GameRig''\cite{gamerig}.
+Dieses separiert die neuen Steuerknochen wieder vom ursprünglichen Modell, wodurch in diesem nur noch die deformierenden Knochen enthalten sind.
+
+Alle erstellten Animationen der Steuerknochen müssen nun in direkte Bewegungen der deformierenden Knochen des Modells umgewandelt werden.
+Um dies zu erreichen wird der in Abbildung \ref{export-prepare} visualisierte Arbeitsablauf verwendet.
+
+Im ersten Schritt wird das zu exportierende Skelett ausgewählt, um diesem später die neue Animation zuweisen zu können.
+Dann muss im zweiten Schritt die gewünschte Animation der Liste der bekannten Animationen hinzugefügt werden.
+
+Danach muss die durch die Constraints abgebildete Animation auf das ausgewählte Skelett übertragen werden, was mit dem ``Bake Action Bakery''-Knopf ausgelöst wird.
+Dabei wird die Position aller deformierenden Knochen zu jedem Zeitpunkt der Animation bestimmt, und in einer neuen Animation mit modifiziertem Namen abgespeichert.
+
+Diese neu erstellte Animation kann nun im vierten Schritt dem ausgewählten Skelett zugewiesen werden.
+Nach dieser Veränderung kann die diese Animation als Collada-Animation exportiert werden.
+Dazu muss noch das visuelle Modell der Selektion hinzugefügt werden, da Gazebo dieses für jede Animation benötigt.
+
+Nun kann der Export über die in Blender integrierte Exportoption ausgelöst werden.
+Hierfür müssen die in Abbildung \ref{export-settings} verwendeten Exporteinstellungen verwendet werden, damit Gazebo die exportierte Animation nutzen kann.
+Alle in der Blender-Version 3.5 nicht standartmäßigen Einstellungen wurden dabei durch Punkte hervorgehoben.
+
+Zuerst müssen im Reiter ``Main'' die globalen Exporteinstellungen angepasst werden.
+Der markierte Punkt 2. bewirkt, dass nur die vorher ausgewählten Modellteile exportiert werden.
+Dies verkleinert das Modell, da alle Steuerknochen von Gazebo nicht verwendet werden können, was die Ladezeit der Simulation verbessert.
+
+Punkt 3. und 4. bewirken, dass das exportierte Modell in Gazebo verwendete Vorwärtsachse erhält.
+In Blender ist Y als Vorwärtsachse üblich, jedoch verwendet Gazebo die X-Achse für diesen Zweck.
+Wird diese Modifikation nicht vorgenommen, sind die Modelle um 90 Grad verdreht.
+
+Nun muss im mit 5 markierten Animations-Reiter noch eine letzte Einstellung vorgenommen werden.
+Die mit 6 markierte Einstellung bewirkt, dass alle Bewegungen der exportierten Knochen mit gespeichert werden, auch wenn diese sich nicht bewegen.
+Da sich einige Knochen nur am Anfang der Animation in einer bestimmten Pose befinden, exportiert Blender diese nicht, was in Gazebo zu verdrehten Knochen führt.
+
+\begin{figure}[hpt]
+\begin{subfigure}[b]{\textwidth}
+\includegraphics[width=.5\textwidth]{img/MA-Umsetzung-Animation-Prepare}%
+\hfill
+\includegraphics[width=.5\textwidth]{img/MA-Umsetzung-Animation-Prepare2}
+\end{subfigure}
+\caption{Vorbereitung zum Export mit GameRig}
+\label{export-prepare}
+\end{figure}
+
+\begin{figure}[hpt]
+\begin{subfigure}[b]{\textwidth}
+\includegraphics[height=.50\linewidth]{img/MA-Umsetzung-Animation-Save}%
+\hfill
+\includegraphics[height=.50\linewidth]{img/MA-Umsetzung-Animation-Save2}
+\end{subfigure}
+\caption{Benötigte Exporteinstellungen in Blender}
+\label{export-settings}
+\end{figure}
 
 \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.
+Nach der ersten Implementation des ActorPlugins kam es zu Kollisionen mit \code{ros_control}, welche beide \code{rclcpp} zur Kommunikation benutzen.
-Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS, verwenden.
+Diese Kollisionen führt zu einem Crash, wenn beide Plugins in der Simulation geladen werden.
+Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS-Topics, 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.
+Nach dem Debuggen des Crashes wurden einige Problemlösungen ausprobiert, jedoch ließ sich der Konflikt durch Modifikation des ActorPlugins allein nicht verhindern, weshalb ein anderer Weg zur Problembehebung gewählt werden musste.
-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.
+Eine Anpassung beider Plugins auf die gemeinsame Nutzung einer Ressource ist möglich, erfordert jedoch potentiell weitreichende Neuimplementationen, welche zeitlich nur schwer planbar sind.
+Die Nutzung eines separaten Nachrichtendienstes, welcher keinen globalen Kontext benötigt, ist die sicherste und schnellste Lösung des Problems.
+Jedoch erfordert diese Implementation zusätziliche Logik, um die beiden Dienste ineinander übersetzen zu können.
 
 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.
+Webdienste, wie zum Beispiel REST-API's und Websockets werden von vielen Sprachen nativ untersützt, was sie zu guten Kanidaten für solche Kommunikation macht.
-Die neueren Websockets bieten die Möglichkeit, bidirektional Daten zu übertragen und erlauben somit Feedback an das aufrufende Programm.
+
+Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die Sockets unterstützt, besitzt jedoch keinen einheitlichen Feedbackmechanismus.
+Dieser müsste entweder durch kontinuierliche Abfragen des aktuellen Status oder eine lang laufende Request mit zerstückelter Antwort realisiert werden.
+Eine Verwendung von kontinuierlichen Abfragen ist zwar mit fast jeder Programmiersprache möglich, jedoch ist die Reaktionszeit des Systems an die Antwortzeit des Servers gebunden.
+Der Einsatz von zerstückelten Antworten umgeht dieses Problem, jedoch müssen der eingesetzte Webserver und Client dieses Feature unterstützen.
+
+Die neueren Websockets bieten die Möglichkeit, bidirektional Daten zu übertragen.
+Dadurch können Aktionsanfragen und Feedback auf dem gleichen Kanal übertragen werden, was das Protokoll übersichtlicher macht.
 Beide Technologien basieren 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.
+Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den gleichen Speicherbereich zugreifen können.
-Alle Zugriffe auf den Bereich sind extrem schnell, was diese Technik ideal zur schnellen Datenübertragung zwischen Prozessen macht.
+Alle Zugriffe auf den Bereich sind extrem schnell, da sie den Arbeitsspeicher des Systems nie verlassen, was diese Technik ideal zur Datenübertragung zwischen Prozessen macht.
-Durch das erlauben gleichzeitiger Zugriffe kann es hierbei vorkommen, dass die selbe Adresse gleichzeitig von einem Programm gelesen und von einem anderen geschrieben wird.
+Durch das erlauben gleichzeitiger Zugriffe kann es hierbei vorkommen, dass beide Programme gleichzeitig versuchen, Änderungen am Speicher vorzunehmen.
-Die dabei gelesenen Daten können Schäden aufweisen, weswegen Zugriffe auf den Speicherbereich koordiniert werden müssen.
+Diese gleichzeitige Modifikation kann zu Fehlern führen, wenn die Zugriffe auf den Bereich nicht kontrolliert werden.
 
 Die letzte betrachtete Methode ist die Verwendung einer Message Queue.
 Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustauch reserviert.
@@ -168,72 +374,152 @@ Ein Programm kann in diesem Bereich Nachrichten ablegen, welche durch das andere
 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 Wahl des Dienstes fiel auf eine MessageQueue, da die integrierten Funktionen die Entwicklung erleichtern ud die Geschwindigkeit ausreichend für das Einsatzszenario ist.
-Die erste Implementation ist die System V MessageQueue, und verwendet zur Identifikation einfache Integer.
+Jedoch existieren unter Linux 2 unabhängige Implementationen von MessageQueues mit unterschidelichen Funktionen.
+Die erste Implementation ist die System V MessageQueue, und verwendet zur Identifikation einfache Ganzzahlen.
 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 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 Zeichenketten zur Identifikation.
 
-Die ausgewählte Implementation ist die neuere POSIX-Implementation einer Message Queue, da diese basierend auf den Erfahrungen mit der System V Implementation verbessert wurde.
+Die ausgewählte Implementation ist die neuere POSIX-Implementation einer Message Queue, da diese basierend auf den Erfahrungen mit der System V Implementation entwickelt wurde.
-\subsubsection{Nachrichten}
+\subsubsection{ROS-Nachrichten}
-Die versendeten Nachrichten für den ActionServer, als auch für die Message Queue sind in den Paketen \code{ros_actor_action_server_msgs} und \code{ros_actor_message_queue_msgs} abgelegt.
+Die verwendeten Nachrichten für den ActionServer, als auch für die Message Queue sind in den entsprechenden Paketen \code{ros_actor_action_server_msgs} und \code{ros_actor_message_queue_msgs} organisiert.
-Sie sind absichtlich nicht in den nutzenden Paketen untergebracht, da sie durch ein externes Programm in den entsprechenden Code umgewandelt werden.
+Sie sind absichtlich nicht in den nutzenden Paketen untergebracht, da sie durch ein externes Programm in den benötigten Code umgewandelt werden.
+Dieser Schritt muss vor dem Kompilliervorgang der nutzenden Pakete geschehen, was so am einfachsten realisiert werden kann.
+Dazu werden diese Nachrichtenpakete als Dependency der nutzenden Pakete angegeben, was eine automatische Anpassung der Kompillantionsreihenfolge bewirkt.
 
-Jede Action definiert 3 Nachrichten, welche zu unterschiedlichen Zeitpunkten in ihrer Ausführung verwendet werden.
+Eine Action des \code{ros_action}-Pakets besteht immer aus 3 einzelnen Nachrichten, deren Inhalt frei definiert werden kann.
-Die definierten Nachrichten sind eine Startnachricht, eine Feedbacknachricht und eine Endnachricht.
 
-Ein ActionServer definiert 3 Funktionen, welche die Handhabung einer Aktion definieren.
+Zum Start der Action wird die erste Nachricht vom Client an den Server gesendet.
+In dieser Startnachricht befinden sich alle Informationen, welche zur Ausführung der Action benötigt werden.
+Nach dieser Nachricht kann der Server später entscheiden, ob die Aktion ausgeführt werden soll und sie gegebenenfalls abbrechen.
+
+Nach dem Beginn der Action werden vom Server Feedbacknachrichten an den Client gesendet, welche den Fortschritt der Action beschreiben.
+Dabei ist es die Aufgabe des Programmierers, diese an sinnvollen Punkten des Ablaufs zu senden.
+
+Am Ende der Action wird die Endnachricht an den Client gesendet, welche weitere Rückgabewerte liefern kann.
+Die Endnachricht enthält standartmäßig eine Erfolgsangabe, weshalb diese nicht angegeben werden muss.
+
+Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die Handhabung einer Aktion definieren.
 Die erste Funktion übergibt den Wert der Startnachricht, welche mit einer Antwort quittiert werden muss.
 Hierbei sind die Antworten ACCEPT_AND_DEFER, ACCEPT_AND_EXECUTE und REJECT möglich.
 
 ACCEPT_AND_EXECUTE signalisiert die sofortige Ausführung des gewünschten Befehls und ACCEPT_AND_DEFER steht für eine spätere Ausführung der gewünschten Aktion.
-Die Option REJECT bricht die Ausführung der Aktion vorzeitig ab.
+Die Option REJECT weist die Ausführung der Aktion vorzeitig ab.
 
 Die zweite Funktion übergibt Abbruchanfragen an den Server, falls die Aktion durch den Client abgebrochen werden soll.
 Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT zurückgewiesen werden.
 
 Um Feedback während der Ausführung der Aktion geben zu können, exisitiert die dritte Funktion.
 Diese erhält als Parameter ein Objekt, mit welchem Feedback- und Endnachrichten an den Client gesendet werden können.
-
-In der Startnachricht werden alle Daten, welche der Server für die Bearbeitung einer Anfrage benötigt, übergeben.
-Dies geschieht, damit der Auftrag schon beim Start abgebrochen werden kann, sollte dieser nicht erfüllbar sein.
-
-Die Feedbacknachrichten werden vom Server an den Client zurück gesendet, solange das Programm ausgeführt wird.
-Dabei ist es Aufgabe des Programms, diese in beliebigen Abständen an den Client zu senden.
-
-Die Endnachricht kann Rückgabewerte für die ausgeführte Aufgabe enthalten, falls diese benötigt werden.
-Sie werden in diesem Projekt nicht genutzt, da das Beenden eines Auftrags immer mit einer einfachen Erfolgs- oder Misserfolgsmeldung quittiert wird.
-
 \subsubsection{ActorPlugin}
-Das ActorPlugin nutzt die empfangenen Nachrichten aus der eingehenden Message Queue, um diese in der Simulation umzusetzen.
+Das ActorPlugin steuert anhand von empfangenen Nachrichten aus der eingehenden Message Queue den Menschen in der Simulationsumgebung.
 Der Code des Plugins ist dabei im Paket \code{ign_actor_plugin} organisiert, welches im Gazebo-Modell der Welt referenziert werden muss, um das Plugin zu laden.
 
-Das Plugin erhält durch die empfangenen Nachrichten mehrere Zustände, welche im folgenden erläutert werden:
+Das Plugin wird durch den Startvorgang und später von den empfangenen Nachrichten in mehrere Zustände versetzt, welche im folgenden erläutert werden:
 \begin{description}
  \item[Setup]
   wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simualtionumgebung im Plugin zu hinerlegen, so dass diese in den anderen Zuständen genutzt werden können.
+ \item[Idle]
+  ist der Zustand, welcher nach erfolgreicher Ausführung eines Befehls angenommen wird.
  \item[Movement]
   bedeutet die Ausführung einer Bewegung in potentiell mehreren Schritten.
-  Zuerst wird die Distanz zum Zielpunkt geprüft.
-  Ist diese ausreichend gering, wird nur eine Bewegung in die gewünschte Endausrichtung durchgeführt.
-  Ist diese größer, dreht sich der Actor in Richtung des Ziels und bewegt sich anschließend dorthin.
-  Falls die gewünschte Endrotation nicht einem Null-Quaternion entspricht, wird anschließend noch eine Rotation in die Zielrichtung durchgeführt.
  \item[Animation]
   entspricht der Ausführung einer Animation an der aktuellen Position des Actors.
   Diese kann durch einen Skalierungsfaktor beschleunigt oder verlangsamt werden.
- \item[Idle]
-  ist der Zustand, welcher nach erfolgreicher Ausführung eines Befehls angenommen wird.
 \end{description}
 
+In diesen Zuständen muss das ActorPlugin die Simulationsumgebung beeinflussen, in dem die simulierte Person bewegt und animiert wird.
+Dies erfordert den Zugriff auf simulationsinterne Daten, welche durch das Plugin gelesen und verändert werden sollen.
+Der Zugriff auf diese Daten wird durch ein EntityComponentManager-Objekt ermöglicht.
+
+Durch den EntityComponentManager kann auf das so genannte ``Entity Component System'' zugegriffen werden, in welchem alle Simulationsobjekte organisiert sind.
+Ein Entity Component System besteht aus einer oder mehr Entities, welche die sich in der Simulation befindlichen Objekte abbilden.
+Objekte können beliebig viele Components besitzen, bei welchen es sich um zusätzliche Eigenschaften und Erweiterungen der Funktionen des betroffenen Objekts handelt.
+Die wichtigsten Komponenten für die Funktion des Plugins sind dabei:
+\begin{description}
+ \item[components::Actor]
+  Dieses Objekt beschreibt die simulierte Person mit allen weiteren Daten, wie zum Beispiel dessen Animationen.
+ \item[components::AnimationName]
+  In dieser Komponente wird der aktuell verwendete Animationsname abgelegt, welcher von Gazebo zur Auswahl der aktuell laufenden Animation verwendet wird.
+ \item[components::AnimationTime]
+  enthält den aktuellen Zeitpunkt innerhalb der Animation, um die richtigen Positionsdaten aus dieser auswählen zu können. Dabei wird zwischen einzelnen Positionen linear interpoliert, falls der Zeitpunkt zwischen diesen liegt.
+ \item[components::Pose]
+  entspricht einer bereits beschriebenen Pose, jedoch verwendet Gazebo dafür diesen neuen Datentyp.
+ \item[components::TrajectoryPose]
+  beschreibt eine Pose während einer Bewegung. Ist diese nicht gesetzt, werden keine Animationen abgespielt.
+\end{description}
+
+Durch das Verändern dieser Komponenten kann nun die gewünschte Funktionalität des Plugins erreicht werden.
+Diese Veränderungen müssen jeden Simulationschritt erneut vorgenommen werden, um einen flüssigen Ablauf zu gewährleisten.
+Um dies zu erreichen, können im Plugin bestimmte Interfaces mit entsprechenden Funktionen implementiert werden.\cite{ignPlugin}
+Diese Funktionen werden später in der Simulation aufgerufen.
+Folgende Funktionen werden von Gazebo unterstützt:
+\begin{description}
+ \item[Configure] wird aufgerufen, sobald das Plugin geladen wurde.
+ Alle benötigten Informationen über dessen Umgebung werden als Parameter übergeben.
+ Darunter fallen die Entity, zu welcher das Plugin als Component hinzugefügt wurde, eine Referenz auf die Konfiguration des Plugins in der geladenen Welt und eine aktuelle Instanz des EntityComponentManagers und EventManagers von Gazebo.
+ \item[PreUpdate] wird verwendet, um den nächsten Update-Schritt vorzubereiten.
+ Diese Funktion erlaubt die Modifikation von Entities und Components und wird vor der eigentlichen Physiksimulation aufgerufen.
+ \item[Update] wird genutzt, um die in der Simulation abgelaufene Zeit zu simulieren.
+ Auch hier ist die Modifikation von Entities und Components möglich.
+ In dieser Funktion werden Beispielsweise die Physiksimulation der Objekte durchgeführt.
+ \item[PostUpdate] bietet die Möglichkeit, die Ergebnisse der Simulation vor dem nächsten Simulationsschritt auszulesen.
+ Dies wird zum Beispiel für die simulierten Sensoren in Gazebo genutzt, welche hier ihren Status prüfen.
+ In dieser Funktion kann nur lesend auf Entities und Components zugegriffen werden.
+\end{description}
+Jede dieser Funktionen ist in einem Interface mit dem Präfix \code{ISystem} definiert, welche vom Plugin genutzt werden können.
+Für Gazebo muss das Plugin noch registriert werden, was mit dem \code{IGNITION_ADD_PLUGIN}-Makro geschieht.
+Mit diesen Vorbereitungsschritten wird das Plugin von Gazebo verwendbar gemacht.
+
+Das ActorPlugin benötigt für seine Funktion das übergeornete Simulationsobjekt, welches durch das Plugin beeinflusst werden soll.
+Dies erfordert die Implementation des \code{ISystemConfigure}-Interfaces für das ActorPlugin.
+Außerdem soll die simulierte Person bewegt werden. Da dieser Vorgang während der Simulationszeit ablaufen soll, muss hierfür das \code{ISystemUpdate}-Interface genutzt werden.
+
+Als erstes wird durch das Laden die Configure-Funktion aufgerufen.
+Da das Plugin erst durch Gazebo geladen werden muss, kann davon ausgegangen werden, dass alle benötigten Message Queues bereits durch den ActorServer erstellt wurden.
+Trotz dieses Umstandes wartet das Plugin auf deren Erstellung, um bei Konfigurationsfehlern auffälliges Verhalten zu zeigen.
+Im Log wird diese Aktion vermerkt, um Debugging zu erleichtern.
+Nach dem erfolgreichen Aufbau der Verbindung wird ein Thread gestartet, welcher die eingehenden Nachrichten verarbeitet.
+Dabei wird zuerst ein Mutex gesperrt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
+Alle in der Anfrage gespeicherten Daten werden nun übernommen und der gewünschte State gesetzt.
+Nach dem Entsperren des Mutex wird im nächsten Simulationschritt die gewünschte Aktion durchgeführt.
+
+Das Setzen aller obrigen Zustände ist dabei möglich, jedoch werden nur Idle, Animation und Movement genutzt.
+Der Idle-Zustand kann zum Beenden eines anderen Zustands eingesetzt werden, falls dieser abgebrochen werden soll.
+Die Zustände Animation und Movement werden gesendet, falls neue Ziele gesetzt werden sollen.
+Da beide Zustände Animationen verwenden, wird bei deren erster Ausführung in der Update-Funktion die gewünschte Animation gesetzt.
+Um dies zu ermöglichen, werden alle in der Actor-Komponente gespeicherten Animationen durchsucht.
+Sollte die Animation nicht gefunden werden, wird versucht, diese anhand ihres Namens zu laden.
+Wurde eine Animation gefunden, wird deren Länge gespeichert, um diese später für das Feedback nutzen zu können.
+
+Ab diesem Zeitpunkt unterscheiden sich die Implementation von Animation und Movement.
+Im Zustand der Animation wird nun die Komponente AnimationTime jedes Update aktualisiert.
+Um die Ausführungsgeschwindigkeit einer Animation anpassen zu können, kann ein Skalierungsfaktor genutzt werden, welcher mit der abgelaufenen Zeit in der Simulation verrechnet wird.
+Nach jedem Update-Schritt wird eine Feedback-Nachricht gesendet, welche den aktuellen Fortschritt der Animation enthält.
+Wurde die Animation vollständig durchlaufen, wird der Zustand des ActorPlugins auf Idle gesetzt.
+
+Soll über den Movement-Zustand eine Bewegung abgespielt werden, müssen noch weitere Parameter der Bewegung berechnet werden.
+Dies geschieht nach dem Setzen der Animation während des ersten Update-Aufrufs.
+Zuerst wird ein Vektor zur Zielposition berechnet, welcher später zur Bewegung genutzt wird.
+Sollte dieser über einer gewissen Mindestlänge liegen, wird eine Rotation des Menschen in Bewegungsrichtung ausgeführt.
+Nach dieser Rotation wird die Bewegung an die Zielposition umgesetzt.
+Dabei wird die Bewegungsanimation abgespielt, welche durch einen Faktor an die zurückgelegte Distanz angepasst wird.
+Dies vermeidet, dass die Beine der Person über den Boden gleiten.
+Wurde eine Endrotation angegeben, welche nicht dem Nullvektor entspricht, wird nach der Bewegung noch eine Rotation in diese Richtung ausgeführt.
+Dabei werden auch die Beine wieder in die Ausgangslage bewegt.
+Wenn sowohl die Zielrotation ausgeführt wurde und die Beine wieder in Ausgangslage sind, wird der Zustand auf Idle gesetzt.
+
 Das ActorPlugin besitzt kein Konzept eines ROS-ActionServers und verlässt sich auf den ActorServer, welcher die Feedbacknachrichten in das richtige Format bringt.
 Feedback wird in den Zuständen Movement und Animation in eine zweiten Message Queue zu jedem Simulationsschritt gesendet.
 Um Zustandsübergänge erkennen zu können, werden auch diese als Feedback an den ActorServer gesendet.
 \subsubsection{ActorServer}
-Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin und ist im Paket \code{ros_actor_action_server} enthalten.
+Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin.
+Er ist als das Programm \code{ros_actor_action_server} im gleichnamigen Paket enthalten.
 Dieser weitere Dienst bindet das ActorPlugin an ROS an.
 
 Es werden dafür zwei ROS-ActionServer gestartet, welche jeweils Bewegungen oder Animationen des simulierten Menschen auslösen können.
 Beide ActionServer prüfen bei dem Empfang eines neuen Ziels zuerst, ob bereits eine andere Aktion ausgeführt wird.
-Sollte bereits eine andere Aktion ausgeführt werden, wird die Anfrage abgelehnt.
+Wird bereits eine andere Aktion ausgeführt, kommt es zur Ablehnung weiterer Anfragen.
 Im anderen Fall wird die Aufgabe akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
 
 Um das Starten mehrerer gleichzeitiger Aktionen zu unterbinden, muss der Empfang einer neuen Anfrage bestätigt werden, bevor weitere Befehle über den ROS-ActionServer entgegen genommen werden können.
@@ -289,13 +575,13 @@ Alle kontrollierbaren Gelenke benötigen auch eine Gelenkachse, welche je nach G
 
 Alle hier erstellten Dateien wurden im Paket \code{iisy_config} zusammengefasst, um diese einfacher wiederauffinden zu können.
 \begin{figure}[hpt]
-\begin{minipage}{.5\textwidth}
+\begin{minipage}{.49\textwidth}
 \includegraphics[width=\textwidth]{img/MA-Roboter-Visuell}
 \centering
 \caption{Visuelles Modell}
 \label{robot_visual}
 \end{minipage}
-\begin{minipage}{.5\textwidth}
+\begin{minipage}{.49\textwidth}
 \includegraphics[width=\textwidth]{img/MA-Roboter-Kollision}
 \centering
 \caption{Kollisionsmodell}
@@ -317,17 +603,18 @@ Jedoch ist hier als Nachteil zu verzeichnen, dass der Moveit Setup Assistent die
 
 Das so erstellte Modell kann ber den Aufruf von \code{ros2 launch iisy_config demo.launch.py} in RViz getestet werden.
 Hierfür erscheint das Robotermodell mit mehreren Markern und Planungsoptionen, welche genutzt werden können, um beliebige Bewegungen zu planen und auszuführen.
-\subsection{Details}
+\subsection{Integration mit Gazebo}
 Das so erstellte Modell kann nun zur Laufzeit in Gazebo geladen werden.
 Dafür wird das Paket \code{ros_gz_sim} verwendet, welches das \code{create} Programm beinhaltet.
-Mit diesem Werkzeuk kann ein Modell unter einem bestimmten Namen anhand einer Datei oder eines übergebenen Strings in Gazebo importiert werden.
+Mit diesem Werkzeug kann ein Modell unter einem bestimmten Namen anhand einer Datei oder eines übergebenen Strings in Gazebo importiert werden.
 Das Modell kann dabei über Argumente im Raum verschoben und rotiert werden, falls diese Funktionalität benötigt wird.
 
+In diesem Fall wird das Modell als String geladen, welcher durch \code{xacro} erstellt wurde.
+Dies ist nötig, um Informationen aus anderen Dateien in das generierte XML übernehmen zu können.
+
 Im Modell sind auch die verwendeten Gazebo-Plugins deklariert, welche für die Integration mit \code{ros_control} verantwortlich sind.
 Das Gazebo-Plugin läd dabei die verwendeten Controller und versorgt diese mit Informationen über den Roboter.
 
-Die zusätzlichen Programme werden nun in die gazebo_controller.launch.py-Datei
-
 \section{Behavior Trees}
 Alle Behavior Trees wurden im Paket \code{btree} organisert, welches die Bäume im XML-Format und die Implementation der Nodes und umliegenden Infrastruktur enthält.
 
@@ -385,7 +672,7 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
   \item[ActorMovement]
   funktioniert wie eine ActorAnimation, sendet jedoch eine Bewegungsanfrage.
   Auch für diese wird ein Animationsname benötigt, welcher im \code{animation_name} Parameter definiert wird.
-  Jedoch wird für die Synchronisation zur Bewegung ein Diztanzwert bewnötigt, welcher in einem Animationsdurchlauf zurückgelegt wied.
+  Jedoch wird für die Synchronisation zur Bewegung ein Disztanzwert benötigt, welcher in einem Animationsdurchlauf zurückgelegt wird.
   Dieser wird im \code{animation_distance} Parameter übergeben.
   Eine Zielpose wird im \code{target} Parameter gesetzt.
   Eine Besonderheit dieses Paramerters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
@@ -402,35 +689,10 @@ Diese beiden roboterspezifischen Nodes beeinflussen im Hintergrund das gleiche S
 Dazu wird das letzte Ziel bis zu dessen erreichen vorgehalten, um die Ausführung neu zu starten, fall eine Geschwindigkeitsänderung durchgeführt werden muss.
 Um die RobotMove-Node nicht zu unterbrechen, wird diese nur über einen Callback über den Erfolg oder Misserfolg der gesamten Bewegung und nicht über den Erfolg einzelner Teilbewegungen informiert.
 
-\section{Docker-Compose}
+\subsection{Subtrees}
-Um Docker für die Verwaltung einer ROS-Installation verwenden zu können, müssen einige Anpassungen vorgenommen werden.
+Um die Wiederverwendung von bestimmten Verhaltensweisen zu erleichtern, wurden diese in Subtrees ausgelagert.
-Da viele Anwendungen, unter anderem auch die Simulationsumgebung, eine Desktopumgebung benötigen, muss eine Zugriffsmöglichkeit geschaffen werden.
+In diesem Fall wurden die Aktionen ``Arbeiten an der Werkbank'' und ``Ablegen eines Objekts im Lagerregal'' des Menschen ausgelagert, da diese in mehreren Fällen verwendet werden und die Lesbarkeit der Bäume verbessert wird.
 
-Diese Möglichkeiten können nicht durch Docker allein gelöst werden, da Befehle auf dem Hostsystem ausgeführt werden müssen, um die gewünschten Funktionen zu aktivieren.
+\subsection{Verhalten des Roboters}
-Um diese Modifikiationen trotzdem reproduzierbar zu machen, wurde ein Shellscript geschrieben, welches zum Starten des Containers verwendet wird.
 
-Dieses Skript erstellt zuerst die benötigten Verzeichnisse für den Container, falls diese noch nicht existieren.
+\subsection{Verhalten des Menschen}
-Danach werden die SSH-Keys des Hosts in den Container kopiert, um eine SSH-Verbindung zu ermöglichen.
-Dieser Umweg über SSH ist nötig, da die benötigten Umgebungsvariablen für ROS sonst nicht in allen Fällen gesetzt werden können.
-
-Außerdem werden die benötigten Zugriffe auf den lokalen X-Server durch den Container anhand dessen Hostname erlaubt.
-Diese Änderung erlaubt es dem Container, Fenster auf dem Desktop anzeigen zu können, solange die benötigten SysFS-Dateien hereingereicht werden.
-Dies geschieht durch Einträge in der compose.yml-Datei, welche diese als ``bind mount'' in den Container hereinreicht.
-
-Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repräsentation im SysFS unter \code{/dev/dri} hineingereicht werden.
-Der Zugriff auf die Desktopumgebung, welcher bereits entsperrt wurde, wird nun durch das mounten von \code{/tmp/.X11-unix} erreicht.
-Dabei handelt es sich um den Unix-Socket des X11 Displayservers.
-
-Zum Starten des Containers muss der Befehl \code{./start.sh} im Verzeichnis der Containerinstallation ausgeführt werden, welcher die obengenannten Schritte ausführt und den Container startet.
-Eine Verbindung zum Container kann aufgebaut werden, nachdem die Meldung \code{ros_1 | Ready to connect.} in der Konsole erscheint.
-
-Dafür muss ein SSH-Client eingesetzt werden, welcher eine Verbindung zu der lokalen Netzadresse des Systems mit dem Benutzer \code{ros} aufbauen kann.
-Der Port des SSH-Servers wird dabei durch die Deklaration im docker-compose.yaml an das Hostsystem durchgereicht.
-Hierbei ist zu beachten, dass der SSH-Server im Container auf Port 2222 ausgeführt wird, was bei der Verbindung beachtet werden muss.
-
-Nach der Verbindung wird automatisch die ROS2-Umgebung eingerichtet, welche sofort nach Verbindungsaufbau genutzt werden kann.
-Um die erstellten Pakete zu kompillieren, kann das Skript \code{build.sh} im \code{workspace}-Verzeichnis verwendet werden.
-
-Dieses Skript nutzt \code{colcon} um alle Pakete in diesem Workspace zu erstellen.
-Dabei wird auch noch eine \code{compile_commands.json}-Datei erstellt, welche von einigen IDE's zur Syntaxvervollständigung genutzt werden.
-Außerdem wird der Event-Handler \code{console_cohesion+} verwendet, welcher das Lesen der Kompillierausgabe erleichtert.

tex/texput.log

@@ -0,0 +1,21 @@
+This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Arch Linux) (preloaded format=pdflatex 2023.4.3)  15 MAY 2023 18:44
+entering extended mode
+ \write18 enabled.
+ %&-line parsing enabled.
+**main.tex
+
+! Emergency stop.
+<*> main.tex
+            
+*** (job aborted, file error in nonstop mode)
+
+ 
+Here is how much of TeX's memory you used:
+ 3 strings out of 476025
+ 111 string characters out of 5796533
+ 1849388 words of memory out of 5000000
+ 20558 multiletter control sequences out of 15000+600000
+ 512287 words of font info for 32 fonts, out of 8000000 for 9000
+ 1141 hyphenation exceptions out of 8191
+ 0i,0n,0p,1b,6s stack positions out of 5000i,500n,10000p,200000b,80000s
+!  ==> Fatal error occurred, no output PDF file produced!

texput.log

@@ -0,0 +1,20 @@
+This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Arch Linux) (preloaded format=pdflatex 2023.4.3)  15 MAY 2023 18:41
+entering extended mode
+ \write18 enabled.
+ %&-line parsing enabled.
+**%.tex
+! Emergency stop.
+<*> %.tex
+         
+*** (job aborted, no legal \end found)
+
+ 
+Here is how much of TeX's memory you used:
+ 2 strings out of 476025
+ 107 string characters out of 5796533
+ 1849388 words of memory out of 5000000
+ 20558 multiletter control sequences out of 15000+600000
+ 512287 words of font info for 32 fonts, out of 8000000 for 9000
+ 1141 hyphenation exceptions out of 8191
+ 0i,0n,0p,1b,6s stack positions out of 5000i,500n,10000p,200000b,80000s
+!  ==> Fatal error occurred, no output PDF file produced!

uml/out/plugin_connectivity/plugin_connectivity.latex

@@ -0,0 +1,137 @@
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{aeguill}
+\begin{document}
+% generated by Plantuml 1.2022.7       
+\definecolor{plantucolor0000}{RGB}{255,255,255}
+\definecolor{plantucolor0001}{RGB}{176,176,176}
+\definecolor{plantucolor0002}{RGB}{128,128,128}
+\definecolor{plantucolor0003}{RGB}{226,226,240}
+\definecolor{plantucolor0004}{RGB}{24,24,24}
+\definecolor{plantucolor0005}{RGB}{0,0,0}
+\definecolor{plantucolor0006}{RGB}{254,255,221}
+\definecolor{plantucolor0007}{RGB}{238,238,238}
+\definecolor{plantucolor0008}{RGB}{64,64,64}
+\begin{tikzpicture}[yscale=-1
+,pstyle0/.style={color=plantucolor0001,fill=white,line width=1.0pt}
+,pstyle1/.style={color=plantucolor0002,line width=1.5pt}
+,pstyle2/.style={color=plantucolor0001,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
+,pstyle3/.style={color=plantucolor0004,fill=plantucolor0003,line width=0.5pt}
+,pstyle4/.style={color=plantucolor0004,fill=plantucolor0006,line width=0.5pt}
+,pstyle5/.style={color=plantucolor0007,fill=plantucolor0007,line width=1.0pt}
+,pstyle6/.style={color=plantucolor0002,line width=1.0pt}
+,pstyle7/.style={color=plantucolor0002,fill=plantucolor0007,line width=2.0pt}
+,pstyle8/.style={color=plantucolor0008,fill=plantucolor0008,line width=1.0pt}
+,pstyle9/.style={color=plantucolor0008,line width=1.0pt}
+,pstyle10/.style={color=plantucolor0008,line width=1.0pt,dash pattern=on 2.0pt off 2.0pt}
+,pstyle11/.style={color=plantucolor0002,fill=plantucolor0007,line width=1.5pt}
+,pstyle12/.style={color=plantucolor0001,line width=2.0pt}
+]
+\draw[pstyle0] (153.8615pt,156.186pt) rectangle (163.8615pt,705.4822pt);
+\draw[pstyle0] (313.3771pt,49.0679pt) rectangle (323.3771pt,767.5501pt);
+\draw[pstyle0] (478.7515pt,49.0679pt) rectangle (488.7515pt,767.5501pt);
+\draw[pstyle1] (66.7865pt,234.598pt) rectangle (556.1768pt,698.4822pt);
+\draw[pstyle1] (76.7865pt,370.4221pt) rectangle (546.1768pt,485.2461pt);
+\draw[pstyle1] (76.7865pt,499.2461pt) rectangle (546.1768pt,582.3642pt);
+\draw[pstyle2] (158.7865pt,39.0679pt) -- (158.7865pt,733.4822pt);
+\draw[pstyle2] (317.4068pt,39.0679pt) -- (317.4068pt,733.4822pt);
+\draw[pstyle2] (483.3262pt,39.0679pt) -- (483.3262pt,733.4822pt);
+\draw[pstyle3] (86.7865pt,10pt) arc (180:270:5pt) -- (91.7865pt,5pt) -- (225.9365pt,5pt) arc (270:360:5pt) -- (230.9365pt,10pt) -- (230.9365pt,33.0679pt) arc (0:90:5pt) -- (225.9365pt,38.0679pt) -- (91.7865pt,38.0679pt) arc (90:180:5pt) -- (86.7865pt,33.0679pt) -- cycle;
+\node at (93.7865pt,12pt)[below right,color=black]{ROS ActionClient};
+\draw[pstyle3] (86.7865pt,737.4822pt) arc (180:270:5pt) -- (91.7865pt,732.4822pt) -- (225.9365pt,732.4822pt) arc (270:360:5pt) -- (230.9365pt,737.4822pt) -- (230.9365pt,760.5501pt) arc (0:90:5pt) -- (225.9365pt,765.5501pt) -- (91.7865pt,765.5501pt) arc (90:180:5pt) -- (86.7865pt,760.5501pt) -- cycle;
+\node at (93.7865pt,739.4822pt)[below right,color=black]{ROS ActionClient};
+\draw[pstyle3] (264.4068pt,10pt) arc (180:270:5pt) -- (269.4068pt,5pt) -- (367.3475pt,5pt) arc (270:360:5pt) -- (372.3475pt,10pt) -- (372.3475pt,33.0679pt) arc (0:90:5pt) -- (367.3475pt,38.0679pt) -- (269.4068pt,38.0679pt) arc (90:180:5pt) -- (264.4068pt,33.0679pt) -- cycle;
+\node at (271.4068pt,12pt)[below right,color=black]{ActorServer};
+\draw[pstyle3] (264.4068pt,737.4822pt) arc (180:270:5pt) -- (269.4068pt,732.4822pt) -- (367.3475pt,732.4822pt) arc (270:360:5pt) -- (372.3475pt,737.4822pt) -- (372.3475pt,760.5501pt) arc (0:90:5pt) -- (367.3475pt,765.5501pt) -- (269.4068pt,765.5501pt) arc (90:180:5pt) -- (264.4068pt,760.5501pt) -- cycle;
+\node at (271.4068pt,739.4822pt)[below right,color=black]{ActorServer};
+\draw[pstyle3] (431.3262pt,10pt) arc (180:270:5pt) -- (436.3262pt,5pt) -- (531.1768pt,5pt) arc (270:360:5pt) -- (536.1768pt,10pt) -- (536.1768pt,33.0679pt) arc (0:90:5pt) -- (531.1768pt,38.0679pt) -- (436.3262pt,38.0679pt) arc (90:180:5pt) -- (431.3262pt,33.0679pt) -- cycle;
+\node at (438.3262pt,12pt)[below right,color=black]{ActorPlugin};
+\draw[pstyle3] (431.3262pt,737.4822pt) arc (180:270:5pt) -- (436.3262pt,732.4822pt) -- (531.1768pt,732.4822pt) arc (270:360:5pt) -- (536.1768pt,737.4822pt) -- (536.1768pt,760.5501pt) arc (0:90:5pt) -- (531.1768pt,765.5501pt) -- (436.3262pt,765.5501pt) arc (90:180:5pt) -- (431.3262pt,760.5501pt) -- cycle;
+\node at (438.3262pt,739.4822pt)[below right,color=black]{ActorPlugin};
+\draw[pstyle0] (153.8615pt,156.186pt) rectangle (163.8615pt,705.4822pt);
+\draw[pstyle0] (313.3771pt,49.0679pt) rectangle (323.3771pt,767.5501pt);
+\draw[pstyle0] (478.7515pt,49.0679pt) rectangle (488.7515pt,767.5501pt);
+\draw[pstyle4] (67pt,54.0679pt) -- (67pt,81.0679pt) -- (153pt,81.0679pt) -- (153pt,64.0679pt) -- (143pt,54.0679pt) -- (67pt,54.0679pt);
+\draw[pstyle4] (143pt,54.0679pt) -- (143pt,64.0679pt) -- (153pt,64.0679pt) -- (143pt,54.0679pt);
+\node at (73pt,59.0679pt)[below right,color=black]{Protocol:};
+\draw[pstyle4] (212pt,54.0679pt) -- (212pt,81.0679pt) -- (307pt,81.0679pt) -- (307pt,64.0679pt) -- (297pt,54.0679pt) -- (212pt,54.0679pt);
+\draw[pstyle4] (297pt,54.0679pt) -- (297pt,64.0679pt) -- (307pt,64.0679pt) -- (297pt,54.0679pt);
+\node at (218pt,59.0679pt)[below right,color=black]{ros\_action};
+\draw[pstyle4] (347pt,54.0679pt) -- (347pt,81.0679pt) -- (472pt,81.0679pt) -- (472pt,64.0679pt) -- (462pt,54.0679pt) -- (347pt,54.0679pt);
+\draw[pstyle4] (462pt,54.0679pt) -- (462pt,64.0679pt) -- (472pt,64.0679pt) -- (462pt,54.0679pt);
+\node at (353pt,59.0679pt)[below right,color=black]{MessageQueue};
+\draw[pstyle5] (0pt,108.6269pt) rectangle (566.1768pt,111.6269pt);
+\draw[pstyle6] (0pt,108.6269pt) -- (566.1768pt,108.6269pt);
+\draw[pstyle6] (0pt,111.6269pt) -- (566.1768pt,111.6269pt);
+\draw[pstyle7] (259.0368pt,96.7739pt) rectangle (307.14pt,122.4799pt);
+\node at (265.0368pt,100.7739pt)[below right,color=black]{\textbf{Goal}};
+\draw[pstyle8] (141.8615pt,152.186pt) -- (151.8615pt,156.186pt) -- (141.8615pt,160.186pt) -- (145.8615pt,156.186pt) -- cycle;
+\draw[pstyle9] (0pt,156.186pt) -- (147.8615pt,156.186pt);
+\node at (9.5pt,136.4799pt)[below right,color=black]{create ActionClient};
+\draw[pstyle8] (301.3771pt,183.892pt) -- (311.3771pt,187.892pt) -- (301.3771pt,191.892pt) -- (305.3771pt,187.892pt) -- cycle;
+\draw[pstyle9] (163.8615pt,187.892pt) -- (307.3771pt,187.892pt);
+\node at (195.4141pt,168.186pt)[below right,color=black]{goal request};
+\draw[pstyle9] (164.8615pt,219.598pt) -- (174.8615pt,215.598pt);
+\draw[pstyle9] (164.8615pt,219.598pt) -- (174.8615pt,223.598pt);
+\draw[pstyle10] (163.8615pt,219.598pt) -- (312.3771pt,219.598pt);
+\node at (190.2546pt,199.892pt)[below right,color=black]{goal response};
+\draw[pstyle11] (66.7865pt,234.598pt) -- (132.0532pt,234.598pt) -- (132.0532pt,244.304pt) -- (122.0532pt,254.304pt) -- (66.7865pt,254.304pt) -- (66.7865pt,234.598pt);
+\draw[pstyle1] (66.7865pt,234.598pt) rectangle (556.1768pt,698.4822pt);
+\node at (81.7865pt,235.598pt)[below right,color=black]{\textbf{alt}};
+\node at (147.0532pt,236.598pt)[below right,color=black]{\textbf{[goal accepted]}};
+\draw[pstyle9] (476.7515pt,278.01pt) -- (466.7515pt,274.01pt);
+\draw[pstyle9] (476.7515pt,278.01pt) -- (466.7515pt,282.01pt);
+\draw[pstyle9] (323.3771pt,278.01pt) -- (477.7515pt,278.01pt);
+\node at (335.3771pt,258.304pt)[below right,color=black]{set state and target};
+\draw[pstyle9] (324.3771pt,309.716pt) -- (334.3771pt,305.716pt);
+\draw[pstyle9] (324.3771pt,309.716pt) -- (334.3771pt,313.716pt);
+\draw[pstyle10] (323.3771pt,309.716pt) -- (477.7515pt,309.716pt);
+\node at (357.5169pt,290.01pt)[below right,color=black]{state change};
+\draw[pstyle5] (0pt,339.5691pt) rectangle (566.1768pt,342.5691pt);
+\draw[pstyle6] (0pt,339.5691pt) -- (566.1768pt,339.5691pt);
+\draw[pstyle6] (0pt,342.5691pt) -- (566.1768pt,342.5691pt);
+\draw[pstyle7] (240.3737pt,327.716pt) rectangle (325.8032pt,353.4221pt);
+\node at (246.3737pt,331.716pt)[below right,color=black]{\textbf{Feedback}};
+\draw[pstyle11] (76.7865pt,370.4221pt) -- (179.6265pt,370.4221pt) -- (179.6265pt,380.1281pt) -- (169.6265pt,390.1281pt) -- (76.7865pt,390.1281pt) -- (76.7865pt,370.4221pt);
+\draw[pstyle1] (76.7865pt,370.4221pt) rectangle (546.1768pt,485.2461pt);
+\node at (91.7865pt,371.4221pt)[below right,color=black]{\textbf{opt par }};
+\node at (194.6265pt,372.4221pt)[below right,color=black]{\textbf{[abort of current action]}};
+\draw[pstyle8] (301.3771pt,409.8341pt) -- (311.3771pt,413.8341pt) -- (301.3771pt,417.8341pt) -- (305.3771pt,413.8341pt) -- cycle;
+\draw[pstyle9] (163.8615pt,413.8341pt) -- (307.3771pt,413.8341pt);
+\node at (191.0765pt,394.1281pt)[below right,color=black]{abort request};
+\draw[pstyle8] (466.7515pt,441.5401pt) -- (476.7515pt,445.5401pt) -- (466.7515pt,449.5401pt) -- (470.7515pt,445.5401pt) -- cycle;
+\draw[pstyle9] (323.3771pt,445.5401pt) -- (472.7515pt,445.5401pt);
+\node at (349.0047pt,425.8341pt)[below right,color=black]{set state to Idle};
+\draw[pstyle9] (164.8615pt,477.2461pt) -- (174.8615pt,473.2461pt);
+\draw[pstyle9] (164.8615pt,477.2461pt) -- (174.8615pt,481.2461pt);
+\draw[pstyle10] (163.8615pt,477.2461pt) -- (312.3771pt,477.2461pt);
+\node at (185.9161pt,457.5401pt)[below right,color=black]{abort response};
+\draw[pstyle11] (76.7865pt,499.2461pt) -- (154.1038pt,499.2461pt) -- (154.1038pt,508.9521pt) -- (144.1038pt,518.9521pt) -- (76.7865pt,518.9521pt) -- (76.7865pt,499.2461pt);
+\draw[pstyle1] (76.7865pt,499.2461pt) rectangle (546.1768pt,582.3642pt);
+\node at (91.7865pt,500.2461pt)[below right,color=black]{\textbf{loop}};
+\node at (169.1038pt,501.2461pt)[below right,color=black]{\textbf{[until action is completed or aborted]}};
+\draw[pstyle9] (324.3771pt,542.6582pt) -- (334.3771pt,538.6582pt);
+\draw[pstyle9] (324.3771pt,542.6582pt) -- (334.3771pt,546.6582pt);
+\draw[pstyle10] (323.3771pt,542.6582pt) -- (477.7515pt,542.6582pt);
+\node at (369.6072pt,522.9521pt)[below right,color=black]{feedback};
+\draw[pstyle9] (164.8615pt,574.3642pt) -- (174.8615pt,570.3642pt);
+\draw[pstyle9] (164.8615pt,574.3642pt) -- (174.8615pt,578.3642pt);
+\draw[pstyle10] (163.8615pt,574.3642pt) -- (312.3771pt,574.3642pt);
+\node at (175.8615pt,554.6582pt)[below right,color=black]{feedback callback};
+\draw[pstyle5] (0pt,611.2172pt) rectangle (566.1768pt,614.2172pt);
+\draw[pstyle6] (0pt,611.2172pt) -- (566.1768pt,611.2172pt);
+\draw[pstyle6] (0pt,614.2172pt) -- (566.1768pt,614.2172pt);
+\draw[pstyle7] (252.5128pt,599.3642pt) rectangle (313.664pt,625.0702pt);
+\node at (258.5128pt,603.3642pt)[below right,color=black]{\textbf{Result}};
+\draw[pstyle9] (324.3771pt,658.7762pt) -- (334.3771pt,654.7762pt);
+\draw[pstyle9] (324.3771pt,658.7762pt) -- (334.3771pt,662.7762pt);
+\draw[pstyle10] (323.3771pt,658.7762pt) -- (477.7515pt,658.7762pt);
+\node at (357.5169pt,639.0702pt)[below right,color=black]{state change};
+\draw[pstyle9] (164.8615pt,690.4822pt) -- (174.8615pt,686.4822pt);
+\draw[pstyle9] (164.8615pt,690.4822pt) -- (174.8615pt,694.4822pt);
+\draw[pstyle10] (163.8615pt,690.4822pt) -- (312.3771pt,690.4822pt);
+\node at (186.68pt,670.7762pt)[below right,color=black]{result callback};
+\draw[pstyle12] (149.8615pt,705.4822pt) -- (167.8615pt,723.4822pt);
+\draw[pstyle12] (149.8615pt,723.4822pt) -- (167.8615pt,705.4822pt);
+\end{tikzpicture}
+\end{document}

uml/plugin_connectivity.puml

@@ -0,0 +1,45 @@
+@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
+
+note left of client: Protocol:
+/note left of server: ros_action
+/note left of plugin: MessageQueue
+
+
+==Goal==
+activate server
+activate plugin
+
+[-> client: create ActionClient
+activate client
+
+client -> server: goal request
+server -->> client: goal response
+
+alt goal accepted
+server ->> plugin: set state and target
+plugin -->> server: state change
+== Feedback==
+group opt par [abort of current action]
+client->server: abort request
+server->plugin: set state to Idle
+server-->>client: abort response
+end
+loop until action is completed or aborted
+plugin -->> server: feedback
+server -->> client: feedback callback
+end
+==Result==
+plugin -->> server: state change
+server -->> client: result callback 
+end
+destroy client
+@enduml

uml/subtree_walk.puml

@@ -0,0 +1,17 @@
+@startmindmap
+
+top to bottom direction
+
+* Fallback
+** Ubuntu
+*** Linux Mint
+*** Kubuntu
+*** Lubuntu
+*** KDE Neon
+** LMDE
+** SolydXK
+** SteamOS
+** Raspbian with a very long name
+*** <s>Raspmbc</s> => OSMC
+*** <s>Raspyfi</s> => Volumio
+@endmindmap