Planet

Buenas de nuevo. Un día más, os traigo la descripción de una de las clases que componen la biblioteca que estoy desarrollando para Nintendo Wii. Hasta el momento, sabemos gestionar los Wii Motes, la pantalla, la tarjeta SD, y podemos crear nuestras propias texturas a partir de archivos de imagen. Hoy vamos a revisar una [...]

Como dije en mi anterior post, he realizado un estudio comparativo comparativo indicando ventajas y desventajas de los frameworks más importantes para lo que quiero realizar:

• JSF.
• PrimeFaces.
• My Faces JSF
• Extjs.
• Dojo.
• Flex.
• JavaFx Script.
• Silverlight.

El estudio es bastante completo, ya que en él se indican todas las características de los frameworks con sus ventajas y desventajas, resumiéndolo todo en una tabla comparativa.
La decisión final fue la librería de sencha ext.js, que como se puede ver en su página web, tiene una licencia doble, Open source si la aplicación es open Source (como es el caso) y de pago si la aplicación va a ser vendida.
Tomé esta decisión porque me pareció una librería muy buena visualmente, con grandes capacidades para grids(que es principalmente lo que necesito) además de mucha documentación y ejemplos ilustrativos.
El documento lo podéis encontrar  en este enlace: EstudioFrameworks, o accediendo directamente a la forja de ePlanning.
Aquí os dejo la tabla resumen, pero os recomiendo leer el estudio.
Cliente/Servidor
Gratuito/Pago
Documentación disponible
Ejemplos Disponibles
JSF
Cliente/Servidor
Gratuito
Si (ver apartado JSF)
-
PRIMEFACE
Cliente/Servidor
Gratuito
-
-
MYFACES JSF
Cliente
Gratuito
-
-
EXT.JS
Cliente
Gratuito
Si (ver punto LIBRERIAS)
Si (ver punto LIBRERIAS)
DOJO
Cliente
Gratuito
Si (ver punto DOJO)
Si (ver punto DOJO)
FLEX
Cliente
Gratuito
Si (ver punto FLEX)
Si (ver punto FLEX)
JAVAFX
Cliente/Servidor
Gratuito
Si (ver punto JAVAFX)
Si (ver punto JAVAFX)
SILVERLIGHT
Cliente/Servidor
Pago
Si (ver punto SILVERLIGHT)
Si (ver punto SILVERLIGHT)

For one reason or another, I have had to leave the project for a while, but here I am again. I only wanted to say that both the project and me are still alive. That said, there are going to be changes in my way of managing this project. Namely: Less and shorter posts. I [...]

Primera versión de desarrollo de la IMU. En cuanto tengamos una beta la subiremos en formato KiCAD o EAGLE:
IMU v0.0.1 (alpha 1)

Entre unas cosas y otras he tenido que dejar el proyecto durante un tiempo, pero aquí estoy otra vez.
Sólo quería decir que el proyecto y yo seguimos vivos.
Eso sí, van a haber cambios en mi forma de llevar el proyecto. En resumen:

• Entradas más breves y menos frecuentes. Me encanta escribir, pero todo el tiempo que dedique a escribir en el blog no lo estaré dedicando a tareas más necesarias para Sprite Hut y para mí.
• Más idiomas. Quiero practicar mi inglés. Y japonés. En cuantos más idiomas esté la información, más gente podrá leerla. Pero claro, ni domino todos los idiomas del mundo ni tendría tiempo para escribir en todos ellos, así que con dos o tres tengo trabajo de sobra.
• Menos diseño y más código. Creo que he sufrido un poco de parálisis del análisis en la fase de diseño. Una cosa es lanzarse a teclear código sin tener una remota idea de la arquitectura de la aplicación y otra querer dejarlo todo atado sobre el papel a la primera. Así que comentaré el diseño de cara a futuros colaboradores y a pelearse con Python, que va siendo hora (prototipo de la GUI aparte).

Eso es todo por ahora. Cambio y corto.

Nos hemos dado cuenta que habíamos empezado a trabajar ya en el desarrollo de la sonda y todavía no habíamos publicado una defición del proyecto en condiciones.
El proyecto NSd trata de construir una sonda meteorológica (sub-espacial) que mida parámetros de la atmósfera y pueda realizar fotografías de gran altitud. Constará de dos partes bien diferenciadas, la sonda propiamente dicha (encargada de la recogida y transmisión de los datos) y la estación de tierra (encargado de la recepción de datos y el procesado y presentación de los mismos).
Sonda
A su vez la sonda constará de 3 partes diferenciadas:
- La IMU (Unidad Inercial)
- Los sensores
- La parte de radiofrecuencia
IMU
La unidad inercial es el cuerpo de la sonda, se encarga de recoger los datos de posición y orientación de la sonda para contextualizar el resto de datos proporcionados por los sensores. Constará de:
- Un procesador.
- Un giroscopio (3 ejes).
- Un acelerómetro (3 ejes).
- Un magnetómetro (3 ejes).
- Un altímetro barométrico.
- Un GPS.
- Un sistema de almacenamiento.
De esta forma tendremos una medida muy completa y exacta de la posición y orientación de la sonda en todo momento. Además dado que queremos un sistema compacto el mismo procesador que tenga la IMU nos podrá servir para recoger los datos del resto de sensores y para transmitir la información a la estación de tierra.
Sensores
Los sensores irán repartidos en una o varias PCBs dependiendo de la necesidad de espacio que ocupen o de la posición en la que hayan de ir. Nosotros hemos escogido unos sensores para medida atmosférica, sin embargo el diseño podría tener otros sensores dependiendo del uso que se vaya a dar (ver la sección de aplicaciones):
- Una cámara (QVGA-VGA) a color
- Sensores de luz para los siguientes canales: rojo, verde, azul, ultravioleta (UV a 400-410nm), Infrarrojo cercano (IR a 850nm), Infrarrojo térmico (IR a )
- Humedad relativa
- Temperatura interna y externa.
- Gases: CO, CO2, O3
Radiofrecuencia
Como ya explicamos antes queremos enviar imágenes/vídeo y los datos de las medidas a la estación de tierra, para ello queremos emplear dos frecuencias:
- Imágen/Video + Datos → 868MHz
- Datos en formato APRS(1200bps) → 145,800 Mhz
El empleo de estas frecuencias es debido a que son en la banda de uso libre: 868MHz es para uso de dispositivos de “corto alcance” y 145,8MHz es de servicio de radioaficionado (1), si transmitimos en protocolo APRS podríamos conseguir que los aficionados de la zona de vuelo pudieran seguir la evolución de la sonda.
Módulo de recuperación
Suele ser interesante tener un canal de comunicaciones auxiliar para localizar la sonda en caso de perder el canal principal. Habíamos pensado en utilizar un módem GSM para enviar la posición una vez en tierra para recuperar la sonda. Para que fuera totalmente auxiliar debería funcionar de forma autónoma por lo que sería implementar una PCB independiente con:
- Un microcontrolador.
- GPS.
- Módem GSM.
- Alimentación independiente.
Sin embargo este módulo no es totalmente imprescindible, ya que tenemos el canal ARPS, por lo que podríamos no usarlo en caso que no tuvieramos tiempo de implementarlo todo.
Estación de tierra
La estación de tierra se encarga de recoger, procesar y presentar los datos. Dado que la sonda lleva un sistema de almacenamiento no es imprescindible hacerlo todo en tiempo real y podríamos espaciar las recepciones para reducir el ancho de banda y, por lo tanto, reducir las interferencias y el ruido (para aumentar la distancia de envío). La estación estará compuesta por:
- Sistema de posicionamiento.
- Sensorización en tierra.
- Recepción de la señal.
- Sistema de procesado y presentación.
Sistema de posicionamiento
El sistema de posicionamiento será un GPS, con ello podremos saber el recorrido del equipo de seguimiento de la sonda, en caso que esta vuele libre; o afinar la posición de la sonda a un error pequeño, en caso que esté fijada.
Sensorización en tierra
Es muy interesante conocer la presión barométrica en tierra, de esta forma se puede conocer la altura real de la sonda (y no sólo la altura barométrica) y así corregir el error del GPS. Sin embargo los sensores no se tienen porque limitar a eso; se podría tener, por ejemplo, una estación meteorológica completa.
Receptores de la señal
Es lo más importante de la estación de tierra, los receptores de los datos de la sonda nos permitirán saber la posición en cada momento y por lo tanto podremos recuperarla.
Sistema de procesado y presentación
Básicamente es un PC en el que se representarán los datos recibidos (tablas, hojas de cálculo, gráficos, mapas, etc.) y se procesarán (altura real en función de la barométrica, iluminación dependiendo del apuntamiento, etc.).
Si cuidamos un poco el diseño podemos reutilizar algunas PCBs (IMU como sistema de posicionamiento del equipo de tierra, etc.) por lo que bajaremos el precio.
(1) Fuente: Cuadro Nacional de Atribucción de Frecuencias

Por fin, que alegría cuando he visto salir los numeritos que me esperaba que salieran por pantalla, os dejo una imagen como hago siempre, que es como mejor se explican las cosas:
Ahora mismo está un poco cutre todo, pero bueno, lo importante es que se ve lo importante, si os fijais en el tablero y empezais a contar (desde 0) las intersecciones que hay hasta la piedra, os debe de salir el numerito que muestra la terminal, a ustedes no os hará ilusión, pero yo he saltado de alegría cuando coincidía
Un saludo !!

Ya detecto las intersecciones mejor, eso si, hay que tener en cuenta que el tablero está en una forma casi ideal, visto desde arriba, os dejo una foto para que veais la detección:

En el caso de que el tablero no se parezca al modelo ideal no funcionará bien, pero ya iré mejorandolo todo, la prioridad ahora mismo es que funcione.
Un saludo !!

He trasladado el contenido del blog a un nuevo dominio: http://blog.seguesec.com , desde allí podréis consultar a partir de ahora las nuevas entradas.

Últimamente hemos estado probando distintos tipos y estilos de APIs para el uso de Facebook. Tras los problemas que obtuvimos hace tiempo, finalmente hemos conseguido hacernos con una combinación de varias que nos permiten trabajar satisfactoriamente.
Estas son:
- RestFB (http://restfb.com/)
- Facebook-Java-API (http://code.google.com/p/facebook-java-api/)