| ... | ... | @@ -66,19 +66,19 @@ Untenstehend ist noch einmal die Auflistung der Aufgabenpakete zu finden: |
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In dieser Abbildung ist der Systemkontext dargestellt. Die Middleware ist die Verbindung zwischen Accelorator und Anki Vector. Eine Person möchte online Teilnehmen und kommuniziert durch die den Vector mit den anderen Kursteilnehmenden. Auch wenn der Accelerator angepasst werden muss, ist dieser nicht in der Systemarchitektur vorhanden. Dies erleichtert die Darstellung. Genauere Informationen zu den Änderungen sind im Kapitel Accelerator präsentiert.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Anki_Gui verbindet den Vektor mit dem Accelerator Raum. Dabei wird eine Socketverbindung verwendet um den Vektor einzuloggen. Weiteres dazu steht in dem Kapitel Anki_Gui. Sobald ein Statusupdate gesendet wird, kann die Anki_Gui dieses als JSON-Datei empfangen. Die JSON-File wird verarbeitet und der Status wird extrahiert. Der Status kann mit der Funktion send_reaction_to_anki an die API des Ideationtable weitergegeben werden. Eine Funktion namens accelerator verwendet je nach Status eine der vorgegebenen Funktionen des Managers. Die ausführbaren Vectorfunktionen sowie die dazu gehörigen Bilddateien sind unter useCases auffindbar. Diese Funktionen binhalten die Regeln der Hierarchie der Animationen. Diese Hierarchieebenen werden unter Middleware weiter beschrieben. Die Befehle werden im Anschluss an den Vector weitergegeben.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Kommunikation der einzelnen Serverkomponenten und deren Ports ist in der oben angefügten Abbildung ersichtlich.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In dem oben aufgeführten Beispiel ist das Sequenzdiagramm für den Prozess Daumen hoch abgebildet.
|
|
|
|
Die online zugeschaltete Person betätigt den "Daumen hoch"-Knopf im Accelerator ist bereits festgelegt, dass diese Person mit dem Vector verbunden ist. Somit wird die Ausgabe nicht an den Raum, sondern an in einer JSON-Datei an das Anki_GUI Script weitergeleitet. Dieses formt die JSON um und bildet eine API Post Nachricht mit dem Inhalt der JSON-Datei, dem Userstatus "thumbsUP". Die API empfängt den Post und ruft je nach Inhalt der Nachricht eine Funktion des Managers auf. Die thumbsUp_accelerator Funktion wird verwendet um mit dem Manager den Bildschirm und die Motoren des Vectors zu steuern. Der Accelerator bekommt davon keine Rückmeldung.
|
| ... | ... | @@ -142,6 +142,7 @@ Der Weg einer Aktion auf dem Accelerator wird in Abbildung x dargestellt. Die m |
|
|
|
- chatmassage
|
|
|
|
- not-onscreen
|
|
|
|
- cancel
|
|
|
|
- silent
|
|
|
|
|
|
|
|
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.
|
| ... | ... | |
