Microsoft Kinect – Halterung im Eigenbau

 Um mal wieder ein klein wenig handwerkliche Arbeiten zu machen, wurde die Kinect-Kamera für eine spätere Montage auf dem Roboter vorbereitet. Da sicher viele sich schon überlegt haben, wie man diese Kamera montieren könnte, hier eine mögliche Lösung dazu.

Als erstes wurde der Fuß der Kamera geöffnet. Hierzu wird die gummierte Seite vorsichtig abgezogen. Vorsichtig deshalb, weil sie später wieder aufgeklebt wird. Unterhalb der Gummiabdeckung befinden sich 4 kleine Torx-Schrauben, die sich aber zur Not auch mit einem Schlitzschraubendreher entfernen lassen. Das sieht dann geöffnet so aus:

 

 

Hier die Gummiabdeckung:

 

In den Fuß der Kinect-Kamera sollen nun 3mm "Gewinde" verbaut werden. Damit die Torx-Schrauben leichter eingesetzt werden können, wird die entfernte Gummiabdeckung wie abgebildet eingeschnitten. Und zwar genau an den Stellen, wo die kreisrunden Abdrücke im Gummi zu sehen sind. Ruhig grob ausschneiden. Bohren in das dünne Gummi hat nicht gut funktioniert, darum einfach per Saitenschneider oder Cutter das Material entfernen:

  

Nun die Kunststoffabdeckung fest aber vorsichtig einspannen und mit einem 3 mm-Bohrer drei Löcher in die gekennzeichneten Stellen bohren (die Stelle beim Metallbügel nicht durchbohren):

   

Danach die überstehenden Rest vorsichtig(!) mit einem großen Bohrer herunter bohren, damit es danach so aussieht:

 

Nun das Gummi wieder aufkleben:

 

Als nächstes drei 3mm-Schrauben von der Unterseite (Gummiseite) durch die Löcher stecken, mit Muttern von innen verschrauben und leicht anziehen:

 

Nun der entscheidende Teil, von dem leider kein Foto vorhanden ist. In dieser Position, wie das Teil auf dem letzten Foto liegt, Heißkleber vorsichtig über die Muttern (mit den durchgesteckten Schrauben laufen lassen. Hierbei gut darauf achten, dass der Kleber 1. möglichst nur in die Kammer rund um die Mutter läuft und 2.  möglichst keine Lufteinschlüsse innerhalb des Heißklebers sind.

Den Kleber ausreichend abkühlen lassen (im Idealfall über Nacht) und danach ggf. überstehende Reste mir einem Cutter vorsichtig entfernen. Das Ergebnis sieht dann hoffentlich so aus:

Wenn man die Schrauebn nun vorsichtig heraus dreht, sieht man *tadah* die neuen Gewinde im Fuß der Kinect-Kamera:

Und hier das Gesamtergebnis (mit einer Schraube). Viel Spaß beim Basteln:

 

  

 

Die hier gezeigte Anleitung führt zum Verlust der Garantie der Kamera und erfolgt auf eigene Gefahr!

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.

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.

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…

Allgemeiner Aufbau direcs1

Auf dieser Seite sollen die einzelnen Bestandteile des Roboters direcs1 näher beschrieben werden.

Das Grundgerüst des Roboters sieht wie folgt aus:

Als Rahmen wurden Aluminium-Profile verwendet, die verhältnismäßig günstig sind:

 

Bezugsquelle: Kalms Flightcase GmbH

Die Räder sind so genannte Mecanum-Räder. Diese versetzen den Roboter in die Lage

  • sich auf der Stelle um sich selbst zu drehen
  • links und rechts seitwärts zu fahren
  • ganz normal vorwärts und rückwärts zu fahren oder
  • diagonal, also schräg nach vorne oder hinten links oder rechts zu fahren:

 

Die im rechten Bild zu sehenden Aluminium-Halter sind Eigenentwicklungen.

Bezugsquelle: About AndyMark, Inc.

Die Motoren sind vom teuren Conrad. 1-12V Getriebemotoren Modelcraft . Der Roboter besitzt vier 1-12V Getriebemotoren Modelcraft (RB350050-22723R) mit 6200 UPM und 1:50 Untersetzung was dann 110 UPM ergibt. Der Stromverbrauch beträgt je Motor maximal 0,75A wobei sie maximal 0,695 Nm leisten [und nicht 5 Nm wie im Datenblatt fälschlicherweise angegeben]:


Im Bild bereits zu sehen, dass der Motor um einen stabileren Halter aus den obigen Aluminiumprofilen erweitert wurde.

Bezugsquelle: Conrad Electronic SE

Der Antrieb wurde mittels Zahnriemen und Zahnriemenscheiben realisiert:

Bezugsquelle: Conrad Electronic SE

Die Stromversorgung des Roboters erfolgt über vier 12V-Akkus mit jeweils 7Ah zwei LiPo-Akkus: Einen 4S und einem 6S mit jeweils 5000 mAh und C30:

11-1V-30c-5000mAh-3-Cells-Li-Po-Rechargeable-Battery-With-Deans-T-Plug  Mystery_22_2V_30C_5000mAh_6S_RC_LiPo_Battery_Deans_plug

Bezugsquelle: Pollin Electronic GmbH Ebay

Auf dem Roboter direcs1 stehen drei verschieden Spannungen in zwei verschiedenen Stromkreisen zur Verfügung

  • 24V für den Laserscanner in Stromversorgungskreis 1
  • 12V für das Commel Mainboard in Stromversorgungskreis 1
  • 5V für den Microcontroller und sonstige Sensoren / Schaltkreise in Stromversorgungskreis 1
  • 12V für die Motoren in einem eigenen Stromversorgungskreis 2.

Erzeugt werden diese Spannungen mittels Schaltregler auf den folgenden Platinen:

 

Bezugsquelle: reichelt elektronik GmbH & Co. KG

Die Schaltkreise sind über Sicherungen geschützt:

Bezugsquelle: reichelt elektronik GmbH & Co. KG

Über ein zentrales Panel können die Spannungen (und damit der Roboter) eingeschaltet werden. Der silberne Taster ganz links dient zum Einschalten des fit-PCs. Der Not-Aus-Schalter unterbricht lediglich die Stromzufuhr zu den Motoren:

Bezugsquelle Lochblech: Praktiker Deutschland GmbH
Bezugsquelle Bauteile: reichelt elektronik GmbH & Co. KG

Die Low-Level-Steuerung, also die Ansteuerung der Motorcontroller erfolgt über ein Atmel-Board mit einem AVR2560 STM32F4-Discovery-Board mit ARM-Prozessor:

Auf dem Bild ebenfalls erkennbar diverse Steckverbinder zu weiteren Platinen, Eingänge zum A/D-Wandler, welcher die Akkuspannungen überwacht, ein Optokoppler zum Ansteuern der Warnleuchte (siehe auch Folgefotos), diverse Spannungsversorgungsstecker und ein USB-Seriell-Wandler.

Bezugsquelle: watterott.com

Die Motorsteuerung bzw. Regelung der Geschwindigkeiten erfolgt über die folgenden Boards:

Bezugsquelle: robotikhardware.de

Ein weiterer verwendeter Sensor ist ein 3D-Kompass befindet sich mit auf dem STM32F4-Board, ist aber derzeit noch nicht im Einsatz.

Der größte „Sensor“ ist sicher der SICK Laserscanner (rechts im Bild):

Links im Bild ist noch der zuvor verwendete Laserscanner älterer Bauart (PLS 101-312) zu sehen, der aktuell durch ein moderneren namens S30B-2011BA (S300 Standard) ersetzt wurde. Dieser weist zudem eine Auflösung von 0,5° (gegenüber 1°) und ein Überwachungsfeld von 270° (gegenüber 180°) auf.

Bezugsquelle: eBay

Das eigentliche „Herz“ des Roboters ist ein fit-PC2 vollwertiges pico ITX Mainboard LP-170G von Commell mit Atom-Prozessor, 2 GB RAM, 2,5″ Festplatte, 4 USB-Ports, 2 seriellen Ports, 2 PS/2-Ports, Gigabit-LAN, WLAN, CF-Kartenleser, Audio-Ein und Ausgang und VGA-Ausgang:

  

Bezugsquelle: HRT Informationstechnik

Zur Anzeige diverser Stati und späteren Steuerung dient ein 7″ Touchscreen von Faytech dessen Eingangssignal über einen Wandler von HDMI nach VGA gewandelt wird:

  

Bezugsquelle: reichelt elektronik GmbH & Co. KG

Damit der Roboter auch etwas „sieht“, hat er eine Logitech Webcam seit neuestem eine Microsoft Kinect Kamera, deren Bild per WLAN zu eine separaten Applikation oder auf eine beliebige Webseite per motion überträgt:

 

Da direcs1 auch über eine Sprachausgabe verfügt, sind zwei Lautsprecher mit integriertem Verstärker ebenfalls vorhanden:

 

Um den Roboter über einen externen Joystick oder Gamepad manuell zu steuern, wurde eine externe USB-Buchse von Neutrik montiert (hier noch ein altes Foto mit dem alten Laserscanner rechts):

 

Bezugsquelle: reichelt elektronik GmbH & Co. KG

Als letztes hat er natürlich auch eine Warnleuchte, wie es sich für einen richtigen Roboter gehört:

Und so sieht er nun (01.09.2012) vollständig aus:

    

 

 

Screenshots direcs

 

Zwei aktuelle Screenshots – einmal der erste Test mit dem neuen ARM-Board unter Linux in der Debian-VM (Parallels unter Mac OS X), der zweite nativ auf dem Mac.
15.04.2012

Erste Experimente mit der Microsoft Kinect Kamera und dem OpenKinect / libfreenect Sourcecode.
30.12.2010

Größeres Redesing: Grafischen Heartbeat korrigiert, Roboter-Motor-Status wird nun grafisch rechts oben angezeigt (mit GUI LEDs), Änderung der Hauptfenstergröße zur Anzeigen auf dem MacBook Pro.
30.11.2010

Kleine Verbesserungen in der GUI: Grafische LEDs über den Zustand diverser Module im „state“ Bereich rechts oben, Gitternetzlinien innerhalb der Plot-Fenster (Batteriespannungen) und ein grafischer Heartbeat (rot).
14.11.2010