Skip to content
Snippets Groups Projects
Commit 6bfb92f5 authored by Christoph Schröter's avatar Christoph Schröter
Browse files

No commit message 

No commit message
parent f0ec0293
Branches
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
cobot1_v1.xml 0 → 100644
+ 379
− 0
View file @ 6bfb92f5
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE nta PUBLIC '-//Uppaal Team//DTD Flat System 1.1//EN' 'http://www.it.uu.se/research/group/darts/uppaal/flat-1_2.dtd'>
<nta>
<declaration>// Place global declarations here.
int init_retry, retry;
int glass_retry;
bool successful;
bool orient_constraint_set;
chan pressure_signal;
chan move_to_bottle_pos;
chan move_to_glass_start, move_to_glass_end;
chan start_pour, stop_pour;
chan bottle_pickup, bottle_place;
chan glass_pickup, glass_place_start, glass_place_target;
chan move_to_start_pos;</declaration>
<template>
<name x="5" y="5">Cobot</name>
<declaration>// Place local declarations here.</declaration>
<location id="id0" x="-510" y="-365">
</location>
<location id="id1" x="-340" y="-187">
</location>
<location id="id2" x="-119" y="-187">
</location>
<location id="id3" x="221" y="-187">
</location>
<location id="id4" x="221" y="-17">
<name x="238" y="-42">pouring</name>
</location>
<location id="id5" x="-8" y="-17">
</location>
<location id="id6" x="-331" y="-17">
</location>
<location id="id7" x="-510" y="-17">
</location>
<location id="id8" x="-161" y="-17">
</location>
<location id="id9" x="-510" y="-187">
</location>
<location id="id10" x="-510" y="119">
</location>
<location id="id11" x="-272" y="119">
</location>
<location id="id12" x="17" y="119">
</location>
<location id="id13" x="255" y="119">
<name x="272" y="127">finished_success</name>
</location>
<location id="id14" x="-340" y="-365">
<committed/>
</location>
<location id="id15" x="306" y="-365">
<name x="331" y="-365">shut_down</name>
</location>
<location id="id16" x="-161" y="-119">
<committed/>
</location>
<location id="id17" x="-731" y="-17">
<committed/>
</location>
<location id="id18" x="-272" y="212">
<committed/>
</location>
<location id="id19" x="-42" y="212">
</location>
<location id="id20" x="-42" y="297">
<committed/>
</location>
<location id="id21" x="272" y="212">
<committed/>
</location>
<init ref="id0"/>
<transition>
<source ref="id7"/>
<target ref="id15"/>
<label kind="guard" x="221" y="42">glass_retry == 0</label>
<label kind="synchronisation" x="229" y="8">glass_pickup?</label>
<label kind="assignment" x="221" y="25">successful = true</label>
<nail x="-272" y="59"/>
<nail x="357" y="59"/>
<nail x="357" y="-246"/>
</transition>
<transition>
<source ref="id21"/>
<target ref="id15"/>
<label kind="guard" x="306" y="195">retry == 1</label>
<nail x="416" y="212"/>
<nail x="416" y="-212"/>
</transition>
<transition>
<source ref="id21"/>
<target ref="id19"/>
<label kind="guard" x="153" y="255">retry &gt; 1</label>
<label kind="assignment" x="161" y="272">retry--</label>
<nail x="161" y="255"/>
</transition>
<transition>
<source ref="id19"/>
<target ref="id21"/>
<label kind="synchronisation" x="102" y="170">glass_place_start?</label>
<label kind="assignment" x="93" y="187">successful = false</label>
</transition>
<transition>
<source ref="id20"/>
<target ref="id7"/>
<label kind="assignment" x="-578" y="280">glass_retry--</label>
<nail x="-629" y="297"/>
</transition>
<transition>
<source ref="id19"/>
<target ref="id20"/>
<label kind="synchronisation" x="-34" y="255">glass_place_start?</label>
<label kind="assignment" x="-34" y="272">successful = true</label>
</transition>
<transition>
<source ref="id18"/>
<target ref="id19"/>
<label kind="guard" x="-195" y="195">retry == 1</label>
<label kind="assignment" x="-221" y="212">retry = init_retry</label>
</transition>
<transition>
<source ref="id18"/>
<target ref="id11"/>
<label kind="guard" x="-391" y="153">retry &gt; 1</label>
<label kind="assignment" x="-374" y="170">retry--</label>
<nail x="-331" y="170"/>
</transition>
<transition>
<source ref="id11"/>
<target ref="id18"/>
<label kind="synchronisation" x="-263" y="144">glass_place_target?</label>
<label kind="assignment" x="-263" y="161">successful = false</label>
</transition>
<transition>
<source ref="id17"/>
<target ref="id15"/>
<label kind="guard" x="-731" y="-518">retry == 1</label>
<nail x="-731" y="-501"/>
<nail x="297" y="-501"/>
</transition>
<transition>
<source ref="id17"/>
<target ref="id7"/>
<label kind="guard" x="-714" y="51">retry &gt; 1</label>
<label kind="assignment" x="-714" y="68">retry--</label>
<nail x="-620" y="59"/>
</transition>
<transition>
<source ref="id7"/>
<target ref="id17"/>
<label kind="synchronisation" x="-663" y="-59">glass_pickup?</label>
<label kind="assignment" x="-688" y="-34">successful = false</label>
</transition>
<transition>
<source ref="id16"/>
<target ref="id15"/>
<label kind="guard" x="-68" y="-136">retry == 1</label>
<nail x="306" y="-119"/>
</transition>
<transition>
<source ref="id16"/>
<target ref="id8"/>
<label kind="guard" x="-85" y="-93">retry &gt; 1</label>
<label kind="assignment" x="-85" y="-68">retry--</label>
<nail x="-85" y="-68"/>
</transition>
<transition>
<source ref="id8"/>
<target ref="id16"/>
<label kind="synchronisation" x="-297" y="-119">bottle_place?</label>
<label kind="assignment" x="-340" y="-102">successful = false</label>
<nail x="-229" y="-68"/>
</transition>
<transition>
<source ref="id14"/>
<target ref="id15"/>
<label kind="guard" x="-322" y="-399">retry == 1</label>
</transition>
<transition>
<source ref="id14"/>
<target ref="id1"/>
<label kind="guard" x="-280" y="-331">retry &gt; 1</label>
<label kind="assignment" x="-272" y="-314">retry--</label>
<nail x="-255" y="-280"/>
</transition>
<transition>
<source ref="id1"/>
<target ref="id14"/>
<label kind="synchronisation" x="-450" y="-314">bottle_pickup?</label>
<label kind="assignment" x="-459" y="-297">successful = false</label>
</transition>
<transition>
<source ref="id12"/>
<target ref="id13"/>
<label kind="synchronisation" x="51" y="93">move_to_start_pos?</label>
</transition>
<transition>
<source ref="id11"/>
<target ref="id12"/>
<label kind="synchronisation" x="-204" y="85">glass_place_target?</label>
<label kind="assignment" x="-204" y="102">successful = true</label>
</transition>
<transition>
<source ref="id10"/>
<target ref="id11"/>
<label kind="synchronisation" x="-467" y="102">move_to_glass_end?</label>
<label kind="assignment" x="-467" y="119">retry = init_retry</label>
</transition>
<transition>
<source ref="id7"/>
<target ref="id10"/>
<label kind="guard" x="-510" y="76">glass_retry &gt; 1</label>
<label kind="synchronisation" x="-510" y="42">glass_pickup?</label>
<label kind="assignment" x="-510" y="59">successful = true, orient_constraint_set = true</label>
</transition>
<transition>
<source ref="id8"/>
<target ref="id6"/>
<label kind="synchronisation" x="-280" y="-17">bottle_place?</label>
<label kind="assignment" x="-408" y="0">successful = true, retry = init_retry, orient_constraint_set = false</label>
</transition>
<transition>
<source ref="id9"/>
<target ref="id1"/>
<label kind="synchronisation" x="-501" y="-204">move_to_bottle_pos?</label>
</transition>
<transition>
<source ref="id6"/>
<target ref="id7"/>
<label kind="synchronisation" x="-501" y="-68">move_to_glass_start?</label>
<label kind="assignment" x="-510" y="-51">glass_retry = init_retry</label>
</transition>
<transition>
<source ref="id5"/>
<target ref="id8"/>
<label kind="synchronisation" x="-136" y="-34">move_to_bottle_pos?</label>
</transition>
<transition>
<source ref="id4"/>
<target ref="id5"/>
<label kind="synchronisation" x="51" y="-34">stop_pour?</label>
<label kind="assignment" x="17" y="-17">orient_constraint_set = true</label>
</transition>
<transition>
<source ref="id3"/>
<target ref="id4"/>
<label kind="synchronisation" x="153" y="-170">start_pour?</label>
<label kind="assignment" x="68" y="-153">orient_constraint_set = false</label>
</transition>
<transition>
<source ref="id2"/>
<target ref="id3"/>
<label kind="synchronisation" x="-68" y="-212">move_to_glass_start?</label>
</transition>
<transition>
<source ref="id1"/>
<target ref="id2"/>
<label kind="synchronisation" x="-280" y="-187">bottle_pickup?</label>
<label kind="assignment" x="-433" y="-170">successful = true, retry = init_retry, orient_constraint_set = true</label>
</transition>
<transition>
<source ref="id0"/>
<target ref="id9"/>
<label kind="select" x="-629" y="-340">i : int[5,10]</label>
<label kind="synchronisation" x="-637" y="-323">pressure_signal?</label>
<label kind="assignment" x="-731" y="-306">init_retry = i, retry = init_retry</label>
</transition>
</template>
<template>
<name>channels</name>
<location id="id22" x="-561" y="-144">
<committed/>
</location>
<init ref="id22"/>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-697" y="-408">move_to_start_pos!</label>
<nail x="-680" y="-391"/>
<nail x="-595" y="-391"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-892" y="-382">glass_place_target!</label>
<nail x="-561" y="-153"/>
<nail x="-807" y="-340"/>
<nail x="-748" y="-365"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-977" y="-297">glass_place_start!</label>
<nail x="-867" y="-255"/>
<nail x="-841" y="-297"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-960" y="-204">glass_pickup!</label>
<nail x="-867" y="-187"/>
<nail x="-858" y="-221"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-943" y="-102">bottle_place!</label>
<nail x="-850" y="-93"/>
<nail x="-850" y="-119"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-884" y="0">bottle_pickup!</label>
<nail x="-782" y="-8"/>
<nail x="-807" y="-34"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-739" y="85">stop_pour!</label>
<nail x="-671" y="59"/>
<nail x="-722" y="25"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-578" y="76">start_pour!</label>
<nail x="-535" y="59"/>
<nail x="-595" y="68"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-425" y="-17">move_to_glass_end!</label>
<nail x="-433" y="0"/>
<nail x="-493" y="42"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-340" y="-93">move_to_glass_start!</label>
<nail x="-340" y="-110"/>
<nail x="-340" y="-51"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-340" y="-221">move_to_bottle_pos!</label>
<nail x="-340" y="-246"/>
<nail x="-331" y="-187"/>
</transition>
<transition>
<source ref="id22"/>
<target ref="id22"/>
<label kind="synchronisation" x="-425" y="-374">pressure_signal!</label>
<nail x="-459" y="-382"/>
<nail x="-391" y="-306"/>
</transition>
</template>
<system>// Place template instantiations here.
// List one or more processes to be composed into a system.
system Cobot, channels;
</system>
<queries>
<query>
<formula>A[] (deadlock imply (Cobot.finished_success or Cobot.shut_down))</formula>
<comment></comment>
</query>
<query>
<formula>A[] ((Cobot.finished_success or Cobot.shut_down) imply deadlock)</formula>
<comment></comment>
</query>
<query>
<formula>A&lt;&gt; (Cobot.finished_success or Cobot.shut_down)</formula>
<comment></comment>
</query>
</queries>
</nta>
images/cobot1_v1.png 0 → 100644
+ 0
− 0
View file @ 6bfb92f5
images/cobot1_v1.png

291 KiB

sections/ausfuehrung.tex
+ 24
− 2
View file @ 6bfb92f5
\chapter{Ausführung} \chapter{Ausführung}
\section{Integration mit actionlib} \section{Integration mit actionlib}
Das hier verwendete Szenario entspricht einem Garagen-Tor, welches präemptiert werden kann. Der implementierte Action-Server nimmt einen Boolean entgegen, der festlegt, ob das Tor geöffnet oder geschlossen werden soll, und gibt dann zufällig Feedback in Form eines Integers zurück, welcher die aktuelle Position des Tores repräsentiert. Dabei steht der Wert 0 für ein geschlossenes sowie 1000 für ein offenes Tor. Nach Abschluss des aktuellen Vorgangs wird der Status zurück zum Client übertragen. Dieser kann jedoch auch während der Ausführung das Wechseln des Ziels anfragen, woraufhin der Server das alte Ziel verwirft.\\ Das hier verwendete Szenario entspricht einer etwas erweiterten Version des in \cref{konzept:uppaal_tor} verwendeten Beispiels, einem Garagen-Tor, welches präemptiert werden kann. Der implementierte Action-Server nimmt einen Boolean entgegen, der festlegt, ob das Tor geöffnet oder geschlossen werden soll, und gibt dann zufällig Feedback in Form eines Integers zurück, welcher die aktuelle Position des Tores repräsentiert. Dabei steht der Wert 0 für ein geschlossenes sowie 1000 für ein offenes Tor. Nach Abschluss des aktuellen Vorgangs wird der Status zurück zum Client übertragen. Dieser kann jedoch auch während der Ausführung das Wechseln des Ziels anfragen, woraufhin der Server das alte Ziel verwirft.\\
Das entsprechend erstellte Uppaal-Modell ist in \cref{integration:uppaal} zu sehen. Auffällig dabei sind Kanten denen die Channel \textit{fertig} und \textit{position} zugewiesen sind. Bei diesen wird vom System die aktuelle Position übermittelt. Dazu wird eine zufällige Zahl zwischen 0 und 1000 ausgewählt und zur Position addiert beziehungsweise subtrahiert. Außerdem wird garantiert, dass die Grenzen des Wertebereiches nicht überschritten werden. Das entsprechend erstellte Uppaal-Modell ist in \cref{integration:uppaal} zu sehen. Auffällig dabei sind Kanten denen die Channel \textit{fertig} und \textit{position} zugewiesen sind. Bei diesen wird vom System die aktuelle Position übermittelt. Dazu wird eine zufällige Zahl zwischen 0 und 1000 ausgewählt und zur Position addiert beziehungsweise subtrahiert. Außerdem wird garantiert, dass die Grenzen des Wertebereiches nicht überschritten werden.
\begin{figure}[h] \begin{figure}[h]
\centering \centering
...@@ -40,4 +40,26 @@ Die hier verwendeten Callbacks \textit{send\_goal\_open(/close)} rufen die Funkt ...@@ -40,4 +40,26 @@ Die hier verwendeten Callbacks \textit{send\_goal\_open(/close)} rufen die Funkt
} }
\end{lstlisting} \end{lstlisting}
Es lässt sich hinzufügen, dass beim Versenden eines Ziels (oder einer sonstigen Nachricht) vom (hier emulierten) Client keine Felder im Header wie zum Beispiel die Identifikationsnummer dieses Zieles gesetzt werden müssen, da der Server diese beim Empfangen der Nachricht entsprechend ausfüllt, sollten sie leer sein. Die Identifikationsnummer ist für den Client wichtig, um einen bestimmten Auftrag abzubrechen und sollte folglich in diesem Fall von ihm gesetzt werden. Die Funktion \textit{feedback\_callback} gibt lediglich die aktuelle Position an TRON weiter. Da im Uppaal-Modell keine Angaben zur Zeit vorhanden sind, kann die Zeiteinheit in diesem Fall frei gewählt werden. Der Test-Timeout sollte so gewählt sein, dass mehrere Zyklen durchlaufen werden können und ist daher abhängig von der Zeit, die der Server zum Bewältigen der Aufgabe benötigt. Es lässt sich hinzufügen, dass beim Versenden eines Ziels (oder einer sonstigen Nachricht) vom (hier emulierten) Client keine Felder im Header wie zum Beispiel die Identifikationsnummer dieses Zieles gesetzt werden müssen, da der Server diese beim Empfangen der Nachricht entsprechend ausfüllt, sollten sie leer sein. Die Identifikationsnummer ist für den Client wichtig, um einen bestimmten Auftrag abzubrechen und sollte folglich in diesem Fall von ihm gesetzt werden. Die Funktion \textit{feedback\_callback} gibt lediglich die aktuelle Position an TRON weiter. Da im Uppaal-Modell keine Angaben zur Zeit vorhanden sind, kann die Zeiteinheit in diesem Fall frei gewählt werden. Der Test-Timeout sollte so gewählt sein, dass mehrere Zyklen durchlaufen werden können und ist daher abhängig von der Zeit, die der Server zum Bewältigen der Aufgabe benötigt.
Die vollständige Implementierung des actionlib-Servers und -Clients sowie des verwendeten TRON-Adapters sind in einem Git-Repository vorhanden (siehe Anhang). Die vollständige Implementierung des actionlib-Servers und -Clients sowie des verwendeten TRON-Adapters sind in einem Git-Repository vorhanden (siehe Anhang).
\ No newline at end of file
\section{Cobot}
Mit der Möglichkeit zur Verwendung der actionlib kann nun ein tatsächliches Testszenario angegangen werden. Dazu wird zunächst die Aufgabe des Systems überprüft und formale Bedingungen zur Ausführung festgehalten. Dabei wurde der Cobot mehrfach simuliert sowie der Code der Implementierung überflogen, um einen Eindruck vom Systemverhalten zu bekommen.
\subsection{Formales Modell}
Als erstes lässt sich feststellen, dass der Cobot wartet bis er ein Signal von einem Drucksensor erhält woraufhin er zu arbeiten beginnt. Nach diesem Signal bewirken weitere Eingaben nichts, wodurch das System als Sequenz modelliert werden kann.
Am Anfang wird eine Anzahl an Versuchen festgelegt, die der Roboter beim Aufheben und Hinstellen von Objekten durchführt, bevor die Ausführung als fehlgeschlagen gilt und das System herunterfährt. Dann bewegt sich der Roboter zur Flasche (wie das Glas in der Simulation als Block dargestellt) und hebt diese auf. Dabei ist wichtig, dass nach dem Aufnehmen die Flasche in einem aufrechten Zustand gehalten wird, um ein Verschütten der (in Simulation nicht vorhandenen) Flüssigkeit zu verhindern. Dann bewegt der Roboter die Flasche neben das Glas und beginnt sie in Richtung des Glases zu kippen. Dabei wird die Beschränkung der Orientierung temporär aufgehoben, bis das Wiederaufrichten durchgeführt wurde und die Flasche wieder an ihre ursprüngliche Position gebracht werden kann. Nach dem Abstellen der Flasche wird das Glas angehoben. Der Weg zum Glas unterliegt wieder keinerlei Beschränkungen, während bei angehobenem Glas dieses aufrecht gehalten werden muss, bis es auf der anderen Seite abgestellt wurde, woraufhin sich der Roboterarm wieder in seine Startposition begibt. Beim Abstellen ist ein zusätzlicher Fallback integriert, der dafür sorgt, dass beim Fehlschlagen des Platzierens am Ziel das Glas wieder an seine Ursprungsposition gebracht und neu aufgehoben wird. Dies geschieht wie die einzelnen Versuche auch so oft wie am Anfang festgelegt. Dabei wird im Modell keine Aktualisierung der Orientierungsbeschränkung vorgenommen, da diese nach dem Abstellen zwar entfernt, aber durch das sofortige Wiederaufheben unmittelbar wieder hinzugefügt wird.
Das aus diesen Angaben erstellte Modell ist in \cref{cobot:formales_modell} dargestellt.\\
\begin{figure}[h]
\centering
\includegraphics[scale=.2]{./cobot1_v1.png}
\caption{Formales Modell des Cobots}
\label{cobot:formales_modell}
\end{figure}
Zu Überprüfen ist neben der Reihenfolge der Ausführung auch die Qualität dieser. Zum einen sind die tatsächlichen Positionen von Glas und Flasche relevant, zum anderen müssen die Beschränkungen beim Bewegen der gefüllten Behältnisse abgeglichen werden. Die am Anfang der Systemausführung übergebene Anzahl an Versuchen zum Platzieren oder Aufheben ist in diesem Modell zwischen (einschließlich) 5 und 10 festgelegt, kann aber beliebig angepasst werden.
Zeitliche Anforderungen an das System sind nicht gegeben, es ist jedoch wichtig dass das System terminiert, auch wenn die Ausführung nicht erfolgreich stattfindet und daher Heruntergefahren wird. Aus diesem Grund kann bereits jetzt eine Verifizierung dieses Modells stattfinden.
Der Uppaal Verifier kann mit der Anfrage \textit{A<> deadlock} (jeder Pfad führt zu einem Deadlock (= terminiert)) nicht umgehen. Daher werden 3 Anfragen verwendet, die diesem Zusammenhang entsprechen:
\begin{enumerate}
\item A[] (deadlock imply (Cobot.finished\_success or Cobot.shut\_down))
\item A[] ((Cobot.finished\_success or Cobot.shut\_down) imply deadlock)
\item A<> (Cobot.finished\_success or Cobot.shut\_down)
\end{enumerate}
1. bedeutet dass wenn ein Deadlock auftritt sich der Cobot immer im Zustand \textit{finished\_success} oder \textit{shut\_down} befindet. 2. kehrt diese Aussage um und sorgt so zusammen mit 1. für einen genau-dann-wenn Zusammenhang zwischen einem Deadlock und den besagten Zuständen. Schließlich wird mit 3. abgefragt, ob jeder Pfad (nach endlicher Zeit) zu \textit{finished\_success} oder \textit{shut\_down} führt. Diese Anfragen werden alle als wahr ausgewertet, wodurch klar ist, dass das Modell immer terminiert.
\ No newline at end of file
sections/konzept.tex
+ 4
− 1
View file @ 6bfb92f5
...@@ -67,4 +67,7 @@ Diese Variante wird auch bei einer später im Text folgenden beispielhaften Anwe ...@@ -67,4 +67,7 @@ Diese Variante wird auch bei einer später im Text folgenden beispielhaften Anwe
\section{actionlib}\label{konzept:actionlib} \section{actionlib}\label{konzept:actionlib}
Die actionlib \cite{Actionlib} baut ein Protokoll auf den Nachrichten von ROS auf und ermöglicht Kommunikation von Nodes für das Ausführen einer bestimmten Aufgabe mithilfe einer Client-Server-Architektur. Diese unterscheidet sich von den \textit{ROS Services}\footnote{\url{http://wiki.ros.org/Services}} insbesondere durch die ermöglichte Asynchronität, welche für konstante Rückmeldung des Servers sowie weitere Anfragen des Clients (wie etwa nach der Präemptierung einer Aktion) genutzt wird. Die actionlib \cite{Actionlib} baut ein Protokoll auf den Nachrichten von ROS auf und ermöglicht Kommunikation von Nodes für das Ausführen einer bestimmten Aufgabe mithilfe einer Client-Server-Architektur. Diese unterscheidet sich von den \textit{ROS Services}\footnote{\url{http://wiki.ros.org/Services}} insbesondere durch die ermöglichte Asynchronität, welche für konstante Rückmeldung des Servers sowie weitere Anfragen des Clients (wie etwa nach der Präemptierung einer Aktion) genutzt wird.
Dazu wurde die Implementierung eines endlichen Automaten realisiert, was sich neben den verwendeten ROS-Nachrichten für das Testen mittels TRON anbietet. Daher wird im Folgenden die Möglichkeit einer Integration des Testadapters in ein System, welches die actionlib verwendet, beispielhaft überprüft. Dazu wurde die Implementierung eines endlichen Automaten realisiert, was sich neben den verwendeten ROS-Nachrichten für das Testen mittels TRON anbietet. Daher wird die Möglichkeit einer Integration des Testadapters in ein System, welches die actionlib verwendet, beispielhaft überprüft.
\ No newline at end of file
\section{Cobot}
Das am Lehrstuhl verwendete Cobot-Projekt\footnote{\url{https://git-st.inf.tu-dresden.de/ceti/ros-internal/chemistry-lab-demo/cobot_1/-/tree/feature/cobot-homestate-version}} wird benutzt, um den Testvorgang mittels des hier vorgestellten Konzeptes zu evaluieren. Der Roboter (Franka Panda\footnote{\url{https://www.franka.de/robot-system}}) soll eine Flasche aufheben, um damit ein Glas zu befüllen. Folglich wird die Flasche wieder an ihre Anfangsposition gebracht und das nun befüllte Glas auf die andere Seite des Roboters transportiert.
\ No newline at end of file
sections/stateoftheart.tex
+ 3
− 0
View file @ 6bfb92f5
...@@ -17,3 +17,6 @@ Invarianten können global oder nur in bestimmten Zuständen angegeben werden. \ ...@@ -17,3 +17,6 @@ Invarianten können global oder nur in bestimmten Zuständen angegeben werden. \
Channels, welche sowohl im modellierten Input als auch im System vorkommen stellen die Schnittstellen für den Adapter dar. Wird im Inputmodell ein Channel verwendet, so wird dieser sowohl im modellierten als auch im echten (oder simulierten) System über den Adapter ausgelöst. Asynchron dazu gibt das System den Output zurück an den Adapter, welcher dann mit den Gegebenheiten des Modells verglichen wird. Als built-in Adapter sind der sogenannte TraceAdapter, welcher über stdin/stdout (Standard-Pipes von Linux) kommuniziert, und der SocketAdapter, welcher zur Kommunikation eine TCP/IP-Verbindung aufbaut, verfügbar. Auch eigene Implementationen werden als dynamische C-Bibliothek ermöglicht. Für ROS bietet sich der SocketAdapter an, da die ROS-interne Kommunikation selbst auf TCP aufsetzt und so auch Übertragbarkeit gewährleistet wird. Channels, welche sowohl im modellierten Input als auch im System vorkommen stellen die Schnittstellen für den Adapter dar. Wird im Inputmodell ein Channel verwendet, so wird dieser sowohl im modellierten als auch im echten (oder simulierten) System über den Adapter ausgelöst. Asynchron dazu gibt das System den Output zurück an den Adapter, welcher dann mit den Gegebenheiten des Modells verglichen wird. Als built-in Adapter sind der sogenannte TraceAdapter, welcher über stdin/stdout (Standard-Pipes von Linux) kommuniziert, und der SocketAdapter, welcher zur Kommunikation eine TCP/IP-Verbindung aufbaut, verfügbar. Auch eigene Implementationen werden als dynamische C-Bibliothek ermöglicht. Für ROS bietet sich der SocketAdapter an, da die ROS-interne Kommunikation selbst auf TCP aufsetzt und so auch Übertragbarkeit gewährleistet wird.
\section{GraphWalker?} \section{GraphWalker?}
\url{http://graphwalker.github.io/} \url{http://graphwalker.github.io/}
\section{MATE}
Das Model-based Adaptivity Test Environment\footnote{\url{http://81.88.24.184/qmate/}} (MATE) wurde unter anderem in \cite{Pueschel2018} vorgestellt und unterstützt verschiedene Arten von Modellen, sodass sich Systeme möglichst optimal darstellen lassen. Abhängig vom genutzten Modell sind Editoren vorhanden, die das Erstellen vereinfachen. Auch hier kann vor dem Testen eine Verifizierung der erarbeiteten Darstellung stattfinden. Es wird online und offline-Testing ermöglicht, statistische Analysen der Testergebnisse werden automatisch (bei offline-Tests) durchgeführt. Zur Ausführung der Tests lassen sich benutzerdefinierte Adapter einrichten, sodass MATE unabhängig von der vom System verwendeten Technologie angewandt werden kann. Außerdem ist das Tool auf Erweiterbarkeit ausgelegt, das heißt es existiert beispielsweise ein Framework, mit welchem eigene Modelltypen implementiert werden können (solange diese einem Metamodell-Interface folgen). Insgesamt ist MATE ein mächtiges und breit einsetzbares Tool für Modell-basiertes Testen, es ist jedoch momentan nicht verfügbar und kann daher im Rahmen dieser Arbeit nicht verwendet werden.
\ No newline at end of file
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment