Monat: November 2010

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

Meanwhile: checking of the motor behavior

 After changing the serial method to transceive ASCII clear text instructions instead if binary data, I found out that that the motors do not react the same when using identical instructions. To ensure that this is not due to a hardware error – and since it does not look like a software error too – I built a small analysis connector which disconnects all connections at all to test every electrical module  seperately. This is how the test looked like:

 

As you can see the green LED shows the state of the corresponding Atmel port bit. For easier testings I simple connected some series resistors of 1.5 k Ohm in line with some LEDs connected to the common ground – with 7-segmend-LEDs, to be more precise. These were than directly soldered on the board connecter:

 

This stuff worked as expected. After this the input ports from the motor control boards were set to high (one after another) to check of these boards work as expected. The most important thing when testing things like this: a wel organised and tidy working environment! 

 

To be honest the reason for this wild flying wires here are was that I had to test this directly at and close to the robot. Since I wanted to have a realistic test case with the original power supply etc. This is why I unmounted the PCBs only this far that I was able to connect all relevant connectors and not resulting in a short circuit.

Using this opportunity I finally labeld the last connectors and cables with this DYMO stuff – since at least anything was disassembled at this moment:

   

Result so far: No error found. After reassambling everything, all motors worked like they should – allthough nothing was changed. Strange….