Low Cost Headtracker mit Arduino und Magnetometer

R

RVB

Erfahrener Benutzer
#121
#121
@Rangarid,
kannst du die Messdaten über eine Schnittstelle ausgeben und dort in eine Datei schreiben? Dann könnte man sich das ungefilterte Signal über der Zeit anschauen und dann entscheiden, was zu tun ist. Auch könntest du deine Ausgaben so mitschreiben und deinen Algorithmus prüfen. Wie schnell werden die Daten erfaßt?
 
R

Rangarid

Erfahrener Benutzer
#123
#123
Die Messung ist im 50Hz Takt genauso wie das PPM. Ich messe wo ich gerade bin, guck ob schon 20ms rum sind und wenn ja schreib ichs PPM raus. Habe also immer nen neuen Wert pro PPM-Frame...Ich denk mal das mit den RAW-Daten Filtern ist vielleicht die bessere Idee...

Ich guck mir mal an wie andere das gemacht haben.
 
R

RVB

Erfahrener Benutzer
#124
#124
Wenn du das gefilterte Signal im 50 Hz Takt haben willst müsstest du mindestens mit 150-200 Hz messen; klar, oder?
 
R

Rangarid

Erfahrener Benutzer
#128
#128
Jo, dacht ich mir. Ich werd mal messen wie lang die Berechnung dauert, wenn ich aus 3 Werten einen Mittelwert bilde. Momentan mit einem Wert und Berechnung dauert das Auslesen und berechnen der Lage ~3,5ms, reicht also noch grad so, um das PPM ohne Interrupt auszugeben.

Ich glaube der Kompass kann mehr als 100Hz, bin mir nichtmehr ganz sicher, aber ich mein auch 400Hz gelesen zu haben in der Doku, muss ich nochmal nachlesen.

Also meint ihr eine Mittelwertsberechnung aus 3-4 mal auslesen sollte vorerst reichen, um eine stabile Ausgabe zu bekommen?
 
R

Rangarid

Erfahrener Benutzer
#131
#131
Das ist ja auch erst der Prototyp ;) learning by doing...

Also das Teil kann im Fast Mode 400Hz, da sollten also ein paar Werte rauszuholen sein. Normal macht er 100Hz, kann ja erstmal kucken wie es bei 2 Werten aussieht, danach müsst ich mal kucken wie ich den Fast Mode einstelle...


Ah ja so gehts:
Code: 
#include <Wire.h>

void setup(){
  // let Wire initialize the Two Wire Interface and interrupts
  Wire.begin();

  // change the clock rate (behind Wires' back)
  TWBR = ((CPU_FREQ / 400000L) - 16) / 2;

  // now we're cookin at 400 Khz... woo hoo!
}
Ah moment jetzt bin ich etwas verwirrt...bei 100kHz sollte man ja schon mit 200hz auslesen können oder versteh ich das grad falsch? Dafür brauch ich ja keinen Fast Mode...
 
R

RVB

Erfahrener Benutzer
#132
#132
@Rangarid,
gibt's echt keinen Weg, die Messwerte in eine Datei zu schreiben? Erst ins Ram und dann auslesen?
Bei Mittelwertfilterung hast du halt immer eine Phasenverschiebung und damit Verzögerung. Wenn du mit 50Hz misst und dann z.B. 5 Werte mittelst, brauch ein Stufensprung 5 Werte bis er voll durchs Filter ist, also 5*20ms Verzögerung. Alles was schneller als 10 Hz ist, wird also (in dem Beispiel) schon gefiltert.
 
R

Rangarid

Erfahrener Benutzer
#134
#134
Ich kann die Werte in die Konsole ausgeben und dann rauskopieren. Wenn dann würde ich die Werte erst Filtern und dann berechnen, das sollte um einiges schneller sein.

Wenn ich pro PPM-Frame also z.B. 4 Werte auslese wäre ich ja bei 200Hz. Dann hab ich doch einen gefilterten Wert pro PPM-Frame, da sollte doch eigentlich keine Verschiebung drin sein?

Werd das gleich mal so ausprobieren....
 
R

RVB

Erfahrener Benutzer
#136
#136
Ich weiß leider etwas wenig über die Funktionsweise deines Trackers, manchmal komm ich leider in deinen posts nicht mit...
Mich würde halt das Signal interessieren, wenn der Tracker stillsteht und wenn du ihn bewegst; daraus könnte man eine passende Filtermethode wählen.
Andere Idee:
Statt einem allgemein gültigen Filter könnte man aber auch ein zweckbezogenes einsetzen (mp3-Idee): schneller als 300° Kopfbewegung pro Sekunde dürfte keiner hinkriegen. Also könntest du das delta (neuer Messwert)-(letzter Messwert) begrenzen auf (300°/50 =) 6°. Das wär schnell programmiert, brauch keine Rechenleistung und bringt keinen Zeitverzug. Vielleicht bessert das das Problem.
Leider kenne ich halt das Problem nicht genau.
 
R

Rangarid

Erfahrener Benutzer
#137
#137
Also ich hab mir jetzt mal nen Filter wo abgeguckt, damit hab ich eigentlich recht gute Werte. Die Abweichungen beim Stillstand liegen bei maximal 15us vom Mittelwert des ganzen.

Wenn man mal bedenkt, dass ein Servo 8bit auflösung hat können 256 Schritte im Servo durchgeführt werden. Wenn wir also von einem 180° Servo ausgehen haben wir grob 2 Schritte pro Grad.
Ein Servo bekommt Signale von 750-2250us, das sind 1500us maximal. Damit kommen wir auf grob 6us pro Schritt bei 8bit, also wieder beim 180° Servo auf maximal 1°. Wenn man nun noch abzieht, dass der Motor nicht in genau 256 Schritten stellt sollte die Abweichung weniger als 1° sein. Bin mal gespannt, wenn ich es nachher zuhause teste ob man das überhaupt merkt.

Seltsam ist, dass der Magnetsensor viel mehr Abweichungen hat als der Beschleunigungssensor. Der hat nämlich GARKEINE Abweichung mit dem Filter...Aber das könnte auch wieder am Kompass liegen. Vielleicht versuch ich mal den HMC5883L Kompass in Verbindung mit dem Beschleunigungssensor. Vielleicht hat der ja weniger Fehlerabweichung...

Ich hoffe ihr habt verstanden, was ich oben geschrieben hab...^^

Für diejenigen die es nicht verstanden haben:
Mit relativ hoher Warscheinlichkeit funktioniert der Filter und die erste Version des HTs könnte fertig sein.
 
der-Frickler

der-Frickler

Fricklomane
#138
#138
Rangarid hat gesagt.:
Wenn man mal bedenkt, dass ein Servo 8bit auflösung hat können 256 Schritte im Servo durchgeführt werden.
Zum Vergrößern anklicken....
Ein analog Servo hat erstmal keinen digitale Auflösung, da PPM im Prinzip Analog ist und die Signallänge mit dem analogen Poti-Wert im Servo zu einem Analogen Stellwert umgesetzt wird.
Deine 2.4er Funke macht aus dem PPM ein digitales Signal und das wird hoffentlich mehr 8-bit haben.
 
R

RVB

Erfahrener Benutzer
#140
#140
@Rangarid:
Also, ich komm gerad garnicht mit: du gibst doch Werte an die Servos aus, wieso misst du die? Ich dachte, du misst die Sensoren und gibst an die Servos aus?

edit:
ich glaub, ich habs jetzt: du misst den ppm-Ausgang und dessen jitter mit nem Oszi und gehst davon aus, wenn der jitter klein genug ist, merkt das Servo das garnicht. Filterst du jetzt dein Ausgangssignal oder die Werte vom Sensor?
Die Idee mit der Auflösung ist vielleicht gar nicht schlecht, auch wenn der-Frickler recht hat, dass das ja analog ist; trotzdem könntest den Ausgang künstlich "digitalisieren" mit einer Auflösung, die du im ppm gut realisieren kannst oder gradweise. Dann müsste die Bewegung auch ruhiger werden.
Und 1° sollte für den Zweck wohl reichen.
 
Um antworten zu können musst du eingeloggt sein.
FPV1

Banggood

Oben Unten