GY-80 Modul (Kurs/Neigung)

Also ich habe jetzt mal folgende Versionen getestet: 0.7.7, 0.7.9, 0.8.0, 0.8.6, 0.8.8

Alle Versionen bis einschließlich 0.8.0 gehen auf Anhieb mit der Kurskorrektur :woohoo:
Bei den 8.6 und 8.8 tut sich nix. Habe auch gemerkt, dass das Anfahren in die entsprechenden Himmelsrichtungen (bei Kompasstest) bei den Versionen vor 0.8.0 wesentlich schneller geht :unsure:

So, nun seid ihr dran ;) Was kann das sein, oder muss ich noch irgendwas speziell einstellen bei den neuen Versionen?

Danke, Gruß
Stefan
 
Markus schrieb:
Habe jetzt im Keller auch keine Reaktion auf Richtungsänderungen bemerkt.
Ich werde mich morgen damit genauer befassen. :)

@markus
Danke und würdest du bitte auch mal nachsehen, warum er bei diesem Kompasstest in den Versionen vor 0.8 schneller dreht? Da geht es nämlich sehr flott, siehe hier :)

Gruß
Stefan
 
Zuletzt bearbeitet von einem Moderator:
Stefan schrieb:
Markus schrieb:
Habe jetzt im Keller auch keine Reaktion auf Richtungsänderungen bemerkt.
Ich werde mich morgen damit genauer befassen. :)

@markus
Danke und würdest du bitte auch mal nachsehen, warum er bei diesem Kompasstest in den Versionen vor 0.8 schneller dreht? Da geht es nämlich sehr flott, siehe hier :)

Gruß
Stefan
Diese Funktion hat er überarbeitet, nachdem mir ein Motortreiber mit ner kleinen Stichflamme hochgegangen ist.
Die Fahrmotoren beim Rotenbach ziehen ordentlich Strom. Wie im Video zu sehen wird bei einer Kurskorrektur mit voller Drehzahl Reagiert und wenn ein gegenläufiges Kommando kam, wurde mit voller Drehzahl gegen gesteuert. Das Ergebnis war das abbrennen vom Treiber.
Könnte sein das es jetzt zu "weich" läuft und noch mal optimiert werden muss.
 
Zuletzt bearbeitet von einem Moderator:
Klopf klopf :)

@Markus
Sorry, aber hast du schon was wegen dieser Kurskorrektur rausfinden können?
Ich blicke einfach bei dem Code noch nicht durch :-(

Gruß
Stefan
 
Stefan schrieb:
Klopf klopf :)

@Markus
Sorry, aber hast du schon was wegen dieser Kurskorrektur rausfinden können?
Ich blicke einfach bei dem Code noch nicht durch :-(

Gruß
Stefan
Auf den ersten Blick hatte ich nichts gefunden, werde mich dem Thema morgen ausführlicher widmen. :)

EDIT: Nicht so einfach, da werde ich noch das WE drüber sitzen.
 
Zuletzt bearbeitet von einem Moderator:
autega schrieb:
Hallo Markus und Stefan,
ich bin momentan ziemlich eingebunden und habe leider keine Zeit die 0.8.8 selber zu testen.
Ich habe einmal schnell drüber geschaut und eine kleine Korrektur eingepflegt.
Ich denke nun sollte die Kurskorrektur wieder funktionieren.
Probiert es doch einmal aus.
Die korrigierte Version ist im Anhang.

Update: Auch hier kann ich keine Anhänge anfügen :(
UPDATE2: Danke Markus. Läuft wieder.

Gruß Sven

Hallo Sven,
hätte hier gerne was anderes geschreiben, aber es geht leider nicht. Keine Reaktionen auf den Kompass :( Evtl. bekomme Markus ja ein anderes Ergebniss. Warten wir mal ab.

Gruß
Stefan

Update:
Habe gerade auch bemerkt, dass die Himmelsrichtungen bei dem Kompasstest nicht mehr stimmen. Sind um ca. 45Grad verschoben. Dachte eigentlich, dass das nur was mit dem Nano zu tun hat. Kann das wirklich sein, glaub eigentl. nicht das der Mega da was für kann :unsure:
 
Zuletzt bearbeitet von einem Moderator:
Stefan schrieb:
Update:
Habe gerade auch bemerkt, dass die Himmelsrichtungen bei dem Kompasstest nicht mehr stimmen. Sind um ca. 45Grad verschoben. Dachte eigentlich, dass das nur was mit dem Nano zu tun hat. Kann das wirklich sein, glaub eigentl. nicht das der Mega da was für kann :unsure:

Ach da fällt mir ein:

Hatte es mit der Kalibrierung nie so hinbekommen, das er mit Mähmotor gelaufen ist.

Gestern war ich mal mutig und habe mit LAUFENDEM und stehendem Messer sowie Fahrmotoren kalibriert. Das Ergebnis war super. Genialer Geradeauslauf auch am Hang :woohoo:

Das komische, nach einiger Zeit fing er dann wieder an zu spinnen. Da hat nix mehr geklappt. Hat zwar versucht eine Richtung zu halten, jedoch drehte er dann einfach irgend welche Kreise nach ein par Metern gerade ausfahrt. Habe es auch nicht wieder hinbekommen.

Hatte einer von euch das auch schon mal, dass es eine Zeit ging und dann alles durcheinander war?
Somit hat der Kompasstest mit Sven seiner Änderung Sache sicher nix zu tun.
 
Zuletzt bearbeitet von einem Moderator:
Hallo zusammen,

in Version 0.8.9 sollte der Fehler (Keine Kurskorrektur) behoben sein.

@Stefan: die Störung des Mähmotors kann man durch die Kalibrierung mit laufenden Motor zwar korrigieren (bitte nicht nachmachen - wikrlich nicht zu empfehlen!!), aber das funktioniert nur solange die Hallsensor-Regler für die Mähmotordrehzahl nicht aktiviert wird (Settings->Mow->Modulate is ON/OFF).

Je nach Drehzahl schwankt der Kurs dann sehr stark.

Ich denke das ist das Phänomen welches Du erlebt hast...

Abhilfe: Kompaß auf Fahnenstange (meiner sitzt wieder 0.5m von allen Motoren entfernt...)

Gruss,
Alexander
 
@Alexander
Werde die Woche den aktuellen Code mal versuchen.

Warscheinlich muss ich dann halt ganz auf den Kompass verzichten :( , weil es mit so einer Fahnenstange bei mir schlecht ist. Cutty soll auch unter Büschen umher wuseln.

Naja, evtl. fällt mir da ja noch eine Lösung ein.

Gruß
Stefan
 
Hello,

ich habe mir euren Code für das Sensormodule (Kompass, Acc, Gyro) durchgesehen,
da ich ziemlich Probleme hatte vernünftige Werte vom Kompass zu erhalten. Das
hat sich mittlerweile zum Glück erledigt, von eurem Code und Vorgehensweise habe
ich jedoch recht viel profitiert. Deswegen versuche ich Euch auch an meinen
Erkenntnissen teilzuhaben.

1. Schaut euch mal die SoftTimer Library an. Die ist wirklich gut geschrieben,
einfach zu handhaben und fehlerfrei. Die funktioniert so wie man sich das
vorstellen würde. Damit kann man Tasks, die in regelmäßigen Abständen ablaufen,
sehr schön modelieren. Der Sourcecode wird dadurch verständlicher, leichter
modifizierbar und übersichtlicher.

2. Meines Erachtens macht ihr die Abfrage vom Gyro falsch. Der Gyro mißt laufend
die Drehgeschwindigkeit um 3 Achsen. Will man nun wissen, wie weit sich ein
Körper gedreht hat, muss man die Messwerte summieren und mit dem Zeitintervall
multiplizieren. Soweit ist ja noch alles klar. Nur darf man natürlich keine
Messwerte überlesen, das Zeitintervall sollte möglichst klein sein, damit das
Messergebnis genau wird und man sollte immer einen Augenblick später die Daten
vom Gyro einlesen, wenn dieser neue Daten ermittelt hat. Keine einfache Aufgabe,
möchte man die Leseschleife selber timen. Aber es gibt einen Trick:

Man initialisiert den Gyro für 400Hz data output rate und er soll im Streaming
mode die Daten in den FIFO Buffer (32 Werte maximal) schreiben.

Fragt man nun den Gyro ca. alle 20ms ab, sind 7 bis 9 Werte im FIFO Buffer. Will
man die Werte auslesen, liest man zuerst das FIFO_SRC_REG, dort steht nämlich
wie viele Werte gerade im FIFO Buffer gespeichert sind und ob vielleicht ein
Überlauf passiert ist. Im nächsten Schritt liest man die n Werte aus dem FIFO
Buffer aus, und summiert sie.

Möchte man, so wie ich das hier mache, auf einen Rutsch bis zu 64 Bytes von der
I2C Schnittstelle einlesen, muss man die internen Buffer in der Arduino Library
Wire vergrößern (die alles andere als gut programmiert ist, das ist aber eine
andere Geschichte)...

hier ein Ausschnitt aus meiner Gyro Lese Routine:


Code:
struct {
      uint8_t out_x_l;
      uint8_t out_x_h;
      uint8_t out_y_l;
      uint8_t out_y_h;
      uint8_t out_z_l;
      uint8_t out_z_h;
   } gyroData[32];

   uint8_t fifoSrcReg = 0;
   read(FIFO_SRC_REG, &fifoSrcReg, sizeof(fifoSrcReg));         // read the FIFO_SRC_REG

   // FIFO_SRC_REG
   // 7: Watermark status. (0: FIFO filling is lower than WTM level; 1: FIFO filling is equal or higher than WTM level)
   // 6: Overrun bit status. (0: FIFO is not completely filled; 1:FIFO is completely filled)
   // 5: FIFO empty bit. (0: FIFO not empty; 1: FIFO empty)
   // 4..0: FIFO stored data level
   //Serial.print("FIFO_SRC_REG: "); Serial.println(fifoSrcReg, HEX);

   uint8_t countOfData = (fifoSrcReg & 0x1F) + 1;
   *pCountOfSamples = countOfData;
   if (bitRead(fifoSrcReg, 6)==1)
      printf_P(PSTR("FIFO overrun FIFO_SRC_REG= 0x%02xn"), fifoSrcReg);

   memset(gyroData, 0, sizeof(gyroData[0])*32);
   read(0xA8, (uint8_t *)gyroData, sizeof(gyroData[0])*countOfData);         // the first bit of the register address specifies we want automatical address increment

   gyroRaw.xAxis = gyroRaw.yAxis = gyroRaw.zAxis = 0;

   for (uint8_t i=0; i<countOfData; i++)
      {
      gyroRaw.xAxis += ((gyroData[i].out_x_h << 8) | gyroData[i].out_x_l) + offsetX;
      gyroRaw.yAxis += ((gyroData[i].out_y_h << 8) | gyroData[i].out_y_l) + offsetY;
      gyroRaw.zAxis += ((gyroData[i].out_z_h << 8) | gyroData[i].out_z_l) + offsetZ;
      }

   //printf("L3G4200D raw data: %5d %5d %5dn", gyroRaw.XAxis, gyroRaw.YAxis, gyroRaw.ZAxis);



Warum ist der Code mit dem Quaternionen von Madgwick auskommentiert? Funktioniert das doch nicht so gut?

lg
Hannes

p.s. ich verwende das GY80 Modul als Input für einen Autopiloten für Segelschiffe. Die 400 sm von Tonga nach Fiji hat er schon geschafft...
 
Hallo Hannes,

erstmal vielen Dank für Deinen Beitrag - großartig, dass Du den Kompaß verwenden und verbessern konntest!

zu 1: Timer Libraries sind bekannt - SoftTimer arbeitet wohl ohne HW-Interrupt, das sollte dann gehen - wenn diese aber mit einem HW-Interrupt arbeiten, ergeben sich im Zusammenhang mit dem Ardumower teilweise neue Probleme hiermit, da dieser derart viele Dinge innerhalb kürzester Zeit erledigen muss, dass man beim Einsatz von Timern plötzlich keine Echtzeiterfassung aller Sensoren mehr hinbekommt (er würde sich quasi nur noch in Timern aufhalten und externe Signal nicht mitbekommen - ein Timer-Interrupt sperrt meines Wissen weitere Interrupts). Dinge wie Millisekunden-genaue Reaktion auf externe Signale (Stichwort "R/C Empfänger") weisen dann deutlich "Jitter" auf... Alles nicht so einfach :)
Falls der Arduino aber nur wenige Aufgaben erledigen soll, sind Timer Libraries auf jeden Fall keine schlechte Idee.

zu 2: Die FIFO-Methode hatte ich schon auf meiner TODO-Liste, ist aber m.E. nicht unbedingt nötig. Die Frage ist ja, wie konfiguriert man den Gyro (100 Hz oder 400 Hz) und hält man dann diese Abfragefrequenz auch ein. Vermutl. kann man mit 400 Hz aber noch bessere Ergebnisse erzielen... (Android-Geräte arbeiten m.E. ebenfalls mit 100 Hz).

Der Code mit Quaternionen war für kurze Zeit im Einsatz - er hatte leider einige Probleme, die ich nicht lösen konnte:
- nicht die gewünschte Genauigkeit (
 
Hallo,

da mir der derzeitige Methode zur Kalibrierung nicht besonders gefällt, entwickle ich derzeit eine neue und einfachere Methode... Das Ergebnis sollte dann dasselbe sein, d.h. ein kalibrierter Kompaß - ohne externe Anwendung zur Kalibrierung.

Der neue Algorithmus versucht nicht mehr einen Ellipsoid in die Meßwerte zu legen (braucht sehr viel Rechenzeit und Programmcode), sondern das Minimum/Maximum aller Achsen zu ermitteln (sehr einfach aber genauso wirkungsvoll).

Hier ein kurzer Zwischenbericht der Entwicklung (links das Ergebnis der alten Kalibrierung mit externem Programm, rechts die Kalibrierung mit der neuen Min/Max-Methode - wie man sieht befinden sich alle kalibrierten Meßwerte wie gewünscht auf der Einheitskugel) ...

compass_minmax.jpg


Gruss,
Alexander
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/compass_minmax.jpg/
 
Zuletzt bearbeitet von einem Moderator:
Hallo aus Fiji,

die Methode besticht durch ihre Einfachheit und dem geringen Rechenaufwand.
Ich vermute aber, dass das nur dann funktioniert, wenn das Ellipsoid einer Kugel sehr ähnlich ist. Wie abgeplattet das Ellipsoid in der Realität ist, weiss ich nicht, aber es hat doch sehr entscheidenden Einfluss auf die Genauigkeit vom Kompass.
Du hast in deinem Posting so eine nette Grafik von den Messwerten. Kann man die auch mit den unkalibrierten Messwerten erzeugen, damit man einen Eindruck von der Verzerrung bekommt?

Ich habe das Problem bei meiner Anwendung (Autopilot für Segelyacht) so gelöst:
Die Kalibrierung wird nur einmal durchgeführt, bevor der Sensor eingebaut wird. Dafür gibt es einen eigenen Menüpunkt.
Der Mega schickt dann die Rohdaten (x,y,z) zu einem Java Programm, das das Ellipsoid berechnet und dann die Kalibrierungswerte zurück zum Mega schickt. Die Kalibrierungswerte werden im EEPROM gespeichert.
Der Rechenaufwand im Java Programm ist ziemlich egal. Statt Java kann man natürlich jede Programmiersprache seines geringsten Vertrauens wählen ;)
Nun sollte der Kompass rein prinzipiell genaue Werte liefern. Die Kalibrierung kann natürlich wieder zunichte gemacht werden, durch eine schlechte Wahl des Einbauortes. Ich weiss nicht, ob ihr die Kalibrierung im eingebauten Zustand (das wäre ideal) durchführt. Mit einem Rasenmäher wäre das noch vorstellbar, mit einer Yacht eine ziemliche Herausforderung...
Um die Fehler beim Einbauort rauszurechnen, fahren wir einen Vollkreis mit möglichst konstanter Geschwindigkeit. Daraus kann dann eine Deviationstabelle berechnet werden (die auch im EEPROM gespeichert wird).
Das hat bis jetzt recht gut funktioniert...

lg
Hannes
 
Hallo Hannes,

im Prinzip machen wir es ja derzeit so wie Du es beschreibst (Ellipsoid extern berechnen). Das Problem an der Sache ist, dass man in der Regel viel am Mäher bastelt (neue Orte für Kompaßmodul ausprobiert, neue Hardware einbaut etc.) und dann nicht jedes Mal eine aufwändige Kalibrierung durchführen möchte. Zumindest stelle ich mir es so vor, dass man auf dem Rasen kalibrieren kann, z.B. indem der Mäher im Kreis fährt.

Hier siehst Du wie stark die Kugel verzerrt und verschoben sein kann (unkalibrierte Meßwerte):
compass_ellipsoid.jpg


Das sollte auch mit der Min/Max-Methode gut lösbar sein. Habe inzwischen herausgefunden wie man es optimal machen kann:

1. Mittelwert über alle Meßwerte berechnen (= Punkt "Pavg")
2. Durchschnittliche Distanz von allen Meßwerten zu dem Punkt "Pavg" berechnen (= PavgDist)
3. Distanz von allen Meßwerten zu dem Punkt "Pavg" berechnen und alle Meßwerte herauswerfen, dessen Distanz größer als 1.5 mal PavgDist ist - Dadurch fallen Ausreißer heraus (in dem Beispiel unten sieht man z.B. einen Ausreißer oben rechts im Bild):
4. Min/Max über alle Achsen berechnen (damit werden dann die zukünftigen Meßwerte später skaliert und verschoben)
5. Varianz der kalibrierten Meßwerte berechnen (Fehler zur idealen Kugel)

Über die Formel zur Varianz/Standardabweichung über alle kalibrierten Meßwerte kann man übrings ermitteln, wie gut die Kalibrierung geworden ist, d.h. wie gut/schlecht die kalibrierten Meßwerte alle auf einer Kugel liegen - Wenn diese z.B. schlecht ausfällt, muss der Benutzer einfach nochmal kalibrieren.

Gruss,
Alexander

http://www.ardumower.de/media/kunena/attachments/905/compass_minmax.jpg
 
Hallo Alexander,

danke für die Grafik, da sieht man doch recht schön, dass es sich doch eindeutig um ein Ellipsoid handelt.

also ich fürchte ohne ein Drehen um alle Achsen wird man nicht auskommen. Sonst bekommt man ja nur ein ganz schmales Band von dem Ellipsoid, z.B. wenn man einen Kreis fährt nur aus der x/y Ebene. Daraus dann auf die z-Ebene zu schließen halte ich für gewagt.
Und leider braucht man ja die z-Achse für die Neigungskompensation.

Wenn das jedoch wirklich funktioniert, wäre der echte Vorteil, dass man zur Laufzeit kalibrieren kann.

Einen, eher aufwändigeren :), Algorithmus der zur Laufzeit kalibriert gibt es auf der Homepage von Freescale zum download. Der rechnet wie der Algo von Madgwick mit Quaternionen rum, ist also zumindest für mich eher schwer durchschaubar was da wirklich passiert. Der Algo setzt jedoch voraus, dass der Sensor laufend um alle Achse irgendwann gedreht wird, was bei einem Einsatz in einem Smartphone gegeben ist. Beim Einsatz auf einer Yacht finden Dreher um die x/y Achse hoffentlich eher selten statt, deswegen haben wir diesen Algo nicht verwendet.

kleiner Hinweis:
Nach dem rauswerfen der Ausreisser aus der Messreihe muss natürlich Pavg neu berechnet werden.

lg
Hannes
 
Hallo Hannes,

richtig - man muss um alle Achsen drehen, um den Ellipsoid wieder auf die Kugel zu bekommen. Daher muss der Mäher um alle Achsen gedreht werden:
http://www.ardumower.de/images/ardumower_compass_calibrate.png
Dann sollte auch das das Min/Max-Prinzip funktionieren.

Wenn man aber eine ebene Rasenfläche hat (ohne Gefälle) könnte man vielleicht mit einer x/y Kalibrierung auskommen (Mäher auf der Stelle drehen). Kommt wohl auf den Anwendungsfall an.

Zumindest sorgt die Min/Max-Methode dafür, dass man ohne externe Anwendung auskommt - das ist schon mal viel Wert...

Gruss,
Alexander
 
Habe nun viele Test am Roboter durchgeführt: leider funktioniert die Min/Max-Methode zur Kompaß-Kalibrierung dort nicht besonders präzise ...

Fazit: wir bleiben bei der Ellipsoid-Methode zur Kalibrierung und entwickle jetzt eine Android-App dafür ;-)

Hier ein erstes Bild des ersten Prototypen :) Ziel ist, dass man damit dann auf Knopfdrück mit der App kalibrieren kann.


android_magneto.jpg

Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/android_magneto.jpg/
 
Zuletzt bearbeitet von einem Moderator:
Oben