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

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

Para empezar, puse el teléfono en una superficie plana y tomé muestras de 1000 lecturas del acelerómetro en las direcciones X e Y (paralelas a la mesa, por lo que la gravedad no actúa en estas direcciones). Luego promedié estas lecturas y usé este valor para calibrar el teléfono (restando este valor de cada lectura subsiguiente).

Luego probé el sistema colocándolo nuevamente sobre la mesa y probando 5000 lecturas del acelerómetro en las direcciones X e Y. Esperaría, dada la calibración, que estas aceleraciones sumen 0 (aproximadamente) en cada dirección. Sin embargo, este no es el caso, y la aceleración total durante 5000 iteraciones no se acerca a 0 (promediando alrededor de 10 en cada eje).

Me doy cuenta de que 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?

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

Aquí hay una explicación de por qué (Google Tech Talk) a las 23:20 . Recomiendo mucho este video.

No es el ruido del acelerómetro el que causa el problema, sino el ruido blanco del giróscopo , consulte la subsección 6.2.3 Propagación de errores. (Por cierto, también necesitará los giroscopios).

En cuanto al posicionamiento en interiores, he encontrado estos útiles:

Localización y seguimiento de interiores basados ​​en RSSI con suavizadores Kalman Sigma-Point

Seguimiento de peatones con sensores inerciales montados en zapatos

Mejora del rendimiento de los podómetros con 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 para Android.

Una pregunta similar es esta .

ACTUALIZAR:

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

Localización peatonal para ambientes interiores

Solo estoy pensando en voz alta y todavía 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 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. De todos modos, nadie lee los TOS.

Ah, y sabes que INS se desplaza con la rotación de la tierra, ¿verdad? Así que también está eso. Una hora más tarde, estás subiendo misteriosamente en una pendiente de 15 ° hacia el espacio. Eso es asumiendo que tenía un INS capaz de mantener la ubicación durante tanto tiempo, 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 conectarlo al GPS para calibrar el INS siempre que sea posible. Donde el GPS se queda corto, INS complementa 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 fuiste golpeado por un meteoro.

Lo que podría hacer es registrar los datos del acelerómetro de los teléfonos, y mucho más. Como semanas. Compárelo con datos GPS buenos (me refiero a realmente buenos) y utilice la extracción de datos para establecer la correlación de tendencias entre los datos del acelerómetro y los datos GPS conocidos. (Consejo profesional: querrá comprobar el almanaque GPS durante días con buena geometría y muchos satélites. Algunos días es posible que solo tenga 4 satélites y eso no es suficiente). Lo que podría hacer es encontrar que cuando una persona está caminando con el teléfono en el bolsillo, los datos del acelerómetro registran un patrón muy específico. Con base en la minería de datos, usted establece un perfil para ese dispositivo, con ese usuario, y qué tipo de velocidad representa ese patrón cuando tenía datos de GPS que lo acompañaban. Debería poder detectar giros, subir escaleras, sentarse (¡calibración al tiempo de velocidad 0! ) y varias otras tareas. La forma en que se sostiene el teléfono debería tratarse como entradas de datos independientes por completo. Huelo una red neuronal que se utiliza para realizar 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 no prestaría realmente atención a las medidas reales del INS. Todo lo que sabría eshistorically, 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 sea completamente ciego, porque con solo poner un teléfono en su bolsillo puede orientarse en una de las 4 orientaciones diferentes, y 8 si cambia de bolsillo. Y también hay muchas formas de sujetar el 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 dejas de caminar y la deriva posicional no se perpetuará. Sabe que estás parado en función de los datos históricos. Los sistemas INS tradicionales no tienen esta función. La deriva se perpetúa en todas las medidas y compuestos futuros de forma exponencial. La precisión impía, o tener una navegación secundaria para verificar a intervalos regulares, es absolutamente vital con el INS tradicional.

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

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

Todavía tendrá una deriva angular con el INS usando mi método. Esto es un problema. Pero, si fue tan lejos para construir un ANN para verter durante semanas datos de GPS e INS entre n usuarios, y realmente lo hizo funcionar hasta este punto, obviamente no le importa el 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ábitos. Prácticamente hacemos las mismas cosas, como caminar por las aceras, atravesar puertas, subir escaleras, y no hacemos cosas locas como cruzar autopistas, paredes o balcones.

Entonces, digamos que está tomando una página de Big Brother y comienza a almacenar datos sobre a dónde van las personas. Puede comenzar a mapear dónde se espera que camine la gente. Es una apuesta bastante segura que si el usuario comienza a subir escaleras, está en la misma base de escaleras que subió la persona antes que ella. Después de 1000 iteraciones y algunos ajustes por mínimos cuadrados, su base de datos sabe prácticamente dónde están esas escaleras con gran precisión. Ahora puede corregir la desviación angular y la ubicación cuando la persona comienza a caminar. Cuando llega a esas escaleras, da vuelta por ese pasillo o baja por una acera, cualquier desviación 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 usandodivide and conquerpara asignar solo los sectores que sean significativos. Sería algo así como esos proyectos del MIT donde el robot equipado con láser comienza con una imagen negra y pinta el laberinto en la memoria dando cada giro, iluminando donde están todas las paredes.

Las áreas de mucho tráfico obtendrían mayor peso, y las áreas donde nadie nunca ha tenido un peso 0. Las áreas de mayor tráfico tienen mayor resolución. Básicamente, terminaría con un mapa de todos los lugares en los que alguien ha estado y lo usaría como modelo de predicción.

No me sorprendería si pudiera determinar qué asiento tomó una persona en un teatro usando este método. Con suficientes usuarios yendo al cine y con suficiente resolución, tendrías un mapeo de datos de cada fila del cine y el ancho de cada fila. Cuantas más personas visiten una ubicación, mayor será la fidelidad con la que podría predecir que esa persona está ubicada.

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 encanta.

No estoy seguro de cuán grande es su compensación, porque se olvidó de incluir unidades. ("Alrededor de 10 en cada eje" no dice mucho.: P) Dicho esto, es probable que se deba a una 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 (sacudir o golpear el teléfono, etc.)

Sin embargo, intentar hacer la navegación a estima con el acelerómetro lo someterá a una gran cantidad de errores compuestos. De lo contrario, el acelerómetro tendría que ser increíblemente preciso, y este no es un caso de uso común, por lo que dudo que los fabricantes de hardware lo estén optimizando.

El acelerómetro de Android es digital, muestra la aceleración usando 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, necesitas muestrear 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 utilícelo para su filtrado.

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

Me doy cuenta de que esto es bastante antiguo, pero el tema 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 sobre una superficie plana, el sensor informará la aceleración debido a la gravedad, que es aproximadamente 9.80665 m/s2, por lo que le dará el 10 que está viendo. Los sensores son inexactos, ¡pero no TAN inexactos! Consulte aquí algunos enlaces útiles e información sobre el sensor que puede estar buscando.

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

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