MasterarbeitLaTeX/tex/2_Konzept.tex

\chapter{Konzept}
Die zu entwickelnde Simulation soll die bisher meißt 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 Bewegungsplanung des simulierten Menschen.
Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen diesen auch Nachrichten ausgetauscht.
Der gesamte Vorgang ist in Abbildung \ref{concept_overview} visualisiert.

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.drawio.pdf}
\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 interessant, was einen für 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 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 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.
Dieses Modell soll dabei um weitere Animationen erweiterbar sein.
Es werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.

Die so erstellten Animationen müssen nun von außerhalb der Simulationsumgebung ausführbar gemacht werden, um diese später mit einer Beschreibungssprache steuern zu können.
Hierfür muss eine Komponente entwickelt werden, die in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Anfragen im Fortschritt überwacht und abgebrochen werden können.

\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 von Rodney Brooks entwickelt, der diese für mobile Roboter einsetzen wollte. \cite{1087032}
Das System setzte sich jedoch erst später in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten durch. \cite{isla2005handling}

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, dass die Relation der Nodes zueinander beschreibt.
Jede Node ist entweder direkt unter der Root-Node oder einer anderen Node angeordnet.
Außerdem kann jede Node eine beliebige Anzahl an untergeordneten Nodes besitzen.
Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unterschieden werden können.
\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.
  Häufig existieren hier die Negation, aber auch das forcieren eines bestimmten Rückgabewertes für die unterliegende Node.
 \item[Sequenz-Nodes]
  beschreiben eine nacheinander ausgeführte Abfolge von darunter liegenden Nodes.
  Sollte eine Node einen Fehler zurückgeben, wird die Ausführung der Sequenz abgebrochen, was wiederum zur Rückgabe eines Fehlers durch die Sequenz selbst führt.
  Beim erfolgreichen Durchlauf gibt die Sequenz einen Erfolg zurück.
 \item[Fallback-Nodes]
  verhalten sich ähnlich zu Sequenz-Nodes, jedoch werden darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurück gibt.
  In diesem Fall wird die Ausführung der Fallback-Node mit einem Erfolg abgebrochen.
  Ein Fehler wird hier zurückgegeben, wenn alle Nodes ohne eine Erfolgsmeldung durchlaufen wurden.
\end{description}

\begin{figure}[]
\includegraphics[]{img/tree_demo}
\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, die drei untergeordnete Nodes besitzt.

Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, ausgeführt.
Daraus resultierend wird als erstes die linke Node ausgeführt, diese ist jedoch eine Fallback-Node mit weiteren untergeordneten Nodes.
Da der Rückgabewert der Fallback-Node von den in ihr befindlichen Nodes bestimmt wird, werden diese nun nacheinander ausgeführt.
Hier gelten die oben genannten Regeln für Fallback-Nodes.
In diesem Fall wird geprüft, ob die Tür bereits offen ist.
Da dies nicht der Fall ist, wird die nächste Node ausgeführt, welche die Tür öffnen soll.
Dieser Versuch gelingt, weshalb die Ausführung der Fallback-Node mit einem Erfolg beendet wird.

Dadurch wird die nächste Node in der Sequenz ausgeführt, 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, der die Ausführung der Sequenz abbricht.
Diese würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.

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, die in dieser Arbeit betrachtet werden, abzudecken.

\section{Virtualisierungsumgebung als Platform}
Aufgrund von vorheriger Erfahrung mit involvierten Einrichtungsprozessen, ist der Einsatz fest definierter Umgebungen unerlässlich.
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 alle Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.

Ein weiterer Vorteil ist die beschleunigte Entwicklung, da Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
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 der virtualisierten Anwendung nicht mehr zur Verfügung steht.
Außerdem muss bei grafischen Systemen bedacht werden, wie die darzustellenden Daten vom Hostsystem angezeigt werden können.

Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung stellt einen wichtigen Schritt in der Entwicklung des Gesamtsystems dar.