Das Mojo-Board mit einem Xilinx-FGPA Spartan 6 ist nicht nur ein preiswertes und ausgezeichnet gemachtes Stück Hardware sondern eignet sich auch hervorragend als Ergänzung für ein mobiles DGPS-System. Es verbraucht extrem wenig Strom und hat ausreichend Rechenpower, um ein eventuell nötiges Preprocessing der GNSS-Daten durchzuführen. Beispielsweise kann ein FPGA für einen Kalmen-Filter (pdf) – oder ein Complementary Filter – verwendet werden. Neben einem GPS-Receiver lässt sich gleichzeitig an den Analog-Ports auch ein Accelerometer anschliessen.
Allerdings ist der Weg zu einem ersten Programm extrem steinig. Die Xilinx-Suite ist nicht unbedingt die beste Wahl für die Entwicklung der Module. Für die meisten Entwicklungen dürfte sich das sperrige und riesige Paket schlecht in den Workflow integrieren lassen.
Nach etlichen Stunden Recherche steht jetzt eine vernünftige Umgebung: Xilinx läuft unter Linux (in unserem Falle in einer VirtualBox) und das Flashen des Boards findet unter MacOSX auf einem anderen Rechner am Arbeitsplatz statt.
Notwendig dafür war eine Anleitung eines FPGA-Experten, wie man die Xilinx-Commandline-Tools verwendet (pdf). Darin ist neben den Tools selbst auch beschrieben, wie man die notwendigen Shell-Variablen setzen muss und wie man in einem Projekt an die jeweilige Syntax kommt. Es zeigt sich jedoch, dass man eine teils erheblich längere Build-Zeit einkalkulieren muss, oder die Scripte anpassen sollte, da sie immer alle Schritte komplett durchführen auch, wenn sich bestimmte Sachen nicht geändert haben.
Die Überspielung des Bitstreams kann statt mit dem vorgegebenen Mojo-Loader (src), der eine aktuelle JVM voraussetzt auch mit einem Python-Programm erfolgen. Im Mojo-Forum war der User mogorman so nett ein Script zu veröffentlichen, das dies sowohl unter Linux als auch unter MacOSX erledigt. Unter letzterem sollte man noch den Parameter -n hinzufügen, da sich das Script andernfalls mit der Meldung “Flash is not same size as local bitstream.” verabschiedet.
Das Mojo selbst wird von OSX als USB-Modem eingehängt und der serielle Port findet sich immer als /dev/tty.usbmodem*. Wobei der Stern eine dreistellige Ziffer ist. Wer schonmal mit einem Arduino unter OSX gearbeitet hat kennt das bereits. Leider ist nicht klar, wie man das System dazu bringt immer den gleichen Device-Namen zu verwenden. Für den Fall, dass man nur ein entsprechendes Gerät an seinem Rechner hat, kann man folgenden Befehl zum Flashen verwenden:
./mojo.py -v -n -d `ls /dev/tty.usb*` mojo_top.bin
Auf der Mojo-Seite findet sich unter anderem ein Beispielprogramm für die serielle Kommunikation über den AVR auf dem Board. Damit liessen sich die berechneten Daten eines GPS-Recievers und eines Accelerometers problemlos an einen Controller (z.B. RaspberryPi) weitergeben. Auf diesem könnte dann die RTKLIB laufen, die die Daten nicht noch selbst bereinigen müsste.
Wem Verilog als Synthesesprache nicht liegt, der kann das Mojo auch mit VHDL benutzen. Ebenfalls im Forum findet sich ein schöner Beispiel-Code von User Xark, das auch gleich noch verdeutlicht, wie die Analogports benutzt werden können.
Ein Beispiel, wie ein FPGA (hier ein etwas älteres Basys 2 von Diligent für ~€50) mit einem GPS-Receiver zusammenspielen kann hat grade All Programmable Planet beschrieben. In nächster Zeit sollen noch weitere Artikel und Beschreibungen zu dem Projekt kommen.
Hallo,
Zuerst: das Projekt finde ich sehr gut und würde mich gerne beteiligen.
Zu dem FPGA: Ich verstehe nicht ganz, wie das Mojo (kenne ich noch nicht) gleichzeitig die Daten eines Bewegungssensors und die von einem GPS verarbeiten soll. So wie ich das bisher verstanden habe, kann auf einen solchen Chip immer nur eine Software geladen werden. Die Daten müssten aber doch unterschiedlich behandelt werden. Der Vorteil des geringen Stromverbrauchs scheint mir dann jedoch hinfällig zu sein, wenn der Controller permanent (alle x ms) den FPGA-Code austauschen muss.
@Reinhard: Es ist richtig, dass auf einem FPGA immer nur ein Programm läuft. Es sei denn man implementiert einen Prozessor, der selbst mehrere Prozesse laufen lassen kann. Allerdings ist ein FPGA so gestaltet, dass man eigentlich einen Parallelprozessor hat. Damit kann man verschiedene Bereiche mit unterschiedlichen Logiken konfigurieren. D.h. die Inputs von verschiedenen digitalen oder analogen Ports können unterschiedlich behandelt werden. Und diese Berechnungen können dann gemeinsam an einen gemeinsamen Output-Port gegeben werden.
Neben den RAW-Data eines GPS-Receivers und eine Accelerometers liessen sich so auch noch die Daten eines Magnetfeld-Sensors verwenden. Die können ja auch von der RTKLIB verwendet werden. Das Setup mit einem RaspberryPi entspricht eigentlich diesem Projekt: http://sourceforge.net/projects/gpsfpgadsp/
Mit welcher Leistungsaufnahme auf einem Copter müsste man denn rechnen, wenn man das Scenario umsetzen wöllte?Und was wiegt das setup?
@rvb
das raspi dürfte für einen copter zu stromhungrig sein. insbesondere wenn man sowieso schon einen prozessor drauf hat wäre das eigentlich doppelt gemoppelt. auf der ardrone ist ja schon ein cortex a8 mit 1ghz und damit wesentlich besser als das raspi. die idee mit dem zusätzlichen gps ist interessant aber eigentlich nicht wirklich geeignet. die drone hat schon einen gyro und einen beschleunigungssektor. allerdings kommt man da zwar an die rohdaten aber nicht, ohne sie durch den prozessor zu routen. damit wäre der vorteil eines fgpa hinfällig.
insofern wäre das nur was für ein selbstbauprojekt. und auch dann würde ich keinen raspi empfehlen. das design ist einfach zu schlecht und deswegen ist der stromverbrauch auch unter den meisten systemen so schlecht.
@tooben: Was haben Sie denn gegen das RaspberryPi? Ich halte es für eines der interessantesten Projekte im Bereich Micros seit vielen Jahren/Jahrzehnten. Und sicher ist es nicht für ALLE Projekte geeignet. Aber welches System ist das denn schon?
Eigentlich müsste ein Teil der RTKLib in einem FPGA realisierbar sein. Insbesondere die Loop-Functions (z.b. in lambda.c) und die ganzen Formatumwandlungen (z.b. in rtcm.c) bieten sich an. Nur die Meta-Funktionen (z.b. solution.c) und die Postprocessingaufrufe sind nicht geeignet (z.b. postpos.c) müssten auf einem “normalen” System laufen. Man bräuchte also eine art APi oder BAPI zwischen dem FPGA und einem Controller.
Aber genau die rechenintensiven Aufgaben könnte man dem FGPA geben. Der Rest müsste eigentlich schon ein Arduino mit 20MHz können. (Abgesehen davon, dass einige Standard-C Aufrufe möglicherweise dort nicht verfügbar sind.) Aber es wäre auf jeden Fall ein relativ preiswertes Design. Ein Spartan 6 kostet je nach Ausführung offensichtlich unter $5 und ein 32bit Amtel bekommt man für unter $1.
K.
Das klingt so als hättest Du bereits mit der RTKLIB gearbeitet. Wir suche nämlich noch Verstärkung
Ergänzung: Eine gute Einführung in die Programmierung von FPGAs mit Matlab findet sich hier: http://blogs.mathworks.com/loren/2013/04/11/matlab-to-fpga-using-hdl-codertm/ Das dürfte vielen Micro-Entwicklern besser gefallen als die Verilog-Beispiele.