Geospector GPS-Forum (vormals kowoma GPS-Forum)

hallo Community,

während meiner Recherche bin ich auf dieses Forum gestossen und vielleicht kann mir jemand helfen. Ich soll ein DGPS-System aufbauen mit 2 Exemplaren der oben genannten Komponente. Nun habe ich mich bis zu dieser Arbeit kaum mit GPS beschäftigt. Bis jetzt habe ich das Buch: Satellitenortung und Navigation: Grundlagen und Anwendung globaler Satellitennavigationssysteme von Werner Mansfeld gelesen und verstanden.
Ich arbeite unter Linux (Ubuntu 8.10) und habe Programmierkenntnisse in C. Nun bräuchte ich das Wissen die Daten aus den Empfängern herauszulesen und diesen Daten ein Postprocessing zu unterziehen.
Welche Literatur oder Links können da für mich hilfreich sein?

Hallo Anfänger,



unsre GNSS-Freunde aus Japan haben vor ca. einem Monat eine Sammlung ganz toller Programme unter dem Namen RTKLIB veröffentlicht.
Die sind frei erhältlich, auch deren source-codes.
http://gpspp.sakura.ne.jp/indexe.html
http://gpspp.sakura.ne.jp/rtklib_e.htm

Da kann man aber ganz sicher noch Verbesserungen anbringen.
Interessant dürfte wohl die Frage sein, ob man den RTK-Teil "RTKNAVI" auch auf einem PDA mit WindowsMobile5 oder WindowsMobile6 zum Leben erwecken kann. Da wäre es dann auch super, die Echtzeitlösungsausgabe ( NMEA0183, NMEA RMC/GGA ) des RTKNAVI auf einem VirtualPort des PDAs zur Verfügung zu stellen und anderen Programmen den Zugriff darauf zu ermöglichen.

Es sind vom Autor Tomoji Takasu auch Weiterentwicklungen angedacht.
Diese gehen voraussichtlich in diese Richtungen:
..."Ist ein bisschen voreilig,
RTKLIB 2.3.0 ist geplant, RTCM 2 und 3 unterstützen, Dynamics-Modell, INS Navigation komplexe, lang-Baseline RTK Verbesserung (PCV-, Gezeiten-Phase Windup), Ntrip BKG Standard Ntrip Broadcaster.....
RTKLIB 2.4.0 GLONASS/Galileo/QZSS, RINEX 3.0
Im Anschluss ist der Zeitplan RTKLIB 2.4.0, GLONASS / Galileo / QZSS Antwort, RINEX 3.0-Unterstützung, Netzwerk-Lösungen....
Gut geplant, aber wer weiß."....

Die etwas holperige Übersetzung aus dem Japanischen kommt von Tante Google und leider nicht von mir...
http://translate.google.com/translate?s ... 200902.htm


Wäre schön, wenn dir damit ein Einstieg ins Thema gelingen würde...
und noch viel schöner, wenn du, ganz dem OpenSource-Gedanken verpflichtet, uns hier weiterhin auf dem Laufenden halten würdest, was deine Arbeiten anbelangt...



Ich füge noch 2 ganz vorzügliche PDFs für Einsteiger mit an, in denen knapp und gut gezeigt wird, um was es üerhaupt geht.
http://www.sbg.ac.at/mat/staff/revers/l ... esie_1.pdf
http://www.sbg.ac.at/mat/staff/revers/l ... esie_2.pdf





Stefan


Wenn sich hier ein Elektronik-Hardware-Freak mal rühren würde, der auf OpenSource-Basis ein kleines Platinenlayout per Eagle erstellen könnte...dann wäre auch mein Glück perfekt...

Hallo,

jetzt geißelt uns Stefan nicht nur mit 220seitigen Publikationen - jetzt wird's noch Japanisch

Hatten wir im Forum nicht mal die Empfehlung
Takasu Low-Cost RTK ?

Sind nur 10 Seiten ...


Grüße Roland

anfänger hat geschrieben:Ich arbeite unter Linux (Ubuntu 8.10) und habe Programmierkenntnisse in C. Nun bräuchte ich das Wissen die Daten aus den Empfängern herauszulesen und diesen Daten ein Postprocessing zu unterziehen.
Welche Literatur oder Links können da für mich hilfreich sein?

Unter Linux bietet sich der gpsd(8) an. Dieser nuckelt die Daten z.B. via RS232 aus dem GPS Empfänger raus und verteilt sie mittels TCP-Socket an belibig viele (übers Netzwerk verteilte) Programme, die die Daten dann weiterverarbeiten. Differential-GPS wird ebenfalls unterstützt. Das schöne an gpsd(8) ist, dass er spezifische Eigenschaften des Empfängers vor den verarbeitenden Applikationen verbirgt. Siehe: http://gpsd.berlios.de/

Zum Anzeigen und Bearbeiten von GPS-Daten verwende ich Viking:
http://viking.sourceforge.net/
Wobei sich diese GPS-Daten bei mir auf Wegaufzeichnungen und Wegpunkte vom Laufen beschränkt.

Hallo Anfänger,
willst du jetzt selbst ein Gerät mit dem LEA 4T bauen ?
Oder meintest du das fertige Gerät AEK-4T ?
Also ist die Aufgabe nur Software oder Hardware+Software ?

Unter Linux bietet sich der gpsd(8) an.

gpsd ist zwar sehr gut, da man für verschiedene Geräte immer die selbe Schnittstelle
benutzen kann. Aber für DGPS doch etwas ungeeignet. Oder ?
Unterstützt es überhaupt Rohdaten ?

eine Sammlung ganz toller Programme unter dem Namen RTKLIB

Das sieht wirklich gut aus. Schon mal jemand probiert ?

Das beste open-source Postprocessing-Paket, das ich bis jetzt kenne ist: gpstk http://www.gpstk.org

Wenn sich hier ein Elektronik-Hardware-Freak mal rühren würde, der auf OpenSource-Basis ein kleines Platinenlayout per Eagle erstellen könnte...dann wäre auch mein Glück perfekt...

Bin zwar kein Hardware-Freak, aber was suchst du denn ?

Hallo XPosition,


ich hätt halt gerne ein kleines, HF-mässig gutes, Platinchen gesehen, das dem LEA-4T ein Zuhause bietet.
Darauf sollten die HF-Design-Regeln, wie sie von u-blox in ihren Dokus beschrieben werden, einigermassen erfüllt sein.

Mit an Bord ein SMA-Anschluss für eine aktive Antenne,
der Active Antenna Supervisor ( siehe 4.3.4 Active Antenna Supervisor der http://www.u-blox.de/customersupport/gp ... 05007).pdf Doku.
Die USB-Schnittstelle(selfpowered) so wie in der genannten Doku beschaltet und den (TTL-)UART der LEA-4T aufgeteilt auf jeweils 2 Anschlüsse ( also 2xR, 2xTx )
An einem Strang ein MAX Pegelwandler, der auch gleich noch den Timepulse auf das "echte" RS-232 Format umsetzen könnte, am anderen TTL-Zweig könnte man ein (abschaltbares, problemloses und günstiges Bluetooth-Modul (BTM222) dranhängen.
Ach ja, die kleine Backupzelle noch...

Für die (mobile) Spannungsversorgung per Li-Ion-Einzelzelle, die mit einem absoluten Minimum an Bauteilen auskommt, hätt ich auch schon Vorstellungen...

Von ungefähr sowas träume ich nachts....

Was die Tests mit RTKLIB anbelangt, am kommenden Wochenende, spätestens am Übernächsten sollte bei mir endgültig Zeit dafür sein.
Wenn man den umfangreichen Fachpublikationen Glauben schenken darf, die auf der Software aufbauen, sollte das eine gute Sache sein.
Wir werden sehen...


Stefan

Erstmal Danke für die vielen Antworten und Anregungen!

Um die Arbeit mal übern Daumen zu erklären: Der Professor hätte gerne für seine Modellflugzeuge eine möglichst genaue Positionsbestimmung (und zwar in Echtzeit, also nicht wo er gewesen ist, sondern wo er ist). Nun das hört sich meiner Meinung nach sehr nach DGPS an. Während meiner Recherche ist aber nun folgendes aufgefallen: es gibt mehrere Lösungswege . Das Gute daran, mein Thema ist noch nicht ausformuliert, d.h. solange die Aufgabe erfüllt wird (mit ein paar Randbedingungen), kann ich machen was ich will.
Wie stark der Einsatz von Soft- bzw. Hardware wird, liegt an dem Lösungsansatz. Ich werde noch bis Ende der Woche versuchen, soviele Lösungen wie möglich zu finden um den entscheidenden Weg einzuschlagen.
Ich hoffe nach Antwort meines Professors bin ich auch besser darüber im Bilde, welche Hardware denn schon alles vorhanden ist.

@Xposition: Ich glaube das AEK-4T ist wohl ein wenig zu fertig und teuer für den Professor

@ssquare_de: ich werde wohl auch für dieses modul eine Platine layouten müssen, höchstwahrscheinlich mit Eagle

Das Problem ist ja je genauer die Position bestimmt werden soll, umso höher ist der Zeitbedarf der Messungen. Für ein Modellflieger nicht gerade optimal, der will sich ja bewegen!
Wie gut (bzw. interessant) ist denn SAPOS für mich? Laut der Tabelle 4.4 im Buch von Herrn Mansfeld ist bei der Echtzeit-Träger-Phasen-Messung ja eine Genauigkeit von 1-5cm angegeben. Und nachdem die Position bestimmt wurde, wird für jede weitere Messung ja nur 1s an Zeitbedarf angegeben. Hört sich auch gut an....

Edit: Um dem OpenSource Gedanken gerecht zu werden: Über meine Arbeit wird es dann wohl auch ein Doku-Wiki geben!

Hallo Anfänger,


na, das ist jetzt mal ordendlicher Input von dir.

Wir wollen also Echtzeitgenauigkeit.
Wenn möglich mit mehreren Hz Updaterate.
( die LEAs können Rohdatenausgabe bis 10Hz, was die Funkstrecken leisten und wo die Grenzen von RTKLIB liegen, weiss ich leider nicht)
Und das ganze Spektakel findet in einem Umkreis von max. 1km ? statt.

Mein Vorschlag:
Ein LEA-4T wird als Basisstation am Boden eingesetzt.
Der Zweite fliegt als Rover mit.
Dessen Daten werden per Bluetooth an den Rechner am Boden übertragen.
Da selbst die leistungsfähigsten Bluetoothmodule zuverlässig nur bis 150-200m übertragen, sollte man hier auch Funkmodule andenken, die absolut perfekt bis zu 1,5-2km funken.

Z.B.
ZigBee Funkmodul XBEE-PRO ( Bezug über Reichelt o.a.)
oder auch ein
Wi.232EUR-R von radiotronix ( Bezug überSander o.a.)
http://www.radiotronix.com/
http://www.radiotronix.com/products/pro ... ?ProdID=13
Die Datenrate, die die beiden Funker schaffen, sollten mit den bischen Rohdaten im Binärformat keine Probleme haben.

Beide LEA-Datenströme treffen sich also im Laptop/Netbook
(die Roverdaten vom Flieger über die Funkstrecke,
die Basisstationsdaten vom am Boden stationierten LEA-4T übers USB-Kabel oder Bluetooth )
vor dem RTKLIB. ( mit den c-codes auf Linux umgesetzt? )
Das RTKLIB verarbeitet die beiden Datenströme in Echtzeit und bietet als Datenausgabe unter anderem das NMEA-Format mit den korrigierten Daten ( Timestamp, Position, Geschwindigkeit....) des Rovers an.
Die Ausgabe der NMEA-Lösung kann auch auf einen seriellen Port des Laptops/Netbooks erfolgen, auf den dann ein beliebiges, nachgeschaltetes GIS/GPS-Programm Zugriff hat, das die Daten visualisiert, für eine spätere Auswertung speichert, usw., usw. ......

Das wäre eine vom Aufwand ( auch finanziell ) überschaubare Lösung, die vermutlich hochgenau ist.
Durch die Kunstflugmanöver wird zwar der Kontakt des Rovers zu den Sats immer wieder abreissen? , aber die Positionsangaben und daraus abgeleitet Geschwindigkeiten und Beschleunigungen ( in allen 3 Dimensionen) sollten dennoch weit besser wie beim autonomen GPS sein.

Mit der optimalen Antennenanordnung im Flugzeug müsste man vielleicht ein bischen experimentieren...

Ein kleines Eagle-Board für den LEA-4T wäre ganz grosse Klasse von dir.
Darauf wird schon sehr lange gewartet.


Stefan

P.S. Das RTKLIB würde natürlich in Echtzeit arbeiten, und mit deiner eigenen Basisstation am Boden bist du nicht auf SAPOS angewiesen, um theoretisch vergleichbare Genauigkeiten zu erzielen.
Mit dem 2ten LEA-4T am Boden hast du quasi dein SAPOS selbst mit dabei.

Hallo,

XPosition hat geschrieben:

eine Sammlung ganz toller Programme unter dem Namen RTKLIB

Das sieht wirklich gut aus. Schon mal jemand probiert ?

Ich habe bisher nur den Ntrip Client und NTrip-Browser getestet. Das funktioniert sauber und versorgt eine Phasetrak12 Rover mit Korrekturdaten auf Basis von Pseudoranges recht ordentlich.


Gruss Joern Weber

Hallo Anfänger,

anfänger hat geschrieben: Wie gut (bzw. interessant) ist denn SAPOS für mich?

Wenn schon das AEK-4T für deinen Prof zu teuer ist, dann will er SAPOS erst recht nicht bezahlen.

Frage bei ascos nach, ob sie dir zu wissenschaftlichen Zwecken einen Zugang sponsoren oder begnüge dich mit deren freien Dienst.

http://www.ascos.de/

Gruss Joern Weber

Hello Mr.Tomoji Takasu,


I just have read, that the KOWOMA-forum has found all the long, long way to Japan.

Much thanks also from here,
Mr.Tomoji Takasu,
(author of RTKLIB)
for the FREE RTKLIB-softwarepackage.




Greetings
Stefan

Hab mich nun mit den u.a. Punkten beschäftigt und folgende Erkenntnisse gewonnen (Bei Irrtümern mich bitte korrigieren):

-gpsd(8):
Also was schonmal sehr gut ist, mein Empfänger ist bei gpsd in der Liste aufgeführt und scheint einwandfrei unter dem Programm zu laufen. Allerdings bin ich mir nicht 100% sicher ob ich damit auch die Rohdaten auslesen kann? In der Dokumentation steht zwar etwas von einem raw- bzw. super-raw-mode, aber ich hatte noch keinen Zugang zur Hardware von daher konnte ich es noch nicht testen.
Wenn ich das richtig verstanden habe, benötige ich unbedingt die Rohdaten (die Pseudoentfernungen), da im NMEA Protokoll ja diese mit einer Fehlerangabe schon "gelöst" und in (wahrscheinliche) Längen- und Breitengrade umgewandelt worden sind.

-gpstk:
Dieses Tool scheint eine Menge zu können, aber aus meinen 2 verschiedenen Sätzen Pseudolängen, eine Korrekturberechnung durchzuführen scheint mit diesem Programm nicht möglich? Oder hab ich das übersehen?

-RTKLIB:
Aufgrund der japanischen Dokumentation nicht gerade einfach Die Übersetzung ist ja echt ein wenig "holperig". Habe ich mir noch nicht näher angesehen....ist mal für dieses Wochenende angesetzt.

-Viking:
Dieses Programm sieht echt gut aus! Ich denke mal besser kann man die gewonnenen Ergebnisse nicht präsentieren. Ist es mit diesem Programm möglich in Echtzeit die Ergebnisse darzustellen?

-andere Lösungen wie Ntrip etc:
Da das DGPS-System seine eigenen Daten gewinnen sollte, fallen Dienste die Korrekturdaten anbieten wohl erstmal aus. Ist aber auf alle Fälle ein Weg, sollte ich die Korrekturdaten nicht selber gewinnen können.

@ssquare_de:
In der Theorie finde ich Deinen Lösungsansatz sehr gut. Jetzt muss sich nur noch zeigen, ob ich in der Lage bin, das in die Praxis umzusetzen

Hallo Anfänger,



ich denke schon, dass dein Problem mit RTKLIB zu schaffen ist.

Wenn in einer der nächsten Releases auch die RTCM2/RTCM3-Funktionalität implementiert wird, so wie es derzeit vom Author angedacht ist, kann man auch fremde Basisstationen ( gratis oder gegen Gebühr) nutzen, ohne Änderungen an der Hardware vorzunehmen.

Bei Nutzung der ( hochwertigsten!!!) Gratisbasisstationen fallen nur die normalen Kosten beim Provider für den mobilen Internetzugang (UMTS) des Laptops/Netbooks an. ( mobile Datenflatrate ? )
Nachdem aber bei den geringen Datenströmen kaum Traffic da ist , kann sich das kostenmässig zu keinem grösseren Problem auswachsen.

Den 2ten Empfänger, der zunächst als Basisstation eingesetzt werden würde, kannst du dann 1:1 übernehmen und als 2ten Rover in einem weiteren Flugzeug/anderweitig einsetzen.

Das mit der Doku auf japanisch (PDF-File) ist natürlich zunächst ein Problem.
Aber die GUI der einzelnen Programme ist ja englischsprachig gestaltet und bietet kaum Widerstand , wenn du GNSS-mässig erst mal die Grundprinzipien von RINEX, GPS, DGPS und RTK erfasst hast.

Die Programme sind sehr funktionell, knapp und übersichtlich aufgebaut und bieten wirklich alles, was wichtig ist.
Manche Funktionalität sucht man selbst in den renomierten Profilösungen vergeblich.


Stefan

P.S. Bei Bedarf erreichst du mich auch über eine PM.

anfänger hat geschrieben:-gpsd(8):
Also was schonmal sehr gut ist, mein Empfänger ist bei gpsd in der Liste aufgeführt und scheint einwandfrei unter dem Programm zu laufen. Allerdings bin ich mir nicht 100% sicher ob ich damit auch die Rohdaten auslesen kann? In der Dokumentation steht zwar etwas von einem raw- bzw. super-raw-mode, aber ich hatte noch keinen Zugang zur Hardware von daher konnte ich es noch nicht testen.

Raw-Mode beim gpsd(8) bedeutet, dass er die vom Empfänger erhaltenen Daten 1:1 weiterreicht. Normalerweise konvertiert gpsd(8) die Daten ja in NMEA. Im Super-Raw-Mode werden selbst Binärnachrichten unangetastet durchgereicht.

Mir ist auch aufgefallen, dass der gpsd(8) mit dem Empfänger quasselt und ihn ggF. für seine Anforderungen umprogrammiert. Eine alte Sirf-II Maus zeigte sich nach dem Erstkontakt mit gpsd(8) deutlich geschwätziger als vorher.

Es kann gut sein, dass es für deine Anwendung keinen Sinn macht gpsd(8) unmittelbar auf die Empfänger los zu lassen. Vielleicht ist es bei dir besser, die ganze Datenaufbereitung inkl. DGPS Korrektur in einem anderen Programm laufen zu lassen. Die fertigen Daten kann man dann u.U. in den gpsd(8) einspeisen um sie leicht an verschiedene Konsumenten zu verteilen. Oder dein Programm implementiert die gleiche Schnitstelle und Protokoll wie gpsd(8)...

Oder die Empfänger spucken irgendwelche Rohdaten aus, die der gpsd(8) ignoriert. Ein Konsument kann dann in den Raw-Mode schalten und diese Rohdaten für DGPS verarbeiten. So ist es einfacher die Empfängerdaten übers Netzwerk zu verteilen. Wie oben könnte man die fertigen DGPS-Daten als zweite Quelle wieder in gpsd(8) einspeisen. Vielleicht spucken die Empfänger neben den Rohdaten zusätzlich NMEA Daten aus. Die kann der gpsd(8) selbst verarbeiten. Damit hättest du gleichzeitig die original nicht-DGPS Position der Empfänger und die korrigierte DGPS Position über die gleiche Schnitstelle verfügbar.

anfänger hat geschrieben:-Viking:
Dieses Programm sieht echt gut aus! Ich denke mal besser kann man die gewonnenen Ergebnisse nicht präsentieren. Ist es mit diesem Programm möglich in Echtzeit die Ergebnisse darzustellen?

Ja, zumindest in der aktuellen 0.9.8: Menü "Layers" => "New GPS Layer". Es erscheint eine Dialogbox, "Realtime Tracking Mode" wählen, entsprechende Daten für die Verbindung mit gpsd(8) kontrollieren / ändern, "OK". Dann das Kontextmenü des "GPS" Layers öffnen (rechte Maustaste) und "Start Realtime Tracking" anklicken. Vielleicht noch einen "Map Layer" hinzufügen und sicherstellen, dass er als unterster in der Layer Liste steht.

gpsd(8) muss dazu natürlich laufen, sich mit dem Empfänger verstehen und der einen Fix haben. Bei mir funktioniert das problemlos mit meinem Garmin etrex H und einer antiken, seriellen GPS-Maus mit Sirf-II Chipsatz.

Na, das ist mal ein hilfreicher thread.

Hallo Stefan,
dein Vorschlag mit der Echtzeit-Verarbeitung kam mir auch gleich in Sinn und ist natürlich spannend.
Aber ob das im gegebenen Zeitrahmen so geht.... Da gibt es gleich ein paar Problemchen mehr.
Einfacher wäre ein lokales abspeichern(SD-Card) der Rohdaten und späteres Postprocessing.

Und es kommt ja auch darauf an welche Qualität die Aufzeichnung haben soll.
Da ist es vielleicht mehr angedacht noch ein paar Sensoren auf das Platinchen zu packen um Fehler
rausfiltern zu können um die Genauigkeit zu erhöhen.

Mmmh, da fällt mir ein:
Bekommen die Profs gerade nur noch Geld von der Rüstungsindustrie um Drohnen zu bauen ?

-gpstk:
Dieses Tool scheint eine Menge zu können, aber aus meinen 2 verschiedenen Sätzen Pseudolängen, eine Korrekturberechnung durchzuführen scheint mit diesem Programm nicht möglich? Oder hab ich das übersehen?

Doch, das geht. Du must auf jeden Fall vorher die Rohdaten in das Rinex-Datei-Format konvertieren. z.B. mit http://facility.unavco.org/software/teqc/teqc.html

Hallo jkunz,
wie ist denn Viking im Vergleich zu Qlandkarte ? Besser, Schlecher ? http://www.qlandkarte.org/

Hallo Anfänger,
du kannst es dir auch ganz einfach machen. Schau mal auf http://fenrir.naruoka.org/archives/000666.html
Das ist zwar ein Autopilot, aber in dem Projekt steckt schon alles drin, das du auch brauchst.
Ja, er ist auch Japaner