-         

Ergebnis 1 bis 7 von 7

Thema: ACC Integrieren / wie Integral möglichst korrekt berechnen?

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    08.09.2007
    Ort
    Berlin
    Alter
    24
    Beiträge
    1.544

    ACC Integrieren / wie Integral möglichst korrekt berechnen?

    Anzeige

    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

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    Zitat Zitat von Che Guevara Beitrag anzeigen
    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.

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    08.09.2007
    Ort
    Berlin
    Alter
    24
    Beiträge
    1.544
    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

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    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.

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    08.09.2007
    Ort
    Berlin
    Alter
    24
    Beiträge
    1.544
    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
    Geändert von Che Guevara (09.11.2013 um 09:59 Uhr)

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    08.09.2007
    Ort
    Berlin
    Alter
    24
    Beiträge
    1.544
    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
    Ich hoffe, ich hab keinen Denkfehler eingebaut. Was hältst du davon?

    Gruß
    Chris

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    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.
    Geändert von RoboHolIC (10.11.2013 um 00:51 Uhr) Grund: Würdigung des bereits Erreichten.

Ähnliche Themen

  1. [ERLEDIGT] Linefinder integrieren , wie die Richtung der Abweichung erkennen ?
    Von oderlachs im Forum Sensoren / Sensorik
    Antworten: 2
    Letzter Beitrag: 22.11.2012, 18:16
  2. Möglichst kleine Gehäuse wie mp3 player
    Von ExXeQtor im Forum Suche bestimmtes Bauteil bzw. Empfehlung
    Antworten: 7
    Letzter Beitrag: 07.09.2010, 17:57
  3. Möglichst kleiner, möglichst schneller Linux-PC gesucht
    Von bjoerng im Forum PC-, Pocket PC, Tablet PC, Smartphone oder Notebook
    Antworten: 11
    Letzter Beitrag: 22.06.2010, 21:56
  4. Mega16 - Wie den Eingang korrekt abfragen
    Von little_boy im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 09.07.2006, 01:54
  5. Wie Fusebit für Quarz korrekt einstellen? (mit AVRprog)
    Von boeseTURBO-CT im Forum AVR Hardwarethemen
    Antworten: 9
    Letzter Beitrag: 08.09.2005, 21:21

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •