Intel bietet zwei verschiedene Linux Varianten für das Galileo Board an, die beide Arduino kompatibel sind.

Das eine Linux firmiert unter clanton-tiny und läuft direkt auf dem Board. Die knapp 8MB große Distribution bietet jedoch so gut wie keine Möglichkeiten zur Interaktion.

Als Alternative gibt es eine clanton-full Distribution, die bereits deutlich mehr Tools zur Verfügung stellt. Insbesondere ist dadurch dann auch möglich sich bei angeschlossenem Netzwerkkabel via

ssh root@galileo

mit dem Board verbinden und erhält eine bash Shell. Die clanton Distribution wird mit Hilfe des yocto-Projektes erstellt. Um clanton-full zu installieren genügt es die zur Verfügung gestellten Files

bzImage - Der Linux Kernel
core-image-nimimal-initramfs-clanton.cpio.gz - Das RAM-Linux, das das Hauptlinux bootet
image-full-clanton.ext3 - Ein Image File, das das gesamte Dateisystem enthält
boot/grub/grub.conf - Die Bootconfiguration, die festlegt welches Dateisystem gestartet werden soll

auf die SD-Karte zu kopieren. Auch das "volle" Linux bietet aber nicht besonders viele Optionen, so dass ich dazu übergegangen bin ein eigenes Linux zu kompilieren. Die entsprechenden recipes kann man sich von Intel unter

https://communities.intel.com/community/makers/software/drivers

herunterladen. Man benötigt die "Board Support Package Sources for Intel Quark".

Für meinen ersten Build meiner SDK-Distribution habe ich mich sklavisch an die von Sergey Kiselev veröffentlichte Anleitung gehalten:

http://www.malinov.com/Home/sergey-s-blog/intelgalileo-buildinglinuximage

Die wichtigsten Schritte im Schnelldurchlauf:

- In meta-clanton_v0.7.5 das Setup Script ./setup.sh ausführen
- In das Build Directory wechseln über source poky/oe-init-build-env yocto_build
- In conf/local.conf die clanton-full Disitribution auswählen
- uClibc patch in v4l2apps auskommentieren
- Rezept für image-sdk erstellen auf Basis des image-full.bb Files
- Die Pakete packagegroup-core-basic packagegroup-core-lsb kernel-dev unter IMAGE_INSTALL zur Installation auswählen
- Die Tools tools-sdk dev-pkgs tools-debug eclipse-debug tools-profile tools-testapps debug-tweaks zu den IMAGE_FEATURES hinzufügen
- Speichergröße um z.B. Faktor 10 auf 3072000 kByte erhöhen (Achtung: Mein Image hatte hinterher knapp 1.5GB benötigt!)
- Den CY8C9540A-Patch hinzufügen
- Das Image über bitbake image-sdk erstellen
- Warten ...

Mit ein bisschen Glück, sollte das Ganze dann durchlaufen, und am Ende findet man die benötigten Files (die man am einfachsten noch umbenennt, so dass sie genauso wie die weiter oben erwähnten Dateien heißen) in dem yocto_build/tmp/deploy/images Verzeichnis.

Das hat natürlich überhaupt nicht funktioniert… Wie man das bei Linux ja schon mal hat…

Zunächst einmal fehlten einige Pakete auf meinem Ubuntu-EeePC, der meine Build-Plattform werden sollte, obwohl ich das build-essential Paket installiert hatte. Immerhin bekommt man in der Fehlermeldung genau mitgeteilt, welche Pakete erwartet werden, so dass man sie über ein entsprechendes

sudo apt-get install <paket-name>

nachinstallieren konnte.

Als nächstes musste ich dann feststellen, dass mein EeePC, der leider mein einziger Linux Rechner im Hause war, keine besonders gute Build-Plattform abgibt. Die komplette 1.5GB Distribution zu kompilieren hat (ungelogen) an die 30 Stunden gedauert.

Wenn es denn dann wenigstens fehlerfrei durchlaufen würde, was mir leider auch nicht vergönnt gewesen ist.

Das OpenCV Paket habe ich nicht gelinkt bekommen. Ich habe immer einen relocation Fehler bekommen. Im Internet wird immer auf die Option -fPIC als Lösung verwiesen. OpenCV selbst wurde aber mit -fPIC erstellt. Ich vermute, dass es am Ende an der Python Library lag. Ich werde mich des Problems ein anderes Mal wieder annehmen, und habe OpenCV schließlich aus dem Image-Recipe entfernt. Dazu einfach die Einträge in der image-sdk.bb Datei unter IMAGE_INSTALL entfernen oder auskommentieren.

Ein weiteres Problem beim Verlinken gab es, weil der Befehl einer Library zu lang geworden ist. Die Parameterlänge ist durch die Stackgröße begrenzt. Ich habe den Stack verdoppelt, aber auf Grund des langen Pfadnamens hatte auch das nicht genügt. Dementsprechend musste ich alles in einen Pfad verschieben, der deutlich weniger lang ist, was (natürlich) einen kompletten Rebuild nach sich zog.

Eine Woche später, war es dann aber endlich geschafft und ich hatte das 3 GB große Image für mein Galileo Board in Händen :-)

Alles weitere kann ich jetzt direkt via ssh auf dem Board selbst kompilieren.

Als Kandidat für die Crawlee Hardware schaue ich mir das neue Intel Galileo Board etwas genauer an. Es handelt sich dabei um einen 400MHz x86 Prozessor auf einem Arduino kompatiblen Board, was eine einfache Inbetriebnahme verspricht.



Gesagt getan tut sich zunächst einmal nichts. Ursache war am Ende meine falsche Annahme, dass der USB-Treiber in dem drivers Verzeichnis liegt. Da liegt aber nur ein FTDI Treiber mit dem wir nichts anfangen können. Am Ende war es am einfachsten,
wenn man bei dem manuellen Treiberupdate das Hauptinstallationsverzeichnis von arduino auswählt.

Von da an hatte es aus der Arduino IDE heraus keine Probleme mehr gegeben. Für Crawlee benötige ich aber gar nicht die Arduino Funktionen, sondern das darunter liegende Linux. Ohne SD Karte genügt der Flash Speicher nur für ein Minimal-Linux, was insbesondere kein WiFi und die ROS Ungebung nicht unterstützt, weswegen ich auf die SD gestützte Variante umsteigen muss.

Interessant ist das Galileo Board, weil es einen x86 Kern in kleinstem Formfaktor bietet. Am Ende sollte es möglich sein beliebige Standart-Komponenten einzubinden, da ja die x86 Treiber verwendet werden können. Von der Leistungsfähigkeit ist es deutlich stärker als der Atmega gestützte Arduino, aber gleichzeitig nicht so leistungsfähig, wie der höher getaktete Raspberry Pi. Für Bildverarbeitung könnte es am Ende nicht reichen, aber ich bin guter Dinge, dass die übrigen ROS-Komponenten funktionieren sollten.