Control de servomotores con Arduino y WPF
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:
Termómetro con Arduino
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.
JavaScript Intellisense con Visual Studio 2010
Parece que la próxima versión de Visual Studio va a traer importantes mejoras en el Intellisense para JavaScript.
En la imagen anterior se aprecia como es capaz de reconocer la introducción de 5 variables de forma dinámica a pesar de los alerts y las excepciones lanzadas.
Publicado el código fuente del programa del Apolo 11
Se ha publicado parte del código fuente del programa que utilizó el Apolo 11 en la primera misión espacial tripulada a la luna.
El programa se puede ejecutar utilizando el emulador del ordenador de a bordo del Apolo 11 proporcionado por el proyecto Virtual AGC y AGS.
Mapas de bits dinámicos en Silverlight
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.
Representación volumétrica de contenido espectral
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í.
Representación de campos escalares tridimensionales
La representación volumétrica es una técnica que permite la representación de campos escalares tridimensionales. Sus aplicaciones son múltiples: representación de imágenes del cuerpo humano procedentes de diversos instrumentos sensores con fines médicos, representación realista de nubes u otros fenómenos gaseosos en simulaciones visuales en entornos virtuales, o representación de diversas estructuras y constructos en la ciencia y la ingeniería.
En este artículo se describirá una variante de la técnica basada en texturas conocida como ‘volume ray casting’. Conceptualmente dicha técnica consiste en el lanzamiento de rayos con origen en la cámara de tal forma que atraviesen el volumen que contiene el campo escalar. El color resultante que se ‘pintará’ en la superficie del volumen en el punto de entrada de cada rayo será una función de los puntos que el rayo atravesó al pasar por el volumen.
Para su implementación se utilizará la plataforma XNA y se hará uso de la aceleración grafica que nos proporcionan la GPU. Será necesaria una tarjeta que soporte al menos la versión 3.0 del modelo de sombreadores (Shader Model 3.0).
El proceso comienza con la representación de un volumen que actuará como frontera del campo escalar, es decir, el campo escalar se encontrará completamente en el interior de ese volumen. Utilizaremos un cubo.
En primer lugar representaremos las posiciones de entrada del rayo y de salida en dos texturas que posteriormente utilizaremos para determinar la dirección. Al Vertex Shader en la GPU se le harán llegar las posiciones sin transformar de los vértices del cubo. Dichas coordenadas se copiaran a la variable InterpolatedPosition a la salida del Vertex Shader. Dicha variable está marcada como coordenadas de textura por lo que a la entrada del pixel shader se recibiran las coordenadas interpoladas. Lo mismo se hará para la variable InterpolatedTransformedPosition solo que en este caso almacenaremos las coordenadas transformadas por la combinación de las matrices de posicionamiento en el mundo (world), vista (view) y proyección (projection) que serán suministradas a la entrada del programa de la GPU como parámetros. Esta última variable será utilizada posteriormente para localizar la posición exacta donde se deben muestrear las texturas para obtener la dirección del rayo.
1 struct VertexShaderInput
2 {
3 float4 Position : POSITION0;
4 };
5
6 struct VertexShaderOutput
7 {
8 float4 Position : POSITION0;
9 float4 InterpolatedPosition : TEXCOORD0;
10 float4 InterpolatedTransformedPosition : TEXCOORD1;
11 };
12
13 VertexShaderOutput VertexShaderFunction(VertexShaderInput input)
14 {
15 VertexShaderOutput output;
16
17 float4 worldPosition = mul(input.Position, World);
18 float4 viewPosition = mul(worldPosition, View);
19 output.Position = mul(viewPosition, Projection);
20 output.InterpolatedPosition = input.Position;
21 output.InterpolatedTransformedPosition = output.Position;
22 return output;
23 }
24
25 float4 RenderPositionsPixelShaderFunction(VertexShaderOutput input) : COLOR0
26 {
27 float4 color = input.InterpolatedPosition;
28 return color;
29 }
Se representarán las caras frontales del cubo en una textura utilizando el estado de representación CullMode.CounterClockWise. El color asignado a la textura en realidad contiene las coordenadas tridimensionades del cubo en el espacio de coordenadas local del modelo en el formato (x,y,z,1).
A continuación se repite la operación pero esta vez representando las caras interiores del cubo.
El siguiente y ultimo paso es la representación del cubo, solo que en esta ocasión el color resultante será función del campo escalar, muestreado en base a las direcciones grabadas en las texturas anteriores. Al muestrear cada una de las texturas anteriores podemos obtener para cada punto (x,y) de la textura, las coordenadas (x,y,z) del cubo por las cuales entró el rayo y por las cuales salió. Con estas dos coordenadas se puede calcular la dirección del rayo y al conocer el punto inicial y la dirección del rayo que atraviesa el campo escalar se puede recorrer cada uno de los puntos de ese campo para calcular su contribución al color de la superficie del cubo. Este proceso se realiza en el Pixel Shader que representará el resultado final en pantalla.
1 float4 RenderVolumePixelShaderFunction(VertexShaderOutput input) : COLOR0
2 {
3 //Calculamos que puntos de las texturas debemos muestrear
4 float2 texC = input.InterpolatedTransformedPosition.xy /= input.InterpolatedTransformedPosition.w;
5 //lo llevamos al rango [0,1] espacio de coordenadas de textura desde espacio de proyeccion 2D
6 texC.x = 0.5f*texC.x + 0.5f;
7 texC.y = -0.5f*texC.y + 0.5f;
8 //Muestreamos las texturas de posiciones iniciales y finales
9 float3 frontPos = tex2D(FrontTextureSampler, texC);
10 float3 backPos = tex2D(BackTextureSampler, texC);
11 //Calculamos el punto inicial y la direccion
12 float4 currentPosition = float4(frontPos,0);
13 float3 direction = normalize(backPos - frontPos);
14 //Inicializamos las variables del color
15 float4 color = float4(0, 0, 0, 0);
16 float4 src = 0;
17 float value = 0;
18 //Recorremos el campo escalar en la dirección calculada
19 //acumulando opacidad en función del campo
20 float3 Step = direction * (1.0f/256.0f);
21 for(int i = 0; i < 256; i++)
22 {
23 //muestreamos la textura
24 value = tex3Dlod(VolumeTextureSampler, currentPosition).r;
25 src = (float4)value;
26 //Front to back blending
27 src.rgb *= src.a;
28 color = (1.0f - color.a)*src + color;
29 //advance the current position
30 currentPosition.xyz += Step;
31 }
32 return color;
33 }
El rendimiento de esta técnica al ser completamente acelerada por GPU es muy bueno como se puede constatar en los siguientes videos obtenidos con una tarjeta gráfica de gama media/baja con un consumo de CPU mínimo.
Basado en un artículo original de Graphic Runner.
Campos escalares obtenidos de vorbis.
Bibliografía: GPU - Based Interactive Visualization Techniques - D. Weiskopf
Observaciones contradictorias
En uno de sus últimos artículos Martin Fowler reflexiona sobre la necesidad de que determinados sistemas sean capaces de manejar información contradictoria.
Se presenta el caso del historial médico de un paciente donde se tienen dos notas con los resultados de los análisis de sangre hechos por dos hospitales diferentes. La nota del primer hospital indica que el paciente presenta un tipo de sangre A mientras que la nota del segundo hospital dice que el tipo de sangre del paciente es B.
Podríamos concluir que uno de los dos hospitales se ha equivocado en sus análisis y solicitar un nuevo análisis que nos confirme uno de los dos tipos de sangre. Puede que en este caso no tuviera demasiada importancia el desechar el análisis que hemos confirmado equivocado, sin embargo, podrían existir situaciones donde la contradicción no esté tan clara o incluso pueda deberse a que se haya producido un cambio muy poco probable en el estado de la propiedad bajo consideración. Además, una observación incorrecta podría haber tenido importantes implicaciones en base a decisiones tomadas cuando se pensaba que era cierta, ya que dichas decisiones podrían ser ahora incorrectas. Si eliminamos el valor incorrecto del sistema se pierde el vinculo con esas decisiones y se dificulta su rastreo.
En el caso de un sistema tradicional se hubiera asociado la propiedad ‘Tipo de sangre’ al paciente como un atributo de su clase que solo pudiera presentar un valor en un momento dado, sin embargo, en el articulo se propone un ‘patrón’ para manejar este tipo de información contradictoria de forma genérica y que denomina ‘observación’.
La clase observación guarda todo el estado relativo a una observación dada, como la fecha de su realización o la probabilidad de que sea cierta; puede referirse tanto a la existencia de una cualidad como a su ausencia, algo importante en situaciones donde se desconozca o no sea posible determinar el valor de una propiedad pero el hecho de poder descartar determinados valores amplíe la probabilidades de tomar una decisión correcta.
Se me ocurre que, tal vez entonces, en los casos en que esto sea aplicable, se deba definir una nueva abstracción a un nivel por encima de la ‘observación’, estando dicha abstracción formada por un conjunto de observaciones y por la lógica necesaria para tomar las decisiones apropiadas sobre dicho conjunto en el dominio del problema que se pretenda resolver. Esta nueva abstracción sustituiría a los tradicionales atributos o propiedades de las clases y podría presentarse de tal forma que fuera ‘transparente’ a las entidades que no necesiten más detalles que el valor de la propiedad, y a la vez presentase un interface más o menos complejo para las entidades que deban tomar decisiones en base al conjunto de observaciones.
Si los programadores construyeran aviones
Enviado por peancor el Lun, 02/23/2009 - 20:46.Pinceladas de evolución
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:
- Generar una población aleatoria de n cromosomas (posibles soluciones al problema).
- 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.
- 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.
- 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.
- Reemplazar la antigua generación por la nueva.
- 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:
- 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.
- Generar una nueva cadena de ADN copiando la cadena de ADN anterior mutándola ligeramente.
- Utilizar la cadena para representar los polígonos en pantalla.
- Comparar el resultado con la imagen original.
- Si la nueva imagen se parece más a la imagen original sobrescribir la cadena de ADN original con la nueva cadena.
- 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
- 1
- 2
- 3
- 4
- siguiente ›
- última »
