Kalman-Filter (Simulation)

[nero76]

Hallo,

Diese Seite sieht nach einer guten Einführung in das Thema Kalman-Filter aus. Zum Verständnis empfiehlt es sich, das ganze in einer Meßwert-Simulation (z.B. mit Hilfe von SciLab ) zu erproben. Im Anhang ist das auf der Beispiel gezeigte 1D-Kalman-Filter Beispiel für SciLab.

Ich habe das Kalman-Beispiel von der genannten Seite etwas ausgebaut (SciLab-Code im Anhang, SciLab ist übrings kostenlos) - nun kann man recht gut sehen wie er funktioniert.

Schwarze Kurve: die realen Werte (z.B. Kompaß-Kurs in Grad)
Rote Punkte: die Meßwerte
Blaue Kurve: die vom Kalman-Filter vorhergesagten Werte!

Eingabe für den Kalman-Filter:
1. die absoluten Positionen (z.B. Meßwerte vom Kompaß)
2. die Änderungen der Meßwerte (z.B. Meßwerte vom Kompaß oder vom Gyro)

Wie man sieht funktioniert die Vorhersage gar nicht schlecht. Es ist auch keine Zeitverögerung in der Schätzung (wie man es bei einer einfachen Mittelwertbildung erwarten würden).

Gruss,
Alexander

 

[nero76]

Hallo,

Diese Seite sieht nach einer guten Einführung in das Thema Kalman-Filter aus. Zum Verständnis empfiehlt es sich, das ganze in einer Meßwert-Simulation (z.B. mit Hilfe von SciLab ) zu erproben. Im Anhang ist das auf der Beispiel gezeigte 1D-Kalman-Filter Beispiel für SciLab.

Ich habe das Kalman-Beispiel von der genannten Seite etwas ausgebaut (SciLab-Code im Anhang, SciLab ist übrings kostenlos) - nun kann man recht gut sehen wie er funktioniert.

Schwarze Kurve: die realen Werte (z.B. Kompaß-Kurs in Grad)
Rote Punkte: die Meßwerte
Blaue Kurve: die vom Kalman-Filter vorhergesagten Werte!

Eingabe für den Kalman-Filter:
1. die absoluten Positionen (z.B. Meßwerte vom Kompaß)
2. die Änderungen der Meßwerte (z.B. Meßwerte vom Kompaß oder vom Gyro)

Wie man sieht funktioniert die Vorhersage gar nicht schlecht. Es ist auch keine Zeitverögerung in der Schätzung (wie man es bei einer einfachen Mittelwertbildung erwarten würden).

Gruss,
Alexander
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/kalman1d.png/

 

[nero76]

Erweiterter Kalman-Filter (EKF)

Hier ist ein weiteres Beispiel, was man so alles mit dem Kalman-Filter anstellen kann: Positionsschätzung

Eingabe für den EKF:
-GPS (max. Fehler 3,5m)
-Odometrie (mit starkem Schlupf: ideale (d.h. gemessene) Bahn ist ein Kreis, der Schlupf erzeugt aber die gezeigte gelbe reale Bahn!)
-Kompaß (max. Fehler 5 Grad)

Welchen maximalen Fehler würde man hier ohne Filter erwarten? Bestimmt keinen max. Fehler im Bereich < 1.2m - Das ist nämlich was der Filter in diesem Beispiel schafft...

Gelbe Kurve: gefahrene Bahn (schwarzes Kreuz ist Anfangspunkt)
Rote Kurve: vom Kalman-Filter geschätzte Bahn (weicht beim Algorithmus-Start erstmal ab, da sich der Filter "warmlaufen" muss)

Erster Simulationslauf...

...und noch ein Simulationslauf

SciLab-Code zur Simulation ist im Anhang. Die Theorie dahinter stammt von hier .

Gruss,
Alexander
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/kalman4.zip/

 

[markus-lbon-facebook]

(weicht beim Algorithmus-Start erstmal ab, da sich der Filter "warmlaufen" muss)

Deutlich zu sehen und sehr Interessant.
Die Genauigkeit ist Beachtlich und wenn es in der Praxis so umzusetzen ist, lässt sich bestimmt gut mit arbeiten.

 

[nero76]

Ja, die Ergebnisse sind in der Tat schon beeindruckend. Vermutlich lässt sich die Genauigkeit noch weiter erhöhen wenn weitere Sensoren in die Schätzung einfließen, z.B. Beschleunigungssensor und Gyro. Mal schauen was sich da noch machen lässt...

 

[nero76]

Interessant ist auch: man kann dem Filter sagen wie "Vertrauenswürdig"...

1. die einzelnen Meßwerte (SigmaL)
2. und das eigene Vorhersage-Modell (SigmaQ) sind

Wenn man z.B. dem Vorhersage-Modell weniger Vertrauenswürdikgeit gibt (SigmaQ vergrößert, und damit indirekt den Meßwerten mehr Vertrauenswürdigkeit gibt), reagiert die Vorhersage schneller auf die Meßwerte (z.B. GPS) und man kann damit den Fehler auf 0.7m bekommen:

Würde man SigmaQ jedoch noch weiter vergrößern (also dem Modell noch weniger/den Meßwerten noch mehr Vetrauenswürdigkeit geben), würde irgendwann der große Fehler der Meßwerte (starkes Meßrauschen) in das Vorhersage-Modell übertragen.
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/kalman3.png/

 

[rainer_r]

Wer sich grundsätzlich über das Thema "Kalman-Filter" informieren möchte - hier eine Linksammlung der
University of North Carolina at Chapel Hill : http://www.cs.unc.edu/~welch/kalman/

 

[nero76]

Hallo Rainer,

danke für die Link-Sammlung - da findet sicherlich jeder genug Stoff zum Lesen ;-)

Ich persönlich finde die reinen theoretischen Abhandlungen oftmals etwas zu nüchtern und brauche konkrete Beispiele welche ich sofort ausprobieren kann ("Learning by Playing"), um eine Theorie besser zu verstehen... Daher die von mir gezeigten Beispiele

UPDATE: Hier ist noch eine gutes Tutorial zum Thema (praxisnah):
http://cwrucutter.wordpress.com/2013/09/13/state-estimation-kalman-filter-tutorial-part-1/
Gruss,
Alexander

 

[nero76]

Ich habe dieses Tutorial auch mal durchgespielt - dort wird nur GPS (Messfrequenz 5 Hz) verwendet um den Kalman-Filter zu füttern. Es ist erstaunlich wie gut der Filter selbständig den Zustand des Systems "Roboter" abschätzen kann (x,y,Kurs,Geschwindigkeit,Drehgeschwindigkeit)...er erreicht dabei beachtliche 1.3m Fehler (GPS-Fehler wieder 3.5m).

Das Bild verdeutlicht dies sehr gut (rosa die GPS-Werte, gelb der echte Kurs, rot der geschätze)

Code ist im Anhang.
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/kalman4.png/

 

[rainer_r]

Hallo Alexander,

die Kalman Filterergebnisse sind wirklich sehr gut. Auch an anderen Stellen im Netz (Rover, Dronen, Copter etc.) werden für die GPS-Position und für die Objekt-Lage-Ermittlung aus einem Sensor-Board (IMU, 4-9 DoF /degrees of freedom) ein Kalman-Filter (meist EKF) eingesetzt.

Es wäre nun interessant für uns eine allg. verwendbare Filter-Funktion zu entwicklen die wir für die GPS-Daten aber auch für das GY-80 Sensor Board verwenden könnten. Soweit ich die Kalman Rekursion verstehe werden jedoch, um optimale Ergebnisse zu erzielen, für jede Messwertart eigene Filter-Parameter notwendig. Das sollte aber kein Problem sein.

Ich habe mir einmal diese Lib ( Kalman.h ) angesehen (im Anhang). Diese wird bei einer 6 DoF IMU verwendet und entspricht schon meinen Vorstellungen.

Attachment: https://forum.ardumower.de/data/media/kunena/attachments/930/IMU-incl-Kalman-filter.zip/

 

[nero76]

Hallo Rainer,

dieser Code ist auf jeden Fall hilfreich wenn es später an die Implementation in C geht.

Die Schwierigkeit beim Kalman-Filter ist ja meist...
- ein passendes Modell finden welches das System gut einschätzt
- die Modellparameter optimieren (Gewichtung von Modell und Messung)

Derzeit versuche ich das Kalman-Modell und deren Filter-Parameter (für die Positionsbestimmung) erstmal am Rechner zu optimieren. Wenn dann die Simulation gut funktioniert, werde ich als nächstes mit realen Daten arbeiten und das Modell damit nochmals optimieren. D.h. ich denke ich werde z.B. eine Schleife im Garten exakt so verlegen, dass mir dessen Koordinaten bekannt sind. Der Rest ist dann abfahren und sammeln der Daten (Kompaß, Odometrie, GPS, Beschleunigungssensor, Gyro) für die Simulation. Hat man einmal die Daten aus der Praxis gesammelt (Ist-Position und Meßdaten) kann jeder das Modell (Geschätzte Position anhand der Meßdaten) beliebig damit verbessern. Ich denke dies ist der schnellste Weg für beste Ergebnisse.

Dasselbe könnten wir auch für einen Kompaß/IMU-Filter machen (wäre hier aber wohl nicht notwendig, da man den Filter-Code direkt mit der realen Hardware, d.h. schnell am Rechner optimieren kann).

Hier ist ein Simulations-Beispiel, wo eine vorgegebene Schleife exakt abgefahren wird und dabei die Position über Kalman-Filter bestimmt wird...

Messfrequenz (5 Hz)
GPS Fehler: 4m
Kompaß Fehler: max. 5 Grad
Odometrie Fehler: max. 0,1m/sec (pro Messung)
Fehler Positionsschätzung: max. 0,5m

Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/kalman5_2014-01-23.zip/

 

[rainer_r]

Hallo Alexander,

betrachten wir einmal nur die 2D-Positionsbestimmung eines Objektes auf einer begrenzten Fläche. Kalman versucht die aktuelle Obj.-Position bei laufender Pos.-Änderung vorauszuberechnen und nimmt dann den nächsten "echten" Messwert zur Korrektur. Diese hochgerechnete Obj-Position kann durch weitere Messwerte (Kompaß, Odometrie, Beschleunigungssensor, Gyro) verbessert werden. Nach der Literatur wäre das dann ein mehrdimensionales Kalman-Filter.

Um die Sache zu Anfang einfacher zu gestalten, würde ich im ersten Schritt nur das GPS-Signal und dann (evt.) die Magnetometer-Werte zur Positionsbestimmung mit Kalman verwenden wollen um das dann erstmal in die Praxis, d.h. in den Mower, zu bringen.

Es ergeben sich derzeit noch folgende Gedanken, Fragen & Schwierigkeiten für die Umsetzung:
1. Mehrdim. Kalman-Filter - großes ? bei mir im Moment.
2. Um wieviel wird die geschätzte Position verbessert wenn weitere Sensoren mit eingerechnet werden?
3. Welche Wichtung der Korr.-Sensoren ist richtig?
4. Welche Sensoren (z.B. eines GY-80) verbessern die Position wirkungsvoll, welche nur minimal oder überhaupt nicht?

.

 

[nero76]

Hallo Rainer,

da das Thema für mich auch relativ neu ist, betrachte alle meine Antworten erstmal "ohne Gewähr" ...

Zunächst sollte man sich überlegen wie man das System (welches man schätzen möchte) am besten beschreibt, so dass man dieses zu einem Zeitpunkt (t) feshalten kann. Das nennt man dann Zustand (state).

Desweiteren braucht man eine gute Beschreibung wie sich der Zustand des Systems vom Zeitpunkt (t) zum nächsten Zeitpunkt (t+1) ändert.

Z.B. lässt sich der Zustand eines Roboters (für eine Positionsschätzung) beschreiben durch:

[Position x
Position y
Vorwärtskurs theta
Vorwärtsgeschwindigkeit v
Drehgeschwindigkeit omega]

Das ist also der Zustandsvektor (state). Die Zustandsänderung (Bewegung) des Roboters könnte man z.B. so beschreiben:

x = x + v * dt *cos(theta)
y = y + v * dt *sin(theta)
theta = theta + omega *dt
v = v
omega = omega

Soll heißen:
- die neue X-Position (x) ist die alte plus Vorwärtsgeschwindigkeit (v in Meter pro Sekunde) mal betrachtetes Zeitinterval (dt in Sekunden) mal Cosinus des aktuellen Kurses (theta)
- der neue Kurs (theta) ist der alte plus Drehgeschwindigkeit (omega in Grad pro Sekunde) mal betrachtetes Zeitintervall (dt in Sekunden)

An diesem System-Modell sieht man schon:
- Je besser das Modell, umso besser kann man den System-Zustand in der Zukunft (t+1) schätzen.
- Je mehr Messungen und je genauer diese sind, umso besser kann man den Zustand in der Zukunft (t+1) schätzen.

Der Rest ist jetzt eigentlich nur noch Messungen für beliebige Zustandsvariablen (x, y, theta etc.) durchführen, um den Kalman-Filter damit zu füttern. Details kann man z.B. hier nachlesen (insb. Teil 3): http://cwrucutter.wordpress.com/2013/09/13/state-estimation-kalman-filter-tutorial-part-1/
Kurz zusammengefaßt:
1. Zustandsvektor für das System aufstellen (state)
2. Zustandsänderung für Zustandsvektor (state) aufstellen (Zustandsänderungsfunktion)
3. Jakobi-Matrix der Zustandsänderungsfunktion ausrechnen (Fk)
4. Kovarianz-Matrix für Zustandsvektor aufstellen (Qk)

5. Für jede Messvariable (GPS: [x;y], Kompaß: [theta], etc.) Messung durchführen (z-Vektor aufstellen)
6. Für jede Messvariable h-Funktion aufstellen [h(state)], welche beschreibt wie man aus einem gegebenen Zustandsvektor die (für diesen Zustand erwarteten) Messwerte (z-Vektor) erhält
7. Für jede Messvariable Jakobi-Matrix der h-Funktion ausrechnen (Hk)
8. Für jede Messvariable Kovarianz-Matrix aufstellen (Rk)

Das meiste davon ist absolut harmlos - Die Schwierigkeit ist z.B. eher die Gewichtung (Kovarianz-Matrix). Da ist meist probieren angesagt...


Zu deinen Fragen:
Generell gilt, je mehr Sensoren (Messvariablen) umso besser, je mehr Messungen (je kleiner dt) umso besser. Leider kann ich keine konkreten Zahlen (welcher Sensor verbessert wie) nennen, da ich erstmal mit realen Meßwerten arbeiten möchte (siehe letzten Beitrag).

Insbesondere bei der GPS-Meß-Simulation habe ich da so meine Zweifel bei den simulierten Werten. Der Kalman-Filter erwartet normalverteilte Meßwerte - das mag bei GPS-Messungen im stationären Fall und über einen längeren Meß-Zeitraum noch hinkommen, aber trifft die Normalverteilung auch noch auf GPS-Messungen zu welche während einer Bewegung durchgeführt werden?

Wenn Du es nur auf simulierte Messungen beziehen möchtest, kannst Du es ja selber mit dem im letzten Beitrag angehängten Simulations-Code ausprobieren (und z.B. einfach die Messung eines Sensors auskommentieren).

Fall Du nur konkrete Ergebnisse (welcher Sensor verbessert wie) suchst (ebenfalls für eine Simulation), könnte dieses Papier aufschlußreich sein: http://hanspeterschaub.info/Papers/bugs.pdf (Ergebnisse stehen dort weiter hinten)

Gruss,
Alexander

 

[rainer_r]

Hallo Alexander,

ich versuche mich auch aus verschiedenen Quellen da etwas einzulesen um auf einem "etwas höheren Level" anzusetzen. Ob das gelingt werden ich noch sehen. Auch stelle ich bei dir einen etwas anderen, erweiterten Blickwinkel auf dieses Thema fest. Ich starte mit der Überlegung nur die Rückkehr des Rob zur Ladestation hinzu bekommen. Wobei der "letzte Meter" auch bei mir noch offen ist.

Würde folgende vereinfachte Überlegung weiterhelfen um von A nach B zu kommen:
Zunächst interessiert (mich) nur die möglichst genaue stationäre Position des Rob irgendwo auf der Rasenfläche (Da kann Kalman nicht helfen). Dann sollte der Rob von dieser Position zu einer End(Lade)-Pos.verfahren werden. Diese End-Pos. wird erreicht wenn nacheinander viele/mehrere Wegpunkte (WP) angefahren werden. Diese WP werden angenähert immer geradlinig angefahren.
WP sind hierbei eine quasi stätionäre GPS-Messung während der relativ langsamen Fahrt des Rob. Die verschiedenen Zustandsvektoren des Rob an einem Wegpunkt = neuer Standort wird durch GPS verifiziert.

Die Vektoren könnte man dann jeweils so beschreiben
Position x = Kalman, am WP über GPS
Position y = Kalman, am WP über GPS
Vorwärtskurs theta = Winkel zum nächsten WP + Gyro/Kompass Wert
Vorwärtsgeschwindigkeit v = bekannt
Drehgeschwindigkeit omega = Gyro/Kompass Wert

Nach einem Halt am neuen WP werden die Abweichungen zum definieren WP sichtbar. Diese sind innerhalb der GPS-Fehlmessung aber nicht erkennbar. Kalman korrigiert eigentlich nur den Kurswinkel des Rob. Wieviel WPs eingesetzt werden müssen um die Endpos. möglichst genau zu erreichen, ist nicht zuletzt eine Frage der sich summierenden Fehler.

Hinternisse sind erst einmal nicht berücksichtigt

Danke für die Links - diese werde ich mir einmal vornehmen.

 

[nero76]

Hallo Rainer,

wenn man die Vorwärtsgeschwindigkeit nicht mißt (und eine gleichförmige Geschwindigkeit angenommen wird, also z.B. v=Berghoch=Bergrunter=const), wird die aktuell geschätzte Entfernung zum WP evtl. etwas ungenau sein (nur über GPS), aber das sollte wohl in diesem Fall keine Rolle spielen...

Ich versuche allgemein die Position während der Fahrt zu schätzen und das möglichst genau. Damit kann man dann später beliebige Dinge anstellen (z.B. virtueller Karte eintragen wo schon gemährt wurde, auf Handy sehen, wo schon gemäht wurde bzw. wo der Roboter gerade ist etc.)

Gruss,
Alexander

 

[rainer_r]

Hallo Alexander,

ich greife nochmals diese Aussage von dir auf :

Insbesondere bei der GPS-Meß-Simulation habe ich da so meine Zweifel bei den simulierten Werten. Der Kalman-Filter erwartet normalverteilte Meßwerte - das mag bei GPS-Messungen im stationären Fall und über einen längeren Meß-Zeitraum noch hinkommen, aber trifft die Normalverteilung auch noch auf GPS-Messungen zu welche während einer Bewegung durchgeführt werden?

Ja richtig - ich überlege deshalb den Fahrbetrieb als einen "permanenten" quasi stationären Fall zu betrachten: da der Rob in 1 Sek. nicht mehr als 0,5-0,8 Meter Weg zurücklegt und der GPS Pos.-Fehler bei ca. 4 Meter liegt. Ich erhalte also min. 20 GPS Positiondaten bei fahrenden Rob innerhalb der GPS Fehlertoleranz. Diese 20 Messungen streuen (über die 3-4 Sek. immer stärker) in die Fahrtrichtung. Jede Kurs-Korrektur des Rob in dieser Zeit wird dann auf Grund der Kalman Schätzung erfolgen - welche den Fehler zum tatsächlichen WP verkleinert sollte.

 

[nero76]

Hallo Rainer,

ich habe da so meine Zweifel ob die Werte wirklich immer in die Fahrtrichtung streuen. Wenn ich mir die GPS-Daten (ohne Bewegung) angucke, stelle ich fest, dass diese m.E. aus zwei Komponenten bestehen:

- Rauschen
- Offset (Bias)

D.h. es gibt einen Bias, erzeugt durch die Atmosphäre, (welcher mal schneller und mal langsamer um den wahren Wert umherwandert), um den sich das Rauschen (hier rote Werte) befindet.

Manchmal ist der Bias langsamer als ein Roboter, manchmal genauso schnell, manchmal sogar schneller, d.h. der Bias verfälscht das Rauschen für kurze Zeiträume m.E. sehr stark.

Ich muss aber Bias und Rauschen mal zeitlich auswerten.

Wenn man länger Werte sammelt (10 Minuten) fällt der Bias wohl nicht mehr so stark ins Gewicht und es wird immer mehr zu einem Meßrauschen...

Gruss,
Alexander
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/noise.gif/

 

[rainer_r]

Hallo Alexander,

wir können weder Noise noch Bias (Rauschen und Offset) vom Messwert trennen, da wir nicht wissen wann und wie stark es auftritt. Auch die quasi stätionäre Messzeit (ergibt Anzahl Messwerte) ist während der Fahrt deutlich kleiner als 5 oder 10 Minuten (oder man bleibt stehen). Ich denke damit müssen wir leben.

Ich habe versucht gestern mich in die Theorie der EKF einzulesen, da die z.V stehenden Messdaten ja eigenlich einer nicht linearen Verteilung folgen. Leider stoße ich da schon an die Grenze meines Matheverständnisses. Die Frage die ich beantworten wollte war: um wieviel schlechter wird die Schätzung wenn ich den diskreten KF einsetze die Messdaten jedoch nicht linear verteilt sind. Auch wenn letztlich der EKF intern eine Linearisierung vorsieht (siehe Anhang). Ich habe es nicht geschafft hierfür eine Abschätzung zu machen.

Ein zweiter Punkt zur Klärung ist: wenn ich einen 1D-KF für einen bestimmten Messwert gut beschreiben kann, wie realisiere ich die Fusion von 2-3 verschiedenen Messdaten in einem KF. Ich bin mir auch nicht mehr sicher ob dies eine gute Lösung wäre.

Einen 3. Punkt betrifft die Rechenzeit des KF bei einer "ausgewachsenen" Gleitkommarechnung. Da während der Fahrzeit gerechnet werden muß, könnte die KF-Rechenzeit schon eine Rolle spielen. Meine Frage ist, könnte man das KF auch ohne Gleitkommarechnung programmieren

Eigentlich stelle ich fest, ich bin noch weit entfernt das KF richtig zu verstehen um des optimal für unseren Zweck einzusetzen. So hoffe ich sehr du kannst hier helfen. Ich habe für dich einige Abhandlungen aus meinem Fundus zum KF angefügt, hoch interessant wie ich finde.

Attachment: https://forum.ardumower.de/data/media/kunena/attachments/930/05_KalmanLokalisierung.pdf/

 

[nero76]

Hallo Rainer,

Linearisierung: Wenn möglich würde ich EKF einsetzen - die Linearisierung erfolgt nur um den Arbeitspunkt, d.h. insgesamt wird meines Wissens schon mit einem nicht-linearen System gearbeitet.

Ich habe alle wichtigen Formeln für den EKF einmal angehängt. Würdest Du auch etwas SciLab-Code für einen Prototypen einsetzen wollen? Dies ist m.E. sehr sinnvoll um erstmal Ergebnisse zu bekommen und bevor man in C-Code loslegt. Dann würde es vermutl. helfen wenn ich eine kleine Einführung/Auffrischung für Matrizenrechnung, Jakobimatrix etc. (für SciLab) gebe. In SciLab kann man sehr schnell den EKF umsetzen und ausprobieren, beispielsweise kann man mit SciLab eine Matrix A definieren
A=[1 2
3 4]
und dann ganz einfach damit rechnen, z.B. Matrizenmultiplikation: B=A*A, oder Inverse einer Matrix berechnen: C=inv(A) und vieles mehr mit einfachen Befehlen...
Ich denke man versteht den EKF deutlich besser wenn man ihn direkt mit ausprobieren und den SciLab-Code nachvollziehen kann).

Fusion: Die Sensorfusion ist beim EKF bereits so vorgesehen, d.h. du kannst den Upate-Step für beliebig viele Sensoren nacheinander durchführen und damit Zustandsvektor und Kovarianzmatrix jedemals updaten. Über die Gewichtung bestimmst Du wie stark der einzelne Sensor gewichtet werden soll.

Gleitkommarechnung: Sollte kein Problem sein, solange die Matrizen nicht so groß werden. Man kann beim EKF das Superpositionsprinzip anwenden, d.h. man kann Sensor für Sensor einzeln updaten und braucht dann keine schwierigen Rechenoperationen durchführen. Wenn die Update-Rate nicht allzu hoch ist, sollte ein Arduino das m.E. gut schaffen.

Gruss,
Alexander
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/ekf.png/

 

[nero76]

Fundstück: Video zum Thema Kalman Filter:

https://www.youtube.com/watch?v=18TKA-YWhX0