.NET

El modelo de led RGB utilizado teóricamente soporta hasta 5W y proporciona 70 lúmenes, sin embargo, en el circuito implementado, se controlará a una potencia mucho menor con una corriente máxima aproximada por color de 60ma. Aún así, esa corriente es demasiada para los puertos del arduino, por lo que se hace necesario intercalar un circuito controlador que soporte corrientes de esa magnitud.

El circuito controlador elegido es el chip ULN2003AN que utilizamos a modo de relé para encender y apagar cada led.

El led tiene cuatro puertos, un ánodo común y un cátodo para cada uno de los colores: rojo, verde y azul. Al combinarse estos colores en distintas proporciones podemos crear la sensación de estar viendo casi cualquier color.

El esquema de circuito se muestra en la siguiente figura:

El sketch Arduino le programa para recibir mensajes de cambio de color del led vía el puerto serie en un formato ‘COLOR R G B’. Una vez recibido el mensaje utiliza la función analogWrite para controlar la corriente que circulara cada led vía modulación de anchura de pulso (PWM).

Posteriormente se realizo un programa en .NET que permite especificar el color del led de una forma amigable. El siguiente video muestra el resultado:

Se adjunta un archivo con el código del sketch arduino y el programa de .NET.

Los servomotores son motores que integran una circuitería de control que permiten posicionar su eje dentro de un rango. Típicamente los servomotores permiten posicionar el eje con precisión dentro de un rango angular de 0 a 180 grados aproximadamente.

Constan de tres señales de entrada: alimentación, referencia, y señal de control. Utilizando la señal de control se puede posicionar el motor dentro del rango. El control se realiza a través de pulsos de duración determinada de la señal de control. Por ejemplo, para posicionar un servomotor controlado con pulsos de 1msg a 2msg de rango 0-180 grados a 90 grados necesitaríamos suministrar a la señal de control un pulso de 1.5msg de duración.

Se conecta el control del servomotor a la salida digital número 9 del Arduino que programaremos para recibir mensajes de posicionamiento a través del puerto serie, interpretarles y posicionar el servomotor. Para ello utilizaremos las librerías de control de servos (Servo) y de delimitación de mensajes del puerto serie (Messenger).

La inicialización del programa del Arduino se muestra en la siguiente figura donde simplemente indicamos a la librería de control de servos que se utilizará el pin 9 para el control, inicializamos el puerto serie a 115200 baudios e inicializamos la librería de procesado de mensajes.

Dentro del bucle principal simplemente se leerá el puerto serie esperando mensajes de la forma ‘SERVO n’ donde n es un número de 0 a 178 que indica el ángulo en grados donde se desea posicionar el motor. Una vez interpretado el mensaje satisfactoriamente se posicionara el servomotor y se añadirá un pequeño retraso de 15msg que permita al servomotor posicionarse antes de recibir otra orden.

Para la aplicación WPF diseñaremos una clase con una única propiedad que permita establecer la posición del servo. Haremos que dicha propiedad sea ‘Bindable’ para poderla enlazar de forma natural con los controles de interface gráfico.

La parte principal de dicha clase se muestra en la figura siguiente:

y se creará un interface gráfico para el control en XAML enlazando a dicha propiedad de la siguiente manera:

El resultado se puede ver en el siguiente video. El código fuente de ambos programas se adjunta en el artículo:

Utilizando un Arduino y el chip sensor de temperatura TMP36 se construye un sencillo termómetro tal y como se propone en el circuito diez de la guía de experimentación de adafruit.

El circuito es extremadamente sencillo, basta conectar los pins de alimentación y referencia del sensor para alimentarle, y que de esta forma nos proporcione en su otro pin un voltaje proporcional a la temperatura, el cual leeremos a través de la entrada analógica número 0 del Arduino, cuyo ADC nos proporciona una resolución de 10 bits.

El programa cargado en el Arduino es simplemente un bucle que cada segundo lee el voltaje de la entrada analógica y le convierte en un valor de temperatura utilizando las indicaciones de la hoja de características del sensor, enviando posteriormente este valor por el puerto serie.

El programa de PC leerá de forma continua los valores de temperatura que le vayan llegando por el puerto serie virtual (USB) y representándoles en pantalla. Su código principal es el siguiente (Aplicacion WPF en C#):

Con lo cual podremos leer en la pantalla del PC el valor de temperatura procedente del sensor, el cual se actualizará cada segundo.

El efecto de transición entre imágenes disolver o ‘dissolve’ consiste en una interpolación desde la imagen inicial hasta la imagen final en un periodo de tiempo determinado.

Para ello se definirá un parámetro t, que representa el progreso de la transición y cuyo rango es de 0 a 1. Un valor de cero significa que la transición aún no ha comenzado, es decir, aún se muestra completamente la imagen de origen, mientras que un valor de 1 significa que se ha completado el 100% de la transición, es decir, se mostrará la imagen de destino. Un valor de 0.5 significaría que la transición está al 50% por lo que se mostraría una mezcla a partes iguales de la imagen de origen y la imagen de destino.

Para su implementación se utilizará un WriteableBitmap. Los pixeles de un WriteableBitmap en Silverlight se representan como valores pargb lo que implica que el canal alpha, encargado de representar el nivel de opacidad, debe ir premultiplicado por lo que para representar un color rojo 50% transparente el pixel debería contener los valores [0.5,0.5,0,0]. De todas formas, para el caso que nos ocupa simplemente realizaremos la interpolación entre cada uno de los componentes de cada pixel de la imagen.

Si representamos cada pixel como un vector de cuatro componentes, siendo tr el vector que representa a un pixel de la transición, o a uno de la imagen de origen y d a uno de la imagen de destino el calculo de cada uno de los pixeles de la transición para un t dado se realiza mediante la siguiente expresión:

siendo x,y las coordenadas del pixel.

El siguiente programa en Silverlight muestra el efecto de transición con dos imagenes predefinidas.

El código fuente del programa se encuentra adjunto al artículo.

Una de las novedades introducidas en la versión 3 de Silverlight es la clase WriteableBitmap que nos permite la generación dinámica de mapas de bits o bitmaps.

Su funcionamiento es muy sencillo, basta con pasar en el constructor el número de pixels de ancho y de alto que queremos que tenga la imagen para generarla y una vez generada podemos acceder a su contenido a través de la propiedad Pixels.

En el siguiente fragmento de código se construye un bitmap de 320x200 pixels y se establece el pixel en la posición (x, y) al color (r,g,b). Una vez modificado el bitmap se debe llamar a la función Invalidate para actualizar su contenido.

   1: var bitmap = new WriteableBitmap(320,200);

   2: var pixelColor = BitConverter.ToInt32(new byte[] { (byte)b, (byte)g, (byte)r, 255 }, 0)

   3: bitmap.Pixels[x + y * bitmap.PixelWidth] = pixelColor;

   4: bitmap.Invalidate();

Por supuesto es necesario asignar el bitmap a la propiedad Source de un control Image para representarle en pantalla.

Una funcionalidad interesante añadida es el método Render que permite representar en el bitmap un control gráfico descendiente de UIElement después de aplicarle una transformación (rotación,escala,posición) lo que abre la puerta a la generación de interesantes efectos.

La siguiente ilustración muestra la generación dinámica de bitmaps. Si posa el cursor sobre la imagen podrá ver una representación de metaballs construida sobre un WriteableBitmap.

Utilizando la técnica descrita en el artículo anterior se ha representado el contenido espectral de una canción en una estructura tridimensional. Para ello se representa el espectro de cada pequeño tramo temporal de la canción en la cara frontal del cubo desplazándose en profundidad a medida que pasa el tiempo y va llegando nuevo contenido espectral.

El resultado se observa a continuación aunque la calidad del video no es demasiado buena y se observan inconsistencias en el framerate que ‘estropean’ la continuidad del efecto.

Cada plano del eje Z o de profundidad representa a un espectro. Cada espectro se representa en cada plano X-Y del volumen modificándose ligeramente de forma aleatoria el contenido del eje Y o altura con objeto de mejorar la estética del efecto. Con el mismo objetivo se aplica una pequeño efecto de escala al volumen que representa la energía promedio del espectro del intervalo de la canción que esta sonando en ese instante.

El sonido pertenece a un fragmento de uno de los episodios de la cuarta temporada de Battlestar Galactica y ha sido extraído de aquí.

Los algoritmos genéticos están inspirados en la teoría de la evolución de Darwin y forman parte de la computación evolutiva, área de rápido crecimiento dentro del campo de la inteligencia artificial.

Los seres vivos están compuestos por células. En cada una de la células de un organismo se encuentra el mismo conjunto de cromosomas. Los cromosomas son cadenas de ADN y sirven como modelo para el organismo, es decir, el organismo se construirá o desarrollará en base a las instrucciones codificadas en su cromosomas.

Un cromosoma está compuesto por genes, bloques de ADN. Cada gen codifica una proteína particular. Se podría decir que cada gen codifica un rasgo, como por ejemplo el color de los ojos. Los diferentes rasgos son llamados alelos (ojos azules, ojos marrones). Cada gen tiene su propia posición dentro del cromosoma.

El conjunto completo de material genético (todos los cromosomas) es llamado genoma. Un conjunto particular de genes del genoma se llama genotipo. El genotipo es la base para el fenotipo, las características físicas y mentales que presentara el organismo al desarrollarse.

Durante la reproducción, el material genético de cada uno de los padres se recombina al formarse los gametos, células cuyo material genético se fusionará en la fecundación. Existe un complicado conjunto de sistemas encargados de asegurar la integridad de la molécula de ADN con el fin de preservar la información hereditaria y reparar la mayor parte de las alteraciones que pueda experimentar, sin embargo, aproximadamente uno de cada mil errores no es corregido por lo que la información se ve alterada de una generación a la siguiente apareciendo lo que se denomina mutación, que hace referencia a cualquier cambio permanente en el material génico no debido a la segregación independiente de los cromosomas o a la recombinación que ocurre durante el proceso de meiosis.

Las mutaciones se producen al azar y son generalmente perjudiciales, aunque en ocasiones también ocurren mutaciones beneficiosas que confieren alguna ventaja a las células en las que aparecen.

Tanto las recombinaciones como las mutaciones beneficiosas son las causas de las grandes variaciones que muestran los individuos de una misma especie. Los individuos que presenten una mejor adaptación a su entorno es más probable que tengan descendientes formados en base a su material genético.

Los algoritmos genéticos permiten encontrar buenas soluciones para una clase de problemas cuya solución sería difícil de encontrar utilizando otros métodos. Conceptualmente establecen una analogía entre el conjunto de soluciones de un problema y el conjunto de individuos de una población. Cada individuo representa una posible solución al problema y se parte de un conjunto de individuos normalmente generado al azar que se hará evolucionar de tal forma que las nuevas generaciones contengan soluciones mejores para el problema a resolver.

De forma general el proceso es el siguiente:

1. Generar una población aleatoria de n cromosomas (posibles soluciones al problema).
2. Evaluar la adaptación f(x) de cada cromosoma x en la población. Dicha función evaluara la bondad de la solución que presenta cada cromosoma.
3. Si se cumple la condición de finalización (típicamente el haber encontrado una solución aceptable o llegar a un número de generaciones máximo) detener el algoritmo.
4. Generar una nueva población. El proceso de crear una nueva generación típicamente se divide en cuatro pasos: Selección, Cruzamiento, Mutación y reemplazo.
5. Reemplazar la antigua generación por la nueva.
6. Ir al paso 2.

Un ejemplo de resolución de este tipo de problemas lo encontramos en la reciente implementación por Roger Alsing de un algoritmo genético para aproximar una imagen utilizando un número pequeño de polígonos traslucidos.

El funcionamiento del algoritmo, variante del proceso descrito anteriormente, se puede resumir en los siguientes pasos, tal y como Roger describe en su blog:

1. Generar una cadena de ADN de forma aleatoria. Esta cadena contendrá las instrucciones para pintar cada uno de los polígonos que aparecen en pantalla.
2. Generar una nueva cadena de ADN copiando la cadena de ADN anterior mutándola ligeramente.
3. Utilizar la cadena para representar los polígonos en pantalla.
4. Comparar el resultado con la imagen original.
5. Si la nueva imagen se parece más a la imagen original sobrescribir la cadena de ADN original con la nueva cadena.
6. Repetir desde 1.

Se puso su implementación a prueba con una imagen arbitraria y se dejo evolucionar al ‘organismo’ durante aproximadamente media hora. En el siguiente video se puede ver el proceso de evolución acelerado por un factor de 32.

La imagen final generada se corresponde con la generación 117653 y está compuesta por un total de 78 polígonos con una media de 8 puntos por polígono.

Se puede descargar el código fuente del programa en el blog de Roger Alsing.

Fuentes| Introduction to Genetic Algorithms | Wikipedia | Fundamentos biológicos de la conducta

Fiji es un proyecto experimental que permite ejecutar aplicaciones Silverlight fuera del navegador, es decir, como aplicaciones de escritorio en su propia ventana. Su objetivo final es coger los archivos de aplicación (.xap) de Silverlight y utilizarles para generar un archivo ejecutable que no necesite del navegador para funcionar.

Para ello se utiliza el mismo mecanismo que algunos navegadores utilizan para cargar sus plugins, NPAPI (Netscape Plugin API).

Para utilizar Fiji solo es necesario pasarle como parámetro la ruta completa del archivo .xap que contiene la aplicación Silverlight, por ejemplo, “fiji.exe C:\AplicacionSilverlight.xap”.

El fenómeno de la sincronización nos rodea: nuestro corazón, los ritmos circadianos, aplausos, generadores eléctricos... Ciertas especies de luciérnagas han cautivado a muchos viajeros en el Sudoeste Asiático, los cuales regresaban a sus lugares de origen contando historias de poblaciones inmensas de luciérnagas emitiendo luz intermitente de forma totalmente sincronizada creando grandes franjas de luz parpadeante en la oscuridad.

Su estudio se remonta a 1665, cuando Christiaan Huygens yacía enfermo en la cama con la compañía de dos relojes de péndulo. Después de unos días se dio cuenta de que los péndulos se movían de tal forma que cuando uno estaba completamente a la izquierda, el otro se encontraba completamente a la derecha, y viceversa.

Intrigado, modifico manualmente el ritmo de los péndulos pero con el tiempo siempre volvían a sincronizarse. La explicación que dio a lo que el llamaba “simpatía de dos relojes” fue que cada uno de los péndulos causaba un movimiento imperceptible en la pared de la que colgaba cada reloj y que dicho movimiento tendía a forzar la sincronización de de cada uno de los péndulos con el otro. El tiempo le daría la razón.

En el siguiente video se puede observar una versión de este fenómeno (con sonido se aprecia mejor).

El modelo Kuramoto fue motivado por el comportamiento de ciertos osciladores químicos y biológicos y permite modelar la sincronización y desincronización en grupos de osciladores acoplados. La ecuación que gobierna el sistema es la siguiente:

La limitada variedad de estados en los que el modelo se puede encontrar lo hace apropiado para el modelado de algunos sistemas utilizados en neurociencia.

En la siguiente aplicación, cuyo código se encuentra adjunto, puede observar como varía el comportamiento de 25 osciladores en función de la constante de acoplamiento (K). Al reiniciar la simulación se asignarán velocidades y fases iniciales aleatorias a cada uno de los osciladores.

Referencias

• Synchronization of Globally Coupled Nonlinear Oscillators. The Rich Behavior of the Kuramoto Model
• An Introduction to Coupled Oscillators: Exploring the Kuramoto Model

La gestión de la complejidad es uno de los principales retos a los que nos enfrentamos a la hora de desarrollar software. Recientemente Patrick Smacchia me invitó a probar NDepend, una potente herramienta que nos proporciona, de forma muy visual e interactiva, una gran cantidad de información sobre ensamblados .NET.

Su utilización simplifica la gestión de una base de código compleja al poder realizar medidas objetivas sobre el código y poder comparar su evolución en el tiempo. También  facilita la comunicación al poder ver de forma muy visual la estructura y dependencias del código. Además, combinada con reflector (herramienta con la que se puede integrar), nos puede facilitar enormemente la tarea de entender o evaluar ensamblados no escritos por nosotros.

Los diferentes gráficos y resultados mostrados a continuación son el resultado del análisis mediante NDepend a una sencilla aplicación que escribí hace tiempo. Se puede observar el informe HTML que fue generado automáticamente por la herramienta aquí.

NDepend facilita ver la estructura y las interrelaciones entre los diferentes componentes de un proyecto de software así como responder a preguntas sobre la calidad u otros aspectos del software en base a los numerosos indicadores o métricas incluidos. Además, podemos realizar nuestras propias preguntas sobre el código utilizando CQL (Code Query Language), un lenguaje de consultas similar a SQL.

Al cargar un conjunto de ensamblados en NDepend se realiza un completo análisis de los mismos. A partir de ese momento tendremos a nuestra disposición una gran cantidad de información que podemos visualizar bajo una agradable interface. Al termino del análisis también se generará un informe en HTML con la información más relevante.

Métricas

Tenemos diferentes métricas a nuestra disposición, las cuales pueden operar a diferentes niveles: espacios de nombres, ensamblados, tipos, métodos y campos. Las métricas nos permiten detectar potenciales problemas en la arquitectura del software y nos pueden indicar la necesidad de reestructurar el código (refactoring).

En la siguiente imagen se observa un gráfico generado por la herramienta que representa el número de líneas de código de cada uno de los métodos de una aplicación. Cada recuadro sombreado representa un método, y su tamaño es proporcional al número de líneas de las que está compuesto. Además, los métodos están agrupados dentro de los tipos que les contienen, por lo que podemos ver su peso especifico dentro de la aplicación.

La cantidad de información que proporciona el gráfico anterior es muy elevada, siendo además interactivo por lo que nos permite navegar a las estructuras representadas dentro del proyecto.

Entre las diferentes métricas a nuestra disposición destacamos las siguientes (tenemos un listado completo en el sitio web de la herramienta):

• Longitud: en instrucciones de lenguaje intermedio (IL), o en líneas de código. Una gran longitud en nuestros tipos o clases podría indicar un exceso de responsabilidad para estas y por lo tanto aconsejar la necesidad de refactorización.
• Aferencia: la aferencia es el número de vías de entrada o referencias hacia la entidad bajo observación. En otras palabras, si estamos trabajando a nivel de métodos, la aferencia de un método nos indicará el número de métodos que dependen de este método bajo observación. Este indicador nos muestra la ‘importancia’ que tiene una determinada entidad. Si una entidad es muy ‘importante’ será más difícil modificarla, porque el número de entidades que depende de ella será elevado y al hacerlo, alguno de ellos podría dejar de funcionar.
• Eferencia: indica el número entidades de las que depende esta entidad. Por ejemplo, a nivel de tipo o clase, nos indicaría el número de clases de las que depende la clase bajo observación. En general, nos interesa mantener este número bajo. Idealmente, un tipo solo debería depender de los tipos inmediatamente inferiores a el en la jerarquía.

CQL

Las consultas predeterminadas que NDepend realiza sobre nuestro proyecto durante su análisis principal se agrupan en las categorías que muestra la siguiente figura.

Esta consultas nos proporcionan una evaluación de nuestro código en base a diferentes parámetros de calidad y son totalmente personalizables.

Dentro de cada uno de los grupos podemos ver cada una de las consultas y las partes del software que no han superado la prueba. Al seleccionar una de las consultas, además, dichas partes se resaltaran tanto en el gráfico como en el visor de resultados.

Dependencias

Un alto nivel de dependencias generalmente significará mayores problemas a la hora de realizar cambios o ampliar la funcionalidad de una aplicación. A través de la matriz de dependencias, podemos observar de forma gráfica e interactiva las dependencias entre los componentes del proyecto, lo cual nos facilita mantener dichas dependencias dentro de un nivel razonable. Por ejemplo, el que la segunda línea de la figura siguiente esté completa indica que todos los tipos de la aplicación dependen de tipos definidos en el ensamblado ‘mscorlib’, lo cual es de esperar ya que es el ensamblado principal del FrameWork.

La herramienta nos proporciona también diagramas en los que el grosor de las líneas entre nodos indica el grado de dependencia con respecto a un ensamblado concreto.

Comparaciones y otras características

Otra característica de NDepend es la comparación entre las diferentes versiones de un conjunto de ensamblados con lo que podemos ver su evolución y observar, por ejemplo, la efectividad de una etapa de refactorización del código.

Podemos ver un ejemplo de este escenario, así como de otros escenarios interesantes en el sitio web de NDepend bajo ‘Online Demos’.