Wild Thumper ROS Roboter

[HaWe]

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

[Defiant]

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

[HaWe]

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!

[Defiant]

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.

[HaWe]

danke für dein Angebot! Was man letztlich bräuchte wäre eine einfache lib zum Einbinden

#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

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!

[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?

[HaWe]

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?