Unser Kinectprojekt wurde nun in das Repository vom Autonomous Lab gemerged. Das lief trotz der Umstellung von Orocos 1.x auf 2.0 relativ problemlos.
Ziel des Projektes ist es einen konkurrenzfähigen Roboter für den Robocup@home zu bauen und mit Software für die einzelnen Aufgaben zu versorgen. Der Grundaufbau dieses Robotors ist ein Otto Bock Xeno Rollstuhl, auf den die Kinect sowie ein Greifarm montiert werden soll. Die Kinect habe ich heute zusammen mit David montiert.
Kinectaufbau Front
Etwas problematisch war, dass wir keine Bohrungen oder sonstige Veränderungen am Rollstuhl selbst vornehmen konnten, da dieser vorerst nur eine Leigabe der Firma ist.
Kinectbefestigung am Sitz
Der Rollstuhl besitzt zusätzlich zur Kinect je einen Sick-Laserscanner vorn und hinten, die für Selbstlokalisierung und Kartographie benutzt werden können.
Gesamtaufbau
Die Aufgaben im Robocup@Home sind sehr vielseitig und reichen von einfacher Sprachausgabe über Wegfindung und Spracherkennung bis zur komplexen Gestenerkennung. Zu Beginn muss sich der Roboter beim Technical Commitee vorstellen und seine Registrierungsunterlagen abgeben. Schwieriger wird es schon, wenn einer bestimmten Person durch einen Hindernisparkour gefolgt werden soll. Ein weiteres Beispiel ist das Finden eines bestimmten Objekts, sowie das Herbeibringen des selbigen. Im auf der Homepage downloadbaren Regelbuch sind alle weiteren Aufgaben mit Bepunktungskriterien wie Zeit oder Genauigkeit genau aufgelistet.
Vorerst ergibt sich jedoch als kurzfristiges Ziel die Steuerungsschnittstelle des Rollstuhls sauber ansprechen zu können.
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.
Xbox Kinect Testaufbau (russische Version)
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.
Kinect Obstacle Map
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.
