Genug des Overheads, ad substantiam:
Meine Idee vom Grundaufbau ist geblieben, vor allem nach hannes's Erfolgsberichten aus Österreich.
Internet-IP-Technologie als etablierte, flexible Kommunikationslinie.
ntrip-caster auf dem 1und1 virtual root server mit fester IP-Adresse als Sternpunkt.
Der Rest des Datenmanagements sollte eigentlich lt. Doku mit ggf kaskadierbaren rtklib-strsrv-Instanzen zu schaffen sein.
Evtl. würde ich
zwei Basisstationen an meinen beiden 7 km entfernten Betriebsstandorten montieren, wenn der Einzelpreis im Rahmen bleibt.
Und / oder eine "
mobile Tagesbasis" am Feldrand.
Das sollte die Basislänge verkürzen (< 1 km). Die kann über die permanente Basis schön gemütlich sich statisch präzise verorten.
Evtl. kann man da auch den Internetzugang einrichten und per wlan an den Rover übertragen, um das Problem von Empfangslöchern zu minimieren.
Was die
Module betrifft, ist mein aktueller Stand dieser:
http://michelebavaro.blogspot.de/2012/0 ... nd-up.html
the S1315F-RAW has 20Hz raw measurements update rate, which is still unmatched performance by other low-cost receivers
the uBlox NEO-6P has integrated PPP for high accuracy standalone mode, no other low-cost receivers claims that
the NVS NV08C-CSM has Glonass!
Für die Basisstation(en) wären es somit wohl die uBlox-Module.
Für den Rover überlege ich, jeweils einen S1315F-RAW und einen NVS NV08C-CSM auf dem Traktor und auf dem Anbaugerät einzusetzen.
Der S1315F-RAW bringt die geforderte hohe Auflösung längs der Fahrstrecke.
Der NVS NV08C-CSM bringt
robustere Fixes durch die mit Glonass größere Satellitenanzahl.
Zwei Empfänger pro Fahrzeug brauche ich ohnehin zum Ermitteln der Gierung (Drehung um die vertikale Achse), vor allem bei der Abdrift am Seitenhang oder in Furchen.
Rollen und Kippen würde ich über
Trägheitssensoren ermitteln, dazu evtl einen
Kreisel.
Ich denke, diese Sensoren gibt es aus dem Flugmodellbau für mittlere zweistellige €uros. Hat jemand Erfahrung damit?
Alles zusammen ergit hoffentlich genügend
Redundanz, um damit das Problem mit den Phasensprüngen weitgend in den Griff zu kriegen:
4 GPS-Empfänger auf dem Rover
1 bis 3 Basisstationen
je 1 bis 2 Beschleunigungs- und Drehsensoren
evtl. eine Geschwindigkeitsmessung vom Traktorrad
Ein Phasensprung würde imho nur dann unauffällig detektiert, wenn gleichzeitig
- alle 4 Rover-Empfänger gleichzeitig einen solchen melden
- der Zug mit allen 4 bis 6 Rädern gleichzeitig in ein entsprechend tiefes (20 cm?) Loch fällt
- der Beschleunigungssensor ausfällt und das Fallen nicht mitkriegt
Oder bin ich da mathematisch-statistisch zu optimistisch?
Womit wir wieder bei den
Filtern wären.
Kalman?
Hab' ich derzeit nur hochgefährliches Viertel-Wissen.
Kann jemand ein
gutes Tutorial empfehlen?
Wie würde man das konfigurieren?
- Erst mal jeden Empfänger (bzw die ihm zugeordnete rtklib-Instanz) sein eigenes Tracking-Süppchen kochen lassen und dann die Ergebnisse samt der weiteren Sensoren in einem extra Modell zusammen führen? So habe ich es beim RTFM irgendwo für die Tunnelüberbrückung der PKW-Navis gelesen.
- Oder die Daten der Sensoren und der anderen Empfänger zrück in die jeweilige rtklib-Instanz führen (ich nehme mal ann, daß bei Rohdatenverarbeitung im Modul nichts nenneswertes mehr gerechnet wird). Erlaubt das die rtklib (sorry, stecke in der Hälfte des Manuals)?
- Oder eine einzige Filter-Instanz, die sowohl alle Rohdaten als auch die anderen Sensorsignale in einem Aufwasch verarbeitet. Aus halbwissenden stochastischen Überlegungen heraus würde ich das bevorzugen. Aber ist die rtklib da noch flexibel genug? Oder macht man da ein komplett neues Fass auf?
Wo kriegt man Erfahrung zu dieser Frage her?
Von den Flugmodellbauern? Von den Tunnelnavigatoren?
Ist es schon an der Zeit, Meister Takasu höchstselbst damit zu behelligen?
Und wenn wir schon bei der Software sind:
Was kann man für das
User-Interface übernehmen?
Ich brauche wohl einen kleinen Panel-PC für Meldungen und Bedienung.
Vermutlich sollte der auch
Karten mit Parallellinien/alten Tracks anzeigen und für einfache Anforderungen / frühe Testphasen ein
optisches Lenksignal für den Fahrer anzeigen. Derzeit habe ich meine Flurkarten in qgis, mit shape-files und gpx-tracks. Teilweise habe ich schon Teilflächenplanung über dxf mit qcad ausgetauscht. Nervig, aber geht. Man kann die Planung ja vorher im Büro erledigen. Meinetwegen sogar als image abspeichern. Vielleicht reicht dann ein einfacher
map-viewer fürs erste schon aus?
Ein ganz wichtiger Punkt scheint mir die
Antenne zu sein. Das beste ist da wohl kaum gut genug.
Hannes' Navxperience 3G-C steht grad für schlappe 1500 in der Bucht. Das wäre für eine Basis tolerabel, meintewegen auch für einen der 4 mobilen Empfänger. Aber 4 x 1500 = 6000 ... das wird schon heftig (wobei es daran noch nicht scheitern würde, wenn es der einzige große Kostenblock wäre).
Gibt es eine preiswertere Alternative?
Zephyr?
Gut gefallen hat mir auch der
Eigenbau-Choke-Ring von Josef Gerstenberg:
http://www.kowoma.de/gpsforum/viewtopic ... 231#p14238
Baut das schon jemand in Kleinserie? Würde jemand das kaufen, wenn ich eine solche auflege?
Was packt man am besten in's Auge?
Eine Tallysmann TW3400 für 100 €?
Oder gleich den kompletten NL-507-ETTL?
Ich würde den Choke Ring zum Schutz gegen Verdrecken in einen KG-Kanal-Deckel einbauen, aber die Antenne mit ihrem eigenen Gehäuse durch ein Loch (Silikonabdichtung) raus ragen lassen.
Das sollte nach meiner kindlichen Vorstellung die Problematik der Beeinflussung der Antenne durch die Abdeckung umgehen.
Hoffe ich. Der Choke Ring selbst soll lt Josef Gerstenberg ja in der Auslegung unkritisch sein.
Wie kann man sowas messtechnisch erfassen?
Reicht der Werkzeugkasten der rtklib dafür aus?
Fragen über Fragen... wie recht Hannes doch hat