Proyecto Fin de Carrera

Robótica, software y telecomunicaciones.

Documentación en la API de RoboComp

En una entrada anterior mostraba un esquema con las relaciones entre las funciones del worker de mi componente, y os contaba cómo escribiendo doxygen Doxyfile se nos generaba automáticamente toda la documentación y se nos guardaba en un nuevo directorio doc.

Pero lo ideal es que esa documentación esté integrada en la API de RoboComp junto a la información de los demás componentes. Es una lástima que Doxygen no soporte ICE de forma que  mostrase los proxies, puertos e interfaces. Pero al menos la gente de RoboComp tiene un scrip que genera los archivos *.cpp y *.h a partir de los *.ICE para que Doxygen pueda enterarse de algo.

Realmente subir la documentación a la API lo hace ese script que se genera en el servidor, por lo cual se necesita que algún administrador dé de alta tu componente, después de esto, todo es automático. El script está programado para ejecutarse una vez a la semana, mientras que nosostros simplemente tenemos que escribir comentarios en nuestro código con el formato de Doxygen.

De momento la documentación de mi componente ya está publicada, ahora queda comentar bien para que sea útil.

¡Ah! Se me olvidaba, por si no ha quedado claro, no seais tan bestias de subir la documentación con un svn ci porque eso sólo te serviría como copia de seguridad, pero son demasiados archivos y cada vez que alguien haga un svn up de tu componente se los tendría que bajar, cuando es más rápido generarlos desde el propio código. Hacer doxygen Doxyfile te puede venir bien para comprobar cómo sería si se generase en el servidor, o para llevártela a otro ordenador, imprimirla, etc.

Anuncios

19 abril 2011 Posted by | all | , , , | Deja un comentario

Tips para Doxygen

Tenía pensado escribir una entrada explicando lo básico para comenzar a documentar con Doxygen en nuestro código, pero antes de ponerme a ello descubro que en el blog del proyecto Infant ya tienen una entrada así.

Documentación de proyecto con Doxygen

El proyecto Infant participa en el CUSL y se encarga de detectar objetos de una imagen en distintos entornos, aprendiendo parámetros de estos objetos. En palabras del autor:

Infant es un proyecto/experimento en el que se tratará, mediante el uso de algoritmos de aprendizaje automático y visión por ordenador crear una aplicación capaz de identificar objetos por medio de diferentes técnicas.

17 abril 2011 Posted by | all | , , | Deja un comentario

El Worker de Camimic

Estos días he estado trasteando con Doxygen y la verdad es que me gustaría aprender más, pues me parece una herramienta muy útil.

De momento he generado la información gracias a que RoboComp ya viene con Doxygen, y es tan sencillo como desplazarte a la carpeta de tu componente (…/micomponenteComp) y ejecutar el siguiente comando:

doxygen Doxyfile

Y de manera automática se nos creará una carpeta llamada doc con otra llamada html llena de los archivos necesarios.

Os dejo una imagen que he creado trasteando con Doxygen:

16 abril 2011 Posted by | all | , | 1 comentario

Autodia y Doxygen aplicado a RoboComp

Hace varios meses os hablé de Dia , Autodia y Doxygen. Hoy os contaré cómo podemos aplicar estas herramientas de documentación a RoboComp.

Primero tengo que decir que Doxygen ya estaba integrado en RoboComp cuando llegué a RoboLab, y esto me fue de gran ayuda para empezar a programar en RoboComp. Doxygen soporta LaTeX siempre que tengas instaladas las oportunas dependencias en tu sistema, para instalarlas sólo ejecuta el siguiente comando:

sudo aptitude install latex dvips gs

Hasta el momento no he documentado mi componente con Doxygen pero en RoboLab lo tienen configurado para que una vez a la semana Doxygen examine todo el código que hay en el repositorio y genere la documentación que se publica en RoboComp API.

Para empezar a documentar con Doxygen tomaré ideas de otros componentes que ya estén documentados a la vez que me ayudo de los manuales de Doxygen.

Por otro lado he estado probando Autodia, el cual es bastante fácil de usar, aunque aún no he conseguido comprender porqué no puede procesar algunos archivos y otros sí. De momento he aplicado Autodía a mi componente leandroComp (ya le cambiaré el nombre a camimicComp) sacando un bonito gráfico con los métodos y variables utilizadas.

Para instalar Autodia simplemente ejecutarmos el siguiente comando en la consola:

sudo aptitude install autodia

Para ejecutarlo basta con llamarlo así:

autodia

Entonces te saldrá una pantalla explicando las distintas opciones posibles, si teneis alguna duda, espero vuestros comentarios.

3 abril 2011 Posted by | all | , , , , | Deja un comentario

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

Dia, AutoDia y Doxygen, herramientas para organizar y documentar

Aunque el Proyecto Fin de Carrera de una Ingeniería Técnica no suele ser de grandes dimensiones siempre es bueno adquirir buenas costumbres desde el principio.

Como ya escribí en esta entrada anterior, fijar los objetivos y una planificación, son buenos hábitos a la hora de desarrollar proyectos.

Cuando el proyecto se trata de software, buenos hábitos son: Organización con UML, Código Limpio y Claro, y Documentación.

Dia Doxygen

Sigue leyendo

16 noviembre 2009 Posted by | Recursos | , , , , , , | 1 comentario

   

A %d blogueros les gusta esto: