Obtention du déplacement à partir des données de l'accéléromètre avec le mouvement du cœur
je développe une application de réalité augmentée qui (à l'heure actuelle) veut afficher un cube simple sur une surface, et être en mesure de se déplacer dans l'espace (à la fois en rotation et en déplacement) pour regarder le cube dans tous les différents angles. Le problème de calibrer la caméra ne s'applique pas ici puisque je demande à l'utilisateur de placer l'iPhone sur la surface il veut placer le cube sur et puis appuyez sur un bouton pour réinitialiser l'attitude. Pour trouver la rotation de la caméra est très simple avec le Gyroscope et mouvement du noyau. Je le fais de cette façon:
if (referenceAttitude != nil) {
[attitude multiplyByInverseOfAttitude:referenceAttitude];
}
CMRotationMatrix mat = attitude.rotationMatrix;
GLfloat rotMat[] = {
mat.m11, mat.m21, mat.m31, 0,
mat.m12, mat.m22, mat.m32, 0,
mat.m13, mat.m23, mat.m33, 0,
0, 0, 0, 1
};
glMultMatrixf(rotMat);
Cela fonctionne vraiment bien. Plus de problèmes surgissent de toute façon quand j'essaie de trouver le déplacement dans l'espace lors d'une accélération. L'exemple Apple Teapot avec Core Motion ajoute simplement les valeurs x, y et z du vecteur d'accélération au vecteur de position. Ceci (mis à part le fait qu'il n'a pas beaucoup de sens) a pour résultat de ramener l'objet à sa position initiale après une accélération. (Depuis l'accélération va de de positif à négatif ou vice versa). Ils l'ont fait comme ceci:
translation.x += userAcceleration.x;
translation.y += userAcceleration.y;
translation.z += userAcceleration.z;
Que dois-je faire pour trouver le déplacement de l'accélération dans certains istant? (avec la connaissance de la différence de temps). En regardant d'autres réponses, il semble que je dois intégrer deux fois pour obtenir la vitesse de l'accélération et ensuite la position de la vitesse. Mais il n'y a aucun exemple dans le code, et je ne pense pas que ce soit vraiment nécessaire. En outre, il ya le problème que lorsque l'iPhone est toujours sur un plan, les valeurs d'accéléromètre ne sont pas nulles (il y a du bruit je pense). Combien dois-je filtrer ces valeurs? Suis-je censé filtre?
4 réponses
Cool, Il ya des gens là-bas lutter avec le même problème, il est donc intéressant de passer un certain temps :-)
je suis d'accord avec la déclaration de westsider que j'ai passé quelques semaines d'expérimentation avec différentes approches et a fini par de mauvais résultats. Je suis sûr qu'il n'y aura pas de solution acceptable pour des distances plus grandes ou des mouvements lents d'une durée supérieure à 1 ou 2 secondes. Si vous pouvez vivre avec certaines restrictions comme de petites distances (<10 cm) et un vitesse minimale pour vos mouvements, alors je pense qu'il pourrait y avoir la chance de trouver une solution - aucune garantie du tout. Si c'est le cas, il vous faudra un temps assez difficile de recherche et beaucoup de frustration, mais si vous l'obtenez, il sera très très cool :-) peut-être vous trouvez ces conseils utiles:
tout d'abord pour faciliter les choses, il suffit de regarder un axe E. g x mais considère que la gauche (- x) et la droite (+x) ont une situation représentative.
Oui, vous avez raison, vous intégrer deux fois pour obtenir la position en fonction du temps. Et pour les traitements ultérieurs, vous devez stocker le résultat de la première intégration (== vitesse), car vous en aurez besoin à un stade ultérieur pour l'optimisation. Faites-le très prudemment car chaque petit bogue entraînera d'énormes erreurs après une courte période de temps.
gardez toujours à l'esprit que même une très petite erreur (par exemple <0,1%) augmentera rapidement après avoir fait deux fois l'intégration. Situation sera encore pire après une seconde si vous configurez l'accéléromètre avec disons 50 Hz, c'est-à-dire 50 tics sont traités et la minuscule erreur négligeable dépassera la valeur "vraie". Je recommande fortement de ne pas compter sur la règle trapézoïdale mais D'utiliser au moins Simpson ou un degré plus élevé Newton-Cotes formule.
si vous avez réussi cela, vous devrez garder un oeil sur la mise en place du filtrage de passe basse droite. Je ne peux pas donner une valeur générale, mais en règle générale, en expérimentant des facteurs de filtrage entre 0.2 et 0.2. 0.8 sera un bon point de départ. La bonne valeur dépend de l'analyse de rentabilisation dont vous avez besoin, par exemple quel type de jeu, à quelle vitesse réagir sur les événements, ...
vous avez Maintenant une solution qui fonctionne assez bien dans certaines circonstances et dans un court laps de temps. Mais au bout de quelques secondes, vous allez avoir des problèmes parce que votre objet s'éloigne. Maintenant, vous allez entrer dans la partie difficile de la solution que j'ai échoué à gérer éventuellement dans le avec le temps champ d'application: - (
une approche prometteuse consiste à introduire ce que j'appelle des" forces de synthèse "ou des"forces virtuelles". Il s'agit d'une stratégie pour réagir sur plusieurs mauvaises situations déclenchant l'objet à dériver bien que l'appareil reste fixe (? pas de locuteur natif, je veux dire sans bouger) dans vos mains. Le plus troublant est à une vitesse supérieure à 0 sans accélération. Il s'agit d'un résultat inévitable de la propagation d'erreurs et peut être traité en ralentissant artificiellement cela signifie introduire une décélération virtuelle même s'il n'y a pas de véritable contrepartie. Un exemple très simplifié:
if (vX > 0 && lastAccelerationXTimeStamp > 0.3sec) {
vX *= 0.9;
}
`
Vous aurez besoin d'une combinaison de ces conditions d'apprivoiser la bête. Beaucoup d'essai et d'erreur n'est requis pour obtenir une sensation pour le droit de chemin à faire et ce sera la partie la plus difficile du problème.
Si vous jamais réussi à décrypter le code, pleeeease laissez-moi savoir, je suis très curieux de voir si c'est possible en général ou non: -)
Cheers Kay
lorsque le iPhone 4 était très nouveau, j'ai passé de nombreuses heures à essayer d'obtenir un déplacement précis à l'aide d'accéléromètres et de gyroscopes. Il n'aurait pas dû y avoir beaucoup de préoccupations au sujet de la dérive incrémentielle, car l'appareil n'avait besoin que de déplacer quelques mètres au plus et la collecte de données durait habituellement quelques minutes au plus. Nous avons essayé toutes sortes d'approches et avons même eu l'aide de plusieurs ingénieurs Apple. En fin de compte, il semble que le gyroscope n'était pas à la hauteur de la tâche. C'était bon pour la 3D. orientation mais c'était tout ... encore une fois, selon des ingénieurs très savants.
j'aimerais entendre quelqu'un s'y opposent - parce que l'application n'a jamais vraiment tourné comme nous l'avions espéré, etc.
j'essaie aussi d'obtenir le déplacement sur l'iPhone. Au lieu d'utiliser l'intégration, j'ai utilisé la formule physique de base de d = .5A * T^2 en supposant une vitesse initiale de 0 (on ne dirait pas que vous pouvez supposer une vitesse initiale de 0). Jusqu'à présent, il semble fonctionner assez bien.
mon problème est que j'utilise le deviceMotion.et les valeurs ne sont pas correctes. deviceMotion.la gravité de lecture proche de 0. Des idées? - OK réparé, apparemment deviceMotion.la gravité a des valeurs de x, y et Z. Si vous ne spécifiez pas ce que vous voulez, vous récupérez x (qui devrait être proche de 0).
trouver cette question deux ans plus tard, je viens de trouver un projet AR sur iOS 6 docset nommé pARk , il fournir une capture de déplacement proximale et de calcul à L'aide du Gyroscope, aka CoreMotion.Framework.
je commence à peine à lire le code.
à suivre...