ACC Integrieren / wie Integral möglichst korrekt berechnen?

Hi,

ich muss einen Beschleunigungssensor integrieren, um auf die Geschwindigkeit zu kommen. Bis hierhin ja kein Problem. Nur leider, wie das beim Integrieren so ist, läuft das Integral weg...
Jetzt suche ich nach einem Weg, dieses Weglaufen zu verhindern. Mein erster Ansatz war, das Integral bei jedem Schleifendurchlauf mit 0.995 zu multiplizieren. Allerdings gibts dann Überschwinger in die andere Richtung, sobald die Geschwindigkeit wieder gegen 0 geht.
Also weiterüberlegt und auf folgende Idee gekommen: Ist es möglich, bzw. macht es Sinn, hier einen Beobachter (z.b. PI) zu implementieren? Ich weiß eben nicht, wieviel mir dieser bei nur einem Signal bringt. Bei mehreren Inputs (z.b. Gyro & Acc) macht es auf jeden Fall Sinn.
Und bevor ich hier jetzt stundenlang wie wild Parameter ausprobiere und rumprogrammiere, dachte ich, ich frag erstmal nach.
Wenn ja, welcher wäre hier den geeignet? Bin kein Profi in dem Gebiet, aber Verständnis dafür habe ich.

Vielen Dank & Gruß
Chris

Zitat:

---

Zitat von Che Guevara

Nur leider, wie das beim Integrieren so ist, läuft das Integral weg...

---

Daran ist nicht das Integral schuld sondern der Offset.

Dass der Offset bereits bestmöglich korrigiert ist, setze ich voraus. Vielleicht kann man minimale g-Werte als nicht relevant unterdrücken, also einen Schwellwert vorsehen, unterhalb dessen sich der Integrator blind/taub stellt. Gibt die Anwendung das her? Das verfälscht zwar auch das Ergebnis, eventuell aber weniger und eher tolerierbar als ein kontinuierliches weglaufen des Integrals!? Und natürlich die maximale angemessene Empfindlichkeit des Sensors wählen, damit der "blinde Fleck" sachter Bewegungen möglichst klein bleibt.

Hi,

nicht nur der Offset ist Schuld, auch z.b. Quantisierungsfehler und "Zeitfehler"... Das lässt sich aber alles nicht vermeiden.
Der Offset wurde gut kalibriert und wird auch ständig per starkem Tiefpass nachgeführt.
Kleine Werte zu unterdrücken ist eine schlechte Idee, da wenn sich z.b. die Geschw. nur langsam ändert, dies dann garnicht ins Integral einfließt und der Wert nur noch schlechter wird...
Also der Sensor hat eine Auflösung von 16384LSB / 1G. Ich teile momentan durch 32, sodass eine Auflösung von 512LSB / 1G rauskommt.
Der Wert muss nicht ganz korrekt sein, hauptsache die Größenordnung stimmt.
Ich hatte auch mal die Idee, das Integral nur dann zu verringern (*0.995), wenn momentan keine Beschleunigung vorhanden ist. Dies ist in zwei Situationen der Fall (theoretisch): Bei Geschwindigkeit = 0 und bei Geschwindigkeit = konstant, aber nicht 0. Das führte auch wieder zu Fehlern, da bei längerer konst. Geschw. das Integral immer kleiner wird und bei abnahme der Geschw. es dann Überschwinger gibt, die absolut nicht sein dürfen!!

Gruß
Chris

Eine Driftkompensierung durch willkürlich angenommene Gegendrift macht wenig Sinn. Eine treffende Driftkompensation erfordert genaue Kenntnis der Drift-verursachenden Messfehler. Die kennst du nicht. Beschleunigungen im Wertebereich von Messunsicherheit, Offset, Quantisierungsfehler entziehen sich nach meinem Verständnis der Messbarkeit.

Andernfalls hätten wir doch in modernen Autos längst Tachos auf Basis von g-Sensoren; das würde Geberbauteile, mechanische oder elektronische Tachowelle und die Fehler von Schlupf und tatsächlichem Radumfang eliminieren. Ich weiß zumindest nichts davon.

In speziellen Fällen kann die Verschmelzung mit anderen Messwerten hilfreich sein: So könnte z.B. jede Kurvenfahrt eines Straßenfahrzeugs anhand von Lenkeinschlag und gemessenen Radialkräften Rückschluss auf die Bahngeschwindigkeit geben.

Hi,

also dass dadurch das Ergebnis nicht sehr genau ist, ist mir klar. Dass es aber funktioniert, zeigt das Video hier: http://www.mikrokopter.de/ucwiki/VideoAbspielen?id=244
Es geht um eine Höhenregelung. Ich habe einen Drucksensor verbaut, der allerdings intern stark gefiltert wird (Tiefpass), ansonsten hätte ich dessen Werte einfach differenziert und zur Driftabschätzung benutzt...
Das ACCIntegral brauche ich, um mit einer best. Geschwindigkeit Steigen und Sinken zu können und um Höhenänderungen schnell zu dämpfen.
Außerdem wird es noch benötigt, um die Höhe zu bestimmen, also der Höhensensor ist zwar auf lange Zeit sehr stabil, reagiert aber nur recht träge. Der ACC hingegen reagiert schnell, hat aber eben Drift.
Deswegen ja auch meine Frage im 1. Post, ob z.b. ein Beobachter Sinn macht.
Die reine Datenverarbeitung sieht dann so aus:

Code:

---

//ACC Integrale
AccZVelocity += (AccZHeightLp-AccZNeutral);
AccZHeight += (AccZVelocity/14000);

//KomplementärFilter (wird nur alle 25Hz ausgeführt)
AccZHeight = (AccZHeight * 0.95) + (PressureHeight * (1-0.95));

---

Jetzt war also meine Frage, ob es Sinn macht, von AccZHeight (was ja durch den Komp. Filter langzeitstabil ist) Rückschlüsse auf den ACC-Drift zu ziehen?


Gruß
Chris

Hi,

also ich hab nochmal überlegt und ein paar Sachen zusammengeschrieben, die IMHO entscheidend sind, ob es funktioniert oder nicht.
Also als erstes muss ich sagen, eine GENAUE Driftbestimmung wirds wohl nicht, das ist klar. ABER unter der Annahme, dass der Kopter nicht bis in den Weltraum fliegen wird, sondern die Höhe immer einigermassen konstant ist (also ich meine zwischen 0 und max. 200Meter), kann man Annahmen, dass die Geschwindigkeit (also das Integral) langfristig auch nahe 0 ist.

Code:

---

lim      (Integral(AccZ(t)-Offset(t))) --> 0
t->oo

---

Deswegen kann man Annehmen, dass die Beschleunigung also langfristig 0 ist.
--> Daraus folgt für mich, dass, wenn ich den Offset immer nachführe (per starkem Tiefpass), der momentane Wert von AccZ-Offset (bis auf kurze Beschleunigungs"pausen") immer 0 sein sollte. Da allerdings die Offset-Nachführung nur aktiv ist, wenn ein Drift vorhanden ist, driftet das Integral trotzdem weg. Dem kann man evtl. mit einem konstanten "gegen 0 ziehen" vorbeugen.

Ich bin also der Meinung, mein Vorhaben ist möglich :D
Ich hoffe, ich hab keinen Denkfehler eingebaut. Was hältst du davon?

Gruß
Chris

Hmm, das kann ich zu dieser Uhrzeit nicht mehr nachvollziehen. Aber das Video zeigt Beeindruckendes!

Was hältst du davon, eine ?PD?-Regelung der Vertikalbeschleunigung mit dem schnellen ACC-Signal zu füttern und so störenden Einflüssen wie schwächelnden Akkus, Böen, Grapschhänden :) und ggf. abgeworfener Nutzlast gegenzusteuern?
Der langsamere Höhen-PI-Regler kann sich auf die träge barometrische Höhenmessung als IST-Wert beziehen und regelt die Drift des ACC-Regelkreises weg.