Last update: 11.08.2008 | © 2010 Julian von Mendel
Werbung für meine Firma:
jInvent —
Softwareentwicklung | Micropayment:
Matthias Bär, Michele Collodo und ich haben zwischen Juni 2007 und März 2008 an dem Projekt gearbeitet.
Siehe roboking.de
Der Kernpunkt der Aufgabe ist es, möglichst schnell möglichst viele Tennisbälle in einer gestellten Spielsituation auf einem 6m²-Spielfeld zu sammeln.
Video vom Roboter auf der Cebit 2008, wie er sich ausnahmsweise mal klug verhält, mit drehbaren Entfernungssensoren zum Bälle-Finden: 2.4 MiB DivX | Youtube
Eine Weiterentwicklung ist momentan in Arbeit, erste Versuche mit der CMUcam3, d. h. Kamera & Bildverarbeitung on Board sehen so aus: 3.6 MiB DivX | Youtube
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
Das Fahrwerk besteht aus drei Omniwheels (Allseitenradantrieb), mit denen man in beliebigen Richtung starten und während der Fahrt drehen kann. Drei aus alten PS/2-Mäusen ausgebaute Radencoder konnten die Drehung der Räder auf 3,42° genau messen. Für die Radencodern empfiehlt sich zum Entprellen dringendst ein Schmitt-Trigger. Man kann ihn in einem Atmel leicht umsetzen, in dem man im Pin Change Interrupt bei jeder Wertänderung abhängig vom aktuellen Messwert den Pullup an- oder ausschaltet. Die Software sollte über die Radencoder ständig die Position nachberechnen und auf Basis der aktuellen Position und einer Zielposition automatisch die effizienteste Motoransteuerung ermitteln, um durch Schrägfahrt und Drehung während der Fahrt möglichst schnell definierte x- und y-Koordinaten auf dem Spielfeld zu erreichen und in einem definierten Winkel ausgerichtet zu sein. Messungen mit teureren Conrad-Gleichstrommotoren haben eine Proportionalität zwischen Spannung und Drehzahl ergeben, wenn eine bestimmte Mindestspannung erreicht wird.
Wir verwenden fünf optische Entfernungssensoren zur Navigation, zwei davon sind drehbar. Durch Kantenerkennung wollten wir mit den drehbaren Sensoren Bälle finden, anhand der Objektbreite kann man erraten, ob es sich um einen Tennisball oder einen feindlichen Roboter handelt. Zum Ballsammeln verwendeten wir eine Schaufel, die über ein Seil und einen Servo hochgeklappt werden kann. Dazu muss der Ball exakt eingeparkt sein. Auf der zweiten Ebene des Roboters können bis zu drei Bälle gelagert werden, möchte man sie abladen, kann man die zweite Ebene über einen Servomotor und ein Seil nach oben bewegen.
Der Bereich, in den ein Ball eingeparkt werden muss, um gesammelt zu werden, war bei unserem Roboter sehr klein. Wäre er mechanisch so konstruiert gewesen, dass größere Toleranzen beim Einparken bestehen, hätten wir mehr Bälle gesammelt.
Die Elektronik besteht aus einer selbstentwickelten Platine mit drei ATMEGA168-Prozessoren, die untereinander per SPI Aufgaben koordinieren. Die Elektronik ist so allgemein gehalten, dass sie für zahlreiche Anwendungen geeignet wäre. Sie ist für die Verarbeitung von drei Radencodern, neun Entfernungssensoren, zwei Tastern, der aktuellen Akkuspannung und sechs Fototransistoren geeignet, kann sechs Gleichstrommotoren, sieben Servos und vier LEDs ansteuern. Über zwei serielle Schnittstellen kann mit einem PDA, einem PC, einem TFT oder einer CMUCam3 kommuniziert werden. Wir haben die Elektronik sicherheitshalber doppelt aufgebaut und mittlerweile auch für nicht auf den Roboter bezogene Projekte eingesetzt. Doppelseitiges Layout und Schaltplan auf Anfrage.
Die Software ist in C geschrieben. Mehr Informationen zur Software und zum Mehrprozessorkonzept in diesem PDF. 5500 unvollständige und teilweise mangelhaft getestete Zeilen Programmcode unter der LGPL3 gibt's zum Download.
Die Mathematik zur Bestimmung der x-, y- und Winkelgeschwindigkeit anhand der drei mit den Encodern gemessenen Drehzahlen ist nicht ganz einfach, wir konnten im ganzen Internet auch niemanden finden, der das schon einmal gemacht hat. Die Einzelschritte sind in dieser wirren Texdatei dokumentiert. Die Ansteuerung der Motoren hingegen ist leicht: Jede Motorgeschwindigkeit errechnet sich aus cos(0 - radwinkel - aktuellerwinkel), die Radwinkel betragen 0°, 120° und 240°.
Die Mechanik zum Ballsammeln war aufgrund der verwendeten Seilkonstruktion anfällig. Die Ballsammelschaufel ragte etwas über den Roboter hinaus, was es unmöglich machte, Bälle, die ganz an der Wand liegen zu sammeln, da sich die Schaufel dann verklemmte. Ansonsten lief die Mechanik, insbesondere das Fahrwerk, perfekt. Nervig war die unideale Verkabelung, die unpraktisch wechselbaren Akkus und das Zusammenbauen der Ebenen. Für zukünftige Versionen einigten wir uns auf ein einzelnes, sehr großes Kabel, Schrittmotoren, und Neodym-Magneten statt Schrauben mit Muttern… Die Positionsberechnung allein auf Basis der Encoderwerte war ungenau, da beispielsweise beim Einparken eines Balls, der nahe an der Wand liegt, diese gestreift wurde, und dann Raddrehungen evtl. nicht direkt zur vermuteten Positionsänderung geführt haben. Die Auflösung der Encoder war gleichzeitig nicht ausreichend genau.
Die Elektronik enthielt einige kleinere Fehler und Unvollständigkeiten, erwies sich im Großen und Ganzen jedoch als recht ausgereift und robust. Das Lötfeld auf der Platine war sehr praktisch, die Tatsache, dass wir die gesamte Peripherie über Jumper mit den Prozessoren verbunden haben war ebenfalls sehr vorteilhaft: wollte man umverkabeln, konnte man zwei Jumper herausziehen und zwei Kabel verlegen, um z. B. zwei Sensoren mit jeweils einem anderen Prozessor zu verbinden. Die Buchsen- und Steckerleisten, die wir zur Verbindung mit der Außenwelt verwendet haben sind von mieser Qualität und nicht empfehlenswert.
Die Software wurde über neun Monate hinweg entwickelt und war gegen Ende äußerst umfangreich, lief jedoch nicht fehlerfrei. Zwei Tage vor dem Finalwettbewerb habe ich 5000 Zeilen ordentlich strukturierter und modular, anwendungsunspezifisch entwickelter Software teilweise durch schlampige, chaotische Lösungen ersetzt. Es waren bis zum Ende hin Fehler in der Protokollimplementation und der Zielpositionsberechnung.
Das Hauptproblem waren die optischen Entfernungssensoren, die ich absolut falsch eingeschätzt hatte. Ich ging davon aus, dass man mit ihrer Hilfe die Entfernung zu einem Tennisball zwischen 300 und 1500mm Entfernung relativ genau bestimmen könne — Schwankungen in den Messwerten und die Tatsache, dass die Sensoren mit Infrarotlicht arbeiten, demzufolge weisse Objekte am besten erkennen können, führte zu einem geringerem Messbereichsmaximum von etwa 800mm und höherer Ungenauigkeit. Die drehbaren Sensoren sollten sich so schnell drehen, dass für jeden Winkel nur ein Messwert vorhanden ist (ein Sharp-Sensor braucht pro Messung etwa 60 Millisekunden), folglich ist es theoretisch unmöglich, Schwankungen auszufiltern. Ein fehlerhafter Messwert hat zu einem falsch erkanntem Ball geführt. Evtl. hätte man hier klüger vorgehen können, in dem man bei der Vermutung eines Balls die Sensoren in dessen Richtung ausrichtet und weitere Messungen durchführt. In der Praxis haben wir mit einer gewissen Wahrscheinlichkeit einen Ball richtig angefahren, kannten seine Position jedoch nicht genau genug, um jedesmal richtig einzuparken. Baugleiche Sharp-Sensoren liefern unterschiedliche Messwerte. Wir haben für jeden Sensor versucht, eine Kurve auszumessen, und eine Näherungsfunktion aufzustellen, waren jedoch nur begrenzt erfolgreich. Von Anfang an auf eine CMUCam zu setzen wäre evtl. klüger gewesen.
Ein Mehrprozessorsystem, Omniwheels und die geplante, exakte Positionsbestimmung der Tennisbälle waren an sich überdimensioniert, da sie für den Wettbewerb nur geeignet gewesen wären, wenn alles perfekt funktioniert hätte. Eine einfachere Lösung, beispielsweise sturres Abfahren des Spielfelds mit einer Schneeschaufel vorne am Roboter, die möglichst viele Bälle erwischt, lässt sich erheblich leichter umsetzen und führt zu besseren Ergebnissen. Wer in einem Wettbewerb dieser Art gewinnen möchte, sollte versuchen, die einfachst mögliche Lösung perfekt umzusetzen. Gleichzeitig hat gerade das Mehrprozessorsystem und die komplette Neuentwicklung eines sehr umfangreichen Frameworks für die Programmierung von einem Mehrprozessor-Atmel-System natürlich zu einiger Programmiererfahrung auf diesem Gebiet geführt.
Die unperfekte Positionskorrektur und die schlechten Sensoren kombiniert mit unausgereifter Sensorverarbeitung führten dazu, dass wir während dem Finalwettbewerb gelegentlich einen Ball gesammelt haben, jedoch keinen einzigen in die Rinne gebracht haben. Fehlannahmen im Programm und die Prozessparallelisierung führten zu einem Roboter, dessen Verhalten vom Kommentator mit »motorischen Störungen« beschrieben wurde. Wir haben es bis in den Zwischenwettbewerb der Finalrunde in der zweiten Liga geschafft.
© 2009 Julian von Mendel (http://derjulian.net) | Datum: 03.09.2010
