Kaltstart Position Fix mit FPGA-Lösung beschleunigen

masterarbeitDie Masterarbeit eines Studenten (Michael Sammartino) der Youngstown State University untersucht die Möglichkeit, die “receiver’s time to first fix from a cold start” zu minimieren. Mit Hilfe eines FPGA (Cyclone IV auf dem DE2 Board von Terasic) erreicht seine Lösung, die 4 mal schneller ist (1,7 sec.) als die Zeit, die ein Garmin Forerunner (8 sec.) braucht.

Obwohl er leider den Code nur in kleinen Auszügen veröffentlicht hat kann man davon ausgehen, dass die verwendete Hardware (FPGA-Board ~250€ plus custom ASIC RF board) eigentlich überdimensioniert ist. Effektiv müsste ein Spartan 6 und ein GPS-Modul, dass die Rohdaten liefert ausreichen.

 

Vermisste Einführung in die RTKLIB

Sieht man sich den Code der RTKLIB auf github an kann man zwei Dinge feststellen: ein ausgesprochen sauberer und effizienter Code und leider nur sehr spärliche Code-Documentation. Zwar gibt es auf der Homepage (rtklib.com) Handbücher. Diese beschreiben aber nur die GUI und Commandline-Benutzung. Der C-Code selbst ist weder selbst- noch fremderklärend.

Seit Anfang des Jahres gibt es jedoch das Blog-Projekt rtklibexplorer. Dort wird in vielen Posts sowohl die Lib selbst beschrieben als auch die Verwendung von verschiedenen Receivern dargestellt.

Ein Beispiel für das Trackprocessing aus dem rtklibexplorer. [Quelle: https://rtklibexplorer.wordpress.com/2016/05/25/new-data-moving-rover-fixed-base/]

FPGAs und SDR auf dem #30c3

Spannende Vorträge über vier Tage 30C3. Oft auch gleichzeitig.

Spannende Vorträge über vier Tage 30C3. Oft auch gleichzeitig.

Morgen startet der 30C3 mit einigen spannenden Talks. In diesem Jahr liegt der Focus der Veranstalter natürlich noch mehr als sonst auf der permanten Überwachung. Kritisch wird hier selbstverständlich auch die Funktion aller mobilen Geräte die Position permanent zu tracken. Am Samstag findet dazu um 12:45 der Talk “lecture: Glass Hacks” statt in dem Stephen Balaban über Google Glass spricht. Am gleichen Tag um 16:00 beschreibt Felix “tmbinc” Domke in “Script your car” wie man die Firmware seines Autos aufmacht und so auch an die GPS-Daten kommt oder diese modiziert. Einen Tag später um 11:30 berichtet Maria Xynou über die Überwachung in Indien.

Aus technischer Sicht sind mehrere Vorträge über FPGAs interessant: An Tag 2 gibt es um 12:45 einen Talk mit dem Titel “Extracting keys from FPGAs, OTP Tokens and Door Locks” von David Oswald von der Ruhr-Uni Bochum und um 17:15 dann “FPGA 101 – Making awesome stuff with FPGAs” von Karsten Becker (von den Parttimescientists). Am gleichen Tag zu späterer Stunde um 21:45 wird dann ebenfalls von Karsten Becker noch PSHDL vorgestellt, das den Anspruch erfüllen soll, die Programmierung von FPGAs so einfach zu machen, wie die des Arduino.

 

Handgestrickter GPS-Receiver in einem FPGA

Die Bereitschaft der GNSS-Receiver-Hersteller, die Rohdaten zur Verfügung zu stellen scheint sich in letzter Zeit nicht signifikant zu verbessern. Dies muss inzwischen aber niemanden mehr ärgern oder allzu tief in die Tasche greifen lassen. Inzwischen gibt es gute Referenzimplementierungen für selbst gemachte GNSS-Receiver. Den Anfang machte Andrew Holme mit einem Spartan-3-FPGA in Zusammenarbeit mit einem Raspberry Pi.

Die Besonderheit bei diesem Projekt ist die Programmierung des FPGA mit Forth. Sicher keine Allerweltssprache aber für den Zweck hervorragend geeignet. Der Sprachcore passt ohne Probleme in den inzwischen recht kleinen Spartan 3 mit unter 10k Logic Cells. Das Projekt ist ein hervorragender Ausgangspunkt für eigene Entwicklungen.

Basierend darauf hat John Seamons vor kurzem eine eigene Implementierung mit einem Spartan 6 und einem Beaglebone Black gemacht. Der FPGA wäre tatsächlich in der Lage, die Rohdaten aufzubereiten und der Prozessor auf dem Beaglebone hätte genug Power, die Differenzsignale zu berechnen. Die Kosten für eine solche Kombination sind allerdings derzeit noch mit knapp 150€ zu hoch. Spannender könnten dann Systeme sein, die über einen Zynq-Prozessor von Xilinx verfügen. Dieser hat zwei vollwertige ARM-Kerne und einen groß bemessenen FPGA gleich mit drin. Für $15 pro Zynq liessen sich wesentlich kostengünstigere und stromsparende GNSS-Reciever bauen.

 

Mojo – Command-Line statt umständlicher Xilinx ISE

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.

Open Source: GNSS Software Defined Receiver

Im Frühjahr starteten etliche Entwickler die Arbeit an einem Projekt, das zukünftig die GNSS-Branche durcheinander würfeln dürfte. Auf der Basis der RTKLIB hatte Michele Bavaro herkömmliche USB-Fernsehempfänger zu GPS-Receivern modifiziert. Bei bestimmten Geräten war es möglich, die Signale von GPS-Satelliten zu extrahieren und daraus die Position zu berechnen.

Auf der Basis seiner Grundlagenforschung hat sich ein Projekt gegründet, dass die dafür notwendige Software für verschiedene Plattformen und Receiver verfügbar machen möchte. Interessant daran sind die auf etlichen Sticks verbauten FPGAs. Das eigentliche Signalprozessing kann damit direkt auf den Receivern stattfinden.

 

Node.js und GPS

Node.js ist momentan das dynamischte Projekt im Programmiereruniversum. Da es jedoch von Grund auf neu entwickelt wurde gibt es selbstverständlich noch nicht so viele Bibiotheken wie etwa bei Python oder Perl. Allerdings gibt es seit kurzem eine GPS-Bibliothek. Sie liefert die Koordinaten wenn es Zugriff auf einen gpsd hat. Dadurch kann es sich sowohl um die Daten eines echten GPS-Receivers handeln oder aber um Daten die von anderen Diensteanbietern im Netz.

Zusammen mit dem interessanten Projekt Hardware Control Suite für node.js (das sich jedoch noch in einem sehr frühen Stadium befindet *hüstel*) hat man übrigens alles, was man braucht um einen Roboter zu steuern ;)