web-dev-qa-db-fra.com

Précision de l'accéléromètre Android (navigation inertielle)

Je cherchais à mettre en œuvre un système de navigation inertielle pour un téléphone Android, ce qui est difficile, compte tenu de la précision de l'accéléromètre et de la fluctuation constante des relevés.

Pour commencer, j'ai placé le téléphone sur une surface plane et échantillonné 1 000 lectures de l'accéléromètre dans les directions X et Y (parallèles à la table, donc aucune gravité agissant dans ces directions). J'ai ensuite fait la moyenne de ces lectures et utilisé cette valeur pour calibrer le téléphone (en soustrayant cette valeur de chaque lecture suivante).

J'ai ensuite testé le système en le plaçant à nouveau sur la table et en échantillonnant 5 000 lectures de l'accéléromètre dans les directions X et Y. Compte tenu de l'étalonnage, je m'attendrais à ce que ces accélérations totalisent 0 (environ) dans chaque direction. Cependant, ce n'est pas le cas et l'accélération totale sur 5000 itérations est loin d'être nulle (moyenne d'environ 10 sur chaque axe).

Je réalise que sans voir mon code, il peut être difficile de répondre à cette question, mais dans un sens plus général ...

S'agit-il simplement d'un exemple d'inexactitude des lectures de l'accéléromètre sur un téléphone portable (HTC Desire S), ou est-il plus probable que j'ai commis des erreurs de codage?

98
woodstock365

Vous obtenez la position en intégrant l'accélération linéaire deux fois mais l'erreur est horrible. C'est inutile en pratique.

Voici une explication pourquoi (Google Tech Talk) at 23:20 . Je recommande fortement cette vidéo.

Ce n’est pas le bruit de l’accéléromètre qui cause le problème mais le bruit blanc , voir la sous-section 6.2.3 Propagation des erreurs. (Au fait, vous aurez aussi besoin des gyroscopes.)

En ce qui concerne le positionnement à l'intérieur, j'ai trouvé ceux-ci utiles: 

Localisation et suivi en salle basés sur RSSI à l’aide de Sigma-Point Kalman Smoothers

Suivi des piétons avec des capteurs inertiels montés sur chaussures

Amélioration des performances des podomètres avec un accéléromètre unique

Je ne sais pas du tout comment ces méthodes fonctionneraient dans des applications réelles ou comment les transformer en une belle application Android.

Une question similaire est this .

METTRE À JOUR:

Apparemment, il existe une version plus récente que celle ci-dessus, Oliver J. Woodman, "Une introduction à la navigation par inertie", sa thèse de doctorat:

Localisation des piétons pour les environnements intérieurs

120
Ali

Je ne fais que penser à voix haute et je n'ai pas encore joué avec une API d'accéléromètre Android, alors supportez-moi.

Tout d’abord, traditionnellement, pour obtenir la navigation à partir d’accéléromètres, il fallait un accéléromètre à 6 axes. Vous avez besoin d'accélérations en X, Y et Z, mais aussi de rotations Xr, Yr et Zr. Sans les données de rotation, vous ne disposez pas de suffisamment de données pour établir un vecteur, sauf si vous supposez que le périphérique ne change jamais d'attitude, ce qui serait assez limitatif. De toute façon, personne ne lit le TOS.

Oh, et vous savez que l'INS dérive de la rotation de la terre, n'est-ce pas? Donc, il y a ça aussi. Une heure plus tard, vous montez mystérieusement sur une pente de 15 °. En supposant que vous disposiez d'un INS capable de conserver votre position aussi longtemps, ce qu'un téléphone ne peut pas encore faire.

Une meilleure façon d'utiliser des accéléromètres - même avec un accéléromètre à 3 axes - pour la navigation serait de se connecter au GPS pour calibrer l'INS chaque fois que possible. Là où le GPS manque, l'INS complimente bien. Le GPS peut vous abattre à 3 pâtés de maisons, car vous êtes trop près d'un arbre. INS n'est pas génial, mais au moins, il sait que vous n'avez pas été touché par un météore.

Ce que vous pouvez faire, c'est consigner les données de l'accéléromètre du téléphone, en grande partie. Comme des semaines vaut la peine. Comparez-le avec de bonnes données GPS (très bonnes) et utilisez la datamining pour établir une corrélation des tendances entre les données de l'accéléromètre et les données GPS connues. (Conseil pro: vous voudrez vérifier l’almanach GPS pendant des jours avec une bonne géométrie et beaucoup de satellites. Certains jours, vous n’avez que 4 satellites et c’est trop peu) Ce que vous pourrez peut-être faire est de le trouver marche avec son téléphone dans sa poche, les données de l’accéléromètre enregistrent un schéma très spécifique. En fonction de la datamining, vous établissez un profil pour ce périphérique, avec cet utilisateur, et le type de vitesse que ce modèle représente lorsqu'il dispose de données GPS. Vous devriez pouvoir détecter les virages, monter les escaliers, vous asseoir (réglage de la vitesse sur 0!) Et diverses autres tâches. La façon dont le téléphone est tenu devrait être traitée comme une entrée de données distincte. Je sens un réseau de neurones utilisé pour l'exploration de données. Quelque chose d'aveugle à ce que signifient les entrées, en d'autres termes. L'algorithme ne chercherait que les tendances dans les modèles, sans vraiment prêter attention aux mesures réelles de l'INS. Tout ce qu'il sait, c'est historically, when this pattern occurs, the device is traveling and 2.72 m/s X, 0.17m/s Y, 0.01m/s Z, so the device must be doing that now. Et cela ferait avancer la pièce en conséquence. Il est important que ce soit complètement aveugle, car il suffit de placer un téléphone dans votre poche pour l’orienter dans l’une des 4 orientations possibles, et 8 si vous changez de poche. Et il existe de nombreuses façons de tenir votre téléphone. Nous parlons beaucoup de données ici.

Vous aurez évidemment encore beaucoup de dérive, mais je pense que vous auriez plus de chance de cette façon, car le dispositif saura quand vous avez arrêté de marcher et la dérive de position ne sera pas perpétuelle. Il sait que vous restez immobile sur la base de données historiques. Les systèmes INS traditionnels ne possèdent pas cette fonctionnalité. La dérive se perpétue à toutes les mesures futures et les composés de manière exponentielle. Une précision imparable, ou une navigation secondaire à vérifier à intervalles réguliers, est absolument essentielle avec les INS traditionnels.

Chaque appareil, et chaque personne devrait avoir son propre profil. C'est beaucoup de données et beaucoup de calculs. Tout le monde marche à des vitesses différentes, avec des étapes différentes, et met son téléphone dans des poches différentes, etc. Pour implémenter cela dans le monde réel, il faudrait que le traitement des chiffres soit géré côté serveur.

Si vous avez utilisé le GPS pour la ligne de base initiale, une partie du problème réside dans le fait que le GPS a tendance à avoir ses propres migrations au fil du temps, mais ce sont des erreurs non perpétuelles. Asseyez un récepteur dans un endroit et enregistrez les données. S'il n'y a pas de corrections WAAS, vous pouvez facilement obtenir des repères d'emplacement dérivant dans des directions aléatoires à 100 pieds autour de vous. Avec WAAS, peut-être jusqu'à 6 pieds. Vous pourriez en fait avoir plus de chance avec un système sous-mètre RTK sur un sac à dos pour au moins obtenir l'algorithme de ANN.

Vous aurez toujours une dérive angulaire avec l'INS en utilisant ma méthode. C'est un problème. Mais, si vous êtes allé jusqu'à créer un ANN qui transmettrait des données GPS et INS sur plusieurs semaines à n utilisateurs, et que vous l'ayez réellement fait fonctionner jusqu'à présent, le Big Data ne vous dérange évidemment pas jusqu'à présent. Continuez sur cette voie et utilisez plus de données pour aider à résoudre la dérive angulaire: Les gens sont des créatures d'habitude. Nous faisons à peu près les mêmes choses, comme marcher sur les trottoirs, par les portes, monter les escaliers, et pas des choses folles, comme traverser des autoroutes, des murs ou des balcons.Supposons que vous preniez une page de Big Brother et que vous commenciez à stocker des données sur l’orientation des personnes. Vous pouvez commencer à cartographier les endroits où les gens sont censés marcher. Il y a fort à parier que si l'utilisateur commence à monter des escaliers, il se trouve au même niveau que celui qui l'a précédée. Après 1000 itérations et quelques ajustements des moindres carrés, votre base de données sait à peu près où se trouvent ces escaliers avec une grande précision. Maintenant, vous pouvez corriger la dérive angulaire et l'emplacement lorsque la personne commence à marcher. Lorsqu'elle heurte ces escaliers, tourne dans cette salle ou descend d'un trottoir, toute dérive peut être corrigée. Votre base de données contiendrait des secteurs pondérés par la probabilité qu'une personne y marche, ou que cet utilisateur l'ait déjà visitée. Les bases de données spatiales sont optimisées pour cela à l'aide de divide and conquer afin d'attribuer uniquement les secteurs significatifs. Ce serait un peu comme ces projets MIT dans lesquels le robot équipé d'un laser commence avec une image en noir et peint le labyrinthe en mémoire en prenant chaque virage en éclairant l'emplacement de tous les murs.

Les zones à fort trafic recevraient des poids plus élevés, et les zones dans lesquelles personne n'a jamais été pesé à zéro. Les zones à trafic élevé ont une résolution plus élevée. Vous obtiendriez essentiellement une carte de tous les endroits où quiconque se trouve et l’utiliseriez comme modèle de prévision.

Je ne serais pas surpris si vous pouviez déterminer quel siège une personne a pris dans un théâtre en utilisant cette méthode. Si vous avez assez d'utilisateurs et que vous avez suffisamment de résolution, vous obtiendrez des données correspondant à chaque rangée du théâtre et à leur largeur. Plus le nombre de personnes visitant un lieu est élevé, plus la fidélité avec laquelle vous pouvez prédire que cette personne est localisée est élevée.

De plus, je vous recommande vivement de vous abonner (gratuitement) au magazine GPS World si vous êtes intéressé par les recherches en cours dans ce domaine. Chaque mois, je fais du geek avec.

Also, I highly recommend you get a (free) subscription to GPS World magazine if you're interested in the current research into this sort of stuff. Every month I geek out with it.

17
RyanJMcGowan

Je ne sais pas à quel point votre compensation est excellente, car vous avez oublié d'inclure les unités. ("Environ 10 sur chaque axe" ne dit pas grand chose.: P) Cela dit, cela reste probablement dû à une imprécision du matériel.

L'accéléromètre convient parfaitement, par exemple pour déterminer l'orientation du téléphone par rapport à la gravité ou pour détecter des gestes (secouer ou cogner le téléphone, etc.).

Cependant, essayer de faire le calcul à l'aide de l'accéléromètre va vous exposer à de nombreuses erreurs complexes. Sinon, l'accéléromètre devrait être incroyablement précis, et comme ce n'est pas un cas d'utilisation courant, je doute que les fabricants de matériel l'optimisent.

8
Trevor Johns

L'accéléromètre Android est numérique, il échantillonne l'accélération en utilisant le même nombre de "seaux". Disons qu'il y a 256 seaux et que l'accéléromètre est capable de détecter de -2g à + 2g. Cela signifie que votre sortie serait quantifiée en termes de ces "compartiments" et sauterait autour d'un ensemble de valeurs.

Pour calibrer un accéléromètre Android, vous devez échantillonner beaucoup plus de 1000 points et trouver le "mode" autour duquel l'accéléromètre fluctue. Recherchez ensuite le nombre de points numériques en fonction de la fluctuation de la sortie et utilisez-le pour votre filtrage.

Je recommande le filtrage de Kalman une fois que vous obtenez le mode et la fluctuation +/-.

7
Alex Stone

Je me rends compte que c'est assez ancien, mais le problème en question n'est traité dans AUCUNE des réponses données.

Ce que vous voyez, c'est l'accélération linéaire de l'appareil, y compris l'effet de la gravité. Si vous posez le téléphone sur une surface plane, le capteur signalera l’accélération due à la gravité qui est approximativement de 9.80665 m/s2, donnant ainsi les 10 que vous voyez. Les capteurs sont inexacts, mais ils ne sont pas si inexacts! Voir ici pour des liens utiles et des informations sur le capteur que vous recherchez peut-être.

5
Simon O'Hanlon

Vous supposez que les lectures de l'accéléromètre dans les directions X et Y, qui dans ce cas sont entièrement du bruit matériel, formeraient une distribution normale autour de votre moyenne. Apparemment, ce n'est pas le cas.

Une chose que vous pouvez essayer est de tracer ces valeurs sur un graphique et de voir si un motif apparaît. Sinon, le bruit est statistiquement aléatoire et ne peut pas être calibré - du moins pour votre matériel téléphonique.

0
Hai Phan