Hallo derseitzer
ja eine Animation ist sicher gut und wie erwähnt eventuell wäre ein Filtern der "Ungenauigkeiten" ok.
Und noch einmal: Das Abgreifen der Werte X,Y,Z ist in den Emba Beispielen sehr schlecht "gelöst". Wenn du zuerst X abfragst, dann Y, dann Z, dann stammen diese drei Werte nicht unbedingt aus der gleichen Messung [nicht aus dem gleichen SensorEvent].
Ich habe rasch mit meinem Nexu10 getestet: Wenn ich die Werte X,Y,Z alle 0.1sec der Reihe nach abgreife, also zum Beispiel
Code:
... := OrientationSensor1.Sensor.TiltX;
... := OrientationSensor1.Sensor.TiltY;
... := OrientationSensor1.Sensor.TiltZ;
dann stammen diese Werte bei meinem Gerät nur in ca. 22%* aller Fälle aus der gleichen Messung. Wenn du also das Gerät bewegst, dann ist dieser Umstand der weit grösste Fehlerfaktor.
: 78%* aller ermittelten Lagevektoren sind dann schlicht falsch. Eine Drohne oder ähnliches Gerät solltest du mit solchen Daten nicht steuern... wenn du's doch tun willst, dann
[*Der ermittelte Wert hängt natürlich ab vom Timerintervall und von der Frequenz, mit welcher des Sensor Daten z.V. stellt.]
Besser: Die Vektoren aus dem SensorEvent auslesen. Dann stammen X,Y,Z aus der gleichen Messung.
Ein Beispiel für diese falsche Art der Abfrage: Wenn du einen Sensor hast, welcher die Lage im R^2 ermitteln kann und sich dein Gerät entlang y=x bewegt, dann durchläuft dein Gerät Positionen (t,t), t aus R. Dein Sensor ermittelt korrekt ..., m(n)=(3.232,3.232), m(n+1)=(6.902,6.902),.... wenn nun in deinem Programm in 78% aller Fälle der Wert für x aus Messung n stammt und der Wert von y aus m(n+1) (oder gar einer späteren Messung), dann hättest du mit deinem Programm in 78% aller Fälle eine komplett falsche Position (3.232,6.902) im Schilf ermittelt, obschon der Sensor absolut korrekte Werte meldet. [Das führt natürlich zu Ruckeln... hoffentlich werten Tesla und Co solche Dinge anders aus...]