Auch dieses Jahr war der Besuch der German Open des RoboCup in Magedeburg ein fester Bestandteil des Terminkalenders. Hier schon einmal die ersten Fotos. Videos folgen noch…
Unterbodenbeleuchtung
Unterbodenbeleuchtung…? fragt sich sicher der ein oder andere. Inspiriert durch iRobots AVA Roboter fiel die Entscheidung, zwischendurch (um mal was zu bauen, was funktioniert ;-) ) eine RGB-Beleuchtung für den Roboter direcs1 zu entwickeln.
Quelle: http://www.botjunkie.com
Die Idee die dahintersteckt ist, verschiedene Zustände leicht signalisieren zu können; z.B. "rot=Hindernis" oder "grün=freie Fahrt". Zum Ansteuern von den ausgewählten RGB-LED-Streifen wurden sechs Optokoppler (4N33 813) auf die vorhandene Steuerplatine gelötet – gar nicht so einfach bei der Verkabelung:
Die Optokoppler sind erforderlich um die LEDs zu schalten, die direkt an 12V angeschlossen werden können:
Nun galt es, die flexiblen LED-Streifen – die übrigens bei Pollin bestellt wurden – auf der Unterseite des Roboters zu montieren. Durch die Klebestreifen, die an den Streifen bereits dran sind, ist dieses sehr simpel. Auch kann die Meterware ca. alle 10 cm einfach mit der Schere geteilt werden. Praktisch. Hier die Fotos dazu:
Nicht ganz so einfach gestaltete sich das Verlegen der Anschlusskabel für die LED-Streifen am Bot. Aber lösbar:
Nun noch das Ganze für den zweiten Streifen:
Und so sieht der erste Test aus:
Wie man sieht, sind hier alle Farbkombinationen möglich, wenngleich erst einmal nur die offensichtlisten genutzt werden sollen wie "grün=freie Fahrt" oder "rot=Hindernis". Praktisch dabei: Es wurden die PWM-Anschlüsse des Atmel-Boards genutzt, so dass hier auch verschiedene Helligkeiten möglich sind. An diesen Portbits waren früher einmal Servos angeschlosssen. Darum existiert auch noch jeglicher Code in der Software zur Ansteuerung, nur dass eben sich nicht Servos drehen, sondern LEDs heller oder dunkler werden.
Und so sieht das Ganze dann im Betrieb aus (hier leider nur Fotos, bei denen nur eine Seite beleuchtet ist):
Motor Fehlersuche Finale
Wie es aussieht, weisen die Motorcontrol-Boards einen Defekt auf. Hier wurde nun eines der Boards bereits gegen ein neues ausgetauscht. Und *tusch* hier das Ergebnis:
Motor Fehlersuche Teil 4 und 5
Im letzten Video zeigte sich, dass anscheinend immer 12 Volt bei den Motoren ankommen, zumindest per Messgerät gemessen. Nun erfolgt der gleiche Test erneut, also mit Betrachtung der Portbits über die 7-Segement-Anzeige (die offenbar immer okay sind). mit angeschlossenen Messgeräten aber zusätzlich mit angeschlossenen Motoren. Hier das Ergebnis:
Ofenbar verhält sich das Motorboard anders, wenn die Motoren anschlossen sind und schaltet die 12 Volt nicht immer / nicht mehr korrekt. Um nun noch als letzte Fehlerursache die Motoren auszuschließen, wurde als nächstes das Ganze noch einmal mit einem Motor im Austausch getestet – mit dem Scheibenwischermotor im Vordergrund:
Das Finale ist nah…
PS.: Leider war es im Video etwas dunkel und man erkennt die Spannungen auf den Messgeräten nicht wirklich. Sorry.
Motor Fehlersuche Teil 3
Als nächstes galt es festzustellen, ob vielleicht die 12 Volt nicht durch die Motorcontrol-Boards nicht korrekt „geschaltet“ werden. Dazu wurden nun je Motor ein Messgerät angeschlossen und parallel die Ports über die 7-Segement-Anzeige beobachtet. Aber seht selbst:
Das Ergebnis ist noch nicht wirklich erklärbar. Anscheinend funktionieren die Motorcontrol-Boards korrekt. Die Motoren an sich waren aber okay. Fortsetzung folgt…
Motor Fehlersuche Teil 2
Bei der weiteren Analyse wurde nun die 7-Segement-Anzeige zu Signalisierung der Portbits parallel zum Motorboard it den Motoren angeschlossen. Wie man sieht, werden die Bits korrekt gesetzt, aber trotzdem bleibt gelegentlich ein Motor stehen:
Meanwhile: Motor Fehlersuche 1
Wie bisher berichtet, trat in der Zwischenzeit immer noch das Problem auf, dass bei gleichzeitiger Ansteuerung aller vier Motoren (was natürlich immer der Fall ist, das es ja ein Allrad-Roboter ist) immer mal wieder eines der Räder sich nicht dreht. Das Phänomen stellte sich mit allen Motoren reproduzierbar aber immer an verschiedenen Rädern / Motoren und immer zu unterschiedlichen Zeitpunkten auf.
Um herauszufinden, ob die Bits auch richtig vom Microcontroller gesetzt werden, wurden kurzerhand zwei Sieben-Segement-Anzeigen „missbraucht“ um die verschiedenen Stati anzuzeigen. Dargestellt werden hier die vier PWM-Bits (oben und unten) sowie die zwei Bits pro Motor, also acht Segmente. Hier das Video zur Dokumentation dazu:
Wie man sieht, ist hier als erstes ein Fehler aufgezeigt, der bei der Umstellung auf die neuen seriellen Befehle kopiert wurde: Beim „vorwärts“ fahren, werden die gleichen Bits gesetzt wie beim „links“ fahren. Das wurde natürlich als erstes nach diesem Video beseitigt – zeigt aber auch wie praktisch eine einfache Analyse mit direkter Anzeigt mit einfachen LEDs hier schnell Ergebnisse bringt.
Hier noch mal die 7-Segment-Anzeige und die Bedeutung der Segmente im Detail:
Austausch der Festplatte (HDD) gegen eine SSD – Vergleich der Bootzeiten im Video
Leider war die Festplatte auf dem Roboter kurz davor das zeitliche zu segnen – brachte sie doch in hohem Maße Fehlermeldungen. Da auf lange Sicht ohnehin geplant war, der Harddisk die hohen mechanischen Belastungen auf dem fahrenden Bot nicht zuzumuten, wurde diese nun gegen eine 2,5″ SSD namens „OCZ AGILITY 2“ ausgetauscht (Modell ACZSSD2-2AGTE60G). 60 GB sind für das Linux System mehr als ausreichend, so das dieses Größe gewählt wurde.
Interessant sind hierbei natürlich auch die nun extrem kürzeren Bootzeiten, der SSD. Um das einmal aufzuzeigen wurde ein kurzes Video gedreht, in dem das sehr schön zu erkennen ist:
Es handelt sich hierbei wohlgemerkt um ein Debian Squeeze out-of-the-box mit einigen zusätzlichen Programmen, mit einem Standard-Kernel
Warum die Kinect Sinn macht – trotz Laserscanner
Für die, die sich fragen, warum die Kinect denn zusätzlich zum bereits vorhandenen Laserscanner nötig ist, hier ein paar Erläuterungen. Ein Vorteil des Laserscanners ist seine hohe Reichweite. Das kommt sicher im Umfeld einer Wohnung oder eines Hauses sicher kaum zum Tragen, ist aber nicht zu verachten. Vor allem aber ist der Laserscanner, dessen normales Einsatzgebiet Sicherheitsbereiche in der Fabrikation mit extrem hohen Anforderungen ist, sehr zuverlässig. Eine optische Erkennung, die auf Software basiert kann derzeit nur ungenauer sein, als die bereits seit langer Zeit im Einsatz befindliche und erprobte Hardware.
Der wesentliche Nachteil des Laserscanners gegenüber der Microsoft Kinect Kamera ist aber, dass er nur zweidimensional scannt. Die Laserstrahlen breiten sich wie ein Fächer nur auf einer Ebene aus. Um das deutlich zu machen wurde im Folgenden ein Päckchen vor dem Roboter als "Hindernis" platziert – einmal hochkant, so dass es in den Scanbereich des Laserscanners hineinragt und einmal flach auf dem Boden liegend, so dass die Laserstrahlen über das Päckchen hinweg gehen. Und so sieht das Ganze dann aus:
Deutlich zu erkennen, dass im linken Screenshot das Päckchen von der Software als Hindernis erkannt wird (hellroter Bereich="Hindernis", grüner Bereich = "frei") während auf dem rechten Bild das Hindernis nur von der Kinect dargestellt wird (weiße grobe Umrisse links unten in dem schwarz-weiß-Bild), für den Laserscanner aber alles "frei" scheint (grün).
Anmerkung: Die Software wertet die Kinect-Daten noch nicht aktiv aus, sondern zeigt sie nur als Bild an.
Kinect sychron mit OpenCV als Qt Thread – endlich
Nach vielen Versuchen in der noch frischen Kinect-Welt ist nun endlich ein lauffähiger erster Wurf heraus gekommen. Aber erst noch ein paar Worte zur Vorgeschichte und als Erfahrungsbericht, falls noch jemand in diese Probleme Herausforderungen läuft.
Begonnen wurde mit der Nutzung von openFrameworks, da es hierzu ein komplexes Beispiel gab, welches auf Anhieb das Bild der Kinect (RGB und Tiefenbild) anzeigt und zusätzlich sogar eine 3D-Punktwolke und auch schon per OpenCV Hindernisse als Blobs darstellt. Vorteil dieser Lösung ist, dass sie unter Mac OS X und unter Linux einwandfrei lief. Nachteil lag (für mich) darin, dass es ein recht komplexes oder besser gesagt sehr vielfältiges Framework ist, welches zusätzlich auf diverse eigene Bibliotheken und zig eigene Datentypen zurückgreift – Nicht gerade der einfachste Einstieg, wenn man ansonsten nicht auf diesem Framework aaufbaut.
Eine weitere Herausforderung war, dass das Ganze in die "Qt-Welt" von direcs eingebettet werden muss, also z.B. mit den genialen Qt-eigenen Mitteln für Events und Eventhandler (sogenannte Signals und Slots). Hierzu gab es dann weitere Experimente, die dann auch mit dem Qt Framework ganz gut zusammen liefen. Hier gab es dann die Schwierigkeit (für mich), dass das Bild mittels OpenGL angezeigt wurde. Da aber ja der Bildinhalt später mit OpenCV weiter verarbeitet werden sollte, gestaltete sich dieses als schwierig.
Um OpenCV erst einmal weitere Erfahrungen zu sammeln, wurde das Buch Learning OpenCV (ISBN 978-0-596-51613-0) von Gary Bradski & Adrain Kaehler aus dem berühmten O’REILLY-Verlag beschafft. Für 50 EUR nicht gerade ein Schnäppchen; ein Fachbuch eben. Das Buch gefällt; leider basiert es auf der alten OpenCV Version 2.0. Seit Dezember 2010 ist Version 2.2 aktuell, bei der es so einige Änderungen gab – insbesondere haben sich die Bibliotheksnamen geändert und es wird offenbar nun viel der Datentyp Mat statt IplImage verwendet, was beim Verständnis bzw. beim Umsetzen von Code-Beispielen, die man im Netz aktuell hat (mir) oft noch schwer fällt. Erste Erfolge wurden daraufhin wie hier beschrieben dann auch zusammen mit Qt und OpenCV erzielt – hier aber noch mit der im iMac verbauten Kamera, nicht mit der Kinect.
Nun galt es per libfreenect / OpenKinect an das Kamerabild der Kinect zu kommen, das ganze als Qt Thread laufen zu lassen und per OpenCV weiter zu verarbeiten. Und – tadaa – hier es das Ergebnis:
Und nach vielen Stunden Anpassen, Programmieren und Verstehen kam dann auch das Tiefenbild hinzu:
Hier noch einmal mit Roboter und Laserscanner im vollen Betrieb:
Im Gegensatz zu den meisten Beispielen im Netz wird hier übrigens das synchronous Interface / Wrapper genutzt! Verwendet wurde Qt 4.7.1 und OpenCV 2.2.0 – beides installiert unter Mac OS X via MacPorts. Der Sourcecode ist wie immer bei im online Repository bei github als Open Source verfügbar (camThread.h und camThread.cpp). Viel Spaß. Fragen? Kommentare? Gerne.