anki-Vector-Verbindung.md

@@ -7,7 +7,7 @@
    2\.1 [Anforderungen](#anforderungen)\
    2\.2 [Herausforderungen](#herausforderungen)\
    2\.3 [Projektplan](#projektplan)
-3. [Softwarearchitektur](#softwarearchitektur)
+3. [Systemarchitektur](#systemarchitektur)
 4. [Accelerator](#accelerator)
 5. [Anki Vector](#anki-vector)
 6. [Middleware](#middleware)
@@ -42,12 +42,12 @@ Zielsetzung des Projektes war es, die Verbindung zwischen dem Accelerator und Ve
 * die Nutzerbefehle müssen alle von dem Vector umgesetzt werden können
 
 ## Herausforderungen
-* Aktionen müssen ersichtlich sein
-* Aktionen dürfen nicht den Unterricht stören
-* Mit dem Bildschirm kann nur eine Aktion angezeigt werden
-* Vektor kann nicht im WLAN der Hochschule verwendet werden
-* Vector verbindet sich in unregelmäßigen Abständen neu
-* Vectors Anwendungen sind auf zeitlich festgelegte Animationen ausgelegt
+1. Aktionen müssen ersichtlich sein
+2. Aktionen dürfen nicht den Unterricht stören
+3. Mit dem Bildschirm kann nur eine Aktion angezeigt werden
+4. Vektor kann nicht im WLAN der Hochschule verwendet werden
+5. Vector verbindet sich in unregelmäßigen Abständen neu
+6. Vectors Anwendungen sind auf zeitlich festgelegte Animationen ausgelegt
 
 ## Projektplan
 
@@ -67,14 +67,19 @@ Somit ergaben sich letztendlich die folgenden Aufgabenblöcke:
 6. Senden der Status an den Ideation Table
 7. Dokumentation
 
-#Softwarearchitektur
+#Systemarchitektur
+Die Systemarchitektur beschreibt das Gesamtsystem Accelorator - Middleware - Anki Vector. 
+In den folgenden Kapiteln wird genauer auf die einzelnen Bestandteile eingegangen. In den Anforderungen ist aufgeführt, dass der Vector von einem Nutzer gesteuert werden muss. Da eine direkte Steuerung des Vectors seitens des Accelerator nicht möglich ist, wird eine Middleware verwendet. 
+Bild Softwaresystemarchitektur
+
+
+
 
 #Accelerator
 
 
 
 # Anki Vector
-## Beschreibung Vector
 
 ## Setup des Vectors
 DigitalDreamLabs stellt eine Vector SDK in Python bereit, welche die Ansteuerung und Programmierung des Roboters ermöglicht. Sie ist unter folgendem Link zu finden: https://developer.anki.com/vector/docs
@@ -87,9 +92,35 @@ Das SDK muss korrekt auf dem zu verwenden PC installiert sein und die sdk_config
 
 #Middleware
 
-#Vorgehen
-(Notizen für den Text )
-Vektor muss in lokalem Wlan angesteuert werden --> dementsprechend brauchen wir eine Middleware, die sich mit dem Accelorator verbinden kann. weiterer Text
+##Empfangen der Accelorator Befehle
+
+## Management der Animationen
+Der Weg einer Aktion auf dem Accellerator wird in Abbildung x dargestellt. Die möglichen Animationen sind unter Animationen aufgelistet. Eine Herausforderung ist es, die normalen Vektoranimationen mit festen Start und Endzeitpunkt beliebig lange abzuspielen. Hierzu wird ein Eventmanagement benötigt. Dazu bieten sich die Optionen der eventbasierten Programmierung oder eine Thread-basierte Programmierung an. Beide Varianten wurden ausgiebig getestet. Im Zuge der Arbeit fördert ein Manager die stabilsten Ergebnisse. Dieser ähnelt einer State-Machine, die je nach Status eine Aktion ausführt. Folgende Stati sind vorhanden:
+- thumbup
+- thumbdown
+- handup
+- applause
+- coffee
+- chatmassage
+- silence
+- not-onscreen
+- cancel
+
+Jede Animation hat einen eigenen Status. Trotz Management können die Übergänge zwischen Bildschirmanzeigen des Vectors nicht fließend gestaltet werden. Dies lässt die Codestruktur nicht zu.
+Demzufolge muss es eine Option geben einen vorherigen Status nicht nur abzubrechen, sondern den Vector anderen Aktionen wieder zur Verfügung zu stellen. Der Status Cancel bricht die vorherige Aktion ab und hinterlässt den Vector in einem Idle Status. Bei jeder Cancel-Aktion werden sowohl die Motoren als auch der Bildschirm auf den Normalstatus gesetzt. Da es keine feste Funktion für das zurücksetzen des Bildschirm gibt, wird eine kurze unaufällige Animation verwendet um den Bildschirm zu bereinigen. Damit sieht ein Wechsel zwischen zwei Bildschirmanimationen wie in Abbildung z gezeigt aus. 
+
+Der Vector kann nur begrenzt Aktionen anzeigen. Eine Verbindung mehrerer Aktionen kann andere Aktionen verdecken. Deshalb zeigt der Vector nur eine Aktion zu einem Zeitpunkt an. Über den Accelerator können jedoch mehrere Tasten gleichzeitig ausgelöst werden. Hierzu muss eine Hierarchie der Funktionen festgelegt werden. In der unten angefügten Abbildung sind die 5 Hierarchieblöcke dargestellt. 
+Der Abbruch einer Aktion muss immer möglich sein. Dementsprechend gehört der Abbruchaktion die höchste Hierarchieebene. Sobald der Zuhörer seine Lautsprecher auf lautlos gestellt hat, kann keine effektive Kommunikation stattfinden. Demzufolge beinhaltet die zweite Hierarchieebene die silence Aktion. Ähnliches gilt für die Pause. Diese wird durch coffee (im Code break genannt) in der dritten Hierarchieebene abgebildet. Auch wenn ein nicht anwesender Zuhörer genauso wenig von der Vorlesung mitbekommt wie ein Zuhörer mit ausgestellten Lautsprechern, sind die Funktionen in verschiedene Hierarchieebenen unterteilt da bei aktivierten Lautsprechern der Zuhörer auditiv auf den Coffee Zustand aufmerksam gemacht werden kann. In der vierten Hierarchieebene finden sich bis auf not-onscreen (im Code afk) alle weiteren Aktionen. Dies basiert auf der Annahme, dass ein Nutzer, der eine Aktion ausführt nicht afk sein kann. 
+
+| Animation | Hierarchieebene |
+| ------ | ------ |
+| cancel | 1 |
+| silence | 2 |
+| coffee | 3 |
+| applause, chatMessage, handup, thumbsUp, thumbsDown | 4 |
+| not-onscreen | 5 |
+
+
 
 # Arbeit mit anki Vector
 
@@ -128,25 +159,6 @@ Die für dieses Projekt angepasste Version ist auf dem Branch [ADD NAME] zu find
 
 ### Verbindung der einzelnen Komponenten
 
-### Management der Animationen
-In den oberen Absätzen wird das Setup der einzelnen Softwarekomponenten beschrieben. Der Weg einer Aktion auf dem Accellerator wird in Abbildung x dargestellt. Die möglichen Animationen sind unter Animationen aufgelistet. Eine Herausforderung ist es, die normalen Vektoranimationen mit festen Start und Endzeitpunkt beliebig lange abzuspielen. Hierzu wird ein Eventmanagement benötigt. Hierzu bieten sich die Optionen der eventbasierten Programmierung oder eine Thread-basierte Programmierung an. Beide Varianten wurden ausgiebig getestet. Im Zuge der Arbeit fördert ein Manager die stabilsten Ergebnisse. Dieser ähnelt einer State-Machine, die je nach Status eine Aktion ausführt. Folgende Stati sind vorhanden:
-- thumbup
-- thumbdown
-- handup
-- applause
-- coffee
-- chatmassage
-- silence
-- not-onscreen
-- cancel
-
-Jede Animation hat einen eigenen Status. Trotz Management können die Übergänge zwischen Bildschirmanzeigen des Vectors nicht fließend gestaltet werden. Dies lässt die Codestruktur nicht zu.
-Demzufolge muss es eine Option geben einen vorherigen Status nicht nur abzubrechen, sondern den Vector anderen Aktionen wieder zur Verfügung zu stellen. Der Status Cancel bricht die vorherige Aktion ab und hinterlässt den Vector in einem Idle Status. Bei jeder Cancel-Aktion werden sowohl die Motoren als auch der Bildschirm auf den Normalstatus gesetzt. Damit sieht ein Wechsel zwischen zwei Bildschirmanimationen wie in Abbildung z gezeigt aus. 
-
-Der Vector kann nur begrenzt Aktionen anzeigen. Eine Verbindung mehrerer Aktionen kann andere Aktionen verdecken. Deshalb zeigt der Vector nur eine Aktion zu einem Zeitpunkt an. Über den Accelerator können jedoch mehrere Tasten gleichzeitig ausgelöst werden. Hierzu muss eine Hierarchie der Funktionen festgelegt werden. In der unten angefügten Abbildung sind die 5 Hierarchieblöcke dargestellt. 
-Der Abbruch einer Aktion muss immer möglich sein. Dementsprechend gehört der Abbruchaktion die höchste Hierarchieebene. Sobald der Zuhörer seine Lautsprecher auf lautlos gestellt hat, kann keine effektive Kommunikation stattfinden. Demzufolge beinhaltet die zweite Hierarchieebene die silence Aktion. Ähnliches gilt für die Pause. Diese wird durch coffee (im Code break genannt) in der dritten Hierarchieebene abgebildet. Auch wenn ein nicht anwesender Zuhörer genauso wenig von der Vorlesung mitbekommt wie ein Zuhörer mit ausgestellten Lautsprechern, sind die Funktionen in verschiedene Hierarchieebenen unterteilt da bei aktivierten Lautsprechern der Zuhörer auditiv auf den Coffee Zustand aufmerksam gemacht werden kann. In der vierten Hierarchieebene finden sich bis auf not-onscreen (im Code afk) alle weiteren Aktionen. Dies basiert auf der Annahme, dass ein Nutzer, der eine Aktion ausführt nicht afk sein kann. 
-
-![HierarchieAktionen](uploads/636d7319205896af9ff66a79f0473748/HierarchieAktionen.png)
 
 
 #Evaluation