Bei Interesse kann ich auch bei der C++ Nutzung helfen. Ich hab die eine oder andere IMU getestet und die Tinkerforge hat bisher den besten Sensor-Fusionsalgorithmus. Klare Empfehlung.
Bei Interesse kann ich auch bei der C++ Nutzung helfen. Ich hab die eine oder andere IMU getestet und die Tinkerforge hat bisher den besten Sensor-Fusionsalgorithmus. Klare Empfehlung.
danke für dein Angebot! Was man letztlich bräuchte wäre eine einfache lib zum Einbinden
und build flags (für Geany, ohne make oder makefile oder cmake) schlicht und ergreifend etwas in der ArtCode:#include <tfIMUbrick2.h>
-ltfIMUbrick2
und wenn es dann nicht einfache Register-Lesezugriffe wie bei I2C sind (ist ja USB), dann in der Art, wie man es auch für den DHT22 oder tinygps macht, also in der Art
über all das, was in der Lib passiert, muss ich ja gar nichts genaues wissen, das kann eine komplette black-box bleiben. Wenn es also so einfach ginge, das wäre absolut genial!Code:tfimubrick imu; imu.init(); float h= imu.yaw; float p= imu.pitch; float r= imu.roll;
Im Grunde ist die Tinkerforge API jetzt nicht soweit davon weg, die Bibliothek unterstützt aber z.B. noch mehrere IMUs und Callbacks weswegen sie ein wenig aufgeblasener wird. Sollte man diese Diskussion in einem separaten Thread fortführen?
ja, gerne!Zitat von Defiant
zu deinem Bot:
wie fusionierst du Odometrie mit dem IMU?
ich selber habe wegen viel Schlupf immer den IMU für die Ausrichtung und das arithmet. Mittel aus beiden Radencodern für die Strecke verwendet. Die Drehung, die unterschiedliche Raddrehungen verursachen, fällt damit komplett weg, was grundsätzlich kein Nachteil ist/war, denn es handelt sich um Gleisketten.
Aber auch der Vortrieb ist ungenau, weil die Ketten auf glattem Parkett oft durchdrehen oder beim Stoppen nachrutschen.
Hast du eine bessere Lösung?
Kann man die Vortriebswerte mit deinen IMU Brick Accelerometern auf brauchbare Weise glätten (s = 1/2*dt*a²) ? Meine Accelerometerdaten sind zu sehr verrauscht, das wird dann höchstens noch schlimmer. Kriegst du das mit deinem IMU brick exakter hin?
Richtig, die Odometrie ist für Rotationen um die Z-Achse bei dem Wild Thumper mit den zwei starren Achsen genauso umbrauchbar wie bei Kettenantrieben. Die Lektion, die ich daraus gelernt habe: Nächstes mal ein Roboter mit einer Antriebsachse und Stützrad. Erspart viel Arbeit und Zeit..
Die Sensorfusionierung übernimmt ein Kalman-Filter in der dazu passenden ROS-Node: robot_pose_ekf. Reell habe ich allerdings die Varianz der Odometrie für die Drehung um die Z-Achse auf "1" gesetzt. Sie ist damit deutlich Größer als die Varianz für die IMU mit 0.008. Kalman-Filter hin oder her praktisch gesehen wird für die Rotation damit fast vollständig nur der IMU-Wert genommen.
Bei der vorherigen Razor IMU sah das Verhältnis der Kovarianzen anders aus: Hier musste der Kalman-Filter fein eingestellt werden da die IMU zwar auch hier deutlich präziser arbeitete, aber nur außerhalb von magnetischen Einflüssen wie der Spülmaschine. Ist Super wenn man geradeaus an der Spülmaschiene vorbeifährt, aber der Roboter eine Kurve berechnet...
Bei der Translation habe ich dank Gummireifen kaum Schlupf, die Werte für Reifendurchmesser etc wurden mit dem UMBMARK eingestellt. IMU halte ich für Translation nicht brauchbar. Mein Standpunkt ist: Die Beschleunigungssensoren messen die Erdbeschleunigung, nicht die des Roboters. Die Erdbeschleunigung ist ja konstant, während der Roboter nur für den Bruchteil einer Sekunde mit vielleicht 1 m/s beschleunigt. Der Sensor des IMU Brick ist für die Beschleunigungen von den Toleranzen her im selben Bereich wie die meisten IMUs die ich gesehen habe (Toleranz ist im Datenblatt mit 1% auf "Full scale" angegeben, also 1% von +-2G = ~0.2m/s). Damit ist die Beschleunigung des Roboters im Toleranzbereich der Beschleunigungssensoren
Um noch einen daraufzusetzen: Die Odometrie wird mit den Werten des 3D-Sensor korrigiert. Entweder anhand von "Simultaneous Localization and Mapping" oder anhand von Monte Carlo Algorithmen mit denen die Position des Roboters anhand einer bekannten Karte geschätzt wird.
Geändert von Defiant (06.06.2017 um 21:21 Uhr)
zum IMU-Brick2-Thema und einem einfachen Raspi-C/C++-Treiber
https://www.roboternetz.de/community...aspi-mit-Geany
Update: Ich habe den Roboter auf einem Parkplatz autonom ein Viereck über GPS Koordinaten abfahren lassen, hier das Video:
https://vimeo.com/247624371
Front Kamera ist unten links, die Kartenansicht (rviz) ist oben links zu sehen.
Update: Mit Ultra-Wideband-Modulen folgt der Roboter erfolgreich einem Ziel.
Dazu ist auf der linken und rechten Seite des Roboters je ein UWB-Modul montiert. Als Ziel wird wird ein drittes UWB-Modul als Bake verwendet. Die Position der Bake wird aus der Differenz der Entfernungen berechnet.
Im folgendem Video folgt der Roboter damit einem ferngesteuerten Auto:
https://vimeo.com/288943433
Details auf hackaday.io
Berechtigungen
Zitieren
Lesezeichen