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?

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.

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

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

Zitat:

---

Zitat von Defiant

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

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.

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.

Es gibt eine Basisstation über die der Roboter mit 12V versorgt wird (Dock.jpg) mit Gegenstück am Rover (wt_aft.jpg).

Die Umschaltung auf den Strom der Basisstation erfolgt über eine ORing-Schaltung. Das setzt voraus, dass die Basisstation eine höhere Spannung als die beiden Akkus liefert. Da die LSD-NiMH Batterie auf dem Roboter im angedockten Zustand abgekoppelt ist, wird sie geladen. Der Roboter stellt die aktuelle Systemspannung und den Strom über eine Message zur Verfügung.

Die Abfolge des andockens ist wie folgt:
1. Benutze die Standard Navigation um den Roboter in Richtung der Basisstation zu fahren, die Genauigkeit der Position liegt aber nur bei 15cm und 6°, die erlaubte Toleranz der Dock-Kontakte liegt aber bei 4cm. Auch könnte die Position der Basisstation geringfügig geändert worden sein.
2. Bewege die Kamera nach hinten (wt_dock_position.jpg).
3. Ermittle die Abweichung der Position des Roboters zu Basistation mittels aruco_detect, welches mir die 6-DOF Position des Fiducial-Markers (Quasi QR-Tag) liefert (wt_fiducial_dock.jpg).
4. Wenn die Y-Achse (Grüne Linie) des Fiducial eine Abweichung von der Mitte hat korrigiere die Translation durch schräges fahren
5. Wenn die Rotation um die Y-Achse nicht 0° beträgt korrigiere die Abweichung durch Drehen
6. Falls notwendig wiederhole ab Schritt 4.
7. Wenn Position des Roboters exakt vor der Basistation fahre Rückwärts bis Systemspannung über der maximalen Akkuspannung liegt.
8. Angedockt

Nachteile:
- Die Erkennung des Fiducial-Marker funktioniert nur bei Licht
- Der Widerstand der Dock-Kontakte ist sehr hoch, ich habe einen Spannungsabfall von bis zu 2V.
- Es wird derzeit nur der LSD-NiMH-Akku geladen, für den LiFePO4-Akku habe ich derzeit keine Ladeschaltung.
- Ich zähle nicht den Strom der in die Batterie fließt, sondern nur den Entladestrom. Beim Abdocken gehe ich davon aus, der Akku ist voll. Dies kann bei einem zu kurzem Dockvorgang dazu führen, dass der errechnete deutlich über dem tatsächlichem Ladeezustand liegt.
- Der Staubsaugerroboter kann die Fläche um/unter der Basisstation nicht putzen solange der Roboter angedockt ist

Hallo :)

Der Kontaktübergangswiderstand könnte ein Problem sein, ich weiß nicht, ob Holomino das vollständig beseitigen konnte. Da mir das so aber nicht behagt, habe ich mich für eine andere Lösung entschieden. Ich denke, damit habe ich auch einen geringeren Übergangswiderstand. Die Positionierung muss allerdings sehr viel genau genauer sein. Nachzulesen in diesem Thread (weiß nicht, ob Du den schon kennst). Ist sicher nicht jedem sein Ding. Ich sehe es als Herausforderung, weil ich auf diese Weise ein Ladegerät verwenden kann, das ich nicht selbst bauen muss.

Die Erkennung des Markers: wenn Du eine Lampe dabei hast, funktioniert es ja sicher auch. Ansonsten kann man den Code auch auf einem Display anzeigen, wird von Kameras auch erkannt. Das habe ich zumindest mit dem Computerbildschirm ausprobiert. Ist vielleicht sogar besser für die Erkennung geeignet. Der Marker erinnert mich an April-Tags.


MfG

Zitat:

---

Zitat von Moppi

Der Kontaktübergangswiderstand

---

würden solche messingpinsel diesen nicht senken?

2V Spannungsabfall heißt ja 1V/Kontakt. Aber bei welchem Strom?

Den Bilder nach zu urteilen ist ein Netzteil angeschlossen, zum Laden für 7V NIMH-Akku. Vielleicht 9V - Netzteil oder 12V.

Kontaktübergangswiderstand: Modelleisenbahn ist ein guter Tip, da hab ich noch nicht dran gedacht. Zum Hintergrund: Als ich die Basisstation gebaut hatte, habe ich genommen was ich so an Metallplatten und Achsen rumliegen hatte. Ich habe hier keine Materialeigenschaften auf Leitfähigkeit o.ä. untersucht. Mein vorheriger Roboter hatte übrigens mit Kupferplatten weniger Spannungsabfall als der jetzige mit den Alu?*-Platten, die Basisstation habe ich weiter verwendet.

Den Gesamtstrom kenne ich ehrlich gesagt nicht, da ich nur den Betriebsstrom messe, nicht den Ladestrom. Wird der Akku nicht geladen, liegen etwa 11V bei 0.5A an. Das Netzteil liefert bei 12V max 5A.

Fiducial Marker: Ich hab Lampen an Bord, ob sie reichen den Tag zu erkennen, habe ich noch nicht ausprobiert. Zur Not könnte ja ich ja auch eine Nachricht an die Hue-Lampen schicken ;)

*Es ist Metall und nicht nicht magnetisch ;)

Zitat:

---

Zitat von Defiant

Mein vorheriger Roboter hatte übrigens mit Kupferplatten weniger Spannungsabfall als der jetzige mit den Alu?*-Platten

*Es ist Metall und nicht nicht magnetisch ;)

---

Mein erster Gedanke war auch !!!Alu!!! das geht nicht gut. Egal wie gut gekratzt/geschliffen - das Zeug passiviert sich doch an der bloßen Umgebungsluft und wird oberflächlich schlecht leitend.

Kritik angekommen. Ich habe noch eine Kupferplatte rumliegen.

Neues Ziel: Bier holen. Zwischenziel: Bier greifen, dafür reicht eine 3D-Kamera und YOLO:

https://vimeo.com/599737982 https://vimeo.com/599737982

Klasse Projekt!