\chapter{Konzept}
Die zu entwickelnde Simulation soll die bisher meist separaten Zweige der Roboter- und Menschensimulation verbinden.
Um die beiden Akteure in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
Diese Befehle werden dabei von externer Software unter der Verwendung einer Beschreibungssprache und Feedback aus der Simulation generiert.

Hierfür wird die Beschreibungssprache in der Dienstumgebung ausgeführt, in der auch die Bewegungsplanung stattfindet.
Die Beschreibungssprache kommuniziert direkt mit der Simulation und der Bewegungsplanung des simulierten Menschen.
Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen Simulation und Bewegungsplanung auch Nachrichten ausgetauscht.
Der gesamte Vorgang ist in Abbildung \ref{concept_overview} visualisiert.

Die zu erarbeitende Softwareumgebung soll einfach erweiterbar sein, um weitere Modifikationen und die Umsetzung anderer Projekte zuzulassen.
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 aufzubauen.

\begin{figure}
\includegraphics{img/MA-Konzept-Übersicht}
\centering
\caption{Visualisierung des Konzepts}
\label{concept_overview}
\end{figure}

\section{Simulation des Roboters}
Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
Außerdem ist die enge Interaktion mit Menschen gewünscht, was für einen auf Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, der als Cobot vermarktet wird.
Die Bezeichnung als Cobot\cite{cobot} ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
Der Roboter besitzt einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.

Um den Kuka iisy in der Simulation verwenden zu können, muss ein Modell des Roboterarms erstellt werden.
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst genau 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 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.

Um diese Animationen erstellen zu können, wird zuerst ein animierbares Modell des Menschen benötigt.
Das zu erstellende Modell soll dabei um weitere Animationen erweiterbar sein.
Unterschiedliche Animationen gehen dabei meist von verschiedenen Ursprungszuständen aus.
Um zwischen diesen Ursprungszuständen wechseln zu können, werden weitere Animationen benötigt.

Die so erstellten Animationen müssen von außerhalb der Simulationsumgebung ausführbar gemacht werden.
Ein solcher Mechanismus erlaubt die spätere Steuerung der Animation durch die Beschreibungssprache.
Hierfür muss eine Komponente entwickelt werden, die in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, soll diese Komponente die Ausführung der Befehle überwachen.
Da mehrere Befehle nacheinander ausgeführt werden sollen, wird der aktuelle Fortschritt der Aktion zurückgemeldet.
Außerdem kann durch andere Komponenten in der Simulation der Abbruch einer Aktion des Menschen nötig werden.
Die Weitergabe eines Abbruchbefehls soll demzufolge auch über die geplante Komponente realisiert werden können.

\section{Behavior Trees als Beschreibungssprache}
Bislang wird das Verhalten von Akteuren in Simationsumgebungen, darunter Roboter und Menschen, häufig in Form von State-Machines ausgedrückt.
Diese besitzen jedoch einen großen Nachteil, der vor allem bei komplexeren Abläufen hervortreten kann.
Dabei handelt es sich um die Übersichtlichkeit, die bei einer wachsenden State-Machine leicht verloren geht.
Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, was zu Fehlern im späteren Betrieb führen kann.

Behavior Trees lösen dieses Problem, in dem sie sogenannte Nodes definieren, die in einer übersichtlichen Baumstruktur angeordnet werden.
Die einzelnen Nodes verändern dabei das System und lösen den Wechsel zu neuen Nodes aus.

Ursprünglich wurde das Konzept der Behavior Trees von Rodney Brooks entwickelt, der diese für mobile Roboter einsetzen wollte. \cite{1087032}
Das System setzte sich später jedoch zuerst in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten, durch. \cite{isla2005handling}

Der Ablauf eines Behavior Trees startet vom sogenannten Root, der Wurzel des Baums.
Von dort an werden Nodes, die je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
Die Nodes werden untereinander angeordnet, was die Relation der Nodes zueinander beschreibt.
Jede Node ist entweder direkt unter der Root-Node oder einer anderen Node angeordnet.
Außerdem kann jede Node eine beliebige Anzahl an untergeordneten Nodes besitzen.
Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unterschieden werden.
\begin{description}
 \item[Aktions-Nodes]
  beschreiben einzelne ausführbare Aktionen, die das System beeinflussen können.
  Jede Aktion liefert dabei einen Rückgabewert über ihren Erfolg, der durch die darüber liegende Node ausgewertet werden kann.
 \item[Dekorations-Nodes]
  können den Rückgabewert einer anderen Node modifizieren.
  Zumeist wird die Negation des Rückgabewerts verwendet, aber auch das Forcieren eines bestimmten Rückgabewertes ist möglich.
 \item[Sequenz-Nodes]
  beschreiben eine nacheinander ausgeführte Abfolge von darunter liegenden Nodes.
  Sollte eine Node einen Fehler zurückgeben, wird die Ausführung der Sequenz abgebrochen, was wiederum zur Rückgabe eines Fehlers durch die Sequenz selbst führt.
  Beim erfolgreichen Durchlauf gibt die Sequenz einen Erfolg zurück.
 \item[Fallback-Nodes]
  verhalten sich ähnlich wie Sequenz-Nodes, jedoch werden die darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurück gibt.
  In diesem Fall wird die Ausführung der Fallback-Node mit einem Erfolg abgebrochen.
  Ein Fehler wird hier zurückgegeben, wenn alle Nodes ohne eine Erfolgsmeldung durchlaufen wurden.
\end{description}

\begin{figure}
\includegraphics[]{img/MA-tree-demo}
\centering
\caption{Beispiel eines BehaviorTrees}
\label{concept_tree_demo}
\end{figure}

Das in Abbildung \ref{concept_tree_demo} visualisierte Beispiel zeigt die Abfolge, um eine Tür zu öffnen und zu durchschreiten.
Die Ausführung des Baumes beginnt an der Root-Node, wobei die Zahlen über den Nodes die Reihenfolge der Rückgabewerte angeben.

Von dort aus wird als erstes die Sequenz-Node ausgeführt, die drei untergeordnete Nodes besitzt.
Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, ausgeführt.

Daraus resultierend wird als erstes die linke Fallback-Node, die ihrerseits untergeordnete Nodes besitzt, ausgeführt.
Da der Rückgabewert der Fallback-Node von den unter ihr befindlichen Nodes bestimmt wird, werden diese nacheinander ausgeführt.

Von diesem Punkt an beginnen die Rückgaben, die das weitere Verhalten beeinflussen.
Folgender Kontrollfluss findet in diesem Beispiel statt:

\begin{enumerate}
 \item{
  In dieser Node wird geprüft, ob die Tür bereits offen ist.
  Da die Tür nicht offen ist, wird ein Misserfolg zurückgemeldet.
 }
 \item{
  Dieses Ergebnis löst die Ausführung der nächsten untergeordneten Node der Fallback-Node aus.
  Die so ausgewählte Node soll die Tür öffnen.
  Der Versuch gelingt und der Erfolg wird an die Fallback-Node übergeben.
 }
 \item{
  Da die untergeornete Node eine erfolgreiche Ausführung meldet, wird die Ausführung der Fallback-Node mit einem erfolgreichen Rückgabewert beendet.
  Aus diesem Grund wird die Node ``Tür eintreten'' nicht mehr ausgeführt.
 }
 \item{
  Dadurch wird die nächste Node in der Sequenz ausgeführt, die prüft, ob die Tür durchlaufen werden kann.
  Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet.
 }
 \item{
  Der gemeldete Misserfolg der untergeordneten Node bricht die Ausführung der Sequenz mit einem negativen Rückgabewert ab.
 }
\end{enumerate}

Dieser Ablauf würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.

Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich neue Verhalten implementieren.
Dies erlaubt die schnelle Anpassung des Verhaltens der gesteuerten Systeme.

In dieser Arbeit sollen deshalb BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, die in dieser Arbeit betrachtet werden, abzudecken.

\section{Virtualisierungsumgebung als Plattform}
Der Einsatz fest definierter Prozesse in einer stabilen Umgebung ist unerlässlich, um Fehler durch die unvollständige Einrichtung der Umgebung zu vermeiden.
Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in der das zu entwerfende System ausgeführt wird.

Dadurch können benötigte Programme, Pfade und Umgebungsvariablen in der Virtualisierungsumgebung hinterlegt werden, die diese bei der Ausführung auf einem anderen Grundsystem korrekt abbildet.
Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da die Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.

Ein weiterer Vorteil ist die beschleunigte Entwicklung, weil Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
Hinzu kommt die einfachere Inbetriebnahme eines bereits entwickelten Systems, da keine Anpassungen am Hostsystem vorgenommen werden müssen.

Natürlich existieren auch Nachteile der Virtualisierung, die mit den Vorteilen abgewogen werden müssen.
Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, die dann der virtualisierten Anwendung nicht mehr zur Verfügung steht.
Außerdem muss bei grafischen Systemen die Darstellung der relevanten grafischen Daten auf dem Hostsystem berücksichtigt werden.

Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung beeinflusst das Ergebnis dieser Arbeit zwar nicht direkt, hat aber großen Einfluss auf die Pflege des Gesamtsystems.
Dies erlaubt zum Beispiel unabhängige, dedizierte Versionen der Softwarekomponenten und die Möglichkeit isolierter Upgrades dieser Komponenten.
Eine solche Plattform sorgt somit für die Reproduzierbarkeit der Ergebnisse auf verschiedenen Systemen.