Im Bachelor-Mastersystem ist es üblich jedes Modul mit einer Prüfungsleistung abzuschließen. Da Klausuren meist weder dem Studenten noch dem Dozenten viel bringen, hat Prof. Dr Rojas für das Computer Vision-Modul in diesem Semester Projekte vergeben. Da diese meinem Gruppenpartner Rene Meusel und mir nicht hundertprozentig zusagten und wir eigentlich gern mit einer Kinect (Eine Erweiterung von Microsoft zur Xbox, die unter anderem eine Kamera enthält, die Entfernungen messen kann) rumspielen wollten, haben wir einfach nachgefragt und vom Autonomous Lab eine Kinect, zusammen mit einer Aufgabe von Prof. Dr. Rojas bekommen. Das Framework, das unter anderem auch das autonome Auto der FU steuert, soll um eine Kinectschnittstelle erweitert werden. Dieses Framework soll dann einen wesentlich kleineren fahrenden Roboter steuern. Der Einfachheit halber soll vorerst nur in die Richtung gefahren werden, die am meisten freien Raum offeriert. Hindernisse sollen dabei umfahren und bei nicht umfahrbaren Hindernissen gebremst werden.
Zum Testen haben wir die Kinect einfach in der Höhe, in der sie später wahrscheinlich auch am Roboter montiert wird, an der Wand befestigt – zugegeben etwas russisch.
Um ein Gefühl für das Framework und die Kinect zu bekommen, versuchen wir unsere Algorithmen vorerst sehr einfach zu halten. Wir lassen uns vom Kinectframework Punkte im 3-dimensionalen Raum generieren, die den Koordinaten in Millimetern ausgehend vom Punkt auf dem Boden direkt unter der Kamera entsprechen. Das bedeutet, dass ein Punkt P mit \((x=2000, y=0, z=1000)\) 2m vor der Kamera auf einer Höhe von 1m liegt. An dieser Stelle befindet sich also irgendein Gegenstand.
Die Grundidee besteht darin diese Punktwolke, die wir von der Kinect bekommen, in eine Obstacle Map (Hinderniskarte) umzuwandeln, also eine Karte in der 2-dimensional Bereiche beschrieben sind, in denen der Robotor sich ungehindert bewegen könnte und Bereiche, in denen sich Hindernisse befinden.
Soweit sind wir dann auch beim ersten Treffen schon gekommen. Der Boden wird durch simples Thresholding klassifiziert. Das bedeutet alle Punkte, die niedriger als 5cm in unserem Koordinatensystem sind, werden als Boden angenommen – zugegebenermaßen könnte das allerdings bei schrägen Ebenen problematisch werden. Wir legen danach ein Raster mit einer Auflösung von 10x10cm über den ganzen Boden und bilden in den Rastern Histogramme der Boden- und Nicht-bodenpunkte, d.h. wir speichern die Anzahl der Bodenpunkte und der Nichtbodenpunkte separat für dieses Rasterstück ab. So können wir für jedes Raster sagen, ob es befahrbar oder mit einem Hindernis besetzt ist, indem wir die Anzahl der entsprechenden Bodenpunkte und Nichtbodenpunkte betrachten. Grüne Bereiche im Bild geben hindernisfreie Raster an, in dunkelgrünen Bereichen würde der Roboter an sich auch in seiner Gänze hineinpassen. Rote Raster geben Hindernisse an, wohingegen in schwarzen Rastern keine Aussage möglich ist, da zu wenig oder keine Sensordaten vorliegen.
Soweit zum aktuellen Stand. Bisher läuft das System auf eher betagter Hardware unter Ubuntu 10.10 ohne die grafische Ausgabe mit etwa 80 Bildern pro Sekunde – also weit mehr als wahrscheinlich benötigt werden wird.
Unsere Idee ist nun für das weitere Vorgehen, dass wir aus der Obstacle Map einen Graphen generieren, der alle möglichen Wege vorwärts und nach links oder rechts beinhaltet. Lenkaktionen sollen dabei bestraft werden, da wir mit dem Roboter möglichst wenig lenken und dennoch in den größtmöglichen freien Raum navigieren wollen. Als Ziel gilt dann der am weitesten entfernte Punkt, der noch auf einem Weg erreichbar ist. Der Lenkwinkel, der dann pro Berechnungsschritt ausgegeben werden soll, ist derjenige, welcher zu Beginn auf dem Weg mit den geringsten Kosten liegt, also der, auf dem am wenigsten gelenkt wird um den Punkt zu erreichen. Das ist zumindest der Plan für die nächste Programmiersession, gefolgt von der eigentlichen Integration ins Autonomous Framework.
