DIRECS – Seite 16 – Developing Intelligent Robots with Enhanced Capabilities

Kinect Live-Bild in vorhandene Roboter GUI integriert

Die Integration des Kinect-Bildes geht voran. Sowohl das Live-Bild, als auch das "Tiefenbild" wird nun in der GUI angezeigt. Und hier die ersten Tests:

Wie man sieht, ist auf dem ersten Bild eine leicht geöffnete Tür (zum Flur) erkennbar – sowohl auf dem "original" Livebild der Kamera, als auch an den grünen Laserlinien und im Tiefenbild der Kinect; erkennbar am blauen Bereich. Im zweiten Bild sieht man die geöffnete Tür. Auf dem dritten ist sowohl auf dem Kamerabild also auch bei den Laserlinien eine Person gut erkennbar.

Weitere Fortschritte mit der Microsoft Kinect – Erste erfolgreiche Nutzung mit Qt!

Ein erster eigener Erfolg wurde beim Ansteuern der Kinect erzielt: Vollständige Integration in ein eigenes eigenständiges Qt-Programm. Zugrunde liegend der Open Source Treiber / die Library OpenKinect. Des weiteren sollte der Wrapper für das Qt Framework, welches von mir genutzt wird, verwendet werden, dieser aber brach aber mit Compiler-Fehlermeldungen ab. Statt dessen wurde auf OpenKinect and Qt reference von Jon Macey zurück gegriffen, welches genau so einen Wrapper zur Verfügung stellt. Und so sieht das ganze dann in der per Qt-Designer erstellten GUI aus:

Der Sourcecode ist wie immer hier verfügbar. Der direkte Link zum eigenständigen Kinect-Testprogramm ist dann dieser. Das Original von Jon Macey wurde des weiteren dahingehend erweitert, dass es z.B. bei nicht angeschlossener Kinect das Programm nicht per EXIT beendet, sondern eine von außen abfragbare Variable abgefragt werden kann, ob die Kamera erkannt wurde oder eben nicht.

Zwischenschritt: Analyse von Motorverhalten

Beim Umstellen der seriellen Funktionen auf ASCII-Klartext-Anweisungen anstatt binärer Daten, stellte sich heraus, dass die Motoren nicht immer gleich auf die selben Anweisungen reagierten. Um sicher zu gehen, dass es kein Hardwarefehler ist – und weil ein Programmfehler nicht feststellbar war – wurde kurzerhand ein kleiner Analysestecker gebaut und alle Verbindungen insgesamt aufgetrennt um jedes elektrische Modul für sich sauber zu testen. Und so sah der Test dann aus:

Wie mah sieht zeigt die grüne LED den Zustand des betreffenden Portbits des Atmel an. Zum einfacheren Testen wurden einfach ein paar LEDs mit je einem 1,5 k Ohm Vorwiderstand gegen Masse auf den betreffenden Pfostenverbinder gelötet:

Das funktionierte offenbar wie gewünscht. Anschließend wurden umgekehrt die Eingänge der Motorcontrol-Boards jeweils per Drahtbrücken auf high gesetzt um zu sehen, ob die Motorcontrol-Boards beide ordentlich funktionieren. Das Wichtigste dabei: Eine ordentliche und aufgeräumte Testumgebung!

Spaß beiseite. Hintergrund dieser wilden Verkabelung ist natürlich, dass das Board "vor Ort" also in der Originalumgebung "im Roboter" getestet werden soll, also mit der gleichen Spannungsversorgung etc. Also wurde die Platinen nur soweit gelöst, dass man an die betreffenden Stecker ordentlich ran kommt und etwas unter die Platinen gelegt, damit es keine Kurzschlüsse gibt.

Nun wurden endlich auch die letzten Stecker und Kabel bei der Gelegenheit beschriftet – wo sowieso schon mal alles auseinander gebaut war:

Ergebnis: Interessanterweise wurde kein Fehler gefunden und nach dem Zusammenbau funktionierte alles wie gewünscht – ohne was geändert zu haben. Irgendwie seltsam…

Erste Tests mit der Microsoft Kinect und OpenKinect / libfreenect

Wie aus dem letzten Post vielleicht für den einen oder anderen zu erkennen, handelt es sich bei dem selbst gemachten Weihnachtsgeschenk um die Microsoft Kinect, die gerade vielfältig von sich reden macht. Denn eine Art 3D-Sensor in dieser Preisklasse schien vorher nicht recht möglich. Seit ein paar Tagen werden die gehackten und mittlerweile als Open Source verfügbaren Treiber, Libraries und Sourcecodes untersucht und ein wenig damit experimentiert. Hier die ersten Eindrücke:

Und hier das erste Erfolgserlebnis im etwas angepassten Sourcecode:

Wie man an der markierten Stelle sieht, wird hier schon ganz gut ein mögliches "Hindernis" für den Roboter angezeigt. Auf dem Live-Bild der Kamera rechts oben im Bild ist ein "Klavier-Hocker" zu erkennen. Der Sourcecode wurde so angepasst bzw. beim Programmstart so eingestellt, dass im Fenster links unten nur Objekte (Hindernisse) ab einer bestimmten Entfernung markiert (umrahmt) werden. Das Programm zeigt das größte Hindernis an, erkennt nun deren Mittelpunkt innerhalb des Bilders (X/Y-Koordinaten) und zeigt auch den Abstand des Objektes an. Und das beste: Das läuft soweit bereits unter Mac OS und unter Linux.

Genutzt wurde dazu der als Open Source verfügbare Treiber / die Library OpenKinect. Ergänzt um openFrameworks und ofxKinect. Vorteil dieser Lösung ist, dass sie unter Windows, Linux und Mac OS läuft. Ein Nachteil dieser Lösung könnte sein: Es gibt zwar einen Wrapper für das Qt Framework, welches von mir genutzt wird, aber da fehlen sämtliche OpenCV Elemente, die bei der openFrameworks Lösung alle schön beinhaltet sind. Da ist also noch etwas Analyse erforderlich, wie das ganze zusammenzubringen ist. :-) Es wird nicht langweilig…

Kleines Spielzeug…

Der Weihnachtsmann war da und hat ein bisschen neue (Robotik?)Hardware mitgebracht:

Mal sehen, was man da noch so schönes mit anstellen kann… :-)

PS.: Damit halbwegs noch was zu erkennen ist, bitte das Video auf Vollbild stellen. Links unten sind bei den „erkannten“ Objekten dezent rote Rahmen um sie herum zu erkennen. Leider wurde die beim Umwandeln twas „wegoptimiert“. Aber mit etwas Mühe sind sie zu sehen. Leider ist das Original-Video irgendwie verschütt gegangen. Sorry…

Demo-Video der GUI im aktuellen Stand

In der Zwischenzeit wurde viel am Code geändert, ab nur unter Linux. Geändert ist ehrlich gesagt auch zu viel gesagt, getestet ist hier wohl das richtige Wort. Denn aus bisher unerklärlichen Gründen läuft der Code für die serielle Ansteuerung für den Sick S300 Laserscanner zwar unter Mac OS X und unter Linux auch zusammen mit dem Atmel, aber nicht unter Linux – dort aber wohl mit dem Atmel. Alles klar? Also: Der Atmel kannunter Linux und unter Mac OS X erfolgreich angesteuert werden, der Laser aber nur unter Mac OS X (selber verwendeter Sourcecode).

Um die Langeweile für die Leser dieses Blogs ein wenig zu überbrücken, wurde ein Video (Screencast) vom aktuellen Stand der GUI (unter Mac OS X) erstellt. Und hier ist es:

Erstellt wurde Video übrigens mit iShowU HD unter Mac OS X (10.6).

Montage des Commel Pico ITX Boards, der Festplatte und der WLAN-Antenne

Nachdem das neue Pico-ITX Board von Commel; das 170G nun "verkabelt" wurde,

ging es an die Montage des Boards auf dem Roboter. Verbaut wurde es an die gleiche Stelle, an der zuvor der fit-PC2 war:

Hierzu wurde es wie bewährt auf die Profilschienen geschraubt:

Wie man an den Detailfotos sieht, wird das Board mit Kunststoffmuttern und -unterlegschreiben auf den Distanzbolzen festgehalten, damit hier keine besonderen Masseschleifen o.ä. entstehen. Das Kabel rechts im Bild mit den freien Kontakten am Pfostenstecker geht übrigens zum Ein-Aus-Schalter auf dem Bedienpanel:

Um nun die 2,5" Festplatte zu befestigen, bedurfte es Distanzbolzen mit sehr kurzem Gewinde. Diese wurden kurzerhand mit einer Schleifmaschine gekürzt. Tipp dazu: Vor dem Kürzen eine passende Mutter auf das Gewinde schrauben, damit man hinterher ggf. die verbleibenden Grate leichter beim Lösen der Mutter "wegdreht" [And always wear safety glasses!]:

Und nun die Montage der Festplatte und ein paar verschiedene Blickwinkel:

Nun noch die WLAN-Antenne montiert, die übrigens samt mini-PCI-Karte noch aus dem defekten fit-PC2 stammt:

Und noch mal im Ganzen fotografiert:

Und nun am Roboter montiert:

Ein abschließender Test durfte nicht fehlen:

PS.: Die Kabel am Mainboard sind natürlich erst provisorisch und müssen noch "verlegt" werden. Und ja, der rote Text im letzten Foto zeigt leider noch eine Fehlermeldung vom Laserscanner. Irgendwie bringt dieser unter Linux – aber nur unter Linux – noch Fehlermeldungen und bricht dann ab. Da ist noch Forschungsarbeit zu leisten.

GUI weiter verbessert und aufgeräumt

Langsam war es an der Zeit, die GUI weiter zu verbessern und auch so in der Darstellung dahingehend anzupassen, dass sie auf dem MacBook Pro mit einer Auflösung von 1680×1050 noch gut dargestellt wird. Vorab das Ergebnis:

Im Wesentlich wurde auf der rechten Hälfte der Bereich Odometrie entfernt und ein Teil der Daten in das rechts oben angezeigte Bereich State eingefügt. Die Buttons zum Zurücksetzen der gefahrenen Strecke (derzeit per Hardware noch in Planung) sind in das Menü bzw. die Toolbar gewandert. Zusätzlich wurde ein Fehler in der Darstellung des Heartbeat-Plot korrigiert. Auch wurden fast alle Icons in höherer Auflösung hinterlegt und einige gegen leichter identifizierbare ausgetauscht – so z.B. das Reset-Icon, welches nun durch das orange 2-Pfeil-Icon dargestellt wird.

Ebenfalls entfernt wurden die großen Schaltflächen zur Anzeige der einzelnen Motoren-Status. Diese werden nun im State Bereich angezeigt – und zwar grafisch per GUI-LED und anhand des echten Roboter-Fotos in der Draufsicht.

Die LEDs zeigen entsprechend den jeweiligen Status der vier Motoren an: Aus (grau), im Uhrzeigersinn (grün), entgegen dem Uhrzeigersinn (rot). Und so sieht das im Detail aus:

Fahrtest mit Akkus

Hier nun der nächste Fahrttest, dieses Mal mit vollem Gewicht – also allen vier 12 Volt-Akkus. Wie es aussieht scheint das Gesamtgewicht des Roboters damit zu hoch zu sein, denn das Querfahren funktioniert nicht wie gewünscht. Das wird eine gewisse Herausforderung, denn eigentlich werden alle vier Akkus für die beiden Stromversorgungen (24V und 12V) benötigt.

Interessant sicher auch der Strom, der von den drei(!) Netzteilen als Picture-in-Picture im Video angezeigt wird:

Fahrtest ohne Akkus

Nach diversen Hardwareproblemem scheint es nun etwas voran zu gehen. Hier ein neues Video, bei denen der Roboter noch an einer externen Stromversorgung angeschlossen ist – die Akkus sind noch nicht „montiert“. Die Steuerung erfolgt zum Testen über die USB-Verbindung am Mac (nicht im Bild).