Luftdrucksensor mit sich selbst überprüfen

Hi,

ich arbeite momentan daran, meinem Quadrocopter das Höhehalten beizubringen. Dazu möchte ich die Daten des Drucksensors (MPX4115) "filtern". Ich denke mir, es sollte doch möglich sein, mithilfe einer mathematischen Probe die Stimmigkeit der Daten zu überprüfen!?
Deswegen führe ich eine zweite Variable ein, nennen wir sie mal Geschätzte_Höhe.
Zuerst bestimme ich die Differenz zwischen der Geschätzen_Höhe und der gemessenen Höhe.
Anschließend integriere ich diese Differenz und differenziere zur letzten Differenz.
Anhand dieser Daten kann ich nun die Geschätze Höhe korrigieren und das Spiel beginnt von vorne. Kann ich damit die Daten etwas verbessern oder ist das nur eine blöde Einbildung von mir?

Wäre interessant, wenn sich jemand zu meinem Ansatz äußern würde und evtl. eine Diskussion entstehen könnte :D

Gruß
Chris

Ich hätte nur über einen bestimmten Zeitraum die gemessene Höhe integriert um das Rauschen zu reduzieren. Das sollte doch locker reichen.
Anstatt softwareseitig zu integrieren bietet sich auch ein Tiefpass an, spart Rechenleistung.

Solange dem Copter nicht gesagt wird, dass er steigen soll, sollte er doch von Haus aus versuchen den Wert des Sensors konstant zu halten, oder?

Hi Robert,

ich habs bereits mit einem digitalen Tiefpass probiert, das reicht jedoch nicht! Einen analogen Tiefpass hab ich schon in die Schaltung integriert ;)
Ein Problem besteht darin, dass der Sensor sehr stark rauscht. Normalerweise würde ich versuchen, das Rauschen mittels Komplementärfilter (incl. ACCZ) zu kompensieren, jedoch braucht das wieder einiges an Rechenleistung...

Gruß
Chris

Hmm, und wie sieht es mit EMV Problemen aus?
Es fließen ja recht hohe Ströme mit steilen Flanken, da koppelt ganz fix was ein.
Ist alles vernünftig geschirmt? Leitungen vom Sensor verdrillt?

Hast du Messwerte für uns? Zum Bsp. eine Wertetabelle von einem DSO mit hoher Abtastung, alternativ eine FFT. Besser ist natürlich ein Specki, da siehst gleich die Störfrequenzen, natürlich ist die Bandbreite auch viel größer.

Oder ist der Sensor einfach so schlecht?

Hi,

ich probier das ohne eingeschaltete Motoren, da sollte es in der Hinsicht keine Probleme geben. Der Sensor ist direkt an einen OP angeschlossen, mit ca. 0.5cm langer Leiterbahn.
Messwerte hab ich momentan nicht. Das Problem sollte wohl auch eher in der Software liegen, ich Interpoliere die Daten durch Oversampling.
Das Rauschen beschränkt sich meist auf ca. +-5Digits, wobei 1 Digit ca. 1cm Auflösung bedeutet.
Außerdem misst der Sensor auch die Beschleunigung mit (in gewissem Maße) und die Luft staut sich, wenn ich hin sehr schnell nach oben bewege...

Ich hoffe, meine Probleme sind etwas rübergekommen!? :D

Gruß
Chris

Also an der EMV sollte es dann auf den ersten Blick nicht liegen, es können aber trotzdem Störungen auf kapazitivem Wege einkoppeln, ist ja alles recht hochohmig.

Dich stören 10cm O.o Andere wären froh, wenn die Kiste nicht vom Himmel fällt :D

Hat der Mikrocontroller genug Zeit zum Messen? Nicht, dass die einfach nur zu kurz gewählt wurde.
Von welchen Spannungsunterschied reden wir denn bei einem Digit?

Zum Thema Luftstau, habe ich mal einen Trick gesehen. Einfach ein Stück Silikonschlauch drauf und vorne verstopfen, der Schlauch und die Luft in ihm wird ja trotzdem komprimiert. Weiß den Zusammenhang aber nicht mehr.

Naja, mich würden 10cm nicht stören, wenn er die Höhe halten würde ;)
Aber z.b. wenn merkt, dass er zu hoch ist, gibt er wenig Gas und fällt mehr oder minder schlagartig um ein paar dm ab... Dabei wirkt irgendetwas auf den Sensor, weßhalb dieser kurzzeitig glaubt, er würde nach oben gehen... Das ist natürlich saublöd, weil es in einer Oszilation endet ...
Was meinst du mit "Zeit zum messen"?
Der Sensor wird von einem ATMega328P ausgelesen (Prescaler = Auto) und anschließend Interpoliert. Das Ergebnis wird dann über die UART zum ATXMega32A4 gesendet, welcher der Hauptprozessor ist.
Also der Sensor gibt 46 mV/kPa aus. Das Ausgangssignal wird dann analog vertärkt und tiefpassgefiltert. Den Verstärkungsfaktor kann ich dir gerade nicht nennen, sollte aber bei so 50-100 liegen.
Natürlich ist der Sensor bei mir nicht einfach lose, ich habe etwas Anti-ESD-Schaumstoff herumgewickelt und das Ganze dann Eingeschrumpft, so sollte er gegen (UV-) Licht und direkte Luftzüge geschützt sein.

Gruß
Chris

Zitat:

---

Zitat von MisterMou

...die Luft in ihm wird ja trotzdem komprimiert. Weiß den Zusammenhang aber nicht mehr.

---

Der Zusammenhang war z.B. das auf einem fahrenden Roboter ein verschlossener Schlauch herum gelegt wird und wenn der Bot gegen ein Hinderniss fährt wird der Schlauch zusammen gedrückt und ein Überdruck entsteht, der dann gemessen werden kann. (Quelle: Roboter selbst bauen von U. Sommer)

Allerdings vermute ich dass das in der Praxis für eine Quadrocopter oder sonstige fliegenden Maschinen nicht geeignet ist, weil der Silikonschlauch zuviel Eigenstabilität hat und somit das Messsergebniss verfälscht und unnötigen Rechenaufwand hervorruft. Mal ganz davon abgesehen das dazu, je nach Schlaumaterial, Messreihen erstellt werden müßten mit denen der Messfehler in den verschiedenn Höhen herrausrechenbar wird.

Viele Grüße

Zitat:

---

(Quelle: Roboter selbst bauen von U. Sommer)

---

Ahh, genau, da hab ich das her :D

Sonnst kommt mir gerade noch ein Schalldämpfer aus der Pneumatik in den Sinn.

Wenn dein Copter so stark abfällt, frag mal deine Reglung ;)
Genau, Prescaler, mir ist das Wort nicht eingefallen. Womit programmierst du, wenn es die Einstellung Auto gibt? Bascom? Unter C und AVR Studio hab ich das nicht.

Also alle Projekte, die ich so kenne (Multiwii, Mikrokopter, Shrediquette, Arducopter, DJI) haben höchstens etwas Schaumstoff um den Sensor, wie ich auch.
Ich lasse ihn ja mit der Hand abfallen ;) Die Motoren sind dabei aus!
Ich programmiere in Bascom. Auto bedeutet, Bascom errechnet aus der Taktfrequenz die optimale Frequenz für den ADC (so, dass er in den Specs liegt).

Gruß
Chris

Randbemerkung zu eurer Diskussion:
Der MPX4115 ist mit seiner Auflösung von 46mV/kPa eigentlich nicht gut für barometrische Anwendungen geeignet. Man müßte die Auflösung im barometrisch relevanten Bereich eigentlich durch einen Linearverstärker verbessern. Hinzu kommt die "grobe" AD-Wandlung, die nur 4,9mV auflösen kann.

Besser ist z.B. die I2C-Variante BMP085 mit einer (digitalen) Auflösung von 0,01hPa bei einer abs. Genauigkeit von +-1,0hPa.

Hi,

der MPX4115 ist deutlich (!!!) besser als der BMP085. Ich verstärke den Ausgang des MPX4115, sodass die Auflösung erheblich steigt.

Gruß
Chris

Zitat:

---

der MPX4115 ist deutlich (!!!) besser als der BMP085.

---

Da habe ich doch deutliche (!!!) Zweifel!

Hi,

ich hab beide Sensoren hier, mit dem BMP085 komme ich nicht auf die Auflösung, die der MPX hat.
Außerdem ist der MPX analog, d.h. ich kann das Signal beliebig (naja fast) verstärken. Beim BMP hingegen muss ich mit der Auflösung leben, die der interne ADC macht.

Gruß
Chris

Hi Chris,

klar, wenn man (MPX + Verstärkung 50-100-fach) vergleicht mit dem BMP solo, dann magst du Recht haben.

Der BMP kann 25cm ohne externe analoge Einflüsse auflösen. Das ist schon wirklich gut und läßt sich durch einfache Mittelwertbildung noch auf 10cm steigern.
Das kann der MPX + µC-ADC nicht leisten.

Hi,

mit Oversampling und OP komme ich auf mehr als 10cm Auflösung beim MPX. Aber die Wahl des Sensors ist schon gefallen. Mir gehts eher um die korrekte Filterung ;)

Gruß
Chris

Zitat:

---

Aber die Wahl des Sensors ist schon gefallen. Mir gehts eher um die korrekte Filterung

---

Ja, das hatte ich kapiert.

Zitat:

---

Ein Problem besteht darin, dass der Sensor sehr stark rauscht.
...
Das Rauschen beschränkt sich meist auf ca. +-5Digits, wobei 1 Digit ca. 1cm Auflösung bedeutet.

---

Das ist ein optimales Ergebnis! Der Copter kann mit dieser Sensorschaltung auf +-5cm gehalten werden.
Da würde ich auch beim MPX bleiben. ;)

Hi,

naja, das Problem besteht eben darin, dass kurze Überschwinger auftretten, wenn der Kopter / Sensor beschleunigt wird... Da ich den D-Anteil (also die Geschwindigkeit) auch regeln muss, besteht genau darin mein Hauptproblem. Deswegen überlege ich mir momentan einen Algorithmus, welcher diese Peaks etwas glättet, darum auch dieser Thread ;)

Gruß
Chris