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


109

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?


1
webvr-polyfill es una gran fuente de inspiración: github.com/borismus/webvr-polyfill/tree/master/src mira cómo rellenan un sensor de realidad virtual
SC

Respuestas:


128

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


2
Me doy cuenta de que esto fue hace mucho tiempo, pero tengo una pregunta de seguimiento. La cámara en Android JB tiene una función de 'panorama', que le permite tomar una foto panorámica moviendo el teléfono, ya sea girándolo o moviéndolo linealmente a lo largo de un eje. Para hacer esto, tiene que rastrear la posición del teléfono con relativa precisión, al menos mejor que el error de 20 cm / s mencionado en el video que enlaza esta respuesta. ¿Cómo lo hace? ¿Tiene alguna forma de mejorar la calidad del seguimiento inercial? ¿O utiliza un procesamiento de imágenes inteligente para hacerlo usando solo la cámara?
Tom

1
@Tom Creo que lo último, el teléfono concatena las imágenes mediante algoritmos de procesamiento de imágenes. ¿Qué te hace pensar que el teléfono tiene que rastrear su posición para producir una imagen panorámica? Era posible hacerlo con cámaras ordinarias en los años 90 y claramente, no teníamos acelerómetros en las cámaras en ese entonces :) Por supuesto, las imágenes se concatenaron en una PC ordinaria. Pero no necesita la posición para esto, los algoritmos de procesamiento de imágenes son suficientes. Espero que esto ayude.
Ali

Es bastante diferente al antiguo trabajo de tomar algunas fotos manualmente y luego coserlas más tarde. De alguna manera rastrea su posición en tiempo real. Es un poco difícil de explicar sin demostrarlo. No es necesario que tome fotografías manualmente: el teléfono decide cuándo se ha alejado lo suficiente para tomar otra. Mientras estás tomando las fotos, te muestra una pequeña barra en la parte inferior con una vista previa del panorama. Si apunta la cámara demasiado hacia abajo (por ejemplo), comienza a emitir un pitido y muestra una flecha hacia arriba para indicarle que debe moverla hacia arriba.
Tom

2
En realidad, parece utilizar el procesamiento de imágenes: iniciar un panorama y luego agitar la mano frente a la cámara confundirá bastante su sistema de seguimiento de posición.
Tom

@Tom OK. Creo que utiliza principalmente procesamiento de imágenes (como también lo sugiere su último comentario), pero es probable que se combine con el seguimiento de la orientación (pero no la posición).
Ali

19

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.


"Sería conectarlo al GPS para calibrar el INS siempre que sea posible. Donde el GPS se queda corto, el INS complementa muy bien". Para esto es para lo que es el filtrado de Kalman, según tengo entendido. Combina las fortalezas de cada método para cancelar las debilidades del otro
endolito

8

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.


Gracias por la respuesta. Los acelerómetros leen alrededor de -0.8 ms ^ -2 en los ejes X e Y cuando están estacionarios, así que usé esto como mi compensación. Por el bit "Alrededor de 10", quise decir que más de 5000 iteraciones, sumando cada una de las aceleraciones en un solo eje del sensor no totaliza aproximadamente 0 ms ^ -2 (como lo haría si fluctuara uniformemente por encima y por debajo del desplazamiento valor), pero en cambio tendió a registrar una aceleración más en una dirección, que después de la doble integración para encontrar la posición, resultó como el teléfono moviéndose alrededor de 3 metros en un minuto.
woodstock365

+1 para el uso del término de navegación aeronáutica, "navegación a estima". Aunque la navegación por estima se aplicaría mejor a la navegación con una cámara que con un INS.
RyanJMcGowan

7

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 +/-.


1
Estaba buscando métodos de calibración. Parece que tu sugerencia es lo que necesito. Solo necesito confirmar. Una vez que encuentre el modo, digamos que es 0.5. No obtuve el mensaje "Luego, busque el número de puntos digitales por cuánto fluctúa la salida y utilícelo para el filtrado". ¿Podría explicarlo más?
Nazerke

1
Digamos que su acelerómetro tiene 256 puntos de salida y fluctúa 0.015m / s ^ 2 entre lecturas. Cuando coloca su dispositivo sobre la mesa, su salida puede fluctuar en múltiplos pares de 0.015 m / s ^ 2. Digamos que obtiene una lectura de 0 +/- (X * 0.015). Necesitas encontrar X (que sería un número par). Por ejemplo, mi X puede ser 3. En este caso, ignoraría los cambios en la lectura del acelerómetro que sean inferiores a 0.045 m / s ^ 2
Alex Stone

así que los acelerómetros de los teléfonos Android no son tan buenos todavía ... ¿correcto?
Techsin

4

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.


17
No, creo que ha leído mal la pregunta: "... lecturas en las direcciones X e Y (paralelas a la mesa, por lo que no hay gravedad que actúe en estas direcciones)". El 9,8 / s2 estaría en el eje Z.
tetera 7

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.