Planet

Me encuentro trabajando desde hace varios días en la primera implementación del Servidor y en la primera implementación de la aplicación web de administración del mismo. Mi plan es tener listas estas versiones después de las Navidades, tal y como establecí en el Roadmap.
Esta primera versión del Servidor debería contar con un Núcleo, una Base de Datos, una API de Servicios y un par de servicios funcionales. El Servidor debería proporcionar también un conjunto de órdenes ejecutables por consola para administrarse. La aplicación web de administración del Servidor sería tan sólo un front-end de dichas órdenes, pero haría las tareas administrativas más amigables para el usuario, especialmente si se hacen remotamente.

Después de un mes con el proyecto dejado de lado, he aprovechado las navidades para trabajar en él un poco, y la verdad es que los resultados son satisfactorios, por ahora.Los cambios son sencillos, he programado un algoritmo basado en fuerzas para imprimir el árbol, la cámara se mueve si se mantiene pulsado el ratón, y también hay programado un algoritmo de coloreado inventado por mí. Además, se ven los nombres de los clados que representan los nodos cuando se coloca el ratón encima.He aquí un video de ejemplo:Mas técnicamente, los dos algoritmos principales son los siguientes:Algoritmo basado en resortesEs el algoritmo usado para calcular la posición de los nodos del árbol. Es un algoritmo de la familia de los algoritmos basados en fuerzas, conocido popularmente como Spring Embedder (resortes embebidos). Este algoritmo consiste en lo siguiente: cada arista es, en realidad, un resorte, —es decir, un muelle— que tiene una longitud dada. Cada pareja de nodos no conectados, se unirán con una arista ficticia que también modelará a un resorte. Las aristas verdaderas serán resortes de atracción, y las aristas ficticias serán resortes de repulsión.Las posiciones de los nodos se inicializan aleatoriamente, y se unirán con muelles de la forma indicada. Cada resorte intentará volver a su posición inicial, generándose un sistema de fuerzas que buscará una situación de equilibrio. Es como si forzaramos una serie de puntos unidos con muelles, algunos estirados y otros comprimidos, y luego tiraramos el conjunto al aire. El gráfico anterior ilustra bastante bien su comportamiento, dando finalmente una visualización elegante del árbol.Algoritmo basado en intervalos de coloresEste algoritmo es invención mía, y funciona de la siguiente forma: a cada nodo se le asigna un intervalo de colores, y se colorea con el centro de dicho intervalo. Dicho intervalo se parte en tantos subintervalos como hijos tenga el nodo, y, análogamente, se colorea con su centro. Se procede recursivamente para todo el árbol, siendo el intervalo de la raíz del árbol el propio cubo RGB (y por tanto, la raíz del árbol será de color gris, pues es el centro del cubo).La forma de partir cada intervalo es el siguiente. Partiendo del cubo RGB asignado a la raíz, primero se elige para particionar la dimensión R —es decir, la del color rojo—. Así, si la raíz tiene n hijos, el cubo se partirá en n rectángulos 3D, donde el ancho en la dimensión R de cada rectángulo 3D será el ancho del nodo raíz dividido entre 'n'. Para el siguiente nivel, cada cubo se partirá en la dimensión G, luego en la B, luego nuevamente en la R, y así sucesivamente.La idea de éste algoritmo es que cada nodo sea dueño de una región, del cubo RGB de la que ninguno de sus hijos podrá escapar. Así, aunque en los primeros niveles haya saltos en la gama de colores —sobre todo si cada nodo tiene pocos hijos—, a medida que se incrementa la profundidad la gama de colores de nodos relacionados será mas homogénea, y el propio coloreado será un indicador gráfico de la cercanía entre nodos.Aspectos por cambiar o mejorarHay todavía muchas cosas importantes por mejorar en la aplicación. El más importante por ahora es que la aplicación no cuenta con ninguna base de datos externa. El árbol está creado nodo a nodo en el fichero program.cpp, es decir, embebido en el propio código. Este es quizás el siguiente aspecto crucial de la aplicación, tener una base de datos externa, y crear la visualización del árbol leyendo los datos a partir de dicha base de datos. Seguramente usaré posgreeSQL.Otros aspectos menores son referidos, por ejemplo, al peso de las aristas. Por ahora, cada arista tiene el mismo peso, que viene indicado en el propio algoritmo basado en resortes —en realidad, no existe aún ninguna clase arista que tenga un atributo peso, sencillamente es una pareja de nodos—. Habrá que asignar un peso a cada arista, usando algún criterio relacionado con el árbol filogenético —por ejemplo, proporcional al número de nietos que tenga un hijo—, y adaptar el algoritmo de resortes para que éste cambio no produzca efectos indeseables en la visualización.Otro aspecto a cambiar es el posicionado del árbol. El árbol entero es movido según el sistema de fuerzas que provoquen los resortes, y habrá que cambiar el algoritmo para que, al menos la raíz, quede fija en un punto dado, porque a veces el árbol se mueve demasiado hacia un extremo y hay que mover la cámara para volver a centrarlo.Hasta otra ...

Hoy vamos a ver los modelos de los sensores utilizados y como se conectarían.
En primer lugar, tenemos el sensor de temperatura que utilizaremos el modelo MCP9700, que posee tres patillas, la patilla 1, de la izquierda se corresponde con la entrada del voltaje , la patilla 3, de la derecha se corresponde con la salida a GND y la patilla 2, de en medio sería los datos de la temperatura. Sobre como recibimos los datos, será según su linealización que hablaremos luego.
En segundo lugar, tenemos el sensor de humedad que utilizaremos el modelo 808H5V, que posee tres patillas, la patilla de la izquierda, con el simbolo – se corresponde con la salida a GND, la patilla de la derecha, con el simbolo + se corresponde con V+ que es la entrada del voltaje y la patilla de en medio con el simbolo V se corresponde con la salida de los datos de la humedad. Sobre como recibimos los datos, será según su linealización que hablaremos luego.
En tercer lugar, tenemos el sensor de movimiento que utilizaremos un modelo PIR de Parallax, que posee 3 pines, el pin -, que corresponde a la salida GND, lo conectamos directamente a GND, el pin +, que corresponde a la entrada del voltaje, lo conectamos al pin de salida del arduino 4 y el pin OUT, que corresponde a la salida de los datos, lo conectamos al pin de entrada del arduino 2.
Su explicación es la siguiente, si el sensor no recibe ningún movimiento, todo el voltaje pasaría del pin + al pin -, si percibe que se produce movimiento, pasaría del pin + al pin OUT, recibiendo los datos la placa arduino. La conexión del pin + a una salida de la placa arduino es para tener la opción de inhabilitar el sensor de movimiento por el usuario.
Por último, tenemos el sensor de luminosidad que utilizaremos un modelo LDR genérico, para su conexionado usaremos una resistencia de 1KΩ que tendrá como entrada los 5 V proporcionado por la placa arduino y dos salidas, una para dicho sensor como entrada y la otra para el pin 4 de las entradas de la placa arduino. El LDR, tendrá como salida a GND de la placa arduino.
Su explicación es sencilla, si existe luminosidad casi todo el voltaje pasa por el sensor, pero si comienza a haber ausencia de luz, el sensor no permite el paso del voltaje por su lado y pasaría todo el voltaje hacia el pin 4 de entrada de la placa arduino. Las patillas del LDR son iguales por lo que no importa como colocar una y la otra.
Además usaremos leds, que se conectarán facilmente, la patilla más larga, positiva, a la salida de la resistencia de 220 Ω que le perteneza y la patilla más corta, negativa, a GND.
Sobre las resistencias no entraremos en detalle porque su conexión es indiferente por cada patilla, pero si será necesario saber a que corresponde cada color, que podemos ver en la siguiente imagen:

Buenas,
Para la realización de la primera versión, empezamos con el nodo sensor. Utilizaremos un arduino duemilanove, en dicho nodo vamos a integrar los sensores de temperatura “modelo MCP9700″, humedad “modelo 808H5V”, movimiento por infrarrojos “PIR” y luminosidad “LDR” y una serie de leds para comprobar su adecuado funcionamiento.
Debemos de saber que antes de cada led, conectaremos una resistencia de 1/4 Ω, para los sensores no sera necesario ninguna resistencia, además será necesario una resistencia de 1 k Ω para usarlo con el sensor de luminosidad que mas adelante explicaremos.
Como podemos ver en la imagen, cada led posee una entrada que es uno de los pines de salida del arduino, siendo controlado por este el encendido y apagado, además uno de los pines de salida es quién hace funcionar el sensor de movimiento. En cuanto a los pines de entrada, cada uno es para los sensores, para saber su estado en todo momento.
Debemos tener en cuenta que hay que añadir a los nodos el modulo xbee, para la comunicación inalámbrica, que simplemente es colocarlo encima de la placa arduino.

¡¡Feliz navidad a todos!!
Queremos acabar el año demostrando todas las esperanzas que tenemos puestas en este proyecto y por eso deciros que nos vamos a presentar al concurso 49k.es (al que por cierto le quedan poco más de 22horas para cerrar el plazo).
Si no sabéis lo que es, en este video de 3minutos lo explican perfectamente:
Para este concurso hemos preparado este video que re-utilizaremos para presentar la aplicación en la web.
Muchas gracias a @annalogik por poner la voz y ayudar a crear el story board del video, a James por la traducción de los subtitulos al inglés y a @pepit4 por el diseño del logo de momento provisional (yo @hhkaos también he aportado mi granito de arena creando los dibujos de la aplicación y ayudando a montar la voz y el video). Por supuesto también gracias a todos los que nos retwitteais y nos ayudáis a difundirlo.
Esperamos que os guste:
Ah! y si os gusta, por favor, votadlo y comentadlo!

Una forma más o menos sencilla de tener una sonda es usar un móvil de última generación, estos disponen de GPS, GSM/GPRS/3G, Acelerómetros y/o giroscopios, cámaras con posibilidad de grabar vídeo (a veces incluso HD), etc.
Lo único que les haría falta es una transmisión radio con mayor alcance que la red móvil y ya trendríamos practicamente toda la sonda (exceptuando los sensores, claro). Y esto es lo que han hecho algunos ingenieros de Google, han cogido varios telefonos Nexus Galaxy S y los han puesto en 7 sondas. El resultado se puede ver en las imágenes y vídeos que ha grabado al efecto:
- blog: Android in Spaaace!
- Imágenes: Android in Space
Nos enteramos de la noticia gracias a este post de Abadía Digital.

Buenos pues hoy, después de los exámenes y todo el lio, he empezado a montar.
Lo primero que he hecho ha sido montar el sensor de temperatura y comprobar que funciona.
Para el sensor he utilizado un LM35 (2,25€) y una resistencia de 100K. Todo esto alimentando la placa con un cable USB al portatil.
Aquí os dejo una foto del codigo y otra del aparato en cuestión.

En la mayoría de videojuegos en tercera persona, la dirección hacia la que se mueve el personaje depende de la orientación de la cámara. A pesar de que Sion Tower es un tower defense, controlamos a un personaje en tercera persona y, por tanto, debía incorporar este sistema. Estos días he estado exprimiendo los sesos

Una de las posibilidades que tiene la sonda es grabar vídeo desde las alturas.
Tener un vídeo del vuelo a la vez que los datos que va recogiendo la sonda nos puede dar una perspectiva mejor de lo que está pasando en cada momento. Sin embargo se nos plantea un problema, transmitir vídeo implica una gran cantidad de datos a transmitir por lo que o tenemos un ancho de banda importante (incompatible con la legislación de las frecuencias ISM).
Para distancias cortas (<1km) no tenemos tanto problema, podemos usar alguna de las frecuencias de ISM que se reservan para datos en banda ancha (en 868MHz serían desde 869.7MHz a 870MHz), estas frecuencias tienen el inconveniente de que tienen muy limitada la potencia a la que se puede transmitir (5mW de potencia radiada aparente (1)), pero tenemos una disponibilidad del 100% del canal (300kHz), aunque tendremos más posibilidades de sufrir interferencias.
Para largas distancias, al necesitar mayor potencia de transmisión, nos tendríamos que situar en la banda de 869.4MHz a 869.65MHz que nos permite una transmisión de hasta 500mW (de PRA) pero solo un 10% de tiempo de ocupación del canal, por lo que tendremos que:
1.- reducir el tamaño del vídeo,
2.- reducir la velocidad de reproducción (fps)
3.- y/o comprimir el vídeo.
Reducir el tamaño del vídeo es relativamente fácil, lo único que necesitamos es que un sensor que capte distintos tamaños o descartar parte de la imágen para quedarnos con un tamaño menor (siempre que el sensor nos envíe los datos en RAW).
Reducir la velocidad de reproducción tambien es fácil (relativamente), sólo necesitamos descartar los frames intermedios. Aquí tenemos un problema ¿cuántas imágenes por segundo necesitaremos?, si utilizamos el vídeo para controlar un aparato (por ejemplo un cóptero) nos interesará tener tiempo real (25-30fps), sin embargo si sólo queremos tener una panorámica del entorno podremos transmitir con mucha menos frecuencia (1-2fps).
Comprimir el vídeo resulta más complicado que las anteriores, para esto necesitaremos un hardware independiente que nos haga el trabajo (existen drivers para sensores de cámara que ya lo hacen automáticamente) o un hardware bastante más potente que el que usamos (un PLD o FPGA, o un procesador ARM9 por ejemplo), sin embargo esto suele chocar con las necesidades de bajo consumo que tenemos. Si la frecuencia de envío es pequeña (1-2fps) podemos comprimir las imágenes como independientes (.jpg) que reduce los requerimientos de hardware para hacerlo, sin embargo no es la mejor opción.
Otra solución es no transmitir el vídeo, sino registrarlo para realizar el post-procesado, de esta forma podríamos tener un vídeo en alta calidad que sincronizaríamos a posteriori con los datos recibidos. Para ello únicamente tenemos que poder interactuar con la cámara que utilicemos, una opción que hace sistemasorp en este post.
De todas formas transmitir vídeo no excluye una segunda cámara registrando todo el viaje.
(1) La potencia radiada aparente es aquella potencia con la que habría que alimentar una antena dipolo λ/2 para que, en un punto determinado del espacio, crease la misma intensidad de campo que un transmisor determinado, con ambas antenas dirigidas en la dirección de máxima radiación. (PRA (dBm) = Pt(dBm) + Gd (dBi) – 2.15dB)

Ha sido publicada en la sección descargas una nueva versión de JavaDiKt. Esta versión incluye muchas mejoras y soluciona varios bugs, se han añadido además las referencias de kanjis contenidas en el “Kanji Basic Book vol 1&2″, que son los libros usados en las clases de Japonés del Instituto de Idiomas de la Universidad de… Continuar leyendo »