diff --git a/cobot1.xml b/cobot1.xml
index 6eedb6d43a7e6ea010c7c0db85eb28fc1dc4a5cb..abd6c944767ea3c6848101290fa67538d3460c47 100644
--- a/cobot1.xml
+++ b/cobot1.xml
@@ -12,10 +12,40 @@ chan place_fail, place_success;
 chan move_fail, move_success;
 chan goal;
 chan position_update;
+
 chan test_done;
-int bottle_in_start_pos = 1;
-int glass_in_start_pos = 1;
-int glass_in_target_pos = 0;</declaration>
+chan intentional_fail;
+urgent chan asap;
+
+const int max_pos_diff = 1000;
+const int max_ang_diff = 180;
+int bottle_diff_to_start_pos;
+int bottle_diff_to_start_ang;
+int bottle_diff_to_target_pos;
+int bottle_diff_to_target_ang;
+int glass_diff_to_start_pos;
+int glass_diff_to_start_ang;
+int glass_diff_to_target_pos;
+int glass_diff_to_target_ang;
+chan bottle_diff_to_start_pos_update;
+chan bottle_diff_to_start_ang_update;
+chan bottle_diff_to_target_pos_update;
+chan bottle_diff_to_target_ang_update;
+chan glass_diff_to_start_pos_update;
+chan glass_diff_to_start_ang_update;
+chan glass_diff_to_target_pos_update;
+chan glass_diff_to_target_ang_update;
+
+const int bottle_start_pos_tolerance = 5;
+const int bottle_target_pos_tolerance = 5;
+const int glass_start_pos_tolerance = 5;
+const int glass_target_pos_tolerance = 5;
+
+bool bottle_in_start_pos = true;
+bool bottle_in_target_pos = false;
+bool glass_in_start_pos = true;
+bool glass_in_target_pos = false;
+</declaration>
 	<template>
 		<name>place</name>
 		<location id="id0" x="0" y="0">
@@ -37,99 +67,105 @@ int glass_in_target_pos = 0;</declaration>
 		</transition>
 	</template>
 	<template>
-		<name>model_positions</name>
-		<location id="id1" x="-1547" y="-416">
-			<name x="-1598" y="-445">start_pos</name>
+		<name>bottle_position</name>
+		<location id="id1" x="-1853" y="-1054">
+			<name x="-1938" y="-1071">start_pos</name>
 		</location>
-		<location id="id2" x="-1343" y="-416">
-			<name x="-1326" y="-425">bottle_moving</name>
+		<location id="id2" x="-1487" y="-1343">
+			<name x="-1504" y="-1377">moving</name>
 		</location>
-		<location id="id3" x="-1343" y="-297">
-			<name x="-1326" y="-323">bottle_end_pos</name>
-		</location>
-		<location id="id4" x="-1343" y="-187">
-			<name x="-1454" y="-178">glass_moving</name>
-		</location>
-		<location id="id5" x="-1079" y="-187">
-			<name x="-1173" y="-170">bottle_and_glass_end_pos</name>
-		</location>
-		<location id="id6" x="-850" y="17">
-		</location>
-		<location id="id7" x="-850" y="-323">
+		<location id="id3" x="-1130" y="-1054">
+			<name x="-1113" y="-1071">target_pos</name>
 		</location>
 		<init ref="id1"/>
 		<transition>
-			<source ref="id7"/>
-			<target ref="id5"/>
-			<label kind="synchronisation" x="-1062" y="-357">position_update?</label>
-			<label kind="assignment" x="-1062" y="-340">glass_in_target_pos = 1</label>
-			<nail x="-1079" y="-323"/>
+			<source ref="id2"/>
+			<target ref="id1"/>
+			<label kind="guard" x="-1904" y="-1045">bottle_diff_to_start_pos &lt;= bottle_start_pos_tolerance
+&amp;&amp; bottle_diff_to_target_pos &gt; bottle_target_pos_tolerance</label>
+			<label kind="synchronisation" x="-1700" y="-1011">asap!</label>
+			<label kind="assignment" x="-1776" y="-994">bottle_in_start_pos = true</label>
+			<nail x="-1538" y="-1054"/>
 		</transition>
 		<transition>
-			<source ref="id4"/>
-			<target ref="id6"/>
-			<label kind="synchronisation" x="-1275" y="-102">position_update?</label>
-			<label kind="assignment" x="-1283" y="-85">glass_in_start_pos = 1</label>
+			<source ref="id3"/>
+			<target ref="id2"/>
+			<label kind="guard" x="-1428" y="-1045">bottle_diff_to_start_pos &gt; bottle_start_pos_tolerance
+&amp;&amp; bottle_diff_to_target_pos &gt; bottle_target_pos_tolerance</label>
+			<label kind="synchronisation" x="-1292" y="-1011">asap!</label>
+			<label kind="assignment" x="-1368" y="-994">bottle_in_target_pos = false</label>
+			<nail x="-1436" y="-1054"/>
 		</transition>
 		<transition>
-			<source ref="id5"/>
-			<target ref="id7"/>
-			<label kind="synchronisation" x="-1003" y="-238">position_update?</label>
-			<label kind="assignment" x="-1037" y="-221">glass_in_target_pos = 0</label>
+			<source ref="id2"/>
+			<target ref="id3"/>
+			<label kind="guard" x="-1377" y="-1266">bottle_diff_to_target_pos &lt;= bottle_target_pos_tolerance</label>
+			<label kind="synchronisation" x="-1317" y="-1249">asap!</label>
+			<label kind="assignment" x="-1326" y="-1232">bottle_in_target_pos = true</label>
 		</transition>
 		<transition>
-			<source ref="id3"/>
+			<source ref="id1"/>
 			<target ref="id2"/>
-			<label kind="synchronisation" x="-1572" y="-365">position_update?</label>
-			<label kind="assignment" x="-1572" y="-348">bottle_in_start_pos = 0</label>
-			<nail x="-1411" y="-348"/>
+			<label kind="guard" x="-1989" y="-1309">bottle_diff_to_start_pos &gt; bottle_start_pos_tolerance
+&amp;&amp; bottle_diff_to_target_pos &gt; bottle_target_pos_tolerance</label>
+			<label kind="synchronisation" x="-1768" y="-1275">asap!</label>
+			<label kind="assignment" x="-1836" y="-1258">bottle_in_start_pos = false</label>
 		</transition>
+	</template>
+	<template>
+		<name>glass_position</name>
+		<location id="id4" x="-697" y="-246">
+			<name x="-782" y="-255">start_pos</name>
+		</location>
+		<location id="id5" x="-331" y="-510">
+			<name x="-348" y="-552">moving</name>
+		</location>
+		<location id="id6" x="59" y="-246">
+			<name x="76" y="-272">end_pos</name>
+		</location>
+		<init ref="id4"/>
 		<transition>
-			<source ref="id6"/>
+			<source ref="id5"/>
 			<target ref="id4"/>
-			<label kind="synchronisation" x="-1470" y="-51">position_update?</label>
-			<label kind="assignment" x="-1504" y="-34">glass_in_start_pos = 0</label>
-			<nail x="-1343" y="8"/>
+			<label kind="guard" x="-731" y="-238">glass_diff_to_start_pos &lt;= glass_start_pos_tolerance
+&amp;&amp; glass_diff_to_target_pos &gt; glass_target_pos_tolerance</label>
+			<label kind="synchronisation" x="-510" y="-204">asap!</label>
+			<label kind="assignment" x="-561" y="-187">glass_in_start_pos = true</label>
+			<nail x="-348" y="-246"/>
 		</transition>
 		<transition>
-			<source ref="id7"/>
-			<target ref="id6"/>
-			<label kind="synchronisation" x="-841" y="-212">position_update?</label>
-			<label kind="assignment" x="-841" y="-195">glass_in_start_pos = 1</label>
+			<source ref="id6"/>
+			<target ref="id5"/>
+			<label kind="guard" x="-297" y="-238">glass_diff_to_start_pos &gt; glass_start_pos_tolerance
+&amp;&amp; glass_diff_to_target_pos &gt; glass_target_pos_tolerance</label>
+			<label kind="synchronisation" x="-178" y="-204">asap!</label>
+			<label kind="assignment" x="-255" y="-187">glass_in_target_pos = false</label>
+			<nail x="-306" y="-246"/>
 		</transition>
 		<transition>
 			<source ref="id4"/>
 			<target ref="id5"/>
-			<label kind="synchronisation" x="-1309" y="-221">position_update?</label>
-			<label kind="assignment" x="-1309" y="-204">glass_in_target_pos = 1</label>
-		</transition>
-		<transition>
-			<source ref="id3"/>
-			<target ref="id4"/>
-			<label kind="synchronisation" x="-1504" y="-263">position_update?</label>
-			<label kind="assignment" x="-1504" y="-246">glass_in_start_pos = 0</label>
+			<label kind="guard" x="-816" y="-484">glass_diff_to_start_pos &gt; glass_start_pos_tolerance
+&amp;&amp; glass_diff_to_target_pos &gt; glass_target_pos_tolerance</label>
+			<label kind="synchronisation" x="-629" y="-450">asap!</label>
+			<label kind="assignment" x="-697" y="-433">glass_in_start_pos = false</label>
 		</transition>
 		<transition>
-			<source ref="id2"/>
-			<target ref="id3"/>
-			<label kind="synchronisation" x="-1334" y="-391">position_update?</label>
-			<label kind="assignment" x="-1334" y="-374">bottle_in_start_pos = 1</label>
-		</transition>
-		<transition>
-			<source ref="id1"/>
-			<target ref="id2"/>
-			<label kind="synchronisation" x="-1479" y="-459">position_update?</label>
-			<label kind="assignment" x="-1513" y="-442">bottle_in_start_pos = 0</label>
+			<source ref="id5"/>
+			<target ref="id6"/>
+			<label kind="guard" x="-263" y="-476">glass_diff_to_target_pos &lt;= glass_target_pos_tolerance</label>
+			<label kind="synchronisation" x="-136" y="-459">asap!</label>
+			<label kind="assignment" x="-212" y="-442">glass_in_target_pos = true</label>
 		</transition>
 	</template>
 	<template>
 		<name>goal_</name>
-		<location id="id8" x="0" y="0">
+		<location id="id7" x="0" y="0">
 		</location>
-		<init ref="id8"/>
+		<init ref="id7"/>
 		<transition>
-			<source ref="id8"/>
-			<target ref="id8"/>
+			<source ref="id7"/>
+			<target ref="id7"/>
 			<label kind="synchronisation" x="-42" y="-51">goal!</label>
 			<nail x="-25" y="-34"/>
 			<nail x="25" y="-34"/>
@@ -137,32 +173,32 @@ int glass_in_target_pos = 0;</declaration>
 	</template>
 	<template>
 		<name>press</name>
-		<location id="id9" x="-3153" y="-3026">
+		<location id="id8" x="-3153" y="-3026">
 		</location>
-		<location id="id10" x="-3026" y="-3026">
+		<location id="id9" x="-3026" y="-3026">
 		</location>
-		<init ref="id9"/>
+		<init ref="id8"/>
 		<transition>
-			<source ref="id9"/>
-			<target ref="id10"/>
+			<source ref="id8"/>
+			<target ref="id9"/>
 			<label kind="synchronisation" x="-3119" y="-3043">pressed!</label>
 		</transition>
 	</template>
 	<template>
 		<name>move</name>
-		<location id="id11" x="-612" y="-68">
+		<location id="id10" x="-612" y="-68">
 		</location>
-		<init ref="id11"/>
+		<init ref="id10"/>
 		<transition>
-			<source ref="id11"/>
-			<target ref="id11"/>
+			<source ref="id10"/>
+			<target ref="id10"/>
 			<label kind="synchronisation" x="-646" y="-25">move_fail!</label>
 			<nail x="-629" y="-34"/>
 			<nail x="-595" y="-34"/>
 		</transition>
 		<transition>
-			<source ref="id11"/>
-			<target ref="id11"/>
+			<source ref="id10"/>
+			<target ref="id10"/>
 			<label kind="synchronisation" x="-663" y="-119">move_success!</label>
 			<nail x="-629" y="-102"/>
 			<nail x="-595" y="-102"/>
@@ -170,24 +206,37 @@ int glass_in_target_pos = 0;</declaration>
 	</template>
 	<template>
 		<name>pickup</name>
-		<location id="id12" x="0" y="0">
+		<location id="id11" x="0" y="0">
 		</location>
-		<init ref="id12"/>
+		<init ref="id11"/>
 		<transition>
-			<source ref="id12"/>
-			<target ref="id12"/>
+			<source ref="id11"/>
+			<target ref="id11"/>
 			<label kind="synchronisation" x="-34" y="34">pickup_fail!</label>
 			<nail x="-17" y="34"/>
 			<nail x="17" y="34"/>
 		</transition>
 		<transition>
-			<source ref="id12"/>
-			<target ref="id12"/>
+			<source ref="id11"/>
+			<target ref="id11"/>
 			<label kind="synchronisation" x="-42" y="-51">pickup_success!</label>
 			<nail x="-17" y="-34"/>
 			<nail x="17" y="-34"/>
 		</transition>
 	</template>
+	<template>
+		<name>asapcatcher</name>
+		<location id="id12" x="-272" y="-119">
+		</location>
+		<init ref="id12"/>
+		<transition>
+			<source ref="id12"/>
+			<target ref="id12"/>
+			<label kind="synchronisation" x="-289" y="-187">asap?</label>
+			<nail x="-306" y="-161"/>
+			<nail x="-238" y="-161"/>
+		</transition>
+	</template>
 	<template>
 		<name x="5" y="5">Cobot</name>
 		<declaration>// Place local declarations here.</declaration>
@@ -198,23 +247,22 @@ int glass_in_target_pos = 0;</declaration>
 		</location>
 		<location id="id15" x="578" y="-119">
 			<name x="535" y="-110">moving_to_glass</name>
-			<label kind="invariant" x="467" y="-93">bottle_in_start_pos == false</label>
+			<label kind="invariant" x="484" y="-93">bottle_in_start_pos == false</label>
 		</location>
-		<location id="id16" x="773" y="-8">
-			<name x="679" y="1">start_pour</name>
+		<location id="id16" x="773" y="-59">
+			<name x="680" y="-68">start_pour</name>
 		</location>
-		<location id="id17" x="1003" y="-263">
-			<name x="960" y="-297">shut_down</name>
+		<location id="id17" x="833" y="-263">
+			<name x="790" y="-297">shut_down</name>
 		</location>
-		<location id="id18" x="773" y="110">
-			<name x="688" y="102">stop_pour</name>
+		<location id="id18" x="773" y="76">
+			<name x="748" y="85">stop_pour</name>
 		</location>
 		<location id="id19" x="357" y="76">
 			<name x="246" y="51">placing_bottle</name>
 		</location>
 		<location id="id20" x="-246" y="76">
-			<name x="-374" y="34">picking_glass</name>
-			<label kind="invariant" x="-459" y="51">bottle_in_start_pos == true</label>
+			<name x="-382" y="42">picking_glass</name>
 		</location>
 		<location id="id21" x="314" y="365">
 			<name x="246" y="374">placing_glass_target</name>
@@ -226,26 +274,27 @@ int glass_in_target_pos = 0;</declaration>
 			<name x="314" y="569">goto_last_state</name>
 		</location>
 		<location id="id24" x="1113" y="612">
-			<name x="892" y="629">goto_last_state_before_shut_down</name>
+			<name x="884" y="629">goto_last_state_before_shut_down</name>
 		</location>
 		<location id="id25" x="977" y="365">
 			<name x="918" y="331">move_to_start_pos</name>
 		</location>
-		<location id="id26" x="977" y="527">
-			<name x="841" y="518">finished_success</name>
+		<location id="id26" x="977" y="544">
+			<name x="841" y="535">finished_success</name>
 		</location>
 		<location id="id27" x="365" y="-119">
 			<name x="323" y="-102">bottle_picked</name>
 		</location>
 		<location id="id28" x="773" y="-119">
-			<name x="773" y="-153">moved_to_glass</name>
+			<name x="790" y="-136">moved_to_glass</name>
 		</location>
 		<location id="id29" x="-59" y="365">
 			<name x="-127" y="374">glass_picked</name>
+			<label kind="invariant" x="-144" y="391">glass_in_start_pos == false</label>
 		</location>
 		<location id="id30" x="671" y="365">
 			<name x="603" y="331">glass_placed_target</name>
-			<label kind="invariant" x="595" y="382">glass_in_target_pos == true</label>
+			<label kind="invariant" x="586" y="382">glass_in_target_pos == true</label>
 		</location>
 		<location id="id31" x="-246" y="408">
 			<name x="-391" y="399">glass_placed_start</name>
@@ -261,24 +310,53 @@ int glass_in_target_pos = 0;</declaration>
 		<location id="id35" x="-127" y="-221">
 		</location>
 		<location id="id36" x="535" y="76">
-			<name x="535" y="85">pouring_done</name>
+			<name x="552" y="76">pouring_done</name>
+			<label kind="invariant" x="527" y="93">glass_in_start_pos == true</label>
 		</location>
 		<location id="id37" x="-25" y="76">
-			<name x="-17" y="51">bottle_placed</name>
+			<name x="-17" y="25">bottle_placed</name>
+			<label kind="invariant" x="-17" y="42">bottle_in_target_pos == true</label>
 		</location>
-		<location id="id38" x="977" y="459">
-			<name x="875" y="450">in_start_pos</name>
+		<location id="id38" x="977" y="433">
+			<name x="994" y="424">in_start_pos</name>
+			<label kind="invariant" x="731" y="407">glass_in_target_pos == true 
+&amp;&amp; bottle_in_target_pos == true</label>
 		</location>
 		<location id="id39" x="663" y="612">
 			<name x="578" y="629">steping_back_start</name>
 		</location>
 		<location id="id40" x="1062" y="-187">
 		</location>
+		<location id="id41" x="1062" y="-238">
+			<committed/>
+		</location>
+		<location id="id42" x="977" y="493">
+			<committed/>
+		</location>
+		<location id="id43" x="773" y="8">
+			<name x="705" y="0">pouring</name>
+		</location>
 		<init ref="id33"/>
+		<transition>
+			<source ref="id43"/>
+			<target ref="id18"/>
+			<label kind="guard" x="782" y="25">bottle_diff_to_start_ang &gt; 110</label>
+			<label kind="synchronisation" x="782" y="42">asap!</label>
+		</transition>
+		<transition>
+			<source ref="id42"/>
+			<target ref="id26"/>
+			<label kind="synchronisation" x="986" y="510">test_done!</label>
+		</transition>
 		<transition>
 			<source ref="id40"/>
+			<target ref="id41"/>
+			<label kind="synchronisation" x="1011" y="-221">asap!</label>
+		</transition>
+		<transition>
+			<source ref="id41"/>
 			<target ref="id17"/>
-			<label kind="synchronisation" x="1028" y="-246">test_done!</label>
+			<label kind="synchronisation" x="952" y="-280">test_done!</label>
 			<nail x="1062" y="-263"/>
 		</transition>
 		<transition>
@@ -288,8 +366,8 @@ int glass_in_target_pos = 0;</declaration>
 		</transition>
 		<transition>
 			<source ref="id38"/>
-			<target ref="id26"/>
-			<label kind="synchronisation" x="892" y="484">test_done!</label>
+			<target ref="id42"/>
+			<label kind="synchronisation" x="986" y="450">asap!</label>
 		</transition>
 		<transition>
 			<source ref="id37"/>
@@ -301,7 +379,7 @@ int glass_in_target_pos = 0;</declaration>
 			<source ref="id36"/>
 			<target ref="id19"/>
 			<label kind="synchronisation" x="433" y="34">goal?</label>
-			<label kind="assignment" x="382" y="51">orient_constraint_set = true</label>
+			<label kind="assignment" x="374" y="51">orient_constraint_set = true</label>
 		</transition>
 		<transition>
 			<source ref="id34"/>
@@ -310,28 +388,21 @@ int glass_in_target_pos = 0;</declaration>
 		<transition>
 			<source ref="id35"/>
 			<target ref="id34"/>
-			<label kind="synchronisation" x="-136" y="-195">move_success?</label>
+			<label kind="synchronisation" x="-59" y="-246">move_success?</label>
 			<nail x="-25" y="-221"/>
 		</transition>
-		<transition>
-			<source ref="id18"/>
-			<target ref="id18"/>
-			<label kind="synchronisation" x="867" y="102">move_fail?</label>
-			<nail x="858" y="84"/>
-			<nail x="858" y="144"/>
-		</transition>
 		<transition>
 			<source ref="id33"/>
 			<target ref="id35"/>
-			<label kind="select" x="-357" y="-280">i : int[1,15]</label>
-			<label kind="synchronisation" x="-357" y="-263">pressed?</label>
-			<label kind="assignment" x="-442" y="-246">init_retry_count = i, retry_count = init_retry_count</label>
+			<label kind="select" x="-357" y="-263">i : int[1,15]</label>
+			<label kind="synchronisation" x="-357" y="-280">pressed?</label>
+			<label kind="assignment" x="-442" y="-246">init_retry_count = i, retry_count = i</label>
 			<nail x="-374" y="-221"/>
 		</transition>
 		<transition>
 			<source ref="id33"/>
 			<target ref="id13"/>
-			<label kind="synchronisation" x="-348" y="-110">move_success?</label>
+			<label kind="synchronisation" x="-348" y="-119">move_success?</label>
 		</transition>
 		<transition>
 			<source ref="id32"/>
@@ -359,8 +430,8 @@ int glass_in_target_pos = 0;</declaration>
 		<transition>
 			<source ref="id28"/>
 			<target ref="id16"/>
-			<label kind="synchronisation" x="773" y="-93">goal?</label>
-			<label kind="assignment" x="773" y="-76">orient_constraint_set = false</label>
+			<label kind="synchronisation" x="782" y="-102">goal?</label>
+			<label kind="assignment" x="782" y="-85">orient_constraint_set = false</label>
 		</transition>
 		<transition>
 			<source ref="id27"/>
@@ -371,8 +442,8 @@ int glass_in_target_pos = 0;</declaration>
 		<transition>
 			<source ref="id25"/>
 			<target ref="id38"/>
-			<label kind="synchronisation" x="867" y="408">move_success?</label>
-			<nail x="977" y="416"/>
+			<label kind="synchronisation" x="977" y="391">move_success?</label>
+			<nail x="977" y="407"/>
 		</transition>
 		<transition>
 			<source ref="id21"/>
@@ -461,8 +532,8 @@ int glass_in_target_pos = 0;</declaration>
 			<source ref="id21"/>
 			<target ref="id21"/>
 			<label kind="synchronisation" x="102" y="314">move_success?</label>
-			<nail x="204" y="348"/>
-			<nail x="220" y="314"/>
+			<nail x="221" y="340"/>
+			<nail x="229" y="323"/>
 		</transition>
 		<transition>
 			<source ref="id20"/>
@@ -483,9 +554,9 @@ int glass_in_target_pos = 0;</declaration>
 		<transition>
 			<source ref="id20"/>
 			<target ref="id20"/>
-			<label kind="guard" x="-425" y="110">retry_count &gt; 1</label>
-			<label kind="synchronisation" x="-399" y="127">pickup_fail?</label>
-			<label kind="assignment" x="-399" y="144">retry_count--</label>
+			<label kind="guard" x="-425" y="119">retry_count &gt; 1</label>
+			<label kind="synchronisation" x="-399" y="136">pickup_fail?</label>
+			<label kind="assignment" x="-399" y="153">retry_count--</label>
 			<nail x="-314" y="119"/>
 			<nail x="-297" y="136"/>
 		</transition>
@@ -507,7 +578,7 @@ int glass_in_target_pos = 0;</declaration>
 			<source ref="id19"/>
 			<target ref="id37"/>
 			<label kind="synchronisation" x="85" y="76">place_success?</label>
-			<label kind="assignment" x="-102" y="93">retry_count = init_retry_count, place_glass_retry = init_retry_count</label>
+			<label kind="assignment" x="-127" y="93">retry_count = init_retry_count, place_glass_retry = init_retry_count</label>
 		</transition>
 		<transition>
 			<source ref="id19"/>
@@ -535,7 +606,7 @@ int glass_in_target_pos = 0;</declaration>
 		<transition>
 			<source ref="id19"/>
 			<target ref="id19"/>
-			<label kind="synchronisation" x="264" y="119">move_fail?</label>
+			<label kind="synchronisation" x="263" y="127">move_fail?</label>
 			<nail x="298" y="110"/>
 			<nail x="349" y="136"/>
 		</transition>
@@ -562,35 +633,20 @@ int glass_in_target_pos = 0;</declaration>
 		</transition>
 		<transition>
 			<source ref="id16"/>
-			<target ref="id18"/>
-			<label kind="synchronisation" x="782" y="42">move_success?</label>
-		</transition>
-		<transition>
-			<source ref="id16"/>
-			<target ref="id16"/>
-			<label kind="synchronisation" x="875" y="-17">move_fail?</label>
-			<nail x="867" y="-42"/>
-			<nail x="867" y="26"/>
+			<target ref="id43"/>
+			<label kind="synchronisation" x="782" y="-34">move_success?</label>
 		</transition>
 		<transition>
 			<source ref="id15"/>
 			<target ref="id28"/>
 			<label kind="synchronisation" x="620" y="-136">move_success?</label>
 		</transition>
-		<transition>
-			<source ref="id15"/>
-			<target ref="id15"/>
-			<label kind="synchronisation" x="629" y="-187">move_fail?</label>
-			<nail x="603" y="-170"/>
-			<nail x="637" y="-144"/>
-		</transition>
 		<transition>
 			<source ref="id14"/>
 			<target ref="id40"/>
-			<label kind="guard" x="450" y="-272">retry_count == 1</label>
-			<label kind="synchronisation" x="450" y="-255">pickup_fail?</label>
-			<nail x="408" y="-272"/>
-			<nail x="858" y="-272"/>
+			<label kind="guard" x="450" y="-229">retry_count == 1</label>
+			<label kind="synchronisation" x="467" y="-212">pickup_fail?</label>
+			<nail x="374" y="-187"/>
 		</transition>
 		<transition>
 			<source ref="id14"/>
@@ -609,19 +665,19 @@ int glass_in_target_pos = 0;</declaration>
 		<transition>
 			<source ref="id13"/>
 			<target ref="id34"/>
-			<label kind="select" x="-170" y="-119">i : int[1,15]</label>
-			<label kind="synchronisation" x="-170" y="-102">pressed?</label>
-			<label kind="assignment" x="-280" y="-85">init_retry_count = i, retry_count = init_retry_count</label>
+			<label kind="select" x="-170" y="-102">i : int[1,15]</label>
+			<label kind="synchronisation" x="-170" y="-119">pressed?</label>
+			<label kind="assignment" x="-246" y="-85">init_retry_count = i, retry_count = i</label>
 		</transition>
 	</template>
 	<template>
 		<name>testdonecatcher</name>
-		<location id="id41" x="0" y="0">
+		<location id="id44" x="0" y="0">
 		</location>
-		<init ref="id41"/>
+		<init ref="id44"/>
 		<transition>
-			<source ref="id41"/>
-			<target ref="id41"/>
+			<source ref="id44"/>
+			<target ref="id44"/>
 			<label kind="synchronisation" x="8" y="-42">test_done?</label>
 			<nail x="59" y="-17"/>
 			<nail x="59" y="17"/>
@@ -629,38 +685,152 @@ int glass_in_target_pos = 0;</declaration>
 	</template>
 	<template>
 		<name>positionupdatecatcher</name>
-		<location id="id42" x="-544" y="-331">
-		</location>
-		<init ref="id42"/>
-		<transition>
-			<source ref="id42"/>
-			<target ref="id42"/>
-			<label kind="synchronisation" x="-493" y="-340">position_update?</label>
-			<nail x="-501" y="-357"/>
-			<nail x="-501" y="-306"/>
+		<location id="id45" x="-731" y="-544">
+		</location>
+		<init ref="id45"/>
+		<transition>
+			<source ref="id45"/>
+			<target ref="id45"/>
+			<label kind="select" x="-1181" y="-816">i : int[0,max_ang_diff]</label>
+			<label kind="synchronisation" x="-1181" y="-833">glass_diff_to_start_ang_update?</label>
+			<label kind="assignment" x="-1181" y="-799">glass_diff_to_start_ang = i</label>
+			<nail x="-977" y="-765"/>
+			<nail x="-935" y="-799"/>
+		</transition>
+		<transition>
+			<source ref="id45"/>
+			<target ref="id45"/>
+			<label kind="select" x="-450" y="-790">i : int[0,max_ang_diff]</label>
+			<label kind="synchronisation" x="-476" y="-807">glass_diff_to_target_ang_update?</label>
+			<label kind="assignment" x="-442" y="-773">glass_diff_to_target_ang = i</label>
+			<nail x="-433" y="-739"/>
+			<nail x="-484" y="-790"/>
+		</transition>
+		<transition>
+			<source ref="id45"/>
+			<target ref="id45"/>
+			<label kind="select" x="-493" y="-382">i : int[0,max_ang_diff]</label>
+			<label kind="synchronisation" x="-493" y="-399">bottle_diff_to_start_ang_update?</label>
+			<label kind="assignment" x="-493" y="-365">bottle_diff_to_start_ang = i</label>
+			<nail x="-476" y="-416"/>
+			<nail x="-510" y="-382"/>
+		</transition>
+		<transition>
+			<source ref="id45"/>
+			<target ref="id45"/>
+			<label kind="select" x="-1198" y="-416">i : int[0,max_ang_diff]</label>
+			<label kind="synchronisation" x="-1232" y="-433">bottle_diff_to_target_ang_update?</label>
+			<label kind="assignment" x="-1207" y="-399">bottle_diff_to_target_ang = i</label>
+			<nail x="-986" y="-433"/>
+			<nail x="-952" y="-391"/>
+		</transition>
+		<transition>
+			<source ref="id45"/>
+			<target ref="id45"/>
+			<label kind="select" x="-858" y="-306">i : int[0,max_pos_diff]</label>
+			<label kind="synchronisation" x="-858" y="-323">bottle_diff_to_target_pos_update?</label>
+			<label kind="assignment" x="-858" y="-289">bottle_diff_to_target_pos = i</label>
+			<nail x="-782" y="-331"/>
+			<nail x="-697" y="-331"/>
+		</transition>
+		<transition>
+			<source ref="id45"/>
+			<target ref="id45"/>
+			<label kind="select" x="-1232" y="-561">i : int[0,max_pos_diff]</label>
+			<label kind="synchronisation" x="-1232" y="-578">glass_diff_to_start_pos_update?</label>
+			<label kind="assignment" x="-1232" y="-544">glass_diff_to_start_pos = i</label>
+			<nail x="-1003" y="-578"/>
+			<nail x="-1003" y="-527"/>
+		</transition>
+		<transition>
+			<source ref="id45"/>
+			<target ref="id45"/>
+			<label kind="select" x="-773" y="-884">i : int[0,max_pos_diff]</label>
+			<label kind="synchronisation" x="-824" y="-901">glass_diff_to_target_pos_update?</label>
+			<label kind="assignment" x="-824" y="-867">glass_diff_to_target_pos = i</label>
+			<nail x="-663" y="-850"/>
+			<nail x="-765" y="-850"/>
+		</transition>
+		<transition>
+			<source ref="id45"/>
+			<target ref="id45"/>
+			<label kind="select" x="-323" y="-569">i : int[0,max_pos_diff]</label>
+			<label kind="synchronisation" x="-323" y="-586">bottle_diff_to_start_pos_update?</label>
+			<label kind="assignment" x="-323" y="-552">bottle_diff_to_start_pos = i</label>
+			<nail x="-331" y="-595"/>
+			<nail x="-331" y="-527"/>
 		</transition>
 	</template>
 	<template>
 		<name>positionupdate</name>
-		<location id="id43" x="0" y="0">
+		<location id="id46" x="0" y="0">
 		</location>
-		<init ref="id43"/>
+		<init ref="id46"/>
 		<transition>
-			<source ref="id43"/>
-			<target ref="id43"/>
-			<label kind="synchronisation" x="59" y="-8">position_update!</label>
-			<nail x="51" y="-17"/>
-			<nail x="51" y="17"/>
+			<source ref="id46"/>
+			<target ref="id46"/>
+			<label kind="synchronisation" x="-331" y="59">bottle_diff_to_target_ang_update!</label>
+			<nail x="-119" y="42"/>
+			<nail x="-85" y="68"/>
+		</transition>
+		<transition>
+			<source ref="id46"/>
+			<target ref="id46"/>
+			<label kind="synchronisation" x="-323" y="-110">glass_diff_to_start_ang_update!</label>
+			<nail x="-85" y="-110"/>
+			<nail x="-119" y="-85"/>
+		</transition>
+		<transition>
+			<source ref="id46"/>
+			<target ref="id46"/>
+			<label kind="synchronisation" x="119" y="-76">glass_diff_to_target_ang_update!</label>
+			<nail x="110" y="-42"/>
+			<nail x="93" y="-68"/>
+		</transition>
+		<transition>
+			<source ref="id46"/>
+			<target ref="id46"/>
+			<label kind="synchronisation" x="102" y="59">bottle_diff_to_start_ang_update!</label>
+			<nail x="85" y="85"/>
+			<nail x="102" y="68"/>
+		</transition>
+		<transition>
+			<source ref="id46"/>
+			<target ref="id46"/>
+			<label kind="synchronisation" x="-340" y="-17">glass_diff_to_start_pos_update!</label>
+			<nail x="-119" y="-25"/>
+			<nail x="-119" y="8"/>
+		</transition>
+		<transition>
+			<source ref="id46"/>
+			<target ref="id46"/>
+			<label kind="synchronisation" x="-136" y="93">bottle_diff_to_target_pos_update!</label>
+			<nail x="-34" y="85"/>
+			<nail x="17" y="85"/>
+		</transition>
+		<transition>
+			<source ref="id46"/>
+			<target ref="id46"/>
+			<label kind="synchronisation" x="-34" y="-119">glass_diff_to_target_pos_update!</label>
+			<nail x="25" y="-102"/>
+			<nail x="-25" y="-102"/>
+		</transition>
+		<transition>
+			<source ref="id46"/>
+			<target ref="id46"/>
+			<label kind="synchronisation" x="127" y="-8">bottle_diff_to_start_pos_update!</label>
+			<nail x="119" y="-17"/>
+			<nail x="119" y="17"/>
 		</transition>
 	</template>
 	<template>
 		<name>goalcatcher</name>
-		<location id="id44" x="-578" y="-263">
+		<location id="id47" x="-578" y="-263">
 		</location>
-		<init ref="id44"/>
+		<init ref="id47"/>
 		<transition>
-			<source ref="id44"/>
-			<target ref="id44"/>
+			<source ref="id47"/>
+			<target ref="id47"/>
 			<label kind="synchronisation" x="-535" y="-272">goal?</label>
 			<nail x="-535" y="-280"/>
 			<nail x="-535" y="-246"/>
@@ -668,7 +838,7 @@ int glass_in_target_pos = 0;</declaration>
 	</template>
 	<system>// Place template instantiations here.
 // List one or more processes to be composed into a system.
-system Cobot, press, move, pickup, place, goal_, goalcatcher, positionupdate, positionupdatecatcher, model_positions, testdonecatcher;
+system Cobot, press, move, pickup, place, goal_, goalcatcher, positionupdate, positionupdatecatcher, bottle_position, glass_position, testdonecatcher, asapcatcher;
     </system>
 	<queries>
 		<query>
diff --git a/images/cobot1.png b/images/cobot1.png
index 8dcea166bbb3bee1289f35dbb87e5a7c1fbfdc01..3ff717f1b2b85db846036f40f72f73fbcf55b2e3 100644
Binary files a/images/cobot1.png and b/images/cobot1.png differ
diff --git a/images/cobot1_positionen_modell.png b/images/cobot1_positionen_modell.png
index 8ff3e75670be3d8f54dd58facdaec557230ef941..3b98c7caf894cb15bb4ae5b4caf6f075bcc0ded3 100644
Binary files a/images/cobot1_positionen_modell.png and b/images/cobot1_positionen_modell.png differ
diff --git a/sections/ausfuehrung.tex b/sections/ausfuehrung.tex
index 78d5f8bccf76f59fa0a9f46e42b3a832862e5370..fa1203774b82f5246db58737ecb11ff2d212daec 100644
--- a/sections/ausfuehrung.tex
+++ b/sections/ausfuehrung.tex
@@ -67,21 +67,22 @@ Der Uppaal Verifier kann mit der Anfrage \textit{A<> deadlock} (jeder Pfad führ
 
 \subsection{Topics, Adapter und Modellanpassungen}
 Als nächstes müssen ROS-Topics identifiziert werden, die die benötigten Informationen transportieren. Dazu eignet sich das Tool \textit{rostopic}\footnote{\url{http://wiki.ros.org/rostopic}}, mit welchem sich alle aktiven Topics auflisten und deren Nachrichten abhören lassen.\\
-Für den initialen Impuls des Drucksensors ist bereits ein Topic vorhanden und wird vom Cobot verwendet, kann also auch als Output vom Adapter benutzt werden. Dabei lässt sich direkt die Anzahl an erneuten Versuchen vor einem Abbruch übertragen, da diese in einer Konfigurationsdatei des Systems festgelegt wird und daher in der Konfigurationsphase des Adapters ausgelesen werden kann. In dieser Konfigurationsdatei sind auch die Startposition der Flasche sowie die Start- und Zielposition des Glases hinterlegt, sodass auch diese im Adapter gehalten werden können. Das Speichern sowie Vergleichen der Positionen von Flasche und Glas muss im Adapter erfolgen, da Uppaal TRON keine Gleitkommazahlen beim Testen unterstützt. Gazebo veröffentlicht regelmäßig über \textit{/gazebo/link\_states} und \textit{/gazebo/model\_states} die aktuellen Positionen in der Simulationsmodelle, welche folglich mit den Gewünschten im Adapter verglichen und das Ergebnis als Boolean an Uppaal weitergegeben werden kann. Für die Verwendung mit TRON müssen auch diese Booleans in Uppaal als Integer deklariert werden, was allerdings kein Problem darstellt, da innerhalb der Modelle Vergleiche mit \textit{true} oder \textit{false} möglich sind und vom Adapter einfach 0 oder 1 übertragen werden kann. Die Simulationssoftware beginnt vor dem Initialisieren der Objekte bereits mit dem Veröffentlichen von Nachrichten, sodass vom Adapter mit dem Weitergeben an TRON gewartet wird, bis die Objekte vollständig initialisiert wurden. Außerdem müssen die Positionen mit einer gewissen Toleranz verglichen werden, da (so gut wie) immer leichte Abweichungen auftreten.
+Für den initialen Impuls des Drucksensors ist bereits ein Topic vorhanden und wird vom Cobot verwendet, kann also auch als Output vom Adapter benutzt werden. Dabei lässt sich direkt die Anzahl an erneuten Versuchen vor einem Abbruch übertragen, da diese in einer Konfigurationsdatei des Systems festgelegt wird und daher in der Konfigurationsphase des Adapters ausgelesen werden kann. In dieser Konfigurationsdatei sind auch die Startposition der Flasche sowie die Start- und Zielposition des Glases hinterlegt, sodass auch diese im Adapter gehalten werden können. Das Speichern sowie Vergleichen der Positionen von Flasche und Glas muss im Adapter erfolgen, da Uppaal TRON keine Gleitkommazahlen beim Testen unterstützt. Gazebo veröffentlicht regelmäßig über \textit{/gazebo/link\_states} und \textit{/gazebo/model\_states} die aktuellen Positionen in der Simulationsmodelle, welche folglich mit den Gewünschten verglichen und die Ergebnisse als Differenz an TRON weitergegeben werden können. Anzumerken ist, dass für jede Differenz ein eigener Channel in Uppaal existiert. Dies ist nötig da eine einzelne Kante, welche alle Werte aktualisiert, dazu führen würde, dass Uppaal alle Kombinationen dieser als mögliche Outputs berechnet, was zu exponentiell erhöhter Rechenzeit führt (\textit{State Explosion}). Die Simulationssoftware beginnt vor dem Initialisieren der Objekte bereits mit dem Veröffentlichen von Nachrichten, sodass vom Adapter mit dem Weitergeben an TRON gewartet wird, bis die Objekte initialisiert wurden. Außerdem wird beim Berechnen der Orientierungsabweichung eine Drehung um die Z-Achse (senkrecht zur Szene) ignoriert, da diese für ein Aufrechtstehen nicht relevant ist.
 Diese Aspekte schränken zwar das Modell ein und machen eine Auslagerung von Logik in den Adapter notwendig, sorgen aber gleichzeitig dafür, dass das Modell abstrakt bleibt und nicht zu detailliert wird.
-Um die Positionen der Objekte im Uppaal-System festzuhalten wurde ein separates Modell, zu sehen in \cref{positionen_modell_bild} hinzugefügt, welches durch das Topic \textit{/gazebo/link\_states} aktualisiert wird und globale Variablen setzt, die das Modell des Cobots verwendet. Dabei musste auch darauf geachtet werden, dass fehlgeschlagene Versuche passend dargestellt sind. Das Modell des Roboters kann nur in den Zustand \textit{finished\_success} übergehen, wenn sich Flasche und Glas an der Endposition befinden.\\
+Um die Positionen der Objekte im Uppaal-System festzuhalten wurde je ein separates Modell, zu sehen in \cref{cobot:positionen_modell_bild} (analog für Flasche) hinzugefügt, welches durch das Topic \textit{/gazebo/link\_states} aktualisiert wird und globale Variablen setzt, die das Modell des Cobots verwendet, um festzustellen ob sich das Objekt an der richtigen Position befindet. Dabei musste auch darauf geachtet werden, dass fehlgeschlagene Versuche passend dargestellt sind, es existiert also für jede Zustand eine Kante zu seinem Vorgänger. Zum Startzustand kann allerdings nur zurückgegangen werden, wenn das Objekt nicht gleichzeitig im Endzustand ist, um ein fälschliches Zurückgehen zu verhindern. Es existiert keine Kante direkt vom Start- zum Endzustand, sodass das Objekt mindestens einmal seine Position verlassen muss.\\
 \begin{figure}[h]
 	\centering
-	\includegraphics[scale=.25]{./cobot1_positionen_modell.png}
-	\caption{Modell der Positionen von Flasche und Glas}
+	\includegraphics[scale=.2]{./cobot1_positionen_modell.png}
+	\caption{Modell der Positionen vom Glas}
 	\label{cobot:positionen_modell_bild}
 \end{figure}
 Für das Platzieren und Aufheben von Objekten sowie die Bewegungsplanung wird von ROS beziehungsweise MoveIt\footnote{\url{https://moveit.ros.org/}} (Framework unter anderem zur Bewegungsplanung) die actionlib verwendet, sodass sich die dort verwendeten Topics \textit{/pickup/result} und \textit{/place/result} zum Testen eignen. Die dort benutzten Nachrichten besitzen einen eigenen Typ von Fehlercode, durch welchen an TRON der Erfolg oder das Fehlschlagen einer Aktion gemeldet werden kann. Um das Modell eindeutiger zu gestalten, wurde die Variable \textit{success} durch je einen weiteren Channel für einen Fehlschlag ersetzt.\\
 Für das Verfolgen von Bewegungen, welche bei der Bewegung zur Flasche, zum Glas und beim Einfüllen relevant sind wird das Topic \textit{/follow\_joint\_trajectory/result} des \textit{position\_joint\_trajectory\_controller} genutzt. Außerdem ist eine Bewegung nach dem Fehlschlagen des Platzierens vom Glas eingefügt worden, da diese hier hinzugefügt wurde, um Abstand zu gewinnen, bevor ein weiterer Versuch ausgeführt wird.
-Die restlichen Bewegungen (bis auf die zur Startposition des Roboters) sind als Teilvorgänge des Platzierens und Aufhebens anzusehen, da sie an sich keine essentielle Funktion des Cobots darstellen und sind daher nicht explizit im Modell angegeben.\\
-Da logischerweise auch das Platzieren und Aufheben von Objekten Bewegungen des Arms beinhaltet, müssen bei entsprechenden Knoten im Modell zusätzliche Kanten eingefügt werden, die zum Knoten selbst zurückführen und dabei eine (nicht-) erfolgreiche Ausführung durch einen Channel abfragen. Diese Kanten sorgen dafür, dass die in \cref{cobot:formales_modell} beschriebene Validierung nicht ohne Weiteres so verwendet werden kann, da nun Endlosschleifen möglich sind. Dies könnte beispielsweise durch einen Zähler mit einer (unrealistisch hohen) maximalen Anzahl an Bewegungen realisiert sein. Für die Orientierungsbeschränkung beim Bewegen kommen nur Topics die ein Ziel festlegen (\textit{/move\_group/goal}, \textit{/pickup/goal}, \textit{/place/goal}) in Frage, da nur in diesen Nachrichten eine solche Beschränkung übergeben wird und eine Überprüfung von bereits berechneten Bewegungsbahnen aufwendig wäre. Anzumerken ist hier, dass das Einhalten einer gegebenen Beschränkung genauso wie das Aufheben oder die Bewegungen selbst nicht Teil des Tests darstellen, sondern auf den niedrigeren Testebenen (Unit-Tests oder Integrations-Tests) getestet werden müssen. Daher wird hier nur überprüft, ob eine Orientierungsbeschränkung festgelegt ist. Auch hier wäre ein Abgleich mit einer gewünschten Orientierung innerhalb des Adapters möglich, diese ist jedoch hier nicht zwingend nötig, da eine falsche Orientierung bei einer Simulation extrem auffällig wäre und daher hier ausgeschlossen werden kann. Bei genauerer Analyse des Cobots sind weitere Bewegungsbeschränkungen wie etwa bei der Beschleunigung aufgefallen, diese würden dem gleichen Schema folgen.\\
-Da innerhalb von jedem Modell-Zustand Nachrichten an \textit{goal} gesendet werden, für das Testen allerdings nur eine Änderung bei der Orientierungsbeschränkung relevant ist, wird in das Uppaal-System ein weiteres Modell integriert, welches Outputs an den entsprechenden Channel entgegennimmt, wenn keine Änderung erfolgte. Das gleiche Prinzip wird auf den Channel angewandt, welcher den Drucksensor repräsentiert.\\
-Das endgültige Testmodell für den Cobot (ohne die erwähnten Zusatzmodelle, siehe Anhang) ist in \cref{cobot:modell_bild} abgebildet.
+Die restlichen Bewegungen (bis auf die zur Startposition des Roboters) sind als Teilvorgänge des Platzierens und Aufhebens anzusehen, da sie an sich keine essentielle Funktion des Cobots darstellen und sind daher nicht explizit im Modell angegeben.
+Da logischerweise auch das Platzieren und Aufheben von Objekten Bewegungen des Arms beinhaltet, müssen bei entsprechenden Knoten im Modell zusätzliche Kanten eingefügt werden, die zum Knoten selbst zurückführen und dabei eine (nicht-) erfolgreiche Ausführung durch einen Channel abfragen. Dies ist nötig, da TRON sonst einen Fehler aufgrund von nicht erwartetem Output ausgibt. Diese Kanten sorgen dafür, dass die in \cref{cobot:formales_modell} beschriebene Validierung nicht ohne Weiteres so verwendet werden kann, da nun Endlosschleifen möglich sind. Dies könnte beispielsweise durch einen Zähler mit einer (unrealistisch hohen) maximalen Anzahl an Bewegungen und eine Deklarierung von allen Channels als \textit{urgent} realisiert sein, wird jedoch hier nicht vorgenommen, um das Modell übersichtlicher zu halten.\\
+Für die Orientierungsbeschränkung beim Bewegen kommen nur Topics die ein Ziel festlegen (\textit{/move\_group/goal}, \textit{/pickup/goal}, \textit{/place/goal}) in Frage, da nur in diesen Nachrichten eine solche Beschränkung übergeben wird und eine Überprüfung von bereits berechneten Bewegungsbahnen aufwendig wäre. Anzumerken ist hier, dass das Einhalten einer gegebenen Beschränkung genauso wie das Aufheben oder die Bewegungen selbst nicht Teil des Tests darstellen, sondern auf den niedrigeren Testebenen (Unit-Tests oder Integrations-Tests) getestet werden müssen. Daher wird hier nur überprüft, ob eine Orientierungsbeschränkung festgelegt ist. Auch hier wäre ein Abgleich mit einer gewünschten Orientierung innerhalb des Adapters möglich, diese ist jedoch hier nicht zwingend nötig, da eine falsche Orientierung bei einer Simulation extrem auffällig wäre und daher hier ausgeschlossen werden kann. Bei genauerer Analyse des Cobots sind weitere Bewegungsbeschränkungen wie etwa bei der Beschleunigung aufgefallen, diese würden dem gleichen Schema folgen.\\
+Da innerhalb von jedem Modell-Zustand Nachrichten an \textit{goal} gesendet werden, für das Testen allerdings nur eine Änderung bei der Orientierungsbeschränkung relevant ist, wird in das Uppaal-System ein weiteres Modell integriert, welches Outputs an den entsprechenden Channel entgegennimmt, wenn keine Änderung erfolgte. Das gleiche Prinzip wird ebenfalls auf andere Channel angewandt, welche zu jedem Zeitpunkt aktiviert werden können.\\
+Das endgültige Testmodell für den Cobot (ohne die zusätzlich verwendeten Modelle, siehe Anhang) ist in \cref{cobot:modell_bild} abgebildet.
 \begin{figure}[h]
 	\centering
 	\includegraphics[scale=.22, angle=90]{./cobot1.png}
@@ -89,4 +90,37 @@ Das endgültige Testmodell für den Cobot (ohne die erwähnten Zusatzmodelle, si
 	\label{cobot:modell_bild}
 \end{figure}
 
-\subsection{Testausführung}
\ No newline at end of file
+\subsection{Testausführung}\label{cobot:testausfuehrung}
+Zur Ausführung wurde ein simples Bash-Script geschrieben, welches zuerst einen build für das Projekt ausführt und dann eine beliebige Anzahl an Tests startet. Dabei werden die Tests sequentiell ausgeführt, indem zunächst TRON und schließlich eine roslaunch-Datei gestartet wird. In dieser Datei ist das Starten der Simulation und nötigen ros-Nodes, inklusive des Test-Adapters, geregelt. Mittels dem Argument \textit{gui} (und dem Wert \textit{false}) wird Gazebo \textit{headless} gestartet, sodass die Tests problemlos im Hintergrund ablaufen können. TRON ermöglicht das festhalten der Ergebnisse in Textdateien (siehe \cite{TronManual}). Das Tool eine Testausführung ab, wenn ein Fehler auftritt oder der im Adapter festgelegte Timeout abläuft. Da das System nicht unendlich läuft und ein Erfolg mittels der Zustände \textit{finished\_success} und \textit{shut\_down} kodiert ist, kann ein erfolgreicher Test vor dem Timeout beendet werden. Dazu wurde ein weiterer Channel \textit{test\_done} deklariert, welcher beim Übergang in diese Zustände auslöst und als Input dient, auf welchen der Adapter mit einer von TRON nicht erwarteten Ausgabe reagiert (Channel \textit{intentional\_fail}). Dadurch können bei gleichbleibender Zeit deutlich mehr Tests durchgeführt werden, wenn in Kauf genommen wird, dass nach dem im Modell spezifizierten Verhalten keine weitere Überprüfung stattfindet.
+
+\subsection{Testergebnisse}
+Die in \cref{cobot:testausfuehrung} beschriebene Methode wurde angewandt um das Modell 100 mal auszuführen und Log-Dateien anzulegen. Folglich konnte erneut ein Bash-Skript genutzt werden, um die Testergebnisse zu analysieren. Da lediglich ein Zustand erreicht werden muss, um den Test erfolgreich abzuschließen, reicht es in diesem Fall nach einem entsprechenden Zustand im Log zu suchen. Wird kein Endzustand erreicht, so kann der Testfall als fehlgeschlagen eingestuft und weiter untersucht werden.\\
+In 46 der 100 Fälle wurde die Sequenz erfolgreich ausgeführt und die Flasche sowie das Glas waren in der richtigen Position. Dabei wurde eine Toleranz von 5cm verwendet. Nur 3 Fälle führten zum Herunterfahren des Systems, was ebenfalls als erfolgreicher Abschluss gezählt werden kann. Die restlichen 51 Ausführungen führten zu keinem Erfolg und wurden im Folgenden manuell analysiert.\\
+Die größte Fehlerquelle stellte das Neigen der Flasche beim Befüllen des Glases dar. Es kam dabei 42 mal zum Umfallen mindestens eines Objektes. Mithilfe der protokollierten Abstände von Positionen und Orientierungen sowie der Zustände in denen diese auftraten lässt sich grob feststellen, wann ein solches Ereignis auftrat. In 27 Fällen war die Flasche zu mindestens einem Zeitpunkt mehr als 110 Grad geneigt, sodass wahrscheinlich kurz vor oder bei der vollen Neigung der Flasche diese verloren ging. Davon wurde in 3 Fällen auch das Glas umgeworfen. Die restlichen 15 mal fiel die Flasche vermutlich eher, da hier keine 110 Grad bei der Orientierungsdifferenz erreicht wurde. Einmal war die Flasche dabei mehr als 2 Meter von seiner Startposition entfernt, was bei dem Tempo der Bewegungen des Roboters äußerst unwahrscheinlich wirkt und vielleicht durch einen Bug (in der Simulation) verursacht wurde. \\
+Nach dem erfolgreichen Befüllen kam es in zwei Fällen zum Umwerfen des Glases beim Aufheben dieses. Weitere zwei Fälle wurde es kurz angehoben und fiel scheinbar zurück in seine Startposition.\\
+Die übrig gebliebenen Testfälle lassen sich unter anderem auf die Planung von Bewegungen zurückführen. So hielt das System je einmal im Zustand \textit{stepping\_back} und \textit{goto\_last\_state\_before\_shutdown}, welche beide auf das Fehlschlagen vom Platzieren des Glases folgen, um den nächsten Platzierungsversuch von einer (leicht) anderen Position auszuführen. Bei genauerer Inspektion des Codes fiel auf, dass an dieser Stelle ein Fehlschlagen der Bewegungsplanung nicht verarbeitet wird, was die Fehlerquelle darstellen könnte.
+Die letzten 3 Testausführungen sind (vermutlich) vom eigentlichen System unabhängig aufgetretene Fehler. Zwei mal wurde im Zustand \textit{in\_start\_pos} ein Update von Positionen der Simulation empfangen, was für TRON zu spät war, da als nächstes der Übergang zu \textit{finished\_success} aufgrund des urgent Channels \textit{asap} hätte stattfinden sollen. Da an diesem Punkt aber bereits die Ausführung des Systems beendet war und sich sowohl die Flasche als auch das Glas an den richtigen Positionen befanden, sind diese Fälle als erfolgreiche Systemausführung zu werten und es sollte eine Korrektur auf diese fehlerhafte Modellierung folgen. Beispielsweise könnten die Channels, welche Positionsupdates empfangen, ebenfalls als urgent gekennzeichnet werden. 
+Der letzte Fehler konnte in der Konfiguration des Adapters identifiziert werden. Im Zustand \textit{move\_to\_glass} wurde eine Nachricht ohne Orientierungsbeschränkung empfangen, was nur auftreten konnte, da für den Channel \textit{goal}, welcher diese Beschränkung übermittelt, mehrere Topics zuständig sind, sodass in der Queue des Subscribers für eines dieser Topics noch eine Nachricht vorhanden war, in der keine Beschränkung besteht, während eine andere mit dieser (von einem anderen Topic)  bereits verarbeitet war. Das Auftreten eines solchen Fehlers ist als sehr selten einzustufen und könnte verhindert werden, indem etwa nur die letzte Nachricht der drei Topics an TRON weitergegeben wird.\\
+Insgesamt ist festzustellen, dass eine Verbesserung des Befüllvorgangs mit Abstand am relevantesten zur Fehlerreduzierung ist. Außerdem sollte das Fehlschlagen von Planungen der Bewegungen immer beachtet und entsprechend damit umgegangen werden. Schließlich könnte das Aufheben und Platzieren von Objekten zuverlässiger gestaltet werden. Unabhängig vom zu testenden System sind auch Fehler im Modell und Adapter aufgefallen, welche jedoch relativ simpel entfernt werden können. Eine kompakte Auflistung aller Testergebnisse ist in zu sehen.
+\\\\\\
+\begin{center}
+\begin{tabular}[]{c|c|c}
+	\caption{Testergebnisse}
+	\centering
+	Anzahl & Ergebnis & (potentieller) Fehler \\
+	\hline
+	46 & erfolgreiche Ausführung & - \\
+	\hline
+	3 & System heruntergefahren (Erfolg) & - \\
+	\hline 
+	42 & Flasche (und Glas) gefallen & Probleme beim Aufheben oder Festhalten \\
+	\hline
+	4 & Glas gefallen & Probleme beim Aufheben oder Festhalten \\
+	\hline
+	2 & System angehalten & fehlgeschlagene Bewegungsplanung \\
+	\hline
+	2 & Zu spätes Positionsupdate & Modellfehler \\
+	\hline 
+	1 & Nicht mehr aktuelle Nachricht & Fehler im Adapter \\
+\end{tabular}
+\end{center}
diff --git a/sections/einleitung.tex b/sections/einleitung.tex
index 22399f7158d330218eca4c43d35fb6b39d4849f9..4add4a9e36e3a1955ac6cff872cb036a44032680 100644
--- a/sections/einleitung.tex
+++ b/sections/einleitung.tex
@@ -5,13 +5,18 @@ Schon heute gibt es beinahe vollautomatische Supermärkte, in vielen Gärten mä
 Auch in Operationssälen finden sich immer mehr Robotersysteme, in der Industrie sind sie bereits ein fester Bestandteil, ihr Anwendungsbereich wächst zunehmend. 
 Sie sind stärker vernetzt denn je und arbeiten mit Menschen oder anderen Robotern zusammen. 
 Gleichzeitig werden ihre Aufgaben immer komplexer. 
-Damit einher geht eine Entwicklung in Richtung komponenten-basierter Softwareentwicklung.
-Das Testen von Komponenten eines Robotiksystems ist unabdingbar.
+Dadurch gewinnt das Testen von Robotersystemen zunehmend an Relevanz.
 Nicht-funktionierende Komponenten könnten Auswirkungen auf das gesamte System haben und durch die (tendenziell größer werdende) Zusammenarbeit mit dem Menschen fatale Konsequenzen, beispielsweise im medizinischen Bereich, haben.
-Weiterhin ermöglicht das Testen eine größere Zuverlässigkeit sowie Qualität der Komponenten und sorgt somit für eine bessere Wiederverwendbarkeit dieser, wodurch Arbeit und Kosten gespart werden können.
+Weiterhin ermöglicht das Testen eine größere Zuverlässigkeit sowie Qualität der Komponenten und sorgt somit für eine bessere Wiederverwendbarkeit dieser, wodurch Arbeit und Kosten gespart werden können. 
+In der Industrie sind bereits verschiedene Testkonzepte bekannt und werden standardisiert angewendet. 
+Obwohl die Forschung im Gebiet der Robotik deutlich zugenommen hat, sind weitere Analysen insbesondere von Testmethodiken dieser speziellen Systeme nötig, um mit dem Fortschritt in der Entwicklung mitzuhalten.
 
 \section{Zielstellung} \label{einleitung:zielstellen}
-Diese Arbeit befasst sich mit dem Systematischen Testen eines in~\Cref{einleitung:motivation} beschriebenen Robotersystems mit Fokus auf das Robot Operating System (ROS). Es werden Anforderungen an das Testen diskutiert und umgesetzt.
+Diese Arbeit befasst sich mit dem Systematischen Testen eines in~\Cref{einleitung:motivation} beschriebenen Robotersystems mit Fokus auf das Robot Operating System (ROS).
+Zunächst müssen relevante Termini beschrieben werden.
+Folglich wird durch Literaturrecherche Anforderungen an Testmethoden von Robotiksystemen ermittelt und Schwierigkeiten bei der Umsetzung dieser erläutert. 
+Ein zentraler Aspekt dabei ist die korrekte Simulation des Roboters, da diese essentieller Bestandteil des Testumfelds ist.
+
 Ein zentraler Aspekt des Testens ist die korrekte Simulation des Roboters. 
 Dazu muss sichergestellt werden, dass sich die Objekte innerhalb der Simulation (ausreichend) physikalisch korrekt verhalten. 
 Die Sensoren des Roboters müssen logisch korrekt auf ihr Umfeld reagieren.
diff --git a/sections/stateoftheart.tex b/sections/stateoftheart.tex
index 6cac8b367bbc92a885a6f1fc2e44947649117c78..933b591a662a0213371e47abd08a1ea20d04aa73 100644
--- a/sections/stateoftheart.tex
+++ b/sections/stateoftheart.tex
@@ -1,12 +1,14 @@
-\chapter{State of the Art}
+\chapter{Tools für MBT}
 Neben der bereits erwähnten Integration von Unit-Tests in ROS und rostests, welche für Integrations- und System-Tests genutzt werden können existiert eine Reihe von Tools für Model-basiertes Testen wie in \cite{Shafique2010} dargestellt. Im Rahmen dieser Arbeit können jedoch nur nicht-kommerzielle Lösungen genauer untersucht werden. Weiterhin muss das gewählte Tool mit ROS und daher mit C++ kompatibel sein. Die Auswahl eines solchen Tools ist in die Testmanagementprozesse einzuordnen.
 \section{Spec Explorer (2010)}
 Der Spec Explorer von Microsoft\footnote{\url{https://marketplace.visualstudio.com/items?itemName=SpecExplorerTeam.SpecExplorer2010VisualStudioPowerTool-5089}} ist ein Tool für Modell-basiertes Testen und als kostenlose Erweiterung für Visual Studio vorhanden. Da jedoch eine kostenpflichtige Visual Studio Version notwendig ist, ist dieses Tool als kommerziell einzustufen und kann im Rahmen dieser Arbeit nicht verwendet werden. Es ist jedoch aufgrund seiner Verbreitung hier zu erwähnen und wurde bereits häufig im akademischen Rahmen verwendet \cite{Silva2008, Campbell2005, Campbell2005a, Naujoks2011, Botincan2007}. Ein abstraktes Modell des zu testenden Systems wird dabei in C\# implementiert, es sind jedoch auch andere Sprachen möglich. Das Tool ist umfangreich und bietet sowohl online- als auch offline-Testing an, wobei sich durch Adapter sämtliche Programmiersprachen verwenden lassen. Ebenso wird eine Validierung des Modells selbst unterstützt und es können verschiedene Testauswahlkriterien angewandt werden.
 \section{Uppaal TRON}
-Uppaal\footnote{\url{https://uppaal.org/}} ist ein für akademische Zwecke frei verfügbares Tool zum Validieren von Modellen und wurde bereits in \cite{Ernits2015, Gummel2018} im Zusammenhang mit ROS verwendet. Dabei wird eine Erweiterung namens TRON\footnote{\url{https://people.cs.aau.dk/~marius/tron/}} (Testing Realtime Systems Online) benutzt, welche das Modell im Rahmen eines online-Tests durchläuft, was sich wie in \cref{grundlagen:testentwicklung:modell-basiert} dargestellt für Robotiksysteme anbietet. Aus diesen Gründen und da auch am Lehrstuhl bereits mit Uppaal gearbeitet wurde, wird das Tool in dieser Arbeit exemplarisch angewandt. Die Erweiterung von TRON namens DTRON (Distributed TRON) für verteilte Systeme sowie das verwendete Adapter-Template von \cite{Ernits2015, Gummel2018} steht zum momentanen Zeitpunkt nicht zur Verfügung und kann daher nicht verwendet werden. Im folgenden wird sowohl das Modell unter Uppaal sowie die Funktionsweise des TRON-Adapters erläutert.
+Uppaal\footnote{\url{https://uppaal.org/}} ist ein für akademische Zwecke frei verfügbares Tool zum Validieren von Modellen und wurde bereits in \cite{Ernits2015, Gummel2018} im Zusammenhang mit ROS verwendet. Dabei wird eine Erweiterung namens TRON\footnote{\url{https://people.cs.aau.dk/~marius/tron/}} (Testing Realtime Systems Online) benutzt, welche das Modell im Rahmen eines online-Tests durchläuft, was sich wie in \cref{grundlagen:testentwicklung:modell-basiert} dargestellt für Robotiksysteme anbietet. Außerdem kann Uppaal ein erstelltes Modell mithilfe von formalen Anfragen einer eigenen Syntax validieren, was gerade in den Anfangsphasen eines Projektes hilfreich sein kann.
+Aus diesen Gründen und da auch am Lehrstuhl bereits mit Uppaal gearbeitet wurde, wird das Tool in dieser Arbeit exemplarisch angewandt. Die Erweiterung von TRON namens DTRON (Distributed TRON) für verteilte Systeme sowie das verwendete Adapter-Template von \cite{Ernits2015, Gummel2018} steht zum momentanen Zeitpunkt nicht zur Verfügung und kann daher nicht verwendet werden. Im folgenden wird sowohl das Modell unter Uppaal sowie die Funktionsweise des TRON-Adapters erläutert.
 \subsection{Modell in Uppaal}
-Ein System in Uppaal besteht aus einem oder mehreren Automaten. Sogenannte Channel und global deklarierte Variablen sorgen für eine Synchronisation dieser. Die Automaten selbst sind als erweiterte endliche nicht-deterministische Automaten einzuordnen, die auch Zeitangaben unterstützen. Durch Guards kann festgelegt werden, wann eine Kante verfügbar ist. Beim Entlanggehen einer Kante, welches auch durch die erwähnten Channel ausgelöst werden kann, können Variablen (global oder lokal) angepasst werden. Channel bieten sich als Modellierung der ROS Topics an.
-Invarianten können global oder nur in bestimmten Zuständen angegeben werden. \cref{konzept:uppaal_tor} zeigt beispielhaft ein modelliertes System eines automatischen Tores mit einem dazugehörigen Schlüssel. Beim probabilistischen Auslösen dieses Schlüssels (mit einer Wahrscheinlichkeit von 1:101) wird das Tor über den Channel \textit{auslösen} informiert, wechselt in den Zustand \textit{öffnend} und setzt die Variable "zeit" auf 0. Nach 10000 vergangenen Zeiteinheiten wechselt das Tor dann in den Zustand \textit{offen}. Das Schließen läuft analog dazu ab.
+Ein System in Uppaal besteht aus einem oder mehreren Automaten. Sogenannte \textit{Channel} und global deklarierte Variablen sorgen für eine Synchronisation dieser. Die Automaten selbst sind als erweiterte endliche nicht-deterministische Automaten einzuordnen, die auch Zeitangaben unterstützen. Durch Guards kann festgelegt werden, wann eine Kante verfügbar ist. Beim Entlanggehen einer Kante, welches auch durch die erwähnten Channel ausgelöst werden kann, können Variablen (global oder lokal) angepasst werden. Channel bieten sich als Modellierung der ROS Topics an.
+Invarianten können global oder nur in bestimmten Zuständen angegeben werden. Außerdem lassen sich Channel sowie Zustände mit verschiedenen Eigenschaften versehen, welche die Ausführung des Modells beeinflussen. Ein als \textit{urgent} bezeichneter Channel sorgt beispielsweise dafür, dass Kanten die mit ihm markiert sind so schnell wie möglich abgelaufen werden. Zustände die als \textit{commited} (im Editor markiert mit einem C) oder als \textit{urgent} (im Editor markiert mit einem U) verbieten, dass in ihnen Zeit abläuft und ermöglichen so das Modellieren von unmittelbar aufeinander folgenden Ereignissen, wobei \textit{commited} noch restriktiver ist, da ein solcher Zustand im nächsten Übergang verlassen werden muss.\\
+\cref{konzept:uppaal_tor} zeigt beispielhaft ein modelliertes System eines automatischen Tores mit einem dazugehörigen Schlüssel. Beim probabilistischen Auslösen dieses Schlüssels (mit einer Wahrscheinlichkeit von 1:101) wird das Tor über den Channel \textit{auslösen} informiert, wechselt in den Zustand \textit{öffnend} und setzt die Variable "zeit" auf 0. Nach 10000 vergangenen Zeiteinheiten wechselt das Tor dann in den Zustand \textit{offen}. Das Schließen läuft analog dazu ab.
 \begin{figure}[h]
 	\centering
 	\includegraphics[scale=.4]{./uppaal_tor.png}
@@ -15,8 +17,9 @@ Invarianten können global oder nur in bestimmten Zuständen angegeben werden. \
 \end{figure}
 \subsection{TRON Adapter}
 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?}
-\url{http://graphwalker.github.io/}
+
+\section{GraphWalker}
+GraphWalker \footnote{\url{http://graphwalker.github.io/}} ist ein neueres Tool, welches auf eine möglichst einfache Bedienung ausgelegt ist. Zum Erstellen von Modellen gibt daher es einen grafischen Editor, welcher über einen Browser geöffnet werden kann. Die Modellierungsmöglichkeiten ähneln denen von Uppaal, wobei weniger Kontrolle über die Ausführung gegeben ist, da Kanten sofort abgelaufen werden, wenn sie verfügbar sind. Dafür können sowohl bei Übergängen als auch in Knoten Aktionen ausgeführt werden, welche durch JavaScript beschrieben sind. Dadurch können im Gegensatz zu Uppaal komplexere Zusammenhänge besser dargestellt werden. Online- und offline-Testen wird unterstützt, wofür eine REST- sowie Websocket-API zur Verfügung steht. Informationen werden dabei durch JSON übermittelt, was auch das Übertragen von komplexen Variablen ermöglicht. Eine Verifizierung eines erstellten Modells kann jedoch nur durch das Ablaufen dieses erfolgen, eine Möglichkeit zur formalen Validierung von Systemeigenschaften existiert nicht.
 
 \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