IMU Bosch BNO055 (z.B. Arduino, Raspberry Pi)

[HaWe]

Wenn man den BNO055 mit der Adafruit library verwendet kann man die Kalibrierung ganz einfach speichern und wieder reinladen. Wenn man außerdem keine absolute Magnetorientierung sondern nur eine relative braucht kann man sich sogar das sparen.

ich hatte es jetzt vielleicht schon das ein oder andere Mal erwähnt, aber Kalibrierung nützt absolut nichts, denn es ist für einen Navigations-Roboter, da brauche ich eine absolut sichere Kurs-Ermittlung, und was soll ich kalibrieren, wenn sich die Fremdmagneteinflüsse alle paar Millisekunden unvorhersehbar komplett ändern können?
schau dir das Video an, Teil 3, sowas mit den Fremdmagneten passiert laufend, und dabei bewegt sich das Teil auch noch mit bis zu 10 km/h in alle möglichen Richtungen vorwärts, rückwärts, und in Kurven. Odometrie für Kursrichtung geht nicht, da teilweise rutschiger Untergrund mit ungleicher beidseitiger Traktion. Also muss es eine IMU sein, die absolut Fremdmagnet-stabilisiert ist (Temperatur ebenfalls wechselnd, s. Video Teil 4, aber nicht so extrem, vielleicht 20° absolut indoors vs. outdoors). Eine passende Sensor Fusion und Filterung (s. Video Teil 3) kann das Problem lösen, und wie gesagt, per on-board-Signalprozessor, wie beim IMU Brick 2, für Raspi u/o Arduino (C/C++).
Der Raspi ist übrigens für den Robi eh der Hauptprozessor, aber ein Arduino Due hängt als Huckepack MCU als IO-Muxer sowieso auch schon per UART dran, dadurch ist UART am Raspi besetzt, SPI ist für Fremdhardware reserviert, aber I2C ist noch frei am Raspi und USB/UART per CH341. Am Arduino sind je 1 i2c, SPI und UART frei.
Das Video oben stellt ziemlich gut die Anforderungen dar, in allen Belangen, bis auf die Treiber, die per C/C++ code über I2C (wiringI2C, Arduino Wire) oder UART (wiringSerial, Arduino Serial) abgefragt werden sollen.

[Ceos]

okay ... blöd gefragt, was spricht dagegen den IMU Brick 2.0 zu nehmen? soweit ich die Doku verstehe, präsentiert der sich als USB Netzwerkkarte und mit der API ist ein Verbinden und auswerten der Daten ja nichts weiter als ein 10 Zeiler.

[HaWe]

kannst du den 10 Zeiler liefern, sodass ich den Kurs einfach per
double heading = getIMUHeading()
abfragen kann?
Ich verstehe von diesen IMU Brick 2 Treibern absolut nichts, und der wird ja auch auf einen Master-Brick augesetzt, damit er funktioniert, wie es aussieht. Aber wenn du davon Kenne hast - das wäre ntl genial.

[Ceos]

Ich topp das ganze sogar für dich, der original Sourcecode der auf dem IMU läuft liegt sogar frei verfügbar bei! Du kannst ihn runterladen, editieren dass er dir eine I2C Schnittstelle biete und drauf flashen! Schematics sind antürlich auch dabei. Auf der deutschenTinkerforge Seite hast du alles was du brauchst
https://github.com/Tinkerforge/imu-v...zipball/master

da ist alles drin, vom 10 Zeiler Example in verschiedenstens Srpachen mit der API bis hin zum Quellcode im Controller und Schaltplläne und sogar PCBs

ich geb zu, beim sopurce code könnte vll. noch der eine oder andere konflikt wegen fehlender referenzen dabei sein, aber versuch dich mit konkreten fragen (nur in englisch vermutlich) mal auf der github seite die in dem link drin steckt

https://github.com/Tinkerforge/imu-v2-brick/

im projekt selber ist alles sogar nochmal erklärt


das ding ist ja mal ne granate ... ganz ehrlich!

[HaWe]

kenn ich, kapiere ich aber nicht, weder wie es angeschlossen wird noch wie man was flasht noch wie man aus Quaternionen den 2D-Kurs berechnet - viel zu kompliziert für mich leider. 3 oder 4 Kabel anschließen und 3 oder 4 bytes per wiringPi oder Wire() aus i2c-Registern auslesen für den Kurs, das kann ich.

[Ceos]

das ist aber schade, dann zweifle ich generell schon am erfolg des projektes ... versuchs doch mal auf github ... die bricks haben einen I2C bus mit dem sie mit dem brick-master kommunizieren ... vll. hat sich schon jemand die mühe gemacht und das protokoll für dich in eine library gegossen damit du den bus mit dem PI direkt ansteuern kannst

[HaWe]

das ist aber schade, dann zweifle ich generell schon am erfolg des projektes ... versuchs doch mal auf github ... die bricks haben einen I2C bus mit dem sie mit dem brick-master kommunizieren ... vll. hat sich schon jemand die mühe gemacht und das protokoll für dich in eine library gegossen damit du den bus mit dem PI direkt ansteuern kannst

bis jetzt nicht, daher habe ich den Tinkerforge IMU Brick 2 auch inzwischen innerlich abgehakt, und daher meine neue Suche nach einem einfacheren Ersatz wie dem Bosch-Sensor, vorrausgesetzt, dessen Signalprozessor wäre ebenso intelligent programmiert wie der Tinkerforge IMU Brick2.
Aber du sagtest ja 10-Zeiler, wenn du das also schaffst, sehr gerne

[shedepe]

Also wir verwenden den BNO055 seit jetzt 2 Jahren in einem Robotersystem. (Das unteranderem mit diesem Sensor durch einen ganzen Park + Fußgängerzone autonom gefahren ist) Wir haben den Sensor bisher nie aktiv kalibriert. Das macht das Teil nämlich komplett von alleine. Der einzige Grund warum man die Kalibrierung speichern will, ist wenn man einen absoluten Winkel nach Norden braucht.

[HaWe]

hast du denn auch Elektromagnete und Stabmagnete drum herum und an wechselnden Stellen an Bord, die ganz in der Nähe unvorhersehbar ihren Platz wechseln?
wie reagiert der BNO055 denn auf Magnetstörfelder wie in dem Tinkerforge Video Teil 3? ich dachte, das Thema hätten wir schon besprochen?
Absolute Orientierung ist aber auch nötig, wegen map+explore.

[Ceos]

@HaWe ... hast du schonmal einen der Links besucht die ich gepostet habe ... und eventuell mal ein wenig gelsen und geklickt?

https://github.com/Tinkerforge/imu-v...ple_all_data.c

welche daten davon du jetzt brauchst ist dir überlassen, denn andere daten würdest du über I2C auch nciht bekommen