Mathesis Wiki

Am Dienstag hatten wir den ersten Termin unseres KI-Crashkurses, in dem wir grundlegende Ideen und Verfahren von statistischen Methoden und maschinellem Lernen vermittelt bekommen haben. Am Mittwoch haben wir uns hauptsächlich damit beschäftigt Jupyter Notebooks zu maschinellem Lernen durchzuarbeiten und eine Bilderkennung zum Laufen zu kriegen, mit der wir eine menschliche Hand und bestimmte Knoten dieser Hand erkennen wollten. Leider hat der Pythoncode, den wir genutzt haben, nicht mit dem Displayserver des Laptops zusammengepasst. An diesem Problem haben wir lange festgesteckt. Aktuell haben wir noch keine Lösung dafür gefunden. Wir haben versucht den Code von dieser Website zu nutzen: google, hand landmarker python example. Dabei sind wir auf den Fehler 'qt.qpa.plugin: Could not find the Qt platform plugin „wayland“' gestoßen.

Am Montag und Dienstag hatten wir die letzten beiden Teile des KI-Chrashkurses, in denen wir Neuronale Netze, Reinforcement Learning und verschiedene Architekturen kennengelernt haben. Am Mittwoch haben wir dann damit angefangen, den Code aus der vorherigen Woche zum Laufen zu bringen, so dass wir unsere Hände erkennen konnten und durch einen Tastendruck die aktuellen Koordinaten der Landmarks einer Hand abspeichern können. Außerdem haben wir unser PyCharm und GitLab so eingerichtet, dass wir komfortabel an den gleichen Dateien arbeiten können (| unser Projekt auf GitLab). Die Koordinaten der Hände haben wir dann in eine CSV Datei gespeichert, das unsere „Handgestendatenbank“ sein sollte. Anschließend haben wir uns das Modell „LinearRegression“ von SciKit-Learn (| LinearRegression) rausgesucht und das Modell an unseren gesammelten Daten trainiert. Mit dem Modell sind wir auf ziemlich gute Metrics gekommen. Danach hat uns Stefan vorgeschlagen das Modell „SVC“ (Support Vector Machine/Classification) (| SVC) von SciKit-Learn zu nutzen. Wir haben dieses Modell implementiert und sind auf noch bessere Metrics gekommen, daher sind wir erstmal dabei geblieben. Zum Ende haben wir mit dem trainierten Modell versucht eine Handgeste live zu erkennen, aber unser Modell hat leider gar nicht gut funktioniert. Wir glauben, dass es daran liegt, dass Koordinaten im 3d-Raum zu vielfältig sind. Deshalb haben wir zuhause ein paar Funktionen geschrieben, die es ermöglichen die Landmarkkoordinaten zu normieren, indem sie auf allen Achsen gleich ausgerichtet werden. Wir hoffen, dass diese Normierung der Koordinaten dazu führt, dass unser Modell die Gesten besser lernen und unterscheiden kann. Jetzt können wir:

1. Hände erkennen
2. Landmarks als Koordinaten abspeichern
3. SVC-Modell an Daten trainieren
4. Landmarkkoordinaten normieren (rotieren und ausrichten)
5. trainiertes Modell nutzen um live Handgesten zu erkennen (funktioniert bis jetzt sehr schlecht)

Diese Woche haben wir zu Begin unsere Handgestenerkennung getestet und uns überlegt wie wir nun fortfahren, da wir vorerst zufrieden mit der Erkennung sind. Viel Zeit haben wir diese Woche mit dem Suchen von Schere-Stein-Papier-Datensätzen verbracht. Wir konnten leider nicht viele Daten finden. Wir haben zwei Datensätze, die öffentlich sind, mit ca. 2600 Einträgen und ca. 1700 Einträgen gefunden. Außerdem haben wir herausgefunden, dass RedBull im Jahr 2007 in kooperation mit Facebook Roshambull gestartet hat. Eine App, die in Facebook installiert werden kann, um mit Freunden oder Fremden SSP zu spielen. Durch dieses Projekt entstand ein Datensatz mit ca. 2,5 millionen Einträgen, den wir sogar in einer Studie zu SSP gefunden haben (| Link zur Studie). Die Forscher der Studie schreiben, dass sie den Datensatz von RebBull bekommen haben. Wir haben dann versucht mehr über diesen Datensatz herauszufinden und sind auf die Website von Craig Kohtz (| Craig Kohtz Website) gestoßen, auf der er kurz über das Projekt Roshambull schreibt, in dem er Mitarbeiter war. Wir haben ihm daraufhin eine Mail geschrieben, in der wir gefragt haben, ob er uns sagen kann wie wir eventuell an den Datensatz kommen können, um unser KI-Modell trainieren zu können. Er hat uns ziemlich schnell geantwortet, dass er nicht weiß, ob die Daten noch existieren, er aber für uns seine alten Kollegen nachfragen wird und vielleicht auch bei RedBull anfragt was mit den Daten passiert ist.

Da wir bis jetzt keine weitere Antwort von Craig Kohtz bekommen haben, schrieben wie ihm eine dankbare Mail, in der wir nocheinmal nachgefragt haben, ob er etwas neues in Erfahrung bringen konnte. Abseits davon haben wir nun angefangen mit PyTorch unser Modell zu basteln. Wir haben uns dafür entschieden eine LSTM-Architektur (|PyTorch LSTM Dokumentation) zu nutzen, denn dabei kann Information von vorherigen SSP-Vorhersagen zur nächsten Vorhersage weitergegeben werden (sozusagen ein „Gedächtnis“). Wir wollen als erstes versuchen ein Vorhersagemodell zu bauen, dass anhand der Vergangenheit den nächsten Zug des Gegenspielers vorhersagt. Alternativ könnten wir ein SSP-Agenten bauen, den wir darauf trainieren, selbst SSP zu spielen. Dieser Agent könnte nicht nur auf gegnerische Strategien antworten, sondern selbst Strategien verfolgen. Wir haben uns an einem Beispiel (|LSTM Codebeispiel) orientiert und angefangen eine Class für unser Modell zu schreiben.

Clemens war diese Woche leider nicht da, nichtsdestotrotz werden wir im Folgenden aus der Wir-Perspektive schreiben. Wir haben uns zu Begin nocheinmal Gedanken gemacht, welchen Encoder wir für unser Modell benutzen wollen. Möglichkeiten wären z.B. der One-Hot-Encoder (|PyTorch One-Hot-Function) oder das sogenannte Embedding von PyTorch (|PyTorch Embedding). Wir werden das Embedding von PyTorch nutzen, denn das ist ebenfalls ein Netz, das wir mit unserem Modell zusammen trainieren können. So wird im Optimalfall unser Encoding der Eingabedaten immer besser an unser Modell angepasst. Das Embedding ist noch nicht implementiert, aber wir haben den Code geschrieben, mit dem wir den einen Datensatz laden können und die Daten in ein sinnvolles Format umwandeln können. Für uns bedeutet das, die Daten bestehen immer aus Paaren (Tupel), die die Geste des Spielers und die Geste des Gegners (in diesem Fall die Geste des Menschen und die Geste des Computers, da die Daten von Mensch gegen KI stammen) beeinhalten. Bei drei Symbolen pro Spieler ergibt das neun Möglichkeiten, diese neun Möglichkeiten stellen wir als Zahlen von 0 bis 8 in einer Liste dar. Die Liste enthält nun 2600 Einträge von Partien mit jeweils 50 Runden. In der nächsten Woche wollen wir das Embedding implementieren und das Modell an den Daten anfangen zu trainieren.