Software für post processing DifferentialGPS: CorrectGPS V2.1

Moin,

ich habe ein kleines ppDGPS-Programm geschrieben, welches DGPS mit relativ wenig Aufwand und vergleichsweise sehr geringen Kosten ermöglichen soll. Es handelt sich bei der Version 2.1 um die erste public release version, die ich nur teilweise testen konnte, da mir z.Zt. noch der erforderliche zweite GPS Logger fehlt. Ich denke aber, dass es genügend Leute geben dürfte, die über zwei identische GPS Logger verfügen und Spass an einem Testlauf haben.
An diese Tester meine Fragen:
Läuft bei Euch das Programm ? Wo klemmt es eventuell ? Funktioniert die Track-Korrektur ? Wie genau ist die Track-Korrektur ? Wie hängt die Genauigkeit der Korrektur von der Entfernung zum Referenzpunkt ab ?
Das Programm könnt Ihr hier runterladen (100 % kostenfrei und legal !!):

Download: http://hotfile.com/dl/122903466/0ac9ff7/CorrectGPS21.zip.html

Die Nachfolgende Anleitung befindet sich auch in der ZIP-Datei:

CorrectGPS

Ein einfaches ppDGPS-Programm
ppDGPS => post processing DifferentialGPS
Ein Programm, mit dem nachträglich die
Genauigkeit einfacher GPS-Tracks erhöht
werden kann.

Voraussetzung:

Windows-Betriebssystem.
.NET Framework 3.5 empfohlen, wahrscheinlich
läuft es aber auch mit 1.0, 1.1 und 2.0.

Zwei (möglichst) identische GPS-Datenlogger,
welche im .GPX-Format aufzeichnen.
z.B.:
2x Navin MiniHomer GPS Data Logger (je ca. 80 €)
oder
2x Holux M241 GPS Data Logger (je ca. 65 €)
oder
2x Mainnav MG-910D GPS Data Logger (je ca. 40 €)

=========Edit=======================
Es sind aber grundsätzlich alle GPS Datenlogger
geeignet, die im GPX-Format aufzeichnen können.
Es können auch unterschiedliche Geräte verwendet
werden, allerdings könnten deren Ergebnisse
aufgrund unterschiedlicher interner Mess- und
Berechnungsverfahren voneinander abweichen.
=========Edit=======================

Anleitung:

  1. .ZIP-Datei in ein beliebiges Verzeichnis entpacken.
    Installation und Setup nicht nötig.

  1. Einen Referenzpunkt suchen und die genauen
    Koordinaten dieses Referenzpunktes ermitteln. Dies ist
    auf drei verschiedenen Wegen möglich:

a. Ein amtlicher Messpunkt, dessen genauen Koordinaten
man beim Landesvermessungsamt oder beim regionalen
Katasteramt erfragen kann.
=> Manuelle Eingabe unter: Referenz->Referenz-Punkt->
Koordinate manuell eingeben. (Format: Dezimalkoordinate)

b. Ein markanter Punkt, den man im Luftbild gut
erkennen kann und dessen Koordinaten deswegen mittels
Google-Satellite ermittelt werden können.
=> Manuelle Eingabe unter: Referenz->Referenz-Punkt->
Koordinate manuell eingeben. (Format: Dezimalkoordinate)

c. Am Referenzpunkt einen der beiden GPS Logger
möglichst an verschiedenen Tagen, mehrfach und über
mehrere Stunden unbeweglich platzieren und dabei
GPX-Tracks aufzeichnen. Aus dieser einen oder mehreren
.GPX-Dateien kann CorrectGPS die Koordinaten des
Referenzpunktes berechnen.
=> Berechnung unter: Referenz->Referenz-Punkt->
Koordinate berechnen / oder: ->aus Liste auswählen
(falls zuvor bereits berechnet und abgespeichert).

=========Edit=========================
Man kann zur Vereinfachung natürlich auch
lediglich die Datei der Referenz-Messung verwenden, um
damit zunächst die Koordinaten des Referenz-Punktes zu
ermitteln. Das Ergebnis dürfte nicht ganz so genau sein.
=========Edit=========================

Je näher der Referenzpunkt am Kartierungsgebiet liegt,
desto genauer die spätere Korrektur durch CorrectGPS.
Zu grosse Entfernung kann möglicherweise die
Genauigkeit im Gegenteil sogar verringern.
Aufgepasst ! Der Referenzpunkt sollte dafür geeignet
sein, dass der Referenz-Logger dort mehrere Stunden
unbeaufsichtigt abgelegt werden kann (tarnen !).

  1. Zur Kartierung einen der beiden Logger auf dem
    Referenzpunkt ablegen und mindestens für die Dauer
    der Kartierung einen GPX-Track aufzeichnen lassen.
    Der zweite Logger wird zur Kartierung mitgenommen
    und zeichnet den eigentlichen GPX-Track auf.
    Achtung: Die Referenz-Messung muss vor der Kartier-
    Messung begonnen und erst nach Beendigung der
    Kartier-Messung beendet werden !

  1. Nach der Kartierung den Referenz-Track in
    CorrectGPS laden unter:
    => Referenz->Referenz-Messung->Mess-Datei öffnen.
    Im linken Referenz-Fenster sollte das Schleifen-Muster
    der Referenz-Messung erscheinen.

  1. Kartier-Track in CorrectGPS laden unter:
    => GPS-Track->Track-Datei öffnen.
    Im rechten GPS-Track-Fenster sollte der unkorrigierte
    Kartier-Track erscheinen.

  1. Korrektur starten:
    => GPS-Track->Track korrigieren.
    Im rechten GPS-Track-Fenster sollte der korrigierte
    Kartier-Track erscheinen.

  1. Korrigierten Kartier-Track speichern:
    => GPS-Track->Korrektur speichern.
    Die korrigierte Track-Datei der Ursprungsdatei ???.gpx
    erhält automatisch den Namen ???_corr.gpx

Statuszeile

N = Nord-Koordinate des Referenz-Punktes
E = Ost-Koordinate des Referenz-Punktes
H = Höhe des Referenz-Punktes in müNN
P = Anzahl der Punkte in der GPX-Datei
Von = Beginn der Messung (Datum, Uhrzeit)
Bis = Ende der Messung (Datum, Uhrzeit)

  • Thunichgud -

Die Oberfläche “läuft” auch unter Linux (mit Mono). Weiteres kann ich im Moment, mangels Daten, nicht ausprobieren.


vofiwg@kiste1:~/Desktop/CorrectGPS21$ mono --version
Mono JIT compiler version 2.6.7 (Debian 2.6.7-5)

Tue uns was Gutes, uns schaue sich dieses Programm an: http://rtklib.com
So macht man es richtig, 100 % kostenfrei, legal, mit handelsüblichen,
wenn auch etwas altmodischen, GPS Chipsätzen wie antaris4, sirf2 und
(mit einigen Einschränkungen) sirf3 :wink:

Ich finde die Idee sehr gut. Aber ob der Ansatz praktikabel ist, wage ich zu bezweifeln. Abgesehen davon, dass man einen zweiten Logger benötigt, muss dieser auch noch auf dem Referenzpunkt liegen. (unter möglichste gleichen Empfangsbedingungen) Damit ist der oftmals auch frei zugänglich, wenn ich den nicht im eigenen Garten liegen lasse.
Neulich habe ich eine Zusammenfassung einer Diplomarbeit gesehen, welche sich mit der Spurgenauigkeit des GPS beschäftigt hat. Dort konnte eine hohe Genauigkeit im niederen Geschwindigkeitsbereiches schon dadurch erreicht werden, dass das Kurssignal mit ausgewertet wurde. Könntest du dir einen ähnlichen Ansatz vorstellen?

Gibt es da einen Link, vielleicht auch auf die ganze Arbeit?

Es handelte sich dabei um ein Plakat, welches in der TU ausgehängt war. Leider kann ich keine online Hinweise dazu finden. Vielleicht schaue ich die nächste Woche nochmal genauer ob es da etwas öffentliches gibt.

Das tun die Garmin Geräte auch schon. Wenn man auf einer Geraden eine “Genauigkeit” von 3m angezeigt bekommt, und dann eine Kurve fährt (Motorrad) erhöht sich die “Genauigkeit” schon mal auf 13m. Fährt man dagegen die gleiche Kurve mit dem Fahrrad, bleibt die “Genauigkeit” bei 3m.

Dadurch wird sich auch bei Deiner SW-Lösung ein Problem (zumindest mit Garmin Geräten) ergeben, dass doppelt Korrektuern an die ausgegebene Koordinate angebracht werden.
MMn funktioniert Postprocessing nur mit echten Rohdaten.

Ohne es zu wissen, hatte ich auch schon den Eindruck, daß GPS-Geräte (Garmin Vista HCx und QStarz BT-Q1000X, beide mit dem MTK II Chip) hier “mehr” tun. Tracks scheinen beim Vergleich mit einem Satellitenbild und miteinander genauer zu sein, als wenn man die Koordinaten eines stationären Punktes über einen Zeitraum von z.B. 24 - 48 Stunden aufzeichnet.

Die rtklib ist - soweit ich es mit einem kurzen Blick verstanden habe - unter Turbo C++ einsetzbar, jedenfalls nicht unter .NET-Framework, welches ich bevorzuge. Ausserdem hatte ich diese Programm zunächst nur zum Eigengebrauch geschrieben. Es sollte kein Lebenswerk werden. Wem’s nicht gefällt, der muss es auch nicht verwenden.

Ich möchte zunächst mal herausfinden, ob ich mich mit dem Programm auf einem totalen Holzweg befinde. Wenn’s funktioniert werde ich es evtl. weiterentwickeln.

Der Weg ist das Ziel. Das Wichtigste ist also, erst einmal zu überlegen, wie Du eine eventuelle Verbesserung überhaupt feststellen könntest. Um die erwähnten Probleme auszuklammern, würde ich zunächst mit der Messung stationärer Punkte beginnen.

Du legst also einen Logger für mindestens 24 Stunden, am besten 48 Stunden oder länger (eine Woche) auf einen stationären Punkt (z.B. irgendwo im Garten) mit möglichst ungestörtem Empfang (um sytematische Fehler wie z.B. durch Gebäude-Reflexionen o.ä. hervorgerufen, auszuschließen). Dann bereitest Du die Meßreihe statistisch auf. Durch einfache Mittelwertbildung bekommst Du z.B. schon eine recht genaue Position. Zumindest den Einfluß der atmosphärischen Störungen (= größter Störfaktor) solltest Du so eliminieren können.

Schließlich wiederholst Du die Meßreihe mit zwei Loggern an zwei stationären Punkten, die zunächst nicht weit voneinander entfernt liegen müssen (i.e. einen Meter getrennt). Nur wenn Du hier durch Berücksichtigung der Daten des ersten Loggers eine Verbesserung der Messreihe des zweiten Loggers beobachten kannst, brauchst Du überhaupt weiter zu machen… Dann kannst Du den Abstand zwischen den Loggern systematisch vergrößern: Zum Nachbargrundstück, zur Freundin im nächsten Ort, … Wenn Du dann immer noch Verbesserungen feststellst, kannst Du anfangen, einen der Logger zu bewegen…

@Schlauchboot:
Den von Dir beschriebenen Test mit einem Logger habe ich natürlich schon während der Entwicklung gemacht und die Ergebnisse waren erwartungsgemäss Prima. Das Schleifenmuster des GPX-Tracks eines stationären Loggers (bis zu 40 m vom Mittelpunkt) wurde auf einen einzigen Punkt fokussiert, dessen Koordinaten (geschätzt) im Bereich von weniger als 50 cm an den korrekten Punkt heranreichen. Aber das war simple Statistik.

Es steht jetzt der Test mit zwei Loggern aus. Bevor ich mich selbst in Unkosten stürze und 160,- € für zwei identische Datenlogger investiere, möchte ich erst einmal sehen, ob ich mich vielleicht doch auf dem Holzweg befinde. Deswegen dachte ich, dass es in Deutschland bestimmt ein paar Leute gibt, die bereits zwei Logger besitzen und das mal Testen können.

Und genau da beginnen meiner Meinung nach die Probleme.

Sobald man mit einem der Logger unterwegs ist, verändern sich dessen Empfangsbedingungen durch Abschattung, Mehrwege-Empfang und was es sonst noch an Fehlerquellen beim GSP-Empfang gibt. Zudem dürfte die Vergleichbarkeit mit zunehmender Entfernung rasch abnehmen. Ich kann nicht einschätzen ob das bei 1-2 km kritisch wird oder erst später.

Nur bei vergleichbaren Bedingungen (freie Sicht bei beiden Loggern) hast du eine einigermaßen vergleichbare Situation. Allerdings ist die freie Sicht genau der Fall, wo man sowieso schon die beste Genauigkeit erzielt und daher am wenigsten von einer möglichen Verbesserung profitiert.

@Thunichgud
Die Seite http://www.kowoma.de/gps/ kennst du? Insbesondere die Ausführungen zu Genauigkeit und Fehlerquellen könnten interessant für dich sein.

Edbert (EvanE)

Moin,

gibt es schon Test-Ergebnisse ? Wenn ja, dann würde ich mich freuen, wenn man mir die entsprechenden .GPX-Dateien (Referenzpunkt-Koordinaten, Referenz-Messungen, GPS-Tracks) zukommen lassen könnte.

Hinweis: Ich habe im ersten Post zwei Ergänzungen eingefügt.

  • Thunichgud -

Die wollen in der Regel Geld dafür

Über das Ganze habe ich vor Jahren auch schonmal was auf Talk-DE geredet. Unter bestimmten Bedingungen bekommt man recht brauchbare Ergebnisse raus. Meine Messungen haben damals jedoch ergeben, dass man mit “normalen” Empfängern nur in (umgerechnet) 4 von 10 Fällen eine Genauigkeit von ca. einem Meter erhält. Das könnte schon statistischer Zufall sein.

Da ich’s für eine Diplom-/Bachelorarbeit aufgehoben habe, steht das hier noch im Raum:
http://openstreetmap.tobwen.de/fossgis2010_gps.pdf

Das funktioniert defintiv im genauen Bereich und ist kostengünstig realisierbar. Hat den gleichen Ansatz, wie CorrectGPS, da man keine Referenzdaten einkaufen muss.

Den meisten OSM-Mappern wird es wohl genügen, gespeicherte GPS-Daten eines bekannten
Fixpunktes mit eigenen Aufzeichnungen zu verrechnen. Quelle könnte zB. der eigene
Garmin-eTrex auf dem Balkon sein.
Perfekt wäre es zB. mit einem Handy mit GPS-Empfänger und Internet-Flatrate die
GPS- Koordinaten oder Korrekturdaten mehrerer bekannter Fixpunkte online zu benutzen.
Das wäre doch etwas: online abrufbare kostenlose Korrekturdaten …
Mir ist natürlich klar, daß diese Daten vermutlich nicht “amtlich” sind :wink:

Nichts anderes wird nachher bei Galileo passieren und heute schon mit WAAS oder EGNOS gemacht.

Nach meinem verständnis wird aber bei egnos, waas, rtk usw. ungefähr so gesendet: Sat4 ist 5m links, sat8 ist 7m mit 135 grad daneben, sat 9 passt usw.
Ich meine dass also per satelit die ungenauigkeit angegeben ist.
Bei dem obigen tool werden aber nur 2 fertig verrechnete gpx dateien miteinander korrigiert was aber bei schlechtem empfang schwachsinn ist da der eine empfänger seine position mit anderen sats errechnet hat als der andere.

Für bessere ergebnisse müsste man rohdaten haben was aber kein mir bekannter leistbarer logger ausspuckt. (siehe rtklib)

Bitte korrigiert mich falls es nicht so ist.

http://www.kowoma.de/gps/waas_egnos.htm

Nur für ausspucken brauchst du keinen Logger. Vollständige Rohdaten
für RTKLIB (Pseudorange, CarrierPhase, Ephemeriden) in der Massenware-Kategorie
werden von SIRF2-basierten
Empfängern geliefert (alte Firmware Versionen 2.2.0, 2.3.1, 2.3.2,
also definitiv kein XTrac; leider nur mit 1Hz Zeitabstand) und von allen bekannten
u-blox Antaris4 Empfängern (hier geht es bis 20 Hz (!), allerdings sind
die CarrierPhase Messungen mit vorprogrammierten TRK Einstellungen
und so einer höher Geschwindigkeit recht unzuverlässig).
Wer so eine Basisstation mit der externen Antenne betreiben will, der kann
z.B. für 30,17€ ein EM-500 Modul von Navilock kaufen
http://navilock.de/produkte/gruppen/13/Boards_und_Module/95807_EM-500.html
http://www.amazon.de/NAVILOCK-Modul-Engine-Board-EM-500/dp/B001AUN1WI/ref=sr_1_1?ie=UTF8&s=ce-de&qid=1309933988&sr=8-1