RC-Auto ohne RC-Monstertruck autonom

[Rabenauge]

Hallöle.
Habs ja hier und dort schon angedeutet- ich bastele schon seit nem Weilchen an einem UGV- oder einfach nem autonomen Fahrzeug.
Basis ist ein 1:10er RC-Monstertruck von Tamiya. So einer: https://www.youtube.com/watch?v=8QagfbtszZw
Meiner ist ein bisschen modifiziert (Kugellager komplett sowieso, sämtliche Lager mit Messinglagern versehen, etwas höher gelegt, bessere Stossdämpfer mit progressiven Federn), aber ansonsten noch ziemlich original.
Das Auto gibts immernoch neu-heisst jetzt Double Blaze, glaub ich (hat nur ne andere Felgenfarbe und andere Karosserie).
Antrieb über zwei komplett getrennte Antriebseinheiten, jeweils nen 540er Bürstenmotor und Getriebe- das hintere Differential hab ich teilgesperrt.

Das _Auto ist grade gross genug, um auf weniger guten Wegen noch zurecht zu kommen, aber per RC wars dann doch mit der Zeit etwas langweilig- nun hab ich ihn zu Höherem auserkoren. Regler und Lenkservo sind drin geblieben, Empfänger raus, Antenne runter, dafür wurde eine Sperrholzplatte aufs Chassis montiert, der Schaumstoffstreifen dichtet sie ringsum zur Karosserie hin ab. Die Platte ist nur auf die originalen Karosseriehalter aufgesteckt- nehm ich vordere und hintere Sensorenplatte ab, kann ich das ganze Auto problemlos wieder in den Ursprungszustand versetzen, brauch dann nur Empfänger und Antenne wieder einbauen, am Auto selber ist _nix_ verändert worden.

Auf der Trägerplatte befinden sich:
-Arduino Mega 2560
-Ublox Neo-6M GPS samt Keramikantenne
-Stepdown-Regler für stabile 5V-Stromversorgung (das BEC des Reglers wird für die Servos zusätzlich genutzt)
- ein 16x2 LCD mit I2C-Adapter
-ein HMC5883L-Kompass
-ein MPU 6050, kombinierter 3Achs-Beschleunigungs-und Gyroskopsensor
-ein Daumenjoystick (der Stick schaut nach unten raus, damit ich ihn auch bei aufgesetzter Karosserie bedienen kann)
- ein ehemaliges 1.8" TFT- das TFT ist mal kaputtgegangen, aber hinten drauf war ein Micro-SD-Kartenslot, der funktioniert noch
Seitlich unter der Platte (aber auch an ihr befestigt) sitzen auf jeder Seite ein HC-Sr04 Ultraschallsensor, die rechtwinklig nach den Seiten schauen, vorn vor der Dämpferplatte ist eine weitere Platte mit zwei HC-Sr-04 montiert. die etwas schräg nach vorn sehen, und am Heck befindet sich ebenfalls ne Trägerplatte, an der ein Miniservo mit nem Sharp GPYirgendwas Infrarot-Sensor sitzt. Der ist somit schwenkbar.
Stromversorgt wird alles, wie original, aus nem 7.2V Racingpack (noch gute NC-Zellen, inzwischen echte Schätzchen).

Da ich heute ein, für mich wichtiges Zwischenziel erreicht hab, stellt ich das Auto hier mal vor....
Wie gesagt: der Plan ist es, das Auto so autonom wie möglich draussen herumfahren zu haben. Da das Ding soo langsam auch nicht ist, sind theoretisch einige Km Reichweite möglich, evtl. spendiere ich noch irgendwann nen LiPo- da geht noch mehr dann.
Viele Teile der Software laufen bereits, genutzt wird aber noch nirgends alles zusammen, dennoch:
Inzwischen ist das Fahrzeug in der Lage, ein wenig autonom zu navigieren.

Konkret: ich suche mir einen beliebigen Punkt, stelle das Auto dort ab und speichere die GPS-Koordinaten (die werden auf die SD-Karte geschrieben).
Nun gehe ich mit dem Auto "irgendwo" anders hin, rufe den entsprechenden Fahrmodus (ich hab ihn GPS2Home genannt) auf, und das Auto fährt "alleine" wieder zum ersten Punkt zurück!
Hab ich heute nach dem Mittag etwas über ne Stunde probiert, mit verschiedenen "Home-Punkten", aus allen möglichen Richtungen- es klappt mit einer Genauigkeit von ungefähr 4m.

Warum steht das "alleine" in Anführungszeichen? Ganz einfach: komplett alleine gehts noch nicht: erstens habe ich ne Sicherheitsfunktion eingebaut, die das Auto nach ner Minute stoppt. Das verhindert, dass ich mir die Lunge ausm Hals renne, wenn irgendwas schief geht. Ich spaziere also gemütlich hinterher, drücke kurz auf den Joystick-und weiter gehts.
Zweitens ist die Umweltsensorik zwar an Bord, auch bereits in der Software vorhanden, wird aber in diesem Fahrmodus überhaupt nicht genutzt. Der Grund dafür: ich wollt nicht zu viele mögliche Fehlerquellen auf einmal am Start haben.
Erstmal sollte die Zielfindung laufen-sie tuts nun, wenn auch noch etwas verbesserungswürdig.
Somit funktioniert das Ganze momentan nur bei einer möglichen direkten Fahrverbindung zwischen Start und Ziel.
Dafür aber theoretisch schon auf beliebige Entfernungen-ich habs auf mehr als 100m auch probiert- klappt mit der genannten Präzision.
Warum nicht genauer?
Zum einen bringt das GPS _nur_ mit SBAS-Signal (ob SBAS empfangen wurd, weiss ich nicht) richtige Genauigkeiten (PPP kann das 6M leider nicht), somit haben wir bereits beim Home-Punkt ~2m Toleranz.
Zum zweiten habe ich den Fahrmodus so programmiert, dass eine Entfernung von 2m ans Ziel als "Ziel erreicht" ausgelegt wird-um endloses Rumgekurve nahe am Ziel zu vermeiden.
Das macht dann schon bis zu 4m- da sind wir also im Geschäft!
Es wird einfach vor dem Start der Zielpunkt von der Karte gelesen, dann die aktuelle GPS-Position ermittelt, Kurs und Entfernung berechnet und ab gehts- während der Fahrt wird laufend mittels Kompass (das GPS hat auch ne Kompass-Funktion, aber die funktioniert lausig) und GPS (das lese ich mit 5Hz aus, hab also 5x pro Sekunde frische Positionsdaten) kontrolliert, ob die Fahrtrichtung noch korrekt ist, und die Entfernung zum ziel noch grösser als 2m.

Auf dem Display werden übrigens eine ganze Menge Daten ausgegeben (derzeit auch während der Fahrt, das schalt ich irgendwann aber ab), z.B. Akku-Füllstand, GPS-Status (Fix aktuell, kein Fix vorhanden, Fix bereits älter), Zielpunkt erfolgreich auf der SD-Karte gefunden (das sagt mir auch, wenn ein neuer Zielpunkt korrekt abgespeichert wurde), Entfernung zum Zielpunkt, aktuellen Kompasskurs (dank dem HMC5883l auch im Stand), und zu debug-Zwecken auch noch ob der Truck eher links-oder eher rechtsherum (oder auch gradeaus natürlich) zum Ziel fahren sollte.
All das wird selbständig "live" berechnet, die Kompassdaten werden kalibriert aufbereitet usw.
Bei Bedarf kann ich auch Sensor-Entfernungen oder ähnliches ausgeben.

Als kleine Spielerei ist ne Art elektronischer Schlüssel eingebaut: ohne die _richtige_ SD-Karte rührt sich gar nix.
Auf der Karte ist eine spezielle Datei mit nem bestimmten Inhalt, und nur wenn _die_ _so_ auch vorhanden ist, kann das Auto aktiviert werden.
Relativ sinnlos-ich weiss, aber der Spieltrieb halt...:cool:

Zusätzlich zum GPS2Home-Modus kann ein manueller Modus gewählt werden, indem man das Auto mit dem Joystick etwas herumfahren kann- der hatte sich ergeben, weil ich die Ansteuerung des Fahrtreglers testen musste (es ist ein CAR-Regler, der über eine Bremsfunktion verfügt)-auch der ist weitgehend sinnlos inzwischen, da der Stick unterhalb der Karosserie fast hinterm Vorderrad sitzt.

Der Modus GPS2Home soll später ausgebaut werden: dann will ich auf der SD-Karte einzelne Dateien anlegen, die jeweils eine GPS-Route enthalten, und möchte dann von unterwegs eine dieser Routen auswählen können, die das Auto dann abzufahren hat- und ggf. Hindernisse umfahren soll dabei. Wer jetzt noch folgen kann, dem wird klar sein, dass diese Optionen noch weit mehr Möglichkeiten zulassen-im Grunde ist alles, was ein komplettes Navi braucht, vorhanden. Soigar die Möglichkeit, vorhandene Routen zu verfeinern, ist gegeben (das Schreiben auf der Karte hab ich ansatzweise auch schon in Griff, beim Zielpunkt klappts ja einwandfrei).
Ob ich das, was mir da so vorschwebt, hinkriegen werd- sehn wir, wenns soweit ist.

Anbei nen paar Bilder von dem Ungetüm-nen aktuelles mit Karosserie hab ich nicht, da hänge ich eins an, von der ersten Elektronikplatte (die musste runter, weil mir da alles zu dreckig wurd, die war nicht dicht nach unten hin)- man sieht von der ganzen Technik lediglich die vorderen seitlichen und den hinteren Sensor- die müssen nunmal rausgucken. ;)
Naja: und durch die Frontscheibe kann man bequem das Display ablesen. Vorhin hab ich noch nen Hauptschalter für die Elektronik eingebaut, der ist auf den Bildern noch nicht drauf, aber nen Schalter haben wohl die meisten schonmal gesehn.;)

[HeXPloreR]

Hallo Sly,

sehr schönes Projekt.

So etwas ähnliches habe ich fürs nächste halbe Jahr mit meinem Bullet ST Flux auch vor, allerdings wollte ich auch den Empfänger drin lassen und quasi mit der RC-Steuerung die Kontrolle jederzeit übernehmen.

Viel Erfolg weiterhin und Gruß
Jörg

[Rabenauge]

Besorg dir besser nen Summit. Der dürfte, nach meinen jetztigen Erfahrungen, am geeignetsten sein.
Warum?
-er kann _auch_ vernünftig langsam fahren. Meiner leider nicht wirklich-momentan habe ich das Tempo auf zügiges Schrittempo gesetzt, damit hat er im Gras schon seine liebe Mühe.
Das wäre nen Argument, nen RC-Empfänger draufzubauen, wenigstens als Notstopp- ich wollts erst auch tun, aber es geht auch ohne.
Viele nehmen auch Crawler- geht natürlich auch, aber die Dinger sind halt absolut streckenuntauglich, durch die extreme Untersetzung kommen die einfach nicht voran.
Aber das langsame Tempo vereinfacht so einiges....
Mein GPS z.B. läuft deutlich nach (2-3 Sekunden ungefähr), das ergibt momentan das Phänomen, dass der Truck erstmal meistens am Ziel vorbeifährt, nen paar Meter später merkt ers und dreht um. Da muss ich noch mal in die GPS-Einstellungen schauen, kann mir nicht vorstellen, dass UBlox das nicht besser hinkriegt.
Würde nen Crawler nicht merken, weil der nur nen halben Meter pro Sekunde fährt oder sowas- im Summit könnt man einfach herunterschalten.
Leider ist das Ding deutlich ausserhalb meines Budgets (und als RC-Modell will ich das Ding gar nicht haben, ist halt weder Fisch noch Fleisch und sieht- für meinen Geschmack-scheusslich aus).
Aber hier wärs wohl das ideale Fahrzeug.

[robosapiens]

îch habe dein Projekt ebenfalls mal angefangen umzusetzen (Fahrzeug - GPS - Ultraschallsensor).
So als Tipp vielleicht, habe damals ein Serielles GPS Modul von Navilock bei Conrad gekauft, welches sehr schnell und Präzise arbeitet. Könnte ein Ersatz zu deinem Ublox Modul sein. http://www.conrad.de/ce/de/product/378833/GPS-Empfaenger-Navilock-NL-303P?ref=searchDetail

Als Chassis habe ich damals ein altes Tamiya Panzerchassis verwendet. War sehr zufrieden mit meiner Wahl, da der Roboter über fast alles drüber kam und dazu recht zügig unterwegs war.

[piggituX]

Hi,

ah nun auch endlich hier :). habe das im Arduino-Forum schon verfolgt. Ich baue derzeit auch genau an so einer Lösung. Mein Chassis ist aktuelle ein altes Nikko RC, geht nur schleppend voran, da mich mein Sohn auf Trab hält. Bin derzeit bei Hindernis-Erkennung dran, aber ich habe ja Zeit

Wünsch Dir viel Erfolg und ich verfolge das mal weiter

pig

[Rabenauge]

@robosapiens: das Navilock-Mäuschen, was du da verlinkt hast, verliert in jeder Kategorie (die dabeisteht) haushoch gegen das Ublox.:)
Und das für den vierfachen Preis....
Ich bin mir sicher, dasss ich nur noch nicht die optimalen Einstellungen gefunden habe, vermutlich hängt es mit dem eigebauten "Odometer" zusammen, das kann man auf etliche Arten konfigurieren (und alles mögliche und unmögliche sonst auch am Ublox).
Nen Panzerchassis wollte ich erst auch verwenden, aber ich hab solche Dinger und weiss: so ohne weiteres sind die 1:16er auch nicht wirklich Wildnistauglich, es geht, aber nicht so gut wie ich es will (früher oder später werd ich mir, wohl auf Basis dieser Panzer, mal ein _richtiges_ Chassis bauen, wenn man nicht auf die Vorbildtreue angewiesen ist, geht da was).

@pig: hatte ich ja auch so angefangen, mit nem Spielzeug-Buggy. Den hab ich aber ausgemustert, weil er für outdoor soo tauglich auch wieder nicht ist- der Monstertruck schafft Bordsteine auch noch aufwärts. Und da ich mir nicht sicher war (und es noch immer nicht bin) wie genau es mit GPS _wirklich_ zu schaffen ist, rechne ich nicht damit, immer guten Untergrund zu haben. Unter "Laborbedingungen" geht vieles weit einfacher, aber genau davon wollte ich eben weg.

[Rabenauge]

Sodele.
Bisschenwas ist heute auch geworden (weniger als geplant, aber das ist ja irgendwie normal): ich hab noch nen Stück Hardware verbaut.
Neee-natürlich nix wichtiges- eine Hupe. :)
Genaugenommen nur ein chinesischer Buzzer (mit jämmerlichster Klangqualität, wenn mir mal was besseres in die Finger kommt, wird das Elend ausgetauscht), aber den wollte ich so ziemlich zu Anfang schon haben. Damit er ein bisschen Sinn macht ("Spieltrieb" klingt immer irgendwie komisch, wenn mans nem Fremden erklärt), darf er gewisse Dinge auspiepsen.
Beispielsweise wird nun, ehe die Antriebe aktiviert werden, dreimal gepiepst- das ist echt praktisch, so kann man noch die Finger vom Vorderrad wegbekommen ehe die Kiste los marschiert. Wenn man will, kann man alles "sinnvoll" reden, oder? ;)

Aber was gescheits ist auch geworden (genaugenommen sitze ich noch dran): die vorderen US-Sensoren laufen nun im GPS2Home-Programm mit.
Somit ist immerhin der Grundstein für eine erfolgreiche Hinderniserkennung schonmal gelegt.
Allerdings gibts ein Problem: bei 15 km/h (das dürfte in etwa Höchstgeschwindigkeit sein, ich hab die kürzere Untersetzung drin, glaub ich ) haben wir etwas über 4m/s- und vier Meter schaffen die US-Sensoren grade noch sicher. Manche auch fünf-aber da verlasse ich mich besser wohl nicht drauf. Ausweichen wird also knapp- das muss sehr schnell gehn.
Glücklicherweise kann das Auto bei _dem_ Tempo (ich könnts auch mit 12V fahren, dann aber könnte ich die Sache vergessen) selbst bei Vollgas noch kräftige Lenkeinschläge schaffen, ohne gleich umzukippen-werds brauchen.
Ne vernünftige Bremsstrategie hab ich nämlich noch nicht, da der Regler sich beim umschalten von Vorwärts auf Bremse enorm zickig gibt.
Nun frage ich mich grade, ob es überhaupt noch Sinn macht, bei Hinderniserkennung proportional zu lenken, oder einfach "rum bis der Weg wieder frei ist"- letzteres ist eigentlich nicht meine Art, ich mags geschmeidiger.

[Rabenauge]

So-ich werd erstmal die "rum-bis-frei-Methode" testen.
Der Grund: um an den Sensorergebnissen noch lange rumzufiltern fehlt die Zeit. Ich möchte nämlich nicht unbedingt schon auf 4m anfangen, Hindernissen aus dem Wege zu gehn- auf den üblichen Teststrecken (Fusswege, max. Radwege, auf öffentliche Strassen will ich logischerweise nicht) ist 4m zu lang- das ergibt ja nur rumgekurve.
Wenn ich den Modus getestet habe werde (heute wird das nix mehr), werd ich wissen, ob das so praktikabel ist-oder nicht. Und auch, ob da noch genug Luft bleibt, ums zu verbessern (bei nur 2m Reichweite spar ich ja doch einiges an Messzeit).
Zusätzlich habe ich die Sensorresultate (ich lass die gleich in cm umrechnen, das braucht der Roboter nicht, aber dem Menschen hilfts) verunschärft- alles was innerhalb 5cm Toleranz passiert, wird nich ernst genommen.
Das ist deshalb nötig, weil die Sensoren mit der verwendeten Bibliothek soo genau auch wieder nich arbeiten, selbst bei völlig freier Sicht wackelt die Ausgabe nen bisschen.
Vermutlich hats der Ersteller (wenn ich mal gaaaanz viel Lust hab guck ich mal in die Bibliothek rein, momentan nich) etwas zu gut gemeint mit seiner Zeitbegrenzung.

Nenbenbei hab ich die beiden vorderen US-Sensoren mechanisch noch stabiler angebaut, die hat es mir beim hantieren immer mal nach hinten gebogen (die waren praktisch nur an den Anschlussstiften verlötet)- dauerndes hin-und-herbiegen kann auch nich gut sein.
Allerdings werden sie jetzt bei nem guten Frontalcrash zerstört, da sie nicht mehr nachgeben können-da muss dann mal noch nen Schutzbügel vor, wenn mir was passendes in die Finger fällt.
Ausserdem: genau den Crash sollen sie ja verhindern-also solln die dinger gefälligst ihren Job machen, dann passiert auch nix.:cool:

[HannoHupmann]

Hast du dir mal Gedanken über die Laufzeit deiner Sensorsignale gemacht?

Der Erklärbär sagt: Laufzeit bedeutet die Zeit von: "Hindernis erkannt" bis "Rumms" die ist direkt abhängig von a) ab wann kann der Sensor ein Hindernis erkennen und b) mit welcher Geschwindigkeit fährt man darauf zu. Also z.B. erkennen ab 1m und 1m/s ergibt 1sec für a) Auswertung & Verarbeitung der Sensorsignale und b) korregierende Maßnahmen: ausweichen und oder bremsen (hier gilt es die Massenträgheit zu beachten).

Da Roboter in der Regel in der Wohnung nur sehr langsam herumfahren ist das Problem der Laufzeit nicht relevant. Bei outdoor Robotern die doch öfters auf beachtliche Geschwindigkeiten kommen wird das Thema schon spannender.

[Rabenauge]

Ja, hab ich. Und das wird etwas knapp, da mit ungefähr 4m/s Geschwindigkeit zu rechnen ist.
Daher verzichte ich momentan auch drauf, die vorderen Sensoren wirklich zu filtern, oder gar-wurd mir auch schon vorgeschlagen (und ich würds auch machen, wenn die Zeit reichen würde) da einen LongRange-Modus zu nutzten, und wenn der was meldet, genauer zu gucken.
Glücklicherweise reicht etwa ein Meter, um vor nem Hindernis abzudrehen, auch bei höherer Geschwindigkeit, als ich sie momentan fahre (die jetztige ist das minimalste, was auch in niedrigerem Gras noch geht), daher brauch mich mir da nicht viele Sorgen machen aber- schnell gehn muss es trotzdem.
Vermutlich wird dadurch deutlich öfter "ausgewichen" wegen Fehlalarm, aber da bei jedem Schleifendurchlauf eh korrigiert wird, wird sich das bei Fehlalarmen nicht wirklich auswirken. Erleichternd kommt noch hinzu, dass die Lenkung bauartbedingt soo präzise ohnehin nicht ist: dúrch die grossen Räder ist Geradeauslauf schon keine Stärke des Monsters, und der Servosaver ist auch relativ weich.
Als es noch per RC unterwegs war, hatte ich nen Hubschrauber-Kreisel drin, damit fuhr es dann allerdings auch auf richtig grobem Untergrund wie auf Schienen.

Die momentane Strategie sieht folgendermassen aus: aus den Ergebnissen der Kursberechnung (Sollkurs vom GPS, Ist-Kurs vom Kompass) werden notwendige Lenkmanöver berechnet. Dann werden die beiden vorderen US-Sensoren abgefragt, deren Werte "verunschärft" (ich teil sie momentan einfach durch 5, nicht besonders clever aber wirkungsvoll), da Rauschen unterdrückt wird), und dann verglichen.
Nun wird das vom Kursrechner ermittelte Lenken kurzerhand überschrieben, je nachdem, wo mehr Platz ist. Melden die Sensoren nix, wird auch nix überschrieben, und die Kurssteuerung ist aktiv-aber so hat das ausweichen immer Vorrang.
Optimal ist das nicht, denn _wenn_ man (es ist unwahrscheinlich, aber möglich) die beiden Sensoren zum selben Ergebnis kommen, knallts.
Dagegen muss noch was unternommen werden, das ist klar, aber ich hab die Möglichkeit, so erstmal zu testen, wie diese Strategie sich schlägt.
Heute, hoffe ich...

[The Man]

Ah, du benutzt einen elektronischen Kompass? Unerstützen die uBlocks nicht eine Nachricht mit aktuellem Kurs? Gut, der ist natürlich im Stillstand und zu geringer Geschwindigkeit falsch. Aber die GPS Maus kann aus einer Ist- und einer Zielposition einen Sollkurs berechnen?
Mist, hab ich damals wohl nicht nach geschaut und die Zielabweichung im Controller berechnet mit ner LUT für den ArcTangens und einer spezialisierten Divisionsroutine.
Die Kursabweichung hab ich einfach bearbeitet und auf den Lenkservo gegeben, k.A. ob P-I oder sogar nur P - zu lange her.

[Rabenauge]

Klar kann das UBlox auch den aktuellen Kurs errechnen.
Aber wie du schon sagtest: im Stand _überhaupt nicht_ (da ist nicht mal eine Info zu bekommen, in welche Richtung wir "schauen") und bei langsamer Fahrt klappt es auch erst nach etlichen Metern. Dann aber noch immer recht unbrauchbar: ohne weitere Tricks (ppp kann das Neo-6m ärgerlicherweise nicht) hat man eine maximale Genauigkeit von 2m. Bei einer Fahrstrecke von, sagen wir mal 10m kannst du dir leicht ausrechnen, wie "genau" da ein Kurs überhaupt berechnet werden kann: nahezu unbrauchbar.
Durch den Kompass hab ich aber bereits vor dem Losfahren eine völlig ausreichende Orientierung- das Auto kann schon bevor es überhaupt fährt, in die richtige Richtung lenken (und das tut es auch, bzw. zeitglich mit dem losfahren)- und das stimmt dann auch.
Zwar hat auch der HMC5883l ein bisschen Abweichung (er schwankt im Bereich von 3-5 Grad bisschen) aber das macht nix, das genügt völlig um nen Zielpunkt zu finden. Wäre noch besser möglich, wenn man das Ding weiter weg von der restlichen Elektrik montieren würde-aber aus optischen Gründen (da bin ich bissel starrköpfig, es muss gut aussehen) wollt ich auch den Kompass unbedingt unter der Karosserie haben- keine 20 cm weg von einem der Fahrmotoren also. Hab ihn aber ganz ordentlich kalibriert bekommen.

Der Sollkurs dagegen wird natürlich aus den GPS-Daten (den aktuellen Positionsdaten und dem vorgegebenen Zielpunkt) errechnet, ebenso die Entfernung. Aber gesteuert wird der Kurs halt nach dem Kreisel, da das einfach besser funktioniert.
Proportionales lenken hab ich weggelassen-dafür gibts keinen richtigen Grund, denn zum einen fährt so ein RC-Monstertruck sowieso nicht soo präzise (im Gelände erst recht nicht) gradeaus, und zum anderen ist es nicht nötig. Immer, wenn Soll-und IstKurs zu stark abweichen, wird mal ein Lenkeinschlag angeordnet, bis es wieder passt. Davon merkt man während der Fahrt kaum was.

Aktuell versuche ich (da ich mit den US-Sensoren noch nicht weiter komme, muss ich mal Lust zum rumbasteln haben) das Fahrprogramm GPS2Home so zu erweitern, dass ich vordefinierte Routen von der SD-Karte einlesen kann, und die dann Wegpunkt für Wegpunkt abgefahren werden.
Wenn ich das nämlich ausreichend genau schaffe, komm ich (im Prinzip...) ohne Hinderniserkennung aus: ich muss halt nur die Routen so legen, dass feste Hindernisse kurzerhand gleich umfahren werden. Unter Idealbedingungen (keiner parkt unangemeldet aufm Testgelände) sollte das klappen.
Allerdings ist das Ganze ziemlich viel Aufwand, da die Routen (in unbekannter Anzahl, ich will später einfach neue mit ablegen können) jeweils in ner eigenen Datei liegen, mir aber die Namen der Dateien (8.3-Format) zu kurz sind, um ausreichende Infos zu haben, welche Route es nun genau ist.
Von daher muss jede Datei einzeln geöffnet werden, die erste Zeile eingelesen (die enthält den richtigen Routennamen), aufs Display ausgegeben werden (damit ich dann die gewünschte Route wählen kann), und _wenn_ ich dann die richtige gefunden hab, muss die zeilenweise gelesen werden, um so einen Punkt nach dem anderen als "Ziel" zu haben. Ist das "Ziel" erreicht, werden einfach die nächsten Koordinaten geladen.
Ich will nämlich keineswegs immer die gesamte Route in den Speicher laden-irgendwann würd der Platz nicht mehr reichen, und bei dem beschriebenen System können die Routen theoretisch beliebig viele Punkte enthalten.

Das tolle ist, dass ich das Fahrprogramm GPS2Home, was ja schon gut funktioniert, für diesen Fahrmodus gleich mit benutzen kann. Es wird einfach nur immer, wenn ein Punkt erreicht ist, mit neuen Zielkoordinaten wieder gestartet.

[Rabenauge]

So- mit der SD-Karten-Geschichte komme ich recht gut voran (hatte die letzten Tage nicht viel Zeit)- einiges läuft bereits.
Dabei kam mir eine Idee:

Beim einschalten des Autos werden ja gewisse Dinge ausgewählt:
-Fahrmodus (GPS2Home oder RoutenNavigation
-falls ersteres, dann auch, ob ein neuer Startpunkt gesetzt werden soll,
-falls RoutenNavi, welche der vorhandenen Routen ausgewählt werden soll.
Nun kam mir die "bahnbrechende" Idee: was passiert, wenn der Mega mal abstützt oder aber der Akku leer ist, bevor die gestellte Aufgabe erledigt werden konnte?
Im Prinzip: nix, nur wird sie dann nie erledigt.
Das geht aber besser, da ich ja sowieso schon dauernd auf der SD-Karte herumspiele, könnte man es so lösen, dass zu Anfang die gewählten Einstellungen in ne Art *.ini-Datei geschrieben werden.
Die wird gelöscht, wenn die Aufgabe erledigt wurde. Dann brauche ich beim einschalten (halt bei jedem Neustart des Bordrechners) nur nachsehen, ob diese Datei vorhanden ist, und wenn ja kann man ne kleine Entscheidung einbauen, die meinetwegen 5s wartet: soll die Aufgabe fortgesetzt werden oder nicht....
Wenn die Zeit abgelaufen ist, ohne dass eine Planänderung vorgenommen wurde, wird einfach weiter gemacht.
Könnte man im Grunde auch in den EEPROM schreiben, aber dafür bräucht ich dann noch ne Bibliothek- die für die SD-Karte ist sowieso da.

Was meint ihr, macht doch Sinn, oder nicht?

[Rabenauge]

Inzwischen hab ich am RoutenParser mal fleissig gearbeitet.
Zwar läuft der momentan (noch) nur als eigenständiges Programm, aber nur, weils übersichtlicher ist.
Sind immerhin alleine knapp 200 Zeilen (nagut, nen paar leere sind auch drin, ausserdem musste ich den Joystick und das Display einpflegen zud zu debug-Zwecken gibts auch noch etliche serielle Ausgaben).

Ich habs aber so strukturiert, dass ich gar nicht viel mehr tun muss, als das Programm dann ins eigentliche Roboter-Programm einzukopieren.
Was macht der Routenparser?
-zuerst öffnet er das Routen-Unterverzeichnis der SD-Karte.
-dort zählt er die gefundenen Dateien (1 Datei=1 Route) und wartet nun auf eine Eingabe (per Joystick)
-bei jeder Stickbewegung wird der Reihe nach eine der Routen-Dateien geöffnet, und der Routenname, der am Anfang in Klartext steht, auf Display ausgegeben, damit man weiss, welche Route man gewählt hat
-das Ganze in ner Schleife. Ist das Verzeichnis durch, wird von vorn angefangen..
Wird der Stick eine gewisse Zeit nich mehr bewegt, wird die gerade gewählte Route übernommen, indem ihr Dateiname in ner Variablen gespeichert wird.
Nun wird ein Wegpunkt nach dem anderen _einzeln_ eingelesen-bevor der nächste gelesen wird, muss ein Trigger kommen (das wird später sein: Wegpunkt erreicht, momentan ist das einfach nur nen Sekundenzähler).

Damit habe ich nun alles beisammen, was ich für die Routen-Navigation brauche.
Im Grunde muss das Ganze dann nur noch an die Routine von GPS2Home übergeben werden, mit den aktuellen Wegpunkt-Werten als Sollwerte. Dann wird einfach GPS2Home so oft abgearbeitet, bis kein neuer Wegpunkt mehr kommt und-fertig.
Entspannende Bastelei also....

Aber noch gibts kleinere Problemchen: ich kann durch die Routen nur in eine Richtung blättern (weil ich einfach routenDatei = dir.openNextFile(); benutze), da ich keine Idee habe, wie man _einfach_ rückwärts blättern könnte.
Wenn die Routen alle durch sind, wird einfach mit dir.rewindDirectory(); wieder zum Anfang des Verzeichnisses gesprungen.
Genau _dort_ gibts ein Problem:
Dieses rewind.directory() macht etwas Probleme: aus einem unerklärlichen Grund dauert das ne halbe Sekunde, ehe es ausgeführt wird. Wenn man aber während dieser Zeit den Stick bewegt, wird zwar eine Datei eingelesen, aber die dann gelesenen Werte stimmen nicht. Wenn mir dazu ne Idee kommt (oder jemand nen Tipp hat?) würd ichd as gerne noch irgendwie auffangen.
Ansonsten muss ich die Routen auch noch auf Plausiblität überprüfen.....

Das zweite Problemchen ist ziemlich trivial (und kann vernachlässigt werden): der letzte Wegpunkt wird zweimal eingelesen, ehe festgestellt wird: da sind wir schon. Ich möchts trotzdem noch fixen- es ist einfach unschön.

Obendrein überlege ich noch, was sinnvoller ist: momentan wird das Auto _immer_ zuerst zum Anfangspunkt der ausgewählten Route fahren, und sie dann abarbeiten.
Effektiver wärs eigentlich, zuerst zu schauen, welcher Wegpunkt der nächste (vom Start) ist, und direkt den anzusteuern.
Ich find, irgendwie haben beide Methoden was. Ob ich da noch nen Fahrmodus mache? Mal schauen...
Zudem werd ich wohl noch die Plausibilität der ausgewählten Route überprüfen, einfach, indem die Entfernung zwischen aktueller (=Start-)Position und dem Routeneinstieg mal gegengerechnet wird. Ist die gewählte route weitewr weg, als das Auto fahren könnte (soo ewig reicht so ein Akku ja auch nicht), wird die Route gar nicht erst akzeptiert- man kann sich beim auswählen ja mal vertan haben.

[Rabenauge]

Sodele. Das Problem mit den teilweise falsch eingelesenen Dateien ist beseitigt.
Es war mal wieder meine eigene Blödheit....
Es wird nämlich lediglich in der jeweiligen Datei einfach nach "Zahlen" gesucht. Die erste gefundene Zahl ist der erste Wegpunkt, die zweite die dazu gehörige Länge, die dritte die Breite...
Da die Datei aber ganz oben auch nen String enthält (der den Klartext-Name der jeweiligen Route ausgibt), kann nun ein besonderes Schlauköpfchen auf die Idee kommen, mal einen Namen wie "ParkplatzRoute1" zu benutzen.
Und die darin enthaltene 1 wird somit bereits als erste Zahl gefunden, und alles verschiebt sich um eine Position.
Clever, oder? ;)
Klar, man könnte das auffangen, indem man alles auf Plausibilität überprüft (wenn ein GPS-Punkt keine acht Stellen hat, kann er nicht stimmen), aber ich machs mir einfach und werd versuchen, die Textdateien in Zukunft ordentlicher anzulegen.
Das jetztige, noch standalone laufende Routen-Parserprogramm ist nämlich ohnehin schon 170 Zeilen lang- wobei ein grosser Teil davon allerdings nicht zählt (die Joystick-Routine ist ja im Monstertruckprogramm eh drin, die brauch ich also nicht noch mal, ausserdem werden zu Testzwecken im Moment eine Menge Daten auf die Konsole ausgegeben, das fällt dann auch weg), trotzdem isses gross genug.
Werd noch bisschen dran herumtesten, und es dann ins Monstertruck-Programm reinkopieren, ich hab es grundsätzlich gleich so ausgelegt, dass das meiste sich einfach rüberkopieren lässt.

[Rabenauge]

Damit keiner einschläft hier: es geht natürlich weiter.
Hatte zwar die letzten Wochen keine rechte Lust (und andere Sachen zu tun), aber nun juckts wieder in den Fingern.

Soeben hab ich mir nen 20x4-LCD mit I2C-Rucksack geordert.
Das derzeitige 16x2 ist einfach immer voll. :(

Da auch der Routen-Parser ja nun problemlos läuft (wenn auch _noch_ standalone) werd ich, während ich auf das neue Display warte, den mal in die Software einbauen.
Als nächstes werden die Display-Routinen aufgeräumt, die hab ich einfach imemr wieder erweitert, wenn was anfiel, und entsprechend sehn die nun auch aus, das blickt keiner mehr. Da ich ja dann bald auch mehr Daten ausgeben kann, wird das gleich entsprechend genutzt bei der Gelegenheit.

[Rabenauge]

Sodele.
Inzwischen ist das Display nun doch bei mir eingetroffen-und zwar gratis, da der Chinamann mir drei Tage Lieferzeit versprochen hatte, aber vier Wochen gebraucht hat. Einerseits ärgerlich, andererseits hab ich nen reichlichen Zehner gespart- auch gut.

Und: es lief, nachdem ich es montiert hatte, sofort.
Also hab ich mich wieder auf die Software gestürzt.

Inzwischen hab ich wieder so einiges gemacht.

Es gibt nun ne Art "Splash-Screen" beim einschalten (ich weiss, nutzlos-aber hübsch ), danach läuft ein Selbsttest durch.
Auch der ist -fast- fertig geschrieben und funktioniert.
Getestet wird so ziemlich alles, was ich so testen kann:

-ist die Bordspannung unter 7V wird die Arbeit verweigert
- ist keine oder die falsche SD-Karte eingelegt, ebenfalls (das mit der falschen Karte ist ne weitere Spielerei: die fungiert sozusagen als Wegfahrsperre. Es muss sich eine bestimmte Datei mit festgelegtem Inhalt drauf befinden, nur dann wird überhaupt gearbeitet)
- der Kompass wird so lange immer wieder durchgetestet, bis seine Abweichung unter 10% liegt (damit kann ich leben, in Verbindung mit dem GPS reicht das notfalls schon, und die ist in der Regel gleich erreicht, wenn sie nie erreicht wird, stimmt irgendwas nicht-> Auto steht auf nem Drehteller oder ein Magnetsturm ist in der Nähe)
-das GPS wird ebenfalls überprüft, und, wenn es schon nen Fix hat, wird die aktuelle Anzahl der erreichbaren Satelliten angezeigt (evtl. geb ich da aber mal den HDOP-Wert aus, der ist wohl aussagekräftiger)
- der Heck-Entfernungsmesser wird auf ähnliche Weise getestet, aber da wird nur ein Schnitt von zehn Messungen hinzugezogen, da er nicht essentiell für die meisten Fahraufgaben ist
- die Ultraschallsensoren werden genauso getestet.
-fehlt noch, kommt aber: die MPU 6050 wird noch daraufhin überprüft, ob das Fahrzeug wenigstens so was ähnliches wie auf den Rädern steht- aufm Dach kann das Teil nicht fahren!

Danach erst kann es losgehen, so ist so halbwegs sichergestellt, dass die wichtigsten Systeme auch funktionieren sollten.

Anschliessend wird das Menü, mit dem der Fahrmodus aufgewählt wird, komplett neu geschrieben. Das funktioniert zwar, hat aber nen paar Schönheitsfehler.

Und:es wird wohl mal wieder noch nen kleines Stückchen Hardware geben (die nicht nötig ist, ich aber mal dran haben möchte), aber dazu mehr, wenn es soweit ist.

[Rabenauge]

So. Wieder was fertig:

Für den Fall, dass "jemand" mal das Auto einschaltet, und dann doch nix damit anzufangen weiss (auf deutsch: es wird kein Betriebsmodus ausgewählt), wird automatisch ein Demo-Modus gestartet.
In dem werden abwechseln nen paar Geschichten auf dem Display ausgegeben, jeweils in nem eigenen Screen:

-Kompassrichtung (die, in die die Nase des Autos zeigt)
-wenn verfügbar, die GPS-Koordinaten so wie die Anzehl der verfügbaren Satelliten
- wenn verfügbar (wenn das GPS keinen Empfang hat, gehts nicht, da ich keine Echtzeituhr hab) Uhrzeit und Datum.

Bei letzterem bin ich auf ne interessante Geschichte gestossen:
Das GPS geht ja (fast) Atomuhr-Genau.
Nun hab ich, spasseshalber, mal verschiedene Uhrzeiten aus dem Internet damit verglichen :
Irgendwie sind die meiner "Atomuhr" 3-4 Sekunden voraus!
Dass ich hier drin recht miesen GPS-Empfang habe, weiss ich (aktuell nur 5 Satelliten), aber das hat ja nix mit der Zeit zu tun.
Angeblich aber sind die Protokolle, mit denen man Uhrzeiten präzise per Internet übertragen kann, ja so richtig genau?
Und nein, es dauert hier nicht vier Sekunden, um alles zu aktualisieren, es geht weit schneller.
Jemand ne Idee? Nicht, dass es mich nun sehr stört, aber ich wundere mich halt....

Zu der Ankündigung mit der neuen Hardware:
Die ist drauf und läuft.
Es ist nur nen kleines Platinchen mit nem LM 35 und nem Fotowiderstand, aber ich hab da bewusst noch etwas Platz gelassen.
Wozu?
Für den Fall, dass mich mal jemand nach dem "Sinn" des Autos fragt (nicht-roboterbauende Leute tun das ja andauernd....), kann ich sagen, er ist ne autonome Wetterstation. :cool:
Das Monster sollte ja eh mehr nen Test werden, um verschiedenes auszuprobieren, genügend freie Pins hab ich auch, also, wieso nicht.
Man könnte über gewisse Fahrstrecken damit beispielsweise Temperaturprofile aufzeichnen, oder ähnliches.
Oder abschalten, wenn der Akku eingefroren ist. :D
Der Lichtsensor soll später auch ne Aufgabe bekommen, ebenfalls für die "Ungläubigen": ich möchte das Monster später mit ner netten Beleuchtung ausrüsten. Einfach, um Sympathiepunkte bei artfremden Leuten zu sammeln- und wegen meinem Spieltrieb auch, nen ganz kleines bisschen.
ES SIEHT NUN MAL VIEL COOLER AUS.
Und: wer hat schon ne autonome Taschenlampe... :D

[Rabenauge]

Sodele.
Das Wochenende war kurz(sind die irgendwie immer, oder?) aber erfolgreich.
Ein guter Teil des Codes ist schon renoviert inzwischen-und läuft trotzdem noch. :)

Überarbeitet hab ich (unter anderem, ich hab fast in allem rumgerührt) die Displayausgaben.
Die erfolgen nun wesentlich strukturierter, in nem eigenen Unterprogramm, dem nur die entsprechenden Werte geschickt werden.
Das ist weit übersichtlicher, früher hat hier jedes Unterprogramm dreingeredet und wenn ich was ändern wollte, ging die Sucherei los.
Fertig ist das Ganze noch nicht, da je nach Bedarf völlig verschiedene Dinge ablaufen, aber es wird.
Und mit jeder Verbesserung gehts einfacher....

Der Akkutest ist auch bereits überarbeitet- ich suche allerdings noch ne Möglichkeit, bei leerem Akku möglichst vieles abzuschalten, das wird aber wohl ohne weitere Hardware nich klappen. Für den Moment wird bei unter 6V immerhin das Display abgeschalten (nicht wirklich, sondern nur die Beleuchtung).
Vorher wird die Restspannung in vier Stufen grafisch (hab ich mir einfach vier eigene Zeichen definiert) ausgegeben.

Insgesamt ist die Software stark umstrukturiert, da ich alles in Einzelne dateien aufteilen werd. Das macht die Pflege enorm einfacher.
Bisher sind es sieben Dateien....und es werden noch mehr. Möglich aber, dass ich später nen paar Sachen wieder zusammenfasse, die Tabs der Arduino-Ide sind zwar praktisch, aber zu viele davon auch wieder nicht.

Natürlich gab es auch nen paar Rückschläge.
Zum Beispiel den, dass sich der NMEA-Parser plötzlich weigerte, die Positionsdaten achtstellig rauszurücken. Es tauchten immer nur sieben Stellen auf. Warum, weiss ich nicht- früher trat dieses Problem nur "sehr selten" mal auf- ich hatt es aufgefangen, indem ich das Ganze bei unglaubwürdigen Ergebnissen einfach noch mal laufen liess.
Funktionierte- bis vorgestern. Dann kam er aus dieser "rechne noch mal-Schleife" nicht mehr raus.
Dauert ne Weile, bis einem auffällt, dass die Zahlenkolonnen ne Stelle zu wenig haben, glaubts mir... ;)
Als ichs rausgefunden hatte,war die Sache leicht: wenn ne Stelle zu wenig ist (es wurde ja immer die letzte abgeschnitten) nehmen wirs mal Zehn- das entspricht ner so verschwindend geringen Auflösung (ich glaub, Millimeterbereich) dass es keinen interessiert.

Die Borduhr (die derzeit nur im Demo-Modus genutzt wird, aber später evtl. auch für Logging oder ähnliches) möcht ich auch noch bissel aufbohren. Die Zeitzone wird bereits korrigiert, aber Sommer-und Winterzeit-Umstellung noch nicht (momentan eh egal). Das möcht ich einfach noch drin haben.

Es bleibt spannend....

[Rabenauge]

Nen bisschen weiter ging es...

Der Demo-Modus zeigt nun auch "Wetterdaten" an. Momentan hat er dazu allerdings nur nen LM35 (der ist in der Karosserie verbaut, den will ich später eventuell nutzen, um zu niedrige Temperaturen (oder auch zu hohe) detektieren zu können).
Dazu kommt dann noch ein DHT11 Kombisensor (Luftfeuchtigkeit und Temperatur), der natürlich dann im Freien montiert wird.
Der sollte heute bereits da sein- aber offenbar sind einige Händler nicht in der Lage, sowas richtig zu verpacken-ausser ner leeren Tüte (samt nem Loch drin) kam nix an.
Ich bekomm nen neuen...
Damit hab ich dann für die übliche Frage "und wozu isses gut???" die perfekte Ausrede: "ne autonome Wetterstation, was sonst??". :)
Wär im Grunde möglich, das Monster jeden Morgen ne Runde durch den Garten zu jagen "mal gucken, wie es draussen ist heute"- wenn ich denn nen Garten hätte....

[Rabenauge]

So. Auch der DHT11-Sensor ist da, verbaut und-läuft.
Nun kann ich die Luftfeuchtigkeit ausserhalb der Karosserie, also im Freien, sozusagen, messen, und die Temperatur auch aussen, und zusätzlich unter der Haube.
Ich denke, das gibt dann in naher Zukunft noch ein Stückchen Software, bei dem, während der Fahrt, Wetterdaten gesammelt und auf die SD-Karte geloggt werden.
Vorerst aber kümmere ich mich um wichtigeres- jetzt ist erst mal der Routen-Navi-Modus dran.
Der läuft zwar als standalone-Programm schon lange, aber ihn in das Auto zu integrieren, bereitet doch einige Schwierigkeiten mehr, als ich dachte.
Naja- wird schon werden...

[ChrisiB86]

Hallo!

Bin neu hier in diesem Forum und habe jetzt sehr aufmerksam die Vorstellung dieses Projektes gelesen, finde es total super!

Mich würde jetzt interessiern ob es auch Videos gibt, die das Ding in action zeigen?

Mfg Christian

[Rabenauge]

Nö, gibts nicht.
Bis vor nen paar Monaten hatte ich keine brauchbare Kamera (inzwischen schon) aber ich komm grad nicht zu, was am Monster zu machen. Aktuell hänge ich da nen bisschen fest, denn das U-Center (mit dem ich das GPS konfiguriere) läuft unter Linux nicht und nen Windows gibt es bei mir nicht mehr.

[Rabenauge]

So.

Nun geht es hier endlich mal weiter.
Eigentlich ist "weiter" nicht ganz richtig, das Ganze ist fast ein Relaunch- aber noch mit der selben Hardware.
Nach längerer Pause und vielen Überlegungen hab ich mich entschieden, die Software komplett neu aufzubauen.

Grund ist vor allem der, dass ich mich ganz schön vertüdelt hatte, und eine Menge Geschichten zwar liefen, aber keineswegs optimal.

Eines der ersten Probleme ist inzwischen beseitigt: das U-Center läuft nun auch unter meinem Linux. War eigentlich gar nicht schwierig, aber man muss auch Lust haben, mal in der Konsole rum zu schrauben.
Neulich hatte ich die und seitdem geht das schon mal.

Da demnächst auch nen bissel Budget in der Bastelkasse eintrifft, wird es auch kleinere Änderungen am Auto geben.
Die Wichtigste: langsamere Motoren.
Vermutlich Carson Poison Truck- die drehn ungefähr halb so schnell. Ich hoffe, die ziehn trotzdem ausreichend durch, das Auto soll wie bisher _jede_ Steigung schaffen können. Bin da aber recht optimistisch..
Eventuell spendiere ich auch noch nen neuen Akku- dezeit ist mein letzter, noch voll einsatzfähiger NC-Pack drin. Auch der wird nicht mehr das ewige Leben haben, befürchte ich (leider).

Aktuell habe ich mal die GPS-Bibliothek gewechselt, statt der TinyGPS würd ich gerne die TinyGPS++ verwenden.
Die ist zwar deutlich rechenlastiger, hat aber das Navi schon eingebaut (sie kann Kurs und Entfernung berechnen)- das musste ich mit der kleinen Bibliothek selber machen. Mangels Mathematikkenntnissen war das schon schwerer Tobak- und ergab trotzdem gelegentlich nen Fehler, dessen Ursache ich nie gefunden hab (ich hatte einfach ne grobe Überprüfung hinterher gesetzt, die sicher stellte dass nur glaubwürdige Ergebnisse auch berücksichtigt werden). Hat funktioniert, ist aber schon Pfusch...
Momentan fahre ich mal einige Tests mit der TinyGps++, um mal zu sehen, was die an Rechenleistung übrig lässt....

Anschliessend werden so nach und nach die anderen Hardware-Komponenten auch wieder in Betrieb genommen. Besonders der Kompass war ja auch so ein spezieller Freund...;)

[Rabenauge]

So-kleinerer Fortschritt: ich hab mir mal ein Testprogramm geschrieben, was mir angibt, wie lange die Berechnungen des GPS dauern.
Das Ergebnis gefällt mir: um die 4ms.
In dieser Zeit wird: das GPS ausgelesen, die Daten aufbereitet und ausgewertet. Ausserdem noch die Differenz zu einem gegebenen Punkt berechnet und auch noch alles seriell ausgegeben (letzteres ist nicht besonders schnell).
Damit ist klar: Zeitprobleme wirds mit der TinyGps++ nich geben, das war eine meiner Hauptsorgen, da ja der Prozessor noch _einige_ andere Sachen zu erledigen hat später.
Da die serielle Ausgabe später entfällt, wirds sogar noch bissel schneller....ausgegeben werden die Daten ja nur, wenn das auch Sinn macht, unterwegs natürlich nicht.

[Rabenauge]

Sodele.
Schon gibts das erste Problem: den Kompass.

Das Teil funktioniert nämlich nur ausreichend genau, wenn er halbwegs kalibriert wurde.
Zumal er im Truck in nem alles andere als störungsfreien Umfeld betrieben wird- ich _will_ ihn einfach nicht auf ne Art Mast setzen oder ähnliches. Das geht auch anders.
Wie, ist dort: http://diydrones.com/profiles/blogs/advanced-hard-and-soft-iron-magnetometer-calibration-for-dummies sehr schön beschrieben.
Genau ander da gibts mal wieder ein Problem: MagMaster läuft _nich_ unter Linux. Mit Wine schon, aber es findet da keine seriellen Ports....auch nicht wenn man für Wine diesen symbolischen Link benutzt- das Progrämmchen kommt damit einfach nicht klar.
Also mal wieder am Rechner rum basteln- ich versuch es mal mit VirtualBox.

[Rabenauge]

Soo. Das Auto wird wieder zurückgebaut auf RC...:cool:
Natürlich nur vorübergehend....:D

Ich hab nämlich die Carson Poison Truck-Motoren bekommen, und will mal sehen, ob die leistungsmässig ausreichen werden. Ehe ich da jetzt grosse Testprogramme schreib, häng ich einfach mal nen RC-Empfänger rein, und probiere sie aus.
Heute wird ni mehr, aber zum Sonntag werd ich die mal gemütlich rein schrauben und dann darf das Auto mal wieder ferngesteuert ein paar Runden drehen.
Steigungen sollte er schon genauso souverän meistern wie bisher, da will ich keine Abstriche machen. Es ging ja nur darum, das Tempo auf ein sinnvolles zu reduzieren.
Gucken wir mal...

[Rabenauge]

Soo-die neuen Motoren sind drin (ich liebe Tamiya- so nen Motor wechselt man problemlos in 2 Minuten), nen Empfänger auch. Nun wart ich auf die Ladegeräte und dann wird probe gefahren.

Nebenbei hab ich mir mal nen LiPo (im Hardcase) bestellt, mit 3Ah sollt es ne anständige Weile gehen. Das Auto lief ja schon mit nem 1900er NC-Akku um die 20 Minuten im RC-Betrieb. Als Roboter ist der Stromverbrauch eher deutlich geringer, da ja dann nicht so herumgetobt wird und wenn sich die Truck-Motoren bewähren, braucht der Antrieb eh deutlich weniger als bisher.

[morob]

grins man ärgert sich immer wie kurz der akku hält. der roboter hält mindestens dreimal so lange :D

[Rabenauge]

Ärgern?
Bin früher (tm) Wettkämpfe gefahren, in den 90ern, da durften wir nur Akkus mit max 1200mAh benutzen (ich glaub man ging dann auf wahnsinnige 1300 rauf)- die haben wir in vier Minuten verbraten. Zehn Minuten Ladezeit, wenn es schnell gehn musste. Das ging (und geht bis heute) _nur_ mit NC-Zellen, da kommen auch wirklich gute LiPo noch immer nicht ran.
Zumal die NC-Akkus das klaglos ne komplette Saison mitgemacht haben. Nen richtig gestressster LiPo ist nach 100 Zyklen hin.
Aber leider gehn mir inzwischen die _guten_ NiCd-Akkus allmählich aus....:(

Den Tamiya hab ich früher mit bis zu acht Zellen gefahren, aber so lange Akkus passen nicht mehr rein, weil die Träger für die seitlichen Sensoren im Wege sind. Ausserdem bringt das als Roboter nichts, funny ist das nur als RC-Modell.

Wie weit ich das Spiel mit dem Auto mal treibe, weiss ich noch nicht, aber ich könnt mir gut ein faltbares Solarpanel auf der Ladefläche vorstellen irgendwann. Aber später erst- wenn mal überhaupt.

Ich denke aber, dass ich vorerst mit dem LiPo schon ne ganze Weile hinkommen werde. Fahren konnt ich leider bisher nicht, da es ab und zu geregnet hat und ich das Auto nicht unnötig einsauen will- so leicht wie als RC-Fahrzeug wär er nicht mehr zu reinigen (früher hab ich einfach den Akku rausgenommen und das Ding dann in der Badewanne abgeduscht).

Ach ja: hat jemand ne Idee, wie ich den Akku an Bord vernünftig überwachen kann? Zwei Analogeingänge wären am Bordrechner noch frei aber wird das ausreichend genau, wenn ich da jede Zelle einzeln anschliesse (wär vom Aufbau her kein Ding, da nen Balanceranschluss sowieso dran ist)?

[morob]

ist ja gut, ich wollte keine wehmut erzeugen :D

lipo nee, bei nimh nehme ich ein spannungsteiler. eine idee eine analogschalter mux pro akku, durchschalten und messen.

[Rabenauge]

Nene- schon gut. Jammern nutzt nix...:cool:
Wann hast du denn mal Zeit wegen dem Kompass-MagMaster-Linux-Problem?
Ich blicke da nix, einfach so compilieren klappt irgendwie nich....

[morob]

ist mir durchgefallen, ich hatte die letzten 14 tage stress im privaten bereich (gesundheitlich).
das nächste we sieht gut aus, vielleicht kann ich es mir auch mal die nächsten tage ansehen, ich werde es ja auch benötigen zur innenraum navigation :D

[Rabenauge]

Stimmt, da kann man auch was mit anfangen. Ich hab ja auch ne MPU 6050 drauf, da könnte man auch mal ein Weilchen unabhängig vom GPS navigieren. Dürft allerdings für den Atmega 2560 nen bissel viel werden, zumal ich keine Odometrie habe.
Und ob ich _die_ jemals nachrüste, ist fraglich, draussen brauch ich sie eigentlich nicht.

[Rabenauge]

Derzeit bin ich eher faul, aber es tun sich kleine Dinge.

Immerhin: der neue Akku ist da. Natürlich-obwohl er die "Car-Ausführung" (passende Form und Hardcase) ist, passt er _nicht_ in die Tamiya-Standard-Halterung. Er ist nämlich minimal dicker als ein Racingpack.
Also ausschleifen, und nun sitzt er- so stramm, dass ich den nicht sichern brauche.
Schnelle Akkuwechsel sind somit Geschichte- hach, früher war alles besser, oder?
Na gut, dafür hab ich ja nun 3Ah an Bord- ne Weile reicht das.

Bei der Gelegenheit hab ich gleich mal den Tamiya-Stecker rausgerupft- die Dinger sind ungemein praktisch, taugen aber ansonsten nich viel. Nun ist Dean verbaut- nicht praktisch (die Dinger sind viel fummeliger und gehen seeeehr stramm), aber besser für die Stromführung allemal...
Anschliessend musste ich die Bordspannung (ist ja nen eigener Spannungsregler verbaut) allerdings neu einstellen. Da kamen gleich um die 7V an...bissel viel.
Ach ja: da muss noch ein Interface gebaut werden, mit dem ich den LiPo überwachen kann.
Balancerstecker hat er ja, ich möcht gerne ne einzelzellen-Überwachung haben.
Sind ja nur zweie...da fehlt mir aber noch nen bissel ein Plan.


Anschliessend nen kleiner Test: es funktioniert so. Allerdings muss ich mich mal in Ruhe hinsetzen, und rausfinden, wie ich das grosse (20x4) Display früher angesprochen hatte. Hab da nen Testprogramm, mit dem es auch funktioniert, aber das ist nen komisches Gewurstele, das geht besser.
Wahrscheinlich war es ne andere Bibliothek....

So lange das MagMaster-Problem nicht gelöst ist, werd ich mich mal an die SD-Karten-Sache ransetzen demnächst, ich gedenke, die zukünftig noch intensiver zu nutzen (z.B. Wetterdaten loggen oder auch den Weg aufzeichnen), und natürlich will ich die Wegpunkt-Navigation wieder haben (festgelegte Routen, die aus mehreren Wegpunkten bestehen, und vorher auf der Karte abgelegt wurden).
Beliebig ausbaubar, wenn ich die Sache erst mal _richtig_ beherrsche, bis hin zur Routen-Optimierung....

[Rabenauge]

Gehts hier nicht weiter?
Dochdoch, nur laaangsam. Mit dem Steckerwechsel und der Neujustierung des Spannungsreglers war es nicht getan.
Ich hatte ja auf der Stromversorgungs-Platine auch nen Akku-Spannungs-Sensor verbaut. Der ist so allerdings nicht mehr zu gebrauchen, da der LiPo voll geladen mehr als 10V im Leerlauf hat.
Daher werd ich die Platine neu aufbauen müssen- und eventuell auch gleich nen zweiten Regler einbauen, um mehr Luft für weitere Spielereien (später) zu haben.
Als Regler benutze ich immer sowas: http://www.ebay.de/itm/5x-LM2596S-DC-DC-Step-Down-Schaltregler-Schalt-Netzteil-Modul-Wandler-Konverter-/121499378192, für das Geld kriegt mans nicht selber gebaut.
Da ich dazu nahezu alle Kabelbäume auseinander nehmen muss, wird das ne Weile dauern, Aber es lohnt sich, denk ich, da die erste Version schon ziemlich an ihre Grenzen gelangt war (zu wenige Buchsen auf der Ausgangs-Schiene).

[morob]

lieferzeit für den regler?

[Rabenauge]

Je nachdem- meist kommen die aus China. Da kanns 2-4 Wochen dauern. Ich bestell die gewöhnlich auf Vorrat (Fünferpack), so kann man rechtzeitig Nachschub ordern.
Die vom Link liegen wohl bereits in Deutschland, da geht das recht schnell.

[Rabenauge]

Verzweiflung breitet sich aus.
Nachdem der Plan für die neue Stromversorgung im Grunde steht, der Platz ausgemessen und alles so weit ist, treibt mich dieser Akku in den Wahnsinn.
Angeblich ein 2s, 7.4v- und ich messe an dem Ding immer wieder deutlich über 11V.
Dass mein Mutimeter rumspinnt, glaub ich nicht, ist nen Voltcraft VC130...und so schwer daneben schätzen würde wohl nicht mal ein ganz billiges.
Eben hab ich den Verkäufer (SLS) mal angeschrieben, obs dafür eine sinnvolle Erklärung gibt. Wäre ja schon wichtig, für den Spannungsteiler zur Akku-Überwachung.
Bin mal gespannt, was dabei raus kommt.
Blöd jetzt: ohne den Spannungsteiler (der muss unter den Spannungsregler, aus Platzgründen) komm ich nun nicht weiter.

[nikolaus10]

Hallo


Du kannst sehr scnell selbst feststellen ob du einen 2S (7,4V) oder einen 3S (11,1V) hast.

Am Balanceranschluss. Hast du 3 Anschluesse ist es ein 2S bei 4 Anschluessen ist es ein 3S.
Am Balanceranschluss kannst du auch die einzelnen Zellen nachmessen.


KR und 73

[Rabenauge]

Ist nen 2s. So ganz unerfahren bin ich mit LiPo' s nicht. :cool: Die Dinger benutze ich seit vielen Jahren für meine Flugmodelle (und nen RC-Motorrad).
Und mir kam ne Eingebung: mal ans Ladegerät damit...Ergebnis: der Akku ist okay, aber das Multimeter misst Mist.:( Das Ding zeigt ne deutlich höhere Spannung an, als wirklich da ist (ne 1.5V-Trockenbatterie hat angebliche 2.2V)- ich werd mal die Batterie im Multimeter auswechseln, obwohl die eigentlich bei ner Spannungsmessung kaum einfluss haben dürfte- oder doch?

[MisterMou]

Na aber sowas von ;)

Im Multimeter ist eine Spannungsreferenz verbaut, die versorgt werden möchte. Reicht die Versorgung nicht aus, stimmt die Referenz nicht.
Um eine Spannung digital messen zu können, muss sie mit einer bekannten Größe verglichen werden, der Referenzspannung.
Stimmt die Referenzspannung nicht, kommt sowas wie bei dir raus.

Die Spannungsreferenz wird natürlich nicht mit der zu messenden Spannung versorgt, sonst würde das die Messung verfälschen.

Nur weil das Display vom Multimeter funktioniert, ist das leider kein Indiz dafür, dass die Spannungsmessung sauber arbeitet. Oft gibt es extra dafür eine Warnanzeige im Display.

[Rabenauge]

Die ollen Zeiger-Multimeter konnten das ohne Batterie noch....und bei meinem stand die Batterieanzeige auf halb voll.
Aber: mit ner frischen ist das Problem nun wirklich beseitigt- und schon hat der Akku wieder anständige 8.24V.
Passt.

[RoboHolIC]

das Multimeter misst Mist.:( Das Ding zeigt ne deutlich höhere Spannung an, als wirklich da ist (ne 1.5V-Trockenbatterie hat angebliche 2.2V)
Genau die selbe Symptomatik hatte ich mal bei einem 10DM-Gerät. Batterieanzeige passte nicht zur Wirklichkeit, genauso wie die Messwerte. Ich hab dann das Gerät erneuert, weil ich nicht vor jeder Messung erst anhand einer Referenzspannungsquelle mein Vertrauen in das Messgerät kalibrieren wollte.

[Rabenauge]

So viel teurer war das Teil auch nicht- ich glaub, um nen 20er (allerdings schon €). Eigentlich mag ich das Ding, weils ne schöne Antirutsch-Beschichtung hat. Auch wenn der Nachfolger irgendwann ein oder zwei Preisstufen höher liegen wird (nen paar Funktionen vermisse ich), will ichs nicht wegwerfen jetzt.
Vermutlich hatte ich die Batterie-Anzeige einfach falsch interpretiert- jetzt ist nämlich gar keine zu sehen, das soll wohl ne Warnung sein.

Na schön-nachdem das geklärt ist, gehts weiter. Erst mal hab ich mir ein Y-Kabel mit Dean-Anschlüssen gebaut. So kann ich sowohl den (RC-) Fahrtregler als auch die Stromversorgung der Bordelektronik parallel an den Akku anschliessen. Das hat Vorteile: ich kann einen der Stecker ziehen, nen RC-Empfänger auftackern, Regler und Lenkservo umstecken und hab ein voll funktionsfähiges RC-Auto, wie früher. Ausserdem kann ich die Servos (und natürlich den Fahrtregler) über den normalen RC-Schalter abschalten, aber die Elektronik trotzdem in Betrieb nehmen- hier im "Labor" entschieden besser, so nen 1/10er Monster kann nämlich einiges demolieren.
Das hatte ich zwar schon ähnlich aufgebaut, aber uneleganter..
Dafür wird die Stromversorgungs-Eigenbau-Platine nun grösser. Da passt nachher ein zweiter der genannten Spannungsregler drauf, den ich aber momentan nicht bestücke.
Kann ich aber jederzeit leicht nachrüsten, wenn er gebraucht wird.
Da die Servos ohnehin über das Regler-BEC versorgt werden, komme ich momentan mit dem einen Regler aus, hab da aber nen paar Sachen im Hinterkopf für "später".
Auf die Platine kommt auch gleich ein anständiger I2C-Bus, da hab ich ja doch mehrere Geräte (das Display, der Kompass, Neigungs-bzw. Beschleunigungsmesser), und auch die Verteilerschiene für die Servos.
Und natürlich ein Spannungsteiler um den Akku überwachen zu können (keine Einzelzellen-Überwachung allerdings).
So hab ich dann nen paar Strippen weniger rum schwirren.
Mal gucken, was dann noch an Platz über bleiben wird, eventuell kann ich noch ne Kleinigkeit mit rauf bauen.

[Rabenauge]

Gestern kam mir ein heimtückischer Gedanke:
die "Fahrsteuerung" läuft über gewöhnliche RC-Komponenten. Die haben auch eine eigene, völlig unabhängige Stromversorgung (BEC vom Fahrtregler). Das deshalb, weil so zum einen das Lenkservo bei "Überlast" nicht den Rechner zum Restart bringen kann, und zum anderen, weil das BEC sowieso da ist. Und: der Regler hat nen eigenen Schalter, so kann ich auf dem Basteltisch die Fahrfunktionen problemlos (und _sicher_ ) deaktivieren. Per Software zu erkennen, ob der Arduino am USB-Kabel hängt, ist mir nämlich noch nie sicher gelungen...
Der Servo"Bus" (genauso aufgebaut wie in nem RC-Empfänger, Plus und Masse als Schienen, Signal jeweils einzeln) sitzt ja auch auf der Stromversorgungsplatine. Wenn ich nun von BEC 5V eine Strippe zu nem digitalen Eingang des Mega 2560 legen würde, könnt ich per Software feststellen, ob die Fahrfunktion überhaupt eingeschalten ist.
Eingänge sind genug da, also warum nicht...eventuell noch nen Spannungsteiler dazwischen, um sicher zu stellen, dass es wirklich nie mehr als 5V sind (RC-Komponenten sind da erstaunlich un-pingelig), und gut- oder sollte man das besser lassen?
Gemeinsame Masse hab ich sowieso-alles liegt an der selben Masse in dem Auto. Aber eben einmal 5V vom BEC und einmal vom Spannungsregler der Elektronik..

[Rabenauge]

So- die neue Stromversorgungsplatine ist fertig (zumindest vorerst).
Sie enthält nun zwei StepDown-Schaltregler. Jeder hat ne längere Buchsenleiste erhalten, um die diversen Gerätschaften einfach anstecken zu können.
Weiterhin ist ein Spannungsteiler drauf, mit dem ich den LiPo zumindest rudimentär überwachen kann, um Tiefentladungen zu verhindern.
Ausserdem eine I2C-Schiene, an die ich 8 Geräte einfach anstecken kann, sowie ein Servo"bus" (ähnlich wie in RC-Empfängern) mit 7 Steckplätzen. Der allerdings wird nicht von den Schaltreglern versorgt, sondern momentan über das BEC vom Fahrtregler. Da hängen aktuell auch lediglich Lenkservo, Fahrtregler und das kleine Servo für den Heck-IR-Sensor dran, viel mehr sollt es auch nicht werden.
Durch den zweiten Step-Down-Regler erhoffe ich mir mehr Reserven, denn bekanntlich hatten die vier US-Sensoren ja Reichweitenprobleme. Das _kann_ auf zu niedrige Spannung hin deuten, und die Stepdown-Module werden zwar mit "bis zu 3A" beworben, aber anderswo las ich, dass sie das lange nicht schaffen.
Nen bissel Platz ist noch auf dem Stück Lochrasterplatine, da kann ich später ggf. noch die eine oder andere Kleinigkeit nachrüsten.

Und es gab noch nen Umbau: anstelle des Micro-SD-Slots (den ich von der Rückseite eines verstorbenen TFT's recycled hatte) sitzt nun ein grosser SD-Karten-Halter auf dem Chassis. Aus Bequemlichkeit: mein Laptop hat nur nen grossen SD-Slot. Will ich Daten auf die MicroSD schreiben, muss ich sie aus dem Monster fummeln, in nen Adapter packen, und den dann in den Laptop. Danach das Ganze retour- das ging mir auf die Nerven, zumal der kleine Slot mit nem Mini-Blech-Kläppchen versehn ist. Nun hab ich es viel bequemer, ne alte 1GB-Sd-Karte dient jetzt als Festplatte.

In den nächsten Tagen werd ich mal alles wieder anstecken, und mal schauen, wie sich die US-Sensoren nun schlagen.
Es bleibt spannend...

[Rabenauge]

Hab mal wieder was gemacht (zu irgendwas muss nen Krankenschein ja auch gut sein ;) ).
Mit den US-Sensoren hab ich nun lange rum experimentiert: mehr als 1.20m Reichweite werden es nicht. Bei schlechtgelaunter Technik noch etwas weniger.
Die Dinger werden also mal ausgetauscht.
Inzwischen hab ich aber auch das Display im Monster (immer noch das 20x4 LCD, dabei wirds wohl auch bleiben) wieder in Betrieb, und die Messung der Akkuspannung läuft auch schon mal.
So nach und nach werden nun die übrigen Geräte auch wieder verkabelt.
Der Joystick isses schon, nur noch nicht programmiert.
Als nächstes aber werde ich die Fahr-und Lenkfunktionen wieder implementieren, damit ich -endlich- mal die neuen Motoren testen kann. Womöglich sind die langsam genug für die kurzsichtigen Sensoren...

[Rabenauge]

So-die Antriebe laufen auch wieder. :)
War, wie üblich nen bissel tricky, da der dämliche RC-Car-Regler so seine Eigenheiten hat, aber nun klappt zumindest vorwärs fahren schon mal wieder. Schön bequem: vom Hauptrogramm (oder später sonst wo her) wird einfach die gewünschte Geschwindigkeit in % an die Funktion "beschleunigen" übergeben.

Falls jemanden einzelheiten interessieren: der Regler startet die Motoren nur dann, wenn er vom "Empfänger" ein Signal "Steuerknüppel ist in Mittellage" bekommt. Sicherheit- eigentlich sinnvoll.
Der Haken: das Ding muss auf die Fernsteuerung angelernt werden. Einmal nur, aber danach muss man genau das, was man da als "Neutralstellung" definiert hatte, auch anbieten.
Wenn man also rein mit Controller arbeitet, bleibt einem nix anderes übrig, als ein Kalibrier-Programm zu stricken, um die Wege überhaupt erstmal einlernen zu können.
Zum Glück hat der Regler immerhin zwei LED's, mit denen er mitteilt, was er gerade zu verstehn glaubt, das half mir bissel.
Spassig wird die Bremse: die funktioniert so, dass bei Steuerkommando rückwärts für eine gewisse Zeit(rund 2s) gebremst wird. Danach erst wird in den Rückwärtsgang geschalten. Allerdings proportional (wie clever...): wenn ich länger als 2.5s voll bremse, spurtet das Ding sofort rückwärts los! Das brachte mir in der vorherigen Version derartige Spannungseinbrüche, dass der Controller jedes Mal neu gestartet ist, wenn nicht wenigstens 5s Stillstand dabei waren.
Dieses Mal will ich versuchen, auch das anständig zu lösen.
Mal sehn, ob ich es schaffe.
Das Lenkservo hängt auch schon wieder im System, allerdings zittert es noch arg, wenn die Motoren laufen, da muss ich mir noch was einfallen lassen.
Ferritringe oder so, mal gucken. Entstört sind die Motoren eigentlich ab Werk schon...

Und ich hab zwei Hardwarebugs gefunden: der erste war niederschmetternd. Fahrtregler lief, Servo nicht. Nach längerem rumprobieren mal gemessen: die Plus-Schiene vom Servobus war gar nicht durchgehend. Konnte so nich klappen.
Das zweite ist eigentlich nur ein Schönheitsfehler: der "Hauptschalter" schaltet _nicht_ alles aus, sondern der Regler (und damit das BEC) bleiben an. Aus Sicherheitsgründen hab ich nämlich den BEC-Schalter des Reglers separat, so kann ich beim programmieren den gesamten Antrieb sicher deaktivieren. Da es _niemals_ nötig ist, das Fahrwerk ohne die Elektronik einzuschalten, werd ich den Hauptschalter (eh nen dreipoliger) einfach mit ins BEC-Schalterkabel einschleifen.
Richtig schön wäre hier ein Relais (oder nen Transistor??) der vom Bordrechner das BEC ein-bzw. ausschalten kann.
Müsste doch mit nem lausigen Transistor (und nem Basiswiderstand) zu machen sein, oder?

[morob]

guten morgen,

das müssen nicht die motoren sein, ich kenne das problem auch.
fernsteuerung, esc und servos, da werden die timer etwas überlastet, ich bin dann auch eine größere plattform umgestiegen pic32.

stephan

[RoboHolIC]

Hallo Stephan.

Was konkret war in deinem Fall das Problem? Mich interessiert das wirklich! Aber so, wie du es geschrieben hast


. . . da werden die timer etwas überlastet . . .

sehe ich da eine qualmende oder schweißtriefende Kaskade aus D-Flipflops vor meinem geistigen Auge ;-).
Geht es um zu viele quasi-gleichzeitige Aufgaben für ein einzelnes Timermodul, um deren programmiertechnische Schachtelung, ...?

Bitte nur ganz kurz, damit wir nicht Rabenauge's Thread kapern, ja ?!

Gruß
Christian.

[Rabenauge]

Es ist kein Timer-Problem. Der Mega 2560 packt lässig mehr als nen Dutzend Servos. Bis zu 48 Stück, glaube ich.
Nen RC-Empfänger hingegen ist bei mir überhaupt nicht im Spiel-ich brauch ja keinen.

Hab ich aber auch schon gemacht. In meinem Seeteufel bedient ein Mega 2560 5 Servos, Fahrtregler, nen Portexpander für die Beleuchtung, liest 4 RC-Kanäle ein und überwacht nebenbei noch die Akkus usw.
Da gab es anfangs auch etwas Trouble, ist aber ohne Probleme am laufen inzwischen.
Allerdings, die klassische Methode, RC-Signale mittels PulseIn einzulesen, versagt da wirklich kläglich. Das dauert viel zu lange...
Da hatte ich diese Lib. benutzt: http://www.rcarduino.tk/

[morob]

ich hatte ein uno verwendet.
rxtx (pulsein), esc und servo klassische methode :(

danke für den link

[Rabenauge]

Wenn man ungefähr weiss, was kommt (oder nich kommen kann), kann man PulseIn bedeutend beschleunigen, indem man ein knappes Timeout setzt.
Das Problem ist, wenn nix kommt, wartet der Arduino bis zum "eingebauten" Timeout- ich glaub, ne volle Sekunde. In der wartet er wirklich nur, das ist also genauso böse wie delay()...
Da klappt dann halt nix anderes mehr.
Zusätzlich kann man Servos oft entkoppeln (myServo.detach()), grad bei Servos, die nur nen Sensor schwenken oder so geht das ohne weiteres, die bleiben dann einfach in der letzten Stellung stehn. Fahrtregler allerdings könnten dann ins failsave fallen, in der ersten Version des Monsters hatte ich das genutzt, um den Antrieb per Software zu entkoppeln: Lenkung geradeaus stellen, Fahrtregler auf stop, und dann beide abschalten.
Wenn das Monster dann seine aktuelle Aufgabe kannte, wurden beide mittels myServo.attach() wieder zugeschalten, und die Fahrt konnte losgehen. So kann man z.B. in Ruhe erst mal irgendwelche Parameter übergeben, oder die Betriebsart auswählen, ohne um die Finger fürchten zu müssen.
Das baue ich ganz sicher auch wieder ein, wobei es mir noch besser gefiele, wenn ich das BEC (was ja Lenkservo und Regler versorgt) direkt per Programmierung abschalten könnte. Nen Relais in das BEC-Schalterkabel wäre ne Möglichkeit, aber mit nem Transistor müsste das doch eleganter (und vor allem: weniger anfällig) gehn?

[morob]

du hast ein klassische frequenz von 50hz, das heißt man könnte das timeout auf 2 perioden legen. das wären dann maximal 40ms, ich muß mir das noch mal anschaun.
ein servo für sensoren habe ich nicht, nur lenkung und esc.

[Rabenauge]

50 Hz?
Servo-Pwm läuft schon bissel schneller.
Standard ist z.B. myServo.writeMicroseconds(1500).
Das sollte die Neutralstellung sein. Probiers aus, myServo.writeMilliseconds() kennt die IDE gar nicht.
Der übliche Bereich liegt zwischen 1000 und 2000 Mikrosekunden. Je nach konkretem Servo geht auch bissel mehr.
Beim abschalten von Servos muss man übrigens auch aufpassen, dass man dem Servo Zeit lässt, um die Soll-Position überhaupt anzufahren. Die kleinen Rechner sind ja doch nen bissel flinker als die olle Servomechanik.

[morob]

grins ich meinte die wiederholfrequenz der servoimpulse, mich nicht ganz klar ausgedrückt.
das timeout für das servosignal sollte also bei 40ms (2 signale) liegen.

[Rabenauge]

Trotzdem sind Interrupts entschieden effektiver. Da weiss der Rechner nämlich, wann etwas passiert ist, und muss nicht dauernd erst nachgucken gehn. Ab und zu gibts ja noch ein paar andere Dinge zu erledigen.
Willie Klaas hat das in seiner Bibliothek schon eingebaut, und es funktioniert hervorragend.

Und: auch die Servobibliothek hat ihre Tücken. Unter Umständen belegt sie nämlich, ohne zu fragen, bestimmte Timer, die dann anderswo plötzlich nicht mehr arbeiten. Das ist aber dokumentiert. Irgendwann will ich mal Servos "zu Fuss" programmieren, aber nicht hier- die Software für das Monster wird mir auch so anspruchsvoll genug.

Jetzt werd ich doch mal versuchen, ob ich den Fahrtregler nun doch überreden kann, vernünftig zu bremsen- ich find das wichtig, weil die Fuhre ja doch _bisselwas_ wiegt.
Selbst im Leerlauf, also aufgebockt, laufen die Räder schon mindestens ne Sekunde nach, wenn die Motoren gestoppt werden, und da ist noch nich viel Schwungmasse im Spiel.

- - - Aktualisiert - - -

Es ist gelungen.
Vowärts fahren, bremsen (max. ne halbe Sekunde, das sollte aber auch genügen), rückwärts fahren-alles klappt.
Notfalls kann man auch mehrere Bremszyklen nacheinander aufrufen, schätze ich.

Hab das gleich mal ordentlich gemacht: es gibt ne globale Variable namens sollSpeed. Deren Wert ist die gewünschte Geschwindigkeit in % !
Somit kann das Auto leicht sowohl proportional vor-als auch rückwärts fahren. Der Wert von sollSpeed wird einfach immer auf den jeweiligen Geschwindigkeitsbereich gemappt.
Und natürlich werden die Sollwerte nicht einfach eingestellt, sondern rampenartig aus dem Stand hochgefahren. Schont die Antriebsstränge nen bissel-obwohl die mit sowas klar kommen. Das Auto verträgt so einiges...aber auch dem Akku wird das sicherlich eher gut tun.
Wenn ich mal ganz viel Lust hab, und nix besseres weiss, kann ich da womöglich noch die Fahrströme messen, und dann "wirtschaftlich" beschleunigen. Aber das steht gaanz weit hinten auf der "Kür"-Liste mit.

[HaWe]

Es ist kein Timer-Problem. Der Mega 2560 packt lässig mehr als nen Dutzend Servos. Bis zu 48 Stück, glaube ich.

der Mega hat max. 15 pwm pins, aber hier muss man sehr aufpassen, dass man nicht mit Timern in Konflikt kommt für programmierte, verwendete Interrupts - sonst funktionieren nämlich weder die betr. Timer IRQs, noch die betr. pwms:

timer - pwm pins
0 ( pin 13, 4)
1 ( pin 12, 11)
2 ( pin 10, 9)
3 ( pin 5, 3, 2)
4 ( pin 8, 7, 6)
5 ( pin 44,45,46)

[Rabenauge]

Und was willst du damit sagen?
Dass du die Servo-Bibliothek _nicht_ kennst?
Mit der isses nämlich überhaupt nicht nötig, PWM-Pins zu benutzen (im übrigen sehe ich selbst gar kein Problem drin, an _irgendeinem_ Pin selber ne PWM raus zu schicken, nur muss ich das dann eben selber machen, wie es die Servobibliothek wohl auch tut).

Details: https://www.arduino.cc/en/Reference/Servo

[HaWe]

in der Tat, deine Servo-Bibliothek kenne ich nicht, ich kenne nur Servo-Steuerung direkt über pwm-Pins. Ich hatte hier nicht gelesen, dass du es anders machst, ohne pwm-Pins.

[MEgg]

[...]
Jetzt werd ich doch mal versuchen, ob ich den Fahrtregler nun doch überreden kann, vernünftig zu bremsen- ich find das wichtig, weil die Fuhre ja doch _bisselwas_ wiegt.
Selbst im Leerlauf, also aufgebockt, laufen die Räder schon mindestens ne Sekunde nach, wenn die Motoren gestoppt werden, und da ist noch nich viel Schwungmasse im Spiel.

- - - Aktualisiert - - -

Es ist gelungen.
Vowärts fahren, bremsen (max. ne halbe Sekunde, das sollte aber auch genügen), rückwärts fahren-alles klappt.
Notfalls kann man auch mehrere Bremszyklen nacheinander aufrufen, schätze ich.
[...]

Das mit dem Bremsen und dem Nachlauf ist beim Dagu 5 (http://robosavvy.com/RoboSavvyPages/Dagu/rover5/Rover5Introduction.pdf) sogar ohne Räder ein kleines Problem.
Der Encoder meldet immer noch ein paar Ticks, nachdem ich gestoppt habe.
Mit diesen Rädern:
30897
und der Masse des Aufbaus wird der Nachlauf wohl mehr werden.
Da Beschleunigung und Encoderticks relativ linear sind, war meine Idee, daraus auszurechnen, wieviel früher ich bremsen muss, um
mit dem Nachlauf auf eine halbwegs genau Bremsung zu kommen.
Mit der finalen Masse des Rovers und Aufbaus, mit den Rädern dran und ein paar Messpunkten sollte die daraufgelegte Gerade der Abbremsung
berechenbar sein.
;-)
Oder hab ich da einen Denkfehler drin?

[Rabenauge]

Die Reifen sehn meinen verdächtig ähnlich...:) Vermutlich aber sind meine etwas schwerer: ich hab Einlagen drin, weil sie mir sonst schon im RC-Modell zu weich waren.
Ist logisch, dass die Geschichte auch mit dem Füsschen in der Luft noch nachläuft: die Motoren alleine haben ja schon ne gewisse Massenträgheit. Und die laufen _vorher_ mit einigen hundert oder gar tausend U/min...

Bremskraft dynamisch berechnen? Hm, klingt schon cool, aber ob das so klappt? Bedenke die -kaum berechenbare, weil nie genau bekannte- Traktion der Reifen, bergauf-oder ab-Fahrt usw.
Da du aber Encoder hast, könntest du die Bremse recht leicht gezielt dosieren. Im einfachsten Falle immer nur ganz kurze Bremsimpulse rauf geben, wie bei nem ABS, so ungefähr.
Wäre auf Glatteis sicher gar keine üble Sache...
Die Option hab ich auch, auch ohne Encoder (ich wüsst nicht recht, wie ich die ran bekommen sollte, und verfolg es auch nicht allzu akribisch, da ich im Grunde nicht unbedingt welche brauch), denn ich hab ja noch ne MPU6050-Platine (Kombi aus dreiachsigem Beschleunigungsmesser und dreiachsigem Gyro) an Bord. Die hab ich bisher noch nie genutzt, das aber schon vor. Auf Asphalt nämlich konnte ich das Monster mit RC seinerzeit mühelos umkippen-voller Lenkeinschlag bei Höchstgeschwindigkeit ergibt ne Rolle.
Im RC-Modell hatte ich dann einfach nen übriggebliebenen Kreisel aus nem RC-Heli eingebaut, wenn die seitliche Neigung zu stark wurde, hat der einfach die Lenkung aufgemacht.
Auch konnt man damit selbst in grobem Gelände Vollgas schnurgerade fahren, und das mit _diesen_ Rädern.
Mit nem bissel Gebastel sollte sich der Beschleunigungssensor durchaus nutzen lassen, um optimal zu bremsen. Aber damit hab ich es nicht besonders eilig, immehin hab ich ja die Truck-Motoren drin jetzt, so schnell wird das Auto damit nicht (ich schätze, nich mehr als 8-10 km/h), das ist beherrschbar.
Da eher nutze ich das Gyroskop erstmal als Geradeausfahr-Regelung. Später dann vielleicht auch als Kippsicherung, mal gucken.

[HaWe]

@MEgg:
für zielgerichtetes, punktgenaues Bremsen verwende ich einen PID-Controller. Der lässt sich so tunen, dass er bei Standardsituationen ohne Overshooting an der Zielstellung sanft gebremst ankommt, und bei Ausnahmesituationen aber auch bei Overshooting (viel Schwungmasse bei schneller steiler Bergabfahrt) notfalls oder bedarfsmäßig wieder ein Stückchen "zurückrudert".

[Rabenauge]

Heute hab ich mal das Lenkservo justiert.
Es gibt drei Konstanten: Vollausschlag links, rechts, und Lenkung geradeaus.
Da bauartbedingt nur ein Teil des möglichen Servoweges genutzt wird, läuft das Servo sonst permanent in die Anschläge, das belastet Akku und Servo unnötig.
Somit kann ich nun später berechnete Lenkmanöver recht einfach auf die verfügbaren Wege mappen, und ganz easy proportional lenken.

Ausserdem habe ich die Akku-Überwachungs-Routine weiter ausgebaut (mal sehn, evtl. mach ich das heute noch weiter), es gibt jetzt ne Variable, die mehrere Akkuzustände (momentan voll, leer und was dazwischen) annehmen kann. Die will ich dann benutzen, um mir ne grafische Akku-Anzeige aufs Display zu malen. So, wie man es vom Handy kennt, halt ne kleine, mehr oder weniger gefüllte Batterie.
Das ist relativ simpel und macht schön was her.
In der vorherigen Version hatte ich die obere Displayzeile gewissermassen als Panel benutzt, um dort lauter so kleine Info-Symbole anzuzeigen, das will ich wieder so machen. Für weitere Ausgaben stehn ja immer noch drei Zeilen zur Verfügung,. das muss eben reichen.

[MEgg]

Heute hab ich mal das Lenkservo justiert.
[...]


Demnach besteht hier ein Unterschied zu meinem Rover: der war ursprünglich für Raupen ausgelegt.
Die Reifen nehme ich, wegen grösserer Bodenfreiheit.
Ich muss aber so lenken, wie wenn ich die Raupen drauf hätte: entweder links aus für Kurve nach links
oder rechts aus für Kurve nach rechts.
Die dritte Möglichkeit, rechts vor und links zurück für Linksdrehung quasi am Stand möchte ich auch noch probieren
(invers für Rechtsdrehung).

[Rabenauge]

An deiner Stelle würde ich niemals so lenken. Wenn du eine Seite stoppst, kämpfen quasi alle vier Reifen gegeneinander.
Besser ist es, die innere nur zu drosseln, oder eben gleich andersrum laufen zu lassen.
Probier das aus, du wirst deutlich Kraft sparen.

Ich würd beides kombinieren: bei Marschfahrt ersteres, beim präzisen positionieren (oder rangieren) das zweite.

Mein Auto könnte ich auch noch wesentlich wendiger machen. Es ist nämlich symmetrisch aufgebaut, Vorder-und Hinterteil sind fast identisch, selbst die seitlichen Chassisteile sind das. Es wär sehr einfach, die Hinterachse auch auf Lenkung umzubauen, sogar mit eigenem Servo.
Vielleicht mach ich das mal, aber vorerst isses nicht nötig, wenn ich das Auto metergenau positionieren kann, bin ich zufrieden.

Und: im vorigen Beitrag hatte ich bissel gelogen: es sind nur zwei Konstanten: Vollausschlag nach links und rechts. Geradeausfahrt ist ne Variable, so kann ich die Lenkung nämlich per Software trimmen. Würde sogar rein hardwaremässig gehen, wenn ich den Hubschrauber-Kreisel wieder ins Lenkservo einschleifen würde. Dann bräuchte ich da nur das Geradeaus-Kommando hinzuschicken, und alles andere erledigt der Gyro alleine.
Aber ich _will_ das selber machen...

Gestern hab ich mir noch ein zweikanaliges Relaisboard beim Chinesen bestellt. Das soll auch an Bord gehen. Dadurch habe ich dann eine ganz bequeme Möglichkeit, das BEC auch per Software sicher zu deaktivieren, und damit Antrieb und Lenkung funktionslos zu bekommen. Das zweite Relais kann ich z.B. nutzen, um einen der beiden Spannungsregler ganz abzuschalten, und somit einige Stromfresser zu deaktivieren, wenn z.B. der Akku leer zu werden droht.
Sicher hätte man das auch mit nen paar geeigneten Transistoren leicht lösen können, aber ich hab sowas einfach nicht so gut drauf, dass ich mich sicher fühle. Und grade bei den Antrieben bin ich lieber etwas übervorsichtig, da ist schon bissel Bumms dahinter...
Das Platinchen kostet nicht mal nen Fünfer.
Weiterer Vorteil: ich kann nicht mehr vergessen, das BEC auszuschalten. Das ist mir nämlich schon mal passiert, weil es nen eigenen Schalter hat, und die LED's des Reglers komplett verdeckt sind.

[MEgg]

An deiner Stelle würde ich niemals so lenken. Wenn du eine Seite stoppst, kämpfen quasi alle vier Reifen gegeneinander.
Besser ist es, die innere nur zu drosseln, oder eben gleich andersrum laufen zu lassen.
Probier das aus, du wirst deutlich Kraft sparen.

Ich würd beides kombinieren: bei Marschfahrt ersteres, beim präzisen positionieren (oder rangieren) das zweite.

Was mir als Neuling nicht klar ist: wenn ich auf einer Seite die Motoren stoppe, müssten bei den gestoppten Motoren doch kein Kraftaufwand notwendig sein,
sondern nur bei den weiterhin laufenden etwas mehr Kraftaufwand?
Nach meinem laienhaften Verständnis würde ein blosses Drosseln der einen Seite doch dann alle 4 Motoren belasten,
während das Stopppen einer Seite nur 2 belastet?
Demnach wäre meine Idee von eine Seite vorwärts und die andere Seite rückwärts jene Variante, die alle 4 Motoren am meisten belastet?

Aber vielleicht habe ich ein Faktum vergessen?



Mein Auto könnte ich auch noch wesentlich wendiger machen. Es ist nämlich symmetrisch aufgebaut, Vorder-und Hinterteil sind fast identisch, selbst die seitlichen Chassisteile sind das. Es wär sehr einfach, die Hinterachse auch auf Lenkung umzubauen, sogar mit eigenem Servo.
Vielleicht mach ich das mal, aber vorerst isses nicht nötig, wenn ich das Auto metergenau positionieren kann, bin ich zufrieden.

Und: im vorigen Beitrag hatte ich bissel gelogen: es sind nur zwei Konstanten: Vollausschlag nach links und rechts. Geradeausfahrt ist ne Variable, so kann ich die Lenkung nämlich per Software trimmen. Würde sogar rein hardwaremässig gehen, wenn ich den Hubschrauber-Kreisel wieder ins Lenkservo einschleifen würde. Dann bräuchte ich da nur das Geradeaus-Kommando hinzuschicken, und alles andere erledigt der Gyro alleine.
Aber ich _will_ das selber machen...

Gibt es ein Foto von Deinem Auto?
"Symmetrisch aufgebaut" klingt für mich jetzt so wie "Vorderer Teil und darangekoppelt hinterer Teil" oder so.
:-)


Gestern hab ich mir noch ein zweikanaliges Relaisboard beim Chinesen bestellt. Das soll auch an Bord gehen. Dadurch habe ich dann eine ganz bequeme Möglichkeit, das BEC auch per Software sicher zu deaktivieren, und damit Antrieb und Lenkung funktionslos zu bekommen. Das zweite Relais kann ich z.B. nutzen, um einen der beiden Spannungsregler ganz abzuschalten, und somit einige Stromfresser zu deaktivieren, wenn z.B. der Akku leer zu werden droht.
Sicher hätte man das auch mit nen paar geeigneten Transistoren leicht lösen können, aber ich hab sowas einfach nicht so gut drauf, dass ich mich sicher fühle. Und grade bei den Antrieben bin ich lieber etwas übervorsichtig, da ist schon bissel Bumms dahinter...
Das Platinchen kostet nicht mal nen Fünfer.
Weiterer Vorteil: ich kann nicht mehr vergessen, das BEC auszuschalten. Das ist mir nämlich schon mal passiert, weil es nen eigenen Schalter hat, und die LED's des Reglers komplett verdeckt sind.

Ich hab diese Dinger:
http://www.amazon.de/gp/product/B014R0FBQQ?psc=1&redirect=true&ref_=oh_aui_detailpage_o04_s00
zwischen Stromversorgung und 4 Channel Motorcontroller Motorstromversorgung geschalten, da man beim Dagu 4CH Motor Controller die Motorstromversorgung nicht einschalten soll,
ohne vorher die 5V Versorgung des Controllers dranzuhängen (manche machen es gleichzeitig aber ich will sicher sein, dass hier nichts sein kann).
Geschalten wird das Relay von meiner Arduino Spider Karte.
Funktioniert wunderbar.

Späterer Plan ist, mit dem hier:
http://www.mttec.de/MTTEC-Lipo-Waechter-BS6-V5-mit-Einzelzellenueberwachung-extra-laut
vorzuwarnen und dann z.B. eine Ladestation anzufahren, Raspberry kontrolliert runterzufahren, Motorcontroller abschalten
und via Spider Arduino Karte alles erst wieder einzuschalten, wenn der LiPo wieder geladen ist.
Aber davon bin ich noch weit entfernt.
:-)

[Rabenauge]

Das Auto ist ein Tamiya Wild Dagger. Den gab es noch unter anderen Namen (da hatten nur die Felgen ne andere Farbe und die Karosserie war ne andere), Double Blaze und Dual Hunter, glaub ich.
Die Fahrwerke bestehen auf zwei kompletten (identischen) Antriebsblöcken (Motor, Getriebe, Differential), an die dann auch die Achsen montiert sind. Verbunden ist das Ganze mit den eigentlichen Chassisteilen, die sind auch identisch, nur eins ist halt um 180 Grad gedreht angebaut. Der einzige Unterschied zwischen vorn und hinten ist halt, dass hinten keine Lenkachse drin ist- aber da alles andere identisch ist, kann man die easy nachrüsten. Die beiden Antriebsblöcke sind auch um 180 Grad gedreht verbaut.

Auf das Teil hab ich dann lediglich ne Sperrholzplatte gesetzt, die die ganze Technik trägt. Am Auto selber hab ich praktisch nichts verändert, ausser das ich die 540er Standardmotoren gegen die Poison Truck-Motoren ausgetauscht habe (die laufen langsamer). Bilder gibts am Anfang dieses Threads schon. Den SD-Kartenslot hab ich auch ausgetauscht gegen einen, in den normale, grosse SD-Karten passen. Die Platte passt genau in die Karosserie und ist mit nem Schaumstoff-Streifen abgedichtet, somit ist die Technik recht gut geschützt.

Was deinen und das Lenken angeht: du kämpfst nicht gegen die Motoren, sondern gegen die Reibung der Reifen auf dem Untergrund.
Meine Reifen (die wohl die selben sein dürften) haben so viel Grip, dass das Auto im Stand gar nicht lenkt- da spricht der Servoschützer an!
Bereits aber bei langsamster Fahrt lenkt es einwandfrei...
Zwar wird dein Fahrzeug sicherlich bissel leichter sein (und somit evtl. nicht ganz so viel Grip haben), aber trotzdem muss die antreibende Seite die Reibung der stehenden Reifen überwinden. Die wäre weit niedriger, wenn die auch etwas drehen würden.
Stell dir mal ein 5-Kilo-Gewicht auf der kurveninneren Seite vor: wahrscheinlich würden dann die drehenden, kurvenäusseren Räder durchdrehen, und lenken würde gar nix...

Ich hab u.A. nen Modellpanzer in 1:16, da kann man das hervorragend sehen und hören: lenken im Stand geht so gut wie gar nicht, wenn man nicht beide Ketten ansteuert (das wiederum geht sehr leicht). Wenn die innere Kette aber auch nur minimal mit dreht, geht es bei weitem einfacher.
Da du jedes Rad einzeln antreibst, und auch noch Encoder hast, kannst du das sogar so richtig gut machen: gewünschten Kurvenradius nehmen, den nötigen Weg für jedes Rad berechnen und jeden Motor passend dazu ansteuern.

[MEgg]

Das Auto ist ein Tamiya Wild Dagger. Den gab es noch unter anderen Namen (da hatten nur die Felgen ne andere Farbe und die Karosserie war ne andere), Double Blaze und Dual Hunter, glaub ich.
Die Fahrwerke bestehen auf zwei kompletten (identischen) Antriebsblöcken (Motor, Getriebe, Differential), an die dann auch die Achsen montiert sind. Verbunden ist das Ganze mit den eigentlichen Chassisteilen, die sind auch identisch, nur eins ist halt um 180 Grad gedreht angebaut. Der einzige Unterschied zwischen vorn und hinten ist halt, dass hinten keine Lenkachse drin ist- aber da alles andere identisch ist, kann man die easy nachrüsten. Die beiden Antriebsblöcke sind auch um 180 Grad gedreht verbaut.

Schaut nett aus das Ding.
Vor allem hast Du mehr Platz drauf, als ich auf meinem Dagu 5.
:-)



[....]
Was deinen und das Lenken angeht: du kämpfst nicht gegen die Motoren, sondern gegen die Reibung der Reifen auf dem Untergrund.
Meine Reifen (die wohl die selben sein dürften) haben so viel Grip, dass das Auto im Stand gar nicht lenkt- da spricht der Servoschützer an!

Ok, ich werde wohl die Stallstrom-Überwachung entsprechend im Auge behalten müssen.



[....]Bereits aber bei langsamster Fahrt lenkt es einwandfrei...
Zwar wird dein Fahrzeug sicherlich bissel leichter sein (und somit evtl. nicht ganz so viel Grip haben), aber trotzdem muss die antreibende Seite die Reibung der stehenden Reifen überwinden. Die wäre weit niedriger, wenn die auch etwas drehen würden.
Stell dir mal ein 5-Kilo-Gewicht auf der kurveninneren Seite vor: wahrscheinlich würden dann die drehenden, kurvenäusseren Räder durchdrehen, und lenken würde gar nix...

Ich hoffe, daß ich unter 5kg bleibe.
:-)


Ich hab u.A. nen Modellpanzer in 1:16, da kann man das hervorragend sehen und hören: lenken im Stand geht so gut wie gar nicht, wenn man nicht beide Ketten ansteuert (das wiederum geht sehr leicht). Wenn die innere Kette aber auch nur minimal mit dreht, geht es bei weitem einfacher.
Da du jedes Rad einzeln antreibst, und auch noch Encoder hast, kannst du das sogar so richtig gut machen: gewünschten Kurvenradius nehmen, den nötigen Weg für jedes Rad berechnen und jeden Motor passend dazu ansteuern.

Das habe ich vor.
Momentan bin ich aber dabei, auszuloten, wo was hinkommt.
Der Platz ist eher klein.
Der Aufbau ist beim alten Rover mit dem Encoderproblem noch mal 13cm über den Rover hinaus hoch.
Ich werd wohl statt 9cm Bodenfreiheit eher mit 6cm vorlieb nehmen und dafür von Mitte Reifen bis Mitte Reifen einen Radstand von 17.5cm
nehmen statt den kürzeren 14.3cm Radstand bei 9cm clearance.
6cm Bodenfreiheit ist z.B. immer noch mehr als dieser hat:
http://www.tamiya.com/english/products/58309twin/index.htm
Der hat nur 4.7cm.
:-)

[Rabenauge]

Bodenfreiheit ist nicht alles. Dieses Auto (meins ist ja bis auf die Karosse identisch, wobei ich viel bessere als die Standard-Federbeine hab) ist weit geländegängiger, als man glauben mag.
Selbst Bordsteinkanten kann man damit mühelos überwinden. Dein Chassis kann nicht wirklich geländetauglich werden, weil die Federung fehlt. Heb mal irgendein Rad an...ich hab an jedem Rad mindestens 5cm Federweg (eher mehr), ehe die Traktion flöten geht.
Grundsätzlich kannst du natürlich jedes Rad einzeln ansteuern, und damit so einiges wett machen (fehlende Traktion an einem der Räder kann man so halbwegs ausgleichen), aber es gibt da Tricks: bei meinem ist die Hinterachse teilgesperrt (kleine Gummistücke zusammen mit Fett im Differential), du glaubst nicht, wo man damit überall durchkommt. Da gibts so schnell kein halten...
Die richtigen RC-Auto-Fahrwerke (Spielzeuge nehm ich hier aus, die taugen meist auch nich viel) sind den üblichen Roboterfahrwerken einfach hoffnungslos überlegen. Wobei z.B. der Wild Thumper auch recht anständig gebaut ist (aber wiederum abartig teuer, dafür dass es nicht mal für ne anständige Chassiswanne gereicht hat).
Guck dir mal auf deiner verlinkten Seite das Video an, und dann versuch mal, die Ackerfahrt mit deinem Chassis so problemlos zu bewältigen. Es geht auch noch gröber....;)

Was den Platz angeht: so viel braucht man nicht...ich hab ihn halt, und ich nutze ihn, aber grundsätzlich könnte man die ganzen Gerätschaften auch auf ner Lochrasterplatine montieren. Hübsch gepackt wär das kaum grösser als nen Arduino Mega...
Vielleicht mache ich das mal irgendwann, wenn endgültig feststeht, welche Hardware bleibt, und welche nicht.
Ich hab mit dem Auto später noch mehr vor, das würde derzeit schon auch eng, weil ich die Karosserie unbedingt drauf haben will, schon als Wetterschutz.
Ideen gibts genug....aber eins nach dem anderen.

Die Tage werd ich erstmal den alten Fahrmodus, ohne Navi, wieder programmieren, um mal zu testen, ob ich mit dem ~1m Reichweite der US-Sensoren jetzt, wo langsamere Motoren verbaut sind, was anfangen kann oder ob ich in den sauren Apfel beissen muss, und neue besorgen.
Eine brauchbare Hinderniserkennung muss unbedingt her.

[Rabenauge]

So. Heute hat der Postmann mir die Relaisplatine zugeworfen. :)
Montiert isse auch schon, aber noch nicht verkabelt (mal sehn ob ich heute noch Lust hab...). Dafür musste das GPS neben den Spannungsreglern weg. Das sitzt nun vorne, quer vor dem Display (unter der Motorhaube der Karosserie).
So geht es- eigentlich wollte ich es nach hinten verfrachten, aber ich hab da im Hinterkopf (...später mal..Wetterdaten sammeln, Kamera, GPRS-Modul, Raspberry, blablabla...) nen Nutzlast-Container, der natürlich bei nem Pickup hinten drauf gehören würde. Dann würd er die GPS-Antenne verdecken, nich so clever...vorne kann da nix passieren.

Wie man das Ding allerdings nun wirklich anschliessen muss, versuche ich noch, rauszufinden. Obwohl von nem deutschen Händler (ging einfach schneller) gibts wiedermal _nix_ Doku dazu. Also raten, goggeln und probieren...
Bsi Sainsmart hab ich sowas wie ne miese Handskizze zu diesen Dingern gefunden, aber so viel gibt die auch nich her, zumal in den Reviews da steht, die stimmt nicht....offenbar kann man sie sowohl aus der selben Spannungsquelle wie den sie steuernden Rechner, als auch aus ner anderen speisen. Die Laststromkreise scheinen zumindest _wirklich_ komplett getrennt zu sein, immerhin was.

[MEgg]

Bodenfreiheit ist nicht alles. Dieses Auto (meins ist ja bis auf die Karosse identisch, wobei ich viel bessere als die Standard-Federbeine hab) ist weit geländegängiger, als man glauben mag.
Selbst Bordsteinkanten kann man damit mühelos überwinden. Dein Chassis kann nicht wirklich geländetauglich werden, weil die Federung fehlt. Heb mal irgendein Rad an...ich hab an jedem Rad mindestens 5cm Federweg (eher mehr), ehe die Traktion flöten geht.

Versteh ich jetzt nicht: wenn die Federung das Rad u.U. hochhebt, ist doch die Traktion eher weg, als im Fall wo das Rad starr am Boden bleibt - oder hab ich da einen Denkfehler?
okok, das Problem ist, wenn eines angehoben wird, sind die anderen wohl meist in der Luft - verstehe.


Wobei z.B. der Wild Thumper auch recht anständig gebaut ist (aber wiederum abartig teuer, dafür dass es nicht mal für ne anständige Chassiswanne gereicht hat).
Guck dir mal auf deiner verlinkten Seite das Video an, und dann versuch mal, die Ackerfahrt mit deinem Chassis so problemlos zu bewältigen. Es geht auch noch gröber....;)

Der Wild Thumper hätte mir gefallen, aber wie Du sagst: abartig teuer.
Gibt es was ähnliches billiger?
Mit dem Dagu5 möchte ich sowieso erst mal Erfahrung sammeln. Wenn was kaputt geht, war es nicht so teuer.



Was den Platz angeht: so viel braucht man nicht...ich hab ihn halt, und ich nutze ihn, aber grundsätzlich könnte man die ganzen Gerätschaften auch auf ner Lochrasterplatine montieren. Hübsch gepackt wär das kaum grösser als nen Arduino Mega...


Die Spider Karte ist vielleicht ein Overkill, war eben im Set dabei.
Momentan verwende ich nur ca 1/5 der Spider Anschlüsse, mal sehen welche Servos noch dazukommen.
Vielleicht ginge ein kleinerer Arduino und vielleicht könnte der Raspberry den Motor Controller auch alleine ansteuern.
Mal sehen.

- - - Aktualisiert - - -


So. Heute hat der Postmann mir die Relaisplatine zugeworfen. :)
[...]

Wie man das Ding allerdings nun wirklich anschliessen muss, versuche ich noch, rauszufinden. Obwohl von nem deutschen Händler (ging einfach schneller) gibts wiedermal _nix_ Doku dazu. Also raten, goggeln und probieren...
Bsi Sainsmart hab ich sowas wie ne miese Handskizze zu diesen Dingern gefunden, aber so viel gibt die auch nich her, zumal in den Reviews da steht, die stimmt nicht....offenbar kann man sie sowohl aus der selben Spannungsquelle wie den sie steuernden Rechner, als auch aus ner anderen speisen. Die Laststromkreise scheinen zumindest _wirklich_ komplett getrennt zu sein, immerhin was.

Wenn es die sind:
10 Pcs 1-Channel Relay Module with Optocoupler H/L Level Triger 5V 30A (http://www.amazon.de/gp/product/B014R0FBQQ?psc=1&redirect=true&ref_=oh_aui_detailpage_o09_s00)
und dort die 5V 1-Channel dann kann ich Dir helfen. Sind sehr klein und einfach.

[Rabenauge]

Ja-der Denkfehler war, dass die Federung die Räder an den Boden drückt-anheben tut sie eben der Boden. Biste ja drauf gekommen...:)
Generell finde ich dein Chassis gar nicht mal übel, aber für draussen wohl eher nix (ne Runde über gepflegten Rasen trau ich ihm grade noch zu, aber da dürfte schon das lenken etwas heftig schwer werden), vor allem die Option Ketten würde mir gefallen. Mein Monster sollte eigentlich nen 1:16er RC-Panzer-Fahrwerk werden, aber das hab ich erst mal verworfen.
Was kleinere Rechner angeht: du musst erstmal lediglich vier Ausgänge bedienen, richtig?
Da brauchste ja noch nicht mal überhaupt nen Arduino- von denen tät es das billigste, was aufzutreiben ist, locker: Pro Mini vom Chinesen für 1.90.
Der hat genausoviele Ein-und Ausgänge wie ein UNO...andereriseits, wieso nicht benutzen, was eh da ist...
Aber ich bin auch so: wenn da irgendwo noch nen freier Pin ist, kann man auch was damit machen. Drum hat mein Monster z.B. ne Hupe- brauchen wirds die im Leben nich...
Also schadet es nie, wenn man bissel was frei hat...Licht könnte auch noch dran (sinnlos, aber cool).
Ich hab den MEGA aber nicht wegen den vielen Pins drauf, sondern weil er auch _richtig_ Speicher hat, gegen das klägliche Bisschen der UNOs...ich brauch allerdings einiges, für die Kursberechnungen.
Und den Rest-naja. Bisschen spielen will man ja auch...;)

Zum Wild Thumper wüsste ich _so_ keine Alternative, aber mal ehrlich: das Chassis selber ist Quatsch. Da baut jemand nen richtig geländegängigen Roboter und dann wird das Chassis als Sieb ausgeführt, was jedes Dreckkrümel und jeden Wassertrofen im Umkreis magisch anziehen wird?? Wie doof muss man sein....
Eventuell kriegt man die Antriebe einzeln (ich glaub, die hab ich schon gesehen) und kann die _sinnvoll_ mit einer Chassiswanne vereinen?
Man muss sich halt entscheiden, wohin man will: drinnen ist deiner grade richtig (evtl. geht draussen mehr als ich vermute, dazu müsst man das Teil mal näher beschnüffeln), das gibts auch in kleiner (Sainsmart hat nen ähnliches Teil, da passt nen gescheiter Arduino grad noch rauf), oder man baut sich fix was selber (Tamiya Track-Set&Zubehör z.B.), oder man will raus.
Dann braucht man es grösser (damit nicht jedes Kieselsteinchen ne Herausforderung wird), und auch entschieden robuster. Einiges gibts da, aber alles, was an Robotern in der Hobbypreis-Liga zu finden ist, hat seine Macken: Wild Thumper hat ein löcheriges Chassis,,T-Rex hat Ketten, deren Grenzen ich _sehr genau (sind Tiger-oder Panterketten 1:16) kenne....alles nicht das Wahre.
RC-Autos aber sind genau dafür gebaut: die sind ausgelegt dafür, auch mal durch den Dreck zu fahren, sind relativ stabil, Ersatzteile notfalls leicht zu beschaffen, können bisselwas tragen, und der Preis meines (bzw. Nachfolger, den Wild Dagger selber gibts seit Jahren nich mehr) liegt mit rund 150€ durchaus im Erträglichen...
Da wo der Thumper hin kommt, kommt meiner auch hin. Und der T-Rex kann meinem nicht das Wasser reichen, auch wenn er auf den Videos recht interessant aussieht- er isses nich.
Es gab auch mal ein RC-Auto, was ähnlich wie der Thumper aufgebaut war: auf jeder Seite drei Räder, allerdings jeweils starr verbunden (nur ein Motor pro Seite), sogar schwimmfähig, das wär nen richtig geiler Outdoor-Roboter. Leider kaum mehr zu bekommen (Reely Kaiman, Robbe Rodeo....). Das Ding hätt ich echt gerne....

Meine Platine ist anders: es ist ne zweikanalige, die zusätzlich nen Jumper hat.
So eine: http://www.sainsmart.com/arduino-pro-mini.html
Die hat zusätzlich noch nen Jumper, mit dem man die Relais völlig abtrennen kann (wozu auch immer mans braucht, einfach den Stecker ziehn funktioniert genauso), und das hatte mich verwirrt, zumal da dann noch ein, völlig unnötiger, Masseanschluss da ist.
Aber zusammen mit der Beschreibung in einem der Reviews, nen paar Schaltskizzen (davon gibts verschiedene...) und bissel Grübeln bin ich drauf gekommen.
Es funktioniert nen bissel anders, wie man an vielen Stellen liest, aber es geht jetzt.
Ich hab es nun verkabelt, und zwar habe ich den Schalter vom BEC in Reihe mit einem der Relais geschalten. Somit muss er auch eingeschalten sein (noch mehr Sicherheit, wenn ich den ausmache, kann das Relais treiben was es will), und wenn dann ausserdem das Relais anzieht, läuft das BEC.
Sicherer wirds nicht mehr: den Hauptschalter aus, und auch das BEC ist aus, da das Relais dann abfällt. Ebenfalls, wenn aus irgendeinem Grunde der Rechner ausgeht- dann kann der auch kein HIGH mehr senden, und das Fahrwerk steht ebenfalls.
Wenn der Spannungsregler ausfällt, ist auch Ruhe...fehlt noch sowas wie ne Selbstdiagnose, es kann nicht erkannt werden, ob der BEC-Schalter auch an ist, also ob das schalten per Relais was bringt. Aber das stört mich monentan nich wirklich, man könnte da noch was basteln, aber man kann alles auch übertreiben..
Was kommt, ist ein entsprechendes Symbol im Display, wenn der Antrieb scharf geschalten wird, so als Hinweis "nimm die Pfoten mal lieber weg jetzt...".

[MEgg]

Meine Platine ist anders: es ist ne zweikanalige, die zusätzlich nen Jumper hat.
So eine: http://www.sainsmart.com/arduino-pro-mini.html
Die hat zusätzlich noch nen Jumper, mit dem man die Relais völlig abtrennen kann (wozu auch immer mans braucht, einfach den Stecker ziehn funktioniert genauso), und das hatte mich verwirrt, zumal da dann noch ein, völlig unnötiger, Masseanschluss da ist.


Schaut irgendwie nur wie eine doppelte Version des Relays aus, das ich verwende.
Das Foto bei Amazon stimmt eigentlich nicht.

30938

[Rabenauge]

Nein.
Ich hab zusätzlich drei Anschlüsse, mit denen ich die Relais komplett extern mit Strom versorgen kann.
Dann ist ab dem Optokoppler wirklich _alles_ getrennt...kann man. Muss man aber nicht.
Wäre dann wohl z.B. möglich, die Platine auch mit 3.3V anzusteuern (nem 3.3V Pro Mini z.B.), und den Spulen trotzdem ihre 5 zu geben.
Das ist mir auch erst im Nachhinein aufgegangen, dass es so durchaus nen Nutzen haben könnte.

[Rabenauge]

Sodele. Mit der anderen Bastelei komm ich grade nicht weiter (wird auch nen "autonomes Auto", dazu erzähl ich erst was, wenn es nennenswertes gibt), also war das Monster mal wieder dran.
Heute: nehmen wir nen Joystick in Betrieb.
Nix weltbewegendes eigentlich: zwei analoge, ein digitaler Eingang- letzteren muss ich noch entprellen, aber das Ding läuft und wird sauber eingelesen.
Damit funktioniert der nun auch wieder softwaremässig.
Den Button (hat das Ding sowieso) will ich nutzen, um Eingaben zu bestätigen, aber auch, wie in der vorherigen Version schon, um den Antrieb freigeben zu können.
Ich will, dass das Auto sich ohne extra Erlaubnis niemals von der Stelle rührt.

Nebenbei habe ich mal wieder versucht, VirtualBox zu bewegen, die seriellen Daten vom Arduino einzulesen, damit ich _endlich_ mal den Kompass wieder nutzen kann- erfolglos. Die Schnittstelle wird gar nich erst gefunden. :(
Leider seh ich wirklich keinen anderen Weg, den Compass "hard iron" zu kalibrieren, und ohne diese Kalibrierung ist er nicht zu gebrauchen.
Meine Vermutung ist, dass Linux die VirtualBox nicht drauf zugreifen lässt- aber ich hab keine Ahnung, wie man das behebt.

[Rabenauge]

Sooo.
Heute war nen seeeehr erfolgreicher Tag: ich hab es geschafft.
Magmaster läuft in der VirtualBox.
Die Schnittstelle wird auch erkannt-es kann los gehen.
Grade eben hab ich mal nen paar Kalibrierungsdaten erarbeitet, und dann in nen, früher mal geschriebenes, Programm für den Kompass eingesetzt.
Es funktioniert!
Zwar sind die Daten noch nicht allzu genau, aber ich hab das hier auf der Couch und etwas in Eile (Bett ruft schon, wo ich wieder bleib...) eben gemacht.
Dafür nehm ich die derzeitigen, runden 20 Grad Abweichung um Norden rum hin- das wird noch besser, wenn man es ordentlich macht.
Wichtig ist: ich hab wieder ne Möglichkeit, den HMC5883l-Kompass zu benutzen.
Ausserdem: ne genaue Richtung brauche ich gar nicht, aber _bissel_ besser möchte ichs schon haben, und das geht auch, wie ich weiss (war ja seinerzeit bei <5 Grad, das reicht locker, da ja die Daten permanent mit denen vom GPS abgeglichen werden).

Ein grosser Schritt fürs Monster. :)

Nebenbei grüble ich noch, ob ich dem Ding nicht mal nen anständigen Roboter-Namen geben soll. Würd ich gerne, aber mir fällt einfach nix gescheites ein.
Wenn jemand nen schönen Vorschlag hat....

Morgen (oder die Tage, wie ich Lust hab) wird der Kompass ordentlich kalibriert, und dann muss ich mal den neuen SD-Kartenhalter verkabeln, das wird auch langsam nötig (auf SD-Karte sollen dann so Geschichten wie Wegpunkte, Routen usw. gespeichert werden, und noch einiges mehr).

[Rabenauge]

So- hier tun sich auch wieder nen paar Dinge.

Da der Kompass nun -im Prinzip- wieder zu gebrauchen ist, hab ich die letzten Tage unter anderem mit dem GPS vertrödelt.
Eigentlich wollte ich ja die TinyGps++-Bibliothek benutzen dieses Mal- aber ich krieg sie nicht vernünftig zum laufen.
Möglicherweise ist der RAM zu knapp (sooo viel hat der 2560 auch nich...)- mir wars zu mühselig das herauszufinden.
Also habe ich wieder die TinyGps am Start.
Blöd: um die Weihnachtszeit hat man so einige elektrische Geschichten in den Fenstern- da ist mein GPS-Empfang hier drin _noch_ mieser. Nen Kaltstart kann durchaus mal ne dreiviertel Stunde dauern...so kommt man auch voran.
Und: das GPS hat sich mal wieder auf die Werkseinstellung zurückgesetzt (1Hz bei lausigen 9600Baud und schlimmer: SBAS AUS), aber ich hatte echt keine Lust aufs U-Center, das stell ich mal an nem ruhigen Tag irgendwann wieder vernünftig ein.
Dennoch ging es voran.
Das GPS läuft, und in der Info-Leiste auf dem Display werden angezeigt ob die Uhrzeit verfügbar ist (die hat das ding schon lange, bevor irgendwelche Positionsdaten rein kommen), das benutze ich mehr oder weniger als Kontrolle ob das GPS überhaupt arbeitet, und wenn dann ein Fix vorliegt, wird auch dazu nen entsprechendes Symbol angezeigt.
Vielleicht schreib ich oben in die Leiste später auch noch die Uhrzeit, Platz wär genug...momentan steht sie weiter unten im Display- nur als Kontrolle. Die kann ich später evtl. fürs Loggen irgendwelcher Daten mal brauchen, und das GPS liefert sie sowieso.
Momentan wird die Zeit nur rudimentär korrigiert (ne Stunde dazu halt, wegen der Zeitzone), mal sehn, ob ich Lust habe, da auch noch ne Sommerzeit-Umstellung zu programmieren.

Als nächstes steht Mathematik an: Kurs- und Entfernungsberechnungen aufgrund der GPS-Daten. Entfernung ist easy, aber Kurswinkel...
Das war der Grund, wieso ich lieber die Tinygps++ wollte- die hat das nämlich eingebaut. Bei der einfacheren muss ich das wohl zu Fuss machen.
Wird toll...

Ach ja: da die Info-Leiste nur neu geschrieben wird, wenn sich dort was ändert, und ich es öde fand, ne Stunde lang immer wieder auf das Display zu starren, hab ich auch die "Hupe" wieder angeschlossen. Nun pip-pip-t es diskret, wenn sich dort Dinge getan haben.
Freie Pins haben wir ja allemal genug....

[morob]

mahlzeit,

ich verwende aus der biblothek folgendes

// way calc
course2 = gps.course_to(float(lat / 10000), float(lon / 10000), float(target_lat / 10000), float(target_lon / 10000));
distance2 = gps.distance_between(float(lat / 10000), float(lon / 10000), float(target_lat / 10000), float(target_lon / 10000));
guck dir das mal an.

[Rabenauge]

Du hast recht. Auch die TinyGPS _kann_ offenbar Entfernung und Kurs berechnen.
Schaue mir grad das Beispiel (test_with_gps_device) an- dort wird das gemacht.
Irgendwo muss da ein Haken sein, sonst hätte ich das in der ersten Version doch bereits benutzt...hm.
Leider hat es Mikal Hart nicht so mit Kommentaren, mal sehen, was ich aus dem Beispiel raus bekomme.
Um schreiben muss ich das ohnehin erst mal, weil ich zum einen keine Soft-Serial brauche und zum anderen gibt es unter Ubuntu offenbar Probleme, wenn zu viele Daten an die serielle Konsole gesendet werden.
Das hatte ich jetzt schon ein paar mal.

Na mal gucken.

[morob]

ich werde das auch über weinachten probieren, weil ich es bei einer lösung benötige.
probleme mit der seriellen hatte ich noch nicht, softserial habe ich aber von ihm genommen und nicht die bei arduino dabei ist.

[Rabenauge]

Ich bin da skeptisch. In der Vorversion hatte ich die Kurs-und Entfernungsberechnungen selbst erledigt. Dafür muss es irgend einen Grund gegeben haben, denn Winkelberechnungen sind ganz sicher nicht mein Lieblingsgebiet.

SoftSerial brauche ich nicht, ich benutze den Mega 2560- der hat ja genug serielle Schnittstellen. :)
Das Problem mit der seriellen Konsole äussert sich so, dass ich, wenn eine "längere Zeit" sehr viele Daten an die Konsole geschickt wurden, nur noch nen blinkenden Cursor auf dem Bildschirm habe. Je nach Programm kann das stundenlang gut gehen, aber grad die GPS-Testprogramme schicken ja ne ganze Menge, da ist nach ner halben Stunde Schluss.
Eventuell sollt ich einfach mal auf die aktuelle IDE updaten...

Gestern hab ich nicht mehr viel gemacht, Kleinigkeiten: nun wird auch die Aktualität des letzten Sat-Fixes als Zeichen auf der Infoleiste ausgegeben. Das kann ich später im Programm als "Warnung" nutzen, wenn man mieser Empfang ist.
Da der Wert zumindest hier drinnen ständig schwankt, wird dabei nicht gepiepst- das würd ziemlich nerven.
Ausserdem hab ich festgestellt, dass die ADC erst nach etlichen Sekunden nach dem Einschalten zu gebrauchen sind. Auch bei fast vollem Akku bekomme ich, beim Einschalten, erst mal ne Akku-Warnung. Einige Sekunden später stimmen dann die Werte. Offenbar müssen Arduinos erst warm laufen. :D

[morob]

ich nehme wahrscheinlich ein micro oder ein chipkit pi (pegelwandler) dafür.

[Rabenauge]

Willst du nicht an nen Pi damit?
Ich hab es nie ausprobiert, aber angeblich läuft meines mit 3.3V auch, bzw. ist für 3.3V ausgelegt, aber 5V-tolerant.
Müsste ich mal nen 3.3V-Pro mini testweise ran hängen...

[morob]

das problem ist das der controller noch die fernsteuerung ausliest und servos ansteuert.
der controller wird das kleinhirn, der rpi das großhirn mit augen :D