Sensor de humedad y temperatura con Arduino. Cuarta parte: Gadget para Windows 7

Este artículo es una continuación de los siguientes:

Utilizando la base desarrollada en artículos anteriores, se construyó un gadget para el escritorio de Windows 7 que nos muestra información sobre la temperatura y la humedad y cuyo aspecto se puede ver en la figura siguiente.

Gadget para Windows 7 para medición de Humedad y Temperatura con Arduino y sensor SHT15

Además del manifiesto que le define, el gadget está compuesto de Html/CSS, JavaScript e imágenes que definen su background. El siguiente artículo que explica como desarrollar un gadget para Windows resultó muy útil.

Toda la lógica ha sido implementada en JavaScript utilizando Jquery y las APIs de visualización de Google.

El gadget establece un timer que ejecutará una medición de forma periódica cada minuto utilizando ajax. Si la petición tiene éxito se ejecutará la función measureReceived.

petición de medicion de temperatura y humedad ajax

En la función measureReceived, ejecutada después de cada medición, se actualizarán los valores de las medidas, así como del gráfico que representa su historia. También se calcularán y actualizarán los estadísticos valor medio, mínimo y máximo de la humedad y temperatura.

El código fuente se adjunta al artículo.

Diamante – Cuadrado

Las extensiones de terreno son uno de los fenómenos naturales más comúnmente representados gráficamente por computador.

El algoritmo Diamond-Square (Diamante-Cuadrado) es un método utilizado para la generación de terreno de forma aleatoria. Fue desarrollado por Loren Carpenter, cofundador y científico jefe de Pixar, para ser usado en el modelado de una superficie planetaria.

Los resultados producidos por dicho método se pueden observar en el siguiente video, generado por un programa cuyo código fuente puede encontrar adjunto a este artículo.

Para modelar el terreno se comienza con una matriz de dimensiones mxn, donde típicamente m será igual a n ya que esto simplifica las cosas. Las dimensiones de la matriz deberán ser potencia de dos más 1, es decir, 33×33, 65×65, 129×129, 257×257, etc.

Los valores de la matriz se interpretan como la altura que tiene el terreno en ese punto, por lo que un valor en la posición 30,30 de 65 significa que en la posición 30,30 del terreno, su altura es de 65 unidades. Este tipo de matrices se conocen como ‘heightmap’ o mapa de alturas.

La siguiente figura, extraída de la publicación original, muestra el proceso de generación de las alturas para una matriz de 5×5.

El proceso comienza con las cuatro esquinas, marcadas como 0, es decir, con un ‘cuadrado’ cuyos valores de altura son inicializados a los valores de altura que deseemos, en nuestro caso serán inicializados con el valor 0.

A continuación, se utilizan dichos valores para calcular la altura del punto 1a. Las etapas del algoritmo marcadas como a (1a, 2a, 3a, etc.) forman la parte ‘diamante’ del proceso, ya que si trazamos las diagonales desde cada punto a cada una de las esquinas del ‘cuadrado’ se formara un patrón de rombos, símbolo que habitualmente se utiliza para representar a los diamantes.

Después se procede a la etapa ‘cuadrado’ por lo que se toman las esquinas de cada uno de los rombos generados para calcular un nuevo valor para su centro, puntos marcados como 1b.

Una vez realizadas las etapas diamante y cuadrado podemos observar que la matriz o rejilla ha quedado dividida en 4 cuadrados.

El algoritmo continúa entonces con una nueva fase diamante-cuadrado, marcada como 2ª y 2b, solo que esta vez partiremos de 4 cuadrados en lugar de 1 y a cuya resolución la rejilla quedará dividida en 16 cuadrados.

En este caso el proceso ha concluido porque todos los puntos de la matriz han sido asignados. Si hubiéramos comenzado con una matriz de dimensiones mayores el proceso continuaría con nuevas etapas diamante-cuadrado hasta que quedase totalmente dividida y todos sus puntos hubiesen sido asignados con su correspondiente valor de altura.

Para calcular la altura de cada punto se utiliza el promedio de los valores circundantes, es decir, los cuadrados en la etapa diamante, y las esquinas de los rombos en la etapa cuadrado. A dicho valor, posteriormente se le añade un valor aleatorio (entre –d y +d) que estará limitado por unos parámetros.

Puede observar los detalles en la implementación adjunta a este artículo. Dicha implementación está basada en el programa de Paul Martz publicada en Generating Random Fractal Terrain y utiliza XNA para la representación grafica.

El efecto mariposa

Según cuenta Edward Norton Lorenz en su libro, la esencia del caos, el origen de esta expresión como símbolo del caos es un poco oscuro. Parece haber surgido a raíz de un artículo que presentó en Washington en 1972 titulado “¿Puede el aleteo de las alas de una mariposa en Brasil generar un tornado en Texas?”.

En dicho artículo, Lorenz evitó responder esta cuestión, pero apuntó que si el aleteo de una mariposa pudiera generar un tornado que de otra forma no se hubiera producido, también podría prevenir un tornado que de otra forma se hubiera formado.

Un probable origen de la expresión es debido a una peculiaridad del primer sistema caótico que Lorenz estudió en detalle, conocido como atractor extraño de Lorenz o atractor de Lorenz, cuya representación se muestra en el siguiente vídeo.

Sin embargo, un relato corto de Roy Bradbury, “Un sonido  de trueno”, escrito mucho antes de la reunión de Washington, narra la historia de como debido a la extinción de una mariposa prehistórica se cambia el resultado de unas elecciones presidenciales en la actualidad.

Se puede encontrar el código fuente que generó el vídeo de este artículo adjunto, el cual esta basado en uno de los ejemplos que se proporcionan con XNA Game studio 2.0.

Código fuente de el efecto mariposa

Primeras impresiones sobre Caliburn

Llevo un tiempo buscando una alternativa a CompositeUI, un buen Framework que me ha facilitado escribir unas cuantas aplicaciones.

En .NET Framework 3.0, Microsoft introdujo un  nuevo sistema de representación (WPF), junto con un nuevo modelo para la construcción de aplicaciones en donde la parte visual de los componentes de la interfaz de usuario típicamente se define utilizando un lenguaje de marcado denominado xaml, al estilo de html. Mediante dicho lenguaje, además, se pueden utilizar las avanzadas capacidades de enlazado a datos (Data Binding) que proporciona el framework.

Sin embargo, CompositeUI es previo a la introducción de las WPF y aunque se han realizado esfuerzos por compaginar ambos entornos, es difícil realizar una buena utilización de lo mejor de cada entorno a la hora de construir una aplicación.

El post de Rob Eisenberg sobre Caliburn (Excalibur) despertó mi interés, así que he estado estudiando un poco su código y la sensación que me ha producido es realmente buena.

El funcionamiento es sencillo, tal como se ve en la aplicación de ejemplo que viene con el código fuente.  El primer paso a realizar es inicializar el sistema, por ejemplo, en el constructor de la aplicación.

public App()
{
    ShellApplication.Start(
        new CustomConfiguration()
        );
}

El objeto suministrado construye una nueva instancia del contenedor a utilizar, en este caso, WindsorContainer, y configura el sistema registrando diversos servicios o componentes.

Entre dichos componentes se encuentra la clase ApplicationPresenter que define el presentador que utilizará la ventana principal de la aplicación (MainWindow) que queda registrado de la siguiente manera.

container.AddComponent("ApplicationPresenter",
    typeof(ApplicationPresenter), typeof(ApplicationPresenter));

A partir del momento que registramos un objeto en el contenedor podemos aprovechar todas las ventajas de la inyección de dependencias, también conocida como inversión de control (IoC).

De forma resumida, bajo inyección de dependencias, las clases de objetos definen que tipo de objetos o interfaces necesitan (dependencias), así como que eventos publican y a cuales desean suscribirse, siendo el contenedor el encargado de proveer a las instancias de los objetos con dichas dependencias. Estos sistemas presentan importantes ventajas desde el punto de vista de flexibilidad, escalabilidad y fiabilidad.

Caliburn provee de dos atributos para la gestión de eventos. Podemos publicar un evento del tipo Action<T> marcándole con el atributo Publish tal y como se ve en el ejemplo siguiente.

[Publish("event://NombreDelEvento")]
public event Action<object> Evento;

Y podemos recibir dicho evento en los objetos que nos interese simplemente definiendo un método que encaje con el delegado del evento, en este caso Action<object> y marcándole con el atributo Subscribe.

[Subscribe("event://NombreDelEvento")]
public void GestorDelEvento(object parametro)
{
    //Acciones a realizar cuando se produzca el evento
}

Cada vez que solicitemos un objeto al contenedor, este se encargará de realizar las gestiones necesarias para ‘cablear’ automáticamente los eventos.

Por último mencionar que podemos obtener objetos del contenedor utilizando el método estático Resolve. Por ejemplo, para obtener un objeto del tipo ApplicationPresenter previamente registrado utilizaríamos el siguiente código.

ApplicationPresenter presenter = 
    (ApplicationPresenter)Shell.Container
    .Resolve(typeof(ApplicationPresenter));

Caliburn también nos proporciona algunas extensiones de marcado para utilizar en xaml que nos permiten obtener una instancia de un presentador directamente desde una vista asignándole a la propiedad DataContext de la vista así como enlazar directamente ciertos componentes de la interfaz de usuario (botones y objetos de menú) a métodos públicos definidos en el presentador.

El juego de la vida

Resulta interesante observar como partiendo de un estado inicial y de unas reglas sencillas, el juego de la vida evoluciona exhibiendo complejos patrones.

Ejemplo de autómata celular, concebido por John Horton Conway y popularizado por Martin Gardner en un artículo de Scientific American aparecido en 1970, el juego de la vida, desde su aparición, ha sido plasmado por los programadores en multitud de sistemas.

Utilizando la plataforma XNA y tomando como base uno de los ejemplos que se proporcionan consistente en un sistema de partículas 2D, se realizó una implementación del juego de la vida. La implementación funciona tanto en sistemas Windows como en Xbox 360 suponiendo que contemos con una licencia para ejecutar código en dicha consola. Para compilar el código es necesario disponer de XNA Game Studio Express 1.0 Refresh, el cual se puede descargar gratuitamente.

En el siguiente vídeo se puede observar la evolución del autómata celular para un estado inicial concreto establecido al azar. 

La implementación consta de una rejilla de 50×50 celdas o ‘células’. Cada célula puede estar en uno de dos posibles estados: viva o muerta.

Para cada iteración se calcula el siguiente estado utilizando las reglas descritas a continuación:

  1. una célula ‘nace’, es decir, pasa al estado de viva si y solo si tres células vecinas suyas están vivas.
  2. Si una célula viva tiene como vecinas a dos o tres células vivas, seguirá viva. En caso contrario la célula morirá.
¿Desea saber más?
  1. Completo artículo en Wikipedia

Código fuente de el juego de la vida