Compare commits
2 Commits
411b27ea28
...
330bce82ec
| Author | SHA1 | Date | |
|---|---|---|---|
| 330bce82ec | |||
| 00c864578a |
303
.gitignore
vendored
Normal file
303
.gitignore
vendored
Normal 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
|
||||||
@ -113,11 +113,11 @@ TextFolding={"checksum":"","ranges":[]}
|
|||||||
ViMarks=
|
ViMarks=
|
||||||
|
|
||||||
[view-settings,view=0,item:main.bib]
|
[view-settings,view=0,item:main.bib]
|
||||||
CursorColumn=1
|
CursorColumn=14
|
||||||
CursorLine=257
|
CursorLine=250
|
||||||
Dynamic Word Wrap=false
|
Dynamic Word Wrap=false
|
||||||
JumpList=
|
JumpList=
|
||||||
TextFolding={"checksum":"d388fe775e2de092b50ce9dbaa861869ee036db3","ranges":[]}
|
TextFolding={"checksum":"cf8b2614fde9a70da69bd9296f0dc1ae50c584e2","ranges":[]}
|
||||||
ViMarks=
|
ViMarks=
|
||||||
|
|
||||||
[view-settings,view=0,item:main.tex]
|
[view-settings,view=0,item:main.tex]
|
||||||
@ -137,27 +137,27 @@ TextFolding={"checksum":"052cc01250adb0f5e3ea2eff211696be3fc560ae","ranges":[]}
|
|||||||
ViMarks=
|
ViMarks=
|
||||||
|
|
||||||
[view-settings,view=0,item:tex/2_Konzept.tex]
|
[view-settings,view=0,item:tex/2_Konzept.tex]
|
||||||
CursorColumn=0
|
CursorColumn=73
|
||||||
CursorLine=115
|
CursorLine=8
|
||||||
Dynamic Word Wrap=false
|
Dynamic Word Wrap=false
|
||||||
JumpList=
|
JumpList=
|
||||||
TextFolding={"checksum":"462cd841a4ae5cfb2a0372ff60c2f3b89035b3ea","ranges":[]}
|
TextFolding={"checksum":"462cd841a4ae5cfb2a0372ff60c2f3b89035b3ea","ranges":[]}
|
||||||
ViMarks=
|
ViMarks=
|
||||||
|
|
||||||
[view-settings,view=0,item:tex/3_Auswahl.tex]
|
[view-settings,view=0,item:tex/3_Auswahl.tex]
|
||||||
CursorColumn=99
|
CursorColumn=49
|
||||||
CursorLine=364
|
CursorLine=422
|
||||||
Dynamic Word Wrap=false
|
Dynamic Word Wrap=false
|
||||||
JumpList=
|
JumpList=
|
||||||
TextFolding={"checksum":"9cca06e103193ebce1a74b19ba51648376b36a4b","ranges":[]}
|
TextFolding={"checksum":"f762ea508da691b2b7d6eed6f6ab298eb722fa32","ranges":[]}
|
||||||
ViMarks=
|
ViMarks=
|
||||||
|
|
||||||
[view-settings,view=0,item:tex/4_Umsetzung.tex]
|
[view-settings,view=0,item:tex/4_Umsetzung.tex]
|
||||||
CursorColumn=0
|
CursorColumn=0
|
||||||
CursorLine=452
|
CursorLine=97
|
||||||
Dynamic Word Wrap=false
|
Dynamic Word Wrap=false
|
||||||
JumpList=
|
JumpList=
|
||||||
TextFolding={"checksum":"dd8e7caf4d43ea72300c447784e10addb44c0e7e","ranges":[]}
|
TextFolding={"checksum":"0a72214ff4945abde5acc7ce77e1e946a152971f","ranges":[]}
|
||||||
ViMarks=
|
ViMarks=
|
||||||
|
|
||||||
[view-settings,view=0,item:tex/Einleitung.tex]
|
[view-settings,view=0,item:tex/Einleitung.tex]
|
||||||
|
|||||||
@ -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}
|
|
||||||
@ -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}
|
|
||||||
@ -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
|
|
||||||
|
|
||||||
Binary file not shown.
347
main.aux
347
main.aux
@ -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
546
main.bbl
@ -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
|
|
||||||
|
|
||||||
15
main.blg
15
main.blg
@ -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
|
|
||||||
27
main.lof
27
main.lof
@ -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
|
|
||||||
86
main.run.xml
86
main.run.xml
@ -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>
|
|
||||||
BIN
main.synctex.gz
BIN
main.synctex.gz
Binary file not shown.
22
main.tex
22
main.tex
@ -135,14 +135,14 @@ parskip=half,
|
|||||||
-Fehler durch fehlerhafte Config (Mal nachsehen, was das genau war)
|
-Fehler durch fehlerhafte Config (Mal nachsehen, was das genau war)
|
||||||
\subsection{Gazebo}
|
\subsection{Gazebo}
|
||||||
\subsubsection{Upgrade auf Ignition}
|
\subsubsection{Upgrade auf Ignition}
|
||||||
Gazebo ist zu diesem Zeitpunkt in mehreren, teilweise gleichnamigen Versionen verfügbar, welche sich jedoch grundlegend unterscheiden.
|
Gazebo ist zu diesem Zeitpunkt in mehreren, teilweise gleichnamigen Versionen verfügbar, die sich jedoch grundlegend unterscheiden.
|
||||||
Ein altes Projekt mit dem früheren Namen Gazebo, welches nun in Gazebo Classic umbenannt wurde,
|
Ein altes Projekt mit dem früheren Namen Gazebo, dass nun in Gazebo Classic umbenannt wurde,
|
||||||
die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
|
die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
|
||||||
die nächste Version, welche nur noch den Namen Gazebo tragen soll.
|
die nächste Version, die nur noch den Namen Gazebo tragen soll.
|
||||||
Dies ist darauf zurückzuführen, dass Gazebo Classic und Ignition eine Zeit lang gleichzeitig existierten, jedoch unterschiedliche Funktionen und interne Schnittstellen besitzen.
|
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.
|
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.
|
Dies ist am leichtesten an der geänderten Nutzeroberfläche sichtbar, die in Ignition nun modular ausgeführt ist.
|
||||||
Um dieses neue modulare System nutzen zu können, wurde das Dateiformat für die Simulationen angepasst.
|
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.
|
In diesem werden die benötigten Physikparameter, Nutzeroberflächen, Plugins und die Simulationswelt definiert.
|
||||||
|
|
||||||
@ -152,24 +152,24 @@ Danach kann die Welt Stück für Stück in das neue Format übertragen werden, w
|
|||||||
Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler während des Ladevorgangs im Log nicht weiter beschrieben werden.
|
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.
|
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.
|
Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, die auf ein Entity-Component-System umstellte, aber auch Veränderungen an den verwendeten Objekten innerhalb dieses Systems.
|
||||||
\subsubsection{Pluginarchitektur}
|
\subsubsection{Pluginarchitektur}
|
||||||
Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
|
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.
|
Jedoch existiert damit jedes Plugin im selben Prozess, was bei der Nutzung von Bibliotheken, die nicht für die mehrfache Nutzung im selben Prozess entsprechend ausgelegt wurden, zu Problemen führen kann.
|
||||||
|
|
||||||
Zur Kommunikation des ActorPlugins mit dem ROS-ActionServer wurde die benötigte Funktionalität vorerst im Plugin selbst implementiert.
|
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.
|
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.
|
Diese Tests verliefen vorerst erfolgreich, jedoch scheiterten sie bei der Integration des Robotermodells, dass über die \code{ros_control}-Integration ebenfalls \code{rclcpp} nutzt.
|
||||||
|
|
||||||
Um dieses Problem zu umgehen, sind mehrere Lösungsansätze denkbar.
|
Um dieses Problem zu umgehen, sind mehrere Lösungsansätze denkbar.
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[Separater Nachrichtendienst]
|
\item[Separater Nachrichtendienst]
|
||||||
Ein solcher losgelöster Dienst kann die Nachrichten mit einem anderen Programm auszutauschen, welches die Kommunikation nach außen übernimmt.
|
Ein solcher losgelöster Dienst kann die Nachrichten mit einem anderen Programm auszutauschen, dass die Kommunikation nach außen übernimmt.
|
||||||
\item[Nutzung der gleichen ROS-Instanz]
|
\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.
|
Um dem Problem zu begegnen, könnte auch eine globale ROS-Instanz von Gazebo verwaltet werden, die dann von den Plugins genutzt werden kann.
|
||||||
Dies könnte als ein Plugin realisiert werden, welches diese anderen Plugins zur Verfügung stellt, jedoch müssten die anderen Plugins zur Nutzung dieser Schnittstelle modifiziert werden.
|
Dies könnte als ein Plugin realisiert werden, dass diese anderen Plugins zur Verfügung stellt, jedoch müssten die anderen Plugins zur Nutzung dieser Schnittstelle modifiziert werden.
|
||||||
\item[Gazebo-ROS-Brücke]
|
\item[Gazebo-ROS-Brücke]
|
||||||
Die Gazebo-ROS-Brücke kann Nachrichten, welche in beiden Formaten definiert wurden, ineinander umwandeln.
|
Die Gazebo-ROS-Brücke kann Nachrichten, die in beiden Formaten definiert wurden, ineinander umwandeln.
|
||||||
Dies ermöglicht die Kommunikation über die Brücke als Mittelmann.
|
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.
|
Dabei müssten Anpassungen an der Architektur vorgenommen werden, da Gazebo kein Äquivalent zum ActionServer besitzt.
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|||||||
88
main.toc
88
main.toc
@ -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
|
|
||||||
@ -2,14 +2,14 @@
|
|||||||
\section{Motivation}
|
\section{Motivation}
|
||||||
Die Simulation von Maschinen wird im industriellen Umfeld immer beliebter, um deren Verhalten schon vor der eigentlichen Produktion zu testen.
|
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.
|
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.
|
Das Modell wird dann um die Maschine selbst erweitert, die Einfluss auf das System nimmt.
|
||||||
Die Veränderungen durch die Maschine werden nun analysiert, und erlauben Rückschlüsse auf die Funktion des Systems.
|
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.
|
Ein solches Modell kann nun für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
|
||||||
|
|
||||||
|
|
||||||
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 simulieren zu können.
|
||||||
Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf in der Simulation bereits vor deren Ausführung fest definiert werden muss.
|
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.
|
Dies erlaubt die Reproduktion des genauen Bewegungsablaufes, aber nicht verschiedene Variationen im gesamten Prozess, die 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.
|
Um eine solche Funktionalität bereitstellen zu können, muss der Bewegungsablauf von sowohl Roboter und Mensch zur Laufzeit der Simulation gesteuert werden.
|
||||||
|
|
||||||
Dies soll durch eine eingängliche Beschreibungssprache ermöglicht werden, die einfach erweitert und auf neue Szenarien angepasst werden kann.
|
Dies soll durch eine eingängliche Beschreibungssprache ermöglicht werden, die einfach erweitert und auf neue Szenarien angepasst werden kann.
|
||||||
@ -35,12 +35,14 @@ In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetz
|
|||||||
|
|
||||||
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 nicht gefunden werden.
|
||||||
|
|
||||||
\section{Welche Szenarien}
|
\section{Auswahl der 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.
|
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.
|
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders in Frage.
|
||||||
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.
|
Diese besitzen viele ähnliche Bestandteile, die jedoch in mehrere 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, die alle 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.
|
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 bei Annäherung des Menschen, um Kollisionen zu vermeiden.
|
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.
|
Der Mensch soll in diesem Szenario auch arbeiten, jedoch nur vereinzelt den Arbeitsbereich des Roboters betreten, um diesen zu beobachten.
|
||||||
|
|
||||||
@ -49,9 +51,9 @@ Außerdem werden grundlegende Aspekte der Simulation getestet, wie zum Beispiel
|
|||||||
|
|
||||||
Im zweiten Szenario prüft und sortiert der Roboter Teile und legt die guten Exemplare auf einem Fließband zur Weiterverarbeitung ab.
|
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.
|
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.
|
Auch hier soll der Mensch solange eigenständig arbeiten, bis der Roboter ein aussortiertes Teil ablegt, dass weiter transportiert werden muss.
|
||||||
|
|
||||||
Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in welchem Mensch und Roboter an der selben Aufgabe arbeiten.
|
Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in dem Mensch und Roboter an der selben Aufgabe arbeiten.
|
||||||
Hierbei soll eine Palette entladen werden, wobei der Roboter nicht jedes Objekt ausreichend manipulieren kann.
|
Hierbei soll eine Palette entladen werden, wobei der Roboter nicht jedes Objekt ausreichend manipulieren kann.
|
||||||
Dies resultiert in Problemen beim Aufheben, Transport und Ablegen der Objekte.
|
Dies resultiert in Problemen beim Aufheben, Transport und Ablegen der Objekte.
|
||||||
In diesen Fällen muss nun ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
|
In diesen Fällen muss nun ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
|
||||||
@ -59,5 +61,5 @@ Dieser soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren
|
|||||||
\section{Welcher Nutzen / Contributions}
|
\section{Welcher Nutzen / Contributions}
|
||||||
Durch diese Arbeit soll in zukünftigen Projekten die Möglichkeit geschaffen werden, konzeptionelle Probleme bei der Erstellung neuer Aufgabenbereiche eines Roboters frühzeitig durch Simulation erkennbar zu machen.
|
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.
|
Dazu ist eine schnelle Konfiguration von sowohl Roboter als auch Mensch auf unterschiedliche Szenarien nötig, die 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.
|
Durch deren einfache Struktur soll komplexes Verhalten einfach und überschaubar definierbar sein, dass dann in der Simulation getestet werden kann.
|
||||||
|
|||||||
@ -3,7 +3,7 @@ Die zu entwickelnde Simulation soll die bisher meißt separaten Zweige der Robot
|
|||||||
Um die beiden Akteure in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
|
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.
|
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.
|
Hierfür wird die Beschreibungssprache in der Dienstumgebung ausgeführt, in der auch die Bewegungsplanung stattfindet.
|
||||||
Die Beschreibungssprache kommuniziert direkt mit der Simulation und Bewegungsplanung des simulierten Menschen.
|
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.
|
Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen diesen auch Nachrichten ausgetauscht.
|
||||||
Der gesamte Vorgang ist in Abbildung \ref{concept_overview} visualisiert.
|
Der gesamte Vorgang ist in Abbildung \ref{concept_overview} visualisiert.
|
||||||
@ -22,7 +22,7 @@ Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
|
|||||||
\section{Simulation des Roboters}
|
\section{Simulation des Roboters}
|
||||||
Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
|
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.
|
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.
|
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 Portemanteau aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
|
Die Bezeichnung als Cobot\cite{cobot} ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
|
||||||
Der Roboter besitzt auch einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
|
Der Roboter besitzt auch einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
|
||||||
|
|
||||||
@ -40,31 +40,31 @@ 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.
|
Es werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.
|
||||||
|
|
||||||
Die so erstellten Animationen müssen nun von außerhalb der Simulationsumgebung ausführbar gemacht werden, um diese später mit einer Beschreibungssprache steuern zu können.
|
Die so erstellten Animationen müssen nun von außerhalb der Simulationsumgebung ausführbar gemacht werden, um diese später mit einer Beschreibungssprache steuern zu können.
|
||||||
Hierfür muss eine Komponente entwickelt werden, welche in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
|
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, müssen diese Anfragen im Fortschritt überwacht und abgebrochen werden können.
|
Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Anfragen im Fortschritt überwacht und abgebrochen werden können.
|
||||||
|
|
||||||
\section{Behavior Trees als Beschreibungssprache}
|
\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.
|
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.
|
Diese besitzen jedoch einen großen Nachteil, der vor allem bei komplexeren Abläufen hervortreten kann.
|
||||||
Dabei handelt es sich um die Übersichtlichkeit, welche bei einer wachsenden State-Machine leicht verloren geht.
|
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.
|
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.
|
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}
|
Ursprünglich wurde das Konzept von Rodney Brooks entwickelt, der 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}
|
Das System setzte sich jedoch erst später in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten durch. \cite{isla2005handling}
|
||||||
|
|
||||||
Der Ablauf eines Behavior Trees startet vom sogenannten Root, der Wurzel des Baums.
|
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.
|
Von dort an werden Nodes, die je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
|
||||||
Die Nodes werden untereinander angeordnet, welches die Relation der Nodes zueinander beschreibt.
|
Die Nodes werden untereinander angeordnet, dass die Relation der Nodes zueinander beschreibt.
|
||||||
Jede Node ist entweder direkt unter der Root-Node oder einer anderen Node angeordnet.
|
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.
|
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 können.
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[Aktions-Nodes]
|
\item[Aktions-Nodes]
|
||||||
beschreiben einzelne ausführbare Aktionen, die das System beeinflussen können.
|
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]
|
\item[Dekorations-Nodes]
|
||||||
können den Rückgabewert einer anderen Node modifizieren.
|
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.
|
Häufig existieren hier die Negation, aber auch das forcieren eines bestimmten Rückgabewertes für die unterliegende Node.
|
||||||
@ -87,7 +87,7 @@ Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unters
|
|||||||
|
|
||||||
Das in Abbildung \ref{concept_tree_demo} visualisierte Beispiel zeigt die Abfolge, um eine Tür zu öffnen und zu durchschreiten.
|
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.
|
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.
|
Von dort an 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.
|
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.
|
Daraus resultierend wird als erstes die linke Node ausgeführt, diese ist jedoch eine Fallback-Node mit weiteren untergeordneten Nodes.
|
||||||
@ -97,28 +97,28 @@ 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.
|
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.
|
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.
|
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, welcher die Ausführung der Sequenz abbricht.
|
Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet, der 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.
|
Diese würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.
|
||||||
|
|
||||||
Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich so einfach neue Verhalten implementieren.
|
Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich so einfach neue Verhalten implementieren.
|
||||||
Dies erlaubt die schnelle Anpassung des Verhaltens der gesteuerten Systeme.
|
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.
|
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}
|
\section{Virtualisierungsumgebung als Platform}
|
||||||
Aufgrund von vorheriger Erfahrung mit involvierten Einrichtungsprozessen, ist der Einsatz fest definierter Umgebungen unerlässlich.
|
Aufgrund von vorheriger Erfahrung mit involvierten Einrichtungsprozessen, ist der Einsatz fest definierter Umgebungen unerlässlich.
|
||||||
Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in der das zu entwerfende System ausgeführt wird.
|
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.
|
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 alle Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
|
Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da alle Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
|
||||||
|
|
||||||
Ein weiterer Vorteil ist die beschleunigte Entwicklung, da Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
|
Ein weiterer Vorteil ist die beschleunigte Entwicklung, da Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
|
||||||
Hinzu kommt die einfachere Inbetriebnahme eines bereits entwickelten Systems, da keine Anpassungen am Hostsystem vorgenommen werden müssen.
|
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.
|
Natürlich existieren auch Nachteile der Virtualisierung, die mit den Vorteilen abgewogen werden müssen.
|
||||||
Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, welche der virtualisierten Anwendung nicht mehr zur Verfügung steht.
|
Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, die 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.
|
Außerdem muss bei grafischen Systemen bedacht werden, wie die darzustellenden Daten vom Hostsystem angezeigt werden können.
|
||||||
|
|
||||||
Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung stellt einen wichtigen Schritt in der Entwicklung des Gesamtsystems dar.
|
Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung stellt einen wichtigen Schritt in der Entwicklung des Gesamtsystems dar.
|
||||||
|
|||||||
@ -4,48 +4,55 @@ Diese Entscheidungen beeinflussen die späteren Entwicklungsprozess nachhaltig.
|
|||||||
|
|
||||||
Im nachfolgenden findet die Auswahl der Komponenten statt.
|
Im nachfolgenden findet die Auswahl der Komponenten statt.
|
||||||
Diese sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
|
Diese sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
|
||||||
Alle diese Teilbereiche können dann zu einer Simulation vebunden werden, welche das gesamte Problemfeld abdeckt.
|
Alle diese Teilbereiche können dann zu einer Simulation vebunden werden, die das gesamte Problemfeld abdeckt.
|
||||||
|
|
||||||
Wie bereits in Abbildung \ref{concept_overview} dargestellt, ist für die Erfüllung der Aufgaben eine Dienst- und eine Simulationsumgebung erforderlich.
|
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 der in diesen laufenden Prozesse.
|
||||||
\section{Dienstumgebung}
|
\section{Dienstumgebung}
|
||||||
Die Dienstumgebung bestimmt maßgeblich, wie Software im Entwicklungsprozess geschrieben wird.
|
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.
|
Bei einer Dienstumgebung für Roboter gehört die Nachrichtenübergabe zwischen einzelen Programmen zu den grundlegenden Aspekten.
|
||||||
Außerdem sind Werkzeuge zur Einstellungsübergabe an Teilsysteme sinnvoll, um diese einfach an einer Stelle anpassen zu können.
|
Diese wird genutzt, um eine gemeinsame Basis für ein erweiterbares System zu schaffen.
|
||||||
|
Außerdem sind Werkzeuge zur Einstellungsübergabe an Teilsysteme sinnvoll, um diese an einer Stelle anpassen zu können.
|
||||||
|
|
||||||
\subsection{Auswahl}
|
\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.
|
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.
|
Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist ein potentieller Kanidat für ein Roboterframework.
|
||||||
|
|
||||||
Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition der Nachrichten, welche über das System ausgetauscht werden.
|
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.
|
Nutzbare, bereits als Interprozesskommunikation integrierte Systeme sind zum Beispiel Pipes, die Daten zwischen Prozessen über Buffer austauschen.
|
||||||
Auch die Nutzung von Message Queues und Shared Memory ist hierfür denkbar.
|
Auch die Nutzung von Message Queues 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.
|
Diese Systeme sind performant, jedoch schwerer zu verwalten.
|
||||||
|
Ein Problem dieser Methoden ist die direkte Kommunikation mehrerer Komponenen.
|
||||||
|
Diese Art der Kommunikation sieht keine Modifikation von Nachrichten zur Anpassung an andere Szenarien vor.
|
||||||
|
|
||||||
Eine Alternative stellen Sockets dar, welche Daten zwischen mehreren Programmen austauschen können.
|
Eine Alternative stellen Sockets dar, die Daten zwischen mehreren Programmen austauschen können.
|
||||||
Dabei dient ein Programm als Server, welches Anfragen von anderen Programmen, auch Clients genannt, entgegen nimmt.
|
Dabei dient ein Programm als Server, dass Anfragen von anderen Programmen, auch Clients genannt, entgegen nimmt.
|
||||||
Die Kommunikation zwischen Client und Server ist bidirektional möglich, was kompliziertere Protokolle ermöglicht.
|
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.
|
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.
|
Dieser Nachteil besteht in der potentiellen Variabilität dieser Kommunikationsmechanismen.
|
||||||
Bei einem ausreichend großen Projekt treten so unweigerlich Unterschiede in der Handhabung auf, die es zu berücksichtigen gilt.
|
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.
|
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.
|
Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standartisierte und erweiterbare Nachrichtendefinition gelöst, die von den Programmen in der Umgebung genutzt werden.
|
||||||
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.
|
Um diese Nachrichten zu senden und empfangen liefert ROS eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
|
||||||
|
Für zum Beispiel Python\cite{python}, C und C++\cite{cpp} existieren die Implementationen in den Paketen \code{rospy}, \code{rclc} und \code{rclcpp}.
|
||||||
|
|
||||||
Die neuste Version ROS2 bietet dabei einige Verbesserungen im Vergleich zu früheren Version ROS1.
|
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.
|
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.
|
Außerdem werden nun neben CMake\cite{cmake} auch andere Buildsysteme unterstützt, was zum Beispiel die Verwendung von Python erlaubt.
|
||||||
|
|
||||||
Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
|
Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
|
||||||
Vor allem die unzähligen ROS-Bibliotheken, welche von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
|
Vor allem die unzähligen ROS-Bibliotheken, die von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
ROS kann für simulierte Umgebungen, aber 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.
|
%-Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
|
||||||
%-ROS2
|
%-ROS2
|
||||||
@ -53,62 +60,76 @@ ROS kann für sowohl simulierte Umgebungen, aber auch für echte Roboter eingese
|
|||||||
%-LCM
|
%-LCM
|
||||||
%-ZeroMQ
|
%-ZeroMQ
|
||||||
\subsection{Beschreibung}
|
\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}, später auch 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.
|
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.
|
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.
|
Zu den Aufgaben von ROS zählen folgende Teilbereiche:
|
||||||
In dieser befindet sich eine in XML verfasste Definition des Paketinhalts, welche verschiedene Aspekte des Pakets beschreibt.
|
\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 den das Paket selbt, wie dessen Name, Beschreibung und Version.
|
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.
|
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.
|
Um das Paket später korrekt ausführen zu können, sind benötigte Pakete für den Kompiliervorgang und Ausführung des Pakets eingetragen.
|
||||||
|
|
||||||
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:
|
|
||||||
\begin{description}
|
|
||||||
\item[Buildumgebung]\hfill \\
|
\item[Buildumgebung]\hfill \\
|
||||||
ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
|
ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
|
||||||
Zu deren Konfiguration werden CMake\cite{cmake} und einige Erweiterungen, wie zum Beispiel das oben erwähnte \code{ament_cmake} eingesetzt.
|
Zu deren Konfiguration wird eine \code{CMakeLists.txt}-Datei erstellt, die den Buildprozess beschreibt.
|
||||||
Anhand dieser Dateien werden die fertiggestellten Pakete dann im Workspace installiert, damit diese später verwendet werden können.
|
In dieser sind die Buildinstruktionen für den Kompiler für die im Paket befindlichen Programme enthalten.
|
||||||
|
Der Aufruf des \code{ament_cmake}-Makros in dieser ergänzt den Kompiliervorgang um weitere Parameter aus der \code{package.xml}-Datei.
|
||||||
|
|
||||||
|
Nach diesen Vorbereitungsschritten kann CMake das Paket kompillieren.
|
||||||
|
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 \\
|
\item[Workspaceverwaltung]\hfill \\
|
||||||
Pakete können in verschiedenen Verzeichnissen installiert werden und müssen für andere Pakete auffindbar sein.
|
Gruppen von Paketen befinden sich in sogenannen ``Workspaces''.
|
||||||
ROS nutzt hierfür von colcon generierte Skripte, welche beim Erstellen eines Pakets und eines Workspaces mit angelegt werden.
|
Diese vereinfachen das auffinden der enthaltenen Pakete durch Skripte, die diese im System registrieren.
|
||||||
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.
|
Die Erstellung der Skripte erfolgt anhand der bereits beschriebenen \code{CMakeLists.txt}-Datei.
|
||||||
|
Das Programm \code{colcon} analysiert diese und generiert die Skripte.
|
||||||
|
Um das Paket im System zu registrieren, muss der Nutzer die generierten Skripte ausführen, was die benötigten Umgebungsvariablen setzt.
|
||||||
|
Hierfür wird meißt ein weiteres Skript verwendet, was alle im Workspace befindlichen Pakete nacheinander der Umgebung hinzufügt.
|
||||||
|
|
||||||
|
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 \\
|
\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.
|
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 vermeiden Abstürze und undefiniertes Verhalten in der Ausführung von Nodes, die diese benötigen.
|
||||||
|
|
||||||
\item[Datenübertragung]\hfill \\
|
\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 sie 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.
|
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.
|
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.
|
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 \\
|
\item[Parameterübergabe]\hfill \\
|
||||||
Um Nodes auf neue Anwendungsfälle anpassen zu können, wird ein Konfigurationsmechanismus benötigt.
|
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.
|
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 einem Robotermodell, aber auch um die Topics der Nodes umbenennen zu 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 nötig werden, was auch mit einen Parameter erfolgen kann.
|
||||||
|
|
||||||
\item[Startverwaltung]\hfill \\
|
\item[Startverwaltung]\hfill \\
|
||||||
In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
|
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}
|
\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.
|
|
||||||
|
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 (Gazebo)}
|
\section{Simulationsumgebung (Gazebo)}
|
||||||
|
|
||||||
@ -122,10 +143,11 @@ Eine Auswahl der als Simulationsumgebung in Frage kommenden Programme werden hie
|
|||||||
CoppeliaSim\cite{coppelia}, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
|
CoppeliaSim\cite{coppelia}, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
|
||||||
Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
|
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.
|
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.
|
CoppeliaSim existiert in 3 Versionen, die sich im Funktionsumfang 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 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.
|
Gazebo setzt wie CoppeliaSim auf Erweiterungen, die die gewünschten Funktionen einbinden können.
|
||||||
Zum Beispiel existiert auch eine ROS-Brücke, welche die Anbindung an ROS ermöglicht.
|
Zum Beispiel existiert auch eine ROS-Brücke, welche die Anbindung an ROS ermöglicht.
|
||||||
Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
|
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.
|
||||||
@ -135,12 +157,12 @@ Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das off
|
|||||||
Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
|
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.
|
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.
|
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.
|
Ein großer Nachteil hingegen ist die Lizenz, die nur für Einzelpersonen kostenlos ist.
|
||||||
|
|
||||||
Die Unreal Engine\cite{unreal} ist wie Unity eine Grafikengine aus dem Spielebereich.
|
Die Unreal Engine\cite{unreal} ist wie Unity eine Grafikengine aus dem Spielebereich.
|
||||||
Auch hier ist die Menschensimulation aufgrund oben genannter Gründe gut möglich.
|
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.
|
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.
|
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.
|
Eine weitere Möglichkeit zur Simulation stellt die Grafikengine Godot\cite{godot} dar.
|
||||||
@ -148,14 +170,15 @@ Im Vergleich zu Unity und Unreal Engine ist Godot quelloffene Software unter der
|
|||||||
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 Standartaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
|
||||||
Auch für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht offiziell.
|
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.
|
Alle vorgestellten Softwares besitzten ein integriertes Physiksystem, dass 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.
|
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.
|
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.
|
Durch diese Einschränkung scheiden sowohl Unreal Engine aber auch Godot aus.
|
||||||
Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese in nahezu allen Umständen eingesetzt werden kann.
|
Diese bieten zwar diese Funktionalität, jedoch wird diese nur durch Nutzer gewartet und ist demzufolge nicht offiziell unterstützt.
|
||||||
|
Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese einen Einsatz in nahezu allen Umständen erlaubt.
|
||||||
|
|
||||||
Die Wahl der Simulationsumgebung fiel deshalb auf Gazebo Ignition, welches gleichzeitig bereits im ROS-Ökosystem etabliert ist.
|
Die Wahl der Simulationsumgebung fiel deshalb auf Gazebo Ignition, dass gleichzeitig bereits im ROS-Ökosystem etabliert ist.
|
||||||
Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
|
Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
|
||||||
\subsection{Welt- und Modellbeschreibung}
|
\subsection{Welt- und Modellbeschreibung}
|
||||||
Um die Simulationsumgebung zu beschreiben, nutzt Gazebo das .sdf-Dateiformat\cite{sdf-format}.
|
Um die Simulationsumgebung zu beschreiben, nutzt Gazebo das .sdf-Dateiformat\cite{sdf-format}.
|
||||||
@ -168,25 +191,28 @@ 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 Aubau des Simulators.
|
||||||
Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten der Simulationsumgebung.
|
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.
|
Außerdem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
|
||||||
Letzendlich können auch mehrere Modelle, Aktoren und Lichter in der Welt definiert werden.
|
Letzendlich ist auch die Definition mehrerer Modelle, Aktoren und Lichter in der Welt möglich.
|
||||||
Diese können auch aus anderen URIs stammen, welche in der Welt deklariert wurden.
|
Diese können auch aus anderen URIs stammen, die in der Welt deklariert wurden.
|
||||||
Dies erlaubt das Laden von zum Beispiel vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek\cite{gazebo-app}.
|
Dies erlaubt das Laden von zum Beispiel vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek\cite{gazebo-app}.
|
||||||
|
|
||||||
Ein Modell enthält einen Roboter oder ein anderes physikalisches Objekt in der Simulation.
|
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.
|
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.
|
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 enhält meißt 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.
|
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 dieses Dateiformat ungeeignet für Roboterdefinitionen macht.
|
||||||
|
|
||||||
Lichter besitzen einen Lichttyp, welcher die Ausbreitung des Lichtes im Raum bestimmt.
|
Lichter besitzen einen Lichttyp, der 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.
|
Die erste Art ist direktionales Licht, dass parallel zur gewünschten Achse auftrifft.
|
||||||
Außerdem existieren noch Punktlichtquellen, welche von einer Position im Raum ausgehen und Spots, welche außerdem noch nur einen gewissen Winkel abdecken.
|
Solche Lichter werden vor allem zur grundlegenden Raumausleuchtung genutzt.
|
||||||
|
Außerdem existieren noch Punktlichtquellen, die von einer Position im Raum ausgehen.
|
||||||
|
Neben den Punklichtquellen existieren auch noch Spots, die außerdem noch nur einen gewissen Winkel ausleuchten.
|
||||||
|
|
||||||
Die Actor-Komponente wird für animierte Modelle in der Simulation eingesetzt.
|
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.
|
Sie besteht aus einem Namen für das Modell, einer Skin, welche das Aussehen des Modells definiert und mehreren Animationen.
|
||||||
@ -194,8 +220,8 @@ Diese können durch in einem Skript definierte Trajectories ausgeführt werden,
|
|||||||
Eine solche Befehlsfolge kann jedoch nicht von außerhalb der Simulation zur Laufzeit angepasst werden, was weitere Entwicklungsarbeit erforderlich macht.
|
Eine solche Befehlsfolge kann jedoch nicht von außerhalb der Simulation zur Laufzeit angepasst werden, was weitere Entwicklungsarbeit erforderlich macht.
|
||||||
|
|
||||||
\subsection{Robotersimulation}
|
\subsection{Robotersimulation}
|
||||||
Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Simulationsumgebung beschrieben wird.
|
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}, welche auf XML basieren.
|
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.
|
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.
|
Jedes Glied des Modells besitzt eine Masse, einen Masseschwerpunkt und eine Trägheitsmatrix für die Physiksimulation in Gazebo.
|
||||||
@ -206,7 +232,8 @@ 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.
|
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.
|
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.
|
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:
|
Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
|
||||||
\begin{description}
|
\begin{description}
|
||||||
@ -224,35 +251,37 @@ Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
|
|||||||
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 Linearaktuatore in der Simulation verwendet.
|
||||||
\end{description}
|
\end{description}
|
||||||
\subsection{Menschensimulation}
|
\subsection{Menschensimulation}
|
||||||
Gazebo besitzt bereits ein einfaches Animationssystem für bewegliche Aktoren, welches auch für Menschen nutzbar ist.
|
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, welche allein abgespielt, oder an Bewegungen gekoppelt werden können.
|
Für diesen existiert bereits ein Modell mit mehreren Animationen, die allein abgespielt, oder an Bewegungen gekoppelt werden können.
|
||||||
Dadurch ist eine Laufanimation realisierbar, welche synchronisiert zur Bewegung abgespielt wird.
|
Dadurch ist eine Laufanimation realisierbar, die synchronisiert zu einer Bewegung abgespielt wird.
|
||||||
|
|
||||||
Dies setzt jedoch voraus, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
|
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ück zu führen, die Aktionen wie Bewegungen und Animationen auslösen können.
|
||||||
Diese können nur als dem Actor untergeordnetes Element in der .sdf-Datei definiert werden, was Veränderungen zur Laufzeit ausschließt.
|
Diese können nur als dem Actor untergeordnetes Element in der .sdf-Datei definiert werden, was Veränderungen zur Laufzeit ausschließt.
|
||||||
Durch diesen Umstand ist der somit realisierbare Simulationsumfang nicht ausreichend, um die gewünschten Szenarien abzubilden.
|
Durch diesen Umstand ist der somit 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.
|
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.
|
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 Befehlts zulässt.
|
||||||
|
|
||||||
Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, welche konstant weiter entwickelt wird.
|
Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, die konstant weiter entwickelt wird.
|
||||||
Dies erlaubt die einfachere Wartung, da bei Updates der Simulationsumgebung nicht die Menschensimulation an den neuen Code angepasst werden muss.
|
Dies vereinfacht die Wartung, da bei Updates der Simulationsumgebung nicht die Menschensimulation an den neuen Code angepasst werden muss.
|
||||||
\section{Roboterumgebung}
|
\section{Roboterumgebung}
|
||||||
MoveIt2\cite{moveit-docs} ist das meist genutzte ROS2 Paket für Bewegungsplanung von Robotern.
|
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.
|
Deshalb existiert viel Dokumentation für die zahlreichen Komponenten, was die Entwicklung neuer Komponenten erleichtert.
|
||||||
Diese Eigenschaften machen das Paket als Roboterumgebung für dieses Projekt extrem attraktiv.
|
Außerdem sind zahlreiche direkte Integrationen mit anderen ROS-Paketen verfügbar, was das Nutzen dieser mit MoveIt zusammen erlaubt.
|
||||||
|
Diese Eigenschaften machen das MoveIt als Bewegungsplanungsumgebung für dieses Projekt extrem attraktiv.
|
||||||
|
|
||||||
MoveIt besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
|
MoveIt besteht aus meheren Komponmenten, die 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.
|
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 moglich.
|
||||||
|
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.
|
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 dieser 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.
|
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}
|
Für die Sprache Python existierte für die Vorgängerversion MoveIt noch das moveit_commander Paket, dass den Zugriff auf MoveIt in Pyhon erlaubt, dass 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.
|
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 kann sowohl die Planung und Ausführung von Bewegungen ausgelöst werden, aber auch Exklusionszonen eingerichtet werden.
|
||||||
@ -260,7 +289,7 @@ Außerdem können Objekte virtuell mit dem Roboter verbunden werden, wodurch sic
|
|||||||
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, jedoch ist so kein einfacher Zugriff auf erweiterte Optionen möglich.
|
||||||
|
|
||||||
Um die durch den Setupassistenten generierten Informationen an MoveIt zu übergeben, wird intern ein RobotStatePublisher verwendet.
|
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äd alle Daten des Robotermodells und gibt sie an andere Programme weiter, 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.
|
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.
|
Dabei können auch bestimmte Einschränkungen des Arbeitsraums, spezielle Trajektorien, oder Limitierungen der Gelenke in der Planung berücksichtigt werden.
|
||||||
@ -268,14 +297,14 @@ Dabei können auch bestimmte Einschränkungen des Arbeitsraums, spezielle Trajek
|
|||||||
Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, die sich um den Roboter befinden.
|
Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, die sich um den Roboter befinden.
|
||||||
Eine solche Erweiterung erlaubt die automatische Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
|
Eine solche Erweiterung erlaubt die automatische Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
|
||||||
|
|
||||||
Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, welcher durch die MoveGroup aufgerufen wird.
|
Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, 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.
|
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.
|
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.
|
Hiefür kann ein anderer \code{ros_control} Controller geladen werden, der entweder die simulierte oder echte Hardware ansteuert.
|
||||||
Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
|
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.
|
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.
|
Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} im Anhang visualisiert.
|
||||||
@ -284,44 +313,44 @@ Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} im Anhang
|
|||||||
Als Programmiersprache kommen in ROS standartmäßig Python\cite{python} und C++\cite{cpp} zum Einsatz.
|
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.
|
Diese beiden Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark in Funktionsumfang und Entwicklungsprozess.
|
||||||
|
|
||||||
Python ist eine interpretierte Skriptsprache, welche zu den hohen Programmiersprachen zählt.
|
Python ist eine interpretierte Skriptsprache, die 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.
|
Sie wird in ROS zum Beispiel in .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.
|
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.
|
C++ hingegen ist eine kompilierte, statisch typisierte, maschinennahe Programmiersprache.
|
||||||
In ROS wird C++ für Code verwendet, welcher entweder häufig oder in zeitkritischen Szenarien ausgeführt wird.
|
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, welche schnell auf große Datenmengen reagieren müssen.
|
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.
|
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 wieder 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.
|
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.
|
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.
|
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.
|
Ein Grund dafür ist die hohe Geschwindigkeit, die bei einer hohen Anzahl an Simulationsschritten pro Sekunde benötigt wird.
|
||||||
Außerdem kann MoveIt2 zur aktuellen Zeit nur mit C++ direkt gesteuert werden.
|
Außerdem kann MoveIt2 zur aktuellen Zeit nur mit C++ direkt gesteuert werden.
|
||||||
|
|
||||||
Die Verwendung von C++ für die zu entwickelnden Nodes erscheint deshalb aus oben genannten Gründen naheliegend.
|
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.
|
In den Launch-Skripten wird jedoch Python verwendet werden, da hier die Vorteile einer Skriptsprache überwiegen.
|
||||||
|
|
||||||
\section{Behavior Trees}
|
\section{Behavior Trees}
|
||||||
Zur Verwaltung der Abläufe sollen BehaviorTrees genutzt werden, welche durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
|
Zur Verwaltung der Abläufe sollen BehaviorTrees genutzt werden, die 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.
|
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 aber auch viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen, die im folgenden vorgestellt werden.
|
||||||
|
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[Asynchrone Nodes]
|
\item[Asynchrone Nodes]
|
||||||
sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese im Lebenszyklus der Nodes beim Konzept der Bibliothek mit bedacht wurden.
|
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.
|
Dies resultiert in Nodes, die 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.
|
\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.
|
Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, die aktuell ausführende Aktionen beeinflussen können.
|
||||||
Darunter fällt die Modifizierung von Parametern der Aktionen, aber auch der vollständige Abbruch einer Aktion durch äußere Einflüsse.
|
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.
|
\item[Das .xml-Format der Behavior Trees] ermöglicht einen Austausch des Verhaltens, ohne die unterliegende Programme verändern zu müssen.
|
||||||
Dies ist vor allem in kompillierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompillierung bedürfen, was die Iterationszeit für Änderungen verbessert.
|
Dies ist vor allem in kompilierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompillierung bedürfen, was die Iterationszeit für Änderungen verbessert.
|
||||||
\item[Plugins] können zum Start geladen werden, um weitere Nodes dem ausgeführten Programm hinzufügen zu können.
|
\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.
|
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.
|
\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.
|
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.
|
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.
|
\item[Integriertes Logging] erlaubt es, Zustandsänderungen im Behavior Tree zu visualisieren, aufzunehmen und wieder abzuspielen.
|
||||||
@ -333,24 +362,25 @@ Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfig
|
|||||||
|
|
||||||
Ports können verwendet werden, um Nodes generischer zu gestalten.
|
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.
|
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.
|
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.
|
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 einfache Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von BehaviorTree.Cpp bereits durch mitgelieferte Funktionen unterstützt.
|
Viele primitive Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von BehaviorTree.Cpp bereits durch mitgelieferte Funktionen unterstützt.
|
||||||
|
|
||||||
Das Blackboard ist ein System, welches die Nutzung von Variablen als Parameter für Ports erlaubt.
|
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.
|
Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeichert.
|
||||||
Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des BehaviorTrees.
|
Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des BehaviorTrees.
|
||||||
Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, welche zu komplexeren Strukturen zusammengesetzt werden können.
|
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.
|
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.
|
Diese bilden dann in ihrer Gesamtheit eine neue Node, die im BehaviorTree eingesetzt werden kann.
|
||||||
Um den Einsatz von Variablen innerhalb eines SubTrees zu ermöglichen, besitzt jeder SubTree ein separates Blackboard.
|
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.
|
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.
|
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.
|
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 zu und von dem SubTree.
|
Die Bibliothek \code{BehaviorTree.CPP} verbindet dann diese Werte und erlaubt die Datenübergabe zu und von dem SubTree.
|
||||||
|
|
||||||
\subsection{Asynchrone Nodes}
|
\subsection{Asynchrone Nodes}
|
||||||
@ -358,24 +388,25 @@ Da nicht jeder Prozess sofort vollständig durchgeführt werden kann, muss die M
|
|||||||
Dies geschieht in \code{BehaviorTree.CPP} durch asynchrone Nodes.
|
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.
|
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.
|
Außerdem werden mehrere Funktionen definiert, die den Lebenszyklus der Node darstellen.
|
||||||
|
|
||||||
Wird eine Node durch den Aufruf der \code{onStart}-Funktion gestartet, geht diese in einen der Zustände RUNNING, SUCCESS oder FAILURE über.
|
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.
|
Der Zustand RUNNING steht dabei für eine Node, die 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.
|
So lang dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand in der neuen \code{onRunning}-Funktion abgefragt.
|
||||||
|
|
||||||
Der IDLE-Zustand ist ein besonderer Zustand, welcher nur durch eine vollständige Ausführung erreichbar ist.
|
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.
|
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.
|
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 die Ausführung der Node abbrechen kann.
|
Dies geschieht mit der neuen \code{onHalted}-Funktion.
|
||||||
|
Diese wird ausgeführt, wenn die Ausführung der Node abgebrochen werden soll.
|
||||||
\subsection{Dateiformat}
|
\subsection{Dateiformat}
|
||||||
Das in BehaviorTree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
|
Das in BehaviorTree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
|
||||||
Jedes Dokument beginnt dabei mit einem Root-Element, welches alle BehaviorTrees und eine Referenz auf die ID des Hauptbaumes enthält.
|
Jedes Dokument beginnt dabei mit einem Root-Element, dass 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.
|
Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genuzt werden können, diese aber sonst nicht vom Hauptbaum unterscheidbar sind.
|
||||||
|
|
||||||
Jeder Baum beginnt mit einem BehaviorTree-Element, welches als Attribut die ID des Baumes besitzen muss.
|
Jeder Baum beginnt mit einem BehaviorTree-Element, dass als Attribut die ID des Baumes besitzen muss.
|
||||||
Als untergeornete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
|
Als untergeornete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
|
||||||
|
|
||||||
Zur besseren Visualisierung der XML-Struktur wurde hier die bereits aus dem Konzept bekannte Baumstruktur, hier noch einmal in Abbildung \ref{choice_tree_demo} zu sehen, umgewandelt.
|
Zur besseren Visualisierung der XML-Struktur wurde hier die bereits aus dem Konzept bekannte Baumstruktur, hier noch einmal in Abbildung \ref{choice_tree_demo} zu sehen, umgewandelt.
|
||||||
@ -410,24 +441,26 @@ Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber au
|
|||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
\section{Docker-Compose als Virtualisierungsumgebung}
|
\section{Docker-Compose als Virtualisierungsumgebung}
|
||||||
Docker ist eine Virtualisierungsumgebung für Anwendungen, welche die komplette Umgebung für deren Ausführung bereitstellt.
|
Docker ist eine Virtualisierungsumgebung für Anwendungen, die eine 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.
|
Dadurch wird die Inbetriebnahme von Anwendungen, die spezielle Umgebungen für ihre Ausführung benötigen auf beliebigen Systemen ermöglicht.
|
||||||
|
|
||||||
Dies wird durch den Einsatz von sogenannten Containern erreicht.
|
Dies wird durch den Einsatz von sogenannten Containern erreicht.
|
||||||
Ein solcher Container wird über sogenannte Build-Files definiert.
|
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.
|
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.
|
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.
|
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, welches aus dem im Buildfile definierten Dateien und einem Overlay besteht.
|
Jeder Container enthält ein eigenes Dateisystem, das 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.
|
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.
|
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.
|
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.
|
Docker-Compose stellt eine Erweiterung von Docker dar.
|
||||||
In dieser Datei werden weitere Optionen angegeben, welche in die Umgebung des laufenden Containers eingreifen.
|
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 Netzwekumgebungen und Erstellen von Volumes und ``bind mounts''.
|
Dazu gehört zum Beispiel das automatisierte Übergeben von Umgebungsvariablen, Einrichten von Netzwekumgebungen und Erstellen von Volumes und ``bind mounts''.
|
||||||
|
|
||||||
Diese Automatisierung erleichtert die initiale Einrichtung eines Containers auf einem neuen System, da alle benötigten Aspekte leicht angepasst werden können.
|
Diese Automatisierung erleichtert die initiale Einrichtung eines Containers auf einem neuen System, da alle benötigten Aspekte leicht angepasst werden können.
|
||||||
|
|||||||
@ -1,14 +1,14 @@
|
|||||||
\chapter{Umsetzung}
|
\chapter{Umsetzung}
|
||||||
|
|
||||||
Bei der Umsetzung des geplanten Systemaufbaus kam es zu mehreren Problemen, welche den geplanten Systemaufbau, sowie dessen Komplexität, negativ beeinflussen.
|
Bei der Umsetzung des geplanten Systemaufbaus kam es zu mehreren Problemen, die den geplanten Systemaufbau, sowie dessen Komplexität, negativ beeinflussen.
|
||||||
|
|
||||||
Die Kommunikation zwischen dem Actormodell und dem Behavior Tree musste in mehrere Komponenten aufgeteilt werden, um Konflikte innerhalb der Simulationssoftware zu vermeiden.
|
Die Kommunikation zwischen dem Actormodell und dem Behavior Tree musste in mehrere Komponenten aufgeteilt werden, um Konflikte innerhalb der Simulationssoftware zu vermeiden.
|
||||||
|
|
||||||
Zudem ist die Bewegungsplanung mit MoveIt2 deutlich komplexer als vorerst angenommen.
|
Zudem ist die Bewegungsplanung mit MoveIt2 deutlich komplexer als vorerst angenommen.
|
||||||
Diese Komplexität entsteht aus der Interaktion mehrerer Komponenten, welche das Gesamtsystem zur Ausführung benötigt.
|
Diese Komplexität entsteht aus der Interaktion mehrerer Komponenten, die das Gesamtsystem zur Ausführung benötigt.
|
||||||
Alle Einzelsysteme mussten hierfür konfiguriert werden, um die Kommunikation dieser zu ermöglichen.
|
Alle Einzelsysteme mussten hierfür konfiguriert werden, um die Kommunikation dieser zu ermöglichen.
|
||||||
|
|
||||||
Anhand der hier genannten Änderungen wurde die Übersicht des Systems angepasst, welche in Abbildung \ref{umsetzung_overview} zu sehen ist.
|
Anhand der hier genannten Änderungen wurde die Übersicht des Systems angepasst, die in Abbildung \ref{umsetzung_overview} zu sehen ist.
|
||||||
|
|
||||||
\begin{figure}[h]
|
\begin{figure}[h]
|
||||||
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Übersicht.drawio}
|
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Übersicht.drawio}
|
||||||
@ -19,10 +19,12 @@ Anhand der hier genannten Änderungen wurde die Übersicht des Systems angepasst
|
|||||||
|
|
||||||
\section{Docker-Compose}
|
\section{Docker-Compose}
|
||||||
Um Docker für die Verwaltung einer ROS-Installation verwenden zu können, müssen einige Anpassungen vorgenommen werden.
|
Um Docker für die Verwaltung einer ROS-Installation verwenden zu können, müssen einige Anpassungen vorgenommen werden.
|
||||||
Da viele Anwendungen, unter anderem auch die Simulationsumgebung, eine Desktopumgebung benötigen, muss eine Zugriffsmöglichkeit geschaffen werden.
|
Da viele Anwendungen, unter anderem auch die Simulationsumgebung, eine Desktopumgebung benötigen, ist der Zugriffs auf eine solche Umgebung erforderlich.
|
||||||
|
|
||||||
Diese Möglichkeiten können nicht durch Docker allein gelöst werden, da Befehle auf dem Hostsystem ausgeführt werden müssen, um die gewünschten Funktionen zu aktivieren.
|
Diese Probleme können nicht durch Docker allein gelöst werden, da die Virtualisierungsumgebung eine Trennung der Systeme vorsieht.
|
||||||
Um diese Modifikationen trotzdem reproduzierbar zu machen, wurde ein Shellscript geschrieben, welches zum Starten des Containers verwendet wird.
|
Die Isolation des Containers von der Benutzeroberfläche des Systemskann durch eine Kombination aus zwei Komponenten aufgehoben werden.
|
||||||
|
|
||||||
|
Um diese Modifikationen trotzdem reproduzierbar zu machen, wurde ein Shellscript geschrieben, dass zum Starten des Containers verwendet wird.
|
||||||
|
|
||||||
Dieses Skript erstellt zuerst die benötigten Verzeichnisse für den Container, falls diese noch nicht existieren.
|
Dieses Skript erstellt zuerst die benötigten Verzeichnisse für den Container, falls diese noch nicht existieren.
|
||||||
Danach werden die SSH-Keys des Hosts in den Container kopiert, um eine SSH-Verbindung zu ermöglichen.
|
Danach werden die SSH-Keys des Hosts in den Container kopiert, um eine SSH-Verbindung zu ermöglichen.
|
||||||
@ -30,21 +32,23 @@ Dieser Umweg über SSH ist nötig, da die benötigten Umgebungsvariablen für RO
|
|||||||
|
|
||||||
Außerdem werden die benötigten Zugriffe auf den lokalen X-Server durch den Container anhand dessen Hostname erlaubt.
|
Außerdem werden die benötigten Zugriffe auf den lokalen X-Server durch den Container anhand dessen Hostname erlaubt.
|
||||||
Diese Änderung erlaubt es dem Container, Fenster auf dem Desktop anzeigen zu können, solange die benötigten SysFS-Dateien hereingereicht werden.
|
Diese Änderung erlaubt es dem Container, Fenster auf dem Desktop anzeigen zu können, solange die benötigten SysFS-Dateien hereingereicht werden.
|
||||||
Dies geschieht durch Einträge in der compose.yml-Datei, welche diese als ``bind mount'' in den Container hereinreicht.
|
Dies geschieht durch Einträge in der compose.yml-Datei, die diese als ``bind mount'' in den Container hereinreicht.
|
||||||
|
|
||||||
Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repräsentation im SysFS unter \code{/dev/dri} hineingereicht werden.
|
Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repräsentation im SysFS unter \code{/dev/dri} hineingereicht werden.
|
||||||
Der Zugriff auf die Desktopumgebung, welcher bereits entsperrt wurde, wird nun durch das mounten von \code{/tmp/.X11-unix} erreicht.
|
Der Zugriff auf die Desktopumgebung, der im vorherigen Schritt entsperrt wurde, wird nun durch das mounten von \code{/tmp/.X11-unix} erreicht.
|
||||||
Dabei handelt es sich um den Unix-Socket des X11 Displayservers.
|
Dabei handelt es sich um den Unix-Socket des X11 Displayservers.
|
||||||
|
|
||||||
Zum Starten des Containers muss der Befehl \code{./start.sh} im Verzeichnis der Containerinstallation ausgeführt werden, welcher die obengenannten Schritte ausführt und den Container startet.
|
Zum Starten des Containers muss der Befehl \code{./start.sh} im Verzeichnis der Containerinstallation ausgeführt werden.
|
||||||
Eine Verbindung zum Container kann aufgebaut werden, nachdem die Meldung \code{ros_1 | Ready to connect.} in der Konsole erscheint.
|
Dieser führt die obengenannten Schritte aus und den Container startet.
|
||||||
|
Eine Verbindung zum Container ist möglich, nachdem die Meldung \code{ros_1 | Ready to connect.} in der Konsole erscheint.
|
||||||
|
|
||||||
Dafür muss ein SSH-Client eingesetzt werden, welcher eine Verbindung zu der lokalen Netzadresse des Systems mit dem Benutzer \code{ros} aufbauen kann.
|
Dafür wird ein SSH-Client eingesetzt, der eine Verbindung zu der lokalen Netzadresse des Systems mit dem Benutzer \code{ros} aufbauen kann.
|
||||||
Der Port des SSH-Servers wird dabei durch die Deklaration im docker-compose.yaml an das Hostsystem durchgereicht.
|
Der Port des SSH-Servers wird dabei durch die Deklaration im docker-compose.yaml an das Hostsystem durchgereicht.
|
||||||
Hierbei ist zu beachten, dass der SSH-Server im Container auf Port 2222 ausgeführt wird, was bei der Verbindung beachtet werden muss.
|
Hierbei ist zu beachten, dass der SSH-Server im Container auf Port 2222 antwortet, was nicht dem standartmäßigen Port 22 entspricht.
|
||||||
|
|
||||||
Nach der Verbindung wird automatisch die ROS2-Umgebung eingerichtet, welche sofort nach Verbindungsaufbau genutzt werden kann.
|
Nach der Verbindung wird automatisch die ROS2-Umgebung eingerichtet.
|
||||||
Um die erstellten Pakete zu kompillieren, kann das Skript \code{build.sh} im \code{workspace}-Verzeichnis verwendet werden.
|
Diese kann ohne weitere Befehle nach Verbindungsaufbau genutzt werden.
|
||||||
|
Um die erstellten Pakete zu kompillieren, wurde das Skript \code{build.sh} im \code{workspace}-Verzeichnis erstellt.
|
||||||
|
|
||||||
\begin{minted}[breaklines,frame=single]{bash}
|
\begin{minted}[breaklines,frame=single]{bash}
|
||||||
#!/bin/bash
|
#!/bin/bash
|
||||||
@ -54,36 +58,36 @@ popd || exit
|
|||||||
\end{minted}
|
\end{minted}
|
||||||
|
|
||||||
Dieses Skript nutzt \code{colcon}, um alle Pakete in \code{~/workspace}-Verzeichnis zu erstellen.
|
Dieses Skript nutzt \code{colcon}, um alle Pakete in \code{~/workspace}-Verzeichnis zu erstellen.
|
||||||
Dabei wird auch eine \code{compile_commands.json}-Datei im build-Unterordner erstellt, welche von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden.
|
Dabei wird auch eine \code{compile_commands.json}-Datei im build-Unterordner erstellt, die von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden.
|
||||||
Um eine Nutzung in allen Umgebungen zu erlauben, wurde diese in das Hauptverzeichnis gelinkt, da einige Umgebung nur dort nach dieser Datei suchen.
|
Um eine Nutzung in allen Umgebungen zu erlauben, wurde diese in das Hauptverzeichnis gelinkt, da einige Umgebung nur dort nach dieser Datei suchen.
|
||||||
|
|
||||||
|
|
||||||
Da der Kompilliervorgang parallel abläuft, erscheinen Informationen zu allen Paketen gleichzeitig, was das Finden eines Fehlers erschwert.
|
Da der Kompiliervorgang parallel abläuft, erscheinen Informationen zu allen Paketen gleichzeitig, was das Finden eines Fehlers erschwert.
|
||||||
Um trotzdem alle wichtigen Informationen zu erhalten, kommt der Event-Handler \code{console_cohesion+} zum Einsatz, welcher die Ausgaben neu formatiert.
|
Um trotzdem alle wichtigen Informationen zu erhalten, kommt der Event-Handler \code{console_cohesion+} zum Einsatz, der die Ausgaben neu formatiert.
|
||||||
Durch diesen werden die Ausgaben gruppiert, und erst nach einen vollständigen Kompilliervorgang eines Pakets nacheinander ausgegeben.
|
Durch diesen werden die Ausgaben gruppiert, und erst nach einen vollständigen Kompiliervorgang eines Pakets nacheinander ausgegeben.
|
||||||
Dies ermöglicht es, aufgetretene Fehler einfacher auf ein bestimmtes Paket zurückführen zu können, ohne das gesamte Log zu durchsuchen.
|
Dies ermöglicht es, aufgetretene Fehler einfacher auf ein bestimmtes Paket zurückführen zu können, ohne das gesamte Log zu durchsuchen.
|
||||||
Hierbei ist es hilfreich, dass die verbleibenden Kompilliervorgänge abgebrochen werden, falls der Kompilliervorgang eines Pakets fehlschlägt.
|
Hierbei ist es hilfreich, dass die verbleibenden Kompiliervorgänge abgebrochen werden, falls der Kompiliervorgang eines Pakets fehlschlägt.
|
||||||
Dadurch befindet sich der Fehlers immer im letzten Paket der Ausgabe, da alle anderen Prozesse abgebrochen und nicht ausgegeben werden.
|
Dadurch befindet sich der Fehlers immer im letzten Paket der Ausgabe, da alle anderen Prozesse abgebrochen und nicht ausgegeben werden.
|
||||||
|
|
||||||
\section{Entwicklungsumgebung}
|
\section{Entwicklungsumgebung}
|
||||||
|
|
||||||
Ein einfacher Texteditor ist für das Schreiben von ROS-Packages ausreichend und bietet bei der Arbeit mit Containern sogar einen großen Vorteil.
|
Ein einfacher Texteditor ist für das Schreiben von ROS-Packages ausreichend und bietet bei der Arbeit mit Containern sogar einen großen Vorteil.
|
||||||
Das Editieren von Dateien ist mit einem Texteditor auch von außerhalb des Containers möglich.
|
Das Editieren von Dateien ist mit einem Texteditor auch von außerhalb des Containers möglich.
|
||||||
Jedoch besitzt ein Texteditor nur wenige Funktionen einer vollständigen Entwicklungsumgebung, welche den Prozess der Softwareentwicklung beschleunigen.
|
Jedoch besitzt ein Texteditor nur wenige Funktionen einer vollständigen Entwicklungsumgebung, die den Prozess der Softwareentwicklung beschleunigen.
|
||||||
Um diese Funktionen bieten zu können, analysieren Entwicklungsumgebungen den geschriebenen Code.
|
Um diese Funktionen bieten zu können, analysieren Entwicklungsumgebungen den geschriebenen Code.
|
||||||
Dies geschieht meißt auf eine von zwei unterschiedlichen Weisen.
|
Dies geschieht meißt auf eine von zwei unterschiedlichen Weisen.
|
||||||
|
|
||||||
Die Entwicklungsumgebung kann eine interne Repräsentation des geschriebenen Codes generieren.
|
Die Entwicklungsumgebung kann eine interne Repräsentation des geschriebenen Codes generieren.
|
||||||
Diese Repräsentation kann nun genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen.
|
Diese Repräsentation kann nun genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen.
|
||||||
Um dies zu erreichen, muss für jede unterstützte Sprache Code geschrieben werden, welcher in die Entwicklungsumgebung integriert werden muss.
|
Um dies zu erreichen, muss für jede unterstützte Sprache Code geschrieben werden, der in die Entwicklungsumgebung integriert werden muss.
|
||||||
|
|
||||||
Als Alternative existiert das Language Server Protocol, kurz LSP, welches eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Infomationen über den Code an die Entwicklungsumgebung zu übergeben.
|
Als Alternative existiert das Language Server Protocol, kurz LSP, dass eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Infomationen über den Code an die Entwicklungsumgebung zu übergeben.
|
||||||
Dies erlaubt einer Entwicklungsumgebung, nur noch den benötigten Server der Sprache zu starten, um Informationen über den Code in einem standartisierten Protokoll zu erhalten.
|
Dies erlaubt einer Entwicklungsumgebung, nur noch den benötigten Server der Sprache zu starten, um Informationen über den Code in einem standartisierten Protokoll zu erhalten.
|
||||||
|
|
||||||
Der große Vorteil des LSP ist, dass eine Entwicklungsumgebung alle Funktionen der Programmiersprache vollständig unterstützt, solange das Protokoll vollständig implementiert wurde und ein entsprechender Server für die Sprache existiert.
|
Der große Vorteil des LSP ist, dass eine Entwicklungsumgebung alle Funktionen der Programmiersprache vollständig unterstützt, solange das Protokoll vollständig implementiert wurde und ein entsprechender Server für die Sprache existiert.
|
||||||
|
|
||||||
Jedoch können bestimmte Funktionen, welche beim Design des LSP nicht bedacht wurden, einfacher in interner Implementation umgesetzt werden.
|
Jedoch können bestimmte Funktionen, die beim Design des LSP nicht bedacht wurden, einfacher in interner Implementation umgesetzt werden.
|
||||||
Deswegen haben Entwicklungsumgebungen mit interner Coderepräsentation häufig mehr Funktionen, spezialisieren sich jedoch auf bestimmte Sprachen.
|
Deswegen besitzen Entwicklungsumgebungen mit interner Coderepräsentation häufig mehr Funktionen, spezialisieren sich jedoch auf bestimmte Sprachen.
|
||||||
|
|
||||||
In diesem Projekt wurden mehrere Entwicklungsumgebungen mit den jeweils unterschiedlichen Verfahren verwendet.
|
In diesem Projekt wurden mehrere Entwicklungsumgebungen mit den jeweils unterschiedlichen Verfahren verwendet.
|
||||||
Um diese mit dem Docker-Container verwenden zu können, müssen diese Umgebungen die Entwicklung auf entfernten Systemen unterstützten, da der Container vom ausführenden System getrennt ist.
|
Um diese mit dem Docker-Container verwenden zu können, müssen diese Umgebungen die Entwicklung auf entfernten Systemen unterstützten, da der Container vom ausführenden System getrennt ist.
|
||||||
@ -114,47 +118,48 @@ Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Imple
|
|||||||
\item[Pose]
|
\item[Pose]
|
||||||
ist einer der häufigsten Datentypen im Umgang mit Gazebo. Dieser Datentyp enthält die Information über die Lage und Rotation eines Objekts im Raum.
|
ist einer der häufigsten Datentypen im Umgang mit Gazebo. Dieser Datentyp enthält die Information über die Lage und Rotation eines Objekts im Raum.
|
||||||
Diese werden als relative Werte im Bezug auf das übergeornete Objekt gespeichert.
|
Diese werden als relative Werte im Bezug auf das übergeornete Objekt gespeichert.
|
||||||
Objekte wie der Mensch liegen in der Hierarchie der Simulation direkt unter der Welt, welche sich direkt im Nullpunkt und ohne Rotation befindet.
|
Objekte wie der Mensch liegen in der Hierarchie der Simulation direkt unter der Welt, deren Pose sich direkt im Nullpunkt und ohne Rotation befindet.
|
||||||
Dadurch sind zum Beispiel die Koordinaten des Menschen absolut, da diese nicht durch die Welt verschoben und rotiert werden.
|
Durch diesen Umstand sind die Koordinaten des Menschen absolut, da diese nicht durch die Welt verschoben und rotiert werden.
|
||||||
\item[Area]
|
\item[Area]
|
||||||
ist eine Datenstruktur mit einem Vektor an Positionen, welche eine Zone im Zweidimensionalen Raum definieren.
|
ist eine Datenstruktur mit einem Vektor an Positionen, die eine Zone im Zweidimensionalen Raum definieren.
|
||||||
Jede Position ist eine einfache Datenstruktur aus 2 Gleitkommazahlen für je die X- und Y-Koordinate der Position.
|
Jede Position ist eine einfache Datenstruktur aus 2 Gleitkommazahlen für je die X- und Y-Koordinate der Position.
|
||||||
Der Verwendungszweck dieser Struktur ist die einfache Definition von Zonen, welche für Positionsgenerierungen und Postionsabfragen genutzt werden können.
|
Der Verwendungszweck dieser Struktur ist die einfache Definition von Zonen, die für Positionsgenerierungen und Postionsabfragen genutzt werden können.
|
||||||
\item[ActorPluginState]
|
\item[ActorPluginState]
|
||||||
definiert 4 Werte, welche das ActorPlugin annehmen kann. Diese 4 Werte sind SETUP, IDLE, MOVEMENT und ANIMATION.
|
definiert 4 Zustände, die das ActorPlugin annehmen kann. Diese 4 Werte sind SETUP, IDLE, MOVEMENT und ANIMATION.
|
||||||
\item[FeedbackMessage]
|
\item[FeedbackMessage]
|
||||||
beschreibt die erste der beiden MessageQueue-Nachrichten, welche vom ActorPlugin an den ActorServer gesendet wird.
|
beschreibt die erste der beiden MessageQueue-Nachrichten, die vom ActorPlugin an den ActorServer gesendet wird.
|
||||||
In dieser Struktur befindet sich der aktuelle Plugin-Zustand als \code{state} Parameter vom Typ ActorPluginState.
|
In dieser Struktur befindet sich der aktuelle Plugin-Zustand als \code{state} Parameter vom Typ ActorPluginState.
|
||||||
Außerdem ein \code{progress} Parameter in Form einer Gleitkommazahl, welche den Fortschritt der aktuellen Aktion angibt.
|
Außerdem ein \code{progress} Parameter in Form einer Gleitkommazahl, die den Fortschritt der aktuellen Aktion angibt.
|
||||||
Um bei Bewegungen die aktuelle Position des Menschen zu erhalten, ist auch die aktuelle Pose des Modells im Parameter \code{current} enthalten.
|
Um bei Bewegungen die aktuelle Position des Menschen zu erhalten, ist auch die aktuelle Pose des Modells im Parameter \code{current} enthalten.
|
||||||
\item[ActionMessage]
|
\item[ActionMessage]
|
||||||
ist die andere Nachricht, welche über die zweite MessageQueue vom ActorServer an das ActorPlugin gesendet wird.
|
ist die andere Nachricht, die über die zweite MessageQueue vom ActorServer an das ActorPlugin gesendet wird.
|
||||||
Wie in der FeedbackMessage ist ein \code{state} Parameter vom selben Typ enthalten, jedoch dient dieser hier als Vorgabe für den nächsten State.
|
Wie in der FeedbackMessage ist ein \code{state} Parameter vom selben Typ enthalten, jedoch dient dieser hier als Vorgabe für den nächsten State.
|
||||||
Ein \code{animationName} Parameter wird als ein char-Array mit einer maximalen Länge von 255 Zeichen übergeben.
|
Ein \code{animationName} Parameter wird als ein char-Array mit einer maximalen Länge von 255 Zeichen übergeben.
|
||||||
Dieser bestimmt später die Animation, welche je nach ActorPluginState während einer Bewegung oder Animation ausgeführt wird.
|
Dieser bestimmt später die Animation, die je nach ActorPluginState während einer Bewegung oder Animation ausgeführt wird.
|
||||||
Der \code{animationSpeed} Parameter beschreibt entweder die Abspielgeschwindigkeit der Animation, oder die Distanz, welche pro Animationsdurchlauf zurückgelegt wird.
|
Der \code{animationSpeed} Parameter beschreibt entweder die Abspielgeschwindigkeit der Animation, oder die zurückgelegte Distanz pro Animationsdurchlauf.
|
||||||
Außerdem wird im Falle einer Bewegung der Parameter \code{target} vom Typ Pose verwendet, um die Endposition und Rotation des Actors zu bestimmen.
|
Außerdem wird im Falle einer Bewegung der Parameter \code{target} vom Typ Pose verwendet, um die Endposition und Rotation des Actors zu bestimmen.
|
||||||
\end{description}
|
\end{description}
|
||||||
\section{Simulationswelt}
|
\section{Simulationswelt}
|
||||||
Die Welt der Simulation wird im Paket \code{ign_world} zur Verfügung gestellt.
|
Die Welt der Simulation wird im Paket \code{ign_world} zur Verfügung gestellt.
|
||||||
In diesem Paket sind sowohl die Geometrien der Welt, aber auch die benötigten Dateien zum Starten der Simulation enthalten.
|
In diesem Paket sind sowohl die Geometrien der Welt, aber auch die benötigten Dateien zum Starten der Simulation enthalten.
|
||||||
|
|
||||||
In diesem Fall handelt es sich um den Raum, in welchem die Interaktion zwischen Mensch und Roboter stattfinden soll.
|
In diesem Fall handelt es sich um den Raum, in dem die Interaktion zwischen Mensch und Roboter stattfinden soll.
|
||||||
Für diesen Raum wurde zuerst ein Raumplan erstellt, welcher alle benötigten Bereiche für die Szenarien besitzt (Abbildung \ref{room-plan}).
|
Für diesen Raum wurde zuerst ein Raumplan erstellt, der alle benötigten Bereiche für die Szenarien besitzt (Abbildung \ref{room-plan}).
|
||||||
|
|
||||||
Zuerst wird ein Stellplatz für den Roboter benötigt, welcher an einer Ecke des Raumes positioniert werden sollte.
|
Zuerst wird ein Stellplatz für den Roboter benötigt.
|
||||||
Diese Position wurde gewählt, um die Verfahrgeschwindigkeit des Roboters höher zu halten, welche je nach Distanz zum Menschen angepasst werden soll.
|
Dieser sollte an einer Ecke des Raumes positioniert werden, was zu höheren Verfahrgeschwindigkeiten führt.
|
||||||
|
Das ist durch die dynamische Verfahrgeschwindigkeit bedingt, die bei geringerer Distanz zum Menschen abnimmt.
|
||||||
|
|
||||||
Des weiteren werden eine Arbeits- und Lagersätte für den Menschen benötigt, welche in den Szenarien genutzt werden sollen.
|
Des weiteren werden eine Arbeits- und Lagersätte für den Menschen benötigt, die in den Szenarien genutzt werden sollen.
|
||||||
Im Koexistenzszenario soll der Mensch nur an diesen Stellen seine Arbeit verrichten, jedoch sich selten dem Roboter nähern, um dessen Fortschritt zu begutachten.
|
Im Koexistenzszenario soll der Mensch nur an diesen Stellen seine Arbeit verrichten, jedoch sich selten dem Roboter nähern, um dessen Fortschritt zu begutachten.
|
||||||
Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch für die fehlerhaften Teile verwendet werden, welche durch den Roboter aussortiert und durch den Menschen dorthin verbracht werden sollen.
|
Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch für die fehlerhaften Teile verwendet werden, die durch den Roboter aussortiert und durch den Menschen dorthin verbracht werden sollen.
|
||||||
Eine Nutzung im Kollaborationsszenario ist nicht nicht geplant, da der Mensch den Roboter überwachen und dessen Fehler korrigieren soll.
|
Eine Nutzung im Kollaborationsszenario ist nicht nicht geplant, da der Mensch den Roboter überwachen und dessen Fehler korrigieren soll.
|
||||||
|
|
||||||
Der so geplante Raum wurde in Blender modelliert und als .stl-Datei exportiert, um sie in die Welt einbinden zu können.
|
Der so geplante Raum wurde in Blender modelliert und als .stl-Datei exportiert, um sie in die Welt einbinden zu können.
|
||||||
Für das Kooperationsszenario wurde ein Förderband moddeliert, welches in diesem Szenario dem Raum hinzugefügt wird.
|
Für das Kooperationsszenario wurde ein Förderband moddeliert, das nur in diesem Szenario dem Raum hinzugefügt wird.
|
||||||
|
|
||||||
Der so erstellte Raum wird in einer .sdf-Datei als Modell referenziert, um diesen später in die Simulation einbinden zu können.
|
Der so erstellte Raum wird in einer .sdf-Datei als Modell referenziert, um diesen später in die Simulation einbinden zu können.
|
||||||
Das Förderband erhält ein eigenes Modell in einer weiteren Datei, welche zur Laufzeit in die Simulation geladen wird.
|
Das Förderband erhält ein eigenes Modell in einer weiteren Datei, die zur Laufzeit in die Simulation geladen wird.
|
||||||
Für beide wird, wie später auch für den Roboter selbst, das Paket \code{ros_gz_sim} verwendet.
|
Für beide wird, wie später auch für den Roboter selbst, das Paket \code{ros_gz_sim} verwendet.
|
||||||
Dieses veranlasst mit dem \code{create}-Programm das Erstellen der übergebenen Datenstruktur in Gazebo.
|
Dieses veranlasst mit dem \code{create}-Programm das Erstellen der übergebenen Datenstruktur in Gazebo.
|
||||||
|
|
||||||
@ -186,18 +191,18 @@ Um diese ausführen zu können, wird der gewünschte Animationsname, aber auch a
|
|||||||
|
|
||||||
Das Feedback an den Client des ROS-Action-Servers wird bei Zustandswechseln und während laufenden Aktionen des ActorPlugins generiert.
|
Das Feedback an den Client des ROS-Action-Servers wird bei Zustandswechseln und während laufenden Aktionen des ActorPlugins generiert.
|
||||||
Dabei wird der aktuelle Zustand mitsamt einigen weiteren Daten, in diesem Fall die Position des Actors und der aktuelle Fortschritt der Aktion an den ActorServer gesendet.
|
Dabei wird der aktuelle Zustand mitsamt einigen weiteren Daten, in diesem Fall die Position des Actors und der aktuelle Fortschritt der Aktion an den ActorServer gesendet.
|
||||||
Dies geschieht über eine zweite MessageQueue, welche den \code{FeedbackMessage}-Datentyp überträgt.
|
Dies geschieht über eine zweite MessageQueue, die den \code{FeedbackMessage}-Datentyp überträgt.
|
||||||
Diese werden durch den ActorServer aufbereitet, da nicht alle Daten für die jeweilige laufende Aktion relevant sind und an den ROS-Action-Client gesendet.
|
Diese werden durch den ActorServer aufbereitet, da nicht alle Daten für die jeweilige laufende Aktion relevant sind und an den ROS-Action-Client gesendet.
|
||||||
|
|
||||||
Um diese Befehle in der Simulation auch visuell umsetzen zu können, werden weitere Animationen für das Modell des Menschen benötigt, welche im Kontext der zur erfüllenden Aufgabe relevant sind.
|
Um diese Befehle in der Simulation auch visuell umsetzen zu können, werden weitere Animationen für das Modell des Menschen benötigt, die im Kontext der zur erfüllenden Aufgabe relevant sind.
|
||||||
Dafür muss dan Modell in einen animierbaren Zustand gebracht werden, in welchem dann weitere Animationen erstellt und in die Simulation eingebunden werden können.
|
Dafür muss dan Modell in einen animierbaren Zustand gebracht werden, in dem dann weitere Animationen erstellt und in die Simulation eingebunden werden können.
|
||||||
\subsection{Modellierung}
|
\subsection{Modellierung}
|
||||||
Um neue Animationen für den Menschen in der Simulation erstellen zu können, muss ein Modell für diesen erstellt werden.
|
Um neue Animationen für den Menschen in der Simulation erstellen zu können, muss ein Modell für diesen erstellt werden.
|
||||||
Dafür wurde eine der inkludierten Animationen in Blender geöffnet und das visuelle Modell kopiert.
|
Dafür wurde eine der inkludierten Animationen in Blender geöffnet und das visuelle Modell kopiert.
|
||||||
|
|
||||||
Dieses Modell war auf Grund von vielen inneren Falten nur schlecht für Animationen geeignet, weshalb das Modell an diesen Stellen vereinfacht wurde.
|
Dieses Modell war auf Grund von vielen inneren Falten nur schlecht für Animationen geeignet, weshalb das Modell an diesen Stellen vereinfacht wurde.
|
||||||
Eine solches Vorgehen beugt späteren Anomalien bei der Animation des Modells vor.
|
Eine solches Vorgehen beugt späteren Anomalien bei der Animation des Modells vor.
|
||||||
Diese entstehen durch unterschiedliche Verschiebung der Strukturen, welche aus dem inneren des Modells hervortreten, wenn dieses bewegt wird.
|
Diese entstehen durch unterschiedliche Verschiebung der Strukturen, die aus dem inneren des Modells hervortreten, wenn dieses bewegt wird.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -211,9 +216,9 @@ Um eine bessere Übersicht zu ermöglichen, sollten als erstes alle nicht benöt
|
|||||||
Nun müssen die Knochen durch Verschiebung und Skalierung an die richtigen Positionen im Modell gebracht werden.
|
Nun müssen die Knochen durch Verschiebung und Skalierung an die richtigen Positionen im Modell gebracht werden.
|
||||||
|
|
||||||
Dabei muss auf die Ausrichtung der Knochen zueinander geachtet werden.
|
Dabei muss auf die Ausrichtung der Knochen zueinander geachtet werden.
|
||||||
Das Kreuzprodukt der Vektoren beider Knochensegmente bestimmt die Richtung der Beugeachse, welche sich im Verbindungspunkt beider Knochen befindet.
|
Das Kreuzprodukt der Vektoren beider Knochensegmente bestimmt die Richtung der Beugeachse, die sich im Verbindungspunkt beider Knochen befindet.
|
||||||
Ist diese nicht richtig ausgerichtet, wenn zum Beispiel beide Knochen auf einer Gerade liegen, verbiegen sich Gelenke bei der Verwendung von inverser Kinematik zur Positionsvorgabe falsch.
|
Ist diese nicht richtig ausgerichtet, wenn zum Beispiel beide Knochen auf einer Gerade liegen, verbiegen sich Gelenke bei der Verwendung von inverser Kinematik zur Positionsvorgabe falsch.
|
||||||
Der Grund dafür ist das Kreuzprodukt, welches im oben genannten Fall ein Nullvektor ist, wodurch keine Beugeachse bestimmt werden kann.
|
Der Grund dafür ist das Kreuzprodukt, dass im oben genannten Fall ein Nullvektor ist, wodurch keine Beugeachse bestimmt werden kann.
|
||||||
|
|
||||||
Deswegen muss bei der Platzierung darauf geachtet werden, dass der Startpunkt A des ersten und der Endpunkt C des zweiten Knochens auf einer Gerade liegen.
|
Deswegen muss bei der Platzierung darauf geachtet werden, dass der Startpunkt A des ersten und der Endpunkt C des zweiten Knochens auf einer Gerade liegen.
|
||||||
Der Verbindungspunkt B der beiden Knochen wird nun vorerst auf dieser Gerade platziert.
|
Der Verbindungspunkt B der beiden Knochen wird nun vorerst auf dieser Gerade platziert.
|
||||||
@ -249,18 +254,18 @@ Hierfür werden für jeden Knochen entweder automatisch oder manuell Teile des M
|
|||||||
Je höher die Wichtung, desto stärker ist die Verformung an dieser Stelle, wenn der Knochen bewegt oder skaliert wird.
|
Je höher die Wichtung, desto stärker ist die Verformung an dieser Stelle, wenn der Knochen bewegt oder skaliert wird.
|
||||||
|
|
||||||
Da das Animieren aller Knochen einzeln sehr zeitaufwändig ist, werden diese in Gruppen zusammengefasst.
|
Da das Animieren aller Knochen einzeln sehr zeitaufwändig ist, werden diese in Gruppen zusammengefasst.
|
||||||
Hierfür werden in Blender sogenannte Constraints eingesetzt, welche Knochen automatisch durch eingestellte Bedingungen positionieren können.
|
Hierfür werden in Blender sogenannte Constraints eingesetzt, die Knochen automatisch durch eingestellte Bedingungen positionieren können.
|
||||||
|
|
||||||
Durch das Verwenden von Rigify und einem standartisierten Skelett ist die Generierung der Constraints einfach.
|
Durch das Verwenden von Rigify und einem standartisierten Skelett ist die Generierung der Constraints einfach.
|
||||||
Hierfür können die in dem Skelett enthaltenen Informationen vom Plugin genutzt werden, um alle häufig genutzten Constraints automatisch zu generieren.
|
Hierfür können die in dem Skelett enthaltenen Informationen vom Plugin genutzt werden, um alle häufig genutzten Constraints automatisch zu generieren.
|
||||||
In diesem Schritt werden auch neue Knochen eingefügt, welche das Skelett durch Constraints beeinflussen.
|
In diesem Schritt werden auch neue Knochen eingefügt, die das Skelett durch Constraints beeinflussen.
|
||||||
Das neue Animationsmodell, visualisiert in Abbildung \ref{person-armature}, kann nun für Animationen genutzt werden.
|
Das neue Animationsmodell, visualisiert in Abbildung \ref{person-armature}, kann nun für Animationen genutzt werden.
|
||||||
|
|
||||||
Hierfür sehen mehrere Knochengruppen zur Verfügung, welche typische Animationsmethoden abdecken.
|
Hierfür sehen mehrere Knochengruppen zur Verfügung, die typische Animationsmethoden abdecken.
|
||||||
|
|
||||||
In Rot sind hier Knochen markiert, welche für inverse Kinematik genutzt werden, in diesem Fall Arme und Beine.
|
In der Farbe Rot sind im Modell Knochen markiert, die für inverse Kinematik genutzt werden, in diesem Fall Arme und Beine.
|
||||||
Diese Knochen geben gewünschte Ausrichtung und die Zielposition des untersten Knochens vor.
|
Diese Knochen geben gewünschte Ausrichtung und die Zielposition des untersten Knochens vor.
|
||||||
Aus diesen Angaben wird die wirkliche Position der Knochen berechnet, welche durch die Constraints automatisch auf diese übertragen wird.
|
Aus diesen Angaben wird die wirkliche Position der Knochen berechnet, die durch die Constraints automatisch auf diese übertragen wird.
|
||||||
|
|
||||||
Orange gefärbte Knochen werden für generelle Einstellungen von Fingern, Handfläche und Zehen genutzt.
|
Orange gefärbte Knochen werden für generelle Einstellungen von Fingern, Handfläche und Zehen genutzt.
|
||||||
Die Handfläche kann so gekrümmt werden, wodurch sich alle Finger mit der Krümmung mitbewegen.
|
Die Handfläche kann so gekrümmt werden, wodurch sich alle Finger mit der Krümmung mitbewegen.
|
||||||
@ -270,7 +275,7 @@ Hierbei wird der Grad des Einknickens nicht durch eine Rotation des Knochens aus
|
|||||||
Anstatt der Rotation wird die Skalierung des Knochens eingesetzt, wobei ein kleinerer Knochen eine stärkere Knickung aller Fingerglieder bewirkt.
|
Anstatt der Rotation wird die Skalierung des Knochens eingesetzt, wobei ein kleinerer Knochen eine stärkere Knickung aller Fingerglieder bewirkt.
|
||||||
|
|
||||||
Die gelben Knochen beeinflussen die generelle Pose des Modells.
|
Die gelben Knochen beeinflussen die generelle Pose des Modells.
|
||||||
Der Quader in der Hüfte gibt die gewünschte Höhe des Modells vor, welche auch für die inverse Kinematik benutzt wird.
|
Der Quader in der Hüfte gibt die gewünschte Höhe des Modells vor, die auch für die inverse Kinematik benutzt wird.
|
||||||
Die anderen Knochen beeinflussen die Rotation des Beckens, der Wirbelsäule, der Schultern und des Kopfes.
|
Die anderen Knochen beeinflussen die Rotation des Beckens, der Wirbelsäule, der Schultern und des Kopfes.
|
||||||
|
|
||||||
Das hier erstellte, verbesserte Rigify-Skelett kann nun durch den Einsatz der neuen Constraints einfacher animiert werden.
|
Das hier erstellte, verbesserte Rigify-Skelett kann nun durch den Einsatz der neuen Constraints einfacher animiert werden.
|
||||||
@ -332,18 +337,18 @@ Da sich einige Knochen nur am Anfang der Animation in einer bestimmten Pose befi
|
|||||||
|
|
||||||
\subsection{Programmierung}
|
\subsection{Programmierung}
|
||||||
\subsubsection{Message Queue}
|
\subsubsection{Message Queue}
|
||||||
Nach der ersten Implementation des ActorPlugins kam es zu Kollisionen mit \code{ros_control}, welche beide \code{rclcpp} zur Kommunikation benutzen.
|
Nach der ersten Implementation des ActorPlugins kam es zu Kollisionen mit \code{ros_control}, die beide \code{rclcpp} zur Kommunikation benutzen.
|
||||||
Diese Kollisionen führt zu einem Crash, wenn beide Plugins in der Simulation geladen werden.
|
Diese Kollisionen führt zu einem Crash, wenn beide Plugins in der Simulation geladen werden.
|
||||||
Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS-Topics, verwenden.
|
Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS-Topics, verwenden.
|
||||||
|
|
||||||
In dieser Bibliothek wird eine globale Instanz angelegt, welche den Zustand des Kommunikationsprotokolls abbildet.
|
In dieser Bibliothek wird eine globale Instanz angelegt, die den Zustand des Kommunikationsprotokolls abbildet.
|
||||||
Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zur Problemen, da kein Synchronisationsmechanismus existiert.
|
Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zur Problemen, da kein Synchronisationsmechanismus existiert.
|
||||||
Die dadurch entstehenden gleichzeitigen Zugriffe auf die selben Ressourcen führen zur Terminierung des Programms.
|
Die dadurch entstehenden gleichzeitigen Zugriffe auf die selben Ressourcen führen zur Terminierung des Programms.
|
||||||
|
|
||||||
Nach dem Debuggen des Crashes wurden einige Problemlösungen ausprobiert, jedoch ließ sich der Konflikt durch Modifikation des ActorPlugins allein nicht verhindern, weshalb ein anderer Weg zur Problembehebung gewählt werden musste.
|
Nach dem Debuggen des Crashes wurden einige Problemlösungen ausprobiert, jedoch ließ sich der Konflikt durch Modifikation des ActorPlugins allein nicht verhindern, weshalb ein anderer Weg zur Problembehebung gewählt werden musste.
|
||||||
|
|
||||||
Eine Anpassung beider Plugins auf die gemeinsame Nutzung einer Ressource ist möglich, erfordert jedoch potentiell weitreichende Neuimplementationen, welche zeitlich nur schwer planbar sind.
|
Eine Anpassung beider Plugins auf die gemeinsame Nutzung einer Ressource ist möglich, erfordert jedoch potentiell weitreichende Neuimplementationen, die zeitlich nur schwer planbar sind.
|
||||||
Die Nutzung eines separaten Nachrichtendienstes, welcher keinen globalen Kontext benötigt, ist die sicherste und schnellste Lösung des Problems.
|
Die Nutzung eines separaten Nachrichtendienstes, der keinen globalen Kontext benötigt, ist die sicherste und schnellste Lösung des Problems.
|
||||||
Jedoch erfordert diese Implementation zusätziliche Logik, um die beiden Dienste ineinander übersetzen zu können.
|
Jedoch erfordert diese Implementation zusätziliche Logik, um die beiden Dienste ineinander übersetzen zu können.
|
||||||
|
|
||||||
Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschielichen Möglichkeiten getroffen.
|
Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschielichen Möglichkeiten getroffen.
|
||||||
@ -356,10 +361,10 @@ Der Einsatz von zerstückelten Antworten umgeht dieses Problem, jedoch müssen d
|
|||||||
|
|
||||||
Die neueren Websockets bieten die Möglichkeit, bidirektional Daten zu übertragen.
|
Die neueren Websockets bieten die Möglichkeit, bidirektional Daten zu übertragen.
|
||||||
Dadurch können Aktionsanfragen und Feedback auf dem gleichen Kanal übertragen werden, was das Protokoll übersichtlicher macht.
|
Dadurch können Aktionsanfragen und Feedback auf dem gleichen Kanal übertragen werden, was das Protokoll übersichtlicher macht.
|
||||||
Beide Technologien basieren jedoch auf einem Webserver, welcher auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Serveices ermöglicht.
|
Beide Technologien basieren jedoch auf einem Webserver, der auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Serveices ermöglicht.
|
||||||
Die Portnummer kann zwar geändert werden, ist jedoch nicht einfach mit einer Komponente assoziierbar, was sie zu einer ``Magischen Zahl'' macht.
|
Die Portnummer kann zwar geändert werden, ist jedoch nicht einfach mit einer Komponente assoziierbar, was sie zu einer ``Magischen Zahl'' macht.
|
||||||
Dies sorgt für schlechte Lesbarkeit in einem wichtigen Teil des Kontrollflusses.
|
Dies sorgt für schlechte Lesbarkeit in einem wichtigen Teil des Kontrollflusses.
|
||||||
Außerdem besitzen beide Terchnologien durch TCP oder UDP und HTTP relativ großen Protokolloverhead, welcher bei den hohen Updateraten der Gazebo-Simulation zu Problemen führen könnte.
|
Außerdem besitzen beide Terchnologien durch TCP oder UDP und HTTP relativ großen Protokolloverhead, der bei den hohen Updateraten der Gazebo-Simulation zu Problemen führen könnte.
|
||||||
|
|
||||||
Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen.
|
Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen.
|
||||||
Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den gleichen Speicherbereich zugreifen können.
|
Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den gleichen Speicherbereich zugreifen können.
|
||||||
@ -369,12 +374,12 @@ Diese gleichzeitige Modifikation kann zu Fehlern führen, wenn die Zugriffe auf
|
|||||||
|
|
||||||
Die letzte betrachtete Methode ist die Verwendung einer Message Queue.
|
Die letzte betrachtete Methode ist die Verwendung einer Message Queue.
|
||||||
Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustauch reserviert.
|
Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustauch reserviert.
|
||||||
Dieser Bereich besitzt ein Identifikationsmerkmal, mit welchem Anwendungen Zugriff auf diesen erlangen können.
|
Dieser Bereich besitzt ein Identifikationsmerkmal, dass es Anwendungen erlaubt, Zugriff auf diesen zu erlangen.
|
||||||
Ein Programm kann in diesem Bereich Nachrichten ablegen, welche durch das andere Programm gelesen werden können.
|
Ein Programm kann in diesem Bereich Daten ablegen, die durch andere Programme gelesen und geschrieben werden können.
|
||||||
Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, aussschließt.
|
Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, aussschließt.
|
||||||
Hierdurch kommt es zu einem Anstieg an Latenzzeit, jedoch ist dieser ausreichend gering.
|
Durch diesen Umstand kommt es zu einem Anstieg an Latenzzeit.
|
||||||
|
|
||||||
Die Wahl des Dienstes fiel auf eine MessageQueue, da die integrierten Funktionen die Entwicklung erleichtern ud die Geschwindigkeit ausreichend für das Einsatzszenario ist.
|
Die Wahl des Dienstes fiel auf eine MessageQueue, da die integrierten Funktionen die Entwicklung erleichtern und die Geschwindigkeit ausreichend für das Einsatzszenario ist.
|
||||||
Jedoch existieren unter Linux 2 unabhängige Implementationen von MessageQueues mit unterschidelichen Funktionen.
|
Jedoch existieren unter Linux 2 unabhängige Implementationen von MessageQueues mit unterschidelichen Funktionen.
|
||||||
Die erste Implementation ist die System V MessageQueue, und verwendet zur Identifikation einfache Ganzzahlen.
|
Die erste Implementation ist die System V MessageQueue, und verwendet zur Identifikation einfache Ganzzahlen.
|
||||||
Eine Spezialität dieser alten Implementation ist das Sortieren der Nachrichten nach Nachrichtentyp in der gleichen Warteschlange.
|
Eine Spezialität dieser alten Implementation ist das Sortieren der Nachrichten nach Nachrichtentyp in der gleichen Warteschlange.
|
||||||
@ -384,43 +389,44 @@ Die ausgewählte Implementation ist die neuere POSIX-Implementation einer Messag
|
|||||||
\subsubsection{ROS-Nachrichten}
|
\subsubsection{ROS-Nachrichten}
|
||||||
Die verwendeten Nachrichten für den ActionServer, als auch für die Message Queue sind in den entsprechenden Paketen \code{ros_actor_action_server_msgs} und \code{ros_actor_message_queue_msgs} organisiert.
|
Die verwendeten Nachrichten für den ActionServer, als auch für die Message Queue sind in den entsprechenden Paketen \code{ros_actor_action_server_msgs} und \code{ros_actor_message_queue_msgs} organisiert.
|
||||||
Sie sind absichtlich nicht in den nutzenden Paketen untergebracht, da sie durch ein externes Programm in den benötigten Code umgewandelt werden.
|
Sie sind absichtlich nicht in den nutzenden Paketen untergebracht, da sie durch ein externes Programm in den benötigten Code umgewandelt werden.
|
||||||
Dieser Schritt muss vor dem Kompilliervorgang der nutzenden Pakete geschehen, was so am einfachsten realisiert werden kann.
|
Dieser Schritt muss vor dem Kompiliervorgang der nutzenden Pakete geschehen, was so am einfachsten realisiert werden kann.
|
||||||
Dazu werden diese Nachrichtenpakete als Dependency der nutzenden Pakete angegeben, was eine automatische Anpassung der Kompillantionsreihenfolge bewirkt.
|
Dazu werden diese Nachrichtenpakete als Dependency der nutzenden Pakete angegeben, was eine automatische Anpassung der Kompilantionsreihenfolge bewirkt.
|
||||||
|
|
||||||
Eine Action des \code{ros_action}-Pakets besteht immer aus 3 einzelnen Nachrichten, deren Inhalt frei definiert werden kann.
|
Eine Action des \code{ros_action}-Pakets besteht immer aus 3 einzelnen Nachrichten, deren Inhalt frei definiert werden kann.
|
||||||
|
|
||||||
Zum Start der Action wird die erste Nachricht vom Client an den Server gesendet.
|
Zum Start der Action wird die erste Nachricht vom Client an den Server gesendet.
|
||||||
In dieser Startnachricht befinden sich alle Informationen, welche zur Ausführung der Action benötigt werden.
|
In dieser Startnachricht befinden sich alle Informationen, die zur Ausführung der Action benötigt werden.
|
||||||
Nach dieser Nachricht kann der Server später entscheiden, ob die Aktion ausgeführt werden soll und sie gegebenenfalls abbrechen.
|
Nach dieser Nachricht kann der Server später entscheiden, ob die Aktion ausgeführt werden soll und sie gegebenenfalls abbrechen.
|
||||||
|
|
||||||
Nach dem Beginn der Action werden vom Server Feedbacknachrichten an den Client gesendet, welche den Fortschritt der Action beschreiben.
|
Nach dem Beginn der Action werden vom Server Feedbacknachrichten an den Client gesendet, die den Fortschritt der Action beschreiben.
|
||||||
Dabei ist es die Aufgabe des Programmierers, diese an sinnvollen Punkten des Ablaufs zu senden.
|
Dabei ist es die Aufgabe des Programmierers, diese an sinnvollen Punkten des Ablaufs zu senden.
|
||||||
|
|
||||||
Am Ende der Action wird die Endnachricht an den Client gesendet, welche weitere Rückgabewerte liefern kann.
|
Am Ende der Action wird die Endnachricht an den Client gesendet, die weitere Rückgabewerte liefern kann.
|
||||||
Die Endnachricht enthält standartmäßig eine Erfolgsangabe, weshalb diese nicht angegeben werden muss.
|
Die Endnachricht enthält standartmäßig eine Erfolgsangabe, weshalb diese nicht angegeben werden muss.
|
||||||
|
|
||||||
Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die Handhabung einer Aktion definieren.
|
Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die Handhabung einer Aktion definieren.
|
||||||
Die erste Funktion übergibt den Wert der Startnachricht, welche mit einer Antwort quittiert werden muss.
|
Die erste Funktion übergibt den Wert der Startnachricht, die mit einer Antwort quittiert werden muss.
|
||||||
Hierbei sind die Antworten ACCEPT_AND_DEFER, ACCEPT_AND_EXECUTE und REJECT möglich.
|
Hierbei sind die Antworten ACCEPT_AND_DEFER, ACCEPT_AND_EXECUTE und REJECT möglich.
|
||||||
|
|
||||||
ACCEPT_AND_EXECUTE signalisiert die sofortige Ausführung des gewünschten Befehls und ACCEPT_AND_DEFER steht für eine spätere Ausführung der gewünschten Aktion.
|
Die erste mögliche Antwort ACCEPT_AND_EXECUTE signalisiert die sofortige Ausführung des gewünschten Befehls.
|
||||||
Die Option REJECT weist die Ausführung der Aktion vorzeitig ab.
|
Als Alternative existiert die Antwort ACCEPT_AND_DEFER, die für eine verspätete Ausführung der gewünschten Aktion steht.
|
||||||
|
Die REJECT-Antwort weist die Ausführung der Aktion vorzeitig ab.
|
||||||
|
|
||||||
Die zweite Funktion übergibt Abbruchanfragen an den Server, falls die Aktion durch den Client abgebrochen werden soll.
|
Die zweite Funktion übergibt Abbruchanfragen an den Server, falls die Aktion durch den Client abgebrochen werden soll.
|
||||||
Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT zurückgewiesen werden.
|
Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT zurückgewiesen werden.
|
||||||
|
|
||||||
Um Feedback während der Ausführung der Aktion geben zu können, exisitiert die dritte Funktion.
|
Um Feedback während der Ausführung der Aktion geben zu können, exisitiert die dritte Funktion.
|
||||||
Diese erhält als Parameter ein Objekt, mit welchem Feedback- und Endnachrichten an den Client gesendet werden können.
|
Diese erhält als Parameter ein Objekt, mit dem Feedback- und Endnachrichten an den Client gesendet werden können.
|
||||||
\subsubsection{ActorPlugin}
|
\subsubsection{ActorPlugin}
|
||||||
Das ActorPlugin steuert anhand von empfangenen Nachrichten aus der eingehenden Message Queue den Menschen in der Simulationsumgebung.
|
Das ActorPlugin steuert anhand von empfangenen Nachrichten aus der eingehenden Message Queue den Menschen in der Simulationsumgebung.
|
||||||
Der Code des Plugins ist dabei im Paket \code{ign_actor_plugin} organisiert, welches im Gazebo-Modell der Welt referenziert werden muss, um das Plugin zu laden.
|
Der Code des Plugins ist dabei im Paket \code{ign_actor_plugin} organisiert, dass im Gazebo-Modell der Welt referenziert werden muss, um das Plugin zu laden.
|
||||||
|
|
||||||
Das Plugin wird durch den Startvorgang und später von den empfangenen Nachrichten in mehrere Zustände versetzt, welche im folgenden erläutert werden:
|
Das Plugin wird durch den Startvorgang und später von den empfangenen Nachrichten in mehrere Zustände versetzt, die im folgenden erläutert werden:
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[Setup]
|
\item[Setup]
|
||||||
wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simualtionumgebung im Plugin zu hinerlegen, so dass diese in den anderen Zuständen genutzt werden können.
|
wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simualtionumgebung im Plugin zu hinerlegen, so dass diese in den anderen Zuständen genutzt werden können.
|
||||||
\item[Idle]
|
\item[Idle]
|
||||||
ist der Zustand, welcher nach erfolgreicher Ausführung eines Befehls angenommen wird.
|
ist der Zustand, der nach erfolgreicher Ausführung eines Befehls angenommen wird.
|
||||||
\item[Movement]
|
\item[Movement]
|
||||||
bedeutet die Ausführung einer Bewegung in potentiell mehreren Schritten.
|
bedeutet die Ausführung einer Bewegung in potentiell mehreren Schritten.
|
||||||
\item[Animation]
|
\item[Animation]
|
||||||
@ -429,18 +435,18 @@ Das Plugin wird durch den Startvorgang und später von den empfangenen Nachricht
|
|||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
In diesen Zuständen muss das ActorPlugin die Simulationsumgebung beeinflussen, in dem die simulierte Person bewegt und animiert wird.
|
In diesen Zuständen muss das ActorPlugin die Simulationsumgebung beeinflussen, in dem die simulierte Person bewegt und animiert wird.
|
||||||
Dies erfordert den Zugriff auf simulationsinterne Daten, welche durch das Plugin gelesen und verändert werden sollen.
|
Dies erfordert den Zugriff auf simulationsinterne Daten, die durch das Plugin gelesen und verändert werden sollen.
|
||||||
Der Zugriff auf diese Daten wird durch ein EntityComponentManager-Objekt ermöglicht.
|
Der Zugriff auf diese Daten wird durch ein EntityComponentManager-Objekt ermöglicht.
|
||||||
|
|
||||||
Durch den EntityComponentManager kann auf das so genannte ``Entity Component System'' zugegriffen werden, in welchem alle Simulationsobjekte organisiert sind.
|
Durch den EntityComponentManager kann auf das so genannte ``Entity Component System'' zugegriffen werden, in dem alle Simulationsobjekte organisiert sind.
|
||||||
Ein Entity Component System besteht aus einer oder mehr Entities, welche die sich in der Simulation befindlichen Objekte abbilden.
|
Ein Entity Component System besteht aus einer oder mehr Entities, die Objekte innerhalb der Simulation abbilden.
|
||||||
Objekte können beliebig viele Components besitzen, bei welchen es sich um zusätzliche Eigenschaften und Erweiterungen der Funktionen des betroffenen Objekts handelt.
|
Objekte können beliebig viele Components besitzen, bei denen es sich um zusätzliche Eigenschaften und Erweiterungen der Funktionen des betroffenen Objekts handelt.
|
||||||
Die wichtigsten Komponenten für die Funktion des Plugins sind dabei:
|
Die wichtigsten Komponenten für die Funktion des Plugins sind dabei:
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[components::Actor]
|
\item[components::Actor]
|
||||||
Dieses Objekt beschreibt die simulierte Person mit allen weiteren Daten, wie zum Beispiel dessen Animationen.
|
Dieses Objekt beschreibt die simulierte Person mit allen weiteren Daten, wie zum Beispiel dessen Animationen.
|
||||||
\item[components::AnimationName]
|
\item[components::AnimationName]
|
||||||
In dieser Komponente wird der aktuell verwendete Animationsname abgelegt, welcher von Gazebo zur Auswahl der aktuell laufenden Animation verwendet wird.
|
In dieser Komponente wird der aktuell verwendete Animationsname abgelegt, der von Gazebo zur Auswahl der aktuell laufenden Animation verwendet wird.
|
||||||
\item[components::AnimationTime]
|
\item[components::AnimationTime]
|
||||||
enthält den aktuellen Zeitpunkt innerhalb der Animation, um die richtigen Positionsdaten aus dieser auswählen zu können. Dabei wird zwischen einzelnen Positionen linear interpoliert, falls der Zeitpunkt zwischen diesen liegt.
|
enthält den aktuellen Zeitpunkt innerhalb der Animation, um die richtigen Positionsdaten aus dieser auswählen zu können. Dabei wird zwischen einzelnen Positionen linear interpoliert, falls der Zeitpunkt zwischen diesen liegt.
|
||||||
\item[components::Pose]
|
\item[components::Pose]
|
||||||
@ -457,21 +463,23 @@ Folgende Funktionen werden von Gazebo unterstützt:
|
|||||||
\begin{description}
|
\begin{description}
|
||||||
\item[Configure] wird aufgerufen, sobald das Plugin geladen wurde.
|
\item[Configure] wird aufgerufen, sobald das Plugin geladen wurde.
|
||||||
Alle benötigten Informationen über dessen Umgebung werden als Parameter übergeben.
|
Alle benötigten Informationen über dessen Umgebung werden als Parameter übergeben.
|
||||||
Darunter fallen die Entity, zu welcher das Plugin als Component hinzugefügt wurde, eine Referenz auf die Konfiguration des Plugins in der geladenen Welt und eine aktuelle Instanz des EntityComponentManagers und EventManagers von Gazebo.
|
Darunter fallen die Entity, zu der das Plugin als Component hinzugefügt wurde.
|
||||||
|
Außerdem wird eine Referenz auf die Konfiguration des Plugins in der geladenen Welt übergeben.
|
||||||
|
Für den Zugriff auf die Simulationsumgebung werden zuletzt noch eine aktuelle Instanz des EntityComponentManagers und EventManagers von Gazebo übergeben.
|
||||||
\item[PreUpdate] wird verwendet, um den nächsten Update-Schritt vorzubereiten.
|
\item[PreUpdate] wird verwendet, um den nächsten Update-Schritt vorzubereiten.
|
||||||
Diese Funktion erlaubt die Modifikation von Entities und Components und wird vor der eigentlichen Physiksimulation aufgerufen.
|
Diese Funktion erlaubt die Modifikation von Entities und Components und wird vor der eigentlichen Physiksimulation aufgerufen.
|
||||||
\item[Update] wird genutzt, um die in der Simulation abgelaufene Zeit zu simulieren.
|
\item[Update] wird genutzt, um die in der Simulation abgelaufene Zeit zu simulieren.
|
||||||
Auch hier ist die Modifikation von Entities und Components möglich.
|
Auch hier ist die Modifikation von Entities und Components möglich.
|
||||||
In dieser Funktion werden Beispielsweise die Physiksimulation der Objekte durchgeführt.
|
In dieser Funktion werden Beispielsweise die Physiksimulation der Objekte durchgeführt.
|
||||||
\item[PostUpdate] bietet die Möglichkeit, die Ergebnisse der Simulation vor dem nächsten Simulationsschritt auszulesen.
|
\item[PostUpdate] bietet die Möglichkeit, die Ergebnisse der Simulation vor dem nächsten Simulationsschritt auszulesen.
|
||||||
Dies wird zum Beispiel für die simulierten Sensoren in Gazebo genutzt, welche hier ihren Status prüfen.
|
Dies wird zum Beispiel für die simulierten Sensoren in Gazebo genutzt, die hier ihren Status prüfen.
|
||||||
In dieser Funktion kann nur lesend auf Entities und Components zugegriffen werden.
|
In dieser Funktion kann nur lesend auf Entities und Components zugegriffen werden.
|
||||||
\end{description}
|
\end{description}
|
||||||
Jede dieser Funktionen ist in einem Interface mit dem Präfix \code{ISystem} definiert, welche vom Plugin genutzt werden können.
|
Jede dieser Funktionen ist in einem Interface mit dem Präfix \code{ISystem} definiert, die vom Plugin genutzt werden können.
|
||||||
Für Gazebo muss das Plugin noch registriert werden, was mit dem \code{IGNITION_ADD_PLUGIN}-Makro geschieht.
|
Für Gazebo muss das Plugin noch registriert werden, was mit dem \code{IGNITION_ADD_PLUGIN}-Makro geschieht.
|
||||||
Mit diesen Vorbereitungsschritten wird das Plugin von Gazebo verwendbar gemacht.
|
Mit diesen Vorbereitungsschritten wird das Plugin von Gazebo verwendbar gemacht.
|
||||||
|
|
||||||
Das ActorPlugin benötigt für seine Funktion das übergeornete Simulationsobjekt, welches durch das Plugin beeinflusst werden soll.
|
Das ActorPlugin benötigt für seine Funktion das übergeornete Simulationsobjekt, dass durch das Plugin beeinflusst werden soll.
|
||||||
Dies erfordert die Implementation des \code{ISystemConfigure}-Interfaces für das ActorPlugin.
|
Dies erfordert die Implementation des \code{ISystemConfigure}-Interfaces für das ActorPlugin.
|
||||||
Außerdem soll die simulierte Person bewegt werden. Da dieser Vorgang während der Simulationszeit ablaufen soll, muss hierfür das \code{ISystemUpdate}-Interface genutzt werden.
|
Außerdem soll die simulierte Person bewegt werden. Da dieser Vorgang während der Simulationszeit ablaufen soll, muss hierfür das \code{ISystemUpdate}-Interface genutzt werden.
|
||||||
|
|
||||||
@ -479,7 +487,7 @@ Als erstes wird durch das Laden die Configure-Funktion aufgerufen.
|
|||||||
Da das Plugin erst durch Gazebo geladen werden muss, kann davon ausgegangen werden, dass alle benötigten Message Queues bereits durch den ActorServer erstellt wurden.
|
Da das Plugin erst durch Gazebo geladen werden muss, kann davon ausgegangen werden, dass alle benötigten Message Queues bereits durch den ActorServer erstellt wurden.
|
||||||
Trotz dieses Umstandes wartet das Plugin auf deren Erstellung, um bei Konfigurationsfehlern auffälliges Verhalten zu zeigen.
|
Trotz dieses Umstandes wartet das Plugin auf deren Erstellung, um bei Konfigurationsfehlern auffälliges Verhalten zu zeigen.
|
||||||
Im Log wird diese Aktion vermerkt, um Debugging zu erleichtern.
|
Im Log wird diese Aktion vermerkt, um Debugging zu erleichtern.
|
||||||
Nach dem erfolgreichen Aufbau der Verbindung wird ein Thread gestartet, welcher die eingehenden Nachrichten verarbeitet.
|
Nach dem erfolgreichen Aufbau der Verbindung wird ein Thread gestartet, der die eingehenden Nachrichten verarbeitet.
|
||||||
Dabei wird zuerst ein Mutex gesperrt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
|
Dabei wird zuerst ein Mutex gesperrt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
|
||||||
Alle in der Anfrage gespeicherten Daten werden nun übernommen und der gewünschte State gesetzt.
|
Alle in der Anfrage gespeicherten Daten werden nun übernommen und der gewünschte State gesetzt.
|
||||||
Nach dem Entsperren des Mutex wird im nächsten Simulationschritt die gewünschte Aktion durchgeführt.
|
Nach dem Entsperren des Mutex wird im nächsten Simulationschritt die gewünschte Aktion durchgeführt.
|
||||||
@ -494,22 +502,31 @@ Wurde eine Animation gefunden, wird deren Länge gespeichert, um diese später f
|
|||||||
|
|
||||||
Ab diesem Zeitpunkt unterscheiden sich die Implementation von Animation und Movement.
|
Ab diesem Zeitpunkt unterscheiden sich die Implementation von Animation und Movement.
|
||||||
Im Zustand der Animation wird nun die Komponente AnimationTime jedes Update aktualisiert.
|
Im Zustand der Animation wird nun die Komponente AnimationTime jedes Update aktualisiert.
|
||||||
Um die Ausführungsgeschwindigkeit einer Animation anpassen zu können, kann ein Skalierungsfaktor genutzt werden, welcher mit der abgelaufenen Zeit in der Simulation verrechnet wird.
|
Um die Ausführungsgeschwindigkeit einer Animation anpassen zu können, wird ein Skalierungsfaktor genutzt.
|
||||||
Nach jedem Update-Schritt wird eine Feedback-Nachricht gesendet, welche den aktuellen Fortschritt der Animation enthält.
|
Dieser optionale Faktor kann mit der abgelaufenen Zeit multipliziert werden.
|
||||||
|
Dies verursacht eine Beschleunigung oder verlangsamung der Ausführung.
|
||||||
|
Nach jedem Update-Schritt wird eine Feedback-Nachricht gesendet, die den aktuellen Fortschritt der Animation enthält.
|
||||||
Wurde die Animation vollständig durchlaufen, wird der Zustand des ActorPlugins auf Idle gesetzt.
|
Wurde die Animation vollständig durchlaufen, wird der Zustand des ActorPlugins auf Idle gesetzt.
|
||||||
|
|
||||||
|
\begin{figure}[hpt]
|
||||||
|
\includegraphics[width=\textwidth]{uml/out/plugin_states.eps}
|
||||||
|
\caption{Zustandsübergänge im ActorPlugin}
|
||||||
|
\label{plugin_states}
|
||||||
|
\end{figure}
|
||||||
|
Alle Zustandsübergänge sind in Abbildung \ref{plugin_states} zusammengefasst.
|
||||||
|
|
||||||
Soll über den Movement-Zustand eine Bewegung abgespielt werden, müssen noch weitere Parameter der Bewegung berechnet werden.
|
Soll über den Movement-Zustand eine Bewegung abgespielt werden, müssen noch weitere Parameter der Bewegung berechnet werden.
|
||||||
Dies geschieht nach dem Setzen der Animation während des ersten Update-Aufrufs.
|
Dies geschieht nach dem Setzen der Animation während des ersten Update-Aufrufs.
|
||||||
Zuerst wird ein Vektor zur Zielposition berechnet, welcher später zur Bewegung genutzt wird.
|
Zuerst wird ein Vektor zur Zielposition berechnet, der später zur Bewegung genutzt wird.
|
||||||
Sollte dieser über einer gewissen Mindestlänge liegen, wird eine Rotation des Menschen in Bewegungsrichtung ausgeführt.
|
Sollte dieser über einer gewissen Mindestlänge liegen, wird eine Rotation des Menschen in Bewegungsrichtung ausgeführt.
|
||||||
Nach dieser Rotation wird die Bewegung an die Zielposition umgesetzt.
|
Nach dieser Rotation wird die Bewegung an die Zielposition umgesetzt.
|
||||||
Dabei wird die Bewegungsanimation abgespielt, welche durch einen Faktor an die zurückgelegte Distanz angepasst wird.
|
Dabei wird die Bewegungsanimation abgespielt, die durch einen Faktor an die zurückgelegte Distanz angepasst wird.
|
||||||
Dies vermeidet, dass die Beine der Person über den Boden gleiten.
|
Dies vermeidet, dass die Beine der Person über den Boden gleiten.
|
||||||
Wurde eine Endrotation angegeben, welche nicht dem Nullvektor entspricht, wird nach der Bewegung noch eine Rotation in diese Richtung ausgeführt.
|
Wurde eine Endrotation angegeben, die nicht dem Nullvektor entspricht, wird nach der Bewegung noch eine Rotation in diese Richtung ausgeführt.
|
||||||
Dabei werden auch die Beine wieder in die Ausgangslage bewegt.
|
Dabei werden auch die Beine wieder in die Ausgangslage bewegt.
|
||||||
Wenn sowohl die Zielrotation ausgeführt wurde und die Beine wieder in Ausgangslage sind, wird der Zustand auf Idle gesetzt.
|
Wenn sowohl die Zielrotation ausgeführt wurde und die Beine wieder in Ausgangslage sind, wird der Zustand auf Idle gesetzt.
|
||||||
|
|
||||||
Das ActorPlugin besitzt kein Konzept eines ROS-ActionServers und verlässt sich auf den ActorServer, welcher die Feedbacknachrichten in das richtige Format bringt.
|
Das ActorPlugin besitzt kein Konzept eines ROS-ActionServers und verlässt sich auf den ActorServer, der die Feedbacknachrichten in das richtige Format bringt.
|
||||||
Feedback wird in den Zuständen Movement und Animation in eine zweiten Message Queue zu jedem Simulationsschritt gesendet.
|
Feedback wird in den Zuständen Movement und Animation in eine zweiten Message Queue zu jedem Simulationsschritt gesendet.
|
||||||
Um Zustandsübergänge erkennen zu können, werden auch diese als Feedback an den ActorServer gesendet.
|
Um Zustandsübergänge erkennen zu können, werden auch diese als Feedback an den ActorServer gesendet.
|
||||||
\subsubsection{ActorServer}
|
\subsubsection{ActorServer}
|
||||||
@ -517,13 +534,13 @@ Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin.
|
|||||||
Er ist als das Programm \code{ros_actor_action_server} im gleichnamigen Paket enthalten.
|
Er ist als das Programm \code{ros_actor_action_server} im gleichnamigen Paket enthalten.
|
||||||
Dieser weitere Dienst bindet das ActorPlugin an ROS an.
|
Dieser weitere Dienst bindet das ActorPlugin an ROS an.
|
||||||
|
|
||||||
Es werden dafür zwei ROS-ActionServer gestartet, welche jeweils Bewegungen oder Animationen des simulierten Menschen auslösen können.
|
Dafür werden zwei ROS-ActionServer gestartet, die jeweils Bewegungen oder Animationen des simulierten Menschen auslösen können.
|
||||||
Beide ActionServer prüfen bei dem Empfang eines neuen Ziels zuerst, ob bereits eine andere Aktion ausgeführt wird.
|
Beide ActionServer prüfen bei dem Empfang eines neuen Ziels zuerst, ob bereits eine andere Aktion ausgeführt wird.
|
||||||
Wird bereits eine andere Aktion ausgeführt, kommt es zur Ablehnung weiterer Anfragen.
|
Wird bereits eine andere Aktion ausgeführt, kommt es zur Ablehnung weiterer Anfragen.
|
||||||
Im anderen Fall wird die Aufgabe akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
|
Im anderen Fall wird die Aufgabe akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
|
||||||
|
|
||||||
Um das Starten mehrerer gleichzeitiger Aktionen zu unterbinden, muss der Empfang einer neuen Anfrage bestätigt werden, bevor weitere Befehle über den ROS-ActionServer entgegen genommen werden können.
|
Um das Starten mehrerer gleichzeitiger Aktionen zu unterbinden, muss der Empfang einer neuen Anfrage bestätigt werden, bevor weitere Befehle über den ROS-ActionServer entgegen genommen werden können.
|
||||||
Hierzu wird ein Mutex verwendet, welcher die Auswertung neuer Nachrichten verhindert, so lange der aktuelle Befehl noch nicht durch das Plugin bestätigt wurde.
|
Hierzu wird ein Mutex verwendet, der die Auswertung neuer Nachrichten verhindert, so lange der aktuelle Befehl noch nicht durch das Plugin bestätigt wurde.
|
||||||
Parallel werden alle eingehenden Feedback-Nachrichten der Message Queue des ActorPlugins in Feedback für die aktuell laufende Action umgewandelt.
|
Parallel werden alle eingehenden Feedback-Nachrichten der Message Queue des ActorPlugins in Feedback für die aktuell laufende Action umgewandelt.
|
||||||
|
|
||||||
Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
|
Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
|
||||||
@ -534,9 +551,9 @@ Soll eine Animation über den Action Server abgespielt werden, wird auch hier ei
|
|||||||
Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl.
|
Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl.
|
||||||
\section{Roboter}
|
\section{Roboter}
|
||||||
\subsection{Übersicht}
|
\subsection{Übersicht}
|
||||||
Der Roboter besteht aus vielen interagierenden Systemen, welche in ihrer Gesamtheit das vollständige Robotermodell in der Simulation verwendbar machen.
|
Der Roboter besteht aus vielen interagierenden Systemen, die in ihrer Gesamtheit das vollständige Robotermodell in der Simulation verwendbar machen.
|
||||||
|
|
||||||
Zuerst muss ein Modell des Roboters erstellt werden, welches in Gazebo geladen werden kann.
|
Zuerst muss ein Modell des Roboters erstellt werden, dass in Gazebo geladen werden kann.
|
||||||
Dieses Modell muss dann für die Bewegungsplanung mit MoveIt erweitert werden.
|
Dieses Modell muss dann für die Bewegungsplanung mit MoveIt erweitert werden.
|
||||||
Hierbei werden Controller von ros_control mit dem Modell verbunden, um den aktuellen Zustand der Achsen zu überwachen und diese steuern zu können.
|
Hierbei werden Controller von ros_control mit dem Modell verbunden, um den aktuellen Zustand der Achsen zu überwachen und diese steuern zu können.
|
||||||
|
|
||||||
@ -545,8 +562,11 @@ Um diese Vielfalt an Daten standartisiert an andere Software in ROS weitergeben
|
|||||||
Für den Kuka LBR iisy existiert kein Simulationsmodell für Gazebo und ROS, weswegen dieses Modell aus Herstellerdaten generiert wurden.
|
Für den Kuka LBR iisy existiert kein Simulationsmodell für Gazebo und ROS, weswegen dieses Modell aus Herstellerdaten generiert wurden.
|
||||||
Hierzu stand eine .stl-Datei des Herstellers zur Verfügung.
|
Hierzu stand eine .stl-Datei des Herstellers zur Verfügung.
|
||||||
Aus dieser Datei wurden mit FreeCAD\cite{freecad} alle Glieder des Roboters als Collada-Dateien exportiert.
|
Aus dieser Datei wurden mit FreeCAD\cite{freecad} alle Glieder des Roboters als Collada-Dateien exportiert.
|
||||||
Dabei muss darauf geachtet werden, dass die exportierten Daten eine ausreichende Meshgröße haben, welche vorher in FreeCAD eingestellt werden muss.
|
Dabei muss darauf geachtet werden, dass die exportierten Daten eine ausreichende Meshgröße haben.
|
||||||
Dies erlaubt das Erhalten der feinen Strukturen des Arms, auch visualisiert in Abbildung \ref{robot_raw}, welche erst später in Blender reduziert werden sollen.
|
Diese kann vor dem Export in FreeCAD eingestellt werden.
|
||||||
|
Durch diese Einstellung bleiben feine Strukturen erhalten, die später in Blender wieder reduziert werden können.
|
||||||
|
Ein solches Vorgehen erlaubt es Blender, bessere Entscheidungen über die Reduktion von Strukturen zu treffen.
|
||||||
|
Das Resultat ist ein besseres Endmodell des Roboters.
|
||||||
|
|
||||||
\begin{figure}[]
|
\begin{figure}[]
|
||||||
\includegraphics[width=\textwidth/2]{img/MA-Roboter-Rohdaten}
|
\includegraphics[width=\textwidth/2]{img/MA-Roboter-Rohdaten}
|
||||||
@ -561,17 +581,17 @@ Außerdem wuden die Glieder so ausgerichtet, dass der Verbindungspunkt zum vorhe
|
|||||||
Das vollständige visuelle Modell ist in Abbildung \ref{robot_visual} zu sehen.
|
Das vollständige visuelle Modell ist in Abbildung \ref{robot_visual} zu sehen.
|
||||||
|
|
||||||
Um die Simulation weiter zu beschleunigen, wurden die Kollisionsboxen des Arms noch weiter vereinfacht, was die Kollisionsüberprüfung dramatisch beschleunigt.
|
Um die Simulation weiter zu beschleunigen, wurden die Kollisionsboxen des Arms noch weiter vereinfacht, was die Kollisionsüberprüfung dramatisch beschleunigt.
|
||||||
Dabei werden stark simplifizierte Formen verwendet, welche das hochqualitative visuelle Modell mit einfachen Formen umfassen.
|
Dabei werden stark simplifizierte Formen verwendet, die das hochqualitative visuelle Modell mit einfachen Formen umfassen.
|
||||||
Das resultierende Modell, welches in Abbildung \ref{robot_collision} dargestellt wird, wird später zur Kollisionserkennung verwendet.
|
Das resultierende Modell, welches in Abbildung \ref{robot_collision} dargestellt wird, wird später zur Kollisionserkennung verwendet.
|
||||||
|
|
||||||
Diese Herangehensweise ist nötig, da Kollisionserkennung auf der CPU durchgeführt wird, welche durch komplexe Formen stark verlangsamt wird.
|
Diese Herangehensweise ist nötig, da Kollisionserkennung auf der CPU durchgeführt wird, die durch komplexe Formen stark verlangsamt wird.
|
||||||
|
|
||||||
Um aus den generierten Gliedermodellen ein komplettes Robotermodell erstellen zu können, wurde eine .urdf-Datei erstellt.
|
Um aus den generierten Gliedermodellen ein komplettes Robotermodell erstellen zu können, wurde eine .urdf-Datei erstellt.
|
||||||
In dieser werden die verwendeten Gelenktypen zwischen den einzelnen Gliedern, aber auch deren Masse, maximale Geschwindigkeit, maximale Motorkraft, Reibung und Dämpfung hinterlegt.
|
In dieser werden die verwendeten Gelenktypen zwischen den einzelnen Gliedern, aber auch deren Masse, maximale Geschwindigkeit, maximale Motorkraft, Reibung und Dämpfung hinterlegt.
|
||||||
Diese Daten können später zur Simulation der Motoren genutzt werden, welche den Arm bewegen.
|
Diese Daten können später zur Simulation der Motoren genutzt werden, die den Arm bewegen.
|
||||||
|
|
||||||
Die Gelenkpositionen sind dabei relative Angaben, welche sich auf das Glied beziehen, an welchem ein weiteres Glied über das Gelenk verbunden werden soll.
|
Die Gelenkpositionen sind dabei relative Angaben, die sich auf das Glied beziehen, an dem ein weiteres Glied über das Gelenk verbunden werden soll.
|
||||||
Alle kontrollierbaren Gelenke benötigen auch eine Gelenkachse, welche je nach Gelenktyp die mögliche Beweglichkeit bestimmt.
|
Alle kontrollierbaren Gelenke benötigen auch eine Gelenkachse, die je nach Gelenktyp die mögliche Beweglichkeit bestimmt.
|
||||||
|
|
||||||
Alle hier erstellten Dateien wurden im Paket \code{iisy_config} zusammengefasst, um diese einfacher wiederauffinden zu können.
|
Alle hier erstellten Dateien wurden im Paket \code{iisy_config} zusammengefasst, um diese einfacher wiederauffinden zu können.
|
||||||
\begin{figure}[hpt]
|
\begin{figure}[hpt]
|
||||||
@ -590,33 +610,34 @@ Alle hier erstellten Dateien wurden im Paket \code{iisy_config} zusammengefasst,
|
|||||||
\end{figure}
|
\end{figure}
|
||||||
\subsection{MoveIt 2 Konfiguration}
|
\subsection{MoveIt 2 Konfiguration}
|
||||||
Das somit erstellte Paket kann nun mit dem neu implementierten MoveIt Configurator um die benötigten Kontrollstrukturen erweitert werden.
|
Das somit erstellte Paket kann nun mit dem neu implementierten MoveIt Configurator um die benötigten Kontrollstrukturen erweitert werden.
|
||||||
Dazu wurde der neue Setupassistent von MoveIt2 verwendet, welcher das Modell analysiert, um es mit für MoveIt benötigten Parameter zu erweitert.
|
Dazu wurde der neue Setupassistent von MoveIt2 verwendet, der das Modell für MoveIt anpasst.
|
||||||
|
Dabei wird das Modell mit weiteren Parametern versehen, die durch MoveIt genutzt werden.
|
||||||
|
|
||||||
Die Erstellung des erweiterten Modells mit dem Assistenten funktionierte komplett fehlerfrei, jedoch ließen sich die generierten Dateien nicht nutzen.
|
Die Erstellung des erweiterten Modells mit dem Assistenten funktionierte komplett fehlerfrei, jedoch ließen sich die generierten Dateien nicht nutzen.
|
||||||
|
|
||||||
Um die generierten Dateien nutzen zu können, mussten diese weiter angepasst werden.
|
Um die generierten Dateien nutzen zu können, mussten diese weiter angepasst werden.
|
||||||
Dies beinhaltete die korrekte Integration der Roboterdefinitionen im Paket, aber auch zahlreiche Pfadreferenzen auf verwendete Dateien, welche nicht korrekt generiert wurden.
|
Dies beinhaltete die korrekte Integration der Roboterdefinitionen im Paket, aber auch zahlreiche Pfadreferenzen auf verwendete Dateien, die nicht korrekt generiert wurden.
|
||||||
Diese können standartmäßig nicht in Gazebo, RViz und MoveGroup gleichzeitig geladen werden, da diese Programme unterschiedliche Pfadangaben verlangen, was die Nutzung verhindert.
|
Diese können standartmäßig nicht in Gazebo, RViz und MoveGroup gleichzeitig geladen werden, da diese Programme unterschiedliche Pfadangaben verlangen, was die Nutzung verhindert.
|
||||||
|
|
||||||
Eine Möglichkeit zur Lösung des Problems ist die Verwendung von \code{file://}-URIs, welche von allen dieser Programme gelesen werden können.
|
Eine Möglichkeit zur Lösung des Problems ist die Verwendung von \code{file://}-URIs, die von allen dieser Programme gelesen werden können.
|
||||||
Jedoch ist hier als Nachteil zu verzeichnen, dass der Moveit Setup Assistent diese URIs nicht lesen kann, was zu Fehlern bei einer Rekonfiguration führen kann.
|
Jedoch ist hier als Nachteil zu verzeichnen, dass der Moveit Setup Assistent diese URIs nicht lesen kann, was zu Fehlern bei einer Rekonfiguration führen kann.
|
||||||
|
|
||||||
Das so erstellte Modell kann ber den Aufruf von \code{ros2 launch iisy_config demo.launch.py} in RViz getestet werden.
|
Das so erstellte Modell kann ber den Aufruf von \code{ros2 launch iisy_config demo.launch.py} in RViz getestet werden.
|
||||||
Hierfür erscheint das Robotermodell mit mehreren Markern und Planungsoptionen, welche genutzt werden können, um beliebige Bewegungen zu planen und auszuführen.
|
Hierfür erscheint das Robotermodell mit mehreren Markern und Planungsoptionen, die genutzt werden können, um beliebige Bewegungen zu planen und auszuführen.
|
||||||
\subsection{Integration mit Gazebo}
|
\subsection{Integration mit Gazebo}
|
||||||
Das so erstellte Modell kann nun zur Laufzeit in Gazebo geladen werden.
|
Das so erstellte Modell kann nun zur Laufzeit in Gazebo geladen werden.
|
||||||
Dafür wird das Paket \code{ros_gz_sim} verwendet, welches das \code{create} Programm beinhaltet.
|
Dafür wird das Paket \code{ros_gz_sim} verwendet, dass das \code{create}-Programm beinhaltet.
|
||||||
Mit diesem Werkzeug kann ein Modell unter einem bestimmten Namen anhand einer Datei oder eines übergebenen Strings in Gazebo importiert werden.
|
Mit diesem Werkzeug kann ein Modell unter einem bestimmten Namen anhand einer Datei oder eines übergebenen Strings in Gazebo importiert werden.
|
||||||
Das Modell kann dabei über Argumente im Raum verschoben und rotiert werden, falls diese Funktionalität benötigt wird.
|
Das Modell kann dabei über Argumente im Raum verschoben und rotiert werden, falls diese Funktionalität benötigt wird.
|
||||||
|
|
||||||
In diesem Fall wird das Modell als String geladen, welcher durch \code{xacro} erstellt wurde.
|
In diesem Fall wird das Modell als String geladen, der durch \code{xacro} erstellt wurde.
|
||||||
Dies ist nötig, um Informationen aus anderen Dateien in das generierte XML übernehmen zu können.
|
Dies ist nötig, um Informationen aus anderen Dateien in das generierte XML übernehmen zu können.
|
||||||
|
|
||||||
Im Modell sind auch die verwendeten Gazebo-Plugins deklariert, welche für die Integration mit \code{ros_control} verantwortlich sind.
|
Im Modell sind auch die verwendeten Gazebo-Plugins deklariert, die für die Integration mit \code{ros_control} verantwortlich sind.
|
||||||
Das Gazebo-Plugin läd dabei die verwendeten Controller und versorgt diese mit Informationen über den Roboter.
|
Das Gazebo-Plugin läd dabei die verwendeten Controller und versorgt diese mit Informationen über den Roboter.
|
||||||
|
|
||||||
\section{Behavior Trees}
|
\section{Behavior Trees}
|
||||||
Alle Behavior Trees wurden im Paket \code{btree} organisert, welches die Bäume im XML-Format und die Implementation der Nodes und umliegenden Infrastruktur enthält.
|
Alle Behavior Trees wurden im Paket \code{btree} organisert, dass die Bäume im XML-Format und die Implementation der Nodes und umliegenden Infrastruktur enthält.
|
||||||
|
|
||||||
|
|
||||||
Für die Umsetzung des Szenarios wurden neue Nodes für den BehaviorTree erstellt.
|
Für die Umsetzung des Szenarios wurden neue Nodes für den BehaviorTree erstellt.
|
||||||
@ -626,11 +647,11 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
|
|||||||
\begin{description}
|
\begin{description}
|
||||||
\item[GenerateXYPose]
|
\item[GenerateXYPose]
|
||||||
generiert eine Pose in einem durch den \code{area} Parameter angegebenen Bereich.
|
generiert eine Pose in einem durch den \code{area} Parameter angegebenen Bereich.
|
||||||
Um dies zu ermöglichen, wird zuerst die Fläche aller Dreiecke berechnet, welche den Bereich definieren.
|
Um dies zu ermöglichen, wird zuerst die Fläche aller Dreiecke berechnet, die den Bereich definieren.
|
||||||
Diese werden durch den Gesamtinhalt geteilt, um eine Wichtung der Dreiecke zum Gesamtinhalt zu erreichen.
|
Diese werden durch den Gesamtinhalt geteilt, um eine Wichtung der Dreiecke zum Gesamtinhalt zu erreichen.
|
||||||
Nun wird eine Zufallszahl zwischen 0 und 1 gebildet.
|
Nun wird eine Zufallszahl zwischen 0 und 1 gebildet.
|
||||||
Von dieser werden nun die Wichtungen der Dreiecke abgezogen, bis dies Zufallszahl im nächsten abzuziehenden Dreieck liegt.
|
Von dieser werden nun die Wichtungen der Dreiecke abgezogen, bis dies Zufallszahl im nächsten abzuziehenden Dreieck liegt.
|
||||||
Nun wird in diesem Dreieck eine zufällige Position ermittelt, welche ber den Ausgabeparameter \code{pose} ausgegeben wird.
|
Nun wird in diesem Dreieck eine zufällige Position ermittelt, die über den Ausgabeparameter \code{pose} ausgegeben wird.
|
||||||
\item[InAreaTest]
|
\item[InAreaTest]
|
||||||
prüft, ob eine Pose, vorgegeben durch den \code{pose} Parameter, in einer durch den \code{area} Parameter definierten Zone liegt.
|
prüft, ob eine Pose, vorgegeben durch den \code{pose} Parameter, in einer durch den \code{area} Parameter definierten Zone liegt.
|
||||||
Hierfür wird überprüft, ob die X und Y-Werte der Pose in einem der Dreiecke liegen, welche die Area definieren.
|
Hierfür wird überprüft, ob die X und Y-Werte der Pose in einem der Dreiecke liegen, welche die Area definieren.
|
||||||
@ -640,25 +661,25 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
|
|||||||
Falls der \code{offset} Parameter gesetzt ist, wird dieser mit dem \code{input} Parameter summiert.
|
Falls der \code{offset} Parameter gesetzt ist, wird dieser mit dem \code{input} Parameter summiert.
|
||||||
Außerdem wird die Orientierung der Pose auf den \code{orientation} Parameter gesetzt, falls dieser vorhanden ist, was den ursprünglichen Wert überschreibt.
|
Außerdem wird die Orientierung der Pose auf den \code{orientation} Parameter gesetzt, falls dieser vorhanden ist, was den ursprünglichen Wert überschreibt.
|
||||||
\item[InterruptableSequence]
|
\item[InterruptableSequence]
|
||||||
stellt eine Sequence dar, welche auch nach ihrem Abbruch ihre Position behält.
|
stellt eine Sequence dar, die auch nach ihrem Abbruch ihre Position behält.
|
||||||
Dies ist von Nöten, wenn bestimmtes Verhalten unterbrechbar ist, aber zu einem späteren Zeitpunkt fortgesetzt werden soll.
|
Dies ist von Nöten, wenn bestimmtes Verhalten unterbrechbar ist, aber zu einem späteren Zeitpunkt fortgesetzt werden soll.
|
||||||
Hierzu wird der Iterator der unterlegenden Sequenz nur erhöht, wenn die untergeordnete Node SUCCESS zurück gibt.
|
Hierzu wird der Iterator der unterlegenden Sequenz nur erhöht, wenn die untergeordnete Node SUCCESS zurück gibt.
|
||||||
Außerdem wird der Iterator nicht zurückgesetzt, wenn die Ausführung dieser modifizierten Sequenz abgebrochen wird.
|
Außerdem wird der Iterator nicht zurückgesetzt, wenn die Ausführung dieser modifizierten Sequenz abgebrochen wird.
|
||||||
\item[WeightedRandom]
|
\item[WeightedRandom]
|
||||||
ist eine Steuerungsnode, welche mehrere untergeordnete Nodes besitzt.
|
ist eine Steuerungsnode, die mehrere untergeordnete Nodes besitzt.
|
||||||
Dabei werden diese nicht, wie bei anderen Steuerungsnodes üblich, sequentiell ausgeführt.
|
Dabei werden diese nicht, wie bei anderen Steuerungsnodes üblich, sequentiell ausgeführt.
|
||||||
Anhand einer vorgegebenen Wichtung im \code{weights} Parameter wird eine der untergeordneten Nodes zufällig ausgewählt.
|
Anhand einer vorgegebenen Wichtung im \code{weights} Parameter wird eine der untergeordneten Nodes zufällig ausgewählt.
|
||||||
Diese Node wird nun als einzige Node ausgeführt, bis diese den SUCCESS-Status zurück gibt.
|
Diese Node wird nun als einzige Node ausgeführt, bis diese den SUCCESS-Status zurück gibt.
|
||||||
Nach dem dieser Status erreicht wurde, wird bei dem nächsten Durchlauf eine neue Node ausgewählt.
|
Nach dem dieser Status erreicht wurde, wird bei dem nächsten Durchlauf eine neue Node ausgewählt.
|
||||||
Der Rückgabewert ist der Rückgabewert der ausgewählten untergeorneten Node.
|
Der Rückgabewert ist der Rückgabewert der ausgewählten untergeorneten Node.
|
||||||
\item[IsCalled]
|
\item[IsCalled]
|
||||||
fragt den aktuellen Called-Status des Actors ab, welcher in einigen Szenarien vom Roboter verwendet wird, um den simulierten Menschen zu rufen.
|
fragt den aktuellen Called-Status des Actors ab, der in einigen Szenarien vom Roboter verwendet wird, um den simulierten Menschen zu rufen.
|
||||||
Der Rückgabewert der Node ist dabei SUCCESS, falls der Mensch gerufen wird, oder FAILURE, wenn kein RUF durchgeführt wird.
|
Der Rückgabewert der Node ist dabei SUCCESS, falls der Mensch gerufen wird, oder FAILURE, wenn kein RUF durchgeführt wird.
|
||||||
\item[SetCalledTo]
|
\item[SetCalledTo]
|
||||||
setzt den aktuellen Called-Status auf den Wert des übergebenen \code{state} Parameters.
|
setzt den aktuellen Called-Status auf den Wert des übergebenen \code{state} Parameters.
|
||||||
Da diese Aktion nicht fehlschlagen kann, liefert diese Node immer SUCCESS als Rückgabewert.
|
Da diese Aktion nicht fehlschlagen kann, liefert diese Node immer SUCCESS als Rückgabewert.
|
||||||
\item[RandomFailure]
|
\item[RandomFailure]
|
||||||
generiert eine Zufallszahl von 0 bis 1, welche mit dem \code{failure_chance} Parameter verglichen wird.
|
generiert eine Zufallszahl von 0 bis 1, die mit dem \code{failure_chance} Parameter verglichen wird.
|
||||||
Der Rückgabewert ist das Ergebnis des Vergleichs, FAILURE, wenn die Zufallszahl kleiner als der \code{failure_chance} Parameter ist, oder im anderen Falle SUCCESS.
|
Der Rückgabewert ist das Ergebnis des Vergleichs, FAILURE, wenn die Zufallszahl kleiner als der \code{failure_chance} Parameter ist, oder im anderen Falle SUCCESS.
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
@ -666,13 +687,13 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
|
|||||||
\begin{description}
|
\begin{description}
|
||||||
\item[ActorAnimation]
|
\item[ActorAnimation]
|
||||||
wird verwendet, um dem simulierten Menschen eine auszuführende Animation zu senden.
|
wird verwendet, um dem simulierten Menschen eine auszuführende Animation zu senden.
|
||||||
Die Node benötigt zur Ausführung einen Animationsname, welcher im \code{animation_name} Parameter angegeben wird.
|
Die Node benötigt zur Ausführung einen Animationsname, der im \code{animation_name} Parameter angegeben wird.
|
||||||
Ein optionaler \code{animation_speed} Parameter gibt die Ausführungsgeschwindigkeit vor.
|
Ein optionaler \code{animation_speed} Parameter gibt die Ausführungsgeschwindigkeit vor.
|
||||||
Der Rückgabewert ist SUCCESS, wenn die komplette Ausführung gelang, oder FAILURE, falls diese abgebrochen oder abgelehnt wurde.
|
Der Rückgabewert ist SUCCESS, wenn die komplette Ausführung gelang, oder FAILURE, falls diese abgebrochen oder abgelehnt wurde.
|
||||||
\item[ActorMovement]
|
\item[ActorMovement]
|
||||||
funktioniert wie eine ActorAnimation, sendet jedoch eine Bewegungsanfrage.
|
funktioniert wie eine ActorAnimation, sendet jedoch eine Bewegungsanfrage.
|
||||||
Auch für diese wird ein Animationsname benötigt, welcher im \code{animation_name} Parameter definiert wird.
|
Auch für diese wird ein Animationsname benötigt, der im \code{animation_name} Parameter definiert wird.
|
||||||
Jedoch wird für die Synchronisation zur Bewegung ein Disztanzwert benötigt, welcher in einem Animationsdurchlauf zurückgelegt wird.
|
Jedoch wird für die Synchronisation zur Bewegung ein Disztanzwert benötigt, der in einem Animationsdurchlauf zurückgelegt wird.
|
||||||
Dieser wird im \code{animation_distance} Parameter übergeben.
|
Dieser wird im \code{animation_distance} Parameter übergeben.
|
||||||
Eine Zielpose wird im \code{target} Parameter gesetzt.
|
Eine Zielpose wird im \code{target} Parameter gesetzt.
|
||||||
Eine Besonderheit dieses Paramerters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
|
Eine Besonderheit dieses Paramerters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
|
||||||
@ -681,7 +702,7 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
|
|||||||
\subsubsection{Roboterspezifisch}
|
\subsubsection{Roboterspezifisch}
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[RobotMove] gibt dem Roboter eine neue Zielposition über den \code{target} Parameter vor.
|
\item[RobotMove] gibt dem Roboter eine neue Zielposition über den \code{target} Parameter vor.
|
||||||
Bei dieser Node handelt es sich um eine asynchrone Node, welche nur bei der erfolgreiche Ausführung der Bewegung SUCCESS zurück gibt.
|
Bei dieser Node handelt es sich um eine asynchrone Node, die nur bei der erfolgreiche Ausführung der Bewegung mit dem SUCCESS-Status beendet wird.
|
||||||
\item[SetRobotVelocity] setzt eine neue maximale Geschwindigkeit des Roboters, vorgegeben durch den \code{velocity} Parameter.
|
\item[SetRobotVelocity] setzt eine neue maximale Geschwindigkeit des Roboters, vorgegeben durch den \code{velocity} Parameter.
|
||||||
Der Rückgabewert ist immer SUCCESS.
|
Der Rückgabewert ist immer SUCCESS.
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|||||||
@ -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!
|
|
||||||
20
texput.log
20
texput.log
@ -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!
|
|
||||||
32
uml/animation_states.puml
Normal file
32
uml/animation_states.puml
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
@startuml animation_states
|
||||||
|
hide empty description
|
||||||
|
|
||||||
|
[*] --> Standing
|
||||||
|
|
||||||
|
state Standing{
|
||||||
|
[*] --> StandingIdle
|
||||||
|
StandingIdle --> [*]
|
||||||
|
StandingIdle --> ExtendArm
|
||||||
|
ExtendArm --> RetractArm
|
||||||
|
RetractArm --> StandingIdle
|
||||||
|
|
||||||
|
StandingIdle --> Walk
|
||||||
|
Walk --> StandingIdle
|
||||||
|
}
|
||||||
|
|
||||||
|
state Low{
|
||||||
|
[*] --> LowIdle
|
||||||
|
LowIdle --> [*]
|
||||||
|
LowIdle --> InspectLow
|
||||||
|
InspectLow --> PutBackLow
|
||||||
|
InspectLow --> GrabLow
|
||||||
|
PutBackLow --> LowIdle
|
||||||
|
GrabLow --> LowIdle
|
||||||
|
}
|
||||||
|
|
||||||
|
Standing -> ToLow
|
||||||
|
ToLow -> Low
|
||||||
|
Low --> ToStanding
|
||||||
|
ToStanding --> Standing
|
||||||
|
|
||||||
|
@enduml
|
||||||
File diff suppressed because it is too large
Load Diff
@ -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
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
14
uml/plugin_animation.puml
Normal 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
|
||||||
37
uml/plugin_movement.puml
Normal file
37
uml/plugin_movement.puml
Normal 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
21
uml/plugin_states.puml
Normal 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
|
||||||
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB |
@ -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
|
|
||||||
Loading…
x
Reference in New Issue
Block a user