Conclusiones
Por último, hicimos un video para ver como funciona el programa completo:
Enlace al video en ScreenCastle
En resumen hemos aprendido mucho sobre el robot nao, la forma de realizar movimientos simples (andar o girar) y como relacionarnos con el entorno por medio de los diferentes sensores de los que disponemos (ultrasonidos, presión). También hemos aprendido a obtener la imagen y hacer transformaciones entre los diferentes formatos (HSV, YUV, RGB).
Además de aprender a implementar un interfaz gráfico sencillo y al manejo del simulador webots.
Sistema de Visión: YUV
En este caso probaremos con el formato YUV. Obtendremos la imagen de la cámara del robot como antes en formato RGB, una vez la tengamos la convertimos a su correspondiente en YUV.
|
y = r * .299000 + g * .587000 + b * .114000; |
Una vez hecho esto mostraremos las 3 imagenes en el interfaz (la de Y , U, V). Y volveremos a convertir la imagen a RGB para mostrar la otra.
|
r = y + 1.4075 * (v – 128); |
Sistema de Visión: HSV
Una vez representada la imagen en RGB nos pusimos a probar con diferentes formatos de imagen, en este caso usaremos el HSV.
Obtendremos la imagen de la cámara del robot como antes en formato RGB, una vez la tengamos la convertimos a su correspondiente en HSV.
|
float max = r; if (max < g) max = g; if (max == min){ if (max == r ){ |
Una vez hecho esto mostraremos las 3 imagenes en el interfaz (la de H , S, V). Y volveremos a convertir la imagen a rgb.
|
float h_aux, f, p, q, t, v_aux; h_aux = ((int)fabs(H/60.0)) % 6; v_aux = V; if (((int)h_aux) == 0){ |
Tuvimos algún problema en las conversiones, perdiamos algo de información y no nos dimos cuenta de los rangos en los que estaba HSV, pero pudimos arreglarlo sin ningún problema.
|
image1->SetRGB(x/2, y/2, (h * 255/360), 0, 0); |
Sistema de Visión
Una vez tenemos el proxy al módulo de NaoCam podemos llamar a sus métodos.
Primero registraremos los parámetros en la cámara, ajustando la resolución, el tipo de imagen que queremos obtener y el refresco. En nuestro caso obtendremos la imagen en RGB en formato VGA (640 x 480) con 5fps de refresco.
|
gvm_fname = camera_proxy->call<std::string>(“register”, gvm_fname, |
Luego seleccionaremos la cámara que queramos usar, en nuestro caso usaremos una variable que modificamos con el interfaz gráfico para elegir entre la cámara frontal o la que apunta al suelo.
|
camera_proxy->callVoid(“setParam”, kCameraSelectID, camera_selection); |
Una vez configurada podremos coger la imagen de la cámara, usaremos el método getImageRemote en una llamada al proxy para obtener una imagen del tipo ALValue.
|
AL::ALValue lastImage; |
Antes de mostrar la imagen en el interfaz realizamos alguna prueba para verificar que la obteniamos correctamente. Sacamos de la imagen los datos que la definían (alto, ancho, número de capas (al ser rgb son 3), el tipo de imagen y el tamaño) y los imprimimos por la salida estándar (consola).
También nos creamos un fichero .ppm donde la guardabamos para poder comprobar con un editor de imagen que los colores son iguales.
Después de comprobar que lo hacía correctamente la mostramos por el interfaz. Tendremos que crearnos una variable del tipo wxImage y la pintaremos pixel por pixel con los componentes rgb leidos.
|
wxImage *image; |
Una vez tengamos la imagen tendremos que mostrarla por el interfaz, usaremos un cliente dc para ello.
|
wxBitmap bitmap1(*image); |
Al pintar la imagen pixel por pixel y tener los componentes RGB separados nos permite mostrarlos individualmente. En nuestro programa mostraremos los 3 y la imagen completa.
Sensores de ultrasonidos
Nao dispone de 2 parejas de ultrasonidos.
Para conocer el valor de ambos ultrasonidos en cada momento hay que acceder al módulo de memoria a través de su memoryProxy y obtener los datos de las siguientes posiciones utilizando el método getData. Los datos se almacenan en un array de 2 posiciones:
|
”extractors/alultrasound/distances” |
Con los valores obtenidos teniamos el mismo problema de siempre y es que nos devolvía enteros por lo que perdiamos los decimales. En este caso el problema era aun mas grave porque los valores que devuelve el ultrasonidos van desde 0 hasta 1, de forma que siempre nos devolvía 0 y no sabiamos si estabamos cogiendo los valores adecuados.
El dato verdadero se puede mirar en el módulo de memory cuando el webots esta en funcionamiento.
Sensores de presión
El Nao tiene 4 sensores de presión en cada pie.
Para conocer su valor hay que acceder al módulo de memoria a través de su memoryProxy y obtener los datos de las siguientes posiciones con el método getData
Para el pie izquierdo:
|
”Device/SubDeviceList/LFoot/FSR/FrontLeft/Sensor/Value” ”Device/SubDeviceList/LFoot/FSR/FrontRight/Sensor/Value” ”Device/SubDeviceList/LFoot/FSR/RearLeft/Sensor/Value” ”Device/SubDeviceList/LFoot/FSR/RearRight/Sensor/Value” |
Para el pie derecho:
|
”Device/SubDeviceList/RFoot/FSR/FrontLeft/Sensor/Value” ”Device/SubDeviceList/RFoot/FSR/FrontRight/Sensor/Value” ”Device/SubDeviceList/RFoot/FSR/RearLeft/Sensor/Value” ”Device/SubDeviceList/RFoot/FSR/RearRight/Sensor/Value” |
Con los valores obtenidos teniamos un gran problema, nos dimos cuenta que cualquier petición de datos al robot nos la devolvía siempre como un entero truncado, en este caso las medidas del sensor de presión son floats y tienen decimales los cuales perdemos.
En la siguiente consola observamos los valores del robot cuando esta parado, apoyado con ambos pies en el suelo. Cuando levanta un pie del suelo los valores son cero y los del pie apoyado incrementan.
Movimiento
En el apartado de movimiento, lo que teniamos que realizar es que Nao sea capaz de andar hacia delante y hacia atrás, además de poder girar a ambos lados.
Para andar hay que crear un proxy al ALMotion. Una vez lo tengamos creado ya podemos realizar las llamadas a los métodos del módulo, en nuestro caso:
setBodyStiffness: Es lo primero a lo que hay que llamar después de conectarse al módulo, sirve para dar fuerza a las articulaciones (el parámetro es un valor entre 0 y 1).
|
pmotion->setBodyStiffness(1.0); |
setWalkConfig: Sirve para ajustar los parámetros del nao al moverse. Con esta tuvimos problemas ya que si la usabamos el robot no andaba, sólo andaba si no la utilizabamos y dejabamos los valores por defecto del Webots.
Para girar si que podiamos emplearla con los siguientes parámetros y funcionaba perfecta:
|
pmotion->setWalkConfig( 0.05, 0.07, 0.04, 0.4, 0.01, 0.00); |
Para girar empleamos la función:
|
pmotion->turn(giro , 80); |
La variable giro tendrá el valor que se le asigne desde la interfaz por el usuario. El 80 es la velocidad con que girará el robot. De esta forma gira a la izquierda, para girar a la derecha solo habría que negar la variable giro.
Para andar empleamos la función:
|
pmotion->post.walkStraight(distancia, 80); |
La variable distancia tendra el valor asignado por le usuario desde la interfaz. El 80 es para lo mismo que en la funcion girar. Para andar hacia atrás basta con negar la variable distancia.
Como se puede observar en ambas funciones hemos empleado el prefijo post. Esto provoca que no sean bloqueantes las acciones de andar y girar para poder capturar imagenes al mismo tiempo.
En el siguiente video se pueden observar los problemas al andar después de ajustar los parámetros de caminata.
Enlace al video en ScreenCastle
1º Gira a la derecha sin haber ajustado los parámetros de giro correctos (se observa como se tambalea ligeramente).
2º Anda hacia delante con los parametros por defecto.
3º Gira a la izquierda habiendo ajustado los parámetros de giro buenos.
4º Se cae al intentar andar después de haber ajustado los parámetros de caminata.
El robot Nao
Este robot ha sido creado por Aldebaran Robotics, se engloba en la clase de humanoides. Principalmente es usado en la robocup para competición.
Este robot es muy completo, cuenta con muchos sensores y actuadores con los que manejarlo.
Tiene varios servos en todas sus articulaciones lo q le permite una gran movilidad y libertar de movimiento.
Además cuenta con diversos sensores para interactuar con el mundo, disponemos de 2 cámaras situadas en la cabeza, 2 sensores de ultrasonidos en el pecho, sensores de presión tanto en la planta como en la punta de los pies, 3 giroscopios en los 3 ejes de coordenadas, además de diversos leds, micrófonos y altavoces.
Conectando con Webots
Para conectar nuestra aplicación con el simulador webots se puede hacer de 2 formas diferentes pero con igual resultado.
1- Crear un proxy directamente desde nuestra aplicación al módulo seleccionado.
Nos conectaremos en un principio al módulo de la cámara “NaoCam” para obtener imagenes de las cámaras.
|
AL::ALProxy *camera_proxy; |
2- Crearnos un broker y sacar los proxies a través de él. Este modo nos permite hacer llamadas a los métodos de los módulos como si fuesen propios.
Crearemos un broker, introduciremos los parámetros para crearlo, el nombre del broker, la ip y el puerto, y la ip y puerto del broker padre.
|
AL::ALPtr pBroker; |
Una vez creado el broker crearemos a partir de él 2 proxies a los módulos que queremos, en este caso al de “ALMemory” y al “ALMotion”.
|
AL::ALPtr pmotion; |
Interfaz gráfico
El interfaz gráfico lo crearemos a partir de la librería wxWidget, usaremos el programa wxGlade que trabaja sobre esta librería y nos permite generar el interfaz de una forma cómoda y sencilla. wxGlade nos permite exportar el código en formato xrc que es fácilmente adaptable en un programa implementado en c++.
Al principio no nos dio demasiados problemas pero cuando iba creciendo la práctica y teniamos que añadir nuevos botones o cuadros de imagen, nos dio bastante guerra ya que era difícil de cuadrar cada uno.
Al final el interfaz gráfico fue el siguiente:
Introducción y objetivos
!!!Bienvenidos al blog sobre el robot Nao!!!
En primer lugar nos presentaremos: somos Daniel Montero y Alberto Sánchez, alumnos de Ingeniería Técnica en Informática de Sistemas de la UJRC.
Este blog está diseñado para la asignatura robótica de 3º de carrera y tratará sobre el robot Nao.
No trabajaremos sobre el propio robot, si no que emplearemos el simulador Webots que nos aportará ventajas como agilizar el proceso de pruebas y no correr el riesgo de romper el robot (al ser un robot bípedo es fácil que se caiga al suelo si se desestabiliza).
Los objetivos de la asignatura serán trabajar con los sensores y actuadores del robot, principalmente con las 2 cámaras de la cabeza. Además diseñaremos un interfaz gráfico no muy complejo para trabajar con nuestro programa.
