Autor: Markus Knapp

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.

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

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

 

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:

 

Screenshots direcs1

 

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

Fotos vom neuen Commel Pico ITX Board

Hier ein paar aktuelle Fotos vom neuen ein Pico-ITX Board von Commel; das 170G, welches das neue "Herz" des Roboters direcs1 werden soll. Erste Tests liefen bereits erfolgreich, ein Debian brachte alle Treiber out-of-the-box mit, so dass auch die KDE ebenfalls korrekt mit passendem Grafikkartentreiber lief. Aber hier nun erstmal die Fotos:

      

Hier noch einmal im Größenvergleich mit dem defekten fit-PC2:

    

Hier liegt neben dem neuen Pico-ITX-Board die "alte" Mini-PCI-WLAN-Karte aus dem fit-PC2:

 

Und so sieht das ganze verkabelt und angeschlossen aus – mehr Kabel als Board  :

   

coding, coding, coding…

Nachdem es in der Vergangenheit öfter Probleme mit der seriellen Übertragung gab, fiel der Entschluss, alle Übertragungen zwischen dem Atmelboard und dem Computer nicht mehr in Binärform sondern in reinem ASCII zu senden. Dazu wurde im git Repository ein neuer Branch namens AtmelSerialClearText angelegt und seit Mitte August immer mal wieder daran gearbeitet. Nun ist es endlich soweit, nahezu alle Funktionen sind komplett auf die neue Übertragungsmethode umgestellt – sowohl auf Computer, als auch auf Atmel-Seite. Wie man sieht, waren dazu doch einige Änderungen nötig:

Merge made by recursive.

 direcs-avr/adconv.c         |   33 ++

 direcs-avr/adconv.h         |    6 +

 direcs-avr/main.c           | 1040 +++++++++++++++++++++++++++++————–

 direcs-avr/main.h           |   13 +-

 direcs-avr/micromag.c       |    4 +

 direcs-avr/usart.c          |  174 ++++++–

 direcs-avr/usart.h          |   38 ++-

 direcs/direcs.tag           |  193 ++++++–

 direcs/src/circuit.cpp      |  112 ++++-

 direcs/src/circuit.h        |   39 ++-

 direcs/src/direcs.cpp       |  127 +++++-

 direcs/src/direcs.h         |   19 +-

 direcs/src/direcsSerial.cpp |   65 ++–

 direcs/src/direcsSerial.h   |    2 +-

 direcs/src/gui.cpp          |   79 ++++-

 direcs/src/gui.h            |   37 ++-

 direcs/src/interfaceAvr.cpp |   98 ++++

 direcs/src/interfaceAvr.h   |   58 ++-

 direcs/src/mainWindow.ui    |   86 +++-

 direcs/src/motor.cpp        |  792 +++++++++++++++++++++———–

 direcs/src/motor.h          |   46 +-

 direcs/src/plotThread.cpp   |   47 ++-

 direcs/src/plotThread.h     |   14 +-

 direcs/src/sensorThread.cpp |  495 +++++++++++———-

 direcs/src/sensorThread.h   |   27 +-

 25 files changed, 2540 insertions(+), 1104 deletions(-)

Zusätzlich wurde das serielle Verfahren auf dem Atmel ebenfalls vollständig neu geschrieben und arbeitet nun – anstatt in einer Endlosschleife auf den Empfang eines Zeichens zu warten – vollständig interruptbasiert.

Wie aber weiß nun der Atmel, wann eine Übertragung für ihn anfängt oder abgeschlossen ist? ganz einfach: Jede Übertragung muss mit einem ‚*‘ starten und mit einem ‚#‘ enden. Alle anderen Zeichenketten werden ignoriert. Eine Signalisierung über LEDs auf der Platine findet ebenfalls statt: Bei jedem empfangenen Zeichen blinkt die rote LED abwechselnd und sobald das Ende eines Befehls mit # erkannt wurde (und zuvor auch mit * startete!) wird dieses über eine grüne LED angezeigt.

Diese Art der Übertragung hat den Vorteil, dass man sie per Terminalprogramm gut debuggen kann, denn es werden nur ASCII-Zeichen verwendet. Zusätzlich antwortet der Atmel auch immer mit der empfangenen Zeichenkette, die wiederum vom Computer als Antwort überprüft wird. Eine neue Sicherheitsfunktion, die zuvor fehlte. Auch kann man dem Atmel so selbst mit einem Terminalprogramm Befehle senden und „sieht“ was er antwortet. Fragt man einen Wert vom Atmel ab, so antwortet er nur mit diesem Wert und dem Starter und Terminator, also z.B. mit *42#.

Und das sind die derzeitigen Befehle:

re = reset

s1 = get value from sensor 1

…

s8 = get value from sensor 8

s16 = get value from sensor 16

cc = check if compass module is connected. ‚ok‘ or ‚er‘

cx = get value from compass axis x

cy = get value from compass axis y

cz = get value from compass axis z

ms1 = get value from motor sensor 1

…

ms4 = get value from motor sensor 4

dd1 = get driven distance 1

..

dd4 = get driven distance 4

id1 = init distance 1

…

id4 = init distance 4

mp1of = motor power 1 off

…

mp4of = motor power 4 off

md1cw = motor direction 1 clockwise

…

md4cw = motor direction 4 clockwise

md1cc = motor direction 1 counterclockwise

…

md4cc = motor direction 4 counterclockwise

mv1nnn = set motor velocity 1 to nnn (0-255)

…

mv4nnn = set motor velocity 4 to nnn (0-255)

mv0nnn = set motor velocity for all motors to nnn (0-255)

bdf = bot drive forward

bdb = bot drive backward

bdl = bot drive left

bdr = bot drive right

btl = bot turn left

btr = bot turn right

bgo = bot go

bst = bot stop

bwa = bot wait