Tanzlehrer
Aus Hansa-Wiki
Wegen des Abiballs haben wir uns für einen Roboter entschieden, der die Abiturienten in Sachen Paartanz und Kleidung vorbereitet. Der Roboter könnte jedoch auch für ähnliche Veranstaltungen benutzt werden.
Inhaltsverzeichnis |
Ursprüngliche Planung
Geplant ist ein Roboter, der einer größere Gruppe gleichzeitig Tanzunterricht und Modeberatung anbieten kann. Er sollte sowohl die Schritte erklären als auch "vortanzen" können und den Gruppenmitgliedern Hilfe bei der Wahl ihrer Kleidung bieten.
Hier die Grundschritte der Tänze, die der Nutzer am Ende der Ausführung beherrscht bzw. beherrschen sollte:
Theoretische Probleme
Hier eine Auflistung der Dinge, die uns bereits bei der Planung als eventuelle Hindernisse und Schwächen ins Auge gefallen sind.
- Nur eine Person kann Gruppensprecher sein. (Mikrophonproblem)
- Roboter muss auf unterschiedliche Kleidung eingehen. (Speicher?)
- Roboter müsste eigene Vorstellungen haben, was zusammenpasst und was nicht.
- Roboter müsste Vorschläge anbieten können. (Datenbank?)
- Starten der Musik. (manuell?)
- Seitwärtsschritte beim Cha-Cha-Cha nötig. (Konstruktion möglich?)
Umsetzung in DialogOS
Bevor wir begannen, die Dialoge auszuarbeiten, entschlossen wir, einen einzigen Gruppensprecher zu nominieren, wobei dieser als einziges ein Mikrophon bekommen sollte, damit bei einem potentiellen Durcheinanderreden DialogOS keine falschen Sprachmuster erkennt und damit einen ungewollten Zweig im Programm auslösen kann. Die Ratschläge, die der Roboter jedoch von sich gibt, sollten im Idealfall über einen Lautsprecher ausgegeben werden, damit alle Gruppenmitglieder die Anweisungen hören können.
Eine unbestreitbare Schwäche dieses Systems ist wohl, dass die Gruppenmitglieder mit dem Gruppensprecher kommunizieren müssen und somit die Antwort an den Roboter aufeinander abstimmen müssen.
Zum Ende dieser Phase hin bekam der Roboter übrigens auch den festen Namen "Floh". (Wahrscheinlich, weil es sich mit einem speziellen Namen bei Bedarf ein wenig besser fluchen lässt.)
Hier kann man sich die XML-Datei anschauen, die den vollständigen Code für das DialogOS-Programm enthält.
Tanzunterricht
Wir hatten uns darauf geeinigt, die Zuhörer über das Dialogsystem entscheiden zu lassen, welchen Tanz sie zuerst auswählen wollen, ob sie überhaupt tanzen wollen und wenn, dann vielleicht nur einen einzigen. Allein das sorgte bereits für drei komplexe Zweige des Gesamtprogramms, da bei eventuell nicht verstandenen Erklärungen Wiederholungen der Schritte und Übungsphasen eingebaut werden müssen.
Erste Improvisationen
Nachdem wir mehrere Versuche gestartet hatten, die Einleitung möglichst locker und ungezwungen zu schreiben, fiel uns auf, dass die Dialoge sehr kompliziert und ausführlich werden würden. Umso deutlicher wurde, dass Erklärungen (so z.B. von Tanzschritten) schnell langweilig werden können. Also kürzten wir fürs Erste die Herrenschritte auf Andeutungen und Verweisen auf die Schritte der Damen. Das bedeutet, dass die Herren bereits zuhören müssen, wenn ihre Partnerinnen üben, damit sie letzten Endes die Schrittfolge spiegelverkehrt tanzen können. Das bedeutet zwar einen Nachteil für den männlichen Tänzer, doch mit ein wenig Umdenken von Seiten des Nutzers sollte das Erlernen der Tänze trotzdem möglich sein. Die Schritte an sich sind schließlich dieselben - sie werden nur versetzt getanzt.
Nachtrag: Beim Cha-Cha-Cha haben wir uns entgegen unserer Bedenken jetzt doch für die Darstellung der Herrenschritte entschieden.
Grammatiken
Die Grammatiken, die uns aufgrund fehlender Variablenüberprüfung eine Weile geärgert haben, stellten nach einem kurzen Hinweis einer anderen Gruppe, die dasselbe Problem hatte, kein Problem mehr dar. Wir kommen glücklicherweise mit zwei einander ähnelnden Grammatikenstrukturen aus. Wir werden hier die ausführlichere vorstellen.
language "Deutsch";
root $verstanden;
$verstanden = $klar {$="klar"}
| $ja {$="ja"}
| $nein {$="nein"};
$klar = ( verstanden
| klar
| kapiert
| okay)
{$="klar"};
$ja = ( ja
| jo
| jepp
| jap
| okeh
| jau
| jup)
{$="ja"};
$nein = ( nein
| nö
| nee
| nä)
{$="nein"};
DialogOS Screenshots
Nach einigen, kleinen Frustrationsphasen wegen Grammatiken und Variablenerkennung ordneten wir das Gewirr, das später einmal unser Hauptdialog werden sollte, mit Unterordnern und Sprüngen zu einem einigermaßen übersichtlichen Anblick.
 Begrüßung |
 Chachacha (ohne Bricxaufrufe) |
 Discofox (ohne Bricxaufrufe) |
 Mambo (ohne Bricxaufrufe) |
Man kann an den Bildern das Problem erkennen, die wir schon am Anfang erwähnt haben. Der Roboter führt einige Zeit lang einen Monolog, wenn er verschiedene Schritte erläutert. Die Gefahr besteht also nach wie vor, dass der Roboter einfach weiterredet, auch wenn niemand mehr zuhört.
Aus diesem Grund haben wir hin und wieder bei Spracheingabefenstern ein Zeitlimit angelegt, nach dessen Ablauf "Floh", also der Roboter, "beleidigt" ist und das Programm beendet.
Modeberatung
Die Modeberatung, die wir am Anfang des Projektes als kurzen Epilog an das Ende des Tanzunterrichtes hängen wollten, entpuppte sich letztendlich als zu zeitraubend für eine Ausführung. Trotzdem möchten wir an dieser Stelle darstellen, was wir uns unter diesem Teil des Projektes vorgestellt und bereits ausgedacht haben.
Der Roboter gibt bei diesem Teil - wie sollte es auch anders sein - (mehr oder weniger ernst gemeinte) Tipps zum Erscheinungsbild bei einem Ball. Dabei wird mit entsprechenden Fragen herausgefunden, wie der Gesprächspartner des Roboters aussieht, um dann individuelle Empfehlungen zu geben. Kern des Systems sollte eine Datenbank werden, aus der Floh die Informationen und entsprechende Antwort- und Empfehlungsmöglichkeiten präsentiert.
Dazu haben wir bereits folgende nicht ganz ausgearbeitete Entwürfe erstellt.
| Größe | Flohs Kommentar |
|---|---|
| über 1.684 m | "Du solltest keine Schuhe mit hohen Absätzen tragen." |
| unter 1.684 m | "Na, du laufender Meter. Trag mal lieber hohe Schuhe, sonst gehst du ganz unter in der Menschenmenge." |
| Augenfarbe | Flohs Kommentar |
|---|---|
| blau | "Uih! Toll! Dazu passt ein blaues Kleid!" |
| blaugrau | "Konntest dich wohl nicht entscheiden, wie? Das passt jetzt gar nicht in mein Weltbild..." |
| andere | "Ich kann so nicht arbeiten! Sag die Wahrheit! Hast du Kontaktlinsen drin?" |
| Haarfarbe | Flohs Kommentar |
|---|---|
| blond | "Wirklich natur? Oder gehörst du zu den gefärbten Wasserstoffblondinen?" |
| braun | "Du solltest auf keinen Fall ein schwarzes Kleid tragen!" |
| weiß | "Hmm... Wenn du dir dort blaue Strähnchen hineinmachst, passt ein violettes Kleid zu dir." |
| rot | "Hey, Pippi Langstrumpf! Als Frisurvorschläg hätte ich zwei geflochtene Rattenschwänze. Ein gepunktetes Kleid wäre passend dazu. Die Farbe lasse ich dich entscheiden. Bei rot kann man zu viel falsch machen, da traue ich mich nicht, Verantwortung zu übernehmen." |
Konstruktion des Roboters
Planung
Zu Beginn dieser Phase diskutierte unsere Gruppe natürlich über den genauen Aufbau. Besonders interessant war hierbei wie der Roboter gleichzeitig in der Lage sein würde, vorwärts, rückwärts und seitwärts zu gehen. Dabei kamen uns folgende Ideen, die demnächst jedoch systematisch ausgeschlossen werden.
- Der Roboter bewegt sich mit Schritten nach vorn, d.h. die "Füße" werden groß genug konstruiert, dass einer allein das Gleichgewicht halten kann. Für die Bewegungen zur Seite werden Rollen unter den Füßen angebracht. Diese sind zur Seite ausgerichtet und blockieren bei Schritten nach vorn, würden also bei Vorwärtsbewegungen kein Problem darstellen. Wenn entsprechende Schritte erforderlich sind, "rollt" der Roboter seitwärts.
- Der Roboter besitzt eine Art Kugelgelenk an der Hüfte, mit der er seine Beine zur Seite und nach vorn drehen kann. Es wären dann nur Vorwärtsschritte zu planen, weil das Gelenk die Füße dann zur Seite ausrichtet. Allerdings ist fraglich, ob das ausführbar ist.
- Der dritte Vorschlag basiert auf vier Rollen unter bzw. an jedem Fuß. Jeweils zwei zeigen nach vorn und zur Seite. Wenn die Bewegung nach vorn gestartet wird, werden die blockierenden Seitwärtsräder aus dem Weg genommmen (z.B. durch hochziehen o.Ä.). So rollt der Roboter sowohl nach vorn als auch nach hinten.
Bauliche Umsetzung
Den Vorschlag, den wir letztendlich umgesetzt haben, stammt zum großen Teil aus dem Internet und benötigte sowohl den Standardkasten als auch ein Erweiterungsset. Die humanoide Form des Roboters "Alpha Rex" passte sehr gut zu unseren Vorstellungen. Allerdings werden wir ihn im Nachhinein wohl noch modifizieren, weil wir noch nicht wissen, ob der Roboter, so wie er jetzt ist, unsere Schritte beherrscht.
Ein Problem ergab sich selbst hier beim Bau "nach Anleitung": Der Akkukasten, der hinten an die Brick angesetzt wird, ist zu breit für die Konstruktion. Wir werden ohne die Abdeckung, also mit "offenem Rücken" und mit Batterien arbeiten müssen. Zudem sind die Arme ein wenig instabil - mit dem Effekt, dass der Arm mit dem Tastsensor immer mal wieder abspringt.
Die Bedenken, die wir bereits bei der Planung hatten, was das Seitwärtsgehen betrifft, wurden durch die Gewichtsverlagerung dieses Modells teilweise zerstreut. "Floh" geht in dieser Gestalt zwar nicht seitwärts, doch er ist in der Lage von einer Seite zur anderen zu "schaukeln" und damit wenigstens diese Seitwärtsbewegung zu simulieren. Eine Erklärung für das Fehlen der Seitwärtsschritte wird in Form einer Geschichte in die DialogOS-Komponente eingebaut.
Die Bauanleitung für diesen Roboter kann man hier downloaden.
Programmierung mit Bricx
Die Programmierung des Roboters schoben wir an das Ende des Projektes, da wir mit Bricx ja bereits gearbeitet hatten und uns die Tanzschritte als nicht so kompliziert bekannt waren. Allerdings hatten wir nicht bedacht, wie genau der Roboter konstruiert ist.
Der Alpha Rex läuft über drei Motoren. Der Motor A ist für die Bewegung der Beine zuständig, während der Motor C die Hüfte bewegt und so das (nicht zu verachtende) Gewicht des Alpha Rex verlagert. Der Motor B ist für uns uninteressant. Er kann die Arme heben und senken sowie gleichzeitig den Kopf drehen. Motor A und C machten uns jedoch Probleme. Ursprünglich hatten wir damit gerechnet, dass jeder der Motoren ein Bein steuert. Dann wäre die Programmierung der Tanzschritte kein Problem gewesen.
Mit dieser Motorenstellung allerdings ist es unmöglich über ein Programm zu bestimmen, wie der Roboter läuft. Ein Programm, dass ihn in einem Moment dazu bringt, das rechte Bein vorzuschieben, kann im nächsten Moment dazu führen, dass das linke Bein einen Schritt nach vorn macht. Die Ausführung eines Programms hängt also davon ab, wie die Motoren und Zahnräder stehen. Das bringt ein weiteres Problem für uns mit, da wir nun immer dafür sorgen müssen, dass der Roboter in einer von uns definierten Grundstellung steht. Diese Stellung ist jedoch nicht immer gewährleistet und eine Einschätzung der Drehungen, die man in die Programme hätte einarbeiten können, ist aufgrund von unterschiedlichen Oberflächen, auf denen der Roboter laufen kann, dem Widerstand der Kleidung etc. kaum möglich.
Dementsprechend blieb uns für die Programmierung nur eine sehr aufwändige Probieraktion mit Fußbewegungen und Gewichtsverlagerungen, an der wir in manchen Momenten fast verzweifelt sind. Plötzlich mussten wir nicht nur darauf achten, welcher Fuß vorn und hinten steht, sondern auch auf welchem Fuß das Gewicht liegt - was manchmal nicht so einfach ist. Letzten Endes war es oft eine Überraschung, ob eine Schrittkombination wirklich funktionierte, wie wir sie uns vorgestellt haben.
Dass die Programme für eine Einarbeitung in DialogOS meist sehr kurz sind, hat dafür gesorgt, dass wir zumindest ein wenig Einfluss auf die Motorenstellung nehmen konnten. Trotzdem wären wir bei einer längeren Frist bis zur Projektabgabe wohl auf ein anderes Modell umgestiegen.
Hier können die gesammelten Werke im .rar-Archiv heruntergeladen werden.
Endergebnis
Als Endergebnis unseres Projektes haben wir folgenden, nett anzusehenden aber etwas steifen und buckligen Herren vorzuweisen. Dank Simones Schwester, die für ihn einen Anzug geschneidert hat, muss er außerdem seinen Unterricht nicht "nackt" geben, sondern kann seiner Aufgabe entsprechend in einem Glitterfrack auftreten.
Des weiteren haben wir eine komplexe Dialog-Komponente (s.o.), an der wir an einigen Stellen zwar gern noch Hand angelegt hätten, die jedoch im Großen und Ganzen dem entspricht, was wir uns zu Anfang vorgestellt hatten. Da das bei einem Projekt eher selten geschieht, sind wir besonders an dieser Stelle zufrieden.
Eine kleine Bildergalerie:
 Seitenansicht |
 Rückansicht |
 Vorderansicht |
Videos sind bereits gedreht, können jedoch aufgrund ihres Umfangs an dieser Stelle schlecht eingebaut werden.
Fazit zu DialogOS
Bei all unseren zwischenzeitlichen Schwierigkeiten waren wir ehrlich erfreut, wie problemlos sich DialogOS mit dem Roboter verbinden lässt. Insbesondere die Einbettung von Bricx-Programmen direkt in den Dialog über einen speziellen Button hat uns sehr geholfen. Überhaupt kam man mit dem Programm im Großen und Ganzen gut klar. Allerdings gab es bei uns auch einige kleinere Punkte, über die wir uns geärgert haben bzw. die uns ausgebremst haben.
Da ist zum einen die Aussprache des Programms. Damit die Texte verständlich abgespielt werden, mussten wir teilweise Wörter zusammenschreiben, Kommata oder Punkte setzen, damit die Computerstimme eine Pause macht, oder Wörter komplett "umschreiben" (z.B. Cha-Cha-Cha -> Tschat-tschat-tscha; los -> lohs, loos). Irgendwann wurde dieses Umschreiben so lästig, dass wir es an einigen Stellen aufgaben oder schlicht vergaßen.
Zweitens wollten wir zur Auflockerung einige englische Wendungen in das Gespräch einbringen (z.B. "by the way", "ladies and gentlemen"), die wir dann als eigene Sprachausgabe mit englischem Sprecher dazwischenfügen mussten, weil es dann doch schwierig war, den deutschen Sprecher tun zu lassen, was man wollte (z.B. "bai seh wäi", "läidiehs änd djentelmän"). Da dieser letzte Punkt allerdings auch gut hätte umgangen werden können, störte er uns weniger.
Drittens als letzten Punkt, der uns an dem System teilweise in den Wahnsinn getrieben hat: der "traditionelle X-Button" zum Schließen funktioniert bei den Spracheingabefenstern nicht. Dieser Punkt ist uns ebenso wichtig wie der nächste.
Viertens ist das Kopieren von einem DialogOS-Dokument zu einem anderen nicht möglich - jedenfalls nicht mit dem traditionellen Cut-and-Paste-Verfahren. Das hat uns an einigen Stellen aufgehalten, weil wir mehrmals Dialoge aufgeteilt und einzeln an unterschiedlichen Computern verfasst haben. Das Zusammenfügen war nur möglich, indem man mühsam jede einzelne Sprachausgabe bearbeitete, indem man den Text kopierte und übertrug - also schlicht noch einmal abschrieb.
