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

[HaWe]

Kern von HaWe's Aussgae war ja nicht die Kalibrierung, sondern dass durch die Fusion der Messdaten bei stehendem Objet und wechselndem Magenetfeld der kompass trotzdem die Ruhe bewahrt ... ich denke es macht aber am emisten Sinn, alle Faktoren selber zu erfassen und auszuwerten. Ich glaube kaum das ein "Consumer Class" Produktjemals diesen Grrad der Störfestigkeit erreichen wird.

In meinem alten Institut hat man auch einen 100k teuren hochleistungs positionssensor-monoblock gekauft damit man auch die vibrationen der flugzeugmotoren aus dem messignal rausrechnen kann

genau,
den Roboter leer oder beladen zu kalibrieren bringt gar nichts, weil die wechselnde Beladung und jede Drehung des ferromagnetischen Roboterarms oben drauf sofort alles wieder zunichte macht.
Selber rechnen ist aber ebenso übermäßig aufwändig (mindestens, wenn nicht sogar komplett illusorisch) wie den Tinkerforge Sensor auf meinem Arduino oder Pi implementieren zu wollen.
Grundsätzlich zeigt aber Tinkerforge immerhin, dass sie es wohl ziemlich perfekt geschafft haben, und auch, dass es sicherlich einiges (!) an Gehirnschmalz erfordert hat, denn selbst die Version 1.0. war ja noch längst nicht so gut, und auch hier steckt sicher schon etliches an Entwicklungsarbeit drin, was ich alleine mit meinen Kenntnissen niemals erreichen könnte -
- hier nochmals der Link:
https://www.youtube.com/watch?v=Aq3SqVen5AQ


aber wie gesagt, dieses Topic geht ja um den Boschsensor mit eingebautem Signalprozessor, und es wäre ntl super, wenn der das auch so gut hinkriegen würde.
Aber im Falle dass nicht: was soll ich mit einem solchen Gerät samt Signalprozessor, wenn ich dann doch alles selber rechnen müsste? Ich Suche ja gerade eine Alternative zum Tinkerforge, die das eben schon kann.

[shedepe]

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.

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

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