Instalar ARToolKit en Ubuntu y usar en RoboComp

En el blog Simocap de José Alberto Gandullo se explica perfectamente cómo instalar ARToolKit en Ubuntu, sin embargo me gustaría añadir algunas notas que me comentó Luiky.

El método de instalación que se menciona en Simocap es para la versión de 32bits de Ubuntu, aunque en realidad podría servir para varias distribuciones GNU/Linux basadas en Ubuntu o en Debian.

Para las distribuciones GNU/Linux de 64bits es preferible modificar el script Configure antes de ejecutarlo, podemos hacerlo con los siguientes comandos:

cd ARToolKit
gedit Configure

Dentro del archivo configure tenemos que añadir -fPIC a la línea 111 sustituyendo la línea que tiene  —  por la que tiene ++ al principio de las líneas que indico:

-- CFLAG="-O $GST_INCLUDE -I/usr/X11R6/include"
++ CFLAG="-O $GST_INCLUDE -fPIC -I/usr/X11R6/include"

A continuación lo ejecutamos:

./Configure

y compilamos:

make

Añadimos la variable de entorno:

export ARTOOLKIT_CONFIG="v4l2src device=/dev/video0 use-fixed-fps=false ! ffmpegcolorspace ! capsfilter caps=video/x-raw-rgb,bpp=24 ! identity name=artoolkit ! fakesink"

y probamos que funciona correctamente ejecutanto el test dsde la carpeta bin:

cd  ARToolKit/bin
./simpleTest

Sin embargo, si queremos integrar ARToolKit en nuestro proyecto, necesitamos modificar nuestro CMakeLists.txt, de forma que los #include no nos den problemas.

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.).

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.