Nach der Ankündigung Googles, dass es in Android N Zugriff auf die GNSS-Rohdaten geben würde beschäftigen sich inzwischen einige Entwickler mit dem Thema. Eine Ausführliche Analyse der verfügbaren Daten hat unter anderem Rokubun (ein ESA funded StartUp) durchgeführt. Unter dem Titel “First look at Android N GNSS raw measurements” werden verschiedene Funktionen beschrieben und auf die verfügbaren Formate eingegangen.
(Danke an OpenDEM für den Tipp!)
Ein Kommentar zu “Android N mit Zugriff auf Raw GPS Data?” verwies auf ein uns bisher unbekanntes Projekt zur Höhenvermessung der Welt mit Hilfe der Crowd. OpenDEM startete bereits 2011 und möchte mit verschiedenen Methoden eine offene Quelle für Höhen- und Tiefenangaben aufbauen.
Neben App und Mapeditor bietet das Projekt Links zu frei verfügbaren Daten und interessante Informationen aus dem Bereich.
In den nächsten Wochen soll es einen ersten Test für die grundlegenden Funktionen von OpenDGPS geben. Eine mobile Station soll mit Hilfe eines RTL-Dongles die Korrekturdaten für die eigene Position ermitteln und diese via Ntrip (Server, Caster & Client sind hier verfügbar) an eine entfernte Station senden, die die Differential-Daten verwendet um die eigene Positionsgenauigkeit zu verbessern. Ein Vergleichs-Receiver an dieser Station dient dazu, die Verbesserung bei verschiedenen Situationen (delay, Wetter) zu vergleichen.
Testsetup mit einer Basisstation und einem “Rover”
Die Distanz beider Stationen beträgt 3,63km und beide sind an einer dauerhaften DSL-Verbindung am Netz.
Setup Basis:
Die Basisstation besteht aus einem parallella mit einem Dual Core ARM A9 auf Basis eines Zynq7020 und einem 16 Core Epiphany SMP. Sowohl die Programming Logic als auch der Multicore-Prozessor kommen im ersten Schritt nicht zum Einsatz. Später soll möglicherweise der FPGA des Zynqs einige Operationen des RTL-SDR-Parts (z.B. via GPS Demystified) oder/und RTKLIB übernehmen.
Als Receiver für die GPS Daten kommt ein einfacher 10€ DAB+ Dongle mit RTL-Chip zum Einsatz. Auf dem SDR-GPS-Blog von Peter Hahn findet sich eine Anleitung, wie man mit Hilfe von GNURadio an die GNSS-Daten gelangt.
Die Korrekturdaten sollen mit Hilfe des NTRIP-Protokolls (über einen Proxy) veröffentlicht werden. Die interessante Frage ist erstens, wie zeitnah ein 1GHz Dual Core ARM die Daten mit Hilfe der RTKLIB berechnen kann und zweitens, wie zeitnah die Daten tatsächlich für welche Genauigkeit beim Rover sein müssen. Es ist klar, dass je aktueller die Differential-Daten tatsächlich sind, desto genauer wird die Korrektur sein. Möglicherweise genügt jedoch eine Update-Frequenz von Minuten um eine signifikante Steigerung der Genauigkeit zu erlangen. Zumal in dem Testsetup vorerst nur eine feste Station die Daten liefert.
Für den Test ist nicht vorgesehen, die Basisstation aufwendig zu eichen. Es soll lediglich eine mehrere Stunden dauernde Korrektur vorgenommen werden um eine annähernde Genauigkeit zu erreichen. Da die Station nicht bewegt wird dürfte sich die Ungenauigkeit an dieser Stelle nicht auf die Qualität der Korrekturdaten auswirken.
Setup “Rover”:
Der Rover ist in unserem Test keine bewegliche Einheit sondern ein stationäres System. Es soll zunächst nur dazu dienen, den Gewinn an Genauigkeit zu definieren. Es wird ein UDOO Quad Core verwendet. Das UDOO verfügt neben einem normalen ARM-System auch über eine Arduino-Einheit die uns die benötigten I/Os bietet. Als GPS-Receiver kommen zwei NaviLock NL 507E TTL zum Einsatz. Der darin verbaute u-blox kann mit NTRIP-Daten umgehen und sie zur Korrektur verwenden.
Dabei soll der nur einer der beiden Receiver die Korrekturdaten erhalten. Der andere Empfänger verwendet nur die onboard Positionierung. Dadurch können die beiden Daten verglichen werden und hoffentlich die Unterschiede in der Genauigkeit sichtbar werden.
Auf dem Rover-System läuft keine RTKLIB, die NMEA-Daten werden lediglich über TTL zur späteren Analyse gespeichert.
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.
Bei einem spontanen Gespräch mit einem Messionar am Strassenrand mitten in Berlin ging es heute schnell um die Frage, ob die Landesvermessungsämter die Koordinaten der Vermessungspunkte zur Verfügung stellen. In einer idealen Welt würden
verfügbar sein. Ganz offensichtlich leben wir ja nicht in einer idealen Welt und daher ist es nicht verwunderlich, dass einige dieser Wünsche als illusorisch darstellen.
Piksi Modul (Quelle: swift-nav.com)
Bei Kickstarter ist vor wenigen Tagen ein Crowdfunding Projekt gestartet, dass sich ideal für OpenDGPS eignen würde. Wenn es nicht viel zu teuer wäre. Mit $900 für zwei Piksi-Module verlangen die Macher fast das zehnfache der Materialkosten. Der Preis scheint aber gerechtfertigt, da schon jetzt die angestrebte Summe von $14.000 weit überschritten ist.
Ein Piksi-Modul besteht aus Antenne, einem Analog-Digital-Wandler, einem Startan-6 (jenem FPGA-Chip auf dem Mojo) und einem ARM Cortex-M4 (STM32F4, über diese günstige CPU hatten wir uns letzte Woche einen Vortrag auf der Makers Faire in Hannover angehört). D.h. Piksi verfügt selbst nicht über einen eigenständigen GNSS-Receiver und stellt damit eine neue Kategorie dar, die man in Zukunft häufiger antreffen dürfte. Zumal das Design mit einem Stromverbrauch von 500mA sehr sparsam ist.
Die Macher von Swift Navigation aus Kalifornien versprechen eine Genauigkeit von bis hinunter zu 1cm. Dabei muss man aber berücksichtigen, dass dazu das Differenzsignal von einer geeichten Feststation kommen muss. Andernfalls gilt diese Genauigkeit nur in Bezug zur Referenzstation. Insofern dürfte es bei einigen Käufern ein böses Erwachen geben. Denn immerhin sind DGPS-Signale noch nicht frei verfügbar.
Interessant ist das Projekt auch, weil sowohl Hardware als auch Software Open Source ist. Damit ist es auch anderen möglich, das Modul nachzubauen und dann bei wesentlich geringeren Kosten zu landen.
[Update] Mit Sicherheit wäre ein Zynq 7010 oder 7020 für das Projekt wesentlich besser geeignet als die Kombination aus Spartan-6 und Cortex-M4. Denn erstens ist darin ein wesentlich leistungsfähigerer ARM-Prozessor drin und zweitens hat der FPGA-Teil bis zu 10 mal mehr Logicelemente. Bei einer Abnahme von x000 Stück kostet eine solche CPU lediglich $15. [Update]
In der Größe zwischen Raspberry Pi und typischen Arduinos und mit ähnlich vielen In und Outs.
Unter dem Namen Mojo läuft grade bei kickstarter eine Sammelaktion für ein FPGA-Board mit einem Xilinx Startan-6 Prozessor. Für $65 bekommt man ein sehr gut mit Ein-/Ausgängen (analog und digital) ausgestattetes Board.
Wirklich interessant wäre es, wenn sich jemand finden würde, der eine RTKLIB-Implementierung für FPGAs anfasst. Zusammen mit einem Software-Defined-Radio könnte man damit dann einen DGPS-Receiver bauen, der in Echtzeit sehr hohe Genauigkeiten liefern würde. Insbesondere da die RTKLIB Daten von Bewegungssensoren einberechnen kann.
Laut einem Artikel der deutschen Technology Review (heise Verlag, Hannover) arbeitet Microsoft an einer Art Remote-RTKLIB-Berechnung um den Stromhunger von GPS-Modulen zu reduzieren. Das mobile Modul soll nur die Rohdaten der Satelliten an einen Server in der Cluod sendet. Dort wird dann die eigentliche Positionsberechnung durchgeführt.
Laut Microsoft könnten so funktionierende GMP-Module mit extrem wenig Strom auskommen. Es bleibt allerdings fraglich, wie der einzusparende Strom nicht komplett durch die dadurch notwendige Online-Verbindung aufgefressen wird. Prinzipiell wäre so auch eine OpenDGPS-ähnliche Lösung zur Verbesserung der Positiondaten möglich. Davon schreiben die Autoren des originalen Papers merkwürdigerweise nichts.
Seit kurzem ist das OpenDGPS Wiki online offline. Dort finden sich in Zukunft alle Informationen zum aktuellen Projektstand, der verwendeten Hard- und Software. Alle Interessierten sind willkommen, mitzudokumentieren und -redigieren. Gerne kann es ausführlicher werden und selbst abwegige Themen können behandelt werden.
Leider ist Mediawiki in der Standardinstallation ein riesiges Einfallstor für alle möglichen Angriffsformen. Da wir aber unsere Zeit derzeit nicht in die Pflege und das patchen von Serversoftware stecken können (und wollen) bleibt das Wiki vorerst offline.
Vielen Dank für die Hinweise!
3Sat sendet am 20.1. eine Dokumentation über Galileo und ist so freundlich, diese bereits jetzt online zu zeigen. Es wird die Struktur und die Funktionsweise erklärt und zeigt ein wenig Hintergrund. Die 28 min. sind auch dann interessant, wenn man nichts Neues lernt.