Sie sind nicht angemeldet.

Werbung

Boote kaufen

Windstärken

Windstärkentabelle

Hallo Besucher, willkommen im Segeln-Forum! Hier kannst Du Dich registrieren, um unser Forum in seiner vollen Pracht genießen zu können! - Weitere Infos zur Registrierung - Login für Mitglieder -

norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

101

Mittwoch, 12. September 2018, 15:59

@x-molich:

Sehe ich genau so. Der AHRS muss perfekt funktionieren, sonst kann man das vergessen. Am WE hatte ich den AHRS-Sensor zwischen zwei Kojenpolster in Mastfußnähe eingeklemmt, da ich noch keine saubere Konstruktion hatte. Das da gewisse Fehler auftreten können war mir schon bewusst, jedoch nicht solche großen Fehler. Die könne da nicht auftreten.

Im Internet findet man einige Beschreibungen zu der Problematik. Es hängt mit der Bewegung an sich zusammen und wie die Winkelberechnung umgesetzt ist. Man sieht ja kontinuierlich weglaufende Werte. Ob die jetzt mit der Temperatur zusammen hängen würde ich erstmal bezweifeln, da der Sensor bei mir gut eine Stunde vor der Aufzeichnung bereits lief und temperiert war. Sonne ist da auch nicht drauf gekommen, da der Sensor richtig im Polster eingeklemmt war. Den AHRS kann ich nicht weiter modifizieren, da im internen Microcontroller die Fusion abläuft. Kann auch sein, dass die da keine Fusion machen und nur die IMU-Daten benutzen. Das wäre natürlich blöd.

Zu Hause hatte ich immer nur in Ruhelage gemessen und nur mit gelegentlichen Bewegungen. Da gab es das Problem nicht. Daher war auch meine Frage an @the_muck: gerichtet, ob er nicht auch mal solche Tests machen könnte. Wäre interessant zu erfahren, ob sein Sensor besser funktioniert. In der Firma habe ich eine Taumelplatte. Ich könnte da auch noch einmal messen.

Norbert

norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

102

Mittwoch, 12. September 2018, 23:39

@x-molich:

Drifts im Kompass von AHRS-Systemen sind durchaus üblich und liegen im Rahmen von 1°/min. Da können auch die Fusion und Filter nichts dran ändern. Ich hätte jetzt nicht gedacht, dass das so groß ist. Folgende Ursachen könne dazu führen:

- Quaitisierungsrauschen des AD-Wandlers
- Analograuschen
- Offsetfehler
- Skalierungsfehler
- Temperaturinstabilität

Der Fehler meines AHRS liegt bei ungefähr 3°/min und ständiger Bewegung in allen Achsen. Das erklärt auch, warum der Sensor in Ruhe so gut arbeitet. Die Empfehlung in einigen Informationsquellen ist es, das System alle 8 Sekunden zu rekalibrieren, um den Summierungsfehler zu reduzieren. Ich muss allerdings dazusagen, dass ich den AHRS-Sensor nur beim Einschalten kalibriert habe und dann ohne weitere Kalibrierung gemessen habe. Im Ardupilot geht ohne GPS-Korrektur auch nichts. Ich hab das jetzt nur mal so grob überflogen.

Ohne regelmäßige Rekalibrierung und Offsetkorrektur durch den GPS wird man kein brauchbares Kompassignal erhalten. Das hatte ich auch in vielen anderen Beiträgen so gelesen.

So gesehen bewegt sich mein AHRS-Sensor im üblichen Rahmen, auch wenn er jetzt nicht so perfekt ist. Ich werde mir die Sache noch etwas genauer ansehen, bevor ich zu einem anderen AHRS-Sensor wechsle. Ich glaube kaum, dass andere Sensoren wesentlich besser sind.

Ich werde mal weitere bewegte Tests in meinem Auto machen. Dann kann ich das schneller verifizieren und muss nicht ständug zum Boot fahren. Mal sehen was da so rauskommt.

Norbert

chrhartz

Offizier

Beiträge: 309

Wohnort: München

Bootstyp: Neptun 20

Heimathafen: Bernau, Chiemsee

  • Nachricht senden

103

Donnerstag, 13. September 2018, 10:10

Hallo Norbert,

hat denn der Bosch BNO055 nicht alles bereits eingebaut? Die werben eigentlich mit "absolute orientation".

Adafruit schreibt folgendes zum BNO055:

If you've ever ordered and wire up a 9-DOF sensor, chances are you've also realized the
challenge of turning the sensor data from an accelerometer, gyroscope and magnetometer into actual
"3D space orientation"! Orientation is a hard problem to solve. The sensor fusion algorithms (the secret
sauce that blends accelerometer, magnetometer and gyroscope data into stable three-axis orientation
output) can be mind-numbingly difficult to get right and implement on low cost real time systems.

Ist der Sensor nicht geeignet für die Anwendung im Pinnenpilot oder warum verwendest Du den nicht?
Mit 9 EUR bei Mouser ist der doch nicht zu teuer?

Viele Grüße,
Christian
Neptun 20, Segelnummer 950, Honda 5BFU, Liegeplatz Bernau/Chiemsee

norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

104

Donnerstag, 13. September 2018, 13:45

@chrhartz:

Ich hatte mir ursprünglich eine BNO055 bestellen wollen, habe mich aber bei der Bestellung vertan, da dort auch was von BNO055 drin stand. Es lag also nicht am Preis. Es war eher ein Versehen.

So wie ich das jetzt verstanden habe, gibt es generell auch bei AHRS-Sensoren mit Fusion eine Drift, die sich ohne weitere Maßnahmen nicht beheben lassen. Diese Drift mit 1°/min ist aber wesentlich geringer als bei einfachen IMUs, die schon bei wenigen heftigen Bewegungen die Orientierung verlieren können. Das interne Magnetometer des AHRS referenziert die Winkeldaten Heading, Roll und Pitch auf das Erdmagnetfeld und richtet das Koordinatensystem nach Nord aus. Diese Ausrichtung wird als Initialisierung bezeichnet und kann über das Magnetometer oder ein externes GPS-Signal erfolgen. Selbst Profi-AHRS mit Laserinterferometer für Flugzeuge haben eine Drift von 0,1°/min und müssen gegelmäßig korrigiert werden.

Man kommt also nicht darum herum diesen Fehler in regelmäßigen Abständen zu korrigieren. Wenn ich bei einer Drift von 3°/min einen Heading-Fehler kleiner 1° haben möchte, so muss ich mindesten alle 20s eine Korrektur durchführen. Das scheint soweit ganz normal zu sein für solche günstigen AHRS. Die Korrektur könnte man natürlich gleitend durchführen, wenn kontinuierlich GPS-Daten zur Verfügung stehen. Genau das machen Assisted GPS- AHRS.

Gut, dass ich mir schon vorsorglich ein GPS-Modul besort habe.

Norbert

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »norbert-walter« (13. September 2018, 22:33)


Beiträge: 5

Wohnort: Seedorf

Schiffsname: Felix

Bootstyp: D35cws

Heimathafen: Rostock

  • Nachricht senden

105

Donnerstag, 13. September 2018, 21:05

Hallo,

ich verfolge mit Interesse diese Diskussion um einen DIY-Autopiloten, da ich seit zwei Jahren selber einen AP-Controller für meine Radsteuerung entwerfe. Das ist für mich Hobby ("der Weg ist das Ziel"), ich darf nur nicht meine Stunden zusammenzählen, da hätte sich ein kommerzieller AP schon gerechnet. Trotzdem gebe ich mal meine Erfahrungen wieder:

1) Ich verwende den BNO055, anfangs im "Fusion-Mode" (NDOF), d. h. die Software fusioniert MAG, GYRO und ACC in drei Dimensionen und gibt den mgK (und weitere Werte) aus. Das funktioniert am Couchtisch im Wohnzimmer nach einigen Kalibrierbewegungen gemäß Datenblatt super (24 h ohne Drift, stabiler, reproduzierbarer mgK, Kalibrierstatus "3333" = 100% ) - auch bei den wildesten simulierten Roll-/Gier- und Stampfbewegungen! Mit einem Modellflugzeug oder einer Drohne kann man das machen - dafür eignet sich der Sensor wohl recht gut.

2) Ab auf's Boot damit - und die Probleme begannen. Ursache (zumindest meine Beobachtung/Theorie): zum Kalibrieren muss der Sensor mit dem Schiff fest verbunden sein, da ich ja das vom Schiff ausgehende Störmagnetfeld kompensieren möchte – das habe ich auch gemacht. Die Kalibirierbewegungen sind auf dem Couchtisch kein Problem - da war mein "Schiff" ja nur die Sensorplatine. Zusammen mit dem Boot ist das aber problematisch, da ich die Kalibrierbewegungen des Gesamtsystems (Boot+Senso) nicht in 3 Dimensionen ausführen konnte und ich im Prinzip nur zweidimensional kompensieren kann. Resultat war, dass die Kalibrierung sehr unstabil war (auch ein ständiges Zurückschreiben der Kalibrierparameter brachte keine Erfolg) und ich sporadische Sprünge im mgK (teilweise 40 °) hatte. Zumindest hat mein PID-Regler diese Sprünge korrekt verarbeitet und dann auch sehr konsequent den Kurs um 40° nachgeregelt ;-)

3) Also Abhilfe: ich betreibe den Sensor jetzt im non-Fusion-mode und habe die Fusions-Mathematik selbst implementiert. Hilfreich war für mich die Anleitung: https://www.instructables.com/id/Acceler…-Gyro-Tutorial/ .

4) Im Prinzip erhält man eine IMU, die ACC+GYRO fusioniert und für die drei Achsen (XYZ) die Drehraten ausgibt. Diese Drehraten werden auf die Horizontebene bezogen, der horizontale Drehwinkel wird dann aufintegriert und man erhält einen Drehwinkel w, der (noch) keinen Bezug zur Realität hat.

5) Um einen mgK zu bestimmen werden dann die MAG-Werte des Sensors verwendet (dreidimensional!). Sehr wichtig ist eine „Offset-Korrektur“ für jede Achse (dafür gibt es tools wie „Magneto“, „MagMaster“ und „MagViewer“, siehe https://www.instructables.com/id/Easy-ha…er-calibration/), ansonsten kommt bei der Berechung des Winkels nur falsche Werte heraus. Weiterhin ist eine Kompensation des „Tilt-Fehlers“ notwendig, der immer dann prinzipbedingt auftritt, wenn der Sensor aus der Horizontalebene herausgedreht wird (d. h. immer dann wenn das Boot kränkt – es treten ohne tilt-Kompensation Fehler von 30° und mehr auf).

...wird fortgesetzt...

Beiträge: 5

Wohnort: Seedorf

Schiffsname: Felix

Bootstyp: D35cws

Heimathafen: Rostock

  • Nachricht senden

106

Donnerstag, 13. September 2018, 21:08

...Teil 2...

6) Dieser „Roh-mgK“ ist stark verrauscht, danach kann man nicht steuern. Viel besser ist unser Drehwinkel (siehe Punkt 4), der leider driftet. Es gilt nun, diese beiden Werte zu fusionieren. Man liest viel über sog. „Kalman“-Filter, welche sicher die (mathematisch) optimale Variante darstellen. So weit bin ich noch nicht, ich habe es mit einfachen „Komplementärfiltern“ probiert, die im Prinzip nichts anderes darstellen als zwei Signale („Roh-mgK“ und IMU-Drehwinkel) in einem bestimmten Verhältnis zu mischen. Es findet somit eine kontinuierliche Nachführung („Stützung“) statt und die Drift ist quasi ausgeschaltet. Die Praxis zeigt (nach zahlreichen Versuchen): es funktioniert! Wenn man auf die Magnetwerte fusioniert benötigt man kein GPS!

7) Nebeneffekt: wenn man die Mathematik implementiert hat, dann kann man auch den Windwinkel oder den GPS-Kurs zur IMU mischen und erhält sehr stabile und schnell reagierende Werte für AWA oder COG. Es hängt vom Mischungsverhältnis ab, die Gyro-Werte haben einen Anteil von typ. > 97 % und sorgen für eine sehr schnelle Reaktion, mgk, COG oder AWA werden nur zu < 3 % zugemischt und haben nur Stützfunktion… Am Wind regelt der AP schneller und sauberer als ich…

8) Nun zu meiner Implementation. Ich verwende einen Arduino Due (wegen Rechenpower, Speicher und vor allem 5 Hardware-UARTS). Er kann derzeit nach mgK, AWA und COG steuern (PWM-Motortreiber), hat zwei NMEA0183 Schnittstellen (für Anbindung an die alte Stowe-Windmessanlage und an den Plotter), einen abgesetzten BNO055 (im alten Fluxgate-Kompasssensor-Gehäuse über Serial angebunden) und am Steuerstand eine Bedieneinheit, die ich in das alte Autohelm ST4000-Gehäuse eingebaut habe. Eine SD-Karte loggt Werte mit (wichtig, um das Schiffsverhalten ermitteln zu können und die PID-Konstanten in einer Simulation zu ermitteln). NMEA2000 kann er nicht.

9) Mein Problem: das Projekt ist „sehr organisch gewachsen“ und von der Ausbildung her bin ich eher Energietechniker als Informatiker: so sieht mein source-code aus (C statt C++, viel zu wenig kommentiert/strukturiert, deutsche und englische Variablen- und Funktionsnamen). Hier muss ich diesen Winter sehr stark aufräumen, um das auch Dritten zugänglich machen zu können.

10 ) Die Frage: da in der mgK-Ermittlung überwiegend Mathematik steckt, diese aber ziemlich unabhängig von meiner Plattform ist, würde ich diesen Block vorab zu Verfügung stellen, falls jemand dort „aufräumen“ möchte. Wer Interesse hat bitte eine kurze PN an mich, dann würde ich mich in den nächsten Tagen mal hinsetzen und diesen Block heraustrennen.

Daniel

PS: ich habe auch im Auto getestet, dort sind aber die schlimmsten Bedingungen die man sich vorstellen kann. Wenn es da funktioniert, dann ist das Boot kein Problem mehr.

norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

107

Donnerstag, 13. September 2018, 21:43

@dguseedorf:

Hallo Daniel,

vielen Dank für Deine umfangreichen Ausführungen. Langsam dämmert es mir, worum es bei den ganzen AHRS geht. Momentan bin ich da noch ziemlich am Anfang und versuche die Theorie dahinter zu verstehen. Irgendwie hatte ich mir schon gedacht, dass das Ganze nicht so einfach sein wird. Eigentlich wollte ich mich um die Theorie drücken und den AHRS als perfektes System benutzen. Dem scheint aber nicht so zu sein. Ich habe im Internet eine ganz gute Beschreibung gefunden die die Thematik mit einfachen Worten beschreibt. Da versteht man erstmal worum es eigentlich geht und was die ursächlichen Probleme für die Fehler sind.

https://www.vectornav.com/support/library/imu-and-ins

Im Grunde genommen verhält sich mein AHRS erstmal ganz unauffällig, solange es in Ruhe ist. Da ist es sehr stabil und hält die Werte über mehrere Tage. Wie auch bei Dir beschrieben, kommen die Fehler mit Zunahme der Bewegungen. In meinem ersten Diagramm sieht man einen langsamen linear ansteigenden Fehler. Da bin ich mit Motor gefahren und mit achterlichem Wind gesegelt ohne merkliche Welle. Ab der zweiten Hälfte war ich nur beim Segeln. Diesmal allerdings mit achterlich quer einfallender Welle und ständigen Roll- und Gierbewegungen. Ab da war der Fehler dann nicht mehr linear und nahm negative und positive Wete an. Zum Schluss bin ich dann wieder motort und der Fehler ist nahezu konstant geblieben. Das kann man auch gut im Geschwindigkeitsdiagramm sehen. Die Bereiche mit nahezu konstanter Geschwindigkeit sind die Mortorfahrten. Alles in Allem habe ich jetzt eine Menge dazugelernt!

Vergleicht man die Fehler mit den Ausführungen im oberen Script, so macht der AHRS schon seinen Dienst, jedoch mit den Fehlern die man erwarten würde. Das Problem bei mir ist allerdings auch die Kalibrierung gewesen, da der Sensor ja ständig die Bewegungen des Bootes in der Kalibrierphase mitmacht und nicht so gut kompensieren kann. Erfolgt die Kalibrierung in absoluter Ruhe, so ist das Ergebnis wesentlich besser.

Die Frage ist ja am Ende auch, was man für Genauigkeiten benötigt, um eine Kurs zu halten. Selbst mit gut ausgeführter Fusion wird es am Ende zu einem Fehler kommen der sich mit der Zeit aufsummiert. Um eine Korrektur wirst Du da auch nicht herumkommen. Der lienar ansteigende Fehler bei mir ist ja nichts anderes als ein Kalibrierfehler. Man wird es bestimmt besser hinbekommen, wenn die Kalibrierung genauer erfolgt. Die Frage ist nur wie man das vernüftig macht. Ich will ja nicht mein Boot in allen Achsen drehen müssen ;) .

Das Thema ist aber sehr spannend. Das hätte ich gar nicht vermutet.

Norbert

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »norbert-walter« (14. September 2018, 13:53)


norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

108

Freitag, 14. September 2018, 13:47

@all:

So, ich bin jetzt einen Schritt weiter. Ursprünglich hatte ich angenommen, dass das AHRS-Modul eine Kalibrierung beim Start selbst ausführt, was sich eigentlich nur darauf beschränkt, dass das umgebenede Magnetfeld gemessen wird. Eine richtige Kalibrierung findet nicht statt. Es werden nur die Werks-Kalibrierdaten geladen. Die eigentliche Kalibrierung muss man noch selbst durch geeignete Bewegungs- und Orientierungsmuster getrennt für Gyro, Beschleunigung und Magnetometer durchführen. Da mein AHRS zusammen auf einem Board mit dem ESP8266 verbaut ist und ich metallische Steckkontakte in unmittelbarer Nähe verwende, ist mit einigen Beeinflussungen zu rechnen. Eine Endkalibrierung in der Zielhardware ist daher immer notwendig, die ich aus Unwissenheit leider nicht durchgeführt habe. Daher ergeben sich letztendlich die großen Abweichungen. Genau genommen muss das Magnetometer im Boot genau in der endgültigen Einbausituation kalibriert werden, da es zur Korrektur der Beschleunigungssensoren und des Gyros verwendet wird.

Das würde ich dann als nächstes mal vornehmen. Dann sollte sich das Ergebnis wesentlich verbessern lassen.

Norbert

109

Freitag, 14. September 2018, 14:23

X Achse ist in Sekunden. Drift lässt sich aus der Formel ablesen, Sprünge habe ich keine und der Sensor war teils nicht voll kalibriert im Auto... man sieht aber wie es nicht Driftet wenn das Auto steht :D...

Im Compass Mode muss man etwas differenzieren weil am Ende wohl die Ablenkung durch Richtungsänderungen hinzu kommt. Aber wie gesagt noch keine richtige Kalibrierung!!!

Wie es aussieht mag der BNO055 aber keine Bewegung :D, mein Auto macht auf der Geraden auch mal -20° Roll, der Fehler Summiert sich hoch, steht man an der Ampel so ist man wieder bei 0°. Im Auto läuft der Sensor dazu richtig schlecht über das Boardnetz, zu viele Störungen auf der Versorgungsspannung. Dämpft man ihn mit mehr Masse und betreibt ihn an einem extra Akku funktioniert der Sensor wesentlich besser. Da ich noch 15m Kabel dazwischen habe tüftel ich gerade an einem Filter für die Versorgung das BNO, denn auch die Datenleitungen stören ihn (Gyro).

Mein Resümee fürs erste... super saubere Versorgungsspannung, + dämpfen von "Motor Vibrationen" erzeugen wesentlich weniger bis 0 Drift ;). Der Senor sollte Gyro, Accl + Mag an der Versorgung kalibriert bekommen, ging bei mir am Auto Boardnetz und laufendem Motor nicht.

Ich hab absichtlich mal, Roll*10 genommen, damit man sieht was ich meine. Das ist schon so ein Indikator dafür das was nicht passt...
»the_muck« hat folgende Dateien angehängt:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »the_muck« (14. September 2018, 16:40)


norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

110

Freitag, 14. September 2018, 16:32

@the_muck:

Sieht ungefähr genau so aus wie bei mir und liegt im NDOF-Mode mit 3,75°/min im selben Range. Hätte da jetzt auch nichts anderes erwartet. Daher geht es primär um eine korrekte Kalibrierung und Korrektur der Fehler. Dann wird das Ergebnis besser werden.

Was ist bei Dir der Kompass-Mode? Was wird da genau gemacht?

Kannst Du noch Geschwindigkeitsdaten dazuplotten?

Norbert

111

Freitag, 14. September 2018, 16:43

@norbert-walter:

Geschwindigkeit :O , der Fuchs der die App Programmiert hat zeichnete die bis Dato nicht mit auf :D... Aber ich hab mal ernsthaft mit ihm gesprochen :D. Beim Letzten Plott sieht man das der Drift wesentlich besser geworden ist. Mich wunderte das, denn beim Testaufbau (Steckbrett) hatte ich nicht diesen Drift im Auto, auf der jetzt gelöteten kleinen Platine aber schon. Zuvor habe ich mir auch nicht alle drei Status Meldung separat anzeigen lassen, und auch nur Kalibriert wenn der Motor aus war. Jetzt mit externem Akku geht das auch bei Laufendem... das ist also alles wirklich tricky :D. Nicht nur der Code sondern das Drum herum ebenso...

http://ae-bst.resource.bosch.com/media/_…55_DS000_14.pdf
»the_muck« hat folgende Datei angehängt:
  • Unbenannt.PNG (433,14 kB - 7 mal heruntergeladen - zuletzt: 20. September 2018, 06:02)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »the_muck« (14. September 2018, 16:55)


norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

112

Freitag, 14. September 2018, 18:39

@the_muck:

Ok, Compass-Mode heisst nur Bescheunigungs- und Magnetometerdaten werden fusioniert mit langsamer Datenausgabe 20Hz. Warum das jetzt so verschidene Ergebnisse bringt ist mir noch unklar. Eigentlich dürften sie nicht wesentlich anders sein. Bei Deinen Autofahrten bist Du überwiegend in der Horizontalen geblieben und hast nur Richtungsänderungen durchgeführt (siehe Roll). Bei mir war das schon etwas anders durch die achterlich laufende Welle. Ab diesem Zeitpunkt sind die Fehler deutlich größer.

Ich muss mein Teil auch mal neu kalibrieren. Dazu muss ich mir aber noch eine Akku-Stromversorgung dazubauen. Die Tests im Auto sind schon sehr hilfreich. So können wir auch im Winter weitermachen.

@txg:

Ist halt doch nicht so einfach nur mal ein paar zugekaufte Module zu verdrahten und schon gehts. ;)

Norbert

113

Freitag, 14. September 2018, 20:23

Ich hab den BNO mal öfter Kalibriert... komisch ist wie unterschiedliche die Offsets bei acc und gyro sind.
»the_muck« hat folgende Datei angehängt:
  • Unbenannt.PNG (44,77 kB - 11 mal heruntergeladen - zuletzt: 20. September 2018, 10:11)

norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

114

Freitag, 14. September 2018, 23:23

@the_muck:

Ich habe hier mal eine sehr ausführliche Beschreibung gefunden wie AHRS für industrielle Anwendungen kalibriert werden. Die ganze Prozedur ist sehr aufwendig und zeitraubend. Das Ergebnis lässt sich aber sehen. Die kalibrieren nach aller Kunst Automotive AHRS und erzielen sehr gute Ergebnisse damit und erreichen dann Industriequalität.

https://www.vectornav.com/support/library/calibration

Dein Magnetometer sieht ganz ok aus, obwohl eine Beeinflussung vorliegt. Das Gyro ist auch ok. Nur der Beschleunigungssensor ist sehr verschieden. Das Teil ist aber auch nicht ganz unwichtig für die Fusion. Ich würde mal den Mittelwert und das Sigma für die Datenreihen dazulegen. Wie hast Du den Beschleunigungssensor kalibriert? Normaler Weise legt man ihn auf die Hauptachsen und das Ganze noch einmal in entgegengesetzte Richtung. Ich bin mir nicht ganz sicher, wie die internen Kalibrierroutinen das umsetzen und wie genau die Bewegungsabfolge aussehen muss. Da schweigt sich leider das Datenblatt bei meinem Sensor aus bzw. es ist nur sehr dürftig beschrieben. Eigentlich müsste die Werkaskalibrierung für das Gyro und den Beschleunigungssensor ausreichen, da sie durch den eigenen Aufbau nicht beeinflusst werden. Im Grunde genommen muss nur das Magnetometer in der endgültigen Applikation kalibriert werden und ggf. von Zeit zu Zeit erneuert werden.

Stell noch einmal auf Werkseinstellung zurück und lese die Kalibrierdaten aus. Dann kann man sie mit Deinen eigenen Kalibrierdaten ganz gut vergleichen. Ich glaube der Hersteller kann solche Kalibrierungen besser durchführen als man selbst. Die haben da besseres Equipment.

Norbert

115

Samstag, 15. September 2018, 10:48

Moin,
der BNO ist da wohl etwas tricky was das alles anbelangt... ich hab gestern Abend noch viel probiert... Ich arbeite mit der Adafruit Lib.

In allen Fusion Modes werden die selbst eingeschriebenen Offsets sofort "überschrieben", sie dienen wohl nur eine schnelleren Initialisierung . Das betrifft folgende Modes...

Quellcode

1
2
3
4
5
OPERATION_MODE_IMUPLUS                                  
OPERATION_MODE_COMPASS                                  
OPERATION_MODE_M4G                                      
OPERATION_MODE_NDOF_FMC_OFF                             
OPERATION_MODE_NDOF


aus dem BST_BNO055_DS000_14-1221282.pdf geht das auch hervor... man hat also nicht wirklich einen Einfluss beim BNO auf die "gute" Kalibrierung wenn sie der Sensor später wieder zerlegt. Ich befürchte Bosch hat den BNO nicht für solche Aufgaben ausgelegt, sondern wirklich mehr für Gamebads, 3D Brillen und so ein zeug. Ich versuche mich noch mal daran die Vibrationen zu dämpfen, befürchte aber das man die Fusion extern machen muss...

https://github.com/kriswiner/BNO055
»the_muck« hat folgende Datei angehängt:
  • Unbenannt.PNG (162,25 kB - 6 mal heruntergeladen - zuletzt: 20. September 2018, 10:14)

Beiträge: 5

Wohnort: Seedorf

Schiffsname: Felix

Bootstyp: D35cws

Heimathafen: Rostock

  • Nachricht senden

116

Samstag, 15. September 2018, 19:19

Hallo,

Tests im Auto sind schon sehr anspruchsvoll, da habe ich meinen AHRS (im Fusion-Mode) nicht zum Laufen bekommen. Das Auto erzeugt ein Störmagnetfeld, welches im Vergleich zum Erdmagnetfeld recht groß ist. Versuch mal einen klassischen Kompass im Auto zu benutzen, bei mir hat dieser immer konstant in eine Richtung gezeigt, egal in welche Himmelsrichtung mein Auto gefahren ist. Die Werte für den magnetischen "0"-Offset waren immer größer als die Änderungen des Erdmagnetfeldes. Zudem ändert sich das "Auto"-Magnetfeld immer mal wieder (und ich hatte schon drauf geachtet dass die Sitzheizung ausgeschaltet ist war). Deshalb habe ich meine Tests dann auch teilweise zu Fuß/mit Fahrrad gemacht - da ich immer mit PowerBank getestet hatte traten bei mir auch keine Probleme mit einer verschmutzen 12V-Spannung auf.


Deshalb: eine eigene Sensor-Fusion ist kein Hexenwerk, damit klapps jetzt auch im Auto. Man muss nur von Hand kalibrieren.

Daniel

117

Samstag, 15. September 2018, 20:39

Ich hab es nun mit dem klassischen Madgwick Filter am laufen, aber das war nicht die Idee mit dem BNO. Dann kann man gleich die MPU 9250 oder ähnlich nehmen... Schauen wir mal wie damit die Tests Aussehen.

Was ich meine... wenn dein Magnetfeld im Auto den Sensor so aussteigen lässt das der BNO mit Internem Algorithmus nicht klar kommt, der Sensor aber mit eigenem Algorithmus läuft! Dann ist das Feld im Auto ja weniger das Problem als der Algorithmus von Bosch... Ich möchte das auch nicht bewerten denn es stellt sich die Frage ob Bosch die Anwendung so vorgesehen hat.

https://www.bosch-sensortec.com/bst/prod…products/bno055

Zitat

Applications

- Augmented reality

- Navigation

- Gaming

- Fitness and well-being

- Context awareness


Was auch immer die eben unter Navigation verstehen ;)...

Hier nun mal im ESP 32 gerechnet... BNO im NDof mode mit vorgeladenen werten...

Grüße Malte
»the_muck« hat folgende Datei angehängt:

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »the_muck« (16. September 2018, 19:59)


norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

118

Sonntag, 16. September 2018, 21:25

@the_muck

Die letzte Fahrt sieht schon wesentlich besser aus. Bist Du gar nicht mehr nach Hause gefahren? Es ging immer nur weg vom Ausgangspunkt. ;)

In meinem GY953 wird der MPU9250 in Kombination mit einem ST Mikrocontroller verwendet. Wenn man sich das Datenblatt zum MPU9250 dazu ansieht, sind die Werkskalibrierungen sehr bescheiden +/-3%. Wenn der Modulhersteller dann nicht nachkalibriert, siehts schlecht aus. Man sieht auch gut, dass der Gyro stark mit der Temperatur driftet. Der muss eigentlich sehr gut kalibriert sein, da er die Drehrate ausgibt mit der man die Winkel über Integration berechnen kann. Die Fusion über Drehrate und Magnetometer ergeben dann erst gute und stabile Richtungswerte.

Du hast dann also nicht die Fusion vom BNO benutzt sondern sie vom ESP32 über Madgwick extern berechnen lassen? Richtig?

Hier ist mal ein Beispiel wie man das Magnetometer MPU9250 richtig kalibriert. Die Ausgangswerte sehen nicht gut aus. Wenn die verwendet werden, dann wundert mich das nicht warum meine Werte so schlecht sind.

https://github.com/kriswiner/MPU6050/wik…ter-Calibration

Mein Modul unterstützt auch eine externe Kalibrierung. Ich werde die demnächst mal ausprobieren. Bin leider noch nicht dazu gekommen, da wir übers WE weg waren.

Norbert
»norbert-walter« hat folgende Dateien angehängt:
  • Gyro.png (59,2 kB - 11 mal heruntergeladen - zuletzt: 20. September 2018, 06:02)
  • Accelerometer.png (69,02 kB - 8 mal heruntergeladen - zuletzt: 20. September 2018, 06:02)
  • Magnetometer.png (16,3 kB - 8 mal heruntergeladen - zuletzt: 20. September 2018, 06:02)

119

Montag, 17. September 2018, 07:52

Du hast dann also nicht die Fusion vom BNO benutzt sondern sie vom ESP32 über Madgwick extern berechnen lassen? Richtig?


Genau so, und der Sensor war im NDof Mode -> Auto Kalibrierung mit vorgeladenen werten... Das Problem ist also auch nicht das Auto sondern die Fusion von Bosch :O

Ich hab hier noch einzelne MPU9250 aus meiner Quadrocopter zeit aber ich wollte mir dieses Fusion Gehampel samt Kalibrierung ja eigentlich sparen... .

Deswegen haben ich mir folgenden Sensor noch bestellt und jetzt auch am laufen... EM7180_SENtral_sensor_hub macht die Fusion samt Kalibrierung und dahinter steckt Kris Winer aus deinem Link ;)

https://www.tindie.com/products/onehorse…lution-mpu9250/

Zitat

The best part of having a motion co-processor is it relieves the host from having to manage the sensors and perform costly calibration and sensor fusion calculations. The EM7180 does this using the embedded PNI Corp's fusion filters on its ARC processor with FPU optimized for fast sensor fusion. Best of all, with this combination of motion sensors, the EM7180 delivers heading with two degree rms accuracy or better when the sensors are properly calibrated. Even projects that use pokey MCUs, like my beloved 8 MHz Arduino ProMini, can get accurate absolute heading, pitch and roll when using the Ultimate Sensor Fusion Solution!


Da steckt "etwas" mehr hinter als "nur" eine Fusion über Madgwick. In seinen Beispielen kann man sich auch die Ergebnisse von dem Madgwick Filter anschauen die die eigene MCU berechnet, da sind schon gravierende Unterschiede.

Ich muss aber den Aufbau im Auto noch anpassen damit ich den Sensor in der gleichen Umgebung testen kann :O.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »the_muck« (17. September 2018, 08:16)


norbert-walter

Proviantmeister

  • »norbert-walter« ist der Autor dieses Themas

Beiträge: 355

Wohnort: Düsseldorf

Schiffsname: Cumulus

Bootstyp: Dehlya 22

Heimathafen: Lemmer (NL)

  • Nachricht senden

120

Montag, 17. September 2018, 09:42

@the_muck:

Das Modul von Kris Winer war mir gar nicht ausfgefallen. Ich habe mir seine Kalibrierungen und technischen Ausführungen durchgelesen. Die sind sehr aufschlussreich. Wenn man sich die Ergebnisse mit Madgwick auschaut, sind die jetzt auch nicht sooo schlecht im Vergleich zu seinem Modul. Eigentlich wollte ich die Fusion auch nicht selbst machen. Aber irgendwie kommt man da jetzt nicht drum herum. Das Grudsätzliche Problem ist eher die Kalibrierung als die Fusion selbst. Ich glaube die machen die anderen Module auch nicht schlecht. Man muss es nur hinbekomemn sie nach allen Regeln der Kunst zu kalibrieren. Das ist das Geheimnis. Nur mal ein paar Bewegungen und Drehungen zu machen reicht nicht für eine saubere Kalibrierung. Profis benutzen dafür Maschinen, um die Bewegungen und Winkel fehlerfrei und korrekt umzusetzen.

So weit ich das gesehen habe kann ich mein Modul nachkalibrieren und dann die Kalibrierparameter dauerhalt speichern. Die sollen dann auch beim nächsten Start verwendet werden. Man kann aber jederzeit auf die Werkskalibrierung zurückgehen. Das würde ich erstmal testen und dann sehen wie sich das Modul verhält.

Norbert

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »norbert-walter« (17. September 2018, 13:53)


Counter:

Gezählt seit: 4. Februar 2014, 08:39, nur eingeloggte Mitglieder
 Zugriffe:   Hits heute: 54   Hits gestern: 2 554   Hits Tagesrekord: 5 297   Hits gesamt: 4 078 992   Hits pro Tag: 2 339,24 
 Seitenaufrufe:   Klicks heute: 460   Klicks gestern: 19 034   Klicks Tagesrekord: 154 353   Klicks gesamt: 33 150 450   Klicks pro Tag: 19 011,27 

Kontrollzentrum

Helvetia