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

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

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

Información para programar

La información que podemos obtener en la API de Robocomp, en QTAssistant, o en la wiki de OpenCV es realmente útil y necesaria para mi PFC, sin embargo, tenía la necesidad de obtener de forma resumida la información que necesitaba.

Para casi cualquier tema podréis encontrar en internet unas hojas a modo de chuleta que sintetizan la información necesaria, simplemente buscando en google “cheatsheet tema” o “tema reference” obtendremos muchos enlaces que nos llevan a archivos pdf de pocas páginas.

Yo he estado buscando de los temas relacionados con mi proyecto y me gustaría compartilos con vosotros:

  • ASCII Reference: Muy útil para escribir caracteres ASCII por el terminal, o manipular caracteres.
  • C Reference: Aunque vaya a usar C++, no viene nada mal tener a mano este documento.
  • C++ Reference: Es útil cuando empezamos con C++, luego ya esto te lo conoces como la palma de tu mano.
  • SVN Reference: No sé si ya he mencionado a Subverson antes, pero es un controlador de versiones de código, usamos un servidor en Robolab y también otro en la forja RedIris.
  • OpenCV Reference: De momento es la que mejor me viene, pues no termino de sentirme cómodo con la documentación oficial de OpenCV.
  • LaTeX Reference: Es ideal para mí, ya que quiero documentar todo mi PFC con LaTeX sin haberlo usado anteriormente.
  • UML Reference: En unos de mis primeras entradas publiqué mi intención de usar diagrmas UML para explicar mi código, sé que siempre debería dibujar los gráficos UML antes que generar código, sin embargo me temo que tendré que hacerlo al revés, espero que con la ayuda de este archivo me sea más fácil.

Pero no todo iban a ser chuletas, éstas son sólo un apoyo, el resto se aprende programando, pidiendo ayuda y consejo a compañeros de Robolab y mi tutor del PFC, buscando información en libros, blogs, foros…

A continuación os dejo una lista de libros o manuales que estoy utilizando para aprender:

  • Aprende C++ como si estuviera en primero.
  • Aprende UML en 24 horas.
  • Robocomp for Dummies.
  • Robex and Robocomp: Building intelliget robots.
  • Distribuited Programming with ICE.
  • Metodología para el desarrollo de aplicaciones orientadas a objetos.
  • Programación vanzada en Shell.

27 febrero 2011 Posted by | all | , , , | Deja un comentario

A %d blogueros les gusta esto: