Merge branch 'master' of https://gitea.yenon.at/yenon/MasterarbeitLaTeX
This commit is contained in:
commit
37459bc12d
@ -113,8 +113,8 @@ TextFolding={"checksum":"","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:main.bib]
|
||||
CursorColumn=14
|
||||
CursorLine=250
|
||||
CursorColumn=1
|
||||
CursorLine=231
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"cf8b2614fde9a70da69bd9296f0dc1ae50c584e2","ranges":[]}
|
||||
|
||||
9
MA.gummi
Normal file
9
MA.gummi
Normal file
@ -0,0 +1,9 @@
|
||||
version=0.6.0
|
||||
typesetter=pdflatex
|
||||
steps=texpdf
|
||||
root=/home/yenon/MasterarbeitLaTeX/main.tex
|
||||
|
||||
file=/home/yenon/MasterarbeitLaTeX/tex/1_Einleitung.tex
|
||||
file=/home/yenon/MasterarbeitLaTeX/tex/2_Konzept.tex
|
||||
file=/home/yenon/MasterarbeitLaTeX/tex/3_Auswahl.tex
|
||||
file=/home/yenon/MasterarbeitLaTeX/tex/4_Umsetzung.tex
|
||||
@ -2,24 +2,33 @@
|
||||
\section{Motivation}
|
||||
Die Simulation von Maschinen wird im industriellen Umfeld immer beliebter, um deren Verhalten schon vor der eigentlichen Produktion zu testen.
|
||||
Dazu wird ein Modell des gesamten Prozesses in der Simulation geschaffen, der durch die Maschine beeinflusst werden soll.
|
||||
Das Modell wird dann um die Maschine selbst erweitert, die Einfluss auf das System nimmt.
|
||||
Die Veränderungen durch die Maschine werden nun analysiert, und erlauben Rückschlüsse auf die Funktion des Systems.
|
||||
Das Modell wird um die Maschine selbst erweitert, die Einfluss auf das
|
||||
System nimmt.
|
||||
Die Veränderungen durch die Maschine werden analysiert, und erlauben
|
||||
Rückschlüsse auf die Funktion des Systems.
|
||||
Ein solches Modell kann nun für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
|
||||
|
||||
|
||||
Im wachsenden Feld der Mensch-Roboter-Kollaboration existieren bereits einige Lösungen, um auch die namensgebende Interaktion von Mensch und Roboter simulieren zu können.
|
||||
Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf in der Simulation bereits vor deren Ausführung fest definiert werden muss.
|
||||
Dies erlaubt die Reproduktion des genauen Bewegungsablaufes, aber nicht verschiedene Variationen im gesamten Prozess, die durch die Ereignisse in der Simulation ausgelöst werden.
|
||||
Dies erlaubt lediglich die Reproduktion des genauen Bewegungsablaufes, aber
|
||||
nicht verschiedene Variationen im gesamten Prozess, die durch die Ereignisse in
|
||||
der Simulation ausgelöst werden.
|
||||
Um eine solche Funktionalität bereitstellen zu können, muss der Bewegungsablauf von sowohl Roboter und Mensch zur Laufzeit der Simulation gesteuert werden.
|
||||
|
||||
Dies soll durch eine eingängliche Beschreibungssprache ermöglicht werden, die einfach erweitert und auf neue Szenarien angepasst werden kann.
|
||||
Um diese Funktionalität zu demonstrieren, sollen 3 unterschiedliche Testszenarien in der Simulationsumgebung abgebildet werden.
|
||||
Diese Steuerung soll durch eine eingängliche Beschreibungssprache ermöglicht
|
||||
werden, die einfach erweitert und auf neue Szenarien angepasst werden kann.
|
||||
Um diese Funktionalität zu demonstrieren, sind 3 unterschiedliche
|
||||
Testszenarien in der Simulationsumgebung abzubilden.
|
||||
Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwischen Mensch und Roboter simulieren.
|
||||
|
||||
\section{Stand der Wissenschaft}
|
||||
Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen Teilaspekten einer solchen Simulation.
|
||||
Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen
|
||||
Teilaspekten einer Simulation eines Mensch-Roboter-Kollaborationsszenarios.
|
||||
|
||||
Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere Projekte dar.\cite{DOMBROWSKI2018134}
|
||||
Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen
|
||||
in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere
|
||||
Projekte dar.\cite{DOMBROWSKI2018134}
|
||||
Hierbei wird die erwünschte Interaktion betrachtet und aus den gewonnenen Daten werden Einschränkungen generiert.
|
||||
Diese Einschränkungen können nun in der Interaktion verwendet werden, um Verletzungen durch den Roboter auszuschließen.
|
||||
|
||||
@ -44,12 +53,15 @@ Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von M
|
||||
|
||||
Das erste Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe befassen, in der 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, um Kollisionen zu vermeiden.
|
||||
Der Mensch soll in diesem Szenario auch arbeiten, jedoch nur vereinzelt den Arbeitsbereich des Roboters betreten, um diesen zu beobachten.
|
||||
Der Mensch soll in diesem Szenario an einer anderen Aufgabe arbeiten.
|
||||
Während dieser Arbeit betritt der Mensch vereinzelt den Arbeitsbereich des
|
||||
Roboters, was eine entsprechende Reaktion hervorrufen soll.
|
||||
|
||||
Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide an unterschiedlichen Aufgaben, 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.
|
||||
Im zweiten Szenario prüft und sortiert der Roboter Teile und legt die
|
||||
fehlerfreien 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.
|
||||
Auch hier soll der Mensch solange eigenständig arbeiten, bis der Roboter ein aussortiertes Teil ablegt, dass weiter transportiert werden muss.
|
||||
|
||||
@ -58,8 +70,11 @@ Hierbei soll eine Palette entladen werden, wobei der Roboter nicht jedes Objekt
|
||||
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.
|
||||
Dieser soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren, was durch das Laufen im Raum abgebildet werden soll.
|
||||
\section{Welcher Nutzen / Contributions}
|
||||
\section{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, die durch eine Beschreibungssprache definiert werden sollen.
|
||||
Dazu ist eine schnelle Konfiguration von sowohl Roboter als auch Mensch auf
|
||||
unterschiedliche Szenarien nötig.
|
||||
Die Szenarien sollen dabei durch eine Beschreibungssprache definiert
|
||||
werden.
|
||||
Durch deren einfache Struktur soll komplexes Verhalten einfach und überschaubar definierbar sein, dass dann in der Simulation getestet werden kann.
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
\chapter{Konzept}
|
||||
Die zu entwickelnde Simulation soll die bisher meißt separaten Zweige der Roboter- und Menschensimulation verbinden.
|
||||
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 Bewegungsplanung des simulierten Menschen.
|
||||
Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen diesen auch Nachrichten ausgetauscht.
|
||||
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.
|
||||
@ -21,10 +21,10 @@ Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
|
||||
|
||||
\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.
|
||||
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 auch einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
|
||||
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.
|
||||
@ -36,8 +36,9 @@ Hierzu sollen in der Simulationsumgebung mehrere Animationen verwendet werden, w
|
||||
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.
|
||||
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 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.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user