Druckbare Version
Warum nimmst du nicht ein Gyroskop? Wie zB.: 6-achsen-bewegungssensor-modul-6d-bs Neben den Beschleunigungssensor ist dort auch ein Gyro verbaut. Dieser Gyro schaft bis zu 2000deg/s. Den Beschleunigungssensor könnte man her nehmen, um ein Drift bzw. Durchdrehen der Kette auf dem Boden festzustellen.Zitat:
Zitat von Jackeder
Zitat:
Zitat von Jackeder
... und, was den CMPS11 angeht, mindestens 1m (!) von allen (elektro-) magnetischen Teilen weg, wie z.B. Radachsen und Motoren, und externe magnetische Störfelder von Gegenständen, in deren Nähe man sich befindet oder an denen man sich vorbei bewegt, dürfen auch keine vorhanden sein.Zitat:
Zitat von morob
Reine Gyros sind auch keine Lösung (LMS330, wie im ELV Modul 6d-bs verbaut), da Gyros keine absolute Orientierung zum Initialisieren besitzen und grundsätzlich einen Driftfehler haben (der müsste wiederum durch einen zusätzlichen Kompass kompensiert werden, womit sich die Katze in den Schwanz beißt, d.h. reiner Gyro geht nicht, und man bräuchte doch einen 9D IMU (3D Kompass+ 3D Gyro+ 3D Accel.) und extrem gute stochastische und statistische Kompensationsalgorithmen, s.u.).Zitat:
Zitat von Jimmybot
@Jimmybot: ich wette, das ist graue Theorie und du hast es mit Sicherheit noch nie selber ausprobiert: völlig illusorisch!
Accelerometer sind viel zu verrauscht, um daraus Bewegungs- und Ortungsdaten zu gewinnen, geschweige denn, um damit Schlupf der Antriebsketten herauszurechnen.
@Jackeder: Eine Idee wäre höchstens der Tinkerforge IMU Brick 2, z.B. in Verbindung mit einem Raspberry Pi, doch der erfordert einen ziemlichen Implementierungsaufwand (ich habe ihn aufgegeben, aber vielleicht hast du ja entsprechende fortgeschrittene Linux-, C++ und Python Kenntnisse).
Unterm Strich halte ich Kettenfahrzeuge für absolut ungeeignet bezüglich Navigation per Odometrie und IMUs, einzig externe Ortungssysteme mit Satelliten- oder Bakenpeilung (wie GPS oder z.B. pozyx) halte ich z.Zt. für aussichtsreich.
Ich kann diesbezüglich den BNO055 empfehlen. Der ist ziemlich unempfindlich was externe Störungen anbelangt.
hast du es mal ausprobiert und einen Stab- oder Elektromagneten daneben gelegt und/oder vorbei bewegt?Zitat:
Zitat von shedepe
Ich wäre sehr überrascht, wenn er daraufhin keine Veränderung zu Kompass-Nord zeigen würde.
Wenn du den Magneten statisch daneben legst, kann man das tatsächlich in begrenztem Maßstab durch die Sensorgeometrie kompensieren.
Und natürlich, Jeden Magnetkompasss kann man durch ein außreichend starkes externes Magnetfeld stören. Durch geschicktes wählen der Sensorposition und Sensorfusion (was der BNO intern macht zum Glück) kann man aber einiges ausgleichen.
Nur zum Vergleich. Wir fahren mit so einem Sensor in einer Laborhalle wo auch Starkstromversuche für Antriebstechnik gemacht werden. Klappt trotzdem.
nein, ich meinte erst z.B. auf Nord ausrichten und dann einen Magneten temporär danebenlegen und irgendwann wieder wegnehmen oder öfters zufällig vorbei bewegen. Außerdem hast du sicherlich eine funktionierende Odometrie, nehme ich an?Zitat:
Zitat von shedepe
Außerdem machen Starkstromleitungen wenig, denn die produzieren ja nur magnetische 60 Hz Wechselfelder, kreisförmig um die Leiter herum, aber keine gerichteten Magnetfelder wie magnetisierte Metallachsen, Metallleisten, oder Elektromagnete.
der Tinkerforge IMU Brick 2 kann ja laut Firmeninfos alle Magnetstörungen über die Sensorfusion kompensieren, das hatte ich ja angesprochen, dennoch bezweifle ich, dass das jemand mit eigenen Mitteln nachmachen könnte, und außerdem kann selbst dies mMn nicht eine aus dem Ruder laufende Odometrie bei durchrutschenden Kettenantrieben kompensieren.
- - - Aktualisiert - - -
ps,
der CMPS11 (9D IMU) hat ja ebenfalls eine interne Sensorfusion, dennoch ändert sich der berechnete (Kompass-) Kurs bei Fremdmagneteinfluss um bis zu 180°, aber schon 5° wären dauerhaft zuviel:
10 Min. Fahrt bei 10m/min und 5° Fehlweisung = knapp 8m Navigationsfehler!
Und das betrifft nur den Kursfehler - der Fehler durch Odometrie bei Kettenschlupf kommt noch oben drauf!
Guten Morgen,
erstmal danke für die vielen Antworten und Anregungen.
Da erübrigt sich schon mal meine Frage ob der Standort günstig ist.Zitat:
Zitat von morob
Anhang 32938
Ich wollt halt alles so bauen das nichts rausschaut bzw kompackt ist, da meine Tochter mit ihren 2 Jahren schon sich sehr dafür interesiert, Taster sind ja zum tasten da usw.
sorry, bin denke ich noch ganz am Anfang mit meinen C++ KenntnissenZitat:
vielleicht hast du ja entsprechende fortgeschrittene Linux-, C++ und Python Kenntnisse
wie gesagt: und den CMPS11 mindestens 1m von den Motoren und Eisenteilen etc. entfernt.
Ich habe selber so ein Gefährt, und ich kann dir sagen: es klappt sonst nicht damit.
Und auch sonst mit Kettenantrieben zur Odometrie: keine Chance, spätestens nach der 1. Kurve.
Einzige halbwegs aussichtsreiche Möglichkeit wäre der Tinkerforge IMU 2, den kannst du u.U. auch in der Nähe von Magnetteilen verbauen, wenn er korrekt initialisiert worden ist (s. Videos).
So schnell noch paar aktuelle Bilder.
Anhang 32939 Anhang 32940
Ganz unten die beiden Akkus und die Versorgungsplatine mit dem ATmega8 der die Spannung über die Balancer überwacht und als Zusatz die Temperatur des LF50.
Anhang 32941 Anhang 32942
Darüber dann die Hauptplatine von Pollin ein ATmega128A, das MotorShild und in der Mitte die ISP Steckplatzbrücke mit Reset Taster für beide ATMEGAs, da ich sonst nicht anders ran komme.
Obendrauf auf dem Messingrahmen das LCD und 7 Tasten für einstellungen usw.
Guten Abend,
erstmal noch was zum CMPS11. Ich hab das Modul so wie oben gezeigt eingebaut und mit ATmega8 ausgelesen. Bei laufenden Motoren sinds ca. 20° Schwankungen. Ist natürlich zu viel um halwegs genau geradeaus zu fahren, bzw. überhaupt in eine Richtung zu steuern. Ich kann maximal im Stillstand die Richtung zumindest ermitteln. Zumindest sind Roll und Pitchwerte verwendbar wehrend der Fahrt.
Gestern Abend und heute Mittag hab ich Zeit gefunden die Drehgebersensoren umzubauen. Ich hatte ja schon mal für eine Seite was gebastelt, aber das hat nur bedingt gehalten.
Anhang 33000 Anhang 33001 Anhang 33002
Durch die Trägerbrücke hab ich auch gleich ein wenig Stabilität gewonnen. Jetzt muss ich erstmal für alles Programme schreiben und dann alles in eines packen.
- - - Aktualisiert - - -
@ shedepe
du schriebst ja das du ebenfals so ein MotorShild verwendest.
Hast du schon mal versucht den Motorstrom damit zu messen ? Ich hab im Netz gelesen das beim VNH2SP30 die Stromsensor- (CS) -Pins etwa 0,13 Volt pro Ampere des Ausgangsstroms ausgeben.
Ich wollte das mit einem LM358 um das 5fache versterken und dann am ATmega128A über ADC messen. Sollte ja so gehen, oder ?