GY-80 Modul (Kurs/Neigung)

nero76

Moderator
GYRO 80 --->

Hallo zusammen,

ich habe gerade ein interessantes Papier gefunden ( Link ).

Dort wird grob skizziert, wie man cm-genaue Navigation (mit allen bereits jetzt im Ardumower eingesetzen Sensoren) erreichen kann:

1. Mit Hilfe von Beschleunigungssensor, Kompaß und Gyo wird die Neigung (Pitch/Roll) sowie der Drehwinkel (Yaw) "geschätzt". Dabei werden die teilweise fehlerhaften Werte zu einem genauen Wert "fusioniert" (nach "Mahoney et al und Madgwick"). Vom dem errechneten Endergebnis wird nur der Drehwinkel (Yaw) verwendet. Dieser weist nur einen Fehler von max. 0,02 Radiant auf (etwa 1 Grad). Hiermit hat man schon mal einen präzisen Kurs (Grad) ermittelt.

2. Die Position des GPS-Signal wird mit Hilfe eines "Erweiterten Kalman Filters" zu einer sich nur langsam/träge ändernden (aber genauen) Position ausgewertet. Hiermit hat man über einen längeren Zeitraum (z.B. 20-30 Sekunden) eine absolute Position ermittelt.

3. Mit Hilfe der Radencoder und des Drehwinkels (aus 1.) wird nun die kurzfristige Position bestimmt. Diese Position hat aber auf Dauer (z.B. nach 20-30 Sekunden) einen "x/y-Versatz" (Fehler) welcher nun durch die (in 2.) absolute (aber träge) GPS Position nach und nach korrigiert wird.

Fazit: es werden die Vor- und Nachteile aller Sensoren kombiniert, um eine exakte Positionbestimmung zu erreichen.

Ich denke das ist ein tolles Verfahren. Mit etwas Übung sollten wir das auch hinbekommen :)

Gruss,
Alexander

Nachtrag
Das Verfahren "Odometrie mit GPS Korrektur" muss man sich wohl etwa wie ein Gummiband vorstellen: auf der einen Seite des Gummibandes "zieht" die Odometrie (ist nicht so "kräftig") - auf der anderen Seite "zieht" das GPS (ist "kräftiger"). Lokale Änderungen sind von der Odometrie erlaubt, bei größeren Bewegungen gewinnt aber GPS... :)
 
GYRO 80 --->

Hallo zusammen,

ich habe gerade ein interessantes Papier gefunden ( Link ).

Dort wird grob skizziert, wie man cm-genaue Navigation (mit allen bereits jetzt im Ardumower eingesetzen Sensoren) erreichen kann:

1. Mit Hilfe von Beschleunigungssensor, Kompaß und Gyo wird die Neigung (Pitch/Roll) sowie der Drehwinkel (Yaw) "geschätzt". Dabei werden die teilweise fehlerhaften Werte zu einem genauen Wert "fusioniert" (nach "Mahoney et al und Madgwick"). Vom dem errechneten Endergebnis wird nur der Drehwinkel (Yaw) verwendet. Dieser weist nur einen Fehler von max. 0,02 Radiant auf (etwa 1 Grad). Hiermit hat man schon mal einen präzisen Kurs (Grad) ermittelt.

2. Die Position des GPS-Signal wird mit Hilfe eines "Erweiterten Kalman Filters" zu einer sich nur langsam/träge ändernden (aber genauen) Position ausgewertet. Hiermit hat man über einen längeren Zeitraum (z.B. 20-30 Sekunden) eine absolute Position ermittelt.

3. Mit Hilfe der Radencoder und des Drehwinkels (aus 1.) wird nun die kurzfristige Position bestimmt. Diese Position hat aber auf Dauer (z.B. nach 20-30 Sekunden) einen "x/y-Versatz" (Fehler) welcher nun durch die (in 2.) absolute (aber träge) GPS Position nach und nach korrigiert wird.

Fazit: es werden die Vor- und Nachteile aller Sensoren kombiniert, um eine exakte Positionbestimmung zu erreichen.

Ich denke das ist ein tolles Verfahren. Mit etwas Übung sollten wir das auch hinbekommen :)

Gruss,
Alexander

Nachtrag
Das Verfahren "Odometrie mit GPS Korrektur" muss man sich wohl etwa wie ein Gummiband vorstellen: auf der einen Seite des Gummibandes "zieht" die Odometrie (ist nicht so "kräftig") - auf der anderen Seite "zieht" das GPS (ist "kräftiger"). Lokale Änderungen sind von der Odometrie erlaubt, bei größeren Bewegungen gewinnt aber GPS... :)
 
Wenn sich das gut umsetzen lässt, wäre es der "Feuchte Traum" von so manchem Rasenroboter Besitzer.
Kaum Auszumalen wenn das gut funktioniert und so manchem teuren Markenteil die Show stiehlt. :)
 
naneona schrieb:
Wenn sich das gut umsetzen lässt, wäre es der "Feuchte Traum" von so manchem Rasenroboter Besitzer.
Kaum Auszumalen wenn das gut funktioniert und so manchem teuren Markenteil die Show stiehlt. :)

Das Zauberwort hierbei lautet " Sensor Fusion ". Beim Android ist das sehr schön umgesetzt worden (Gyro/Beschleunigungssensor u. Kompaß ergeben zusammen die präzise Drehbewegung und den aktuellen "Kurs").

Einzig bei der Bildverarbeitung steckt Android noch in den Kinderschuhen. Es gibt zwar Ansätze von "Dritten" mit OpenCV, aber ich sehe dort starke Defizite bei der Verarbeitungsgeschwindigkeit welche man für optische Odometrie wohl bräuchte. Zum Vergleich: die Odometrie einer optischen Maus arbeitet mit 2000 FPS (Bilder pro Sekunde). Mit Android-Kamera/OpenCV wird man vielleicht 5-10 Bilder pro Sekunde schaffen. Ob das ausreicht ist fraglich...
 
Zuletzt bearbeitet von einem Moderator:
autega schrieb:
...
Iir vorstellen das die gelieferten Daten gerade in Hinblick auf Fehlerkorrekturen sehr gut sind...

Nun, die Kompaßdaten sind gut - das Verfahren ist aber nichts neues (es werden Gyro, Beschl. und Kompaß-Rohdaten zu einem stabilen Kompaß "fusioniert"). Dasselbe Verfahren steckt (fast) so schon im Ardumower-Code.

Ob wir die Kompaßdaten des Android auslesen wollen oder selber berechnen sollte letzen Endes keine Rolle spielen (es wird beides gut gehen). Beim Android hat man das kleine Problem, die Daten "ohne Latenz" (also Verzögerung) auszulesen. Bluetooth etc. haben eine Latenz von 1-3 Sekunden, wäre also für schnelle Manöver nicht geeigent. Das Problem "Kompaß" ist aber wie gesagt schon gut lösbar (mit den jetztigen Ardumower-Sensoren).

Ein stabiler Kompaß allein reicht leider nicht für Navigation. Man muss zusätzlich noch wissen, wie weit (cm) man in eine Richtung gefahren ist. Und da fängt es an beim Android problematisch zu werden. Er hat (wie es scheint) leider keine guten Sensoren hierfür. Ich verwende derzeit einen optischen Maussensor (ADNS-2051), welcher gute Ergebnisse liefert. Der Sensor liefert mir die Entfernung welche der Roboter zurücklegt. Der Kompaß liefert mir den Winkel. Also weiß ich wo der Roboter fährt.

GPS dient dann nur noch zur langfristigen Korrektur.

Aufgrund der Probleme mit dem Android (Latenz, optischer Sensor) werde ich für meine ersten Tests daher erstmal ohne Android arbeiten. Wenn es etwas zu sehen gibt, mache ich ein Video :)
 
Zuletzt bearbeitet von einem Moderator:
Kurzer Zwischenbericht zur Navigation:

Der Kompaß (genauer: der mit Gyro und Beschleunigungssensor fusionierte Kompaß) funktioniert inzwischen sehr schnell, präzise und stabil. Ich musste den Kompaß höher setzen, da meine Motoren sonst stören (selbes Problem ergibt sich übrings mit normalen Kompaß/Android etc).

Bei der Fusion von Maussensor und Kompaß habe ich anscheinend noch ein kleines mathematisches Problem welches es noch zu lösen gilt.

Ich fahre immer die Induktionsschleife entlang (3 x 2 m) und zeichne die Position auf. Dabei ergibt sich ein starker Versatz. Das muss noch gelöst werden...

Btw, eine gute Lektüre zum diesem Thema findet man hier ( Link )

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

habe mich heute mal wieder etwas mit der Odometrie auseinandergesetzt. Die Hardware ist ja schon auf den Artikel-Seiten beschrieben worden - heute war die Software dran.

Zum Test lasse ich den Roboter immer auf seinem Schleifen-Parcour fahren:

hf39ff8c.jpg


Die errechneten Positions-Daten ( nach Odometrie-Formeln ) lasse ich per Bluetooth zum Rechner schicken und dort auf einer Karte eintragen. Das Ergebnis sieht schon mal nicht schlecht aus:

he42992c.jpg


Mit etwas Phantasie erkennt man den Parcours (gedreht) wieder.

Wenn man den Roboter aber ein zweites Mal die Schleife abfahren lässt, ist das Bild aber nicht deckungsgleich - Wie erwartet driftet der Drehwinkel mit der Zeit:

h0fd899f.jpg


Das Problem muss nun über ständige Kurs-Korrektur gelöst werden. Ansätze dazu stehen ja schon auf der Kompaß/Gyro-Seite (u.a. Fusion von Kompaß,Gyro+Beschl.Sensor ).

Also muss jetzt erstmal eine schnelle+präzise Kurs-Bestimmung her (wie in dem Link skizziert).

Gruss,
Alexander
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/hf39ff8c.jpg/
 
Zuletzt bearbeitet von einem Moderator:
Nachtrag: ich habe gerade den Algorithmus von "Mayhony et al" zum Laufen bekommen ("Quaternion implementation of the 'DCM filter'. Incorporates the magnetic distortion compensation algorithms from Sebastian Madgwick's filter"), welcher sehr gute Yaw,Pitch,Roll-Werte ohne Störung und Drift liefert.

Mit anderen Worten: unser GY-80 Modul liefert nun exakte Kompaß-Werte wie ein Android-Gerät.

Damit wird die Odometrie als nächstes ergänzt und dann sind wir nicht mehr weit entfernt von Mähen in Bahnen :) ...
 
autega schrieb:
Was du immer so findest.
Es hört sich auf jeden Fall großartig an, daß wir nun Zugriff auf exakte Kompaß Werte haben.
Damit sollten dann ja eigentlich reproduzierbare Ergebnisse möglich sein, oder?
Neigung beeinflußt den Kompaß nun nicht mehr, da der Algorithmus dies über den Beschleuinigungssensor korrigiert. Er korrigiert auch Meßfehler durch Vibrationen. Kurzfristige Kompaßstörungen beinflussen nun das Ergebnis auch nicht mehr mehr. Dennoch liefert der Kompaß auch bei kurzfristigen Störungen weiterhin Werte, weil der Algorithmus auch auf den Gyro zurückgreift. Alles in einem also ein stabiler und schneller Kompaß. So wie man es eigentlich erwartet.

autega schrieb:
Immer dieses mähen in Bahnen.....als wenn das so wichtig wäre. ;-)
Durch Odometrie korrigiert mit Kompaß sollte das Koordinatensystem des Mähers sich nicht mehr drehen. Es kann jetzt nur noch wandern ( also seinen Ursprung ändern ). Dies könnten wir dann über das GPS-Modul in den Griff bekommen.

Eine cm-genaues Positions-Erkennungssystem ist natürlich nicht nur für Mähen in Bahnen schön. Was man damit anstellt, bleibt jedem selber überlassen. Mähen in Bahnen könnte zeigen, dass Ardumower "intelligenter" ist als andere Mäher... :)
 
Zuletzt bearbeitet von einem Moderator:
Also ich finde es schon cool wenn er bahnen mähen könnte. Der Mäher würde extrem schneller fertig werden. Somit kürzere Ladezeiten und weniger Ansprüche an den Akku.
 
Hallo,

dann bräuchte ich ja gar nicht erst mein Kabel verbuddeln.

So schnell wie Alexander ist, wird das ja fast noch für die letzten Rasenschnitte dieses Jahr anwendbar sein :)

Gruß
Stefan
 
Ach so Alexander

Keine Ahnung ob es ein Ansatz ist, gegen verfälschte Messwerte des Kompasses:

Mir kommt da wieder meine Coptersteuerung (APM2.5+) in den Sinn. Das Kompassproblem gibt es dort ja auch sehr stark durch die vielen Kabel und Motoren.
Dagegen gibt es beim APM eine Softwarelösung:

Der Kompass wird einmal ohne laufende Motoren kalibriert, dann wird der Copter am Boden fixiert und es werden alle Drehzahlen durchgegangen. Dabei rechnet die Steuerung alle störenden Werte raus und vergleicht mit dem vorherigen Ergebnis ohne Störeinflüsse.

Die Sache funktioniert wohl nicht 100%ig, aber besser wie ohne das Softwareupdate.

Ob sich so etwas hier umsetzen lässt, kann ich nicht beurteilen. Nur mal so als Gedanke.

Gruß
Stefan
 
Stefan schrieb:
Hallo,

dann bräuchte ich ja gar nicht erst mein Kabel verbuddeln.

So schnell wie Alexander ist, wird das ja fast noch für die letzten Rasenschnitte dieses Jahr anwendbar sein :)

Geh' lieber mal davon aus, dass es bis zur nächsten Rasensaison dauert, bis das einigermaßen stabil läuft (Odometrie incl. GPS) :) Der Teufel steckt im Detail - Wir sind aber wohl auf einem guten Weg...
 
Zuletzt bearbeitet von einem Moderator:
Stefan schrieb:
...
Der Kompass wird einmal ohne laufende Motoren kalibriert, dann wird der Copter am Boden fixiert und es werden alle Drehzahlen durchgegangen. Dabei rechnet die Steuerung alle störenden Werte raus und vergleicht mit dem vorherigen Ergebnis ohne Störeinflüsse...

Ja, so eine Kompaßkalibrierung könnte man auch noch vornehmen (dadurch wären die Kompaßwerte etwas korrekter). Derzeit bin ich schon froh wenn der Kompaß in die richtige Richtung zeigt und das störungsfrei. Es gibt ja zig Arten von Störungen, Motoren sind nur eine davon. Teilweise heftiger sind Störungen durch leichtes Kippen des Kompaß, Vibrationen, Beschleunigung, Bremsen, und die Umgebung. Daher muss man mitteln - dadurch wird der Kompaß aber träge, und da fängt es an komplizierter zu werden. Aber das haben wir jetzt durch o.g. Algorithmus in den Griff bekommen denke ich.
 
Zuletzt bearbeitet von einem Moderator:
Frage zur Navigationsgeschichte:

Könnte man dann auch verschiedene Flächen speichern?
Wenn ja wäre echt genial, und wenn man sie dann noch mittels Handy und dieser App auswählen könnte...

Ich glaube die "professionellen" Firmen würden aufgeben und machen mit normalen Benzinrasenmähern weiter :)

Gruß
Stefan
 
Stefan schrieb:
Frage zur Navigationsgeschichte:

Könnte man dann auch verschiedene Flächen speichern?
Wenn ja wäre echt genial, und wenn man sie dann noch mittels Handy und dieser App auswählen könnte...

Wenn das Grundprinzip ("Positionserkennung") stabil läuft, sind der Ideen keine Grenzen gesetzt. Ich hoffe ja, dass sich hier noch der ein oder andere Informatik-Student findet, der Interesse hat, solche und andere weitergehende Dinge mitzuentwickeln. Es gibt hier so viele Themen für eine Diplomarbeit o.ä. - da müsste dieses Projekt doch eigentlich sehr reizvoll erscheinen...
 
Zuletzt bearbeitet von einem Moderator:
So wie es aussieht, muss der Code für das Positionserkennungssystem auch in einen neuen Arduino Nano wandern. Der Algorithmus benötigt Echzeiterfassung und Echtzeitverarbeitung der Daten im kH-Bereich und das schafft der Mega nicht wenn er nebenher noch alle anderen Sensoren des Roboters abfragen soll.
Auch ist es für's Prototyping einfacher. Das GPS-Modul könnte später evtl. ebenfalls an das "Ardumower Positioning System" angeschlossen werden. Denkbar ist auch dasss die Odometrie-Sensoren daran angeschlossen werden, der neue Nano also nur für die Positionserkennung da sein wird...

Falls jemand schon mal den reinen IMU-Algorithmus (also stabilen Kompaß) mit einem Nano ausprobieren möchte, ich habe den Code unter Downloads hochgeladen.

Der Code gibt fortlaufend "Yaw,Pitch,Roll" aus, d.h. Kurs und Neigung.

Visualisieren lassen kann man sich die Werte z.B. mit dem Programm " SerialChart ".

h180688e.jpg


Als nächstes kommt die Übermittlung der Werte (über I2C) zum Mega hinein...
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/h180688e.jpg/
 
Zuletzt bearbeitet von einem Moderator:
@Stefan: das mit der Kompaßkalibrierung war ein sehr guter Tipp.

Der Kompaß muss tatsächlich kalibriert werden, damit die Rohdaten stimmen. Das Problem: die Rohdaten der einzelnen Achsen (z.B. X, Y) sind unterschiedlich zueinander (in Ausschlag/Größe) und haben dazu auch noch einen Offset (Verschiebung vom Nullpunkt): http://www.ardumower.de/images/compass_calibration.jpg
Dadurch stimmen die berechnen Kompaßwerte nicht. Wenn man das wieder herausrechnet (durch eine einmalige Kalibrierung) sind die Kompaßwerte sehr genau :)

(Störungen hat man hierbei noch nicht berücksichtigt - ist aber auch denkbar wenn es notwendig wäre...)
 
Für alle interessierten habe ich gerade den optimierten Code für Kompaß/Neigungserkennung (für den weiteren Nano) online gestellt (Downloads->IMU). Der neue Nano fungiert nun als Lageerkennungsmodul (IMU) bzw. später dann wohl auch als Positionserkennungsmodul (GPS etc.). Der Code für den Mega wurde nun auch angepaßt.

Eine Anleitung zum Kalibrieren des Kompaß (über die Serielle Konsole) werde ich noch auf der Artikelseite ergänzen. Die Kalibrierungswerte findet man in der Datei "imucal.h". Die Kalibrierung muss einmalig für das (eigene) GY-80 Modul erfolgen.

Ich werde dazu auf der Artikelseite noch ein Bild malen.

Die Werte dann in "imucal.h" eintragen.
 
Oben