Precisión del acelerómetro de Android (navegación inercial)

Question

Estaba buscando implementar un sistema de navegación inercial para un teléfono Android, lo que me doy cuenta de que es difícil dada la precisión del acelerómetro y la fluctuación constante de las lecturas.

Para comenzar, configuré el teléfono en una superficie plana y probé lecturas de 1000 acelerómetro en las direcciones X e Y (paralelo a la mesa, por lo que no hay gravedad que actúe en estas direcciones). Luego promedié estas lecturas y usé este valor para calibrar el teléfono (restando este valor de cada lectura posterior).

Luego probé el sistema colocándolo nuevamente en la mesa y probando lecturas de acelerómetro 5000 en las direcciones X e Y. Esperaría, dada la calibración, que estas aceleraciones deberían sumar 0 (aproximadamente) en cada dirección. Sin embargo, este no es el caso, y la aceleración total de más de 5000 iteraciones no está cerca de 0 (con un promedio de alrededor de 10 en cada eje).

Me doy cuenta sin ver mi código, esto podría ser difícil de responder, pero en un sentido más general ...

¿Es esto simplemente un ejemplo de cuán inexactas son las lecturas del acelerómetro en un teléfono móvil (HTC Desire S), o es más probable que haya cometido algunos errores en mi codificación?

Answer 1

Obtiene la posición integrando la aceleración lineal dos veces pero El error es horrible. Es inútil en la práctica.

Aquí está Una explicación por qué (Google Tech Talk) a 23:20. Recomiendo encarecidamente este video.

No es el ruido del acelerómetro lo que causa el problema, sino el ruido blanco giroscopio, ver subsección 6.2.3 Propagación de errores. (Por cierto, también necesitarás los giroscopios).

En cuanto al posicionamiento interior, los he encontrado útiles:

Localización y seguimiento interior con sede en RSSI utilizando Sigma-Point Kalman Smoothers

Seguimiento de peatones con sensores de inercia montados en zapatos

Mejorar el rendimiento de los pedómetros utilizando un solo acelerómetro

No tengo idea de cómo funcionarían estos métodos en aplicaciones de la vida real o cómo convertirlos en una buena aplicación de Android.

Una pregunta similar es este.

ACTUALIZAR:

Aparentemente hay una versión más nueva que la de Oliver J. Woodman anterior, "Una introducción a la navegación inercial", su tesis doctoral:

Localización peatonal para entornos interiores

Answer 2

Solo estoy pensando en voz alta, y aún no he jugado con una API de acelerómetro de Android, así que tengan paciencia conmigo.

En primer lugar, tradicionalmente, para obtener la navegación de los acelerómetros, necesitaría un acelerómetro de 6 ejes. Necesita aceleraciones en X, Y y Z, pero también rotaciones XR, YR y ZR. Sin los datos de rotación, no tiene suficientes datos para establecer un vector a menos que asuma que el dispositivo nunca cambia su actitud, lo que sería bastante limitante. Nadie lee el TOS de todos modos.

Ah, y sabes que INS se desplaza con la rotación de la Tierra, ¿verdad? Así que eso también está. Una hora después y estás subiendo misteriosamente en una pendiente de 15 ° al espacio. Eso supone que tenía un INS capaz de mantener la ubicación tan larga, lo que un teléfono aún no puede hacer.

Una mejor manera de utilizar acelerómetros, incluso con un acelerómetro de 3 ejes, para la navegación sería vincularse con GPS para calibrar los INS siempre que sea posible. Donde el GPS se queda corto, Ins cumple muy bien. El GPS puede dispararte repentinamente a 3 cuadras de distancia porque te acercaste demasiado a un árbol. INS no es genial, pero al menos sabe que no fue golpeado por un meteorito.

Lo que podría hacer es registrar los datos del acelerómetro de teléfonos y mucho. Como un valor de semanas. Compare con los datos GPS buenos (me refiero a realmente buenos) y use Datamining para establecer la correlación de las tendencias entre los datos del acelerómetro y los datos GPS conocidos. (Consejo profesional: querrá consultar el Almanaque GPS durante días con buena geometría y muchos satélites. Algunos días solo puede tener 4 satélites y eso no es suficiente) lo que puede hacer es encontrar que una persona es una persona que una persona está caminando con su teléfono en su bolsillo, los datos del acelerómetro registran un patrón muy específico. Según la data de Aymining, establece un perfil para ese dispositivo, con ese usuario, y qué tipo de velocidad representa ese patrón cuando tenía datos GPS para acompañarlo. Debería poder detectar vueltas, subir escaleras, sentarse (¡calibración a 0 tiempo de velocidad!) Y varias otras tareas. La forma en que se retiene el teléfono necesitaría ser tratado como entradas de datos separadas por completo. Huelo una red neuronal que se utiliza para hacer la minería de datos. Algo ciego a lo que significan las entradas, en otras palabras. El algoritmo solo buscaría tendencias en los patrones, y realmente no prestaría atención a las mediciones reales de los INS. Todo lo que sabría es 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. Y movería la pieza hacia adelante en consecuencia. Es importante que esté completamente ciego, porque simplemente poner un teléfono en su bolsillo puede orientarse en una de 4 orientaciones diferentes, y 8 si cambia de bolsillos. Y también hay muchas maneras de sostener su teléfono. Estamos hablando de muchos datos aquí.

Obviamente, todavía tendrás mucha deriva, pero creo que tendrías mejor suerte de esta manera porque el dispositivo sabrá cuándo dejó de caminar, y la deriva posicional no será una perpetuación. Sabe que estás quedado quieto en base a datos históricos. Los sistemas INS tradicionales no tienen esta característica. La deriva perpetúa a todas las mediciones y compuestos futuros exponencialmente. La precisión impía, o tener una navegación secundaria para verificar a intervalos regulares, es absolutamente vital con los INS tradicionales.

Cada dispositivo, y cada persona tendría que tener su propio perfil. Son muchos datos y muchos cálculos. Todos caminan diferentes velocidades, con diferentes pasos, y coloca sus teléfonos en diferentes bolsillos, etc. Seguramente implementar esto en el mundo real requeriría que el número de números se maneje del lado del servidor.

Si usó GPS para la línea de base inicial, parte del problema, hay GPS, tiende a tener sus propias migraciones con el tiempo, pero son errores no perpetuantes. Sienta un receptor en una ubicación y registre los datos. Si no hay correcciones WAAS, puede obtener fácilmente las correcciones de ubicación a la deriva en direcciones aleatorias a los 100 pies a su alrededor. Con Waas, tal vez hasta 6 pies. De hecho, es posible que tenga mejor suerte con un sistema RTK subméter en una mochila para al menos reducir el algoritmo de ANN.

Todavía tendrá una deriva angular con el INS utilizando mi método. Esto es un problema. Pero, si llegó tan lejos para construir una ANN para verter durante semanas de datos de GP e INS entre los usuarios de N, y en realidad lo hizo funcionar hasta este punto, obviamente no le importa Big Data hasta ahora. Siga por ese camino y use más datos para ayudar a resolver la deriva angular: las personas son criaturas de hábito. Hacemos las mismas cosas como caminar en las aceras, a través de puertas, escaleras arriba, y no hacer cosas locas como caminar por las autopistas, a través de las paredes o los balcones.

Entonces, digamos que está tomando una página de Big Brother y comience a almacenar datos sobre a dónde va la gente. Puede comenzar a mapear donde se espera que las personas caminen. Es una apuesta bastante segura de que si el usuario comienza a subir escaleras, está en la misma base de escaleras que la persona antes que ella caminó. Después de 1000 iteraciones y algunos ajustes de mínimos cuadrados, su base de datos sabe dónde están esas escaleras con gran precisión. Ahora puede corregir la deriva angular y la ubicación cuando la persona comienza a caminar. Cuando ella llega a esas escaleras, o levanta esa sala, o viaja por una acera, cualquier deriva puede corregirse. Su base de datos contendría sectores que están ponderados por la probabilidad de que una persona camine allí, o que este usuario haya caminado allí en el pasado. Las bases de datos espaciales están optimizadas para esto utilizando divide and conquer solo asignar sectores que sean significativos. Sería como esos proyectos del MIT donde el robot equipado con láser comienza con una imagen negra, y pinta el laberinto en la memoria tomando cada turno, iluminando dónde están todas las paredes.

Las áreas de alto tráfico obtendrían pesos más altos, y las áreas en las que nadie ha tenido 0 peso. Las áreas de tráfico más altas tienen una mayor resolución. Básicamente, terminaría con un mapa de todas partes que cualquiera lo haya estado y lo use como modelo de predicción.

No me sorprendería si pudiera determinar qué asiento tomó una persona en un teatro utilizando este método. Dado suficientes usuarios que van al teatro y suficiente resolución, tendría datos mapeando cada fila del teatro y cuán amplia es cada fila. Cuantas más personas visiten una ubicación, más fidelidad con la que podría predecir que se encuentra esa persona.

Además, le recomiendo que obtenga una suscripción (gratuita) a la revista GPS World si está interesado en la investigación actual sobre este tipo de cosas. Todos los meses me salgo con él.

Answer 3

No estoy seguro de lo bueno que es tu compensación, porque olvidaste incluir unidades. ("Alrededor de 10 en cada eje" no dice mucho.: P) Dicho esto, todavía es probable que se deba a la inexactitud en el hardware.

El acelerómetro está bien para cosas como determinar la orientación del teléfono en relación con la gravedad, o detectar gestos (sacudiendo o golpeando el teléfono, etc.)

Sin embargo, tratar de hacer un cálculo muerto usando el acelerómetro lo someterá a mucho error compuesto. El acelerómetro necesitaría ser increíblemente preciso de otra manera, y este no es un caso de uso común, por lo que dudo que los fabricantes de hardware lo optimicen.

Answer 4

El acelerómetro de Android es digital, muestra la aceleración utilizando el mismo número de "cubos", digamos que hay 256 cubos y el acelerómetro es capaz de detectar de -2g a +2g. Esto significa que su salida se cuantificaría en términos de estos "cubos" y saltaría alrededor de algún conjunto de valores.

Para calibrar un acelerómetro de Android, debe probar muchos más de 1000 puntos y encontrar el "modo" alrededor del cual el acelerómetro está fluctuando. Luego encuentre el número de puntos digitales por cuánto fluctúa la salida y úselo para su filtrado.

Recomiendo el filtrado de Kalman una vez que obtenga el modo y la fluctuación +/-.

Answer 5

Me doy cuenta de que esto es bastante antiguo, pero el problema en cuestión no se aborda en ninguna de las respuestas dadas.

Lo que está viendo es la aceleración lineal del dispositivo, incluido el efecto de la gravedad. Si coloca el teléfono en una superficie plana, el sensor informará la aceleración debido a la gravedad que es aproximadamente 9.80665 m/s2, por lo tanto, dando los 10 que estás viendo. Los sensores son inexactos, ¡pero no son tan inexactos! Ver aquí Para algunos enlaces e información útiles sobre el sensor que puede estar después.

Answer 6

Está suponiendo que las lecturas del acelerómetro en las direcciones X e Y, que en este caso son completamente ruido de hardware, formarían una distribución normal en torno a su promedio. Aparentemente, ese no es el caso.

Una cosa que puede probar es trazar estos valores en un gráfico y ver si surge algún patrón. Si no, el ruido es estadísticamente aleatorio y no se puede calibrar contra, al menos para su hardware de teléfono en particular.