GUI – DIRECS

direcs mit optionaler kleiner GUI

Um das direcs Hauptprogramm auf dem Roboter optimal nutzen zu können, wurde für den Roboter die GUI neu designt. Der Clou dabei: Wenn das Programm auf einem Gerät gestartet wird, welches im Hostnamen "robot" enthält, wird automatisch die "kleine" neue GUI verwendet. Klein deshalb, weil sie für die Auflösung des Touchscreens auf dem Roboter optimiert wurde (840×542 Pixel). Bisher wurde die GUI beim compile-Vorgang fest ausgewählt. Ferner kann die kleine GUI auf jedem anderen System erzwungen werden, wenn als Startparameter "small" übergeben wird (die große mit "large"). Verzichtet wurde in der kleinen GUI auf keines der bisherigen Elemente, sie wurde nur anders angeordnet – konkret wurde sie auf mehrere Tabs / Reiter verteilt. Und sieht das Ergebnis aus (nur einige Tabs dargestellt):

PS.: Die Kinect-Kamera und der Roboter warten zum Zeitpunkt der Screenshots nicht angeschlossen und nur der Simulationsmodus aktiviert.

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.

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).

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:

Kleine GUI Verbesserungen

Nach diversen Aktualisierungen im Programmcode sollte auch etwas für die Optik getan werden. Zur leichteren Erkennbarkeit wurden weitere "LEDs" hinzugefügt:

Diese zeigen den Status diverser Module an:

Der Heartbeat blinkt im Rhythmus der Antworten vom Atmel-Board durch Abfrage des Sensorthreads. Sie leuchtet konstant rot, wenn der Roboter nicht als angeschlossen erkannt wurde.
Die Compass-LED zeigt an, ob das Compass-Modul mit dem Atmel-Board physisch verbunden ist.
Die Camera-LED leuchtet (derzeit), wenn mittels OpenCV eine angeschlossene Kamera erkannt wurde.
Die Joystick-LED ist grün, wenn ein Joystick angeschlossen ist.
Die Network-LED soll einmal anzeigen, wenn eine Kommunikation über WLAN mit direcs-remote stattfindet (welches wichtige Status.-Werte des Roboters remote anzeigt).
Eine hier noch nicht dargestellte weitere Laser-LED zeigt an, ob der Laserscanner erkannt wurde.

Als weitere Verbesserung wurden die Plot-Bereiche mit Gitternetzlinien versehen, was nicht nur eine leichtere Lesbarkeit bewirkt, sondern insgesamt einen professionelleren Eindruck macht:

Um auf einen Blick noch schneller den Status des Roboters darzustellen, wurde ein weiterer Plot-Bereich hinzugefügt, der im Prinzip den wechselnden Status der Heartbeart-LED darstellt:

Und so sieht das ganze dann vollständig im Betrieb aus:

3D-Kompass-Modul-Verbindung wird geprüft und in GUI angezeigt

Beim Testen des Atmelboards außerhalb des Roboter fiel auf, dass es manchmal bei der seriellen Übertragung nach einiger Zeit timeouts gab. Die Ursache lag im Atmelcode für den Micromag 3D-Kompass. Dieser initialisiert beim ersten Start des Atmels das SPI / I²C Protokoll. Danach fragt das direcs-Hauptprogramm den Atmel nach den Kompassdaten. Ist das Kompassmodul aber nun gar nicht mit dem Atmelboard verbunden, so kommt es zu den timeouts, da im SPI-Code auf bestimmte Bitzustände gewartet wird.

Um dieses zu verhindern und hiermit auch eine weitere Sicherheit einzubauen, wird nun beim Abfragen der Kompasswerte jedesmal geprüft, ob ein bestimmtes Portbit gesetzt ist. Dieses Portbit ist durch einen 100k-Widerstand am Atmelboard standardmäßig auf Masse gezogen. Wird das Kompassmodul nun per Falchbandkabel angesteckt, wird diese Leitung vom Kompassmodul aus auf 5V "hoch gezogen".

Bei der Initialisierung des Atmelboards bzw. der Prüfung ob der Roboter eingeschaltet ist im direcs-Hauptprogramm, wird nun auch zusätzlich abgefragt, ob das Kompassmodul verbunden ist. Dieses wird auch in der GUI grafisch mit einer weiteren LED (rechts oben im Bild) angezeigt.

Atmel-Board gar nicht verbunden (Kompass damit natürlich auch nicht):

Atmel-Board verbunden, Kompassmodul nicht angeschlossen:

Atmel-Board verbunden, Kompassmodul ebenfalls angeschlossen:

Analyse der fit-PC2 Probleme, Update der direcs-remote GUI

Seit langer Zeit gibt es im Blog nicht viel Neues. Dieses liegt vor allem daran, dass es Probleme mit dem fit-PC in Verbindung mit dem Atmel-Controller gibt – scheinbar zumindest. Als erstes stellte sich heraus, dass aufgrund des unter Debian fehlenden Intel-Grafikkarten-Treibers die Performance der GUI so miserabel war, dass diese (eben mangels passenden Treibers) vollständig "in Software gerendert" wurde. Was das bedeutet, kann sich jeder vorstellen: Der größte Teil der CPU-Zeit steht nicht für das eigentliche direcs-Programm zur Verfügung, sondern wurde für den X-Server und/oder die KDE-Oberfläche "verbraucht".

Nach dem Entfernen der kompletten GUI zeigte sich auch, dass für das direcs-Programm auf dem 1,1 GHz-Rechner natürlich genug CPU-Power zur Verfügung hat; trotz diverser parallel laufender Threads für die Sensoren, den Laserscanner, das Netzwerk, den Joystick usw.

In der System-Konsole sah man nun endlich auch, dass derzeit offenbar ein ganz anderes Problem vorliegt. Denn nach Analyse der bisher selbst gedrehten Videos, war schnell klar, dass der fit-PC bisher nie im Einsatz auf dem Roboter war, um diesen – also das Atmel-Board – direkt anzusteuern. Zum Testen wurde in der Vergangenheit immer der Entwicklungungs-PC bzw. -Mac genutzt.

Das Ergebnis von heute sieht also derzeit so aus: direcs auf dem Bot im Konsolen-Modus (ohne GUI) gestartet; wartet auf Befehle (per Joystick oder über das WLAN). Danach wird direcs-remote gestartet (derzeit noch im Teststadium):

Wie man sieht, werden über WLAN vom fit-PC z.B. Spannungswerte der Akkus übertragen und in der GUI angezeigt sowie ein Heartbeat (grüne GUI-LED rechts oben), an dem derzeit lediglich erkennbar ist, dass der SensorThread auf dem Roboter läuft und Daten ausliest bzw. übermittelt.

Klickt man nun links unten auf den "foward" Button (blauer Pfeil nach oben), wird über WLAN der Befehl "forward" an den Roboter gesendet und nun passiert folgendes (was erst in der Konsole sichtbar wurde, da Systemmeldung):

Und hier gilt es nun zu Analysieren, woran es liegt. Denn wird der Roboter z.B. an den Mac oder an ein anderes Linux-Laptop angeschlossen, tritt dieses Problem nicht auf:

Settings Dialog angepasst

Neben ein paar anderen Punkten in der GUI wurde der Settings Dialog angepasst. Er ist nun übersichtlicher und weist den neuen "Robot Slot" mit der Durchfahrtsweite aus. Also die Weite, durch die der Bot mindestens passen muss. Derzeit erfolgt das (in der Logikeinheit) nur anhand eines Winkels. Hier erst einmal der neue Settings Dialog (etwas unspektakulär):

Die Logik muss nun noch dahingehend angepasst werden, dass diese Durchfahrtsweite (in cm) auch aktiv genutzt wird. Berechnet und angezeigt wird sie jedenfalls bereits in der GUI.

S300 Laserscanner eingebunden

Das Update des Programmcodes ist so gut wie abgeschlossen. Hier die erste Ansicht, die natürlich fast wie vorher aussieht, nun eben mit Daten vom SICK S300 Laserscanner:

Es sieht aber nur fast genau so aus, wie vorher: Denn: Der S300 hat eine Auflösung von 0,5 Grad bei 270 Grad "field of view". Darum werden im Screenshot auch 540 statt 270 Laserlinien angezeigt. Daher war auch das Anpassen des Sourcecodes aufwändiger, da an vielen Stellen die Auflösung des Scanners zusätzlich mit integriert werden musste (LaserThread, ObstacleCheckThread, GUI, …).

Ein paar Ausreißer gibt es noch: Wie man sieht ist der Wert für 0 Grad noch falsch (längste rote Linie rechts oben im Bild) und die Flags werden nicht vollständig für alle Linien gesetzt (z.B: grün für den größten freien Bereich). Um einen Eindruck über die Anpassungen zu bekommen, hier eine git Übersicht: