Abschlussarbeiten

Implementierung eines Safety-Controllers in einen acaBot-Roboter (Bachelorarbeit)

"MT"

Bei einer Roboterfahrt kann es jederzeit passieren, dass unerwartete Ereignisse eintreten. Z.B. kann das ein Hindernis sein, das der Roboter umfahren muss; je nach Ausmaß und Position des Hindernisses muss der Roboter möglicherweise sogar eine völlig neue Weg-Route berechnen. Eine zweite Art eines unerwarteten Ereignisses - das Gegenstand dieser Abschlussarbeit sein soll - betrifft erstens den unerwartet schnell zurück gegangenen Akku-Ladestand des Roboters und zweitens seine verloren gegangene Funkverbindung zum Prozessleitsystem. In beiden Fällen muss der Roboter seine ursprüngliche Aufgabe abbrechen und einen bestimmten, sicheren Platz anfahren. Dieser Platz soll sich jederzeit veränderbar irgendwo in unserem Roboter-Labyrinth befinden und muss demnach vom Roboter mithilfe einer Software-Navigations- und Hardware-Sensor-Strategie gefunden werden. Es gibt hierfür ein paar unterschiedliche, nicht allzu schwere Ansätze, von denen einer im Rahmen einer Bachelorarbeit realisiert werden soll. 

Abbildung unserer Universal-Fernsteuerung für die acaBot-Roboter als mobile App für iOS (Bachelorarbeit)

"M"

Alle unsere Roboter können - neben der programmierten Betriebsweise - auch manuell über Fernbedienungen (mit ZigBee-Funkmodul) gelenkt werden. Leider verfügt jeder Roboter über eine leicht unterschiedliche Fernbedienungsfunktionalität, und mit den Beschriftungen auf den Fernbedienungen ist das auch so eine Sache.

Im Rahmen einer Bachelorarbeit suchen wir einen oder eine Studierende aus dem Studiengang Medieninformatik, die uns eine Nachbildung unserer physischen Fernbedienungen als App für iPhone erstellt, mit der wir über den Weg eines Wifi/ZigBee-Gateways (dieses existiert schon) alternativ unsere Roboter steuern können.

"Hilfe - ein Ghost-Bot im Labyrinth!" Roboter-Lokalisierung nach Markov (Masterarbeit)

"MT" 

Ein Schwerpunkt zu den acaBot-Robotern im PSE-Labor ist das sogenannte Prozessleitsystem (PCS: process control system). Mittels einer ausgeklügelten Kameraführung werden über Farbkodierungen sämtliche sich im Prozess-Raum/Labyrinth befindlichen Roboter identifiziert (und ihnen über das PCS ggfs. Aufgaben zugewiesen). Eine Ergänzung hierzu soll der Ghost-Bot werden. Der Ghost-Bot verfügt über keine Farbkodierung und kann somit vom PCS nicht erkannt werden; er bewegt sich sozusagen "under the radar". Ohne weitere Maßnahmen ist ein solches Szenario natürlich nicht wirklich denkbar und funktioniert auch tatsächlich nicht, denn der Ghost-Bot wird durch seine Anwesenheit im Labyrinth jegliche Ordnung im Bewegungsablauf der anderen Roboter stören. Deshalb soll diesem Ghost-Bot im Rahmen einer Abschlussarbeit ein Feature zugewiesen werden, durch das es möglich wird, dass er trotz fehlender Farbkodierung störungsfrei im Labyrinth umherfahren kann: der Ghost-Bot teilt von sich aus dem PCS mit, wo er sich gerade in ihm befindet. In einer einfachen, wenn auch ziemlich ungenauen Betrachtung kennt der Ghost-Bot seine aktuelle Position über die sogenannte Odometrie, die er ausschließlich durch die in seinen Motoren befindlichen Encoder erhält. Da der Ghost-Bot aber zusätzlich zu diesen Odometriedaten die Welt, in der er sich bewegt (das ist das Labyrinth), als Karte insgesamt sehr genau kennt, kann er dennoch von sich aus dem PCS recht zuverlässig mitteilen, wo er sich gerade befindet. Das PCS verlässt sich auf die Positionsangaben des Ghost-Bots und zieht diesen in seine Raumbelegungen mit ein. Hier nun die eigentliche Aufgabenstellung für die Abschlussarbeit: Der Ghost-Bot kennt zwar die Karte, das sind die Räume und Wände des Labyrinths, in dem er sich befindet, aber er weiß damit noch nicht, an welcher Stelle genau er sich in diesem Labyrinth gerade befindet. Was würden wir als Menschen in einer solchen Situation tun? Wir schauen uns um, betrachten alle Wände und Türen der Umgebung und lernen mehr und mehr, je länger wir uns umsehen. Irgendwann sind wir so weit und können sagen: "Jetzt weiß ich, wo ich bin!". Genau so macht es auch der Roboter: er befindet sich anfangs noch an irgendeiner unbekannten Position, fährt los, sieht sich seine Umgebung an, bis er feststellt: "Dies ist meine Position!" Diese gewonnene Erkenntnis teilt er dem PCS mit. Es handelt sich bei dieser Aufgabe um ein statistisches Problem, das mithilfe des sogenannten Markov-Algorithmus gelöst werden kann. (Eine erfolgreiche Realisierung existiert auch schon im PSE-Labor, jedoch steht sie in Verbindung mit dem unter Linux laufenden Player-Stage-Simulator, der den Markov-Algorithmus als Plugin benutzt. Wir hätten diesen Algorithmus jedoch gerne Stand-Alone auf dem Raspberry Pi des Roboters, um ihm damit einen ganz besonderen Anstrich von Autonomie zu verleihen.) Die Programmierung erfolgt in C++ oder Python. Nach Aussage von Prof. Dr. Martin von Löwis existiert ein Markov-Algorithmus per se schon in der Open-Source-Bibliothek für Python und könnte, wenn das stimmt, natürlich für die vorliegende Arbeit mit verwendet werden.

Inbetriebnahme einer 360 Grad Kamera an einem acaBot-Roboter zur Objektverfolgung (Bachelor-/Masterarbeit)

"MT" 

Einige unserer acaBot-Roboter, z.B. der autonome Goal-Keeper, sind mit einer Frontal-Kamera zur Objekterkennung ausgestattet (so muss etwa der Goal-Keeper den auf ihn zurollenden Ball erkennen). Diese Kamera ist an der Stirnseite des Bots angebracht und geradeaus gerichtet. Damit kann sie alles erkennen, was vor dem Bot und leicht zu seinen Seiten hin geschieht. Wird diese Kamera auf geeignete Weise auf einen Parabolspiegel gerichtet, wird es möglich, nicht nur einen begrenzten Ausschnitt des Raumes zu betrachten, sondern tatsächlich die gesamte 360-Grad Umgebung in einem Aufwasch "zu überwachen". Um diese Raum-Kamera nützlich in anspruchsvolle Anwendungen einbinden zu können, ist es zunächst erforderlich, die Kamera zu kalibrieren und die elementaren Funktionsnachweise an einfachen Roboter-Bewegungen zu erbringen.

Es existieren derzeit zwei verschiedene Kameras von Interesse im PSE-Labor. Die von der Auflösung her schlechtere Kamera, die "Pixy-Cam" beherrscht mit einer enormen Bildrate von 50 pics/s von Hause aus das sehr rechenintensive Blob-Finding, das für Objekterkennung erforderlich ist. Die von der Auflösung her bessere Kamera, das ist die "Pi-Camera" (speziell für den Raspberry Pi gebaut) liefert zwar hervorragende Bilder, aber es müssen über Open-CV-Funktionen erst die Objekte von Interesse aus den Gesamtbildern herausgerechnet werden, was die Performance dieser Kamera (drastisch) herabsetzt. Hier gilt also, sich je nach Aufgabenstellung bei der eingesetzten Kamera für Bildqualität oder Bildratenschnelligkeit zu entscheiden.

Sensorfusion für eine bessere Odometrie der acaBot-Roboter (Bachelorarbeit)

"T" 

Wird ein Roboter in einem Prozessleitsystem betrieben, ist die Sache einfach: das PCS (process control system) schaut sich alles akribisch genau an und sagt jedem Roboter genau, wo er sich gerade befindet. Im Prozessleitsystem des PSE-Labors sind hierfür sechs hochauflösende Kameras zuständig. Fährt ein Roboter hingegen ohne eine solche Kontrolle von außen alleine und auf sich gestellt, ist er gefordert, permanent seine odometrischen Spurdaten aufzuzeichnen - immer in der Hoffnung, dass diese korrekt sind ... was jedoch nur am Anfang der Fall ist, denn je länger und weiter der Bot fährt, umso größer wird die Fehler-Ellipse. Ganz eliminierbar ist ein solcher Spurfehler nicht, aber man kann den Fehler dadurch verkleinern, dass mehrere, unterschiedliche Sensordaten fusioniert werden. Im vorliegenden Fall sollen die Encoderdaten der Motoren zusammen mit den Daten eines Beschleunigungssensors für eine bessere Positionsbestimmung sorgen.

"Broomstick-Balancing via Robot-Dancing" Die Realisierung eines inversen Pendels (Masterarbeit, eventuell als Gruppenarbeit)

"MT" 

Wem sämtliche zuvor genannten Themen zu trivial und langweilig erscheinen, der darf sich gerne auch an einer ganz besonderen Herausforderung aus der Regelungstechnik profilieren: dem Balancieren eines Besenstiels auf einem omnidirektionlen acaBot-Roboter mit Mecanumantrieb. Alles, was man dafür an Hardware benötigt, ist ein mechanisch sehr stabiler Joystick (den haben wir!), der auf der Oberseite des Bot befestigt wird. Der Besenstiel steckt, wer hätte es gedacht, mit einem Ende am Stiel des Joysticks. Durch Auswertung der beiden Joystick-Potentiometer über einen Analogwandler kann zu jedem Zeitpunkt die aktuelle Besenstielstellung ermittelt werden. Gerät der Besenstiel aus der Geradestellung in die Schiefstellung, muss sich der unter ihm befindliche Bot korrespondierend in die eine oder andere Richtung bewegen, um die Abweichung auszugleichen. Was man sonst noch braucht? Ahnung von Mathe. Die Programmierung sollte in C++ oder Python erfolgen. Wen es interessiert, der kann sich über das Stichwort "Inverses Pendel" zunächst mit dem theoretischen Wissen vertraut machen und sich dann bei uns melden. Es wäre für den Anfang auch möglich, das Problem auf einen Freiheitsgrad einzuschränken. Mutige vor!