Changes up to 27.06

.kile/mechforsch.kilepr.gui

@@ -67,6 +67,15 @@ Indentation Mode=normal
 Mode=LaTeX
 Mode Set By User=false
 
+[document-settings,item:tex/5_Evaluation_und_Diskussion.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
+
 [document-settings,item:tex/Einleitung.tex]
 Bookmarks=
 Encoding=UTF-8
@@ -78,7 +87,7 @@ Mode Set By User=false
 
 [item:main.bib]
 open=true
-order=5
+order=6
 
 [item:main.tex]
 open=true
@@ -104,6 +113,10 @@ order=3
 open=true
 order=4
 
+[item:tex/5_Evaluation_und_Diskussion.tex]
+open=true
+order=5
+
 [view-settings,view=0,item:Einleitung.tex]
 CursorColumn=0
 CursorLine=0
@@ -113,24 +126,24 @@ TextFolding={"checksum":"","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.bib]
-CursorColumn=1
+CursorColumn=20
-CursorLine=231
+CursorLine=108
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"cf8b2614fde9a70da69bd9296f0dc1ae50c584e2","ranges":[]}
+TextFolding={"checksum":"7dd721e78f3a584f245ca717d88453d9d1888b82","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
-CursorColumn=89
+CursorColumn=32
-CursorLine=117
+CursorLine=26
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"5c50dc53ef39690810318af01f4ba4d3cb14fab0","ranges":[]}
+TextFolding={"checksum":"19a710817310e6ac5ce296cc7073fcf7cdc1cc55","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/1_Einleitung.tex]
-CursorColumn=78
+CursorColumn=0
-CursorLine=61
+CursorLine=22
 Dynamic Word Wrap=false
 JumpList=
 TextFolding={"checksum":"578f69b0ffbc27d095768d7a3111120650ffd5d0","ranges":[]}
@@ -138,26 +151,34 @@ ViMarks=
 
 [view-settings,view=0,item:tex/2_Konzept.tex]
 CursorColumn=0
-CursorLine=36
+CursorLine=8
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"3273e70036fa23cebeead6b7a47fc2014926bdf5","ranges":[]}
+TextFolding={"checksum":"a590f5cb77a9b42aa1d412e8c60088086c2e8f81","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/3_Auswahl.tex]
-CursorColumn=9
+CursorColumn=107
-CursorLine=161
+CursorLine=273
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"ee9b56159ddf3293cde4120dfc5d90bbd2f0759a","ranges":[]}
+TextFolding={"checksum":"860366adcb7dc59b870dcd7c34c98c68b581d6d0","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/4_Umsetzung.tex]
-CursorColumn=113
+CursorColumn=0
-CursorLine=127
+CursorLine=428
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"2172161d77c4b318d98d968032cce683727b0108","ranges":[]}
+TextFolding={"checksum":"6678e5fe5aa540fc73ddc9fc5e763f132f521e9f","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:tex/5_Evaluation_und_Diskussion.tex]
+CursorColumn=0
+CursorLine=59
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"618c3dd623e4798cc57536a05b4dd83a099ea683","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/Einleitung.tex]

main.bib

@@ -276,3 +276,9 @@ doi = {https://doi.org/10.1201/9780429489105}
   url = {https://gazebosim.org/api/gazebo/2.10/createsystemplugins.html},
   note = {letzter Zugriff 01.06.2023},
 }
+
+@misc{changesRosII,
+  title = {Changes between ROS 1 and ROS 2},
+  url = {http://design.ros2.org/articles/changes.html},
+  note = {letzter Zugriff 25.06.2023},
+}

main.out.ps

@@ -2,301 +2,3 @@
 /pdfmark where{pop}
 {/globaldict where{pop globaldict}{userdict}ifelse/pdfmark/cleartomark load put}
 ifelse
-[
-/Title(\376\377\000E\000i\000n\000l\000e\000i\000t\000u\000n\000g)
-/Count -4
-/Action/GoTo/Dest(chapter.1)cvn
-/OUT pdfmark
-[
-/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 -4
-/Action/GoTo/Dest(chapter.2)cvn
-/OUT pdfmark
-[
-/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\000\040\000a\000l\000s\000\040\000B\000e\000s\000c\000h\000r\000e\000i\000b\000u\000n\000g\000s\000s\000p\000r\000a\000c\000h\000e)
-/Action/GoTo/Dest(section.2.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000V\000i\000r\000t\000u\000a\000l\000i\000s\000i\000e\000r\000u\000n\000g\000s\000u\000m\000g\000e\000b\000u\000n\000g\000\040\000a\000l\000s\000\040\000P\000l\000a\000t\000f\000o\000r\000m)
-/Action/GoTo/Dest(section.2.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000K\000o\000m\000p\000o\000n\000e\000n\000t\000e\000n\000-\000/\000S\000o\000f\000t\000w\000a\000r\000e\000a\000u\000s\000w\000a\000h\000l)
-/Count -6
-/Action/GoTo/Dest(chapter.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000D\000i\000e\000n\000s\000t\000u\000m\000g\000e\000b\000u\000n\000g)
-/Count -2
-/Action/GoTo/Dest(section.3.1)cvn
-/OUT pdfmark
-[
-/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\000s\000c\000h\000r\000e\000i\000b\000u\000n\000g)
-/Action/GoTo/Dest(subsection.3.1.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000s\000u\000m\000g\000e\000b\000u\000n\000g\000\040\000\050\000G\000a\000z\000e\000b\000o\000\051)
-/Count -4
-/Action/GoTo/Dest(section.3.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000A\000u\000s\000w\000a\000h\000l)
-/Action/GoTo/Dest(subsection.3.2.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000W\000e\000l\000t\000-\000\040\000u\000n\000d\000\040\000M\000o\000d\000e\000l\000l\000b\000e\000s\000c\000h\000r\000e\000i\000b\000u\000n\000g)
-/Action/GoTo/Dest(subsection.3.2.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000R\000o\000b\000o\000t\000e\000r\000s\000i\000m\000u\000l\000a\000t\000i\000o\000n)
-/Action/GoTo/Dest(subsection.3.2.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000M\000e\000n\000s\000c\000h\000e\000n\000s\000i\000m\000u\000l\000a\000t\000i\000o\000n)
-/Action/GoTo/Dest(subsection.3.2.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000R\000o\000b\000o\000t\000e\000r\000u\000m\000g\000e\000b\000u\000n\000g)
-/Action/GoTo/Dest(section.3.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000P\000r\000o\000g\000r\000a\000m\000m\000i\000e\000r\000s\000p\000r\000a\000c\000h\000e)
-/Action/GoTo/Dest(section.3.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
-/Count -2
-/Action/GoTo/Dest(section.3.5)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000A\000s\000y\000n\000c\000h\000r\000o\000n\000e\000\040\000N\000o\000d\000e\000s)
-/Action/GoTo/Dest(subsection.3.5.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000D\000a\000t\000e\000i\000f\000o\000r\000m\000a\000t)
-/Action/GoTo/Dest(subsection.3.5.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000D\000o\000c\000k\000e\000r\000-\000C\000o\000m\000p\000o\000s\000e\000\040\000a\000l\000s\000\040\000V\000i\000r\000t\000u\000a\000l\000i\000s\000i\000e\000r\000u\000n\000g\000s\000u\000m\000g\000e\000b\000u\000n\000g)
-/Action/GoTo/Dest(section.3.6)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000U\000m\000s\000e\000t\000z\000u\000n\000g)
-/Count -7
-/Action/GoTo/Dest(chapter.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000D\000o\000c\000k\000e\000r\000-\000C\000o\000m\000p\000o\000s\000e)
-/Action/GoTo/Dest(section.4.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000E\000n\000t\000w\000i\000c\000k\000l\000u\000n\000g\000s\000u\000m\000g\000e\000b\000u\000n\000g)
-/Action/GoTo/Dest(section.4.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000V\000e\000r\000w\000e\000n\000d\000e\000t\000e\000\040\000D\000a\000t\000e\000n\000t\000y\000p\000e\000n)
-/Action/GoTo/Dest(section.4.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000s\000w\000e\000l\000t)
-/Action/GoTo/Dest(section.4.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000M\000e\000n\000s\000c\000h)
-/Count -4
-/Action/GoTo/Dest(section.4.5)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000\334\000b\000e\000r\000s\000i\000c\000h\000t)
-/Action/GoTo/Dest(subsection.4.5.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000M\000o\000d\000e\000l\000l\000i\000e\000r\000u\000n\000g)
-/Action/GoTo/Dest(subsection.4.5.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000E\000x\000p\000o\000r\000t\000\040\000d\000e\000r\000\040\000M\000o\000d\000e\000l\000l\000a\000n\000i\000m\000a\000t\000i\000o\000n\000e\000n)
-/Action/GoTo/Dest(subsection.4.5.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000P\000r\000o\000g\000r\000a\000m\000m\000i\000e\000r\000u\000n\000g)
-/Action/GoTo/Dest(subsection.4.5.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000R\000o\000b\000o\000t\000e\000r)
-/Count -4
-/Action/GoTo/Dest(section.4.6)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000\334\000b\000e\000r\000s\000i\000c\000h\000t)
-/Action/GoTo/Dest(subsection.4.6.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000M\000o\000d\000e\000l\000l\000i\000e\000r\000u\000n\000g)
-/Action/GoTo/Dest(subsection.4.6.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000M\000o\000v\000e\000I\000t\000\040\0002\000\040\000K\000o\000n\000f\000i\000g\000u\000r\000a\000t\000i\000o\000n)
-/Action/GoTo/Dest(subsection.4.6.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000I\000n\000t\000e\000g\000r\000a\000t\000i\000o\000n\000\040\000m\000i\000t\000\040\000G\000a\000z\000e\000b\000o)
-/Action/GoTo/Dest(subsection.4.6.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
-/Count -3
-/Action/GoTo/Dest(section.4.7)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000S\000u\000b\000t\000r\000e\000e\000s)
-/Action/GoTo/Dest(subsection.4.7.1)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000V\000e\000r\000h\000a\000l\000t\000e\000n\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000s)
-/Action/GoTo/Dest(subsection.4.7.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000V\000e\000r\000h\000a\000l\000t\000e\000n\000\040\000d\000e\000s\000\040\000M\000e\000n\000s\000c\000h\000e\000n)
-/Action/GoTo/Dest(subsection.4.7.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000S\000z\000e\000n\000a\000r\000i\000e\000n\000b\000a\000s\000i\000e\000r\000t\000e\000\040\000E\000v\000a\000l\000u\000a\000t\000i\000o\000n)
-/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 -5
-/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\000E\000r\000w\000e\000i\000t\000e\000r\000u\000n\000g\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000m\000o\000d\000e\000l\000l\000s\000\040\000m\000i\000t\000\040\000M\000o\000v\000e\000I\000t)
-/Action/GoTo/Dest(subsection.6.1.2)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000G\000a\000z\000e\000b\000o)
-/Action/GoTo/Dest(subsection.6.1.3)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000R\000O\000S\0002)
-/Action/GoTo/Dest(subsection.6.1.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000M\000o\000v\000e\000I\000t\0002)
-/Action/GoTo/Dest(subsection.6.1.5)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000L\000e\000s\000s\000o\000n\000s\000\040\000L\000e\000a\000r\000n\000e\000d\000\040\000b\000e\000i\000\040\000d\000e\000n\000\040\000S\000z\000e\000n\000a\000r\000i\000e\000n)
-/Count -1
-/Action/GoTo/Dest(section.6.2)cvn
-/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 -5
-/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
-[
-/Title(\376\377\000Z\000u\000s\000a\000m\000m\000e\000n\000b\000r\000i\000n\000g\000e\000n\000\040\000v\000o\000n\000\040\000A\000c\000t\000o\000r\000P\000l\000u\000g\000i\000n\000\040\000u\000n\000d\000\040\000A\000c\000t\000o\000r\000S\000e\000r\000v\000e\000r)
-/Action/GoTo/Dest(subsection.7.3.4)cvn
-/OUT pdfmark
-[
-/Title(\376\377\000S\000e\000p\000a\000r\000i\000e\000r\000e\000n\000\040\000d\000e\000r\000\040\000S\000u\000b\000t\000r\000e\000e\000s\000\040\000i\000n\000\040\000e\000i\000g\000e\000n\000e\000\040\000D\000a\000t\000e\000i\000e\000n)
-/Action/GoTo/Dest(subsection.7.3.5)cvn
-/OUT pdfmark

main.tex

@@ -8,34 +8,37 @@ parskip=half,
 \usepackage[ngerman]{babel}
 \usepackage[T1]{fontenc}
 \usepackage{lmodern}
-\usepackage{minted}
+\usepackage[newfloat=true]{minted}
 \usepackage{csquotes}
 \usepackage[includehead, includefoot, left=3.0cm, right=2.5cm, top=1.5cm, bottom=1.5cm]{geometry}
 \usepackage{acro}
-\usepackage[style=numeric,backend=biber]{biblatex}
+\usepackage[style=numeric,backend=biber,sorting=none]{biblatex}
+\usepackage{notoccite}
 \usepackage{pdfpages}
-\usepackage{scrhack}
 \usepackage{xcolor}
 \usepackage{enumitem}
+\usepackage[onehalfspacing]{setspace}
 \usepackage{hyperref}
 \usepackage{tabularray}
 \usepackage{xurl}
 \usepackage{soul}
 \usepackage{xcolor}
-\usepackage{inconsolata}
 \usepackage{subcaption}
-
 \usepackage[strings]{underscore}
 
+
 \usepackage[letterspace=150]{microtype}
-\usepackage[onehalfspacing]{setspace}
+
 \usepackage[page]{totalcount}
 \usepackage[automark,headsepline=.4pt,plainheadsepline]{scrlayer-scrpage}         % Erstellung von selbst definierten Kopfzeilen
+%\usepackage{scrhack}
+
+\newcommand{\source}[1]{\caption*{Quelle: {#1}} }
+
 \clearpairofpagestyles%\clearscrheadfoot veraltet
 \renewcommand*{\chaptermarkformat}{
   \chaptername~\thechapter\autodot\quad-\quad
 }
-
 \definecolor{light-gray}{gray}{0.95}
 %\newcommand{\code}[1]{\colorbox{light-gray}{\texttt{#1}}}
 \newcommand{\code}[1]{
@@ -92,122 +95,13 @@ parskip=half,
 
 \setcounter{page}{1}
 \pagenumbering{arabic}
-
 \input{tex/1_Einleitung.tex}
 \input{tex/2_Konzept.tex}
 \input{tex/3_Auswahl.tex}
 \input{tex/4_Umsetzung.tex}
+\input{tex/5_Evaluation_und_Diskussion.tex}
 
-\chapter{Szenarienbasierte Evaluation}
+\chapter{Ausblick}
-\section{Simulation des Menschen}
--Animationen und Bewegungen funktionieren
-
--Kollisionen möglich, aber mit Animationen schwer zu synchronisieren
-\section{Bewegung des Roboters}
--Roboter kann sich bewegen
-
--Kollisionen verfügbar
-
--Interaktion technisch möglich, nicht implementiert. (Kooperation MoveIt/Gazebo nötig)
-\section{BehaviorTrees}
-\subsection{Nodes}
--Nodes für implementierte Funktionen verfügbar
-
--Einige andere, technisch relevante Nodes auch implementiert
-\subsection{Kombinieren von Nodes zu einer Request}
--MoveIt Planung benötigt mehrere Parameter, sollen aber in einzelnen Nodes gesetzt werden
-
--Kombination nötig, Beschreibung hier
-\chapter{Diskussion}
-\section{Lessons Learned bei der Umsetzung}
--Viele kleine Unannehmlichkeiten, kombiniert ein großes Problemen
-
--Dokumentation für spätere Projekte
-\subsection{Erstellung des Robotermodells}
--Keine direkten technischen Daten zum Roboter von Kuka
-
--Nur CAD-Dateien der Außenhülle
-
--Schätzung von Spezifikationen anhand Marketingmaterial
-\subsection{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, die sich jedoch grundlegend unterscheiden.
-Ein altes Projekt mit dem früheren Namen Gazebo, dass nun in Gazebo Classic umbenannt wurde,
-die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
-die nächste Version, die nur noch den Namen Gazebo tragen soll.
-Dies ist darauf zurückzuführen, dass Gazebo Classic und Ignition eine Zeit lang gleichzeitig existierten, jedoch unterschiedliche Funktionen und interne Schnittstellen besitzen.
-
-Das Upgrade von Gazebo Classic auf Gazebo Ignition gestaltete sich aus mehreren Gründen schwierig.
-Dies ist am leichtesten an der geänderten Nutzeroberfläche sichtbar, die in Ignition nun modular ausgeführt ist.
-Um dieses neue modulare System nutzen zu können, wurde das Dateiformat für die Simulationen angepasst.
-In diesem werden die benötigten Physikparameter, Nutzeroberflächen, Plugins und die Simulationswelt definiert.
-
-Um alte Simulationsdateien zu migieren, empfiehlt sich die Erstellung einer neuen, leeren Welt in Gazebo Ignition,
-sodass alle benötigten Physik, Nuteroberflächen und Pluginreferenzen erstellt werden.
-Danach kann die Welt Stück für Stück in das neue Format übertragen werden, wobei nach jedem Eintrag ein Test zur Funktionsfähigkeit gemacht werden sollte, da sich bestimmte Parameterdeklarationen geändert haben.
-Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler während des Ladevorgangs im Log nicht weiter beschrieben werden.
-
-Auch das alte Plugin musste auf das neue System angepasst werden, was auch hier zu einer kompletten Neuimplementation führte, da die internen Systeme zu große Unterschiede aufwiesen.
-Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, die auf ein Entity-Component-System umstellte, aber auch Veränderungen an den verwendeten Objekten innerhalb dieses Systems.
-\subsubsection{Pluginarchitektur}
-Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
-Jedoch existiert damit jedes Plugin im selben Prozess, was bei der Nutzung von Bibliotheken, die nicht für die mehrfache Nutzung im selben Prozess entsprechend ausgelegt wurden, zu Problemen führen kann.
-
-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, dass ü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, dass 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, die dann von den Plugins genutzt werden kann.
-  Dies könnte als ein Plugin realisiert werden, dass 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, die 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.
-
-\subsubsection{Fehlende Animationsgrundlagen}
--Animationen werden als .col bereitgestellt
-
--Enthalten Textur, Mesh und Bones, jedoch nicht verbunden -> schlecht für Animation
-\subsection{ROS2}
-\subsubsection{Nachrichten und deren Echtzeitfähigkeit}
--TCP und UDP verfügbar, jedoch nicht sofort kompatibel
-\subsubsection{Änderung der Compilertoolchain}
--Änderung des Buildsystems von rosbuild auf catkin
-
--Benötigte Änderungen in CMakeFile und package
-\subsection{MoveIt2}
-\subsubsection{Upgrade auf MoveIt2}
--Unterschiede in der Deklaration des Roboters selbst
-
--Änderungen der Deklaration der ros\_control Anbindung
-
--Vorerst kein Setup, manuelle Migration erforderlich
-
-->Lesson learned: Projekte häufig auf Updates prüfen
-\subsubsection{Fehlerhafte Generierung der Roboter}
--Einige Aspekte der Generierung nicht erforderlich oder falsch
-\subsubsection{Controller}
--Controller benötigte Anpassungen und manuelle Tests
-\section{Lessons Learned bei den Szenarien}
-\subsection{Debugging}
--async tty Option
-
--gdb ist ein Muss
-
--``Aufhängen'' von trees
-\chapter{Zusammenfassung und Ausblick}
 \section{Ergebnisse}
 \subsection{Graphische Repräsentation der Szenarien}
 -Szenarien graphisch abgebildet
@@ -248,7 +142,9 @@ Natürlich ist die Einführung eines weiteren Nachrichtendienstes ein Bruch der
 \markboth{Anhang}{Anhang}
 \begin{figure}[ht]
 \includegraphics[width=14cm]{img/moveit_pipeline}
-\caption{Visualisierung der MoveIt Pipeline \protect \cite{moveitpipeline}}
+\caption{Visualisierung der MoveIt Pipeline}
+\source{\cite{moveitpipeline}}
 \label{moveitpipeline}
 \end{figure}
+
 \end{document}          

mechforsch.kilepr

@@ -59,3 +59,9 @@ archive=true
 encoding=UTF-8
 highlight=LaTeX
 mode=LaTeX
+
+[item:tex/5_Evaluation_und_Diskussion.tex]
+archive=true
+encoding=UTF-8
+highlight=LaTeX
+mode=LaTeX

tex/2_Konzept.tex

@@ -83,8 +83,8 @@ Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unters
   Ein Fehler wird hier zurückgegeben, wenn alle Nodes ohne eine Erfolgsmeldung durchlaufen wurden.
 \end{description}
 
-\begin{figure}[]
+\begin{figure}
-\includegraphics[]{img/tree_demo}
+\includegraphics[]{img/MA-tree-demo}
 \centering
 \caption{Beispiel eines BehaviorTrees}
 \label{concept_tree_demo}

tex/3_Auswahl.tex

@@ -1,9 +1,8 @@
 \chapter{Komponenten-/Softwareauswahl}
-Die Auswahl der verwendeten Softwarekomponenten ist ein wichtiger Schritt der Entwicklung.
+Die Auswahl der verwendeten Softwarekomponenten ist ein wichtiger Schritt in der Entwicklung.
-Diese Entscheidungen beeinflussen die späteren Entwicklungsprozess nachhaltig.
+Die Festlegung auf eine Komponente beeinflusst den späteren Entwicklungsprozess nachhaltig.
 
-Im nachfolgenden findet die Auswahl der Komponenten statt.
+Alle Komponenten sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
-Diese sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
 Alle diese Teilbereiche können dann zu einer Simulation vebunden werden, die das gesamte Problemfeld abdeckt.
 
 Wie bereits in Abbildung \ref{concept_overview} dargestellt, ist für die Erfüllung der Aufgaben eine Dienst- und eine Simulationsumgebung erforderlich.
@@ -12,18 +11,18 @@ Dieses Kapitel beschreibt die Auswahl der Umgebungen und der in diesen laufenden
 Die Dienstumgebung bestimmt maßgeblich, wie Software im Entwicklungsprozess geschrieben wird.
 Durch sie werden häufig benötigte Funktionen bereitgestellt, die Programme innerhalb der Umgebung nutzen können.
 
-Bei einer Dienstumgebung für Roboter gehört die Nachrichtenübergabe zwischen einzelen Programmen zu den grundlegenden Aspekten.
+Bei einer Dienstumgebung für Roboter gehört die Nachrichtenübergabe zwischen den einzelnen Programmen zu den grundlegenden Aspekten.
 Diese wird genutzt, um eine gemeinsame Basis für ein erweiterbares System zu schaffen.
-Außerdem sind Werkzeuge zur Einstellungsübergabe an Teilsysteme sinnvoll, um diese an einer Stelle anpassen zu können.
+Außerdem sind Werkzeuge zur Einstellungsübergabe an Teilsysteme sinnvoll, um die Einstellungen an einer Stelle gesammelt anpassen zu können.
 
 \subsection{Auswahl}
 Es existieren mehrere Systeme, die als Dienstumgebung für Roboter in Frage kommen, wenn es lediglich um die Nachrichtenübergabe zwischen Programmen geht.
-Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist ein potentieller Kanidat für ein Roboterframework.
+Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist potentiell als ein Roboterframework einsetzbar.
 
 Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition der Nachrichten, die über das System ausgetauscht werden.
 
 Nutzbare, bereits als Interprozesskommunikation integrierte Systeme sind zum Beispiel Pipes, die Daten zwischen Prozessen über Buffer austauschen.
-Auch die Nutzung von Message Queues und Shared Memory ist hierfür denkbar.
+Auch die Nutzung von Message Queues oder Shared Memory ist für diesen Einsatzzweck möglich.
 Diese Systeme sind performant, jedoch schwerer zu verwalten.
 Ein Problem dieser Methoden ist die direkte Kommunikation mehrerer Komponenen.
 Diese Art der Kommunikation sieht keine Modifikation von Nachrichten zur Anpassung an andere Szenarien vor.
@@ -35,16 +34,16 @@ Die Kommunikation zwischen Client und Server ist bidirektional möglich, was kom
 Alle diese Lösungen besitzen einen gemeinsamen Nachteil in deren Nachrichtendefinition.
 Dieser Nachteil besteht in der potentiellen Variabilität dieser Kommunikationsmechanismen.
 Bei einem ausreichend großen Projekt treten so unweigerlich Unterschiede in der Handhabung von Nachrichten auf, die es zu berücksichtigen gilt.
-Durch solche Unterschiede kann es zu inkompatibilitäten zwischen Programmen kommen, was sich auf die universelle Nutzbarkeit der Programme negativ auswirkt.
+Durch solche Unterschiede kann es zu Inkompatibilitäten zwischen Programmen kommen, was sich auf die universelle Nutzbarkeit der Programme negativ auswirkt.
 
-In diesem Bereich sticht ROS\cite{doi:10.1126/scirobotics.abm6074} als Dienstumgebung für Roboter hervor, da es sich um ein etabliertes und quelloffenes System handelt.
+In diesem Bereich ist ROS\cite{doi:10.1126/scirobotics.abm6074} als Dienstumgebung für Roboter bekannt, da es sich um ein etabliertes und quelloffenes System handelt.
-Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standartisierte und erweiterbare Nachrichtendefinition gelöst, die von den Programmen in der Umgebung genutzt werden.
+Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standardisierte und erweiterbare Nachrichtendefinition gelöst, die von den Programmen in der Umgebung genutzt werden.
-Um diese Nachrichten zu senden und empfangen liefert ROS eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
+Um diese Nachrichten senden und empfangen zu können, liefert ROS eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
-Für zum Beispiel Python\cite{python}, C und C++\cite{cpp} existieren die Implementationen in den Paketen \code{rospy}, \code{rclc} und \code{rclcpp}.
+Für zum Beispiel Python\cite{python}, C und C++\cite{cpp} existieren entsprechende Implementationen in den Paketen \code{rospy}, \code{rclc} und \code{rclcpp}.
 
-Die neuste Version ROS2 bietet dabei einige Verbesserungen im Vergleich zu früheren Version ROS1.
+Die neuste Version ROS2 bietet dabei mehrere Verbesserungen im Vergleich zu früheren Version ROS1 \cite{changesRosII}.
-Ein neues Nachrichtenformat mit Quality of Service kann zum Beispiel Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
+Ein neues Nachrichtenformat mit Quality of Service kann beispielsweise Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
-Außerdem werden nun neben CMake\cite{cmake} auch andere Buildsysteme unterstützt, was zum Beispiel die Verwendung von Python erlaubt.
+Außerdem werden nun neben CMake\cite{cmake} auch andere Buildsysteme unterstützt, was die Verwendung von Python erlaubt.
 
 Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
 Vor allem die unzähligen ROS-Bibliotheken, die von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
@@ -74,17 +73,17 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
   Jedes Paket enthält dabei eine \code{package.xml}-Datei.
   In dieser befindet sich eine in XML verfasste Definition des Paketinhalts, die verschiedene Aspekte des Pakets beschreibt.
 
-  Darunter fallen Informationen über den das Paket selbt, wie dessen Name, Beschreibung und Version.
+  Darunter fallen Informationen über das Paket selbst, wie dessen Name, Beschreibung und Version.
   Außerdem sind Name und Mailadresse des Autors, sowie die gewählte Lizenz des Codes vermerkt.
-  Um das Paket später korrekt ausführen zu können, sind benötigte Pakete für den Kompiliervorgang und Ausführung des Pakets eingetragen.
+  Um das Paket später korrekt ausführen zu können, sind benötigte Pakete für den Kompiliervorgang und die Ausführung des Pakets eingetragen.
 
  \item[Buildumgebung]\hfill \\
   ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
   Zu deren Konfiguration wird eine \code{CMakeLists.txt}-Datei erstellt, die den Buildprozess beschreibt.
-  In dieser sind die Buildinstruktionen für den Kompiler für die im Paket befindlichen Programme enthalten.
+  In dieser sind die Buildinstruktionen für den Kompiler enhalten, mit welchen die im Paket befindlichen Programme kompiliert werden können.
   Der Aufruf des \code{ament_cmake}-Makros in dieser ergänzt den Kompiliervorgang um weitere Parameter aus der \code{package.xml}-Datei.
 
-  Nach diesen Vorbereitungsschritten kann CMake das Paket kompillieren.
+  Nach diesen Vorbereitungsschritten kann CMake das Paket kompilieren.
   Hierbei werden alle in der \code{CMakeLists.txt}-Datei angegebenen Programmteile kompiliert.
 
   Es ist außerdem möglich, bestimmte Pfade des Pakets nach dem Buildvorgang zu exportieren.
@@ -92,11 +91,11 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
 
  \item[Workspaceverwaltung]\hfill \\
   Gruppen von Paketen befinden sich in sogenannen ``Workspaces''.
-  Diese vereinfachen das auffinden der enthaltenen Pakete durch Skripte, die diese im System registrieren.
+  Diese vereinfachen das Auffinden der enthaltenen Pakete durch Skripte, die diese im System registrieren.
   Die Erstellung der Skripte erfolgt anhand der bereits beschriebenen \code{CMakeLists.txt}-Datei.
   Das Programm \code{colcon} analysiert diese und generiert die Skripte.
   Um das Paket im System zu registrieren, muss der Nutzer die generierten Skripte ausführen, was die benötigten Umgebungsvariablen setzt.
-  Hierfür wird meißt ein weiteres Skript verwendet, was alle im Workspace befindlichen Pakete nacheinander der Umgebung hinzufügt.
+  Hierfür wird meist ein weiteres Skript verwendet, was alle im Workspace befindlichen Pakete nacheinander der Umgebung hinzufügt.
 
   Dieser Vorgang erlaubt zum Beispiel das Auffinden von Paketen anhand deren Namen im Dateisystem.
   Das erleichtert die Verwaltung durch die Unabhängigkeit von spezifischen Pfaden im entwickelten System.
@@ -107,7 +106,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
   Die generierten Warnungen bei fehlenden Paketen vermeiden Abstürze und undefiniertes Verhalten in der Ausführung von Nodes, die diese benötigen.
 
  \item[Datenübertragung]\hfill \\
-  Um Daten zwischen Nodes austauschen zu können, müssen sie miteinander auf einem festgelegten Weg kommunizieren können.
+  Um Daten zwischen Nodes austauschen zu können, müssen die Nodes miteinander auf einem festgelegten Weg kommunizieren können.
   Ein solcher Aufbau erlaubt den Austausch von Daten in vorher nicht durch die Entwickler bedachten Anwendungsfällen.
   Die von ROS gebotene Schnittstelle zur Datenübertragung wird in Form mehrerer Bibliotheken für unterschiedliche Programmiersprachen bereitgestellt.
 
@@ -204,7 +203,7 @@ Jedes Modell wird über eine Translation und Rotation im Simulationsraum veranke
 Dies geschieht immer relativ zum Referenzsystem des überliegenden Modells.
 Außerdem können im Modell Einstellungen für dessen Physiksimulation vorgenommen werden.
 
-Ein Modell enhält meißt mindestens ein Link-Element, dass zur Darstellung von dessen Geometrie verwendet wird.
+Ein Modell enhält meist mindestens ein Link-Element, dass zur Darstellung von dessen Geometrie verwendet wird.
 Mehrere Link-Elemente können dabei mit der Welt oder anderen Link-Elementen über Joint-Elemente verbunden werden.
 Diese Joint-Elemente können jedoch nicht von außerhalb gesteuert werden, was dieses Dateiformat ungeeignet für Roboterdefinitionen macht.
 
@@ -347,7 +346,7 @@ Es existieren aber auch viele Beispiele und eine gute Dokumentation über die er
   Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, die aktuell ausführende Aktionen beeinflussen können.
   Darunter fällt die Modifizierung von Parametern der Aktionen, aber auch der vollständige Abbruch einer Aktion durch äußere Einflüsse.
   \item[Das .xml-Format der Behavior Trees] ermöglicht einen Austausch des Verhaltens, ohne die unterliegende Programme verändern zu müssen.
-  Dies ist vor allem in kompilierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompillierung bedürfen, was die Iterationszeit für Änderungen verbessert.
+  Dies ist vor allem in kompilierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompilierung bedürfen, was die Iterationszeit für Änderungen verbessert.
   \item[Plugins] können zum Start geladen werden, um weitere Nodes dem ausgeführten Programm hinzufügen zu können.
   Dies vereinfacht die Erweiterung um neue Funktionen und das mehrfachen Nutzen von Code.
   \item[Das Blackboard] ist eine Interaktionsebene, die den Datenfluss zwischen den Nodes erlaubt.
@@ -414,7 +413,7 @@ Die resultierende Datei ist in Abbildung \ref{choice_tree_xml} abgebildet.
 Dabei ist zu beachten, dass die Root-Node nicht in der Struktur existiert, da diese nur den Eintrittspunkt in die Struktur darstellt.
 Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber auch über den Namen Action mit ihrem Namen als ID-Parameter, referenziert werden.
 \begin{figure}[hpt]
-\includegraphics[width=\textwidth]{img/tree_demo}
+\includegraphics[width=\textwidth]{img/MA-tree-demo}
 \centering
 \caption{Beispiel eines BehaviorTrees}
 \label{choice_tree_demo}

tex/4_Umsetzung.tex

@@ -10,7 +10,7 @@ Alle Einzelsysteme mussten hierfür konfiguriert werden, um die Kommunikation di
 
 Anhand der hier genannten Änderungen wurde die Übersicht des Systems angepasst, die in Abbildung \ref{umsetzung_overview} zu sehen ist.
 
-\begin{figure}[h]
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-Umsetzung-Übersicht.drawio}
 \centering
 \caption{Visualisierung des überarbeiteten Konzepts}
@@ -75,7 +75,7 @@ Ein Texteditor ist für das Schreiben von ROS-Packages ausreichend und bietet be
 Das Editieren von Dateien ist mit einem Texteditor auch von außerhalb des Containers möglich.
 Jedoch besitzt ein Texteditor nur wenige Funktionen einer vollständigen Entwicklungsumgebung, die den Prozess der Softwareentwicklung beschleunigen.
 Um diese Funktionen bieten zu können, analysieren Entwicklungsumgebungen den geschriebenen Code.
-Dies geschieht meißt auf eine von zwei unterschiedlichen Weisen.
+Dies geschieht meist auf eine von zwei unterschiedlichen Weisen.
 
 Die Entwicklungsumgebung kann eine interne Repräsentation des geschriebenen Codes generieren.
 Diese Repräsentation kann nun genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen.
@@ -103,7 +103,7 @@ Dazu wurden dem Container die benötigten LSP-Server hinzugefügt und konfigurie
 Unter Verwendung dieser neuen Server kann Lapce nun Codevervollständigung und Codeanalyse wie PyCharm und CLion durchführen.
 Dabei wird auch der Ressourcenverbrauch gesenkt, da nur ein einziger Editor benötigt wird.
 
-\begin{figure}[hpt]
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-Umsetzung-Lapce}
 \centering
 \caption{Entwicklungsumgebung Lapce}
@@ -163,7 +163,7 @@ Das Förderband erhält ein eigenes Modell in einer weiteren Datei, die zur Lauf
 Für beide wird, wie später auch für den Roboter selbst, das Paket \code{ros_gz_sim} verwendet.
 Dieses veranlasst mit dem \code{create}-Programm das Erstellen der übergebenen Datenstruktur in Gazebo.
 
-\begin{figure}[hpt]
+\begin{figure}
 \begin{minipage}{.45\textwidth}
 \includegraphics[width=\textwidth]{img/MA-Umsetzung-Welt-Plan.drawio}
 \centering
@@ -224,7 +224,7 @@ Deswegen muss bei der Platzierung darauf geachtet werden, dass der Startpunkt A
 Der Verbindungspunkt B der beiden Knochen wird nun vorerst auf dieser Gerade platziert.
 Dieser muss nun senkrecht zu dieser Gerade und der gewünschten Biegeachse verschoben werden, wie in Abbildung \ref{bend} gezeigt.
 
-\begin{figure}[hpt]
+\begin{figure}
 \begin{minipage}{.45\textwidth}
 \includegraphics[width=\textwidth]{img/MA-Umsetzung-Person-Bones}
 \centering
@@ -240,7 +240,7 @@ Dieser muss nun senkrecht zu dieser Gerade und der gewünschten Biegeachse versc
 \end{minipage}
 \end{figure}
 
-\begin{figure}[hpt]
+\begin{figure}
 \includegraphics[width=.8\textwidth]{img/MA-Umsetzung-Joint}
 \centering
 \caption{Visualisierung der generierten Beugeachse}
@@ -315,7 +315,7 @@ Nun muss im mit 5 markierten Animations-Reiter noch eine letzte Einstellung vorg
 Die mit 6 markierte Einstellung bewirkt, dass alle Bewegungen der exportierten Knochen mit gespeichert werden, auch wenn diese sich nicht bewegen.
 Da sich einige Knochen nur am Anfang der Animation in einer bestimmten Pose befinden, exportiert Blender diese nicht, was in Gazebo zu verdrehten Knochen führt.
 
-\begin{figure}[hpt]
+\begin{figure}
 \begin{subfigure}[b]{\textwidth}
 \includegraphics[width=.5\textwidth]{img/MA-Umsetzung-Animation-Prepare}%
 \hfill
@@ -325,7 +325,7 @@ Da sich einige Knochen nur am Anfang der Animation in einer bestimmten Pose befi
 \label{export-prepare}
 \end{figure}
 
-\begin{figure}[hpt]
+\begin{figure}
 \begin{subfigure}[b]{\textwidth}
 \includegraphics[height=.50\linewidth]{img/MA-Umsetzung-Animation-Save}%
 \hfill
@@ -417,6 +417,32 @@ Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT z
 
 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 dem Feedback- und Endnachrichten an den Client gesendet werden können.
+
+Die gesamte Kommunikation einer Anfrage verläuft wie in Abbildung \ref{plugin_sequence} dargestellt.
+Zuerst wird durch den Client eine Zielvorgabe an den Server gesendet.
+Sollte der Server diese abweisen, wird die Kommunikation beendet.
+Dies geschieht, falls bereits eine Aktion ausgeführt wird.
+
+Falls keine Aktion ausgeführt wird, beginnt die Kommunikation mit dem ActorPlugin.
+Das Plugin erhält die Zielinformationen und seinen neuen Status aus der Zielvorgabe des Clients über die MessageQueue.
+Der Server wartet den Zustandswechsel des Plugins ab und bestätigt dem Client die Ausführung der Zielanfrage.
+
+Ab diesem Zeitpunkt ist eine Terminierung der Anfrage durch den Client möglich.
+Dies geschieht durch eine Abbruchanfrage, welche sofort bearbeitet wird.
+Für den Abbruch wird der Status des Plugins über die MessageQueue auf IDLE gesetzt, was alle laufenden Aktionen sofort beendet.
+Der Zustandswechsel des Plugins wird abgewartet, um bei erreichen des IDLE-Zustands die Abbruchanfrage zu bestätigen.
+
+Solange die Aktion läuft, werden periodisch Feedbacknachrichten über die MessageQueue an den Server gesendet.
+Der Server bringt diese in ein neues Format und leitet sie an den Client weiter.
+
+Wenn das Ziel erreicht wird, wechselt das Plugin eigenständig in den IDLE-Zustand, was vom Server durch eine Feedbacknachricht erkannt wird.
+Dieser Zustandswechsel löst die Meldung einer vollständigen Ausführung des gewünschten Befehls an den Client aus.
+\begin{figure}
+\includegraphics[width=\textwidth]{uml/out/plugin_connectivity.eps}
+\caption{Kommunikation des ActorPlugins}
+\label{plugin_sequence}
+\end{figure}
+
 \subsubsection{ActorPlugin}
 Das ActorPlugin steuert anhand von empfangenen Nachrichten aus der eingehenden Message Queue den Menschen in der Simulationsumgebung.
 Der Code des Plugins ist dabei im Paket \code{ign_actor_plugin} organisiert, dass im Gazebo-Modell der Welt referenziert werden muss, um das Plugin zu laden.
@@ -508,7 +534,7 @@ Dies verursacht eine Beschleunigung oder verlangsamung der Ausführung.
 Nach jedem Update-Schritt wird eine Feedback-Nachricht gesendet, die den aktuellen Fortschritt der Animation enthält.
 Wurde die Animation vollständig durchlaufen, wird der Zustand des ActorPlugins auf Idle gesetzt.
 
-\begin{figure}[hpt]
+\begin{figure}
 \includegraphics[width=\textwidth]{uml/out/plugin_states.eps}
 \caption{Zustandsübergänge im ActorPlugin}
 \label{plugin_states}
@@ -529,6 +555,7 @@ Wenn sowohl die Zielrotation ausgeführt wurde und die Beine wieder in Ausgangsl
 Das ActorPlugin besitzt kein Konzept eines ROS-ActionServers und verlässt sich auf den ActorServer, der die Feedbacknachrichten in das richtige Format bringt.
 Feedback wird in den Zuständen Movement und Animation in eine zweiten Message Queue zu jedem Simulationsschritt gesendet.
 Um Zustandsübergänge erkennen zu können, werden auch diese als Feedback an den ActorServer gesendet.
+
 \subsubsection{ActorServer}
 Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin.
 Er ist als das Programm \code{ros_actor_action_server} im gleichnamigen Paket enthalten.
@@ -570,7 +597,7 @@ Durch diese Einstellung bleiben feine Strukturen erhalten, die später in Blende
 Ein solches Vorgehen erlaubt es Blender, bessere Entscheidungen über die Reduktion von Strukturen zu treffen.
 Das Resultat ist ein besseres Endmodell des Roboters.
 
-\begin{figure}[]
+\begin{figure}
 \includegraphics[width=\textwidth/2]{img/MA-Roboter-Rohdaten}
 \centering
 \caption{Rohdaten aus .stl-Datei}
@@ -584,7 +611,7 @@ 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, die 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.
+Das resultierende Modell, dass 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, die durch komplexe Formen stark verlangsamt wird.
 
@@ -596,7 +623,7 @@ Die Gelenkpositionen sind dabei relative Angaben, die sich auf das Glied beziehe
 Alle kontrollierbaren Gelenke benötigen auch eine Gelenkachse, die 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{figure}
 \begin{minipage}{.49\textwidth}
 \includegraphics[width=\textwidth]{img/MA-Roboter-Visuell}
 \centering
@@ -727,7 +754,7 @@ Dies wird durch zwei Animations-Nodes mit entsprechenden Parametern gesteuert.
 Die Ausführung der Nodes dieser Gesamtaktion soll Sequenziell erfolgen, weshalb die Nodes unterhalb einer Sequence-Node gruppiert werden.
 Der vollständige resultierende Baum ist in Abbildung \ref{subtree_work} visualisiert.
 
-\begin{figure}[]
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-subtree-work}
 \centering
 \caption{BehaviorTree für das Arbeiten an der Werkbank}
@@ -751,7 +778,7 @@ Für die beiden Fälle werden auch Sequenz-Nodes genutzt, da die Aktionen nachei
 Die beiden zufälligen Auswahlverfahren werden durch eine Sequenz verbunden.
 Der resultierende Ablauf wurde als Baum in Abbildung \ref{subtree_deposit} visualisiert.
 
-\begin{figure}[]
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-subtree-deposit}
 \centering
 \caption{BehaviorTree für das Ablegen von Objekten im Schrank}
@@ -782,32 +809,131 @@ Sonst wird die Geschwindigkeit wieder auf 100\% erhöht.
 Nach dieser Sequenz kann der spezifische Teil für die gewünschte Applikation hinzugefügt werden.
 In Abbildung \ref{tree_base_robot} wurde dies durch eine Wolke repräsentiert.
 
-\begin{figure}[]
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-tree-base-robot}
 \centering
-\caption{BehaviorTree für das Ablegen von Objekten im Schrank}
+\caption{Grundlegender BehaviorTree des Roboters}
 \label{tree_base_robot}
 \end{figure}
 
-\begin{figure}[]
+Im ersten Szenario, der Koexistenz zwischen Mensch und Roboter, soll eine Arbeitsaufgabe durch den Roboter allein simuliert werden.
+Hierfür soll der Roboter Objekte von der rechten auf die linke Tischseite transportieren.
+Alle Nodes werden einer ReactiveSequence untergeordnet, um bei Unterbrechungen durch den Mensch den Fortschritt der Aktion behalten zu können.
+Mit einer GenerateXYPose-Node wird zuerst ein Ziel auf der linken Tischseite generiert.
+Dieses Ziel befindet sich auf dem Boden, und muss auf die Tischebene angehoben werden.
+Das Anheben wird durch eine OffsetPose-Node realisiert.
+Mit einer RobotMove-Node wird nun die Bewegung zum generierten Zielpunkt ausgeführt.
+Dies geschieht auf gleichem Weg für die rechte Tischseite.
+Der vollständige Baum ist in Abbildung \ref{tree_robot_coex} zu sehen.
+
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-tree-robot-coex}
 \centering
-\caption{BehaviorTree für das Ablegen von Objekten im Schrank}
+\caption{Erweiterter BehaviorTree des Roboters bei Koexistenz }
-\label{tree_base_robot}
+\label{tree_robot_coex}
 \end{figure}
 
-\begin{figure}[]
+Im Kooperationsszenario wird der Ablauf des ersten Szenarios modifiziert.
+Nach der Bewegung zu einem Objekt auf der linken Tischseite wird eine zufällige Entscheidung getroffen.
+Mit einer Chance von 90\% ist das Objekt den Anforderungen gerecht, und kann durch den Roboter auf ein Förderband gelegt werden.
+Im anderen Fall soll das Objekt auf den rechten Tisch gelegt werden.
+Von dort aus soll der Mensch dieses Objekt abholen, um den Ausschuss im Regal zu verstauen.
+Es wird dafür die gleiche Operationsabfolge aus dem ersten Szenario verwendet.
+Am Ende der übernommenen Sequenz wird eine SetCalledTo-Node ergänzt, die den Menschen ruft.
+
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-tree-robot-coop}
 \centering
 \caption{BehaviorTree für das Ablegen von Objekten im Schrank}
-\label{tree_base_robot}
+\label{tree_robot_coop}
 \end{figure}
 
-\begin{figure}[]
+Für das dritte Szenario soll der Roboter mit dem Menschen kollaborieren.
+Um dieses Szenario umzusetzen, wird ein weiteres Mal das erste Szenario modifiziert.
+Hier soll der Roboter eine Palette ausladen, wobei es durch die Beschaffenheit der Objekte zu Fehlern kommen kann.
+Dies wird durch das Hinzufügen mehrerer RandomFailure-Nodes erreicht, welche die Sequenz abbrechen können.
+Da diese Probleme durch den Menschen behoben werden sollen, muss ein Mechanismus geschaffen werden, um diesen zu rufen.
+Hierfür wird eine Fallback-Node über der InterruptableSequence angeordnet.
+Diese Fallback-Node führt im Fall eines Fehlers in der InterruptableSequence die nächste Node aus.
+Bei dieser handelt es sich um eine SetCalledTo-Node, welche den Menschen ruft.
+
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-tree-robot-colab}
 \centering
 \caption{BehaviorTree für das Ablegen von Objekten im Schrank}
-\label{tree_base_robot}
+\label{tree_base_colab}
 \end{figure}
 
 \subsection{Verhalten des Menschen}
+
+Im ersten Szenario soll der Mensch nur neben dem Roboter arbeiten.
+Um das Verhalten des Roboters trotzdem zu prüfen, soll der Mensch selten die Sicherheitszone betreten, um den Roboter zu überwachen.
+Dies wird durch eine WeightedRandom-Node erreicht, die mit 95 prozentiger Wahrscheinlichkeit den normalen Arbeitsvorgang ausführt.
+Im anderen Zweig wird mit einer Wahrscheinlichkeit von 5\% eine Bewegung in die Sicherheitszone ausgelöst.
+
+Der normale Arbeitsvorgang ist ein linearer Ablauf und wird von einer Sequence-Node repräsentiert.
+In dieser werden nacheinander die beiden Subtrees ``WorkOnBench'' und ``DepositToShelf'' ausgeführt.
+Das Bewegen in die Sicherheitszone wird auch durch eine Sequence-Node erreicht.
+Diese enthält eine GenerateXYPose-Node, um ein Ziel in der Sicherheitszone auszuwählen und eine ActorMovement-Node, um die Bewegung auszulösen.
+
+\begin{figure}
+\includegraphics[width=\textwidth]{img/MA-tree-actor-coex}
+\centering
+\caption{BehaviorTree des Menschen bei Koexistenz }
+\label{tree_actor_coex}
+\end{figure}
+
+Für das Kooperationsszenario wird diese Abfolge durch eine weitere, übergeordnete Sequence-Node ergänzt.
+Diese wurde ausgewählt, da ein Ruf durch den Roboter in diesem Szenario nicht zeitkritisch ist.
+Eine solche Implementation erlaubt das vollständige Ausführen der vorgehenden Aufgabe.
+In dieser hinzugefügten Sequence-Node wird die nötige Funktionalität für das Abholen der aussortierten Objekte implementiert.
+Dies erfolgt nach einer AmICalled-Node, welche die Sequence vorzeitig beendet, falls der Mensch nicht gerufen wurde.
+Das vorzeitige Beenden führt zu einer erneuten Auswahl zwischen Arbeit und Inspektion.
+Sollte der Mensch jedoch durch den Roboter gerufen werden, wird die Sequence weiter ausgeführt.
+
+In diese Fall soll der Mensch das Objekt vom rechten Tisch abholen und in das Regal legen.
+Dies erfolgt durch eine ActorMovement-Node, welche den Mensch zum rechten Tisch bewegt.
+Nach dieser werden zwei ActorAnimation-Nodes ausgeführt, welche die Animationen ``standing_extend_arm'' und ``standing_retract_arm'' durchführen.
+Dies simuliert den Griff auf den Tisch, um das Objekt aufzuheben.
+Um das Objekt im Schrank zu verstauen, wird der bereits definierte Subtree ``DepositToShelf'' genutzt.
+
+
+\begin{figure}
+\includegraphics[width=\textwidth]{img/MA-tree-actor-coop}
+\centering
+\caption{BehaviorTree des Menschen bei Kooperation }
+\label{tree_actor_coop}
+\end{figure}
+
+Für das letzte Szenario soll der Mensch dem Roboter beim Entladen einer Palette assistieren.
+Falls der Mensch nicht vom Roboter gerufen wird, soll dieser im Raum herumwandern.
+Für die festlegung einer Baumstruktur ist es wichtig, ob der Mensch sofort, oder erst nach vollenden seiner Arbeit dem Roboter zu Hilfe kommt.
+In diesem Fall soll er seine Arbeit unterbrechen, um auch diese Möglichkeit zu demonstrieren.
+
+Ein solches Verhalten lässt sich mit Hilfe einer Fallback- mit untergeordneter ReactiveSequence-Node modellieren.
+In der ReactiveSequence wird zuerst überprüft, ob der Mensch gerufen wurde.
+Da dieser Zustand die ReactiveSequence abbrechen soll, wird die verantwortliche AmICalled-Node mit einer Inverter-Node versehen.
+In der ReactiveSequence kann nun eine weitere Sequence nach der Inverter-Node angeornet werden.
+
+Diese enthält den Teil des Baumes, der ausgeführt werden soll, solange der Mensch nicht gerufen wird.
+In diesem Fall wird mit einer WeightedRandom-Node eine von drei GenerateXYPose-Nodes ausgewählt.
+Diese geben jeweils Ziele in der sicheren Zone, Warnzone und Sicherheitszone zurück.
+Nach der WeightedRandom-Node wird eine ActorMovement-Node genutzt, welche den Mensch zu dem ausgewählen Ziel bewegt.
+
+Neben der ReactiveSequence unter der Fallback-Node wird eine weitere Sequence angeordnet.
+Hier wird die gewünschte Aktionsfolge bei Ruf durch den Roboter definiert.
+In diesem Fall soll das Aufheben eines heruntergefallenen Objekts durchgeführt werden.
+Dazu wird zuerst ein Ziel in der Warnzone unter Zuhilfenahme einer GenerateXYPose-Node generiert.
+Nach einer Bewegung zu diesem Ziel durch eine ActorMovement-Node wir ein Objekt aufgehoben.
+Dies geschieht durch vier ActorAnimation-Nodes, welche jeweils die Animationen ``standing_to_low'', ``low_inspect'', ``low_grab'' und ``low_to_standing'' ausfühen.
+Um das Objekt wieder abzulegen, wird nun eine Bewegung zum rechte Tisch des Roboters durch eine ActorMovement-Node ausgeführt.
+Auch hier wird zum Ablegen eine weitere Animationsfolge aus zwei ActorAnimation-Nodes genutzt.
+Dabei wird zuerst ``standing_extend_arm'' abgespielt, gefolgt von ``standing_retract_arm''.
+Als letzte Aktion wird der Ruf nach dem Menschen durch eine SetCalledTo-Node auf false zurückgesetzt.
+
+\begin{figure}
+\includegraphics[width=\textwidth]{img/MA-tree-actor-colab}
+\centering
+\caption{BehaviorTree des Menschen bei Kollaboration }
+\label{tree_actor_colab}
+\end{figure}

tex/5_Evaluation_und_Diskussion.tex

@@ -0,0 +1,219 @@
+\chapter{Evaluation und Diskussion}
+
+\section{Nutzung der Virtualisierungsumgebung}
+Die auf Docker basierende Virtualisierungsumgebung stellt eine vollständige ROS2-Installation dar.
+In dieser Umgebung sind alle für die Arbeit benötigten Pakete enthalten.
+Der Start der Umgebung erfolgt über das mitgelieferte \code{start.sh}-Shellskript, welches ohne Parameter ausgeführt wird.
+
+Falls die Umgebung noch nicht genutzt wurde, wird eine neue Containervorlage erstellt.
+Dieser Prozess kann, je nach Internetverbindung des ausführenden Rechners, mehrere Minuten in Anspruch nehmen.
+Der Start der Umgebung wird mit der Ausgabe \code{ros-ros-1  | Ready to connect.} abgeschlossen, die auch in Abbildung \ref{console-docker-started} sichtbar ist.
+Während der Nutzung der Umgebung muss das Terminal weiter geöffnet bleiben.
+Nach dem Senden eines Terminiersignals durch das Schließen des Terminals oder die Tastenkombination \code{Ctrl+C} wird die Containerumgebung beendet.
+
+\begin{figure}[h]
+\includegraphics[width=\textwidth]{img/MA-Docker-Started}
+\centering
+\caption{Konsole mit ausgeführter Virtualisierungsumgebung}
+\label{console-docker-started}
+\end{figure}
+
+Die Verbindung in die ROS-Umgebung erfolgt über SSH in einer separaten Konsole.
+In der so aufgebauten Session kann die Hardwarebeschleunigung des Hostsystems automatisch genutzt werden.
+Dies wurde in Abbildung \ref{console-docker-passthrough} durch die Ausführung von \code{glxgears}, einer OpenGL-Anwendung zum Testen der Grafikpipeline, demonstriert.
+
+Das entworfene Containersystem ist mit deiser Funktionalität für den Einsatz geeignet.
+
+\begin{figure}[h]
+\includegraphics[width=\textwidth]{img/MA-Docker-Passthrough}
+\centering
+\caption{Konsole in der virtuellen Umgebung mit Grafiktests}
+\label{console-docker-passthrough}
+\end{figure}
+
+\section{Starten der Simulation eines Szenarios}
+Das Starten der Simulation erfolgt über ein Skript innerhalb des \code{ign_world}-Pakets.
+Dieses Skript wird durch den Befehl \code{ros2 launch ign_world gazebo_controller_launch.py} ausgeführt.
+In diesem Skript werden alle für die Simulation benötigten ROS2-Nodes gestartet und konfiguriert.
+
+Durch die Verwendung des optionalen Parameters \code{scene} kann das gewünschte Szenario ausgewählt werden.
+Dieser muss in folgendem Format verwendet werden:
+\code{ros2 launch ign_world gazebo_controller_launch.py scene:=[Coex|Coop|Colab]}
+Als Standard wird die Option \code{Coex} genutzt, falls der \code{scene}-Parameter nicht spezifiziert wird.
+
+Nach dem Start der Simulationsumgebung ist der Raum vollständig geladen und einsatzbereit (Abbildung \ref{sim-room}).
+Der Roboter befindet sich in der Ausgangsposition, siehe Abbildung \ref{robot-still}
+
+\begin{figure}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Room}
+\centering
+\caption{Raum in der Simulation}
+\label{sim-room}
+\end{minipage}
+\hspace{.09\textwidth}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Robot-Still}
+\centering
+\caption{Roboterarm in Ausagangslage}
+\label{robot-still}
+\end{minipage}
+\end{figure}
+
+\section{Steuerung des Menschen}
+
+\section{Umsetzung der Szenarien}
+\subsection{Koexistenzszenario}
+
+\begin{figure}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Robot-Move}
+\centering
+\caption{Roboter in Bewegung}
+\label{coex-move}
+\end{minipage}
+\hspace{.09\textwidth}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Human-Shelf}
+\centering
+\caption{Mensch am Regal}
+\label{coex-shelf}
+\end{minipage}
+\end{figure}
+
+\subsection{Kooperationsszenario}
+
+\begin{figure}
+\includegraphics[width=\textwidth]{img/MA-Sim-Human-Coop}
+\centering
+\caption{Mensch am Tisch des Roboters mit Förderband}
+\label{coop-human}
+\end{figure}
+
+\subsection{Kollaborationsszenario}
+
+\begin{figure}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Pickup}
+\centering
+\caption{Mensch bei Aufheben eines Objektes}
+\label{colab-pickup}
+\end{minipage}
+\hspace{.09\textwidth}
+\begin{minipage}{.45\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Drop}
+\centering
+\caption{Mensch beim Ablegen eines Objektes}
+\label{colab-drop}
+\end{minipage}
+\end{figure}
+
+
+
+
+\section{Simulation des Menschen}
+-Animationen und Bewegungen funktionieren
+
+-Kollisionen möglich, aber mit Animationen schwer zu synchronisieren
+\section{Bewegung des Roboters}
+-Roboter kann sich bewegen
+
+-Kollisionen verfügbar
+
+-Interaktion technisch möglich, nicht implementiert. (Kooperation MoveIt/Gazebo nötig)
+\section{BehaviorTrees}
+\subsection{Nodes}
+-Nodes für implementierte Funktionen verfügbar
+
+-Einige andere, technisch relevante Nodes auch implementiert
+\subsection{Kombinieren von Nodes zu einer Request}
+-MoveIt Planung benötigt mehrere Parameter, sollen aber in einzelnen Nodes gesetzt werden
+
+-Kombination nötig, Beschreibung hier
+\section{Lessons Learned bei der Umsetzung}
+-Viele kleine Unannehmlichkeiten, kombiniert ein großes Problemen
+
+-Dokumentation für spätere Projekte
+\subsection{Erstellung des Robotermodells}
+-Keine direkten technischen Daten zum Roboter von Kuka
+-Nur CAD-Dateien der Außenhülle
+
+-Schätzung von Spezifikationen anhand Marketingmaterial
+\subsection{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, die sich jedoch grundlegend unterscheiden.
+Ein altes Projekt mit dem früheren Namen Gazebo, dass nun in Gazebo Classic umbenannt wurde,
+die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
+die nächste Version, die nur noch den Namen Gazebo tragen soll.
+Dies ist darauf zurückzuführen, dass Gazebo Classic und Ignition eine Zeit lang gleichzeitig existierten, jedoch unterschiedliche Funktionen und interne Schnittstellen besitzen.
+
+Das Upgrade von Gazebo Classic auf Gazebo Ignition gestaltete sich aus mehreren Gründen schwierig.
+Dies ist am leichtesten an der geänderten Nutzeroberfläche sichtbar, die in Ignition nun modular ausgeführt ist.
+Um dieses neue modulare System nutzen zu können, wurde das Dateiformat für die Simulationen angepasst.
+In diesem werden die benötigten Physikparameter, Nutzeroberflächen, Plugins und die Simulationswelt definiert.
+
+Um alte Simulationsdateien zu migieren, empfiehlt sich die Erstellung einer neuen, leeren Welt in Gazebo Ignition,
+sodass alle benötigten Physik, Nuteroberflächen und Pluginreferenzen erstellt werden.
+Danach kann die Welt Stück für Stück in das neue Format übertragen werden, wobei nach jedem Eintrag ein Test zur Funktionsfähigkeit gemacht werden sollte, da sich bestimmte Parameterdeklarationen geändert haben.
+Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler während des Ladevorgangs im Log nicht weiter beschrieben werden.
+
+Auch das alte Plugin musste auf das neue System angepasst werden, was auch hier zu einer kompletten Neuimplementation führte, da die internen Systeme zu große Unterschiede aufwiesen.
+Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, die auf ein Entity-Component-System umstellte, aber auch Veränderungen an den verwendeten Objekten innerhalb dieses Systems.
+\subsubsection{Pluginarchitektur}
+Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
+Jedoch existiert damit jedes Plugin im selben Prozess, was bei der Nutzung von Bibliotheken, die nicht für die mehrfache Nutzung im selben Prozess entsprechend ausgelegt wurden, zu Problemen führen kann.
+
+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, dass ü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, dass 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, die dann von den Plugins genutzt werden kann.
+  Dies könnte als ein Plugin realisiert werden, dass 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, die 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.
+
+\subsubsection{Fehlende Animationsgrundlagen}
+-Animationen werden als .col bereitgestellt
+
+-Enthalten Textur, Mesh und Bones, jedoch nicht verbunden -> schlecht für Animation
+\subsection{ROS2}
+\subsubsection{Nachrichten und deren Echtzeitfähigkeit}
+-TCP und UDP verfügbar, jedoch nicht sofort kompatibel
+\subsubsection{Änderung der Compilertoolchain}
+-Änderung des Buildsystems von rosbuild auf catkin
+
+-Benötigte Änderungen in CMakeFile und package
+\subsection{MoveIt2}
+\subsubsection{Upgrade auf MoveIt2}
+-Unterschiede in der Deklaration des Roboters selbst
+
+-Änderungen der Deklaration der ros\_control Anbindung
+
+-Vorerst kein Setup, manuelle Migration erforderlich
+
+->Lesson learned: Projekte häufig auf Updates prüfen
+\subsubsection{Fehlerhafte Generierung der Roboter}
+-Einige Aspekte der Generierung nicht erforderlich oder falsch
+\subsubsection{Controller}
+-Controller benötigte Anpassungen und manuelle Tests
+\section{Lessons Learned bei den Szenarien}
+\subsection{Debugging}
+-async tty Option
+
+-gdb ist ein Muss
+
+-``Aufhängen'' von trees