Changes up to 22.04

.gitignore

@@ -1,315 +0,0 @@
-
-# Created by https://www.toptal.com/developers/gitignore/api/latex
-# Edit at https://www.toptal.com/developers/gitignore?templates=latex
-
-### LaTeX ###
-## Core latex/pdflatex auxiliary files:
-*.aux
-*.lof
-*.log
-*.lot
-*.fls
-*.out
-*.toc
-*.fmt
-*.fot
-*.cb
-*.cb2
-.*.lb
-
-## Intermediate documents:
-*.dvi
-*.xdv
-*-converted-to.*
-# these rules might exclude image files for figures etc.
-# *.ps
-# *.eps
-# *.pdf
-
-## Generated if empty string is given at "Please type another file name for output:"
-.pdf
-
-## Bibliography auxiliary files (bibtex/biblatex/biber):
-*.bbl
-*.bcf
-*.blg
-*-blx.aux
-*-blx.bib
-*.run.xml
-
-## Build tool auxiliary files:
-*.fdb_latexmk
-*.synctex
-*.synctex(busy)
-*.synctex.gz
-*.synctex.gz(busy)
-*.pdfsync
-
-## Build tool directories for auxiliary files
-# latexrun
-latex.out/
-
-## Auxiliary and intermediate files from other packages:
-# algorithms
-*.alg
-*.loa
-
-# achemso
-acs-*.bib
-
-# amsthm
-*.thm
-
-# beamer
-*.nav
-*.pre
-*.snm
-*.vrb
-
-# changes
-*.soc
-
-# comment
-*.cut
-
-# cprotect
-*.cpt
-
-# elsarticle (documentclass of Elsevier journals)
-*.spl
-
-# endnotes
-*.ent
-
-# fixme
-*.lox
-
-# feynmf/feynmp
-*.mf
-*.mp
-*.t[1-9]
-*.t[1-9][0-9]
-*.tfm
-
-#(r)(e)ledmac/(r)(e)ledpar
-*.end
-*.?end
-*.[1-9]
-*.[1-9][0-9]
-*.[1-9][0-9][0-9]
-*.[1-9]R
-*.[1-9][0-9]R
-*.[1-9][0-9][0-9]R
-*.eledsec[1-9]
-*.eledsec[1-9]R
-*.eledsec[1-9][0-9]
-*.eledsec[1-9][0-9]R
-*.eledsec[1-9][0-9][0-9]
-*.eledsec[1-9][0-9][0-9]R
-
-# glossaries
-*.acn
-*.acr
-*.glg
-*.glo
-*.gls
-*.glsdefs
-*.lzo
-*.lzs
-*.slg
-*.slo
-*.sls
-
-# uncomment this for glossaries-extra (will ignore makeindex's style files!)
-# *.ist
-
-# gnuplot
-*.gnuplot
-*.table
-
-# gnuplottex
-*-gnuplottex-*
-
-# gregoriotex
-*.gaux
-*.glog
-*.gtex
-
-# htlatex
-*.4ct
-*.4tc
-*.idv
-*.lg
-*.trc
-*.xref
-
-# hyperref
-*.brf
-
-# knitr
-*-concordance.tex
-# TODO Uncomment the next line if you use knitr and want to ignore its generated tikz files
-# *.tikz
-*-tikzDictionary
-
-# listings
-*.lol
-
-# luatexja-ruby
-*.ltjruby
-
-# makeidx
-*.idx
-*.ilg
-*.ind
-
-# minitoc
-*.maf
-*.mlf
-*.mlt
-*.mtc[0-9]*
-*.slf[0-9]*
-*.slt[0-9]*
-*.stc[0-9]*
-
-# minted
-_minted*
-*.pyg
-
-# morewrites
-*.mw
-
-# newpax
-*.newpax
-
-# nomencl
-*.nlg
-*.nlo
-*.nls
-
-# pax
-*.pax
-
-# pdfpcnotes
-*.pdfpc
-
-# sagetex
-*.sagetex.sage
-*.sagetex.py
-*.sagetex.scmd
-
-# scrwfile
-*.wrt
-
-# svg
-svg-inkscape/
-
-# sympy
-*.sout
-*.sympy
-sympy-plots-for-*.tex/
-
-# pdfcomment
-*.upa
-*.upb
-
-# pythontex
-*.pytxcode
-pythontex-files-*/
-
-# tcolorbox
-*.listing
-
-# thmtools
-*.loe
-
-# TikZ & PGF
-*.dpth
-*.md5
-*.auxlock
-
-# titletoc
-*.ptc
-
-# todonotes
-*.tdo
-
-# vhistory
-*.hst
-*.ver
-
-# easy-todo
-*.lod
-
-# xcolor
-*.xcp
-
-# xmpincl
-*.xmpi
-
-# xindy
-*.xdy
-
-# xypic precompiled matrices and outlines
-*.xyc
-*.xyd
-
-# endfloat
-*.ttt
-*.fff
-
-# Latexian
-TSWLatexianTemp*
-
-## Editors:
-# WinEdt
-*.bak
-*.sav
-
-# Texpad
-.texpadtmp
-
-# LyX
-*.lyx~
-
-# Kile
-*.backup
-
-# gummi
-.*.swp
-
-# KBibTeX
-*~[0-9]*
-
-# TeXnicCenter
-*.tps
-
-# auto folder when using emacs and auctex
-./auto/*
-*.el
-
-# expex forward references with \gathertags
-*-tags.tex
-
-# standalone packages
-*.sta
-
-# Makeindex log files
-*.lpz
-
-# xwatermark package
-*.xwm
-
-# REVTeX puts footnotes in the bibliography by default, unless the nofootinbib
-# option is specified. Footnotes are the stored in a file with suffix Notes.bib.
-# Uncomment the next line to have this generated file ignored.
-#*Notes.bib
-
-### LaTeX Patch ###
-# LIPIcs / OASIcs
-*.vtc
-
-# glossaries
-*.glstex
-
-# End of https://www.toptal.com/developers/gitignore/api/latex

.kile/mechforsch.kilepr.gui

@@ -77,8 +77,8 @@ Mode=LaTeX
 Mode Set By User=false
 
 [item:main.bib]
-open=false
+open=true
-order=1
+order=5
 
 [item:main.tex]
 open=true
@@ -113,27 +113,27 @@ TextFolding={"checksum":"","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.bib]
-CursorColumn=14
+CursorColumn=39
-CursorLine=109
+CursorLine=124
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"4af487415133a6dcd896d70e042ef9ac694f0ea6","ranges":[]}
+TextFolding={"checksum":"739b41a3d0418be76fb9832856bf61b41b8246a1","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
-CursorColumn=0
+CursorColumn=45
-CursorLine=111
+CursorLine=176
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"86fedba94f6f431aca10df7e7ffc4fd7dd3eac24","ranges":[]}
+TextFolding={"checksum":"158329202f028c3e1d1437e81256f8ab37c5f9c3","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/1_Einleitung.tex]
-CursorColumn=42
+CursorColumn=0
-CursorLine=26
+CursorLine=19
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"7f68313ac5accbbfe63bf0c2f33b5f2b97851ec3","ranges":[]}
+TextFolding={"checksum":"8adc2060163a9c199c7a904534fb248831564ce4","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/2_Konzept.tex]
@@ -141,23 +141,23 @@ CursorColumn=0
 CursorLine=0
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"daf7cac8e4765460806a7139b3eb9171fb011da3","ranges":[]}
+TextFolding={"checksum":"0c6fe8907e6bb50811600d85d72851fe402f8c80","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/3_Auswahl.tex]
-CursorColumn=0
+CursorColumn=157
-CursorLine=164
+CursorLine=266
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"04558a693eba7702df7000723ab69b6eb36166ba","ranges":[]}
+TextFolding={"checksum":"e90e925eeab38e92c6b17256a2993fc4a01f29c8","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/4_Umsetzung.tex]
-CursorColumn=0
+CursorColumn=27
-CursorLine=216
+CursorLine=138
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"93fb61d8448ada79778cce2b5e34a55776abbb30","ranges":[]}
+TextFolding={"checksum":"d54709e0d3b00c46d9571f297ab62aa6064e7f7c","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/Einleitung.tex]

main.bbl

@@ -0,0 +1,145 @@
+% $ biblatex auxiliary file $
+% $ biblatex bbl format version 3.2 $
+% Do not modify the above lines!
+%
+% This is an auxiliary file used by the 'biblatex' package.
+% This file may safely be deleted. It will be recreated by
+% biber as required.
+%
+\begingroup
+\makeatletter
+\@ifundefined{ver@biblatex.sty}
+  {\@latex@error
+     {Missing 'biblatex' package}
+     {The bibliography requires the 'biblatex' package.}
+      \aftergroup\endinput}
+  {}
+\endgroup
+
+
+\refsection{0}
+  \datalist[entry]{nty/global//global/global}
+    \entry{colcon}{misc}{}
+      \field{sortinit}{c}
+      \field{sortinithash}{4d103a86280481745c9c897c925753c0}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 02.04.2023}
+      \field{title}{colcon - collective construction}
+      \verb{urlraw}
+      \verb https://colcon.readthedocs.io/en/released/
+      \endverb
+      \verb{url}
+      \verb https://colcon.readthedocs.io/en/released/
+      \endverb
+    \endentry
+    \entry{ros-git}{misc}{}
+      \field{sortinit}{G}
+      \field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 02.04.2023}
+      \field{title}{GitHub - ros2/ros2: The Robot Operating System, is a meta operating system for robots.}
+      \verb{urlraw}
+      \verb https://github.com/ros2/ros2
+      \endverb
+      \verb{url}
+      \verb https://github.com/ros2/ros2
+      \endverb
+    \endentry
+    \entry{doi:10.1126/scirobotics.abm6074}{article}{}
+      \name{author}{5}{}{%
+        {{hash=7b84d10a03303cd00f198fefb38a5da3}{%
+           family={Macenski},
+           familyi={M\bibinitperiod},
+           given={Steven},
+           giveni={S\bibinitperiod}}}%
+        {{hash=0d11ace6e44e4742ea1692d7ddf4819e}{%
+           family={Foote},
+           familyi={F\bibinitperiod},
+           given={Tully},
+           giveni={T\bibinitperiod}}}%
+        {{hash=a8ad4a5f43253f69552460c946e34e49}{%
+           family={Gerkey},
+           familyi={G\bibinitperiod},
+           given={Brian},
+           giveni={B\bibinitperiod}}}%
+        {{hash=4e2c9f9d04cf548117105f50a9c8a7a1}{%
+           family={Lalancette},
+           familyi={L\bibinitperiod},
+           given={Chris},
+           giveni={C\bibinitperiod}}}%
+        {{hash=fe838d86b89f8983167a3747e11998bb}{%
+           family={Woodall},
+           familyi={W\bibinitperiod},
+           given={William},
+           giveni={W\bibinitperiod}}}%
+      }
+      \strng{namehash}{4a195e02383364d4009f77ca22451e11}
+      \strng{fullhash}{c321d95ccac4f92536f0f1ed99f34d05}
+      \strng{bibnamehash}{4a195e02383364d4009f77ca22451e11}
+      \strng{authorbibnamehash}{4a195e02383364d4009f77ca22451e11}
+      \strng{authornamehash}{4a195e02383364d4009f77ca22451e11}
+      \strng{authorfullhash}{c321d95ccac4f92536f0f1ed99f34d05}
+      \field{sortinit}{M}
+      \field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
+      \field{labelnamesource}{author}
+      \field{labeltitlesource}{title}
+      \field{journaltitle}{Science Robotics}
+      \field{number}{66}
+      \field{title}{Robot Operating System 2: Design, architecture, and uses in the wild}
+      \field{volume}{7}
+      \field{year}{2022}
+      \field{pages}{eabm6074}
+      \range{pages}{-1}
+      \verb{doi}
+      \verb 10.1126/scirobotics.abm6074
+      \endverb
+      \verb{urlraw}
+      \verb https://www.science.org/doi/abs/10.1126/scirobotics.abm6074
+      \endverb
+      \verb{url}
+      \verb https://www.science.org/doi/abs/10.1126/scirobotics.abm6074
+      \endverb
+    \endentry
+    \entry{moveitpython}{misc}{}
+      \field{sortinit}{M}
+      \field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 10.04.2023}
+      \field{title}{MoveIt Commander with ROS2 - Issue \#337 - ros-planning/moveit2_tutorials}
+      \verb{urlraw}
+      \verb https://github.com/ros-planning/moveit2_tutorials/issues/337
+      \endverb
+      \verb{url}
+      \verb https://github.com/ros-planning/moveit2_tutorials/issues/337
+      \endverb
+    \endentry
+    \entry{moveitpipeline}{misc}{}
+      \field{sortinit}{m}
+      \field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 02.04.2023}
+      \field{title}{moveit2_tutorials/moveit_pipeline.png at humble - ros-planning/moveit2_tutorials}
+      \verb{urlraw}
+      \verb https://github.com/ros-planning/moveit2_tutorials/blob/humble/_static/images/moveit_pipeline.png
+      \endverb
+      \verb{url}
+      \verb https://github.com/ros-planning/moveit2_tutorials/blob/humble/_static/images/moveit_pipeline.png
+      \endverb
+    \endentry
+    \entry{rospackages}{misc}{}
+      \field{sortinit}{P}
+      \field{sortinithash}{ff3bcf24f47321b42cb156c2cc8a8422}
+      \field{labeltitlesource}{title}
+      \field{note}{letzter Zugriff: 10.04.2023}
+      \field{title}{Packages - /ros2/ubuntu/pool/main/ :: Oregon State University Open Source Lab}
+      \verb{urlraw}
+      \verb http://packages.ros.org/ros2/ubuntu/pool/main/
+      \endverb
+      \verb{url}
+      \verb http://packages.ros.org/ros2/ubuntu/pool/main/
+      \endverb
+    \endentry
+  \enddatalist
+\endrefsection
+\endinput
+

main.bib

@@ -35,12 +35,6 @@
   note = {letzter Zugriff: 13.4.2022},
 }
 
-@misc{sdf,
-  title = {SDFormat Specification},
-  url = {http://sdformat.org/spec},
-  note = {letzter Zugriff: 13.4.2022},
-}
-
 @misc{urdf,
   title = {Tutorial: Using a URDF in Gazebo},
   url = {http://gazebosim.org/tutorials/?tut=ros_urdf},
@@ -142,3 +136,27 @@
   url = {https://unity.com/solutions/automotive-transportation-manufacturing/robotics},
   note = {letzter Zugriff: 10.04.2023},
 }
+
+@misc{freecad,
+  title = {FreeCAD: Ihr parametrischer 3D-Modellierer},
+  url = {https://www.freecad.org/index.php?lang=de},
+  note = {letzter Zugriff: 21.04.2023},
+}
+
+@misc{xacro,
+  title = {FreeCAD: Ihr parametrischer 3D-Modellierer},
+  url = {https://github.com/ros/xacro},
+  note = {letzter Zugriff: 21.04.2023},
+}
+
+@misc{gazebo-app,
+  title = {Gazebo},
+  url = {https://app.gazebosim.org/dashboard},
+  note = {letzter Zugriff: 23.04.2023},
+}
+
+@misc{sdf-format,
+  title = {SDFormat Specification},
+  url = {https://sdformat.org/spec},
+  note = {letzter Zugriff: 23.04.2023},
+}

main.blg

@@ -0,0 +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
+[51] Biber.pm:419> INFO - Reading 'main.bcf'
+[88] Biber.pm:979> INFO - Found 6 citekeys in bib section 0
+[95] Biber.pm:4419> INFO - Processing section 0
+[100] Biber.pm:4610> INFO - Looking for bibtex file 'main.bib' for section 0
+[101] bibtex.pm:1713> INFO - LaTeX decoding ...
+[107] 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'
+[131] 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'
+[131] Biber.pm:4245> INFO - No sort tailoring available for locale 'de-DE'
+[136] bbl.pm:660> INFO - Writing 'main.bbl' with encoding 'UTF-8'
+[137] bbl.pm:763> INFO - Output to main.bbl

main.out.ps

@@ -4,78 +4,238 @@
 ifelse
 [
 /Title(\376\377\000E\000i\000n\000l\000e\000i\000t\000u\000n\000g)
+/Count -4
 /Action/GoTo/Dest(chapter.1)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000A\000u\000f\000g\000a\000b\000e)
+/Title(\376\377\000M\000o\000t\000i\000v\000a\000t\000i\000o\000n)
+/Action/GoTo/Dest(section.1.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000S\000t\000a\000n\000d\000\040\000d\000e\000r\000\040\000W\000i\000s\000s\000e\000n\000s\000c\000h\000a\000f\000t)
+/Action/GoTo/Dest(section.1.2)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000W\000e\000l\000c\000h\000e\000\040\000S\000z\000e\000n\000a\000r\000i\000e\000n)
+/Action/GoTo/Dest(section.1.3)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000W\000e\000l\000c\000h\000e\000r\000\040\000N\000u\000t\000z\000e\000n\000\040\000/\000\040\000C\000o\000n\000t\000r\000i\000b\000u\000t\000i\000o\000n\000s)
+/Action/GoTo/Dest(section.1.4)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000K\000o\000n\000z\000e\000p\000t)
+/Count -3
 /Action/GoTo/Dest(chapter.2)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000L\000\366\000s\000u\000n\000g\000s\000k\000o\000n\000z\000e\000p\000t)
+/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000s)
+/Action/GoTo/Dest(section.2.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000\040\000d\000e\000s\000\040\000M\000e\000n\000s\000c\000h\000e\000n)
+/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)
+/Action/GoTo/Dest(section.2.3)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
 /Action/GoTo/Dest(chapter.3)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000R\000O\000S)
+/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)
 /Count -2
 /Action/GoTo/Dest(section.3.1)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000M\000o\000v\000e\000I\000t)
+/Title(\376\377\000A\000u\000s\000w\000a\000h\000l)
 /Action/GoTo/Dest(subsection.3.1.1)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e)
+/Title(\376\377\000B\000e\000s\000c\000h\000r\000e\000i\000b\000u\000n\000g)
 /Action/GoTo/Dest(subsection.3.1.2)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000G\000a\000z\000e\000b\000o)
+/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 -1
+/Count -3
 /Action/GoTo/Dest(section.3.2)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000S\000e\000n\000s\000o\000r\000e\000n)
+/Title(\376\377\000A\000u\000s\000w\000a\000h\000l)
 /Action/GoTo/Dest(subsection.3.2.1)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000R\000o\000b\000o\000t\000e\000r)
+/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.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)
+/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)
 /Action/GoTo/Dest(section.3.3)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000Z\000u\000s\000a\000m\000m\000e\000n\000f\000a\000s\000s\000u\000n\000g)
+/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
 /Action/GoTo/Dest(section.3.4)cvn
 /OUT pdfmark
 [
 /Title(\376\377\000U\000m\000s\000e\000t\000z\000u\000n\000g)
-/Count -1
+/Count -4
 /Action/GoTo/Dest(chapter.4)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000R\000O\000S)
+/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)
-/Count -4
 /Action/GoTo/Dest(section.4.1)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000A\000u\000s\000w\000a\000h\000l\000\040\000d\000e\000r\000\040\000R\000O\000S\000-\000U\000m\000g\000e\000b\000u\000n\000g)
+/Title(\376\377\000M\000e\000n\000s\000c\000h)
-/Action/GoTo/Dest(subsection.4.1.1)cvn
+/Count -3
+/Action/GoTo/Dest(section.4.2)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000G\000a\000z\000e\000b\000o)
+/Title(\376\377\000\334\000b\000e\000r\000s\000i\000c\000h\000t)
-/Action/GoTo/Dest(subsection.4.1.2)cvn
+/Action/GoTo/Dest(subsection.4.2.1)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000M\000o\000v\000e\000I\000t)
+/Title(\376\377\000M\000o\000d\000e\000l\000l\000i\000e\000r\000u\000n\000g)
-/Action/GoTo/Dest(subsection.4.1.3)cvn
+/Action/GoTo/Dest(subsection.4.2.2)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000u\000r\000-\000T\000r\000e\000e\000s)
+/Title(\376\377\000P\000r\000o\000g\000r\000a\000m\000m\000i\000e\000r\000u\000n\000g)
-/Action/GoTo/Dest(subsection.4.1.4)cvn
+/Action/GoTo/Dest(subsection.4.2.3)cvn
 /OUT pdfmark
 [
-/Title(\376\377\000E\000r\000g\000e\000b\000n\000i\000s\000s\000e)
+/Title(\376\377\000R\000o\000b\000o\000t\000e\000r)
+/Count -4
+/Action/GoTo/Dest(section.4.3)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000\334\000b\000e\000r\000s\000i\000c\000h\000t)
+/Action/GoTo/Dest(subsection.4.3.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
+/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
+/OUT pdfmark
+[
+/Title(\376\377\000D\000e\000t\000a\000i\000l\000s)
+/Action/GoTo/Dest(subsection.4.3.4)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
+/Count -1
+/Action/GoTo/Dest(section.4.4)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.4.4.1)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)
+/Count -3
 /Action/GoTo/Dest(chapter.5)cvn
 /OUT pdfmark
 [
+/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000\040\000d\000e\000s\000\040\000M\000e\000n\000s\000c\000h\000e\000n)
+/Action/GoTo/Dest(section.5.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000B\000e\000w\000e\000g\000u\000n\000g\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000s)
+/Action/GoTo/Dest(section.5.2)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000T\000r\000e\000e\000s)
+/Count -2
+/Action/GoTo/Dest(section.5.3)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000N\000o\000d\000e\000s)
+/Action/GoTo/Dest(subsection.5.3.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000K\000o\000m\000b\000i\000n\000i\000e\000r\000e\000n\000\040\000v\000o\000n\000\040\000N\000o\000d\000e\000s\000\040\000z\000u\000\040\000e\000i\000n\000e\000r\000\040\000R\000e\000q\000u\000e\000s\000t)
+/Action/GoTo/Dest(subsection.5.3.2)cvn
+/OUT pdfmark
+[
 /Title(\376\377\000D\000i\000s\000k\000u\000s\000s\000i\000o\000n)
+/Count -2
 /Action/GoTo/Dest(chapter.6)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\000r\000\040\000U\000m\000s\000e\000t\000z\000u\000n\000g)
+/Count -4
+/Action/GoTo/Dest(section.6.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000E\000r\000s\000t\000e\000l\000l\000u\000n\000g\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000m\000o\000d\000e\000l\000l\000s)
+/Action/GoTo/Dest(subsection.6.1.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000G\000a\000z\000e\000b\000o)
+/Action/GoTo/Dest(subsection.6.1.2)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000R\000O\000S\0002)
+/Action/GoTo/Dest(subsection.6.1.3)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000M\000o\000v\000e\000I\000t\0002)
+/Action/GoTo/Dest(subsection.6.1.4)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
+/OUT pdfmark
+[
+/Title(\376\377\000D\000e\000b\000u\000g\000g\000i\000n\000g)
+/Action/GoTo/Dest(subsection.6.2.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000Z\000u\000s\000a\000m\000m\000e\000n\000f\000a\000s\000s\000u\000n\000g\000\040\000u\000n\000d\000\040\000A\000u\000s\000b\000l\000i\000c\000k)
+/Count -3
+/Action/GoTo/Dest(chapter.7)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000E\000r\000g\000e\000b\000n\000i\000s\000s\000e)
+/Count -2
+/Action/GoTo/Dest(section.7.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000G\000r\000a\000p\000h\000i\000s\000c\000h\000e\000\040\000R\000e\000p\000r\000\344\000s\000e\000n\000t\000a\000t\000i\000o\000n\000\040\000d\000e\000r\000\040\000S\000z\000e\000n\000a\000r\000i\000e\000n)
+/Action/GoTo/Dest(subsection.7.1.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000A\000n\000p\000a\000s\000s\000u\000n\000g\000\040\000d\000e\000r\000\040\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s\000\040\000a\000n\000\040\000S\000z\000e\000n\000a\000r\000i\000e\000n)
+/Action/GoTo/Dest(subsection.7.1.2)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000D\000i\000s\000k\000u\000s\000s\000i\000o\000n)
+/Action/GoTo/Dest(section.7.2)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000A\000u\000s\000b\000l\000i\000c\000k)
+/Count -3
+/Action/GoTo/Dest(section.7.3)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000U\000m\000s\000e\000t\000z\000u\000n\000g\000\040\000i\000n\000\040\000a\000n\000d\000e\000r\000e\000m\000\040\000S\000i\000m\000u\000l\000a\000t\000o\000r)
+/Action/GoTo/Dest(subsection.7.3.1)cvn
+/OUT pdfmark
+[
+/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000\040\000b\000e\000w\000e\000g\000t\000e\000r\000\040\000O\000b\000j\000e\000k\000t\000e)
+/Action/GoTo/Dest(subsection.7.3.2)cvn
+/OUT pdfmark
+[
+/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

main.run.xml

@@ -0,0 +1,86 @@
+<?xml version="1.0" standalone="yes"?>
+<!-- logreq request file -->
+<!-- logreq version 1.0 / dtd version 1.0 -->
+<!-- Do not edit this file! -->
+<!DOCTYPE requests [
+  <!ELEMENT requests (internal | external)*>
+  <!ELEMENT internal (generic, (provides | requires)*)>
+  <!ELEMENT external (generic, cmdline?, input?, output?, (provides | requires)*)>
+  <!ELEMENT cmdline (binary, (option | infile | outfile)*)>
+  <!ELEMENT input (file)+>
+  <!ELEMENT output (file)+>
+  <!ELEMENT provides (file)+>
+  <!ELEMENT requires (file)+>
+  <!ELEMENT generic (#PCDATA)>
+  <!ELEMENT binary (#PCDATA)>
+  <!ELEMENT option (#PCDATA)>
+  <!ELEMENT infile (#PCDATA)>
+  <!ELEMENT outfile (#PCDATA)>
+  <!ELEMENT file (#PCDATA)>
+  <!ATTLIST requests
+    version CDATA #REQUIRED
+  >
+  <!ATTLIST internal
+    package CDATA #REQUIRED
+    priority (9) #REQUIRED
+    active (0 | 1) #REQUIRED
+  >
+  <!ATTLIST external
+    package CDATA #REQUIRED
+    priority (1 | 2 | 3 | 4 | 5 | 6 | 7 | 8) #REQUIRED
+    active (0 | 1) #REQUIRED
+  >
+  <!ATTLIST provides
+    type (static | dynamic | editable) #REQUIRED
+  >
+  <!ATTLIST requires
+    type (static | dynamic | editable) #REQUIRED
+  >
+  <!ATTLIST file
+    type CDATA #IMPLIED
+  >
+]>
+<requests version="1.0">
+  <internal package="biblatex" priority="9" active="0">
+    <generic>latex</generic>
+    <provides type="dynamic">
+      <file>main.bcf</file>
+    </provides>
+    <requires type="dynamic">
+      <file>main.bbl</file>
+    </requires>
+    <requires type="static">
+      <file>blx-dm.def</file>
+      <file>blx-compat.def</file>
+      <file>biblatex.def</file>
+      <file>standard.bbx</file>
+      <file>numeric.bbx</file>
+      <file>numeric.cbx</file>
+      <file>biblatex.cfg</file>
+      <file>german.lbx</file>
+      <file>ngerman.lbx</file>
+    </requires>
+  </internal>
+  <external package="biblatex" priority="5" active="0">
+    <generic>biber</generic>
+    <cmdline>
+      <binary>biber</binary>
+      <infile>main</infile>
+    </cmdline>
+    <input>
+      <file>main.bcf</file>
+    </input>
+    <output>
+      <file>main.bbl</file>
+    </output>
+    <provides type="dynamic">
+      <file>main.bbl</file>
+    </provides>
+    <requires type="dynamic">
+      <file>main.bcf</file>
+    </requires>
+    <requires type="editable">
+      <file>main.bib</file>
+    </requires>
+  </external>
+</requests>

main.tex

@@ -13,7 +13,6 @@ parskip=half,
 \usepackage{acro}
 \usepackage{listings}
 \usepackage[style=numeric,backend=biber]{biblatex}
-%\usepackage[style=numeric,backend=libbib]{biblatex}
 \usepackage{pdfpages}
 \usepackage{scrhack}
 \usepackage{xcolor}
@@ -21,7 +20,9 @@ parskip=half,
 \usepackage{hyperref}
 \usepackage{tabularray}
 \usepackage{xurl}
+\usepackage{soul}
 \usepackage{xcolor}
+\usepackage{inconsolata}
 \usepackage[strings]{underscore}
 
 \usepackage[letterspace=150]{microtype}
@@ -34,7 +35,13 @@ parskip=half,
 }
 
 \definecolor{light-gray}{gray}{0.95}
-\newcommand{\code}[1]{\colorbox{light-gray}{\texttt{#1}}}
+%\newcommand{\code}[1]{\colorbox{light-gray}{\texttt{#1}}}
+\newcommand{\code}[1]{
+  \begingroup%
+  \sethlcolor{light-gray}%
+  \hl{\texttt{#1}}%
+  \endgroup
+}
 
 \ihead*{\rightmark}
 \ohead*{\thepage}
@@ -120,6 +127,10 @@ parskip=half,
 -Nur CAD-Dateien der Außenhülle
 
 -Schätzung von Spezifikationen anhand Marketingmaterial
+\subsection{Erweiterung des Robotermodells mit MoveIt}
+-Fehler durch falsche Pfade des Setups
+
+-Fehler durch fehlerhafte Config (Mal nachsehen, was das genau war)
 \subsection{Gazebo}
 \subsubsection{Upgrade auf Ignition}
 Gazebo ist zu diesem Zeitpunkt in mehreren, teilweise gleichnamigen Versionen verfügbar, welche sich jedoch grundlegend unterscheiden.
@@ -141,11 +152,28 @@ Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler währe
 Auch das alte Plugin musste auf das neue System angepasst werden, was auch hier zu einer kompletten Neuimplementation führte, da die internen Systeme zu große Unterschiede aufwiesen.
 Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, welche auf ein Entity-Component-System umstellte, aber auch sahlreiche kleinere Änderungen
 \subsubsection{Pluginarchitektur}
--Plugins werden im selben Kontext geladen, verwendung von Librarys mit globalem Kontext schwer
+Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
-\subsubsection{Doppelte Messagedienste}
+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.
--Duplizierung von Messagediensten in ROS und Gazebo
+
+Zur Kommunikation des ActorPlugins mit dem ROS-ActionServer wurde die benötigte Funktionalität vorerst im Plugin selbst implementiert.
+Da diese Funktionalität zuerst entwickelt wurde, konnte sie zu diesem Zeitpunkt nur alleinstehend getestet werden.
+Diese Tests verliefen vorerst erfolgreich, jedoch scheiterten sie bei der Integration des Robotermodells, welches über die \code{ros_control}-Integration ebenfalls \code{rclcpp} nutzt.
+
+Um dieses Problem zu umgehen, sind mehrere Lösungsansätze denkbar.
+\begin{description}
+  \item[Separater Nachrichtendienst]
+  Ein solcher losgelöster Dienst kann die Nachrichten mit einem anderen Programm auszutauschen, welches die Kommunikation nach außen übernimmt.
+  \item[Nutzung der gleichen ROS-Instanz]
+  Um dem Problem zu begegnen, könnte auch eine globale ROS-Instanz von Gazebo verwaltet werden, welche dann von den Plugins genutzt werden kann.
+  Dies könnte als ein Plugin realisiert werden, welches diese anderen Plugins zur Verfügung stellt, jedoch müssten die anderen Plugins zur Nutzung dieser Schnittstelle modifiziert werden.
+  \item[Gazebo-ROS-Brücke]
+  Die Gazebo-ROS-Brücke kann Nachrichten, welche in beiden Formaten definiert wurden, ineinander umwandeln.
+  Dies ermöglicht die Kommunikation über die Brücke als Mittelmann.
+  Dabei müssten Anpassungen an der Architektur vorgenommen werden, da Gazebo kein Äquivalent zum ActionServer besitzt.
+\end{description}
+Die Entscheidung fiel auf einen separaten Nachrichtendienst, da dessen Implementation losgelöst von anderen Systemen funktioniert.
+Natürlich ist die Einführung eines weiteren Nachrichtendienstes ein Bruch der Philosophie, jedoch die einzige Methode, die garantiert funktioniert, weswegen sie letztendlich implementiert wurde.
 
--Potentielle Lösung in einer Präsentation angekündigt (mal sehen, ob ich die wiederfinde)
 \subsubsection{Fehlende Animationsgrundlagen}
 -Animationen werden als .col bereitgestellt
 
@@ -203,11 +231,18 @@ Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, w
 
 -Daten aus Gazebo extrahieren und in MoveIt einbinden
 
--Person in OctoMap erkennen
+-Person in OctoMap\cite{octomap} erkennen
+\subsection{Zusammenbringen von ActorPlugin und ActorServer}
+-Mechanismus für Datenaustausch zwischen ROS und Gazebo überdenken/überarbeiten
+
+-Geteilte ROS Instanz zwischen Plugins? Wie?
+
+-Potentielle Integration von ROS als Messagedients in Gazebo
+
 
 \printbibliography
 \markboth{Anhang}{Anhang}
-\begin{figure}[h]
+\begin{figure}[ht]
 \includegraphics[width=14cm]{img/moveit_pipeline}
 \caption{Visualisierung der MoveIt Pipeline\cite{moveitpipeline}}
 \label{moveitpipeline}

main.toc

@@ -0,0 +1,79 @@
+\acswitchoff 
+\babel@toc {ngerman}{}\relax 
+\contentsline {chapter}{\numberline {1}Einleitung}{1}{chapter.1}%
+\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 {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 {chapter}{\numberline {3}Komponenten-/Softwareauswahl}{7}{chapter.3}%
+\contentsline {section}{\numberline {3.1}Dienstumgebung (ROS2)}{7}{section.3.1}%
+\contentsline {subsection}{\numberline {3.1.1}Auswahl}{7}{subsection.3.1.1}%
+\contentsline {subsection}{\numberline {3.1.2}Beschreibung}{8}{subsection.3.1.2}%
+\contentsline {section}{\numberline {3.2}Simulationsumgebung (Gazebo)}{9}{section.3.2}%
+\contentsline {subsection}{\numberline {3.2.1}Auswahl}{9}{subsection.3.2.1}%
+\contentsline {subsection}{\numberline {3.2.2}Robotersimulation}{10}{subsection.3.2.2}%
+\contentsline {subsection}{\numberline {3.2.3}Menschensimulation}{11}{subsection.3.2.3}%
+\contentsline {section}{\numberline {3.3}Roboterumgebung (MoveIt2)}{12}{section.3.3}%
+\contentsline {section}{\numberline {3.4}Behavior Trees}{13}{section.3.4}%
+\contentsline {subsection}{\numberline {3.4.1}Asynchrone Nodes}{14}{subsection.3.4.1}%
+\contentsline {section}{\numberline {3.5}Docker-Compose als Virtualisierungsumgebung}{15}{section.3.5}%
+\contentsline {chapter}{\numberline {4}Umsetzung}{16}{chapter.4}%
+\contentsline {section}{\numberline {4.1}Grundlegender Systemaufbau}{16}{section.4.1}%
+\contentsline {section}{\numberline {4.2}Verwendete Datentypen}{16}{section.4.2}%
+\contentsline {section}{\numberline {4.3}Mensch}{18}{section.4.3}%
+\contentsline {subsection}{\numberline {4.3.1}Übersicht}{18}{subsection.4.3.1}%
+\contentsline {subsection}{\numberline {4.3.2}Modellierung}{18}{subsection.4.3.2}%
+\contentsline {subsection}{\numberline {4.3.3}Programmierung}{19}{subsection.4.3.3}%
+\contentsline {subsubsection}{\nonumberline Message Queue}{19}{subsubsection*.3}%
+\contentsline {subsubsection}{\nonumberline Nachrichten}{21}{subsubsection*.5}%
+\contentsline {subsubsection}{\nonumberline ActorServer}{21}{subsubsection*.7}%
+\contentsline {subsubsection}{\nonumberline Gazebo Plugin}{22}{subsubsection*.9}%
+\contentsline {section}{\numberline {4.4}Roboter}{22}{section.4.4}%
+\contentsline {subsection}{\numberline {4.4.1}Übersicht}{22}{subsection.4.4.1}%
+\contentsline {subsection}{\numberline {4.4.2}Modellierung}{22}{subsection.4.4.2}%
+\contentsline {subsection}{\numberline {4.4.3}MoveIt 2 Konfiguration}{23}{subsection.4.4.3}%
+\contentsline {subsection}{\numberline {4.4.4}Details}{24}{subsection.4.4.4}%
+\contentsline {section}{\numberline {4.5}Behavior Trees}{24}{section.4.5}%
+\contentsline {subsubsection}{\nonumberline Allgemein nutzbare Nodes}{24}{subsubsection*.11}%
+\contentsline {subsubsection}{\nonumberline Menschenspezifisch}{25}{subsubsection*.13}%
+\contentsline {subsubsection}{\nonumberline Roboterspezifisch}{26}{subsubsection*.15}%
+\contentsline {section}{\numberline {4.6}Docker-Compose}{26}{section.4.6}%
+\contentsline {chapter}{\numberline {5}Szenarienbasierte Evaluation}{28}{chapter.5}%
+\contentsline {section}{\numberline {5.1}Simulation des Menschen}{28}{section.5.1}%
+\contentsline {section}{\numberline {5.2}Bewegung des Roboters}{28}{section.5.2}%
+\contentsline {section}{\numberline {5.3}BehaviorTrees}{28}{section.5.3}%
+\contentsline {subsection}{\numberline {5.3.1}Nodes}{28}{subsection.5.3.1}%
+\contentsline {subsection}{\numberline {5.3.2}Kombinieren von Nodes zu einer Request}{28}{subsection.5.3.2}%
+\contentsline {chapter}{\numberline {6}Diskussion}{29}{chapter.6}%
+\contentsline {section}{\numberline {6.1}Lessons Learned bei der Umsetzung}{29}{section.6.1}%
+\contentsline {subsection}{\numberline {6.1.1}Erstellung des Robotermodells}{29}{subsection.6.1.1}%
+\contentsline {subsection}{\numberline {6.1.2}Gazebo}{29}{subsection.6.1.2}%
+\contentsline {subsubsection}{\nonumberline Upgrade auf Ignition}{29}{subsubsection*.17}%
+\contentsline {subsubsection}{\nonumberline Pluginarchitektur}{30}{subsubsection*.19}%
+\contentsline {subsubsection}{\nonumberline Doppelte Messagedienste}{30}{subsubsection*.21}%
+\contentsline {subsubsection}{\nonumberline Fehlende Animationsgrundlagen}{30}{subsubsection*.23}%
+\contentsline {subsection}{\numberline {6.1.3}ROS2}{30}{subsection.6.1.3}%
+\contentsline {subsubsection}{\nonumberline Nachrichten und deren Echtzeitfähigkeit}{30}{subsubsection*.25}%
+\contentsline {subsubsection}{\nonumberline Änderung der Compilertoolchain}{30}{subsubsection*.27}%
+\contentsline {subsection}{\numberline {6.1.4}MoveIt2}{31}{subsection.6.1.4}%
+\contentsline {subsubsection}{\nonumberline Upgrade auf MoveIt2}{31}{subsubsection*.29}%
+\contentsline {subsubsection}{\nonumberline Fehlerhafte Generierung der Roboter}{31}{subsubsection*.31}%
+\contentsline {subsubsection}{\nonumberline Controller}{31}{subsubsection*.33}%
+\contentsline {section}{\numberline {6.2}Lessons Learned bei den Szenarien}{31}{section.6.2}%
+\contentsline {subsection}{\numberline {6.2.1}Debugging}{31}{subsection.6.2.1}%
+\contentsline {chapter}{\numberline {7}Zusammenfassung und Ausblick}{32}{chapter.7}%
+\contentsline {section}{\numberline {7.1}Ergebnisse}{32}{section.7.1}%
+\contentsline {subsection}{\numberline {7.1.1}Graphische Repräsentation der Szenarien}{32}{subsection.7.1.1}%
+\contentsline {subsection}{\numberline {7.1.2}Anpassung der Behavior Trees an Szenarien}{32}{subsection.7.1.2}%
+\contentsline {section}{\numberline {7.2}Diskussion}{32}{section.7.2}%
+\contentsline {section}{\numberline {7.3}Ausblick}{32}{section.7.3}%
+\contentsline {subsection}{\numberline {7.3.1}Umsetzung in anderem Simulator}{32}{subsection.7.3.1}%
+\contentsline {subsection}{\numberline {7.3.2}Simulation bewegter Objekte}{32}{subsection.7.3.2}%
+\contentsline {subsection}{\numberline {7.3.3}Ergänzung von Umgebungserkennung}{33}{subsection.7.3.3}%
+\contentsline {subsection}{\numberline {7.3.4}Zusammenbringen von ActorPlugin und ActorServer}{33}{subsection.7.3.4}%
+\providecommand \tocbasic@end@toc@file {}\tocbasic@end@toc@file 

tex/1_Einleitung.tex

@@ -8,7 +8,7 @@ Diese Prüfung kann durch eine Simulation, in welcher der konkrete Anwendungsfal
 
 Außerdem bietet eine Simulation die Möglichkeit, die Aufgabe des Roboters, ohne dessen Anschaffung, evaluieren zu können.
 Das so gefertigte Modell des Anwendungsfalls könnte später auch als Grundlage für einen digitalen Zwilling dienen.
-Dieser kann später zur Wartung und Fehlerdiagnose des Systems dienen.
+Dieser kann später zur Wartung und Fehlerdiagnose des Systems genutzt werden.
 
 -MRK häufiger ein Thema
 -Anwendungsfälle sollen evaluiert werden
@@ -34,19 +34,30 @@ Aktuelle Arbeiten:
 \url{https://www.researchgate.net/publication/220065749_Human-Robot_Collaboration_a_Survey}
 
 \section{Welche Szenarien}
-Die drei Szenarien sollten so gewählt werden, dass vorher genutzte Bestandteile in späteren, komplexeren Szenarien weiter genutzt werden können.
+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 Manipulation von 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 Szenarien denkbar 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 eines 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.
-Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit bei Annäherung des Menschen.
+Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit bei Annäherung des Menschen, um Kollisionen zu vermeiden.
 
-Bei dem zweiten Szenario soll der Roboter Teile sortieren und auf ein Fließband legen, falls diese weiter genutzt werden können.
+Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide an unterschiedlichen Aufgabe, jedoch im selben Raum, arbeiten.
-Der Mensch muss nun nur noch den Ausschuss beseitigen, welcher vom Roboter in eine besondere Zone gelegt wird.
+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.
+
+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.
 In diesen Fällen muss nun ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
 \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

@@ -1,14 +1,19 @@
 \chapter{Konzept}
 Die zu entwickelnde Simulation soll die bisher meißt separaten Zweige der Roboter- und Menschensimulation verbinden.
-Um die beiden Akteuren in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
+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 von Behavior Trees und Feedback aus der Simulation generiert.
+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.
+Die Beschreibungssprache kommunitziert direkt mit dem simulierten Menschen in der Simulation und der Bewegungsplanung.
+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.
 
 Die zu erarbeitende Softwareumgebung soll einfach erweiterbar sein, um weitere Modifikationen und die Umsetzung anderer Projekte zuzulassen.
 Hierzu zählt die Austauschbarkeit und Erweiterbarkeit von Komponenten wie der simulierten Welt, dem Roboter oder dem simulierten Mensch.
-Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufgebaut.
+Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
 
-\begin{figure}[]
+\begin{figure}
-\includegraphics[]{img/Konzept_Overview}
+\includegraphics{img/MA-Konzept-Übersicht.drawio.pdf}
 \centering
 \caption{Visualisierung des Konzepts}
 \label{concept_overview}
@@ -18,45 +23,80 @@ Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufgebaut.
 Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
 Außerdem ist die enge Interaktion mit Menschen interessant, was einen für Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
 Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, welcher als Cobot vermarktet wird.
-Cobot ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für MRK-Szenarien noch einmal unterstreicht.
+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.
 
 Um den Kuka iisy in der Simulation verwenden zu können, muss ein Modell des Roboterarms erstellt werden.
-Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut wiederspiegeln.
+Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut abbilden.
 Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
 
 \section{Simulation des Menschen}
 Der Mensch soll in der Simulation typische Aufgaben erledigen und häufiges Verhalten abbilden können.
-Hierzu werden Animationen verwendet, welche die aktuelle Tätigkeit darstellen.
+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'' auszuführen.
+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.
 
-Auch hier wird ein Modell der Person für die Simulation benötigt.
+Um diese Animationen erstellen zu können, wird zuerst ein animierbares Modell benötigt.
-Außerdem werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.
+Dieses Modell soll dabei die Möglichkeit bieten, um weitere Animationen erweitert werden zu können.
-Hinzu kommt noch eine Komponente, welche diese Animationen und andere Parameter von außen entgegennehmen kann, um sie in der Simulation ausführen zu können.
+Es werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.
-Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Aktionen im Fortschritt überwacht und abgebrochen werden können.
 
-\section{Behavior Trees}
+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.
-Häufig wird Verhalten in State-Machines ausgedrückt, welche jedoch einige Nachteile besitzen.
+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.
 State-Machines werden ab einer gewissen Größe schnell unübersichtlich.
 Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, welche jedoch essentiell für den Betrieb einer Maschine sind.
-Um diese Probleme zu adressieren, entstand das Konzept der Behavior Trees.
+Um diese Probleme zu adressieren, wurde das Konzept der Behavior Trees entwickelt.
 
 Ein Behavior Tree ist eine Struktur, um Verhalten als ein Baum zu beschreiben.
 Der Ablauf startet vom sogenannten Root, der Wurzel des Baums.
 Von dort an werden sogenannte Nodes, welche je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
 Die Nodes werden untereinander angeordnet, welches die Relation der Nodes zueinander beschreibt.
-Jede Node hat dabei entweder die Root-Node oder eine andere Node über ihr im Baum und eine beliebige Anzahl an Nodes unter sich.
+Jede Node hat dabei entweder die Root-Node oder eine andere Node über sich im Baum und eine beliebige Anzahl an Nodes unter sich.
 Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
 \begin{description}
  \item[Aktions-Nodes]
-  beschreiben einzelne ausführbare Aktionen. Mit Hilfe von Parametern kann ihr Verhalten von anderen Nodes beeinflusst werden.
+  beschreiben einzelne ausführbare Aktionen, die das System beeinflussen können.
  \item[Dekorations-Nodes]
-  können den Rückgabewert einer anderen Node modifizieren. Häufig existieren hier Negation, garantierter Erfolg und garantierter Fehler.
+  können den Rückgabewert einer anderen Node modifizieren.
+  Häufig existieren hier Negation, garantierter Erfolg und garantierter Fehler.
  \item[Sequenz-Nodes]
   beschreiben eine nacheinander ausgeführte Abfolge von anderen Nodes, welche mit spezifischen Randbedingungen weiter fortschreitet.
  \item[Fallback-Nodes]
   werden verwendet, um Verhalten zu definieren, welches nur bei Fehlern in vorherigen Nodes ausgeführt wird.
 \end{description}
 
-In dieser Arbeit sollen BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
+\begin{figure}[]
+\includegraphics[]{img/tree_demo}
+\centering
+\caption{Beispiel eines BehaviorTrees}
+\label{concept_tree_demo}
+\end{figure}
+
+Das in Abbildung \ref{concept_tree_demo} visualisierte Beispiel zeigt die Abfolge, um eine Tür zu öffnen und zu durchschreiten.
+Die Ausführung des Baumes beginnt an der Root-Node.
+Von dort an wird als erstes die Sequenz-Node ausgeführt, welche 3 untergeordnete Nodes besitzt.
+
+Die linke untergeordnete Node wird als erstes ausgeführt, ist jedoch eine weitere Fallback-Node mit weiteren untergeordneten Nodes.
+Diese werden auch von links nach rechts ausgeführt, bis die erste Node ein positives Ergebnis zurück gibt.
+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.
+
+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.
+Diese würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node immer 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.
+
+\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.
+
+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.
+Dies erhöht die Zuverlässigkeit der Umgebung, da alle Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden können.

tex/3_Auswahl.tex

@@ -1,24 +1,44 @@
 \chapter{Komponenten-/Softwareauswahl}
+Die Auswahl der verwendeten Softwarekomponenten ist ein wichtiger Schritt der Entwicklung, da diese Entscheidungen den späteren Entwicklungsprozess nachträglich beeinflussen.
+Hierfür werden Komponenten ausgewählt, welche die im Konzept besprochenen Teilbereiche abdecken und miteinander verbunden werden können.
+
 \section{Dienstumgebung (ROS2)}
-\subsection{Auswahl}
+Die Dienstumgebung bestimmt maßgeblich, wie Software im Entwicklungsprozess geschrieben wird.
-Durch eine Dienstumgebung werden häufig benötigte Funktionen bereitgestellt, welche in Programmen genutzt werden können.
+Durch sie werden häufig benötigte Funktionen bereitgestellt, welche in Programmen in der Umgebung genutzt werden können.
-Dabei ist es irrelevant, ob diese für simulierte, aber auch echte Hardware, genutzt werden.
+
 Bei einer Dienstumgebung für Roboter gehören zu den grundlegendn Aspekten die Nachrichtenübergabe zwischen einzelen interagierenden Programmen, um eine gemeinsame Basis für ein einfach erweiterbares System zu schaffen.
 
+\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.
+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.
+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.
+
+
 In diesem Bereich sticht ROS als Dienstumgebung für Roboter hervor, da es sich um ein etabliertes, quelloffenes und häufig verwendetes System handelt.
 Es bietet die oben genannten Aspekte und einige weitere Verbesserungen, welche später näher beleuchtet werden.
+
 Die neuste Version ROS2 bietet dabei einige Verbesserungen im Vergleich zu früheren Version ROS1.
 Ein neues Nachrichtenformat mit Quality of Service kann zum Beispiel Nachrichten vorhalten und über sowohl TCP als auch UDP kommunizieren.
 Außerdem werden nun neben CMake auch andere Buildsysteme unterstützt, unter anderem auch Python.
 
-Generell existieren im Feld der Roboter-Dienstumgebungen keine Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite, jedoch sind andere Systeme mit anderen Nachrichtenformaten denkbar.
+Generell existieren im Feld der Roboter-Dienstumgebungen keine 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}
 
--Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
+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.
--ROS2
+
--Andere (nur) Messagingsysteme
+
--LCM
+%-Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
--ZeroMQ
+%-ROS2
+%-Andere (nur) Messagingsysteme
+%-LCM
+%-ZeroMQ
 \subsection{Beschreibung}
 ROS2\cite{doi:10.1126/scirobotics.abm6074}, später auch einfach nur ROS genannt, beschreibt sich selbst als ``a meta operating system for robots''\cite{ros-git}.
 Hierbei ist ``operating system'' nicht in seiner herkömmlichen Bedeutung eines vollständigen Betriebssystems zu verstehen.
@@ -57,8 +77,8 @@ Zu den Aufgaben von ROS gehören dabei:
   In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
 \end{description}
 
-
 \section{Simulationsumgebung (Gazebo)}
+
 \subsection{Auswahl}
 Als Simulationsumgebung können verschiedene Programme genutzt werden, welche sich in ihrem Funktionsumfang stak unterscheiden.
 Hierfür kommen dedizierte Werkzeuge zur Robotersimulation, aber auch zum Beispiel universell einsetzbare Gameengines in Frage.
@@ -100,9 +120,31 @@ Aus diesen Funktionen könnte ein Roboterarm aufgebaut werden, welcher dann durc
 
 Die Wahl der Simulationsumgebung fiel auf Gazebo Ignition, da dieser Simulator bereits im ROS-Framework etabliert ist.
 Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschidlichsten Szenarien.
+\subsection{Verwendete Dateiformate}
+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.
+
+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 Welt definiert in Gazebo den kompletten Aubau des Simulators.
+Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten der Simulationsumgebung.
+Außerdem werden alle benötigten Teile der Nutzeroberfläche deklariert, welche im ausgeführten Simulator verfügbar sein sollen.
+Letzendlich können auch mehrere Modelle, Aktoren und Lichter in der Welt definiert werden.
+Diese können auch aus anderen URIs stammen, welche in der Welt deklariert wurden.
+Dies erlaubt das Laden von zum Beispiel vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek\cite{gazebo-app}.
+
+Ein Modell enthält einen Roboter oder ein anderes physikalisches Objekt in der Simulation.
+Die Deklaration eines weiteren Untermodells ist möglich, um komplexere Strukturen abbilden zu können.
+Über ein include-Element können auch andere .sdf-Dateien, welche nur ein Modell enthalten, zum Modell hinzugefügt werden.
+
+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.
+
 
 \subsection{Robotersimulation}
-Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Siimulationsumgebung beschrieben wird.
+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.
 In diesen werden die einzelnen Glieder des Arms und die verbindenden Gelenke beschrieben.
 
@@ -124,11 +166,11 @@ Folgende Typen von Gelenken können in urdf genutzt werden:
  \item[feste Gelenke]
   sperren alle 6 Freiheitsgrade und werden häufig zur Plazierung von Objekten in einer Szene genutzt.
  \item[kontinuierliche Gelenke]
-  erlauben die beliebige Rotation um die Achse des Gelenks. Sie sind nur selten in rotierenden Gelenken mit Schleifkontakten zu finden.
+  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 Verbindungen, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
+  verhalten sich wie kontinuerliche Gelenke, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
  \item[prismatische Gelenke]
-  ermöglichen die Bewegung entlang der Achse des Gelenks. Denkbare Anwendungsfälle sind simulierte lineare Aktuatoren.
+  ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Denkbare Anwendungsfälle sind simulierte lineare Aktuatoren.
 \end{description}
 \subsection{Menschensimulation}
 Gazebo besitzt bereits ein einfaches Animationssystem für bewegliche Aktoren, welches auch für Menschen nutzbar ist.
@@ -137,14 +179,16 @@ Dadurch ist eine Laufanimation realisierbar, welche synchronisiert zur Bewegung
 
 Jedoch ist dies nur unter der Bedingung möglich, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
 Dies ist auf die Definition der Pfade, welche die Bewegung auslösen, zurückzuführen.
-Diese können nur in der .sdf-Datei des Aktoren definiert werden, was Veränderungen zur Laufzeit ausschließt.
+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.
 
-Um diesen Umstand zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
+Um dieses Problem 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.
 
+Ein solches System sollte 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)}
-MoveIt2 ist das empfohlene ROS2 Paket für Bewegungsplanung von Robotern.
+MoveIt 2 ist das empfohlene ROS2 Paket für Bewegungsplanung von Robotern.
 Das System besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
 Der Nutzer kann mit MoveIt auf mehreren Wegen Steuerbefehle für den Roboter absenden.
 
@@ -153,19 +197,140 @@ Dort können Bewegungen durch das Bewegen von Markierungen oder  in der Simulati
 
 Da sich ein solches System nur beschränkt zur Automatisierung durch Software eignet, existieren auch noch andere Schnitstellen.
 Für die Sprache Python existierte früher noch das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, welches aber aktuell noch nicht portiert wurde. \cite{moveitpython}
-Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt auf einer abstrakteren Ebene zu interagieren.
-Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, was jedoch Erfahrung mit den verwendeten Datenstrukturen benötigt.
 
-Durch diese Schnittstelle erhält die sogenannte MoveGroup ihre Informationen über die gewünschte Bewegung.
+Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt auf einer abstrakteren Ebene zu interagieren.
+Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden 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.
+Diese werden über einen RobotStatePublisher an MoveIt übergeben, welches daraus das Robotermodell für die Bewegungsplanung generiert.
+
+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.
 Eine solche Erweiterung erlaubt die Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
 
 Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, welcher durch die MoveGroup aufgerufen wird.
-Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an ros_control weitergegeben.
+Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an \code{ros_control} weitergegeben.
 Dabei können sowohl echte Hardwaretreiber, aber auch simulierte Roboter genutzt werden.
 Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
 
-Im Falle von Gazebo wird ign_ros_control genutzt, welches die benötigten ros_control Controller in die Simulation einbindet.
+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 ros_control genutzt werden.
+Diese können dann wie normale Controller von \code{ros_control} genutzt werden.
 
 Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
+
+\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.
+
+Es existieren aber auch viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen, welche im folgenden vorgestellt werden.
+
+\begin{description}
+  \item[Asynchrone Nodes]
+  sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese im Lebenszyklus der Nodes beim Konzept der Bibliothek mit bedacht wurden.
+  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.
+  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.
+  Diese können dabei sowohl statisch, als auch dynamisch über sogenannte Ports mit Informationen versorgt werden.
+  \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}
+
+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.
+So kann auf feste Parameter in den Nodes selber verzichtet werden, was das erstellen mehrerer Nodes für ähnliche Funktionalitäten verhindert.
+Diese Daten können sowohl aus einem String ausgelesen werden, falls die ensprechende Funktion, welche diese in den Zieltyp übersetzt, implementiert wurde.
+Aber sie können 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.
+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.
+
+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.
+
+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.
+Dies geschieht in in \code{behaviortree_cpp_v3} durch asynchrone Nodes.
+
+Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE auch noch die beiden anderen Zustände RUNNING und IDLE.
+
+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.
+
+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.
+
+\subsection{Dateiformat}
+Das 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.
+Dabei ist zu beachten, dass die Root-Node nicht in der Struktur existiert.
+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}
+\centering
+\caption{Beispiel eines BehaviorTrees}
+\label{choice_tree_demo}
+\end{figure}
+\begin{figure}[hpt]
+\begin{lstlisting}[]
+<?xml version="1.0"?>
+<root main_tree_to_execute="demoTree">
+    <BehaviorTree ID="actorTree">
+        <Sequence>
+            <Fallback>
+                <Action ID="IsDoorOpen"\>
+                <Action ID="OpenDoor"\>
+                <Action ID="BreakDoor"\>
+            </Fallback>
+            <CanWalkThrough\>
+            <WalkThrough\>
+        </Sequence>
+    </BehaviorTree>
+</root>
+\end{lstlisting}
+\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.
+Dadurch wird die Inbetriebnahme von Anwendungen, welche spezielle Umgebungen für ihre Ausführung benötigen, ermöglicht.
+
+Dies wird durch den Einsatz von sogenannten Containern erreicht, welche durch Buildfiles definiert werden.
+Ein Buildfile enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.
+Die so erstellten Container können entweder lokal oder auf einem Server für die Verwendung bereitgehalten werden.
+
+Ein solcher 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.
+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.
+In dieser Datei werden weitere Optionen angegeben, welche in die Umgebung des laufenden Containers eingreifen.
+Dazu gehört zum Beispiel das automatisierte Übergeben von Umgebungsvariablen, Einrichten von Netzwekumgebungen und Erstellen von Volumes und ``bind mounts''.
+
+Diese Automatisierung erleichtert die initiale Einrichtung eines Containers auf einem neuen System, da alle benötigten Aspekte leicht angepasst werden können.

tex/4_Umsetzung.tex

@@ -1,20 +1,89 @@
 \chapter{Umsetzung}
 
-\section{Grundlegender Systemaufbau}
+Bei der Umsetzung des geplanten Systemaufbaus kam es zu mehreren Problemen, welche den geplanten Systemaufbau, sowie dessen Komplexität, negativ beeinflussen.
-Der grundlegende Systemaufbau musste stark modifiziert werden, wie in Abbildung \ref{umsetzung_overview} zu sehen, um die gesetzten Aufgaben erfüllen zu können.
-Dabei fallen vor allem die überarbeitete Kommunikation mit dem simulierten Menschen und die komplexere Steuerung des Roboterarms auf.
 
-Die komplexere Steuerung des Roboters ist auf die Struktur von MoveIt zurückzuführen, welches in viele einzelne Teilmodule aufgeteilt ist.
+Die Kommunikation zwischen dem Actormodell und dem Behavior Tree musste in mehrere Komponenten aufgeteilt werden, um Konflikte innerhalb der Simulationssoftware zu vermeiden.
-Diese müssen durch ihren modularen Aufbau, welcher für die Vielseitigkeit verantwortlich ist, einzeln konfiguriert werden, um miteinander in Interaktion treten zu können.
 
-Außerdem musste die Kommunikation des Modells des Menschen überarbeitet werden, da die ROS-Kommunikation in Gazebo nur mit Einschränkungen möglich ist.
+Zudem ist die Bewegungsplanung mit MoveIt2 deutlich komplexer als vorerst angenommen.
+Diese Komplexität entsteht aus der Interaktion mehrerer Komponenten, welche das Gesamtsystem zur Ausführung benötigt.
+Alle Einzelsysteme mussten hierfür konfiguriert werden, um die Kommunikation dieser zu ermöglichen.
 
-\begin{figure}[]
+Anhand der hier genannten Änderungen wurde die Übersicht des Systems angepasst, welche in Abbildung \ref{umsetzung_overview} zu sehen ist.
-\includegraphics[width=\textwidth]{img/Umsetzung_Overview}
+
+\begin{figure}[h]
+\includegraphics[width=\textwidth]{img/MA-Umsetzung-Übersicht.drawio}
 \centering
 \caption{Visualisierung des überarbeiteten Konzepts}
 \label{umsetzung_overview}
 \end{figure}
+
+\section{Verwendete Datentypen}
+In der Implementation werden unterschiedliche Datentypen verwendet.
+\begin{description}
+  \item[geometry_msgs::msg::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.
+  Dadurch sind zum Beispiel die Koordinaten des Menschen absolut, da diese nicht durch die Welt verschoben und rotiert werden.
+  \item[Area]
+  ist eine Datenstruktur mit einem Vektor an Positionen, welche eine Zone im Zweidimensionalen Raum definieren.
+  Jede Position ist eine einfache Datenstruktur aus 2 Gleitkommazahlen für je die X- und Y-Koordinate der Position.
+  Der Verwendungszweck dieser Struktur ist die einfache Definition von Zonen, welche für Positionsgenerierungen und Postionsabfragen genutzt werden können.
+  \item[ActorPluginState]
+  definiert 4 Werte, welche das ActorPlugin annehmen kann. Diese 4 Werte sind SETUP, IDLE, MOVEMENT und ANIMATION.
+  \item[FeedbackMessage]
+  beschreibt die erste der beiden MessageQueue-Nachrichten, welche vom ActorPlugin an den ActorServer gesendet wird.
+  In dieser Struktur befindet sich der aktuelle Plugin-Zustand als \code{state} Parameter vom Typ ActorPluginState.
+  Außerdem ein \code{progress} Parameter in Form einer Gleitkommazahl, welche den Fortschritt der aktuellen Aktion angibt.
+  Um bei Bewegungen die aktuelle Position des Menschen zu erhalten, ist auch die aktuelle Pose des Modells im Parameter \code{current} enthalten.
+  \item[ActionMessage]
+  ist die andere Nachricht, welche über die zweite MessageQueue vom ActorServer an das ActorPlugin gesendet wird.
+  Wie in der FeedbackMessage ist ein \code{state} Parameter vom selben Typ enthalten, jedoch dient dieser hier als Vorgabe für den nächsten State.
+  Ein \code{animationName} Parameter wird als ein char-Array mit einer maximalen Länge von 255 Zeichen übergeben.
+  Dieser bestimmt später die Animation, welche je nach ActorPluginState während einer Bewegung oder Animation ausgeführt wird.
+  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}
+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.
+
+In diesem Fall handelt es sich um den Raum, in welchem die Interaktion zwischen Mensch und Roboter stattfinden soll.
+Für diesen Raum wurde zuerst ein Raumplan erstellt, welcher alle benötigten Bereiche für die Szenarien besitzt (Abbildung \ref{room-plan}).
+
+Zuerst wird ein Stellplatz für den Roboter benötigt, welcher an einer Ecke des Raumes positioniert werden sollte.
+Diese Position wurde gewählt, um die Verfahrgeschwindigkeit des Roboters höher zu halten, welche je nach Distanz zum Menschen angepasst werden soll.
+
+Des weiteren werden eine Arbeits- und Lagersätte für den Menschen benötigt, welche in den Szenarien genutzt werden sollen.
+Im Koexistenzszenario soll der Mensch nur an diesen Stellen seine Arbeit verrichten, jedoch sich selten dem Roboter nähern, um dessen Fortschritt zu begutachten.
+Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch für die fehlerhaften Teile verwendet werden, welche durch den Roboter aussortiert und durch den Menschen dorthin verbracht werden sollen.
+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.
+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.
+Hierfür 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}
+\end{minipage}
+\hspace{.1\textwidth}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Umsetzung-Welt-Blender}
+\centering
+\caption{Umsetzung in Blender}
+\label{roomfinished}
+\end{minipage}
+\end{figure}
+
 \section{Mensch}
 \subsection{Übersicht}
 Das angepasste Verfahren zur Menschensteuerung in der Simulation verwendet mehrere Kommunikationswege.
@@ -107,7 +176,23 @@ Die neuere Implementation der POSIX MessageQueue bietet einige weitere Funktione
 Die ausgewählte Implementation ist die neuere POSIX-Implementation einer Message Queue, da diese basierend auf den Erfahrungen mit der System V Implementation verbessert wurde.
 \subsubsection{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 beiden ActionServer definieren jeweils 3 Nachrichten, welche eine Startnachricht, das Feedback während der Laufzeit und eine Endnachricht beschreiben.
+Sie sind absichtlich nicht in den nutzenden Paketen untergebracht, da sie durch ein externes Programm in den entsprechenden Code umgewandelt werden.
+
+Jede Action definiert 3 Nachrichten, welche zu unterschiedlichen Zeitpunkten in ihrer Ausführung verwendet werden.
+Die definierten Nachrichten sind eine Startnachricht, eine Feedbacknachricht und eine Endnachricht.
+
+Ein ActionServer 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 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.
@@ -117,24 +202,12 @@ Dabei ist es Aufgabe des Programms, diese in beliebigen Abständen an den Client
 
 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{ActorServer}
-Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin.
-Es werden zwei ActionServer angeboten, welche jeweils Bewegungen oder Animationen des simulierten Menschen auslösen können.
-Beide ActionServer prüfen zuerst, ob bereits eine andere Aktion ausgeführt wird.
-Sollte dies der Fall sein, wird die Anfrage abgelehnt.
-Im anderen Fall wird die Aufgabe akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
-Hier kommt es zu einer forcierten Warteschleife, welche die Bestätigung der Aktion vom ActorPlugin in der Feedback-Queue wartet, um das Starten mehrerer gleichzeitiger Aktionen zu unterbinden.
-Parallel werden alle eingehenden Feedback-Nachrichten der Message Queue des ActorPlugins in Feedback für die aktuell laufende Action umgewandelt.
 
-Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
+\subsubsection{ActorPlugin}
-Zuerst werden Animationsname und -diztanz benötigt, um die richtige Animation auszuwählen und die Bewegung mit der Animation zu synchronisieren.
+Das ActorPlugin nutzt die empfangenen Nachrichten aus der eingehenden Message Queue, um diese in der Simulation umzusetzen.
-Als Feedbacknachricht erhält der Client die aktuelle Pose des Actors im Simulationsraum.
+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.
 
-Soll eine Animation über den Action Server abgespielt werden, wird auch hier ein Animationsname, jedoch auch eine Animationsgeschwindigkeit benötigt.
+Das Plugin erhält durch die empfangenen Nachrichten mehrere Zustände, welche im folgenden erläutert werden:
-Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl.
-\subsubsection{Gazebo Plugin}
-Das ActorPlugin nutzt die Daten aus der Message Queue für Befehle, um diese in der Simulation umzusetzen.
-Es werden dabei mehrere Zustände unterschieden.
 \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.
@@ -151,21 +224,59 @@ Es werden dabei mehrere Zustände unterschieden.
   ist der Zustand, welcher nach erfolgreicher Ausführung eines Befehls angenommen wird.
 \end{description}
 
-Das ActorPlugin besitzt kein Konzept des ActionServers und verlässt sich auf den ActorServer, welcher die Feedbacknachrichten in das richtige Format bringt.
+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 jedem Simulationsschritt gesendet.
+Feedback wird in den Zuständen Movement und Animation in eine zweiten Message Queue zu jedem Simulationsschritt gesendet.
-Um auch Zustandsübergänge erkennen zu können, werden auch diese als Feedback an den ActorServer 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.
+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.
+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.
+Hierzu wird ein Mutex verwendet, welcher die Auswertung neuer Nachrichten verhindert, so lange der aktuelle Befehl noch nicht durch das Plugin bestätigt wurde.
+Parallel werden alle eingehenden Feedback-Nachrichten der Message Queue des ActorPlugins in Feedback für die aktuell laufende Action umgewandelt.
+
+Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
+Zuerst werden Animationsname und -diztanz benötigt, um die richtige Animation auszuwählen und die Bewegung mit der Animation zu synchronisieren.
+Als Feedbacknachricht erhält der Client die aktuelle Pose des Actors im Simulationsraum.
+
+Soll eine Animation über den Action Server abgespielt werden, wird auch hier ein Animationsname, jedoch auch eine Animationsgeschwindigkeit benötigt.
+Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl.
 \section{Roboter}
 \subsection{Übersicht}
+Der Roboter besteht aus vielen interagierenden Systemen, welche in ihrer Gesamtheit das vollständige Robotermodell in der Simulation verwendbar machen.
+
+Zuerst muss ein Modell des Roboters erstellt werden, welches in Gazebo geladen werden kann.
+Dieses Modell muss dann für die Bewegungsplanung mit MoveIt erweitert werden.
+Hierbei werden Controller von ros_control mit dem Modell verbunden, um den aktuellen Zustand der Achsen zu überwachen und diese steuern zu können.
+
+Um diese Vielfalt an Daten standartisiert an andere Software in ROS weitergeben zu können, wird eine MoveGroup in ROS gestartet, welche die Planung von Bewegungen durch andere Programme zulässt.
 \subsection{Modellierung}
 Für den Kuka LBR iisy existiert kein Simulationsmodell für Gazebo und ROS, weswegen dieses Modell aus Herstellerdaten generiert wurden.
-Die Maße und Form des Roboters wurden aus einer .stl-Datei des Arms generiert.
+Hierzu stand eine .stl-Datei des Herstellers zur Verfügung.
+Aus dieser Datei wurden mit FreeCAD\cite{freecad} alle Glieder des Roboters als Collada-Dateien exportiert.
+Dabei muss darauf geachtet werden, dass die exportierten Daten eine ausreichende Meshgröße haben, welche vorher in FreeCAD eingestellt werden muss.
+Dies erlaubt das Erhalten der feinen Strukturen des Arms, auch visualisiert in Abbildung \ref{robot_raw}, welche erst später in Blender reduziert werden sollen.
 
-Diese Datei wurde dazu in die unterschidlichen Glieder aufgeteilt, welche danach in Blender weiter bearbeitet wurden.
+\begin{figure}[]
-Hiebei wurde die hohe Auflösung der Modelle reduziert, was sich in kleineren Dateien und Startzeiten der Simulation, aber auch in der Renderzeit der Simulation, auswirkt.
+\includegraphics[width=\textwidth/2]{img/MA-Roboter-Rohdaten}
+\centering
+\caption{Rohdaten aus .stl-Datei}
+\label{robot_raw}
+\end{figure}
+
+Diese Dateien können dann in Blender bearbeitet werden, um sie für die Simulation tauglich zu machen.
+Hierfür wurde die hohe Auflösung der Modelle reduziert, was sich in kleineren Dateien und Startzeiten der Simulation, aber auch in der Renderzeit der Simulation, auswirkt.
 Außerdem wuden die Glieder so ausgerichtet, dass der Verbindungspunkt zum vorherigen Glied im Nullpunkt des Koordinatensystems befindet.
+Das vollständige visuelle Modell ist in Abbildung \ref{robot_visual} zu sehen.
 
 Um die Simulation weiter zu beschleunigen, wurden die Kollisionsboxen des Arms noch weiter vereinfacht, was die Kollisionsüberprüfung dramatisch beschleunigt.
 Dabei werden stark simplifizierte Formen verwendet, welche das hochqualitative visuelle Modell mit einfachen Formen umfassen.
+Das resultierende Modell, welches in Abbildung \ref{robot_collision} dargestellt wird, wird später zur Kollisionserkennung verwendet.
 
 Diese Herangehensweise ist nötig, da Kollisionserkennung auf der CPU durchgeführt wird, welche durch komplexe Formen stark verlangsamt wird.
 
@@ -177,49 +288,149 @@ Die Gelenkpositionen sind dabei relative Angaben, welche sich auf das Glied bezi
 Alle kontrollierbaren Gelenke benötigen auch eine Gelenkachse, welche je nach Gelenktyp die mögliche Beweglichkeit bestimmt.
 
 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}
+\includegraphics[width=\textwidth]{img/MA-Roboter-Visuell}
+\centering
+\caption{Visuelles Modell}
+\label{robot_visual}
+\end{minipage}
+\begin{minipage}{.5\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Roboter-Kollision}
+\centering
+\caption{Kollisionsmodell}
+\label{robot_collision}
+\end{minipage}
+\end{figure}
 \subsection{MoveIt 2 Konfiguration}
 Das somit erstellte Paket kann nun mit dem neu implementierten MoveIt Configurator um die benötigten Kontrollstrukturen erweitert werden.
+Dazu wurde der neue Setupassistent von MoveIt2 verwendet, welcher das Modell analysiert, um es mit für MoveIt benötigten Parameter zu erweitert.
+
+Die Erstellung des erweiterten Modells mit dem Assistenten funktionierte komplett fehlerfrei, jedoch ließen sich die generierten Dateien nicht nutzen.
+
+Um die generierten Dateien nutzen zu können, mussten diese weiter angepasst werden.
+Dies beinhaltete die korrekte Integration der Roboterdefinitionen im Paket, aber auch zahlreiche Pfadreferenzen auf verwendete Dateien, welche nicht korrekt generiert wurden.
+Diese können standartmäßig nicht in Gazebo, RViz und MoveGroup gleichzeitig geladen werden, da diese Programme unterschiedliche Pfadangaben verlangen, was die Nutzung verhindert.
+
+Eine Möglichkeit zur Lösung des Problems ist die Verwendung von \code{file://}-URIs, welche von allen dieser Programme gelesen werden können.
+Jedoch ist hier als Nachteil zu verzeichnen, dass der Moveit Setup Assistent diese URIs nicht lesen kann, was zu Fehlern bei einer Rekonfiguration führen kann.
+
+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}
 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.
 Das Modell kann dabei über Argumente im Raum verschoben und rotiert werden, falls diese Funktionalität benötigt wird.
 
-Im Modell sind auch die verwendeten Gazebo-Plugins deklariert, welche für die Integration mit dem \code{ros_control} verantwortlich sind.
+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_trees} organisert, welche durch das Paket \code{btree_nodes} gelesen werden.
+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.
-BehaviorTrees werden in \code{behaviortree_cpp_v3} als .xml-Dateien gespeichert.
-Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeschnittstellen.
 
-Solche Schnittstellen können verwendet werden, um Nodes generischer gestalten zu können.
-So kann auf feste Parameter in den Nodes selber verzichtet werden, was das erstellen mehrerer Nodes für ähnliche Funktionalitäten verhindert.
-Diese Daten können sowohl aus einem String ausgelesen werden, falls die ensprechende Funktion, welche diese in den Zieltyp übersetzt, implementiert wurde.
-Aber sie können 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.
+Für die Umsetzung des Szenarios wurden neue Nodes für den BehaviorTree erstellt.
-Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeichert.
+Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
-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.
 
-Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Nodes als sogenannte SubTrees abspeichern.
+\subsubsection{Allgemein nutzbare Nodes}
-Diese bilden dann in ihrer Gesamtheit eine neue Node, welche im BehaviorTree eingesetzt werden kann.
+\begin{description}
-Um den Einsatz von Variablen innerhalb eines SubTrees zu ermöglichen, besitzt jeder SubTree ein separates Blackboard.
+  \item[GenerateXYPose]
-Dadurch kann ein Eingriff in äußere Funktionalität verhindert werden.
+  generiert eine Pose in einem durch den \code{area} Parameter angegebenen Bereich.
+  Um dies zu ermöglichen, wird zuerst die Fläche aller Dreiecke berechnet, welche den Bereich definieren.
+  Diese werden durch den Gesamtinhalt geteilt, um eine Wichtung der Dreiecke zum Gesamtinhalt zu erreichen.
+  Nun wird eine Zufallszahl zwischen 0 und 1 gebildet.
+  Von dieser werden nun die Wichtungen der Dreiecke abgezogen, bis dies Zufallszahl im nächsten abzuziehenden Dreieck liegt.
+  Nun wird in diesem Dreieck eine zufällige Position ermittelt, welche ber den Ausgabeparameter \code{pose} ausgegeben wird.
+  \item[InAreaTest]
+  prüft, ob eine Pose, vorgegeben durch den \code{pose} Parameter, in einer durch den \code{area} Parameter definierten Zone liegt.
+  Hierfür wird überprüft, ob die X und Y-Werte der Pose in einem der Dreiecke liegen, welche die Area definieren.
+  Der Rückgabewert ist das Ergebnis dieser Überprüfung, wobei SUCCESS bedeutet, dass sich die Pose in der Area befindet.
+  \item[OffsetPose]
+  wird genuzt, um eine Pose im Raum zu bewegen und/oder deren Orientierung zu verändern.
+  Falls der \code{offset} Parameter gesetzt ist, wird dieser mit dem \code{input} Parameter summiert.
+  Außerdem wird die Orientierung der Pose auf den \code{orientation} Parameter gesetzt, falls dieser vorhanden ist, was den ursprünglichen Wert überschreibt.
+  \item[InterruptableSequence]
+  stellt eine Sequence dar, welche auch nach ihrem Abbruch ihre Position behält.
+  Dies ist von Nöten, wenn bestimmtes Verhalten unterbrechbar ist, aber zu einem späteren Zeitpunkt fortgesetzt werden soll.
+  Hierzu wird der Iterator der unterlegenden Sequenz nur erhöht, wenn die untergeordnete Node SUCCESS zurück gibt.
+  Außerdem wird der Iterator nicht zurückgesetzt, wenn die Ausführung dieser modifizierten Sequenz abgebrochen wird.
+  \item[WeightedRandom]
+  ist eine Steuerungsnode, welche mehrere untergeordnete Nodes besitzt.
+  Dabei werden diese nicht, wie bei anderen Steuerungsnodes üblich, sequentiell ausgeführt.
+  Anhand einer vorgegebenen Wichtung im \code{weights} Parameter wird eine der untergeordneten Nodes zufällig ausgewählt.
+  Diese Node wird nun als einzige Node ausgeführt, bis diese den SUCCESS-Status zurück gibt.
+  Nach dem dieser Status erreicht wurde, wird bei dem nächsten Durchlauf eine neue Node ausgewählt.
+  Der Rückgabewert ist der Rückgabewert der ausgewählten untergeorneten Node.
+  \item[IsCalled]
+  fragt den aktuellen Called-Status des Actors ab, welcher in einigen Szenarien vom Roboter verwendet wird, um den simulierten Menschen zu rufen.
+  Der Rückgabewert der Node ist dabei SUCCESS, falls der Mensch gerufen wird, oder FAILURE, wenn kein RUF durchgeführt wird.
+  \item[SetCalledTo]
+  setzt den aktuellen Called-Status auf den Wert des übergebenen \code{state} Parameters.
+  Da diese Aktion nicht fehlschlagen kann, liefert diese Node immer SUCCESS als Rückgabewert.
+  \item[RandomFailure]
+  generiert eine Zufallszahl von 0 bis 1, welche mit dem \code{failure_chance} Parameter verglichen wird.
+  Der Rückgabewert ist das Ergebnis des Vergleichs, FAILURE, wenn die Zufallszahl kleiner als der \code{failure_chance} Parameter ist, oder im anderen Falle SUCCESS.
+\end{description}
 
-Natürlich sollte es auch möglich sein, Variablen an solche SubTrees zu übergeben.
+\subsubsection{Menschenspezifisch}
-Diese können, wie auch bei normalen Nodes, einfach als Parameter an den SubTree übergeben werden.
+\begin{description}
-Die Bibliothek \code{behaviortree_cpp_v3} verbindet dann diese Werte und erlaubt die Datenübergabe zu und von dem SubTree.
+  \item[ActorAnimation]
+  wird verwendet, um dem simulierten Menschen eine auszuführende Animation zu senden.
+  Die Node benötigt zur Ausführung einen Animationsname, welcher im \code{animation_name} Parameter angegeben wird.
+  Ein optionaler \code{animation_speed} Parameter gibt die Ausführungsgeschwindigkeit vor.
+  Der Rückgabewert ist SUCCESS, wenn die komplette Ausführung gelang, oder FAILURE, falls diese abgebrochen oder abgelehnt wurde.
+  \item[ActorMovement]
+  funktioniert wie eine ActorAnimation, sendet jedoch eine Bewegungsanfrage.
+  Auch für diese wird ein Animationsname benötigt, 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.
+  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.
+\end{description}
 
-\subsection{Asynchrone Nodes}
+\subsubsection{Roboterspezifisch}
-Da nicht jeder Prozess in einem einzigen Durchlauf des BehaviorTrees abgebildet werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
+\begin{description}
-Dies geschieht in in \code{behaviortree_cpp_v3} durch asynchrone Nodes.
+  \item[RobotMove] gibt dem Roboter eine neue Zielposition über den \code{target} Parameter vor.
+  Bei dieser Node handelt es sich um eine asynchrone Node, welche nur bei der erfolgreiche Ausführung der Bewegung SUCCESS zurück gibt.
+  \item[SetRobotVelocity] setzt eine neue maximale Geschwindigkeit des Roboters, vorgegeben durch den \code{velocity} Parameter.
+  Der Rückgabewert ist immer SUCCESS.
+\end{description}
+Diese beiden roboterspezifischen Nodes beeinflussen im Hintergrund das gleiche System, da Bewegungen bei Geschwindigkeitsänderungen neu geplant und ausgeführt werden müssen.
+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.
 
-Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE auch noch die beiden anderen Zustände RUNNING und IDLE.
+\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.
 
-Der Zustand RUNNING steht dabei für eine Node, welche sich noch in der Ausführung befindet.
+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.
-So lang dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand abgefragt.
+Um diese Modifikiationen trotzdem reproduzierbar zu machen, wurde ein Shellscript geschrieben, welches zum Starten des Containers verwendet wird.
 
-Der IDLE-Zustand ist ein besonderer Zustand, welcher nur durch eine vollständige Ausführung erreichbar ist.
+Dieses Skript erstellt zuerst die benötigten Verzeichnisse für den Container, falls diese noch nicht existieren.
-Er wird von der Node angenommen, nachdem ein RUNNING Zustand durch entweder SUCCESS oder FAILURE beendet wurde und darf sonst nicht verwendet werden.
+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.