Changes up to 22.04
This commit is contained in:
parent
c5e91e77c2
commit
e773fa66ce
315
.gitignore
vendored
315
.gitignore
vendored
@ -1,315 +0,0 @@
|
||||
|
||||
# Created by https://www.toptal.com/developers/gitignore/api/latex
|
||||
# Edit at https://www.toptal.com/developers/gitignore?templates=latex
|
||||
|
||||
### LaTeX ###
|
||||
## Core latex/pdflatex auxiliary files:
|
||||
*.aux
|
||||
*.lof
|
||||
*.log
|
||||
*.lot
|
||||
*.fls
|
||||
*.out
|
||||
*.toc
|
||||
*.fmt
|
||||
*.fot
|
||||
*.cb
|
||||
*.cb2
|
||||
.*.lb
|
||||
|
||||
## Intermediate documents:
|
||||
*.dvi
|
||||
*.xdv
|
||||
*-converted-to.*
|
||||
# these rules might exclude image files for figures etc.
|
||||
# *.ps
|
||||
# *.eps
|
||||
# *.pdf
|
||||
|
||||
## Generated if empty string is given at "Please type another file name for output:"
|
||||
.pdf
|
||||
|
||||
## Bibliography auxiliary files (bibtex/biblatex/biber):
|
||||
*.bbl
|
||||
*.bcf
|
||||
*.blg
|
||||
*-blx.aux
|
||||
*-blx.bib
|
||||
*.run.xml
|
||||
|
||||
## Build tool auxiliary files:
|
||||
*.fdb_latexmk
|
||||
*.synctex
|
||||
*.synctex(busy)
|
||||
*.synctex.gz
|
||||
*.synctex.gz(busy)
|
||||
*.pdfsync
|
||||
|
||||
## Build tool directories for auxiliary files
|
||||
# latexrun
|
||||
latex.out/
|
||||
|
||||
## Auxiliary and intermediate files from other packages:
|
||||
# algorithms
|
||||
*.alg
|
||||
*.loa
|
||||
|
||||
# achemso
|
||||
acs-*.bib
|
||||
|
||||
# amsthm
|
||||
*.thm
|
||||
|
||||
# beamer
|
||||
*.nav
|
||||
*.pre
|
||||
*.snm
|
||||
*.vrb
|
||||
|
||||
# changes
|
||||
*.soc
|
||||
|
||||
# comment
|
||||
*.cut
|
||||
|
||||
# cprotect
|
||||
*.cpt
|
||||
|
||||
# elsarticle (documentclass of Elsevier journals)
|
||||
*.spl
|
||||
|
||||
# endnotes
|
||||
*.ent
|
||||
|
||||
# fixme
|
||||
*.lox
|
||||
|
||||
# feynmf/feynmp
|
||||
*.mf
|
||||
*.mp
|
||||
*.t[1-9]
|
||||
*.t[1-9][0-9]
|
||||
*.tfm
|
||||
|
||||
#(r)(e)ledmac/(r)(e)ledpar
|
||||
*.end
|
||||
*.?end
|
||||
*.[1-9]
|
||||
*.[1-9][0-9]
|
||||
*.[1-9][0-9][0-9]
|
||||
*.[1-9]R
|
||||
*.[1-9][0-9]R
|
||||
*.[1-9][0-9][0-9]R
|
||||
*.eledsec[1-9]
|
||||
*.eledsec[1-9]R
|
||||
*.eledsec[1-9][0-9]
|
||||
*.eledsec[1-9][0-9]R
|
||||
*.eledsec[1-9][0-9][0-9]
|
||||
*.eledsec[1-9][0-9][0-9]R
|
||||
|
||||
# glossaries
|
||||
*.acn
|
||||
*.acr
|
||||
*.glg
|
||||
*.glo
|
||||
*.gls
|
||||
*.glsdefs
|
||||
*.lzo
|
||||
*.lzs
|
||||
*.slg
|
||||
*.slo
|
||||
*.sls
|
||||
|
||||
# uncomment this for glossaries-extra (will ignore makeindex's style files!)
|
||||
# *.ist
|
||||
|
||||
# gnuplot
|
||||
*.gnuplot
|
||||
*.table
|
||||
|
||||
# gnuplottex
|
||||
*-gnuplottex-*
|
||||
|
||||
# gregoriotex
|
||||
*.gaux
|
||||
*.glog
|
||||
*.gtex
|
||||
|
||||
# htlatex
|
||||
*.4ct
|
||||
*.4tc
|
||||
*.idv
|
||||
*.lg
|
||||
*.trc
|
||||
*.xref
|
||||
|
||||
# hyperref
|
||||
*.brf
|
||||
|
||||
# knitr
|
||||
*-concordance.tex
|
||||
# TODO Uncomment the next line if you use knitr and want to ignore its generated tikz files
|
||||
# *.tikz
|
||||
*-tikzDictionary
|
||||
|
||||
# listings
|
||||
*.lol
|
||||
|
||||
# luatexja-ruby
|
||||
*.ltjruby
|
||||
|
||||
# makeidx
|
||||
*.idx
|
||||
*.ilg
|
||||
*.ind
|
||||
|
||||
# minitoc
|
||||
*.maf
|
||||
*.mlf
|
||||
*.mlt
|
||||
*.mtc[0-9]*
|
||||
*.slf[0-9]*
|
||||
*.slt[0-9]*
|
||||
*.stc[0-9]*
|
||||
|
||||
# minted
|
||||
_minted*
|
||||
*.pyg
|
||||
|
||||
# morewrites
|
||||
*.mw
|
||||
|
||||
# newpax
|
||||
*.newpax
|
||||
|
||||
# nomencl
|
||||
*.nlg
|
||||
*.nlo
|
||||
*.nls
|
||||
|
||||
# pax
|
||||
*.pax
|
||||
|
||||
# pdfpcnotes
|
||||
*.pdfpc
|
||||
|
||||
# sagetex
|
||||
*.sagetex.sage
|
||||
*.sagetex.py
|
||||
*.sagetex.scmd
|
||||
|
||||
# scrwfile
|
||||
*.wrt
|
||||
|
||||
# svg
|
||||
svg-inkscape/
|
||||
|
||||
# sympy
|
||||
*.sout
|
||||
*.sympy
|
||||
sympy-plots-for-*.tex/
|
||||
|
||||
# pdfcomment
|
||||
*.upa
|
||||
*.upb
|
||||
|
||||
# pythontex
|
||||
*.pytxcode
|
||||
pythontex-files-*/
|
||||
|
||||
# tcolorbox
|
||||
*.listing
|
||||
|
||||
# thmtools
|
||||
*.loe
|
||||
|
||||
# TikZ & PGF
|
||||
*.dpth
|
||||
*.md5
|
||||
*.auxlock
|
||||
|
||||
# titletoc
|
||||
*.ptc
|
||||
|
||||
# todonotes
|
||||
*.tdo
|
||||
|
||||
# vhistory
|
||||
*.hst
|
||||
*.ver
|
||||
|
||||
# easy-todo
|
||||
*.lod
|
||||
|
||||
# xcolor
|
||||
*.xcp
|
||||
|
||||
# xmpincl
|
||||
*.xmpi
|
||||
|
||||
# xindy
|
||||
*.xdy
|
||||
|
||||
# xypic precompiled matrices and outlines
|
||||
*.xyc
|
||||
*.xyd
|
||||
|
||||
# endfloat
|
||||
*.ttt
|
||||
*.fff
|
||||
|
||||
# Latexian
|
||||
TSWLatexianTemp*
|
||||
|
||||
## Editors:
|
||||
# WinEdt
|
||||
*.bak
|
||||
*.sav
|
||||
|
||||
# Texpad
|
||||
.texpadtmp
|
||||
|
||||
# LyX
|
||||
*.lyx~
|
||||
|
||||
# Kile
|
||||
*.backup
|
||||
|
||||
# gummi
|
||||
.*.swp
|
||||
|
||||
# KBibTeX
|
||||
*~[0-9]*
|
||||
|
||||
# TeXnicCenter
|
||||
*.tps
|
||||
|
||||
# auto folder when using emacs and auctex
|
||||
./auto/*
|
||||
*.el
|
||||
|
||||
# expex forward references with \gathertags
|
||||
*-tags.tex
|
||||
|
||||
# standalone packages
|
||||
*.sta
|
||||
|
||||
# Makeindex log files
|
||||
*.lpz
|
||||
|
||||
# xwatermark package
|
||||
*.xwm
|
||||
|
||||
# REVTeX puts footnotes in the bibliography by default, unless the nofootinbib
|
||||
# option is specified. Footnotes are the stored in a file with suffix Notes.bib.
|
||||
# Uncomment the next line to have this generated file ignored.
|
||||
#*Notes.bib
|
||||
|
||||
### LaTeX Patch ###
|
||||
# LIPIcs / OASIcs
|
||||
*.vtc
|
||||
|
||||
# glossaries
|
||||
*.glstex
|
||||
|
||||
# End of https://www.toptal.com/developers/gitignore/api/latex
|
||||
@ -77,8 +77,8 @@ Mode=LaTeX
|
||||
Mode Set By User=false
|
||||
|
||||
[item:main.bib]
|
||||
open=false
|
||||
order=1
|
||||
open=true
|
||||
order=5
|
||||
|
||||
[item:main.tex]
|
||||
open=true
|
||||
@ -113,27 +113,27 @@ TextFolding={"checksum":"","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:main.bib]
|
||||
CursorColumn=14
|
||||
CursorLine=109
|
||||
CursorColumn=39
|
||||
CursorLine=124
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"4af487415133a6dcd896d70e042ef9ac694f0ea6","ranges":[]}
|
||||
TextFolding={"checksum":"739b41a3d0418be76fb9832856bf61b41b8246a1","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:main.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=111
|
||||
CursorColumn=45
|
||||
CursorLine=176
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"86fedba94f6f431aca10df7e7ffc4fd7dd3eac24","ranges":[]}
|
||||
TextFolding={"checksum":"158329202f028c3e1d1437e81256f8ab37c5f9c3","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/1_Einleitung.tex]
|
||||
CursorColumn=42
|
||||
CursorLine=26
|
||||
CursorColumn=0
|
||||
CursorLine=19
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"7f68313ac5accbbfe63bf0c2f33b5f2b97851ec3","ranges":[]}
|
||||
TextFolding={"checksum":"8adc2060163a9c199c7a904534fb248831564ce4","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/2_Konzept.tex]
|
||||
@ -141,23 +141,23 @@ CursorColumn=0
|
||||
CursorLine=0
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"daf7cac8e4765460806a7139b3eb9171fb011da3","ranges":[]}
|
||||
TextFolding={"checksum":"0c6fe8907e6bb50811600d85d72851fe402f8c80","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/3_Auswahl.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=164
|
||||
CursorColumn=157
|
||||
CursorLine=266
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"04558a693eba7702df7000723ab69b6eb36166ba","ranges":[]}
|
||||
TextFolding={"checksum":"e90e925eeab38e92c6b17256a2993fc4a01f29c8","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/4_Umsetzung.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=216
|
||||
CursorColumn=27
|
||||
CursorLine=138
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"93fb61d8448ada79778cce2b5e34a55776abbb30","ranges":[]}
|
||||
TextFolding={"checksum":"d54709e0d3b00c46d9571f297ab62aa6064e7f7c","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/Einleitung.tex]
|
||||
|
||||
Binary file not shown.
BIN
Deckblatt.pdf
BIN
Deckblatt.pdf
Binary file not shown.
BIN
htwk-eps-converted-to.pdf
Normal file
BIN
htwk-eps-converted-to.pdf
Normal file
Binary file not shown.
Binary file not shown.
BIN
img/MA-Konzept-Übersicht.drawio.pdf
Normal file
BIN
img/MA-Konzept-Übersicht.drawio.pdf
Normal file
Binary file not shown.
BIN
img/MA-Roboter-Kollision.png
Normal file
BIN
img/MA-Roboter-Kollision.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
BIN
img/MA-Roboter-Rohdaten.png
Normal file
BIN
img/MA-Roboter-Rohdaten.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 293 KiB |
BIN
img/MA-Roboter-Visuell.png
Normal file
BIN
img/MA-Roboter-Visuell.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
BIN
img/MA-Umsetzung-Welt-Blender.png
Normal file
BIN
img/MA-Umsetzung-Welt-Blender.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
BIN
img/MA-Umsetzung-Welt-Plan.drawio.pdf
Normal file
BIN
img/MA-Umsetzung-Welt-Plan.drawio.pdf
Normal file
Binary file not shown.
Binary file not shown.
145
main.bbl
Normal file
145
main.bbl
Normal file
@ -0,0 +1,145 @@
|
||||
% $ biblatex auxiliary file $
|
||||
% $ biblatex bbl format version 3.2 $
|
||||
% Do not modify the above lines!
|
||||
%
|
||||
% This is an auxiliary file used by the 'biblatex' package.
|
||||
% This file may safely be deleted. It will be recreated by
|
||||
% biber as required.
|
||||
%
|
||||
\begingroup
|
||||
\makeatletter
|
||||
\@ifundefined{ver@biblatex.sty}
|
||||
{\@latex@error
|
||||
{Missing 'biblatex' package}
|
||||
{The bibliography requires the 'biblatex' package.}
|
||||
\aftergroup\endinput}
|
||||
{}
|
||||
\endgroup
|
||||
|
||||
|
||||
\refsection{0}
|
||||
\datalist[entry]{nty/global//global/global}
|
||||
\entry{colcon}{misc}{}
|
||||
\field{sortinit}{c}
|
||||
\field{sortinithash}{4d103a86280481745c9c897c925753c0}
|
||||
\field{labeltitlesource}{title}
|
||||
\field{note}{letzter Zugriff: 02.04.2023}
|
||||
\field{title}{colcon - collective construction}
|
||||
\verb{urlraw}
|
||||
\verb https://colcon.readthedocs.io/en/released/
|
||||
\endverb
|
||||
\verb{url}
|
||||
\verb https://colcon.readthedocs.io/en/released/
|
||||
\endverb
|
||||
\endentry
|
||||
\entry{ros-git}{misc}{}
|
||||
\field{sortinit}{G}
|
||||
\field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
|
||||
\field{labeltitlesource}{title}
|
||||
\field{note}{letzter Zugriff: 02.04.2023}
|
||||
\field{title}{GitHub - ros2/ros2: The Robot Operating System, is a meta operating system for robots.}
|
||||
\verb{urlraw}
|
||||
\verb https://github.com/ros2/ros2
|
||||
\endverb
|
||||
\verb{url}
|
||||
\verb https://github.com/ros2/ros2
|
||||
\endverb
|
||||
\endentry
|
||||
\entry{doi:10.1126/scirobotics.abm6074}{article}{}
|
||||
\name{author}{5}{}{%
|
||||
{{hash=7b84d10a03303cd00f198fefb38a5da3}{%
|
||||
family={Macenski},
|
||||
familyi={M\bibinitperiod},
|
||||
given={Steven},
|
||||
giveni={S\bibinitperiod}}}%
|
||||
{{hash=0d11ace6e44e4742ea1692d7ddf4819e}{%
|
||||
family={Foote},
|
||||
familyi={F\bibinitperiod},
|
||||
given={Tully},
|
||||
giveni={T\bibinitperiod}}}%
|
||||
{{hash=a8ad4a5f43253f69552460c946e34e49}{%
|
||||
family={Gerkey},
|
||||
familyi={G\bibinitperiod},
|
||||
given={Brian},
|
||||
giveni={B\bibinitperiod}}}%
|
||||
{{hash=4e2c9f9d04cf548117105f50a9c8a7a1}{%
|
||||
family={Lalancette},
|
||||
familyi={L\bibinitperiod},
|
||||
given={Chris},
|
||||
giveni={C\bibinitperiod}}}%
|
||||
{{hash=fe838d86b89f8983167a3747e11998bb}{%
|
||||
family={Woodall},
|
||||
familyi={W\bibinitperiod},
|
||||
given={William},
|
||||
giveni={W\bibinitperiod}}}%
|
||||
}
|
||||
\strng{namehash}{4a195e02383364d4009f77ca22451e11}
|
||||
\strng{fullhash}{c321d95ccac4f92536f0f1ed99f34d05}
|
||||
\strng{bibnamehash}{4a195e02383364d4009f77ca22451e11}
|
||||
\strng{authorbibnamehash}{4a195e02383364d4009f77ca22451e11}
|
||||
\strng{authornamehash}{4a195e02383364d4009f77ca22451e11}
|
||||
\strng{authorfullhash}{c321d95ccac4f92536f0f1ed99f34d05}
|
||||
\field{sortinit}{M}
|
||||
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
|
||||
\field{labelnamesource}{author}
|
||||
\field{labeltitlesource}{title}
|
||||
\field{journaltitle}{Science Robotics}
|
||||
\field{number}{66}
|
||||
\field{title}{Robot Operating System 2: Design, architecture, and uses in the wild}
|
||||
\field{volume}{7}
|
||||
\field{year}{2022}
|
||||
\field{pages}{eabm6074}
|
||||
\range{pages}{-1}
|
||||
\verb{doi}
|
||||
\verb 10.1126/scirobotics.abm6074
|
||||
\endverb
|
||||
\verb{urlraw}
|
||||
\verb https://www.science.org/doi/abs/10.1126/scirobotics.abm6074
|
||||
\endverb
|
||||
\verb{url}
|
||||
\verb https://www.science.org/doi/abs/10.1126/scirobotics.abm6074
|
||||
\endverb
|
||||
\endentry
|
||||
\entry{moveitpython}{misc}{}
|
||||
\field{sortinit}{M}
|
||||
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
|
||||
\field{labeltitlesource}{title}
|
||||
\field{note}{letzter Zugriff: 10.04.2023}
|
||||
\field{title}{MoveIt Commander with ROS2 - Issue \#337 - ros-planning/moveit2_tutorials}
|
||||
\verb{urlraw}
|
||||
\verb https://github.com/ros-planning/moveit2_tutorials/issues/337
|
||||
\endverb
|
||||
\verb{url}
|
||||
\verb https://github.com/ros-planning/moveit2_tutorials/issues/337
|
||||
\endverb
|
||||
\endentry
|
||||
\entry{moveitpipeline}{misc}{}
|
||||
\field{sortinit}{m}
|
||||
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
|
||||
\field{labeltitlesource}{title}
|
||||
\field{note}{letzter Zugriff: 02.04.2023}
|
||||
\field{title}{moveit2_tutorials/moveit_pipeline.png at humble - ros-planning/moveit2_tutorials}
|
||||
\verb{urlraw}
|
||||
\verb https://github.com/ros-planning/moveit2_tutorials/blob/humble/_static/images/moveit_pipeline.png
|
||||
\endverb
|
||||
\verb{url}
|
||||
\verb https://github.com/ros-planning/moveit2_tutorials/blob/humble/_static/images/moveit_pipeline.png
|
||||
\endverb
|
||||
\endentry
|
||||
\entry{rospackages}{misc}{}
|
||||
\field{sortinit}{P}
|
||||
\field{sortinithash}{ff3bcf24f47321b42cb156c2cc8a8422}
|
||||
\field{labeltitlesource}{title}
|
||||
\field{note}{letzter Zugriff: 10.04.2023}
|
||||
\field{title}{Packages - /ros2/ubuntu/pool/main/ :: Oregon State University Open Source Lab}
|
||||
\verb{urlraw}
|
||||
\verb http://packages.ros.org/ros2/ubuntu/pool/main/
|
||||
\endverb
|
||||
\verb{url}
|
||||
\verb http://packages.ros.org/ros2/ubuntu/pool/main/
|
||||
\endverb
|
||||
\endentry
|
||||
\enddatalist
|
||||
\endrefsection
|
||||
\endinput
|
||||
|
||||
30
main.bib
30
main.bib
@ -35,12 +35,6 @@
|
||||
note = {letzter Zugriff: 13.4.2022},
|
||||
}
|
||||
|
||||
@misc{sdf,
|
||||
title = {SDFormat Specification},
|
||||
url = {http://sdformat.org/spec},
|
||||
note = {letzter Zugriff: 13.4.2022},
|
||||
}
|
||||
|
||||
@misc{urdf,
|
||||
title = {Tutorial: Using a URDF in Gazebo},
|
||||
url = {http://gazebosim.org/tutorials/?tut=ros_urdf},
|
||||
@ -142,3 +136,27 @@
|
||||
url = {https://unity.com/solutions/automotive-transportation-manufacturing/robotics},
|
||||
note = {letzter Zugriff: 10.04.2023},
|
||||
}
|
||||
|
||||
@misc{freecad,
|
||||
title = {FreeCAD: Ihr parametrischer 3D-Modellierer},
|
||||
url = {https://www.freecad.org/index.php?lang=de},
|
||||
note = {letzter Zugriff: 21.04.2023},
|
||||
}
|
||||
|
||||
@misc{xacro,
|
||||
title = {FreeCAD: Ihr parametrischer 3D-Modellierer},
|
||||
url = {https://github.com/ros/xacro},
|
||||
note = {letzter Zugriff: 21.04.2023},
|
||||
}
|
||||
|
||||
@misc{gazebo-app,
|
||||
title = {Gazebo},
|
||||
url = {https://app.gazebosim.org/dashboard},
|
||||
note = {letzter Zugriff: 23.04.2023},
|
||||
}
|
||||
|
||||
@misc{sdf-format,
|
||||
title = {SDFormat Specification},
|
||||
url = {https://sdformat.org/spec},
|
||||
note = {letzter Zugriff: 23.04.2023},
|
||||
}
|
||||
|
||||
15
main.blg
Normal file
15
main.blg
Normal file
@ -0,0 +1,15 @@
|
||||
[0] Config.pm:307> INFO - This is Biber 2.19
|
||||
[0] Config.pm:310> INFO - Logfile is 'main.blg'
|
||||
[44] biber:340> INFO - === Sa Apr 15, 2023, 22:14:36
|
||||
[51] Biber.pm:419> INFO - Reading 'main.bcf'
|
||||
[88] Biber.pm:979> INFO - Found 6 citekeys in bib section 0
|
||||
[95] Biber.pm:4419> INFO - Processing section 0
|
||||
[100] Biber.pm:4610> INFO - Looking for bibtex file 'main.bib' for section 0
|
||||
[101] bibtex.pm:1713> INFO - LaTeX decoding ...
|
||||
[107] bibtex.pm:1519> INFO - Found BibTeX data source 'main.bib'
|
||||
[131] UCollate.pm:68> INFO - Overriding locale 'de-DE' defaults 'variable = shifted' with 'variable = non-ignorable'
|
||||
[131] UCollate.pm:68> INFO - Overriding locale 'de-DE' defaults 'normalization = NFD' with 'normalization = prenormalized'
|
||||
[131] Biber.pm:4239> INFO - Sorting list 'nty/global//global/global' of type 'entry' with template 'nty' and locale 'de-DE'
|
||||
[131] Biber.pm:4245> INFO - No sort tailoring available for locale 'de-DE'
|
||||
[136] bbl.pm:660> INFO - Writing 'main.bbl' with encoding 'UTF-8'
|
||||
[137] bbl.pm:763> INFO - Output to main.bbl
|
||||
204
main.out.ps
204
main.out.ps
@ -4,78 +4,238 @@
|
||||
ifelse
|
||||
[
|
||||
/Title(\376\377\000E\000i\000n\000l\000e\000i\000t\000u\000n\000g)
|
||||
/Count -4
|
||||
/Action/GoTo/Dest(chapter.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000A\000u\000f\000g\000a\000b\000e)
|
||||
/Title(\376\377\000M\000o\000t\000i\000v\000a\000t\000i\000o\000n)
|
||||
/Action/GoTo/Dest(section.1.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000S\000t\000a\000n\000d\000\040\000d\000e\000r\000\040\000W\000i\000s\000s\000e\000n\000s\000c\000h\000a\000f\000t)
|
||||
/Action/GoTo/Dest(section.1.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000W\000e\000l\000c\000h\000e\000\040\000S\000z\000e\000n\000a\000r\000i\000e\000n)
|
||||
/Action/GoTo/Dest(section.1.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000W\000e\000l\000c\000h\000e\000r\000\040\000N\000u\000t\000z\000e\000n\000\040\000/\000\040\000C\000o\000n\000t\000r\000i\000b\000u\000t\000i\000o\000n\000s)
|
||||
/Action/GoTo/Dest(section.1.4)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000K\000o\000n\000z\000e\000p\000t)
|
||||
/Count -3
|
||||
/Action/GoTo/Dest(chapter.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000L\000\366\000s\000u\000n\000g\000s\000k\000o\000n\000z\000e\000p\000t)
|
||||
/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000s)
|
||||
/Action/GoTo/Dest(section.2.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000\040\000d\000e\000s\000\040\000M\000e\000n\000s\000c\000h\000e\000n)
|
||||
/Action/GoTo/Dest(section.2.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
|
||||
/Action/GoTo/Dest(section.2.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000K\000o\000m\000p\000o\000n\000e\000n\000t\000e\000n\000-\000/\000S\000o\000f\000t\000w\000a\000r\000e\000a\000u\000s\000w\000a\000h\000l)
|
||||
/Count -4
|
||||
/Action/GoTo/Dest(chapter.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000R\000O\000S)
|
||||
/Title(\376\377\000D\000i\000e\000n\000s\000t\000u\000m\000g\000e\000b\000u\000n\000g\000\040\000\050\000R\000O\000S\0002\000\051)
|
||||
/Count -2
|
||||
/Action/GoTo/Dest(section.3.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000M\000o\000v\000e\000I\000t)
|
||||
/Title(\376\377\000A\000u\000s\000w\000a\000h\000l)
|
||||
/Action/GoTo/Dest(subsection.3.1.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e)
|
||||
/Title(\376\377\000B\000e\000s\000c\000h\000r\000e\000i\000b\000u\000n\000g)
|
||||
/Action/GoTo/Dest(subsection.3.1.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000G\000a\000z\000e\000b\000o)
|
||||
/Count -1
|
||||
/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000s\000u\000m\000g\000e\000b\000u\000n\000g\000\040\000\050\000G\000a\000z\000e\000b\000o\000\051)
|
||||
/Count -3
|
||||
/Action/GoTo/Dest(section.3.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000S\000e\000n\000s\000o\000r\000e\000n)
|
||||
/Title(\376\377\000A\000u\000s\000w\000a\000h\000l)
|
||||
/Action/GoTo/Dest(subsection.3.2.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000R\000o\000b\000o\000t\000e\000r)
|
||||
/Title(\376\377\000R\000o\000b\000o\000t\000e\000r\000s\000i\000m\000u\000l\000a\000t\000i\000o\000n)
|
||||
/Action/GoTo/Dest(subsection.3.2.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000M\000e\000n\000s\000c\000h\000e\000n\000s\000i\000m\000u\000l\000a\000t\000i\000o\000n)
|
||||
/Action/GoTo/Dest(subsection.3.2.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000R\000o\000b\000o\000t\000e\000r\000u\000m\000g\000e\000b\000u\000n\000g\000\040\000\050\000M\000o\000v\000e\000I\000t\0002\000\051)
|
||||
/Action/GoTo/Dest(section.3.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000Z\000u\000s\000a\000m\000m\000e\000n\000f\000a\000s\000s\000u\000n\000g)
|
||||
/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
|
||||
/Action/GoTo/Dest(section.3.4)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000U\000m\000s\000e\000t\000z\000u\000n\000g)
|
||||
/Count -1
|
||||
/Count -4
|
||||
/Action/GoTo/Dest(chapter.4)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000R\000O\000S)
|
||||
/Count -4
|
||||
/Title(\376\377\000G\000r\000u\000n\000d\000l\000e\000g\000e\000n\000d\000e\000r\000\040\000S\000y\000s\000t\000e\000m\000a\000u\000f\000b\000a\000u)
|
||||
/Action/GoTo/Dest(section.4.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000A\000u\000s\000w\000a\000h\000l\000\040\000d\000e\000r\000\040\000R\000O\000S\000-\000U\000m\000g\000e\000b\000u\000n\000g)
|
||||
/Action/GoTo/Dest(subsection.4.1.1)cvn
|
||||
/Title(\376\377\000M\000e\000n\000s\000c\000h)
|
||||
/Count -3
|
||||
/Action/GoTo/Dest(section.4.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000G\000a\000z\000e\000b\000o)
|
||||
/Action/GoTo/Dest(subsection.4.1.2)cvn
|
||||
/Title(\376\377\000\334\000b\000e\000r\000s\000i\000c\000h\000t)
|
||||
/Action/GoTo/Dest(subsection.4.2.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000M\000o\000v\000e\000I\000t)
|
||||
/Action/GoTo/Dest(subsection.4.1.3)cvn
|
||||
/Title(\376\377\000M\000o\000d\000e\000l\000l\000i\000e\000r\000u\000n\000g)
|
||||
/Action/GoTo/Dest(subsection.4.2.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000u\000r\000-\000T\000r\000e\000e\000s)
|
||||
/Action/GoTo/Dest(subsection.4.1.4)cvn
|
||||
/Title(\376\377\000P\000r\000o\000g\000r\000a\000m\000m\000i\000e\000r\000u\000n\000g)
|
||||
/Action/GoTo/Dest(subsection.4.2.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000E\000r\000g\000e\000b\000n\000i\000s\000s\000e)
|
||||
/Title(\376\377\000R\000o\000b\000o\000t\000e\000r)
|
||||
/Count -4
|
||||
/Action/GoTo/Dest(section.4.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000\334\000b\000e\000r\000s\000i\000c\000h\000t)
|
||||
/Action/GoTo/Dest(subsection.4.3.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000M\000o\000d\000e\000l\000l\000i\000e\000r\000u\000n\000g)
|
||||
/Action/GoTo/Dest(subsection.4.3.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000M\000o\000v\000e\000I\000t\000\040\0002\000\040\000K\000o\000n\000f\000i\000g\000u\000r\000a\000t\000i\000o\000n)
|
||||
/Action/GoTo/Dest(subsection.4.3.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000D\000e\000t\000a\000i\000l\000s)
|
||||
/Action/GoTo/Dest(subsection.4.3.4)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s)
|
||||
/Count -1
|
||||
/Action/GoTo/Dest(section.4.4)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000A\000s\000y\000n\000c\000h\000r\000o\000n\000e\000\040\000N\000o\000d\000e\000s)
|
||||
/Action/GoTo/Dest(subsection.4.4.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000S\000z\000e\000n\000a\000r\000i\000e\000n\000b\000a\000s\000i\000e\000r\000t\000e\000\040\000E\000v\000a\000l\000u\000a\000t\000i\000o\000n)
|
||||
/Count -3
|
||||
/Action/GoTo/Dest(chapter.5)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000\040\000d\000e\000s\000\040\000M\000e\000n\000s\000c\000h\000e\000n)
|
||||
/Action/GoTo/Dest(section.5.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000B\000e\000w\000e\000g\000u\000n\000g\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000s)
|
||||
/Action/GoTo/Dest(section.5.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000B\000e\000h\000a\000v\000i\000o\000r\000T\000r\000e\000e\000s)
|
||||
/Count -2
|
||||
/Action/GoTo/Dest(section.5.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000N\000o\000d\000e\000s)
|
||||
/Action/GoTo/Dest(subsection.5.3.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000K\000o\000m\000b\000i\000n\000i\000e\000r\000e\000n\000\040\000v\000o\000n\000\040\000N\000o\000d\000e\000s\000\040\000z\000u\000\040\000e\000i\000n\000e\000r\000\040\000R\000e\000q\000u\000e\000s\000t)
|
||||
/Action/GoTo/Dest(subsection.5.3.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000D\000i\000s\000k\000u\000s\000s\000i\000o\000n)
|
||||
/Count -2
|
||||
/Action/GoTo/Dest(chapter.6)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000L\000e\000s\000s\000o\000n\000s\000\040\000L\000e\000a\000r\000n\000e\000d\000\040\000b\000e\000i\000\040\000d\000e\000r\000\040\000U\000m\000s\000e\000t\000z\000u\000n\000g)
|
||||
/Count -4
|
||||
/Action/GoTo/Dest(section.6.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000E\000r\000s\000t\000e\000l\000l\000u\000n\000g\000\040\000d\000e\000s\000\040\000R\000o\000b\000o\000t\000e\000r\000m\000o\000d\000e\000l\000l\000s)
|
||||
/Action/GoTo/Dest(subsection.6.1.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000G\000a\000z\000e\000b\000o)
|
||||
/Action/GoTo/Dest(subsection.6.1.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000R\000O\000S\0002)
|
||||
/Action/GoTo/Dest(subsection.6.1.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000M\000o\000v\000e\000I\000t\0002)
|
||||
/Action/GoTo/Dest(subsection.6.1.4)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000L\000e\000s\000s\000o\000n\000s\000\040\000L\000e\000a\000r\000n\000e\000d\000\040\000b\000e\000i\000\040\000d\000e\000n\000\040\000S\000z\000e\000n\000a\000r\000i\000e\000n)
|
||||
/Count -1
|
||||
/Action/GoTo/Dest(section.6.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000D\000e\000b\000u\000g\000g\000i\000n\000g)
|
||||
/Action/GoTo/Dest(subsection.6.2.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000Z\000u\000s\000a\000m\000m\000e\000n\000f\000a\000s\000s\000u\000n\000g\000\040\000u\000n\000d\000\040\000A\000u\000s\000b\000l\000i\000c\000k)
|
||||
/Count -3
|
||||
/Action/GoTo/Dest(chapter.7)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000E\000r\000g\000e\000b\000n\000i\000s\000s\000e)
|
||||
/Count -2
|
||||
/Action/GoTo/Dest(section.7.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000G\000r\000a\000p\000h\000i\000s\000c\000h\000e\000\040\000R\000e\000p\000r\000\344\000s\000e\000n\000t\000a\000t\000i\000o\000n\000\040\000d\000e\000r\000\040\000S\000z\000e\000n\000a\000r\000i\000e\000n)
|
||||
/Action/GoTo/Dest(subsection.7.1.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000A\000n\000p\000a\000s\000s\000u\000n\000g\000\040\000d\000e\000r\000\040\000B\000e\000h\000a\000v\000i\000o\000r\000\040\000T\000r\000e\000e\000s\000\040\000a\000n\000\040\000S\000z\000e\000n\000a\000r\000i\000e\000n)
|
||||
/Action/GoTo/Dest(subsection.7.1.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000D\000i\000s\000k\000u\000s\000s\000i\000o\000n)
|
||||
/Action/GoTo/Dest(section.7.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000A\000u\000s\000b\000l\000i\000c\000k)
|
||||
/Count -3
|
||||
/Action/GoTo/Dest(section.7.3)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000U\000m\000s\000e\000t\000z\000u\000n\000g\000\040\000i\000n\000\040\000a\000n\000d\000e\000r\000e\000m\000\040\000S\000i\000m\000u\000l\000a\000t\000o\000r)
|
||||
/Action/GoTo/Dest(subsection.7.3.1)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000S\000i\000m\000u\000l\000a\000t\000i\000o\000n\000\040\000b\000e\000w\000e\000g\000t\000e\000r\000\040\000O\000b\000j\000e\000k\000t\000e)
|
||||
/Action/GoTo/Dest(subsection.7.3.2)cvn
|
||||
/OUT pdfmark
|
||||
[
|
||||
/Title(\376\377\000E\000r\000g\000\344\000n\000z\000u\000n\000g\000\040\000v\000o\000n\000\040\000U\000m\000g\000e\000b\000u\000n\000g\000s\000e\000r\000k\000e\000n\000n\000u\000n\000g)
|
||||
/Action/GoTo/Dest(subsection.7.3.3)cvn
|
||||
/OUT pdfmark
|
||||
|
||||
86
main.run.xml
Normal file
86
main.run.xml
Normal file
@ -0,0 +1,86 @@
|
||||
<?xml version="1.0" standalone="yes"?>
|
||||
<!-- logreq request file -->
|
||||
<!-- logreq version 1.0 / dtd version 1.0 -->
|
||||
<!-- Do not edit this file! -->
|
||||
<!DOCTYPE requests [
|
||||
<!ELEMENT requests (internal | external)*>
|
||||
<!ELEMENT internal (generic, (provides | requires)*)>
|
||||
<!ELEMENT external (generic, cmdline?, input?, output?, (provides | requires)*)>
|
||||
<!ELEMENT cmdline (binary, (option | infile | outfile)*)>
|
||||
<!ELEMENT input (file)+>
|
||||
<!ELEMENT output (file)+>
|
||||
<!ELEMENT provides (file)+>
|
||||
<!ELEMENT requires (file)+>
|
||||
<!ELEMENT generic (#PCDATA)>
|
||||
<!ELEMENT binary (#PCDATA)>
|
||||
<!ELEMENT option (#PCDATA)>
|
||||
<!ELEMENT infile (#PCDATA)>
|
||||
<!ELEMENT outfile (#PCDATA)>
|
||||
<!ELEMENT file (#PCDATA)>
|
||||
<!ATTLIST requests
|
||||
version CDATA #REQUIRED
|
||||
>
|
||||
<!ATTLIST internal
|
||||
package CDATA #REQUIRED
|
||||
priority (9) #REQUIRED
|
||||
active (0 | 1) #REQUIRED
|
||||
>
|
||||
<!ATTLIST external
|
||||
package CDATA #REQUIRED
|
||||
priority (1 | 2 | 3 | 4 | 5 | 6 | 7 | 8) #REQUIRED
|
||||
active (0 | 1) #REQUIRED
|
||||
>
|
||||
<!ATTLIST provides
|
||||
type (static | dynamic | editable) #REQUIRED
|
||||
>
|
||||
<!ATTLIST requires
|
||||
type (static | dynamic | editable) #REQUIRED
|
||||
>
|
||||
<!ATTLIST file
|
||||
type CDATA #IMPLIED
|
||||
>
|
||||
]>
|
||||
<requests version="1.0">
|
||||
<internal package="biblatex" priority="9" active="0">
|
||||
<generic>latex</generic>
|
||||
<provides type="dynamic">
|
||||
<file>main.bcf</file>
|
||||
</provides>
|
||||
<requires type="dynamic">
|
||||
<file>main.bbl</file>
|
||||
</requires>
|
||||
<requires type="static">
|
||||
<file>blx-dm.def</file>
|
||||
<file>blx-compat.def</file>
|
||||
<file>biblatex.def</file>
|
||||
<file>standard.bbx</file>
|
||||
<file>numeric.bbx</file>
|
||||
<file>numeric.cbx</file>
|
||||
<file>biblatex.cfg</file>
|
||||
<file>german.lbx</file>
|
||||
<file>ngerman.lbx</file>
|
||||
</requires>
|
||||
</internal>
|
||||
<external package="biblatex" priority="5" active="0">
|
||||
<generic>biber</generic>
|
||||
<cmdline>
|
||||
<binary>biber</binary>
|
||||
<infile>main</infile>
|
||||
</cmdline>
|
||||
<input>
|
||||
<file>main.bcf</file>
|
||||
</input>
|
||||
<output>
|
||||
<file>main.bbl</file>
|
||||
</output>
|
||||
<provides type="dynamic">
|
||||
<file>main.bbl</file>
|
||||
</provides>
|
||||
<requires type="dynamic">
|
||||
<file>main.bcf</file>
|
||||
</requires>
|
||||
<requires type="editable">
|
||||
<file>main.bib</file>
|
||||
</requires>
|
||||
</external>
|
||||
</requests>
|
||||
BIN
main.synctex.gz
Normal file
BIN
main.synctex.gz
Normal file
Binary file not shown.
51
main.tex
51
main.tex
@ -13,7 +13,6 @@ parskip=half,
|
||||
\usepackage{acro}
|
||||
\usepackage{listings}
|
||||
\usepackage[style=numeric,backend=biber]{biblatex}
|
||||
%\usepackage[style=numeric,backend=libbib]{biblatex}
|
||||
\usepackage{pdfpages}
|
||||
\usepackage{scrhack}
|
||||
\usepackage{xcolor}
|
||||
@ -21,7 +20,9 @@ parskip=half,
|
||||
\usepackage{hyperref}
|
||||
\usepackage{tabularray}
|
||||
\usepackage{xurl}
|
||||
\usepackage{soul}
|
||||
\usepackage{xcolor}
|
||||
\usepackage{inconsolata}
|
||||
\usepackage[strings]{underscore}
|
||||
|
||||
\usepackage[letterspace=150]{microtype}
|
||||
@ -34,7 +35,13 @@ parskip=half,
|
||||
}
|
||||
|
||||
\definecolor{light-gray}{gray}{0.95}
|
||||
\newcommand{\code}[1]{\colorbox{light-gray}{\texttt{#1}}}
|
||||
%\newcommand{\code}[1]{\colorbox{light-gray}{\texttt{#1}}}
|
||||
\newcommand{\code}[1]{
|
||||
\begingroup%
|
||||
\sethlcolor{light-gray}%
|
||||
\hl{\texttt{#1}}%
|
||||
\endgroup
|
||||
}
|
||||
|
||||
\ihead*{\rightmark}
|
||||
\ohead*{\thepage}
|
||||
@ -120,6 +127,10 @@ parskip=half,
|
||||
-Nur CAD-Dateien der Außenhülle
|
||||
|
||||
-Schätzung von Spezifikationen anhand Marketingmaterial
|
||||
\subsection{Erweiterung des Robotermodells mit MoveIt}
|
||||
-Fehler durch falsche Pfade des Setups
|
||||
|
||||
-Fehler durch fehlerhafte Config (Mal nachsehen, was das genau war)
|
||||
\subsection{Gazebo}
|
||||
\subsubsection{Upgrade auf Ignition}
|
||||
Gazebo ist zu diesem Zeitpunkt in mehreren, teilweise gleichnamigen Versionen verfügbar, welche sich jedoch grundlegend unterscheiden.
|
||||
@ -141,11 +152,28 @@ Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler währe
|
||||
Auch das alte Plugin musste auf das neue System angepasst werden, was auch hier zu einer kompletten Neuimplementation führte, da die internen Systeme zu große Unterschiede aufwiesen.
|
||||
Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, welche auf ein Entity-Component-System umstellte, aber auch sahlreiche kleinere Änderungen
|
||||
\subsubsection{Pluginarchitektur}
|
||||
-Plugins werden im selben Kontext geladen, verwendung von Librarys mit globalem Kontext schwer
|
||||
\subsubsection{Doppelte Messagedienste}
|
||||
-Duplizierung von Messagediensten in ROS und Gazebo
|
||||
Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
|
||||
Jedoch existiert damit jedes Plugin im selben Prozess, was bei der Nutzung von Bibliotheken, welche nicht für die mehrfache Nutzung im selben Prozess entsprechend ausgelegt wurden, zu Problemen führen kann.
|
||||
|
||||
Zur Kommunikation des ActorPlugins mit dem ROS-ActionServer wurde die benötigte Funktionalität vorerst im Plugin selbst implementiert.
|
||||
Da diese Funktionalität zuerst entwickelt wurde, konnte sie zu diesem Zeitpunkt nur alleinstehend getestet werden.
|
||||
Diese Tests verliefen vorerst erfolgreich, jedoch scheiterten sie bei der Integration des Robotermodells, welches über die \code{ros_control}-Integration ebenfalls \code{rclcpp} nutzt.
|
||||
|
||||
Um dieses Problem zu umgehen, sind mehrere Lösungsansätze denkbar.
|
||||
\begin{description}
|
||||
\item[Separater Nachrichtendienst]
|
||||
Ein solcher losgelöster Dienst kann die Nachrichten mit einem anderen Programm auszutauschen, welches die Kommunikation nach außen übernimmt.
|
||||
\item[Nutzung der gleichen ROS-Instanz]
|
||||
Um dem Problem zu begegnen, könnte auch eine globale ROS-Instanz von Gazebo verwaltet werden, welche dann von den Plugins genutzt werden kann.
|
||||
Dies könnte als ein Plugin realisiert werden, welches diese anderen Plugins zur Verfügung stellt, jedoch müssten die anderen Plugins zur Nutzung dieser Schnittstelle modifiziert werden.
|
||||
\item[Gazebo-ROS-Brücke]
|
||||
Die Gazebo-ROS-Brücke kann Nachrichten, welche in beiden Formaten definiert wurden, ineinander umwandeln.
|
||||
Dies ermöglicht die Kommunikation über die Brücke als Mittelmann.
|
||||
Dabei müssten Anpassungen an der Architektur vorgenommen werden, da Gazebo kein Äquivalent zum ActionServer besitzt.
|
||||
\end{description}
|
||||
Die Entscheidung fiel auf einen separaten Nachrichtendienst, da dessen Implementation losgelöst von anderen Systemen funktioniert.
|
||||
Natürlich ist die Einführung eines weiteren Nachrichtendienstes ein Bruch der Philosophie, jedoch die einzige Methode, die garantiert funktioniert, weswegen sie letztendlich implementiert wurde.
|
||||
|
||||
-Potentielle Lösung in einer Präsentation angekündigt (mal sehen, ob ich die wiederfinde)
|
||||
\subsubsection{Fehlende Animationsgrundlagen}
|
||||
-Animationen werden als .col bereitgestellt
|
||||
|
||||
@ -203,11 +231,18 @@ Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, w
|
||||
|
||||
-Daten aus Gazebo extrahieren und in MoveIt einbinden
|
||||
|
||||
-Person in OctoMap erkennen
|
||||
-Person in OctoMap\cite{octomap} erkennen
|
||||
\subsection{Zusammenbringen von ActorPlugin und ActorServer}
|
||||
-Mechanismus für Datenaustausch zwischen ROS und Gazebo überdenken/überarbeiten
|
||||
|
||||
-Geteilte ROS Instanz zwischen Plugins? Wie?
|
||||
|
||||
-Potentielle Integration von ROS als Messagedients in Gazebo
|
||||
|
||||
|
||||
\printbibliography
|
||||
\markboth{Anhang}{Anhang}
|
||||
\begin{figure}[h]
|
||||
\begin{figure}[ht]
|
||||
\includegraphics[width=14cm]{img/moveit_pipeline}
|
||||
\caption{Visualisierung der MoveIt Pipeline\cite{moveitpipeline}}
|
||||
\label{moveitpipeline}
|
||||
|
||||
79
main.toc
Normal file
79
main.toc
Normal file
@ -0,0 +1,79 @@
|
||||
\acswitchoff
|
||||
\babel@toc {ngerman}{}\relax
|
||||
\contentsline {chapter}{\numberline {1}Einleitung}{1}{chapter.1}%
|
||||
\contentsline {section}{\numberline {1.1}Motivation}{1}{section.1.1}%
|
||||
\contentsline {section}{\numberline {1.2}Stand der Wissenschaft}{1}{section.1.2}%
|
||||
\contentsline {section}{\numberline {1.3}Welche Szenarien}{2}{section.1.3}%
|
||||
\contentsline {section}{\numberline {1.4}Welcher Nutzen / Contributions}{2}{section.1.4}%
|
||||
\contentsline {chapter}{\numberline {2}Konzept}{4}{chapter.2}%
|
||||
\contentsline {section}{\numberline {2.1}Simulation des Roboters}{4}{section.2.1}%
|
||||
\contentsline {section}{\numberline {2.2}Simulation des Menschen}{5}{section.2.2}%
|
||||
\contentsline {section}{\numberline {2.3}Behavior Trees als Beschreibungssprache}{5}{section.2.3}%
|
||||
\contentsline {section}{\numberline {2.4}Virtualisierungsumgebung als Platform}{6}{section.2.4}%
|
||||
\contentsline {chapter}{\numberline {3}Komponenten-/Softwareauswahl}{7}{chapter.3}%
|
||||
\contentsline {section}{\numberline {3.1}Dienstumgebung (ROS2)}{7}{section.3.1}%
|
||||
\contentsline {subsection}{\numberline {3.1.1}Auswahl}{7}{subsection.3.1.1}%
|
||||
\contentsline {subsection}{\numberline {3.1.2}Beschreibung}{8}{subsection.3.1.2}%
|
||||
\contentsline {section}{\numberline {3.2}Simulationsumgebung (Gazebo)}{9}{section.3.2}%
|
||||
\contentsline {subsection}{\numberline {3.2.1}Auswahl}{9}{subsection.3.2.1}%
|
||||
\contentsline {subsection}{\numberline {3.2.2}Robotersimulation}{10}{subsection.3.2.2}%
|
||||
\contentsline {subsection}{\numberline {3.2.3}Menschensimulation}{11}{subsection.3.2.3}%
|
||||
\contentsline {section}{\numberline {3.3}Roboterumgebung (MoveIt2)}{12}{section.3.3}%
|
||||
\contentsline {section}{\numberline {3.4}Behavior Trees}{13}{section.3.4}%
|
||||
\contentsline {subsection}{\numberline {3.4.1}Asynchrone Nodes}{14}{subsection.3.4.1}%
|
||||
\contentsline {section}{\numberline {3.5}Docker-Compose als Virtualisierungsumgebung}{15}{section.3.5}%
|
||||
\contentsline {chapter}{\numberline {4}Umsetzung}{16}{chapter.4}%
|
||||
\contentsline {section}{\numberline {4.1}Grundlegender Systemaufbau}{16}{section.4.1}%
|
||||
\contentsline {section}{\numberline {4.2}Verwendete Datentypen}{16}{section.4.2}%
|
||||
\contentsline {section}{\numberline {4.3}Mensch}{18}{section.4.3}%
|
||||
\contentsline {subsection}{\numberline {4.3.1}Übersicht}{18}{subsection.4.3.1}%
|
||||
\contentsline {subsection}{\numberline {4.3.2}Modellierung}{18}{subsection.4.3.2}%
|
||||
\contentsline {subsection}{\numberline {4.3.3}Programmierung}{19}{subsection.4.3.3}%
|
||||
\contentsline {subsubsection}{\nonumberline Message Queue}{19}{subsubsection*.3}%
|
||||
\contentsline {subsubsection}{\nonumberline Nachrichten}{21}{subsubsection*.5}%
|
||||
\contentsline {subsubsection}{\nonumberline ActorServer}{21}{subsubsection*.7}%
|
||||
\contentsline {subsubsection}{\nonumberline Gazebo Plugin}{22}{subsubsection*.9}%
|
||||
\contentsline {section}{\numberline {4.4}Roboter}{22}{section.4.4}%
|
||||
\contentsline {subsection}{\numberline {4.4.1}Übersicht}{22}{subsection.4.4.1}%
|
||||
\contentsline {subsection}{\numberline {4.4.2}Modellierung}{22}{subsection.4.4.2}%
|
||||
\contentsline {subsection}{\numberline {4.4.3}MoveIt 2 Konfiguration}{23}{subsection.4.4.3}%
|
||||
\contentsline {subsection}{\numberline {4.4.4}Details}{24}{subsection.4.4.4}%
|
||||
\contentsline {section}{\numberline {4.5}Behavior Trees}{24}{section.4.5}%
|
||||
\contentsline {subsubsection}{\nonumberline Allgemein nutzbare Nodes}{24}{subsubsection*.11}%
|
||||
\contentsline {subsubsection}{\nonumberline Menschenspezifisch}{25}{subsubsection*.13}%
|
||||
\contentsline {subsubsection}{\nonumberline Roboterspezifisch}{26}{subsubsection*.15}%
|
||||
\contentsline {section}{\numberline {4.6}Docker-Compose}{26}{section.4.6}%
|
||||
\contentsline {chapter}{\numberline {5}Szenarienbasierte Evaluation}{28}{chapter.5}%
|
||||
\contentsline {section}{\numberline {5.1}Simulation des Menschen}{28}{section.5.1}%
|
||||
\contentsline {section}{\numberline {5.2}Bewegung des Roboters}{28}{section.5.2}%
|
||||
\contentsline {section}{\numberline {5.3}BehaviorTrees}{28}{section.5.3}%
|
||||
\contentsline {subsection}{\numberline {5.3.1}Nodes}{28}{subsection.5.3.1}%
|
||||
\contentsline {subsection}{\numberline {5.3.2}Kombinieren von Nodes zu einer Request}{28}{subsection.5.3.2}%
|
||||
\contentsline {chapter}{\numberline {6}Diskussion}{29}{chapter.6}%
|
||||
\contentsline {section}{\numberline {6.1}Lessons Learned bei der Umsetzung}{29}{section.6.1}%
|
||||
\contentsline {subsection}{\numberline {6.1.1}Erstellung des Robotermodells}{29}{subsection.6.1.1}%
|
||||
\contentsline {subsection}{\numberline {6.1.2}Gazebo}{29}{subsection.6.1.2}%
|
||||
\contentsline {subsubsection}{\nonumberline Upgrade auf Ignition}{29}{subsubsection*.17}%
|
||||
\contentsline {subsubsection}{\nonumberline Pluginarchitektur}{30}{subsubsection*.19}%
|
||||
\contentsline {subsubsection}{\nonumberline Doppelte Messagedienste}{30}{subsubsection*.21}%
|
||||
\contentsline {subsubsection}{\nonumberline Fehlende Animationsgrundlagen}{30}{subsubsection*.23}%
|
||||
\contentsline {subsection}{\numberline {6.1.3}ROS2}{30}{subsection.6.1.3}%
|
||||
\contentsline {subsubsection}{\nonumberline Nachrichten und deren Echtzeitfähigkeit}{30}{subsubsection*.25}%
|
||||
\contentsline {subsubsection}{\nonumberline Änderung der Compilertoolchain}{30}{subsubsection*.27}%
|
||||
\contentsline {subsection}{\numberline {6.1.4}MoveIt2}{31}{subsection.6.1.4}%
|
||||
\contentsline {subsubsection}{\nonumberline Upgrade auf MoveIt2}{31}{subsubsection*.29}%
|
||||
\contentsline {subsubsection}{\nonumberline Fehlerhafte Generierung der Roboter}{31}{subsubsection*.31}%
|
||||
\contentsline {subsubsection}{\nonumberline Controller}{31}{subsubsection*.33}%
|
||||
\contentsline {section}{\numberline {6.2}Lessons Learned bei den Szenarien}{31}{section.6.2}%
|
||||
\contentsline {subsection}{\numberline {6.2.1}Debugging}{31}{subsection.6.2.1}%
|
||||
\contentsline {chapter}{\numberline {7}Zusammenfassung und Ausblick}{32}{chapter.7}%
|
||||
\contentsline {section}{\numberline {7.1}Ergebnisse}{32}{section.7.1}%
|
||||
\contentsline {subsection}{\numberline {7.1.1}Graphische Repräsentation der Szenarien}{32}{subsection.7.1.1}%
|
||||
\contentsline {subsection}{\numberline {7.1.2}Anpassung der Behavior Trees an Szenarien}{32}{subsection.7.1.2}%
|
||||
\contentsline {section}{\numberline {7.2}Diskussion}{32}{section.7.2}%
|
||||
\contentsline {section}{\numberline {7.3}Ausblick}{32}{section.7.3}%
|
||||
\contentsline {subsection}{\numberline {7.3.1}Umsetzung in anderem Simulator}{32}{subsection.7.3.1}%
|
||||
\contentsline {subsection}{\numberline {7.3.2}Simulation bewegter Objekte}{32}{subsection.7.3.2}%
|
||||
\contentsline {subsection}{\numberline {7.3.3}Ergänzung von Umgebungserkennung}{33}{subsection.7.3.3}%
|
||||
\contentsline {subsection}{\numberline {7.3.4}Zusammenbringen von ActorPlugin und ActorServer}{33}{subsection.7.3.4}%
|
||||
\providecommand \tocbasic@end@toc@file {}\tocbasic@end@toc@file
|
||||
@ -8,7 +8,7 @@ Diese Prüfung kann durch eine Simulation, in welcher der konkrete Anwendungsfal
|
||||
|
||||
Außerdem bietet eine Simulation die Möglichkeit, die Aufgabe des Roboters, ohne dessen Anschaffung, evaluieren zu können.
|
||||
Das so gefertigte Modell des Anwendungsfalls könnte später auch als Grundlage für einen digitalen Zwilling dienen.
|
||||
Dieser kann später zur Wartung und Fehlerdiagnose des Systems dienen.
|
||||
Dieser kann später zur Wartung und Fehlerdiagnose des Systems genutzt werden.
|
||||
|
||||
-MRK häufiger ein Thema
|
||||
-Anwendungsfälle sollen evaluiert werden
|
||||
@ -34,19 +34,30 @@ Aktuelle Arbeiten:
|
||||
\url{https://www.researchgate.net/publication/220065749_Human-Robot_Collaboration_a_Survey}
|
||||
|
||||
\section{Welche Szenarien}
|
||||
Die drei Szenarien sollten so gewählt werden, dass vorher genutzte Bestandteile in späteren, komplexeren Szenarien weiter genutzt werden können.
|
||||
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Manipulation von Objekten, besonders in Frage, da diese viele ähnliche Bestandteile haben, jedoch mehrere Szenarien denkbar sind.
|
||||
Die drei zu modellierenden Szenarien sollten so gewählt werden, dass in vorherigen Szenarien genutzte Bestandteile in späteren, komplexeren Szenarien weiter genutzt werden können.
|
||||
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten, besonders in Frage, da diese viele ähnliche Bestandteile haben, jedoch mehrere Szenarien denkbar sind.
|
||||
Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das begutachten eines Objekts, welche alle nur eine Bewegungsabfolge eines Menschen sind.
|
||||
|
||||
Das erste abgebildete Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe handeln, in welcher ein Roboter im Arbeitsbereich eines Menschen Teile fertigt.
|
||||
Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit bei Annäherung des Menschen.
|
||||
Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit bei Annäherung des Menschen, um Kollisionen zu vermeiden.
|
||||
|
||||
Bei dem zweiten Szenario soll der Roboter Teile sortieren und auf ein Fließband legen, falls diese weiter genutzt werden können.
|
||||
Der Mensch muss nun nur noch den Ausschuss beseitigen, welcher vom Roboter in eine besondere Zone gelegt wird.
|
||||
Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide an unterschiedlichen Aufgabe, jedoch im selben Raum, arbeiten.
|
||||
Außerdem werden grundlegende Aspekte der Simulation getestet, wie zum Beispiel das Bewegen von Mensch und Roboter und die sicherheitsrelevante Aktion der Geschwindigkeitsanpassung.
|
||||
|
||||
Im zweiten Szenario prüft und sortiert der Roboter Teile und legt die guten Exemplare auf einem Fließband zur Weiterverarbeitung ab.
|
||||
Die Mängelexemplare werden hingegen in einer besonderen Zone abgelegt, von wo sie vom Menschen abtransportiert werden.
|
||||
|
||||
In diesem Szenario wird das vorhergegangene Szenario um weitere Aspekte ergänzt, was dieses zu einem
|
||||
|
||||
Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in welchem Mensch und Roboter an der selben Aufgabe arbeiten.
|
||||
Hierbei soll eine Palette entladen werden, wobei der Roboter nicht jedes Objekt ausreichend manipulieren kann.
|
||||
Dies resultiert in Problemen beim Aufheben, Transport und Ablegen der Objekte.
|
||||
In diesen Fällen muss nun ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
|
||||
\section{Welcher Nutzen / Contributions}
|
||||
Durch diese Arbeit soll in zukünftigen Projekten die Möglichkeit geschaffen werden, konzeptionelle Probleme bei der Erstellung neuer Aufgabenbereiche eines Roboters frühzeitig durch Simulation erkennbar zu machen.
|
||||
|
||||
Dazu ist eine schnelle Konfiguration von sowohl Roboter als auch Mensch auf unterschiedliche Szenarien nötig, welche durch eine Beschreibungssprache definiert werden sollen.
|
||||
Durch deren einfache Struktur soll komplexes Verhalten einfach und überschaubar definierbar sein, welches dann in der Simulation getestet werden kann.
|
||||
- Erkennen von konzeptionellen Problemen vor Ersteinsatz
|
||||
|
||||
- Definition von Interaktion mit einfacheren Strukturen als State-Machines
|
||||
|
||||
@ -1,14 +1,19 @@
|
||||
\chapter{Konzept}
|
||||
Die zu entwickelnde Simulation soll die bisher meißt separaten Zweige der Roboter- und Menschensimulation verbinden.
|
||||
Um die beiden Akteuren in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
|
||||
Diese Befehle werden dabei von externer Software unter der Verwendung von Behavior Trees und Feedback aus der Simulation generiert.
|
||||
Um die beiden Akteure in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
|
||||
Diese Befehle werden dabei von externer Software unter der Verwendung einer Beschreibungssprache und Feedback aus der Simulation generiert.
|
||||
|
||||
Hierfür wird die Beschreibungssprache in der Dienstumgebung ausgefürht, welche auch die Bewegungsplanung bereitstellt.
|
||||
Die Beschreibungssprache kommunitziert direkt mit dem simulierten Menschen in der Simulation und der Bewegungsplanung.
|
||||
Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen diesen auch Nachrichten ausgetauscht.
|
||||
Der gesamte Vorgang ist dabei in Abbildung \ref{concept_overview} visualisiert.
|
||||
|
||||
Die zu erarbeitende Softwareumgebung soll einfach erweiterbar sein, um weitere Modifikationen und die Umsetzung anderer Projekte zuzulassen.
|
||||
Hierzu zählt die Austauschbarkeit und Erweiterbarkeit von Komponenten wie der simulierten Welt, dem Roboter oder dem simulierten Mensch.
|
||||
Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufgebaut.
|
||||
Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
|
||||
|
||||
\begin{figure}[]
|
||||
\includegraphics[]{img/Konzept_Overview}
|
||||
\begin{figure}
|
||||
\includegraphics{img/MA-Konzept-Übersicht.drawio.pdf}
|
||||
\centering
|
||||
\caption{Visualisierung des Konzepts}
|
||||
\label{concept_overview}
|
||||
@ -18,45 +23,80 @@ Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufgebaut.
|
||||
Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
|
||||
Außerdem ist die enge Interaktion mit Menschen interessant, was einen für Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
|
||||
Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, welcher als Cobot vermarktet wird.
|
||||
Cobot ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für MRK-Szenarien noch einmal unterstreicht.
|
||||
Cobot ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
|
||||
Er besitzt auch einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
|
||||
|
||||
Um den Kuka iisy in der Simulation verwenden zu können, muss ein Modell des Roboterarms erstellt werden.
|
||||
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut wiederspiegeln.
|
||||
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut abbilden.
|
||||
Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
|
||||
|
||||
\section{Simulation des Menschen}
|
||||
Der Mensch soll in der Simulation typische Aufgaben erledigen und häufiges Verhalten abbilden können.
|
||||
Hierzu werden Animationen verwendet, welche die aktuelle Tätigkeit darstellen.
|
||||
Für komplexere Verhaltensweisen können Animationen und andere Aktionen, wie zum Beispiel eine Bewegung und Rotation kombiniert werden, um zum Beispiel die Aktion ``laufen'' auszuführen.
|
||||
Hierzu sollen in der Simulationsumgebung mehrere Animationen verwendet werden, welche die aktuelle Tätigkeit darstellen.
|
||||
Für komplexere Verhaltensweisen können Animationen und andere Aktionen, wie zum Beispiel eine Bewegung und Rotation kombiniert werden, um zum Beispiel die Aktion ``Laufen in eine bestimmte Richtung'' auszuführen.
|
||||
|
||||
Auch hier wird ein Modell der Person für die Simulation benötigt.
|
||||
Außerdem werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.
|
||||
Hinzu kommt noch eine Komponente, welche diese Animationen und andere Parameter von außen entgegennehmen kann, um sie in der Simulation ausführen zu können.
|
||||
Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Aktionen im Fortschritt überwacht und abgebrochen werden können.
|
||||
Um diese Animationen erstellen zu können, wird zuerst ein animierbares Modell benötigt.
|
||||
Dieses Modell soll dabei die Möglichkeit bieten, um weitere Animationen erweitert werden zu können.
|
||||
Es werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.
|
||||
|
||||
\section{Behavior Trees}
|
||||
Häufig wird Verhalten in State-Machines ausgedrückt, welche jedoch einige Nachteile besitzen.
|
||||
Die so erstellten Animationen müssen nun von außerhalb der Simulationsumgebung ausführbar gemacht werden, um diese später mite einer Beschreibungssprache steuern zu können.
|
||||
Hierfür muss eine Komponente entwickelt werden, welche in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
|
||||
Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Anfragen im Fortschritt überwacht und abgebrochen werden können.
|
||||
|
||||
\section{Behavior Trees als Beschreibungssprache}
|
||||
Häufig wird das Verhalten von Akteuren in einer Simulationsumgebung mit State-Machines ausgedrückt, welche jedoch einige Nachteile besitzen.
|
||||
State-Machines werden ab einer gewissen Größe schnell unübersichtlich.
|
||||
Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, welche jedoch essentiell für den Betrieb einer Maschine sind.
|
||||
Um diese Probleme zu adressieren, entstand das Konzept der Behavior Trees.
|
||||
Um diese Probleme zu adressieren, wurde das Konzept der Behavior Trees entwickelt.
|
||||
|
||||
Ein Behavior Tree ist eine Struktur, um Verhalten als ein Baum zu beschreiben.
|
||||
Der Ablauf startet vom sogenannten Root, der Wurzel des Baums.
|
||||
Von dort an werden sogenannte Nodes, welche je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
|
||||
Die Nodes werden untereinander angeordnet, welches die Relation der Nodes zueinander beschreibt.
|
||||
Jede Node hat dabei entweder die Root-Node oder eine andere Node über ihr im Baum und eine beliebige Anzahl an Nodes unter sich.
|
||||
Jede Node hat dabei entweder die Root-Node oder eine andere Node über sich im Baum und eine beliebige Anzahl an Nodes unter sich.
|
||||
Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
|
||||
\begin{description}
|
||||
\item[Aktions-Nodes]
|
||||
beschreiben einzelne ausführbare Aktionen. Mit Hilfe von Parametern kann ihr Verhalten von anderen Nodes beeinflusst werden.
|
||||
beschreiben einzelne ausführbare Aktionen, die das System beeinflussen können.
|
||||
\item[Dekorations-Nodes]
|
||||
können den Rückgabewert einer anderen Node modifizieren. Häufig existieren hier Negation, garantierter Erfolg und garantierter Fehler.
|
||||
können den Rückgabewert einer anderen Node modifizieren.
|
||||
Häufig existieren hier Negation, garantierter Erfolg und garantierter Fehler.
|
||||
\item[Sequenz-Nodes]
|
||||
beschreiben eine nacheinander ausgeführte Abfolge von anderen Nodes, welche mit spezifischen Randbedingungen weiter fortschreitet.
|
||||
\item[Fallback-Nodes]
|
||||
werden verwendet, um Verhalten zu definieren, welches nur bei Fehlern in vorherigen Nodes ausgeführt wird.
|
||||
\end{description}
|
||||
|
||||
In dieser Arbeit sollen BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
|
||||
\begin{figure}[]
|
||||
\includegraphics[]{img/tree_demo}
|
||||
\centering
|
||||
\caption{Beispiel eines BehaviorTrees}
|
||||
\label{concept_tree_demo}
|
||||
\end{figure}
|
||||
|
||||
Das in Abbildung \ref{concept_tree_demo} visualisierte Beispiel zeigt die Abfolge, um eine Tür zu öffnen und zu durchschreiten.
|
||||
Die Ausführung des Baumes beginnt an der Root-Node.
|
||||
Von dort an wird als erstes die Sequenz-Node ausgeführt, welche 3 untergeordnete Nodes besitzt.
|
||||
|
||||
Die linke untergeordnete Node wird als erstes ausgeführt, ist jedoch eine weitere Fallback-Node mit weiteren untergeordneten Nodes.
|
||||
Diese werden auch von links nach rechts ausgeführt, bis die erste Node ein positives Ergebnis zurück gibt.
|
||||
In diesem Fall wird geprüft, ob die Tür bereits offen ist.
|
||||
Da dies nicht der Fall ist, wird die nächste Node ausgeführt, welche die Tür öffnen soll.
|
||||
Dieser Versuch gelingt, weshalb die Ausführung der Fallback-Node beendet wird.
|
||||
|
||||
Dadurch wird die nächste Node in der Sequenz ausgeführt, welche prüft, ob die Tür durchlaufen werden kann.
|
||||
Da dies nicht möglich ist, wird ein Misserfolg gemeldet, welcher die Ausführung der Sequenz abbricht.
|
||||
Diese würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node immer neu startet.
|
||||
|
||||
Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich so einfach neue Verhalten implementieren.
|
||||
Dies erlaubt die schnelle Anpassung des Verhaltens der gesteuerten Systeme.
|
||||
|
||||
In dieser Arbeit sollen deshalb BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
|
||||
Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, welche in dieser Arbeit bearbeitet werden, abzudecken.
|
||||
|
||||
\section{Virtualisierungsumgebung als Platform}
|
||||
Aufgrund von vorheriger Erfahrung mit involvierten Einrichtungsprozessen, ist der Einsatz fest definierter Umgebungen unerlässlich.
|
||||
Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in welcher das zu entwerfende System ausgeführt wird.
|
||||
|
||||
Durch diesen Zwischenschritt können benötigte Programme, Pfade und Umgebungsvariablen in der Virtualisierungsumgebung hinterlegt werden, welche diese bei der Ausführung auf einem anderen Grundsystem korrekt abbilden kann.
|
||||
Dies erhöht die Zuverlässigkeit der Umgebung, da alle Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden können.
|
||||
|
||||
@ -1,24 +1,44 @@
|
||||
\chapter{Komponenten-/Softwareauswahl}
|
||||
Die Auswahl der verwendeten Softwarekomponenten ist ein wichtiger Schritt der Entwicklung, da diese Entscheidungen den späteren Entwicklungsprozess nachträglich beeinflussen.
|
||||
Hierfür werden Komponenten ausgewählt, welche die im Konzept besprochenen Teilbereiche abdecken und miteinander verbunden werden können.
|
||||
|
||||
\section{Dienstumgebung (ROS2)}
|
||||
\subsection{Auswahl}
|
||||
Durch eine Dienstumgebung werden häufig benötigte Funktionen bereitgestellt, welche in Programmen genutzt werden können.
|
||||
Dabei ist es irrelevant, ob diese für simulierte, aber auch echte Hardware, genutzt werden.
|
||||
Die Dienstumgebung bestimmt maßgeblich, wie Software im Entwicklungsprozess geschrieben wird.
|
||||
Durch sie werden häufig benötigte Funktionen bereitgestellt, welche in Programmen in der Umgebung genutzt werden können.
|
||||
|
||||
Bei einer Dienstumgebung für Roboter gehören zu den grundlegendn Aspekten die Nachrichtenübergabe zwischen einzelen interagierenden Programmen, um eine gemeinsame Basis für ein einfach erweiterbares System zu schaffen.
|
||||
|
||||
\subsection{Auswahl}
|
||||
Es existieren mehrere Systeme, welche als Dienstumgebung für Roboter in Frage kommen, wenn es nur um die Nachrichtenübergabe zwischen Programmen geht.
|
||||
Jede Lösung, welche Nachrichten zwischen Prozessen austauschen kann, ist ein potentieller Kanidat für ein Roboterframework.
|
||||
|
||||
Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition der Nachrichten, welche über das System ausgetauscht werden.
|
||||
|
||||
Nutzbare, bereits als IPC integrierte Systeme sind zum Beispiel Pipes, welche Daten zwischen Prozessen über Buffer austauschen.
|
||||
Auch die Nutzung von Message Queues und Shared Memory ist hierfür denkbar.
|
||||
Diese Systeme sind performant, jedoch nicht einfach zu verwalten, da sie von einer direkten Kommunikation von 2 oder mehr Komponenten, welche exakt für diesen Zweck entwickelt wurden, ausgehen.
|
||||
|
||||
Eine Alternative stellen Sockets dar, welche Daten zwischen zwei Programmen austauschen können.
|
||||
|
||||
|
||||
In diesem Bereich sticht ROS als Dienstumgebung für Roboter hervor, da es sich um ein etabliertes, quelloffenes und häufig verwendetes System handelt.
|
||||
Es bietet die oben genannten Aspekte und einige weitere Verbesserungen, welche später näher beleuchtet werden.
|
||||
|
||||
Die neuste Version ROS2 bietet dabei einige Verbesserungen im Vergleich zu früheren Version ROS1.
|
||||
Ein neues Nachrichtenformat mit Quality of Service kann zum Beispiel Nachrichten vorhalten und über sowohl TCP als auch UDP kommunizieren.
|
||||
Außerdem werden nun neben CMake auch andere Buildsysteme unterstützt, unter anderem auch Python.
|
||||
|
||||
Generell existieren im Feld der Roboter-Dienstumgebungen keine Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite, jedoch sind andere Systeme mit anderen Nachrichtenformaten denkbar.
|
||||
Generell existieren im Feld der Roboter-Dienstumgebungen keine Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
|
||||
Vor allem die unzähligen ROS-Bibliotheken, welche von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
|
||||
|
||||
-Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
|
||||
-ROS2
|
||||
-Andere (nur) Messagingsysteme
|
||||
-LCM
|
||||
-ZeroMQ
|
||||
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.
|
||||
|
||||
|
||||
%-Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
|
||||
%-ROS2
|
||||
%-Andere (nur) Messagingsysteme
|
||||
%-LCM
|
||||
%-ZeroMQ
|
||||
\subsection{Beschreibung}
|
||||
ROS2\cite{doi:10.1126/scirobotics.abm6074}, später auch einfach nur ROS genannt, beschreibt sich selbst als ``a meta operating system for robots''\cite{ros-git}.
|
||||
Hierbei ist ``operating system'' nicht in seiner herkömmlichen Bedeutung eines vollständigen Betriebssystems zu verstehen.
|
||||
@ -57,8 +77,8 @@ Zu den Aufgaben von ROS gehören dabei:
|
||||
In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
|
||||
\end{description}
|
||||
|
||||
|
||||
\section{Simulationsumgebung (Gazebo)}
|
||||
|
||||
\subsection{Auswahl}
|
||||
Als Simulationsumgebung können verschiedene Programme genutzt werden, welche sich in ihrem Funktionsumfang stak unterscheiden.
|
||||
Hierfür kommen dedizierte Werkzeuge zur Robotersimulation, aber auch zum Beispiel universell einsetzbare Gameengines in Frage.
|
||||
@ -100,9 +120,31 @@ Aus diesen Funktionen könnte ein Roboterarm aufgebaut werden, welcher dann durc
|
||||
|
||||
Die Wahl der Simulationsumgebung fiel auf Gazebo Ignition, da dieser Simulator bereits im ROS-Framework etabliert ist.
|
||||
Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschidlichsten Szenarien.
|
||||
\subsection{Verwendete Dateiformate}
|
||||
Um die Simulationsumgebung zu beschreiben, nutzt Gazebo das .sdf-Dateiformat\cite{sdf-format}.
|
||||
Dieses Format basiert auf XML und wird zur definition gesamter Welten, aber auch einzelner Objekte benutzt.
|
||||
|
||||
Um verschiedene Versionen des Formats zu unterstützen, enthält das einzige sdf-Element die gewünschte Versionsnummer.
|
||||
In diesem befinden sich entweder ein Modell, Actor oder Licht, oder mindestens eine Welt.
|
||||
|
||||
Eine Welt definiert in Gazebo den kompletten Aubau des Simulators.
|
||||
Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten der Simulationsumgebung.
|
||||
Außerdem werden alle benötigten Teile der Nutzeroberfläche deklariert, welche im ausgeführten Simulator verfügbar sein sollen.
|
||||
Letzendlich können auch mehrere Modelle, Aktoren und Lichter in der Welt definiert werden.
|
||||
Diese können auch aus anderen URIs stammen, welche in der Welt deklariert wurden.
|
||||
Dies erlaubt das Laden von zum Beispiel vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek\cite{gazebo-app}.
|
||||
|
||||
Ein Modell enthält einen Roboter oder ein anderes physikalisches Objekt in der Simulation.
|
||||
Die Deklaration eines weiteren Untermodells ist möglich, um komplexere Strukturen abbilden zu können.
|
||||
Über ein include-Element können auch andere .sdf-Dateien, welche nur ein Modell enthalten, zum Modell hinzugefügt werden.
|
||||
|
||||
Jedes Modell wird über eine Translation und Rotation im Simulationsraum verankert, wobei das Referenzsystem des überliegenden Modells genutzt wird.
|
||||
Außerdem können im Modell Einstellungen für dessen Physiksimulation vorgenommen werden.
|
||||
Für unbewegliche Modelle sollte ein \code{static}-Element auf 1 gesetzt werden, um dieses unbeweglich zu machen.
|
||||
|
||||
|
||||
\subsection{Robotersimulation}
|
||||
Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Siimulationsumgebung beschrieben wird.
|
||||
Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Simulationsumgebung beschrieben wird.
|
||||
Gazebo nutzt hierfür .srdf-Dateien, welche auf xml basieren.
|
||||
In diesen werden die einzelnen Glieder des Arms und die verbindenden Gelenke beschrieben.
|
||||
|
||||
@ -124,11 +166,11 @@ Folgende Typen von Gelenken können in urdf genutzt werden:
|
||||
\item[feste Gelenke]
|
||||
sperren alle 6 Freiheitsgrade und werden häufig zur Plazierung von Objekten in einer Szene genutzt.
|
||||
\item[kontinuierliche Gelenke]
|
||||
erlauben die beliebige Rotation um die Achse des Gelenks. Sie sind nur selten in rotierenden Gelenken mit Schleifkontakten zu finden.
|
||||
erlauben die beliebige Rotation um die Achse des Gelenks. Sie sind nur selten in rotierenden Gelenken mit Schleifkontakten oder anderen frei rotierbaren Übertragungsmechanismen zu finden.
|
||||
\item[drehbare Gelenke]
|
||||
verhalten sich wie kontinuerliche Verbindungen, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
|
||||
verhalten sich wie kontinuerliche Gelenke, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
|
||||
\item[prismatische Gelenke]
|
||||
ermöglichen die Bewegung entlang der Achse des Gelenks. Denkbare Anwendungsfälle sind simulierte lineare Aktuatoren.
|
||||
ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Denkbare Anwendungsfälle sind simulierte lineare Aktuatoren.
|
||||
\end{description}
|
||||
\subsection{Menschensimulation}
|
||||
Gazebo besitzt bereits ein einfaches Animationssystem für bewegliche Aktoren, welches auch für Menschen nutzbar ist.
|
||||
@ -137,12 +179,14 @@ Dadurch ist eine Laufanimation realisierbar, welche synchronisiert zur Bewegung
|
||||
|
||||
Jedoch ist dies nur unter der Bedingung möglich, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
|
||||
Dies ist auf die Definition der Pfade, welche die Bewegung auslösen, zurückzuführen.
|
||||
Diese können nur in der .sdf-Datei des Aktoren definiert werden, was Veränderungen zur Laufzeit ausschließt.
|
||||
Diese können nur als dem Actor untergeordnetes Element in der .sdf-Datei definiert werden, was Veränderungen zur Laufzeit ausschließt.
|
||||
Durch diesen Umstand ist der mögliche Simulationsumfang nicht ausreichend.
|
||||
|
||||
Um diesen Umstand zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
|
||||
Um dieses Problem zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
|
||||
Dieses System muss, wie im Konzept beschrieben, Steuerbefehle von außen empfangen, umsetzen und Feedback liefern können.
|
||||
|
||||
Ein solches System sollte als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, welche konstant weiter entwickelt wird.
|
||||
Dies erlaubt die einfachere Wartung, da bei Updates der Simulationsumgebung nicht die Menschensimulation an den neuen Code angepasst werden muss.
|
||||
\section{Roboterumgebung (MoveIt2)}
|
||||
MoveIt 2 ist das empfohlene ROS2 Paket für Bewegungsplanung von Robotern.
|
||||
Das System besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
|
||||
@ -153,19 +197,140 @@ Dort können Bewegungen durch das Bewegen von Markierungen oder in der Simulati
|
||||
|
||||
Da sich ein solches System nur beschränkt zur Automatisierung durch Software eignet, existieren auch noch andere Schnitstellen.
|
||||
Für die Sprache Python existierte früher noch das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, welches aber aktuell noch nicht portiert wurde. \cite{moveitpython}
|
||||
Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt auf einer abstrakteren Ebene zu interagieren.
|
||||
Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, was jedoch Erfahrung mit den verwendeten Datenstrukturen benötigt.
|
||||
|
||||
Durch diese Schnittstelle erhält die sogenannte MoveGroup ihre Informationen über die gewünschte Bewegung.
|
||||
Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt auf einer abstrakteren Ebene zu interagieren.
|
||||
Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden um einzelne Bereiche des Systems zu testen, jedoch ist so kein einfacher Zugriff auf erweiterte Optionen möglich.
|
||||
|
||||
Aus einem Robotermodell können nun die Informationen, welche von MoveIt über den zu kontrollierenden Roboter benötigt werden, generiert werden.
|
||||
Diese werden über einen RobotStatePublisher an MoveIt übergeben, welches daraus das Robotermodell für die Bewegungsplanung generiert.
|
||||
|
||||
Durch die vorher erwähne C++-API erhält die MoveGroup die Informationen über die gewünschte Bewegung.
|
||||
Dabei können auch bestimmte Einschränkungen des Arbeitsraums, spezielle Trajektorien, oder Limitierungen der Gelenke in der Planung berücksichtigt werden.
|
||||
|
||||
Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, welche sich um den Roboter befinden.
|
||||
Eine solche Erweiterung erlaubt die Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
|
||||
|
||||
Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, welcher durch die MoveGroup aufgerufen wird.
|
||||
Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an ros_control weitergegeben.
|
||||
Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an \code{ros_control} weitergegeben.
|
||||
Dabei können sowohl echte Hardwaretreiber, aber auch simulierte Roboter genutzt werden.
|
||||
Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
|
||||
|
||||
Im Falle von Gazebo wird ign_ros_control genutzt, welches die benötigten ros_control Controller in die Simulation einbindet.
|
||||
Diese können dann wie normale Controller von ros_control genutzt werden.
|
||||
Im Falle von Gazebo wird \code{ign_ros_control} genutzt, welches die benötigten \code{ros_control} Controller in die Simulation einbindet.
|
||||
Diese können dann wie normale Controller von \code{ros_control} genutzt werden.
|
||||
|
||||
Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
|
||||
|
||||
\section{Behavior Trees}
|
||||
Zur Verwaltung der Abläufe sollen BehaviorTrees genutzt werden, welche durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
|
||||
Diese Bibliothek wurde in C++ geschrieben, und ist somit einfach in ROS integrierbar.
|
||||
|
||||
Es existieren aber auch viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen, welche im folgenden vorgestellt werden.
|
||||
|
||||
\begin{description}
|
||||
\item[Asynchrone Nodes]
|
||||
sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese im Lebenszyklus der Nodes beim Konzept der Bibliothek mit bedacht wurden.
|
||||
Dies resultiert in Nodes, welche ohne spezielle Logik langanhaltende Aktionen ausführen können, ohne die Ausführung des BehaviorTrees zu behindern.
|
||||
\item[Reaktives Verhalten] ist ein neues Konzept, um die Handhabung von asnchronen Nodes zu vereinfachen.
|
||||
Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, welche aktuell ausführende Aktionen beeinflussen können.
|
||||
\item[Das .xml-Format] ermöglicht einen einfachen Austausch des Verhaltens, ohne die unterliegende Programmierung verändern zu müssen.
|
||||
Dies ist vor allem in kompillierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompillierung bedürfen, was die Iterationszeit für Änderungen verbessert.
|
||||
\item[Plugins] können zum Start geladen werden, um weitere Nodes dem ausgeführten Programm hinzufügen zu können.
|
||||
Dies vereinfacht die Erweiterung um neue Funktionen und das mehrfachen Nutzen von Code.
|
||||
\item[Datenfluss] zwischen den Nodes erlaubt es, von außen konfigurierbares Verhalten der Nodes zu erreichen.
|
||||
Diese können dabei sowohl statisch, als auch dynamisch über sogenannte Ports mit Informationen versorgt werden.
|
||||
\item[Integriertes Logging] erlaubt es, Zustandsänderungen im Behavior Tree zu visualisieren, aufzunehmen und wieder abzuspielen.
|
||||
Dies erleichtert das häufig schwierige Debuggen von Zustandsmaschienen erheblich, da das Verhalten genau untersucht werden kann.
|
||||
\end{description}
|
||||
|
||||
BehaviorTrees werden in \code{BehaviorTree.CPP} als .xml-Dateien gespeichert.
|
||||
Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeports.
|
||||
|
||||
Solche Ports können verwendet werden, um Nodes generischer gestalten zu können.
|
||||
So kann auf feste Parameter in den Nodes selber verzichtet werden, was das erstellen mehrerer Nodes für ähnliche Funktionalitäten verhindert.
|
||||
Diese Daten können sowohl aus einem String ausgelesen werden, falls die ensprechende Funktion, welche diese in den Zieltyp übersetzt, implementiert wurde.
|
||||
Aber sie können auch aus dem sogenannten Blackboard entnommen werden.
|
||||
|
||||
Das Blackboard ist ein System, welches die Nutzung von Variablen als Parameter für Ein- und Ausgänge erlaubt.
|
||||
Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeichert.
|
||||
Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des BehaviorTrees.
|
||||
Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, welche zu komplexeren Strukturen zusammengesetzt werden können.
|
||||
|
||||
Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Nodes als sogenannte SubTrees abspeichern.
|
||||
Diese bilden dann in ihrer Gesamtheit eine neue Node, welche im BehaviorTree eingesetzt werden kann.
|
||||
Um den Einsatz von Variablen innerhalb eines SubTrees zu ermöglichen, besitzt jeder SubTree ein separates Blackboard.
|
||||
Dadurch kann ein Eingriff in äußere Funktionalität verhindert werden.
|
||||
|
||||
Natürlich sollte es auch möglich sein, Variablen an solche SubTrees zu übergeben.
|
||||
Diese können, wie auch bei normalen Nodes, einfach als Parameter an den SubTree übergeben werden.
|
||||
Die Bibliothek \code{BehaviorTree.CPP} verbindet dann diese Werte und erlaubt die Datenübergabe zu und von dem SubTree.
|
||||
|
||||
\subsection{Asynchrone Nodes}
|
||||
Da nicht jeder Prozess in einem einzigen Durchlauf des BehaviorTrees abgebildet werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
|
||||
Dies geschieht in in \code{behaviortree_cpp_v3} durch asynchrone Nodes.
|
||||
|
||||
Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE auch noch die beiden anderen Zustände RUNNING und IDLE.
|
||||
|
||||
Der Zustand RUNNING steht dabei für eine Node, welche sich noch in der Ausführung befindet.
|
||||
So lang dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand abgefragt.
|
||||
|
||||
Der IDLE-Zustand ist ein besonderer Zustand, welcher nur durch eine vollständige Ausführung erreichbar ist.
|
||||
Er wird von der Node angenommen, nachdem ein RUNNING Zustand durch entweder SUCCESS oder FAILURE beendet wurde und darf sonst nicht verwendet werden.
|
||||
|
||||
\subsection{Dateiformat}
|
||||
Das verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
|
||||
Jedes Dokument beginnt dabei mit einem Root-Element, welches alle BehaviorTrees und eine Referenz auf die ID des Hauptbaumes enthält.
|
||||
Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genuzt werden können, diese aber sonst nicht vom Hauptbaum unterscheidbar sind.
|
||||
|
||||
Jeder Baum beginnt mit einem BehaviorTree-Element, welches als Attribut die ID des Baumes besitzen muss.
|
||||
Als untergeornete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
|
||||
|
||||
Zur besseren Visualisierung der XML-Struktur wurde hier die bereits aus dem Konzept bekannte Baumstruktur, hier noch einmal unter Abbildung \ref{choice_tree_demo} zu sehen, in XML umgewandelt.
|
||||
Dabei ist zu beachten, dass die Root-Node nicht in der Struktur existiert.
|
||||
Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber auch über den Namen Action mit ihrem Namen als ID-Parameter, referenziert werden.
|
||||
\begin{figure}[hpt]
|
||||
\includegraphics[width=\textwidth]{img/tree_demo}
|
||||
\centering
|
||||
\caption{Beispiel eines BehaviorTrees}
|
||||
\label{choice_tree_demo}
|
||||
\end{figure}
|
||||
\begin{figure}[hpt]
|
||||
\begin{lstlisting}[]
|
||||
<?xml version="1.0"?>
|
||||
<root main_tree_to_execute="demoTree">
|
||||
<BehaviorTree ID="actorTree">
|
||||
<Sequence>
|
||||
<Fallback>
|
||||
<Action ID="IsDoorOpen"\>
|
||||
<Action ID="OpenDoor"\>
|
||||
<Action ID="BreakDoor"\>
|
||||
</Fallback>
|
||||
<CanWalkThrough\>
|
||||
<WalkThrough\>
|
||||
</Sequence>
|
||||
</BehaviorTree>
|
||||
</root>
|
||||
\end{lstlisting}
|
||||
\caption{Beispiel eines BehaviorTrees als .xml}
|
||||
\label{choice_tree_xml}
|
||||
\end{figure}
|
||||
|
||||
\section{Docker-Compose als Virtualisierungsumgebung}
|
||||
Docker ist eine Virtualisierungsumgebung für Anwendungen, welche die komplette Umgebung für deren Ausführung bereitstellen.
|
||||
Dadurch wird die Inbetriebnahme von Anwendungen, welche spezielle Umgebungen für ihre Ausführung benötigen, ermöglicht.
|
||||
|
||||
Dies wird durch den Einsatz von sogenannten Containern erreicht, welche durch Buildfiles definiert werden.
|
||||
Ein Buildfile enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.
|
||||
Die so erstellten Container können entweder lokal oder auf einem Server für die Verwendung bereitgehalten werden.
|
||||
|
||||
Ein solcher Container enthält ein eigenes Dateisystem, welches aus dem im Buildfile definierten Dateien und einem Overlay besteht.
|
||||
In diesem Overlay werden Änderungen gespeichert, welche am Container während der Laufzeit vorgenommen werden.
|
||||
Sofern nicht definiert, werden diese Änderungen beim Neustart des Containers wieder entfernt.
|
||||
|
||||
Um dies zu vermeiden, kann entweder ein Volume, eine Art virtuelles Laufwerk im \code{/var/lib/docker} Verzeichnis, oder ein ``bind mount'' in der compose.yml-Datei eingerichtet werden.
|
||||
Ein ``bind mount'' ist eine direkte Verbindung zu einem Ort des Host-Dateisystems, welche in den Container hereingereicht wird.
|
||||
|
||||
Docker-Compose stellt eine Erweiterung von Docker dar, welche die Inbetriebnahme der Container über ein spezielles Dateiformat verwaltet.
|
||||
In dieser Datei werden weitere Optionen angegeben, welche in die Umgebung des laufenden Containers eingreifen.
|
||||
Dazu gehört zum Beispiel das automatisierte Übergeben von Umgebungsvariablen, Einrichten von Netzwekumgebungen und Erstellen von Volumes und ``bind mounts''.
|
||||
|
||||
Diese Automatisierung erleichtert die initiale Einrichtung eines Containers auf einem neuen System, da alle benötigten Aspekte leicht angepasst werden können.
|
||||
|
||||
@ -1,20 +1,89 @@
|
||||
\chapter{Umsetzung}
|
||||
|
||||
\section{Grundlegender Systemaufbau}
|
||||
Der grundlegende Systemaufbau musste stark modifiziert werden, wie in Abbildung \ref{umsetzung_overview} zu sehen, um die gesetzten Aufgaben erfüllen zu können.
|
||||
Dabei fallen vor allem die überarbeitete Kommunikation mit dem simulierten Menschen und die komplexere Steuerung des Roboterarms auf.
|
||||
Bei der Umsetzung des geplanten Systemaufbaus kam es zu mehreren Problemen, welche den geplanten Systemaufbau, sowie dessen Komplexität, negativ beeinflussen.
|
||||
|
||||
Die komplexere Steuerung des Roboters ist auf die Struktur von MoveIt zurückzuführen, welches in viele einzelne Teilmodule aufgeteilt ist.
|
||||
Diese müssen durch ihren modularen Aufbau, welcher für die Vielseitigkeit verantwortlich ist, einzeln konfiguriert werden, um miteinander in Interaktion treten zu können.
|
||||
Die Kommunikation zwischen dem Actormodell und dem Behavior Tree musste in mehrere Komponenten aufgeteilt werden, um Konflikte innerhalb der Simulationssoftware zu vermeiden.
|
||||
|
||||
Außerdem musste die Kommunikation des Modells des Menschen überarbeitet werden, da die ROS-Kommunikation in Gazebo nur mit Einschränkungen möglich ist.
|
||||
Zudem ist die Bewegungsplanung mit MoveIt2 deutlich komplexer als vorerst angenommen.
|
||||
Diese Komplexität entsteht aus der Interaktion mehrerer Komponenten, welche das Gesamtsystem zur Ausführung benötigt.
|
||||
Alle Einzelsysteme mussten hierfür konfiguriert werden, um die Kommunikation dieser zu ermöglichen.
|
||||
|
||||
\begin{figure}[]
|
||||
\includegraphics[width=\textwidth]{img/Umsetzung_Overview}
|
||||
Anhand der hier genannten Änderungen wurde die Übersicht des Systems angepasst, welche in Abbildung \ref{umsetzung_overview} zu sehen ist.
|
||||
|
||||
\begin{figure}[h]
|
||||
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Übersicht.drawio}
|
||||
\centering
|
||||
\caption{Visualisierung des überarbeiteten Konzepts}
|
||||
\label{umsetzung_overview}
|
||||
\end{figure}
|
||||
|
||||
\section{Verwendete Datentypen}
|
||||
In der Implementation werden unterschiedliche Datentypen verwendet.
|
||||
\begin{description}
|
||||
\item[geometry_msgs::msg::Pose]
|
||||
ist einer der häufigsten Datentypen im Umgang mit Gazebo. Dieser Datentyp enthält die Information über die Lage und Rotation eines Objekts im Raum.
|
||||
Diese werden als relative Werte im Bezug auf das übergeornete Objekt gespeichert.
|
||||
Objekte wie der Mensch liegen in der Hierarchie der Simulation direkt unter der Welt, welche sich direkt im Nullpunkt und ohne Rotation befindet.
|
||||
Dadurch sind zum Beispiel die Koordinaten des Menschen absolut, da diese nicht durch die Welt verschoben und rotiert werden.
|
||||
\item[Area]
|
||||
ist eine Datenstruktur mit einem Vektor an Positionen, welche eine Zone im Zweidimensionalen Raum definieren.
|
||||
Jede Position ist eine einfache Datenstruktur aus 2 Gleitkommazahlen für je die X- und Y-Koordinate der Position.
|
||||
Der Verwendungszweck dieser Struktur ist die einfache Definition von Zonen, welche für Positionsgenerierungen und Postionsabfragen genutzt werden können.
|
||||
\item[ActorPluginState]
|
||||
definiert 4 Werte, welche das ActorPlugin annehmen kann. Diese 4 Werte sind SETUP, IDLE, MOVEMENT und ANIMATION.
|
||||
\item[FeedbackMessage]
|
||||
beschreibt die erste der beiden MessageQueue-Nachrichten, welche vom ActorPlugin an den ActorServer gesendet wird.
|
||||
In dieser Struktur befindet sich der aktuelle Plugin-Zustand als \code{state} Parameter vom Typ ActorPluginState.
|
||||
Außerdem ein \code{progress} Parameter in Form einer Gleitkommazahl, welche den Fortschritt der aktuellen Aktion angibt.
|
||||
Um bei Bewegungen die aktuelle Position des Menschen zu erhalten, ist auch die aktuelle Pose des Modells im Parameter \code{current} enthalten.
|
||||
\item[ActionMessage]
|
||||
ist die andere Nachricht, welche über die zweite MessageQueue vom ActorServer an das ActorPlugin gesendet wird.
|
||||
Wie in der FeedbackMessage ist ein \code{state} Parameter vom selben Typ enthalten, jedoch dient dieser hier als Vorgabe für den nächsten State.
|
||||
Ein \code{animationName} Parameter wird als ein char-Array mit einer maximalen Länge von 255 Zeichen übergeben.
|
||||
Dieser bestimmt später die Animation, welche je nach ActorPluginState während einer Bewegung oder Animation ausgeführt wird.
|
||||
Der \code{animationSpeed} Parameter beschreibt entweder die Abspielgeschwindigkeit der Animation, oder die Distanz, welche pro Animationsdurchlauf zurückgelegt wird.
|
||||
Außerdem wird im Falle einer Bewegung der Parameter \code{target} vom Typ Pose verwendet, um die Endposition und Rotation des Actors zu bestimmen.
|
||||
\end{description}
|
||||
\section{Welt}
|
||||
Die Welt der Simulation wird im Paket \code{ign_world} zur Verfügung gestellt.
|
||||
In diesem Paket sind sowohl die Geometrien der Welt, aber auch die benötigten Dateien zum Starten der Simulation enthalten.
|
||||
|
||||
In diesem Fall handelt es sich um den Raum, in welchem die Interaktion zwischen Mensch und Roboter stattfinden soll.
|
||||
Für diesen Raum wurde zuerst ein Raumplan erstellt, welcher alle benötigten Bereiche für die Szenarien besitzt (Abbildung \ref{room-plan}).
|
||||
|
||||
Zuerst wird ein Stellplatz für den Roboter benötigt, welcher an einer Ecke des Raumes positioniert werden sollte.
|
||||
Diese Position wurde gewählt, um die Verfahrgeschwindigkeit des Roboters höher zu halten, welche je nach Distanz zum Menschen angepasst werden soll.
|
||||
|
||||
Des weiteren werden eine Arbeits- und Lagersätte für den Menschen benötigt, welche in den Szenarien genutzt werden sollen.
|
||||
Im Koexistenzszenario soll der Mensch nur an diesen Stellen seine Arbeit verrichten, jedoch sich selten dem Roboter nähern, um dessen Fortschritt zu begutachten.
|
||||
Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch für die fehlerhaften Teile verwendet werden, welche durch den Roboter aussortiert und durch den Menschen dorthin verbracht werden sollen.
|
||||
Eine Nutzung im Kollaborationsszenario ist nicht nicht geplant, da der Mensch den Roboter überwachen und dessen Fehler korrigieren soll.
|
||||
|
||||
Der so geplante Raum wurde in Blender modelliert und als .stl-Datei exportiert, um sie in die Welt einbinden zu können.
|
||||
Für das Kooperationsszenario wurde ein weiterer Raum mit Förderband erstellt, welcher nur dort genutzt wird.
|
||||
Der so erstellte Raum wird nun in einer separaten .sdf-Datei referenziert, welche
|
||||
|
||||
Diese Entscheidung limitiert wie der Raum in die Simulation eingebunden wird, da mehrere unterschiedliche Räume je nach ausgewähltem Szenario geladen werden müssen.
|
||||
Hierfür wird, wie später auch für den Roboter selbst, das Paket \code{ros_gz_sim} verwendet.
|
||||
Dieses veranlasst mit dem \code{create}-Programm das Erstellen der übergebenen Datenstruktur in Gazebo.
|
||||
|
||||
|
||||
\begin{figure}[hpt]
|
||||
\begin{minipage}{.45\textwidth}
|
||||
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Welt-Plan.drawio}
|
||||
\centering
|
||||
\caption{Geplanter Raum}
|
||||
\label{roomplan}
|
||||
\end{minipage}
|
||||
\hspace{.1\textwidth}
|
||||
\begin{minipage}{.45\textwidth}
|
||||
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Welt-Blender}
|
||||
\centering
|
||||
\caption{Umsetzung in Blender}
|
||||
\label{roomfinished}
|
||||
\end{minipage}
|
||||
\end{figure}
|
||||
|
||||
\section{Mensch}
|
||||
\subsection{Übersicht}
|
||||
Das angepasste Verfahren zur Menschensteuerung in der Simulation verwendet mehrere Kommunikationswege.
|
||||
@ -107,7 +176,23 @@ Die neuere Implementation der POSIX MessageQueue bietet einige weitere Funktione
|
||||
Die ausgewählte Implementation ist die neuere POSIX-Implementation einer Message Queue, da diese basierend auf den Erfahrungen mit der System V Implementation verbessert wurde.
|
||||
\subsubsection{Nachrichten}
|
||||
Die versendeten Nachrichten für den ActionServer, als auch für die Message Queue sind in den Paketen \code{ros_actor_action_server_msgs} und \code{ros_actor_message_queue_msgs} abgelegt.
|
||||
Die beiden ActionServer definieren jeweils 3 Nachrichten, welche eine Startnachricht, das Feedback während der Laufzeit und eine Endnachricht beschreiben.
|
||||
Sie sind absichtlich nicht in den nutzenden Paketen untergebracht, da sie durch ein externes Programm in den entsprechenden Code umgewandelt werden.
|
||||
|
||||
Jede Action definiert 3 Nachrichten, welche zu unterschiedlichen Zeitpunkten in ihrer Ausführung verwendet werden.
|
||||
Die definierten Nachrichten sind eine Startnachricht, eine Feedbacknachricht und eine Endnachricht.
|
||||
|
||||
Ein ActionServer definiert 3 Funktionen, welche die Handhabung einer Aktion definieren.
|
||||
Die erste Funktion übergibt den Wert der Startnachricht, welche mit einer Antwort quittiert werden muss.
|
||||
Hierbei sind die Antworten ACCEPT_AND_DEFER, ACCEPT_AND_EXECUTE und REJECT möglich.
|
||||
|
||||
ACCEPT_AND_EXECUTE signalisiert die sofortige Ausführung des gewünschten Befehls und ACCEPT_AND_DEFER steht für eine spätere Ausführung der gewünschten Aktion.
|
||||
Die Option REJECT bricht die Ausführung der Aktion vorzeitig ab.
|
||||
|
||||
Die zweite Funktion übergibt Abbruchanfragen an den Server, falls die Aktion durch den Client abgebrochen werden soll.
|
||||
Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT zurückgewiesen werden.
|
||||
|
||||
Um Feedback während der Ausführung der Aktion geben zu können, exisitiert die dritte Funktion.
|
||||
Diese erhält als Parameter ein Objekt, mit welchem Feedback- und Endnachrichten an den Client gesendet werden können.
|
||||
|
||||
In der Startnachricht werden alle Daten, welche der Server für die Bearbeitung einer Anfrage benötigt, übergeben.
|
||||
Dies geschieht, damit der Auftrag schon beim Start abgebrochen werden kann, sollte dieser nicht erfüllbar sein.
|
||||
@ -117,24 +202,12 @@ Dabei ist es Aufgabe des Programms, diese in beliebigen Abständen an den Client
|
||||
|
||||
Die Endnachricht kann Rückgabewerte für die ausgeführte Aufgabe enthalten, falls diese benötigt werden.
|
||||
Sie werden in diesem Projekt nicht genutzt, da das Beenden eines Auftrags immer mit einer einfachen Erfolgs- oder Misserfolgsmeldung quittiert wird.
|
||||
\subsubsection{ActorServer}
|
||||
Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin.
|
||||
Es werden zwei ActionServer angeboten, welche jeweils Bewegungen oder Animationen des simulierten Menschen auslösen können.
|
||||
Beide ActionServer prüfen zuerst, ob bereits eine andere Aktion ausgeführt wird.
|
||||
Sollte dies der Fall sein, wird die Anfrage abgelehnt.
|
||||
Im anderen Fall wird die Aufgabe akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
|
||||
Hier kommt es zu einer forcierten Warteschleife, welche die Bestätigung der Aktion vom ActorPlugin in der Feedback-Queue wartet, um das Starten mehrerer gleichzeitiger Aktionen zu unterbinden.
|
||||
Parallel werden alle eingehenden Feedback-Nachrichten der Message Queue des ActorPlugins in Feedback für die aktuell laufende Action umgewandelt.
|
||||
|
||||
Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
|
||||
Zuerst werden Animationsname und -diztanz benötigt, um die richtige Animation auszuwählen und die Bewegung mit der Animation zu synchronisieren.
|
||||
Als Feedbacknachricht erhält der Client die aktuelle Pose des Actors im Simulationsraum.
|
||||
\subsubsection{ActorPlugin}
|
||||
Das ActorPlugin nutzt die empfangenen Nachrichten aus der eingehenden Message Queue, um diese in der Simulation umzusetzen.
|
||||
Der Code des Plugins ist dabei im Paket \code{ign_actor_plugin} organisiert, welches im Gazebo-Modell der Welt referenziert werden muss, um das Plugin zu laden.
|
||||
|
||||
Soll eine Animation über den Action Server abgespielt werden, wird auch hier ein Animationsname, jedoch auch eine Animationsgeschwindigkeit benötigt.
|
||||
Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl.
|
||||
\subsubsection{Gazebo Plugin}
|
||||
Das ActorPlugin nutzt die Daten aus der Message Queue für Befehle, um diese in der Simulation umzusetzen.
|
||||
Es werden dabei mehrere Zustände unterschieden.
|
||||
Das Plugin erhält durch die empfangenen Nachrichten mehrere Zustände, welche im folgenden erläutert werden:
|
||||
\begin{description}
|
||||
\item[Setup]
|
||||
wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simualtionumgebung im Plugin zu hinerlegen, so dass diese in den anderen Zuständen genutzt werden können.
|
||||
@ -151,21 +224,59 @@ Es werden dabei mehrere Zustände unterschieden.
|
||||
ist der Zustand, welcher nach erfolgreicher Ausführung eines Befehls angenommen wird.
|
||||
\end{description}
|
||||
|
||||
Das ActorPlugin besitzt kein Konzept des ActionServers und verlässt sich auf den ActorServer, welcher die Feedbacknachrichten in das richtige Format bringt.
|
||||
Feedback wird in den Zuständen Movement und Animation in jedem Simulationsschritt gesendet.
|
||||
Um auch Zustandsübergänge erkennen zu können, werden auch diese als Feedback an den ActorServer gesendet.
|
||||
Das ActorPlugin besitzt kein Konzept eines ROS-ActionServers und verlässt sich auf den ActorServer, welcher die Feedbacknachrichten in das richtige Format bringt.
|
||||
Feedback wird in den Zuständen Movement und Animation in eine zweiten Message Queue zu jedem Simulationsschritt gesendet.
|
||||
Um Zustandsübergänge erkennen zu können, werden auch diese als Feedback an den ActorServer gesendet.
|
||||
\subsubsection{ActorServer}
|
||||
Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin und ist im Paket \code{ros_actor_action_server} enthalten.
|
||||
Dieser weitere Dienst bindet das ActorPlugin an ROS an.
|
||||
|
||||
Es werden dafür zwei ROS-ActionServer gestartet, welche jeweils Bewegungen oder Animationen des simulierten Menschen auslösen können.
|
||||
Beide ActionServer prüfen bei dem Empfang eines neuen Ziels zuerst, ob bereits eine andere Aktion ausgeführt wird.
|
||||
Sollte bereits eine andere Aktion ausgeführt werden, wird die Anfrage abgelehnt.
|
||||
Im anderen Fall wird die Aufgabe akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
|
||||
|
||||
Um das Starten mehrerer gleichzeitiger Aktionen zu unterbinden, muss der Empfang einer neuen Anfrage bestätigt werden, bevor weitere Befehle über den ROS-ActionServer entgegen genommen werden können.
|
||||
Hierzu wird ein Mutex verwendet, welcher die Auswertung neuer Nachrichten verhindert, so lange der aktuelle Befehl noch nicht durch das Plugin bestätigt wurde.
|
||||
Parallel werden alle eingehenden Feedback-Nachrichten der Message Queue des ActorPlugins in Feedback für die aktuell laufende Action umgewandelt.
|
||||
|
||||
Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
|
||||
Zuerst werden Animationsname und -diztanz benötigt, um die richtige Animation auszuwählen und die Bewegung mit der Animation zu synchronisieren.
|
||||
Als Feedbacknachricht erhält der Client die aktuelle Pose des Actors im Simulationsraum.
|
||||
|
||||
Soll eine Animation über den Action Server abgespielt werden, wird auch hier ein Animationsname, jedoch auch eine Animationsgeschwindigkeit benötigt.
|
||||
Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl.
|
||||
\section{Roboter}
|
||||
\subsection{Übersicht}
|
||||
Der Roboter besteht aus vielen interagierenden Systemen, welche in ihrer Gesamtheit das vollständige Robotermodell in der Simulation verwendbar machen.
|
||||
|
||||
Zuerst muss ein Modell des Roboters erstellt werden, welches in Gazebo geladen werden kann.
|
||||
Dieses Modell muss dann für die Bewegungsplanung mit MoveIt erweitert werden.
|
||||
Hierbei werden Controller von ros_control mit dem Modell verbunden, um den aktuellen Zustand der Achsen zu überwachen und diese steuern zu können.
|
||||
|
||||
Um diese Vielfalt an Daten standartisiert an andere Software in ROS weitergeben zu können, wird eine MoveGroup in ROS gestartet, welche die Planung von Bewegungen durch andere Programme zulässt.
|
||||
\subsection{Modellierung}
|
||||
Für den Kuka LBR iisy existiert kein Simulationsmodell für Gazebo und ROS, weswegen dieses Modell aus Herstellerdaten generiert wurden.
|
||||
Die Maße und Form des Roboters wurden aus einer .stl-Datei des Arms generiert.
|
||||
Hierzu stand eine .stl-Datei des Herstellers zur Verfügung.
|
||||
Aus dieser Datei wurden mit FreeCAD\cite{freecad} alle Glieder des Roboters als Collada-Dateien exportiert.
|
||||
Dabei muss darauf geachtet werden, dass die exportierten Daten eine ausreichende Meshgröße haben, welche vorher in FreeCAD eingestellt werden muss.
|
||||
Dies erlaubt das Erhalten der feinen Strukturen des Arms, auch visualisiert in Abbildung \ref{robot_raw}, welche erst später in Blender reduziert werden sollen.
|
||||
|
||||
Diese Datei wurde dazu in die unterschidlichen Glieder aufgeteilt, welche danach in Blender weiter bearbeitet wurden.
|
||||
Hiebei wurde die hohe Auflösung der Modelle reduziert, was sich in kleineren Dateien und Startzeiten der Simulation, aber auch in der Renderzeit der Simulation, auswirkt.
|
||||
\begin{figure}[]
|
||||
\includegraphics[width=\textwidth/2]{img/MA-Roboter-Rohdaten}
|
||||
\centering
|
||||
\caption{Rohdaten aus .stl-Datei}
|
||||
\label{robot_raw}
|
||||
\end{figure}
|
||||
|
||||
Diese Dateien können dann in Blender bearbeitet werden, um sie für die Simulation tauglich zu machen.
|
||||
Hierfür wurde die hohe Auflösung der Modelle reduziert, was sich in kleineren Dateien und Startzeiten der Simulation, aber auch in der Renderzeit der Simulation, auswirkt.
|
||||
Außerdem wuden die Glieder so ausgerichtet, dass der Verbindungspunkt zum vorherigen Glied im Nullpunkt des Koordinatensystems befindet.
|
||||
Das vollständige visuelle Modell ist in Abbildung \ref{robot_visual} zu sehen.
|
||||
|
||||
Um die Simulation weiter zu beschleunigen, wurden die Kollisionsboxen des Arms noch weiter vereinfacht, was die Kollisionsüberprüfung dramatisch beschleunigt.
|
||||
Dabei werden stark simplifizierte Formen verwendet, welche das hochqualitative visuelle Modell mit einfachen Formen umfassen.
|
||||
Das resultierende Modell, welches in Abbildung \ref{robot_collision} dargestellt wird, wird später zur Kollisionserkennung verwendet.
|
||||
|
||||
Diese Herangehensweise ist nötig, da Kollisionserkennung auf der CPU durchgeführt wird, welche durch komplexe Formen stark verlangsamt wird.
|
||||
|
||||
@ -177,49 +288,149 @@ Die Gelenkpositionen sind dabei relative Angaben, welche sich auf das Glied bezi
|
||||
Alle kontrollierbaren Gelenke benötigen auch eine Gelenkachse, welche je nach Gelenktyp die mögliche Beweglichkeit bestimmt.
|
||||
|
||||
Alle hier erstellten Dateien wurden im Paket \code{iisy_config} zusammengefasst, um diese einfacher wiederauffinden zu können.
|
||||
\begin{figure}[hpt]
|
||||
\begin{minipage}{.5\textwidth}
|
||||
\includegraphics[width=\textwidth]{img/MA-Roboter-Visuell}
|
||||
\centering
|
||||
\caption{Visuelles Modell}
|
||||
\label{robot_visual}
|
||||
\end{minipage}
|
||||
\begin{minipage}{.5\textwidth}
|
||||
\includegraphics[width=\textwidth]{img/MA-Roboter-Kollision}
|
||||
\centering
|
||||
\caption{Kollisionsmodell}
|
||||
\label{robot_collision}
|
||||
\end{minipage}
|
||||
\end{figure}
|
||||
\subsection{MoveIt 2 Konfiguration}
|
||||
Das somit erstellte Paket kann nun mit dem neu implementierten MoveIt Configurator um die benötigten Kontrollstrukturen erweitert werden.
|
||||
Dazu wurde der neue Setupassistent von MoveIt2 verwendet, welcher das Modell analysiert, um es mit für MoveIt benötigten Parameter zu erweitert.
|
||||
|
||||
Die Erstellung des erweiterten Modells mit dem Assistenten funktionierte komplett fehlerfrei, jedoch ließen sich die generierten Dateien nicht nutzen.
|
||||
|
||||
Um die generierten Dateien nutzen zu können, mussten diese weiter angepasst werden.
|
||||
Dies beinhaltete die korrekte Integration der Roboterdefinitionen im Paket, aber auch zahlreiche Pfadreferenzen auf verwendete Dateien, welche nicht korrekt generiert wurden.
|
||||
Diese können standartmäßig nicht in Gazebo, RViz und MoveGroup gleichzeitig geladen werden, da diese Programme unterschiedliche Pfadangaben verlangen, was die Nutzung verhindert.
|
||||
|
||||
Eine Möglichkeit zur Lösung des Problems ist die Verwendung von \code{file://}-URIs, welche von allen dieser Programme gelesen werden können.
|
||||
Jedoch ist hier als Nachteil zu verzeichnen, dass der Moveit Setup Assistent diese URIs nicht lesen kann, was zu Fehlern bei einer Rekonfiguration führen kann.
|
||||
|
||||
Das so erstellte Modell kann ber den Aufruf von \code{ros2 launch iisy_config demo.launch.py} in RViz getestet werden.
|
||||
Hierfür erscheint das Robotermodell mit mehreren Markern und Planungsoptionen, welche genutzt werden können, um beliebige Bewegungen zu planen und auszuführen.
|
||||
\subsection{Details}
|
||||
Das so erstellte Modell kann nun zur Laufzeit in Gazebo geladen werden.
|
||||
Dafür wird das Paket \code{ros_gz_sim} verwendet, welches das \code{create} Programm beinhaltet.
|
||||
Mit diesem Werkzeuk kann ein Modell unter einem bestimmten Namen anhand einer Datei oder eines übergebenen Strings in Gazebo importiert werden.
|
||||
Das Modell kann dabei über Argumente im Raum verschoben und rotiert werden, falls diese Funktionalität benötigt wird.
|
||||
|
||||
Im Modell sind auch die verwendeten Gazebo-Plugins deklariert, welche für die Integration mit dem \code{ros_control} verantwortlich sind.
|
||||
Im Modell sind auch die verwendeten Gazebo-Plugins deklariert, welche für die Integration mit \code{ros_control} verantwortlich sind.
|
||||
Das Gazebo-Plugin läd dabei die verwendeten Controller und versorgt diese mit Informationen über den Roboter.
|
||||
|
||||
Die zusätzlichen Programme werden nun in die gazebo_controller.launch.py-Datei
|
||||
|
||||
\section{Behavior Trees}
|
||||
Alle Behavior Trees wurden im Paket \code{btree_trees} organisert, welche durch das Paket \code{btree_nodes} gelesen werden.
|
||||
BehaviorTrees werden in \code{behaviortree_cpp_v3} als .xml-Dateien gespeichert.
|
||||
Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeschnittstellen.
|
||||
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.
|
||||
|
||||
Solche Schnittstellen können verwendet werden, um Nodes generischer gestalten zu können.
|
||||
So kann auf feste Parameter in den Nodes selber verzichtet werden, was das erstellen mehrerer Nodes für ähnliche Funktionalitäten verhindert.
|
||||
Diese Daten können sowohl aus einem String ausgelesen werden, falls die ensprechende Funktion, welche diese in den Zieltyp übersetzt, implementiert wurde.
|
||||
Aber sie können auch aus dem sogenannten Blackboard entnommen werden.
|
||||
|
||||
Das Blackboard ist ein System, welches die Nutzung von Variablen als Parameter für Ein- und Ausgänge erlaubt.
|
||||
Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeichert.
|
||||
Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des BehaviorTrees.
|
||||
Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, welche zu komplexeren Strukturen zusammengesetzt werden können.
|
||||
Für die Umsetzung des Szenarios wurden neue Nodes für den BehaviorTree erstellt.
|
||||
Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
|
||||
|
||||
Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Nodes als sogenannte SubTrees abspeichern.
|
||||
Diese bilden dann in ihrer Gesamtheit eine neue Node, welche im BehaviorTree eingesetzt werden kann.
|
||||
Um den Einsatz von Variablen innerhalb eines SubTrees zu ermöglichen, besitzt jeder SubTree ein separates Blackboard.
|
||||
Dadurch kann ein Eingriff in äußere Funktionalität verhindert werden.
|
||||
\subsubsection{Allgemein nutzbare Nodes}
|
||||
\begin{description}
|
||||
\item[GenerateXYPose]
|
||||
generiert eine Pose in einem durch den \code{area} Parameter angegebenen Bereich.
|
||||
Um dies zu ermöglichen, wird zuerst die Fläche aller Dreiecke berechnet, welche den Bereich definieren.
|
||||
Diese werden durch den Gesamtinhalt geteilt, um eine Wichtung der Dreiecke zum Gesamtinhalt zu erreichen.
|
||||
Nun wird eine Zufallszahl zwischen 0 und 1 gebildet.
|
||||
Von dieser werden nun die Wichtungen der Dreiecke abgezogen, bis dies Zufallszahl im nächsten abzuziehenden Dreieck liegt.
|
||||
Nun wird in diesem Dreieck eine zufällige Position ermittelt, welche ber den Ausgabeparameter \code{pose} ausgegeben wird.
|
||||
\item[InAreaTest]
|
||||
prüft, ob eine Pose, vorgegeben durch den \code{pose} Parameter, in einer durch den \code{area} Parameter definierten Zone liegt.
|
||||
Hierfür wird überprüft, ob die X und Y-Werte der Pose in einem der Dreiecke liegen, welche die Area definieren.
|
||||
Der Rückgabewert ist das Ergebnis dieser Überprüfung, wobei SUCCESS bedeutet, dass sich die Pose in der Area befindet.
|
||||
\item[OffsetPose]
|
||||
wird genuzt, um eine Pose im Raum zu bewegen und/oder deren Orientierung zu verändern.
|
||||
Falls der \code{offset} Parameter gesetzt ist, wird dieser mit dem \code{input} Parameter summiert.
|
||||
Außerdem wird die Orientierung der Pose auf den \code{orientation} Parameter gesetzt, falls dieser vorhanden ist, was den ursprünglichen Wert überschreibt.
|
||||
\item[InterruptableSequence]
|
||||
stellt eine Sequence dar, welche auch nach ihrem Abbruch ihre Position behält.
|
||||
Dies ist von Nöten, wenn bestimmtes Verhalten unterbrechbar ist, aber zu einem späteren Zeitpunkt fortgesetzt werden soll.
|
||||
Hierzu wird der Iterator der unterlegenden Sequenz nur erhöht, wenn die untergeordnete Node SUCCESS zurück gibt.
|
||||
Außerdem wird der Iterator nicht zurückgesetzt, wenn die Ausführung dieser modifizierten Sequenz abgebrochen wird.
|
||||
\item[WeightedRandom]
|
||||
ist eine Steuerungsnode, welche mehrere untergeordnete Nodes besitzt.
|
||||
Dabei werden diese nicht, wie bei anderen Steuerungsnodes üblich, sequentiell ausgeführt.
|
||||
Anhand einer vorgegebenen Wichtung im \code{weights} Parameter wird eine der untergeordneten Nodes zufällig ausgewählt.
|
||||
Diese Node wird nun als einzige Node ausgeführt, bis diese den SUCCESS-Status zurück gibt.
|
||||
Nach dem dieser Status erreicht wurde, wird bei dem nächsten Durchlauf eine neue Node ausgewählt.
|
||||
Der Rückgabewert ist der Rückgabewert der ausgewählten untergeorneten Node.
|
||||
\item[IsCalled]
|
||||
fragt den aktuellen Called-Status des Actors ab, welcher in einigen Szenarien vom Roboter verwendet wird, um den simulierten Menschen zu rufen.
|
||||
Der Rückgabewert der Node ist dabei SUCCESS, falls der Mensch gerufen wird, oder FAILURE, wenn kein RUF durchgeführt wird.
|
||||
\item[SetCalledTo]
|
||||
setzt den aktuellen Called-Status auf den Wert des übergebenen \code{state} Parameters.
|
||||
Da diese Aktion nicht fehlschlagen kann, liefert diese Node immer SUCCESS als Rückgabewert.
|
||||
\item[RandomFailure]
|
||||
generiert eine Zufallszahl von 0 bis 1, welche mit dem \code{failure_chance} Parameter verglichen wird.
|
||||
Der Rückgabewert ist das Ergebnis des Vergleichs, FAILURE, wenn die Zufallszahl kleiner als der \code{failure_chance} Parameter ist, oder im anderen Falle SUCCESS.
|
||||
\end{description}
|
||||
|
||||
Natürlich sollte es auch möglich sein, Variablen an solche SubTrees zu übergeben.
|
||||
Diese können, wie auch bei normalen Nodes, einfach als Parameter an den SubTree übergeben werden.
|
||||
Die Bibliothek \code{behaviortree_cpp_v3} verbindet dann diese Werte und erlaubt die Datenübergabe zu und von dem SubTree.
|
||||
\subsubsection{Menschenspezifisch}
|
||||
\begin{description}
|
||||
\item[ActorAnimation]
|
||||
wird verwendet, um dem simulierten Menschen eine auszuführende Animation zu senden.
|
||||
Die Node benötigt zur Ausführung einen Animationsname, welcher im \code{animation_name} Parameter angegeben wird.
|
||||
Ein optionaler \code{animation_speed} Parameter gibt die Ausführungsgeschwindigkeit vor.
|
||||
Der Rückgabewert ist SUCCESS, wenn die komplette Ausführung gelang, oder FAILURE, falls diese abgebrochen oder abgelehnt wurde.
|
||||
\item[ActorMovement]
|
||||
funktioniert wie eine ActorAnimation, sendet jedoch eine Bewegungsanfrage.
|
||||
Auch für diese wird ein Animationsname benötigt, welcher im \code{animation_name} Parameter definiert wird.
|
||||
Jedoch wird für die Synchronisation zur Bewegung ein Diztanzwert bewnötigt, welcher in einem Animationsdurchlauf zurückgelegt wied.
|
||||
Dieser wird im \code{animation_distance} Parameter übergeben.
|
||||
Eine Zielpose wird im \code{target} Parameter gesetzt.
|
||||
Eine Besonderheit dieses Paramerters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
|
||||
\end{description}
|
||||
|
||||
\subsection{Asynchrone Nodes}
|
||||
Da nicht jeder Prozess in einem einzigen Durchlauf des BehaviorTrees abgebildet werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
|
||||
Dies geschieht in in \code{behaviortree_cpp_v3} durch asynchrone Nodes.
|
||||
\subsubsection{Roboterspezifisch}
|
||||
\begin{description}
|
||||
\item[RobotMove] gibt dem Roboter eine neue Zielposition über den \code{target} Parameter vor.
|
||||
Bei dieser Node handelt es sich um eine asynchrone Node, welche nur bei der erfolgreiche Ausführung der Bewegung SUCCESS zurück gibt.
|
||||
\item[SetRobotVelocity] setzt eine neue maximale Geschwindigkeit des Roboters, vorgegeben durch den \code{velocity} Parameter.
|
||||
Der Rückgabewert ist immer SUCCESS.
|
||||
\end{description}
|
||||
Diese beiden roboterspezifischen Nodes beeinflussen im Hintergrund das gleiche System, da Bewegungen bei Geschwindigkeitsänderungen neu geplant und ausgeführt werden müssen.
|
||||
Dazu wird das letzte Ziel bis zu dessen erreichen vorgehalten, um die Ausführung neu zu starten, fall eine Geschwindigkeitsänderung durchgeführt werden muss.
|
||||
Um die RobotMove-Node nicht zu unterbrechen, wird diese nur über einen Callback über den Erfolg oder Misserfolg der gesamten Bewegung und nicht über den Erfolg einzelner Teilbewegungen informiert.
|
||||
|
||||
Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE auch noch die beiden anderen Zustände RUNNING und IDLE.
|
||||
\section{Docker-Compose}
|
||||
Um Docker für die Verwaltung einer ROS-Installation verwenden zu können, müssen einige Anpassungen vorgenommen werden.
|
||||
Da viele Anwendungen, unter anderem auch die Simulationsumgebung, eine Desktopumgebung benötigen, muss eine Zugriffsmöglichkeit geschaffen werden.
|
||||
|
||||
Der Zustand RUNNING steht dabei für eine Node, welche sich noch in der Ausführung befindet.
|
||||
So lang dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand abgefragt.
|
||||
Diese Möglichkeiten können nicht durch Docker allein gelöst werden, da Befehle auf dem Hostsystem ausgeführt werden müssen, um die gewünschten Funktionen zu aktivieren.
|
||||
Um diese Modifikiationen trotzdem reproduzierbar zu machen, wurde ein Shellscript geschrieben, welches zum Starten des Containers verwendet wird.
|
||||
|
||||
Der IDLE-Zustand ist ein besonderer Zustand, welcher nur durch eine vollständige Ausführung erreichbar ist.
|
||||
Er wird von der Node angenommen, nachdem ein RUNNING Zustand durch entweder SUCCESS oder FAILURE beendet wurde und darf sonst nicht verwendet werden.
|
||||
Dieses Skript erstellt zuerst die benötigten Verzeichnisse für den Container, falls diese noch nicht existieren.
|
||||
Danach werden die SSH-Keys des Hosts in den Container kopiert, um eine SSH-Verbindung zu ermöglichen.
|
||||
Dieser Umweg über SSH ist nötig, da die benötigten Umgebungsvariablen für ROS sonst nicht in allen Fällen gesetzt werden können.
|
||||
|
||||
Außerdem werden die benötigten Zugriffe auf den lokalen X-Server durch den Container anhand dessen Hostname erlaubt.
|
||||
Diese Änderung erlaubt es dem Container, Fenster auf dem Desktop anzeigen zu können, solange die benötigten SysFS-Dateien hereingereicht werden.
|
||||
Dies geschieht durch Einträge in der compose.yml-Datei, welche diese als ``bind mount'' in den Container hereinreicht.
|
||||
|
||||
Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repräsentation im SysFS unter \code{/dev/dri} hineingereicht werden.
|
||||
Der Zugriff auf die Desktopumgebung, welcher bereits entsperrt wurde, wird nun durch das mounten von \code{/tmp/.X11-unix} erreicht.
|
||||
Dabei handelt es sich um den Unix-Socket des X11 Displayservers.
|
||||
|
||||
Zum Starten des Containers muss der Befehl \code{./start.sh} im Verzeichnis der Containerinstallation ausgeführt werden, welcher die obengenannten Schritte ausführt und den Container startet.
|
||||
Eine Verbindung zum Container kann aufgebaut werden, nachdem die Meldung \code{ros_1 | Ready to connect.} in der Konsole erscheint.
|
||||
|
||||
Dafür muss ein SSH-Client eingesetzt werden, welcher eine Verbindung zu der lokalen Netzadresse des Systems mit dem Benutzer \code{ros} aufbauen kann.
|
||||
Der Port des SSH-Servers wird dabei durch die Deklaration im docker-compose.yaml an das Hostsystem durchgereicht.
|
||||
Hierbei ist zu beachten, dass der SSH-Server im Container auf Port 2222 ausgeführt wird, was bei der Verbindung beachtet werden muss.
|
||||
|
||||
Nach der Verbindung wird automatisch die ROS2-Umgebung eingerichtet, welche sofort nach Verbindungsaufbau genutzt werden kann.
|
||||
Um die erstellten Pakete zu kompillieren, kann das Skript \code{build.sh} im \code{workspace}-Verzeichnis verwendet werden.
|
||||
|
||||
Dieses Skript nutzt \code{colcon} um alle Pakete in diesem Workspace zu erstellen.
|
||||
Dabei wird auch noch eine \code{compile_commands.json}-Datei erstellt, welche von einigen IDE's zur Syntaxvervollständigung genutzt werden.
|
||||
Außerdem wird der Event-Handler \code{console_cohesion+} verwendet, welcher das Lesen der Kompillierausgabe erleichtert.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user