Das Arduino-Monster (temporäres Projekt, für diverse Tests)

GPS kriegt man genauer - aber (für sich genommen) nur mit stationärem Referenzsignal.
Beide Stationen (mobil + stationär) kann man per BT oder WiFi oder XBee miteinander kommunizieren lassen, und nur die Abweichung zum Referenzstandort wird berechnet.
Positionier-Genauigkeit: bis ca. +/- 2cm!
:sunglasses:

Auch andere Methoden sind denkbar, aber mit extrem hohem Rechenaufwand verbunden, und man braucht dazu am besten feste, bekannte, externe Referenzpunkte (Baken, Wände ect., wobei man durchaus auch GPS u/o Kompassdaten als "externe Referenzen", wenn auch stark verrauscht, behandeln kann):

Sensor-Fusioning mit GPS, Odometrie, Gyro (am besten ntl IMU) , 3D-Accelerometer und Kompass,
dazu stochastische Filter, entweder EKF (Extended Kalman Filter) oder SMC (Sequenzielle Monte Carlo Methoden = Partikelfilter).

Auszug:

Example application

As an example application, consider the problem of determining the precise location of a truck. The truck can be equipped with a GPS unit that provides an estimate of the position within a few meters. The GPS estimate is likely to be noisy; readings 'jump around' rapidly, though always remaining within a few meters of the real position. In addition, since the truck is expected to follow the laws of physics, its position can also be estimated by integrating its velocity over time, determined by keeping track of wheel revolutions and the angle of the steering wheel. This is a technique known as dead reckoning. Typically, dead reckoning will provide a very smooth estimate of the truck's position, but it will drift over time as small errors accumulate.

In this example, the Kalman filter can be thought of as operating in two distinct phases: predict and update. In the prediction phase, the truck's old position will be modified according to the physical laws of motion (the dynamic or "state transition" model) plus any changes produced by the accelerator pedal and steering wheel. Not only will a new position estimate be calculated, but a new covariance will be calculated as well. Perhaps the covariance is proportional to the speed of the truck because we are more uncertain about the accuracy of the dead reckoning estimate at high speeds but very certain about the position when moving slowly. Next, in the update phase, a measurement of the truck's position is taken from the GPS unit. Along with this measurement comes some amount of uncertainty, and its covariance relative to that of the prediction from the previous phase determines how much the new measurement will affect the updated prediction. Ideally, if the dead reckoning estimates tend to drift away from the real position, the GPS measurement should pull the position estimate back towards the real position but not disturb it to the point of becoming rapidly changing and noisy.

Kalman filter - Wikipedia (hier wird auch die Mathematik besser hergeleitet als auf der deutschen Wiki-Seite, wie ich finde).

Wie das professionelle Systeme machen, kann man hier im Anhang erkennen (2 unabhängige Extended Kalman Filter, je nach Beschaffenheit des Untergrunds):

Improvement of Dead Reckoning Accuracy of a Mobile Robot by Slip Detection and Compensation using Multiple Model Approach.pdf (684 KB)

Hm-laut dem "Test im Stand", den ich beschrieben habe, und den ich mehrmals gemacht hab, komme ich auf ne maximale Abweichung von 4m (da ich 2m Entfernung vom Punkt als "da" definiert hatte).
Damit, wenn man den "simplen" Aufbau bedenkt, wäre ich eigentlich zufrieden vorerst. Was solls-TollCollect findet nich mal Autobahnen, und die sind bissel grösser. 8)
Was mich halt stört ist, dass die Daten gewissermassen viel zu spät eintreffen.
Hätte ich den Truck am "Ziel" losfahren lassen, wäre ers- um es dann anschliessend lange zu suchen.

Allerdings hab ich noch einige Optionen:
-die TinyGPS liest wohl nur NMEA-Daten. Angeblich ist aber das Ublox-Protokoll deutlich genauer, die Arducopter-Leute haben ne Bibliothek, die es unterstützt, die schau ich mir mal an
-ich "glaube" (so ganz blick ich da noch nicht durch, die Software ist nicht besonders benutzerfreundlich), mein GPS läuft momentan nur mit 1Hz, kann aber schneller (ne Doku kriegt man beim Chinesen ja nicht dazu), ich werd mal versuchen, das hochzuschrauben

MPU ist eine weitere Option, schon wegen dem unabhängigen Kompass, leider hab ich keine 9er da, mit meiner 6er (gleiche wie im Segway) könnt ich Bewegungen feststellen, aber die Richtung nicht wirklich.
Verbauen wollt ich eh eine, auch noch aus anderen Gründen: damit kann man fein Neigungen detektieren. Und da hier im Gebirge nix grade ist, könnts den einen oder anderen Überschlag vermeiden helfen.

Kalman-Filter sind toll. Benuze ich im Segway ja und war ganz von den Socken, was der aus dem Gerausche des Sensors macht. Aber: ich begreif nicht, wie er funktioniert- das ist ne Stufe zu hoch für mich. :frowning: Und Englisch verstehe ich zwar leidlich, aber Fachenglisch -da hakts auch wieder.

Weiters hab ich nen Problem damit, die Daten, die das GPS ausspuckt, als korrekt (oder eben nich) zu identifizieren. Zwar nutze ich die Optionen "Fix, Fix veraltet, kein Fix" durchaus (Start-und Zielpunkt werden nur dann akzeptiert, wenn ein Fix nicht älter als 2.5s ist, kann ich in der Wohnung sehr schön beobachten, da dauert das speichern des Home`s schonmal zehn Minuten, wenn der Empfang schlecht ist, teilweise muss ich ans Fenster zu), aber offenbar reicht das eben nicht.
Keine Ahnung, wie das gehen soll (nach etlichen Minuten hatte es ja dann den korrekten Standort, es geht also irgendwie...).

Als nächstes steht auf dem Programm: die GPS-Einstellungen im UCenter noch mal genauer anzugucken, möglicherweise gibts dort noch Tuning-Möglichkeiten;
ne Möglichkeit zu finden, einen Kompasskurs zwischen zwei gegebenen Punkten zu errechnen, und zwar vor dem losfahren.
Dann kann ich während der Fahrt nämlich den als zusätzliche Referenz nutzen, und weiss dann obendrein, ob ich rechts, oder links lenken sollte.

das wirst du, wie gesagt, ohne Referenzsystem und/oder ohne stochastische Filter mit sensor fusioning nicht vernünftig hinkriegen - ich arbeite schon seit 8 Jahren mit Navigations- bzw. map-and-explore-Robotern. Dazu die obigen Links!

Soo-gestern hatte ich nicht soo viel Lust (Mathe ist nicht wirklich mein Hobby) aber heut hab ich mich wieder drangesetzt.
Aufgabe: die Kompassrichtung zwischen nem gegebenen Standort und einem Ziel zu ermitteln.
Formeln dafür gibts zu Hauf, aber wenn man die nich kapiert (geb ich zu, das übersteigt meine mathematischen Kenntnisse nen bissel), kommt man damit nicht allzu weit.
Ich habs probiert. Auf mehrere Arten. Die Ergebnisse dabei reichten von Kursen im Berich von -0.0034 Grad bist zu "nan".
Es war nix dabei, was man, mit extrem viel gutem Willen als sowas ähnliches wie "brauchbar, im Prinzip" beschreiben könnte-breiten wir das Mäntelchen des Schweigens drüber. :roll_eyes:

Aber nun sehe ich Licht am Horizont- da drüben leuchtets: http://www.maartenlamers.com/nmea/
Angeblich reicht beim Arduino der Speicher allerdings nicht- der vom MEGA tut es!
Zugegeben: 2K RAM-Verbrauch, nur um den Kompasswinkel zu berechnen ist heftig- aber wenn man 8e hat...
Fakt ist: es läuft (die Lib ist älter, musste also mal wieder an die neuere IDE angepasst werden)- es geht und die Ergebnisse stimmen auch- habs getestet indem ich mir von GoogleMaps nen paar Koordinaten aus jeder Himmelsrichtung besorgt habe und die als Ziel eingegeben.

Nun weiss ich nicht (der Autor selber empfiehlt ja bei wenig Speicher die TinyGps) ob ich entweder den Teil "berechne den Kompasskurs" aus der Lib raushole, und versuche in mein Programm zu implementieren, oder komplett auf diese Lib umsteigen sollte- die kann noch deutlich mehr, sie kann nämlich auch die Entfernung zwischen zwei Punkten berechnen.
Das kann mein Programm zwar auch schon, aber ist schon praktisch, wenns gleich in der Lib. drine ist.
Da werd ich mal bisschen drüber philosophieren jetzt-und dann mal gucken, was ihr dazu meint. :wink:

So. Hab nicht lange philosophiert, sondern bin umgestiegen.
Und zwar auf die TinyGps++, die alle nötigen Funktionen schon enthält.
Musste ich zwar ne ganze Menge umschreiben, aber- es läuft. 8)

Damit hab ich nun eine entschieden bessere Ausgangsbasis fürs Navigieren, und zudem hab ich das Gefühl, dass mit der neuen Bibliothek noch einiges mehr an Genauigkeit rauszuholen sein wird.
Allerdings hab ich da noch nicht wirklich alles untersuchen können-erstmal wars mir wichtig, auf dem Stand von "vorher" zu sein- und jetzt bin ich schon nen Stück weiter, weil die neue Lib. eben auch den Kompasskurs zu nem gegebenen Punkt ausgeben kann.
Das wollt ich ja unbedingt erreichen, weil man so jederzeit, auch nach Umwegen oder Ausweichmanövern, den Kurs sofort neu berechnen kann.

So-letztes Update für heute:
Inzwischen ist die neue Bibliothek nahezu komplett eingebaut: die selbergestrickte Berechnung der Entfernung ist raus- das macht mir nun TinyGps++. Das Ergebnis ist sogar genauer als meines. Auch den Kurswinkel hab ich nun implementiert- jetzt weiss das Auto wirklich, in welche Richtung es fahren muss um den "Zielpunkt" (bei Routennavigation wird das später der nächst anzufahrende Wegpunkt sein, momentan isses einfach der "HomePunkt") zu finden.
Dadurch wird das Auffinden des Zieles viel einfacher: im Grunde braucht nur noch geguckt werden, ob der tatsächlich gefahrene Kurs mit dem Soll-Kurs übereinstimmt, und entsprechend rechts oder links gelenkt zu werden.
Da mach ich dann gar nicht mehr lange rum- das wird gleich auf proportionale Lenkeinschläge umgerechnet.
Toll an der Sache ist: ich habs mittels GoogleMaps überprüft: der Kurswinkel stimmt. :smiley:

Was ich noch nicht so wirklich in Griff habe ist die Funktion fix_age.
Zwar habe ichs geschafft, die Startposition erst dann zu übernehmen, wenn ein Fix vorliegt (mitunter muss ich dazu unters Fenster gehn, sonst dauert es eeeeewig manchmal), aber ich möchte, für später auch wissen, wie alt der letzte Fix ist- um z.B. bei schlechtem Empfang bisschen improvisieren zu können. Dann wird halt beispielsweise einfach erstmal gradeaus gefahren, oder gestoppt-irgend sowas.

Insgesamt muss ich sagen: die tinyGpsPlus-Lib ist entschieden schwieriger zu handlen (wegen nem Tippfehler in der Doku hab ich vorhin mal eben ne halbe Stunde gerätselt, die Erleuchtung brachte dann nen Beispielprogramm) als die tinyGps- kann aber auf jeden Fall viel mehr.
Und mehr Speicher brauchtse auch...

Baue das ganze auch aber auf 1:5

gps.location.age(); und du bekommst die Zeit zum letzten fix

Ja danke-das hab ich dann auch noch rausgefunden.
Ist toll, dass man auch einzelne Parameter auf ihr "Alter" prüfen kann.
Momentan liegen aber andere Probleme an (gestern ist überhaupt nix geworden):
Das GPS ist zu langsam. Angeblich kann es zwar die Daten mit 5Hz liefern, aber ich kriegs einfach nicht eingestellt übers U-Center.
Beim jetztigen Tempo aber ist das Auto schon etwas über Schrittempo schnell-weniger wirds auch nicht, auf ner Wiese z.B. muss ich mehr Gas geben, sonst würgts die Motoren ab- und wenn dann nur alle 2-3s gültige Daten eintreffen, ist das sehr weit ab von "halbwegs genau".
Zwar habe ich bei den MultiWii-Fliegern irgendwo ne "Anleitung" gefunden, wie man die Frequenz erhöhlt, aber die ist für meines komplett unbrauchbar- hätte mir um ein Haar die Firmware abgeschossen.
Und die Einstellung im U-Center kann ich zwar aktivieren, aber übernommen wird sie nicht. :frowning:

Falls ich das nicht in Griff krieg, wird etwas mehr Intelligenz in den Fahralgorithmus rein müssen-so dass eben der Kurs die meiste Zeit interpoliert (bzw, vorausgeschätzt) wird.

So-das GPS hat ne Mac ke.
Mit viel rumbasteln hatte ich es tatsächlich überredet gehabt, etwas schneller zu arbeiten. Das funktionierte dann auch (sogar nach nem Neustert)- bis ich das Teil mehrere Stunden stromlos hatte.
Nun ist wieder alles beim alten-ich habs satt. Sind die Chinesen wirklich zu blöde, sowas nach ner Doku richtig zu bauen oder stellen die sich absichtlich so, damit man eben ne teurere Version kauft??

Egal-dann muss es eben langsamer gehen.
Nach mehreren Tagen Grübelei und ein paar entscheidenden Tipps ausm Roboternetz hab ichs immerhin geschafft, einen Algorithmus zu entwickeln, mit dem das Auto nun, bei Abweichungen vom Sollkurs, entscheiden kann, ob es besser rechts-oder linksrum fährt zur Korrektur.
Interessant ist, dass es da etliche Ansätze gibt, aber keiner wirklich funktioniert....der, der es nun tut, ist von mir ergänzt worden, ich dacht echt die ganze Zeit: das kann soo schwer doch nicht sein..Pustekuchen. So einfach dann auch wieder nich...
Gut- ist erledigt.

Nachdem diese Entscheidung dann gefallen ist, muss ein sinnvoller Lenkalgorithmus her- probeweise hab ich erstmal einfach die Servowege auf die Abweichungen gemappt- das klingt gut, ist aber total hirnrissig, da bei der Lösung ununterbrochen Kreise gefahren würden, die sich -möglicherweise- dann irgendwann dem Ziel nähern.
Das GPS ist halt viel zu lahmarschig, und das Auto viel zu schnell. Es würde so funktionieren (und gäbe eine richtig gute Kursregelung ab) wenn die Daten in Echtzeit verfügbar wären-sindse aber nun mal nicht.
Notiert: wenn ich mir wieder mal ein RC-Auto kaufe, dann nen Crawler. Die kullern mit nem halben Km/h duch die Landschaft- da könnts klappen. Das Monster braucht mindestens 5 km/h, damit es auch leichte Steigungen schafft, auf der Wiese deutlich mehr.

Ich weiß du wolltest am Auto selbst nicht viel ändern aber wäre es nicht erstmal einfacher die Getriebeübersetzung zu verändern und wenn das System läuft versuchen das Monster schrittweise schneller zu machen?

Nein, leider nicht.
Ich würds tun aber das ist bei dieser Reihe von Tamiya schlicht unmöglich. Der Grund ist, dass das gesamte Auto quasi "symmetrisch" aufgebaut ist: die Vorder-und die Hinterachse unterscheiden sich nur darin, dass eine lenken kann-man kann ganz problemlos aus den Standardteilen z.B. eine Allradlenkung nachrüsten, indem man die entsprechenden Teile der Vorderachse hinten auch einbaut. Auch das Chassis besteht aus zwei identischen Teilen-nur ist die linke Seite um 180 Grad gedreht angebaut.
Mit den Getrieben verhält es sich genauso: es sind zwei getrennte, vollkommen gekapselte Getriebe verbaut. Es gibt für das Auto zwei mögliche Untersetzungen-die langsamere hab ich schon drin. Das Konzept ist super-in die Getriebe läuft nicht mal Wasser rein (ich bin als RC-Modell mit dem Ding wirklich schon komplett unter Wasser gefahren, wenn die Reifen mal vollgelaufen sind, geht das)-aber vollkommen Umbau-ungeeignet.
Mehr läuft auf nen kompletten Neubau beider Getriebe hinaus-leider.
Was ich noch tun könnte (und vielleicht zu gegebener Zeit mal mache, aber derzeit gibts das Budget nicht her): langsamere Motoren einbauen. Da gibts den Truckpuller, ein starker, aber langsamer Motor, der mehr zieht, aber nich so rennt wie die Standard-Blechmotoren. Mir wärs recht- es gibt keinerlei Notwendigkeit, dass das Monster mit 20 km/h durch die Gegend brettert und-dem Stromverbrauch täts auch gut. Aber wie gesagt: ich bräucht ja gleich zweie (diese Dualmotor-Angelegenheit hat ihre Vorteile, ich mag es), aber ist zur Zeit einfach nich drin...

Eben hab ich übrigens mal wieder einige Stunden mit meinem Kompassmodul vermurkst-erfolglos. Ich bin nun wirklich sicher, dass es "kaputt" ist-in irgendeiner Form.
Hab mal eben schnell zwei neue geordert, bis dahin hab ich noch was anderes vor:
Ich hatte die Tage den Eindruck, dass die TinyGPS++ noch langsamer ist als das GPS sowieso schon.
Denkbar wärs: die macht nahezu alles mit Fliesskommaberechnungen.
Jetzt hab ich Programmversion 1(die mit TinyGps_ohnePlus) wieder vorgekramt: Entfernungen berechnen hatte ich da ja schon drin, nur den Kurswinkel noch nicht. Aber ich schätze, auch das krieg ich hin- und dann kann ich mal gucken, ob die Sache schneller läuft-ich vermuts.

Nebenbei will ich mal versuchen, die Serial1, die ich fürs GPS ja benutze, auch zu schreiben (bis jetzt hab ich keinen blassen Schimmer, wie ich das anstellen sollte....müsst irgendwie die Daten, die von der Serial0 kommen einfach auf die Serial1 schicken), dann kann ich vielleicht erstens vom U-Center aus die Konfiguration auch ändern und kann das 2. eventuell bei jedem Programmstart ausführen-um dem GPS Beine zu machen. Das Ding kann mit 5Hz arbeiten, das weiss ich inzwischen genau. Nur nach jedem längeren "Stromausfall" fängts wieder mit 1Hz an*grmbl

Soo. Wieder ein Meilenstein (für mich, dem einen oder anderen wirds nur ein müdes Grinsen entlocken) geschafft.
Der Zurück-Umstieg auf die TinyGps (statt der TinyGps++) ist gelungen.
Und-er hat sich gelohnt denn:

-die errechneten Daten (Entfernung, Kurswinkel) treffen sichtbar schneller ein (gemessen hab ichs nicht, aber während die TinyGPS++ für einen Satz Berechnungen (incl. GPS auslesen natürlich) ca. anderthalb Sekunden braucht, schaffe ichs mit der TinyGps und _"selber"gemachten Berechnungen der beiden Parameter in ner Sekunde.
Vermutlich liegt es daran, dass die ++-Version entschieden mehr aus dem Datenstrom fischt und auch gleich sämtliche Berechnungen erledigt oder so. Da ich aber den ganzen Krempel nicht brauche.... :roll_eyes:

  • der RAM-Verbrauch mit der jetztigen Methode ist um ca. 100byte niedriger. Ursache vermutlich dieselbe.

Bin bissel stolz auf mich, weil ich es endlich (das waren insgesamt locker 6-8 Stunden Rätselraten) hinbekommen habe, auch den Kurswinkel richtig zu berechnen.
Und nein: den Rechenweg hab ich nicht selber hingekriegt (dafür reicht mein Mathewissen wirklich nicht aus)- der stammt von da:
http://www.daedalus.ei.tum.de/index.php/de/navigationssysteme/navigation
Ehre wen Ehre gebührt!
Da das so gut lief, hab ich die Entfernungsberechnung auch gleich übernommen- sie ist genauer als meine.

So langsam sehe ich wieder nen hellen Schimmer am Horizont-einmal pro Sekunde frische Daten, das kann klappen!
Als nächstes (sowas mach ich echt lieber wie diese trockenen Mathe-Zaubereien) muss ich nun gefahrenen Kurs und Kurswinkel logisch aufs Fahrverhalten aufdröseln, ich werd da etwas Unschärfe reinmontieren (es gibt keinen sinnvollen Grund, wegen nem Grad Kursabweichung wild zu lenken, je näher das Ziel kommt, umso grösser wird die Abweichung ja sowieso), und dann könnte mal wieder ne Testfahrt anstehen.

Hallo,
Einstellung im U-Center kann ich zwar aktivieren"

Sprechen wir hier von ublox AG?
Wenn ja, dann wirst Du nur eine freie Demo des Programm haben. Das kann ein
wenig etwas anzeigen- das ist aber auch schon alles.
Wenn Deine Empfänger ein ublox-Empfänger ist, dann besorge Dir einmal die
Unterlagen dafür. Das Ding läßt sich einfach über seriell steuern.
Wie gesagt, nur wenn es von ublox ist.
Gruß und Spaß
Andreas

Ich hab im U-Center (v8.11) nix gefunden, was drauf hindeutet, dass es eine Demo wäre....und hab auch noch nie von ner anderen "besseren" Version gehört. Allerdings würd es manches erklären (es kann durchaus mehr als nur anzeigen).
Hast du da mal nen Link zu?

Und ja: man kann. Mein Problem ist, dass ich bisher mit den seriellen Schnittstellen kaum was gemacht habe, ausser mal nen paar Daten auf den Rechner zu schicken.
Werd mich damit wohl mal auseinander setzen müssen....

Vorhin hab ich mal einen seeehr üblen Bug gefixt:
Servo"zucken".
Ich habs in Griff, dass je nach Kursabweichung gelenkt wird. Allerdings zuckte die Lenkung immer nur kurz in die entsprechende Richtung. Hat mich locker ne Stunde gekostet, den Fehler zu finden. Ursache war meine "Cleverness":

Ich hab einen Timer drin. Der läuft immer so ne halbe Minute, dann ändert er eine Variable und ruft ne Funktion auf, die "schalteServosAnAus" heisst-und genau das auch macht.
Bekommt diese Funktion ne 1 übermittelt, werden Fahrtregler und Lenkservo "attached", kommt ne Null, werden sie "detached". Somit stoppt das Auto alle halbe Minute von alleine, ich geh hin, drücke den JoyButton und weiter gehts.
ABER: ich cleveres Kerlchen hab bei "attach" auch gleich mal "Grundeinstellungen" mit programmiert gehabt und zwar soo dämlich, dass bei jedem Aufruf der Funktion das Len kservo gradeaus gestellt wurde.
Alle paar Millisekunden also...so ging das nicht, es ist behoben und ich selig....
Falls das Wetter es hergibt, gibts morgen wieder ne Probefahrt draussen-dieses mal nach Kurswinkel statt nur nach Entfernung.

Hallo,
ich habe das vor 100 Jahren gemacht.
Ich bin mal auf der ublox-Seite gewesen. Da hat sich ja einiges geändert.
In den Beschreibungen steht nicht mehr von "eingeschränkt"
Sei aber versichert, das es so ist. Diese Software gabe es auch für Handheld
Computer. Ich habe die für ein OEM GPS 25-LVS genutzt. Du konntest dort sehr
viel einstellen, aber der Empfänger hat es nicht empfangen.
Die "Vollversion" konnte man damals kaufen. Ich habe das dann aber alles seriell
gemacht. Die Software hat diese Änderungen dann auch angezeigt.
Es gab auch einmal ein Handbuch Handbuch dazu:
Grundlagen der Satellitennavigation. Das bieten sie auch nicht mehr an.
Da stand genau beschrieben wie man Parameter ändert und was für Auswirkungen
das hatte. Dort wurde auch erklärt, wie man mit 2 von den Dinger
(+ Referenzpunkt) auf 1 bis 2cm genau die Position feststellen konnte.
Die beiden Empfänger habe ich eben "ausgebuddelt" Das Handbuch habe ich auch
noch. Wenn ich es in den Tiefen meiner Sicherheit-Kopien finde, dann sende
ich Dir es einmal zu. Ich müßte auch noch eine gewaltige Menge an Software
dazu haben.

Wenn Du es auf Deiner Rennbahn "genauer" haben möchtest, dann suche auf dem
Grundstück oder dem Gehweg mal einen "Messpunkt" Das sind kleine Runde
"Plättchen" aus weißen PVC oder aus Bronze.
Schreibe Dir genau auf, wo diese Plättchen sich befindet.
(22 Schritte von Kreuzung, 4 Schritte von Einfahrt u.s.w.)
Dann fährst Du PERSÖNLICH zu Deinem Katasteramt und fragst Dich da durch, wer
Dir etwas zu diesem Messpunkt sagen kann. Wenn Du den Typen gefunden hast,
dann bittest Du ihn höflich um die genaue Position Deines Plättchen.
Wenn er dann den PC anwirft…
Dann besorgst Du Dir zwei die gleiche GPS-Empfänger- und dann kannst Du auf
einige cm "genau" bei Dir rumkurven.

Und wenn Du einen Kurs festlegen willst, dann mache das mit ein wenig Dreieck-
und nicht mit einer geheimnisvollen Lib.
Ich bin mit einem Peilkompass und einem Bleistift mit Taschenrechner, genauer
als Du mit Deinem GPS.
Gruß und Spaß
Andreas
Mit dem Empfänger komme ich auf 3m
https://www.gpscentral.ca/products/garmin/25.htm

Der hat auch das Buch von "oben" geschrieben.
Schaue einmal unter "Publications" eine ware Fundgrube diese Seite

"GPS kriegt man genauer - aber (für sich genommen) nur mit stationärem Referenzsignal.
Beide Stationen (mobil + stationär) kann man per BT oder WiFi oder XBee miteinander kommunizieren lassen, und nur die Abweichung zum Referenzstandort wird berechnet.
Positionier-Genauigkeit: bis ca. +/- 2cm! "

HaWe hat es ja schon angesprochen- ich weiß nicht wie das heute ist. So ein ReferenzSignal wurde in der BRD vor hundert Jahren mal
von verschiedenen Referenzpunkten gesendet. Dieses Signal konnte man mit einem Scanner empfangen und im Schlepptop
weiter verarbeiten.

2m Genauigkeit reichen.
Das Neo 6m kann laut Ublox alleine (mit Sbas-Signal) unter nem Meter- wenns denn entsprechend eingestellt ist.
Also brauch ich da keinerlei Zaubereien ringsherum, denn soo präzise auf den Punkt kann das Monster eh nicht fahren ohne aufwendige Rangiermanöver (ich hatte seinerzeit im RC-Betrieb schon nen Gyro auf der Lenkung, um bei voller Geschwindigkeit im Gelände meterbreite Tore überhaupt zu treffen).

Ich krieg die Einstellungen ja auch hin-nur werden die leider nicht dauerhaft gespeichert, sondern sind nach längerem "Stromausfall" wieder zurückgesetzt...
Das würde ich gerne umschiffen, indem ich zu Serial1 bei jedem Start die entsprechenden Settings schicke-schon wärs gut.
Nur wie das geht.... :~

Es gibt ein Programm für (für Arduino und Ublox) aber da raff ich noch nicht mal die Hälfte..
Wahrscheinlich geht es auch über das U-Center, aber mein "Programm" mit dem ich das GPS übern Arduino auslese, kann von Serial1 nur lesen-und ich trau mir ans schreiben nicht so richtig ran, ohne zu wissen, was ich denn da tu.

void setup()
{
  Serial.begin(115200); 
  Serial1.begin(9600);
}

void loop()
{
  if (Serial1.available())  Serial.write(Serial1.read());
}

Was die Berechnungen angeht: hättste alles die letzten Tage gelesen, wüsstest du, dass ich aus der Lib nur noch die aktuellen GPS-Daten (Kurs, Position, Geschwindigkeit) hole-und den Rest selber mache. 8)
Die GPS++ kann das auch-ebenso genau, aber eben langsamer und mit mehr RAM-Verbrauch.

Hallo,
"Ich krieg die Einstellungen ja auch hin-nur werden die leider nicht dauerhaft gespeichert,"
"Nur wie das geht…."
"Das GPS ist halt viel zu lahmarschig"

Ich glaube Du hast ein richtiges Problem mit Deinem GPS-"Empfänger"
Versuche doch einmal heraus zu bekommen, was die genau für eine Empfänger
nutzen. Wenn der nur halbwegs etwas taugt, dann sollte der über eine serielle
Schnittstelle zu programmieren sein, wenn der keinen nichtflüchtigen Speicher
hat, dann sollte sich eine StützBatterie (CRxxxx) anschließen lassen.
Auch sollte der in der Lage sein Rohdaten liefern zu können. NMEA hört sich
immer gut an, fragt sich nur, was Dein Empfänger für Daten liefert.

Also, besorge Dir einmal Unterlagen und Datenblätter dafür, dann weißt Du auf
alle Fälle schon einmal, was das Ding macht- und kann.

Ich komme mit meinem Empfänger auf 3m, das zweifel ich aber stark an. DU
schreibst sogar 2m. Ich kann mir nicht vorstellen, das die Ami´s ein so
genaues Signal zur Verfügung stellen.
Die Ami´s gaben an, das bei 95% der Messungen der horizontale Fehler kleiner
als 7,4m und der vertikale Fehler kleiner als 9m war. Bei einer Messung über
24h!

Nur ein Beispiel: Galileo soll eine Genauigkeit von < 1m erreichen können,
das funktioniert aber nur über eine Zweitfrequenz. Und dafür zahlst Du.
Gruß und Spaß
Andreas
P.S. ich muß da selber mal mit spielen, ist das die TinyGPS Library die Du nutzt?
https://www.pjrc.com/teensy/td_libs_TinyGPS.html

Ich glaub, du vergleichst hier irgendwelche Uralt-Modelle (sagtest du vor 100 Jahren?? :wink: ) mit halbwegs modernen Geräten.
Kenne inzwischen die Beschreibung, Datenblatt usw. schon zur Hälfte auswendig.
Und: diese Genauigkeit ist beim Neo 6 (so eins hab ich) durchaus möglich, weil zusätzlich zu den GPS-Daten, eben auch das SBAS mit genutzt werden kann, HDOP und PDOP werden berücksichtigt, und weiteres. Zudem hat das Ding ne Art INS drin-auch das kann man konfigurieren. Wahrscheinlich wird da noch weiter gefiltert, vermittelt-wasweiss ich.
Ich glaub das dem Hersteller also einfach mal...
Fakt ist: dass es so gut funktionieren kann ist bewiesen-ich hab da mehrere Referenzen zu gefunden, wo Fahrzeuge mit deutlich weniger als 2m Abweichung brav um Punkte rumgekurvt sind. Ohne weiteres Zubehör...es geht also.

An dem Ding gibts massenhaft Konfigurationsmöglichkeiten, und: ich bekomme es ja auch hin, damit nämlich: Arduino Playground - GPS
Pufferbatterie ist drauf-diese Einstellungen bleiben eine Weile auch ohne Strom erhalten. Aber eben nicht dauerhaft (vermutlich ist der Knopfakku dann einfach leer).

Und: ich könnte durchaus damit leben, nur einmal pro Sekunde aktuelle daten zu haben (könnt die Zwischenzeiten ja interpolieren) aber warum-wenns das GPS eh drauf hat.

Momentan aber hab ich ein anderes Problem-da es allgemeinerer Natur ist, frag ich da aber mal extra.

Hallo,
"unter nem Meter- wenns denn entsprechend eingestellt ist"
und den Rest wußte ich wohl nicht.
Schon interessant, wie genau man heute "doch" schon mit dem GPS-Signal arbeiten kann.
Gruß und Dank
Andreas

Hallo,
nach dem Neo 6m/t bin ich ja ein wenig gierig geworden. Verwendest Du den
nach diesem Schaltbild?
http://www.uctronics.com/ebayproductpic/GYGPS6MV1_SCH.jpg
der hat ein EEprom auf dem Board, kannst Du da nicht Deine Einstellungen speichern?

Gruß und Dank
Andreas