Planet

Terminada la primera versión de la rama 1.x del programa. Esta nueva versión supone un avance significativo respecto de la primera versión disponible, principalmente el manejo dinámico de la memoria, eliminación de las limitaciones respecto de las variables y las conectivas, y un algoritmo de evaluación que es una solución general al problema.
Las nuevas características que incorpora son las siguientes:

• Código fuente modular.
• Mensajes y menús en Inglés.
• Reserva dinámica de memoria.
• Dimensión de las matrices libre (limitado por la memoria disponible).
• Posibilidad de definir nuevas conectivas y de borrar las ya existentes.
• Posibilidad de guardar las matrices en un archivo externo. Éstas se guardan en formato de tabla simple, legible tanto por una persona como por un ordenador. Pensado principalmente para guardar las matrices definidas y para una futura opción de cargar las matrices desde archivos externos que se puedan editar con un editor de texto corriente.
• Las variables son registradas por demanda.
• Menús rediseñados. Mejorada la robustez de la entrada de datos.
• La detección de las fórmulas bien formadas en notación polaca se efectúa en función de los datos proporcionados por el usuario según la convención que se comentó en un post anterior: cualquier letra mayúscula es una conectiva, cualquier letra minúscula es una variable.
• Mejoras en la detección de errores en fórmulas mal formadas.  Creado un parser que transforma una fórmula bien formada en notación polaca en una estructura de datos tipo árbol.
• Algoritmo de evaluación general. Las fbf’s individuales se evalúan mediante la estructura en árbol (evaluación independiente de la notación empleada), todas las posibilidades se calculan en función de la dimensión dada y de las variables definidas por el usuario (independiente de valores predefinidos).
• Posibilidad de seleccionar los valores mostrados en la evaluación, entre: todos, valores designados o valores no designados. También se muestran estadísticas a continuación de las fórmulas evaluadas.

Con el proyecto 3signos quiero crear una red social orientada a hablantes de la lengua de signos, tanto sordos como intérpretes.
Antes de nada aclarar un tema importante: no tengo pensado llamar discapacitados auditivos a los sordos. No me gustan los eufemismos y espero que nadie se indigne por este motivo.
¿Que porque hago este proyecto? Vamos a ver: existen diccionarios de lengua de signos, decenas de webs orientadas a ello, vídeos en youtube, etc… En la red se puede encontrar contenido de sobra, los sordos son gente creativa a la que le gusta expresarse. El problema es que muchas de esas webs se han quedado obsoletas, la llamada web 2.0 ha cambiado la manera de usar internet, se ha pasado de sitios con contenido estático a sitios alimentados por el contenido generado por los usuarios. 3signos pretende ser un sitio en el que su principal activo sea el contenido generado por los usuarios.
¿Que tecnologías se van a usar? Pues como no me sobra tiempo ni paciencia en un principio parecía buena idea usar el framework Django. Con este framework uno se ahorra tiempo de desarrollo, mas o menos el tiempo que emplea leyendo manuales… En fin, nadie ni nada es perfecto. Como reproductor de vídeos se usa FlowPlayer, ffmpeg para la conversión de videos y Jquery para hacer guarradas en AJAX/JavaScript.
¿Para cuando? Pues la primera beta saldrá a mediados de Enero, de todas maneras los valientes pueden descargarse el código fuente de la forja. El código se libera bajo licencia GPL.
Por cierto, este proyecto esta inscrito en el concurso universitario de software libre. Hay poco que perder y de esperanza también se vive.
Saludos a todos!

Una vez que ya tenemos estudiado el canal físico que utiliza X10 vamos a avanzar un poco mas, viendo como hace para trasmitir este protocolo.
Estructura del mensaje:
Un mensaje completo en X-10 está compuesto por el código de comienzo (1110) o Start Code y puede usarse para alertar al producto O.E.M. del código que emitirá a [...]

Hemos empezado a realizar pruebas con el módulo de comunicaciones de Locator. Ahora mismo nuestra prioridad es hacer que funcione el “ensamblado” de Arduino + TelitGM862; que podamos leer los datos que nos proporciona el chip GPS de Telit y que podamos acceder al módulo GSM/GPRS.
En el caso del chip GPS la primera decisión que debemos tomar es que “formato de sentencias” vamos a utilizar para recibir la latitud y la longitud y algún dato extra.
El estándar NMEA 0183 (el que esta implementando en nuestro chip GPS ) soporta varios formatos:

• * AAM - Waypoint Arrival Alarm
• * ALM - Almanac data
• * APA - Auto Pilot A sentence
• * APB - Auto Pilot B sentence
• * BOD - Bearing Origin to Destination
• * BWC - Bearing using Great Circle route
• * DTM - Datum being used.
• * GGA - Fix information
• * GLL - Lat/Lon data
• * GRS - GPS Range Residuals
• * GSA - Overall Satellite data
• * GST - GPS Pseudorange Noise Statistics
• * GSV - Detailed Satellite data
• * MSK - send control for a beacon receiver
• * MSS - Beacon receiver status information.
• * RMA - recommended Loran data
• * RMB - recommended navigation data for gps
• * RMC - recommended minimum data for gps
• * RTE - route message
• * TRF - Transit Fix Data
• * STN - Multiple Data ID
• * VBW - dual Ground / Water Spped
• * VTG - Vector track an Speed over the Ground
• * WCV - Waypoint closure velocity (Velocity Made Good)
• * WPL - Waypoint Location information
• * XTC - cross track error
• * XTE - measured cross track error
• * ZTG - Zulu (UTC) time and time to go (to destination)
• * ZDA - Date and Time

De todos los que hay ahí el más completo es el formato GGA, el cual además de incluir información de localización muestra información sobre los satélites, altitud, etc.
Pero recordemos que nosotros vamos a transmitir la información por GPRS y que dicha conexión es lenta y cara.
Por tanto tenemos que optar por un formato de datos que nos permita localizar al portador de Locator, simplemente eso, que por ahora es lo que queremos.
Por ello nos hemos decantado por el formato RMC (recommended minimum data for gps ) Este formato nos proporciona:

• Posición ( Latitud - Longitud )
• Velocidad
• Fecha (UTC)

Más que suficiente ( por ahora ) para hacer un seguimiento a algo que se este movimiento
La segunda parte viene en que hay que configurar el chip GPS para que solo muestre los datos por ese formato, ya que por defecto y según especificaciones del fabricante:
By Default the NMEA serial port (on pins 35 and 41) provides the following sentences:
GGA, GSA, GSV, RMC.
Tras revisar la documentación del módulo GPS encontramos la siguiente forma de desactivar los demás “formatos de sentencia”:
/* Código en Arduino
// Configuramos el modulo GPS para que solo nos muestre los datos en formato RMC ( Recommended Minimum Specific GNSS Data)
serialGPS.println(”$PSRF103,05,00,00,00″);
serialGPS.println(”$PSRF103,03,00,00,00″);
serialGPS.println(”$PSRF103,02,00,00,00″);
serialGPS.println(”$PSRF103,01,00,00,00″);
serialGPS.println(”$PSRF103,00,00,00,00″);
//Activamos el modo RMC
serialGPS.println(”$PSRF103,04,01,00,01*25″);
*/
Nota: si deseas revisar la configuración de manera mas específica te aconsejamos que mires el código de Locator en el repositorio SVN.
      

LongoMatch es una aplicación multimedia para realizar análisis técnico/tácticos por vídeo de encuentros deportivos. Esta pensado para ayudar a los entrenadores a indentificar las jugadas clave de un partido y organizarlas por categorías para poder recuperlas de una forma fácil con un simple click. Se crea una base de datos sobre el partido en la cual se pueden ir agregando jugadas delimitadas por un tiempo de inicio y un tiempo de fin. Estas jugadas se identifican mediante un nombre y se agrupan por categorías, como por ejemplo: goles, faltas, defensa 1 contra 1, presión de los delanteros, salidas de fondo, corners, etc… Las jugadas se pueden editar sobre una línea temporal para tener una representación gráfica del partido. Además añade soporte para listas de reproducción (para realizar un resumen de un partido, por ejemplo) y edición no-linear (para poder crear un nuevo video con las jugadas seleccionadas).
En el aspecto técnico, LongoMatch está escrito en C# y corre bajo Mono (ahora me arrepiento por cuestiones éticas, pero era un lenguaje con el me sentía muy cómodo al ser similar a java y su entorno de desarrollo me pareció muy práctico). El interfaz gráfico usa las librerías GTK, la base de datos está implementada con db4o (una base de datos puramente orientada a objetos) y el  backend multimedia está implementado usando el motor de GStreamer.
Una de las carácteristicas importantes del proyecto es que es multi plataforma. La idea es que use el mismo código tanto en Linux como en Windows, lo cual es un reto en el tema referente a GStreamer ya que pocos proyectos han podido portarlo de forma satisfactoria a Windows (pienso en songbird y elisa).
En la siguiente entrada comentaré el estado actual del proyecto y qué se pretende hacer durante el concurso…
      

He solucionado el problema mencionado en el anterior artículo.
Se trata de las rutas relativas de los archivos. Las rutas relativas parten de un directorio llamado “directorio de trabajo” y se supone que dicho directorio es aquel donde se está el programa ejecutado. El problema es que en Windows, el directorio de trabajo no es aquel donde está el programa, sino aquel donde está Python instalado, por lo que el código no funcionaba bien en dicho sistema.
La solución que he encontrado es una función que te devuelve el directorio donde está el programa ejecutado, independientemente del sistema en el que se esté, tanto si coincide con el directorio de trabajo como si no. Al obtener el directorio donde está mi programa, puedo trabajar ya correctamente con los archivos y directorios del programa.
Por lo tanto, el problema queda solucionado. Sólo lo he comprobado en Linux y en Windows, así que, puedo garantizar su funcionamiento en ambos sistemas.
En cuanto termine otras pruebas, publicaré la versión 0.2.
      

Cuando decidimos seriamente el empezar con el desarrollo de un videojuego libre, lo primero sobre lo que empezamos a investigar, fué sobre los distintos motores gráficos libres, ya que, en lo que respecta al lenguaje en el que lo íbamos a programar, resultaba evidente que iba a ser C++. En ...

Locator es un proyecto emprendido por Adrián Yanes y Martín Gómez, que participa en el III Concurso Universitario de Software Libre.
El proyecto consiste en ensamblar y programar un hardware que retransmita vía GSM/GPRS los datos de la localización donde se encuentra. Expresado de manera sencilla podemos decir que Locator es un “GPS en remoto“.
La pregunta que se hace mucha gente es:
¿de que me sirve saber la localización de algo en remoto?
He aquí el ejemplo de las ambulancias.
Supongamos que tenemos 30 ambulancias. Cada una tiene un locator instalado. Ocurre una emergencia en X sitio. Automáticamente si hay seguimiento activo el software de Locator (el cual estaría instalado en este caso en el centro donde se gestionan las emergencias ) sabe donde se encuentran las ambulancias, tan solo es necesario comprobar cual de las 30 esta mas cerca de la emergencia y avisar a esa directamente, en vez de mandar la señal vía radio y que aparezcan 3 ambulancias en un sitio cuando solo se necesita 1.
Con esto se soluciona ( en el caso del ejemplo ) que acudan en vez de 3 ambulancias cercanas , la más cercana, consiguiendo así que si por ejemplo había 3 cercanas, 2 de ellas queden disponibles puesto que la emergencia esta cubierta.
Visto el ejemplo pasemos a la parte técnica.
Actualmente hay muchos dispositivos que permiten localizar vehículos. Hasta la fecha no conocemos de ninguno que permita localizar y además trazar rutas en remoto hacia otros puntos.
Estos dispositivos tienen elevados costes y rara vez utilizan un seguimiento activo.
Locator pretende que una persona / entidad pueda saber la posición del portador del objeto ( véase vehículo o persona ) en cualquier momento.
No debemos confundir la funcionalidad del dispositivo y del software. Locator pretende optimizar recursos, no localizar a portadores que desconozcan que portan un Locator.
Para la realización del proyecto nos hemos decantado por una plataforma de hardware libre conocida como Arduino.

Los motivos son evidentes:

• -Hardware libre.
• -Muy buena documentación.
• -Bajo consumo.
• -Utiliza AVR-Libc
• -Bajo coste

Si quieres ver más características técnicas de Arduino puedes hacerlo aquí.
El módulo que hace las funciones GPS y de conexión GSM/GPRS es el Telit GM862, los motivos de esta elección están condicionados por esta premisa:
-Nuestro presupuesto es bajo, pero por suerte la gente de R4P tenía este mismo módulo sin usar, así que no los han cedido temporalmente ( ¡ gracias !).
Quitando esta primera condición indispensable el modulo Telit GM862 tiene las siguientes características:

• -Chip GPS SiRFstar III, el mismo que lleva mi GPS y que hasta la fecha me esta dando excelentes resultados.
• -Pila TCP/IP incorporada. Lo cual nos permite utilizar sockets, y a partir de ahí crear nuestro propio “protocolo” de transmisión de datos hacia el servidor.
• -Intérprete Python. Por ahora no le tenemos asignada ninguna función a este intérprete, pero apostamos a que la tendrá en un futuro cercano.
• -Cliente FTP/SMTP incorporado. Es obvio que ambos se pueden exprimir.
• -GSM QuadBand. Lo que significa que Locator podría funcionar con cualquier compañía telefónica del mundo (recordemos que necesitamos una conexión GPRS para transmitir datos).

Por ahora contamos con estos componentes hardware. Aunque ayer ya hicimos una pequeña lista de cosas URGENTES por comprar. Entre ellas están los conectores y antenas necesarios para el módulo de comunicaciones Telit.
Además de un adaptador de corriente para empezar a trabajar con ambos (Arduino + TelitGM862) a la vez. Esto lo explicaremos en un post mas adelante.
Recordar que el código fuente del proyecto esta bajo la licencia GNU General Public License v3. Así como la documentación lo esta bajo una licencia Creative Commons -BY-.
Si quieres acceder a la página de “oficial” del proyecto deberás ir a esta dirección:
https://forja.rediris.es/projects/cusl3-locator/
Si lo que deseas es ver nuestros progresos en lo que se refiere a desarrollo, deberás acceder al repositorio SVN que la forja de RedIris ha puesto a nuestra disposición:
https://forja.rediris.es/svn/cusl3-locator/
      

Actualmente estoy implementando la gestión de paquetes de Tucan, parte esencial para la automatización de descargas (también para subidas, aunque ahora mismo estoy centrado en las descargas), lo que me esta costando bastante mas de lo esperado.
No hay nada mejor para poneros en situación que un ejemplo concreto.
Imaginad que queréis descargar 3 capítulos de vuestra serie favorita, cada capitulo esta compuesto por 3 enlaces y esta subido a 2 servicios diferentes. Esto nos da 18 links diferentes para 9 archivos.
‘D.S02E01.part’
‘D.S02E01.part1.rar’
‘D.S02E01.part2.rar’
‘D.S02E01.part3.rar’
‘D.S02E02.part’
‘D.S02E02.part1.rar’
‘D.S02E02.part2.rar’
‘D.S02E02.part3.rar’
‘D.S02E03.part’
‘D.S02E03.part1.rar’,
‘D.S02E03.part2.rar’,
‘D.S02E03.part3.rar’.
Para que entendáis la dificultad del problema voy a describir brevemente los pasos necesarios para descargar los archivos.

1. Conseguir los links: Hay varias formas de pasarle los links a Tucan, podemos pegar directamente los links, o bien copiar el contenido de una pagina al portapapeles y al abrir la ventana de descargas, el contenido de todos los links sera parseado y pegado igual que si los hubiéramos copiado manualmente.
2. Comprobar que están soportados y que están activos: Para esto hacemos uso de los plugins y accedemos a la pagina como lo haríamos con el navegador obteniendo información adicional como el nombre del archivo (importante cuando no es parte del link como en el caso de megaupload) y el tamaño aproximado.
3. Crear los paquetes: En nuestro ejemplo queremos que los capítulos se descarguen en orden y además como usamos links intercambiables, algo bastante común para agilizar la descarga, queremos que se descarguen los archivos alternadamente y que no se descargue el mismo archivo en varios servicios.En este punto tenemos los links ordenados por servicios, así que tenemos que buscar que archivos están relacionados (esto se dice muy rápido pero no es algo trivial), finalmente con la parte común del principio de los archivos creamos el nombre del paquete.
4. Descargar los archivos: Una vez creados los paquetes ya solo tenemos que añadirlos a una cola e ir descargando en orden. Cuando un servicio no nos deje seguir descargando, tendremos que esperar el tiempo correspondiente, pero mientras podemos seguir descargando en otros servicios automáticamente.

Ya solo me falta implementar la cola de descargas, por lo que proximamente Tucan sera minimamente usable, sin embargo aun es pronto para empaquetar una version, por lo que si queréis probarlo tendréis que hacer un checkout del repositorio.
Un Saludo, Crak.
      

Debido a un fallo del programa, éste no se puede ejecutar correctamente en Windows (y puede que tampoco en otros sistemas que no sean Unix). En los próximos días intentaré corregir este problema, para luego publicar la versión 0.2.