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.

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.

Der Start der Sojus-Rakete. (Video nach dem Klick auf spacelivecast.de)

Wenn wir bei OpenDGPS reden, meinen wir natürlich nicht nur GPS sondern beziehen implizit auch das russische System Glonass und auch das europäische Galileo ein (beide sind ebenso wie GPS für ein System verteilter Differenzstationen geeignet). Für Letzteres wurden gestern die Stalliten 3 und 4 ins All befördert. Damit kann der Testbetrieb aufgenommen werden. Ein ausführliches Video über den Start und mit Hintergrundinformationen unter anderem über Galileo findet sich auf spacelivecast.de.

Es gibt viele gute Quellen, die Differential GPS erklären. Eine DGPS-Station empfängt die Signale von verschiedenen GPS-Satelliten und errechnet für jeden einzelnen das Delta, das zum Beispiel durch die Ionosphäre bewirkt wird. Dieses Signal wird dann die mobilen Stationen in der Nähe gesendet. (Das bedeutet übrigens auch, dass Signalverzerrungen die durch die direkte lokale Umgebung entstehen – Gebäude – nicht mit DGPS rausgerechnet werden können.)

Der Übertragungsweg ist im Prinzip egal. Wichtig ist, dass die mobile Station über einen GPS-Receiver verfügt, der seinerseits Zugriff auf die Rohdaten der Satelliten-Signale bietet. Das ist leider nur bei den wenigsten gegeben. Die mobile Station benötigt natürlich nur die Daten von den Satelliten, die es selbst grade sieht.

Der einfachste Weg, um die Daten an die mobilen Stationen zu bekommen, ist NTRIP (Networked Transport of RTCM via Internet Protocol). Es basiert auf http und kann relativ leicht als REST-Service mit XML/JSON umgesetzt werden. Falls auf der mobilen Station kein IP zur Verfügung steht kann man aber auch auf Funktechnik wie den NTX2 zurückgreifen.

Interessant ist, dass ein DGPS in bestimmten Situationen keine geeichte Basisstation benötigt. Entweder kann man die Daten – beispielsweise bei der Erfassung für OpenStreetMap oder der Vermessung eines Grundstücks – nachträglich korrigieren. Oder, man hat eine Situation – beispielsweise für einen lokalen Drohnenflug – in der es genügt, exakte Angaben lediglich in Bezug auf die Basisstation.

Mit einem funktionieren und dichten OpenDGPS-Netz könnten mobile Stationen (sogenannte Rover) ihre eigene Position in Echtzeit bis auf wenige Zentimeter genau bestimmen. Aber wofür könnte man dies konkret einsetzen?

OpenStreetMap

Der wohl wichtigste Einsatzzweck dürfte natürlich die Erfassung von OpenStreetMap-Daten sein. Dieses unglaubliche Projekt zeigt die Power der Community. Während die meisten dieser Daten schon lange in mehr oder weniger guter Qualität in Amtsstuben vor sich hin schimmeln und nur gegen harte Währungen und nur unter unzumutbaren Lizenzen verwendet werden können hat die Crowd innerhalb weniger Jahre die Infrastrukur und die Daten für den freien Gebrauch geschaffen.

Mit Hilfe von OpenDGPS könnte die Datenqualität bereits bei der Erfassung erheblich verbessert werden. Fusswege, Eingänge oder Hydranten würden zukünftig fast blind zu finden sein. Wahrscheinlich könnte OpenStreetMap damit wesentlich bessere Daten haben als alle kommerziellen Dienste.

Autonome Copter und Rover

Eine begeisterte Community hat sich der Programmierung autonomer Copter oder Rover verschrieben. So findet beispielsweise am 5. Oktober in Berlin ein Workshop zum programmieren der AR Drone 2.0 unter node.js statt.

Bisher sind autonome Copter nur eingeschränkt einsetzbar weil die exakte Positionierung mit hohen Kosten für kommerzielle DGPS-Dienste verbunden sind. Auf der Basis von OpenDGPS könnten sich solche Geräte wesentlich besser orten. Insbesondere die Höhenangaben würden hilfreich sein. Interessant dabei ist, dass der Einsatz auch dann möglich ist, wenn in der Region kein verlässliches DGPS-Signal existiert. Mit Hilfe einer festen Station könnte der Copter oder Rover die relative Position ermitteln. Mit nachträglichem Prozessing der Daten liesse sich die genaue Flugbahn später ermitteln.

Übrigens würden autonome Drohnen mit exakter Positionierung sogar einen Fotoservice für OpenStreetMap ermöglichen.

Self-Monitoring

Eines der Buzzwords in Businessplänen der StartUp-Szene ist der Begriff des Self-Monitoring. Gemeint ist der Wunsch vieler Leute, Daten über das eigene Leben zu erheben. Egal ob das Gewicht, die gelaufenen Kilometer oder die aktuellen Nagellackkreationen, there is an app for that!

Grade für Sportler im Outdoor-Bereich ist die Speicherung der exakten Strecken interessant. Bergsteiger, die später in Google-Earth die Tour nachspielen können oder Segelflieger, die Kameraaufzeichnungen mit zentimetergenauen Angaben versehen können dürften sich über einen offenen DGPS-Dienst freuen.

Es dürfte noch viele weitere Möglichkeiten geben, OpenDGPS sinnvoll oder weniger sinnvoll einzusetzen. Egal ob Geocaching oder die Unterstützung von Hilfseinsätzen in Notfällen, letztlich entscheidet die Community was man daraus machen kann.

Die Genauigkeit eines heute Verfügbaren GPS-Empfängers liegt – je nach Quelle und Empfänger – bei 3 bis 50 Metern. Im Prinzip wäre GPS geeignet wesentlich genauer zu arbeiten. Allerdings wird die Genauigkeit durch natürliche und künstliche Einflüsse beeinflusst. Da diese Einflüsse aber auf alle Empfänger wirken kann man diese Abweichungen eigentlich rausrechnen. Dazu wird die Abweichung von einem Gerät berechnet, bei dem die exakte Position bekannt ist. (Eigentlich wird nicht die Abweichung der Postition berechnet, sondern die Abweichungen der Signallaufzeit zu den einzelnen Satelliten). Ein solches Differenzsignal nennt sich sperrig RTCM (Radio Technical Commission for Maritime Services) und kann von teureren Empfängern benutzt werden.

Ein normaler GPS-Empfänger ist ein recht nervöser Zeitgenosse. Ohne Korrektursignal springt die Position selbst dann, wenn man sich nicht bewegt.

Mit einem korrigierten Signal erreicht man – je nach Quelle – eine Genauigkeit von bis zu 2cm. Grade in unwegsamem Gelände (Häuserschluchten!) erhöht sich die Genauigkeit deutlich weil der Empfänger nur sehr wenige Satelliten sieht und Abweichungen (z.B. absichtliche Zeitverzögerungen) der einzelnen Signale sich besonders deutlich auswirken.

Für dieses Korrektursignal gibt es seit einigen Jahren sogar das Internetprotokoll Ntrip (Networked Transport of RTCM via Internet Protocol). Die Daten werden dabei im Wesentlichen in einen HTTP-Stream verpackt auf Anfrage ausgesendet. In Deutschland gibt es dutzende Server, die die Korrekturdaten für verschiedene Positionen senden. Allerdings sind offensichtlich alle geschützt und/oder kostenpflichtig. Mit dem schönen Namen SAPOS (Satellitenpositionierungsdienst der deutschen Landesvermessung) bieten die Länder verschiedene Dienste (siehe AdV) mit unterschiedlicher Genauigkeit an, die über unterschiedliche Medien übertragen werden. In Berlin sendet der RBB zum Beipsiel auf 88,8 ein Signal mit dem eine Genauigkeit von unter 2m berechnet werden können. Genauere Daten sind allerdings bei allen Bundesländern nur kostenpflichtig zu erhalten. Mit 10 Cent pro Minute dürfte es sich um den teuersten behördlichen Dienst überhaupt handeln.

Jetzt ist es aber nicht so, dass der Betrieb einer Referenzstation und die Bereitstellung der Korrekturdaten Raketenwissenschaft ist. Zwar wird dabei mit relativistischen Effekten gerechnet aber die Formeln sind bekannt und zum Teil als OSS (RTKLIB)  verfügbar. Inzwischen gibt es immer mehr Empfänger die sich dazu bringen lassen, die Rohdaten rauszurücken und bieten damit alles, was man als Referenzstation benötigt. Ein Set aus einem Navilock 551EUSB für ca. 30 € betrieben an einem Beagleboard für 150 € unter Ångström Linux, vernünftig kalibriert und mit dem Netz verbunden würde einen hervorragenden Ntrip-Server liefern.

Ein solcher Korrekturserver könnte jedes online verbundene Smartphone mit einer Genauigkeit im Zentimeterbereich ausstatten. Zusammen mit den inzwischen verfügbaren Gyroskopsensoren in aktuellen Androidgeräten und iPhones würden AR-Programme plötzlich wirklich Spass machen.

Es bleibt also die Frage, wer in Zukunft umsonst solche Referenzmessungen anbietet. Hallo Google? Hallo Nokia? Aber eigentlich ist es ja ein hervorragendes Crowdsourcing-Projekt.

Hier lang gehts zu weiteren Informationen:

• Einfache Einführung zu GPS: http://ivvgeo.uni-muenster.de/Vorlesung/GPS_Script/einfuehrung_historisches.html
• SAPOS Berlin: http://www.stadtentwicklung.berlin.de/geoinformation/sapos/
• Tobis Wendorff zu 40cm Low Cost Messung: http://openstreetmap.tobwen.de/fossgis2010_gps.pdf
• Beagleboard: http://beagleboard.org/
• User’s Guide ublox: http://www.zogg-jm.ch/Dateien/Update_Zogg_Deutsche_Version_Jan_09_Version_Z4x.pdf
• Navilock ublox5 GPS-Receiver bei Conrad: http://www.conrad.de/ce/de/product/372874/NAVILOCK-552ETTL-GPS-ENGINE-MODULE-TTL
• GPS-Community: http://www.kowoma.de/gps/
• OSS gpsd: http://gpsd.berlios.de/
• International verfügbare Ntrip-Server: http://www.rtcm-ntrip.org/home

[Disclaimer] Der Artikel erschien ursprünglich auf qrios.de. Dabei handelt es sich um den Blog von qrios, der sich hauptsächlich mit dem Thema Privacy und Netzpolitik beschäftigt.[/Disclaimer]