Aside

OpenDGPS ist eine freie Initiative von GNSS-Enthusiasten. Ziel ist der Aufbau eines Netzes von festen Stationen, die Differential-Signale zur Verfügung stellen und damit jedem Empfänger eine Ortung bis zu einer Genauigkeit im zweistelligen Zentimeterbereich ermöglichen. Mehr ->

RasPiGNSS und RTKLIB für Verbesserung der Genauigkeit auf einem Rover

Der Autor (“Roboter-Autos mit dem Raspberry Pi“) und Maker Ingmar Stapel beschreibt in einem ausführlichen Artikel den Aufbau eines Systems aus einer mobilen und einer festen Station zur Verbesserung der GNSS-Genauigkeit. Zum Einsatz kommen zwei RaspberryPi und zwei RasPiGNSS-Module (“Aldebaran” ~149€ von Dr. Franz Fasching) mit NV08C-CSM (hier schon mal beschrieben) von NVS Technologies AG.

Der Artikel beschreibt den theoretischen Hintergrund und den praktischen Aufbau. Im Unterschied zu OpenDGPS, wo die Differential Signale per NTRIP übertragen werden, benutzt Stapel die Daten der fixen Station um sie auf dem Rover mittels RTKLIB zu prozessieren und so die Genauigkeit der eigenen Position zu verbessern.

Bisher sind noch nicht alle Artikel erschienen. Es ist aber dennoch eine interessante Lektüre, wenn man sich mit dem Thema (insbesondere RTKLIB auf dem RasPi) beschäftigen will.

Der Anbieter des RasPiGNSS-Moduls hatte auf den Grazer Linux-Tagen 2016 einen interessanten Vortrag über “Präzise GNSS-Positionierung mit dem Raspberry Pi und RTKLIB”. Die Folien findet man hier.

Apache SIS: EPSG Koordinaten umrechnen (und mehr)

Eine der – für die meisten – weniger schönen Beschäftigungen im Umfeld von GPS/GNSS ist die Umwandlung von Koordinaten von einem “Coordinate Reference System” (CRS) in ein anderes. Im Allgemeinen sprechen die Receiver WGS84. Das genügt auch solange man die Daten nicht mit anderen Systemen austauschen oder abgleichen möchte.

Unter EPSG versteht man einen einheitlichen Standard von Coordinate Reference Systems. Derzeit sind knapp 6000 solcher Systeme gebräuchlich. Wahrscheinlich gibt es jedoch noch wesentlich mehr, die nicht veröffentlicht wurden. Entwickelt wurde das System im Rahmen einer Arbeitsgruppe der International Association of Oil & Gas Producers und firmiert unter dem Namen “European Petroleum Survey Group Geodesy“.

Unter der Katalognummer EPSG 4326 verbirgt sich zum Beispiel das genannte WGS84. Andere Systeme, wie Gauss-Krüger mit verschiedenen Anpassungen an die jeweiligen Breiten und Längen sind zum Beispiel in Deutschland gültig.

Ein typischer Fall für die Konversion verschiedener Koordinatensystem ist beispielsweise die Gebäude-Datenbank des österreichischen Bundesamt für Eich- und Vermessungswesen. in mehreren Excel-Dateien (sic!) sind Strassen, Hausnummern und Gebäudetypen aller österreichischen Bundesländer(!) aufgelistet. Zusätzlich ist jedes Gebäude auch mit einer (Punkt-)Koordinate verzeichnet.

Die Koordinaten sind dabei allerdings in zwei verschiedenen CRS gelistet: EPSG 31255 und EPSG 31266. D.h. bei einer Konversion genügt nicht eine Formel sondern man benötigt mindestens zusätzliche Variablen.

Mit Hilfe der Apache SIS Bibliothek steht ein Java-Framework zur Verfügung, dass die EPSG-Spezifikationen lesen kann und Konversionen von über 5000 Systemen durchführen kann.

ps: Neben der bemerkenswerten Tatsache, dass Österreich offensichtlich in Sachen “Offene Daten” ein Vorreiter ist, muss man geoland.at erwähnen. Dort kann man unter anderem Gauss-Krüger-Daten verschiedener CRS eintragen und sich auf der Karte anzeigen lassen.

 

Rohdaten unter Android N

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!)

Die Höhenvermessung der Welt: OpenDEM

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.

Aufbau einer ersten Testumgebung

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"

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.

GPS entschlüsselt

Für einen GPS-Receiver braucht es nicht viel: eine RF-Einheit mit Antenne und ~1,5 GHz, einen Wandler und einen Prozessor. Und dann muss man nur noch wissen, wie man aus den Daten auch die Informationen rausfiltert, die man sucht.

Den Softwarepart hat sich der @field_hamster vorgenommen. In seinem neuen Blog GPS DEMYSTIFIED beschreibt er den Prozess, wie die empfangenen Daten decodiert werden können. In seinen ersten Posts erklärt er, was ein Gold Code ist (Identifier zur Erkennung der Satelliten und dem korrekten Datenempfang) und wie man aus dem Datenstream mit Hilfe eines simplen XOR-Tricks die GPS-Daten filtern kann, ohne einen Megaflop-Prozessor bemühen zu müssen.

Die Hardwarebasis ist das Kickstarter-Projekt KiwiSDR, das einen Xilinx Artix 7 FPGA auf einem Beagle Cape anbietet. Allerdings sollten sich die Ausführungen auch leicht auf andere Hardware transportieren lassen. So sind sie eine hervorragende Ergänzung zu dem Homemade GPS Receiver von Andrew Holme. Dieses Hardware Project basiert auf einem sehr preiswerten Spartan 3.

Michael Field (@field_hamster) hat darüber hinaus auch noch weitere Projekte auf Github, wie einen FPGA WebServer und FPGA GigabitTx. Eigentlich schon alle grundlegenden Module, die man für OpenDGPS bräuchte.

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/]

Android N mit Zugriff auf Raw GPS Data?

Auf der Google I/O sagte Steve Malkos, Technical Manager vom Android Location and Context Team, dass Apps auf Android N zukünftig Zugriff auf die GPS-Rohdaten haben werden. Das wäre tatsächlich für OpenDGPS eine ausgezeichnete Nachricht. Tatsächlich liess sich diese Aussage bisher nicht bestätigen. Möglicherweise gilt diese Aussage auch nur für einige Modelle, da es bisher nicht zu den Anforderungen an die Hardware gehörte, die GPS Pseudoranges auszugeben. Zumindest bei einigen Broadcom-Chips dürfte das nicht unbedingt gegeben sein.

Bleibt auch noch die Frage ob das auch für Glonass, Galileo und BeiDou gilt.

https://www.youtube.com/watch?v=OEvycEMoLUg

Update

OpenDGPS hat sich einige Zeit in einem Hybernation-Modus befunden. Aus privaten Gründen konnte sich kein Unterstützer darum kümmern. Wir hoffen dem Projekt nun wieder Schwung geben zu können.

Zunächst werden wir uns darum kümmern, ein Wiki und/oder eine Mailinglist in Betrieb nehmen zu können. Hilfe ist wie immer willkommen.