Softwareumgebung: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 128: | Zeile 128: | ||
Damit der Datenaustausch Prozess- und Plattform-übergreifend stattfinden kann, muss vereinbart werden, wie die Daten im Datenbereich eines UDP-Paketes abzulegen sind. Jedes Paket hat mindestens ein 16-Bit großes, <code>unsigned int</code>-Feld mit einer ID, die angibt, welche Daten folgen. Danach, folgt dann die, für die entsprechende ID festgelegt Datenstruktur. Einige Datenstrukturen sind bereits festgelegt, wie etwa die Struktur zum erfassen einer Ballposition, oder die Struktur zum erfassen der Spielstangenpositionen. Weitere Strukturen können nach belieben hinzugefügt werden. |
Damit der Datenaustausch Prozess- und Plattform-übergreifend stattfinden kann, muss vereinbart werden, wie die Daten im Datenbereich eines UDP-Paketes abzulegen sind. Jedes Paket hat mindestens ein 16-Bit großes, <code>unsigned int</code>-Feld mit einer ID, die angibt, welche Daten folgen. Danach, folgt dann die, für die entsprechende ID festgelegt Datenstruktur. Einige Datenstrukturen sind bereits festgelegt, wie etwa die Struktur zum erfassen einer Ballposition, oder die Struktur zum erfassen der Spielstangenpositionen. Weitere Strukturen können nach belieben hinzugefügt werden. |
||
In der aktuellen Implementierung, gibt es |
In der aktuellen Implementierung, gibt es vier grundlegende Arten von Paketen. Sie unterscheiden sich weniger in der Struktur als in ihrer Behandlung beim Empfänger: |
||
;Alive-Pakete |
|||
:Sie dienen zum Überprüfen ob der Kommunikationspartner verfügbar ist. |
|||
:Nach der ID folgt ein long-Wert, welcher als eindeutige Kennung dient. |
|||
:Auf eine Alive-Anfrage, sollte eine Alive-Antwort, mit dem gleichen long-Wert als Kennung zurückgesendet werden. |
|||
:Beispiel: [[Softwareumgebung#Spielsteuerung|Spielsteuerung]] überprüft ob die [[Softwareumgebung#SPSchnittstelle|SPSchnittstelle]] verfügbar ist. |
|||
;Anfrage-Pakete |
;Anfrage-Pakete |
||
Zeile 150: | Zeile 156: | ||
=== Aufbau der Datenpakete === |
=== Aufbau der Datenpakete === |
||
Im [https://kicker.ee.hm.edu/svn/trunk/ProCK-KI-new-TEST/Interprozesskommunikation/ SVN] sind Beispielimplementationen für verschiedene, denkbare Kommunikationspartner abgelegt. Diese |
Im [https://kicker.ee.hm.edu/svn/trunk/ProCK-KI-new-TEST/Interprozesskommunikation/ SVN] sind Beispielimplementationen für verschiedene, denkbare Kommunikationspartner abgelegt. [https://kicker.ee.hm.edu/svn/trunk/ProCK-KI-new-TEST/Interprozesskommunikation/CompleteClient/ CompleteClient] und [https://kicker.ee.hm.edu/svn/trunk/ProCK-KI-new-TEST/Interprozesskommunikation/CompleteServer/ CompleteServer] sind vollständig implementierte Kommunikationspartner, bei denen alle Datenpakete implementiert sind. Diese sollten als Grundlage für ein neues Programm in der Softwareumgebung herangezogen werden. |
||
=== Beispiel der IPC zwischen Ballerkennung und Spielsteuerung === |
=== Beispiel der IPC zwischen Ballerkennung und Spielsteuerung === |
Version vom 8. Januar 2013, 13:44 Uhr
Um den Kicker zu betreiben, sind drei grundlegende Software-Komponenten nötig. Die SPS (TwinCAT), die Ballerkennung und die Spielsteuerung. Um den Zugriff auf die SPS, für die anderen Programme zu vereinfachen, gibt es die SPSchnittstelle.
TwinCAT
TwinCAT ist eine Software-SPS der Firma Beckhoff Automation. Sie bietet sowohl die Funktionalität einer SPS, sowie einer numerischen Bahnregelung (NC), zur Regelung der Elektromotoren. TwinCAT läuft unter Windows XP und erweitert dieses um eine echtzeitfähige Laufzeitumgebung. Es wird TwinCAT NC PTP (Numerical Control, Point-To-Point) in der Version 2.10.0 verwendet. Als Schnittstelle zur SPS, steht ADS zur Verfügung.
Die Programmierung erfolgte in "Strukturierter Text" und ist im SVN abgelegt. Programmierer war hier Karsten Schätzle, die Umsetzung geschah 2010 als Teil der Diplomarbeit "Entwicklung, Aufbau und Programmierung eines mehrachsigen Antriebskonzeptes mit überlagerten Bewegungen".
SPSchnittstelle
Um den Zugriff auf die SPS zu vereinfachen, wurde die SPSchnittstelle programmiert. Sie übersetzt die ADS-Schnittstelle und stellt ein UDP-Server dar, um eine einheitliche Interprozesskommunikation im Projekt zu gewährleisten.
Die Programmierung erfolgte in C/C++ und ist im SVN abgelegt. Programmierer war hier Karsten Schätzle (erste Version, mit TCP-IP), die Umsetzung geschah 2010 als Teil der Diplomarbeit "Entwicklung, Aufbau und Programmierung eines mehrachsigen Antriebskonzeptes mit überlagerten Bewegungen". Die Umstellung auf UDP erfolgte von Scharel Clemens.
Ballerkennung
Die Ballerkennung ermittelt die Ballposition auf dem Spielfeld mit Hilfe von zwei Embedded-Kameras im 10ms-Takt. Die Position des Balls wird mittels einer Visualisierung am Bildschirm dargestellt und für weitere Programme per UDP-Server zur Verfügung gestellt.
Die Programmierung erfolgte in C/C++ und ist im SVN abgelegt. Programmierer war hier Manuel Zimmermann (erste Version, mit Shared Memory), die Umsetzung geschah 2009 als Teil der Diplomarbeit "Computergestützte visuelle Positionsbestimmung durch Triangulation in zwei Dimensionen". Die Umstellung auf UDP erfolgte von Manuel Zimmermann und Scharel Clemens.
Spielsteuerung
Die Spielsteuerung, ist das Programm, welches die Spielzüge bestimmt. Sie berechnet, mit Hilfe der Ball- und Spielstangenpositionen, welche Bewegungen als nächstes auszuführen sind. Sie stellt also die künstliche Intelligenz dar.
Die Programmierung erfolgte in C++ und ist im SVN abgelegt. Programmierer war hier Scharel Clemens, die Umsetzung geschah 2012 als Teil der Diplomarbeit "Konzeption einer Softwareumgebung zur intelligenten Ansteuerung eines automatisierten Tischkickers".
Dokumentation
Der Quellcode ist recht ausführlich kommentiert und fast vollständig mit Doxygen-Kommentaren versehen. Aus dem Quellcode lässt sich mit Hilfe von Doxygen eine vollständige Dokumentation der Klassen und Prozeduren extrahieren. Das entsprechende Doxyfile liegt im gleichen Ordner wie der Quellcode. Die Ausgabe erfolgt in drei Formaten: html, latex/pdf und rtf.
Programmablauf
Aus der Dokumentation und des Quellcodes alleine, ist der Programmablauf nur schwer ersichtlich. Deshalb wird dieser hier, mit Hilfe von Sequenzdiagrammen beschrieben. Der allgemeine Programmablauf, ist diesem Sequenzdiagramm zu entnehmen. Es erläutert, welche Klasse wann erzeugt und welche Memberfunktionen wann aufgerufen werden. Die eigentliche Funktionalität (Fahrbefehle für die Spielstangen) befindet sich in der Funktion runAgent()
, der Klasse AxisAgent
. Es gibt vier Instanzen dieser Klasse, und somit 4 Threads, in denen die Funktion runAgent()
parallel ausgeführt wird. Jede Instanz ist für eine Spielstange zuständig.
Die Sequenzdiagramme sind ebenfalls im Microsoft Visual Studio-Format im SVN beim Quellcode abgelegt.
Jedes mal, wenn sich die Ballposition verändert, wird die Funktion ballUpdate()
der Klasse KnowledgeBase
aufgerufen. Wenn sich eine Spielstangenposition ändert, wird die Funktion axisUpdate(Gamer gamer, Axis axis)
, ebenfalls der Klasse KnowledgeBase
aufgerufen. Die Parameter gamer
und axis
, geben an, welche Spielstange sich bewegt hat. Diese Funktionen sind momentan noch leer, können aber später für eine Triggerung und zum Datenabgleich verwendet werden.
Konfiguration
Um konstante Daten nicht fest im Quellcode einprogrammieren zu müssen, gibt es zwei Konfigurationsdateien.
Als Dateiformat wird XML gewählt. Die erste Datei heißt config.xml
und ist im relativen Ordner (gegenüber dem Ausführungsverzeichnis) config/
abgelegt. Das Attribut file
vom Element startup
gibt den Dateinamen der zweiten Datei an. Diese liegt im gleichen Ordner wie die erste Datei und beinhaltet die eigentliche Konfiguration.
Das Zwei-Dateien-System erlaubt es verschiedene Profile, für verschiedene Laufzeitumgebungen (z.B.: verschiedene Server-Adressen der Ballerkennung/SPSchnittstelle) anzulegen. Die file
-Elemente innerhalb profiles
, geben an, welche weiteren Dateien/Profile zur Verfügung stehen.
Die Daten werden von der Klasse Config
verwaltet. Als Interpreter für die Dateien, wird TinyXML verwendet.
Aufbau von config/config.xml
<?xml version="1.0" encoding="utf-8" ?>
<config>
<!-- Konfiguration die beim Programmstart geladen werden soll -->
<startup file="default.xml" />
<!-- Alle verfügbaren Konfigurationsdateien -->
<profiles>
<file name="default.xml" />
<file name="localhost.xml" />
<file name="localhost_kickerAndBallAtProck-Kicker.xml" />
</profiles>
</config>
Aufbau von config/[DATEINAME].xml
Der Aufbau der zweiten Konfigurationsdatei, ist hier erläutert.
Exception Beschreibungen
In der Spielsteuerung sind, zur Fehlerbehandlung während der Laufzeit, Exceptions implementiert. Aktuell, können Exceptions geworfen werden, es gibt jedoch noch keine sinnvolle Behandlung. Es wird lediglich eine Nachricht in der Konsole ausgegeben. Die Exceptions beinhalten einen Fehler-Code, für den in der Datei config/exception.xml
die Beschreibungen hinterlegt sind.
<?xml version="1.0" encoding="utf-8" ?>
<exceptons>
<ex_000 desc="Es liegt kein Fehler vor!" />
<ex_001 desc="Es ist ein unbekannter Fehler aufgetreten!" />
<ex_002 desc="Es liegt ein Problem mit einer Datei vor!" />
<ex_003 desc="Es liegt ein Problem mit einer Configuration vor!" />
<ex_004 desc="Es liegt ein Problem mit einem Mutex vor!" />
<ex_004 desc="Timeout beim Warten auf ein Mutex!" />
<ex_006 desc="Es konnte eine Host-Adresse nicht aufgelöst werden!" />
<ex_007 desc="Es liegt ein Problem mit einem Thread vor!" />
<ex_100 desc="Es liegt ein allgemeines Problem mit der Ballerkennung vor!" />
<ex_200 desc="Es liegt ein allgemeines Problem mit dem SPServer vor!" />
<ex_201 desc="Es scheint eine Spielstange hängen geblieben zu sein!" />
<ex_300 desc="Es liegt ein allgemeines Problem mir der Wissensbasis vor!" />
<ex_301 desc="Es liegt ein Problem mit einem System-Zustand vor!" />
</exceptons>
Interprozesskommunikation
Für die Interprozesskommunikation (nachgehend mit "IPC" abgekürzt) wird das Netzwerkprotokoll UDP verwendet. Im Datenbereich der UDP-Pakete, ist ein übergeordnetes, eigenes Protokoll aufgesetzt.
Server/Client
Eine Kommunikation findet immer zwischen zwei Parteien statt. Dabei unterscheidet man zwischen Server- und Client-Applikationen.
- Server:
- SPSchnittstelle
- Ballerkennung
- Client:
- Spielsteuerung
- OpenGL_Grafik
Die Server-Programme sind hier diejenigen, die den Zugriff auf die reale Welt ermöglichen. Die Client-Programme benutzen die, zur Verfügung gestellten Daten um diese auszuwerten und ggf. in das Geschehen einzugreifen (per Kommando an den Server).
Aufgesetztes Protokoll
Damit der Datenaustausch Prozess- und Plattform-übergreifend stattfinden kann, muss vereinbart werden, wie die Daten im Datenbereich eines UDP-Paketes abzulegen sind. Jedes Paket hat mindestens ein 16-Bit großes, unsigned int
-Feld mit einer ID, die angibt, welche Daten folgen. Danach, folgt dann die, für die entsprechende ID festgelegt Datenstruktur. Einige Datenstrukturen sind bereits festgelegt, wie etwa die Struktur zum erfassen einer Ballposition, oder die Struktur zum erfassen der Spielstangenpositionen. Weitere Strukturen können nach belieben hinzugefügt werden.
In der aktuellen Implementierung, gibt es vier grundlegende Arten von Paketen. Sie unterscheiden sich weniger in der Struktur als in ihrer Behandlung beim Empfänger:
- Alive-Pakete
- Sie dienen zum Überprüfen ob der Kommunikationspartner verfügbar ist.
- Nach der ID folgt ein long-Wert, welcher als eindeutige Kennung dient.
- Auf eine Alive-Anfrage, sollte eine Alive-Antwort, mit dem gleichen long-Wert als Kennung zurückgesendet werden.
- Beispiel: Spielsteuerung überprüft ob die SPSchnittstelle verfügbar ist.
- Anfrage-Pakete
- Sie fordern Informationen vom Kommunikationspartner.
- Nach der ID folgt ein Bitfeld, wo jedes Bit für ein bestimmtes Informations-Paket steht.
- Die Antwort ist in der Regel ein Informations-Paket.
- Beispiel: Spielsteuerung fragt den Spielstand bei der SPSchnittstelle ab.
- Abonnement-Pakete
- Sie abonnieren Informationen vom Kommunikationspartner.
- Nach der ID folgt ein boolescher Wert, welcher das Abonnement entweder abschließt (
true
) oder kündigt (false
). - Danach wird von der Gegenseite jedes mal ein Informations-Paket gesendet, wenn sich der abonnierte Wert entweder verändert hat (z.B.: Spielstand) oder neu ermittelt wurde (z.B.: Ballposition).
- Beispiel: Spielsteuerung abonniert die Ballposition bei der Ballerkennung.
- Informations-Pakete
- Sie beinhalten Informationen über die Umwelt.
- Nach der ID folgt ein bestimmter Datentyp oder eine Struktur, je nach Festlegung für die ID.
- Ist in der Regel die Antwort auf ein Anfrage-Paket oder ein abonnierter Wert.
- Beispiel: SPSchnittstelle sendet den Spielstand an die Spielsteuerung.
Aufbau der Datenpakete
Im SVN sind Beispielimplementationen für verschiedene, denkbare Kommunikationspartner abgelegt. CompleteClient und CompleteServer sind vollständig implementierte Kommunikationspartner, bei denen alle Datenpakete implementiert sind. Diese sollten als Grundlage für ein neues Programm in der Softwareumgebung herangezogen werden.
Beispiel der IPC zwischen Ballerkennung und Spielsteuerung
Dieses Sequenzdiagramm beschreibt den sequentiellen Ablauf der IPC zwischen Spielsteuerung und Ballerkennung, innerhalb der Spielsteuerung.