Hallo,
ein Freund von mir und ich wollen uns ein Modellauto bauen/umbauen, welches dann "selbständig" fahren kann.
Als Fahrgestell wollen wir einfach ein altes Modellauto nehmen, den Rest aber selber bauen.
Die ganze Steuerung haben wir bis jetzt 2 unterschiedliche Sachen geplant:
1.)
www.tinkerforge.com
Mit verschiedenen Bricks und Bricklets hiervon das ganze Umsetzen
2.)
http://www.raspberrypi.org/
http://elinux.org/Rpi_Low-level_peripherals
http://www.element14.com/community/d...el-peripherals
Mit dem Raspberry Pi über die Outputs(GPIO, I2C, SPI,UART) versuchen den Motor anzusprechen, und die Sensoren abzufragen.
Wobei wir da für die Motorsteuerung H-Brücken benötigen, oder? Kann man die über die Outputs vom Raspberry Pi überhaupt gut genug ansteuern?
Die Frage ist jetzt, welches von beiden Systemen wird besser funktionieren, und einem am Ende auch das Gefühl vermitteln etwas geschafft zu haben?
Was könnt ihr uns für Bauteile für diese Zwecke empfehlen?
Vielen Dank für eure Hilfe
Geändert von haering (15.04.2012 um 23:21 Uhr)
Hallo,
schnelle Frage: Habt ihr beiden Erfahrung im Kernelmodule bauen und in Echtzeitsystemen?
Mit dem Raspberry Pi seid ihr sehr viel flexibler was die Anbindung an die Aussenwelt angeht: WLAN, Bluetooth, etc. Rechenpower habt ihr auch eine ganze Menge mehr. Aber es erfordert auch ein wenig Engangement, das ganze zum funtkionieren zu bringen. Wenn ihr keine Ahnung von Linux habt, dann wird das wohl länger als ein halbes Jahr dauern
Ja, also dumm von mir nicht zu sagen was wir so können: Zuerst mal, wir studieren beide Informatik, jetzt im zweiten Semester.
Mit kernelmodule bauen und mit echtzeitsystemen haben wir noch keine Bekanntschaft gemacht. Zu Linux, haben erfahrung mit gui (ohh^^) aber auch bissel mit Konsole (haben zb auch nen non-gui ubuntu server unter unser kontrolle) . Ansonsten wollen wir eben nur das nötigste (also was man so braucht um die versch. Geräte anzusteueren) in C oder was hier in frage kommt zu schreiben. Über die GPIO's kann man ja zb ne H-Brücke ansteuern und damit nen Motor, oder ein PWM Signal für nen Servo oder eine externe Motorsteuerung, erzeugen (ich weiß nich ob des wirklich geht, aber eig. kann man ja mit allem was sich flott ein und aus schalten lässt so was machen!?). Nur bei den Sensoren hätte ich spontan überhaupt keine Ahnung wie man da ran geht, muss man da dann das I2C oder spi protokoll implementieren um da dann Messwerte auslesen zu können?
Die Hauptlogik soll dann in Java geschrieben werden (hier haben wir auch wirklich viel erfahrung und können eig auch alles umsetzen was wir uns in den kopf setzen
Okay, dann legen wir mal los:
Ihr habt nun die Wahl zwischen einem nativ programmierten µC und einem eingebetteten Linux System. Beides hat vor und Nachteile. Der größte Nachteil eines Linux Systems ist das fehlen jeglicher Hart-Echtzeitfähigkeit bedingt durch das OS. Ich nehme mal an, dass ihr wisst, wie ein Os parallele Prozesse ablaufen lässt: Es nutzt Prozessmultiplexing. Das bedeutet, es lässt einen Prozess laufen und nach einer bestimmten Zeit, legt es ihn still und geht über zum nächsten, und so weiter und so fort. In einem Echtzeitsystem ist allerdings eine sofortige Ausgabe vonnöten. Wie "echtzeitfähig" so ein System denn nun wirklich ist, müsst ihr für euch definieren und auch, ob ihr so etwas braucht.Wenn euch ein paar ms Verzögerung nichts ausmachen, dann braucht ihr auch nicht wirklich ein Echtzeitsystem. Aber wenn der Roboter relativ schnell fährt, wäre es vielleicht vonnöten, sofort Aktionen zu triggern.
Ihr wollt einen autonomen Roboter bauen und fragt euch nun, was ihr nutzen wollt: Ein modulares System oder einen kleinen Rechner. Mit dem modularen System seid ihr sehr sehr nahe an der Hardware, was euch als Informatikern vermutlich gar nicht gefällt. Natürlich bieten diese Bricks auch Java oder Python als Programmiersprache an, doch da drängt sich mir die Frage auf wie leistungsfähig ein solcher SAM Prozessor mir einer JRE ist. Meine Vermuntung: Entweder ist er schnell oder er hat eine vollständige JRE. Echtzeitfähigkeit kann man da auch vergessen.
Auf dem RBpi läuft auch ein kleines OS, was euch ebenfalls eine glatte Oberfläche bietet, um eine JRE darauf zu setzen. Hier müsstet ihr wohl noch ein bis zwei Kernelmodule kompillieren und einbinden. Das wird ein wenig frickelig, aber im Endeffekt ist das kein großer Act. Was ihr zum RBpi noch braucht ist eine eigene Elektronik, die an die entsprechenden Schnittstellen angeschlossen wird. Hier könnt ihr euch an die Community wenden. Wenn's denn halbwegs echtzeitfähig sein soll, müsst ihr auch den Kernel, etc selbst mit RTOS Einstellungen und Modulen bauen, eben wie ein Linux From Scratch.
Da ich persönlich nichts von Java halte, möchte ich noch einen kleinen Hinweis geben: Java ist eine Hochsprache, die sehr viel höher angesetzt ist als C oder C++. Die JRE ist wie die Meeresoberfläche: Sie versteckt die Felsen, bietet euch eine glatte Basis zum programmieren an. Der Preis dafür ist ihre Geschwindigkeit. Informatiker machen heutzutage alles in Java (was ich sehr schade finde), weil es dort nur um die Algorithmen und Datenstrukturen geht, die man mit Java sehr gut implementieren und testen kann. Läuft vor allem auf jedem System, denn Java ist plattformunabhängig. Doch in der Robotik durch die Geschwindigkeit leider eher weniger zu gebrauchen. Generell ist bei einem Roboter, der eine JRE implementiert die Rechenleistung oberstes Gebot. Dennoch ist eine JRE immer ineffizienter als ein C Programm, dass das gleiche tut (bis auf wenige Ausnahmen natürlich). Daher würde ich euch persönlich dazu raten, Java von Robotern für Steuerungsaufgaben und Co fernzuhalten und lieber C zu nehmen. Das ist schneller, braucht weniger Ressourcen und in dem Fall wohl auch flexibler. Wenn es doch Java sein muss, dann würde ich definitiv den RBpi empfehlen. Für sehr schnelle Erfolge (aber imho weniger Lernerfolg, da ihr keine neuen Gewässer beschifft) könnt ihr die Bricks nehmen, doch lernen werdet ihr dabei eher weniger.
Die Anbindung der Sensoren und Aktoren erfolgt über SPI, I2C und was sonst noch alles an Bord des RaspberryPI rumliegt. Unter Linux werden die Devices dann als Blockdevices durch udev oder einem anderen Device Manager dann unter /dev abgelegt. Das bedeutet, ihr könnt mit C dann per fopen() fread() und fwrite() ohne Probleme drauf zugreifen. Vielleicht wäre auch eine Kombination Atmega/PIC <> RBpi vernünftig, denn der RBpi hat SPI I2C und alles was man sich an schnellen Schnittstellen so wünschen kann schon drauf und der AtMega/PIC kann dann als Multi-GPIO und Schnittstellenerweiterung dienen.
Vom Lerneffekt würde ich auf jeden Fall den RaspberryPI nehmen. Da könnt ihr euch in Linuxnutzung üben (müsst ihr später sowieso), mehr über µC und embedded Systems lernen, Treiberentwicklung/Nutzung lernen, lernen, mit der Konsole umzugehen, usw, etc.
PS: In C kann man auch mit sockets arbeiten. TCP UDP und viele weitere.
Du kannst auch Linux problemlos echtzeitfähig machen bsp. mit RTAI oder dem normalen "RT-Kernel". Das lässt sich auch auf ARM kompilieren. Und ja: Es ist echt "harte Echtzeit". Siehe [2]
Gruß
Georg
[1] http://www.rtai.org
[2] http://www.heise.de/open/meldung/OSA...h-1500094.html
Oha, dickes Danke! Das werde ich mir mal zu Gemüte führen. Kannte ich bis jetzt noch keinen Meter!
Erstmal großes Danke, wir haben uns jetzt entschlossen einen Raspberry Pi zu nehmen, und versuchen den Rest möglichst selber zu machen. Kann man den direkt von den GPIO Ports z.B. eine H-Brücke ansprechen?
Oder muss man dazu erstmal noch ein Board davorschalten? Die andere Frage ist, ob man noch einen zusätlichen µc nimmt, und in diesem dann manche Sachen auslagert. Gibts da dann schon passende µC die schon entsprechendes leisten (z.B. Servo steuern), oder muss man da alles selber programmieren? Da gäbe es passend für den Raspberry Pi zum Beispiel
das Gertboard http://www.raspberrypiblog.de/hardwa...board-rev2/346, wobei wir dabei natürlich weniger selber gemacht hätten.
Es gibt den SD 21 Controller für Servos (gibt aber auch kleinere Modelle).
Gewöhnt euch jetzt schon an, Datenblätter zu lesen!Kann man den direkt von den GPIO Ports z.B. eine H-Brücke ansprechen?
Die Frage die sich für mich vor allen stellt ist: Habt ihr den schon ein Raspberry Pi? Im Moment sieht es nämlich so aus: https://www.roboternetz.de/community...s-Raspberry-Pi Sprich so schnell ist nicht damit zu rechnen, wenn an heute erst bestellt. Gab wohl mehrere Jungs die auf die Idee gekommen sind das Ding zu verwenden.
Punkt Nummer 2: Informatiker und die Elektronik :-P. Ich würde euch auf jeden Fall eine Treiberstufe empfehlen, aber meistens sind Roboter von Informatikern beeindruckend programmiert, aber mit Heißkleber und Tape zusammen gebaut (so kenn ich es noch aus meinem Studium). Mechanik, Elektrik und Co spielen eine genauso große Rolle wie die Programmierung und da ihr euch in den niederen Gefilden der Hardware bewegt müsst ihr euch mit besagten Datenblättern und Motorkennzahlen herumschlagen.
Das klingt jetzt gewollt süffisant, ich bin nämlich Mechatroniker und daher sind meine Roboter ganz toll mechanisch und elektrisch umgesetzt. Nur die Programmierung ist dann eher stümperhaft :-P Das geb ich auch ganz offen zu.
Also wir haben den Raspberry Pi schon bestellt, aber wann er ankommt steht in den Sternen. Solang planen wir mal was wir noch für andere Hardwarekomponenten brauchen.
Berechtigungen
Zitieren
Lesezeichen