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