Proyecto Fin de Carrera

Robótica, software y telecomunicaciones.

Ideas para Camimic

En algunas de las entradas publicadas se puede ver la GUI de mi componente, ya sea a través de las capturas de pantalla o con el video que he publicado recientemente. Sin embargo ese no será el aspecto definitivo, la GUI que he usado hasta el momento ha sido simplemente un método para aprender lo básico sobre GUI con QT y para comprobar algunos efectos de la kinect más cómodamente. De hecho estoy considerando pasar parte de este código y GUI al componente evaluationkinectComp.

Este fin de semana he estado reflexionando sobre cómo llevar a cabo las funciones de Camimic y el aspecto preliminar que debería tener la GUI, ya que ahora me siento con los conocimientos necesarios para desarrollar, pues hasta ahora me he dedicado a adquirir conocimientos básicos sobre C++, QT, KDevelop, etc.

En la siguiente imagen tengo notas con ideas que me gustaría plasmar en Camimic hacíendolas realidad.

Gracias a Pencil (programa de diseño de esquemas y mockups de GUI) la idea tiene un toque más simpático.

Idea-GUI-Camimic

Idea de GUI diseñada con Pencil y Gimp, usando OpenClipArt.

Por último he dibujado un diagrama de flujo con Dia, el cual aún necesita una mayor profundización.

Camimic-Flux-Diagram

Anuncios

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

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

Configurar componente con GUI

En la entrada anterior explicaba cómo conseguir que una GUI creada con QT Creator se comunicase con nuestro componente, sin embargo dejé pendiente la configuración para que todo eso funcionase.

El primer archivo a modificar es el config.h que se encuentra en micomponenteComp/src/, es un archivo muy simple, y tan sólo tenemos que decomentar la línea en negrita:

#ifndef CONFIG_H
#define CONFIG_H

// Comment out this line if your application has a QtGui
// #define USE_QTGUI

#define PROGRAM_NAME    “Kinect”
#define SERVER_FULL_NAME   “RoboCompKinect::Kinect”
#endif

Con eso le indicamos a la configuración que queremos usar QT para implementar nuestra GUI.

También tenemos que añadir el archivo .h con un include al worker.h, simplemente abrimos el worker.h y escribimos lo siguiente en la cabecera:

#include "nombre_de_mi_GUI.h"

Esto se hace igual que si incluimos cualquier librería, como opencv o iostream

Por último modificaremos el archivo CMakeLists.txt que se encuentra en el mismo directorio que los archivos anteriores. Simplemente añadimos las líneas en negrita, debajo de los respectivos comentarios:

# Graphical User Interfaces
SET (UIS nombre_de_mi_GUI.ui)

# Qt4
QT4_WRAP_UI( UI_HEADERS ${UIS} )

Con esto estaría todo configurado para añadir widgets y conectarlos con nuestro componente, para ello habría que repetir los pasos que se explican en la entrada anterior.

 

29 marzo 2011 Posted by | all | , , | 2 comentarios

GUI con QT4 en RoboComp

Las librerías QT de Nokia(antes Troltech) permiten crear una GUI (interfaz gráfica de usuario) para un programa con relativa facilidad, pero además de la GUI, estas librerías librerías tienen un toolkit muy completo, con máquina de estados, control de excepciones, tratamiento multimedia, etc.

RoboComp hace uso de las capacidades de QT4, tanto para la GUI como para otras tareas, por lo que si queremos crear una GUI para nuestro componente, lo mejor es hacerla con QT4.

Logo de QT

Para empezar, podemos ojear la información que nos da la propia Nokia aquí, sin embargo podemos usar QT Assistant que es un asistente con toda la documentación que necesitan los desarrolladores que usen QT. Como nosotros desarrollamos con KDevelop, tenemos la ventaja que este IDE (Entorno de Programación Integrado) integra a QT Assistant de forma que su uso es muy cómodo.

Siguiendo los tutoriales, uno se da cuenta que es muy fácil crear una primera GUI con QT4, más aún cuando usamos un programa de edición de GUI como QT Creator. Sin embargo a la hora de unir la GUI que puedes hacer siguiendo un tutorial, con el componente creado en RoboComp, parece que la tarea se complica.

En realidad no es tan complicado, los pasos son muy simples, crear un método SLOT, crear un widget con SIGNAL, y conectarlos.

El método SLOT no es más que un método (en C y otros lenguajes se llaman funciones) que tratará la comunicación con la señal, y se crea como cualquier otro método que queramos. Un ejemplo podría ser capturar el valor de un slider(barra desplazadora, fader), o ejecutar cualquier tarea al ser presionado un botón.

Para crear un método en RoboComp, primero lo declaramos en worker.h, debajo de public slots:

public slots:
void compute();
void pb_say_hello();

Luego lo desarrollamos en worker.cpp debajo de compute{}:

void Worker::pb_say_hello()
{   
   std::cout << "Hello!";
}

Con esto tenemos creado nuestro método SLOT listo para conectar a un widget con SIGNAL, el nombre pb_say_hello puede ser cualquiera, y el método puede tener argumentos de entrada o de salida, depende de nuestras necesidades, aunque sí suele ser conveniente que podamos identificar el método con la GUI, por ello pb_ hace referencia a “push button”, pero vale cualquier referencia.

El siguiente paso es crear el widget con SIGNAL, los widgets son cualquier elemento gráfico de una GUI, como una barra de desplazamiento, un botón, la caja de texto, un frame de video, texto no editable o la propia ventana que sujeta a todos los demás elementos. Los widgets con SIGNAL son aquellos que permiten la interacción del usuario con el programa, por ejemplo widgets con SIGNAL son los botones (dicen si están presionados o no al programa), las cajas de texto editable (pueden comunicar su texto al programa), o los sliders (pueden variar su posición), sin embargo los frames de video, los textos fijos o las ventanas que siven de soporte a otros widgets, no emiten SIGNAL.

Con QT Creator crear un widget es algo realmente sencillo, el único detalle que tenemos que tener en cuenta es darle un nombre al widget para que los podamos asociar cómodamente al método SLOT. De forma que en vez de tener botón1, botón2, botón3… tengamos say_hello_pb, stop_pb, close_pb…

Simplemente queda crear la conexión, ésta la hacemos en worker.cpp en el constructor. Si no sabeís qué es o dónde está el constructor, de forma rápida diré que en el constructor es donde se inicializan todas las variables que usemos y suele ser lo primero que encontramos en worker.cpp, se llama:

 Worker::Worker(...) : Qwidget(parent)
{
...
}

Entre esos corchetes será donde realizemos la conexión entre el método SLOT y el widget con SIGNAL. Según he visto en otros componentes de RoboComp, esto lo hacen al final del constructor, así que sería mejor seguir el orden y añadirlo en la parte baja del constructor. Quedaría así:

 Worker::Worker(...) : Qwidget(parent)
{
...
...
connect(  say_hello_pb,SIGNAL( clicked() ),this,SLOT( pb_say_hello() )  );
}

Como se puede advertir en la línea anterior, say_hello_pb es el widged, pues no lleva los paréntesis () característicos de los métodos. Además, say_hello_pb activa una señal cuando llama a su propio método clicked(), ya que un botón puede emitir una señal al dejar de pulsarlo, el nombre de estos métodos se pueden consultar de la información de QT, pero el propio KDevelop te ayuda sugiriéndote los métodos. Lo siguiente en aparecer es this, que se refiere a quién tiene el SLOT a conectar, en nuestro caso es worker, y cuando llegue la señal, se ejecutará el método pb_say_hello().

En principio con esto bastaría, y sería el proceso que hay que realizar para que cada widget de nuestra GUI pueda conectarse con nuestro componente, sin embargo antes de esto, deberíamos realizar algunas modificaciones, como añadir el .h de nuestra GUI en worker.h o modificar archivos como el ../etc/config o el ../src/CMakeLists.txt, esto lo contaré en otra entrada, pero si no queréis esperar podeís dejar un comentario con las dudas.

29 marzo 2011 Posted by | all | , , | 1 comentario

   

A %d blogueros les gusta esto: