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

[Rabenauge]

Nen (leicht aufgerüsteten) NiboBee hab ich da, schick mit Holzgehäuse. 8)

Das mit dem Maussensor lässt mir jetzt keine Ruhe-hab da was gefunden. Wenn ich wüsst, dass es jemanden ersnthaft interessiert, würd ich dazu mal nen extra Tread aufmachen.

Die Anwendungen dafür sind vielfältig, sie reichen von ner präzisen Wegmessung (dürft besser als mit Radencodern z.B. sein, da dort Schlupf usw. problematisch ist) bis hin zu ner -sehr simplen- Objekterkennung.
Aber oftmals reicht eine sehr niedrige Auflösung aus (z.B. um ein farbig markiertes Ziel zu finden, einer Linie zu folgen oder ähnliches), Roboterfussball (Ball erkennen, Tore erkennen, Begrenzungen erkennen)- dort ist weniger sowieso mehr.
Ich hab ne olle Logimaus hier- werd damit mal rumspielen.
Soll ich hier oder in nem Extra-Tread, was meint ihr?

[Rabenauge]

So. Hab mal mit der alten Logimaus ein bisschen Grundlagenforschung betrieben: das Ding auslesen, ist kinderleicht, braucht nur lausige zwei Leitungen....
Schwieriger ist es, die Optik auf ne vernünftige Reichweite umzubauen, fürchte ich.
Hab da auch grad nicht soo viel da für, mein alter Fernrohrbaukasten existiert schon 20 Jahre nicht mehr-schade.
Aber das Thema ist zu interessant, um es nicht noch weiter zu verfolgen....

Inzwischen aber werd ich mal wieder was am Monster machen, mit dem, was bereits verbaut ist.

[Rabenauge]

Sodele.
Die Software ist noch arg überarbeitungsbedürftig (sie funktioniert soweit, im Prinzip ja schon irgendwie...), da geht noch was.
Aufm Wäschenboden Runden drehen klappt leidlich, aber das isses ja nich...das kann jedes Spielzeugauto auch.

Es gibt aber, viel spannendere Neuigkeiten: heut gabs Post. Meine Brieftaube war da und hat das GPS hier abgeworfen.
Natürlich war das Ding ne halbe Stunde später auf dem Monster aufgesessen, ein kleines Probeprogrämmchen auf den Dino gespielt (ich verwend derzeit die SoftSerial, weils mitm Uno nich anders geht), und die Ublox-Software hat tatsächlich rausgefunden, wo ich wohne. Toll-jetzt weiss die NSA auch das.
Zwar musste ich das Monster mal aufs Fensterbrett stellen, damit ich nen Fix hatte aber nun isser da- die Genauigkeit hat meine Erwartungen echt übertroffen- keine 2m neben dem Fenster.
Das Ublox scheint gut zu sein....

Langsam wird es allerdings mit dem Uno nun wirklich eng- es sind jetzt alle Pins belegt. Da ich später auf jeden Fall nen Datenträger brauche, überlege ich, auf nen Mega zu wechseln, damit ich die SPI nutzen kann (für ne SD-Karte, ich möchte auf der später GPS-Wegpunkte ablegen können). Alternativ nen I2C-EEPROM-Baustein, aber das find ich unhandlich..

[Rabenauge]

So-der Uno ist runter.
Weiter als bis dahin wäre ich damit nicht mehr gekommen und die SoftSerial ist-naja. Lahmarschig und unzuverlässig.
Jetzt ist auf dem Mega umgerüstet-die UnoPins hätten eh nicht gereicht, und alles ist besser, schöner und so. 8)

Hat seine Vorteile, obwohls ne ziemliche Arbeit war (ich hab ja den Chinesen-Uno, der die hübschen Steckerleisten hat, und musste nun alles auf Stifte umbauen), z.B. kann ich nun die vier US-Sensoren wieder vernünftig ansteuern, jeden mit nem eigenen Triggerpin, und die SPI ist trotzdem noch frei (da kommt noch ne SD dran), und die zweite Serielle Schnittstelle des Mega funktioniert hervorragend.

Von dem Ublox bin ich echt begeistert- hab jetzt ne halbe Stunde einfach mal geguckt, was das Ding so treibt. Okok-angeblich spaziere ich auf dem Dach herum, und bin ein, zweimal wohl auch runtergefallen, aber im Schnitt ist die Genauigkeit selbst hier drinnen wirklich gut, wenn man bedenkt, was das Ding kostet!

Ich war sogar in Versuchung, das kleine Display gegen nen TFT zu tauschen, um da nen Teil der Navi-Daten mal schick grafisch auszugeben, habs aber gelassen-der Speicherverbrauch ist auch aufm Mega nicht ganz ohne dann. Und da ich noch immer so Geschichten wie den A* als Wegfindung im Hinterkopf hab (zu gegebener Zeit darf er weiter vor kommen), werd ich noch jedes Byte Speicher brauchen, was zu kriegen ist.
Und: wir wissen ja vom Seeteufel, was diese billigen TFT`s im Freien taugen... 8)
Werd aber mal gucken, ob von dem defekten der SD-Slot noch funktioniert, dann kommt der nämlich drauf-nen losen hab ich nicht. Da das Display vorne dran sowieso hin ist...

Jetzt werd ich aber erstmal gucken, was man mit der TinyGPS so anfangen kann-oder gibts was besseres?

[Rabenauge]

Heute kam nun die -möglicherweise letzte- Komponente noch an Bord: ein Laufwerk.
Eigentlich der Rest meines mal versehentlich geschrotteten TFT`s- da klebte ja hinten noch ein SD-Karten-Slot dran, und-der funktioniert auch noch. Wozu also wegwerfen...das TFT kurzerhand runtergemeisselt, nen Brettchen mit Heisskleber drunter (zum bequemen anschrauben), Kabelbündel dran und-geht. 8)
Test hat das Ding auch bestanden, Dateien lesen und schreiben funktioniert, gut.

Ausserdem hab ich neulich ne Kleinigkeit umgebaut: bis dahin wurden die Servos auch aus dem Stepdown-Wandler versorgt (genauso wie alles andere ausser dem Dino selber auch)- jetzt hängen die Servos (Lenkservo und das für den Hecksensor) am Regler-BEC.
Vorteil: das Lenkservo zieht nun wieder ordentlich durch-offenbar braucht es im Stand doch bissel mehr Strom-naja.
Während der Fahrt war es kein Problem, aber wenn das BEC schonmal da ist, wieso nicht auch benutzen.
Der Stepdown ist nun für fast alles andere zuständig: GPS, Joystick, sämtliche Sensoren, SD-Slot, Display.
Nur der MEGA hängt direkt am Akku, das ist mir nix, den mit 5V zu füttern, so wie jetzt kann ich sorglos das USB-Kabel an-oder abstecken, auch wenn das Fahrzeug an ist.

Wo ich den Regler grad erwähne: der nervt. Da er immer wieder rumzickte, hab ich ihn (mit nem extra dafür geschriebenen Programm) mal neu eingelernt- auch davon wurds nich besser:
Es ist gar kein Problem, aus "voller" (in Wirklichkeit ist die im Handbetrieb enorm gedrosselt) Fahrt rückwärts sofort auf volle Fahrt vorwärts zu schalten-das wird prompt erledigt.
Umgedreht aber hab ichs noch mal gründlich getestet:
Wenn ich vorher NICHT vorwärts gefahren bin, klappt rückwärtsfahren sofort.
Bin ich aber vorwärts gefahren, muss ich rückwärts mindestens ganz kurz (nicht länger als 2s, ansonsten schmiert der Dino ab) geben, dann ca. 5s warten und nun kann ich auch rückwärts fahren.
Schon irgendwie dämlich- der Dino scheint in dem Moment abzuschmieren, wo der Regler von "bremsen" auf "rückwärts" umschaltet.
Wird lustig, das der Software klarzumachen...
Leider bin ich mir recht sicher (messen kann ichs nicht, mein Hobbystrommessemeter geht nur bis 10A), dass die beiden 540er Motoren unter Vollast schon mehr als 15A ziehen, sonst würd ich ne Motorplatine, wie im Segway einbauen und der Zirkus wär vom Tisch, aber beim vollen Beschleunigen geht der Akku dermassen in die Knie, dass ich mir sicher bin: da geht bissel mehr Strom durch die Leitungen.

Nun müssen erstmal eine ganze Reihe Bugs, die teils durch den Umbau, teils auch durch den Schlaumeier, ders programmiert hat, noch behoben werden:
-das GPS zeigt auch dann nen aktuellen Fix im Display, wenn es gar keinen hat (veraltete zeigts dagegen korrekt, ebenso wie aktuelle)
-die Sonarsensoren müssen gestaffelter abgefragt werden, teilweise scheinen sie Echos von anderen zu empfangen
-die Fahrsteuerung muss auf die Hirnrissigkeit-ähm-die Besonderheiten dieses Reglers angepasst werden
-irgendwas haut mit der automatischen Abschaltung der Motoren nach ner Minute nicht hin, im manuellen Modus klappts, im autonomen nicht

Nebenbei werd ich mir mal überlegen, ob ich eigentlich überhaupt noch nen zusätzlichen Kompass verbauen will (es wär zwar praktisch, da das GPS zwar den Kompasskurs errechnen kann, aber erst nach dem losfahren, es würde also immer erstmal nen Stück gefahren und dann "gucken wir mal, wohin wir eigentlich fahren")- hätte schon Vorteile, aber nach meinen Erfahrungen mit dem HMC588l bin ich da so bissel von geheilt erstmal, vermutlich hat meiner einfach nen Treffer), und was sonst noch so drauf soll.
Nen Neigungsmesser würd ich schon gerne verbauen, um z.B. eine Geradeausfahr-Regelung auch in unebenem Gelände zu haben (ich hatte mal ne Weile, als ich das Auto noch artgerecht per RC gefahren hab, einen normalen Gyro auf dem Lenkservo, damit fuhr die Kiste selbst im schweren Gelände wie auf Schienen), und auch, um Umkippen zu vermeiden, oder gefährliche Neigungen halt erkennen zu können.

Ausserdem hab ich noch keine richtige Idee, wie ich mir auf der SD-Karte "Routen" so anlegen kann, dass der Dino daraus GPS-Punkte entnehmen kann, die er dann mal abfahren soll.
Das wird noch ne richtig spannende Geschichte.

[Rabenauge]

Sodele. Ein bisschen weiter bin ich immerhin.
Eine ganze Handvoll Bugs sind gefunden und erschlagen. Alle bestimmt noch nicht-hatte aucgh gestern gar keine Zeit und heut noch nicht viel...

Nebenbei hab ich mich mal etwas in die Speicherkarten-Sache angefangen, einzuarbeiten. Das hab ich bisher immer so bissel vor mir hergeschoben, weil ichs nicht so wirklich brauchte.
Inzwischen schaffe ich es schonmal, bzufragen ob ne Karte verfügbar ist, ob sie eine bestimmte Datei enthält, und ob in der auch "gültige" Daten sind.
Spielerei, aber mir gings vor allem darum, dass ich ZAHLEN von der Karte so auslesen kann, dass ich nachher damit auch rechnen kann im Programm. Um das zu testen hab ich einfach mal eine bestimmte Datei angelegt, die nix weiter als nen paar Zahlen enthält, und später als "Autoschlüssel" dienen kann.
Nur wenn die Karte, die richtige Datei UND der richtige "Code" in dieser Datei vorhanden sind, startet der Roboter überhaupt.
Funktioniert...nehm ich die Karte raus, startet das Auto gar nich erst und wenn sie nicht wirklich die passende Datei (und in der den Code) enthält, ebenso wenig.
Ist, wie ich zugeb, relativ unnötig, aber ich wollte eben mal sehen, ob ich richtig Zahlen auch eingelesen bekomme- in den Beispielen zur SD wird ja immer nur mit Strings rumgewirtschaftet, das nutzt mir später gar nix.
Da das soweit klappt, kann ich nun dem Monster beibringen, GPS-Koordinaten sowohl von der Karte zu lesen, als auch rauf zu schreiben (letzteres möcht ich dann evtl. fürs Logging nutzen, oder um vorgegebene Routen zu optimieren).

[Rabenauge]

Und sc hon wieder Neues (interessierts überhaupt jemanden?):

Ich hab mal angefangen, Vorbereitungen für eine return-to-home-Funktion zu treffen.

Im Startmenü (wo ich z.B. auch zwischen autonomen und manuellen Betrieb umschalten kann) fragt das Monster, ob der aktuelle Standort als "home" gelten soll (das ist nötig, weils ja sein kann, ich bin mal wo anders als zu Hause damit, aber eben auch die Möglichkeit besteht, dass eine längere Strecke in Etappen gefahren werden soll), und falls ich das bestätige, wird gewartet, bis das GPS nen aktuellen Fix hat, und dann die Koordinaten auf die SD-Karte geschrieben.
Theoretisch findet der Truck sich also dann allein zurück zum Startpunkt, jedenfalls, so lange der Aku reicht(oder eben zwischendurch gewechselt wird, da die Daten auf der SD-Karte ja bleiben).
Bild mir schon was drauf ein, das hinbekommen zu haben.... 8) Irgendwie wächst man doch mit seinen Aufgaben, ich glaub, die SD-Geschichte hab ich schon ganz gut in Griff.

Nun wird es spannend: als nächstes sollen in einer Datei "beliebig viele" Wegpunkte angelegt werden (die hol ich mir z.B. aus Google Maps), und dann soll das Monster diese Route abfahren, und ggf. wieder zum Anfang zurückkehren.
Mal sehen, was das geben wird, bin schon selber gespannt. Noch weiss ich nicht mal genau, was ich da für ein Dateiformat verwenden soll (bzw. wie ich die Daten, so simpel lesbar wie möglich, auf die Karte schreiben soll).
Interessant wird dabei vor allem die Tatsache, dass nicht vorher bekannt ist, wieviele Wegpunkte es gibt...das richtet sich schliesslich immer nach dem konkreten Erfordernis (ich möchte lieber mehr, als weniger haben, um präzisere Kurse zu fahren, statt dauernd querfeldein).

[Rabenauge]

Hm, auch wenn es offenbar keinen so recht interessiert:
Ich bin weiter.

Jetzt gibt es schon beinahe den ersten richtigen GPS-Fahrmodus. Beinahe deshalb, weil er noch nicht fährt-aber das schaffe ich evtl. morgen noch.
Im Moment kann der Truck: sein "zuhause" auf Knopfdruck auf der SD-Karte speichern (nur auf Knopfdruck deshalb, damit man auch ein "altes" behalten kann).
Im Betriebsmodus, den ich GPS2Home nenne, läuft das dann so ab:
Es wird der "Home"-Punkt von der Karte eingelesen.
Nun wird der aktuelle Standort per GPS ermittelt, und die Entfernung zwischen den beiden Punkten-als Luftlinie natürlich, Google Maps werd ich nicht implementieren deswegen.. 8)
Der Teil, der nun folgt, muss noch programmiert werden:
Jetzt soll das Monster eine kleine Runde fahren (das ist nötig, um nen paar verschiedene GPS-Daten zu bekommen, weil nur dann die Kompassfunktion des GPS auch funktioniert), und sich dann auf den Weg machen zum "Home".
Da es keine Festlegung gibt, wie weit die beiden Punkte auseinander sein dürfen, kann dieser Modus später ganz nach Belieben aufgebohrt werden. Man braucht sich ja nur nen "Zielpunkt" suchen, den abspeichern, mit dem Monster wo anders hin gehen, und es laufen lassen. Schwierigkeitsgrad: beliebig, wenn man die Umwelt-Sensoren mit benutzt.
Die jetzt noch einzupflegen, schaff ich heute und morgen allerdings nicht, daher wird das wohl auf irgendeinem freien Parkplatz getestet, wo genug Platz ringsum ist.

Es gab, bis hierhin, einige Tücken. Z.B. benutze ich nicht die float-Funktionen der TinyGps, sondern arbeite mit Ganzzahligen (um die Entfernung zu berechnen, komm ich allerdings dann nicht ohne floats aus, aber die haben ne kurze Lebensdauer, da sie das Unterprogramm nie verlassen). Dadurch bekomme ich die Entfernung auf Millimeter-mit 10-15 Nachkommastellen. 8)
Unnütz- auch das Ziel wird noch bissel gerundet, wenn ich es schaffe, auf nen Meter ranzukommen, bin ich volkommen selig.
Und: allzu genau ist es nicht, da ich die Entfernungen lediglich nach dem Phytagoras-Satz berechne (hab ne bessere Formal da, find die aber vorerst unnötig)-> im Nahbereich wird das allemal ausreichen.
Zudem verwechsele ich andauernd lat und lon-auch das gibt dann -interessante-Ergebnisse (die heissen in meinem Programm nämlich Laenge und Breite).

[Rabenauge]

Sooo. Heute war mein Monstertruck das erste mal draussen "alleine" unterwegs- die Aufgabe war, per GPS zu nem vorher festgelegten Punkt zu finden.

Das Ergebnis war- eigentlich- jämmerlich: es hat einmal wirklich geklappt-dabei wurd das "Ziel" um ziemlich genau 5m verfehlt. Allerdings hab ich die Aufgabe so programmiert, dass er nicht näher als 2m ran muss-man kanns nun auch als 7m auslegen, oder als 3... 8)

Woran lags?
Zum einen daran, dass meine Fahrstrategie einfach nur zusammengepfuscht war, weil ich heute mal testen wollte. Daher wurde nur dauernd die GPS-Position gemessen und "wenn Entfernung grösser wird, fahr mal rechts rum, ansonsten fahr gradeaus".
Alles andere als effektiv, das war sowieso klar.
Zum anderen konnte ich beobachten (am Lenkverhalten) dass wohl nur ca. einmal pro Sekunde die GPS-Daten frisch verfügbar (im Programm halt) waren- das Auto fuhr ungefähr zügiges Schrittempo, ohne Interpolation oder nen schnelleren Datenstrom wird das so auch nix.

Weiter müssen die GPS-Daten besser aufbereitet werden. Folgender Test:

Roboter hinstellen, dann neuen Zielpunkt "hier!" definieren und abspeichern.
Anschliessend-ohne das Fahrzeug zu bewegen, neu starten. wie von Geisterhand geht der Wert der Entfernung erstmal deutlich rauf-bis ca. 10, 12m. Danach nimmt er kontinuierlich wieder ab- nach ner Minute meldet das System: "bin angekommen".
Interessant-mal sehen, ob ich dieses Verhalten irgendwie erklärt bekomme.

Also: da müssen wir noch mal ran.
Aber gutes gabs auch: der Rest des Konzeptes(soweit aktiv, ausserm GPS war kein einziger Sensor online) funktioniert bestens. Der Vorgaberwert für den Fahrtregler (den konnt ich nur schätzen) passte-auch leichte Steigungen schafft das Auto so noch, und dennoch wars ggf. möglich, mal hinzugehn und es notfalls zu stoppen.
Auch der Timer (reine Vorsichtsmassnahme) den ich eingebaut hab, hat immer tadellos funktioniert: nach ner halben Minute stoppte das Auto immer- dann braucht ich nur auf den Joystick drücken und weiter gings.

Die Probleme mit dem GPS schieb ich auf mehrere Ursachen: zum einen hört man an allen Ecken und Enden, dass GPS in der Bewegung genauer funktionieren als im Stand.
Zum anderen ist da irgendwas zu langsam-ich guck nachher noch mal in den Code, was zwischen "lies das GPS ab" und "reagiere drauf" so alles passiert- musste eben schnell gehn... 8)
Naja-und die Fahrstrategie war (das war mir schon auf dem Weg nach unten klargeworden) so ineffektiv, wie sie nur sein kann. Die wird natürlich grundlegend verbessert.

Insgesamt waren die Tests also schon ein Erfolg, da ich vieles, grad im Zusammenhang mit dem GPS-hier drin einfach nicht testen kann.

[michael_x]

bis ca. 10, 12m

.
Völlig normal

[system]

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!

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)

[Rabenauge]

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. 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.

[system]

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!

[Rabenauge]

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.

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.

[Rabenauge]

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.

[Rabenauge]

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.

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...

[oOSpikeOo]

Baue das ganze auch aber auf 1:5

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

[Rabenauge]

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.

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.

[Rabenauge]

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.

[Scherheinz]

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?