Precisión del acelerómetro de Android (navegación inercial)
Estaba pensando en 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 fluctuación constante de las lecturas.
Para empezar, coloqué el teléfono sobre 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 no actúa la gravedad 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 sobre la mesa y tomando muestras de 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 en 5000 iteraciones no está ni cerca de 0 (con un promedio de 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 imprecisas 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 la 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 del por qué (Google Tech Talk) a las 23:20 . Recomiendo mucho este vídeo.
No es el ruido del acelerómetro el que causa el problema sino el ruido blanco del giroscopio ; consulte la subsección 6.2.3 Propagación de errores. (Por cierto, también necesitarás los giroscopios).
En cuanto al posicionamiento en interiores, estos me han resultado útiles:
Localización y seguimiento en interiores basados en RSSI utilizando Sigma-Point Kalman Smoothers
Seguimiento de peatones con sensores inerciales montados en zapatas
Mejora del rendimiento de los podómetros mediante un único 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 hay una versión más nueva que la anterior de Oliver J. Woodman, "Una introducción a la navegación inercial", su tesis doctoral:
Localización de peatones 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.
En primer lugar, tradicionalmente, para obtener navegación mediante acelerómetros se 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 el INS se desplaza con la rotación de la Tierra, ¿verdad? Entonces está eso también. Una hora más tarde, misteriosamente estás subiendo hacia el espacio por una pendiente de 15°. Eso suponiendo que tuviera un INS capaz de mantener la ubicación durante tanto tiempo, algo 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 conectar el GPS para calibrar el INS siempre que sea posible. Cuando el GPS se queda corto, el INS lo complementa muy bien. El GPS puede dispararte repentinamente a 3 cuadras de distancia porque te acercaste demasiado a un árbol. El INS no es genial, pero al menos sabe que no fuiste alcanzado por un meteorito.
Lo que podría hacer es registrar los datos del acelerómetro del teléfono, y muchos más. Como semanas que valen. Compárelo con datos de GPS buenos (quiero decir realmente buenos) y utilice la minería de datos para establecer una correlación de tendencias entre los datos del acelerómetro y los datos de GPS conocidos. (Consejo profesional: querrás consultar el almanaque GPS para ver los días con buena geometría y muchos satélites. Algunos días es posible que solo tengas 4 satélites y eso no es suficiente) Lo que podrías hacer es encontrar eso cuando una persona camina con el teléfono en el bolsillo, los datos del acelerómetro registran un patrón muy específico. Con base en la extracción 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 para acompañarlo. 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 completamente separadas. Huelo que se utiliza una red neuronal para realizar la extracción de datos. En otras palabras, algo ciego a lo que significan las entradas. El algoritmo solo buscaría tendencias en los patrones y no prestaría atención a las mediciones reales del 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 haría avanzar la pieza en consecuencia. Es importante que sea completamente ciego, porque con solo poner un teléfono en el bolsillo se puede orientar en una de 4 orientaciones diferentes, y 8 si cambias de bolsillo. Y también hay muchas formas de sostener tu teléfono. Estamos hablando de muchos datos aquí.
Obviamente, todavía tendrás mucha desviación, pero creo que tendrás más suerte de esta manera porque el dispositivo sabrá cuándo dejaste de caminar y la deriva posicional no se perpetuará. Sabe que estás parado basándose en datos históricos. Los sistemas INS tradicionales no tienen esta característica. La deriva se perpetúa en todas las mediciones futuras y se agrava exponencialmente. Una 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. Seguramente implementar esto en el mundo real requeriría que los cálculos numéricos se manejaran 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 WAAS, puede obtener fácilmente correcciones de ubicación que se desplazan en direcciones aleatorias a 100 pies a su alrededor. Con WAAS, tal vez hasta 6 pies. De hecho, es posible que tengas más suerte con un sistema RTK submétrico en una mochila para al menos controlar el algoritmo de ANN.
Aún tendrás deriva angular con el INS usando mi método. Esto es un problema. Pero, si fue tan lejos para construir una ANN para distribuir durante semanas datos de GPS e INS entre n usuarios, y realmente la hizo funcionar hasta este punto, obviamente no le importa el big data hasta ahora. Continúe por ese camino y utilice 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 locuras como cruzar autopistas, atravesar paredes o balcones.
Entonces digamos que estás tomando una página de Gran Hermano y comienzas a almacenar datos sobre adónde va la gente. Puede comenzar a mapear por dónde se espera que caminen las personas. Es una apuesta bastante segura que si el usuario comienza a subir escaleras, estará en la misma base de escaleras por la que subió la persona que la precedió. Después de 1000 iteraciones y algunos ajustes de mínimos cuadrados, su base de datos sabe prácticamente 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 llega a esas escaleras, gira por ese pasillo o viaja por una acera, cualquier desviación se puede corregir. Su base de datos contendría sectores ponderados por la probabilidad de que una persona caminara hasta allí, o que este usuario haya caminado hasta allí en el pasado. Las bases de datos espaciales están optimizadas para esto y divide and conquersolo asignan sectores que sean significativos. Sería algo así como esos proyectos del MIT en los que el robot equipado con láser comienza con una imagen negra y pinta el laberinto en la memoria tomando cada vuelta, iluminando dónde están todas las paredes.
Las áreas de mucho tráfico obtendrían ponderaciones más altas y las áreas donde nunca ha estado nadie obtendrían 0 ponderaciones. Las áreas de mayor tráfico tienen mayor resolución. Básicamente, terminarías con un mapa de todos los lugares donde alguien ha estado y lo usarías como modelo de predicción.
No me sorprendería que se pudiera determinar qué asiento ocupó una persona en un cine utilizando este método. Si hubiera suficientes usuarios yendo al cine y suficiente resolución, tendría datos que mapearían cada fila del cine y el ancho de cada fila. Cuanta más gente visite un lugar, mayor será la fidelidad con la que se podrá predecir que se encuentra esa persona.
Además, le recomiendo encarecidamente 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 divierto con eso.
No estoy seguro de qué tan grande es tu compensación porque olvidaste 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 realizar cálculos a estima utilizando el acelerómetro le expondrá a muchos 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.
