Wild Thumper ROS Roboter

Hier mein Roboter in dritter Generation. Es ist mein erster, der von Anfang an auf ROS ausgerichtet ist.

Daten:

• Basis Chassis: Wild Thumper 4wd, aufgerüstet mit Encodern für die Motoren
• Spannungsversorgung: 2x 7.2V NiMh über LM5050-2 active ORing angebunden. Die ORing Schaltung ist skalierbar und ermöglicht damit auch die Parallelschaltung einer Docking Station zur stationären Versorgung.
• 5V via Spannungsregler LM2576 (3A)
• Hauptcomputer: Solid Run Hummingboard (i.MX6 ARM Cortex-A9 Dual Core 1GHz, 2GB RAM)
• Peripherie am Hummingboard: GPS (uart), IMU (USB), Tiefenkamera (USB), restliche Peripherie über I2C
• I2C-Peripherie: AVR Atmega32 (Steuerung Motoren), AVR Atmega328 (Arduino Nano, restliche I/O: Abfrage Ultraschall- (US) und Infrarot- (IR) Sensoren, Messung Akkuspannung)
• Anbindung des 5V I2C Bus an die 3.3V des ARM µC über einen PCA9517 "Level translating I2C-bus repeater"
• Motorsteuerung: 4x VNH2SP30 per PWM 20kHz an Atmega32. Der Atmega32 übernimmt die Geschwindigkeitsregelung (PID) und Odometrie
• IMU zur Korrektur der Odometrie über 4 Räder: Tinkerforge IMU Brick 2.0 (In den Bildern noch Razor IMU). Die Tinkerforge IMU hat den Vorteil, dass sie nahezu immun gegen magnetische Störungen von außen ist.
• Distanzsensoren: Xtion Pro Live 3D-Kamera, 2x IR 2D120X (links/rechts), 3x US SRF05 (2x vorne, 1x hinten). Die beiden US-Sensoren sind aufgrund der toten Zone der 3D-Kamera bis ca. 0.5m erforderlich.
• Software: Debian Jessie + Robot Operating System (ROS) Indigo, ROS Navigationstack läuft auf einem PC über W-Lan.
• Mehr auf Hackaday.io

Die Bilder zeigen u.a. die mehrstufige Odometrie Auswertung und Sensorabdeckung.

Autonome Navigation mit GPS: https://vimeo.com/247624371. Dort fährt der Roboter auf einem Parkplatz autonom ein Viereck über GPS Koordinaten. Front Kamera ist unten links, die Kartenansicht (rviz) ist oben links zu sehen.

schaut prächtig aus!
was meinst du mit "Tinkerforge IMU hat den Vorteil, dass sie nahezu immun gegen magnetische Störungen von außen ist." ?
wenn das Erdmagnetfeld durch magnetische Störfelder / magnetische Metallteile gestört ist (Stahlbeton, Eisenerzadern, Eisen auf dem Bot, vorbeifahrender LKW oder ein davorgehaltener Stabmagnet): wie kann es dagegen "immun" sein?

Keine Ahnung wie, vermutlich werden die Magnetometer mit den Gyros verglichen und entsprechend nachkalibriert o.ä. Es funktioniert! Hier das Video des Herstellers: https://www.youtube.com/watch?v=Aq3SqVen5AQ&t=55

Als Test ob das wirklich funktioniert habe ich die Tinkerforge IMU zusammen mit der Razor IMU im Abstand von ca. 10 cm auf den Roboter montiert und bin mit einem Magneten darüber gefahren. Das Ergebnis anhand der Yaw-Achse hängt als Bild an.

Nachteilig der Tinkerforge IMU ist der gegenüber der Razor IMU etwas größere Stromverbrauch (70mA Tinkerforge, 40mA Razor) und man ist auf die Tinkerforge Bibliothek zum Auslesen angewiesen. Das aufleuchten der IMU wie ein Weihnachtsbaum nervt auch etwas, lässt sich aber abschalten.

wirklich enorm !
Kennst du persönlich libs für Arduino Wire() oder Raspbian mit wiringPi für den Tinkerforge ?

Nein, ich habe auch sonst nichts mit den Tinkerforge Bricks gemacht, die vordefinierten Anbindungen sind hier beschrieben: https://www.tinkerforge.com/de/doc/H...rschnittstelle. Der IMU Brick v2 wird auch über ein proprietäres USB-Protokoll angesteuert. Mit GPIO ist da nicht viel.


Ich habe einfach mit der Python API den ROS-Knoten implementiert

Python kapiere und nutze ich nicht, aber die C/C++ Schnittstelle ist auch reichlich überkompliziert. Ich für meine Zwecke bräuchte ja nur die horizontale Ausrichting (Heading), aber selbst dafür ist das ein Buch mit sieben Siegeln für mich.
Super, dass du das hingekriegt hast!

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

Code:

---

#include <tfIMUbrick2.h>

---

und build flags (für Geany, ohne make oder makefile oder cmake) schlicht und ergreifend etwas in der Art
-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

Code:

---

tfimubrick  imu;

imu.init();
float h= imu.yaw;
float p= imu.pitch;
float r= imu.roll;

---

ü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!

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?

Zitat:

---

Zitat von Defiant

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!

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?