Mostrando entradas con la etiqueta ABSys. Mostrar todas las entradas
Mostrando entradas con la etiqueta ABSys. Mostrar todas las entradas

martes, 29 de diciembre de 2015

Como una Moto a 360

Qué encontrarás en esta entrada?
  • Primeras impresiones del Moto 360.
  • Personalización del dispositivo.
  • Aplicaciones interesantes para un smartwatch con Android Wear. 

Navidades: la apología del consumismo por excelencia. Dejando a un lado los dilemas morales sobre el sentido de las fiestas, el caso es que este año me ha caído un flamante smartwatch Moto 360 y voy a comentar un poco mis primeras impresiones y algunas cosas que he descubierto jugueteando un poco con él.


En primer lugar, dejar claro que no tengo un gran conocimiento en el campo. Hasta hace dos días pensaba que los smartwatches eran una pijada por completo innecesaria, una muestra de la ineludible espiral de decadencia que ha tomado nuestra sociedad a través de la tecnología como herramienta para hacer patente hacia los demás una frágil y no muy fundamentada sensación de "status quo"... pero la verdad es que el cacharro mola.

¿Qué aporta un smartwatch? En mi caso, mi móvil (un Nexus 5) es un poco grande como para llevarlo continuamente en un bolsillo pegado a ti. Muy habitualmente acaba encima de alguna mesa, cajón, o metido en algún sitio de no muy fácil acceso. Hay veces que me mandan mensajes, o incluso me llaman, y no me entero hasta tiempo después, que decido echarle un ojo. Para eso vale en mi caso un smartwatch: para enterarte de que te están llegando cosas al móvil cuando lo tienes por ahí tirado, y no tener que sacarlo si no son realmente importantes.

El Moto 360 cumple con esta funcionalidad y además aporta muchas cosas más. Todas las notificaciones del móvil aparecen en tu muñeca, y puedes incluso contestar mensajes desde el propio reloj. Más adelante veremos aplicaciones que permiten realizar cosas muy interesantes.

Diseño


El diseño del Moto 360 es bastante elegante. Hay quien piensa que es demasiado grande. A mi no me lo parece, y más si tenemos en cuenta que su pantalla es táctil y que, por tanto, necesitamos ciertas dimensiones como para poder manejarlo con facilidad. Tiene pantalla redonda, que en mi opinión lo hace bastante más bonito que los cuadrados, mimetizándose mejor con los relojes clásicos. En mi caso vino con una correa metálica, dándole un aspecto sofisticado.

La personalización de la esfera es una de las cosas más adictivas que he encontrado últimamente. Al ser un reloj con pantalla digital, se puede cambiar la esfera por múltiples diseños. Hay esferas que se pueden descargar directamente desde Google Play, como las que muestro a continuación:

O también hay esferas que están diseñadas a través de otras aplicaciones, como es el caso de WatchMaker.


La mejor opción que he encontrado hasta el momento, es con WatchMaker, que permite relojes personalizables hasta el extremo y mucho más detallados que las que presentan otras alternativas. Lo primero es tener la versión PREMIUM (puesto que la gratuita no te permite utilizar cualquier carátula que encuentres). Una vez tengamos esta versión, se puede descargar cualquier esfera en formato ".watch", incluso hacértela tú mismo.

Páginas como FaceRepo ofrecen una ingente variedad de modelos que se pueden descargar de manera gratuita. Algunos de mis favoritos son:



Con la aplicación WatchMarker se configura la caráruta que queramos de las descargadas en este formato, y luego hay que tener seleccionada la opción WatchMarker en las carátulas de Android Wear (que luego veremos que es la aplicación desde la que podremos administrar nuestro reloj desde el móvil).


Aplicaciones


La aplicación fundamental es Android Wear. Esta aplicación permite administrar nuestro reloj desde el móvil: las carátulas, las aplicaciones, etc.


Al principio, las aplicaciones para el reloj pueden parecer un poco confusas, debido a que se descargan desde la misma Play Store, y no queda claro si son aplicaciones para el móvil o para el smartwatch. Por eso es útil la aplicación Wear Store, ya que es una tienda de aplicaciones (que enlaza con Play Store), pero sólo para el reloj.


También es recomendable la aplicación Wear Mini Launcher, que aporta opciones adicionales, como un listado de aplicaciones disponibles en el reloj o accesos directos a distintos ajustes. También incluye carátulas configurables con estas funcionalidades.


Hay muchísimas aplicaciones que podemos instalar en nuestro reloj, desde juegos, hasta herramientas de todo tipo. Destacar un par de ellas: Wear Camera Remote, que permite tomar fotos con el móvil usando tu reloj como disparador (con múltiples opciones, incluyendo la de visualizar desde el reloj lo que está enfocando el móvil). También me ha gustado una aplicación muy simple llamada Mini Maps for Wear. Esta aplicación dibuja un pequeño mapa en tu reloj alrededor de tu posición actual.



Por último, comentar que muchas aplicaciones del móvil tienen widgets para el reloj que aparecen automáticamente cuando éstas están instaladas. Éste es el caso de Google Play Music, OruxMaps, Swarm, Shazam, etc., las cuales permiten acceder a ciertas funcionalidades limitadas de las que se ofrecen en el móvil a través del reloj. Veamos un ejemplo con Hangouts y ABSys.


En resumen: un juguetito muy interesante. ¿Vital para la subsistencia como especie? Pues más bien no... pero que puede permitir hacer muchas cosas divertidas. Ya sólo por el hecho de poder controlar la música desde la muñeca cuando llevas el móvil en invierno en un bolsillo interno debajo de doce capas de ropa sin necesidad de sacarlo, merece la pena.
Publicado por a las 2 comentarios:
Categorías: , , , , ,

jueves, 17 de diciembre de 2015

Un día en la vida de @AstarothsBot

Qué encontrarás en esta entrada?

Como comentábamos el otro día, El Diablo Fumado se ha lanzado a las redes sociales, y ahora publica "por su cuenta" en Twitter bajo el alias @AstarothsBot. En la última entrada vimos que esto era posible gracias a Node-RED. Hoy veremos cómo es un día en la vida de este peculiar "community manager" recorriendo una sesión de sus twits, en concreto, la del 16 de diciembre de 2015.


Recordemos que @AstarothsBot es un bot que recoge variables, como el pronóstico del tiempo, la temperatura de la CPU, el uso de los procesadores, de la memoria, de la red, etc. y devuelve mensajes teñidos de su... peculiar carácter. El esquema actual de su programación en Node-RED sería el siguiente:


Publicado por a las No hay comentarios:
Categorías: , ,

sábado, 5 de diciembre de 2015

El Diablo Fumado y el Nodo

Qué encontrarás en esta entrada?
  • Breve presentación de Node-RED.
  • Presentación en sociedad de @AstarothsBot.

El otro día, mi enlace con las tecnologías experimentales, Altair·Mikoto, me habló de Node-RED. Se trata de una forma de programar gráfica bastante interesante. La aplicación ofrece varios módulos que se conectan de forma gráfica mediante "cables", que enganchan las salidas y entradas de cada uno de los ellos.


Dentro de cada módulo hay funciones complejas pre-programadas, o incluso la capacidad de escribir tus propias funciones en JavaScript. También hay módulos que desde Linux ejecutan comandos en shell.


Entre sus varias formas de salida, me llamó desde el principio la capacidad de que publique directamente en Twitter. Es esta la forma en la que nació @AstarothsBot, el "community manager" de Astaroth's Bot System (ABSys).


Como algunos ya sabréis, ABSys es un sistema que he creado, cada vez más complejo, por el que me comunico con mi ordenador y al final éste realiza tareas para mi sin la necesidad de estar físicamente presente. Este simpático bot toma distintas variables (monitorización del sistema, clima, etc.) y, tras analizarlas, publica distintos mensajes divertidos en su cuenta de Twitter.

Para empezar a usar Node-RED en Ubuntu, deberéis seguir los siguientes pasos:

sudo apt-get install nodered
sudo apt-get install npm
sudo ln -s /usr/bin/nodejs /usr/bin/node

Podréis acceder entonces a la aplicación tecleando primero en una consola:

node-red

Y luego accediendo desde un navegador de Internet a la dirección:

http://127.0.0.1:1880/

Lo suyo sería ejecutar "node-red &" como aplicación al inicio, y así siempre que se encendiese el ordenador, se activarían automáticamente las acciones que hayamos configurado.

Os invito a seguir los delirantes comentarios sarcásticos del Diablo Fumado en su canal de Twitter.

Publicado por a las No hay comentarios:
Categorías: , , , ,

domingo, 1 de noviembre de 2015

CenterIM y Ubuntu 15.10

Qué encontrarás en esta entrada?
  • Instalar CenterIM en Ubuntu 15.10.

ADVERTENCIA:

No me responsabilizo de los posibles riesgos de seguridad que impliquen seguir los pasos detallados en esta entrada.


Acabo de abordar recientemente la siempre estimulante tarea de un formateo. Aunque es recomendable realizarlo de vez en cuando para limpiar basura y actualizar los sistemas operativos, con cada actualización siempre hay algunos problemillas que hay que solventar. Y es que somos animales de costumbres que, una vez acostumbrados a utilizar algo, nos cuesta mucho utilizar otra cosa a no ser que tenga claras y rápidas ventajas con respecto a lo anterior.

Es el caso de CenterIM en Ubuntu 15.10. Por un momento pensé en que iba a tener que renunciar a este ligero cliente de mensajería instantánea que, por otra parte, hace la función de cimientos para el sistema ABSys (el sistema por el cual puedo dar órdenes a mi ordenador desde el móvil, pudiendo acceder a tiempo real a mi equipo y ejecutar distintas tareas, como he documentado alguna vez en este blog).

Según podíamos leer en RSPPI en su día, de donde tomé las bases para ABSys, para instalar CenterIM bastaba con ejecutar en un terminal el siguiente comando:

apt-get install centerim

Sin embargo, esto sólo funciona limpiamente para versiones antiguas de Ubuntu. En la versión 15.10, hay que ir algunos pasos más allá. Al intentar instalar CenterIM de la página oficial, nos encontramos varias alternativas: la versión 5, que hay que configurarla ("./configure"), y la versión 4, que está para configurar también, o en forma de paquete ".deb".

Personalmente, y debido a mi falta de conocimiento, estoy un poco "peleado" con las versiones en "tar.gz" para configurar, porque antes o después llego a un problema irresoluble de dependencias. Éste es también mi caso para las versiones 4 y 5 de CenterIM. Pruebo por tanto los paquetes, pero éstos también tienen problemas de dependencias: fundamentalmente, el paquete "libgnutls26" parece haber sido descatalogado para las nuevas versiones de Ubuntu.

Tras luchar con Synaptic y sus repositorios, encuentro una interesante página en la que se pueden descargar paquetes antiguos de Ubuntu: Ubuntu Updates. Allí no es difícil descargar la librería libgnutls26.

Una vez hecho esto, el problema lo da libgcrypt11, pero resulta que éste también está en Ubuntu Updates.

Después de estos pasos, estamos listos para instalar los paquetes ".deb" de la página de CenterIM. En antiguos repositorios de Ubuntu, accesibles desde la web, también tenemos estos paquetes. Primero hay que instalar la versión "commons" ("centerim-common_4.22.10-2ubuntu1_all.deb"), y después, por ejemplo, la versión "centerim_4.22.10-2ubuntu1_amd64.deb".

Con esto tenemos instalado de nuevo CenterIM en un Ubuntu 15.10.

Resumiendo los pasos:
  1. Instalar libgcrypt11.
  2. Instalar libgnutls26.
  3. Instalar centerim-common_4.22.10-2ubuntu1_all.deb.
  4. Instalar centerim_4.22.10-2ubuntu1_amd64.deb.

Publicado por a las No hay comentarios:
Categorías: , , ,

sábado, 6 de diciembre de 2014

Siente la fuerza (Parte II)

Qué encontrarás en esta entrada?
  • Cinemática basada en los sensores Android.
  • Frecuencias electromagnéticas. 

En la última entrada os hablamos de AndroSensor y de cómo manipular los datos que este software nos permite guardar. Hoy vamos a comentar algunos de los resultados que he obtenido utilizando varios métodos para intentar ajustar estos sensores a la realidad física.


El Círculo:

Lo primero que vamos a hacer es dibujar un círculo a mano alzada con el móvil, y nos vamos a centrar, como la última vez, en la parte de la cinemática (análisis de la aceleración para intentar reconstruir la trayectoria). El algoritmo de diferencias finitas que utilizo ya fue esbozado en la entrada anterior, por lo que hoy nos vamos a dedicar a ver dibujitos.

Vemos la trayectoria tal cual sale de las lecturas del sensor:

Datos sin correcciones

Bien en verdad que a mi los círculos a mano alzada no se me dan muy bien... pero quizás éste haya salido especialmente mal.

El siguiente paso sería suponer que los acelerómetros estuviesen afectados por un error constante, un "error de cero", así que los intentamos ajustar para que el error sea compensado, obteniendo lo siguiente:


Datos con correcciones de cero para la aceleración

Supongo que habrá controversia al respecto... pero yo diría que lo de arriba se parece ya bastante a un círculo (al menos, a uno de los que dibujo yo a mano alzada).

Una cosa que se me ha ocurrido recientemente, es descartar las pequeñas vibraciones: ¿Qué pasaría si, en lugar de corregir la aceleración forzándola para que la velocidad sea nula al principio y al final, simplemente la "simplifico"?, y con "simplificar" me refiero a "cuantizarla". Defino un "paso mínimo", y obligo a la aceleración a que tome sólo valores que sean múltiplos enteros de esa "unidad" que acabo de definir. Con todo esto, obtenemos:

Datos con la aceleración cuantizada en pasos de 1m/s²

Bueno, también tiene pinta de círculo. Sin embargo, tiene un fallo importante:

Avance de la hélice en la dirección perpendicular al círculo

En el eje perpendicular al círculo, donde debería estar inmóvil, se mueve nada más ni nada menos que ¡¡4 metros!! No es un círculo, sino una especie de hélice que va avanzando.

El mismo problema lo presentaba la primera gráfica, asociada a datos en bruto, sin ningún tipo de corrección. Sin embargo, no era así cuando obligábamos a la velocidad a ser cero al inicio y al final.

Avance en la dirección perpendicular con la corrección de cero en la aceleración: aunque no sea nulo, éste es "sólo" de metro y medio

Avance en la dirección perpendicular sin correcciones: se dispara hasta los cuatro metros

La última idea es mezclarlo todo: ¿qué pasaría si cuantizamos la aceleración, y al mismo tiempo intentamos corregir el posible error de cero?

Aceleracioes con corrección de cero y cuantización en bloques de 1m/s²

La hélice avanza, pero menos que en cualquiera de los casos anteriores

En este último caso obtenemos un círculo (si bien es verdad, que algo "chuchurrío"), y el avance en la dirección perpendicular es "sólo" de metro y medio. En realidad este "avance" debería ser casi nulo (20cm a lo sumo), pero es el mejor resultado que he obtenido hasta el momento.

A continuación, vamos a ver las gráficas de la cinemática en los dos casos más favorables. La posición está en azul, la velocidad en rojo, y la aceleración en verde. Al terminar el trazado del círculo en el mismo punto en el que lo empezamos, ambas deberían acabar en cero, pero vemos que en ambos casos acaban en metro y medio.

Posición, velocidad y aceleración en la dirección del trazado sin cuantizar la aceleración

Posición, velocidad y aceleración en la dirección del trazado cuantizando la aceleración

En la segunda gráfica se puede apreciar la cuantización de la aceleración. Ésta sólo puede valer múltiplos enteros de 1m/s² (1m/s², 2m/s², 3m/s², ...).

A continuación, dibujamos las gráficas de los casos más desfavorables: aquellos en los que no hemos corregido el error de cero de la aceleración, desviándose notablemente en la dirección perpendicular:

Sin corrección de cero ni cuantizado

Sin corrección de cero, pero con la aceleración cuantizada

Paradójicamente, si nos fijamos sólo en la dirección del trazado, estos círculos empezaron en el mismo punto donde acabaron, lo cual es correcto. El problema es que los valores para el eje perpendicular al trazado son completamente irreales.

En cualquier caso, y aunque aún hay mucho en lo que mejorar, de momento me quedo satisfecho en lo que al dibujo de círculos se refiere... ¿y si lo intentamos con algo más complicado?


El Corazón:

Partiendo de lo anterior, dibujo los cuatro corazones:

Sin corrección de cero ni cuantizado

Con corrección de cero, pero sin cuantizado

Sin corrección de cero, pero con aceleraciones cuantizadas

Con corrección de cero y aceleraciones cuantizadas

Como si de una constante se tratara, en los casos en los que no hemos corregido el error de cero en la aceleración se desvían unos cuatro metros en la dirección perpendicular, mientras que en los que sí lo hemos corregido, el desvío es de metro y medio. En este caso, si tuviera que elegir el que más se parece a la realidad, creo que me quedaría con el segundo. Sin embargo, el segundo no tiene las aceleraciones cuantizadas, y eso puede dar problemas, como veremos en el siguiente caso.


El caso estático:

Vamos a dejar el móvil quieto encima de la mesa, y a ver qué pasa...

"Trayectoria" de un móvil parado con datos en bruto

La conclusión es indiscutible: el móvil se teletransporta a través de dimensiones ocultas del espacio y, aunque parezca que no se mueva de encima de la mesa, recorre unos 80 metros en su apasionante viaje lleno de misterios a través de la parafísica... Bueno, puede ser eso, o que los sensores se hayan visto afectados por un importante error que se potencie con el tiempo.

Vamos a ver cómo se comporta nuestro móvil parado con las distintas correcciones en la aceleración:

"Trayectoria" de un móvil parado con aceleraciones corregidas (error de cero)

"Trayectoria" de un móvil parado con aceleraciones cuantizadas

En el primer caso, la compensación del error de cero no es suficiente para "parar" al objeto, aunque sí acorta su viaje: en este caso pasa de los 80 a los 4 metros recorridos.

En la segunda gráfica (aceleraciones cuantizadas), no es que tengáis mala vista, sino que sólo se representa un punto y, al no estar en compañía de otros, es invisible. La posición del objeto está siempre en el origen. El objeto, por fin, se ha quedado parado.

En mi script he dejado todas las opciones programadas y accesibles, y seguiré trabajando en ello, pero parece que las mejores soluciones las aportan los métodos en los que corregimos el error de cero de la aceleración, siendo en algunos casos especialmente interesante añadir además el proceso de la cuantización.


Magnetismo:

Hasta ahora nos habíamos centrado en las variables cinemáticas, básicamente, en el estudio de la aceleración para reconstruir la velocidad y trayectoria del objeto en cuestión. Sin embargo, AndroSensor ofrece otras variables interesantes, como es el caso del campo magnético.

Bajando el otro día en mi ascensor me di cuenta de la variación tan pintoresca que tenía el campo a medida que bajaba.


He leído un poco por encima sobre el tema y, por lo visto, el hormigón del que están hechas las paredes de mi casa no es demasiado saludable de cara a las posibles interferencias electromagnéticas. De hecho, según Radiansa, la normativa española establece como límite 100 microteslas para campos magnéticos de 50Hz.

En este caso medimos campos que pasan de los 60 microtestas, aparentemente estacionarios (aunque no sé si realmente se está midiendo el promedio temporal de un campo oscilante de más alta frecuencia). La modulación que se observa proviene del movimiento del sensor (que está bajando en un ascensor), de tal manera que lo que estamos viendo es una variación en el espacio, y no en el tiempo.

Es interesante ver que entre piso y piso la amplitud del campo decae incluso casi media centena de microteslas. Se puede utilizar esto para ver claramente que en el recorrido del ascensor hemos cruzado ocho suelos, y así contar los pisos.

Afinamos un poco más este tipo de medidas, e incorporamos a nuestro script de análisis de datos de los sensores la funcionalidad de contar oscilaciones: por separado las bajadas y las subidas.


En este segundo experimento estamos viendo la señal con el sensor fijo. Se trata de uno de los casos estáticos de los cuales hemos estudiado la cinemática unas líneas más arriba. En esas circunstancias, estamos viendo la variación del módulo del campo magnético con el tiempo.


Viendo cuánto oscila a lo largo del tiempo medido, contamos que decae 379 veces, y que vuelve a subir otras 379 en unos 108 segundos. Eso da una frecuencia de unos 3'5 Hz. En general, en esa zona de mi habitación estoy midiendo frecuencias que van desde los 3 a los 4 Hz (bajas frecuencias). Insisto que no sé si se trataría de una frecuencia normal o, en el caso de estar midiendo promedios temporales del campo magnético, una frecuencia secundaria de modulación de la onda.


Informe Remoto:

Para finalizar, os comentaré la integración de este script en Astaroth's Bot System (ABSys), el sistema que me permite la comunicación con mi ordenador vía Hangouts.

Actualmente, puedo depositar los datos adquiridos con mi móvil en una carpeta en la nube que se sincroniza con una carpeta local de mi equipo de sobremesa. Una vez estén los datos en casa, dando una orden vía Hangouts, recibo el resumen del análisis por mensajería instantánea y al correo, incluyendo las gráficas en este último caso.


Un ejemplo curioso de integración entre Android, mensajería instantánea, shell de Linux y MATLAB/OCTAVE.
Publicado por a las No hay comentarios:
Categorías: , , , , , ,

domingo, 7 de septiembre de 2014

Render in progress

Qué encontrarás en esta entrada?
  • Monitorización renderizaciones en Blender en Linux.

En Astaroth's World no es la primera vez que intentamos monitorizar Blender. El proceso de renderizado (creación de una imagen digital a partir de un diseño previo), es un proceso en la mayor parte de las ocasiones costoso tanto a nivel de recursos del sistema como en tiempo. No es raro que un proyecto de animación amateur tarde días o semanas en renderizar, y este tiempo siempre puede dispararse hasta el infinito según las calidades que queramos o la duración de nuestra secuencia. Por ello, es especialmente interesante poder monitorizar el proceso, incluso a distancia, mientras que invertimos ese tiempo en otras actividades.

La solución propuesta hace meses en este blog involucraba un costoso análisis del vídeo generado. Como el vídeo en formación estaba incompleto, primero lo reconstruía corrigiendo el índice, y luego contaba los fotogramas y el tiempo (relacionados por los "fotogramas por segundo"). Finalmente, lo enviaba por correo usando mutt. De esta manera podíamos programar un informe periódico para recibirlo en el correo electrónico (en aquella versión incluso se incluía el último fotograma renderizado extraído del vídeo en formación).

La solución propuesta ahora es más eficiente, puesto que aprovecha los propios recursos de Blender y no implica un procesamiento de vídeo mientras que se está generando (muy costoso para el sistema).

La clave está en que Blender permite un acceso por línea de comandos (más información aquí), de tal manera que se puede renderizar en una consola de Linux sin necesidad de abrir el entorno gráfico de la aplicación. A priori, esto parece ser más eficiente para el sistema. A cambio, perdemos la capacidad de ver el fotograma que se está generando, lo cual a veces puede resultar útil para detectar errores durante el renderizado.

La sintaxtis básica podría ser la siguiente:

./blender -b archivo.blend -s 001 -e 100 -a -x 1

De esta manera se renderizaría el proyecto guardado en "archivo.blend" desde el primer fotograma hasta el número 100. En pantalla podremos ver algo parecido a lo siguiente:

Fra:1 Mem:23.51M (0.00M, Peak 29.46M) | Preparing Scene data
Fra:1 Mem:23.51M (0.00M, Peak 29.46M) | Preparing Scene data
Fra:1 Mem:23.51M (0.00M, Peak 29.46M) | Creating Shadowbuffers
Fra:1 Mem:23.51M (0.00M, Peak 29.46M) | Raytree.. preparing
Fra:1 Mem:34.57M (0.00M, Peak 34.57M) | Raytree.. building
Fra:1 Mem:33.92M (0.00M, Peak 51.19M) | Raytree finished
Fra:1 Mem:33.92M (0.00M, Peak 51.19M) | Creating Environment maps
Fra:1 Mem:33.92M (0.00M, Peak 51.19M) | Caching Point Densities
Fra:1 Mem:33.92M (0.00M, Peak 51.19M) Sce: Scene Ve:180482 Fa:80512 La:1
Fra:1 Mem:33.92M (0.00M, Peak 51.19M) | Loading voxel datasets
Fra:1 Mem:33.92M (0.00M, Peak 51.19M) Sce: Scene Ve:180482 Fa:80512 La:1
Fra:1 Mem:33.93M (0.00M, Peak 51.19M) Sce: Scene Ve:180482 Fa:80512 La:1
Fra:1 Mem:33.93M (0.00M, Peak 51.19M) | Volume preprocessing
Fra:1 Mem:33.93M (0.00M, Peak 51.19M) Sce: Scene Ve:180482 Fa:80512 La:1
Fra:1 Mem:33.93M (0.00M, Peak 51.19M) Sce: Scene Ve:180482 Fa:80512 La:1
Fra:1 Mem:48.35M (0.00M, Peak 51.19M) | Scene, Part 8-135

Como vemos, en este "log" se da información a tiempo real sobre el proceso. Lo interesante es que no es difícil redirigir esta salida en pantalla a un archivo de texto, basta con hacer:

./blender -b archivo.blend -s 001 -e 100 -a -x 1 > log.txt

Con ello conseguimos obtener un archivo "log.txt" en el que venga información a tiempo real sobre el renderizado. Bastaría con leerlo para saber en qué punto se encontraría nuestra animación.

El flujo de trabajo constaría entonces de dos partes: renderizado por consola y lectura de los datos generados. Para la primera parte podríamos utilizar un script parecido al siguiente:

#!/bin/bash
tmps=`date +%s`
echo "$tmps;$2;$3" > log.txt
dir=`pwd`
cd /url_donde_este_blender/
ini=`printf "%03d" $2`
fin=`printf "%03d" $3`
./blender -b $dir/$1 -s $ini -e $fin -a -x 1 >> log.txt
Si a este archivo le llamásemos "render.sh", habría que ejecutarlo en la misma carpeta donde estuviera el ".blend" de la siguiente manera:

./render.sh archivo.blend 1 100

En dicho caso, cogería el archivo "archivo.blend" y renderizaría la animación desde el fotograma 1 al 100. Primero tomaría el tiempo inicial (para poder dar estimaciones de cuánto va a tardar). Luego, escribiría esa información, junto con la de los fotogramas iniciales y finales en el log (para poderlos usar más tarde en nuestros cálculos posteriores). Tras dar el formato adecuado a los números de fotogramas renderizaría la animación mandando el log a un archivo de texto.

Ya se está generando la animación, y nuestro log tiene la siguiente pinta:

1410073356;1;100
Read new prefs: /********/userpref.blend
found bundled python: /********/python
read blend: /********/untitled.blend
Fra:1 Mem:23.51M (0.00M, Peak 29.46M) | Preparing Scene data

En la primera fila, separados por ";", tenemos los datos sobre tiempo y fotogramas que hemos introducido nosotros a través del primer script. La última fila con el texto "Fra:[número]" nos da el último fotograma con el que se está trabajando. Con todo ello, podemos iniciar la segunda fase: lectura de los datos generados.

   Un script como el siguiente leería los datos del log y nos calcularía lo que deseamos:

# Tiempo de inicio de la animación:
tinibl=`cat log.txt | sed -n '1p' | awk -F\; '{print $1}'`

# Primer fotograma:
fotblendin=`cat log.txt | sed -n '1p' | awk -F\; '{print $2}'`

# Último fotograma:
fotblendfn=`cat log.txt | sed -n '1p' | awk -F\; '{print $3}'`

# Archivo blender renderizado:
archblen=`cat log.txt | sed -n '4p' | grep -o "/.*blend"`

# Último fotograma renderizado:
framblen=`cat log.txt | grep -o "Fra:[0-9]*" | sed -n '$p' | grep -o "[0-9]*"`

# Hora actual:
tfinbl=`date +%s`

# Tiempo de renderizado hasta el momento:
tbl=`echo "scale=2; ( $tfinbl - $tinibl ) / 60" | bc`

# Fotogramas por renderizar (el último de la animación menos el último renderizado):
fotporren=`echo "$fotblendfn - $framblen" | bc`

# Fotogramas renderizados (el último renderiado menos el primero de la animación):
fotyarend=`echo "$framblen - $fotblendin" | bc`

# Porcentaje renderizado:
porcblen=`echo "( $fotyarend * 100 ) / ($fotblendfn - $fotblendin)" | bc`

# Estimación de lo que queda por renderizar:
tiempestbl=`echo "scale=2; $fotporren * $tbl / $fotyarend" | bc`

# Redondeo del tiempo:
tiemptrunc=`echo "$tiempestbl / 1" | bc`            # truncado.
tdiscb=`echo "($tiempestbl * 10 - $tiemptrunc * 10) / 1 " | bc`    # Regla redondeo.
if [ $tdiscb -lt 5 ] ; then
    inctimbl=$tiemptrunc
else
    inctimbl=`echo "$tiemptrunc + 1" | bc`
fi

# Fecha fin:
ffinble=`date +%d/%m/%Y\ \(%H:%M\) -d "+$inctimbl min"`

Y con los datos ya leídos, simplemente tenemos que redirigirlos hacia donde queramos. Por ejemplo, podríamos mandarnos un correo electrónico con ellos a través de mutt. Mi opción ha sido aprovechar el sistema que me estoy creando basado en centerIM y Hangouts para poderme comunicar con mi ordenador a través de mi móvil (ver más acerca de esto). De esta manera, puedo preguntar por el móvil cómo va la renderización y recibiría algo como lo siguiente.


En fin, una herramienta más para sobrellevar el tedioso tiempo de espera durante el renderizado.
Publicado por a las No hay comentarios:
Categorías: , , , , , , ,

lunes, 4 de agosto de 2014

El diablo con peor vista del mundo

Qué encontrarás en esta entrada?
  • Reconocimiento (AMATEUR) de imágenes por MATLAB.
  • Integración con BASH de Linux.

Siguiendo en la línea de mis últimas entradas, estoy mejorando mi sistema de comunicación con mi ordenador a través del móvil. Los que seáis lectores habituales de la página, recordaréis la reciente entrada "Comunicación ordenada", en la que hablaba de cómo redirigir CenterIM (un programa de mensajería instantánea en línea de comandos) para que respondiera un "contestador automático", que realmente era un script en shell de Linux. De esta manera, y según lo que le mandases a tu ordenador vía Hangouts, él "te respondía" atendiendo a las directrices de dicho script.

Comentaba entonces que esto abría infinitas posibilidades. Por ejemplo, podemos colocar una webcam, instalarnos Motion para la detección del movimiento, y poder controlarlo desde nuestro móvil y que nos mande avisos si alguien entra en nuestra casa.

Una de las cosas que más me gusta de programar en shell es la facilidad que hay para integrarlo con otros programas que corran desde Linux. Se me ocurrió hacer un sistema de detección de imágenes basado en octave (la versión libre análoga a MATLAB), y eso es lo que os voy a contar hoy.

Antes de nada: no os hagáis muchas ilusiones. Esto es un juego en vías de desarrollo basado en ideas muy simples que sólo pretende ilustrar las posibilidades que se abren para la gente con interés en el tema.

En primer lugar, os muestro cómo ve mi ordenador.


De lujo, ¿verdad? Estáis viendo mi habitación con la luz apagada... bueno, dicho así suena un poco estúpido, pero desarrollaré la idea a continuación.

Maravillosa y nítida imagen de mi habitación a oscuras

Tengo una webcam situada en una posición fija de mi cuarto. El objetivo es que sepa diferenciar distintas situaciones y, para ello, no me importa si cambian sutilmente un número determinado de píxeles. Lo que quiero es que reconozca patrones de una manera fácil.

En una primera fase me he centrado en las condiciones de luz y en la apertura de mi puerta. Al cambiar las condiciones de luz, varían las sombras, y al abrir o cerrar la puerta, interfiere la luz que proviene del exterior. En teoría esto debería dejar unos patrones más o menos estándar.

¿Qué hago para crear el patrón? "Repixelado e indexado". Como he comentado antes, no me interesa la variación pixel por pixel, sino por zonas. Mi primera idea ha sido unir varios píxeles en lo que podríamos llamar "macro-píxeles", los cuales tendrían la luminosidad media de los píxeles que se encuentran en su interior. La segunda idea, ha sido normalizar el color a tres estados: negro (para las zonas con luminosidad baja), blanco (para las de luminosidad alta) y gris (para las de luminosidad media). Con esto mi intención es facilitar el análisis de coincidencias por comparación directa con una imagen modelo.

celda=32;    % Tamaño de la celda.
[I,J,K]=size(IMG);
% Valores límite:
media=mean(mean(mean(IMG)));
maxim=max(max(max(IMG)));
minim=min(min(min(IMG)));
% Indexando y repixelado:
i=1;
for ni=1:(I/celda)
    j=1;
    for nj=1:(J/celda)
        IMGrp(ni,nj)=mean(mean(mean(IMG(i:i+(celda-1),j:j+(celda-1),1:3))));
        % Indexado:
        if IMGrp(ni,nj) < mean([minim,media])
            IMGrp(ni,nj)=0;
        else
            if IMGrp(ni,nj) > mean([media,maxim])
                IMGrp(ni,nj)=255;
            else
                IMGrp(ni,nj)=127;
            end
        end
        j=j+celda;
    end
    i=i+celda;
end

La siguiente parte es la toma de imágenes modelo. Una vez tomadas, se capta la imagen "muestra" y se la somete al mismo tratamiento (monocromatizado + repixelado + indexado), comparándola a continuación, "macro-pixel" a "macro-pixel", hasta obtener unos "coeficientes de similaridad" según coincidan con las imágenes modelo.


En principio, la que mayor coeficiente de similaridad tenga, representa la respuesta correcta.

Patrón que da la puerta de mi cuarto abierta con la habitación apagada

Una vez programado en octave, desde bash sólo habría que llamarlo de la siguiente forma:

echo "comando_de_matlab" | octave

De esta manera hemos unido octave con shell. A través de CenterIM, unimos shell con nuestro móvil y... voilà! Podemos recibir en nuestro móvil información procesada con octave y, en mi caso, retransmitida por el siempre carismático Diablo Fumado.


Como en otras tantas ocasiones, las posibilidades son infinitas. ¿Cuál es la vuestra?


ACTUALIZACIÓN (05/08/2014)

Creo que en la entrada que escribí ayer me quedé un poco corto de ejemplos y me gustaría que vierais de forma más dinámica cómo funciona el programa. Los siguientes ejemplos son muestras reales del amanecer de esta mañana en mi casa. Las fotos, y su posterior análisis, se han realizado mediante una orden que he dado yo desde mi móvil mientras estaba de camino al trabajo.

Caso #1: Habitación en oscuridad total (6:19am).

La imagen real y la simplificada fueron las siguientes:


Se ve que, pese a la oscuridad casi total, la cámara presenta un efecto parecido al viñeteo, pero a la inversa: los bordes son más claros que el centro. En la imagen original yo diría que es imperceptible, pero al transformarla en un patrón, tomando como referencia los máximos y mínimos de una imagen en la cuál ambos son casi iguales (e iguales a cero), se acentúa el contraste apareciendo este efecto.

Y a 30 km de distancia, en mi móvil (además de la foto), pudo leerse:


Caso #2: Habitación en penumbra (7:16am).

Las imágenes:


Ahora, la imagen simplificada no muestra una tendencia a la simetría radial como en el caso anterior. Con mayor cantidad de luz, los defectos en la captura homogénea de la cámara se hacen más irrelevantes y aparecen las primeras áreas de sombra y penumbra, definiendo zonas diferenciadas entre sí. Nótese que la caja blanca es con mucha diferencia el objeto que más luz está reflejando de la habitación a estas horas, y por tanto es también la única zona que queda clasificada como "luces altas" (color blanco).

La respuesta que recibo es la siguiente:


Caso #3: Habitación iluminada (7:35am).

Las imágenes:


Las paredes blancas, en contacto con la luz del sol entrante, empiezan a reflejar y a adquirir relevancia en la imagen. Las zonas negras se reducen y el patrón obtenido es más luminoso.

La respuesta que me llega:


Bueno, tres de tres, no ha estado mal, aunque aún necesita un poco de entrenamiento.


ACTUALIZACIÓN (07/08/2014)

Sigo entrenando al Diablo Fumado para que vea correctamente y me comunique sus conclusiones por Hangouts y correo electrónico. Para ello, he aumentado la resolución (reducido el tamaño de la celda del repixelado) y completado la paleta de colores (ahora uso un blanco, un negro, y dos grises medios). Pero sobre todo, lo que estoy aumentando es el número de imágenes (o "situaciones") con las que estoy comparando. Actualmente tengo definidos 14 escenarios posibles. Con todo ello, ya se empiezan a ver algunos resultados interesantes.


Parece que distingue correctamente entre los distintos estados de iluminación, diferenciando la luz natural de la artificial, y empieza a acertar también en lo que respecta a la situación de la puerta (cosa que desde el principio le ha costado). Seguiré trabajando en ello...
Publicado por a las No hay comentarios:
Categorías: , , , , , ,
Suscribirse a: Entradas (Atom)