|
|
|
|
|
|
|
|
|
|
|
#Inhaltsangabe
|
|
|
|
|
|
|
|
1. [Einleitung](#einleitung)
|
|
|
|
|
|
|
|
|
|
|
|
# Einleitung
|
|
|
|
Das Projekt "anki Vector Verbindung" wurde im Sommersemester 2022 von
|
|
|
|
|
| ... | ... | @@ -16,6 +21,23 @@ Der anki Vector ist ein Mini-Roboter der Firma DigitalDreamLabs. Eine kurze Vors |
|
|
|
Zielsetzung des Projektes war es, die Verbindung zwischen dem Accelerator und Vector herzustellen, um so die verschiedenen Reaktionen und Aktionen, die ein Nutzer im Accelerator durchführen kann, physisch abzubilden. Dies ist im Kontext von hybriden Teams eine denkbare Maßnahme, um die Awareness bezüglich einer nicht-anwesenden Person zu steigern. Mit dem Vector als Repräsentant für eine lokal entfernte Person kann dies gelingen und die Interaktion in der Gruppe verbessert werden, ohne dass sich mehrere Personen um einen Rechner o.ä. versammeln müssen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Anforderungen
|
|
|
|
* Accelerators muss den Vector in die Nutzerverwaltung aufnehmen können
|
|
|
|
* Vector muss jeden Raum betreten können
|
|
|
|
* ein Nutzer muss sich mit dem Vector verbinden können
|
|
|
|
* Nutzerbefehle müssen an den Vector geschickt werden können
|
|
|
|
* 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
|
|
|
|
|
|
|
|
## Projektplan
|
|
|
|
|
|
|
|
Neben der Verbindungsherstellung zwischen Vector und Accelerator sind auch die Animationen auszuarbeiten, welche für die verschiedenen Accelerator-Funktionen stehen sollen. Diese Aufgabenblöcke wurden zwischen den Teammitgliedern aufgeteilt. Der genaue Zeitplan inklusive Aufgabenverteilung ist untenstehend zu finden.
|
| ... | ... | @@ -34,26 +56,15 @@ Somit ergaben sich letztendlich die folgenden Aufgabenblöcke: |
|
|
|
6. Senden der Status an den Ideation Table
|
|
|
|
7. Dokumentation
|
|
|
|
|
|
|
|
# Anforderungen
|
|
|
|
* Accelerators muss den Vector in die Nutzerverwaltung aufnehmen können
|
|
|
|
* Vector muss jeden Raum betreten können
|
|
|
|
* ein Nutzer muss sich mit dem Vector verbinden können
|
|
|
|
* Nutzerbefehle müssen an den Vector geschickt werden können
|
|
|
|
* die Nutzerbefehle müssen alle von dem Vector umgesetzt werden können
|
|
|
|
#Softwarearchitektur
|
|
|
|
|
|
|
|
# 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
|
|
|
|
#Accelerator
|
|
|
|
|
|
|
|
#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
|
|
|
|
|
|
|
|
# Arbeit mit anki Vector
|
|
|
|
|
|
|
|
# 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
|
|
|
|
Dort steht auch eine ausführliche Beschreibung zur Installation und dem Setup mit Vector bereit.
|
| ... | ... | @@ -62,6 +73,16 @@ Es wurde der anki-Account des Ideation Table-Teams übernommen. Die Zugangsdaten |
|
|
|
## Vector Zertifikate
|
|
|
|
Das SDK muss korrekt auf dem zu verwenden PC installiert sein und die sdk_config.ini sowie das Zertifikat für den zu verwendenden Vector im Root-Verzeichnis des Benutzers /.anki-vector liegen, um eine Verbindung zu einem Vector-Roboter herstellen zu können.
|
|
|
|
|
|
|
|
|
|
|
|
#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
|
|
|
|
|
|
|
|
# Arbeit mit anki Vector
|
|
|
|
|
|
|
|
|
|
|
|
## Animationen
|
|
|
|
Für folgende Accelerator-Funktionen wurden Vector-Animationen erstellt:
|
|
|
|
|
| ... | ... | @@ -94,10 +115,30 @@ Im Großen und Ganzen konnte das Ideation Table-Projekt für die Verbindung zum |
|
|
|
Die für dieses Projekt angepasste Version ist auf dem Branch [ADD NAME] zu finden.
|
|
|
|
|
|
|
|
|
|
|
|
#Anpassungen an dem Accelorator
|
|
|
|
Alex dein Text dazu kann hier rein
|
|
|
|
### 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#Evaluation
|
|
|
|
|
|
|
|
# Setup
|
|
|
|
##
|
| ... | ... | @@ -128,28 +169,7 @@ Benötigte Dependencies: |
|
|
|
python-engineio, Version 3.14.2
|
|
|
|
python-socketio, Version 4.6.1
|
|
|
|
|
|
|
|
## Software
|
|
|
|
### 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ... | ... | |
