Da ich zur Zeit genau das gleiche mache, nämlich auch eine Diplomarbeit über das gleiche Thema mit den gleichen Empfängern, melde ich mich hier auch mal zu Wort.
Mir wurden zwei AEK-4T zur Verfügung gestellt, deswegen muss ich mich nicht um eine Schaltung kümmern. Da ich technische Informatik studiere ist das ja auch nicht direkt meine Aufgabe
Neben den Empfängern habe ich zwei Asus EeePC Netbooks mit Ubuntu 8.04 bzw. Ubuntu eee zur Verfügung. Das ganze System soll im Bereich der Robotik eingesetzt werden, ich habe es also mit weitaus kleineren Geschwindigkeiten zu tun, dafür habe ich allerdings das Problem das ich nicht so eine freie Sicht auf den Himmel ab wie bei einem Flugzeug.
Ich wollte die Kommunikation auch zuerst über Bluetooth machen, als ich das Zeug dann aber endlich mal zum laufen gekriegt hab hat sich das auch schon wieder recht schnell erledigt, da nach ca. 10m kein Signal mehr empfangen wurde. Ich habe dafür eine serielle Verbindung über RFCOMM hergestellt und das serielle Device (/dev/ttyACM0 bei mir) mit dem tool socat (sehr zu empfehlen) an diese Verbindung gekoppelt, so dass ich auf das device zugreifen konnte, als wäre es direkt angeschlossen. Mittlerweile mache ich das ganze über ein WLAN Ad-Hoc Netzwerk, auch mit socat, diesmal halt tcp anstatt RFCOMM.
Ich arbeite bis jetzt mit dem GPSTk, da es eine sehr vernünftige Basis mit vielen Möglichkeiten bietet. Auch der Support ist sehr gut, ich habe dort einen Thread dazu am laufen: http://www.gpstk.org/bin/view/Documenta ... psQuestion
auch dieser hier ist interessant: http://www.gpstk.org/bin/view/Documenta ... maticRover
Das Problem war zuerst, dass GPSTk überwiegend für den Postprocessing Bereich entwickelt wurde. Ich habe deswegen eine Klasse, welche Daten von einem Ashtech Receiver in RINEX umwandelt als Vorbild genommen und für die U-Blox Receiver umgeschrieben. Diese Klasse befüllt jetzt gnssRinex Objekte mit den Rohdaten, so dass eine Echtzeit Anwendung geschrieben werden kann. Es gibt auch viele Beispiele, von denen eines auch einfaches DGPS mit Pseudoranges behandelt. Dieses läuft bei mir jetzt in Echtzeit.
Vor kurzem wurde das example10 hinzugefügt, welches differentielles GPS mit Phasen behandelt. Das Problem ist, dass dort von 2-Frequenz Epmfängern ausgegangen wird. Ich hoffe, dass ich eine solche Lösung auf Einzel-Frequenz umbauen kann.
In den letzten Tagen habe ich mir mal RTKLIB angeschaut. Leider funktioniert rtknavi bei mir nicht, irgendwie meckert er bei mir immer am Wert für "Validation Threshold to Fix Ambiguity", auch beim Standartwert von 3.0. Das führt dann dazu dass ich die Basisstationsposition nicht eintragen kann und das Programm kommt dann zu keiner Lösung.
Gehe ich aber den Weg über die Konsole mit Aufzeichnen der Rohdaten, umwandeln in RINEX und anschliessendes Postprocessing mit rnx2rtkp bekomme ich eine Lösung. Hat jemand eine Lösung für diesen Bug? Ansonsten wollte ich mir in nächster Zeit den Code mal genauer anschauen, wie die das lösen. Leider gibt es ja bisher kein Manual auf Englisch...
Sonst kann ich dir noch empfehlen die Antennen auf ein Stahlblech zu legen. Ich habe ein 25cm * 25cm großes Blech für jede Antenne, das schützt ein wenig vor Multipath und meines Erachtens steigt die Signalstärke auch ein wenig an.
Dann hab ich noch ein paar Links:
[*] Eine sehr interessante Mailingliste zu diesem Thema: http://n2.nabble.com/High-accuracy-posi ... 12818.html
[*] Sehr interessantes Paper zu RTK mit U-Blox: http://www.weblab.dlr.de/rbrt/pdf/ION_07D23.pdf
Da gibt es auch einen time difference Ansatz, der dich interessieren könnte. Habe dazu ansonsten allerdings wenig gefunden.
Ich habe demnächste noch ein Gespräch mit meinem Prof, denn auch wir haben das Thema noch nicht genau ausformuliert und wissen noch nicht genau in welche Richtung es geht. Theoretisch wäre bei mir auch noch eine Sensorfusion mit anderen Sensoren des Roboters, z.B. Odometrie oder Beschleunigungssensor möglich.
) der Basisstation immer mindestens 1,50m über dem freien Gelände positionieren, 2m sind besser. ( Multipath! )
