Er fährt!

Nachdem im vorigen Beitrag gezeigt wurde, was alles nicht geht, und wie auch in der letzten Sendung meines Podcasts erwähnt, kann ich heute sagen: Kaum 7,5 Jahre später… und er fährt! ;-)

Sicher noch nicht perfekt und im hier auch noch sehr langsam, aber die „Richtung“ ist erkennbar. Nun gilt es noch die Parameter etwas zu optimieren, damit er auch noch durch die Tür fährt. Derzeit ist dieser Abstand dem Roboter noch zu eng. Alle diese Werte, wie diese „Durchfahrweite“, die per Kosinussatz anhand der Laserlinien ermitteltwird, können übrigens in der GUI „live“ über einen Settingsdialog geändert werden.

 

Hindernisumfahrung – Erstes Ergebnis

Wie im vorigen Beitrag gezeigt, fuhr der Roboter beim Starten nicht in die Richtung, die vom obstacleCheckThread schon lange ermittelt wurde. Der Fehler wurde gefunden und nun sieht das Ganze schon etwas besser aus. Noch nicht perfekt, aber es geht in die richtige Richtung – im wahrsten Sinne des Wortes:

PS.: Natürlich ist dieses nicht die Endgeschwindigkeit, aber zum Testen erstmal ganz angenehm.

 

Hindernisumfahrung – Erste Analyse

Wie im vorigen Beitrag gezeigt, schafft es der Roboter gerade hervorragend mutig gegen ein Hindernis zu fahren – ohne auszuweichen. Um herauszufinden, woran es liegt, wurde nun die Fahrt des Bots etwas präziser aufgezeichnet. Zuvor wurde der TFT-Bildschirm ummontiert, so dass diese endlich in Fahrtrichtung zeigt und auch von oben etwas besser erreichbar ist. Hier das mit der Hand gedrehte Video:

Es ist etwas wackelig, da ich die Kamera nicht fest auf dem Roboter montieren konnte. Sie würde trotz aufgesetztem Weitwinkel-Objektiv zu weit nach hinten vom Bot abstehen. Und ich möchte mir nicht vorstellen, was passiert, wenn der Roboter sich dann dreht und die Kamera mit Halterung irgendwie abbricht, stürzt oder ähnliches…

Was ist also im Video oben passiert? Hier sieht man erst einmal die Richtung in die der Bot fährt:

Wie man sieht, ist der grüne Bereich der Laserlinien der für den Roboter befahrbare Bereich und der Roboter hat als sogenannte „preferred direction“ bereits links gewählt – Erkennbar an dem Pfeil in der GUI, der nach links zeigt:

Was macht er aber genau nicht, wenn man auf dem Touchscreen auf „Start“ klickt? Richtig. Nach links fahren. Denn obwohl der obstacleCheckThread die ganze Zeit aktiv ist (sonst würde der Pfeil nicht nach links zeigen), fährt der Roboter geradeaus – und fährt komischerweise auch weiter geradeaus. Normalerweise sollte der obstacleCheckThread sofort die Info per Qt’s Signal und Slot Mechanismen an alle beteiligten Prozesse senden, dass es nach links gehen. Hier gilt es also, einen schönen Bug zu finden! Bleibt dran…

Hindernisumfahrung mit Hindernissen

Nach vielen vielen Code-Updates und dem kompletten Rewrite des sogenannten obstacleCheckThreads, war es endlich an der Zeit, den Roboter drauf los zu lassen. Hello world… ;-)

Es gab zwar beim Testen ein- oder zweimal Abstürze, beim Betrieb der Software unterm Mac (Roboter war „aufgebockt“, Fahrpogramm gestartet), diese konnten aber bislang nicht reproduziert werden.

Um es gleich vorweg zu nehmen: Alles funktioniert eigentlich einwandfrei. Jedoch „erkennt“ der Roboter die Hindernisse derzeit noch zu spät. Obwohl bereits die langsamste Fahrgeschwindigkeit gewählt wurde und auch das Entfernen des sleep commands aus laserThread und obstacleCheckThread keine Beschleunigung brachte, reichte dies alles nicht aus, den Roboter dazu zu bringen, schnell genug auszuweichen.

Im Moment habe ich ehrlich gesagt keine Idee, woran es liegen könnte… Genug der Worte, hier die einzelnen Videos.

Hier sieht man, wie der Roboter – wie im späteren Fahrbetrieb – mit dem onBoard-PC läuft, jedoch noch „aufgebockt“:

Beim zweiten Video sieht man, wie der Roboter „richtig“ fährt und auch dem ersten Hindernis brav ausweicht, aber dann unmotiviert (leider aus dem Bild) bei einem Hindernis festhängt, dann aber wendet um anschließend mutig Richtung Werkbank zu fahren. Vor lauter Schreck bleibt er er jedoch vor dem Hindernis stehen und aktiviert den Zustand „alles voller Hindernisse“ (Blitzlicht an, alles stoppen):

Nun wurde kurzerhand ein Laptop auf den Bot „befestigt“ (Festplatte zuvor vom Roboter auf den Laptop geclont) um zu Testen, ob der onBoard-PC vielleicht zu langsam ist. Sieht aber nicht danach aus. Auch das klappt nicht wie gewünscht:

Da er beim vorigen Film drohte, erneut die Staffelei umzureißen (auch wegen der provisorisch befestigten, aber herausragenden Aluschiene), hier noch ein letzter „Outtake“. Ich nenne ihn mal „mutiges Hindernis-Anfahren, um dann doch zu stoppen“:

 

Serielle Übertragungen vom STM-Board zum Computer über USB

Es geht voran mit dem STM32F4-Discovery Board!

Um es vorweg zu nehmen: Die folgende serielle Übertragung geschieht nicht über die bereits auf dem STM-Board verbauten USB-Ports. Nach Studium diverser Threads im Internet erwarb ich ein neues IC, welches in der Lage ist, den seriellen Port des ARM-Prozessors (USART) in einen USB-Port zu wandeln. 

Das Ganze ist auf einem sogenannten Breakout-Board von Sparkfun gleich praktisch fertig verlötet, man muss nur noch Stiftleisten hinzufügen. Zum Einsatz kommt hier der Baustein FTDI232R, der keine weiteren Bauteile mehr benötigt und auch gleich mit den 3,3 Volt Logiklevel des STM-Boards klar kommt. Entgegen dem Datenblatt von FTDI müssen bei der Verbindung zwischen dem Breakoutboard drei Leitungen verlötet werden: TX mit RX und RX mit TX und natürlich die gemeinsame Masse, GND. Wer will könnte auch noch gleich zwei Hardware flow control Leitungen mit anschließen – beide Boards unterstützen dieses. So sieht die Testverbindung dann mit den Steckern aus:

 

Hier das Breakout-Board mit dem FTDI-Chip und der USB-Buchse (rechts, mit oranger Schutzfolie) noch einmal im Detail:

  

Und so wird das Ganze dann zum Testen angeschlossen: Das schwarze USB-Kabel, welches zum STM-Board führt, dient hier nur zum flashen des selbigen und zur Stromversorgung. Das transparente USB-Kabel, welches zum FTDI-Board geht, ist das Kabel, welches dann zum PC oder Mac geht. Wird dieses dann angeschlossen, erscheint z.B. unter Linux und Mac OS X ein Device namens /dev/tty.xxxxx bzw. /dev/ttyUSBx. Beim Mac enthält „xxxxx“ gleich eine einmalige Seriennummer. Bestellt hattee ich das Board übrigens bei Watterott (ca. 14 EUR).

  

Hier sind beide Boards dann mal zum Testen am „PC“ des Roboters angeschlossen:

 

Später sollen dann die Daten vom PC des Roboters zum STM-Board (über den FTDI-Chip) und zurück fließen. Diese Aufgabe übernimmt derzeitnoch ein Atmel-Board mit einem Atmega 2560. Tipp: Auf dem STM-Board gibt es diverse USART, wovon aber einige bereits z.B. durch den vorhandenen USB-Port belegt sind! Ich habe mich daher für den noch freien USART2 entschieden.

 

Erstes serielles Testprogramm für das STM-Discovery Board

Nach etwas Suche im Netz fand ich hier und hier Beispiele für serielle Übertragung vom STM-Board. Um es vorweg zu nehmen, das zweite Beispiel verwendet die Open Source Bibliothek libopenmc3. Ich habe mit dem dortigen USART Beispiel lange experimentiert und das Senden war auch erfolgreich. Auch das Empfangen von Daten am STM-Board lieg gut. sobald ich jedoch den TX_RX-Modus aktivierte, ging das Senden nicht mehr. Vielleicht hat jemand eine Lösung – mir gelang es nicht. Ich bin daher wieder zurück auf die Standard-Library von STM gewechselt und mit dem ersten Beispiel dann mit Senden und Empfangen erfolgreich gewesen.

Der folgende Aufbau ist jedoch erst einmal noch „nur Senden“ vom STM-Board Richtung Mac / PC [Update: Auch der Empfang ist mittlerweile (ohne libopenmc) gelöst, hierzu später mehr]

Um hier zu sehen, ob das funktioniert, konnte ich endlich mal meinen Logik Analyser testen. Für alle, die dieser Analyser interessiert, er ist erhältlich bei Saleae und bietet tolle Analysemöglichkeiten. Und das Beste: Die dazugehörige Software läuft unter Linux, Windows und Mac OS!

Das serielle Beispiel sendet nun Zeichen vom STM-Board ausgehend. Die seriellen Signale können dan direkt an einem der Pins abgegriffen werden. Achtung: Die seriellen Ports des STM-Boards dürfen nicht direkt an einen PC angeschlossen werden, da das STM-Board nur mit 3,3 Volt also „logisch HIGH“ arbeitet“. Der PC aber mit 5 oder gar 15 Volt!

Der Versuchsaufbau sah dann wie folgt aus:

 

Hier der entscheidende Ausschnitt des Sourcecodes:

Sehr schön ist hier in der Software des Logic Analysers nun das serielle Protokoll zu erknnen – bzw. die gesendeten Zeichen, die übertragen werden:

 

 

Programme für das STM32F4DISCOVERY Board unter Mac OS X 10.7 (Lion) erstellen und übertragen (flashen)

Voraussetzung für das compilen von ARM-Programmen ist die hier beschriebene Toolchain! Als erstes in das zuvor beschriebene stlink-Verzeichnis wechseln und das „Standard Periph Drivers“ Beispiel erstellen:

cd stlink/example/stm32f4/STM32F4xx_StdPeriph_Driver/build
make
Nun können wir das im stlink-Repository mitgelieferte Beispiel verändern, um später zu sehen, ob unser Code auch erfolgreich geflasht wurde. Dazu in das entsprechende Verzeichnis wechseln:

cd stlink/example/stm32f4/Projects/discovery_demoEs ist übrigens genau das Beispiel, welches ab Werk auf dem Board installiert ist. Wer dieses nicht anpassen möchte, den nächsten Schritt einfachen überspringen..

Nun z.B. in der Datei usbd_desc.c in Zeile 55 folgende Änderung vornehmen und speichern:
Alt:

#define USBD_MANUFACTURER_STRING      „STMicroelectronics“Neu:

#define USBD_MANUFACTURER_STRING      „STMicroelectronics Markus

Nun das Beispiel einfach per make erstellen.
Jetzt gibt es zwei Möglichkeiten das Programm auf das Board übertragen (flashen):
Möglichkeit 1)
cd stlink
./flash/flash write example/stm32f4/Projects/discovery_demo/STM32F4-Discovery_Demo.bin 0x8000000
./st-flash write example/stm32f4/Projects/discovery_demo/STM32F4-Discovery_Demo.bin 0x8000000Wichtig: Hier die .bin Datei verwenden, nicht die .elf Datei!

 

Möglichkeit 2)
cd stlink
./gdbserver/st-util 4242 usb

Dann in einem zweiten Terminal folgendes zum Flashen ausführen:

arm-none-eabi-gdb (gdb) target extended localhost:4242
(gdb) load STM32F4-Discovery_Demo.elf
(gdb) continue

Fertig! Du hast nun erfolgreich das Programm zum Board übertragen!

Um die oben durchgeführte Änderung am Sourcecode zu sehen, jetzt den zweiten (Mikro)USB-Port an den Mac anschließen und die Mac Software USB Prober bei angeschlossenem Board starten. Nun auf dem Board den blauen Taster (User Taster) betätigen. Ggf. im USB Prober den Refresh-Button betätigen. Es erscheint ein neues Gerät namens „Joystick in FS Mode“. In den Details sieht man nun die eben durchgeführte Änderung im Source Code (hier rot markiert):

 

Full Speed device @ 9 (0xFA130000): .............................................   Composite device: "Joystick in FS Mode"
    Port Information:   0x0018
           Not Captive
           External Device
           Connected
           Enabled
    Device Descriptor   
        Descriptor Version Number:   0x0200
        Device Class:   0   (Composite)
        Device Subclass:   0
        Device Protocol:   0
        Device MaxPacketSize:   64
        Device VendorID/ProductID:   0x0483/0x5710   (STMicroelectronics)
        Device Version Number:   0x0200
        Number of Configurations:   1
        Manufacturer String:   1 "STMicroelectronics Markus"
        Product String:   2 "Joystick in FS Mode"
Configuration Descriptor
        Length (and contents):   34
            Raw Descriptor (hex)    0000: 09 02 22 00 01 01 00 E0  32 09 04 00 00 01 03 01  
            Raw Descriptor (hex)    0010: 02 00 09 21 11 01 00 01  22 4A 00 07 05 81 03 04  
            Raw Descriptor (hex)    0020: 00 0A 
        Number of Interfaces:   1
        Configuration Value:   1
        Attributes:   0xE0 (self-powered, remote wakeup)
        MaxPower:   100 ma
        Interface #0 - HID/Boot Interface   
            Alternate Setting   0
            Number of Endpoints   1
            Interface Class:   3   (HID)
            Interface Subclass;   1   (Boot Interface)
            Interface Protocol:   2
            HID Descriptor   
                Descriptor Version Number:   0x0111
                Country Code:   0
                Descriptor Count:   1
                Descriptor 1   
                    Type:   0x22  (Report Descriptor)
                    Length (and contents):   74
                        Raw Descriptor (hex)    0000: 05 01 09 02 A1 01 09 01  A1 00 05 09 19 01 29 03  
                        Raw Descriptor (hex)    0010: 15 00 25 01 95 03 75 01  81 02 95 01 75 05 81 01  
                        Raw Descriptor (hex)    0020: 05 01 09 30 09 31 09 38  15 81 25 7F 75 08 95 03  
                        Raw Descriptor (hex)    0030: 81 06 C0 09 3C 05 FF 09  01 15 00 25 01 75 01 95  
                        Raw Descriptor (hex)    0040: 02 B1 22 75 06 95 01 B1  01 C0 
                    Parsed Report Descriptor:   
                          Usage Page    (Generic Desktop) 
                          Usage (Mouse)    
                              Collection (Application)    
                                Usage (Pointer)    
                                    Collection (Physical)    
                                      Usage Page    (Button) 
                                      Usage Minimum...........    (1)  
                                      Usage Maximum...........    (3)  
                                      Logical Minimum.........    (0)  
                                      Logical Maximum.........    (1)  
                                      Report Count............    (3)  
                                      Report Size.............    (1)  
                                      Input...................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield) 
                                      Report Count............    (1)  
                                      Report Size.............    (5)  
                                      Input...................   (Constant, Array, Absolute) 
                                      Usage Page    (Generic Desktop) 
                                      Usage (X)    
                                      Usage (Y)    
                                      Usage (Wheel)    
                                      Logical Minimum.........    (-127)  
                                      Logical Maximum.........    (127)  
                                      Report Size.............    (8)  
                                      Report Count............    (3)  
                                      Input...................   (Data, Variable, Relative, No Wrap, Linear, Preferred State, No Null Position, Bitfield) 
                                    End Collection     
                                Usage (Motion Wakeup)    
                                Usage Page    (Vendor Defined) 
                                Usage 1 (0x1)    
                                Logical Minimum.........    (0)  
                                Logical Maximum.........    (1)  
                                Report Size.............    (1)  
                                Report Count............    (2)  
                                Feature.................   (Data, Variable, Absolute, No Wrap, Linear, No Preferred, No Null Position, Nonvolatile, Bitfield) 
                                Report Size.............    (6)  
                                Report Count............    (1)  
                                Feature.................   (Constant, Array, Absolute, No Wrap, Linear, Preferred State, No Null Position, Nonvolatile, Bitfield) 
                              End Collection     
            Endpoint 0x81 - Interrupt Input   
                Address:   0x81  (IN)
                Attributes:   0x03  (Interrupt no synchronization data endpoint)
                Max Packet Size:   4
                Polling Interval:   10 ms

Getestet wurde dieses alles übrigens seinerzeit unter Mac OS X 10.6 (Snow Leopard) und danach auch unter Mac OS X 10.7 (Lion).

Wer das Ganze etwas bequemer innerhalb Eclipse erstellen und compilen möchte, kann sich hier in Svens Anleitung die nötigen Schritte anschauen.

STM32F4DISCOVERY unter Mac OS X 10.7 (Lion) – und warum die Linux-Anleitungen nicht funktionierten

Um für den ARM-Prozessor auf dem STM32F4-Board eigene Programme zum Laufen zu bekommen, benötigt man eine passende Toolchain. Denn normalerweise erzeugt ein Compiler standardmäßig ja nur ausführbare Programme, die auf dem eigenen Computer laufen – bzw. auf einem mit der gleichen CPU. Um also ein lauffähiges Programm für den ARM-Prozessor zu erzeugen, nutzt man das sog. cross compiling; dass heißt man nutzt den eigenen schnellen Rechner (hier ein Apple iMac mit Intel Core i7 @ 2,8 GHz) um auf diesem die Software für den im Vergleich viel langsameren Rechner zu erzeugen (hier das STM32F4 Discovery Board).

Getestet wurde dieses alles übrigens seinerzeit unter Mac OS X 10.6 (Snow Leopard) und danach auch unter Mac OS X 10.7 (Lion).

Für den bisher auf meinem Roboter verwendeten Atmel-Prozessor gibt es für Mac-Anwender ganz bequem ein fertiges Installations-Paket hier. Für Linux (Ubuntu, Debian u.ä.) hat Sven hier eine 1a-Anleitung verfasst – die ich auf dem Mac auch verwenden wollte. Verwenden wollte, ist das richtige Stichwort. Erste Herausforderung war die Installation der benötigten Pakete auf dem Mac. Diese wäre normalerweise mit MacPorts kein Problem. Leider benötige ich aber für meine libfreenect die libusb-devel, welche sich nicht zusammen mit der libusb hier installieren lässt. Um es vorweg zu nehmen: Dieses habe später in Kauf genommen. Wer also, hier ein Problem hat, muss für sich prüfen, wie er beide installiert bekommt, den gegenseitigen Ausschluss gelöst bekommt oder die libusb ggf. für die libfreenect patcht…

Also als erstes die per MacPorts installierte libusb-devel entfernen:
sudo port uninstall libusb-devel

Sollten hier noch alte Versionen installiert sein und MacPorts sich darüber beschweren, diese beim Entfernen genau angeben. Zum Beispiel so:
sudo port uninstall libusb-devel @1.0.8.20101017_2

Der zweite Grund, warum ich Svens Linux-Anleitung unter Mac OS X (Lion) nicht verwenden konnte ist, dass von ihm verwendete Codesourcery Toolchain anscheinend nicht für 64 Bit-Systeme geeignet ist – was bei Lion, aber der Fall ist. Jedenfalls brachte der GNU/Linux Installer von Codesourcery die Fehlermeldung, man solle ia32 Bibliotheken installieren. Und da die Seiten von Mentor Graphics nicht gerade durch Übersichtlichkeit glänzen, entschied ich mich im Web nach einer passenden Mac OS Lösung zu suchen.

Die nachfolgenden Schritte habe ich dann erfolgreich der englischen Anleitung hier, hier und hier entnommen. Da viele Anwender gerne auch mal eine deutsche Anleitung haben wollen, werde ich die Schritte hier 1:1 aufführen:

Download des Tools „STLink“ für Mac OS (genauer: Auschecken des Repositories) in ein Verzeichnis deiner Wahl. Zum Beispiel /Users/markus/develop/STM
cd develop/STM
git clone https://github.com/texane/stlink.git
Wer git noch nicht installiert hat, installiert dieses über MacPorts: sudo port install git

Nun die zuvor erwähnte libusb installieren:
sudo port install libusb

Nun das Tool STLink bauen:
cd stlink
./autogen.sh
./configure
LIBRARY_PATH=/opt/local/lib C_INCLUDE_PATH=/opt/local/include make CONFIG_USE_LIBSG=0

Zum Testen das Board an den „normalen“ USB-Anschluss mit dem Mac verbinden und Folgendes im stlink-Verzeichnis eingeben:
./gdbserver/st-util 4242 usb
Als Ergebnis sollten die LEDs auf dem Board nicht mehr blinken (wie sie es ab Werk tun) und im Terminal werden einige Zeilen wie die folgenden ausgegeben:

non-option ARGV-elements: 4242 usb
2011-12-27T19:16:37 INFO src/stlink-usb.c: — exit_dfu_mode
2011-12-27T19:16:37 INFO src/stlink-common.c: Loading device parameters….
2011-12-27T19:16:37 INFO src/stlink-common.c: Device connected is: F4 device, id 0x413
2011-12-27T19:16:37 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 Bytes
Chip ID is 00000413, Core ID is  2ba01477.
KARL – should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242…

Gratulation! Wenn es so aussieht, hast du dich erfolgreich mit dem Board verbunden. Nun gilt es „nur“ noch die Toolchain zu installieren… Die nachfolgenden Schritte habe ich dieser Anleitung entnommen.

Ein Wehrmutstropfen noch an dieser Stelle: Der folgende Weg lässt bisher nicht die Nutzung der Fließkomma-Einheit zu. Dazu ist zusätzlicher manueller Aufwand nötig; wie hier beschreiben. Sobald ich diese verwenden möchte, werde ich das auch noch mal testen und dann hier berichten. Aber erst einmal der einfachere Weg.

Als erstes nötige Abhängigkeiten installieren:
sudo port install gmp mpfr libmpc wget libftdi

Nun die ARM-Toolchain besorgen:
git clone https://github.com/esden/summon-arm-toolchain.git
Hier gibt es auch noch einen Fork für die Nutzung der Fließkomma-Einheit, dieser lief bei mir aber nicht erfolgreich durch!

In das heruntergeladene Verzeichnis wechseln:
cd summon-arm-toolchain

Und die Toolchain bauen und installieren (dauert  je nach Rechner so 20 – 30 Minuten, da einiges heruntergelanden wird!). Standardmäßig installiert sich die Toolchain mit dem Aufruf von ./summon-arm-toolchain in das Homeverzeichnis nach ~/sat.

 

Um sie in ein sinnvolleres Verzeichnis wie z.B. /usr/local zu installieren gibt man zum Beispiel
sudo ./summon-arm-toolchain PREFIX=/usr/local
ein. Das ganze dauert ein paar Minuten, da so einiges runtergeladen, entpackt, erstellt und installiert wird!

Update 28.10.2012
Unter Mac OS 10.7.5 mit dem aktuellsten macport libs (gmp 5.0.5_0, mpfr 3.1.1 und libmpc 1.0.1_0) bekam ich nach einem Restore und Neueinrichten meines System immer folgende Fehlermeldung

******************************************************************
* Configuring gcc-linaro-4.6-2011.10 and newlib-1.19.0
******************************************************************
[...]
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations.  Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/.  See also
http://gcc.gnu.org/install/prerequisites.html for additional info.  If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files.  They may be located in separate packages.
Die Lösung war folgender Aufruf zum Installieren der Toolchain:
sudo ./summon-arm-toolchain PREFIX=/usr/local DARWIN_OPT_PATH=/opt/local

 

Update 23.05.2012

Beim Ausführen des letzten Befehls oben kommt es offenbar derzeit zu einer Fehlermeldung und damit zum Abbruch (siehe auch hier):

******************************************************************
* Downloading gcc-linaro-4.5-2011.02-0 sources...
******************************************************************
--2012-05-23 22:37:08--  http://launchpad.net/gcc-linaro/4.5/4.5-2011.02-0/+download/gcc-linaro-4.5-2011.02-0.tar.bz2
Auflösen des Hostnamen »launchpad.net (launchpad.net)«... 91.189.89.223, 91.189.89.222
Verbindungsaufbau zu launchpad.net (launchpad.net)|91.189.89.223|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 303 See Other
Platz: https://launchpadlibrarian.net/63823291/gcc-linaro-4.5-2011.02-0.tar.bz2[folge]
--2012-05-23 22:37:09--  https://launchpadlibrarian.net/63823291/gcc-linaro-4.5-2011.02-0.tar.bz2
Auflösen des Hostnamen »launchpadlibrarian.net (launchpadlibrarian.net)«... 91.189.89.228, 91.189.89.229
Verbindungsaufbau zu launchpadlibrarian.net (launchpadlibrarian.net)|91.189.89.228|:443... verbunden.
FEHLER: Dem Zertifikat von »launchpadlibrarian.net« wird nicht vertraut.
FEHLER: Das Zertifikat von »»launchpadlibrarian.net«« wurde von einem unbekannten Austeller herausgegeben.

 

Lösung:

Die Datei summon-arm-toolchain mit einem Texteditor öffnen (z.B. TextEdit) und folgende Anpassung vornehmen (rot = vorher, grün = nachher, den Rest so lassen!):

function fetch {
     if [ ! -e ${STAMPS}/$1.fetch ]; then
        log „Downloading $1 sources…“
        wget -c –no-passive-ftp $2 && touch ${STAMPS}/$1.fetch
        wget -c --no-passive-ftp --no-check-certificate $2 && touch ${STAMPS}/$1.fetch
     fi
}

Danach den Befehl erneut ausführen:

sudo ./summon-arm-toolchain PREFIX=/usr/local

Fertig!

 

Du bist nun in der Lage Code für den ARM-Prozessor auf deinem Mac zu erstellen und ihn auf das STM-Board zu übertragen (flashen). Wie das geht, wird im folgenden Artikel beschrieben.

Analyse der fit-PC2 Probleme – Teil 2 (vor fit-PC-Tod)

 Auf der Suche der USB-Probleme, genauer, warum die USB-Verbindung offensichtlich verloren geht, geht es hier nun weiter. Wie man hier sieht, geht zeitweise die USB-Verbindung zwischen PC und Atmel-Board verloren:

Bei der vorangegangenen Analyse wurde bereits klar, dass das Problem nicht auftritt, wenn das Atmel-Board an ein anderes Gerät als den fit-PC2 angeschlossen wird, also z.B. an den iMac oder ein anderes Linux-Laptop. Um alles auszuschließen, wurden erst alle Stromversorgung extern aufgeteilt; also jede Spannung wurde durch ein eigenes Netzteil angeschlossen (5V, 12V und 24V):

Dieses brachte leider noch keine Änderung: Nach mehreren Motor Ein- und Ausschaltvorgängen, ging die USB-Verbindung wieder verloren. Nach weiteren Tests fiel auf, dass ein wichtiger Hinweis aus dem Wiki von roboternetz.de vernachlässigt wurde: Und nie vergessen Motoren zu entstören!

Solle es also daran liegen? Streuen die Motoren so viele Störungen Richtung fit-PC? Also, "kurz mal eben" alle Motoren und deren Kabel ausgebaut, ausgetauscht (die Kabel) und gemäß Wiki entstört:

     

Ja, Entstören wurde leider sträflich versäumt in der Vergangenheit. Und das Ergebnis? Leider nichts! Der oben gezeigte Fehler tritt noch immer auf. Fortsetzung folgt…

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: