Archiv verlassen und diese Seite im Standarddesign anzeigen : Sensor Fusion von verschiedenen Winkelpositionsgeber
Hallo Zusammen,
ich habe derzeit das Problem, das ich verschiedene Winkelpositionen, welche ich durch verschiedene Sensoren bekomme,
versuche zu einer einheitlichen Ausrichtung zu bekommen. Ich denke mal, das Kalman hier das letztendliche Ziel ist,
muss aber vorher einige andere Probleme lösen (denke ich mal).
Folgendes Problem:
Ich habe derzeit einen digitalen Gyro (ADIS16265), einen analogen Gyro (ADXR620), einen Compass CMPS (mit LSM303 für Beschleunigungsdaten) und die Ausrichtung bedingt durch die Fahrzeugbewenkung (Impulse der Räder/Ketten).
Als erstes möchte ich den analogen Gyro mit dem Beschleunigungsdaten des LSM303 vereinigen, damit hier ein stablierer Wert rauskommen. Ich suche hier noch die Bedeutung der Accelerometerwerte des CMPS und deren Umrechnung für die Sensorfusion
mit dem analogen Gyro. Evtl. reicht hier auch ein komplimentär Filter.
http://robottini.altervista.org/kalman-filter-vs-complementary-filter
Danach sollen alle Messwerte (Winkelangaben) zu einer Vorhersage einer "wirklichen" Ausrichtung verwendet werden.
Hierfür musste ich doch folgende Vorbedingungen haben:
a) Alle Winkel in dem gleichen Wertebreich arbeiten (und auch Änderungen richtungsgleich sind)
Diesen teil habe ich schon, alle im Bereich von 2 PI und Änderungen sind richtungsgleich im Wert.
b) Alle Winkel müssten ungefähr den gleichen Wert haben.
Hier kommen die ersten Problem, da ich bei den Gyros noch einen Drift habe.
Auch ist der Startwinkel derzeit noch für alle Winkel nicht gleich.
Hat jemand eine Idee, wie die alle Winkel relativ gleich halte oder ist das garnicht notwendig ?
Gibt es gute Webseiten, welche die Fusionierung von mehreren Sensoren gut erklären (will mir evtl. einen befreundeten Mathematiker zur Seite holen).
Viele Grüße
R.
Che Guevara
16.11.2014, 16:34
Hi,
ich glaube, du hast den Sinn eines Kalman- / Komplementärfilters noch nicht verstanden ;)
b) Alle Winkel müssten ungefähr den gleichen Wert haben.
Hier kommen die ersten Problem, da ich bei den Gyros noch einen Drift habe.
Auch ist der Startwinkel derzeit noch für alle Winkel nicht gleich.
Eine Sensordatenfusion nutzt man doch, um solche Sachen wie zb. Drift auszugleichen. Jeder Sensor hat andere Eigenschaften bzw. Vor- und Nachteile, welche durch die Fusion kombiniert werden sollen (also natürlich nur die Vorteile ;) ).
Der Acc hat z.b. keinen Drift, dafür aber verrauschte Werte und man kann nicht zwischen Drehung & Bewegung unterschieden. Mit dem Gyro hat man sehr schnelle, "richtige" Signale mit Drift (bzw. bei Mems v.a. Quantisierungsfehler), welchen eben der absolute Bezug zum Umfeld fehlt.
Ein Komplementärfilter reicht vollkommen aus, wenn dieser richtig parametrisiert ist, weicht sein Ergebnis garnicht bis kaum vom Kalmanfilter ab (welcher immer als Wundermittel gehypt wird, was er aber nicht ist!).
Außerdem lässt sich der Komplementärfilter wesentlich schneller berechnen.
Gruß
Chris
super Link zum Komplementärfilter!
dazu 3 Fragen von mir (obwohl ich nicht der TO bin... ;) ):
1) // newAngle = angle measured with atan2 using the accelerometer
was bedeutet "measured with atan2 ...."? einfach atan2 auf die Beschleunigungswerte anwenden ??? das kann doch nicht sein ! Oder doch ?? Aber wie ??
2) // newRate = angle measured using the gyro
Gyro misst normalerweise nicht den Winkel, sondern die Rotationsgeschwindigkeit, und DIE wird als "rate" bezeichnet, sowei ich weiss.
Dann muss man doch sicherlich vorher aufinegrieren, oder? Oder wird nicht der Winkel, sondern die Rotationsgeschwindigkeit eingespeist?
3) wie schleust man jetzt noch einen zusätzlichen Kompass in die Komplementärfilter-Gleichung mit ein?
Che Guevara
16.11.2014, 18:34
Hi,
ja, mit dem atan2 kannst du Vorzeichenrichtig den Winkel (verrauscht) aus dem Acc ausrechnen.
Hier ist das ganze bildlich dargestellt: http://www.sensoren.info/Winkel-Beschleunigung.png
x_angleC = a* (x_angleC + newRate * dtC) + (1-a) * (newAngle);
Wenn du von dieser Formel sprichst: Da wird doch integriert.
Den Kompass fusioniert man in einem weiteren Filter mit dem GyroZ Wert, selbes Prinzip.
Gruß
Chris
Che Guevara
16.11.2014, 23:28
Hast du dir den Link mal genauer angesehen? Bei der Korrektur geht es nur um die Kleinwinkelnäherung, um sich den Sinus zu sparen. Ich hab das gepostet, um den Zusammenhang zwischen den trig. Funktionen und der Beschleunigung darzustellen, um klar zu machen, warum / wieso / dass der atan(2) für die Winkelberechnung geeignet ist.
Was hat deine Formel mit dem Thema zu tun?
Gruß
Chris
halt stopp - irgendwas stimmt nicht:
ein Accelerometer gibt eine geradlinige Beschleunigung an, keine Winkelbeschleunigung.
Wieso also atan?
Wieso Winkel ?
doppelt über die Zeit integriert ergibt sich hingegen:
Weg = 1/2 * Beschleunigung * dt² (Weg, nicht Winkel!)
Che Guevara
17.11.2014, 00:00
halt stopp - irgendwas stimmt nicht:
ein Accelerometer gibt eine geradlinige Beschleunigung an, keine Winkelbeschleunigung.
Wieso also atan?
Wieso Winkel ?
doppelt über die Zeit integriert ergibt sich hingegen:
Weg = 1/2 * Beschleunigung * dt² (Weg, nicht Winkel!)
Was hat das jetzt wieder mit dem Thema zu tun? Troll?
Ein Acc gibt Beschleunigungswerte aus, nicht mehr, nicht weniger (deswegen heißt es ja auch "Beschleunigungssensor").
Hallo Chris,
klar bin ich nicht der Profi in Sensor Fusion, sonst hätte ich ja keine Fragen ;-).
Evtl. habe ich hier Informations-Fusion und Sensorfusion ein wenig gemischt.
Ich dachte bis vor kurzem, das der Kalman-Filter ein statisches Verfahren ist,
welches verschiedene Sensorinformation zu einer gemeinsamen Information "verheiraten" kann.
Sicher würden Sensoren, welche mittles verschiedenen Verfahren arbeiten, das Ergebnis deutlich besser
im Ergebnis verbessern, jedoch sollten doch mehrere Informationen aus verschiedenen Quellen ein gleiches
tun.
Ich will übrigens auch den Komplementärfilters bei der direkten Messwertumwandlung verwenden, da hier sonst
mein Microcontroller dicke Backen bekommt.
Nebenbei versuchte ich derzeit die Beschleunigungswerte des CMPS10 (serial Interface) zu verstehen und habe hierbei
so meine Probleme. Auf dieser Platine hat mir jemand in einem anderen Thread mitgeteilt, soll es
sich um bei dem verwendeten Chip um einen ST LM303 handeln. Nur kann ich die Rohwerte,
welche die CMPS10 in seiner Schnittstelle noch nicht so richtig bewerten.
Im Netz konnte ich bis jetzt keine eindeutigen Links finden. Heute versuche ich den Chip erstmal neu zu kalibrieren,
soll ja immer helfen.
Viele Grüße
R.
Che Guevara
19.11.2014, 18:43
Hi,
mit solchen Filtern (egal ob Kalman oder Komplementär) kannst du nur "gleiche" Daten fusionieren, also z.b. nur Winkel mit Winkel, Temperatur mit Temperatur, Höhe mit Höhe, etc..
Allerdings lassen sich diese Informationen teilweise durch Differenzierung / Integration berechnen, wie z.b. der (driftende) Winkel aus der Winkelgeschwindigkeit (Gyro).
Also wenn die Werte deines Acc "unbrauchbar" aussehen, kannst du das nicht durch Kalibrierung ausgleichen. Lediglich wenn der Offset (oder die Maximalwerte) verschoben ist, bringt eine Kalibrierung was.
Gruß
Chris
Hallo Chris,
Ich dachte bis vor kurzem, das der Kalman-Filter ein statisches Verfahren ist,
welches verschiedene Sensorinformation zu einer gemeinsamen Information "verheiraten" kann.
Das war wohl schlecht ausgedrückt. Klar kann ich nur Äpfel mit Äpfel "addieren", im realen Leben gibt es
beim Mischen Gemüsesalat und in der Mathe nur "Blödsinn".
Ich habe hierbei mehrere Winkelinformation, welche ich von verschiedenen Sensoren bekomme.
Derzeit will ich halt mit den Beschleunigungsdaten des CMPS10 den errechneten Winkel des Gyro ADXR620 (analog) stabilisieren.
Hier mal ein Datenauszug eines erstellten Log. Das Board stand stabil ohne Bewegung.
accelerometer[0]
accelerometer[1]
accelerometer[2]
28670
16380
12355
8190
24572
4163
-8195
8188
-12221
8190
28668
-24509
12286
12284
28739
12286
-20484
20547
-12291
24572
-12222
8190
24572
24643
12286
-32772
12355
-2
-28676
4163
12286
24572
-16317
20478
28668
-16317
16382
16380
24643
16382
12284
-12221
12286
-28676
20547
28670
12284
-28605
4094
28668
-4030
-4099
28668
-12221
-8195
12284
-28605
4094
-24580
-28605
-2
24572
4163
8190
20476
67
-2
24572
-28605
16382
16380
-32701
-2
-16388
-28605
-32770
-24580
67
-2
24572
4164
16382
-28676
-16317
12286
4092
16451
-2
28668
16451
4094
12284
68
Ich habe schon einige Lösungen gesehen, wo der Mittelwert des letzten Messungen genommen wird.
Ich könnte, wenn überhaupt einen fliessenden Mittelwert berechnen, da ich sonst zu langsam wäre,
wenn ich erst 5 Messungen via seriell einlesen muss, um einen Wert zu bekommen.
Viele Grüße
R.
erklär doch mal bitte, wie du mit Accelerometerwerten Winkeldaten stabilisieren willst.
Natürlich nennt man ein Verfahren, das so etwas kann, "sensor fusion", und Kalman-Filter wären tatsächlich ein Verfahren dafür.
Und es soll ja tatsächlich Lösungen dazu geben, aber mir ist nicht klar, wie du die Verbindung zwischen geradliniger Beschleunigung (durch Gravitation oder Geschwindigkeitsänderung) und Dreh-Winkeln herstellen willst.
In dem Beispiel oben wird der atan angeführt, ich verstehe aber ehrlich nicht, was der damit zu tun haben soll.
Che Guevara
19.11.2014, 20:55
Hi,
könnte es sein, dass du die / den / das Endianness falsch interpretierst / programmierst? Sieht für mich ein bisschen danach aus.
Diese Werte sind definitiv von keinem funktionsfähigen Acc, der stabil auf dem Tisch liegt.
Gruß
Chris
Hallo,
@HaWe
Da dieser Sensor die Beschleunigung misst, kann man anhand der Beschleunigung innerhalb einer Zeiteinheit eine Wegänderung errechnen (1g = 9.81m/s).
Der Sensor gibt die Wegänderung für jede Achse aus. Mich interessiert nur die Änderung der "X Achse", je nach Betrachtung.
Schau hier mal nach: http://www.pololu.com/product/1250/resources
Dort ist ein Projektfile Namens : LSM303DLH-orangutan-example-code
hier ein Teilstück aus dem Quellcode:
// Returns a heading (in degrees) given an acceleration vector a due to gravity, a magnetic vector m, and a facing vector p.
int get_heading(const vector *a, const vector *m, const vector *p)
{
vector E;
vector N;
// cross magnetic vector (magnetic north + inclination) with "down" (acceleration vector) to produce "east"
vector_cross(m, a, &E);
vector_normalize(&E);
// cross "down" with "east" to produce "north" (parallel to the ground)
vector_cross(a, &E, &N);
vector_normalize(&N);
// compute heading
int heading = round(atan2(vector_dot(&E, p), vector_dot(&N, p)) * 180 / M_PI);
if (heading < 0)
heading += 360;
return heading;
}
Da der Kompass CMPS10 den LSM303 als Beschleunigungs und Magnetfeld Messung verwendet,
kannst Du sicher auch das hier gebrauchen, um die Sache besser zu Verstehen:
http://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf
@Chris
Endianness, das ist eine Möglichkeit, das prüfe ich gerade. Den diese Werte machen für mich keinen Sinn, aber der ausgegebene Kompasswert des CMPS ist korrekt.
Er muss also korrekt arbeiten, da der Drift korriegiert ist.
Gruss R.
- - - Aktualisiert - - -
Vielen Dank Chris für diesen Hinweis:
Das sieht jetzt besser aus.
-832
-224
17344
-656
-240
17472
-704
-256
17280
-720
-560
17072
-672
-560
17504
-688
-544
17440
-816
-576
17408
m_AtmegaStatus.accelerometer[0] =(int) (int)(m_RS232_Buffer[4] + (int) (m_RS232_Buffer[5] << 8)); // get the Acc X
m_AtmegaStatus.accelerometer[1] =(int) (int)(m_RS232_Buffer[6] + (int) (m_RS232_Buffer[7] << 8)); // get the Acc Y
m_AtmegaStatus.accelerometer[2] =(int) (int)(m_RS232_Buffer[8] + (int) (m_RS232_Buffer[9] << 8)); // get the Acc Z
So ist es richtig.
Gruss R.
das ist mir völlig klar!
eine Beschleunigung ist die Differenzierung der Geschwindigkeit nach der Zeit bzw. die Geschw. ist die Integration der Beschleunigung über die Zeit ( a = dv / dt oder v = da x dt)
die doppelte Integration der Beschleunigung über die Zeit ergibt den zurückgelegten Weg ( s = 1/2 da x dt²)
aber sie ergibt keinen Winkel!
die Integration oder Differenzierung ergibt immer Vektoren, die bezeichnen einen Wert (Skalar) und eine (geradlinige ) Richtung !
also wie willst du einen gedrehten Winkel und einen zurückgelgten Weg ( oder gerichtete Geschwindigkeit oder gerichtete Beschleunigung ) zueinander in Beziehung setzen?
sicherlich geht es irgendwie, wenn man die 3D-Matrix der acc-Werte irgendwie zueinander in Beziehung setzt und weiß, in welcher räumlichen Lage sich der Sensor im 3D Raum befindet, was man auf schrägem Untergrund oder - im Extremfall - fliegenden Objekten aber nie sicher wissen kann)
Im Übrigen müssen bei einem ruhenden horizontal waagerecht gelagerten acc-Sensor:
2 Werte Null sein (horizontal geradeaus und horizontal quer zur Orientierung)
1 Wert 1 g = 9,80665 m/s² betragen (senkrecht zur Lage, gerichtet auf den Erdmittelpunkt). (edit: sry, verschrieben)
Wo stehen diese Werte bei dir?
Che Guevara
19.11.2014, 23:42
Also ich versteh dein Problem nicht, du gibst dir doch schon selbst die Antwort:
Im Übrigen müssen bei einem ruhenden horizontal waagerecht gelagerten acc-Sensor:
2 Werte Null sein (horizontal geradeaus und horizontal quer zur Orientierung)
1 Wert 1 g = 9,80665 m/s² betragen (senkrecht zur Lage, gerichtet auf den Erdmittelpunkt). (edit: sry, verschrieben)
Daraus lässt sich der aktuelle Winkel berechnen (bzw. dessen Mittelwert, wenn der Acc in Bewegung ist oder Vibrationen nahe der Resonanz vorhanden sind) mit dem atan.
Gruß
Chris
NIEMALS lässt sich daraus so einfach der Winkel errechnen !!!
Oder beweise die mathematischen Zusammenhänge !!
(Winkel = gedreht um die senkrechte Raumachse = heading)
ich geb dir mal was zu lesen:
hier ist eine Publikation, die ich schon etliche Jahre kenne, und die Accelerometer und Gyros per Sensor Fusioning per Kalman Filter integriert. Da siehst du, um was es prinzipiell geht:
sie ist hier mal wieder zu groß (Mann, Moderatoren, ändert mal die Defaults !!!) , ich verlinke sie woanders, da musst du dich wschl nur registrieren um sie zu lesen...
http://www.mindstormsforum.de/viewtopic.php?f=78&t=8432
Che Guevara
20.11.2014, 00:03
Sorry, aber so etwas von sich zu geben, OBWOHL
- schon viele viele Leute das erfolgreich implementiert haben
- der Zusammenhang u.a. in dem Link, den ich schonmal gepostet hatte, dargestellt ist
zeugt nicht von viel Ahnung.
(Mann, Moderatoren (https://www.roboternetz.de/community/misc.php?do=vsamodstats), ändert mal die Defaults !!!)
Anscheinend solltest du mal an deinem Ton feilen, hab das schon in einem anderen Thread beobachtet, dass ein Forum wohl nicht unbedingt der beste Platz für dich ist.
bin daran gewöhnt, bin selber admin und Moderator. Außerdem geht dich das nichts an.
i.Ü. zeig einfach mal, wie der Zusammenhang zwischen Drehung um die senkrechte Achse und acc-Werten ist, und alles ist gut.
edit: dass es grundsätzlich iwie geht, bestreite ich nicht, aber wie und warum - das bleibt zu zeigen.
Che Guevara
20.11.2014, 00:15
Also wenn du um die AccZ-Achse (senkrecht) drehst, merkst du das in den Daten nicht, um das gehts hier aber nicht, sind Äpfel und Birnen.
es geht eben doch, unter bestimmten Bedingungen / Prämissen, lies den Artikel!!
und genau um das geht es auch beim Sensor fusioning bei dead reckoning = Koppel-Navigation !
Lies dich erstmal in die Thematik ein, bevor du andere Leute als Idioten und Trolls hinstellst!
Che Guevara
20.11.2014, 00:27
Als erstes möchte ich den analogen Gyro mit dem Beschleunigungsdaten des LSM303 vereinigen, damit hier ein stablierer Wert rauskommen. Ich suche (https://www.roboternetz.de/community/content/50-volltextsuche) hier noch die Bedeutung der Accelerometerwerte des CMPS und deren Umrechnung für die Sensorfusion
mit dem analogen Gyro. Evtl. reicht hier auch ein komplimentär Filter.
Das war / ist der Eingangspost dieses Threads --> ergo: Es geht um die Datenfusion von Gyro & Acc, sodass ein fusionierter Winkel rauskommt.
Ich hab mich lange genug eingelesen, hab selbst schon einige Datenfusionen erfolgreich programmiert!
Und NEIN, AccZ und GyroZ lassen sich nicht ohne weiteres fusionieren, nimm einen Acc, leg ihn auf den Tisch und dreh ihn um die Hochachse, da ändert sich GARNICHTS.
Ist mir jetzt aber auch egal, will darüber mit dir nicht mehr diskutieren.
dann lass es, keinem ist es verboten, dumm zu bleiben.
Die grundlegende Frage ist doch die nach der Art der Drehung, z.B.:
wenn ein Gyro sich um die senkrechte Achse dreht, wie bei einem fahrenden Roboter, wie willst du diese Drehungen mit einem Accelerometer filtern? Sicher nicht einfach per Accelerometer und atan, da sind wir uns ja jetzt einig.
Die gute Nachricht: Acc- und Gyro Fusion geht per Kalman-Filter für Navigation und Drehung aber doch, siehe Link - nur eben ganz anders!
(übrigens auch per Partikel-Filter / SMC Filter, davon abgesehen)
Es ist ein professionell eingesetztes System.
Aber es erfordert ungeheuer viel Programmier-Aufwand.
Und Odometriedaten als weiteren Input für den Kalman.
ps, edit,
eigtl sind es sogar 2 Kalmans in dem Link.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.