Archiv verlassen und diese Seite im Standarddesign anzeigen : IMU Bosch BNO055 (z.B. Arduino, Raspberry Pi)
hallo,
hat jemand Erfahrung mit der IMU Bosch BNO055 (z.B. Arduino, Raspberry Pi)? Wie gut funktioniert Sensor Fusion mit seinen Einzel-Sensoren, und ist er mit seinem eingebauten Signal-Prozessor mit div. statistischen oder stochastischen Filtern unempfindlich gegen sich bewegende magnetische Störfelder?
https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview
Soweit ich das lese muss der nach jedem Power Up kalibiriert werden oder Klaibierdaten bekommen
ein MPU-6050 benötigt das meines Wissen nach nicht und hat glaube ich dieselben Funktionen wnen nicht vll. eine Spur mehr!
Soweit ich das lese muss der nach jedem Power Up kalibiriert werden oder Klaibierdaten bekommen
ein MPU-6050 benötigt das meines Wissen nach nicht und hat glaube ich dieselben Funktionen wnen nicht vll. eine Spur mehr!
hallo,
danke, wenn der immer kalibriert werden muss, dann scheidet er aus. Außerdem ändern sich die Magnet-Störfelder auch während des Betriebs, von daher ist eine Kalibrierung am Anfang nicht so hilfreich.
Der MPU6050 oder 9050 hat aber keinen Signalprozessor an Bord.
Ich habe den CMPS11, dessen Gyro ist sehr gut durch den Magnetfeldsensor stabilisiert, aber nicht umgekehrt, daher dreht der ermittelte Kurs (yaw, heading) bei Störfeldern um sage und schreibe bis zu 180°.
Ich suche daher eine IMU, bei der der Kompass durch den Gyro stabilisiert wird und dessen (geringe, normale) Gyro-Drift per Filter (Highpass?) eliminiert wird, sodass man eine stabile Kursanzeige hat auch bei starken wechselnden Magnet-Störfeldern.
Es gibt tatsächlich bereits so einen Sensor (Thinkerforge IMU Brick 2), der ist aber leider von den Treibern her (kombiniert TCP/IP und USB) absolut nicht zu händeln für mich (Arduino oder Raspi C/C++).
Meine Hoffnung war daher einer dieser genannten Bosch Sensoren.
Sorry ich glaube das war der MPU 91irgendwas von sparkfun, der hat angeblich schon fusiondaten und embedded logic dafür drinne
den 6050 hab ich jetzt bei mir im einsatz, daher der gedankendreher, aber da reichen mir die üblichen daten schon aus :)
- - - Aktualisiert - - -
doppelkorrektur, es IST der 6050
https://www.sparkfun.com/products/13762 das ist der 9250 (9150 ist veraltet)
https://www.sparkfun.com/products/11028 das ist der 6050 ließ dir mal die ebschreibuing durch, hört sich schwer nach dem an was du suchst
---
Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronization and gesture detection
Embedded algorithms for run-time bias and compass calibration. No user intervention required
Sorry ich glaube das war der MPU 91irgendwas von sparkfun, der hat angeblich schon fusiondaten und embedded logic dafür drinne
den 6050 hab ich jetzt bei mir im einsatz, daher der gedankendreher, aber da reichen mir die üblichen daten schon aus :)
und du bist sicher, dass der MPU 91irgendwas seinen Kompasskurs / yaw / heading gegen vorbei bewegte Magnete entstört gefiltert kriegt?
vorbeibewegte magneten stören sogar eine mechanischen kompass, sowas kann man nicht "kurzfristig" kompensieren!
vorbeibewegte magneten stören sogar eine mechanischen kompass, sowas kann man nicht "kurzfristig" kompensieren!
doch, kann man, denn der Gyro reagiert ja NICHT darauf, also kann man den Kompasswert durch die sich dann nicht ändernden Gyro / Acc Werte dadurch stabilisieren - man braucht nur die passenden Filter und Prozessoren dafür.
Der Thinkerforge IMU Brick 2 kann das sehr gut, aber wie gesagt....
Che Guevara
17.07.2017, 13:21
Hi,
sowas kann man sich relativ leicht selbst machen:
Die Länge des Vektors des gemessenen Magnetfeldes gibt Auskunft darüber, wie stark das aktuell vorliegende Magnetfeld ist. Bei einem kalibrierten Magnetometer sollte der Wert, egal in welcher Orientation, immer gleich 1 sein. Befindet sich nun eine Störquelle in der Nähe, so verändert sich die Stärke des Magnetfeldes und dementsprechend die Länge des Vektors.
Somit kann man nun entweder den Winkel nur dann abgleichen, wenn |M|==1 oder eine Variable benutzen:
a = ConstrainF(absf(1.0f - |M|),0.0f,0.1f);
Coeff = 0.99f + a;
Winkel = ((Winkel+(Gyro*dt)) * (Coeff)) + (MagWinkel * (1.0f-Coeff));
Vielleicht hilfts ja weiter.
Gruß
Chris
Video:
https://www.youtube.com/watch?v=Aq3SqVen5AQ
https://www.youtube.com/watch?v=Aq3SqVen5AQ
(hat sich überschnitten)
die Kompass-Kompensation ist nicht trivial, denn der Robot bewegt sich ja dabei, also müssen die Gyro-Werte mit berücksichtigt werden, aber dessen Drift muss herausgerechnet werden (Extended Kalman, Madgwick, Mahony Filter etc.)
Aber der Thinkerforge IMU 2.0 scheidet wegen Treiber-Monstern ja aus, meine Idee daher ob der von Bosch das auch kann.
Holomino
17.07.2017, 13:41
Bei einem kalibrierten Magnetometer sollte der Wert, egal in welcher Orientation, immer gleich 1 sein.
Ist das Indoor so?
Ist das Indoor so?
nein, ganz bestimmt nicht, und auch nicht out-doors, denn der Robot hat ja Eisen- und Magnetteile in sich und an sich, und er wird auch mit Eisen- und Magnet-Teilen beladen oder sie werden an ihm vorbeibewegt (z.B. durch den Greifer, oder sie bewegen sich selbstständig), Elektromagnete wie Motoren etc. außerdem noch mit wechslender Stromzufuhr.
Che Guevara
17.07.2017, 14:17
Hi,
also je nach Umgebung funktioniert das natürlich besser oder schlechter, aber mit einer Hard-Iron Kalibrierung (die man immer machen sollte, MINIMUM) hat man schon mal die ferromagnetischen Störfaktoren des eigenen "Körpers" ausgeblendet.
So ähnlich läuft bei mir eine Fusion auf meiner Drone, die ist natürlich fast immer Outdoor, aber da gibts auch Störquellen, welche so keinen Einfluss haben!
Je genauer man kalibriert, desto genauer lassen sich Störfelder erkennen und ausblenden. Zusätzlich gäbe es noch eine dynamische Kalibrierung, die eben solche Einflüsse (zb. Indoor) korrigiert, da muss ich aber passen.
Gruß
Chris
Holomino
17.07.2017, 14:52
Nix für ungut. Meine Frage: Ist mit einer IMU alleine die absolute Richtungsdetektion überhaupt möglich, wenn magnetische Störfelder oder Abschirmungen auftreten?
Soweit ich weiß, wird der Kompasssensor als Driftkompensation für das Gyroskop verwendet. Mit dem Kalman-Filter multiplizierst Du vereinfacht gesehen Varianzen. Wenn allerdings die Varianz des Kompasses ungültig ist (was willst Du als Varianz annehmen, wenn ein Magnet durch die Wohnung springt?), kann auch der Kalman nix mehr machen. Der müsste den Kompassfehler detektieren und vorübergehend die Kalmanerei als Errorstate aussetzen.
Was passiert im dynamischen Fall bei der Vorbeifahrt am Magneten?
Kein Problem, wenn das Störfeld schnell genug verschwindet, dann sollte der Kalman wieder greifen, bevor der Drift ein Problem wird.
Was passiert aber jetzt, wenn ich meinen Roboter im Stillstand neben dem Magneten parke und der Kalman nicht greift? Dann müsste der Gyro anfangen zu driften! Oder ich kalibriere den Kompass im Störfeld durch einen Turnaround neu?!? Dann werde ich Gleiches tun müssen, wenn ich aus dem Störfeld wieder herausfahre.
Also ich bin der Meinung, ohne externes Zutun kann's nicht funktionieren. Die IMU kann's nicht alleine, egal was man da intern fusioniert oder filtert.
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
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
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.
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.
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.
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.
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.
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 :D
https://github.com/Tinkerforge/imu-v2-brick/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/
(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!
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.
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
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 :)
Aber du sagtest ja 10-Zeiler, wenn du das also schaffst, sehr gerne
bitte lies nochmal genau nach kollege ... cih sagte 10zeiler um das ding per USB anzusteuern
bitte lies nochmal genau nach kollege ... cih sagte 10zeiler um das ding per USB anzusteuern
gerne auch per USB, wenn der Kurs ähnlich einfach zu pollen ist:
#include <IMU2USB.h>
double heading = getIMUheading();
wie das intern abläuft in der Treiber-Lib, ist letztendlich egal, das kann eine "Black Box" bleiben, Hauptsache, der Kurs stimmt. Ein USB Kabel einstecken ist ja sogar auch noch viel einfacher als enzelne i2c oder UART Kabellitzen.
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.
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.
@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-v2-brick/blob/master/software/examples/c/example_all_data.c
welche daten davon du jetzt brauchst ist dir überlassen, denn andere daten würdest du über I2C auch nciht bekommen ;)
@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-v2-brick/blob/master/software/examples/c/example_all_data.c
welche daten davon du jetzt brauchst ist dir überlassen, denn andere daten würdest du über I2C auch nciht bekommen ;)
ja, kenn ich, die Daten habe ich sogar schon etliche Wochen hier auf meinem Compi heruntergeladen und abgespeichert. Aber ich sach ja: viel zu kompliziert dieser Sensor, zu unüberschaubar die Treiber und die Daten, ein einfaches Kurs-Heading (yaw, gefiltert und stabilisiert) ist nicht dabei, nur Quaternionen und Eulerwinkel, und daher habe ich die Sache mit dem IMU 2 ja auch abgehakt.
Der CMPS11 dagegen hat ja auch einenn Signalprozessor, hat einen sehr einfachen i2c Treiber, nur ist der verbaute, interne Filteralgorithmus extrem schlecht im Vergleich. Der müsste nur besser programmiert sein, dann ginge es ganz einfach mit dem Auslesen - auch nur ein 10-Zeiler, der aber dann tatsächlich funktioniert!
s.z.B. hier:
http://www.mindstormsforum.de/viewtopic.php?f=78&t=8689&p=70055#p70055
es ist also möglich, so ein IMU richtig zu programmieren (IMU2) und auch einfach auszulesen (CMPS11), aber das eine ist sinnlos für mich ohne das andere. Daher meine Idee, möglicherweise den Bosch Sensor verwenden zu können - scheint aber auch nicht zu gehen.
also der IMU als Basis und vor allem die bereits fertigen Sources ... sind die BESTE vorlage die du haben könntest! Was du in dem Video siehst ist post processing am PC, was du willst ist dieses Processing im Chip ... das GEHT grundsätzlich ... abe rich glaube du unterschätzt hie gerade GEWALTIG den aufwand die rohdaten des BNO zu verabeiten ... sinnvoller wäre es wenn du dich mit dem source im github auseinandersetzt, ihn begreifst, und umschreibst soweit es dir möglich ist oder du adaptierst anderen code hinein, compilierst es und spielst es wieder auf den brick (das ist ein SAM/Cortex Prozessor die haben alle identische Programmierschnittstellen sog. SWD, das Tool dafür kostet original von Atmel 120€ über nen distri 70€ und wenn du nach fremd tools suchst bestimmt noch weniger, aber die habne dann ein mir zumindest unbekanntes flash tool dass du dann noch verstehen musst)
also wie gesagt, ICH verstehe den IMU2 nicht, ich wäre - nein: bin! -mit dem Code und der Implementierung überfordert, aber es war DEINE Idee mit dem 10-Zeiler.
Ich muss da also passen, aber wenn du mir den 10-Zeiler mit deinen Kenntnissen liefern kannst, perfekt.
ich sagte nur das du mit dem 10-zeiler an daten kommst, dass dir die mathematik dahinter zu hoch ist versteh ich zwar (mir leider auch) aber das hattset du anfangs ja auch nicht gewünscht :D du wolltest wissen ob man mit dem BN= allein arbeiten kann, servierst den IMU als vergleich der einen SAM prozessor an board hat und bekommst sogar 90% der arbeit frei haus ... wenn du die restliche mathematik nicht beherrschst müsstest du auch reinschreiben dass du hilfe bei den algorithmen erwartest ... der 10 zeiler bringt dich nur über USB an die messdaten ran! ob die schon kompensiert sind weis ich nicht, das müsstest du schlicht und ergreifend testen
ich sagte nur das du mit dem 10-zeiler an daten kommst, dass dir die mathematik dahinter zu hoch ist versteh ich zwar (mir leider auch) aber das hattset du anfangs ja auch nicht gewünscht :D du wolltest wissen ob man mit dem BN= allein arbeiten kann, servierst den IMU als vergleich der einen SAM prozessor an board hat und bekommst sogar 90% der arbeit frei haus ... wenn du die restliche mathematik nicht beherrschst müsstest du auch reinschreiben dass du hilfe bei den algorithmen erwartest ... der 10 zeiler bringt dich nur über USB an die messdaten ran! ob die schon kompensiert sind weis ich nicht, das müsstest du schlicht und ergreifend testen
die Ausgangsfrage war ja zunächst nur, ob der Boschsensor überhaupt in der Lage ist, die Magnetstörungen rauszurechnen.
Sobald das verneint worden wäre, wäre das Thema bereits sofort durch gewesen.
Dann wäre die nächste Frage, welche Daten er liefert.
Ich kenne ihn nicht und seine Treiber-Libs, daher wäre das dann als nächstes zu klären gewesen - das hat sich aber ja aber schon vorher erübrigt, wie ich es sehe, wegen der zu schlechten Magnetstörungs-Filter.
Kennen tu ich aber bisher nur den CMPS11, welcher per UART und I2C und onbaord-Signalprozessor die Daten wie yaw, pitch, roll ganz simpel abfragen lässt - kein Grund also, daran zu zweifeln, dass es nicht auch Bosch oder sogar der IMU2 gekonnt hätten oder können könnten.
Ich selber habe auch nie in Frage gestellt, dass die IMU2 Daten und Treiber viel zu kompliziert sind, aus mannigfachen Gründen, und dass ich damit überfordert bin, daher kam er für mich momentan auch nicht in Betracht
- bis du mit deinem 10-Zeiler kamst, für welche Schittstelle auch immer - kein Grund also für mich, daran zu zweifeln, dass dein 10-Zeiler den bereinigten und gefilterten yaw-Wert liefern könnte. Wenn das dein 10-Zeiler also gekonnt hätte: super - wenn nicht, bleibts dabei, dass der IMU2 zu kompliziert ist für mich...: bis zu dem Moment wo irgendwer tatsächlich die gesuchten Werte treibermäßig einfach zur Verfügung stellen kann.
Wenn das also eintrifft, ist er wieder im Rennen, sobald 10-Zeiler aber nur theoretisch möglich wären, aber nicht praktisch verfügbar sind, bleibt er weiter illusorisch, dann muss man andere IMUs suchen.
die Ausgangsfrage war ja zunächst nur, ob der Boschsensor überhaupt in der Lage ist, die Magnetstörungen rauszurechnen.
Sobald das verneint worden wäre, wäre das Thema bereits sofort durch gewesen.
ausgehend von der Tinkerforge Seite ist das (kontinuierliche eigenkalibrierung) wohl schon implementiert!
Dann wäre die nächste Frage, welche Daten er liefert.
siehe gelinkten example code von mir
Ich selber habe auch nie in Frage gestellt, dass die IMU2 Daten und Treiber viel zu kompliziert sind, aus mannigfachen Gründen, und dass ich damit überfordert bin, daher kam er für mich momentan auch nicht in Betracht
Treiber sind scheiß egal, das Gerät meldet sich als USB Netzwerkkarte, du must nur eine TCP Verbindung aufbauen (siehe example code) Was die daten angeht, das lässt sich mit ein klein wenig Internet doch sicher alles brauchbar verwendn um Positionsdaten zu gewinnen!
Das Example liefert auf jeden fall schonmal die ganzen Ausrichtungsdaten die du brauchst und wen ich die Artikelbeschreibung so lese auch bereits korrigiert unf gefiltert ... das müsste man ggf. halt testen
das jetzt in einen yaw umzurechnen würde ich schon eher in ein neues topic packen, das ist was für mathematik/algorithmik köpfe
ausgehend von der Tinkerforge Seite ist das (kontinuierliche eigenkalibrierung) wohl schon implementiert!
siehe gelinkten example code von mir
Treiber sind scheiß egal, das Gerät meldet sich als USB Netzwerkkarte, du must nur eine TCP Verbindung aufbauen (siehe example code) Was die daten angeht, das lässt sich mit ein klein wenig Internet doch sicher alles brauchbar verwendn um Positionsdaten zu gewinnen!
Das Example liefert auf jeden fall schonmal die ganzen Ausrichtungsdaten die du brauchst und wen ich die Artikelbeschreibung so lese auch bereits korrigiert unf gefiltert ... das müsste man ggf. halt testen
das jetzt in einen yaw umzurechnen würde ich schon eher in ein neues topic packen, das ist was für mathematik/algorithmik köpfe
wäre ja schön, wenn das alles so einfach geht, wie du es wohl verstehst.
Ich selber kann das aber nicht, weder mathematisch noch sonst was, das hast du doch sicher inzwischen verstanden.
Ich mache dir dazu daher ein Angebot, das du hoffentlich nicht abschlagen kannst, da es ja alles viel eher in deinen Kompetenzbereich fällt:
Du kaufst den IMU2 und bringst ihn so zum Laufen, wie ich es oben skizziert habe mit der einfachen stabilisierten, ausgerechneten yaw-Abfrage.
Wenn er läuft, kaufe ich ihn dir ab, bezahle dir zusätzlich 10 EUR für Porto und 30 EUR für deinen Treibercode oben drauf - und fertig!
Wie wär's ? 8)
reicht es wenn er auf basis eines raspberry pi arbeitet ?
reicht es wenn er auf basis eines raspberry pi arbeitet ?
ja klar, das würde ausreichen, ich habe einen Pi2B (alte Ausführung). Die freien Schnittstellen habe ich ja oben genannt: 1 USB Buchse ist noch frei, außerdem i2c-1.
Ich arbeite allerdings nie mit make oder makefile oder cmake, ausschließlich mit Geany und den Compile- und build-Flags, die man dort in den Preferences fest eingeben kann. Wenn du also dafür die -l und -I Parameter angeben kannst, dann geht es auf meinem Pi (siehe meinen obigen Link zum CMPS11, in diesem Raspi-Beginner-Topic sind alle üblichen Settings von Anbeginn an definiert.)
ich würde das tool und dessen software unberührt lassen, ich würde erstmal so ein sample nehmen und dann mal etwas internet nehmen um aus dem quaternionenkram meinen yaw zu rechnen :D
PS will soweiso gerade bei tinkerforge was bestellen, die haben da kapazitive erdfeuchtesensoren ... die kann ich auch so benutzen, dafür brauch ich den brick kram rundherum nicht
ich würde das tool und dessen software unberührt lassen, ich würde erstmal so ein sample nehmen und dann mal etwas internet nehmen um aus dem quaternionenkram meinen yaw zu rechnen :D
PS will soweiso gerade bei tinkerforge was bestellen, die haben da kapazitive erdfeuchtesensoren ... die kann ich auch so benutzen, dafür brauch ich den brick kram rundherum nicht
passt ja ! :)
also, abgemacht?
sowas wie das hier ist das Ziel:
// filename: imu2test.c
#include <IMU2USB.h>
int main() {
//... init ...
while(1) {
double heading = getIMUheading(); // oder "yaw" für "heading"
printf("%7.2f", heading);
delay(10);
}
}
für Geany was in dieser Art:
g++ -lwiringPi -pthread -o "%e" "%f" -lxxxxx -Iyyyyy
der ganze tinkerforge brick kram hat ja mal richtig hand und fuß zu anständigen preisen und sie liefern sogar nach in DE mit DHL ... ich bin begeistert ... gleich mal ne großbestellung draus machen XD
die idee mit dem stapeln ist zwar nicht neu aber die extension und multimaster .... und die bricklet .... ports ist mal richtig pfiffig!
Ich liefere wenn dann nur source code, das compilen sollte auch so funktionieren!
der ganze tinkerforge brick kram hat ja mal richtig hand und fuß zu anständigen preisen und sie liefern sogar nach in DE mit DHL ... ich bin begeistert ... gleich mal ne großbestellung draus machen XD
die idee mit dem stapeln ist zwar nicht neu aber die extension und multimaster .... und die bricklet .... ports ist mal richtig pfiffig!
Ich liefere wenn dann nur source code, das compilen sollte auch so funktionieren!
genau, so sollte es auch sein, danke! :)
kann man sich ein Topic eigentlich irgendwie sticky machen ? also irgendwo im profil ne persönliche notiz? ich ersauf hier schon fast an meinen eigenen lesezeichen im browser :P
kann man sich ein Topic eigentlich irgendwie sticky machen ? also irgendwo im profil ne persönliche notiz? ich ersauf hier schon fast an meinen eigenen lesezeichen im browser :P
vlt kannst du dir ja selber ne PN mit der url schicken :p
Hardware ist angekommen @HaWe .. mal schauen was ich heute Nachmittag so schaffe, habe noch ein Problem mit meinem Datalogger zu lösen, zum Glück übernimmt Petrus gerade die Bewässerung meines Balkons
Hardware ist angekommen @HaWe .. mal schauen was ich heute Nachmittag so schaffe, habe noch ein Problem mit meinem Datalogger zu lösen, zum Glück übernimmt Petrus gerade die Bewässerung meines Balkons
alles klar, bin gespannt! Danke für die Nachricht! :)
zwischenbericht: brick läuft erstmal, alle abhängigkeiten sind installiert
negativ: man braucht den sog. brickdemon ... ich lgaub ich versteh was du mit treiber meinst ... aber die installation ist doch eigentlich ganz leicht
positiv: als ich hab jetzt keinen ultra starken magneten hier, aber man sieht wie das magnetsignal rumeiert, aber das stört die ausrichtung nicht im geringsten
Kommst du damit klar den service zu installieren oder ist das schon ein no-go?
zwischenbericht: brick läuft erstmal, alle abhängigkeiten sind installiert
negativ: man braucht den sog. brickdemon ... ich lgaub ich versteh was du mit treiber meinst ...
Kommst du damit klar den service zu installieren oder ist das schon ein no-go?
hallo,
ich habe bislang Null Erfahrung mit demons und kenne sie nur vom Hörensagen. Ich weiß weder, wie man die installiert noch wie man sie startet, an sich wollte ich eine einfache Treiberlib oder Datentransfer mit einfachen Protokollen, wie sonst auch für i2c-, SPI- oder UART-Sensoren.
Was genau steckt denn aber hinter diesem speziellen demon, wie genau sind die Installations- und Startbefehle?
https://www.tinkerforge.com/en/doc/Software/Brickd_Install_Linux.html#brickd-install-linux
unter windows ist es einfach nur ne exe die man installiert
unter linux lädt man sich das ".deb" file runter und installiert es mit dem packagemanager
für den RaspberryPi mit Debian Lite sind es 3 zeilen
sudo apt-get install pm-utils
wget http://download.tinkerforge.com/tools/brickd/linux/brickd_linux_latest_armhf.deb
sudo dpkg -i brickd_linux_latest_armhf.deb
pm-utils fehlt leider in der standard installation und wird auch nicht im guide erwähnt, aber bei der installation steht es dabei wenn es nicht installiert worden ist!
Konfigurieren musst du glücklicherweise nichts, ansonsten ist ein Demon nichts weiteres als ein "Dienst" also ein Programm dass bei Systemstart mitläuft und Funktionen anbietet
In diesem Fall erkennt der BrickDemon wenn ein Brick per USB angeschlossen wird und stellt ihn als Socketverbindung über localhost bereit
... Daher auch meine falsche Annahme dass der sich als USB Netzwerkkarte anmeldet ... wäre ja auch zu schön gewesen ...
https://www.tinkerforge.com/en/doc/Software/Brickd_Install_Linux.html#brickd-install-linux
unter windows ist es einfach nur ne exe die man installiert
unter linux lädt man sich das ".deb" file runter und installiert es mit dem packagemanager
für den RaspberryPi mit Debian Lite sind es 3 zeilen
sudo apt-get install pm-utils
wget http://download.tinkerforge.com/tools/brickd/linux/brickd_linux_latest_armhf.deb
sudo dpkg -i brickd_linux_latest_armhf.deb
pm-utils fehlt leider in der standard installation und wird auch nicht im guide erwähnt, aber bei der installation steht es dabei wenn es nicht installiert worden ist!
Konfigurieren musst du glücklicherweise nichts, ansonsten ist ein Demon nichts weiteres als ein "Dienst" also ein Programm dass bei Systemstart mitläuft und Funktionen anbietet
In diesem Fall erkennt der BrickDemon wenn ein Brick per USB angeschlossen wird und stellt ihn als Socketverbindung über localhost bereit
... Daher auch meine falsche Annahme dass der sich als USB Netzwerkkarte anmeldet ... wäre ja auch zu schön gewesen ...
hallo,
also das ist ja genau das, was mich von Anfang an abgeschreckt hat - das ist mir eindeutig zu monstermäßig und zu wirr.
Um einen Demon downzuloaden, müsste etwas wie ein
sudo apt-get install brickdemon
reichen,
und um ihn zu starten, ein einfaches
sudo ./brickdemon
bzw
system("sudo ./brickdemon");
aus dem C-programm heraus.
Ansonsten müsste fürs eigene Programm ein einfaches #include ausreichen und einfache Compiler und Linker-Flags, wie ich sie oben beschrieben habe, samt simplem IMU-polling
double yaw = getIMUheading();
oder ähnlich.
Vorbild kann nach wie vor der CMPS11 sein, wie schon erwähnt, da braucht man noch nicht mal eine Lib einzubinden, es reicht i2c-Register auszulesen (z.B. mit wiringPi / wiringI2C), in denen die fusionierten gefilterten Werte ja bereits drinstehen.
ps,
alternativ, statt einer Lib, den erwähnten "10-Zeiler" (von mir aus auch 20-Zeiler) einfach in mein eigenes C-Programm hinein zu copy-and-pasten, wie eine beliebige zusätzliche (komplizierte) C-Funktion, wäre natürlich auch ok, wenn man dann die yaw-Werte ähnlich simpel pollen kann.
system("sudo ./brickdemon");
sudo /etc/init.d/brickd start
sudo /etc/init.d/brickd stop
sudo /etc/init.d/brickd restart
sudo apt-get install brickdemon
das package ist leider meines wissens nach in keinem public repository, also musst du es schon mit wget laden, aber das ist standard bei allen linux distros
Daher hier 2 Varianten, eine nach deinem Wunsch, welche vorraussetzt dass die deb file in einem bestimmten ordner liegt und die alternative variante die ähnlich simpel ist und genau so gut funktioniert
wget -P /var/cache/apt/archives/ http://download.tinkerforge.com/tools/brickd/linux/brickd_linux_latest_armhf.deb
sudo apt-get install brickd_linux_latest_armhf
ALTERNATIV
wget http://download.tinkerforge.com/tools/brickd/linux/brickd_linux_latest_armhf.deb
sudo dpkg -i brickd_linux_latest_armhf.deb
sudo apt-get install -f
.... ich lese meinen artikel und frage mich gerade warum ich mich früher immer so blöd angestellt habe .. es ist doch eigebntlich total einfach wenn man erstmal ein wenig in den dokus ließt ....
PS: apt-get benutzt auch nur
sudo dpkg im hintergrund, aber es lädt zusätzlich die abhängigkeiten mit runter
in der alternativen version benutz ich den "wunderbefehl"
sudo apt-get install -f ... den solltest du dir unbedingt merken, der reparieret kaputte package installationen (verbindungsverlust z.B. oder eben ein unvollständig installiertes .deb)
ich spiele gerade auch mit dem gedanken die bridge komponente aus dem brickd source code zu extrahieren, aber das ist ein ganz schönes stück arbeit
hallo,
das hier einmalig in die Konsole zu copy-and-pasten ist ntl kein Problem:
wget -P /var/cache/apt/archives/ http://download.tinkerforge.com/tools/brickd/linux/brickd_linux_latest_armhf.deb
sudo apt-get install brickd_linux_latest_armhf
diese Befehle hier für den Demon allerdings müssen intern von meinem C-Programm aus zugänglich sein, notfalls über den system execute cmd:
sudo /etc/init.d/brickd start
sudo /etc/init.d/brickd stop
sudo /etc/init.d/brickd restart
also z.B. bei Programmstart, am Anfang von main() :
system("sudo /etc/init.d/brickd start");
und bei Programmende, am Ende von main(), direkt vor exit(0) :
system("sudo /etc/init.d/brickd stop");
(sicher bin ich mir jetzt natürlich nicht, ob system von einem user Programm aus aufgerufen auch sudo Befehle für demons ausführen kann, das muss selbstverständlich klappen)
wenn das alles ist und genau so auch sicher funktioniert, kein Problem!
Wie genau pollt man dann die yaw- oder heading-Werte?
Ganz ohne Demon wäre es mir allerdings sympathischer, klarer Fall... ;)
das sollte genau so funktionieren, testen kann cih es erst heute nachmittag
daten habe ich auch schon gelesen, abe rich habe noch nichts konkretes was die ausrichtung angeht ... das demo tool wie gesagt zeigt dass der magnetfeldstörungen wohl ganz gut ignoriert
tag 3 .... ich habe DOCH eine kaputte SDCard ... neue ist(edit: sind) bestellt ... grmpf (besser ich hab mal etwas reserve)
SDCards liegen jetzt beim Paketshop, da mein anderes Prjekt eh gerade einen Dämpfer abbekommen hat kann ich heute nochmal hieran arbeiten.
@HaWe Messdaten habe ich unter Python übrigens schon erfolgreich ausgelesen, es kondensiert sich zu folgendem Code in C(ungetestet, das wollte ich heute ausprobieren, wenn ich dazu komme):
#include "ip_connection.h"
#include "brick_imu_v2.h"
typedef struct
{
float w;
float x;
float y;
float z;
}quaternion_s;
quaternion_s q;
// Create IP connection
IPConnection ipcon;
ipcon_create(&ipcon);
// Create device object
IMUV2 imu;
imu_v2_create(&imu, UID, &ipcon);
// Connect to brickd
if(ipcon_connect(&ipcon, HOST, PORT) < 0) {
fprintf(stderr, "Could not connect\n");
return 1;
}
// Don't use device before ipcon is connected
// Get current quaternion
int16_t w, x, y, z;
if(imu_v2_get_quaternion(&imu, &w, &x, &y, &z) < 0) {
fprintf(stderr, "Could not get quaternion, probably timeout\n");
return 1;
}
q.w = w/16383.0;
q.x = x/16383.0;
q.y = y/16383.0;
q.z = z/16383.0;
float yaw = atan2(2.0*(q.y*q.z + q.w*q.x), q.w*q.w - q.x*q.x - q.y*q.y + q.z*q.z);
float pitch = asin(-2.0*(q.x*q.z - q.w*q.y));
float roll = atan2(2.0*(q.x*q.y + q.w*q.z), q.w*q.w + q.x*q.x - q.y*q.y - q.z*q.z);
SDCards liegen jetzt beim Paketshop, da mein anderes Prjekt eh gerade einen Dämpfer abbekommen hat kann ich heute nochmal hieran arbeiten.
@HaWe Messdaten habe ich unter Python übrigens schon erfolgreich ausgelesen, es kondensiert sich zu folgendem Code in C(ungetestet, das wollte ich heute ausprobieren, wenn ich dazu komme):
#include "ip_connection.h"
#include "brick_imu_v2.h"
typedef struct
{
float w;
float x;
float y;
float z;
}quaternion_s;
quaternion_s q;
// Create IP connection
IPConnection ipcon;
ipcon_create(&ipcon);
// Create device object
IMUV2 imu;
imu_v2_create(&imu, UID, &ipcon);
// Connect to brickd
if(ipcon_connect(&ipcon, HOST, PORT) < 0) {
fprintf(stderr, "Could not connect\n");
return 1;
}
// Don't use device before ipcon is connected
// Get current quaternion
int16_t w, x, y, z;
if(imu_v2_get_quaternion(&imu, &w, &x, &y, &z) < 0) {
fprintf(stderr, "Could not get quaternion, probably timeout\n");
return 1;
}
q.w = w/16383.0;
q.x = x/16383.0;
q.y = y/16383.0;
q.z = z/16383.0;
float yaw = atan2(2.0*(q.y*q.z + q.w*q.x), q.w*q.w - q.x*q.x - q.y*q.y + q.z*q.z);
float pitch = asin(-2.0*(q.x*q.z - q.w*q.y));
float roll = atan2(2.0*(q.x*q.y + q.w*q.z), q.w*q.w + q.x*q.x - q.y*q.y - q.z*q.z);
sieht ja echt schon ungeheuer vielversprechend aus! Bin extrem gespannt! :cool:
Wieso ruft ihr imu_v2_get_quaternion() auf und formt das in Euler-Winkel um anstatt direkt imu_v2_get_orientation() den Euler-Winkel auszulesen?
wenn du mir erklärst was genau die in der doku mit dem gimballock meinen und warum sie dazu raten die quaternioen zu benutzen? wenn ich es recht verstehe, drehst du das ding auf hochkant und bekommst keine ausrichtugn mehr ... über die quaternionen soll dasd wohl nicht passieren, solange man die ausrichtung der achsen berücksichtigt ... meinem verständnis nach muss man das dann selber machen, weswegen ich den obigen ansatz verfolge ...
denke ich habe das WE mal irgendwo zwit dazwischen um mich wieder ran zu setzen
PS: nicht erklären was gimballock ist, sondern im konkreten kontext dieses sensors und warum sie davor warnen wenn nicht gemeint ist was ich gerade als annahme geschrieben habe :D
Ja, die Quaternion-Darstellung ist ohne Gimbal Lock. Allerdings nur solange wie man bei Quaternionen bleibt, bei der Umrechnung in Euler verliert man deren Vorteile.
Gimbal Lock ist in der Deutschen Wikipedia leider nicht mathematisch erklärt, bei Drehungen kann es zu Singularitäten (Sprünge bei einem Pitch von +90/-90°) kommen, Eine gute Erklärung kriege ich leider nicht hin, deswegen der Verweis auf [1].
Der Punkt ist: Das Problem hat man (soweit ich das verstehe) bei Berechnungen, z.B. Gegeben ist eine Position A. Welche Drehung d muss ich anwenden um zu Position B zu kommen. Beim einfachen auslesen des aktuellen Winkels, um die Drehung im 3D-Raum zu lesen kommt es zu keinem Problem. Die Eulerwinkel des IMU Bricks 2 sind hier nicht besser oder schlechter als die Eulerwinkel anderer IMUs.
[1] https://zfx.info/viewtopic.php?p=35924#p35924
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.