Zitierenzum IMU-Brick2-Thema und einem einfachen Raspi-C/C++-Treiber
https://www.roboternetz.de/community...aspi-mit-Geany
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 22: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
ok, danke, da muss ich mal sehen, sieht im Gegensatz zu pozyx etwas weniger verständlich und weniger leicht handhabbar aus, eher was für Profiprogrammierer...Zitat von Defiant
Update: Habe einen 4 DoF OpenManipulator mit RealSense D435 Tiefenkamera auf den Wild Thumper gesetzt. Als Software wird natürlich MoveIt eingesetzt, damit wird die inverse Kinematik und der Pfad automatisch berechnet. In der folgenden Animation ist das sichtbar:
1. Es wird der Zielpunkt durch Ziehen mit der Maus vorgegeben
2. Mit "Plan und Execute" wird die Bewegung zum Zielpunkt ausgeführt.
Bild hier
Die Objekterkennung per Tiefenkamera habe ich allerdings noch nicht gemacht.
Geändert von Defiant (27.08.2020 um 13:57 Uhr)
schon beeindruckend geschmeidig!
Nochmal zum Verständnis: das alles läuft nicht autonom auf dem Auto, oder etwa doch?
Ehrlich gesagt wirkt das nur in der Animation so geschmeidig, die Aktualisierungen erfolgen "nur" mit 10Hz, schneller bekommt der AVR, der die Befehle- und Statuswerte vom I2C zum Half Duplex UART übersetzt, das nicht hin.
In diesem Fall wird die Kinematik und der Pfad auf einem PC berechnet. Bei ROS ist das ja relativ egal auf welchem Rechner eine Node läuft. Ich hab die Berechnung auf dem Roboter noch nicht ausprobiert, dürfte aber einige Sekunden länger dauern.
Berechtigungen
Lesezeichen