Skip to content
Snippets Groups Projects
Commit 084f9580 authored by JimM's avatar JimM
Browse files

Einordnung der angewandten Constraints

parent 212a246e
Branches
No related tags found
No related merge requests found
Pipeline #9027 failed
images/Taxonomie.jpg

99.8 KiB | W: | H:

images/Taxonomie.jpg

101 KiB | W: | H:

images/Taxonomie.jpg
images/Taxonomie.jpg
images/Taxonomie.jpg
images/Taxonomie.jpg
  • 2-up
  • Swipe
  • Onion skin
images/cobot_1_init.png

46.3 KiB

images/cobot_2_init.png

37.8 KiB

\chapter{Ausblick}
In diesem Abschnitt werden verschiedene Erweiterungen der Fallstudie vorgestellt und daraus resultierende Constraints ebenfalls in die Taxonomie eingeordnet werden.
\ No newline at end of file
\chapter{Erprobung der Anwendungsinstallation}\label{ch:evaluation}
\chapter{Evaluation}
Ziel der Fallstudie war die Anwendung einiger der in der Taxonomie eingeordneten Constraints in einem realen Anwendungsfall. In diesem Kapitel wird die Implementierung hinsichtlich der Erfüllung der in Abschnitt~\ref{ch:requirements} gelisteten Anforderungen überprüft. Dazu werden beide Cobot-Anwendungsfälle in einer Gazebo Simulationsumgebung simuliert. Anschließend werden alle aufgetretenen Constraints in die in Kapitel~\ref{ch:taxonomy} präsentierte Taxonomie eingeordnet.
\blindtext
\section{Simulation}
Die Initialisierung der Simulationsumgebung geschieht in einem Zuge mit dem Hinzufügen der Objekte in die Planning Scene. Die Startzustände der beiden Roboter sind in Abbildung~\ref{fig:cobots_init} zu sehen.
\begin{figure}
\ffigbox[\FBwidth]%
{\begin{subfloatrow}%
\ffigbox[\FBwidth]%
{\includegraphics[height=7cm]{images/cobot_1_init.png}}%
{\caption{Cobot 1}\label{fig:cobit_1_init}}%
\ffigbox[\FBwidth]%
{\includegraphics[height=7cm]{images/cobot_2_init.png}}%
{\caption{Cobot 2}\label{fig:cobit_2_init}}%
\end{subfloatrow}}%
{\caption{Gazebo Simulationsumgebung nach der Initialisierung}\label{fig:cobots_init}}%
\end{figure}
\section{Constraints}
In diesem Abschnitt werden alle verwendeten Constraints aufgelistet und in die Taxonomie eingeordnet.
\paragraph{Workflow}
Die Handlungen der beiden Roboter folgt einem strikten Ablaufplan. Ihre Handlungswahl ist dementsprechend beschränkt. In der Taxonomie wird ein solcher Constraint eingeordnet unter:
\begin{center}
Robotische Constraints → Handlung → Endeffektorunspezifisch
\end{center}
\paragraph{Orientierung}
Bei der Handhabung und Manipulation von mit Flüssigkeit befüllten Behältern, müssen die Roboter diesen aufrecht relativ zum Boden halten. Dies geschieht beim Aufnehmen der Flasche, der Bewegung der Flasche an das Glas hinan, beim Abstellen der Flasche, bei der Aufnahme des Glases, bei der Bewegung des Glases und beim Abstellen des Glases. Dieser Constraint wird bereits bei der Pfadplanung berücksichtigt und ist aufgrund der Art des bewegten Werkstücks notwendig. Daher lässt er sich in der Taxonomie einordnen unter:
\begin{center}
Robotische Constraints → Pfad → Orientierung des Endeffektors → Bewegtes Werkstück
\end{center}
\paragraph{Beschleunigung}
Neben der Orientierung, muss beim Arbeiten mit Flüssigkeiten auch die Beschleunigung beschränkt werden, um ein Überschwappen zu verhindern. Berücksichtigt wird die Beschleunigungsskalierung von der Move Group erst bei Ausführung des geplanten Pfads. Dementsprechend wird der Beschleunigungs-Constraint wie folgt eingeordnet:
\begin{center}
Robotische Constraints → Bewegung → Beschleunigung → Bewegtes Werkstück
\end{center}
\paragraph{Geschwindigkeit}
Das Umfüllen der Flüssigkeit aus den ersten in den zweiten Behälter erforderte eine zusätzliche Beschränkung der Geschwindigkeit. Eine zu schnelle Rotation des Endeffektors könnte ebenfalls zu einem Überschwappen führen. So wie der Beschleunigungs-Constraint wird auch der Geschwindigkeits-Constraint als Bewegungs-Constraint eingeordnet:
\begin{center}
Robotische Constraints → Bewegung → Geschwindigkeit → Bewegtes Werkstück
\end{center}
\paragraph{Sicherheitszone}
Um eine Kollision der Roboter in dem sich überschneidenden Arbeitsbereich zu verhindern, ist es immer nur einem Roboter möglich die Sicherheitszone zu betreten. Da das Betreten nicht mit einer Änderung des Verhaltens einhergeht, sondern ohne weiteres gar nicht möglich ist, handelt es sich eigentlich um verbotene Zone:
\begin{center}
Robotische Constraints → Pfad → Arbeitsbereich → Kollaboration → Verbotene Zone
\end{center}
Realisiert wurde die Sicherheitszone in der Fallstudie durch ein weiteres Kollisionsobjekt, weshalb eine zusätzliche Einordnung möglich ist:
\begin{center}
Robotische Constraints → Pfad → Hindernisse
\end{center}
\ No newline at end of file
......@@ -23,6 +23,8 @@ Um einen reibungslosen Ablauf zu gewährleisten und den gestellten Anforderungen
\item[C3] Arbeitsbereich: Um eine Kollision der beiden Roboter zu vermeiden, soll um die Übergabestelle eine Sicherheitszone eingerichtet werde, die immer nur von einem Roboter geschnitten werden darf.
\item[C4] Näherung: Nach der Aufnahme eines Objektes soll ein zusätzlicher Sicherheitsabstand zu anderen Objekten und insbesondere dem Tisch eingehalten werden, bis das Objekt wieder abgestellt wird.
\item [C5] Handlung: Die Handlungen dürfen nur in der durch die Aufgabenstellung vorgeschriebenen Reihenfolge durchgeführt werden.
\end{enumerate}
Zusätzlich sind noch weitere handlungsunabhängige Anforderungen zu berücksichtigen:
\begin{enumerate}
......@@ -185,10 +187,3 @@ Anhand dieses Objekts kann der \textit{ObjectCreator} entsprechende Kollisionsob
\subsection{PressureSensor}
Als Drucksensor wird die Tinkerforge Load\_Cell\_V2\footnote{\url{https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Load_Cell_V2.html}} verwendet. Für den Sensor steht ein \textit{C/C++} API Binding zur Verfügung, welches mit im \textit{pressure\_sensor} Package liegt und vom \textit{PressureSensor}-Node eingebunden wird. Dieser inseriert das \verb|pressure| Topic beim ROS Master und lädt die Konfigurationsparameter des Drucksensors vom ROS Parameter Server. Die Parameter enthalten sowohl die Adresse des Sensors als auch den Grenzwert in Gramm, ab dem das Glas als vorhanden angesehen werden soll. Bei jeder Änderung in der Messung, wird das Gewicht neu ausgewertet und der Zustand auf dem Topic veröffentlicht.
\section{Evaluation}
\textcolor{blue}{
Konnte die Fallstudie zeigen, dass Einschränkungen aus der Taxonomie angewandt werden können?
\paragraph{} Wo sind die implementierten Constraints einzuordnen?
\paragraph{} Wie könnte die Fallstudie erweitert werden, sodass neue Constraints notwendig sind und sind diese bereits in der Taxonomie enthalten?
}
\ No newline at end of file
......@@ -16,7 +16,6 @@
\AtEveryBibitem{%
\clearfield{note}%
}
\usepackage[hidelinks]{hyperref} % makes all links clickable but hides ugly boxes
\usepackage[capitalise,nameinlink,noabbrev]{cleveref} % automatically inserts Fig. X in the text with \cref{..}
......@@ -142,7 +141,8 @@
\input{sections/tax_einordnung.tex}
\input{sections/implementierung.tex}
%\input{sections/problem.tex}
%\input{sections/eval.tex}
\input{sections/eval.tex}
\input{sections/ausblick.tex}
\input{sections/zusammenfassung.tex}
\printbibliography[heading=bibintoc]\label{sec:bibliography}%
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment