Proyecto Fin de Carrera

Robótica, software y telecomunicaciones.

Información para programar

La información que podemos obtener en la API de Robocomp, en QTAssistant, o en la wiki de OpenCV es realmente útil y necesaria para mi PFC, sin embargo, tenía la necesidad de obtener de forma resumida la información que necesitaba.

Para casi cualquier tema podréis encontrar en internet unas hojas a modo de chuleta que sintetizan la información necesaria, simplemente buscando en google “cheatsheet tema” o “tema reference” obtendremos muchos enlaces que nos llevan a archivos pdf de pocas páginas.

Yo he estado buscando de los temas relacionados con mi proyecto y me gustaría compartilos con vosotros:

  • ASCII Reference: Muy útil para escribir caracteres ASCII por el terminal, o manipular caracteres.
  • C Reference: Aunque vaya a usar C++, no viene nada mal tener a mano este documento.
  • C++ Reference: Es útil cuando empezamos con C++, luego ya esto te lo conoces como la palma de tu mano.
  • SVN Reference: No sé si ya he mencionado a Subverson antes, pero es un controlador de versiones de código, usamos un servidor en Robolab y también otro en la forja RedIris.
  • OpenCV Reference: De momento es la que mejor me viene, pues no termino de sentirme cómodo con la documentación oficial de OpenCV.
  • LaTeX Reference: Es ideal para mí, ya que quiero documentar todo mi PFC con LaTeX sin haberlo usado anteriormente.
  • UML Reference: En unos de mis primeras entradas publiqué mi intención de usar diagrmas UML para explicar mi código, sé que siempre debería dibujar los gráficos UML antes que generar código, sin embargo me temo que tendré que hacerlo al revés, espero que con la ayuda de este archivo me sea más fácil.

Pero no todo iban a ser chuletas, éstas son sólo un apoyo, el resto se aprende programando, pidiendo ayuda y consejo a compañeros de Robolab y mi tutor del PFC, buscando información en libros, blogs, foros…

A continuación os dejo una lista de libros o manuales que estoy utilizando para aprender:

  • Aprende C++ como si estuviera en primero.
  • Aprende UML en 24 horas.
  • Robocomp for Dummies.
  • Robex and Robocomp: Building intelliget robots.
  • Distribuited Programming with ICE.
  • Metodología para el desarrollo de aplicaciones orientadas a objetos.
  • Programación vanzada en Shell.
Anuncios

27 febrero 2011 Posted by | all | , , , | Deja un comentario

Herramientas de trabajo

Las herramientas que uso para la programación de mi componente son un gran abanico de aplicaciones y librerías que si bien están lejos de formar un TodoEnUno compacto, a la hora de usar estas herramientas uno se siente cómodo trabajando, y se da cuenta que a pesar de ser independientes, trabajan bien juntas.

Las aplicaciones que utilizo son las siguientes:

  • Kdevelop-> Es un IDE (Entorno de Desarrollo Integrado) muy completo y fácil de usar, con él escribo el código y lo compilo. Su opción de autocompletado funciona realmente bien y te ayuda a avanzar mucho más rápido porque no tienes la necesidad de memorizar los nombres de todos los métodos y variables.
  • QTDesigner-> Es un diseñador de GUI (Interfaz Gráfica de Usuario), simplemente tenemos que maquetar nuestra GUI, y QTDesigner nos genera todo el código necesario para que funcione.
  • QTAssistant-> Nos proporciona todo tipo de información sobre las librerías QT, si bien en kdevelop podemos acceder a cierta información sobre las funciones que usamos, QTAssistant nos dará toda la información.
  • Yakuake-> Es un emulador de terminal similar a la consola de comandos del videojuego Quake, se despliega y se contrae a nuestro gusto, es muy configurable y cómodo de usar. Necesito un terminal para la compilación, navegar por los archivos, arrancar y pasar procesos, etc.
  • Gedit-> Normalmente todo el código lo edito con Kdevelop, sin embargo hay veces que es más rápido y cómodo editar con Gedit, por ejemplo los archivos de configuración de ICE.
  • Kile-> Es el programa que estoy empezando a usar para la documentación del PFC. Kile es una especie de IDE para LaTeX.
  • Cmake-> Es un programa de terminal que se encarga de enlazar todos los archivos para que la compilación sea algo muy sencillo. Sigue la configuración indicada en CMakeLists.txt, por eso ese archivo es tan importante.

Las librerías que utilizo son las siguientes:

  • QT4: Son unas librerías muy completas, desarrolladas por TrollTech (ahora es parte de Nokia), en algún sitio he leído que son la equivalencia a las MCF(Microsoft Class Foundation) de Windows en GNU/Linux. Pero lo cierto es que QT tiene soporte en GNU/Linux, Windows y MacOS. El escritorio KDE ha sido desarrollado completamente con las QT, y por esto rápidamente se asocia esta librería a las interfaces gráficas, pero lo cierto es que son mucho más que unas librerías puramente gráficas.
  • STD: Son las librerías estándar de C++, aunque no se puede decir que le doy un gran uso, son muy fáciles de usar, y lógicamente se puede encontrar muchísima información sobre ellas en internet.
  • OpenCV2: Ya he hablado anteriormente de OpenCV, las librerías para el procesamiento de imágenes. Son las librerías que usaré para el núcleo de mi componente, pues con ellas realizaré el traking y la detección.

A parte de lo anterior tengo que lidiar con ICE(la interface de comunicación entre componentes que usa Robocomp), con las herramientas de Robocomp(replayComp, managerComp, etc.), así como todo lo relacionado con la Kinect(Freenect, kinectComp, etc.).

26 febrero 2011 Posted by | all | , , , , , , , , , | Deja un comentario

Mi hueco en la Sala Beta

Hace mucho tiempo dí una descripción general de la Sala Beta, donde acudo para trabajar con la kinect.

Llevaba ya varios días queriendo hacer fotos, pero siempre se me olvidaba la cámara. Hoy que me he llevado la cámara no estaba Ursus, pero de todos modos he aprovechado para sacar un par de fotos a la sala.

25 febrero 2011 Posted by | all | , , | 1 comentario

Kinect, freenect, OpenKinect, y OpenNI

Ahora que voy a usar una kinect, necesitaré comunicarme con un componente llamado kinectComp, este componente dispone de una interfaz desde la cual podemos conseguir los datos de imagen y profundidad para poder trabajar con ellos en nuestro componente.

En realidad kinectComp se encarga de controlar la kinect, haciendo de intermediario entre el driver (controlador) de la kinect y los demás componentes de Robocomp.

Logo-OpenKinect

El driver se está desarrollando desde OpenKinect, coordinando a un gran grupo de personas que trabajan con este nuevo periférico. El driver se llama Freenect, y hasta el momento es capaz de capturar la imagen de la cámara con una resolución VGA (640×480), así como los datos de profundidad, y controlar el pequeño motor en su base. Sin embargo, con kinectComp sólo podemos acceder a los datos de profundidad e imagen.

Una versión experimental de Freenect consigue capturar el audio de sus micrófonos y cambiar el estado del LED frontal.  Y trabajan en un sistema llamado Fakenect con el cual puedas grabar una sesión con una kinect, para trabajar posteriormente con esa sesión sin necesidad de tenerla conectada al PC.

Logo-OpenNI

Por otro lado tenemos a PrimeSense, los diseñadores del chip PS1080 que lleva incorporado la kinect.  PrimeSense junto con WillowGarage (desarrolladores de OpenCV), están creando unas librerías llamadas OpenNI (Open Natural Interaction) que en principio no tiene nada que ver con el proyecto OpenKinect, y se encargan de facilitar el tracking de personas, el control por gestos, etc. De hecho, son las librerías que utilizan en NITE (framework de código cerrado) los desarrolladores de videojuegos para la XBOX360.

Hasta ahora, si queremos usar kinectComp necesitamos tener conectada la kinect, e instalar una versión del driver adecuada. La versión debe ser la adecuada porque Freenect está en constante cambio, recordemos que se empezó a trabajar con esto tan sólo hace 4 meses (Noviembre 2010), y el nombre con el que se accede a sus datos puede ser distinto en cada versión.

En mi caso, la primera vez que instalé freenect, lo hice con el método más cómodo, añadiendo el PPA a Ubuntu e instalando desde synaptic o aptitude, sin embargo la versión que se me instalaba con este método era un poco antigua (11 Diciembre 2010) y consumía RAM de forma incremental, hasta el punto de bloquear el ordenador si mantenía la kinect encendida más de 5 minutos.

Para solucionar esto, instalé la versión master desde el repositorio de GitHub, la cual me funcionaba perfectamente desde la demo de Freenect (glview), pero que no podía comunicarse con kinectComp. La solución vino de la mano de Luiky (miembro de Robolab) que modificó el archivo CMakeLists.txt de kinectComp. ¡Gracias Luiky!

 

 

18 febrero 2011 Posted by | all | , , , , | 1 comentario

Ursus, Kinect y Robocomp

En los últimos días mi proyecto se ha vuelto aún más interesante, principalmente gracias a los progresos de la gente que trabaja en Robolab, que han ido ampliando y mejorando a Robocomp, y además creando nuevos robots sobre los cuales se planean interesantes aplicaciones.

Respecto a las mejoras de Robocomp podemos echar un vistazo a la página del proyecto en SourceForge para ver que se envían un mínimo de 5 “code commits” al día. Sin duda es un proyecto muy activo.

En cuanto a los nuevos robots me gustaría destacar a URSUS, cuyo objetivo inicial es ayudar a los niños con problemas físicos a seguir los ejercicios de rehabilitación. Con URSUS los niños realizarían los ejercícios como si de un juego se tratase, a la vez que ayuda a los médicos a monitorizar los ejercicios. Se puede encontrar más información sobre esto en varios medios de comunicación que han intentado dar difusión a este proyecto tan interesante: [1][2][3][4][5][6][7][8].

Pero como he dicho antes, Robocomp no sólo mejora, sino que se amplía con más componentes, en concreto Robocomp ahora dispone de un componente llamado kinectComp, desarrollado por Luis Manso, que nos permite acceder a los datos que captura la kinect, pero es posible que llegado a este punto te preguntes… ¿qué es la kinect?

La kinect es un accesorio para la videoconsola de Microsoft XBOX360, se trata de una cámara en 3 dimensiones que permite jugar sin mandos, sólo con los movimientos de nuestro cuerpo. En Noviembre de 2010, el español Héctor Martín consiguió crear un controlador de código abierto que funciona sobre GNU/Linux para acceder a los datos de imagen y profundidad de la kinect, y ahora nosotros podemos usarla con Robocomp gracias a kinectComp. El precio de este aparato ronda los 150€, un precio aceptable para la calidad que consigue, la cual no deja de ser curiosa, pues consiste en una webcam VGA que nos da la imagen plana 2D, y una lámpara de infrarojos que emite un patrón concreto que junto con una cámara de infrarojos nos da información de la distancia.  Más sobre kinect.

Gracias a todas estas novedades, en mi proyecto trabajaré con una kinect en lugar de una webcam, y el resultado será aplicado a URSUS de forma que ampliemos sus aplicaciones.

10 febrero 2011 Posted by | all | , , , , , | 2 comentarios

Las partes de un componente de Robocomp

En la entrada anterior expliqué cómo crear un componente en Robocomp, ahora explicaré con más detalle, las partes de un componente, qué función tiene cada parte, dónde tenemos que insertar nuestro código y dónde podemos encontrarnos problemas a la hora de implementar nuestro componente.

Suponemos que hemos creado un componente llamado fooComp, y éste se encuentra en $ROBOCOMP/Components/Robolab/Experimental/fooComp/

Dentro de la carpeta fooComp/ se nos habrán creado los siguientes archivos y carpetas:

  • CMakeLists.txt -> Es un archivo que usará cmake para que podamos compilar correctamente con make. En principio no debemos modificarlo.
  • Doxyfile -> Es una archivo de configuración de Doxygen (un sistema de documentación automático), imagino que debemos configurarlo cuando queramos que todas las clases, funciones y métodos que usa nuestro componentes su publiquen en la API de Robocomp. De momento no modificaremos nada.
  • fooComp.kdevelop -> Es un archivo XML que se genera para que podamos importar correctamente nuestro componente como un proyecto en kdevelop (un IDE de programación muy completo). No lo modificaremos, en todo caso lo usaremos para importar el componente a kdevelop y desarrollar nuestro componente desde allí.
  • templates/ -> Es un directorio con 2 archivos vacíos, un .cpp y un .h, realmente no sé para qué sirve pero por lo que indica su nombre, se supone que aquí se guardarán las plantillas con código de uso frecuente.
  • etc/ -> Dentro tenemos los archivos config y config.debug, el archivo de configuración de ICE y el mismo para hcer debug (localizar fallos y errores en el código).  El archivo config usar el lenguaje SLICE que es bastante intuitivo, este archivo sí tendremos que modificarlo, especialmente los host y los puertos de los componentes con los que nos comunicaremos.
  • bin/ -> En esta carpeta encontraremos 4 scripts, y será aquí donde se genere el binario cuando compilemos nuestro componente. Dos de los scripts sirven para ejecutar y parar el componente sin tener que pasar las opciones de configuración de ICE al binario. Los otros dos hacen lo mismo pero para hacer debug. Estos scripts serán: startfoo.sh, stopfoo.sh, startDebug.sh, y forceStopfoo.sh. El binario que se creará tras compilar se llamará fooComp.
  • src/ -> Como podréis imaginar aquí tenemos todo el código importante que hace funcionar nuestro componente, los archivos que encontremos aquí pueden variar en función de las clases e interfaces que utilicemos, pero es cierto que algunos archivos siempre estarán presentes. Por lo general todo archivo .cpp tendrá su homónimo .h, a continuación explico estos archivos:
    • CMakeLists.txt -> Este es un archivo muy importante que tendremos que modificar cada vez que vayamos a usar clases de otras librerías. Importante no confundir este archivo con su homónimo en la carpeta fooComp. Este es mucho más completo y ya veremos cómo se modifica más adelante.
    • config.h -> Es el único archivo .h que no tiene un .cpp con el mismo nombre, es un archivo de configuración muy sencillo, deberemos modificarlo si vamos a usar una GUI (Interfaz Gráfica de Usuario), descomentando la línea #define USE_QTGUI
    • monitor.cpp y monitor.h -> Estos archivos se generan para que nuestro componente se comunique adecuadamente con el componente monitorComp (un componente que encontraremos en $ROBOCOMP/Tools/ con el que se pueden monitorear todos los componentes de Robocomp). En un principio no modificaremos estos archivos.
    • commonbehaviorI.cpp y commonbehaviorI.h -> Aún no sé con seguridad el papel que desenpeñan estos archivos, pero en principio no será necesario modificarlos. Creo que son complementarios para el monitosComp.
    • fooI.cpp y fooI.h -> Desde aquí podemos implementar la interfaz de nuestro componente, definiendo lo que otros componentes pueden hacer y que datos pueden obtener conectándose a nuestro componente. Es muy posible que modifiquemos estos archivos más adelante.
    • fooComp.cpp ->No sé la función de este archivo, es curioso que no exista un fooComp.h, pero de momento no necesitamos editar este archivo.
    • worker.cpp y worker.h -> estos son los archivos más importantes de nuestro componente, el núcleo que se encargará de procesar la información, estos son los primeros archivos que modificaremos con total seguridad. En otra entrada hablaré de la estructura de éstos archivos y cómo modificarlos para dar forma a nuestro componente.

Resumiendo, los archivos que necesitamos modificar son:

/etc/config -> Editar hosts y puertos,  al principio trabajemos en un único ordenador, usaremos localhost en luegar de host.

/src/config.h -> Descomentar la línea si queremos usar GUI.

/src/worker.h -> Declaración de variables, objetos, señales y slots. Añadir los DEFINE y los INCLUDE.

/src/worker.cpp -> Inicializar variables y objetos, así como operar con ellos. Se opera principalmente en worker::compute() y se inicializa en el constructor.

/src/CMakeLists.txt -> Se añaden las rutas de las clases que usemos en #SOURCES, se añaden todos los archivos .h que usemos en #HEADERS, añadimos instrucciones CMake en #ROBOCOMP, descomentamos el #INCLUDE de #IPP en caso de que las necesitemos, añadiremos líneas en el apartado #QT4 en caso de usar GUI.

9 febrero 2011 Posted by | all | , , | Deja un comentario

   

A %d blogueros les gusta esto: