Projektlabor Robotik MINTgrün

Der Roboter ist ein Nachbau des sprechenden Hutes aus Harry Potter, der die Schüler*innen in die Häuser Gryffindor, Hufflepuff, Slytherin und Ravenclaw einteilt. Die Einteilung in die vier Häuser erfolgt mit Hilfe einer Reihe von „Ja/Nein“-Fragen, beziehungsweise „Entweder/Oder“-Fragen, die dazu dienen, die Persönlichkeitsmerkmale des Hutträgers/der Hutträgerin einzuordnen. Während der Befragung erkennt der Roboter, welche Antworten gegeben werden und analysiert diese, um den User/die Userin zu einem der Häuser zuzuordnen. Hat der Roboter eine eindeutige Zuordnung getroffen, so blinkt das LED-Band an der Hutkrempe in der Farbe des Hauses auf: Grün für Slytherin, Rot für Gryffindor, Gelb für Hufflepuff und Blau für Ravenclaw. Ziel dabei ist es, die Zuordnung so zu treffen, dass es mit den individuellen Eigenschaften des Befragten bestmöglich übereinstimmt.

Da wir einen Nachbau anstreben, war das Ziel einen Roboter zu bauen, der so viel Ähnlichkeit wie möglich mit dem Original hat. Harry Potter ist jedoch ein Fantasy-Buch und somit hatten wir künstlerische Freiheit bei einzelnen Details. Die Zentrale Frage war: Wie kann der Hutträger/die Hutträgerin einem der vier Häuser korrekt zugeordnet werden?

Wir haben uns bewusst für „Ja/Nein“-Fragen beziehungsweise „Entweder/Oder“-Fragen entschieden, da durch die begrenzte Anzahl möglicher Antwortoptionen das Fehlerpotenzial bei der Eingabe reduziert wird und sich ein klarer Punktestand zur Feststellung eines Gewinners ableiten lässt. Der Benutzer/die Benutzerin muss zwischen zwei Antwortmöglichkeiten wählen, wobei jede eine Charakteristik eines der Hogwarts Häuser aufgreift und somit den Punktestand dieses Hauses repräsentiert – ohne dass der Spieler/die Spielerin weiß, welches Haus hinter welcher Antwort steht. Je nach Entscheidung des Nutzers/der Nutzerin wird der “counter” also der Zähler des jeweiligen Hauses um eins erhöht. Sobald einer der “counter” gleich vier ist, sich der Befragte also vier Mal für dasselbe Haus entschieden hat, ist das Quiz zu Ende und das jeweilige Haus wird als Gewinner verkündet.

Der Hut besteht aus dem Gehäuse, das Platz für Elektronik und Mechanik bietet. Das Innenleben besteht aus dem Arduino Nano, einem DF-Player Mini, einem Audelivery Lautsprecher mit 3 Watt, einem Motor, 3 Knöpfen für „Ja/Nein“, beziehungsweise „Entweder/Oder„ und einem als „reset”-Knopf, einem LED-Band, welches in den Farben rot, gelb, blau und grün leuchten kann und einer Stromversorgung (Lithium-Ionen-Akku).

Um den Roboter erstellen zu können, erfolgte zu Beginn eine Aufteilung in Hard- und Software bezogene Aufgaben. Dabei muss nicht nur ein realitätsgetreuer Aufbau gegeben sein, welcher auch Bewegungen des Huts imitieren kann, sondern auch ein Code, der die Analyse der Antworten ermöglicht und entsprechende Reaktionen des Huts erlaubt.

Die Aufgabenverteilung sah folgendermaßen aus:

1. Quiz Fragen erstellen und aufnehmen
2. Quiz programmieren (ein Arduino Programm, das in der Lage ist, Fragen aufzurufen, Input zu registrieren, Hauspunkte zu zählen und einen Gewinner bekannt zu geben. Dazu gehörten:
   • „Ja/Nein-“, beziehungsweise „Entweder/Oder-“ Knöpfe * Listenpunktprogrammieren
   • Wärmesensorik & Resetknopf programmieren
   • Audio Hard- & Software
   • LEDs Hard- & Software
3. Hardwareaufbau fertigstellen
4. Projektpräsentation
5. Projektdokumentation

Aufgrund von Zeitmangel und großem Fehlerpotential entschlossen wir uns als Gruppe den Wärmesensor zu streichen. Die Befürchtung war, dass das Quiz nicht zuverlässig starten und schwer zu “resetten” sein würde.

Dieses Semester haben wir uns zunächst auf die Software bezogenen Aufgaben fokussiert, da wir besonders in der letzten Arbeitsphase gemerkt haben, dass der Aufbau der restlichen Hardware den zeitlichen Rahmen sprengen würde. Eine interessierte Gruppe könnte mit unserem kommentierten Code nächstes Semester die Hardware Aufgaben, wie sie aus unserer Projektvorstellung und vor allem auch aus der Abschlusspräsentation mit Lösungsansätzen zu entnehmen sind, fertigstellen.

Als wir uns im Prozess der Projektfindung für den Sprechenden Hut entschieden haben, war uns sofort klar, dass der Hut nicht einfach nur zufällig agieren soll, sondern dass wir seine Magie und Weisheit auch in der User*innen Experience deutlich spürbar machen wollen. Essentiell dafür sind unserer Meinung nach

• Fragen, die gleichzeitig effektiv zur Entscheidungsfindung beitragen, realistisch anwendbar sind, aber dennoch dem Ganzen nicht die Magie nehmen
• magische Formulierungen, die den Hut einerseits lebendig wirken lassen und andererseits den Verlauf des Quiz leicht verständlich machen und reibungslos wirken lassen
• eine sinnvolle Reihenfolge und Logistik der verschiedenen Formulierungen, Fragen und Effekte
• eine passende Stimme

Um unsere Entscheidungen in diesen Bereichen nachvollziehen zu können, ist es wichtig, erstmal einen Überblick über die grundsätzliche Stimmung der Harry-Potter-Saga zu schaffen. Es handelt sich um eine von J.K.Rowling geschriebene Fantasy-Roman Buchreihe, die von der titelgebenden Figur Harry Potter erzählt. Harry ist ein 11-Jähriger Junge, der unerwartet von seiner magischen Begabung erfährt und fortan eine Schule für Hexen und Zauberer namens Hogwarts besucht. In dieser Schule gibt es vier Häuser, in die Schülerinnen und Schüler in ihrem ersten Schuljahr zugeordnet werden. Die Zuteilung auf die Häuser wird vom “Sprechenden Hut„ vorgenommen. Ein magischer Hut, der den Schülerinnen und Schülern aufgesetzt wird, in ihre Köpfe hinein blickt und je nach Vorlieben, Eigenschaften, Stärken und Schwächen, entscheidet in welches Haus er oder sie gehört. Der folgenden Tabelle kann man die wichtigsten Informationen zu den jeweiligen Häusern entnehmen:

Unser Quiz besteht aus 13 „Entweder/Oder-“ Fragen. Wir haben die Fragen so gestellt, dass die Antwortmöglichkeiten für jeweils ein Haus stehen. Zum Beispiel: Bleibst du der Wahrheit stets treu (dies wäre die Antwort für Hufflepuff) oder ergreifst du manchmal den Weg der Täuschung (dies für Slytherin)? Insgesamt gibt es sechs Kombinationen zwischen den vier Häusern. Wir haben zu jeder Kombination zwei Fragen formuliert, aber da es dann die Möglichkeit gibt, dass jedes Haus am Ende des Quizzes gleich oft gewählt wurde, haben wir noch eine dritte Frage zu der Slytherin-Gryffindor-Kombination formuliert. So ist es etwas zwar etwas wahrscheinlicher, einem dieser Häuser zugeordnet zu werden, allerdings entspricht dies auch dem Geist des Buches, da dies die Häuser mit den meisten Protagonisten sind. Diese 13 Fragen ordneten wir dann so, dass alle Häuser gleich viele Möglichkeiten haben gewählt zu werden, sodass die Chancen, ein Haus zu bekommen, bei allen Häusern möglichst gleich sind. Der User bekommt sein Haus verkündet, wenn er oder sie viermal eine Antwort für ein bestimmtes Haus gewählt hat.

Nachdem die Reihenfolge der Fragen festgelegt war, beschäftigten wir uns ausgiebig mit den Eigenschaften der vier Häuser, um eine wirklich akkurate Einteilung zu gewährleisten. Die Fragen sind so formuliert, dass hinter jeder Antwort eine bestimmte Eigenschaft des jeweiligen Hauses steckt. Gemeinsam haben wir uns viele Fragen ausgedacht, wobei wir uns auch von anderen Quizzen inspirieren lassen haben und reduzierten letztendlich auf die Fragen, die wir für am geeignetsten halten.

Außerdem formulierten wir ein Intro, in dem der Sprechende Hut sich vorstellt und seine Funktionsweise erklärt. Um die Lebhaftigkeit des Hutes zu symbolisieren, schrieben wir auch Reaktionen auf einige der Antworten. So wirkt es mehr wie eine menschliche Interaktion, als eine einseitige Abfrage. Um dem User das zugeteilte Haus mitzuteilen, gibt es eine Hausverkündung für jedes Haus, bei der nochmal auf die typischen Eigenschaften verwiesen wird. Im Falle eines Fehlers in unserem Technik- oder Codeteil, soll eine Fehlermeldung abgespielt werden. Diese Formulierungen wurden dann dem erfahrenen Schriftsteller Till S. präsentiert, mit dessen Hilfe wir unsere Ideen in magische, elegante und altmodische Formulierungen umgewandelt haben. So spricht unser Hut nun um die 700 Wörter.

Um eine magische Atmosphäre zu schaffen, braucht der Hut eine passende Stimme, die unsere erdachten Fragen, Reaktionen und Formulierungen ausspricht. Um die Audiodateien für die Stimme aufzunehmen, haben wir uns mit Synchronsprecher Casper L. getroffen, der sich bereit erklärt hat, die Stimme unseres Hutes zu werden. Mit ihm haben wir uns für eine bestimmte Stimmlage entschieden, mit der innerhalb von insgesamt sieben Stunden das Intro, alle Fragen mit Reaktionen, die Fehlermeldung und die Hausverkündung aufgenommen wurden. Diese Stimmlage sollte den alten, weisen und magischen Charakter des Hutes reflektieren.

Quellen:

https://harrypotter.fandom.com/de/wiki/Gryffindor https://harrypotter.fandom.com/wiki/Slytherin https://harrypotter.fandom.com/de/wiki/Hufflepuff https://harrypotter.fandom.com/de/wiki/Ravenclaw

Detailbeschreibung einzelner Systembestandteile

Ein Arduino besteht aus Hard- und Software. Dabei gehören die Arduino-Boards, welche einen Mikrocontroller enthalten, zu der Hardware. Über einen Mikrocontroller sind alle Komponenten des Roboters verknüpft. Die Software umfasst eine Programmierumgebung, welche es dem Benutzer ermöglicht, einen eigenen Code zu schreiben. Durch das Schreiben eines Programms kann der Mikrocontroller auf Eingabesignale reagieren und gewünschte Aktionen ausführen.

Der DF-Player Mini dekodiert MP3-Dateien von einer Mikro SD Karte. Wir verwenden das Modul in Kombination mit einem 3 Watt Lautsprecher über den der zuvor professionell eingesprochenen Text ausgegeben werden kann. Diese Konstruktion verleiht dem Hut seine Stimme und bildet so das Herzstück des Roboters.

https://wolles-elektronikkiste.de/dfplayer-mini-ansteuerung-mit-dem-arduino, letzter Zugriff: 29.03.2025

(Hier auf dem Bild ist die Verkabelung an einem Arduino UNO dargestellt, in unserem Roboter arbeiten wir allerdings mit dem Arduino NANO.)

Der Motor ist im Hut eingebaut, um ihn weniger starr und unecht wirken zu lassen. Mit Hilfe der „random” Funktion wurden im Code beliebige starke und beliebig schnelle Drehungen des Motors eingebaut, die nacheinander ausgegeben werden sollen. Da der Motor mit Hilfe von Nylonschnüren an der Innenseite des Hutes befestigt ist, tragen die unregelmäßigen Bewegungen dazu bei, dem Hut ein lebensechtes Erscheinungsbild zu verleihen und so das magische Element des Sprechenden Hutes einzufangen, wie man auch in der Skizze sehen kann.

https://www.circuits-diy.com/wp-content/uploads/2023/03/Potentiometer-Triggers-Servo-Motor-Arduino-Tutorial.png, letztere Zugriff: 29.03.2025

Als Motor haben wir einen Servo-Motor vorgesehen, da diese nur Strom bei Drehung verbrauchen und weil diese durch ihr kleines und sehr leichtes Exterieur gut im Hut verbaubar sind.

Durch die Vorstellungsrunde der Sensoren zum Anfang des Kurses kannten wir den Wärmesensor, der ursprünglich als elegante Lösung für den Start des Quizzes geplant war. Durch den Wärmesensor erkennt der Roboter, dass der Hut aufgesetzt wurde und er ist bereit, Fragen zu stellen. Um allerdings mögliche Fehler ausräumen zu können (bspw. der Hut startet das Quiz nicht oder nur zu stark verzögert) und auch aus zeitlichen Gründen, haben wir vorerst nur einen reset-Knopf eingeführt, der ein manuelles Starten ermöglicht.

Der Hut beinhaltet drei Knöpfe. Zwei Knöpfe für die Antwortmöglichkeiten, sowie ein „Start/Reset-” Knopf, der den Wärmesensor ersetzt und für den Start oder eine Unterbrechung des Quizzes sorgt. Die „Antwort-” Knöpfe sollen in den, für den sprechenden Hut typischen, Stofflappen versteckt sein, wo der Benutzer/die Benutzerin sie gut erreichen kann. Der „Start/Reset-” Knopf soll in der Hutspitze versteckt sein. Für die Stofflappen haben wir bereits ein Schnittmuster erstellt. Nach dem Schnittmuster ist an der Seite des Lappens (in die Naht integriert) auch ein Reißverschluss. Dieser soll ein Austauschen der Kabel bei möglichen Kabel Defekten erleichtern.

Sobald am Ende des Quizzes das Ergebnis feststeht, dienen LEDs an der Hutkrempe zur Visualisierung der Zuordnung zu einem der vier Häuser: Gryffindor, Hufflepuff, Slytherin und Ravenclaw.

Der erste Abschnitt des Codes legt die Grundstruktur des Programms fest. Zunächst werden notwendige Bibliotheken eingebunden. Zum Beispiel die „Adafruit_NeoPixel-Bibliothek“, welche für die Steuerung der RGB-LEDs benötigt wird. Anschließend werden die Hardware Pins für die Buttons und den Lautsprecher festgelegt. Da wir es leider zeitlich nicht mehr geschafft haben, den gesamten physischen Aufbau des Hutes fertigzustellen, fehlt im Code noch eine Zuweisung der Pins für die LEDs und den Motor. Die Zuweisung der übrigen Pins würde erst nach der praktischen Erprobung erfolgen, um sicherzustellen, dass die Verkabelung und das gesamte Layout optimal funktionieren.

Nach der Hardware-Zuweisung werden die wesentlichen Variablen des Programms definiert. Dazu gehören die Punktestände der vier Häuser, genannt: int g_count, s_count, r_count, h_count, sowie eine Variable namens: int current_question, die speichert welche Frage gerade aktiv ist. Zu Beginn des Quizes sind alle Variablen auf 0 gesetzt. Eine Variable namens unsigned long input_timer ist noch als Kommentar im Code zu finden und sollte ursprünglich genutzt werden, um zu messen, wie lange ein Benutzer braucht, um sich zwischen den Antwortmöglichkeiten zu entscheiden. Der Hut sollte dann je nach Reaktionszeit reagieren. Aus Zeitgründen entschieden wir uns, diese Idee zu verwerfen.

Die letzte Variable heißt bool running. Diese Variable ist ein Boolean und kann daher nur die Werte true oder false annehmen. Sie repräsentiert den Status des Quizzes, also ob es gerade aktiv läuft oder nicht. Zu Beginn jeder Iteration der main loop wird der Status dieser Variable überprüft. Der Reset-Knopf schaltet den Status der Variable running um. Solange running = true, wird in jeder Iteration die Frage erhöht. Ist running = false, wird das Quiz abgebrochen und alle Variablen zurückgesetzt.

Der nächste Abschnitt ist die setup() Funktion. Sie wird beim Start des Arduino einmal ausgeführt und dient dazu, die Hardware-Komponenten und die Kommunikation vorzubereiten. Serial.begin(9600); startet die serielle Kommunikation, um zu ermöglichen, dass Debugging-Informationen über den seriellen Monitor ausgegeben werden können. Anschließend werden die drei Buttons mit pinMode() als Eingänge definiert und durch die Nutzung von INPUT_PULLUP mit einem internen Pull-Up-Widerstand versehen. Das bedeutet, dass die Tasten standardmäßig HIGH sind und beim Drücken auf LOW wechseln.

Ein besonderer Bestandteil dieses Abschnitts ist der “Interrupt” für den Reset-Button, der mit attachInterrupt() festgelegt wird und ermöglicht, den Quiz-Status jederzeit umzuschalten. Dies ist wichtig, um das Quiz jederzeit zu stoppen oder neu zu starten, selbst wenn das Hauptprogramm gerade eine andere Funktion ausführt.

Die LED-Steuerung wird mit hut_led.begin initialisiert. Um sicherzustellen, dass der RGB-Streifen erst durch das Quiz aktiviert wird sorgt hut_led.show dafür, dass alle LEDs zu Beginn ausgeschaltet bleiben.

Anschließend an die setup()-Funktion folgt ein Struct, in dem die Fragen und weiteren Sprachaufnahmen des Quiz gespeichert sind. Jede Frage ist mit dem Namen der zugehörigen MP3-Datei sowie den Häusern verknüpft, die für eine linke oder rechte Antwort Punkte erhalten. Aufgrund des begrenzten Speichers des Arduino Nano war es nicht möglich, den vollständigen Fragetext zu speichern. Wir hätten ein größeres Board nutzen können, sahen dies aber als Herausforderung und entwickelten stattdessen eine alternative Lösung. Dazu kürzten wir die Fragen stark ab, um den Speicherbedarf zu reduzieren.

Damit das Programm eine Antwort korrekt einem Haus zuordnen kann, haben wir jedem Haus eine Zahl zugewiesen: Gryffindor = 1, Slytherin = 2, Ravenclaw = 3, Hufflepuff = 4. Einträge im struct folgen also der Syntax: {„Intro, F1“, „0001.mp3“, 1, 2}. Im Hauptprogramm (main loop) bestimmt die Variable current_question, welche Frage gestellt wird mithilfe des Index des structs.

*Hier ein Ausschnitt des structs*

Im Anschluss an den Struct werden alle Funktionen definiert, die für den Hauptcode benötigt werden. Diese Funktionen steuern verschiedene Abläufe des Quiz, darunter das Stellen von Fragen, die Eingabeerkennung, das Vergeben von Punkten und die Verkündung des Gewinners. Um die Bedeutung und Funktionsweise dieser Funktionen besser zu verstehen, ist es hilfreich, die “main loop” des Programms zu betrachten. Diese bildet das Herzstück des Codes und ruft die einzelnen Funktionen in der richtigen Reihenfolge auf.

Die folgende Grafik veranschaulicht den Ablauf des Programms und zeigt, wie die verschiedenen Funktionen miteinander verbunden sind:

Der Code der main loop mag auf den ersten Blick kurz erscheinen, aber er steuert eine komplexe Verkettung von Funktionen, die wiederum weitere Funktionen aufrufen. Jede Funktion innerhalb der main loop hat eine spezifische Aufgabe, sei es das Stellen einer Frage, das Erfassen einer Antwort oder das Überprüfen des Gewinnerstatus.

Die erste Funktion der main-loop lautet check_status_reset. Die Funktion prüft den Status der running Variable. Steht diese auf false setzt check_status_reset alle Variablen auf 0.

Die nächste Zeile checkt ebenfalls den Status der running Variable. Steht diese auf false beginnt die Schleife von vorne und keine Frage wird gestellt. Dies passiert so lange, bis der Reset-Knopf gedrückt wird und running auf true gesetzt wird. Damit wird das Quiz gestarted.

Sobald running = true wird die nächste Funktion des main-loop aufgerufen. Da die Audio-Hardware noch nicht funktioniert, ist Debugging hier besonders wichtig. Die Funktion frage_stellen gibt im seriellen Monitor die Abkürzung der nächsten Frage, den Titel der zugehörigen MP3-Datei sowie die Werte der rechten und linken Antwort aus. Am Ende ruft frage_stellen die Platzhalterfunktion play_Audio auf und übergibt die MP3-Datei der aktuellen Frage. Diese Platzhalterfunktion soll durch eine funktionierende Version ersetzt werden, sobald die Audio-Hardware einsatzbereit ist.

Nach Frage_stellen folgt die Funktion detect_input. Diese läuft in einer Dauerschleife, bis sie einen Button-Input erhält.

Sobald ein Input registriert wird, wird dieser an die Funktion update_house_points übergeben. Diese erhöht den Punkte-Stand des entsprechenden Hauses und gibt den aktuellen Punktestand zur Fehlersuche (Debugging) im seriellen Monitor aus.

Die letzte Funktion der main-loop, check_winner vergleicht die aktuellen Punktestände mit der gewinn_punkte Variable. Hat eins der Häuser die erforderlichen 4 Punkte erreicht wird die entsprechende Gewinner Funktion (g_winner, s_winner, r_winner, h_winner) aufgerufen.

Die Gewinner-Funktionen sind strukturell identisch. Sie geben den Gewinner auf dem seriellen Monitor aus und rufen die MP3-Datei auf, die das gewinnende Haus verkündet. Zusätzlich lassen sie die LEDs in der Hausfarbe 20 Sekunden lang blinken und setzen anschließend das Quiz zurück indem sie die die running Variable auf false setzen.

Findet die check_winner Funktion keinen Gewinner wird die current_question Variable erhöht und die main-loop beginnt mit der nächsten Frage von vorne. Die main-loop läuft also bis ein Gewinner feststeht oder das Quiz zurückgesetzt wird.

Wie bereits zu Beginn angedeutet, ist der Großteil der Software Aufgaben unseres Hutes schon erledigt. Unser Code ermöglicht eine bislang fehlerlose Zuordnung zu einem der vier Häuser. Auch die Tondateien sind bereits aufgenommen, auf der SD-Karte entsprechend gelabelt und in den Hauptcode mit einbezogen. Dasselbe gilt für den Code der LEDs und den Reset-Knopf. Wir haben uns bewusst dafür entschieden, den Code des Motors noch nicht mit in den Hauptcode zu integrieren, damit wir die beiden kürzeren Codes zunächst leichter debuggen können und um erstmal die einzelnen Codes separat zu bearbeiten, beziehungsweise zu optimieren. Nichtsdestotrotz ist auch dieser Code fertig und kann genutzt werden.

Die Hardware Aufgaben sind allerdings, aufgrund der zeitlichen Einschränkungen, die unter anderem aus mehreren Krankheitsfällen in unserer Gruppe resultierten, noch nicht vollständig bearbeitet. Das Grundmodell unseres Hutes ist fertig ausgebaut und die grundlegenden Bestandteile sind vorbereitet, aber noch nicht verbaut. Der Rohling des Hutes ist von innen mit einem bereits fixierten Drahtgestell von uns verkleidet worden und auch die untere Pappeinlage ist bereits zurechtgeschnitten und verbaut. Allerdings sind die einzelnen Bauteile noch nicht permanent fixiert, das heißt, die Kabel sind noch nicht verlötet und auch die Knöpfe sind noch nicht permanent in seitlichen Strängen am Hut verbaut, allerdings haben wir ein fertiges Schnittmuster für die Gestaltung der Stoffstränge. Wir wollten diesen Schritt eigentlich ganz zum Schluss erledigen, um uns etwas mehr Flexibilität zu verschaffen, wurden dann aber vor eine zeitliche Herausforderung gestellt.

Zudem haben die Risiken eines Kabelbruchs und eines verminderten Handlungsspielraums beim endgültigen Verbaung der Hardware in den Hut, diesen letzten Schritt deutlich erschwert.

Toll wäre es, wenn eine zukünftige Gruppe unser Projekt aufgreift und vervollständigt. Besonders ein originalgetreuer Aufbau der Hardware und ein Abarbeiten der restlichen Hardware Aufgaben wären dabei essenziell. Grundlegend ist dafür, dass nicht nur der Hardwareaufbau für die Tonausgabe korrekt ist, sondern, dass auch die einzelnen Module der Hardware korrekt verbaut sind. Momentan ist unsere Software zwar potentiell richtig, es scheitert aber weiterhin an der Hardware bei der Tonausgabe, weshalb diese noch manuell gesteuert werden muss. Ein automatisierter Prozess würde den Hut auf jeden Fall deutlich magischer machen, jedoch verleiht selbst die manuell gesteuerte Stimme dem Hut schon einen ausdrucksstarken Charakter.

Gegebenenfalls könnte noch ein Wärmesensor programmiert und eingebaut werden, dabei muss allerdings das erhöhte Fehlerrisiko beachtet werden, weshalb wir uns nicht sicher sind, ob dieser Schritt wirklich in der Praxis funktioniert.

Ebenfalls könnten die Bewegungen des Hutes noch vielseitiger gestaltet werden und vielleicht könnten noch mehr Motoren, ergänzend zu dem bereits existierenden, verbaut werden. Alles in allem sind die Grundlagen für einen funktionierenden Roboter gelegt und könnten im nächsten Semester durch eine andere Gruppe ausgebaut werden. Im vergangenen Semester haben wir viel gelernt – von der Hardware-Planung über die Verkabelung und den Umgang mit Arduino-Boards bis hin zur Programmierung eines komplexen Codes. Wir haben erkannt, dass der Aufbau der Hardware oft genauso herausfordernd ist wie das Schreiben des Programms und dass besonders die letzten Feinschliffe unerwartet viel Zeit kosten können. Trotzdem sind wir stolz darauf, dass unser Quiz funktioniert und spielbar ist.

Abschlusspräsentation: der_sprechende_hut_praesentation.pdf

Codes und Anhang: dersprechendehut_code.zip

Bibliothek: adafruit_neopixel.zip

Audiodokumente: sprechender_hut_sprachaufnahmen.zip

Überblick über die selbst erstellten Graphiken: