Liebe Besucher,

der Blog wird unter neuer Adresse an anderer Stelle fortgeführt. Ich hoffe ich sehe euch da ;-)

http://blog.ruhr-robots.de

Viele Grüße
Christoph

Zunächst einmal habe ich manuell eine Verbindung mit der Firmware aufgebaut. Der Zugriff auf den EeePC erfolgt über ssh mit

ssh christoph@crawlee-0

Nachdem ich EeePC und RP6 verbunden habe konnte ich eine Terminalverbindung aufbauen mit

sudo gtkterm -p /dev/ttyUSB0 -s 38400

Da das RTS-Signal benutzt wird um den Roboter zu resetten, muss es noch manuell getoggled werden um den Roboter zu starten. Das einzige Problem was dann noch über blieb, war das CR+LF Verhalten, da gtkterm lediglich CR sendet und der RP6 auf ein LF wartet.

Ach ja! Ich hatte noch Zugriffsprobleme unter dem Ubuntu. Um die nötigen Rechte zu erhalten musste der user noch in die Gruppe dialout aufgenommen werden über

sudo adduser christoph dialout

Ich habe mich dann noch gleich in die Gruppe video aufgenommen um später auf die Webcam zugreifen zu können

sudo adduser christoph video

Ich habe mir inzwischen ein Arduino Motor-Shield besorgt, um bei der späteren Hardware die Motoren treiben zu können. Um den Treiber zu testen, habe ich einen kleinen Teststand aufgebaut auf dem ich einen Motor mit einer Luftschraube betreiben kann. Die Kratzer auf dem Aluminium sind meinem handwerklichen Geschick zu schulden, aber seit heute kann ich immerhin sagen: "Ja, ich habe schon einmal mit einem Proxxon frei Hand gefräst." Für den Gesellenbrief genügt es vermutlich nicht, aber glücklicherweise bietet das Ergebnis dennoch ausreichend Halt…



Hier betreibe ich den Motor selbst bereits direkt mit der Batteriespannung. Das Galileo-Board würde ich auch gerne an dem gleichen Batteriepack betreiben. Dafür fehlt mir aber noch ein einfacher DCDC-Spannungswandler (Teile kommen hoffentlich nächste Woche)…

Ich habe erstmalig auch meinen Speed-Blitz testen können. Und in der Tat ist er recht schnell, möchte ich mal behaupten, wenn man sich den quasi stehenden Rotor anschaut.





Die Motoransteuerung selbst war leichter als ich erwartet hatte. Das Arduino-Shield lässt sich leicht über GPIOs und die PWM Ausgänge kontrollieren. Da ich ja ein eigenes Linux aufgespielt habe, kann ich z.Zt. leider keine Sketches aufspielen. Die einzelnen Ausgänge können jedoch direkt als Dateien in dem Linux-Dateisystem angesprochen werden.

Auch hier hat Sergey Kiselev wieder eine schöne (Englische) Einführung geschrieben:

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

Um den Motor an Ausgang B des Shields zu steuern muss ich nun PWM Channel 4 an Pin 11, sowie die GPIOS 13 (Drehrichtung) und 8 (Bremse) programmieren. Unter Linux muss ich dazu einmal die Multiplexer an Linux GPIO ID 43 sowie 55 auf 1 programmieren. Die Linux GPIOs für 13 und 8 sind 39 und 26 respektive.

Die jeweiligen Sequenzen habe ich mir in Shell-Skripte gepackt:

PWM Sequenz

echo -n "4" > /sys/class/pwm/pwmchip0/export
echo -n "1" > /sys/class/pwm/pwmchip0/pwm4/enable
echo -n "1000000" > /sys/class/pwm/pwmchip0/pwm4/period 
echo -n "500000" > /sys/class/pwm/pwmchip0/pwm4/duty_cycle 
echo -n "4" > /sys/class/pwm/pwmchip0/unexport

Brake Sequenz

echo -n "26" > /sys/class/gpio/export
echo -n "out" > /sys/class/gpio/gpio26/direction
echo -n "$1" > /sys/class/gpio/gpio26/value
echo -n "26" > /sys/class/gpio/unexport

Direction Sequenz

echo -n "39" > /sys/class/gpio/export
echo -n "out" > /sys/class/gpio/gpio39/direction
echo -n "$1" > /sys/class/gpio/gpio39/value
echo -n "39" > /sys/class/gpio/unexport

Das Einschalten kann dann z.B. einfach über die Eingabe

./engineB_setBrake.sh 0

durchgeführt werden.

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.

Um Crawlee #0 mobil zu machen, muss der EeePC sich zusammen mit dem RP6 bewegen. Dementsprechend fertige ich einen entsprechenden Aufbau an. Zunächst habe ich mir eine Gewindestange besorgt, die ich auf 4 Stangen gleicher Höhe abgelängt habe. Diese habe ich dann mit Muttern versehen und an die RP6 Platine angebracht.



Die Muttern, die hier sichtbar sind, habe ich als Auflage mit Sekundenkleber fixiert, und anschließend an der Platine festgeschraubt.



Als Laptoptisch soll eine dünne Spanplatte dienen, die ich in der Restekiste im Baumarkt gefunden habe. Ich habe diese mit Löchern versehen, und die USB-zu-Seriell Platine, die zusammen mit dem RP6 geliefert wurde, montiert.





Diesen Tisch habe ich lose (in der Tat ist das ganze Konstrukt nicht sehr lose, weil auf Grund meiner unpräzisen Arbeitsweise alles auf leichter Spannung gehalten wird…) aufgelegt, und durchgebohrte Schrauben und Gewindestangen mit dem Multitool gekürzt.





Damit der EeePC nicht auf die Dauer von diesem Tisch herunterwackelt, gab es noch eine einfache Halterungen aus ein paar Winkeln, die ich ebenfalls im Baumarkt erstanden habe.



Et voilà :-)

Firmware V1.0 - b9

Nachdem eine geeignete Entwicklungsumgebung aufgesetzt wurde, kann nun die eigentliche Firmware (FW) erstellt werden. Die FW selbst ist eigentlich ein Terminal, auf den über die serielle Schnittstelle zugegriffen werden kann. Auch wenn ich dadurch etwas Overhead produzieren werde, und ich einen einfachen Parser auf dem Atmega laufen lassen muss, glaube ich, dass die dadurch sehr guten Debug-Möglichkeiten es mehr als Wert sind. Prinzipiell kann der RP6-Rumpf über jedes Standartterminal programmiert und ausgelesen werden.

Für die eigentliche Kontrolle der Hardware greife ich in großem Maße auf die mitgelieferte RP6RobotBaseLib.h Bibliothek zu. Die Art und Weise, wie ein Bewegungsbefehl ausgeführt wird, habe ich aus dem LightFollowing Beispiel Nummer 7 übernommen.

Main Loop

Die Hauptschleife meines Roboters sieht wie folgt aus:

while(true)
	{
		//Check commands
		checkCommands();

		//Update ACS
		updateACS();

		//Execute move command
		moveCommand(&mv_cmd);

		//Perform system tasks and update data-fields
		task_RP6System();
	}

Zunächst kontrolliert der Roboter über checkCommands, ob ein Befehl (vollständig) gesendet wurde. Anschließend werden die mitgelieferten Systemfunktionen der Reihe nach aufgerufen. Die Funktionen updateACS und task_RP6System sind notwendig um alle Änderungen in Variablen in Hardware (HW) umzusetzen und Zustandsänderungen der HW in Variablen zu kopieren. Der moveCommand wertet einen etwaigen Bewegungsbefehl aus, und schaltet die Motoren.

Der Parser

Der Parser ist ein zentraler Bestandteil der FW, da er die Terminalfunktionalität bereitstellt.

checkCommands
Die Funktion liest alle Bytes in ein Bytearray und kontrolliert, ob der Befehl durch einen Zeilenumbruch ('\n') abgeschlossen wurde. Sollte das der Fall sein, wird der eigentliche Parser gestartet.

parseCommands
Der zentrale Parser ermittelt an Hand des ersten Buchstabens in einem switch-Konstrukt, welcher Befehl eingelesen werden soll. Kürzere Befehle, wie z.B. Move-Befehle, werden direkt in dieser Funktion vollständig geparst. Komplexere Befehle werden an spezialisierte Funktionen übergeben.

parseSpeedCommand, parseOffsetCommand, parseACSCommand, parseMoveTimedCommand
Spezialisierte Kommandos.

reportACSState, reportBatteryState, reportEngineState, reportLightState, reportBumperState
Diese Befehle senden die jeweiligen Sensorwerte über die serielle Schnittstelle zurück.

Der Terminal

Die Firmware ist ein einfacher Terminal. Nach dem Starten aus dem Bootloader wird zunächst eine Begrüßung gesendet. Eine Eingabeaufforderung wird durch das Senden des

>

Zeichens signalisiert. Die eigentlichen Befehle bestehen immer aus einem einzelnen Buchstaben und typischerweise einem Parameter.

Befehlsliste
w<dist> - Bewege den RP6 <dist>mm nach vorne
a<ang> - Drehe den RP6 <ang>° nach links
s<dist> - Bewege den RP6 <dist>mm zurück
d<ang> - Drehe den RP6 <ang>° nach rechts
q<speed> - Stelle den Speed für den nächsten Bewegungsbefehl ein auf <speed> zwischen 0 und 255
o<offset> - Stelle einen Offset zwischen den Ketten ein, für den c-Befehl
c<time> - Aktiviere beide Ketten für <time> ms mit Geschwindigkeit <speed> und <offset> -> Ein erneuter c Befehl resettet den Timer

e - Gibt die Motorströme zurück als 16-bit Wert
v - Gibt die Batteriespannung zurück als 16-bit Wert
b - Gibt den Bumperstatus zurück
l - Gibt die Helligkeitswerte zurück als 16-bit Wert
i<cmd> - Wird <cmd> weggelassen wird der Obstacle Sensor ausgegeben. Ansonsten kann die Helligkeit der IR-LEDs mit + und - erhöht werden oder über die Stufe 0 bis 3 auf eine entsprechende Helligkeit gesetzt werden.

Der RP6 kommt mit einigen Tools daher, die eine erste Inbetriebnahme äußerst komfortabel werden lassen. Um eigene Firmware zu programmieren benötigt man unter Windows zunächst einen geeigneten Compiler. Ich habe diesbezüglich WinAVR 20100110 installiert, das mit einem entsprechenden gcc Crosscompiler daherkommt. Als Programmierumgebung habe ich auf die grande dame Eclipse gesetzt. Ein entsprechendes Plug-In zur einfachen Integration kann man unter http://avr-eclipse.sourceforge.net/updatesite herunterladen.

Projekt Setup

Eine Beschreibung, wie ein AVR Projekt unter Eclipse mit Plugin einzurichten ist, gibt es ebenfalls in der offiziellen online Anleitung. Ich habe jedoch auf dem makefile, das dem RP6 Beispielcode beiliegt, aufgesetzt und ein makefile-Projekt erstellt. Das hat den Vorteil, dass die entsprechenden Abhängigkeiten bereits richtig in den Build-Flow integriert worden sind, und man sich darum nicht kümmern muss. Außerdem sind die Parameter für den Atmega32, wie er verbaut worden ist, bereits richtig eingestellt. Am Ende gilt es lediglich das Target anzupassen zu

TARGET = crawlee_fw

und alle notwendigen Files in Eclipse zu importieren. Mein Projektdirectory sieht schließlich wie folgt aus:


Der Build Vorgang

… lässt sich über einen Rechtsclick auf das Projekt starten, und läuft dann ziemlich problemlos durch :-)




File Upload

Jetzt kommt der erste Schritt, bei dem ich nicht mehr auf Eclipse setze. Grund dafür ist ganz einfach, dass das mitgelieferte Tool mit dem Bootloader auf sehr angenehme Art und Weise zusammenarbeitet, und noch einige Zusatzfeatures bietet, die avrdude (das WinAVR Tool zum Binary Upload) meines Wissens nicht besitzt.

Ich benutze den RobotLoader von Arexx in der Version 20120924 . Die ältere, auf der CD mitgelieferte Version, hatte mir unter Windows 8 und einer aktuellen Java Version einige Probleme bereitet. Ist der RP6 über Connect verbunden wurden, kann die kompilierte *.hex Datei über Upload! hochgeladen werden. Damit der auf dem Atmega32 installierte Bootloader die eigene FW startet, muss das System durch das Senden des Buchstaben 's' im Terminal oder den Start Button aktiviert werden.

Heute gibt es ein paar Fotos von meinem neuen RP6 im Urzustand.

Man findet den Roboter gut verpackt in der Modellbau- und Spielwarenabteilung in jeder gut sortierten Conrad Filiale.




Nachdem er aus seinem anti-statischen Schutzbeutel befreit wurde …



… habe ich erst einmal die Platine inspiziert.



Der RP6 ist an zentraler Stelle mit dem Atmega32 ausgestattet. Man erkennt aber auch im hinteren Bereich die Motortreiber Sektion und im vorderen Bereich die Infrarotsensoren und LEDs zur Statusanzeige. Ansonsten zeichnet sich die RP6 Platine vor allem durch zahlreiche Erweiterungsstecker aus.

Und hier ist nun mein neues Arbeitstier: Der Arexx RP6 V2!



Eine schöne detaillierte Erklärung der RP6 Hardware habe ich im Roboternetz gefunden: http://www.rn-wissen.de/index.php/RP6

Crawlee soll so weit wie möglich auf ROS aufbauen. ROS ist eine Sammlung von Linux-Paketen, die als Zwischenschicht einige Services für Roboter anbietet. In der ROS-Welt gibt es eine beliebige Anzahl an Nodes (Achtung: Ab hier werde ich mich bestem Denglisch bedienen - ja, noch (viel) mehr als vorher…), die die eigentliche Arbeit erledigen. Diese können sich miteinander über so genannte Topics und Services unterhalten.

Dabei sind Topics eine Art Broadcasting-System. Ein Node kann Daten zu einem Topic publishen und alle Nodes, die sich für dieses Topic interessieren, können dieses Topic subscriben und erhalten von da an die Daten übermittelt. Services hingegen sind eine Art Remote-Procedure-Call-Verfahren (RPC) und ermöglichen es Befehle an Nodes zu übermitteln.
Intern gibt es sicher Unterschiede in der Implementierung, mit etwas Abstand verschwimmen die Einsatzgebiete für Topics und Services aber an vielen Stellen. Als Beispiel könnte man einen Node, der die Bewegung kontrolliert, nennen. Ist ein Bewegungsbefehl ein Topic oder doch ein Service des Nodes?
Ich werde zunächst einmal versuchen Services nur zur Kontrolle/Konfiguration der Nodes zu benutzen. Sprich um den Zustand/State des Nodes zu verändern. Für die Datenübermittelung (und Bewegungsbefehle sind imho keine State-Änderung) werde ich daher auf Topics zurückgreifen.

Natürlich kann man sich fragen, ob es nicht bereits ausreichend verschiedene Datentransfer und RPC-Mechanismen in Linux selbst gibt, und es eines ROS Aufsatzes wirklich bedarf… In meinen Augen gibt es auch da keine klare Antwort zu, aber der ROS Ansatz hat eine viel wichtigere Funktion, als das reine Angebot von Low-Level Services:

Standardisierung!

Der wirklich große Vorteil ist am Ende, dass man streng eingekapselte Module für ROS-Roboter bauen kann. Publizieren oder subscriben sie zu den richtigen Topics, kann man sie mit bestehenden Nodes zusammenarbeiten lassen, ohne irgendwelche zusätzlichen Interfaces zu programmieren, oder in den Code der bestehenden Nodes einzugreifen.

Um ROS nun auf meinen selbstgebauten Roboter anwenden zu können, benötige ich zunächst eine neue Zwischenschicht, zwischen der PR6 Hardware und dem Linux Betriebssystem. Das führt zu der folgenden Architektur.



Dabei werde ich in einem ersten Schritt zwei neue Softwares programmieren, die ich als Firmware (Software, die auf dem Atmega32 läuft und dabei unter keinem Betriebssystem) und Driver (ein Linux Programm, dass die FW Funktionen unter Linux/ROS zur Verfügung stellt) bezeichne. Der Driver wird dabei kein echter "Linux Treiber" werden, sondern ein reguläres Linux Programm im User-Space. Da ich auf keine HW Funktionen des EeePC zugreifen möchte, sondern lediglich über mein USB-2-UART kommunizieren mag, ist das ausreichend. Dazu aber ein anderes Mal mehr.

Nachdem ich in dem letzten Eintrag grob die Anwendungsfälle und Anforderungen, die sich daraus ableiten, umrissen habe, möchte ich heute das Grundkonzept meiner Prototyping-Plattform skizzieren.

Für den ersten Prototypen möchte ich möglichst wenig Geld investieren und gleichzeitig möglichst wenig Zeit. Dementsprechend werde ich auf so viele vorhandene oder einfach zu besorgende Komponenten wie möglich zurückgreifen.

Die Hardware

Die Hardware von Crawlee #0 wird aus 2 Teilsystemen bestehen. Als mobile Grundplattform werde ich den bei Conrad erhältlichen Roboter RP6 V2 verwenden. Dabei handelt es sich um einen kleinen Roboter mit fest gelagertem Kettenantrieb, einigen einfachen Sensoren und einem Atmega32 Mikrocontroller. Der PR6 enthält damit schon einmal fast alle Grundkomponenten, die ich für Crawlee #0 benötige. Um dem Atmega32 einen leistungsstarken Zentralcomputer zur Seite zu stellen, habe ich einen alten Asus EeePC R101D ausgewählt. Da nicht besonders viele Daten zwischen RP6 und EeePC übertragen werden müssen, werde ich als Schnittstelle ein einfaches UART verwenden.



Dadurch, dass der RP6 bereits eine einfache FW enthält, die die Sensoren und Motoren kontrollieren und auslesen kann, ist an dieser Stelle nicht viel zu tun.
Der EeePC auf der anderen Seite ergänzt den RP6 mit einer Kamera, einer Festplatte, WiFi und natürlich einem vergleichsweise zu Höchstleistungen fähigen Prozessor. Ich habe bereits vor einiger Zeit eine Ubuntu Linux Version installiert, so dass ich auch diese Systemkomponenten ohne großen Aufwand verwenden kann.

Um das Gesamtsystem zusammenzusetzen, muss folglich nur noch die UART-2-USB Schnittstelle programmiert werden und danach kann ich mich auf die Software Seite Crawlees konzentrieren.

Auf Grund der vier Nutzungsszenarien, sollen einige technische Anforderungen abgeleitet werden.

R1 Rad- oder Kettenantrieb
Für alle Nutzungsszenarien, muss sich Crawlee bewegen können. Einzig ein Rad- oder Kettenantrieb kann vermutlich UC1 und UC5 erfüllen.

R2 Akku
Um sich frei bewegen zu können wird eine wiederaufladbare Energiequelle benötigt.

R3 Transportfläche
Es muss eine Ablagefläche existieren, um Objekte zu transportieren.

R4 Auflagesensor
Irgendeine Form von Schalter oder Sensor wird benötigt um feststellen zu können, ob ein Objekt aufgelegt wurde oder nicht.

R5 Kamera
Eine Kamera ist ein zentraler Bestandteil

R6 Ladestation-Andockmechanik
In irgendeiner Form muss Crawlee an die Ladestation andocken können.

R6.2 Energiemonitor
Crawlee sollte seinen Ladezustand abschätzen.

R7 Zentralcomputer
Um die Berechnungen durchführen zu können ist ein (vergleichsweise) schneller Rechner nötig. Vermutlich mindestens Atom-Kategorie mit einem vollwertigen (Linux-)Betriebssystem

R7 WiFi Modul
Crawlee muss an das Netzwerkangebunden sein.

R8 Navigationsmodul
Um sich in der Wohnung quasi frei bewegen zu können muss Crawlee navigieren können.

R9 Ortsbestimmungsmodul
Um navigieren zu können muss Crawlee seinen Ort abschätzen zu können.

R10 Lautsprecher
Crawlee soll so in der Lage sein Botschaften zu überbringen

R11 Fernsteuerung
Alle Funktionen sollen über das Internet fernsteuerbar sein und alle Informationen abrufbar.

R12 Low-cost

Der Gesamtpreis des Materials soll sich unter 100€ bewegen.

Auch wenn ein Projekt wie dieses am Ende sicher am Ende stark durch die vorhandenen Ressourcen begrenzt wird, ist es immer eine gute Idee sich klar zu machen, was das fertige Produkt am Ende können soll. Da ein Blog einen Tagebuchcharakter hat, ist es umso spannender zu vergleichen, was man am Anfang erreichen wollte und was am Ende dabei herausgekommen ist.

Ich beginne mit einigen Nutzungsszenarien und werde davon dann technische Anforderungen ableiten, die ich schließlich versuchen werde auf die vorhandene Hardware zu mappen.

UC1 Crawlee - Der Transporter
Crawlee soll in der Lage sein Objekte von einem Ort zu einem anderen zu transportieren. Er soll dabei bemerken, wann das Objekt aufgestellt/-gelegt und am Ende des Transports wieder abgenommen wurde. Dazu muss er sich frei in der Wohnung bewegen können.

UC2 Crawlee - Der Wachhund
Crawlee soll in der Lage sein die Wohnung rudimentär zu überwachen und das Bild auf Abruf über das Netzwerk an einen Nutzer zu senden. Er soll dabei in der Lage sein unerwartete Ereignisse zu melden.

UC3 Crawlee - Der Selbstversorger
Crawlee soll sich selbständig zu einer Ladestation begeben können und sich dort aufladen.

UC4 Crawlee - Mr. Telepräsenz
Crawlee soll über das Internet fernsteuerbar sein und in der Lage sein Botschaften zu überbringen.

UC5 Crawlee - Everybodys Darling
Crawlee soll prinzipiell für jeden erschwinglich sein.

Es gab eine Zeit in der ich große Teile meiner Freizeit mit dem Computer verbracht habe. Damals habe ich meine Liebe zur Technik entwickelt, die schließlich in einem Ingenieurs-Studium gipfelte.
Während meiner ersten Berufsjahre litt das Hobby etwas unter dem Zeitmangel. Durch das Aufkommen der so genannten Maker-Szene, gibt es inzwischen jedoch ungeahnte Möglichkeiten, mit vertretbarem Aufwand komplexe Systeme aufzubauen.

Und so ward schließlich ein neues Projekt geboren. Die Crawlee-Roboter Plattform.



Der Begriff der Plattform ist in der Industrie allgegenwärtig. Persönlich habe ich das erste Mal in einem Artikel über die Automobileindustrie von "Pattformen" gehört. Inzwischen ist die Plattform Idee aber mit Sicherheit in jedem Technologiezweig ein fester Begriff.

Auch in der Hobbykultur ist die Plattform inzwischen eine feste Größe. Arduino Boards oder der Raspberry Pi sind inzwischen quasi Standard. Während in der Industrie die Plattform vor allem hilft die Kosten für Hochtechnologie zu reduzieren, ist in der Open-Source Kultur in meinen Augen vor allem die Standardisierungsfunktion entscheidend, die es ermöglicht mit minimalem Aufwand laufende, vollständig dokumentierte Systeme aufzusetzen. Man muss nur noch die letzten 5% selbst entwickeln, und kann die eigene Entwicklung wieder an die Community zurückgeben.

Obwohl ich mich erst seit kurzem (wieder) mit Robotik beschäftige, bin ich mir darüber im Klaren, dass es auch heute schon Roboter-Plattformen gibt, auf denen ich aufbauen könnte zum Teil aber auch werde.
Die meiner Kurzrecherche nach prominentesten Plattformen für den kleinen Geldbeutel sind dabei sicher der Nao und der Turtle-Bot, die eher im universitären Umfeld angesiedelt sind. Obwohl sie für Roboter sehr günstig sind, kosten sie immer noch 4-stellige Euro Beträge.

Wer noch günstiger in die Robotik einsteigen möchte, muss im spielzeugnahen Bereich wildern. Die Lego Mindstorms Serie oder aber die Conrad Asuro und RP6-Plattformen sind Vertreter in diesem Segment. Auch wenn es sich bei diesen um "echte" Roboter handelt, gibt es bei diesen Produkten schnell große Einschränkungen. Die Rechenleistung ist sehr begrenzt, dafür muss/kann man sich sehr hardwarenah in alle Details einarbeiten. Möchte man Roboter bauen, die mehr können, als einer Linie oder einem Lichtpunkt zu folgen genügt die Leistungsfähigkeit meist nicht.

Beide Segmente waren in meinen Augen nicht geeignet. Entweder konnte ich 1000€+ ausgeben oder mich mit Trivialanwendungen begnügen. Daraus ist schließlich die Idee geboren eine eigene Plattformen aufzubauen.
Ich plane dabei zwei Entwicklungsschritte. In einem ersten Schritt baue ich den Crawlee #0 Prototypen auf bestehende Plattformen auf und entwickle das Software Grundgerüst.

In einem zweiten Entwicklungsschritt möchte ich eine eigene Hardware entwickeln, die zu der entwickelten Software weitestgehend kompatibel ist, so dass ich die Crawlee #0 auf den Crawlee #1 übertragen kann.

Ziel soll es am Ende sein eine offene Plattform aufzubauen, deren einzelne Komponenten in Summe nicht mehr als 100€ kosten.