Planet

¡El proyecto Meshias vuelve! por tercera o cuarta vez ya, y esperamos que esta vez sea para terminarse, si es que un proyecto de software se puede acabar. Después de muchos parones en el proyecto lo vuelvo a coger con mucha ilusión y esperanzado en sacar alguna versión útil a gran escala. En esta nueva etapa estoy yo solo, Alejandro Castaño del Castillo y es mi proyecto de fin de carrera; aunque espero que durante el desarrollo esto no siga siendo así. Me encantaría que la gente le interesase el proyecto y colaborara de cualquier manera posible: opinando, comentando, probando, programando, etc. ¡Cualquier manera es buena! Y que mejor forma de conseguir colaboración  que inscribiéndose en el  http://www.concursosoftwarelibre.org/. Aún estás a tiempo de inscribirte en http://www.concursosoftwarelibre.org/1011/inscripcion. Desde este blog deseamos un happing coding! a todos los participantes.
El blog será actualizado más asiduamente y será utilizado para algo más que para avisar de cambios en el código. Espero postear resultados de pruebas realizadas en entornos controlados y entornos reales, conclusiones obtenidas, mucha documentación creada de este proyecto y de otros similares, investigaciones sobre otros protocolos e implementaciones, etc.
Bueno esto es todo por ahora, pero tendrán noticias pronto.

Desde hoy, se puede obtener el paquete Debian de la versión más reciente del proyecto desde el repositorio de paquetes Debian de la asociación SUGUS (http://sugus.eii.us.es). Este repositorio será el oficial del proyecto. La dirección del repositorio es “deb http://sugus.eii.us.es/debrepo sugus main”. Una vez añadido el repositorio en la distribución de Linux basada en Debian que se desee, basta con ejecutar la orden “apt-get install unimail” como administrador en una terminal para descargar e instalar el programa.

Para poder probar todo lo contado en las anteriores entradas era necesario tener un elemento externo a los ya explicados que fuera el encargado de realizar la conexión entre los MMDevices.Para ello, desarrollé un pequeño (¡58 líneas!) programa en Python que únicamente solicitaba la conexión entre dos MMDevices, que eran pasados en forma de stringfied proxies al programa mediante argumentos.Además, siguiendo las directrices de AVStreams, también se debía crear un objeto de la clase StreamCtrl (control del flujo), que a su vez debería estar accesible públicamente. Esto último se ha "obviado" en cierto modo, ya que el programa termina nada más establecer la conexión entre los dos extremos, por lo que el objeto de tipo StreamCtrl desaparece al poco de ser creado. A fin de cuentas, este programa es el que pretendo utilizar para realizar algunas pruebas automáticas a los elementos del sistema (cosa que entrará, si FSM quiere, en otro post).Ahora, vamos a utilizarlo...Descarga de argos_configComo el resto de Argos, se puede encontrar en el repositorio Mercurial:$ hg clone http://arco.esi.uclm.es/~josel.segura/pfcDentro del directorio software/src/CliConfigurator está el ejecutable, que a la vez es el fichero de código fuente al tratarse de Python.Ejecución de argos_configPara ejecutarlo deberemos tener en cuenta que la sintaxis correcta para el comando es la siguiente:./argos_config [ICE options] A-Side-Proxy B-Side-ProxyLos argumentos A-Side-Proxy y B-Side-Proxy son intercambiables, ya que la conexión entre ellos se realiza igual independientemente de quien tenga el rol de sumidero y quien el de fuente.Los argumentos opcionales de Ice son los habituales vistos en los anteriores posts. Si no se pasa ninguno, argos_config intentará cargar el fichero de configuración Ice por defecto de Argos, que deberá estar en $HOME/.argos/ice_config (el equivalente a pasar como opción --Ice.Config=~/.argos/ice_config).Sobra decir que para poder probar esta herramienta de configuración será necesario tener dos MMDevices funcionando. Por ejemplo, se podría conectar una cámara Axis o un dispositivo V4L2 con un sumidero de vídeo en escritorio.

Desde hoy, el proyecto ya tiene cuenta en Twitter, con el ID “proyectounimail”. En Twitter iré anunciando muy brevemente (y enlazando con el blog) las novedades del proyecto.
La dirección del perfil del proyecto en Twitter es: http://twitter.com/proyectounimail

Tras un parón en mis entradas, vuelvo a la carga para contar como servir cámaras (o cualquier otro dispositivo) que funcionen utilizando la librería Video4Linux 2 (v4l2). Dentro de este grupo se engloban tanto cámaras USB, tarjetas capturadoras de televisión, TDT...Para desarrollar este servicio me he vuelto a apoyar del ya archi-comentado MMDeviceCreator. La implementación del V4L2Server se ha realizado en Python.El flujo multimedia del dispositivo V4L2 se sirve utilizando un servidor RTSP proporcionado por el proyecto Gstreamer. La implementación del servidor RTSP de Gstreamer, a día de hoy, es algo tosca, ya que no está integrado al 100% con el resto del framework, y además, a pesar de proveer unos bindings para Python que hubieran sido muy útiles para mi implementación, estos están poco/nada documentados y, por lo que he probado, son inusables a día de hoy.A pesar de ello he decidido utlizarlo en detrimento de otras alternativas como VideoLan VLC, ya que su servidor RTSP no era configurable tan a medida como promete, en un futuro, el de Gstreamer.Tras esta entrada sobre las tecnologías utilizadas, vamos al meollo del asunto:Servir un dispositivo V4L2 utilizando ArgosLo primero será obtener los ejecutables. Para ello y como siempre, debes descargar el código desde el respositorio:$ hg http://arco.esi.uclm.es/~josel.segura/pfcEn el directorio software/src encontraréis, entre otros, los directorios GstRTSPLaunch y v4l2Server. El primero de ellos contiene el código del servidor RTSP que vamos a utilizar, mientras que el segundo es la fuente de V4L2 de Argos.Compilar e instalar el servidor RTSPPara compilar el servidor RTSP necesitaremos tener instaladas las librerías de desarrollo siguientes:

• Gstreamer 0.10 (en Debian y similares, paquete libgstreamer0.10-dev)
• Gst-RTSP-Server 0.10 (en Debian y similares, paquete libgstrtspserver-0.10-dev)

Con ellos instalados, dentro del directorio GstRTSPLaunch indicado anteriormente, ejecutaremos:$ make$ make installEs posible que para el segundo paso (la instalación) hagan falta permisos de super-usuario.Otro modo de conseguirlo es a través del paquete Debian que se puede descargar desde el repositorio de Gnesis, añadiendo la siguiente línea al fichero /etc/apt/sources.list:deb http://babel.esi.uclm.es/gnesis sid mainTras añadir la línea solo hará falta hacer:# aptitude update# aptitude install gst-rtsp-serverEjecutando la fuente Argos de V4L2Para ello vayamos al directorio v4l2Server comentado anteriormente.Dentro de ese directorio está el fichero ejecutable "v4l2server.py". Al ejecutarlo podremos pasarle el fichero de configuración Ice de la forma habitual (con el argumento --Ice.Config=fichero) o bien dejarlo sin poner (toma por defecto el fichero de configuración de $HOME/.argos/ice_config).Dentro del fichero de configuración se deberán definir las siguientes variables de configuración:

• Ice.Default.Locator: el locator por defecto para la aplicación. Se utilizará para resolver nombres de proxies indirectos.
• Adapter.Endpoints: el endpoint que tomará el adaptador de objetos de la aplicación.
• Argos.MMDeviceDeployer: el proxy al servicio de negociación/creación de MMDevices comentado con anterioridad.

En el repositorio podéis ver un ejemplo de este fichero de configuración guardado con el (original) nombre de "config".Para ejecutar:$ ./v4l2server.py --Ice.Config=configPor ahora, y a falta de más pruebas, se supone que el dispositivo a servir es el ubicado en /dev/video0. A no mucho tardar añadiré la posibilidad de configurar esto desde el propio fichero de configuración.¿Qué está ocurriendo tras todo esto?Detrás de todo este "lío" lo que está ocurriendo es que el programa v4l2server.py está notificando al servicio MMDeviceCreator indicado su capacidad para servir un dispositivo v4l2. MMDeviceCreator creará un MMDevice y demás objetos asociados a las negociaciones de AVStreams.Cuando alguien "conecte" este MMDevice con otro que tenga la capacidad de renderizar un flujo (por ejemplo, el RenderApplet), ambos MMDevices comenzarán el proceso de configuración del flujo. Cuando le toqué, el MMDevice creado para nuestro v4l2Server preguntará a éste la cadena de conexión RTSP (u otro tipo de protocolo streaming que se implementara) y se la pasará al sumidero multimedia para que sea capaz de consumir dicho flujo.

Bueno, tal y como dije estoy trabajando en la nueva versión del Shield, además de alguna que otra sopresa más XD.
Podeis bajaros el Esquemático de ArCan V2.
Los cambios que he realizado son sencillos, y están explicados en el post anterior, además de lo que ya había dicho he decidido añadir un transceiver 485 que nunca está demás. Además esta nueva versión será un poco más económica ya que he eliminado los conectores atornillables que encarecían cada placa unos 4€. Además la shield será algo más chica y supongo que eso también podría abaratar costes.
Otra novedad importante, por sugerencia de IgorR, es el TVS para proteger el circuito de posibles picos en las líneas CAN.
No se si debería añadirle alguna cosilla más, como ya sabeis ha aparecido un competidor a ArCan,  SK Pung. Tiene algunas cosas que para mí son superfluas, pero dependiendo el usuario podría ser determinista. Me gustaría plantearos antes de fabicar la nueva versión varias questiones.

1. ¿Veis importante el conector para la microSD?
2. ¿Os parece interesante el conector para el GPS?
3. ¿Que conector preferiís, DB9 o atornillables?
4. ¿Os resulta interesante la salida para el display, y el joystick?

Además de todo lo escrito, si teneis alguna sugerencia ruego que participeis en el desarrollo de esta nueva versión del shield.

El Viernes pasado se hizo la primera BarCamp en Medialabs Madrid. Toda la información del evento está recogida en http://arduinobarcamp.jottit.com/ y también podéis ver el hilo en el foro de Arduino.
CoLe me convenció para preparar un video presentando ArCan en la BarCamp, aunque el tiempo estaba muy justo conseguí hacer algo, no con el acabado que me gustaría, pero bueno, espero que os sirva para conocer un poco mejor el proyecto.
Si tenéis alguna duda preguntadme ^^.
PD: El programita del PC está hecho con LabWindows CVI, se que no es gratuito, pero en su momento fue la opción más rápida y sencilla. Ahora estoy aprendiendo Java, así que es posible que rehaga la aplicación para poder compartirla con todos vosotros.

Siguiendo la veda iniciada en las dos entradas del blog anteriores, en esta entrada voy a presentaros RenderApplet.RenderApplet es un programa escrito en Python que utiliza el servicio MMDeviceCreator de negociación. El programa está escrito en forma de applet de escritorio para Gnome: al activarlo se registrará en el servicio de negociación y, a partir de ese momento, dicho servicio negociará en su nombre las conexiones AVStreams, pasándole a RenderApplet la cadena de conexión resultado de dicha negociación.La utilización como veis es bastante sencilla. Para poderlo probar sin necesidad de añadir el applet de escritorio también puede ejecutarse como aplicación "independiente" (aunque queda mucho peor :P).Al estar escrito en Python, el código fuente y el ejecutable es el mismo. Para obtenerlo, descargad mi repositorio con Mercurial:$ hg http://arco.esi.uclm.es/~josel.segura/pfcExplorar en el directorio pfc/software/src/RenderApplet/RenderApplet y encontraréis el código de la aplicación.Dos saboresComo he comentado anteriormente, el programa puede ejecutarse tanto como aplicación GTK normal y corriente y como applet de escritorio de Gnome.Si eliges utilizar esta segunda opción, deberás realizar, antes de instalar, una configuración para que Gnome sea capaz de encontrar el applet en la ruta de instalación. No instalo directamente en la ruta por defecto dónde lo encontraría por no ensuciar los directorios que gestiona muy bien tu sistema gestor de paquetes ;)Argos Render como appletSi te decides a instalarlo como applet, deberás realizar lo siguiente antes de instalar:

1. Instala el programa bonobo-activation-sysconf. En sistemas Debian-based se encuentra en el paquete libbonobo2-bin.
2. Ejecuta, como super-usuario, lo siguiente:

# bonobo-activation-sysconf --add-directory=/usr/local/lib/bonobo/serversDeberéis cambiar esta línea si habéis cambiado la ruta de instalación en el Makefile del prorgamaInstalandoPara instalar Argos Render Applet deberás ir, dentro del repositorio Mercurial, al directorio software/src/RenderApplet y ejecutar simplemente:$ make installEsto copiará todos los ficheros a sus rutas correspondientes.Haciendo que Gnome encuentre el appletSi vas a usar el applet deberás reiniciar el servicio de búsqueda de applets de Gnome para que busque los nuevos recién instalados y puedas añadirlos a los paneles. Para ello hay dos opciones:

• Reiniciar la sesión de tu usuario
• "Matar" los procesos "bonobo-activation-server" y "gnome-panel". Durante unos instantes desaparecerán todos tus paneles, pero a los pocos segundos volverán, tranquilo :)

Fichero de configuraciónComo aplicación Ice que se precie, lo habitual es pasarle los parámetros de funcionamiento (como el default locator o proxys que necesite utilizar la aplicación a través de un fichero de configuración. Si lanzamos la aplicación como programa (no como applet) tan solo deberemos pasarle cualquier opción en la forma habitual que Ice la "parsearía" (--Ice.Config=... --Ice.Default.Locator=...).Sin embargo, si se trata de un applet no podemos ejecutar y elegir que parámetros se le pasan al ser ejecutado, ya que esta ejecución la realizará el panel de Gnome. Por ello, el programa por defecto buscará en el directorio home del usuario un directorio que se llame .argos y, dentro de él, el fichero ice_config.Todas las aplicaciones de usuario que voy a desarrollar cogerán su configuración de ese fichero si no la encuentran entre los parámetros de ejecución, sí que sería recomendable que esté escrito desde ya con parámetros que puedan utilizar todos los programas. Un ejemplo mínimo sería el siguiente:Ice.Default.Locator=IceGrid/Locator -t:tcp -h peter -p 4061Argos.MMDeviceDeployer = MMDeviceCreator -t:tcp -h peter -p 15000Ejecución del programa

• Ejecución como applet: Sobre alguno de los paneles de Gnome pulsamos con el botón derecho del ratón en una zona libre y seleccionamos la opción "Añadir al panel". Se abrirá una ventana dónde podremos encontrar el "Argos Media Render Applet". Lo seleccionamos y le damos a "Añadir" y debería aparecernos un círculo rojo en nuestro panel (el applet).
• Ejecución como programa externo: vamos a la ruta del código fuente dónde está el programa o bien a la ruta de instalación (por defecto /usr/local/share/argos-render-applet) y ejecutar como un programa normal desde la terminal el fichero RenderApplet.py, pasándole como primer argumento la palabra "window". Aparecerá una nueva y pequeña ventana que incluye el mismo icono que podríamos ver en el panel si hubiéramos realizado la otra opción.

En ambos casos, una vez hecho esto, si pulsáis en el círculo rojo (o el icono que aparezca, depende del tema de iconos de Gnome) éste pasará a ser verde y significará que, si las configuraciones son correctas, el programa se ha comunicado con el MMDeviceCreator para que cree un MMDevice y el resto de elementos AVStreams necesarios para gestionar la configuración. Una forma de comprobar que todo ha ido bien es, en el programa icegrid-gui, conectar con el registry y observar los objetos bien conocidos: debería aparecer un nuevo objeto, de tipo ::AVStreams::MMDevice, llamado $USER_render (dónde $USER es el nombre de tu usuario en tu máquina).En la próxima entrada explicaré brevemente como utilizar un pequeño programa de configuración para poder conectar entre si un sumidero y una fuente multimedia, y poderle así dar un uso visual al applet.Hasta pronto :)

Como comenté en mi entrada anterior (Servicio de negociación), he escrito un servicio IceBox que proporciona, a aquellos clientes que lo necesiten, toda la negociación que puedan necesitar para realizar conexiones AVStream.En este post detallaré como instalar dicho servicio y como ponerlo en marcha. Allá vamos.InstalaciónPara instalarlo, en entornos Debian, solo habrá que tener esta línea en el fichero /etc/apt/sources.listdeb http://babel.esi.uclm.es/gnesis/ unstable mainy realizar lo siguiente:# aptitude update# aptitude install libmmdevicecreatorPara el resto de entornos GNU/Linux, libmmdevicecreator.tar.gz: este fichero contiene tanto la librería (fichero .so) como dos ficheros, nombrados "config" y "config_MMDCS", que serán explicados en el siguiente punto.Puesta en marchaComo el resto de servicios implementados utilizando las ventajas de IceBox, para lanzarlo solamente hará falta escribir un par de ficheros de configuración: en uno de ellos, que será el que acepte el ejecutable de IceBox, se describirá como debe lanzarse el servicio (nombre de la librería, versión, orden en el caso de lanzarse varios servicios a la vez...). El otro fichero de configuración se le pasará al servicio propiamente dicho, y tendrá las variables que necesite para su ejecución. Estos ficheros se corresponden, respectivamente, con los que encontramos en el tarball.Para lanzar el servicio, lo primero, deberemos tener la librería en una ubicación bien conocida para el ejecutable de IceBox. En el caso del paquete Debian no habrá ningún problema, pero en el caso del tarball deberemos copiar el fichero .so a /usr/local/lib o bien hacer que la variable de entorno LD_LIBRARY_PATH contenga el directorio dónde se encuentre el fichero.El fichero "config" tiene tan solo la configuración del "Default Locator" de nuestro entorno y la configuración de carga de la librería:Ice.Default.Locator=IceGrid/Locator:tcp -h peter -p 4061IceBox.Service.MMDCS=MMDeviceCreator:createService --Ice.Config=config_MMDCSCon esa configuración definimos un servicio IceBox llamado "MMDCS", el cual intentará cargar la librería "libMMDeviceCreator" a través de su punto de entrada "createService", pasándole la configuración del fichero config_MMDCS.Este otro fichero es el que configura realmente el servicio, y además de la configuración del Default Locator, deberá incluir la configuración del endpoint para el MMDeviceCreatorAdapter, el proxy al PropertySetDefFactory, que nos proporciona el servicio de propiedades, y un par de variables Registry.username y Registry.password que contendrán, si los hubiera, el nombre de usuario y la password administrativa del Registry al que estamos conectados.Para lanzarlo:$ icebox --Ice.Config=configAl lanzarlo, obtendremos por la salida en el terminal algo como lo siguiente:[INFO] [MMDevice Creator] Starting service[INFO] [MMDevice Creator] PropertySetDefFactory proxy: PropertySetFactory -t @ AutoPropertyService.Adapter[INFO] Negotiator -t:tcp -h 192.168.1.2 -p 15000Esa última línea es la que los clientes deberán utiliazr para poder utilizar el servicio. Si se realizara un despliegue a a través de IceGrid, este ñultimo proxy sería un objeto bien conocido, por lo que el acceso para los clientes sería más sencillo aún.En la próxima entrada os contaré como utilizar el primer cliente que hice para este servicio: un sumidero que se activa a través de un applet de escritorio y que, por ahora, podréis probar con una cámara Axis, si es que la tenéis claro :P

Durante el desarrollo de Argos, poco a poco, me he ido dando cuenta que ciertas partes del código se repetían en los diferentes elementos que conforman el sistema. En concreto, todo el algoritmo denegociación de AVStreams se repetía en cada elemento fuente o sumidero, lo cual implicaba la re-escritura del código en diferentes lenguajes y, además, tener duplicado dicho algoritmo en diferentes ubicaciones.A raíz de este "descubrimiento" empecé a pensar en simplificarlo: si la negociación siempre se hace de la misma forma, dando los mismos pasos, ¿por qué no hacer un servicio que se encargara de ella? Empecé así a escribir un servicio que permitiera a cualquier sumidero ser anunciado/publicado en el sistema y realizar la negociación escribir una sola línea de AVStreams en el mismo, delegando todo ello en ese servicio.Tras realizarlo, observé que la idea era fácilmente adaptable para acoger no solo a los elementos que quisieran actuar como sumideros, si no también a aquellas fuentes que así lo quisieran.De esta idea, surgió poco a poco el servicio que por ahora llamo MMDeviceCreator (se admiten sugerencias en el nombre :D). Este servicio proporciona a sus clientes la posibilidad de delegarle totalmente la negociación de la conexión AVStream. El programador de un elemento solamente tendrá que preocuparse de escribir como proporcionar el flujo multimedia (o como consumirlo, en el caso de los sumideros) y "decirle" al servicio que capacidades tiene (de la misma forma que AVStreams hace para negociarentre dos extremos de conexión). Con ello, y solamente definiendo un nuevo fichero de interfaz slice, se desacoplaba la negociación del flujo propiamente dicho, y de paso, se permite que la implementación final esté realizada en el lenguaje que queramos (siempre que sea compatible con Ice, por supuesto).El servicio ya está "terminado", aunque en fase de pruebas. Ya he realizado la puesta en marcha de algunos casos de uso y he implementado un sumidero y una fuente que utilizan el servicio, pero estos serán material para próximas entradas.