Wie Sensordaten effektiver glätten?

[charles200 (Gast)]

Hallo,
ich bin gerade an einem regelungstechnischen Projekt, in dem ich einen 
Lego-Roboter auf 2 Rädern stabilisiere. Dazu wird ein Raspberry Pi mit 
Lego-Sensor/Aktuator-Interface verwendet.
Für die Messung des Winkels wird ein Lego Gyro-Sensor verwendet, der 
eine Sampling-Rate von 1 kHz und eine WInkelauflösung von 1° hat.

Der Sensor gibt neben dem absoluten Winkel auch die 
Winkelgeschwindigkeit aus, welche beide auch als Zustände definiert 
sind.

Ich habe nun das Problem, dass die Geschwindigkeitswerte sehr stark 
verrauscht sind. Bisher habe ich es so gehandhabt, dass ich den 
Differenzenquotienten der aboluten Winkeländerungen durch die 
Programmlaufzeit berechnet habe und darüber noch mal einen gleitenden 
Mittelwert gebildet habe (da die Auflösung sehr schlecht und die Werte 
daher groß sind). Also im Prinzip so (mit Python):

import time
from collections import deque

winkelwert_alt=0
liste=deque(maxlen=21)
while True:
  start=time.time
  
  s=(winkelwert_aktuell - winkelwert_alt)/abtastzeit   #Differenzenquotient
  winkelwert_alt=winkelrwert_aktuell
  liste.append(s)                                      #Erweitere Liste
  
  winkel_ableitung= sum(liste)/len(liste)           #gleitender Mittelwert
  
  ende=time.time
  
  if (ende-start)<0.01:
       time.sleep(0.01-(ende-start))   # feste Schleifenlaufzeit von 10 ms

Also ich bilde pro Schleifenschritt, der mit einer festen Abtastzeit von 
10 ms erfolgt den gleitenden Mittelwert über 21 Änderungswerte.
Das läuft so eigentlich auch ganz gut, ich habe aber das Problem, dass 
sich der Roboter nach einer längeren Zeit der Stabilisierung wieder 
selbst hochschaukelt und die Ableitungswerte schleichend wieder größer 
werden.
Ich möchte daher nun innerhalb der Schleife eine weitere Schleife 
realisieren, in der der Sensor mehrmals ausgelesen wird und somit mehr 
Werte pro Schritt zur Verfügung stehen.
Habt ihr noch bessere Vorschläge?

[Thomas (kosmos)]

wenn das Ding 1000 Ergebnisse pro Sekunde liefert warum sollte man dann 
nur 100 mal pro Sekunde abtasten? Man sollte das Potential hier schon 
ausnutzen.

Wenn er sich aufschaukelt liegt das vermutlich an zu großen 
Korrekturwerten oder der zu geringen Abtastrate, so das der Fehler zu 
spät bemerkt wird.

[charles200 (Gast)]

wenn ich die Abtastrate erhöhe, kann man dann durch Bildung des 
gleitenden Mittelwerts eigentlich von einem Oversampling sprechen? Bin 
mir sowieso noch nicht im Klaren darüber, wie ich die Verzögerung für 
die Ausarbeitung formal modellieren soll, d.h. mit Zeitkonstanten etc.

[wurster (Gast)]

Ich würde mir erstmal ein paar Sekunden mit dem Gyrosensor aufzeichnen 
(Stillstand, periodische/chaotische Bewegung, etc.) und dann das Signal 
erstmal einer FFT unterziehen.

Da siehst du dann ganz schnell, was Nutzdaten und Störsignale sind.

Entsprechend würde ich mir ein digitales Filter auslegen.

Aber auch hier gilt: Shit in Shit out.

Das Signal sollte schon möglichst rein vom Sensor erfasst werden.

[Roland P. (pram)]

Probier mal einen Medianfilter. Du brauchst dazu ein sliding window mit 
den letzten 5 oder 7 Messwerten. Die Werte sortierst du und nimmst den 
mittleren.
Gruß Roland

[Bernd K. (prof7bit)]

Also mit der Abtrastrate würde ich an die Grenze dessen gehen was der 
Sensor hergibt, ansonsten verschenkst Du an der Stelle schon wertvolle 
Informationen.

Du sagst daß der "Gyro"-Sensor auch absolute Winkel ausgibt? Dann sind 
es eigentlich 2 Sensoren: Ein Accelerometer und ein Gyroskop. Die kannst 
Du mit einem Kalman-Filter fusionieren. Hat diese Sensorbaugruppe 
vielleicht schon irgendeine Art von Auswertung eingebaut die versucht 
eben dies bereits intern zu tun? Kommst Du auch irgendwie an die rohen 
Werte von Gyro und Accelerometer dran?

[Hamburger (Gast)]

Roland P. schrieb:
> Probier mal einen Medianfilter. Du brauchst dazu ein sliding window mit
> den letzten 5 oder 7 Messwerten. Die Werte sortierst du und nimmst den
> mittleren.

Das gibt aber gewaltiges digitales Rauschen sagt mir mein Wissen aus der 
NT-Vorlesung!

[Weg mit dem Troll ! Aber subito (Gast)]

Was soll gleitender Mittelwert ueber 20 Punkte, und solcher Scheiss ? 
Rechenzeit verbraten ?
Nimm ein exponential Average, resp ein tiefpass. Beides benoetigt eine 
Speicherstelle und vielleicht 5 Operationen pro Sample. Und dann lass 
das ganze so schnell laufen wie's geht.

[Bernd K. (prof7bit)]

Weg mit dem Troll ! Aber subito schrieb:
> Was soll gleitender Mittelwert ueber 20 Punkte, und solcher Scheiss ?
> Rechenzeit verbraten ?

Verbrät kein bisschen mehr Rechenzeit als ein EMA, nur ein bisschen mehr 
Speicher.

> Nimm ein exponential Average

Hat aber völlig andere Eigenschaften, vielleicht braucht er zwingend ne 
fixe endliche Step Response?

[Manfred M. (bittbeisser)]

> Was soll gleitender Mittelwert ueber 20 Punkte, und solcher Scheiss ? Rechenzeit 
verbraten ?

Wenn er richtig programmiert wird, ist ein gleitender Mittelwert sehr 
effektiv. Kein anderer Tiefpass benötigt weniger Ressourcen! Allerdings 
ist die Umsetzung mit eine double ended Queue kontraproduktiv. Es genügt 
ein Ringpuffer fester Größe (Array) den man hier wohl selber verwalten 
muss.

Wenn man es richtig macht, benötigt jeder Arbeitszyklus nur eine 
Subtraktion, eine Addition und eine Division, und das unabhängig von der 
Anzahl der Werte. Den Ringpuffer benötigt man nur für die Subtraktion 
der alten Werte.

Aber da ich kein Java spreche, könnte ich das nur in C oder C++ zeigen.

[ABC (Gast)]

Manfred M. schrieb:
> Wenn er richtig programmiert wird, ist ein gleitender Mittelwert sehr
> effektiv. Kein anderer Tiefpass benötigt weniger Ressourcen!

Nee. Wenn egal ist ob IIR oder FIR: Ein EMA Filter ist wesentlich 
simpler.

y(t) = alpha * x(t) + (1 - alpha) * y(t-1)