Auswahl Achse zum Schätzen der BPM #3

New Issue

toni · 2017-10-12T14:43:01+02:00

toni commented

2017-10-12 14:43:01 +02:00

Für den Schätzung der aktuellen BPM möchte ich die "beste" Achse des Accelerometers. D.h. die Achse mit der höchsten Periodizität und den "schönsten" Kurven. Das aktuelle Verfahren zählt einfach die Anzahl der Peaks, was eher suboptimal ist. Hier gilt es etwas cleveres zu finden.

Die einfachste Methode wäre vermutlich einfach die Korrelationswerte aufsummieren und dann diese Achse wählen. Leider sagt der reine Korrelationswert noch nichts darüber aus, ob diese Achse auch die richtigen BPM haben.

Spannend: Bei unterschiedlichen Arten des Dirigieren (Weich, Hart, Schnell, Langsam) sind unterschiedliche Achsen unterschiedlich wertvoll. Bei hart ist bspw. die Z-Achse sehr deutlich, bei weich eher die Y-Achse des XSense.

Vielleicht könnte man auch einfach alle Achsen beobachten und gewinnbringend kombinieren? Wobei eine Achse meist absoluten Humbug liefert und zwei Achsen ja eigentlich immer ganz "gut" sein müssten. Muss man probieren. Vielleicht die zwei Achsen die am ähnlichsten sind und dann von diesen Mittelwert nehmen oder die Achse mit geringsten Sigma über die Zeit.

Für den Schätzung der aktuellen BPM möchte ich die "beste" Achse des Accelerometers. D.h. die Achse mit der höchsten Periodizität und den "schönsten" Kurven. Das aktuelle Verfahren zählt einfach die Anzahl der Peaks, was eher suboptimal ist. Hier gilt es etwas cleveres zu finden. Die einfachste Methode wäre vermutlich einfach die Korrelationswerte aufsummieren und dann diese Achse wählen. Leider sagt der reine Korrelationswert noch nichts darüber aus, ob diese Achse auch die richtigen BPM haben. Spannend: Bei unterschiedlichen Arten des Dirigieren (Weich, Hart, Schnell, Langsam) sind unterschiedliche Achsen unterschiedlich wertvoll. Bei hart ist bspw. die Z-Achse sehr deutlich, bei weich eher die Y-Achse des XSense. Vielleicht könnte man auch einfach alle Achsen beobachten und gewinnbringend kombinieren? Wobei eine Achse meist absoluten Humbug liefert und zwei Achsen ja eigentlich immer ganz "gut" sein müssten. Muss man probieren. Vielleicht die zwei Achsen die am ähnlichsten sind und dann von diesen Mittelwert nehmen oder die Achse mit geringsten Sigma über die Zeit.

toni self-assigned this 2017-10-12 14:43:01 +02:00

toni added the

Feature

Matlab

labels 2017-10-12 14:43:01 +02:00

toni referenced this issue from a commit

2017-10-15 21:04:31 +02:00

work on #3 - viele Dinge versucht, leider fehlt irgendwie die richtige Idee...

toni commented

2017-10-16 00:01:01 +02:00

Heute sehr viel versucht:

Kombination zwischen Mean, Number of peaks und Summe der Peaks. Ergebnisse waren durchwachsen. Number of peaks ist nicht wirklich geeignet, da auch bei schlechten Signalen viele Peaks erkannt werden können. Für Summe der Peaks gilt das Gleiche. Auch der Mean funktioniert eher schlecht, da zu langsame Signale mit wenigen Peaks auch einen hohen Correlations Mean haben können.
sum(corr) am nächsten zu 0. Hier könne zwar sehr verrauschte Signale rausgefiltert werden, jedoch ist eine Unterscheidung zwischen einer 40 BPM und 80 BPM Korrelation nicht möglich. Also auch eher ungeeignet.
getNumberOfIntersections mit spezifischen Wert. Funktioniert erstaunlich gut mit einem Wert von 0.2. Von 30 getesteten Aufnahmen hatte 3 Stück ein paar Probleme damit.

Irgendwie bin ich aber mit all dem nicht zufrieden. Das wirkt so mega heuristisch. Eigentlich suche ich einen Wert, der die Periodizität des Signals am besten beschreibt. Also diese schöne eindeutige Form (siehe Bild).

Edit: Kombination auf Intersections, RMS und GeoMean läuft ganz gut. Nicht zu 100% zufrieden. Wird mit dem nächsten Commit trotzdem erst einmal geclosed! Notfalls reopen mit Begründung.

Edit 2: Doch nicht closen. Wieso auch :)?

Heute sehr viel versucht: 1) Kombination zwischen Mean, Number of peaks und Summe der Peaks. Ergebnisse waren durchwachsen. Number of peaks ist nicht wirklich geeignet, da auch bei schlechten Signalen viele Peaks erkannt werden können. Für Summe der Peaks gilt das Gleiche. Auch der Mean funktioniert eher schlecht, da zu langsame Signale mit wenigen Peaks auch einen hohen Correlations Mean haben können. 2) sum(corr) am nächsten zu 0. Hier könne zwar sehr verrauschte Signale rausgefiltert werden, jedoch ist eine Unterscheidung zwischen einer 40 BPM und 80 BPM Korrelation nicht möglich. Also auch eher ungeeignet. 3) getNumberOfIntersections mit spezifischen Wert. Funktioniert erstaunlich gut mit einem Wert von 0.2. Von 30 getesteten Aufnahmen hatte 3 Stück ein paar Probleme damit. Irgendwie bin ich aber mit all dem nicht zufrieden. Das wirkt so mega heuristisch. Eigentlich suche ich einen Wert, der die Periodizität des Signals am besten beschreibt. Also diese schöne eindeutige Form (siehe Bild). Edit: Kombination auf Intersections, RMS und GeoMean läuft ganz gut. Nicht zu 100% zufrieden. Wird mit dem nächsten Commit trotzdem erst einmal geclosed! Notfalls reopen mit Begründung. Edit 2: Doch nicht closen. Wieso auch :)?

Screenshot from 2017-10-15 22-23-14.png

26 KiB

toni referenced this issue from a commit

2017-10-16 00:20:58 +02:00

ref #3 - methode zum auswählen der achse hinzugefügt. nutze qualitätsmerkmale RMS, Intersections und GeoMean um die beste Achse zu suchen.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toni/Dirigent#3