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.

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

Avahi — maquinafoo.local

Ya he comentado alguna vez que el mayor potencial de RoboComp es la utilización de hardware simultáneamente por varios equipos. En nuestro caso podemos usar la Kinect desde varios ordenadores de RoboLab gracias a que RoboComp utiliza ICE, sin embargo hasta el momento, yo siempre había usado la Kinect desde mi ordenador y habían sido los compañeros quienes se conectaban a ella desde la red local.

Hoy me ha tocado a mí conectarme a la Kinect mientras esta estaba conectada en otro ordenador, y lo único que tenía que modificar era el archivo config que se encuentra en …/micomponenteComp/etc/ y cambiar localhost por la IP de la máquina donde corre la Kinect.

Gracias a Avahi no es necesario tratar con IP’s mientras éstas estén en la misma red local, simplemente podemos poner maquinafoo.local y Avahi se encargará de buscar la máquina con el nombre maquinafoo, obtener su IP real y sustituir maquinafoo.local por la misma.

Avahi es un demonio (similar a un servicio en Windows), que se encarga de obtener las IP’s de una red local y asociarlas a los respectivos nombres de máquina. Es similar al Bonjour de Apple, y a este tipo de servicio también se les suele llamar descubridores de servicios de red o se los puede comparar a un servicio de DNS a nivel local.

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

Novedades en KinectComp

En Robolab seguimos trasteando con la Kinect, con su calibración y con el cómo pasar los datos de imagen y profundidad a coordenadas en 3D. La semana pasada se hicieron algunos cambios en las interfaces (archivos .ice) kinect y rgbd. Lo que me lleva a modificar mi código para trabajar con estas nuevas interfaces. Estos cambios son debidos a la calibración de la kinect y al ajuste que se aplica para hacer coincidir los datos de profundidad sobre la imagen RGB o bien la imagen sobre la profundidad.

De momento, estos métodos son getDataRGBZinIR() y getDataRGBZinRGB(), ambos métodos nos devuelven la Z en lugar de la DEPTH (profundidad), ya que es más útil porque podríamos pasar esa información a un sistema cartesiano con coordenadas XYZ, además para mi caso concreto, también es más útil pues los movimientos que haremos sobre la cámara serán movimientos planos en lugar de movimientos esféricos con centro en la Kinect.

Diferencias entre el concepto de Depth y Z.

Diferencias entre el concepto de Depth y Z.

Respecto a los métodos de conseguir los datos de imagen, es debido a que la cámara IR y la cámara RGB están desplazadas en el eje X (suponiendo un sistema cartesiano de tres dimensiones XYZ), y por tanto es importante usar como referencia una cámara u otra.

Estos cambios han hecho que me interese más aún por el componente que gestiona la Kinect en RoboComp y por el mismo driver de OpenKinect. He realizado algunas modificaciones en KinectComp de forma que sea más versátil y potencialmente más capaz. Por ejemplo, es interesante que en la interfaz de KinectComp (archivos .ice) estén definidos métodos con todas las posibilidades de la Kinect, pues aunque no se puedan implementar en este momento, es posible dejar esos métodos vacios y desarrollarlos más adelante sin interferir con los programas o componentes que se conectan a KinectComp.

Por este motivo he estado pensando en varios métodos, además de los existentes. Un método casi obligado sería el de calibrar la Kinect. Ya que sería conveniente poder calibrar cada Kinect antes de obtener los datos de imagen y profundidad, hasta ahora KinectComp calibraba la Kinect con unos valores de calibración genéricos proporcionados por Nicolas Burrus en su wiki. He modificado el código para que use variables en esa calibración, ya que cada Kinect tiene unos valores específicos asociados, de forma que con un método del tipo setCalibration(vectorCalibration[]) podamos pasar los valores específicos de nuestra Kinect en caso de que los conozcamos.

Otros métodos son asociados al LED de la Kinect de forma que podamos cambiar y leer su estado, esto puede ser útil para nuestra aplicación como un método de comunicación entre el programa y el usuario. Por ejemplo, si el usuario está demasiado cerca de la kinect, ponemos el LED en rojo, y si está a una distancia óptima se pone a verde.

Tambien sería ideal tener métodos para el audio o el acerelómetro de la Kinect, aunque en este momento no se le vaya a dar uso, porque aún no está bien implementado en el driver.

Como apunte final respecto a los métodos, creo que es conveniente evitar los parámetro en funciones siempre que se pueda, por ejemplo, se podría usar el siguiente método para la modificación del color del LED:

void setLEDcolor(int color);

Sin embargo, veo mucho más interesante crear la misma funcionalidad con un serie de métodos, pues el tener varios métodos no es algo necesariamente negativo:

void setLEDred();

void setLEDgreen();

void setLEDorange();

28 marzo 2011 Posted by | all | , , , | 1 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

Instalar Robocomp

Como ya comenté en la entrada anterior, a partir de ahora usaré Robocomp, un framework para generar componentes de software para robots.

Robocomp es capaz de funcionar en varios sistemas operativos y en un amplio hardware, sin embargo la mayoría de los desarrolladores y testers utilizan Debian o Ubuntu para trabajar, de hecho tienen un script para una instalación más sencilla de Robocomp en estos sitemas.

Casi todo el software desarrollado en Robocomp está escrito en C++ o Python, aunque usa el framework de comunicación de componentes ICE que le permite reutilizar componentes independientemente del lenguaje en el que esté escrito.

Los componentes de Robocomp es software para el control y funcionalidad de los robots, como pueden ser control de servomotores, cálculo de distancias con cámaras estéreo, posicionamiento con ayuda de láser, reconocimiento de objetos e imágenes, sistemas de sonido y reconocimiento de órdenes…

Aunque en la wiki del proyecto dan claras instrucciones para su instalación, voy a contaros aquí un poco los pasos que he dado para instalar Robocomp en Ubuntu Lucid 10.04:

  • Primero descargarse las librerías IPP de Intel. Estas librerías es software propietario y por lo tanto sólo lo puede distribuir Intel, además deberás dejar tu correo electrónico para que te manden una clave de activación. Son unos 400MB por lo que tardarán bastante en descargarse, dependiendo de tu conexión, y para instalarse también tardara un poco.

Una vez descargado tendremos que descomprimirlo, navegar con la consola hasta la carpeta descomprimida y ejecutar:

sudo /bin/bash ./install.sh
 

Nos pedirá que aceptemos la licencia, y luego nos dará a elegir entre instalar en periodo de prueba o activar, a mi personalmente me tardaba demasiado con la activación así que tuve que instalar el periodo de 30 días, ya la activaré después. El directorio de instalación es: /opt/intel/ipp/6.1.2.051/ia32

  • El siguiente paso es instalar las dependencias, en principio el script te instala todas las dependencias, pero creo que es mejor tenerlas instaladas primero, son las siguientes:
sudo apt-get install subversion openssh-server build-essential cmake g++ pyqt4-dev-tools python-qt4-dev python-qt4 

sudo apt-get install libfwbase1-dev libfwbase1 libcwiid1 libcwiid1-dev libdevil1c2 libdevil-dev libglew1.5-dev
sudo apt-get install libqt4-dev qt4-dev-tools libslice33 libzeroc-ice33 libzeroc-ice33-dev python-zeroc-ice libdc1394-22-dev
  • Ahora descargaremos el script, y lo ejecutamos desde la consola con el siguiente comando:
python robocompInstaller.py

El script detectará tu sistema operativo y después intenta satisfacer las dependencias, (suele tardar bastante), después tiene que descargar todos los datos de Robocomp y finalmente debes pasarle las rutas que introducirá como variables del sistema, como la ruta donde se instalará Robocomp, la ruta donde está instalada IPP, etc.

Finalmente, tendremos que reiniciar para que se guarden las variables del sistema.

 

20 julio 2010 Posted by | all | , , , , , , , | 5 comentarios

   

A %d blogueros les gusta esto: