Siente la fuerza

Qué encontrarás en esta entrada?

• Sensores en Android.
• Tratamiento de datos a partir de ellos.

No es la primera vez que hablamos en esta página de AndroSensor, una aplicación que muestra los valores que registran todos los sensores de tu teléfono móvil, con la interesante característica de poder exportarlo todo a un archivo de datos separados por comas (".csv").

Tampoco sería la primera vez que intento sacarle partido a esta aplicación, siendo evidente que contiene un gran potencial en los campos de la ciencia e ingeniería.

Para ser sinceros, no he conseguido mucho hasta el momento, pero me gustaría exponeros aquí mis - aún bastante pobres - resultados y mis reflexiones sobre ellos. En el primer intento que citaba anteriormente, básicamente me centré en representar gráficamente los datos recopilados. Hoy me gustaría llegar un poco más lejos y realizar unos cuántos cálculos.

El proceso empieza tomando una medida de un suceso cinemático a través del móvil. La idea es que, en su recorrido, el dispositivo grabe todas las variables que pueda, estando yo especialmente interesado (por el momento) en la aceleración lineal.

AndroSensor, según la versión y el dispositivo utilizado, permite la grabación de varias aceleraciones. Yo he trabajado con las siguientes:

• Acelerómetro: es la medida de toda aceleración detectada por el móvil. Con el dispositivo paralelo al suelo detecta una "componente z" de unos 9'8 m/s² con el dispositivo desacelerado por completo.

• Gravedad: como su nombre indica, es la parte de la aceleración correspondiente a la gravedad. La suma de todos sus componentes estará alrededor del valor 9'8 m/s².

• Aceleración lineal: es la parte de aceleración que queda una vez descontada la gravedad.

Esta última será la que utilicemos.

Hagamos un paréntesis para hablar de los ejes en AndroSensor. El sistema de referencia del dispositivo tiene tres ejes dispuestos de la siguiente manera:

• Eje x: es el que cruza la pantalla en la dirección de medida de su ancho.

• Eje y: es el que cruza la pantalla en la dirección de medida de su alto.

• Eje z: es el que cruza el dispositivo en la dirección de medida de su profundidad.

Además de este sistema de referencia, esta el sistema anclado en "el mundo". 

Ángulos de Tait-Bruan. Fuente: Wikipedia.

Ambos sistemas están relacionados por la orientación: tres variables angulares que parecen tener bastante en común con los ángulos de Tait-Bryan. Se podría pasar de un sistema a otro multiplicando por una matriz.

Matriz de cambio de base. Fuente: Wikipedia.

Con todo esto me dispongo a calcular la trayectoria. Partimos de la aceleración, y ésta es a= dv/dt. Supongamos que dv y dt son diferencias finitas, aunque muy pequeñas (lo cual es verdad si el muestreo se realiza a alta frecuencia). En tal caso, podremos decir que:

v(i+1) = v(i) + a(i) * [t(i+1) - t(i)]

Donde la letra i denota el valor i-ésimo que toma el vector al que vaya referida. Es decir, si se toman tres medidas de la magnitud genérica A cada 5 segundos, A(i=1) sería el valor que toma a tiempo cero, A(i=2), el que toma a los 5 segundos y A(i=3), el que toma a los 10 segundos.

Siguiendo el mismo argumento, podemos decir que la posición cumple que v=ds/dt, por lo que:

s(i+1) = s(i) + v(i) * [t(i+1) - t(i)]

Las ecuación anteriores se pueden escribir por separado de la siguiente manera:

x(i+1) = x(i) + v_x(i) * [t(i+1) - t(i)]

y(i+1) = y(i) + v_y(i) * [t(i+1) - t(i)]

z(i+1) = z(i) + v_z(i) * [t(i+1) - t(i)] 

donde:

v_x(i+1) = v_x(i) + a_x(i) * [t(i+1) - t(i)]

v_y(i+1) = v_y(i) + a_y(i) * [t(i+1) - t(i)]

v_z(i+1) = v_z(i) + a_z(i) * [t(i+1) - t(i)]

Donde la velocidad dependería del valor de la aceleración, que es el único que hemos medido realmente.

Esto se puede implementar en MATLAB u Octave fácilmente, y podemos ir viendo cómo funciona. Empecemos, como no podría ser de otra forma en física, por un péndulo.

Como diría el de Jurassic Park: "no hemos reparado en gastos". El montaje experimental de alta tecnología que podéis ver sobre estas líneas, se trata de un flexo con una cinta atada en el que voy a colgar el móvil y a hacer que se balancee. Lo primero que obtenemos es lo siguiente.

Maaaaaaal! A la izquierda vemos la trayectoria, que nada tiene que ver con la situación real. El péndulo supuestamente desciende un metro, mientras que oscila, una sola vez, recorriendo una decena de metros en cada eje del plano horizontal. Viendo las dimensiones en la foto de nuestra mágica cinta-péndulo, se puede confirmar que el experimento ha sido un fracaso.

A la derecha vemos representadas la posición (en azul), la velocidad (en rojo) y la aceleración (en verde), según lo que el script calcula como "eje de avance" (el eje en el que más desplazamiento ha habido). En este caso se trata del "eje x", y tampoco tiene mucho sentido: el experimento se ha tratado de hacer partiendo y finalizando en una situación de reposo, sin embargo la velocidad al final no acaba en cero, y la posición, lejos de pararse, parece que se aleja cada vez más del origen.

Se podría pensar que hay una mala calibración de los sensores, y que existe un "error de cero", una magnitud constante que altera la medida de la aceleración. Para intentar corregirla, como hemos comentado, partimos y finalizamos en una situación de reposo, e imponemos precisamente que existe una cantidad constante la cual, sumada a la aceleración, da una velocidad final nula. Como empezamos con velocidad cero por definición del algoritmo, una aceleración constante no hace más que añadir una pendiente a una recta imaginaria que pasaría por el origen y sobre la que dibujaríamos la velocidad. Es decir, modulamos la curva de la velocidad con una pendiente constante, rotándola sobre el origen hasta conseguir que la punta más alejada de éste (la velocidad final) acabe en cero también.

Suponiendo una aceleración constante, v=a*t, y asumiendo un error: v'=(a+e)*t.

t=0 => v=v'=0

(en el origen, la velocidad original y la corregida son cero)

t=T => v(T)=aT => a=v(T)/T

t=T => 0=v'(T)=(a+e)*T => e=-a

e=-v(T)/T

Es decir, la corrección aditiva a la aceleración es la velocidad final que tendría sin corrección entre el tiempo en llegar a ella con signo opuesto. Añadiendo esto a lo anterior, obtenemos lo siguiente.

Sin embargo, la mejora no es sustancial. La trayectoria sigue siendo un desastre y las gráficas cinemáticas tampoco tienen mucho sentido. Lo que sí podemos ver, es que la velocidad acaba en cero, y que, como consecuencia de ello, la posición no se aleja indefinidamente, sino que parece que se estabiliza a cierta distancia.

Al menos, la primera parte de la gráfica de la aceleración sí me gusta, tiene un sano aspecto oscilante.

Para acabar, quiero realizar una última prueba. Su gráfica correspondiente sería la siguiente.

Desciende casi un metro, y en los ejes "x" e "y" avanza 5 en cada uno de ellos. Su velocidad inicial y final son cero (impuesto con la corrección anterior), pero no es así en la mayoría de los puntos intermedios.

Señoras y señores, la gráfica de arriba es la que ha tomado mi móvil parado encima de mi mesa.

Esto da que pensar sobre los errores que pueden acumular los sensores. Es posible que haya cometido más de un error de cálculo por el camino, que haya liado los sistemas de referencia, que haya realizado "correcciones" con dudosa justificación falseando los resultados, etc. Pero entiendo que un objeto parado debería tener una aceleración muy cercana a cero, y que el posible ruido se compensase para que la trayectoria orbitase de manera más o menos aleatoria en torno al origen. Asumiendo que pudiera detectar otro tipo de aceleraciones, estando parado el objeto, entiendo que deberían ser a lo sumo cantidades constantes aditivas (lo cual se compensaría con la corrección que hemos comentado anteriormente). En resumen, y quizás me vuelva a equivocar, pero creo que las medidas de los sensores no son lo suficientemente estables como para realizar estos cálculos, al menos de una manera tan simple como lo he intentado yo.

Tendré que seguir trabajando en ello. De momento, os he mostrado lo que tengo.