No commit message

No commit message

images/tron_adapter.h

@@ -72,7 +72,7 @@ inline bool read_4_bytes_nonblock(int fd, byte *buf);
  */
 int create_connected_socket(std::string IP, uint16_t port);
 
-// ----------------------------------------------------------------------------------------
+// --------------------------------------------------
 
 struct Channel {
     /**

sections/appendix.tex

+\chapter{Git-Repositorys}
+Das Repository für die actionlib-Integration sowie für das Testen des Cobots sind unter folgenden Links erreichbar:
+\begin{itemize}
+	\item \url{https://git-st.inf.tu-dresden.de/CS/actionlib_tron}
+	\item \url{https://git-st.inf.tu-dresden.de/CS/cobot1_tron_testing}
+\end{itemize}
+Die Adapter-Implementierung und jeweils genutzten Uppaal-Modelle (als XML-Datei) sind in beiden Fällen vorhanden. Beim Cobot sind außerdem die für die Test-Ausführung und -Analyse genutzten Bash-Scripts zu finden.
 \chapter{Header der Adapter-Implementierung}
 \lstset{
 	escapeinside={(@*}{*@)}

sections/fallbeispiel.tex

@@ -24,24 +24,24 @@ Das entsprechend erstellte Uppaal-Modell ist in \cref{integration:uppaal} zu seh
 Der Einsatz des Adapters erfolgt unter Verwendung von eigens für die Nachrichtentypen implementierten Callbacks statt der Zuweisung von Bytes. Dadurch können andere Bestandteile des Action-Protokolls wie die Header vernachlässigt werden. Weiterhin ist zu beachten, dass im Adapter die Nachrichten verwendet werden, die \textbf{Action} im Namen tragen (z.B. TriggerActionGoal, nicht TriggerGoal). Diese Nachrichten beinhalten neben den Daten auch Header- und Statusinformationen und müssen verwendet werden, wenn der Adapter selbst weder Client noch Server des Systems ist, sondern ersteren nur emuliert oder die Kommunikation beider Parteien abhört. Eine Implementierung des Adapters, welcher selbst einen Client darstellt wäre allerdings auch möglich. Die Namen der Topics sind aus dem Namen des Servers (wird bei Konstruktion übergeben) und dem Inhalt der Nachricht zusammengesetzt und können daher ohne Probleme verwendet werden. Die (nicht vollständige) Konfigurationsphase für den Adapter des in \cref{integration:uppaal} gezeigten Modells sieht wie folgt aus:
 \begin{lstlisting}[tabsize=1]
 	// oeffnen und schliessen stellt jeweils ein Ziel dar
-	Mapping map = Mapping("/garage_server/goal", "oeffnen", true);
+	Mapping map = adapter.createMapping("/garage_server/goal", "oeffnen", true);
 	map.input_callback = send_goal_open;
-	mappings.push_back(map);
+	adapter.mappings.push_back(map);
 	
-	map = Mapping("/garage_server/goal", "schliessen", true);
+	map = adapter.createMapping("/garage_server/goal", "schliessen", true);
 	map.input_callback = send_goal_close;
-	mappings.push_back(map);
+	adapter.mappings.push_back(map);
 	
 	// wichtig ist, dass die Queue ausreichend gross ist, falls TRON
 	// viele Inputs sendet (hier relativ unwichtig)
-	input_publishers.push_back(nh.advertise<actionlib_example::TriggerActionGoal>("/garage_server/goal", 100));
+	adapter.input_publishers.push_back(nh.advertise<actionlib_example::TriggerActionGoal>("/garage_server/goal", 100));
 	
 	// aktuelle Position wird per feedback zureckgegeben
 	// (wie bei result-Topic an Channel 'fertig')
-	map = Mapping("/garage_server/feedback", "position", false);
-	map.add_var_to_mapping("akt_position", 0);
-	mappings.push_back(map);
-	output_subscribers.push_back(nh.subscribe("/garage_server/feedback", 100, 
+	map = adapter.createMapping("/garage_server/feedback", "position", false);
+	adapter.add_var_to_mapping(map, "akt_position");
+	adapter.mappings.push_back(map);
+	adapter.output_subscribers.push_back(nh.subscribe("/garage_server/feedback", 100, 
 	feedback_callback));
 \end{lstlisting}
 Die hier verwendeten Callbacks \textit{send\_goal\_open(/close)} rufen die Funktion \textit{send\_goal} auf: