HB-UNI-Sen-LEV-US - Ultraschall Füllstandsensor schwankende Werte

[oreider]

Hallo zusammen,

ich würde gerne mit dem oben genannten Sensor die Salzmenge meiner Wasserenthärtungsanlage messen.
Hier geht es grundsätzlich nicht um absolute Genauigkeit sondern eher um eine Meldung, wenn ich wieder Salztabletten nachfüllen muss.
Ich habe das ganze mit dem "SODIAL(R) Ultraschall Sensor Entfernungsmessung Modul Sensor US-100" realisiert.
Nun schwankt der Wert doch sehr stark. Mögliche Ursache evtl. der kleine Behälter der gemessen werden soll!? Gibt es hierfür einen Sensor der sich besser eignet? Evtl. hat hier schon jemand von euch Erfahrungswerte bevor ich andere Sensoren teste...
Auf den Bildern seht ihr natürlich nur den Versuchsaufbau... Keine Finale Version.
Schönen Dank
Tom

[FUEL4EP]

Hallo oreider,

versuche mal, Dein verrauschtes Sensorsignal mit einem Kalman-Filter zu filtern.

Beispiele sind z.B. unter

https://github.com/NagarajSMurthy/Kalma ... nic-sensor
https://github.com/VibAruna/Kalman-Filt ... nic-Sensor

zu finden.

[jp112sdl]

Hier misst jemand seinen Salzbehälter-Stand über das Gewicht... vielleicht wäre das die bessere Lösung für deine Anwendung:
viewtopic.php?f=76&t=49752&start=10#p634672

Ansonsten - wenn du einen reflektierenden Feststoff misst, kannst du es mit optischer Abstandmessung (ToF Sensor VL53L0X) probieren:
https://github.com/jp112sdl/HB-UNI-Sen-LEV-TOF

[cmjay]

versuche mal, Dein verrauschtes Sensorsignal mit einem Kalman-Filter zu filtern.

Für den Anwendungsfall und bei dem gezeigten Messwertverlauf braucht man aus meiner Sicht kein solch schweres Geschütz wie einen Kalman-Filter. Ein gleitender Mittelwert mit Ausschlusskriterium "20%-Abweichung vom Mittelwert", um die wenigen Ausreisser einzufangen, sollte völlig ausreichen. Letztendlich geht es doch hier nicht um eine Präzisionsmessung einer stark fluktuierenden Größe sondern nur darum festzustellen, wann sich der Behälter langsam und stetig einem Füllstand nähert, bei dem man mal ans Auffüllen denken sollte.

[FUEL4EP]

Hallo cmjay,

im eindimensionalen Fall ist ein Kalman Filter ist kein schweres Geschütz. Es ist im Gegensatz zu einem gleitenden Mittelwertfilter sehr Speicher schonend. Ein gleitender Mittelwert über N Abtastwerte braucht dagegen N Speicherwerte. Vom Prinzip her ist ein Kalman Filter im eindimensionalen Fall es ein rekursives Filter 1. Ordnung, das ganz einfach ist. Hier aus dem zitierten Codebeispiel https://github.com/VibAruna/Kalman-Filt ... 42_IIC.ino:

Code: Alles auswählen

   //Kalman Filter Algorithm
    float mu_bar = A*pre_mu;
    float sigma_bar = A*pre_sigma*A + R;
    float K = sigma_bar*C/(C*sigma_bar*C + Q);
    float mu = mu_bar + K*(range - C*mu_bar);
    float sigma = (1 - K*C)*sigma_bar;

Dazu braucht man noch ein paar Parameter:

Code: Alles auswählen

//---------------------------------------Parameters Related to the Kalman Filter-----------------------------------------------
int A = 1;
int B = 0;
int C = 1;
int u = 0;
float R = 8*pow(10,-3);
float Q = 8.4535*pow(10,-2);

Das ist alles! Selbst wenn man mit der Schätzung des Kovarianz des Messrauschens R oder des Prozessrauschens Q daneben liegt, ist ein Kalman Filter relativ 'gutmütig'. Probiert es doch einfach mal aus und 'spielt' damit.

Selbst ein mehrdimensionales Kalman Filter passt locker auf einen ATmega1284P.

[stan23]

Es ist im Gegensatz zu einem gleitenden Mittelwertfilter sehr Speicher schonend. Ein gleitender Mittelwert über N Abtastwerte braucht dagegen N Speicherwerte.

Es ist aber nur Datenspeicher-schonend.
Die Codegröße ist wesentlich höher, gerade wenn die CPU keine HW-Division unterstützt und mit nur 8 Bit breiten Registern Float-Werte berechnen soll.

Ohne es zu testen, würde ich sagen dass ein gleitender Mittelwert in der Summe RAM+Code-Größe kleiner ist und schneller gerechnet ist.

Natürlich nimmt man dazu keine runde Dezimalzahl an Werten zur Berechnung des Mittels, sondern eine Zweipotenz die sich durch einen Shift ersetzen lässt.

[cmjay]

Hallo Ewald,
mir ging es primär darum, dass ein gleitender Mittelwert im Gegensatz zu einem Kalman-Filter recht intuitiv verständlich und leicht auf der CCU zu implementieren ist (gibt auch Skriptbeispiele im Forum). Über den Ressourcenverbrauch habe ich mir in dem Zusammenhang gar keine Gedanken gemacht. Da hast du ganz offensichtlich ein viel tieferes Verständnis der Materie als ich.

Meine Sorge war, dass der TE (dessen Background in der Messwertanalyse ich natürlich nicht kenne) bei der Konfrontation mit den kryptischen Parametern eines Kalman-Filters akute Panikattacken bekommt und sofort den Griffel fallen lässt.

Wie auch immer. Unabhängig von der zu wählenden Methode der Filterung bin ich der Meinung, dass die Performance des US-100 mit einer Schwankungsbreite der Messungen von +/- 1.5cm durchaus ausreichend für die Anwendung des TE ist.

EDIT:
Zwischenzeitlich hat Marco ja auch einen Beitrag verfasst und ich stelle fest, dass ich von den Diskutanten derjenige mit der wenigsten Ahnung von der Materie bin.

[FUEL4EP]

Hallo stan23,

die paar Zeilen Code von oben brauchen nicht viel Flashspeicher. Für einen gleitenden Mittelwert sind ähnlich viele Programmzeilen vonnöten.
Bei einem 328P basierten Ultraschallsensor 'langweilt' sich die MCU, so dass auch Floatingpoint Operationen problemlos machbar sind.
Wollen wir dagegen über 1024 Messwerte einen gleitenden Mittelwert bilden (1 Messwert = 2 Byte), brauchen wir schon 2kByte RAM!
Ein Kalman Filter braucht nur wenige Bytes. Ich nutze gerade auf einem ATmega1284P ein Kalman Filter (n=4,m=1) mit Double Floatingpoint Arithmetik. Die Rechenzeit ist nur 0.2 Sekunden.

Wir können ja eine 'Challenge' machen: klassisches Mittelwertfilter gegen Kalman Filter Möge das bessere Filter gewinnen

Hier nochmal eine andere, einfach anwendbare Kalman Filter Bibliothek von Github für den trivialen eindimensionalen Fall:

https://github.com/denyssene/SimpleKalmanFilter

Da muss man keinen 'Angstschweiß' auf die Stirn davon bekommen

[stan23]

Hallo Ewald,
1024 Messwerte finde ich extrem viel, ich dachte eher an 16

Aber vielleicht habe ich den Anwendungsfall nicht richtig verstanden und bin in mein gewohntes Verhalten zurückgefallen, Resourcen (Laufzeit + Speicher) zu sparen.

[jp112sdl]

Bin gespannt, was der TE überhaupt erstmal für ne Meinung zu den Vorschlägen hat