Proyecto Fin de Carrera

Robótica, software y telecomunicaciones.

Cómo usar OpenCV 2.2 en RoboComp

Una de las tareas que me han costado más esfuerzo del esperado es utilizar OpenCV 2.2 en mi componente. Ya en otra entrada explicaba como instalar OpenCV 2.2 en Ubuntu 10.10 y dejarlo preparado para trabajar con RoboComp y las IPP de Intel. Sin embargo, la simple tarea de mostrar la imagen RGB capturada por la Kinect se me ha complicado más de lo esperado.

Antes que nada tenemos que tener en cuenta que OpenCV no está diseñado para trabajar con la Kinect y mucho menos con RoboComp. En cambio OpenCV sí está pensado para capturar imágenes desde webcams, cámaras IP o cámaras Firewire, capturando las imágenes en los formatos IplImage, cvMat o Mat directamente. OpenCV también dispone de una GUI que te permite ver el procesado aplicado a las imágenes.

Entonces, ¿porqué usar RoboComp y QT si OpenCV puede capturar, procesar y mostrar con su GUI? Es cierto que RoboComp tiene un formato de imagen, QT otro y OpenCV otro más, lo que puede resultar engorroso a la hora de programar, pero hay una serie de ventajas en usar Robocomp y QT:

  • La gran ventaja de RoboComp es que si tenemos un componente dedicado a servirnos los datos de un determinado hardware, cualquier componente puede usar ese hardware sin interferencias. Por ejemplo con OpenCV, si un programa está capturando de la cámara, esta queda bloqueada para otros programas. En cambio con RoboComp podríamos usar la misma cámara desde distintos componentes que se ejecuten en distintos ordenadores. Esto no parece ser una gran ventaja cuando el precio de una webcam ronda los 20€, pero es muy útil cuando una Kinect cuesta unos 150€ y no podemos tener una para cada ordenador del laboratorio.
  • Respecto a QT, nos ofrece un abanico de posibilidades muy superior a la GUI de OpenCV, la documentación de QT está mejor estructurada que la respectiva de OpenCV, QT se integra mejor en el sistema operativo, pero la mayor de las ventajas es la facilidad para editar la GUI con QT Designer sin necesidad de escribir un código complejo.

Mis problemas con OpenCV, derivan principalmente del cambio de nomenclatura que están llevando a cabo y a que tienen una forma particular de hacer las cosas.

Por ejemplo, la función para dibujar en una ventana es:

imshow("newWindow",imageCV);

Sin embargo necesitaba escribir lo siguiente para que mostrase la imagen, pues de lo contrario se mostraba la ventana vacía:

imshow("newWindow",imageCV);
waitKey(2);

Otro de los problemas es que OpenCV trabaja en el espacio de color BGR por defecto en lugar del RGB, el resultado es el de la imagen que se muestra a continuación.

Para solucionar esto, debemos escribir lo siguiente tras rellenar la imagen del formato de OpenCV:

cvtColor(imageCV,imageCV,CV_BGR2RGB);

De todos modos, los pasos serían los siguientes:

9 abril 2011 Posted by | all | , , , , | 4 comentarios

Mi componente de RoboComp

Hace unos días grabé un vídeo usando mi componente tras solucionar el refresco de la imagen al cambiar de fuente. Los principales problemas llegaban por la imagen de infrarrojos que al ser de distinto tipo (Blanco y Negro) y de distinto tamaño (8 píxeles más alta).

El problema ahora son los FPS (frames por segundo) que son demasiado bajos al pedir constantemente a la Kinect la imagen de infrarrojos y la RGB. Toca solucionarlo.

 

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

Calibración de Kinect

En esta entrada os comentaba sobre la calibración de la Kinect, y en esta otra algunas mejoras del componente de RoboComp que gestiona la kinect, kinectComp.

Os hablé de las matrices de Rotación y Traslación y de los parámetros intrínsecos de la cámara, los cuales son otra matriz. Los parámetros intrínsecos son los mismos para cualquier Kinect, pero tenemos que tenerlos en cuenta a la hora de interpretar los datos que captura la cámara para poder relacionar estos datos con el mundo real.

En la página de Nicolas Burrus podemos encontrar los parámetros intrínsecos, así como las matrices de Rotación y Traslación para una Kinect concreta. Pero gracias a Nicolas Burrus y los desarrolladores de la comunidad OpenKinect podemos calcular estas matrices calibrando nuestra propia Kinect. Para ello simplemente usaremos la aplicación RGBDemo, la cual basa la calibración en el método de OpenCV para calibrar cámaras estéreo.

Os dejo algunas capturas de las calibraciones de prueba que he hecho con las Kinects de RoboLab:

Sigue leyendo

7 abril 2011 Posted by | all | , , | Deja un 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

Robolab — Robótica en Extremadura

Acabo de descubrir un canal en YouTube con vídeos de RoboLab y me gustaría compartirlo con mis lectores. A la vez, aprovecho para contaros un poco la intención a largo plazo de nuevos proyectos que se gestan en RoboLab.

Ya os había hablado de Ursus anteriormente, pues bien, se sigue progresando con este simpático robot, y es que en RoboLab están trabajando para dotarle de una boca que se mueva cuando Ursus habla. Además se está fabricando un segundo Ursus, con un torso más natural, y con piernas que aunque no se muevan, mejorarán bastante el aspecto exterior.

Como se puede ver en algunos videos se trabaja en un robot que transporta palés en miniatura, en principio puede chocar esta aplicación porque si ves los videos de buenas a primeras, seguramente no entiendas porqué nuestros robots van tan mal comparándolo con robots industriales que ya transportan palés desde hace varios años. La diferencia está en que esos robots industriales que funcionan tan bien, están fuertemente condicionados por su entonrno, mediante guías, raíles o movimientos programados muy concretos, donde en realidad se ha tenido que modificar el entorno para adaptarse al robot, esto supone un coste económico y logístico cuando por ejemplo, en una fábrica es necesario que el robot realice algo nuevo por un cambio de la disposición de los palés, lo que llevaría a adaptar nuevamente el entorno para el robot. De este modo los robots condicionan el modo de trabajo a las empresas que se ven en la necesidad de usarlos, generando un coste incial muy elevado para las empresas que quieren aplicar la robótica a su negocio, ya que además del precio del robot, tienen que invertir en la adaptación del entorno para el robot. Los robots de RoboLab buscan la mayor independencia con el entorno, de forma que sean ellos los que se adaptan a las situaciones y no al revés. Esto no es nada fácil, por eso podemos observar en los vídeos como se va progresando poco a poco con este robot.

Quizás el más impresionante es el SMART, que es un robot todoterreno con el objetivo de proporcionar ayuda como en situaciones posteriores a catástrofes naturales buscando heridos, por ejemplo. De momento aún queda mucho por hacer porque hasta ahora no deja de ser una especie de minicarro eléctrico controlado remotamente, pero la idea es que finalmente pueda ser más o menos independiente. Para lograr este propósito en RoboLab están pensando en adquirir un Drone (también conocido como Quadcóptero) de forma que el SMART haga de base nodriza, recargue las baterías del Drone, y transporte material sanitario, agua o víveres. Mientras que el Drone sea los ojos del SMART y analice la periferia, de forma que SMART pueda calcular la mejor ruta hasta el objetivo. Todo esto siendo un único robot a pesar de ser físicamente dos componentes distintos.

Por otro lado se está trabajando en un robot que reconstruye un mundo virtual a través de lo que va captando del mundo real, de forma que una vez reconstruido su mundo, puede navegar por él. También podemos apreciar en algunos de los videos a Muecas, un robot que pretende simular expresiones faciales. También hay algún proyecto sobre robot-juguete, y otros tantos de los que aún no me he enterado.

Sin lugar a dudas queda mucho trabajo por hacer, pero es muy emocionante estar haciendo mi Proyecto Fin de Carrera aquí, con la tecnología puntera y la investigación tan cerca, y sobretodo rodeado de estos cracks que forman el equipo de RoboLab.

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

OpenCV2.2 con IPP activas en Ubuntu 10.10

Parece ser que se ha dado un salto de OpenCV2.1 (versión en los repositorios oficiales de Ubuntu 10.10) a OpenCV2.2 (última versión estable en los repositorios de WillowGarage -Marzo 2011- ) en cuanto a la forma de trabajar con imágenes. Si bien se guarda la compatibilidad con los formatos anteriores como IplImage o cvMat, a partir de ahora lo ideal sería trabajar con imágenes de la clase Mat, aunque de momento muchas funciones o métodos de OpenCV las admiten por igual como argumento.

Como puede complicarse un poco la instalación de la instalación y puesta a punto de esta versión 2.2 de OpenCV, voy a intentar explicar el método paso a paso para tenerlas configuradas para trabajar con IPP.

Antes que nada, doy por supuesto que tienes instalada la última versión de IPP en Ubuntu, en una entrada anterior explico como instalarlas junto a RoboComp.

  • Descomprimimos el archivo en nuestra carpeta de usuario.
  • Abrimos un terminal y nos desplazamos a la carpeta de OpenCV que se nos ha creado:
cd /home/my_user/OpenCV-2.2.0/
  • Ahora editamos el archivo CMakeLists.txt con nuestro editor favorito, por ejemplo gedit:
gedit CMakeLists.txt
  • Dentro de este archivo tenemos que buscar las siguientes líneas: (*Error:¡ Ver aclaración al final del documento!)
if(IPP_FOUND AND USE_IPP)
message(STATUS "    Use IPP:                   ${IPP_PATH}")
else()
message(STATUS "    Use IPP:                   NO")
endif()
  • Donde vamos a cambiar un NO por un YES en la posición marcada con negrita. Es la línea 1404 del archivo.
  • Guardamos y cerramos gedit y desde la consola (suponemos que estamos en /home/my_user/OpenCV-2.0.0/) ejecutamos:
cmake .
make
sudo make install

Con eso ya tendríamos OpenCV2.2 listo para trabajar con las IPP en Ubuntu 10.10 Maverick.

Para utilizar las recién instaladas en RoboComp, simplemente tenemos que modificar el CMakeLists.txt de nuestro componente (no olvidar borrar el CMakeCache.txt y hacer cmake . antes de compilar con el CMakeLists.txt modificado) y añadir el #include a la cabecera de nuestro worker.h:

  • En CMakeLists.txt de la carpeta mycomponentComp/src/ añadimos lo que está en negrita:
ADD_DEFINITIONS( -Wall -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB )
FIND_PACKAGE( Qt4 REQUIRED )
FIND_PACKAGE( OpenCV REQUIRED )
SET( QT_USE_QTGUI TRUE )
SET( QT_USE_QTOPENGL TRUE )
SET( QT_USE_QTXML TRUE )
INCLUDE( ${QT_USE_FILE} )
QT4_WRAP_CPP( MOC_SOURCES ${HEADERS} )
QT4_WRAP_UI( UI_HEADERS ${UIS} )#MODIFICADO LANDER PARA DIBUJAR LA UI

# Specify construction and link process
ADD_EXECUTABLE( leandroComp ${SOURCES} ${MOC_SOURCES} ${RC_SOURCES} ${UI_HEADERS} )
TARGET_LINK_LIBRARIES( leandroComp ${QT_LIBRARIES} ${LIBS} ${OpenCV_LIBS})
  • En worker.h de nuestro componente, inmediatamente encima o debajo de otros #include añadimos la siguiente línea:
#include <opencv2/opencv>

Y ya podemos usar las funciones de OpenCV en nuestro componente. Tener en cuenta que si queremos usar las funciones de OpenCV tendríamos que usar el operador de ámbito de la forma cv::funcionDeOpenCV() o añadir:

using namespace cv;

en la cabecera del worker.h para poder usar las funciones como funcionDeOpenCV(), como explico en esta entrada.

* El punto que está tachado es un error bastante grave, ya que con eso no solucionamos la instalación de OpenCV con IPP, sino que lo único que cambiamos es el mensaje de error cuando al hacer cmake . a OpenCV2.2 y éste no encontrar las IPP, nos dirá que todo está OK aunque en realidad no fuera así. Lo cual, además de no ser la solución, nos conduce a un grave error pensar que OpenCV está usando IPP cuando en realidad no es así.

Buscamos en el CMakeLists.txt las siguientes líneas y las modificamos según el texto rojo:

foreach(v "6.1" "6.0" "5.3" "5.2" "5.1")
    if(NOT IPP_FOUND)
        if(WIN32)
            find_path(IPP_PATH "ippi-${v}.dll"
                PATHS ${CMAKE_PROGRAM_PATH} ${CMAKE_SYSTEM_PROGRAM_PATH}
                DOC "The path to IPP dynamic libraries")
            if(NOT IPP_PATH)
                find_path(IPP_PATH "ippiem64t-${v}.dll"
                    PATHS ${CMAKE_PROGRAM_PATH} ${CMAKE_SYSTEM_PROGRAM_PATH}
                    DOC "The path to IPP dynamic libraries")
            endif()
        endif()
        if(UNIX)
            find_path(IPP_PATH "libippi.so.6.1"
                PATHS ${CMAKE_LIBRARY_PATH} ${CMAKE_SYSTEM_LIBRARY_PATH} ENV ${OPENCV_LOADER_PATH} /opt/intel/ipp/6.1.2.051/ia32/sharedlib
                DOC "The path to IPP dynamic libraries")
            if(NOT IPP_PATH)
                find_path(IPP_PATH "libippiem64t${CMAKE_SHARED_LIBRARY_SUFFIX}.${v}"
                    PATHS ${CMAKE_LIBRARY_PATH} ${CMAKE_SYSTEM_LIBRARY_PATH} ENV ${OPENCV_LOADER_PATH}
                    DOC "The path to IPP dynamic libraries")
            endif()
        endif()

En mi caso tenía instalada la versión 6.1 en 32 bits, pero si tienes una versión posterior tendrías que añadirla en la primera línea de las que comento, por ejemplo añadiendo “7.0” si fuera el caso, después modificar el nombre de archivo libippi.so.6.1 a libippi.so.7.0 (por ejemplo) en caso de la versión de 32 bits o la zona naranja a libippiem64t.so.7.0 en caso de ser de 64 bits. Y después, tal y como destaca la ruta de color rojo, añadir la ruta donde se encuentre el archivo anterior, que en caso de 64 bits sería en la línea siguiente a la que tiene marcado el nombre naranja.

Esta forma es un poco chapucera porque es un método “a mano”, pero de momento parece que funciona. Espero no haber metido la pata esta vez, pero si alguien tiene sugerencias, se admiten todas.

Pido disculpas por los inconvenientes que he podido ocasionar por el error inicial.

1 abril 2011 Posted by | all | , , , | 4 comentarios

A %d blogueros les gusta esto: