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?
Werbung
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
UWB? was hast du da genau? Ein pozyx kit?
edit: ah, sah gerade, DWM1000 Module... also wohl nicht...
Laufen die auch per Arduino IDE code oder nur per ROS ? (Mit pozyx habe ich auch schon geliebäugelt, nur sind die ja schw***teuer...)
Für die DWM1000 habe ich diese Arduino-Bibliothek verwendet: https://github.com/thotro/arduino-dw1000
Berechtigungen
Zitieren
Lesezeichen