Wie beereits hier angekündigt, sind nun alle Videos auf direcs.de umkonvertiert! Also ab heute kein Flash mehr. Yeah!
Ein Video konnte leider nicht mehr rekonstruiert werden und ist in nicht wirklich toller Qualität. Dafür wurde aber echt alle Videos von allen Robotern und allen Events und so weiter und sofort nach .m4v konvertiert und sollten auf den meisten Endgeräten funktionieren. Viel Spaß.
Es hat sich sicher längst rumgesprochen, das Adobes Flash stirbt, darum habe ich einen neuen Player für meine Videos hier. Dieser ist nun voll HTML5-fähig (versucht aber auch Flash). Ab sofort werden alle Videos neu erstellt und nicht mehr im .flv-Format sondern als .m4v – sprich MPEG4. Und das beste (wie ich finde): Die Videos können damit endlich auch am iPhone/iPad angesehen werden.
Um sicherzugehen, dass möglichst viele die Videos sauber sehen können, habe ich folgende Systeme und Browser getestet:
Mac OS X, 10.7 (Lion)
– Safari
– Firefox
iPhone 4 (iOS 5.0.1)
– Safari
iPad 2 (iOS 5.0.1)
– Safari
Windows XP
– Internet Explorer 7
– Firefox 9
Linux (Debian)
– Iceweasel (mit mplayer)
– Google Chrome
Um in den vollen Genuss der Videos zu kommen, habe ich nun einen Großteil der Videos neu konvertiert und hochgeladen. Das betrifft alle Videos von direcs1, alle Events aus 2011 und das Asimo-Event.
So, der master branch von direcs ist wieder sauber und das Programm läuft mit dem seriellen Port nun offenbar einwandfrei unter Mac OS X und Linux (Parallels VM)… Nun geht es weiter mit cherry-picking aus dem Branch, den ich seit Juni parallel entwickelt hat. Here we go…
Erinnerung an mich selbst: SHA 46b4a9cfd7a32a1456839d05a8d63923e561cb39 ;-)
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!
In der Vergangenheit gab es bekanntermaßen diverse Probleme mit der seriellen Schnittstelle. Um hier beim debuggen nicht immer auf den angeschlossenen Roboter angewiesen zu sein, fiel der Entschluss einen direcs1-Roboter-Simulator zu entwickeln. Ziel sollte es sein eine Software zu haben, die auf dem seriellen Port wie die Software auf dem Atmel Microcontroller Befehle entgegennimmt und genauso "antwortet", also regiert.Gesagt, getan, hier das Zwischenergebnis. Als Name des Simulators wurde direcs-avrsim gewählt.
Vorher noch eine Erklärung, wie das ganze hardwaretechnisch gelöst wurde, denn es müssen ja dann im Betrieb die Daten zwischen zwei seriellen Ports miteinander ausgetauscht werden; also zwischen der direcs-Software und direcs-avrsim. Ganz einfach, man verbindet einfach zwei serielle Ports mit einem seriellen crossover cable, auch Nullmodem-Kabel genannt. Und wenn am Gerät keine seriellen Ports vorhanden sind, jeweils noch über zwei USB-Seriell-Wandler. Und so sieht das Ganze dann aus:
Von Vorteil ist es, wenn USB-Seriell-Wandler mit einem unterschiedlichen Chip verwendet, dann haben die seriellen Ports unterschiedlichere Namen, wie z.B. hier diese drei:
~/develop/direcs% ls /dev/tty*
crw-rw-rw- 1 root wheel 2, 0 17 Jun 19:38 /dev/tty
crw-rw-rw- 1 root wheel 11, 46 19 Jun 16:01 /dev/tty.PL2303-003014FA
crw-rw-rw- 1 root wheel 11, 44 19 Jun 16:02 /dev/tty.SLAB_USBtoUART
crw-rw-rw- 1 root wheel 11, 40 14 Jun 21:29 /dev/tty.USA19Hfa141P1.1
Um die grundsätzliche Funktionalität der Adapter und des Kabels sicherzustellen, bietet es sich an diese mit zwei Terminal-Programmen zu testen. Z.B. auf dem Mac mit goSerial oder in der Shell (Konsole) mit minicom:
Bei jedem Programm muss dann jeweils der passende serielle Port gewählt werden und jeden Befehl, den man auf "der einen Seite" dann eintippt, sollte "auf der anderen Seite" genauso erscheinen.
Hier die nun sehr einfache GUI von direcs-avrsim direkt nach dem Start:
Das abgebildete Relais, das Flashlight und die GUI-LEDs entsprechen Aufbauten auf dem realen Roboter. Als Code der hier zur Verwendung kommt, dient dabei natürlich zu 99% der, der ansonsten auf dem Atmel läuft (main.c). Dieser kann – da es ja Standard-C ist – weiterverwendet werden. Die Atmel-spezifischen Anweisungen (Setzen von Registern, Watchdog etc.) sind natürlich nicht implementiert.
Die GUI wartet nun auf die Entgegennahme von Befehlen auf dem seriellen Port – eben genau so, wie sonst der reale Roboter. Hier sieht man den Status nach Erhalt der ersten Befehle (*re# = Reset, Roboter antwortet mit *ok#):
Hier sieht man unter anderem wie das Flashlight eingeschaltet wurde (Befehl *f0on#, Roboter antwortet ebenfalls mit *f0on#):
Ebenfalls erkennbar ist die Abfrage zweier Sensoren (*s7# und *s8#). Hier antwortet die GUI zurzeit noch mit immer den gleichen Werten. Sie entsprechen den Werten des AD-Wandlers und ergeben umgerechnet dier 12 und 24. Dieses entspricht der Akku-Überwachung mit 12Volt und 24Volt-Akkus.
So, lange gab es keinen neuen Artikel… Hintergrund ist, das zurzeit an einer sehr umfänglichen Umstrukturierung an der direcs-Software gearbeitet wird. Hierzu wurde extra im Sourcecode-Repository ein separater Branch eröffnet, da die grundsätzliche Arbeitsweise rund um den seriellen Port geändert wird. Ursache waren diverse Probleme in der Vergangenheit mit der Kommunikation zwischen PC / Mac und dem Roboter. Aber dazu in den nächsten Tagen mehr…
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…
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.
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.
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.