Pregunta

Entonces, he estado luchando con este problema durante algún tiempo, y no he tenido suerte aprovechando la sabiduría de los internets y las publicaciones relacionadas con el tema.

Estoy escribiendo una aplicación de Android que usa el acelerómetro ubicuo, pero parece que estoy obteniendo una cantidad increíble de "ruido" incluso en reposo, y parece que no puedo descubrir cómo lidiar con él, ya que mis lecturas deben ser relativamente preciso. Pensé que tal vez mi teléfono (HTC Incredible) era disfuncional, pero el sensor parece funcionar bien con otros juegos y aplicaciones que he jugado.

He tratado de usar varios "filtros", pero parece que no puedo entenderlos. Entiendo que la gravedad debe tratarse de alguna manera, y tal vez ahí es donde me estoy equivocando. Actualmente he probado esto, adaptado de un Pues contesta, que se refiere a un ejemplo del SDK del iPhone:

                accel[0] = event.values[0] * kFilteringFactor + accel[0] * (1.0f - kFilteringFactor);
                accel[1] = event.values[1] * kFilteringFactor + accel[1] * (1.0f - kFilteringFactor);


                double x = event.values[0] - accel[0];
                double y = event.values[1] - accel[1];

El póster dice que "juegue con" el valor de KfilteringFactor (kFilteringFactor = 0.1f en el ejemplo) hasta que esté satisfecho. Desafortunadamente, todavía parece que tengo mucho ruido, y todo lo que parece hacer es hacer que las lecturas lleguen como decimales pequeños, lo que no me ayuda tanto, y parece hacer que el sensor sea menos sensible. Los centros de matemáticas de mi cerebro también están atrofiados por años de negligencia, por lo que no entiendo completamente cómo funciona este filtro.

¿Alguien puede explicarme con cierto detalle cómo obtener un útil ¿Leyendo del acelerómetro? Un tutorial sucinto sería una ayuda increíble, ya que no he encontrado uno realmente bueno (al menos dirigido a mi nivel de conocimiento). Me frustré porque siento que todo esto debería ser más evidente para mí. Cualquier ayuda o dirección sería muy apreciada y, por supuesto, puedo proporcionar más muestras de mi código si es necesario.

Espero no pedir demasiado ser alimentado con cuchara; No preguntaría a menos que haya estado tratando de imaginarlo por un tiempo. También parece que hay algún interés de otros miembros.

¿Fue útil?

Solución

Para obtener una lectura correcta del acelerómetro, debe usar la velocidad de la ecuación = sqrt (x*x + y*y + z*z). Usando esto, cuando el teléfono esté en reposo, la velocidad será la de la gravedad: 9.8m/s. Entonces, si restas eso (sensorManager.gravity_earth), entonces cuando el teléfono esté en reposo, tendrás una lectura de 0 m/s. En cuanto al ruido, BLRFL podría tener razón sobre acelerómetros baratos, incluso cuando mi teléfono está en reposo, continuamente parpadea algunas fracciones de un metro por segundo. Podrías establecer un umbral pequeño, por ejemplo, 0.4m/s y si la velocidad no pasa por encima de eso, entonces está en reposo.

Otros consejos

Respuesta parcial:

Precisión. Si está buscando una alta precisión, los acelerómetros económicos que encuentre en los teléfonos no cortará la mostaza. A modo de comparación, un sensor de tres ejes adecuado para uso industrial o científico corre hacia el norte de $ 1,500 solo para el sensor; Agregar el hardware para alimentarlo y convertir sus lecturas en algo que una computadora puede usar duplica el precio. El sensor en un teléfono funciona muy por debajo de $ 5 en cantidad.

Ruido. Los sensores baratos son inexactos y la inexactitud se traduce en ruido. Un sensor inexacto que no se mueve no siempre mostrará ceros, mostrará valores a ambos lados dentro de algún rango. Lo mejor que puede hacer es caracterizar el sensor mientras está inmóvil para tener una idea de cuán ruidoso es y usarlo para redondear sus mediciones a una escala menos precisa basada en el error esperado. (En otras palabras, si está dentro de ±X m/s^2 de cero, es seguro decir que el sensor no se mueve, pero no puede estar precisamente seguro porque podría moverse muy lentamente). Tendrá que hacer esto en cada dispositivo, porque no lo hacen Todos usan el mismo acelerómetro y todos se comportan de manera diferente. Supongo que esa es una ventaja que tiene el iPhone: el hardware es prácticamente homogéneo.

Gravedad. Hay alguna discusión en el SensorEvent documentación Acerca de factorizar la gravedad de lo que dice el acelerómetro. Notará que tiene mucha similitud con el código que publicó, excepto que es más claro lo que está haciendo. :-)

Hth.

¿Cómo lidias con la mueca? Alisas los datos. En lugar de mirar la secuencia de valores del sensor como sus valores, los promedia de forma continua, y la nueva secuencia formada se convierte en los valores que usa. Esto mueve cada valor nervioso más cerca del promedio móvil. El promedio necesariamente elimina las variaciones rápidas en los valores adyacentes ... y es la razón por la cual las personas usan el filtrado de aprobación de baja (frecuencia) de terminología ya que los datos que originalmente pueden haber variado mucho por muestra (o tiempo de la unidad) ahora varía más lentamente.

Por ejemplo, en lugar de usar valores 10 6 7 11 7 10, puede promediarlos de muchas maneras. Por ejemplo, podemos calcular el siguiente valor a partir de un peso igual del promedio de ejecución (es decir, de su último punto de datos procesados) con el siguiente punto de datos sin procesar. Usando una mezcla 50-50 para los números anteriores, obtendríamos 10, 8, 7.5, 9.25, 8.125, 9.0675. Esta nueva secuencia, nuestros datos procesados, se utilizarían en lugar de los datos ruidosos. Y podríamos usar una mezcla diferente de 50-50, por supuesto.

Como analogía, imagine que está informando dónde se encuentra una determinada persona usando solo su vista. Tienes una buena vista del paisaje más amplio, pero la persona está envuelta en una niebla. Verá piezas del cuerpo que llaman su atención ... una mano izquierda en movimiento, un pie derecho, brilla los anteojos, etc., que están nerviosos, pero cada valor está bastante cerca del verdadero centro de la masa. Si ejecutamos algún tipo de promedio de ejecución, obtendríamos valores que se acercan al centro de masa de ese objetivo a medida que se mueve a través de la niebla y en efecto son más precisos que los valores que (el sensor) informó que se hizo ruidoso por el ruidoso. niebla.

Ahora parece que estamos perdiendo datos potencialmente interesantes para obtener una curva aburrida. Sin embargo, tiene sentido. Si estamos tratando de recrear una imagen precisa de la persona en la niebla, la primera tarea es obtener una buena aproximación suave del centro de masa. A esto podemos agregar datos de un proceso de medición/sensor complementario. Por ejemplo, una persona diferente podría estar cerca de este objetivo. Esa persona puede proporcionar una descripción muy precisa de los movimientos del cuerpo, pero puede estar en el medio de la niebla y no saber en general dónde está terminando el objetivo. Esta es la posición complementaria de lo que obtuvimos por primera vez: los segundos datos dan detalles con precisión sin un sentido de la ubicación aproximada. Los dos datos se unirían. Pasaríamos el primer set (como su problema presentado aquí) para obtener una ubicación general sin ruido. Pasaríamos el segundo conjunto de datos para obtener los detalles sin contribuciones engañosas no deseadas a la posición general. Utilizamos datos globales de alta calidad y datos locales de alta calidad, cada conjunto optimizado de manera complementaria y evitamos que corromperen el otro conjunto (a través de los 2 filtros).

Específicamente, se mezclaríamos en datos de giroscopio, datos que son precisos en el detalle local de los "árboles" pero se pierde en el bosque (deriva), en los datos discutidos aquí (desde el acelerómetro) que ve bien el bosque pero pero No los árboles.

Para resumir, pasamos los datos de los sensores que están nerviosos pero permanece cerca del "centro de masa". Combinamos este valor suave base con datos precisos en el detalle pero se desplaza, por lo que este segundo conjunto es filtrado de paso alto. Obtenemos lo mejor de ambos mundos a medida que procesamos cada grupo de datos para limpiarlo de aspectos incorrectos. Para el acelerómetro, pasamos suave/bajo los datos de manera efectiva ejecutando alguna variación de un promedio de ejecución en sus valores medidos. Si estuviéramos tratando los datos del giroscopio, haríamos matemáticas que mantengan efectivamente los detalles (acepta Deltas) mientras rechazan el error acumulado que eventualmente crecería y corrompería la curva suave del acelerómetro. ¿Cómo? Esencialmente, usamos los valores de giroscopios reales (no promedios), pero usamos un pequeño número de muestras (de deltas) una pieza al derivar nuestros valores limpios finales totales. El uso de un pequeño número de deltas mantiene la curva promedio general principalmente a lo largo de los mismos promedios rastreados por la etapa de paso bajo (por los datos de acelerómetro promedio) que forma la mayor parte de cada punto de datos final.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top