sistema - Precisión del acelerómetro Android(navegación inercial)
sensor de orientacion (6)
Estaba buscando la implementación de un sistema de navegación inercial para un teléfono Android, que me parece difícil debido a la precisión del acelerómetro y la fluctuación constante de las lecturas.
Para empezar, puse el teléfono en una superficie plana y tomé muestras de 1000 acelerómetros en las direcciones X e Y (paralelas a la mesa, para que la gravedad no 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 volviéndolo a colocar sobre la mesa y probando 5000 lecturas del acelerómetro en las direcciones X e Y. Me esperaba, dada la calibración, que estas aceleraciones deberían sumar hasta 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 (un promedio de alrededor de 10 en cada eje).
Me doy cuenta sin ver mi código que 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?
El acelerómetro 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 producción se cuantizará en términos de estos "cubos" y estaría saltando alrededor de un conjunto de valores.
Para calibrar un acelerómetro Android, necesita muestrear mucho más de 1000 puntos y encontrar el "modo" alrededor del cual el acelerómetro está fluctuando. Luego, encuentre la cantidad de puntos digitales según la cantidad de salida fluctúa y utilícela para su filtrado.
Recomiendo el filtrado de Kalman una vez que obtienes el modo y la fluctuación +/-.
Me doy cuenta de que esto es bastante antiguo, pero el tema que nos ocupa 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 debida a la gravedad, que es aproximadamente de 9.80665 m/s2 , dando los 10 que está viendo. Los sensores son inexactos, ¡pero no son TAN inexactos! Vea here algunos enlaces útiles e información sobre el sensor que puede estar buscando.
No estoy seguro de cuán grande es su compensación, porque olvidó 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, tratar de calcular a destiempo usando el acelerómetro lo va a someter a muchos errores compuestos. De lo contrario, el acelerómetro debería 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.
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 este video.
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, he encontrado que estos son útiles:
Localización y seguimiento en interiores basados en RSSI utilizando Smoman de Sigma-Point Kalman
Seguimiento de peatones con sensores inerciales montados en el calzado
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 reales o cómo convertirlas en una buena aplicación para Android.
Una pregunta similar es this .
ACTUALIZAR:
Aparentemente hay una versión más nueva que la anterior, Oliver J. Woodman, "Una introducción a la navegación inercial", su tesis doctoral:
Solo estoy pensando en voz alta, y aún no he jugado con un API de acelerómetro Android, así que tengan paciencia conmigo.
Antes que nada, tradicionalmente, para obtener la navegación de los acelerómetros necesitarías 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 suponga que el dispositivo nunca cambia su actitud, lo que sería bastante limitante. Nadie lee los TDS de todos modos.
Ah, y sabes que el INS se desplaza con la rotación de la Tierra, ¿verdad? Así que ahí está eso también. Una hora más tarde, estás misteriosamente subiendo en una pendiente de 15 ° hacia el espacio. Eso es suponiendo que tengas un INS capaz de mantener la ubicación durante tanto tiempo, lo que un teléfono aún no puede hacer.
Una mejor forma 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 de repente a 3 cuadras de distancia porque te acercas 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 de eso. Como semanas vale la pena. Compárelo con datos de GPS buenos (me refiero realmente buenos) y use datamining para establecer una correlación de tendencias entre los datos del acelerómetro y los datos de GPS conocidos. (Sugerencia: querrá consultar el almanaque del GPS por días con buena geometría y muchos satélites. Algunos días puede 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 su teléfono en el bolsillo, los datos del acelerómetro registran un patrón muy específico. Con base en la datamining, estableces un perfil para ese dispositivo, con ese usuario, y qué tipo de velocidad representa ese patrón cuando tenía datos de GPS para ir junto con él. Debería poder detectar giros, subir escaleras, sentarse (calibración a 0 tiempo de velocidad) y varias otras tareas. La forma en que se sostenga el teléfono necesitaría ser tratada como entradas de datos separadas por completo. Huelo una red neuronal que se utiliza para hacer la extracción 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 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 sea completamente ciego, ya que solo poner un teléfono en el bolsillo podría 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 una gran cantidad de 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 dejaste de caminar, y la deriva posicional no se perpetuará. Sabe que estás parado en base a datos históricos. Los sistemas tradicionales de INS no tienen esta característica. La deriva se perpetúa en todas las mediciones y compuestos futuros de forma exponencial. La exactitud 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 debería tener su propio perfil. Son muchos datos y muchos cálculos. Todo el mundo camina a diferentes velocidades, con diferentes pasos, y coloca sus teléfonos en diferentes bolsillos, etc. Seguramente, para implementar esto en el mundo real, sería necesario controlar los números en el lado del servidor.
Si utilizó el GPS para la línea de base inicial, parte del problema es que el GPS tiende a tener sus propias migraciones a lo largo del tiempo, pero no son perpetuadores. Coloque un receptor en una ubicación y registre los datos. Si no hay correcciones 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. En realidad, podrías tener mejor suerte con un sistema RTK de metro en una mochila para, al menos, bajar el algoritmo de la ANN.
Seguirás teniendo un desplazamiento angular con el INS usando mi método. Esto es un problema. Pero, si fue tan lejos para construir una ANN para verter durante semanas el valor de GPS y datos de INS entre n usuarios, y en realidad lo hizo funcionar hasta este punto, obviamente no le importan los big data hasta el momento. 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, subir escaleras, y no hacer cosas alocadas como caminar por las autopistas, a través de las paredes o desde los 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 donde se esperaría que las personas caminen. Es una apuesta bastante segura que si el usuario comienza a subir las escaleras, está en la misma base de las escaleras que la persona que tenía delante. Después de 1000 iteraciones y algunos ajustes por mínimos cuadrados, su base de datos sabe muy bien dónde están esas escaleras con gran precisión. Ahora puede corregir la deriva angular y la ubicación a medida que la persona comienza a caminar. Cuando ella golpea esas escaleras, o baja esa sala, o viaja por una acera, cualquier deriva puede ser corregida. 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 para asignar sectores que son 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 memoria tomando cada vuelta, iluminando donde 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 recibido peso alguno. Las áreas de mayor tráfico tienen una resolución más alta. Básicamente, terminarías con un mapa de todos lados y lo usarías como modelo de predicción.
No me sorprendería si pudiera determinar qué asiento tomó una persona en un teatro con este método. Dado que hay suficientes usuarios yendo al teatro, y con suficiente resolución, tendrías que mapear los datos de cada fila del teatro, y qué ancho tiene cada fila. Cuantas más personas visitan un lugar, mayor es la fidelidad con la que se puede 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 hago geek con esto.
Usted está asumiendo que las lecturas del acelerómetro en las direcciones X e Y, que en este caso es completamente ruido de hardware, formarán una distribución normal en torno a su promedio. Aparentemente, ese no es el caso.
Una cosa que puedes 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.