Compare commits

..

16 Commits

Author SHA1 Message Date
93ff4038e6 spellcheck. 2023-07-03 03:58:31 +02:00
8a6b7455f9 spellcheck. 2023-07-03 03:52:47 +02:00
d00a3f18be More Changes. 2023-07-03 01:59:01 +02:00
9ebb18886f More Changes. 2023-07-02 18:06:37 +02:00
48cbe29307 Fixes for errors in chapter 4 2023-07-01 01:50:37 +02:00
910cc99ccb Changes on the go. 2023-06-30 09:28:54 +02:00
8b0b1ac02b Changes up 29.06 2023-06-30 03:01:03 +02:00
6c0668f2fd Chnages to 29.06 2023-06-29 04:22:34 +02:00
0dad2e87f6 Changes up to 27.06 2023-06-27 19:20:19 +02:00
bfbd1be0e8 second pass to page 8 2023-06-21 21:54:41 +02:00
e5985af2df Chnages up to 20.06 2023-06-21 21:11:52 +02:00
37459bc12d Merge branch 'master' of https://gitea.yenon.at/yenon/MasterarbeitLaTeX 2023-06-19 14:33:48 +02:00
85a23b1352 Changes on tower 2023-06-19 14:26:36 +02:00
99008ee9fd First pages of second rework 2023-06-19 14:24:58 +02:00
330bce82ec Added .gitignore 2023-06-14 13:11:25 +02:00
00c864578a Fixed: welche, other stuff till 13.06 2023-06-14 13:04:18 +02:00
83 changed files with 11960 additions and 8754 deletions

303
.gitignore vendored Normal file
View File

@@ -0,0 +1,303 @@
## 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
/main.pdf

View File

@@ -2,7 +2,7 @@
kile_livePreviewEnabled=true
kile_livePreviewStatusUserSpecified=true
kile_livePreviewTool=LivePreview-PDFLaTeX
lastDocument=tex/4_Umsetzung.tex
lastDocument=tex/3_Auswahl.tex
[document-settings,item:Einleitung.tex]
Bookmarks=
@@ -67,6 +67,24 @@ Indentation Mode=normal
Mode=LaTeX
Mode Set By User=false
[document-settings,item:tex/5_Evaluation_und_Diskussion.tex]
Bookmarks=
Encoding=UTF-8
Highlighting=LaTeX
Highlighting Set By User=false
Indentation Mode=normal
Mode=LaTeX
Mode Set By User=false
[document-settings,item:tex/6_Ausblick.tex]
Bookmarks=
Encoding=UTF-8
Highlighting=LaTeX
Highlighting Set By User=false
Indentation Mode=normal
Mode=LaTeX
Mode Set By User=false
[document-settings,item:tex/Einleitung.tex]
Bookmarks=
Encoding=UTF-8
@@ -78,7 +96,7 @@ Mode Set By User=false
[item:main.bib]
open=true
order=5
order=7
[item:main.tex]
open=true
@@ -104,6 +122,14 @@ order=3
open=true
order=4
[item:tex/5_Evaluation_und_Diskussion.tex]
open=true
order=5
[item:tex/6_Ausblick.tex]
open=true
order=6
[view-settings,view=0,item:Einleitung.tex]
CursorColumn=0
CursorLine=0
@@ -113,51 +139,67 @@ TextFolding={"checksum":"","ranges":[]}
ViMarks=
[view-settings,view=0,item:main.bib]
CursorColumn=1
CursorLine=257
CursorColumn=51
CursorLine=326
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"d388fe775e2de092b50ce9dbaa861869ee036db3","ranges":[]}
TextFolding={"checksum":"8795c48226fb036f16e6bbcfbf55b812c6d43eaa","ranges":[]}
ViMarks=
[view-settings,view=0,item:main.tex]
CursorColumn=68
CursorLine=32
CursorColumn=0
CursorLine=105
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"88153af05e2be709e828e4e8a1a9f54b756bcefe","ranges":[]}
TextFolding={"checksum":"80ccd936ce5ae7dc5995816ffe293139ed94b427","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/1_Einleitung.tex]
CursorColumn=114
CursorLine=46
CursorColumn=196
CursorLine=35
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"052cc01250adb0f5e3ea2eff211696be3fc560ae","ranges":[]}
TextFolding={"checksum":"99e42b912b320890bab1219df1e7d056e5124a2d","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/2_Konzept.tex]
CursorColumn=0
CursorLine=115
CursorColumn=26
CursorLine=25
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"462cd841a4ae5cfb2a0372ff60c2f3b89035b3ea","ranges":[]}
TextFolding={"checksum":"111913c063e94bf8f1bf4f786b47b20be2773064","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/3_Auswahl.tex]
CursorColumn=99
CursorLine=364
CursorColumn=17
CursorLine=361
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"9cca06e103193ebce1a74b19ba51648376b36a4b","ranges":[]}
TextFolding={"checksum":"7aa9002df025f03505dbfc278b329c1fb13f4e2a","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/4_Umsetzung.tex]
CursorColumn=0
CursorLine=452
CursorColumn=102
CursorLine=1001
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"dd8e7caf4d43ea72300c447784e10addb44c0e7e","ranges":[]}
TextFolding={"checksum":"dbda4a467836d9dfaee2833e58221fe122996b5e","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/5_Evaluation_und_Diskussion.tex]
CursorColumn=18
CursorLine=168
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"847cd8cf59a779530aa24d2840e2423d2f10200b","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/6_Ausblick.tex]
CursorColumn=59
CursorLine=71
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"e964476a9eab203b42b321940c7b6784639e0caf","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/Einleitung.tex]

2264
Fehler.html Normal file

File diff suppressed because one or more lines are too long

9
MA.gummi Normal file
View File

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

View File

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

View File

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

View File

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

64
dict.txt Normal file
View File

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

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 327 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 312 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 292 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 188 KiB

BIN
img/MA-Docker-Started.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 177 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 214 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 180 KiB

BIN
img/MA-Sim-Human-Coop.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 210 KiB

BIN
img/MA-Sim-Human-Shelf.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 160 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 159 KiB

BIN
img/MA-Sim-Robot-Move.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 162 KiB

BIN
img/MA-Sim-Robot-Still.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 189 KiB

BIN
img/MA-Sim-Room.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 157 KiB

Binary file not shown.

BIN
img/MA-bend-axis.pdf Normal file

Binary file not shown.

BIN
img/MA-subtree-deposit.pdf Normal file

Binary file not shown.

BIN
img/MA-subtree-work.pdf Normal file

Binary file not shown.

BIN
img/MA-tree-actor-coex.pdf Normal file

Binary file not shown.

BIN
img/MA-tree-actor-colab.pdf Normal file

Binary file not shown.

BIN
img/MA-tree-actor-coop.pdf Normal file

Binary file not shown.

BIN
img/MA-tree-base-robot.pdf Normal file

Binary file not shown.

BIN
img/MA-tree-colab.pdf Normal file

Binary file not shown.

BIN
img/MA-tree-demo.pdf Normal file

Binary file not shown.

BIN
img/MA-tree-robot-coex.pdf Normal file

Binary file not shown.

BIN
img/MA-tree-robot-colab.pdf Normal file

Binary file not shown.

BIN
img/MA-tree-robot-coop.pdf Normal file

Binary file not shown.

Binary file not shown.

347
main.aux
View File

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

546
main.bbl
View File

@@ -1,546 +0,0 @@
% $ 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{gamerig}{misc}{}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{Arminando/GameRig: GameRig is an auto rigging for games addon for Blender. Built on top of Rigify, it adds rigs, metarigs and additional functionality that enable game engine friendly rig creation. Open source and can be used for personal and commercial projects.}
\verb{urlraw}
\verb https://github.com/Arminando/GameRig
\endverb
\verb{url}
\verb https://github.com/Arminando/GameRig
\endverb
\endentry
\entry{1087032}{article}{}
\name{author}{1}{}{%
{{hash=3d750c4d36f30d3cb25be30be5c1870b}{%
family={Brooks},
familyi={B\bibinitperiod},
given={R.},
giveni={R\bibinitperiod}}}%
}
\strng{namehash}{3d750c4d36f30d3cb25be30be5c1870b}
\strng{fullhash}{3d750c4d36f30d3cb25be30be5c1870b}
\strng{bibnamehash}{3d750c4d36f30d3cb25be30be5c1870b}
\strng{authorbibnamehash}{3d750c4d36f30d3cb25be30be5c1870b}
\strng{authornamehash}{3d750c4d36f30d3cb25be30be5c1870b}
\strng{authorfullhash}{3d750c4d36f30d3cb25be30be5c1870b}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{IEEE Journal on Robotics and Automation}
\field{number}{1}
\field{title}{A robust layered control system for a mobile robot}
\field{volume}{2}
\field{year}{1986}
\field{pages}{14\bibrangedash 23}
\range{pages}{10}
\verb{doi}
\verb 10.1109/JRA.1986.1087032
\endverb
\endentry
\entry{cmake}{misc}{}
\field{sortinit}{C}
\field{sortinithash}{4d103a86280481745c9c897c925753c0}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{CMake}
\verb{urlraw}
\verb https://cmake.org/
\endverb
\verb{url}
\verb https://cmake.org/
\endverb
\endentry
\entry{cobot}{misc}{}
\field{sortinit}{C}
\field{sortinithash}{4d103a86280481745c9c897c925753c0}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 18.4.2022}
\field{title}{Cobots: der intelligente Roboter als Kollege}
\verb{urlraw}
\verb https://www.kuka.com/de-de/future-production/mensch-roboter-kollaboration/cobots
\endverb
\verb{url}
\verb https://www.kuka.com/de-de/future-production/mensch-roboter-kollaboration/cobots
\endverb
\endentry
\entry{colcon}{misc}{}
\field{sortinit}{c}
\field{sortinithash}{4d103a86280481745c9c897c925753c0}
\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{btintro}{book}{}
\name{author}{2}{}{%
{{hash=db7c35906ea6fb15b4ad802938cde9b5}{%
family={Colledanchise},
familyi={C\bibinitperiod},
given={Michele},
giveni={M\bibinitperiod}}}%
{{hash=ebd3acb81e2d857e368ec17c18bec591}{%
family={Ögren},
familyi={Ö\bibinitperiod},
given={Petter},
giveni={P\bibinitperiod}}}%
}
\strng{namehash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
\strng{fullhash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
\strng{bibnamehash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
\strng{authorbibnamehash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
\strng{authornamehash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
\strng{authorfullhash}{a7ac798c3a7f5340156bccfc5c9a4bdf}
\field{sortinit}{C}
\field{sortinithash}{4d103a86280481745c9c897c925753c0}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{CRC Press}
\field{title}{Behavior Trees in Robotics and AI - An Introduction}
\field{year}{2018}
\verb{doi}
\verb https://doi.org/10.1201/9780429489105
\endverb
\endentry
\entry{ffdrobotsim}{article}{}
\name{author}{3}{}{%
{{hash=f2dc35051dfb5b500d5402c64759f099}{%
family={Dombrowski},
familyi={D\bibinitperiod},
given={Uwe},
giveni={U\bibinitperiod}}}%
{{hash=68eeb042550b17c611d6249fcb1e14a7}{%
family={Stefanak},
familyi={S\bibinitperiod},
given={Tobias},
giveni={T\bibinitperiod}}}%
{{hash=9ec1975d8ae166000acc0cce4dcb58d7}{%
family={Perret},
familyi={P\bibinitperiod},
given={Jérôme},
giveni={J\bibinitperiod}}}%
}
\strng{namehash}{e4d9514f8a853c3f8392ba05b5ad0d42}
\strng{fullhash}{e4d9514f8a853c3f8392ba05b5ad0d42}
\strng{bibnamehash}{e4d9514f8a853c3f8392ba05b5ad0d42}
\strng{authorbibnamehash}{e4d9514f8a853c3f8392ba05b5ad0d42}
\strng{authornamehash}{e4d9514f8a853c3f8392ba05b5ad0d42}
\strng{authorfullhash}{e4d9514f8a853c3f8392ba05b5ad0d42}
\field{sortinit}{D}
\field{sortinithash}{6f385f66841fb5e82009dc833c761848}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Procedia Manufacturing}
\field{month}{12}
\field{title}{Interactive Simulation of Human-robot Collaboration Using a Force Feedback Device}
\field{volume}{11}
\field{year}{2017}
\field{pages}{124\bibrangedash 131}
\range{pages}{8}
\verb{doi}
\verb 10.1016/j.promfg.2017.07.210
\endverb
\endentry
\entry{DOMBROWSKI2018134}{article}{}
\name{author}{3}{}{%
{{hash=f2dc35051dfb5b500d5402c64759f099}{%
family={Dombrowski},
familyi={D\bibinitperiod},
given={Uwe},
giveni={U\bibinitperiod}}}%
{{hash=68eeb042550b17c611d6249fcb1e14a7}{%
family={Stefanak},
familyi={S\bibinitperiod},
given={Tobias},
giveni={T\bibinitperiod}}}%
{{hash=db67f8b79eeeb57441d27000b23d527e}{%
family={Reimer},
familyi={R\bibinitperiod},
given={Anne},
giveni={A\bibinitperiod}}}%
}
\strng{namehash}{6b4730d5f57faa6cb0e5bcbbd4041102}
\strng{fullhash}{6b4730d5f57faa6cb0e5bcbbd4041102}
\strng{bibnamehash}{6b4730d5f57faa6cb0e5bcbbd4041102}
\strng{authorbibnamehash}{6b4730d5f57faa6cb0e5bcbbd4041102}
\strng{authornamehash}{6b4730d5f57faa6cb0e5bcbbd4041102}
\strng{authorfullhash}{6b4730d5f57faa6cb0e5bcbbd4041102}
\field{sortinit}{D}
\field{sortinithash}{6f385f66841fb5e82009dc833c761848}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{In this paper, we show the importance of digital factory tools for the planning of human-robot collaboration (HRC), the associated risk assessment and the safety certification of the entire HRC-application. Referring to the structure of this paper, first we define the requirements of the simulation of human-robot collaboration by means of power and force limiting by inherent design or control. Then we review the state-of-the-art of domain of robotic simulation. We demonstrate how to determine the force and pressure in case of a direct collision between human and robot for industrial safety certification. With the help of a detailed parameter study, we reduce the needed parameters for the simulation of HRC to the relevant factors. Finally, the paper shows how to use the approach of simulation to reduce the time and costs for the implementation of real HRC-scenarios into the factory of tomorrow.}
\field{issn}{2351-9789}
\field{journaltitle}{Procedia Manufacturing}
\field{note}{28th International Conference on Flexible Automation and Intelligent Manufacturing (FAIM2018), June 11-14, 2018, Columbus, OH, USAGlobal Integration of Intelligent Manufacturing and Smart Industry for Good of Humanity}
\field{title}{Simulation of human-robot collaboration by means of power and force limiting}
\field{volume}{17}
\field{year}{2018}
\field{pages}{134\bibrangedash 141}
\range{pages}{8}
\verb{doi}
\verb https://doi.org/10.1016/j.promfg.2018.10.028
\endverb
\verb{urlraw}
\verb https://www.sciencedirect.com/science/article/pii/S2351978918311442
\endverb
\verb{url}
\verb https://www.sciencedirect.com/science/article/pii/S2351978918311442
\endverb
\keyw{Interactive simulation,collaborative robotics,occupational safety,health,manufacturing ergonomics,modeling,simulation,human factors,smart manufacturing}
\endentry
\entry{freecad}{misc}{}
\field{sortinit}{F}
\field{sortinithash}{2638baaa20439f1b5a8f80c6c08a13b4}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 21.04.2023}
\field{title}{FreeCAD: Ihr parametrischer 3D-Modellierer}
\verb{urlraw}
\verb https://www.freecad.org/index.php?lang=de
\endverb
\verb{url}
\verb https://www.freecad.org/index.php?lang=de
\endverb
\endentry
\entry{gazebo}{misc}{}
\field{sortinit}{G}
\field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{Gazebo}
\verb{urlraw}
\verb https://staging.gazebosim.org/home
\endverb
\verb{url}
\verb https://staging.gazebosim.org/home
\endverb
\endentry
\entry{gazebo-app}{misc}{}
\field{sortinit}{G}
\field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{Gazebo}
\verb{urlraw}
\verb https://app.gazebosim.org/dashboard
\endverb
\verb{url}
\verb https://app.gazebosim.org/dashboard
\endverb
\endentry
\entry{halo2}{misc}{}
\field{sortinit}{G}
\field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 18.05.2023}
\field{title}{GDC 2005 Proceeding: Handling Complexity in the Halo 2 AI}
\verb{urlraw}
\verb https://www.gamedeveloper.com/programming/gdc-2005-proceeding-handling-complexity-in-the-i-halo-2-i-ai
\endverb
\verb{url}
\verb https://www.gamedeveloper.com/programming/gdc-2005-proceeding-handling-complexity-in-the-i-halo-2-i-ai
\endverb
\endentry
\entry{ros-git}{misc}{}
\field{sortinit}{G}
\field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
\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{godot}{misc}{}
\field{sortinit}{G}
\field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 10.04.2023}
\field{title}{Godot Engine - Free and open source 2D and 3D game engine}
\verb{urlraw}
\verb https://godotengine.org
\endverb
\verb{url}
\verb https://godotengine.org
\endverb
\endentry
\entry{isla2005handling}{misc}{}
\name{author}{1}{}{%
{{hash=04a4610505a94b6883df923efb3f2f3e}{%
family={Isla},
familyi={I\bibinitperiod},
given={D},
giveni={D\bibinitperiod}}}%
}
\strng{namehash}{04a4610505a94b6883df923efb3f2f3e}
\strng{fullhash}{04a4610505a94b6883df923efb3f2f3e}
\strng{bibnamehash}{04a4610505a94b6883df923efb3f2f3e}
\strng{authorbibnamehash}{04a4610505a94b6883df923efb3f2f3e}
\strng{authornamehash}{04a4610505a94b6883df923efb3f2f3e}
\strng{authorfullhash}{04a4610505a94b6883df923efb3f2f3e}
\field{sortinit}{I}
\field{sortinithash}{8d291c51ee89b6cd86bf5379f0b151d8}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{title}{Handling complexity in the halo 2 ai. GDC 2005 Proceedings}
\field{year}{2005}
\endentry
\entry{doi:10.1126/scirobotics.abm6074}{article}{}
\name{author}{5}{}{%
{{hash=7b84d10a03303cd00f198fefb38a5da3}{%
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{moveit-docs}{misc}{}
\field{sortinit}{M}
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 13.4.2022}
\field{title}{MoveIt 2 Documentation}
\verb{urlraw}
\verb https://moveit.picknik.ai/galactic/index.html
\endverb
\verb{url}
\verb https://moveit.picknik.ai/galactic/index.html
\endverb
\endentry
\entry{moveitpython}{misc}{}
\field{sortinit}{M}
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
\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{octomap}{misc}{}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 13.4.2022}
\field{title}{OctoMap}
\verb{urlraw}
\verb https://octomap.github.io
\endverb
\verb{url}
\verb https://octomap.github.io
\endverb
\endentry
\entry{rospackages}{misc}{}
\field{sortinit}{P}
\field{sortinithash}{ff3bcf24f47321b42cb156c2cc8a8422}
\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
\entry{rigify}{misc}{}
\field{sortinit}{R}
\field{sortinithash}{5e1c39a9d46ffb6bebd8f801023a9486}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{Rigify — Blender Manual}
\verb{urlraw}
\verb https://docs.blender.org/manual/en/3.5/addons/rigging/rigify/index.html
\endverb
\verb{url}
\verb https://docs.blender.org/manual/en/3.5/addons/rigging/rigify/index.html
\endverb
\endentry
\entry{coppelia}{misc}{}
\field{sortinit}{R}
\field{sortinithash}{5e1c39a9d46ffb6bebd8f801023a9486}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{Robot simulator CoppeliaSim: create, compose, simulate, any robot - Coppelia Robotics}
\verb{urlraw}
\verb https://www.coppeliarobotics.com/
\endverb
\verb{url}
\verb https://www.coppeliarobotics.com/
\endverb
\endentry
\entry{sdf-format}{misc}{}
\field{sortinit}{S}
\field{sortinithash}{b164b07b29984b41daf1e85279fbc5ab}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{SDFormat Specification}
\verb{urlraw}
\verb https://sdformat.org/spec
\endverb
\verb{url}
\verb https://sdformat.org/spec
\endverb
\endentry
\entry{cpp}{misc}{}
\field{sortinit}{S}
\field{sortinithash}{b164b07b29984b41daf1e85279fbc5ab}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{Standard C++}
\verb{urlraw}
\verb https://isocpp.org
\endverb
\verb{url}
\verb https://isocpp.org
\endverb
\endentry
\entry{unreal}{misc}{}
\field{sortinit}{T}
\field{sortinithash}{9af77f0292593c26bde9a56e688eaee9}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 10.04.2023}
\field{title}{The most powerful real-time 3D creation tool - Unreal Engine}
\verb{urlraw}
\verb https://www.unrealengine.com
\endverb
\verb{url}
\verb https://www.unrealengine.com
\endverb
\endentry
\entry{unity}{misc}{}
\field{sortinit}{U}
\field{sortinithash}{6901a00e45705986ee5e7ca9fd39adca}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 10.04.2023}
\field{title}{Unity Real-Time Development Platform | 3D, 2D, VR \& AR Engine}
\verb{urlraw}
\verb https://unity.com
\endverb
\verb{url}
\verb https://unity.com
\endverb
\endentry
\entry{urdf-format}{misc}{}
\field{sortinit}{u}
\field{sortinithash}{6901a00e45705986ee5e7ca9fd39adca}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{urdf/XML ROS Wiki}
\verb{urlraw}
\verb http://wiki.ros.org/urdf/XML
\endverb
\verb{url}
\verb http://wiki.ros.org/urdf/XML
\endverb
\endentry
\entry{python}{misc}{}
\field{sortinit}{W}
\field{sortinithash}{4315d78024d0cea9b57a0c6f0e35ed0d}
\field{labeltitlesource}{title}
\field{note}{letzter Zugriff: 23.04.2023}
\field{title}{Welcome to Python.org}
\verb{urlraw}
\verb https://www.python.org
\endverb
\verb{url}
\verb https://www.python.org
\endverb
\endentry
\enddatalist
\endrefsection
\endinput

2439
main.bcf

File diff suppressed because it is too large Load Diff

View File

@@ -214,8 +214,8 @@
}
@misc{gamerig,
title = {Arminando/GameRig: GameRig is an auto rigging for games addon for Blender. Built on top of Rigify, it adds rigs, metarigs and additional functionality that enable game engine friendly rig creation. Open source and can be used for personal and commercial projects.},
url = {https://github.com/Arminando/GameRig},
title = {BlenderBoi/Game_Rig_Tools},
url = {https://github.com/BlenderBoi/Game_Rig_Tools},
note = {letzter Zugriff: 23.04.2023},
}
@@ -276,3 +276,55 @@ 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},
}
@misc{lsp,
title = {Official page for Language Server Protocol},
url = {https://microsoft.github.io/language-server-protocol/},
note = {letzter Zugriff 29.06.2023},
}
@misc{gazeboDebug,
title = {Ignition Gazebo: Debugging},
url = {https://gazebosim.org/api/gazebo/2.10/debugging.html},
note = {letzter Zugriff 29.06.2023},
}
@misc{rosDebug,
title = {How can I run ROS2 nodes in a debugger (e.g. gdb)? - ROS Answers: Open Source Q\&A Forum},
url = {https://answers.ros.org/question/267261/how-can-i-run-ros2-nodes-in-a-debugger-eg-gdb/},
note = {letzter Zugriff 29.06.2023},
}
@misc{mqPosix,
title = {mq_overview(7) — Linux manual page},
url = {https://man7.org/linux/man-pages/man7/mq_overview.7.html},
note = {letzter Zugriff 30.06.2023},
}
@misc{mqSystemV,
title = {sysvipc(7) — Linux manual page},
url = {https://man7.org/linux/man-pages/man7/sysvipc.7.html},
note = {letzter Zugriff 30.06.2023},
}
@misc{shmem,
title = {shm\_overview(7) — Linux manual page},
url = {https://man7.org/linux/man-pages/man7/shm_overview.7.html},
note = {letzter Zugriff 30.06.2023},
}
@misc{websocket,
title = {RFC 6455 - The WebSocket Protocol},
url = {https://datatracker.ietf.org/doc/html/rfc6455},
note = {letzter Zugriff 30.06.2023},
}
@misc{ipcBench,
title = {goldsborough/ipc-bench: :horse_racing: Benchmarks for Inter-Process-Communication Techniques},
url = {https://github.com/goldsborough/ipc-bench},
note = {letzter Zugriff 30.06.2023},
}
@misc{moveItStudio,
title = {MoveIt Studio Developer Platform \& SDK | PickNik},
url = {https://picknik.ai/studio/},
note = {letzter Zugriff 30.06.2023},
}

View File

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

BIN
main.dvi

Binary file not shown.

View File

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

1702
main.log

File diff suppressed because it is too large Load Diff

View File

@@ -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

BIN
main.pdf

Binary file not shown.

View File

@@ -1,86 +0,0 @@
<?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>

Binary file not shown.

167
main.tex
View File

@@ -8,34 +8,36 @@ 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]{
@@ -97,158 +99,17 @@ parskip=half,
\input{tex/2_Konzept.tex}
\input{tex/3_Auswahl.tex}
\input{tex/4_Umsetzung.tex}
\chapter{Szenarienbasierte Evaluation}
\section{Simulation des Menschen}
-Animationen und Bewegungen funktionieren
-Kollisionen möglich, aber mit Animationen schwer zu synchronisieren
\section{Bewegung des Roboters}
-Roboter kann sich bewegen
-Kollisionen verfügbar
-Interaktion technisch möglich, nicht implementiert. (Kooperation MoveIt/Gazebo nötig)
\section{BehaviorTrees}
\subsection{Nodes}
-Nodes für implementierte Funktionen verfügbar
-Einige andere, technisch relevante Nodes auch implementiert
\subsection{Kombinieren von Nodes zu einer Request}
-MoveIt Planung benötigt mehrere Parameter, sollen aber in einzelnen Nodes gesetzt werden
-Kombination nötig, Beschreibung hier
\chapter{Diskussion}
\section{Lessons Learned bei der Umsetzung}
-Viele kleine Unannehmlichkeiten, kombiniert ein großes Problemen
-Dokumentation für spätere Projekte
\subsection{Erstellung des Robotermodells}
-Keine direkten technischen Daten zum Roboter von Kuka
-Nur CAD-Dateien der Außenhülle
-Schätzung von Spezifikationen anhand Marketingmaterial
\subsection{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.
Ein altes Projekt mit dem früheren Namen Gazebo, welches nun in Gazebo Classic umbenannt wurde,
die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
die nächste Version, welche nur noch den Namen Gazebo tragen soll.
Dies ist darauf zurückzuführen, dass Gazebo Classic und Ignition eine Zeit lang gleichzeitig existierten, jedoch unterschiedliche Funktionen und interne Schnittstellen besitzen.
Das Upgrade von Gazebo Classic auf Gazebo Ignition gestaltete sich aus mehreren Gründen schwierig.
Dies ist am leichtesten an der geänderten Nutzeroberfläche sichtbar, welche in Ignition nun modular ausgeführt ist.
Um dieses neue modulare System nutzen zu können, wurde das Dateiformat für die Simulationen angepasst.
In diesem werden die benötigten Physikparameter, Nutzeroberflächen, Plugins und die Simulationswelt definiert.
Um alte Simulationsdateien zu migieren, empfiehlt sich die Erstellung einer neuen, leeren Welt in Gazebo Ignition,
sodass alle benötigten Physik, Nuteroberflächen und Pluginreferenzen erstellt werden.
Danach kann die Welt Stück für Stück in das neue Format übertragen werden, wobei nach jedem Eintrag ein Test zur Funktionsfähigkeit gemacht werden sollte, da sich bestimmte Parameterdeklarationen geändert haben.
Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler während des Ladevorgangs im Log nicht weiter beschrieben werden.
Auch das alte Plugin musste auf das neue System angepasst werden, was auch hier zu einer kompletten Neuimplementation führte, da die internen Systeme zu große Unterschiede aufwiesen.
Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, welche auf ein Entity-Component-System umstellte, aber auch Veränderungen an den verwendeten Objekten innerhalb dieses Systems.
\subsubsection{Pluginarchitektur}
Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
Jedoch existiert damit jedes Plugin im selben Prozess, was bei der Nutzung von Bibliotheken, welche nicht für die mehrfache Nutzung im selben Prozess entsprechend ausgelegt wurden, zu Problemen führen kann.
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.
\subsubsection{Fehlende Animationsgrundlagen}
-Animationen werden als .col bereitgestellt
-Enthalten Textur, Mesh und Bones, jedoch nicht verbunden -> schlecht für Animation
\subsection{ROS2}
\subsubsection{Nachrichten und deren Echtzeitfähigkeit}
-TCP und UDP verfügbar, jedoch nicht sofort kompatibel
\subsubsection{Änderung der Compilertoolchain}
-Änderung des Buildsystems von rosbuild auf catkin
-Benötigte Änderungen in CMakeFile und package
\subsection{MoveIt2}
\subsubsection{Upgrade auf MoveIt2}
-Unterschiede in der Deklaration des Roboters selbst
-Änderungen der Deklaration der ros\_control Anbindung
-Vorerst kein Setup, manuelle Migration erforderlich
->Lesson learned: Projekte häufig auf Updates prüfen
\subsubsection{Fehlerhafte Generierung der Roboter}
-Einige Aspekte der Generierung nicht erforderlich oder falsch
\subsubsection{Controller}
-Controller benötigte Anpassungen und manuelle Tests
\section{Lessons Learned bei den Szenarien}
\subsection{Debugging}
-async tty Option
-gdb ist ein Muss
-``Aufhängen'' von trees
\chapter{Zusammenfassung und Ausblick}
\section{Ergebnisse}
\subsection{Graphische Repräsentation der Szenarien}
-Szenarien graphisch abgebildet
\subsection{Anpassung der Behavior Trees an Szenarien}
-Trees angepasst
\section{Diskussion}
-Viele Iterationen benötigt
-Funktionstüchtige Simulation der Szenarien
-Bewegung der Objekte schwerer als gedacht
-Synchronisationsmechanismus Gazebo <-> MoveIt benötigt
\section{Ausblick}
\subsection{Umsetzung in anderem Simulator}
-Einfachere ROS Anbindung
-Potentiell einfacher ausbaubar auf Basis einer erweiterbaren Gameengine
-Mangelhafte Dokumentation von Gazebo
\subsection{Simulation bewegter Objekte}
-Aufgrund von Komplexität des Prozesses nicht integriert
\subsection{Ergänzung von Umgebungserkennung}
-MoveIt hat Unterstützung
-Daten aus Gazebo extrahieren und in MoveIt einbinden
-Person in OctoMap\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
\subsection{Separieren der Subtrees in eigene Dateien}
\input{tex/5_Evaluation_und_Diskussion.tex}
\input{tex/6_Ausblick.tex}
\printbibliography
\newpage
\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}

View File

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

View File

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

Binary file not shown.

BIN
robot.pdf

Binary file not shown.

Binary file not shown.

View File

@@ -2,62 +2,68 @@
\section{Motivation}
Die Simulation von Maschinen wird im industriellen Umfeld immer beliebter, um deren Verhalten schon vor der eigentlichen Produktion zu testen.
Dazu wird ein Modell des gesamten Prozesses in der Simulation geschaffen, der durch die Maschine beeinflusst werden soll.
Das Modell wird dann um die Maschine selbst erweitert, welche Einfluss auf das System nimmt.
Die Veränderungen durch die Maschine werden nun analysiert, und erlauben Rückschlüsse auf die Funktion des Systems.
Ein solches Modell kann nun für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
Das Modell wird um die Maschine selbst erweitert, die Einfluss auf das System nimmt.
Die Veränderungen durch die Maschine werden analysiert, und erlauben Rückschlüsse auf die Funktion des Systems.
Ein solches Modell kann für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
Da in der Realität oftmals Menschen und Maschinen im gleichen Umfeld mit- oder auch zusammenarbeiten, ist es sinnvoll, die Menschen in die Simulation einzubeziehen.
Im wachsenden Feld der Mensch-Roboter-Kollaboration existieren bereits einige Lösungen, um auch die namensgebende Interaktion von Mensch und Roboter simulieren zu können.
Im wachsenden Feld der Mensch-Roboter-Kollaboration existieren bereits einige Lösungen, um auch die namensgebende Interaktion von Mensch und Roboter zu simulieren.
Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf in der Simulation bereits vor deren Ausführung fest definiert werden muss.
Dies erlaubt die Reproduktion des genauen Bewegungsablaufes, aber nicht verschiedene Variationen im gesamten Prozess, welche durch die Ereignisse in der Simulation ausgelöst werden.
Um eine solche Funktionalität bereitstellen zu können, muss der Bewegungsablauf von sowohl Roboter und Mensch zur Laufzeit der Simulation gesteuert werden.
Dies erlaubt lediglich die Reproduktion des geplanten Bewegungsablaufes, aber nicht dessen Variation im Prozess, ausgelöst durch Ereignisse in der Simulation.
Um eine solche Funktionalität bereitzustellen, müssen die Bewegungsabläufe sowohl von Roboter als auch Mensch zur Laufzeit der Simulation gesteuert werden können.
Dies soll durch eine eingängliche Beschreibungssprache ermöglicht werden, die einfach erweitert und auf neue Szenarien angepasst werden kann.
Um diese Funktionalität zu demonstrieren, sollen 3 unterschiedliche Testszenarien in der Simulationsumgebung abgebildet werden.
Diese Steuerung soll durch eine eingängige Beschreibungssprache erfolgen, die einfach erweitert und auf neue Szenarien angepasst werden kann.
Um die Funktionalität zu demonstrieren, sind 3 unterschiedliche Testszenarien in der Simulationsumgebung abzubilden.
Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwischen Mensch und Roboter simulieren.
\section{Stand der Wissenschaft}
Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen Teilaspekten einer solchen Simulation.
Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen Teilaspekten der Simulation eines Mensch-Roboter-Kollaborationsszenarios.
Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere Projekte dar.\cite{DOMBROWSKI2018134}
Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere
Projekte dar \cite{DOMBROWSKI2018134}.
Hierbei wird die erwünschte Interaktion betrachtet und aus den gewonnenen Daten werden Einschränkungen generiert.
Diese Einschränkungen können nun in der Interaktion verwendet werden, um Verletzungen durch den Roboter auszuschließen.
Diese Einschränkungen können in der Interaktion verwendet werden, um zum Beispiel Verletzungen des Menschen durch den Roboter auszuschließen.
Ein anderer Weg der Kollisionsvermeidung ist die Planung der maximal zurücklegbaren Distanz eines Menschen aus seiner aktuellen Position.\cite{ffdrobotsim}
Dafür werden die maximalen Beschleunigungen einzelner Körperteile ermittelt, um diese während der Interaktion überwachen zu können.
Ein anderer Weg der Kollisionsvermeidung ist die Planung der maximal zurücklegbaren Distanz eines Menschen aus seiner aktuellen Position \cite{ffdrobotsim}.
Dafür werden die maximalen Beschleunigungen einzelner Körperteile ermittelt, um diese während der Interaktion zu überwachen.
Sollte ein Mensch den Roboter erreichen können, muss dieser in der dafür benötigten Zeit stoppen können.
Dies sorgt für eine Geschwindigkeitsanpassung im Nahfeld, da hier schnellere Bewegungen möglich sind.
Es existieren auch zahlreiche Wege, die Bewegungs- und Interaktionsplanung eines Roboters mit Beschreibungssprachen abzudecken.\cite{btintro}
Es existieren auch zahlreiche Ansätze, die Bewegungs- und Interaktionsplanung eines Roboters mit Beschreibungssprachen abzudecken \cite{btintro}.
Dabei kommt es auf die Umsetzung in der Beschreibungssprache, aber auch auf Anforderungen an das System an, um zum Beispiel das Abbrechen von Aktionen zu ermöglichen.
In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetzt, um verschiedene Systeme, wie zum Beispiel die Steuerung von Nichtspielercharakteren, zu beschreiben.\cite{halo2}
In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetzt, um verschiedene Systeme, wie zum Beispiel die Steuerung von Nichtspielercharakteren, zu beschreiben \cite{halo2}.
Eine vollständige Umsetzung einer erweiterbaren Simulation mit Mensch und Roboter, gesteuert durch eine Beschreibungssprache konnte nicht gefunden werden.
Eine vollständige Umsetzung einer erweiterbaren Simulation mit Mensch und Roboter, gesteuert durch eine Beschreibungssprache, konnte bei der Recherche zu dieser Arbeit jedoch nicht gefunden werden.
\section{Welche Szenarien}
Die drei zu modellierenden Szenarien sollten so gewählt werden, dass in vorherigen Szenarien genutzte Bestandteile in späteren, komplexeren Szenarien weiter genutzt werden können.
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders in Frage, da diese viele ähnliche Bestandteile haben, jedoch mehrere Umstände denkbar sind, in welchen diese verwendet werden können.
Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das Begutachten eines Objekts, welche alle nur eine Bewegungsabfolge des beteiligten Menschen sind.
\section{Auswahl der Szenarien}
Die drei zu modellierenden Szenarien sollten so gewählt werden, dass spätere komplexere Szenarien auf einfacheren Vorgängern aufsetzen und deren Funktionen weiter nutzen und ergänzen.
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders infrage.
Diese besitzen viele ähnliche Bestandteile, die in mehreren Umständen nutzbar sind.
Das erlaubt den Einsatz von wenigen Animationen in vielen Szenarien.
Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das Begutachten eines Objekts, welche jeweils nur eine ähnliche Bewegungsabfolge des beteiligten Menschen sind.
Das erste Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe befassen, in welcher ein Roboter im Arbeitsbereich eines Menschen Teile fertigt.
Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit bei Annäherung des Menschen, um Kollisionen zu vermeiden.
Der Mensch soll in diesem Szenario auch arbeiten, jedoch nur vereinzelt den Arbeitsbereich des Roboters betreten, um diesen zu beobachten.
Das erste Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe befassen, in der ein Roboter im Arbeitsbereich eines Menschen Teile fertigt.
Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit des Roboters bei Annäherung des Menschen, um Kollisionen zu vermeiden.
Der Mensch soll in diesem Szenario an einer anderen Aufgabe arbeiten.
Während dieser Arbeit betritt der Mensch vereinzelt den Arbeitsbereich des Roboters, was die entsprechende Reaktion des Roboters hervorrufen soll.
Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide an unterschiedlichen Aufgaben, jedoch im selben Raum, arbeiten.
Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide im selben Raum, jedoch an unterschiedlichen Aufgaben arbeiten.
Außerdem werden grundlegende Aspekte der Simulation getestet, wie zum Beispiel das Bewegen von Mensch und Roboter und die sicherheitsrelevante Aktion der Geschwindigkeitsanpassung.
Im zweiten Szenario prüft und sortiert der Roboter Teile und legt die guten Exemplare auf einem Fließband zur Weiterverarbeitung ab.
Die Mängelexemplare werden hingegen in einer besonderen Zone abgelegt, von wo sie vom Menschen abtransportiert werden.
Auch hier soll der Mensch solange eigenständig arbeiten, bis der Roboter ein aussortiertes Teil ablegt, welches weiter transportiert werden muss.
Im zweiten Szenario prüft und sortiert der Roboter Teile und legt die fehlerfreien Exemplare auf einem Fließband zur Weiterverarbeitung ab.
Die Mängelexemplare werden hingegen in einer dafür vorgesehenen Zone abgelegt, von wo sie vom Menschen abtransportiert werden.
Auch hier soll der Mensch so lange eigenständig arbeiten, bis der Roboter ein aussortiertes Teil ablegt, das transportiert werden muss.
Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in 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.
Dieser soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren, was durch das Laufen im Raum abgebildet werden soll.
\section{Welcher Nutzen / Contributions}
Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in dem Mensch und Roboter an derselben Aufgabe arbeiten.
Hierbei soll der Roboter eine Palette entladen, wobei er nicht jedes Objekt ausreichend manipulieren kann.
Dies wird durch zufällige Fehler beim Aufheben, Transport und Ablegen der Objekte abgebildet.
In diesen Fällen muss ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
Der Mensch soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren, was durch das Laufen im Raum abgebildet werden soll.
\section{Contributions}
Durch diese Arbeit soll in zukünftigen Projekten die Möglichkeit geschaffen werden, konzeptionelle Probleme bei der Erstellung neuer Aufgabenbereiche eines Roboters frühzeitig durch Simulation erkennbar zu machen.
Dazu ist eine schnelle 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.
Dazu ist eine schnelle Adaption von sowohl Roboter als auch Mensch auf unterschiedliche Szenarien nötig.
Die Szenarien sollen dabei durch eine Beschreibungssprache definiert werden.
Durch deren Struktur soll komplexes Verhalten einfach und überschaubar abbildbar sein, dass dann in der Simulation getestet werden kann.

View File

@@ -1,11 +1,11 @@
\chapter{Konzept}
Die zu entwickelnde Simulation soll die bisher meißt separaten Zweige der Roboter- und Menschensimulation verbinden.
Die zu entwickelnde Simulation soll die bisher meist separaten Zweige der Roboter- und Menschensimulation verbinden.
Um die beiden Akteure in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
Diese Befehle werden dabei von externer Software unter der Verwendung einer Beschreibungssprache und Feedback aus der Simulation generiert.
Hierfür wird die Beschreibungssprache in der Dienstumgebung ausgeführt, in welcher auch die Bewegungsplanung stattfindet.
Die Beschreibungssprache kommuniziert direkt mit der Simulation und Bewegungsplanung des simulierten Menschen.
Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen diesen auch Nachrichten ausgetauscht.
Hierfür wird die Beschreibungssprache in der Dienstumgebung ausgeführt, in der auch die Bewegungsplanung stattfindet.
Die Beschreibungssprache kommuniziert direkt mit der Simulation und der Bewegungsplanung des simulierten Menschen.
Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen Simulation und Bewegungsplanung auch Nachrichten ausgetauscht.
Der gesamte Vorgang ist in Abbildung \ref{concept_overview} visualisiert.
Die zu erarbeitende Softwareumgebung soll einfach erweiterbar sein, um weitere Modifikationen und die Umsetzung anderer Projekte zuzulassen.
@@ -13,7 +13,7 @@ Hierzu zählt die Austauschbarkeit und Erweiterbarkeit von Komponenten wie der s
Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
\begin{figure}
\includegraphics{img/MA-Konzept-Übersicht.drawio.pdf}
\includegraphics{img/MA-Konzept-Übersicht}
\centering
\caption{Visualisierung des Konzepts}
\label{concept_overview}
@@ -21,13 +21,13 @@ Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
\section{Simulation des Roboters}
Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
Außerdem ist die enge Interaktion mit Menschen interessant, was einen für Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, welcher als Cobot vermarktet wird.
Die Bezeichnung als Cobot\cite{cobot} ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
Der Roboter besitzt auch einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
Außerdem ist die enge Interaktion mit Menschen gewünscht, was für einen auf Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, der als Cobot vermarktet wird.
Die Bezeichnung als Cobot \cite{cobot} ist dabei ein Kofferwort aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
Der Roboter besitzt einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
Um den Kuka iisy in der Simulation verwenden zu können, muss ein Modell des Roboterarms erstellt werden.
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut abbilden.
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst genau abbilden.
Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
\section{Simulation des Menschen}
@@ -36,89 +36,117 @@ Hierzu sollen in der Simulationsumgebung mehrere Animationen verwendet werden, w
Für komplexere Verhaltensweisen können Animationen und andere Aktionen, wie zum Beispiel eine Bewegung und Rotation kombiniert werden, um zum Beispiel die Aktion ``Laufen in eine bestimmte Richtung'' auszuführen.
Um diese Animationen erstellen zu können, wird zuerst ein animierbares Modell des Menschen benötigt.
Dieses Modell soll dabei um weitere Animationen erweiterbar sein.
Es werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.
Das zu erstellende Modell soll dabei um weitere Animationen erweiterbar sein.
Unterschiedliche Animationen gehen dabei meist von verschiedenen Ursprungszuständen aus.
Um zwischen diesen Ursprungszuständen wechseln zu können, werden weitere Animationen benötigt.
Die so erstellten Animationen müssen nun von außerhalb der Simulationsumgebung ausführbar gemacht werden, um diese später mit einer Beschreibungssprache steuern zu können.
Hierfür muss eine Komponente entwickelt werden, welche in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Anfragen im Fortschritt überwacht und abgebrochen werden können.
Die so erstellten Animationen müssen von außerhalb der Simulationsumgebung ausführbar gemacht werden.
Ein solcher Mechanismus erlaubt die spätere Steuerung der Animation durch die Beschreibungssprache.
Hierfür muss eine Komponente entwickelt werden, die in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, soll diese Komponente die Ausführung der Befehle überwachen.
Da mehrere Befehle nacheinander ausgeführt werden sollen, wird der aktuelle Fortschritt der Aktion zurückgemeldet.
Außerdem kann durch andere Komponenten in der Simulation der Abbruch einer Aktion des Menschen nötig werden.
Die Weitergabe eines Abbruchbefehls soll demzufolge auch über die geplante Komponente realisiert werden können.
\section{Behavior Trees als Beschreibungssprache}
Bislang wird das Verhalten von Akteuren in Simationsumgebungen, darunter Roboter und Menschen, häufig in Form von State-Machines ausgedrückt.
Diese besitzen jedoch einen großen Nachteil, welcher vor allem bei komplexeren Abläufen hervortreten kann.
Dabei handelt es sich um die Übersichtlichkeit, welche bei einer wachsenden State-Machine leicht verloren geht.
Bislang wird das Verhalten von Akteuren in Simulationsumgebungen, darunter Roboter und Menschen, häufig in Form von State-Machines ausgedrückt.
Diese besitzen jedoch einen großen Nachteil, der vor allem bei komplexeren Abläufen hervortreten kann.
Dabei handelt es sich um die Übersichtlichkeit, die bei einer wachsenden State-Machine leicht verloren geht.
Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, was zu Fehlern im späteren Betrieb führen kann.
Behavior Trees lösen dieses Problem, in dem sie sogenannte Nodes definieren, welche in einer übersichtlichen Baumstruktur angeordnet werden.
Behavior Trees lösen dieses Problem, in dem sie sogenannte Nodes definieren, die in einer übersichtlichen Baumstruktur angeordnet werden.
Die einzelnen Nodes verändern dabei das System und lösen den Wechsel zu neuen Nodes aus.
Ursprünglich wurde das Konzept von Rodney Brooks entwickelt, welcher diese für mobile Roboter einsetzen wollte. \cite{1087032}
Das System setzte sich jedoch erst später in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten durch. \cite{isla2005handling}
Ursprünglich wurde das Konzept der Behavior Trees von Rodney Brooks entwickelt, der diese für mobile Roboter einsetzen wollte. \cite{1087032}
Das System setzte sich später jedoch zuerst in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten, durch. \cite{isla2005handling}
Der Ablauf eines Behavior Trees startet vom sogenannten Root, der Wurzel des Baums.
Von dort an werden Nodes, welche je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
Die Nodes werden untereinander angeordnet, welches die Relation der Nodes zueinander beschreibt.
Von dort an werden Nodes, die je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
Die Nodes werden untereinander angeordnet, was die Relation der Nodes zueinander beschreibt.
Jede Node ist entweder direkt unter der Root-Node oder einer anderen Node angeordnet.
Außerdem kann jede Node eine beliebige Anzahl an untergeordneten Nodes besitzen.
Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unterschieden werden können.
Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unterschieden werden.
\begin{description}
\item[Aktions-Nodes]
beschreiben einzelne ausführbare Aktionen, die das System beeinflussen können.
Jede Aktion liefert dabei einen Rückgabewert über ihren Erfolg, welcher durch die darüber liegende Node ausgewertet werden kann.
Jede Aktion liefert dabei einen Rückgabewert über ihren Erfolg, der durch die darüber liegende Node ausgewertet werden kann.
\item[Dekorations-Nodes]
können den Rückgabewert einer anderen Node modifizieren.
Häufig existieren hier die Negation, aber auch das forcieren eines bestimmten Rückgabewertes für die unterliegende Node.
Zumeist wird die Negation des Rückgabewerts verwendet, aber auch das Forcieren eines bestimmten Rückgabewertes ist möglich.
\item[Sequenz-Nodes]
beschreiben eine nacheinander ausgeführte Abfolge von darunter liegenden Nodes.
Sollte eine Node einen Fehler zurückgeben, wird die Ausführung der Sequenz abgebrochen, was wiederum zur Rückgabe eines Fehlers durch die Sequenz selbst führt.
Beim erfolgreichen Durchlauf gibt die Sequenz einen Erfolg zurück.
\item[Fallback-Nodes]
verhalten sich ähnlich zu Sequenz-Nodes, jedoch werden darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurück gibt.
verhalten sich ähnlich wie Sequenz-Nodes, jedoch werden die darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurückgibt.
In diesem Fall wird die Ausführung der Fallback-Node mit einem Erfolg abgebrochen.
Ein Fehler wird hier zurückgegeben, wenn alle Nodes ohne eine Erfolgsmeldung durchlaufen wurden.
\end{description}
\begin{figure}[]
\includegraphics[]{img/tree_demo}
\begin{figure}
\includegraphics[]{img/MA-tree-demo}
\centering
\caption{Beispiel eines BehaviorTrees}
\label{concept_tree_demo}
\end{figure}
Das in Abbildung \ref{concept_tree_demo} visualisierte Beispiel zeigt die Abfolge, um eine Tür zu öffnen und zu durchschreiten.
Die Ausführung des Baumes beginnt an der Root-Node.
Von dort an wird als erstes die Sequenz-Node ausgeführt, welche drei untergeordnete Nodes besitzt.
Die Ausführung des Baumes beginnt an der Root-Node, wobei die Zahlen über den Nodes die Reihenfolge der Rückgabewerte angeben.
Von dort aus wird als Erstes die Sequenz-Node ausgeführt, die drei untergeordnete Nodes besitzt.
Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, ausgeführt.
Daraus resultierend wird als erstes die linke Node ausgeführt, diese ist jedoch eine Fallback-Node mit weiteren untergeordneten Nodes.
Da der Rückgabewert der Fallback-Node von den in ihr befindlichen Nodes bestimmt wird, werden diese nun nacheinander ausgeführt.
Hier gelten die oben genannten Regeln für Fallback-Nodes.
In diesem Fall wird geprüft, ob die Tür bereits offen ist.
Da dies nicht der Fall ist, wird die nächste Node ausgeführt, welche die Tür öffnen soll.
Dieser Versuch gelingt, weshalb die Ausführung der Fallback-Node mit einem Erfolg beendet wird.
Dadurch wird die nächste Node in der Sequenz ausgeführt, welche prüft, ob die Tür durchlaufen werden kann.
Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet, welcher die Ausführung der Sequenz abbricht.
Diese würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.
Daraus resultierend wird zuerst die linke Fallback-Node, die ihrerseits untergeordnete Nodes besitzt, ausgeführt.
Da der Rückgabewert der Fallback-Node von den unter ihr befindlichen Nodes bestimmt wird, werden diese nacheinander ausgeführt.
Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich so einfach neue Verhalten implementieren.
Von diesem Punkt an beginnen die Rückgaben, die das weitere Verhalten beeinflussen.
Folgender Kontrollfluss findet in diesem Beispiel statt:
\begin{enumerate}
\item{
In dieser Node wird geprüft, ob die Tür bereits offen ist.
Da die Tür nicht offen ist, wird ein Misserfolg zurückgemeldet.
}
\item{
Dieses Ergebnis löst die Ausführung der nächsten untergeordneten Node der Fallback-Node aus.
Die so ausgewählte Node soll die Tür öffnen.
Der Versuch gelingt und der Erfolg wird an die Fallback-Node übergeben.
}
\item{
Da die untergeordnete Node eine erfolgreiche Ausführung meldet, wird die Ausführung der Fallback-Node mit einem erfolgreichen Rückgabewert beendet.
Aus diesem Grund wird die Node ``Tür eintreten'' nicht mehr ausgeführt.
}
\item{
Dadurch wird die nächste Node in der Sequenz ausgeführt, die prüft, ob die Tür durchlaufen werden kann.
Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet.
}
\item{
Der gemeldete Misserfolg der untergeordneten Node bricht die Ausführung der Sequenz mit einem negativen Rückgabewert ab.
}
\end{enumerate}
Dieser Ablauf würde nun von neuem beginnen, da die Root-Node ihre untergeordnete Node ohne Berücksichtigung des Rückgabewertes neu startet.
Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich neue Verhalten implementieren.
Dies erlaubt die schnelle Anpassung des Verhaltens der gesteuerten Systeme.
In dieser Arbeit sollen deshalb BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, welche in dieser Arbeit betrachtet werden, abzudecken.
Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, die in dieser Arbeit betrachtet werden, abzudecken.
\section{Virtualisierungsumgebung als Platform}
Aufgrund von vorheriger Erfahrung mit involvierten Einrichtungsprozessen, ist der Einsatz fest definierter Umgebungen unerlässlich.
\section{Virtualisierungsumgebung als Plattform}
Der Einsatz fest definierter Prozesse in einer stabilen Umgebung ist unerlässlich, um Fehler durch die unvollständige Einrichtung der Umgebung zu vermeiden.
Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in der das zu entwerfende System ausgeführt wird.
Dadurch können benötigte Programme, Pfade und Umgebungsvariablen in der Virtualisierungsumgebung hinterlegt werden, welche diese bei der Ausführung auf einem anderen Grundsystem korrekt abbildet.
Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da alle Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
Dadurch können benötigte Programme, Pfade und Umgebungsvariablen in der Virtualisierungsumgebung hinterlegt werden, die diese bei der Ausführung auf einem anderen Grundsystem korrekt abbildet.
Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da die Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
Ein weiterer Vorteil ist die beschleunigte Entwicklung, da Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
Ein weiterer Vorteil ist die beschleunigte Entwicklung, weil Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
Hinzu kommt die einfachere Inbetriebnahme eines bereits entwickelten Systems, da keine Anpassungen am Hostsystem vorgenommen werden müssen.
Natürlich existieren auch Nachteile der Virtualisierung, welche mit den Vorteilen abgewogen werden müssen.
Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, welche der virtualisierten Anwendung nicht mehr zur Verfügung steht.
Außerdem muss bei grafischen Systemen bedacht werden, wie die darzustellenden Daten vom Hostsystem angezeigt werden können.
Natürlich existieren auch Nachteile der Virtualisierung, die mit den Vorteilen abgewogen werden müssen.
Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, die dann der virtualisierten Anwendung nicht mehr zur Verfügung steht.
Außerdem muss bei grafischen Systemen die Darstellung der relevanten grafischen Daten auf dem Hostsystem berücksichtigt werden.
Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung stellt einen wichtigen Schritt in der Entwicklung des Gesamtsystems dar.
Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung beeinflusst das Ergebnis dieser Arbeit zwar nicht direkt, hat aber großen Einfluss auf die Pflege des Gesamtsystems.
Dies erlaubt zum Beispiel unabhängige, dedizierte Versionen der Softwarekomponenten und die Möglichkeit isolierter Upgrades dieser Komponenten.
Eine solche Plattform sorgt somit für die Reproduzierbarkeit der Ergebnisse auf verschiedenen Systemen.

View File

@@ -1,51 +1,55 @@
\chapter{Komponenten-/Softwareauswahl}
Die Auswahl der verwendeten Softwarekomponenten ist ein wichtiger Schritt der Entwicklung.
Diese Entscheidungen beeinflussen die späteren Entwicklungsprozess nachhaltig.
Die Auswahl der verwendeten Softwarekomponenten beeinflusst den späteren Entwicklungsprozess nachhaltig.
Im nachfolgenden findet die Auswahl der Komponenten statt.
Diese sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
Alle diese Teilbereiche können dann zu einer Simulation vebunden werden, welche das gesamte Problemfeld abdeckt.
Alle Komponenten sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
Alle diese Teilbereiche können dann zu einer Simulation verbunden werden, die das gesamte Problemfeld abdeckt.
Wie bereits in Abbildung \ref{concept_overview} dargestellt, ist für die Erfüllung der Aufgaben eine Dienst- und eine Simulationsumgebung erforderlich.
Dieses Kapitel beschreibt die Auswahl der Umgebungen und der in diesen laufenden Prozesse.
Dieses Kapitel beschreibt die Auswahl der Umgebungen und alle in den Umgebungen laufenden Prozesse.
\section{Dienstumgebung}
Die Dienstumgebung bestimmt maßgeblich, wie Software im Entwicklungsprozess geschrieben wird.
Durch sie werden häufig benötigte Funktionen bereitgestellt, welche durch die Programme innerhalb der Umgebung genutzt werden können.
Durch sie werden häufig benötigte Funktionen bereitgestellt, die Programme innerhalb der Umgebung nutzen können.
Bei einer Dienstumgebung für Roboter gehören zu den grundlegenden Aspekten die Nachrichtenübergabe zwischen einzelen interagierenden Programmen, um eine gemeinsame Basis für ein einfach erweiterbares System zu schaffen.
Außerdem sind Werkzeuge zur Einstellungsübergabe an Teilsysteme sinnvoll, um diese einfach an einer Stelle anpassen zu können.
Bei einer Dienstumgebung für Roboter gehört die Nachrichtenübergabe zwischen den einzelnen Programmen zu den grundlegenden Aspekten.
Diese wird genutzt, um eine gemeinsame Basis für ein erweiterbares System zu schaffen.
Außerdem sind Werkzeuge zur Parameterübergabe an Teilsysteme sinnvoll, um die Einstellungen an einer Stelle gesammelt anpassen zu können.
\subsection{Auswahl}
Es existieren mehrere Systeme, die als Dienstumgebung für Roboter in Frage kommen, wenn es lediglich um die Nachrichtenübergabe zwischen Programmen geht.
Jede Lösung, welche Nachrichten zwischen Prozessen austauschen kann, ist ein potentieller Kanidat für ein Roboterframework.
Es existieren mehrere Systeme, die als Dienstumgebung für Roboter infrage kommen, wenn man lediglich die Nachrichtenübergabe zwischen Programmen betrachtet.
Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist potenziell als ein Roboterframework einsetzbar.
Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition der Nachrichten, welche über das System ausgetauscht werden.
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, 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.
Nutzbare, bereits als Interprozesskommunikation integrierte Systeme sind zum Beispiel Pipes, die Daten zwischen Prozessen über Buffer austauschen.
Auch die Nutzung von Message Queues oder Shared Memory ist für diesen Einsatzzweck möglich.
Diese Systeme sind performant, jedoch schwerer zu verwalten.
Ein Problem dieser Methoden ist die direkte Kommunikation mehrerer Komponenten, da die Art der Kommunikation keine Modifikation von Nachrichten zur Anpassung an andere Szenarien vorsieht.
Eine Alternative stellen Sockets dar, welche Daten zwischen mehreren Programmen austauschen können.
Dabei dient ein Programm als Server, welches Anfragen von anderen Programmen, auch Clients genannt, entgegen nimmt.
Eine Alternative stellen Sockets dar, die Daten zwischen mehreren Programmen austauschen können.
Dabei dient ein Programm als Server, der Anfragen von anderen Programmen, auch Clients genannt, entgegen nimmt.
Die Kommunikation zwischen Client und Server ist bidirektional möglich, was kompliziertere Protokolle ermöglicht.
Alle diese Lösungen besitzen einen gemeinsamen Nachteil in deren Nachrichtendefinition.
Dieser Nachteil besteht in der potentiellen Variation zahlreicher Kommunikationsmechanismen, welche zum Datenaustausch über all diese möglichen Systeme verwendet werden können.
Bei einem ausreichend großen Projekt treten so unweigerlich Unterschiede in der Handhabung auf, die es zu berücksichtigen gilt.
Dieser Nachteil besteht in der potenziellen Variabilität dieser Kommunikationsmechanismen.
Bei einem ausreichend großen Projekt treten so unweigerlich Unterschiede in der Handhabung von Nachrichten auf, die es zu berücksichtigen gilt.
Durch solche Unterschiede kann es zu Inkompatibilitäten zwischen Programmen kommen, was sich auf die universelle Nutzbarkeit der Programme negativ auswirkt.
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.
Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standartisierte und erweiterbare Nachrichtendefinition gelöst, welche von den Programmen in der Umgebung genutzt werden.
Um diese Nachrichten zu senden und empfangen liefert ROS eine eigene Implementation des Protokolls für zum Beispiel Python\cite{python} und C++\cite{cpp}, welche mehrere Arten der Nachrichtenübergabe unterstützten.
Im Bereich der Robotik ist ROS \cite{doi:10.1126/scirobotics.abm6074}, bei dem es sich um ein quelloffenes System handelt, als Dienstumgebung etabliert.
Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standardisierte und erweiterbare Nachrichtendefinitionen gelöst, die von den Programmen in der Umgebung genutzt werden.
Um diese Nachrichten senden und empfangen zu können, liefert ROS bereits eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
Zum Beispiel existieren für Python \cite{python}, C und C++ \cite{cpp} entsprechende Implementationen in Form der Pakete \code{rospy}, \code{rclc} und \code{rclcpp}.
Die neuste Version ROS2 bietet dabei einige Verbesserungen im Vergleich zu früheren Version ROS1.
Ein neues Nachrichtenformat mit Quality of Service kann zum Beispiel Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
Außerdem werden nun neben CMake\cite{cmake} auch andere Buildsysteme unterstützt, was zum Beispiel die Verwendung von Python erlaubt.
Die neuste Version ROS2 bietet mehrere Verbesserungen im Vergleich zu früheren Version ROS1 \cite{changesRosII}.
Ein neues Nachrichtenformat mit Quality of Service kann beispielsweise Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
Außerdem werden neben CMake \cite{cmake} auch andere Buildsysteme unterstützt, was die Verwendung von Python erlaubt.
Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
Vor allem die unzähligen ROS-Bibliotheken, welche von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
ROS kann für sowohl simulierte Umgebungen, aber auch für echte Roboter eingesetzt werden, da beide Anwendungsfälle durch Programme an die Umgebung angebunden werden können.
Vor allem die Vielzahl von ROS-Bibliotheken, die von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär \cite{rospackages}.
ROS kann sowohl für simulierte Umgebungen als auch für echte Roboter eingesetzt werden.
Diese beiden Anwendungsfälle werden durch unterschiedliche Controller realisiert.
Für simulierte Umgebungen leitet der Controller die Steuerdaten an die Simulationsumgebung weiter.
Bei dem Einsatz echter Hardware werden die Zielpositionen durch den Controller an die Roboterhardware weitergeleitet.
%-Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
%-ROS2
@@ -53,149 +57,172 @@ ROS kann für sowohl simulierte Umgebungen, aber auch für echte Roboter eingese
%-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}.
ROS2 \cite{doi:10.1126/scirobotics.abm6074}, im weiteren Verlauf nur ROS genannt, beschreibt sich selbst als ``a meta operating system for robots'' \cite{ros-git}.
Hierbei ist ``operating system'' nicht in seiner herkömmlichen Bedeutung eines vollständigen Betriebssystems zu verstehen.
Es handelt sich dabei um eine gemeinsame Grundlage für Programme und Daten, welche durch ROS bereitgestellt wird.
Es handelt sich dabei um eine gemeinsame Grundlage für Programme und Daten, die durch ROS bereitgestellt wird.
Einzelne Bestandteile in der Umgebung sind dabei in Pakete gegliedert, wobei jedes Paket beliebig viele Daten und Programme beinhalten kann.
Programme, die mit anderen Programmen in der Umgebung über die ROS internen Schnittstellen kommunizieren, werden in ROS ``Nodes'' genannt.
Jedes Paket enthält dabei eine \code{package.xml}-Datei, welche durch die Paketverwaltung genutzt wird.
In dieser befindet sich eine in XML verfasste Definition des Paketinhalts, welche verschiedene Aspekte des Pakets beschreibt.
Darunter fallen Informationen über den das Paket selbt, wie dessen Name, Beschreibung und Version.
Außerdem sind Name und Mailadresse des Autors, sowie die gewählte Lizenz des Codes vermerkt.
Um das Paket später korrekt ausführen zu können, werden außerdem benötigte Pakete für die Erstellung und Ausführung des Pakets eingetragen.
Falls C++ zur Entwicklung des Pakets verwendet wird, befindet sich außerdem eine \code{CMakeLists.txt}-Datei im Paket.
In befinden sich die Buildinstruktionen für den Compiler für die im Paket befindlichen Programme.
Durch einen Aufruf von \code{ament_cmake} werden andere Parameter aus der \code{package.xml}-Datei ergänzt.
Außerdem können bestimmte Pfade aus dem Paket exportiert werden, sodass diese später im Workspace verfügbar sind.
Programme, welche mit anderen Programmen in der Umgebung über die ROS internen Schnittstellen kommunizieren, werden in ROS ``Nodes'' genannt.
Zu den Aufgaben von ROS gehören dabei:
Zu den Aufgaben von ROS zählen folgende Teilbereiche:
\begin{description}
\item[Organisation]\hfill \\
Um die einzelnen Teile einer Roboterumgebung zu separieren, werden diese in ROS auf unterschiedliche Pakete aufgeteilt.
Jedes Paket enthält dabei eine \code{package.xml}-Datei.
In dieser befindet sich eine in XML verfasste Definition des Paketinhalts, die verschiedene Aspekte des Pakets beschreibt.
Darunter fallen Informationen über das Paket selbst, wie dessen Name, Beschreibung und Version.
Außerdem sind Name und Mailadresse des Autors, sowie die gewählte Lizenz des Codes vermerkt.
Um das Paket später korrekt ausführen zu können, werden benötigte Pakete für den Kompiliervorgang und die Ausführung in die package.xml-Datei eingetragen.
\item[Buildumgebung]\hfill \\
ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
Zu deren Konfiguration werden CMake\cite{cmake} und einige Erweiterungen, wie zum Beispiel das oben erwähnte \code{ament_cmake} eingesetzt.
Anhand dieser Dateien werden die fertiggestellten Pakete dann im Workspace installiert, damit diese später verwendet werden können.
Zu deren Konfiguration wird eine \code{CMakeLists.txt}-Datei erstellt, die den Buildprozess beschreibt.
In dieser sind die Buildinstruktionen für den Compiler enthalten, mit welchen die im Paket befindlichen Programme kompiliert werden.
Der Aufruf des \code{ament_cmake}-Makros in dieser ergänzt den Kompiliervorgang um weitere Parameter aus der \code{package.xml}-Datei.
Nach diesen Vorbereitungsschritten kann CMake das Paket kompilieren.
Hierbei werden alle in der \code{CMakeLists.txt}-Datei angegebenen Programmteile kompiliert.
Es ist außerdem möglich, bestimmte Pfade des Pakets nach dem Buildvorgang zu exportieren.
Diese sind dann später im erstellten Workspace für die Nutzung durch andere Programme verfügbar.
\item[Workspaceverwaltung]\hfill \\
Pakete können in verschiedenen Verzeichnissen installiert werden und müssen für andere Pakete auffindbar sein.
ROS nutzt hierfür von colcon generierte Skripte, welche beim Erstellen eines Pakets und eines Workspaces mit angelegt werden.
Das Skript des Pakets fügt nur dieses Paket der Umgebung hinzu, das Skript des Workspaces führt alle Skripte der in diesem enthaltenen Pakete aus, um diese allesamt der Umgebung hinzuzufügen.
Gruppen von Paketen werden zur einfacheren Handhabung in sogenannten ``Workspaces'' zusammengefasst.
Diese vereinfachen das Auffinden der enthaltenen Pakete durch Skripte, die diese im System registrieren.
Die Erstellung der Skripte erfolgt anhand der bereits beschriebenen \code{CMakeLists.txt}-Datei.
Das Programm \code{colcon} analysiert diese und generiert die Skripte.
Um das Paket im System zu registrieren, muss der Nutzer die generierten Skripte ausführen, was die benötigten Umgebungsvariablen setzt.
Hierfür wird meist ein weiteres Skript verwendet, was alle im Workspace befindlichen Pakete nacheinander der Umgebung hinzufügt.
Dieser Vorgang erlaubt zum Beispiel das Auffinden von Paketen anhand deren Namen im Dateisystem.
Das erleichtert die Verwaltung durch die Unabhängigkeit von spezifischen Pfaden im entwickelten System.
Außerdem wird die Laufzeitumgebung für alle Programme konfiguriert, was definierte Bibliotheken für diese verfügbar macht.
\item[Abhängigkeitsverwaltung]\hfill \\
ROS kann durch die in den Paketen deklarierten Abhängigkeiten prüfen, ob diese in der aktuellen Umgebung ausführbar sind.
Die generierten Warnungen bei fehlenden Paketen vermeiden Abstürze und undefiniertes Verhalten in der Ausführung von Nodes, welche diese benötigen.
Die generierten Warnungen bei fehlenden Paketen helfen dem Anwender, Abstürze und undefiniertes Verhalten bei der Ausführung von Nodes zu vermeiden, die diese Pakete benötigen.
\item[Datenübertragung]\hfill \\
Um Daten zwischen Nodes austauschen zu können, müssen 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.
Der Datenaustausch geschieht in sogenannten Topics, welche Nachrichtenkanäle zwischen den Nodes darstellen.
Der Datenaustausch geschieht in sogenannten Topics, die Nachrichtenkanäle zwischen den Nodes darstellen.
Eine Node kann entweder als Server ein Topic anbieten, was durch andere Nodes gelesen wird, oder als Client auf solche bereitgestellten Topics zugreifen.
Durch die Kombination mehrerer Topics ist eine komplexere Interaktion abbildbar, welche zum Beispiel Rückgabewerte zum aktuell ausgeführten Steuerbefehl liefert.
Durch die Kombination mehrerer Topics ist eine komplexere Interaktion abbildbar, die zum Beispiel Rückgabewerte zum aktuell ausgeführten Steuerbefehl liefert.
\item[Parameterübergabe]\hfill \\
Um Nodes auf neue Anwendungsfälle anpassen zu können, wird ein Konfigurationsmechanismus benötigt.
In ROS geschieht dies durch die Übergabe sogenannter Parameter, welche durch die Node gelesen werden können.
Diese eignen sich zur Übergabe von Informationen, wie zum Beispiel einem Robotermodell, aber auch um die Topics der Nodes umbenennen zu können.
In ROS geschieht dies durch die Übergabe sogenannter Parameter, die durch die Node gelesen werden können.
Diese eignen sich zur Übergabe von Informationen, wie zum Beispiel Daten über ein verwendetes Robotermodell.
Um neue Konfigurationen zu unterstützen, kann das Umbenennen von Topics einer Node notwendig werden, was auch mit einem Parameter erfolgen kann.
\item[Startverwaltung]\hfill \\
In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
Dabei werden diese mit den gewünschten Parametern versehen, welche verschiedene Eigenschaften der Node an die aktuelle Umgebung anpassen können.
Das Einstellen von bestimmten Parametern erlaubt die Anpassung der Funktionen an den gewünschten Anwendungsfall.
\end{description}
Durch eine solche Umgebung kann die gewünschte Simulation einfacher in mehrere Komponenten zerlegt werden, was die spätere Wartung des Projekts vereinfacht.
\section{Simulationsumgebung (Gazebo)}
Eine solche Umgebung erlaubt die Zerlegung der geplanten Simulation in mehrere Komponenten.
Die daraus erfolgte Abgrenzung erhöht die Übersichtlichkeit der einzelnen Bestandteile.
Dies vereinfacht die spätere Wartung des Projekts.
\section{Simulationsumgebung}
\subsection{Auswahl}
Als Simulationsumgebung eignen sich verschiedenen Programme, die sich hinsichtlich ihres Funktionsumfangs stark unterscheiden.
Hierfür kommen dedizierte Werkzeuge zur Robotersimulation, aber auch beispielsweise universell einsetzbare Gameengines in Frage.
Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da der gebotene Funktionsumfang der Softwares sich stark unterscheidet.
Auch andere Aspekte, wie Lizenzen oder schwer bewertbare Aspekte wie Nutzerfreundlichkeit, sind hierbei zu betrachten.
Eine Auswahl der als Simulationsumgebung in Frage kommenden Programme werden hier vorgestellt.
Hierfür kommen beispielsweise dedizierte Werkzeuge zur Robotersimulation, aber auch universell einsetzbare Gameengines infrage.
Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da sich der gebotene Funktionsumfang der Softwares stark unterscheidet.
Auch andere Aspekte, wie Lizenzen oder die schwer bewertbare Nutzerfreundlichkeit, sind hierbei zu betrachten.
Eine Auswahl der als Simulationsumgebung infrage kommenden Programme wird hier vorgestellt.
CoppeliaSim \cite{coppelia}, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
Der Simulator selbst unterstützt Menschliche Aktoren, jedoch können diese nur Animationen abspielen oder zusammen mit Bewegungen abspielen.
CoppeliaSim existiert in 3 Versionen, welche sich im Funktionsumfang unterscheiden, jedoch hat nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
Der Simulator selbst unterstützt menschliche Aktoren, diese können aber nur Animationen allein oder in Kombination mit einer Bewegung abspielen.
CoppeliaSim existiert in 3 Versionen, die sich hinsichtlich Funktionsumfang und Lizenz unterscheiden.
Jedoch besitzt nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
Gazebo Ignition\cite{gazebo} ist wie CoppeliaSim eine Robotersimulationsumgebung, jedoch ohne integrierten Editor und direkte ROS-Unterstützung.
Gazebo setzt wie CoppeliaSim auf Erweiterungen, welche die gewünschten Funktionen einbinden können.
Zum Beispiel existiert auch eine ROS-Brücke, welche die Anbindung an ROS ermöglicht.
Gazebo Ignition \cite{gazebo} ist wie CoppeliaSim eine Robotersimulationsumgebung, besitzt aber keinen integrierten Editor und direkte ROS-Unterstützung.
Gazebo setzt wie CoppeliaSim auf Erweiterungen, um zusätzliche Funktionen einbinden zu können.
So existiert zum Beispiel auch eine ROS-Brücke, die die Anbindung an ROS ermöglicht.
Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
Das Projekt ist Open Source, unter der Apache Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
Das Projekt ist Open Source, unter der Apache-Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
Unity\cite{unity} hingegen ist primär eine Grafikengine für Nutzung in Computerspielen.
Unity \cite{unity} hingegen ist primär eine Grafikengine für die Nutzung in Computerspielen.
Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteigerbereich zurückzuführen ist.
Auch die Optionen zur Menschensimulation sind gut, da diese häufig in Spielen verwendet werden.
Ein großer Nachteil hingegen ist die Lizenz, welche nur für Einzelpersonen kostenlos ist.
Auch die Optionen zur Menschensimulation sind umfangreich, da diese häufig in Spielen verwendet werden.
Ein großer Nachteil hingegen ist die Lizenz, die nur für Einzelpersonen kostenfrei ist.
Die Unreal Engine \cite{unreal} ist wie Unity eine Grafikengine aus dem Spielebereich.
Auch hier ist die Menschensimulation aufgrund oben genannter Gründe gut möglich.
Jedoch existiert für Unreal Engine keine offizielle Lösung zur Anbindung an ROS2.
Die Programmierung der Engine erfolgt in C++, was die Erstellung eines Plugins zur ROS-Anbindung der Unreal Engine ermöglichte, welche von Nutzern gewartet wird.
Die Programmierung der Engine erfolgt in C++, was die Erstellung eines Plugins zur ROS-Anbindung der Unreal Engine ermöglichte, die von Nutzern gewartet wird.
Die Lizenz der Unreal Engine erlaubt die kostenfreie Nutzung bis zu einem gewissen Umsatz mit der erstellten Software.
Eine weitere Möglichkeit zur Simulation stellt die Grafikengine Godot \cite{godot} dar.
Im Vergleich zu Unity und Unreal Engine ist Godot quelloffene Software unter der MIT-Lizenz.
Auch hier stellt die Simulation von menschlichen Aktoren eine Standartaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
Auch hier stellt die Simulation von menschlichen Aktoren eine Standardaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
Auch für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht offiziell.
Alle vorgestellten Softwares besitzten ein integriertes Physiksystem, welches die Simulation von starren Körpern und Gelenken erlaubt.
Aus diesen Funktionen kann ein Roboterarm aufgebaut werden, welcher dann durch eine ROS-Brücke gesteuert werden kann.
Alle vorgestellten Softwares besitzen ein integriertes Physiksystem, dass die Simulation von starren Körpern und Gelenken erlaubt.
Diese Funktionen erlauben den Aufbau eines Roboterarms, der durch eine ROS-Brücke gesteuert wird.
Um den Entwicklungsvorgang zu beschleunigen, ist die Auswahl einer Umgebung mit bereits existierender ROS-Unterstützung sinnvoll.
Durch diese Einschränkung scheiden sowohl Unreal Engine aber auch Godot aus, welche nur durch Nutzer unterstützt werden.
Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese in nahezu allen Umständen eingesetzt werden kann.
Um den Fokus dieser Arbeit auf die gestellte Aufgabe zu ermöglichen, ist die Auswahl einer Umgebung mit bereits existierender ROS-Unterstützung sinnvoll.
Durch diese Einschränkung scheiden sowohl Unreal Engine aber auch Godot aus.
Sie bieten zwar diese Funktionalität, jedoch werden sie nur durch Nutzer gewartet und sind demzufolge nicht offiziell unterstützt.
Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese einen Einsatz unter nahezu allen Umständen erlaubt.
Die Wahl der Simulationsumgebung fiel deshalb auf Gazebo Ignition, welches gleichzeitig bereits im ROS-Ökosystem etabliert ist.
Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
Die Wahl der hier zu verwendenden Simulationsumgebung fiel deshalb auf Gazebo Ignition, welche gleichzeitig bereits im ROS-Ökosystem etabliert ist.
Dabei erlauben die offizielle ROS-Anbindung und die offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
\subsection{Welt- und Modellbeschreibung}
Um die Simulationsumgebung zu beschreiben, nutzt Gazebo das .sdf-Dateiformat\cite{sdf-format}.
Gazebo nutzt das .sdf-Dateiformat, um die Simulationsumbebung zu beschreiben \cite{sdf-format}.
Dieses Format basiert auf XML und wird zur Definition gesamter Welten, aber auch einzelner Objekte innerhalb dieser Welten benutzt.
Eine Welt ist in Gazebo eine Umgebung aus mehreren Objekten, welche simuliert werden sollen.
Die Welt beschreibt außerdem die simulierte Physikumgebung und deren Konstanten, wie zum Beispiel die Gravitation.
Um verschiedene Versionen des Formats zu unterstützen, enthält das einzige sdf-Element die gewünschte Versionsnummer.
Eine solche Datei kann, wie bereits oben beschrieben, unterschiedliche Daten enthalten.
Im Falle eines Objekts ist dies eine einzige Instanz von entweder einem Modell, Actor oder Licht.
Andernfalls können in der Datei eine oder mehrere Welten definiert werden.
Eine Welt definiert in Gazebo den kompletten Aubau des Simulators.
Eine Welt definiert in Gazebo den kompletten Aufbau des Simulators.
Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten der Simulationsumgebung.
Außerdem werden alle benötigten Teile der Nutzeroberfläche deklariert, 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}.
Zudem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
Letztendlich ist die Definition mehrerer Modelle, Aktoren und Lichter in der Welt möglich.
Diese können auch aus anderen URIs stammen, die in der Welt deklariert wurden.
Dies erlaubt zum Beispiel das Laden von vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek \cite{gazebo-app}.
Ein Modell enthält einen Roboter oder ein anderes physikalisches Objekt in der Simulation.
Die Deklaration eines weiteren Untermodells ist möglich, um komplexere Strukturen abbilden zu können.
Über ein include-Element können auch andere .sdf-Dateien, welche nur ein Modell enthalten, zum Modell hinzugefügt werden.
Über ein include-Element können auch andere .sdf-Dateien, die nur ein einzelnes Modell enthalten, zu einem Modell hinzugefügt werden.
Jedes Modell wird über eine Translation und Rotation im Simulationsraum verankert, wobei das Referenzsystem des überliegenden Modells genutzt wird.
Jedes Modell wird über eine Translation und Rotation im Simulationsraum verankert.
Dies geschieht immer relativ zum Referenzsystem des überliegenden Modells.
Außerdem können im Modell Einstellungen für dessen Physiksimulation vorgenommen werden.
Ein Modell enhält meißt mindestens ein Link-Element, welches zur Darstellung von dessen Geometrie verwendet wird.
Ein Modell enthält meist mindestens ein Link-Element, dass zur Darstellung von dessen Geometrie verwendet wird.
Mehrere Link-Elemente können dabei mit der Welt oder anderen Link-Elementen über Joint-Elemente verbunden werden.
Diese Joint-Elemente können jedoch nicht von außerhalb gesteuert werden, was dieses Dateiformat ungeeignet für Roboterdefinitionen macht.
Diese Joint-Elemente können jedoch nicht von außerhalb gesteuert werden, was das Dateiformat ungeeignet für Roboterdefinitionen macht.
Lichter besitzen einen Lichttyp, welcher die Ausbreitung des Lichtes im Raum bestimmt.
Die erste Art ist direktionales Licht, welches parallel zur gewünschten Achse auftrifft, welches vor allem zur grundlegenden Raumausleuchtung genutzt werden kann.
Außerdem existieren noch Punktlichtquellen, welche von einer Position im Raum ausgehen und Spots, welche außerdem noch nur einen gewissen Winkel abdecken.
Lichter besitzen einen Lichttyp, der die Ausbreitung des Lichtes im Raum bestimmt.
Die erste Art ist direktionales Licht, dass parallel zur gewünschten Achse auftrifft.
Solche Lichter werden vor allem zur grundlegenden Raumausleuchtung genutzt.
Weiterhin sind Punktlichtquellen verfügbar, deren Licht von einer Position im Raum ausgeht.
Neben den Punktlichtquellen existieren auch noch Spots, die nur einen gewissen Winkel ausleuchten.
Die Actor-Komponente wird für animierte Modelle in der Simulation eingesetzt.
Sie besteht aus einem Namen für das Modell, einer Skin, welche das Aussehen des Modells definiert und mehreren Animationen.
Diese können durch in einem Skript definierte Trajectories ausgeführt werden, was eine einfache Simulation eines Menschen erlaubt.
Eine solche Befehlsfolge kann jedoch nicht von außerhalb der Simulation zur Laufzeit angepasst werden, was weitere Entwicklungsarbeit erforderlich macht.
Diese können durch in einem Skript definierte Trajectories ausgeführt werden, was eine einfache, aber statische, Simulation des Menschen erlaubt.
Eine solche Befehlsfolge kann nicht von außerhalb der Simulation zur Laufzeit angepasst werden.
Diese Funktionalität wurde im Rahmen der Arbeit hinzugefügt.
\subsection{Robotersimulation}
Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Simulationsumgebung beschrieben wird.
Gazebo und ROS nutzen hierfür .urdf-Dateien\cite{urdf-format}, welche auf XML basieren.
Für die Robotersimulation wird ein Modell des Roboters benötigt, in dem dieser für die Simulationsumgebung beschrieben wird.
Gazebo und ROS nutzen hierfür .urdf-Dateien \cite{urdf-format}, die auf XML basieren.
In diesen werden die einzelnen Glieder des Roboterarms und die verbindenden Gelenke beschrieben.
Jedes Glied des Modells besitzt eine Masse, einen Masseschwerpunkt und eine Trägheitsmatrix für die Physiksimulation in Gazebo.
@@ -206,14 +233,15 @@ Hierbei werden die Modelle für die Physiksimulation und das Aussehen des Robote
Gelenke werden separat von den Gliedern definiert und verbinden jeweils zwei Glieder miteinander.
Durch das Aneinanderreihen von mehreren Gliedern und Gelenken ist die Beschreibung eines beliebigen Roboteraufbaus möglich.
Jedes Gelenk besitzt eine Position und Rotation im Raum, um dessen Effekte, welche vom Gelenktyp abhängen, berechnen zu können.
Jedes Gelenk besitzt eine Position und Rotation im Raum.
Diese werden für die Berechnung der Effekte genutzt, die vom spezifischen Gelenktyp abhängen.
Aspekte wie Reibung und Dämpfung können auch hier für die Nutzung in der Physiksimulation beschrieben werden.
Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
\begin{description}
\item[freie Gelenke]
ermöglichen vollständige Bewegung in allen 6 Freiheitsgraden (Rotation und Translation). Sie stellen den normalen Zustand der Glieder zueinander dar.
\item[planare Gelenke]
erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden zum Beispiel für Bodenkollisionen eingesetzt.
erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden zum Beispiel für Oberflächen eingesetzt, auf welchen Objekte gleiten sollen.
\item[feste Gelenke]
sperren alle 6 Freiheitsgrade und werden häufig zur Fixierung von Objekten in einer Szene genutzt.
\item[kontinuierliche Gelenke]
@@ -221,169 +249,172 @@ Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
\item[drehbare Gelenke]
verhalten sich wie kontinuierliche Gelenke, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
\item[prismatische Gelenke]
ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Sie werden zur Umsetzung von Linearaktuatore in der Simulation verwendet.
ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Sie werden zur Umsetzung von Linearaktuatoren in der Simulation verwendet.
\end{description}
\subsection{Menschensimulation}
Gazebo besitzt bereits ein einfaches Animationssystem für bewegliche Aktoren, welches auch für Menschen nutzbar ist.
Für diesen existiert bereits ein Modell mit mehreren Animationen, welche allein abgespielt, oder an Bewegungen gekoppelt werden können.
Dadurch ist eine Laufanimation realisierbar, welche synchronisiert zur Bewegung abgespielt wird.
Gazebo besitzt bereits ein simples Animationssystem für bewegliche Aktoren, dass auch für Menschen nutzbar ist.
Für diesen existiert bereits ein Modell mit mehreren Animationen, die allein abgespielt, oder an Bewegungen gekoppelt werden können.
Dadurch ist zum Beispiel eine Laufanimation realisierbar, die synchronisiert zu einer Bewegung abgespielt wird.
Dies setzt jedoch voraus, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
Der Grund dafür ist auf die Definition der Pfade, welche die Bewegung auslösen, zurück zu führen.
Der Grund dafür ist auf die Definition der Pfade zurückzuführen, die Aktionen wie Bewegungen und Animationen auslösen.
Diese können nur als dem Actor untergeordnetes Element in der .sdf-Datei definiert werden, was Veränderungen zur Laufzeit ausschließt.
Durch diesen Umstand ist der somit realisierbare Simulationsumfang nicht ausreichend, um die gewünschten Szenarien abzubilden.
Durch diesen Umstand ist der damit realisierbare Simulationsumfang nicht ausreichend, um die gewünschten Szenarien abzubilden.
Um diese Einschränkung zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
Dieses System muss, wie im Konzept beschrieben, Steuerbefehle von außen empfangen, umsetzen und Feedback liefern können.
Dafür soll ein ROS Action-Server verwendet werden, welcher die Befehle entgegennimmt, unter konstantem Feedback ausführt und nach Erfolgreicher Ausführung den Empfang des nächsten Befehlts zulässt.
Dafür soll ein ROS Action-Server verwendet werden, der die Befehle entgegennimmt, unter konstantem Feedback ausführt und nach erfolgreicher Ausführung den Empfang des nächsten Befehls zulässt.
Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, 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.
Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, die konstant weiter entwickelt wird.
Dies vereinfacht die Wartung, da bei Updates der Simulationsumgebung nicht die Menschensimulation an den neuen Code angepasst werden muss.
\section{Roboterumgebung}
MoveIt2\cite{moveit-docs} ist das meist genutzte ROS2 Paket für Bewegungsplanung von Robotern.
Deshalb existiert viel Dokumentation für die zahlreichen Komponenten, was die Entwicklung erleichtert und zahlreiche direkte Integrationen mit anderen ROS-Paketen, wodurch diese einfacher zusammen genutzt werden können.
Diese Eigenschaften machen das Paket als Roboterumgebung für dieses Projekt extrem attraktiv.
MoveIt2 \cite{moveit-docs} ist das meist genutzte ROS2 Paket für die Bewegungsplanung von Robotern.
Deshalb existiert eine umfangreiche Dokumentation für die zahlreichen Komponenten, was die Entwicklung neuer Komponenten erleichtert.
Außerdem sind zahlreiche direkte Integrationen mit anderen ROS-Paketen verfügbar, was die Nutzung dieser zusammen mit MoveIt erlaubt.
Aufgrund dieser Eigenschaften ist MoveIt eine vorteilhafte Bewegungsplanungsumgebung für dieses Projekt.
MoveIt besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
Der Nutzer kann mit MoveIt auf verschiedenen Wegen Steuerbefehle für den Roboter absenden, welche durch die Software umgesetzt werden.
MoveIt besteht aus mehreren Komponenten, die in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
Der Nutzer kann mit MoveIt auf verschiedenen Wegen Steuerbefehle für den Roboter absenden, die durch die Software umgesetzt werden.
Die einfachste Art der Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files, welche durch einen mitgelieferten Setupassistenten für den Roboter generiert werden.
Die erste Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files möglich.
Diese wurden mit dem mitgelieferten Setupassistenten für den Roboter generiert.
Durch die Ausführung dieser Demo startet RViz, eine Test- und Visualisierungsumgebung für ROS.
Darin können Roboterbewegungen unter Zuhilfenahme von Markierungen in RViz geplant und ausgeführt werden.
In der Demo können Roboterbewegungen unter Zuhilfenahme von Markierungen in RViz geplant und ausgeführt werden.
Da sich eine solche Bewegungsplanung nur beschränkt zur Automatisierung durch Software eignet, müssen die der Demo zugrundeliegenden Schnittstellen genutzt werden.
Für die Sprache Python existierte für die Vorgängerversion MoveIt noch das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, welches aber für MoveIt2 noch nicht portiert wurde. \cite{moveitpython}
Da sich eine Bewegungsplanung in einer Nutzeroberfläche nur beschränkt zur Automatisierung durch Software eignet, müssen die der Demo zugrundeliegenden Schnittstellen genutzt werden.
Für die Sprache Python existierte für die Vorgängerversion von MoveIt das moveit_commander Paket, welches den Zugriff auf MoveIt in Python erlaubt, aber für MoveIt2 noch nicht portiert wurde \cite{moveitpython}.
Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt2 direkt zu interagieren.
Dabei kann sowohl die Planung und Ausführung von Bewegungen ausgelöst werden, aber auch Exklusionszonen eingerichtet werden.
Dabei können sowohl die Planung und die Ausführung von Bewegungen ausgelöst aber auch Exklusionszonen eingerichtet werden.
Außerdem können Objekte virtuell mit dem Roboter verbunden werden, wodurch sich diese in RViz mit dem Roboter bewegen.
Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden um einzelne Bereiche des Systems zu testen, jedoch ist so kein einfacher Zugriff auf erweiterte Optionen möglich.
Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, um einzelne Bereiche des Systems zu testen.
Um die durch den Setupassistenten generierten Informationen an MoveIt zu übergeben, wird intern ein RobotStatePublisher verwendet.
Dieser läd alle Daten des Robotermodells und gibt sie an andere Programme weiter, welche diese zur Laufzeit anfordern, unter diesen auch MoveIt selbst.
Dieser lädt alle Daten des Robotermodells und übergibt sie an andere Programme, die Roboterparameter zur Laufzeit anfordern, unter diesen auch MoveIt selbst.
Durch die vorher erwä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.
Durch die vorher erwähnte C++-API erhält die MoveGroup die Informationen über die gewünschte Bewegung.
Dabei können auch bestimmte Einschränkungen des Arbeitsraums, spezielle Trajektorien oder Limitierungen der Gelenke in der Planung berücksichtigt werden.
Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, die sich um den Roboter befinden.
Eine solche Erweiterung erlaubt die automatische Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, welcher durch die MoveGroup aufgerufen wird.
Die Planung der Bewegung wird durch einen der in MoveIt implementierten Solver realisiert, der durch die MoveGroup aufgerufen wird.
Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an die \code{ros_control} Controller des Roboters weitergegeben.
Diese Abstaktion erlaubt die Nutzung von sowohl simulierten, aber auch echten Robotern.
Hiefür kann einfach ein anderer \code{ros_control} Controller geladen werden, welcher entweder die simulierte oder echte Hardware ansteuert.
Diese Abstraktion erlaubt die Nutzung von sowohl simulierten, aber auch echten Robotern.
Dazu werden für echte und simulierte Roboter unterschiedliche ros_control Controller verwendet.
Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
Im Falle von Gazebo wird \code{ign_ros_control} genutzt, welches die benötigten \code{ros_control} Controller in die Simulation einbindet.
Im Falle von Gazebo wird \code{ign_ros_control} genutzt, dass die benötigten \code{ros_control} Controller in die Simulation einbindet.
Diese können dann wie normale Controller von \code{ros_control} genutzt werden.
Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} im Anhang visualisiert.
Der Ablauf der Bewegungsplanungspipeline von MoveIt ist im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
\section{Programmiersprache}
Als Programmiersprache kommen in ROS standartmäßig Python\cite{python} und C++\cite{cpp} zum Einsatz.
Diese beiden Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark in Funktionsumfang und Entwicklungsprozess.
Als Programmiersprache kommen in ROS standardmäßig Python \cite{python} und C++ \cite{cpp} zum Einsatz.
Beide Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark im Funktionsumfang und im Entwicklungsprozess.
Python ist eine interpretierte Skriptsprache, welche zu den hohen Programmiersprachen zählt.
Sie wird in ROS zum Beispiel in .launch.py-Dateien eingesetzt, welche den Start von Diensten in der Umgebung verwalten.
Python ist eine interpretierte Skriptsprache, die zu den hohen Programmiersprachen zählt.
Sie wird in ROS zum Beispiel in \code{.launch.py}-Dateien eingesetzt, die den Start von Diensten in der Umgebung verwalten.
Die Sprache kann aber auch für die Programmierung von Nodes innerhalb des ROS-Systems verwendet werden.
C++ hingegen ist eine kompillierte, statisch typisierte, maschinennahe Programmiersprache.
In ROS wird C++ für Code verwendet, welcher entweder häufig oder in zeitkritischen Szenarien ausgeführt wird.
Aus diesem Grund wird C++ in Nodes verwendet, welche schnell auf große Datenmengen reagieren müssen.
C++ hingegen ist eine kompilierte, statisch typisierte, maschinennahe Programmiersprache.
In ROS wird C++ für Code verwendet, der entweder häufig oder in zeitkritischen Szenarien ausgeführt wird.
Aus diesem Grund wird C++ in Nodes verwendet, die schnell auf große Datenmengen reagieren müssen.
Die Nutzung eines Kompilierers beschleunigt C++ deutlich im Vergleich zu Python, ist jedoch weniger geeignet für häufige Modifikation.
Dies ist vor allem in häufig geänderten Programmen ein Nachteil, welche dann wieder kompilliert werden müssten.
Dies ist vor allem in häufig geänderten Programmen ein Nachteil, die nach einer Änderung erneut kompiliert werden müssen.
Aus diesem Grund wird Python vor allem in .launch.py-Dateien verwendet, welche die Interaktion der anderen Programme in der Umgebung verwalten.
Um die gewünschten Funktionen für die Simulation umsetzen zu können, ist die Programmierung in C++ nötig.
Da zum Beispiel Gazebo-Plugins auf C++ als Programmiersprache ausgelegt sind, was die Nutzung anderer Sprachen stark erschwert.
Ein Grund dafür ist die hohe Geschwindigkeit, welche bei einer hohen Anzahl an Simulationsschritten pro Sekunde benötigt wird.
Außerdem kann MoveIt2 zur aktuellen Zeit nur mit C++ direkt gesteuert werden.
Um die gewünschten Funktionen für die Simulation umzusetzen ist die Verwendung der Programmiersprache C++ nahezu unumgänglich.
Zum Beispiel sind Gazebo-Plugins in C++ erstellt, was die Nutzung anderer Sprachen stark einschränkt.
Ein weiterer Grund für die Nutzung von C++ ist die hohe Geschwindigkeit, die bei einer hohen Anzahl von Simulationsschritten pro Sekunde benötigt wird.
Außerdem kann MoveIt2 derzeit nur mit C++ direkt gesteuert werden.
Die Verwendung von C++ für die zu entwickelnden Nodes erscheint deshalb aus oben genannten Gründen naheliegend.
In den Launch-Skripten wird jedoch Python verwendet werden, da hier die Vorteile einer Skriptsprache überwiegen.
\section{Behavior Trees}
Zur Verwaltung der Abläufe sollen BehaviorTrees genutzt werden, welche durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
Diese Bibliothek wurde in C++ geschrieben, und ist somit einfach in ROS und dem geplanten Konzept integrierbar.
Zur Verwaltung der Abläufe sollen Behavior Trees genutzt werden, die durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
Diese Bibliothek wurde in C++ geschrieben, und ist somit in ROS und dem geplanten Konzept integrierbar.
Es existieren aber auch viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen, welche im folgenden vorgestellt werden.
Es existieren viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen der Bibliothek, die im Folgenden vorgestellt werden.
\begin{description}
\item[Asynchrone Nodes]
sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese 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.
sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese in Form verschiedener Zustände der Nodes beim Konzept der Bibliothek mit bedacht wurden.
Dies resultiert in Nodes, die ohne spezielle Logik langanhaltende Aktionen ausführen können, ohne die Ausführung des Behavior Trees zu behindern.
\item[Reaktives Verhalten] ist ein neues Konzept, um die Handhabung von asynchronen Nodes zu vereinfachen.
Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, die die aktuell ausgeführte Aktion beeinflussen können.
Darunter fällt die Modifizierung von Parametern der Aktionen, aber auch der vollständige Abbruch einer Aktion durch äußere Einflüsse.
\item[Das .xml-Format der Behavior Trees] ermöglicht einen einfachen Austausch des Verhaltens, ohne die unterliegende Programme verändern zu müssen.
Dies ist vor allem in kompillierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompillierung bedürfen, was die Iterationszeit für Änderungen verbessert.
\item[Das .xml-Format der Behavior Trees] ermöglicht einen Austausch des Verhaltens, ohne die unterliegenden Programme verändern zu müssen.
Dies ist vor allem in kompilierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompilierung bedürfen, was die Iterationszeit für Änderungen verbessert.
\item[Plugins] können zum Start geladen werden, um weitere Nodes dem ausgeführten Programm hinzufügen zu können.
Dies vereinfacht die Erweiterung um neue Funktionen und das mehrfachen Nutzen von Code.
\item[Das Blackboard] ist eine Schicht, welche den Datenfluss zwischen den Nodes erlaubt.
Dies vereinfacht die Erweiterung um neue Funktionen und das mehrfache Nutzen von Code.
\item[Das Blackboard] ist eine Interaktionsebene, die den Datenfluss zwischen den Nodes erlaubt.
In diesem System kann unter Verwendung einer Zeichenkette als Identifikator ein Wert in Form einer Referenz hinterlegt werden.
Sogenannte Ports erlauben Nodes, Daten aus dem Blackboard zu lesen und auf dieses zu schreiben.
\item[Integriertes Logging] erlaubt es, Zustandsänderungen im Behavior Tree zu visualisieren, aufzunehmen und wieder abzuspielen.
Dies erleichtert das häufig schwierige Debuggen von Zustandsmaschienen erheblich, da das Verhalten genau untersucht werden kann.
Dies erleichtert das häufig schwierige Debuggen von Zustandsmaschinen erheblich, da das Verhalten genau untersucht werden kann.
\end{description}
BehaviorTrees werden in \code{BehaviorTree.CPP} als .xml-Dateien gespeichert.
Behavior Trees werden bei Verwendung von \code{BehaviorTree.CPP} in Form von .xml-Dateien gespeichert.
Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeports.
Ports können verwendet werden, um Nodes generischer zu gestalten.
Durch veränderbare Parameter im später erstellten Tree können Nodes ohne Programmänderung verändert werden.
Falls die Nodes mit Bedacht erstellt wurden, kann so auf viele spezialisierte Nodes verzichtet werden, da deren Funktionen aus einfacheren Nodes mit variablen Parametern abgebildet werden kann.
Falls die Nodes mit Bedacht erstellt wurden, kann so auf viele spezialisierte Nodes verzichtet werden.
Um dies zu ermöglichen, kann deren Funktion durch mehrere andere Nodes in einem Subtree mit Parametern abgebildet werden.
Diese in den Ports übertragenen Daten können sowohl aus einem String ausgelesen, aber auch aus dem sogenannten Blackboard entnommen werden.
Um die Übersetzung aus einem String zu ermöglichen, muss eine entsprechende Funktion implementiert werden, welche diesen String in den gewünschten Zieltyp übersetzt.
Viele einfache Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von BehaviorTree.Cpp bereits durch mitgelieferte Funktionen unterstützt.
Um die Übersetzung aus einem String zu ermöglichen, muss eine entsprechende Funktion implementiert werden, die einen String in den gewünschten Zieltyp übersetzt.
Viele primitive Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von Behavior Tree.Cpp bereits durch native Funktionen unterstützt.
Das Blackboard ist ein System, welches die Nutzung von Variablen als Parameter für Ports erlaubt.
Das Blackboard ist ein System, dass die Nutzung von Variablen als Parameter für Ports erlaubt.
Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeichert.
Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des Behavior Trees.
Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, welche zu komplexeren Strukturen zusammengesetzt werden können.
Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, die zu komplexeren Strukturen zusammengesetzt werden können.
Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich 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.
Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Gruppen von Nodes als sogenannte Subtrees abspeichern.
Diese bilden in ihrer Gesamtheit eine neue Node, die im Behavior Tree eingesetzt werden kann.
Um den Einsatz von Variablen innerhalb eines Subtrees zu ermöglichen, besitzt jeder Subtree ein separates Blackboard.
Dadurch kann auch ein Eingriff durch äußere Einflüsse verhindert werden.
Natürlich sollte es auch möglich sein, Variablen an solche SubTrees zu übergeben.
Diese können, wie auch bei normalen Nodes, 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.
Natürlich sollte es auch möglich sein, Variablen an solche Subtrees zu übergeben.
Diese können, wie auch bei normalen Nodes, als Parameter an den Subtree übergeben werden.
Die Bibliothek \code{BehaviorTree.CPP} verbindet dann diese Werte und erlaubt die Datenübergabe zum und vom Subtree.
\subsection{Asynchrone Nodes}
Da nicht jeder Prozess sofort vollständig durchgeführt werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
Dies geschieht in \code{BehaviorTree.CPP} durch asynchrone Nodes.
Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE einer normalen Node auch noch die beiden neuen Zustände RUNNING und IDLE.
Außerdem werden mehrere Funktionen definiert, welche den Lebenszyklus der Node darstellen.
Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE einer normalen Node auch die beiden neuen Zustände RUNNING und IDLE.
Außerdem werden mehrere Funktionen definiert, die den Lebenszyklus der Node definieren.
Wird eine Node durch den Aufruf der \code{onStart}-Funktion gestartet, geht diese in einen der Zustände RUNNING, SUCCESS oder FAILURE über.
Der Zustand RUNNING steht dabei für eine Node, 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 in der neuen \code{onRunning}-Funktion abgefragt.
Der Zustand RUNNING steht dabei für eine Node, die sich noch in der Ausführung befindet.
Solange dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand in der neuen \code{onRunning}-Funktion abgefragt.
Der IDLE-Zustand ist ein besonderer Zustand, welcher nur durch eine vollständige Ausführung erreichbar ist.
Der IDLE-Zustand ist ein besonderer Zustand, der nur durch eine vollständige Ausführung erreichbar ist.
Er wird von der Node angenommen, nachdem deren Ausführung durch SUCCESS oder FAILURE beendet wurde.
Im Falle eines Abbruchs, welcher durch andere Nodes im Baum ausgelöst werden könnte, muss die Ausführung der Node vorzeitig beendet werden.
Dies geschieht mit der neuen \code{onHalted}-Funktion, welche die Ausführung der Node abbrechen kann.
Im Falle eines Abbruchs, der durch andere Nodes im Baum ausgelöst werden könnte, muss die Ausführung der Node vorzeitig beendet werden können.
Dies geschieht mit der neuen \code{onHalted}-Funktion, welche ausgeführt wird, wenn die Ausführung der Node abgebrochen werden soll.
\subsection{Dateiformat}
Das in Behavior Tree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
Jedes Dokument beginnt dabei mit einem Root-Element, 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.
Jedes Dokument beginnt dabei mit einem Root-Element, dass alle Behavior Trees und eine Referenz auf die ID des Hauptbaumes enthält.
Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genutzt werden können, die aber sonst nicht vom Hauptbaum unterscheidbar sind.
Jeder Baum beginnt mit einem 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.
Jeder Baum beginnt mit einem Behavior Tree-Element, das als Attribut die ID des Baumes besitzen muss.
Als untergeordnete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
Zur besseren Visualisierung der XML-Struktur wurde hier die bereits aus dem Konzept bekannte Baumstruktur, hier noch einmal in Abbildung \ref{choice_tree_demo} zu sehen, umgewandelt.
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.
Als Beispiel wird der bereits im Konzept verwendete Behavior Tree (siehe Abbildung \ref{choice_tree_xml}) in die entsprechende XML-Repräsentation umgewandelt.
Dabei ist zu beachten, dass die Root-Node in der Datei nicht existiert, da diese nur den Eintrittspunkt in die Struktur darstellt.
Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber auch über den Namen Action mit ihrem Namen als ID-Parameter, referenziert werden.
\begin{figure}[hpt]
\includegraphics[width=\textwidth]{img/tree_demo}
\includegraphics[width=\textwidth]{img/MA-tree-demo}
\centering
\caption{Beispiel eines Behavior Trees}
\label{choice_tree_demo}
@@ -409,25 +440,41 @@ Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber au
\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 bereitstellt.
Dadurch wird die Inbetriebnahme von Anwendungen, welche spezielle Umgebungen für ihre Ausführung benötigen auf beliebigen Systemen ermöglicht.
\section{Virtualisierungsumgebung}
Dies wird durch den Einsatz von sogenannten Containern erreicht.
Ein solcher Container wird über sogenannte Build-Files definiert.
Ein Build-File enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.
Der so erstellte Container wird anhand dieser Definition durch den ausführenden Rechner erstellt.
Um diesen Prozess weiter zu beschleunigen, ist auch der Einsatz eines Buildservers möglich, welcher benötigte Container als Download bereitstellt.
Bei Virtualisierungsumgebungen wird zwischen virtuellen Maschinen und Containerumgebungen unterschieden.
Jeder Container enthält ein eigenes Dateisystem, welches aus dem im Buildfile definierten Dateien und einem Overlay besteht.
In diesem Overlay werden Änderungen gespeichert, welche am Container während der Laufzeit vorgenommen werden.
Bei einer virtuellen Maschine (VM) werden alle Komponenten der Maschine simuliert, was die Nutzung anderer Betriebssysteme ermöglicht.
Dies beinhaltet auch die Abstraktion von Speichermedien und anderen Geräten.
Eine virtualisierte Umgebung erzeugt kleine Performanceverluste durch die Abstraktion.
Eine Containerumgebung nutzt den Kernel des Hostsystems mit, was die Virtualisierung auf die Ebenen über dem Betriebssystem beschränkt.
Die auszuführende Umgebung muss also mit dem Systemkernel lauffähig sein, um in einem Container ausgeführt werden zu können.
Die Performanceverluste dieser Umgebung sind kleiner als die einer virtuellen Maschine, da grundlegende Teile des Systems nicht mehrfach ausgeführt werden müssen.
Da bereits eine Linux-Maschine zur Entwicklung vorhanden ist, wäre die Virtualisierung eines weiteren Linux-Kernels nur mit weiterem Performanceverlust verbunden.
Außerdem soll in der Virtualisierungsumgebung Grafikbeschleunigung genutzt werden, wozu in einer VM eine Grafikkarte an das Zielsystem durchgereicht wird, die dann von der VM exklusiv genutzt wird.
In einer Containerumgebung kann die Grafikeinheit des Hostsystems mit genutzt werden, indem das durch das Hostsystem bereits abstrahierte Gerät in den Container hereingereicht werden.
Diese Punkte sprechen für die Nutzung einer Containerumgebung.
Docker ist eine etablierte Umgebung für die Ausführung von Containern, die aufgrund der extensiven Dokumentation und Verfügbarkeit auf allen gängigen Linux-Systemen ausgewählt wurde.
Ein Container wird in Docker über sogenannte Build-Files definiert.
Das Build-File enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.
Der so erstellte Container wird anhand dieser Definition durch den Host erstellt.
Um diesen Prozess weiter zu beschleunigen, ist auch der Einsatz eines Buildservers möglich, der benötigte Container als Download bereitstellt.
Jeder Container enthält ein eigenes Dateisystem, das aus dem im Buildfile definierten Dateien und einem Overlay besteht.
In diesem Overlay werden temporär Änderungen gespeichert, die am Container während dessen Laufzeit vorgenommen werden.
Sofern nicht definiert, werden diese Änderungen beim Neustart des Containers wieder entfernt.
Um dies zu vermeiden, kann entweder ein Volume, eine Art virtuelles Laufwerk in einem Systemverzeichnis des Hostsystems, oder ein ``bind mount'' eingerichtet werden.
Ein ``bind mount'' ist eine direkte Verbindung zu einem Ort des Host-Dateisystems, welche in den Container hereingereicht wird.
Ein ``bind mount'' ist eine direkte Verbindung zu einem Ort des Host-Dateisystems, dass in den Container hereingereicht wird.
Docker-Compose stellt eine Erweiterung von Docker dar, 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''.
Docker-Compose stellt eine Erweiterung von Docker dar.
Diese Erweiterung verwaltet die Inbetriebnahme der Container über ein spezielles Dateiformat.
Eine solche Funktion erlaubt das wiederholte Einrichten von Containern mit gleichen Parametern.
In dieser Datei werden weitere Optionen angegeben, die in die Umgebung des laufenden Containers eingreifen.
Dazu gehört zum Beispiel das automatisierte Übergeben von Umgebungsvariablen, Einrichten von Netzwerkumgebungen und Erstellen von Volumes und ``bind mounts''.
Diese Automatisierung erleichtert die initiale Einrichtung eines Containers auf einem neuen System, da alle benötigten Aspekte leicht angepasst werden können.

File diff suppressed because it is too large Load Diff

View File

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

81
tex/6_Ausblick.tex Normal file
View File

@@ -0,0 +1,81 @@
\chapter{Ausblick}
\section{Umsetzung in anderem Simulator}
Die Umsetzung des gleichen Problems in einem anderen Simulator bietet die Möglichkeit, weitere Simulationsplattformen zu testen und miteinander zu vergleichen.
Hierbei ist vor allem die Anbindung an ROS interessant, welche mit Gazebo mit nur einem Plugin gleichzeitig funktioniert.
Eine verbesserte Anbindung an ROS würde die schnellere Entwicklung von Komponenten und Szenarien erlauben.
Da diese für viele andere Simulatoren erst geschaffen werden muss, kann von Anfang an der Fokus auf Erweiterbarkeit gelegt werden.
Je nach gewählter Umgebung ist es potenziell nötig, bestimmte Basisfunktionen neu zu implementieren, falls diese noch nicht unterstützt werden.
Moderne Gameengines sind für diesen Einsatzzweck geeignet, da diese viele Bestandteile einer Simulationsplattform bereits enthalten.
Außerdem ist die hohe Verfügbarkeit von Tutorials und Dokumentation für diese weitläufig eingesetzten Engines vorteilhaft.
Mitgelieferte Werkzeuge bekannter Engines wie Unity, Unreal Engine und Godot beinhalten ausgereifte Physik- und Animationssysteme.
Diese können für Roboterbewegungen und Menschensimulation verwendet werden.
\section{Simulation bewegter Objekte}\label{objectsim}
Die Simulation bewegter Objekte benötigt ein neues Gazebo-Plugin, welches mit den bereits entwickelten Komponenten der aktuellen Umgebung interagiert.
Um ein Objekt mit dem Roboter oder Menschen zu bewegen, muss dieses auf eine von zwei Arten bewegt werden.
Die Bewegung von Objekten mit dem Roboter ist möglich, da dieser mit der gegenwärtigen Implementation aus mehreren Physikobjekten besteht.
Das zu bewegende Objekt kann somit dem Objekt des Endeffektors als Unterobjekt hinzugefügt werden.
Der daraus resultierende Übergang in lokale Koordinaten kann potenzielle Umrechnung anhand der Transformationen vorhergehender Armteile erfordern.
Eine Bewegung mit dem Menschen erfordert vor allem bei Animationen einen anderen Mechanismus.
Da der Mensch nicht aus einzelnen Physikobjekten besteht, ist die Anbringung als Unterobjekt nicht möglich.
Stattdessen muss die aktuelle Position des Armes anhand der Animationsdaten verfolgt werden, um die Position des Objektes an diese anzupassen.
Die unterschiedliche Anbindung von Roboter und Mensch erfordert mehrere Implementationen, welche Zustandsdaten über das Objekt austauschen müssen.
Um die Objekte zu steuern, muss eine weitere ROS-Anbindung in einem entsprechenden Gazebo-Plugin erfolgen.
Dieses Plugin unterliegt denselben Limitierungen, die auch schon im ActorPlugin beachtet werden mussten.
Eine weitere Nachrichtenübergabe als Zwischenschritt vor dem eigentlichen ROS-Server ist so unausweichlich.
Dieser Kommunikationsmechanismus muss das Erstellen, Entfernen und Bewegen von Objekten zwischen Roboter, Umgebung und Mensch unterstützen.
\section{Erweiterung um Umgebungserkennung}
Eine Ergänzung von simulierten Tiefenkameras zur Umgebungserkennung stellt eine weitere mögliche Ausbaustufe des Projekts dar.
Mit den Kameras kann eine Tiefenkarte erstellt werden, um die Verfahrgeschwindigkeit des Roboters zu kontrollieren.
MoveIt implementiert für diesen Verwendungszweck bereits sogenannte Octomaps.
Diese Octomaps repräsentieren die Belegung eines Raums durch Objekte mit gleichseitigen Würfeln.
Der Einsatz dieser Octomaps zum Ausweichen von Hindernissen ist bereits in der Bewegungsplanung implementiert.
Für die Reduktion der Verfahrgeschwindigkeit muss der erwartete Raum mit dem aktuellen Raum verglichen werden.
Daraus kann die Distanz zu einem unerwarteten Objekt berechnet werden, um die Verfahrgeschwindigkeit dementsprechend anzupassen.
\section{Zusammenführung von ActorPlugin und ActorServer}
Die aktuelle, separate Implementation von ActorServer und ActorPlugin kann durch eine Vereinigung der Implementation verbessert werden.
Folgende Versuche wurden bereits durchgeführt, führten aber zu keinem Erfolg:
\begin{itemize}
\item{Die Ausführung in einem separaten Thread,}
\item{eine Trennung vom Hauptprogramm mittels Fork und}
\item{das Weglassen der Initialisierung von rclcpp, da diese später durch ign_ros2_control durchgeführt wird.}
\end{itemize}
\section{Migration auf die neuste ROS-Version}
Die neuste ROS-Version bietet keine expliziten Vorteile der Umgebung selbst, jedoch sind in dieser mehr Pakete verfügbar.
In der für das Projekt genutzten Umgebung befinden sich mehrere Pakete, die so auf eine neuere Version gebracht werden könnten.
Jedoch ist der Aufwand einer Migration nur schwer abschätzbar.
Dies führte zu der Entscheidung, diesen Prozess in dieser Arbeit nicht durchzuführen.
Ein Vorteil dieser Maßnahme ist die Möglichkeit, das Paket \code{gz_ros2_control} aus einer offiziellen Paketquelle zu beziehen.
Dieses Paket stellt das Gazebo-Plugin für den Roboter bereit und muss so nicht manuell auf dem neusten Stand gehalten werden.
\section{Verbesserung der Behavior Trees}
Eine weitere mögliche Verbesserung ist der Ausbau der Implementation der Behavior Trees.
Ein Update auf die neuste Version, die während der Entwicklung dieses Projektes erschienen ist, würde die verbesserte Nutzung von asynchronen Nodes erlauben.
Die Integration von Pre- und Post-Conditions erlaubt die Ausführung von Events vor und nach dem Ausführen einer Node.
Weitere universelle Node-Parameter vereinfachen den Aufbau von Bäumen durch die Vereinfachung von Schleifen und Bedingungen.
Ein Nachteil der Migration wäre jedoch das Wegfallen einiger Funktionen des Editors, welcher in dieser Version unter einer neuen Lizenz vertrieben wird.
Die Analyse von Logdateien nach der Ausführung und die Überwachung von Bäumen zur Laufzeit sind ohne kostenpflichtige Lizenz nicht mehr möglich.
Eine weitere Alternative ist die Nutzung von MoveIt Studio \cite{moveItStudio}, welches ebenfalls mit Behavior Trees arbeitet.
Die direkte Integration mit MoveIt vereinfacht die Anbindung an den Roboter, da wichtige Funktionen bereits implementiert sind.
Jedoch ist die Unterstützung für eigene Befehle nur schlecht dokumentiert.
Diese werden aber für die Steuerung des Menschen benötigt, was dieses Alternative nur für die Robotersteuerung attraktiv macht.
Die Anpassung der aktuellen Implementation für größere Projekte ist eine weitere Option.
Um die Übersichtlichkeit des Projekts zu erhöhen, werden häufig separate Module verwendet.
Diese können einzelne Funktionen bereitstellen, die separat von anderen Modulen agieren.
Alle Module müssen aktuell im Buildfile deklariert und mit in das Programm kompiliert werden.
Bei einer großen Anzahl an Modulen erschwert dieser Umstand die Übersicht über benötigte Module für spezifische Trees.

View File

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

View File

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

View File

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

39
uml/animation_states.puml Normal file
View File

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

2175
uml/out/animation_states.eps Normal file

File diff suppressed because it is too large Load Diff

View File

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

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 10 KiB

2007
uml/out/plugin_states.eps Normal file

File diff suppressed because it is too large Load Diff

14
uml/plugin_animation.puml Normal file
View File

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

Binary file not shown.

Before

Width:  |  Height:  |  Size: 25 KiB

View File

@@ -8,38 +8,30 @@ skinparam ArrowColor #404040
participant "ROS ActionClient" as client
participant ActorServer as server
participant ActorPlugin as plugin
note left of client: Protocol:
/note left of server: ros_action
/note left of plugin: MessageQueue
==Goal==
activate server
activate plugin
[-> client: create ActionClient
[-> client: neuer ActionClient
activate client
client -> server: goal request
server -->> client: goal response
client -> server: Zielvorgabe
server -->> client: Antwort auf Zielvorgabe
alt goal accepted
server ->> plugin: set state and target
plugin -->> server: state change
== Feedback==
group opt par [abort of current action]
client->server: abort request
server->plugin: set state to Idle
server-->>client: abort response
alt Zielvorgabe akzeptiert?
server ->> plugin: neuen Status und Ziel setzen
plugin -->> server: Zustandswechsel bei\nnächstem Simulationsschritt
group opt par [Abbruch der Aktion]
client->server: Abbruchanfrage
server->plugin: Status auf Idle setzen
plugin -->> server: Zustandswechsel auf Idle
server-->>client: positive Abbruchantwort
end
loop until action is completed or aborted
plugin -->> server: feedback
server -->> client: feedback callback
loop Bis Aktion vollständig ausgeführt oder abgebrochen ist
plugin -->> server: Feedback
server -->> client: Feedback
end
==Result==
plugin -->> server: state change
server -->> client: result callback
plugin -->> server: Zustandswechsel auf Idle
server -->> client: Endnachricht
end
destroy client
@enduml

37
uml/plugin_movement.puml Normal file
View File

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

21
uml/plugin_states.puml Normal file
View File

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

25
uml/subtree_deposit.puml Normal file
View File

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

Binary file not shown.

Before

Width:  |  Height:  |  Size: 17 KiB

View File

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

BIN
user.pdf

Binary file not shown.

Binary file not shown.