103 lines
7.4 KiB
TeX
103 lines
7.4 KiB
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ü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 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, welcher als Cobot vermarktet wird.
|
|
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 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 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.
|
|
|
|
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, 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 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, 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.
|
|
\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}
|
|
|
|
\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.
|