130 lines
10 KiB
TeX
130 lines
10 KiB
TeX
\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 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.
|
|
Das zu erstellende Modell soll dabei um weitere Animationen erweiterbar sein.
|
|
Unterschiedliche Animationen gehen dabei meist von verschidenen 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, soll der aktuelle Fortschritt der Aktion zurückgemeldet werden.
|
|
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 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.
|
|
Meist existiert die Negation des Rückgabewerts, 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/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.
|
|
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 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 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 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}
|
|
Um Fehler durch die unvollständige Einrichtung der Umgebung zu vermeiden, ist der Einsatz fest definierter Prozesse 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.
|