Algoritmos de visión para plataformas mini humanoide de competición con capacidades aumentadas

Transcripción

1 DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y AUTOMÁTICA TESIS DE MÁSTER Algoritmos de visión para plataformas mini humanoide de competición con capacidades aumentadas Autor: Franklin Eduardo Samaniego Riera Director: Dr. Alberto Jardón Huete MÁSTER OFICIAL EN ROBÓTICA Y AUTOMATIZACIÓN LEGANÉS, MADRID SEPTIEMBRE 2013

2

3 UNIVERSIDAD CARLOS III DE MADRID MÁSTER OFICIAL EN ROBÓTICA Y AUTOMATIZACIÓN El tribunal aprueba la tesis de Máster titulada ALGORITMOS DE VISIÓN PARA PLATAFORMAS MINI HUMANOIDE DE COMPETICIÓN CON CAPACIDADES AUMENTADAS realizado por Franklin Eduardo Samaniego Riera. Fecha: Octubre 2013 Tribunal: Dolores Blanco Rojas PRESIDENTE Concepción Alicia Monje Micharet SECRETARIO Juan G. Víctores VOCAL

4

5 Una madre tierna, comprensiva y cariñosa, un padre trabajador, honesto y fuerte en los momentos difíciles, los dos dispuestos a morir por ti y aunque separados por la distancia siempre puedo sentir su presencia protectora e incondicional. A mi Papá y mi Mamá. v

6

7 Índice de contenidos Índice de Contenidos... vii Índice de Figuras...xiii Índice de Tablas...xvii Agradecimientos...xix Resumen...xxi Abstract...xxiii 1 Introducción Motivación Carrera de Obstáculos Escaleras Lucha (Sumo) Prueba Libre exhibición Objetivos Generales Objetivos Específicos Estructura del documento Estado del Arte KHR Servomotor Kondo KRS Controladora RCB Robonova Servomotor Hitec...37 vii

8 2.2.2 Controladora Robonova MRC Bioloid Dinamixel AX Controladora Bioloid CM DarwinOP MX Controladora Darwin Z Selección de Hardware y Software Análisis de Hardware de control ROBOARD RB Arduino Raspberry Pi PC/104 o PC Selección de componente hardware Selección de componente software S.O Lubuntu vs Ubuntu Lubuntu Programación de robots Métodos de programación de robots Programación por guiado o aprendizaje Programación textual Procesamiento de imágenes Cámaras evaluadas Usb Webcam Minoru webcam Conclusiones Desarrollo de la Arquitectura Descripción del Sistema Simulación del modelo Bioloid 3D xml Tratamiento de información en AX Visión Artificial Unión de tareas Reproducción de movimientos...66 viii

9 3.2 Cinemática ROBOPLUS Modelo Cinemático desarrollado Instalaciones y configuraciones Medios empleados Sistema Operativo Instalación Lubuntu Configuración LAN DHCP + internet Instalación WebCam USB Configuración ax-12 en ROBOARD Configuración AX-12 método A Configuración AX-12 método B DMP RM-G145 3-Axis Gyro HMC ADXL OpenCV S.O. Modo texto Problema a resolver Volcado de movimientos Replica de Movimientos Visualización en Matlab Propuesta de caminado bípedo Formulación del problema Datos conocidos Incógnitas Busca del centro de gravedad Tratamiento de imagen Cámara simple Visión Estero Calibración de cámara estero MINORU Descriptor ORBFeatureDetector Estimación de distancia ix

10 6 Implementación, programación y puesta en marcha Montaje de herramientas hardware ROBOARD sobre mini-humanoide Minoru sobre mini-huanoide Mini tarjeta wifi sobre mini-humanoide Magnetómetro y acelerómetro sobre mini-humanoide Ejecución de movimiento de un AX speedmotor motionmotor torquemotor torquealarm motorid baudratemotor operationanglemotor operationvoltagemotor Plano sagital Plano axial Magnetómetro y acelerómetro Visión Artificial Visión Mono Visión estero Unión ROBOARD, AX-12, OpenCV Resultados Resultados en caminata Resultados de procesamiento de imagen Resumen de resultados Conclusiones y Trabajos Futuros Conclusiones Trabajos Futuros Referencias ANEXOS OpenRAVE x

11 Instalación de OpenRAVE Yarp Instalación y configuración de yarp Matlab & YARP Configuración de SWIG Configuración de enlaces de lenguaje Yarp Llamado de yarp desde Matlab Respaldo de Disco SD xi

12

13 Índice de Figuras Figura 1.1. Prueba de obstáculos...27 Figura 1.2. Prueba de escalera...28 Figura 1.2. Prueba de Sumo...29 Figura 1.4. Exhibición de Robots...29 Figura 2.1. Robot Mini-humanoide KHR Figura 2.2. Apariencia servomotor KRS...35 Figura 2.3. Controladora RCB Figura 2.4. Robonova...36 Figura 2.5. Apariencia Servo Hitec...37 Figura 2.6. Tarjeta controladora MRC Figura 2.7. Mini-humanoide bioloid...39 Figura 2.8. Servomotor Dinamixel ax Figura 2.9. CM AX Figura DarwinOP...41 Figura Apariencia MX Figura Intel Atom Z530 en Darwin...43 Figura Roboard RB Figura Apariencia Arduino...47 Figura Apariencia Rasberry Pi Figura Arquitectura Linux...53 Figura Apariencia Lubuntu, arrancada en modo consola...55 Figura Apariencia de una Webcam USB...58 Figura Apariencia webcam Minoru...59 Figura Esquema general del trabajo...60 Figura 3.1. Arquitectura general de modelo desarrollado...62 Figura 3.2. Arquitectura etapa Figura 3.3. Comunicación ROBOARD, AX Figura 3.4. Visión artificial una cámara...65 xiii

14 Figura 3.5. Visión Artificial dos cámaras...65 Figura 3.5. Nuevo modelo Bioloid Figura 3.6. Diagrama de flujo a seguir...67 Figura 3.8. Apariencia de las herramientas de ROBOTIS...68 Figura 3.9. Modelo triple péndulo y centro de gravedad...69 Figura 4.1. Ejecución del comando sudo dhclient...74 Figura 4.2. Modificar numero de interfaz...74 Figura 4.3. Modifica ip, dns e ip...75 Figura 4.4. Ejecución de una cámara USB...76 Figura 4.5. Full duplex como Half duplex...77 Figura 4.6. Conexión física de full a half duplex...78 Figura 4.6. Conexión física sensor DMP RM-G145 sobre ROBOARD...79 Figura 4.6. Ejemplo de codificación sensor magnetómetro...79 Figura 4.7. Ejemplo de codificación para el acelerómetro...80 Figura 5.1. Administración general de movimientos...84 Figura 5.2. Adición de un nuevo movimiento...84 Figura 5.3. Valores posibles de movimiento angular de un motor...85 Figura 5.4. Movimiento de un motor tomando dato desde la matriz...85 Figura 5.5. Traslación de datos desde el simulador hasta Matlab...86 Figura 5.6. Ejemplo de lectura de datos en un puerto desde Matlab...87 Figura 5.7. Conexión exitosa yarp-matlab mostrada desde el terminal...87 Figura 5.8. Parámetros definidos de una pierna...89 Figura 5.9. Visualización del problema...89 Figura Variación de espacio y amplitud en tiempo en recorrido de trayectoria de una pierna...92 Figura Simulación de una pierna...92 Figura Simulación de las dos piernas...93 Figura Algoritmo sobre el simulador...93 Figura Cambio del centro de gravedad...95 Figura Fotografía de un posible escenario...96 Figura Esquema de visión del robot...97 Figura Detección de un objeto dentro del campo de acción Figura Imagen de un Tablero de ajedrez...98 Figura Tomas con la cámara estero...99 xiv

15 Figura Calibración cámaras OpenCV Figura Imágenes de distorsión según la calibración Figura ORBFeatureDetector sobre una imagen Figura ORBFeatureDetector sobre un par de imagenes Figura Relación geométrica entre par de cámaras para la obtención de profundidad Figura 6.1. Montaje de ROBOARD sobre Bioloid Figura 6.5. Ejemplo de parámetros de velocidad para ax Figura 6.6. Ejemplo de parámetros de movimiento angular para ax Figura 6.7. Calculo de cinemática Inversa 3 DOFs Figura 6.8. Trayectoria a seguir de una pierna Figura Código base del magnetómetro Figura Código base del acelerómetro Figura Disminución de imagen tomada por el par de cámaras Figura Liberar imagen Figura 6.7. Curvas de los actuadores de las piernas Figura 6.8. Contraste de evolución angular ROBOTIS vs nuevo modelo Figura Aceleración de ejes, desde el centro de gravedad en las piernas Figura Robot y procesamiento de imagen con una cámara Figura Datos relevantes del procesamiento de imagen estereo Figura U mbralización de un par de imagenes Figura Disparidad imagen alterada Figura A.1. Apariencia OpenRAVE Figura A.2. Lanzamiento de yarpserver exitoso Figura A3. Ejecución en marcha ddrescue xv

16

17 Índice de Tablas Tabla 2.1. Características de servo motor KRS...35 Tabla 2.2. Características del Servo Hitec...37 Tabla 2.3. Características principales ax Tabla 2.4. Características MX Tabla 2.5. Especificaciones ROBOARD RB Tabla 2.6. Características Generales de Arduino...48 Tabla 2.7. Características Rasberry Pi...49 Tabla 2.8. Características PC/104 bus standard...51 Tabla 4.1. Configuración ip sobre lubuntu...75 Tabla 4.3. Instalación de dependencias para OpenCV...80 Tabla 4.4. Ejecución de los ejemplos de la biblioteca...81 Tabla A.2. Instalación Yarp Tabla A.3. Configuración de variables de entorno yarp Tabla A.4. Instalación de SWIG sobre linux Tabla A.5. Pasos a seguir para configuración de enlaces yarp Tabla A.6. Instalación de Enlaces Tabla A.7. Generación de clases faltantes para los enlaces yarp Tabla A.8. Llamado de yarp desde Matlab xvii

18

19 Agradecimientos: Primero quiero agradecer a mis padres1 y mis hermanos2 quienes a pesar de la distancia siempre me han apoyado, obteniendo de ellos la fuerza necesaria para continuar y nunca desfallecer. A Gloria3 quien me ha soportado junto a mi los malos momentos y me ha dado su apoyo incondicional. A mi tutor Alberto4 por haberme dado la oportunidad y ayudarme en la realización de este proyecto, a Juan5 y a todos lo catedráticos que me han ayudado a obtener los conocimientos necesarios para el desarrollo de este trabajo. 1 Wilfrido Rodrigo Samaniego Chavez y Carmita Piedad Riera Bonilla. 2 Wilfrido Rodrigo Samaniego Riera, Fredy Patricio Samaniego Riera, Diego Paúl Samaniego Riera. 3 Gloria Isabel Vanegas Zabala. 4 Alberto Jardón Huete, Post-Doc Researcher, Dept. Ingenieria de Sist. y Automatica, Esc. Politecnica Superior, Universidad Carlos III de Madrid. 5 Juan Gonzales Vítores, Doctorando Dept. Ingenieria de Sist. y Automatica, Esc. Politecnica Superior, Universidad Carlos III de Madrid. xix

20

21 Resumen La presente investigación esta centrada en la robótica humanoide y la creación de una arquitectura que sea capaz de replicar una serie de movimientos coordinados para el desenvolvimiento en caminata de un robot humanoide de 18 DoFs en un medio dinámico, adquiriendo así nuevas habilidades. El desarrollo del presente trabajo6 propone el remplazo total del procesador dedicado para este robot por otro procesador más potente basado en arquitectura x86, agregando así nuevas capacidades de procesamiento y liberándolo. La arquitectura que sustituirá a la anterior es un µpc denominado ROBOARD RB-110 en la cual se instalará un S.O. Linux lubuntu, y se ha programado en C++. Dada la tecnología x86 compatible, se ha centrado en hacer un segundo gran proceso, implementando dos algoritmos para la estimación de distancia con los que se podrá hacer una toma de decisiones en base a los resultados de estos datos, primero con una cámara simple y después con una cámara doble (estéreo), el robot podrá tomar decisiones en función de los datos recogidos del ambiente por medio de visión artificial aumentando así sus capacidades. Palabras clave: C++, DoFs, Linux, lubuntu, ROBOARD. 6 Hace falta mucho arte para crear algo que parezca desprovisto de arte Isaac Asimov xxi

22

23 Abstract This research is focused on humanoid robotics and the creation of an architecture that is capable of replicating a series of coordinated movements for the dynamic walking in a humanoid robot of 18 DoFs, acquiring with this new skills. The development of this work proposes total replacement of a dedicated processor for this robot by another more powerful processor based on the x86 architecture, adding new processing capabilities and releasing it. The architecture that replaces the old is a μpc called "RoBoard RB-110" which will install an OS Linux "lubuntu" and will programming with C + +. Given the support x86 technology, has focused on doing a second major process, implementing two algorithms for estimating distance with these results it's may make a decision based on these data, first with a simple camera and then with a dual camera (stereo), the robot can make decisions based on the data collected from the environment by increasing vision capabilities. Keywords: C + +, DoFs, Linux, lubuntu, RoBoard. xxiii

24

25 Capítulo 1 1 Introducción Sin lugar a duda el realizar una investigación que pretende hacer caminar a un robot bípedo comienza con una serie de movimientos pre-estudiandos y preprogramados, donde cada paso es idéntico al anterior. Este será el punto de partida para hacer este estudio. Explotaremos las cualidades de un mini-humanoide bioloid haciendo una replica de movimientos trabajados sobre este, tomando las características de la CPU x86 y los servomotores AX-12, fusionando de estas tecnologías, además de la implementación de unos algoritmos prácticos de visión artificial que ayudará al agente a cumplir con la tarea de movimiento en un entorno dinámico. Sobre la µpc RB-110 se ha instalado un Sistema Operativo Linux lubuntu, se han usado las funcionalidades de este S.O. programando los movimientos en C++,

26 26 Introducción siempre teniendo en cuenta que el procesador sobre RB-110 no es demasiado potente, así que se ha implementado una codificación no demasiado pesada, evitando hacer impresiones en pantallas de datos provenientes de algún cálculo o de las imágenes tomadas por las cámaras. 1.1 Motivación Pese a que no existe una definición7 precisa, se suele considerar que un robot humanoide con cierto grado de inteligencia, ha de imitar el comportamiento de los humanos, complementando a las personas en la realización de tareas útiles. Los robots, en la actualidad, se utilizan en el ámbito industrial (para montar piezas, desplazar grandes pesos y otras tareas), en la medicina (para operar en lugares de difícil acceso), en el campo militar (para reducir las bajas humanas), y en la educación para enseñar y desarrollar en el estudiante destrezas y habilidades para resolver un problema. La capacidad de la robótica[1] para cautivar a los estudiantes es tan evidente que varias Universidades se encuentran desarrollando concursos de minihumanoides, esta clase de concursos ayuda a la creatividad de los estudiantes al programar sus robot y el buscar las mejores configuraciones de hardware y software. CEABOT [2] es una competición española en la que se celebra de forma anual, su principal objetivos es mostrar las habilidades que cada robot humanoide posee mediante el desarrollo de varias pruebas. Este concurso es un escaparate para que las distintas universidades presenten sus progresos en el campo de los robots humanoides. Las pruebas presentadas en CEABOT son carrera de obstáculos, subir escaleras, pelea de sumo y Robots de exhibición, para cada una de estas actividades es necesario desarrollar no sólo estrategias de control para el movimiento del robot, sino que además es necesario dotar al robot con una lógica robusta que le permita desarrollar las tareas de manera autónoma y eficiente. 7

27 Motivación 27 Para cada una de las pruebas el robot debe tener una constitución antropomórfica, es decir dos piernas, un tronco y dos brazos articulados. Su peso máximo permitido es de 3 Kg, su altura máxima es de 50 cm y longitud máxima de 11 cm, esto quiere decir cuando el robot se encuentra bien estirado. Su locomoción deberá ser andar o correr a dos patas, no pudiendo utilizar ruedas, patines o similares, cada robot debe ser autónomo a nivel de locomoción sensorización y procesamiento, debiendo así tomar sus propias decisiones. A continuación se explicara a breves rasgos cada uno de estas pruebas Carrera de Obstáculos Esta prueba se basa en completar un recorrido a través de una zona plagada de obstáculos, teniendo que cruzar esta zona desde una línea de salida a otra de llegada sin tirar ni desplazar los obstáculos, una vez allí deberá dar la vuelta de forma autónoma e iniciar el proceso de vuelta al punto de partida. Hay que tener en cuenta que el suelo es de color verde y los obstáculos son de color blanco, como podemos apreciar en la figura 1.1. Figura 1.1. Prueba de obstáculos.

28 28 Introducción Escaleras En esta prueba se demuestra la capacidad del robot para subir y bajar escaleras caminando en una sola dirección (figura 1.2), no siendo permitido ningún tipo de salto o acrobacia. Una buena manera de apoyar al robot en la consecución de esta prueba, será la localización de la escalera. Figura 1.2. Prueba de escalera. Se finalizará la prueba cuando se haya sobrepasado totalmente la línea de salida o llegada parcial, según el sentido de comienzo de la prueba indicado por los jueces. Se puntuará la habilidad de superar la escalera de forma autónoma, valorando el que el robot supere escalones sin que caiga o se desvíe y penalizando cualquier intervención por parte del portavoz del equipo Lucha (Sumo) Esta prueba se realiza en una Área de combate llamado Ring (figura 1.3a), esta tendrá una forma circular, de color verde, homogéneo en la medida de lo posible y de 1.5m. de diámetro. Señalando el límite exterior del Ring, habrá una línea blanca o amarilla circular de 0.05m. de ancho y no habrán paredes ni otros obstáculos a menos de 0.5m del límite exterior.

29 Motivación 29 Figura. 1.3a. Estructura del Ring Figura 1.3b. Pelea de Robots Figura 1.2. Prueba de Sumo. La prueba consiste en pelear dos robots de dos equipos diferentes(figura 1.3b), dentro del área de combate según las normas de CEABOT, para obtener puntos efectivos (llamados puntos Yuhkoh). Se valora el comportamiento competitivo del robot, pudiéndose penalizar actitudes pasivas e inmóviles Prueba Libre exhibición La prueba de exhibición se basa en una libre demostración de lo que es capaz de hacer el robot mecánicamente, mediante una serie de movimientos como si fuese una coreografía, el tema o exhibición será libre y la única limitación será el tiempo, que no superará los 5 minutos. Figura 1.4. Exhibición de Robots.

30 30 Introducción 1.2 Objetivos Generales Cambiar el medio de control original por otra x86 compatible, para el procesamiento del mini-humanoide. El controlador original CM-510 que actúa sobre Bioloid maneja muy bien a los servos AX-12 pero tiene limitadas capacidades en procesamiento sin tener capacidad de evolución, por ello se hace la búsqueda de una tecnología más actual, compatible con x86, de tal manera que se amplíen sus capacidades y perdure en el tiempo, además que existirá escalabilidad con otras tecnologías basadas en x86. Realizar tareas de locomoción del modelo (caminado bípedo). El modelo original Bioloid ejecuta su propia secuencia para realizar la tarea básica de caminata, pero al cambiar el controlador original por otra x86 tecnología más actual es lógico pensar que se puede crear una nueva rutina que optimice este trabajo. Implementa un algoritmo de visión artificial utilizando OpenCV. Hasta la competición de CEABOT 2012, la forma de detección de obstáculos fue en base a sensores ultravioletas o de ultrasonido, estos sensores dan una respuesta muy variante según las condiciones de ambiente y por ello se propone la implementación de visión artificial, comenzando por un procesamiento con una sola cámara hasta un procesamiento en estereo. 1.3 Objetivos Específicos Reemplazar el procesador actual en bioloid CM-510 por la µpc ROBOARD RB-110. Luego de la realización del estudio de microprocesadores, se ha llegado a que la mejor opción es la utilización de la µpc ROBOARD RB-110, que será la que remplace al antiguo procesador CM-510. Moverse en un entorno dinámico. El nuevo modelo de robot mini-humanoide deberá ser capaz de realizar la tarea de navegación autónoma en un entorno definido siendo capaz de caminar siempre sobre sus extremidades inferiores detectando obstáculos, evitándolos y sin caerse.

31 Objetivos Específicos 31 Hacer comparación en rendimiento anterior y actual sobre el robot minihumanoide. Se hará una comparativa entre el funcionamiento anterior y actual sobre el caminado de robot, evaluando las curvas generadas por los actuadores incidentes en esta tarea. 1.4 Estructura del documento El presente documento esta dividido en varios capítulos, en los cuales se detalla el desarrollo del trabajo realizado, en el capítulo 1 se hace un breve introducción de lo que se pretende lograr y la motivación por la que se desarrollo este estudio, el capítulo 2 muestra el estado del arte en un breve resumen de las tecnologías creadas y utilizadas dentro de estos temas, el capítulo 3 muestra el diseño de la arquitectura propuesta e implementada, en el capítulo 4 se resume la instalación y configuración de los principales componentes utilizados, en el capítulo 5 se hablará del algoritmo creado para lograr el objetivo de caminado bípedo a demás del procesamiento de imagen, en el capítulo 6 mostrará la implementación y puesta en marcha a demás de los resultados obtenidos después de la ejecución, en el capítulo 7 se presentará las conclusiones y trabajos futuros.

32

33 Capítulo 2 2 Estado del Arte En el presente capítulo se hará un resumen de las tecnologías hardware y software utilizados por robots mini-humanoides de interés previamente usados en CEABOT a demás de conceptos similares básicos de funcionalidad en dichas tecnologías. Primero se realizará una descripción de los posibles mini-humanoides estudiados, sus micro-controladores a demás de los servomotores que cada tecnología utiliza, para luego compararlos, al final se hablará del Sistema Operativo instalado sobre la placa, dado que para el desarrollo del algoritmo que se encargará del caminado se ha hecho con cinemática inversa, también se mencionará la programación de robots.

34 34 Estado del Arte 2.1 KHR1 Es importante hacer mención a KHR1 (figura 2.1), este modelo de robot humanoide fue el primero con el que trabajo la Universidad y no debería ser olvidado con el paso del tiempo, creado por la compañía Kondo con una dimensión en altura igual a 340 mm y un peso de 1kg, tuvo muchas carencias ya que no realizaba ningún tipo de control real sobre los servos dejando que estos actúen en un lazo abierto. Aún así, afinando los algoritmos se consigue un grado relativamente elevado de confianza en el robot. KHR1 tiene 17 servomotores KRS-786ICS Digital Servos que los dotan de igual número de DoFs. Los problemas sobre este modelo consisten en en que el controlador interno es de baja calidad, su costo aproximado fue de 900 y 1300, pero ya esta fuera del mercado. Figura 2.1. Robot Mini-humanoide KHR Servomotor Kondo KRS Los problemas con estos servos (figura 2.2) consisten en que, el controlador interno que tiene para mantener los grados que se le han indicado, es de baja calidad. Llegaba un momento en el cual, el mismo controlador al tratar llevar al servo a una posición lo hacia a tanta velocidad que "se pasa" lo cual obliga a reajustarlo cada vez más. Sin embargo, siempre lo hace tan rápido que siempre se 8

35 KHR1 35 pasa y vuelve a iniciarse el proceso. Por lo que acaba provocando que la articulación tiemble cada vez más y sin llegar a pararse a no ser que se le pida otra posición a dicho servo. Figura 2.2. Apariencia servomotor KRS.9 Las características principales de estos actuadores utilizados en el minihumanoide se pueden ver en la tabla 2.1. Tabla 2.1. Características de servo motor KRS. Engranajes de resina de doble cara perfeccionada. Limite 180º Troque 20kg/cm Velocidad 60º sec Voltaje 6V Tamaño 41x35x21mm Controladora RCB-1 La información sobre el controlador del mini-humanoide KHR1 es bastante escasa pero se puede mencionar varios aspectos importantes. Dos controladoras de nombre RCB-1 (figura 2.3) fueron las encargadas de inter-actuar con los servos KRS, con un tamaño de 45x35xl6mm, peso: 12g, voltaje de 6V y 600mA-Hr con una duración cercana a los 20 minutos, maneja hasta 12 servos, posee 128kb de memoria y una capacidad para almacenar 40 secuencias de 100 posiciones cada una, un RS-232 cable serial para la conexión con el PC y el PC puede controlar las dos placas si están unidas en "Daisy-chain10", las baterías proporcionan 6V es un esquema de cableado usado en ingeniería eléctrica y electrónica.

36 36 Estado del Arte Figura 2.3. Controladora RCB Robonova Es un robot humanoide de 305 mm de altura y un peso de 1,3 Kg, está construido en base al kit comercial Robonova-1 (figura 2.4). Tiene 16 servomotores digitales HSR-8498HB de Hitec12 que se corresponden con los 16 grados de libertad o articulaciones con las que contará el robot[3] (cinco en cada pierna y tres en cada brazo). Un potente microcontrolador ATMEL ATMega 128 con amplias reservas de rendimiento se sitúa en el corazón de la Robonova, el coste aproximado del kit es de 900. Figura 2.4. Robonova

37 Robonova Servomotor Hitec Estos servos (figura 2.5) que tienen un rango de giro de 180º y un par de fuerza superior a los 7,4 Kg cm, son los que permitirán el movimiento del robot. Estos servos que son trasmitidos por engranajes de carbonita, más resistentes y duraderos que los de nailon han sido diseñados específicamente para este robot e incluyen una característica especial conocida como Feedback Motion, que permite leer desde el controlador la posición real del servo, pudiéndose colocar el robot manualmente en cualquier posición para luego leer y guardar la configuración de los 16 servos en un programa. Figura 2.5. Apariencia Servo Hitec.14 Los servos Hitec se caracterizan por su calidad técnica (tabla 2.2) y sus excelentes características mecánicas y electrónicas hacen que sean los servos muy utilizados en el montaje de robots. Tabla 2.2. Características del Servo Hitec. Sistema de Control Control por Anchura de Pulso. 1,5 ms al centro Tensión de funcionamiento 4,8V a 6 V Velocidad a 6V 0,16 Seg /60 grados sin carga Fuerza a 6V 4,1 Kg x cm Dimensiones 40,6 x 19,8 x 36,6 mm Peso 45,5 g Corriente Máxima 1100 ma Zona Neutra 8 µsec Rango Trabajo 1100 a 1900 µsec 14

38 38 Estado del Arte Controladora Robonova MRC-3024 El Robonova tiene incorporado como sistema de control la tarjeta controladora MRC-3024 (figura 2.6), gobernada por un micro controlador Atmel Atmega 128 de 8 bits y de procesamiento centralizado, cuenta con una memoria de 64 Kbits de tipo flash, lo que le permite ejecutar gran cantidad de pasos y movimientos de forma autónoma. Tiene un total de 40 puertos de entrada y salida y es capaz de controlar 24 servos, con 8 puertos de A/D, 3 salidas PWM y puerto serie de alta velocidad, sus medidas son de 61 x 50.5 cm. Figura 2.6. Tarjeta controladora MRC Bioloid La plataforma robótica modular Bioloid16 (figura 2.7) de la compañía ROBOTIS, es una de las plataformas más completas de robótica modular, a demás Bioloid tiene la posibilidad de ampliarse. Con bioloid se puede llegar a crear un gran número de robots distintos, desde un humanoide hasta un dinosaurio, y gracias a su modulo de sensores se puede interactuar de manera sencilla con el. Este modelo con 18 servomotores e igual número de grados de libertad, posee una altura de 397 mm y un peso de 1,7 Kg, el kit Bioloid Premium tiene un costo aproximado a 1000,00. Su µprocesador ATMega 2561 junto a la tecnología de sus actuadores AX-12 otorgan a Bioloid la capacidad de un procesamiento distribuido

39 Bioloid 39 Figura 2.7. Mini-humanoide bioloid Dinamixel AX-12 Bioloid trabaja con actuadores Dinamixel AX-12 cada uno tiene su propio controlador, estos actuadores son accionadores inteligentes y modulares que incorporan un reductor de engranajes, un motor de corriente continua de precisión y electrónica de control con capacidad de red, todo en una caja. Los servomotores AX-12 (figura 2.8) de BIOLOID son controlados por una conexión serie a 1 Mbps y pueden ser conectados entre sí para crear cadenas de servomotores (hasta 254 servomotores pueden ser conectados). El sistema de comunicación permite controlarlos a todos al mismo tiempo (ponerlos en movimiento o sincronizarlos), todo esto a una velocidad de comunicación de 1 Mbps, se resumen sus características principales en la tabla 2.3. Figura 2.8. Servomotor Dinamixel ax-12.

40 40 Estado del Arte Tabla 2.3. Características principales ax Peso 55 g Voltaje de entrada (V) 7 V a 10 V Torque final máximo (kgf x cm) Sec/60degree Resolución 0.35 Angulo de operación 300, Endless Turn Corriente máxima 900mA Señal de control Paquetes Digitales Tipo de protocolo Half duplex Asynchronous Serial Communication (8bit,1stop,No Parity) Conexión física TTL Level Multi Drop (daisy chain type Connector) ID 254 ID (0~253) Velocidad de comunicación 7343 bps ~ 1 Mbps Controladora Bioloid CM-510 La tarjeta controladora (figura 2.9) se basa en un µcontrolador Atmega 256 de 8 bits, que a demás de la capacidad de controlar servomotores AX-12 (motores de rotación continua) por un control estándar serial TTL (figura 2.9b), posee 6 puertos de entrada/salida de propósito general para conectar extensiones y otros sensores adicionales, como sensores de distancia (IR. Infrarrojo) aunque se puede conectar otros sensores para conseguir mayor potencia y flexibilidad, también ha sido diseñado para la gestión de baterías LiPo. La tarjeta CM-510 mide 85 x 52 x 25 mm, y tiene 5 botones (1 reset y 5 puertos) para que el usuario interactue de manera sencilla con él, por último cuenta con un Sensor acelerómetro GYRO que proporciona señales en los ejes cartesianos x, e y. 17 Dynamixel AX-12 User s Manual

41 Bioloid 41 Figura 2.9a. Apariencia CM-510. Figura 2.9b. Conexión varios AX-12. Figura 2.9. CM AX DarwinOP El robot Darwin OP, (Dynamic Anthropomorphic Robot with Intelligence Open Platform)[4] es un robot humanoide de la empresa Robotis, tiene una altura de 450 mm y 522 mm de palmo a palmo. Darwin OP (figura 2.10) cuenta con una capacidad comunicacional avanzada, sensores sofisticados y un canal externo de audio (todo esto lo provee de un determinado comportamiento autonomo), tiene veinte grados de libertad (seis grados de libertad para cada pierna, tres para cada brazo y dos para la cabeza), cada uno controlado por un MX-28 servomotor Dynamixel. El MX-28 tiene un par de bloqueo de 24 kgf x cm (a 12 V, 1,5 A) y un rango de 360 grados de movimiento. El costo aproximado del kit es de 1800,00. Figura DarwinOP

42 42 Estado del Arte MX-28 Cada servo motor (figura 2.11) tiene su propio micro controlador, lo que permite una red de servos para ser controlados por un microprocesador a través de una sola red de TTL, el MX-28 pesa 72g y tiene una resolución de 0.088º y una relación de reducción de engranajes 193:1. El MX-28 proporciona la retro alimentación de la temperatura, la posición, la carga y la tensión de entrada, lo que indica un recalentamiento y parada de emergencia, cuando la temperatura es superior a su rango, más características se detallan en la tabla 2.4. Figura Apariencia MX-28. Tabla 2.4. Características MX-28. MCU ST CORTEX-M3 ( 72MHZ,32BIT) Sensor de posición Contactless absolute encoder (12BIT,360 DEGREE) BAUD RATE 8000 bps ~ 4.5 Mbps Resolución Ángulo de operación 0 ~ 360 Endless Turn Peso 72g Dimensión 35.6mm x 50.6mm x 35.5mm Torque 2.3N.m (at 11.1V, 1.3A) 2.5N.m (at 12V, 1.4A) 3.1N.m (at 14.8V, 1.7A) Potencia sin carga 50rpm (at 11.1V) 55rpm (at 12V) 67rpm (at 14.8V) Temperatura -5 ~ +80 Voltaje 10 ~ 14.8V (Recomendado 12V)

43 DarwinOP 43 Señal de comando Tipo de protocolo Digital Packet MX-28T (Half duplex Asynchronous Serial Communication (8bit,1stop, No Parity)) MX-28R (RS485 Asynchronous Serial Communication (8bit,1stop, No Parity)) Conexión física MX-28T (TTL Level Multi Drop Bus) MX-28R (RS485 Multi Drop Bus) ID 254 ID (0~253) Corriente en reposo 100 ma Controladora Darwin Z530 El procesador del Darwin OP (figura 2.12) es un procesador Intel Atom Z530 a 1.6 GHz con 4 GB de memoria flash integrada de 32 bits, compatible con x86. El sistema de control cuenta con dos tarjetas: 1 PC y 1 CM-730, la primera se encarga de todas las interfaces con las que cuenta el robot, mientras la segunda, del control de los servomotores, todos los actuadores MX-28 ponen en movimiento al robot, puede caminar a una velocidad de 24,0 cm/s con un tiempo de paso de 0,25 seg/paso, en cada acción intervienen los actuadores de sus piernas, brazos, y cuello. Cuenta como su nombre lo indica un software de licencia libre, del mismo nombre (Darwin OP). Figura Intel Atom Z530 en Darwin

44 44 Estado del Arte 2.5 Selección de Hardware y Software Una vez estudiados estos modelos de mini-humanoides, analizando sus fortalezas y debilidades (tabla 2.5), se ha decidido trabajar con el mini-humanoide bioloid, sus actuadores AX-12 tienen una tecnología superior a un servo motor común, trabajan en red de acuerdo a un ID y esto evita una gran cantidad de cable desde el actuador hasta el procesador. Tabla 2.5. Características relevantes de los modelos mini-humanoides. KHR1 Robonova Bioloid DarwinOP Costo , DoFs Actuadores KRS-786ICS Hitec KgHSR- AX-12 Digital MX HB Servos Comunicación lazo abierto con actuadores Tamaño humanoide Peso del 300x500x80 mm del 1 kg Centralizada Distribuida Distribuida analógica (TTL Level (TTL Level Multi Drop Multi Drop (daisy chain (daisy chain type type Connector) Connector) 30 x 55 x x 150 x 450 mm x 522 mm altura 120 mm mm 1,3 Kg 1,7 kg 2.4 kg humanoide MX-28 es una mejora del AX-12, tiene mayores capacidades (resolución angular, velocidad de transmisión/recepción de datos) y con ello mucho mayor costo. El kit de bioloid permite hacer varias configuraciones del robot, su precio supera a robonova, pero es mucho menor que Darwin, otro motivo por el cual utilizar bioloid. Sin embargo el procesador de bioloid CM-510 encargado de trabajar con AX12 es bastante limitado en sus prestaciones, por lo que será descartado y 3131

45 Selección de Hardware y Software 45 reemplazado por otro más potente, una opción es utilizar el procesador de Darwin pero solo el costo de este procesador supera al mismo bioloid, por lo que se ha optado por otro hardware de control, con lo que se ha hecho el análisis y posterior definición del procesador con el que se trabajará Análisis de Hardware de control Existe una gran cantidad de hardware con el que se puede trabajar, en esta sección se hará un resumen de las tecnologías aplicables y el motivo por el cual se ha definido una u otra ROBOARD RB-110 Roborad (figura 2.13) es una tarjeta creada para desarrollar aplicaciones robóticas, tiene un procesador de 32 bits x86 CPU y una velocidad de procesamiento de 1 Ghz, 256 MB RAM, consumo 2.3 [W] y de medidas 96 x56 mm. Tiene una buena relación costo/rendimiento a demás de un promedio de vida útil de 10 años, compatible con varios sistemas operativos como Linux, Windows y DOS, sus especificaciones están resumidas en la tabla 2.5. Al ser x86 compatible, permite la utilización de bibliotecas de desarrollo para Pc como Opensource C++ (permite una programación en alto nivel), OpenCV (procesamiento de imagen), también tiene compatibilidad con puertos USB, COM, LAN, JTAG, I2C, Analógicos, Mini PCI. Figura Roboard RB

46 46 Estado del Arte Tabla 2.5. Especificaciones ROBOARD RB-110. RB-110 CPU DM&P Vortex86DX- 1000MHz BIOS AMI BIOS Memory 256MB DDR2 onboard ADCs Analog Devices AD bit Hi-Speed UART FTDI FT2232HL Hi-Speed UART I /O Interface Connectors Resolution Micro SD slot x 1 USB port x 1 (USB 2.0 version) PWM x 16 RS-232 x 1 Hi -speed (COM6) x 1 High speed (COM5) x 1 RS-485 x 1 TTL serial x 2 I2C x 1 A/D x 1 USB x 1 LAN x 1 JTAG x 1 Mini PCI Card connector Power x 2 PWM : 20ns Serial : bps/750Kbps (COM 1, 2, 3 & 4) High Speed Serial : Up to 12Mbps (COM5 & COM6) Power I2C : 1Kbps ~ 3.3Mbps 400mA Consumption Power Input DC-in 6V to 24V Dimension 96mm x 56mm Costo 180,00

47 Selección de Hardware y Software Arduino Arduino21 es una plataforma de electrónica abierta para la creación de prototipos basada en software y hardware flexibles y fáciles de usar. Se creó para artistas, diseñadores, aficionados y cualquiera interesado en crear entornos u objetos interactivos. Arduino (figura 2.14) puede tomar información del entorno a través de sus pines de entrada de toda una gama de sensores y sin que puede afectar aquello que le rodea controlando luces, motores y otros actuadores. El microcontrolador en la placa Arduino se programa mediante el lenguaje de programación Arduino (basado en Wiring) y el entorno de desarrollo Arduino (basado en Processing). Figura Apariencia Arduino.22 Existe una gran cantidad de arduino en el mercado y dependiendo de las necesidades del usuario se escoge una u otra, y dependiendo de su variedad poseerá unas u otras características sin embargo, se hará una descripción un poco general (tabla 2.6) de las características del procesador de arduino, sabiendo que esta tecnología esta basada en Atmega 168/328/1280 de 8bits

48 48 Estado del Arte Tabla 2.6. Características Generales de Arduino. Voltaje operativo Voltaje de entrada recomendado Voltaje de entrada límite Pines de entrada y salida digital Pines de entrada analógica Intensidad de corriente Atmega168 5V Atmega328 5V Atmega1280 5V 7-12 V 7-12 V 7-12 V 6-20 V V ( V (6 54 proporcionan proporcionan PWM) 6 40 ma PWM) 6 40 ma 32KB 16KB Memoria Flash (2KB reservados para el bootloader) SRAM EEPROM Frecuencia de reloj Costo 1 KB 512 bytes 16 MHz 30,00 (14 proporcionan PWM) ma (2KB 128KB (4KB reservados para bootloader) 2 KB 1 KB 16 MHz 40,00 reservados el para el bootloader) 8 KB 4 KB 16 MHz 50,00 De acuerdo con las características de los diferentes Arduino, no es posible conectar los servomotores AX-12, sin embargo la placa controladora CDS55xx compatible, hace posible la comunicación con dichos servos mediante un puerto UART y así los servos ROBOTIS Bioloid/Dynamixel AX-12 pueden conectarse en bus serie Raspberry Pi Raspberry Pi23 (figura 2.15) es una placa computadora (SBC) de bajo costo desarrollada en Reino Unido por la Fundación Raspberry Pi, con el objetivo de estimular la enseñanza de ciencias de la computación. La fundación da soporte para las descargas de las distribuciones para arquitectura ARM, Raspbian (derivada de Debian), RISC OS 5, Arch Linux ARM (derivado de Arch Linux) y Pidora (derivado de Fedora); y promueve principalmente el aprendizaje del lenguaje de programación Python, y otros 23

49 Selección de Hardware y Software 49 lenguajes como Tiny BASIC, C y Perl. Figura Apariencia Rasberry Pi.24 El diseño incluye un System-on-a-chip Broadcom BCM2835, que contiene un procesador central (CPU) ARM1176JZF-S a 700 MHz y 32 bits (el firmware incluye unos modos Turbo para que el usuario pueda hacerle overclock de hasta 1 GHz sin perder la garantía), un procesador gráfico (GPU) VideoCore IV, y 512 MB de memoria RAM aunque originalmente al ser lanzado eran 256 MB. El diseño no incluye un disco duro o una unidad de estado sólido, ya que usa una tarjeta SD para el almacenamiento permanente; tampoco incluye fuente de alimentación o carcasa (tabla 2.7). Tabla 2.7. Características Rasberry Pi. SoC: CPU: GPU: Memoria (SDRAM): Puertos USB 2.0: Entradas de vídeo: Modelo A Modelo B Broadcom BCM2835 (CPU + GPU + DSP + SDRAM + puerto USB) ARM1176JZF-S a 700 MHz (familia ARM11) Broadcom VideoCore IV,59, OpenGL ES 2.0, -2 y VC-1 (con licencia), 1080p30 H.264/MPEG-4 AVC 256 MB (compartidos 512 MB (compartidos con la GPU) con la GPU) desde el 15 de octubre de (vía hub USB integrado) Conector [[MIPI] CSI que permite instalar un módulo de 24

50 50 Estado del Arte Salidas de vídeo: Salidas de audio: Almacenamiento integrado: Conectividad de red: camara desarrollado por la RPF Conector RCA (PAL y NTSC), HDMI (rev1.3 y 1.4), Interfaz DSI para panel LCD Conector de 3.5 mm, HDMI SD / MMC / ranura para SDIO Ninguna 10/100 Ethernet (RJ-45) via hub USB Periféricos de bajo 8 x GPIO, SPI, I²C, UART nivel: Reloj en tiempo real: Ninguno Consumo energético: 500 ma, (2.5 W) 700 ma, (3.5 W) Dimensiones: 85.60mm 53.98mm ( inch) GNU/Linux: Debian (Raspbian), Fedora (Pidora), Arch Sistemas operativos Linux (Arch Linux ARM),Slackware Linux. soportados: RISC OS Costo 50, PC/104 o PC104 PC/104 o PC10425 (figura 2.16) es un estándar de ordenador embebido que define el formato de la placa base (form factor) y el bus del sistema, PC/104 especifica dos versiones de módulo 8 bits y 16 bits que corresponden a implementaciones de bus PC y PC/AT, respectivamente. A diferencia de la clásica arquitectura ATX y bus PCI que son usados en la mayoría de los ordenadores personales, el PC/104 está diseñado para aplicaciones específicas, como adquisición de datos o sistemas de control industrial. La arquitectura de la placa base no es la típica placa de circuitos integrados (backplane) en el que van insertados los componentes; en lugar de eso, los componentes se encuentran en módulos que son apilados unos encima de otros, el tamaño estándar es de 900 mm 950 mm. Aunque los módulos PC/104 han sido fabricados a partir de 1987, no se publicó una especificación formal hasta Desde entonces, el interés en 25

51 Selección de Hardware y Software 51 PC/104 se ha disparado, con más de un centenar de diferentes tarjetas PC/104. En 1992, el IEEE comenzó un proyecto para estandarizar un diseño de fabrica reducida, la especificación IEEE P996 para buses PC y PC/AT, en aplicaciones embebidas. La especificación PC/104 ha sido adoptada como el documento de base para este nuevo proyecto de norma IEEE, llamado el estándar P996.1 Standard for Compact Embedded-PC Modules. Figura 2.16a. PC-104. Figura 2.16b.Modulos sobre PC-104. Figura Apariencia PC-104. La tabla 2.8 proporciona las especificaciones de una PC/104 de bus standard, 6-channel analógicos y salida de tarjetas. Tabla 2.8. Características PC/104 bus standard. Salida analógica 6 canales de 12 bits de doble búfer Rango de salida: Unipolar: 0 ~ 5V, 0 ~ 10V Bipolar: ± 10V, ± 5V Corriente en bucles: 4 ~ 20 ma, ± 10 V DC externa o AC Tensión de referencia: Interna: -5V,-10V externa: DC o AC, hasta ± 10 V Entrada digital: 16 canales, compatible con TTL Entrada: De bajo nivel:-0.5v ~ 0.8V alto nivel: 2.0V ~ 5.0V Corriente de entrada: 0,2 0,4 V (máx.)

52 52 Estado del Arte Salida Digital: 16 canales, compatible con TTL Bajo nivel: (máx.) De alto nivel: (mín. PC/104 Arquitectura Conector macho de 10 pines x 2 x 20pin y 2 Entrada digital Canal: 16 canales Nivel eléctrico: compatible con el nivel eléctrico TTL Entrada: bajo nivel eléctrico:-0.5v ~ 0.8V alto nivel: 2.0V ~ 5.0V Corriente de entrada: 0,2 0,4 V (máx.) Desviación: 0,2 V ~ 0,4 V Salida digital Canal: 16 canales Nivel eléctrico: compatible con el nivel eléctrico TTL Salida: Nivel bajo: 24mA@0.5V (máx.) Nivel alto: 15mA@2.0V (Min.) Desviación: 0,2 V ~ 0,4 V Costo 170, Selección de componente hardware Una vez estudiadas varias opciones tecnológicas, se ha seleccionado una de ellas, haremos un resumen del por qué de dicha selección. Sin lugar a duda Rasberry Pi es una buena opción por su tecnología, supera a Arduino, permitiendo una instalación de sistema operativo y la opción de programación en alto nivel, a demás el precio contra Arduino es muy similar, sin embargo esta tecnología no permite hacer procesamiento de imagen y sin esto nuestro robot no puede navegar de forma autónoma por lo que estas tecnologías se descartan. Lo que nos deja opciones entre ROBOARD y PC-104, las características de PC-104 superan a ROBOARD en procesamiento, ROBOARD lo supera en otras

53 Selección de Hardware y Software 53 como numero pines digitales, analógicos y puertos COM, sus precios y su tamaño son similares. PC-104 puede tener todas las características de ROBOARD y mucho más pero habrá que añadir los módulos necesarios, esto crea una torre aumentando así su tamaño, mientras que en ROBOARD, su tamaño no cambiará ya sea que a este este conectada la mini-tarjeta VGA o la mini-tarjeta wifi, por lo que se ha seleccionado a ROBOARD como plataforma de control en el desarrollo de este trabajo y dado que a este hardware se tiene que instalar un S.O. se trabajará bajo una plataforma libre linux Selección de componente software S.O Sin embargo hay una gran variedad de S.O. Linux pero su arquitectura (figura 2.17) siempre es la misma, por lo que se ha hecho un breve análisis de cual será la distribución a ser instalada. La distribución que debe ser seleccionada tiene que tener muy en cuenta los requerimientos del sistema, a demás de explotar la mínima cantidad de recursos para así optimizar el rendimiento del hardware seleccionado, también una mayor capacidad en uso eficiente de la energía en aplicaciones como LXDE26, un entorno de escritorio ligero, por lo que se han analizado dos S.O. basados en linux Lubuntu y Ubuntu. Figura Arquitectura Linux "Lightweight X11 Desktop Environment", que en español significa Entorno de escritorio X11 ligero 27

54 54 Estado del Arte Lubuntu vs Ubuntu Tanto Ubuntu y Lubuntu comparten dos cosas importantes principales: Mismo núcleo del sistema. Mismos repositorios. Lubuntu y Ubuntu pertenecen a la misma familia y por lo que no es correcto referirce de cada uno como dos sistemas totalmente diferentes, ya que tienen algunas cosas en común. Comparten la misma zona Forum y comparten muchas páginas Wiki28. Las diferencias entre Lubuntu y Ubuntu son: Diferente DE29 - Lubuntu utiliza LXDE mientras Ubuntu utiliza la Unity 30 como la DE por defecto. Diferentes aplicaciones predeterminadas. El objetivo del proyecto Lubuntu es crear una variante de Ubuntu que es más ligero, con menos ávidas de recursos y más energía eficiente utiliza aplicaciones ligeras y LXDE, el entorno de escritorio X11 es muy ligero por lo que será este el sistema operativo a instalar Lubuntu. Lubuntu31 es Sistema Operativo basado en Ubuntu, su lema es menos recursos y más eficiencia energética, posee un entorno de trabajo (figura 2.18) muy ligero X11 (LXDE), el objetivo de la creación de esta distribución con todas las ventajas y funcionalidades (repositorios, soporte, etc.) lo hace muy adecuado para correr sobre un hardware como ROBOARD. 28 es un sitio web cuyas páginas pueden ser editadas por múltiples voluntarios 29 Entorno de escritorio 30 Unity es un interfaz de usuario creada para el entorno de escritorio GNOME 31

55 Selección de Hardware y Software 55 Figura Apariencia Lubuntu, arrancada en modo consola. Los requerimientos de hardware de Lubuntu/LXDE son similares a los de Windows XP. Un viejo CPU Pentium II o III entre MHz es suficiente, Una vez iniciado X.org y LXDE, el uso total de memoria aproximado es de 60 MB en máquinas i386. Este valor puede ser más alto o más bajo dependiendo de las diferentes configuraciones de sistema. Así que es recomendable tener mínimo entre MB de memoria RAM o más, todo esto lo hace adecuado para una instalación en ROBOARD. 2.6 Programación de robots Programar un robot consiste en indicar paso por paso las diferentes acciones (moverse a un punto, abrir o cerrar la pinza, etc.) que éste deberá realizar durante su funcionamiento. Un robot[5] puede ser programado mediante guiado o mediante un procedimiento textual. Los esfuerzos por unificar en cierta medida los procedimientos de programación no han tenido hasta la fecha el reconocimiento y la aceptación necesaria, forzando así a que cada fabricante desarrolle su lenguaje, valido únicamente para sus propios robots.

56 56 Estado del Arte El sistema de programación es, por tanto, la herramienta con que cuenta el usuario para acceder a las diversas prestaciones del robot, existiendo una relación directa entre las características y posibilidades del sistema de programación y las del robot en si mismo Métodos de programación de robots Programar un robot consiste en indicar paso por paso las diferentes acciones (moverse a un punto, abrir o cerrar la pinza, etc.) que éste deberá realizar durante su funcionamiento automático. La flexibilidad en la aplicación del robot y, por tanto, su utilidad dependerá en gran medida de las características de su sistema de programación. Un robot puede ser programado mediante lo que se denomina guiado o mediante un procedimiento textual (método que se ha adoptado en este trabajo), existiendo robots que conjugan ambos modos. Este primer nivel de división admite un segundo, atendiendo a la potencia y particularidades del método de programación. Las características de cada procedimiento de programación serán mas o menos ventajosas según la aplicación a la que se destine el robot Programación por guiado o aprendizaje La programación por guiado o aprendizaje consiste en hacer realizar al robot, o a una maqueta del mismo, la tarea (llevándolo manualmente, por ejemplo) al tiempo que se registran las configuraciones adoptadas, para su posterior repetición de manera automática. Para guiar al robot por las trayectorias o puntos deseados se utilizan diferentes soluciones. Si los actuadores del robot están desconectados y es el programador quien debe aportar directamente la energía para mover el robot, se trata de un guiado pasivo. En este caso, el programador puede tomar el extremo del robot y llevarlo hasta los puntos deseados siguiendo las trayectorias mas adecuadas. La unidad de control del robot registrara, de manera automática, la serial de los sensores de posición de las articulaciones en todos los puntos recorridos. Este tipo

57 Programación de robots 57 de guiado se denomina guiado pasivo directo Programación textual Como alterativa a la programación por guiado, el método de programación textual que permite indicar la tarea al robot mediante el uso de un lenguaje de programación especifico. Un programa se corresponde ahora, como en el caso de un programa general, con una serie de órdenes que son editadas y posteriormente ejecutadas. Existe, por tanto, un texto para el programa. El texto del programa es editado en un sistema informático que puede ser independiente del robot, no precisando por ello, a diferencia de la programación por guiado, la presencia de éste durante la fase de desarrollo del programa. Por este motivo también se conoce a este método de programación como fuera de linea. Es necesario especificar cada uno de los movimientos que ha de realizar el robot, así como la velocidad, direcciones de aproximación y salida, apertura y cierre de la pinza, etc. Sera necesario también descomponer la tarea global en varias subtareas. 2.7 Procesamiento de imágenes Una vez que se ha definido una nueva CPU x86 con altas capacidades, se ha planteado el hacer algo de procesamiento de imágenes [6] (visión por computador) de tal manera que el robot pueda facilitar la búsqueda de información y así hacer una interpretación visual de su entorno. El objetivo principal de este trabajo no es el procesamiento de imágenes sin embargo se hará un poco de ello, por lo que cabe hacer una explicación de los procesos generales por los que se debe pasar. Como podemos consultar en el libro Visión por Computador [7], la visión por computador se define como el proceso de extracción de información del mundo físico a partir de imágenes, utilizando para ello un computador.

58 58 Estado del Arte Para construir un sistema de visión artificial es necesario conocer y emplear restricciones físicas sobre los objetos del mundo real y sobre su proyección en imágenes. Es conveniente destacar que esta predisposición natural a imitar al humano puede acarrear ciertas desventajas. Un ejemplo de ello son las ampliamente conocidas ilusiones visuales. Las etapas a considerar en un proceso de visión artificial dependen del objetivo perseguido: reconocer, localizar, estimar forma, etc. 2.8 Cámaras evaluadas Si se ha planteado hacer un ligero procesamiento de imagen, se debe seleccionar un cámara apropiada para nuestra tecnología x86 y como esta tecnología otorga una compatibilidad USB, se ha hecho una búsqueda de diferentes posibilidades de cámaras web con esta conexión USB Usb Webcam Una webcam (figura 2.19) es una cámara de vídeo que alimenta con su imagen en tiempo real a una computadora o red informática. A diferencia de una cámara IP (que utiliza una conexión directa a través de Ethernet o Wi-Fi), una cámara web está generalmente conectada mediante un cable USB. Figura Apariencia de una Webcam USB.

59 Cámaras evaluadas Minoru webcam La Minoru32 es una webcam (figura 2.20) que posee dos lentes separadas, que combinan las imágenes para ofrecer esta sensación de visualización en 3D. Funciona como una webcam convencional, por lo que es compatible con cualquiera de las aplicaciones que la usen, a demás de un solo conector usb, y una pequeña adición en su electrónica que añade un HUB. Figura Apariencia webcam Minoru Conclusiones Antes de finalizar el presente capítulo hay que mencionar que después de la selección de la tecnología y de la obvia asimilación de sus respectivos manuales de funcionalidad tanto en la x86 ROBOARD, como en AX-12[8], se decidió hacer una pausa en la implementación de una posible geometría[9] y la experimentación del caminado bípedo para robot humanoide[10] sobre el robot físico, haciendo primero un proceso de simulación, para así evitar movimientos no adecuados sobre los componentes físicos que puedan causar su destrucción. Al pasar por un proceso de simulación OpenRAVE y desarrollando sus primeros movimientos con un lenguaje de programación en C++, compatible con tecnología x86 se logro hacer una replica casi exacta desde el simulador hasta el robot. 32 Conoce a Minoru, que significa "la realidad" en japonés 33

60 60 Estado del Arte Figura Esquema general del trabajo. La figura 2.21 muestra el esquema de partida para el desarrollo de la arquitectura del modelo trabajado donde primero se ha construido el modelo, se ha hecho varias simulaciones y al final se ha re-codificado sobre el robot físico, la arquitectura que se detalla en el siguiente capítulo.

61 Capítulo 3 3 Desarrollo de la Arquitectura En este capítulo se presentará el diseño general de la arquitectura creada y los diferentes componentes utilizados en el desarrollo del proyecto, el funcionamiento de cada uno de dichos componentes, y la descripción de los medios utilizados que han servido para hacer dicha arquitectura. 3.1 Descripción del Sistema El presente trabajo ha pasado por diferentes fases, cada fase ha cumplido con cierta actividad, en la figura 3.1 se muestra un diagrama en el que se puede diferenciar las principales etapas de la aplicación. La primera parte muestra una primera etapa en la que se ha hecho una simulación del modelo 3D xml, la segunda etapa se hace un tratamiento de la información que procesan los actuadores, dado que estos cuentan con cierta inteligencia, se debe tomar muy en

62 62 Desarrollo de la Arquitectura cuenta esta pila de protocolos. En una tercera etapa se realiza una algoritmia clásica de visión artificial, en la cuarta etapa se realiza una fusión entre los movimientos ya realizados en el modelo físico y la integración de la visión artificial, para la quinta y última etapa se mostrará los resultados del procesamiento previo de datos. Cabe destacar que varias etapas tienen sub-etapas, y según se continué con la descripción del capitulo se detallaran estos avances. Figura 3.1. Arquitectura general de modelo desarrollado Simulación del modelo Bioloid 3D xml La primera etapa en el desarrollo de este trabajo fue la simulación en OpenRAVE34, se comenzó con el modelado de las piezas necesarias todas estas creadas en freecad35, posterior a esto se escribió el lenguaje xml necesario para funcionar las piezas del modelado anterior y la definición de los diferentes axis en cada una de las articulaciones del robot. Con el modelo gráfico en el simulador, se inició con la implementación del modelo matemático propuesto para el caminado bípedo del mini-humanoide, haciendo una primera simulación en matlab, se ha propuesto un modelo de cinemática inversa de tres grados de libertad en cada pierna para conseguir un caminado en lazo abierto con base a una oscilación cosenoidal, y luego se ha acoplado dos grados más de libertad por pierna para conseguir su estabilidad

63 Descripción del Sistema 63 La selección de tecnología de simulación fue OpenRAVE y se ha partido del modelo cartesianserver [11], una aplicación creada por Juan Vítores (Vítores, 2012) que permite enviarle coordenadas x, y, z a determinado actuador del robot ASIBOT. Cambiando sus parámetros originales de ejecución se cargo el modelo bioloid 3D xml creado para el desarrollo de esta etapa. Las instrucciones de trayectoria se envían por un puerto YARP[12], y los resultados son recogidos por Matlab[13], donde se grafican y se analizan. La configuración total del simulador + yarp + matlab + c++ (detallada detalla en los ANEXOS), ha facilitado la comunicación entre cada sistema ampliando así el análisis de datos desde diferentes punto de vista. Figura 3.2. Arquitectura etapa Tratamiento de información en AX-12 Dentro de AX-12 hay dos aspectos importantes a tener en cuenta, primero que este dispositivo electrónico actúa con una transmisión y recepción de datos en half-duplex pero en ROBOARD los puertos COM 3 y 4 que son con los que trabajaremos son full-duplex, con lo que había que solucionar este inconveniente de alguna manera, por suerte ROBOARD proporciona una solución interna de hardware, lo único que hay que hacer es una conexión externa entre Tx y Rx, con lo que se solucionará la transformación de full a half-duplex.

64 64 Desarrollo de la Arquitectura El segundo aspecto en la comunicación es el manejo de información en AX- 12, que son una serie de registros definidos en hexadecimal, accediendo y escribiendo a los registros correspondientes se hará una serie de operaciones sobre AX-12 como lectura (angular de temperatura, etc), escritura (angular de temperatura, de torque, etc), el controlador principal x86 Roboard se comunica con las unidades AX-12 mediante el envío y la recepción de paquetes de datos. Hay dos tipos de paquetes: Paquete de instrucciones. Enviado desde el controlador a los actuadores Dynamixel AX-12). Paquete de estado. Enviado desde los actuadores Dynamixel AX-12 al controlador. Figura 3.3. Comunicación ROBOARD, AX Visión Artificial Dada la compatibilidad x86, el procesamiento de imágenes es posible, por lo que se ha experimentado con esto, adaptando al principio una webcam UBS en el lugar donde se ubicaba la cabeza del robot y después en el mismo sitio otra cámara estero, siempre haciendo una programación sencilla OpenCV, dado que se ha instalado un S.O. linux sobre ROBOARD la instalación de esta biblioteca ha sido típica. Se ha hecho una primera serie de pruebas con la primera cámara ubicada sobre el robot, se ha tomado datos del entorno (figura 3.4), haciendo un cálculo aproximado de distancia tomado desde el punto central más bajo de la cámara

65 Descripción del Sistema 65 hasta el centro del objeto encontrado en dicho entorno. Como esta cámara mira hacia abajo con cierto ángulo, hay que hacer una calibración previa del dispositivo de visión[14], encontrando los parámetros intrínsecos y extrínsecos se puede hacer una mejor aproximación de distancia. Figura 3.4. Visión artificial una cámara. El siguiente paso en cuanto a visión artificial implica procesamiento en estéreo, haciendo primero una adquisición de pares de imágenes derecha e izquierda de la cámara estéreo MINORU y encontrando las características más relevantes y comunes de estas imágenes se ha hecho una estimación de distancia (según los datos arrojados en la calibración) hasta el objeto más cercano teniendo así la información necesaria para ejecutar una u otra acción. Figura 3.5. Visión Artificial dos cámaras.

66 66 Desarrollo de la Arquitectura Unión de tareas Para que el robot se desempeñe de manera autónoma, tiene que entender todos los datos de su entorno y ejecutar su movimiento de forma fluida, se ha mencionado acerca de su motricidad y su visión pero el modelo lleva otra serie de componentes como se ve en la figura 3.5. Figura 3.5. Nuevo modelo Bioloid Reproducción de movimientos En la figura 3.6 se muestra el algoritmo de funcionalidad básica final que seguirá el controlador x86, donde se hace la reproducción de los movimientos de las coordenadas articulares obtenidos y procesados, luego de pasar por las etapas anteriores, proceso dependiente de la distancia calculada en el procesamiento de imagen. Lo más destacable en esta etapa es la reproducción de la cinemática inversa creada para el caminado bípedo (detallado en el capítulo 5).

67 Descripción del Sistema 67 Figura 3.6. Diagrama de flujo a seguir. 3.2 Cinemática La cinemática del robot estudia el movimiento del mismo con respecto a su sistema de referencia sin considerar las fuerzas que intervienen. Así, la cinemática se interesa por la descripción analítica del movimiento espacial del robot como una función del tiempo, y en particular por las relaciones entre la posición y la orientación del extremo final del robot con los valores que toman sus coordenadas. Existen dos problemas fundamentales a resolver en la cinemática del robot, el primero de ellos se conoce como el problema cinemático directo, consiste en determinar cual es la posición y la orientación del extremo final del robot, con respecto a un sistema de coordenadas que se toma como referencia, conocidos los valores de las articulaciones y los parámetros geométricos de los elementos del robot; el segundo denominado problema cinemático inverso, resuelve la configuración que debe adoptar el robot para una posición del extremo conocido. Para el análisis cinemático del modelo se comenzó haciendo un estudio d el modelo cinemático que utiliza el software original de ROBOTIS y después se ha tomado sus mejores características y en base a estas, se ha iniciado el trabajo.

68 68 Desarrollo de la Arquitectura ROBOPLUS El software de los desarrolladores de ROBOPLUS (figura 3.8), cuenta con varias herramientas, por una parte que para el desarrollo de movimientos como la caminata se procede con un guiado, es decir un usuario se encarga de mover un actuador o una serie de actuadores, luego captura la posición de cada uno de ellos, estos movimientos se van guardando en un archivo y este se reproduce según las especificaciones de programación detalladas en el software. El software original limita la programación y posterior manipulación de los servo motores, con lo que no es la mejor opción, sin embargo su herramienta del RoboPlus Manager es muy buena en cuanto a la configuración en las características de un AX-12, a demás sirve para hacer la recuperación de configuración por defecto en un AX-12 cuando este pierda su funcionalidad (funcionalidad que ha sido muy explotada durante el desarrollo del trabajo), esta herramienta no ha sido dejada de lado dado que posee una fácil usabilidad y alta efectividad (esta serie de herramientas software funcionan bajo Windows). Figura 3.8. Apariencia de las herramientas de ROBOTIS

69 Cinemática Modelo Cinemático desarrollado El modelo que se ha desarrollado para complementar con la tarea de caminado, se ha hecho en base de cinemática inversa (figura 3.7a), luego de experimentar con una primera simulación notamos una similitud con un modelo clásico de triple péndulo, con la diferencia que desde el principio se ha enfocado todo el esfuerzo sobre las piernas, cada pierna es un triple péndulo, con lo tenemos un triple péndulo por pierna, por otra parte se ha hecho un cálculo ligero para la localización del centro de gravedad (figura 3.7b), y de acuerdo a esta estimación se hace una inserción del ángulo calculado sobre los actuadores que intervienen en esta acción para llegar al equilibrio. Figura 3.7a. Triple péndulo. Figura 3.7b. Centro de gravedad. Figura 3.9. Modelo triple péndulo y centro de gravedad.

70

71 Capítulo 4 4 Instalaciones y configuraciones Este capítulo detallará los pasos seguidos para la instalación y configuración de las herramientas hardware y software que se han utilizado durante el desarrollo del sistema Robótico, se ha utilizado varias herramientas hardware y software, comenzando por un ordenador personal de Sistema Operativo Linux Ubuntu 12.10, de 32 bits y 3 Gg de RAM, en el que se ha hecho diferentes simulaciones, la primera simulación de cinemática inversa con Matlab R2011a The MathWork, las demás herramientas software son OpenSouce. 4.1 Medios empleados Durante el desarrollo del El modelado de las piezas del robot se utilizo FreeCad, herramienta libre con la que se puede hacer piezas en 3D.

72 72 Instalaciones y configuraciones OpenRAVE es el simulador seleccionado para hacer las tareas de movimiento según las cinemáticas propuesta. Para gestionar las comunicaciones a alto nivel se hace uso de YARP Yet Another Robot Platform. Es una infraestructura de software libre y abierto cuyo objetivo es reducir el coste computacional. Esto es importante en sistemas de percepción al momento de procesar gran cantidad de datos, a la vez que se ejecutan en tiempo real. 4.2 Sistema Operativo Como ya se ha mencionado, sobre la placa ROBOARD RB-110 se ha instalado un Sistema Operativo Linux Lubuntu, a continuación se mencionarán los pasos que hemos superado. Para llegar a una correcta instalación del S.O. hemos utilizado la imagen clonezilla-live-roboard_lubuntu_10.04_lts_img, este es un instalador de un imagen ya funcional probada sobre ROBOARD, esta configurada e instalados los controladores de su mini tarjeta pci y la mini tarjeta de red, de tal manera que al instalar esta imagen al disco duro (SD) el sistema queda por completo funcional y listo para su utilización Instalación Lubuntu Para la instalación de Lubuntu sobre ROBOARD RB-110 se ha usado un método de muy sencillo usando VirtualBox, pero antes hay que mencionar que necesitaremos una tarjeta SD mínimo de de 8 Ghz que hará las funcionalidades un disco duro, y seguiremos los siguientes pasos: 1. Necesitaremos un computador que tenga instalado VirtualBox y en este se deberá copiar la imagen clonezilla-live- RoBoard_Lubuntu_10.04_LTS_img. 2. Arrancamos VirtualBox y creamos una nueva máquina, le asignaremos un nombre y 512 MB de memoria RAM, después especificamos el lugar de instalación que no será una imagen virtual en el disco duro.

73 Sistema Operativo Arrancamos la imagen desde VirtualBox. 4. Al iniciar la instalación se podrá visualizar un menú de clonezilla, lo primero que hay que hacer es decir a VirtualBox el lugar de instalación y para esto dar un clic derecho sobre el icono en forma de conector usb y alli escoger el nombre de la SD. 5. Escoger la primera opción dentro del menú de clonezilla y presionar enter. 6. En el monitor se visualizará un mensaje en el que hay que presionar enter nuevamente. 7. A las preguntas contestaremos con y, seguido de enter. 8. Al finalizar la instalación se mostrará que dice Instalatión finished. No error reported. Done!. 9. Esto significa una instalación completada exitosamente, seguidamente dar un enter nuevamente. 10. Finalmente se pude ver un menú que presenta 4 opciones: (0) Poweroff (1) Reboot (2) Enter command line prompt (3) Start over 11. Frente a este menú presionar 0 lo que llevara a la finalización de la presente instalación. 12. Un último mensaje dice que hay que retirar el disco duro, para lo cual hay que dar clic derecho nuevamente sobre el ícono en forma de usb, con esto se desmonta. Finalizada la instalación de lubuntu sobre la SD hay que conectarlo en la ROBOARD y encenderla, revisando el menú de boot, conectando primero el monitor y el teclado. Hay que notar que esta imagen pre-instalada de Lubuntu usa el COM1 como puerto serie para la consola por defecto, el nombre de usuario es roboard y la contraseña es roboard Configuración LAN DHCP + internet Para la configuración de LAN en ROBOARD con el S.O. Lubuntu el

74 74 Instalaciones y configuraciones procedimiento es bastante sencillo, primero vamos a obtener el número de LAN en el procesador desde el modo comando, al ejecutar el comando adecuado tenemos como algo similar a la figura 4.1. Figura 4.1. Ejecución del comando sudo dhclient. Podemos modificar los valores de la interfaz que hemos visualizado de forma manual, modificando el archivo correspondiente ubicado en /etc/wicd/managersettings.conf, accediendo al número de interfaz adecuando ver la figura 4.2. Figura 4.2. Modificar numero de interfaz. Finalmente se puede modificar las ip, dns y gateway mediante el acceso al archivo correspondiente (figura 4.3), dado que lubuntu es un S.O. linux basado en Ubuntu se puede hacer todo esto siguiendo un procedimiento como típico 37 como el detallado en la tabla manpages/jaunty/man5/wicd-wired-settings.conf.5.html

75 Sistema Operativo 75 Figura 4.3. Modifica ip, dns e ip. Tabla 4.1. Configuración ip sobre lubuntu. sudo dhclient # muestra la intefaz dhcp activa y sus direcciones. gvim /etc/wicd/maneger-setings.conf # modifica el número de interfaz LAN. Guardamos con esc: wq!. gvim /etc/wicd/wired-settings.conf # modifica la interface wired_interface según el número de interface. Guardamos con esc :wq!, salimos y reiniciamos el sistema. Para asegurarse de una correcta configuración de ip estática cambiamos los valores de ip, dns, gateway, etc. Lo mencionado anteriormente se ha logrado conectado de forma directa a la ROBOARD, visualizando todo por el monitor es decir hemos explotado las capacidades de la tarjeta mini-vga Instalación WebCam USB La imagen Lubuntu instalada sobre la ROBOARD tiene la capacidad de trabajar con una cámara USB, dado que también posee este soporte por defecto ejecutando un comando sencillo (tabla 4.2) en un terminal, se podrá hacer la comprobación de kernel y soporte con la cámara (figura 4.4).

76 76 Instalaciones y configuraciones Figura 4.4. Ejecución de una cámara USB. Tabla 4.2. Comprobación de compatibilidad cámara. luvcview # muestra en pantalla la imagen captada por una cámara. luvcview -d /dev/video1 -i 15 & luvcview -d /dev/video0 -i 15 # Si se posee dos cámaras simultaneas, en este caso Minoru, la ejecución normal de este comando muestra compatibilidad completa. 4.3 Configuración ax-12 en ROBOARD Como ya se ha mencionado, dynamixel AX-12 es un actuador inteligente, modular que tiene incorporado un reductor y engranajes, además tiene la capacidad de detectar y actuar sobre las condiciones internas tales como cambios de temperaturas interna o tensión de alimentación. Por defecto actúa a una velocidad de 1 Mbps pero para que llegue a tener una comunicación con ROBOARD esta velocidad de transferencia de datos debe ser modificada a 125 kbps tanto en AX-12 como en ROBOARD. Para ROBOARD la configuración se debe hacer desde la bios, se hara la comunicación por medio del puerto COM3 que es Full Duplex, es este puerto el que debe ser configurado, y para esto existen dos métodos.

77 Configuración ax-12 en ROBOARD Configuración AX-12 método A Al arrancar el Sistema Operativo ingresamos al bios presionando f12, buscamos al opción del menú Configuration, después Serial/Parallel port configuration, seleccionamos el puerto COM con el que trabajaremos para nuestro caso COM3, y seleccionamos la velocidad Configuración AX-12 método B Otra forma de modificar el puerto es mediante la utilización de un archivo ejecutable rbcom.exe, especificando aquí el puerto y la velocidad, este segundo método puede ser realizado por un Sistema Windows por lo que se ha seguido el médodo A. La velocidad no coincide con la cambiada en AX-12 pero es muy similar y con esto se establece una buena comunicación. También hay que notar que el puerto que se ha seleccionado COM3 trabaja con full duplex, mientras que AX-12 es half duplex, entonces ha y que superar esta incopatibilidad. Un puerto full duplex puede ser half duplex en ROBOARD, la figura 4.5 indica la esquema para la transición de half a full duplex, el diagrama es de fácil interpretación lo que se debe hacer es un puente entre los pines de transición y recepción en ROBOARD especificado en la figura 4.6. Figura 4.5. Full duplex como Half duplex.

78 78 Instalaciones y configuraciones Figura 4.6. Conexión física de full a half duplex. Hacer esta sencilla unión entre los cables de transmisión/recepción en ROBOARD y uniéndolos al pin de datos en AX-12 permite comunicación entre las tecnologías sin componentes adicionales hardware o software. 4.4 DMP RM-G145 3-Axis Gyro El módulo de RoBoard RM-G144 esta por completo integrado, y combina un sensor de tipo magnetómetro resistivo de 3 ejes (HMC5843), con un acelerómetro de 3 ejes (ADXL345), todo funcional a través de la interfaz I2C, la dimensión del modulo es de 20 x 20 mm HMC5843 Este modulo de magnetómetro es de montaje superficial diseñado para la detección magnética y posee una interfaz para aplicaciones que busca un bajo coste en brújula y magnometría ADXL345 Este circuito es un acelerómetro de 3 ejes con una resolución de 13 bits con una medición de hasta +/- 16g. Los datos digitales de salida se formatean como de 16 bits con un complemento a 2 y accesible a través de la interfaz digital I2C.

79 DMP RM-G145 3-Axis Gyro 79 Figura 4.6. Conexión física sensor DMP RM-G145 sobre ROBOARD. Su instalación es muy sencilla todo lo que se debe hacer es conectar como se puede ver en la figura 4.6, la codificación es bastante sencilla (figura 4.7), como siempre hay que inicial izar el sensor y manipular los registros pertinentes, de idéntica forma con el acelerómetro (figura 4.7), solo iniciar y manipular registros. Figura 4.6. Ejemplo de codificación sensor magnetómetro.

80 80 Instalaciones y configuraciones Figura 4.7. Ejemplo de codificación para el acelerómetro. 4.5 OpenCV OpenCV es una muy buena biblioteca OpenSource de visión por computadora que sigue en desarrollo y que ha servido para el desarrollo de este trabajo. Se ha instalado la versión de OpenCV 2.1, para lo que se ha seguido el siguiente procedimiento. 1. Comenzamos con la instalación de las dependencias necesarias (algunas de estas dependencias ya fueron instaladas previamente, pero las volveremos a mencionar, así que si ya fueron instaladas no hay ningún conflicto en replicar nuevamente la línea de comando). 2. Luego descargar la versión de OpenCV mencionada. 3. Descomprimimos el archivo descargado. 4. Creamos una carpeta para hacer la compilación y creación de los archivos necesarios para instalación. 5. Instalamos la biblioteca. 6. Configuramos la biblioteca. Las líneas de comando necesarias serán detalladas en la (tabla 4.3), estas líneas se deben ejecutar en un terminal en el mismo orden en el que se mencionan. Tabla 4.3. Instalación de dependencias para OpenCV. sudo apt-get install build-essential sudo apt-get install libgtk2.0-dev sudo apt-get install libavcodec-dev

81 OpenCV 81 sudo apt-get install libavformat-dev sudo apt-get install libjpeg62-dev sudo apt-get install libtiff4-dev sudo apt-get install cmake sudo apt-get install libswscale-dev sudo apt-get install libjasper-dev sudo apt-get install libtbb2 sudo apt-get install libtbb-dev # fin de instalación de dependencias wget unix/2.1/opencv tar.bz2 tar xfv OpenCV tar.bz2 rm OpenCV tar.bz2 cd OpenCV-2.1.0/ mkdir opencv.build cd opencv.build cmake -D WITH_TBB=YES.. (or cmake.. # para configurar sin TBB) make sudo make install sudo gedit /etc/ld.so.conf.d/opencv.conf #para configurar /usr/local/lib # agregar esta línea, guardar y salir sudo ldconfig # Actualiza sudo gedit /etc/bash.bashrc PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig export PKG_CONFIG_PATH # agregar esta línea, guardar y salir Para comprobar si la biblioteca esta correctamente instalada y funcional, podemos ingresar a la carpeta de ejemplo, compilarlos y verificar su funcionalidad, siguiendo los pasos de la tabla 4.4, luego de compilarlos, se puede ejecutar un archivo creado y con esto queda lista la instalación. Tabla 4.4. Ejecución de los ejemplos de la biblioteca. cd samples # ingresar a la carpeta de ejemplos chmod +x build_all.sh # otorgar permisos de ejecución al archivo de instalación./build_all.sh # compilar y crear los archivos necesarios de los ejemplos

82 82 Instalaciones y configuraciones./grabcut lena.jpg # Ejecución de un ejemplo Terminado este capítulo se ha concluido con la instalación de un sistema operativo linux sobre ROBOARD, la configuración de diferentes componentes a demás de la sincronización con ax-12 y de la biblioteca OpenCV para el procesamiento de imágenes. 4.6 S.O. Modo texto Para finalizar y una vez comprobado que todas las herramientas que se utilizarán en la implementación del sistema están por completo funcionales y para poder explotarlas de mejor manera, hay que minimizar el coste en arranque y procesamiento del S.O. instalado en modo gráfico, por lo que se ha cambiado la configuración del grub para que este S.O. arranque en modo texto, minimizando así este consumo, primero abriremos un nuevo terminal y luego seguiremos las instrucciones detaladas en la tabla 4.5 con lo que quedará cambiado el arranque del sistema a modo texto. Tabla 4.5. Ejecución de los ejemplos de la biblioteca. vim /etc/default/grub Buscar la linea GRUB_CMDLINE_LINUX_DEFAULT= quiet splash Agregar la palabra text GRUB_CMDLINE_LINUX_DEFAULT= quiet splash text Guardar y salir esc:wq Actualizar grub sudo update-grub Reiniciar el sistema y los cambios quedarán actualizados rebooot Con lo que el sistema operativo reiniciará siempre en modo texto, para volver al modo gráfico se deberá rehacer este proceso y dejar la linea especificada en grub como era original seguida la actualización del mismo.

83 Capítulo 5 5 Problema a resolver En este capitulo haremos un resumen de la problemática y la manera en la que se ha abordado tal problemática, pasando por las soluciones obtenidas hasta la adquisición de datos, se ha separado dicho problema en dos partes, pues en el desarrollo del trabajo se ha llegado a la creación de un nuevo algoritmo que fue implementado y analizado. 5.1 Volcado de movimientos Para dar inicio con la simulación del caminado del mini-humanoide se ha hecho una réplica de los movimientos originales en bioloid premium A, para ello se ha creado un archivo plano que contendrá todos los movimientos suficientes y necesarios creados por Robotis que cumplen con esta tarea, este archivo se crea de forma dinámica (figura 5.1), teniendo siempre opción de

84 84 Problema a resolver agregar, modificar, eliminar y listar movimientos específicos o en conjunto. Figura 5.1. Administración general de movimientos. Figura 5.2. Adición de un nuevo movimiento. La adición de un nuevo step se hace de manera muy sencilla (figura 5.2), damos un nombre al sub-movimiento, y especificamos tres datos por cada motor que son: Angulo de movimiento. Este valor estará dado entre un valor de 0 a 1023, puesto que en el modelo original ax-12 se maneja una precisión de 10 bits y el movimiento angular estará dado según este valor (figura 5.3). Velocidad del movimiento. Este valor estará dado entre un valor de 0 a 5, siendo el movimiento más lento en 0 y el más rápido en 5. Toque del movimiento. Valor dado por un torque38 máximo y mínimo entre 38 El par o torque del motor se refiere a la fuerza que producen los cuerpos en

85 Volcado de movimientos 85 0 y 5, siendo 5 la mayor capacidad de fuerza de giro que puede hacer el motor. Figura 5.3. Valores posibles de movimiento angular de un motor. Cada movimiento o sub-movimiento puede ser modificado o eliminado en caso que no se lo haya ingresado de forma correcta o si en determinado caso requiera de algún ajuste. 5.2 Replica de Movimientos Una vez terminado este archivo plano con la cantidad total de movimientos, la siguiente tarea fue hacer que estos registros se replicaran en el simulador, haciendo un procedimiento y extrayendo todos los datos guardados a un arreglo bidimensional Matriz, luego se hará el llamado a registro por registro ubicados en una posición especifica del arreglo bidimensional en un orden adecuado (figura 5.4) para que se cumpla con la tarea de caminado, este procedimiento muestra el cumplimiento de la tarea de caminado. Figura 5.4. Movimiento de un motor tomando dato desde la matriz. Donde la variable movimiento hace el calculo del ángulo que girará un determinado motor de acuerdo al valor recibido por la matriz de nombre matriz, k indicará el paso actual de ejecución de movimiento, j es el ID de motor que actuará en el presente instante de tiempo y matriz[k+1] es la velocidad aplicada a determinado motor para determinado movimiento en el mismo instante de rotación.

86 86 Problema a resolver tiempo. 5.3 Visualización en Matlab Hemos utilizado yarp para crear un puerto de comunicaciones tcp por el que viajarán los datos obtenidos de la simulación del modelo, una vez que se han ingresado los movimientos replicados desde el archivo plano, estos datos llegan a Matlab donde los datos son recolectados analizados y visualizados en la figura 5.5, pero el análisis de estos datos no es una tarea sencilla puesto que los movimientos recogidos no son provenientes de un algoritmo especifico creado para el movimiento de un robot bípedo sino de una serie de capturas de movimientos. Es decir que se ubica al robot en una cierta posición de tal manera que no se caiga y se captura todas las posiciones angulares de los motores, luego se hace una ligera variación del movimiento y se vuelve a capturar todas posiciones angulares de cada motor, se repite este procedimiento hasta lograr un objetivo que en este caso es hacer que el mini-humanoide realice un caminado continuo, al final se hace una replica continua de cada movimiento capturado en su correspondiente motor. Figura 5.5. Traslación de datos desde el simulador hasta Matlab. En el Anexo 1 se mostrarán los pasos necesarios para la configuración de yarp en Matlab, y para la obtención de las gráficas mostradas en la figura 5.5 se ha

87 Visualización en Matlab 87 explotado dicha configuración añadiendo unas cuantas lineas de código que respaldan dicha configuración (figura 5.6). Básicamente se indica a Matlab que cargue yarp, entonces se crea un puerto que es definido por el usuario, y en un terminal adicional se indica que se realice tal conexión entre el simulador y el archivo.m (figura 5.7), si los nombres de los puertos son correctos, el archivo.m comienza con la recolección y gráfica de los datos publicados en el puerto asignado por yarp al simulador. Figura 5.6. Ejemplo de lectura de datos en un puerto desde Matlab. Figura 5.7. Conexión exitosa yarp-matlab mostrada desde el terminal. Los datos obtenidos muestran una similitud casi exacta entre un movimiento de los motores derechos hasta los motores izquierdos, tomando en cuanta ciertas consideraciones, los motores derechos tienen una diferencia angular de 180º pues su ubicación física ha sido definida de esta forma desde el robot original hasta nuestra replica en el modelo 3D xml, esto quiere decir que si movemos el hombro del brazo derecho un angulo θ, el correspondiente ángulo en el hombro izquierdo

88 88 Problema a resolver será el mismo ángulo θ pero negativo y con eso se consigue al realizar el mismo movimiento angular esto se repite a lo largo de todos los motores del minihumonoide. Partiendo desde este análisis se puede llegar a formular una posible solución de movimiento anterior y siguiente, tomando en cuenta los datos llenados en la matriz de replica antes definida haciendo un análisis de cinemática directa mencionada en el capitulo 2, sin embargo estos datos obtenidos desde la serie de movimientos originales no han sido del completo agrado así que se ha decidido hacer un nuevo algoritmo que permita al mini-humanoide bípedo desplazarse utilizando sus extremidades inferiores pero aplicando un cálculo de cinemática inversa también mencionada en el capitulo Propuesta de caminado bípedo Partiendo del análisis del brazo robótico tipo escara de tres grados de libertad, tomando en cuenta el cálculo de tomar objetos desde un punto o soltarlo en otro con un ángulo determinado, partiremos por el análisis de una pierna como un arreglo cinemático en un entorno planar es decir un plano (x, y), definiendo tres parámetros únicos que son las distancias en tres motores (figura 5.8), partiendo de aquí se formulará una serie de ecuaciones a resolver. Para el cálculo se ha partido desde el punto más alto de la pierna como origen de coordenadas (x=0, y=0), asumiendo eso se evitarán puntos de singularidad 39 en un movimiento de la pierna solo haciendo una comparación entre distancias. La distancia medida entre un punto de la pierna desde el extremo más lejano deberá ser menor o igual a la suma de las distancias de las longitudes de la pierna ecuación 1. dist ( x org, y org )(x fin, y fin ) dist ( Longmuslo + Long pant + Longtobillo ) ecu(1) 39 Es una zona del espacio-tiempo donde no se puede definir alguna magnitud física.

89 Propuesta de caminado bípedo 89 Figura 5.8. Parámetros definidos de una pierna. Sabiendo esto se puede definir una serie de formas para encontrar el punto final del efector[15] (figura 5.9), conociendo las distancias mencionadas, se asignarán ángulos para que cada actuador se mueva en función de un punto final definido. Figura 5.9. Visualización del problema.

90 90 Problema a resolver Formulación del problema Conociendo todos los datos, se puede generalizar un procedimiento para que cada motor calcule el ángulo al que debe llegar para que el punto final de la pierna incida con determinado angulo en el tobillo (pitch) Datos conocidos Longitud del muslo. Longitud de la pantorrilla. Longitud del tobillo. Ángulo del tobillo (pitch). Eje X, eje Y Incógnitas Ángulo del muslo. Ángulo de la pantorrilla. Ángulo del tobillo. Lo primero es resaltar que se ha hecho el cálculo en base a funciones trigonométricas, es necesario explicar una cosa sobre el ángulo del tobillo (pitch). Es un ángulo que se asignó a la pierna para que esa posición se mantenga constante desde el punto de vista del observador, aunque la pierna se mueva a otra posición. La cinemática inversa también calcula un ángulo del tobillo, pero son cosas relativamente distintas aunque dependientes la una con la otra. El calculo de la cinemática inversa cambia su valor en la medida en la que cambia la posición de la pierna para mantener el ángulo del tobillo (pitch) en la misma posición en todo momento. Hay que recordar que no es lo mismo atan()40 que atan2() atan( ) sólo tiene efecto en los cuadrantes 1 y atan2( ) dependiendo de los signos contenidos en los valores X e Y tiene presente el cuadrante en el que se encuentra y puede recorrer los cuatro cuadrantes.

91 Propuesta de caminado bípedo 91 afx=cos ( pitch) Longtobillo ecu(2) LadoB =X afx ecu (3) afy=sin( pitch) Longtobillo ecu( 4) Lado A =Y afx ecu (5) Hipotenusa= ( Lado A )2 +(LadoB )2 ecu (6) α =atan(lado A, Lado B ) ecu (7) ((Longmuslo )2+(Long pantorrilla )2 +(Hipotenusa)2) β=acos (2 Longmuslo Hipotenusa) Angmuslo =a+ B δ =acos ecu( 9) (( Long muslo)2 +( Long pantorrilla )2+(Hipotenusa)2 ) ( 2 Longmuslo Long pantorrilla ) Ang pantorrilla =(180 G) ecu(8) ecu(10) ecu (11) Angtobillo = pitch Angmuslo Ang pantorrilla ecu (12) En una primera instancia se han replicado estas fórmulas en Matlab, se ha conseguido una primera simulación con una pierna, se ha definido que la cinemática inversa siga un movimiento suavizado, así que se ha generando un coseno normal de (-pi, hasta, pi) con un punto constante de amplitud igual a 14, definiendo previamente que la longitud del muslo=8, longitud de pantorrilla=8 y la longitud del tobillo = 3.5, en la figura 5.11a se puede apreciar una primera serie de movimientos sobre una pierna. Para continuar con la resolución del problema es necesario considerar que un paso realizado por una pierna tiene dos fases la primera partiendo desde una posición trasera hasta llegar a una posición delantera y la segunda fase es el procedimiento contrario es decir de adelante hacia atrás, en esta segunda parte también se tiene una peculiaridad y es que al regresar el pie no debe hace un movimiento coseno como el anterior sino que debe permanecer a la misma altura desplazándose como ya se indico, formando así una línea recta (figura 5.11b). El punto final del actuador realizará una trayectoria en avance que recorrerá Δt espacios con m amplitudes en un número de n iteraciones definidas (figura 5.10), de la misma forma recorrerá en sentido contrario el mismo número de

92 92 Problema a resolver espacios Δt con una sola amplitud en un mismo número de n de iteraciones, con lo que finaliza la tarea de caminata en avance y retroceso en una pierna. Figura Variación de espacio y amplitud en tiempo en recorrido de trayectoria de una pierna. Figura 5.11a. Paso 1 avanzar. Figura Paso 2 Regresar. Figura Simulación de una pierna. Cumpliendo con esto una pierna podría moverse haciendo un movimiento suavizado tanto a la ida como a la vuelta, para la siguiente pierna se siguió el mismo procedimiento, solo considerando lo inherente al proceso de caminar que es mientras una pierna esta haciendo proceso de avanzado la la otra esta haciendo

93 Propuesta de caminado bípedo 93 el proceso contrario es decir estará regresando, y cuando la otra avanza la primera regresará, teniendo un proceso total mostrado en la figura Figura Paso adelante. Figura Paso atrás. Figura Simulación de las dos piernas. Una vez que comprobamos que nuestro algoritmos funciona lo hemos volcado sobre el simulador (figura 5.13) traduciendo las fórmulas antes descritas y codificadas en Matlab a C++, produciendo un movimiento mucho mejor, suavizado en base a un algoritmo definido. Figura Algoritmo sobre el simulador.

94 94 Problema a resolver Este proceso se ha complementado centralizando el proceso, haciendo los cálculos antes formulados e indicando a cada motor el movimiento que se debe hacer en un instante de tiempo definido, cumplido así con las tareas de movimientos necesarias en el plano sagital, quedando aún pendiente la resolución de movimiento en el plano axial. 5.5 Busca del centro de gravedad Una vez concluido con el proceso de caminata suavizada por la función coseno, pasamos a la resolución de un nuevo problema que es la ubicación del centro de gravedad, pues al momento de ejecutar la acción de movimiento, si una pierna se levanta, la gravedad entra en acción y el robot se caerá inevitablemente sin importar la velocidad con la que haga estos movimientos. Para la localización del centro de gravedad y modificación del mismo se ha hecho un ligero cálculo geométrico, partiendo de un estado inicial ideal, es decir el robot de pie con igual apertura de sus piernas y brazos, encontramos un centro de gravedad, construyendo un triangulo entre el centro de gravedad y el punto central en sus tobillos derecho e izquierdo. Comenzaremos con el análisis de la pierna derecha, entre el tobillo de esta pierna, el centro de gravedad del robot y el suelo existe un triangulo como el de la figura 5.14a en el que se puede notar un ángulo β, producto de c= a 2+b 2 a β=sin 1( ) c ecu (13) ecu(14 ) Donde c (ecu 13) es la distancia entre en centro de gravedad del robot y el punto central del tobillo, conociendo este último dato es sencillo encontrar el valor del β(ecu 14).

95 Busca del centro de gravedad 95 Figura 5.14a. Centro de Gravedad Figura 5.14b. Centro de gravedad original. desplazada. Figura Cambio del centro de gravedad. El objetivo de este análisis matemático data en una nueva ubicación del centro de gravedad que se situará sobre el plano del tobillo de la pierna incidente como en la figura 5.14b, para alcanzar este objetivo nos ubicaremos primero sobre el plano de dicho tobillo y se hará un movimiento angular igual al ángulo β conocido, pero este simple movimiento no corrige al robot a una posición ideal por lo que junto al movimiento del tobillo se deben añadir movimientos angulares iguales sobre el tobillo contrario a demás sobre los dos actuadores ubicados en la cadera baja, encargados de los movimiento horizontales, que deberán hacer el mismo movimiento angular para completar el cambio del nuevo centro de gravedad, para la pierna contraria se hace un proceso idéntico, teniendo en cuenta las mismas consideraciones angulares a demás de los actuadores implicados en esta tarea. 5.6 Tratamiento de imagen Uno de los principales objetivos en este trabajo ha sido la fusión entre el movimiento coordinado y la visión artificial, sin embargo dentro del tema de visión artificial se puede hablar mucho así que lo que se explicará será el trabajo

96 96 Problema a resolver práctico, más no todos los detalles de las teorías y principios utilizados en los algoritmos aplicados. Para hacer el procesamiento de imagen se ha hecho más de un proceso, se ha comenzado con la ubicación de una cámara webcam sobre la cabeza del robot y después se cambio esta cámara por una doble cámara MINORU, haciendo un rápido y sencillo procesamiento estéreo Cámara simple Tomando en cuenta un suelo de color verde y una serie de obstáculos de color blanco, se ha comenzado haciendo una segmentación de imagen según las características mencionadas, primero ubicando el apropiado umbral y después buscando el punto central donde se encuentre un obstáculo del color especificado (figura 5.15). En el Robot, la cámara esta ubicada en la cabeza del mismo apuntando hacia abajo, de tal manera que existirá una distancia entre sus pies y el primer punto de visión, (figura 5.16). Como se puede apreciar, el robot no vera su propio cuerpo, la cámara esta ubicada a 30 cm del suelo, y margen de visión esta denotado por el cuadro a su frente, teniendo las medidas mostradas, todos estos datos son propensos a ligeros cambios por la actividad constante del robot, por lo que se han utilizado siempre aproximaciones. Figura Fotografía de un posible escenario.

97 Tratamiento de imagen 97 Figura Esquema de visión del robot. Como se puede ver en la figura 5.17, si un objeto incide dentro del campo de visión de robot, este se podrá segmentar, se encontrara el punto medio del objeto y si se acerca demasiado hacia el mini-humanoide, este lo evadirá haciendo un movimiento lateral, y una vez superado continuará con su recorrido. Figura Detección de un objeto dentro del campo de acción Visión Estero Una de las tareas básicas de visión estereoscópica en computación es la calibración de la cámara estéreo, con el fin de obtener los parámetros que le permitirán calcular la información 3D de la escena.

98 98 Problema a resolver Calibración de cámara estero MINORU Se podría mencionar muchas cosas acerca de los modelos de cámaras, de proyección, de estereoscopia, la distorsión de lentes, etc. Simplemente se mencionará el proceso seguido para calibrar un sistema de cámaras estéreo y empezar a calcular cosas en 3D de inmediato usando OpenCV. Así que... qué se necesita para calibrar una cámara estéreo?. Un tablero de ajedrez, parecido al de la figura Por qué un tablero de ajedrez? Debido a que sus esquinas son muy fáciles de encontrar mediante el uso de algoritmos de visión por computador y su geometría es muy simple. Con el fin de averiguar la posición de cualquier esquina, lo único necesario es saber cuántas casillas horizontales y verticales que hay en el tablero de ajedrez y el tamaño de un cuadrado. El tablero de ajedrez en la imagen es un tablero de ajedrez de 8x8 y si se imprime en un papel de tamaño A4 el tamaño de los cuadrados es más o menos 2 cm. Seguido se han tomado múltiples vistas de tablero de ajedrez en diferentes posiciones y orientaciones con la cámara estéreo, las imágenes deben tener un aspecto al de la figura Figura Imagen de un Tablero de ajedrez.

99 Tratamiento de imagen 99 Figura Tomas con la cámara estero. Con las imágenes tomadas, se ha aplicado el algoritmo de calibración proporcionado en los ejemplos de OpenCV (figura 5.20), con lo que se ha obtenido una serie de archivos *.xml, que son los modelos de distorsión de las cámaras. Matrices que será necesarias para deshacer la distorsión de las imágenes producidas por las lentes, como las de la figura 5.21.

100 100 Problema a resolver Figura Calibración cámaras OpenCV.

101 Tratamiento de imagen 101 Figura Imágenes de distorsión según la calibración Descriptor ORBFeatureDetector Antes de comenzar con la estimación de distancia, se ha trabajado con el descriptor ORBFeatureDetector, esta función, extrae las características locales de interés de una imagen. Un punto de interés es un punto en una imagen que tiene una posición bien definida y puede ser detectada con firmeza. Esto significa que en el punto de interés puede ser una esquina, pero puede no ser así, por ejemplo, un punto de interés puede ser un punto de máxima intensidad, un final de línea, o un punto en una curva (cuando la curvatura es localmente aislada), se ha trabajado con este algoritmo puesto que ofrece mayor velocidad[16]. Comprobada la aplicación de este algoritmo a una imagen simple (figura 5.22), el siguiente paso es utilizar el mismo algoritmo a un par de imágenes tomadas de forma simultanea pero desde diferentes ángulos (figura5.23), buscando las áreas de interés comparándolas y trazando lineas en las zonas de interés en el par de imágenes, conociendo las localizaciones exactas de interés en cada imagen (los puntos x, y) se puede hacer una nueva aplicación de procesamiento con estos datos Estimación de distancia El objetivo final después de la generación de los archivos *.xml provenientes de la calibración de las cámaras es obtener la capacidad de calcular la posición 3D

102 102 Problema a resolver (en mm, cm, m o la unidad de medida preferida), de un punto dada su posición (en píxeles) de la imagen de la izquierda y su corresponsal en la imagen de la derecha, con lo que se necesita la matriz Q. De acuerdo con la posición de un punto de interés en la imagen de la izquierda y de la derecha, la posición 3D se puede calcular según. d= pointrightimage.x pointleftimage.x ; ecu(14 ) X= pointleftimage.x Q[0, 0]+Q[0, 3]; ecu(15) Y =pointleftimage.y Q[1, 1]+Q[1,3 ]; ecu(16) Z=Q[2,3 ] ; ecu(17) W=d Q[3, 2]+ Q[3,3]; ecu (18) X =X /W ; ecu (19) Y =Y /W ; ecu(20) Z=Z /W ; ecu (21) El uso de los archivos *.xml resultantes de la calibración es bastante sencilla, sin embargo toma bastante tiempo el revisar la documentación y enterarse de que hacer con estas matrices, se tratará de hacer una breve y detallada explicación. Figura ORBFeatureDetector sobre una imagen.

103 Tratamiento de imagen 103 Figura ORBFeatureDetector sobre un par de imagenes. Si asumimos una configuración de dos cámaras de características similares (figura 5.24), un punto en el espacio tridimensional P, co0n corrdenadas homogéneas (x, y, z)t, se proyecta en cada una de las imágenes bidimensionales en los puntos pl y pr, con coordenadas homogeneas (xl, yl, 1)T y (xr, yr, 1)T, respectivamente. Figura Relación geométrica entre par de cámaras para la obtención de profundidad.

104 104 Problema a resolver El plano contiene a los puntos P, OL y OR, interseca a las imágenes en dos rectas el y er. Dada la configuración del par estereo, éstas son rectas epipolares entre sí, o sea, un punto pl, en la recta el de la imagen IL tiene su correspondencia en algún lugar de la recta er, con lo que se obtiene la relación entre la disparidad d y la profundidad Z de punto P. La disparidad es la diferencia en las coordenadas horizontales de los puntos p L y pr, o sea, d = xl-xr. Dependiendo del sistema de referencia utilizado en las imágenes la definición puede cambiar de modo que el signo sea siempre positivo. Las coordenadas de pl y pr quedan relacionadas mediante xl=xr+d y yl=yr. Por semejanzas entre los triángulos POLOR, proror y plolol se llega a la relación entre d y Z Zd=fB ecu(21) De esta forma se puede recuperar, a menos de una constante de escala, la profundidad de cada pixel en cada una de las imágenes a partir de la disparidad calculada. Con estos cálculos se puede estimar las posiciones 3D de 2 imágenes usando OpenCV. Una vez resueltos estos principales problemas se ha procede a realizar la correspondiente fusión de tecnologías para que todo funcione al mismo tiempo, comunicando los resultado de un proceso mientras otro sigue su camino.

105 Capítulo 6 6 Implementación, programación y puesta en marcha En este capítulo haremos una descripción del trabajo de implementación, programación realizada y la posterior puesta en marcha de los procedimientos descritos en las secciones anteriores, comenzando la ubicación del hardware ROBOARD, sobre el mini-humanoide, la implementación del caminado bípedo sobre agente humanoide y la integración con la visión artificial. 6.1 Montaje de herramientas hardware Sobre el nuevo mini-humanoide no solo irá la tecnología x86 seleccionada ROBOARD, a esta tecnología sino que deben encajar varias piezas y cada una de estas deben ocupar el mínimo espacio de tal manera que se optimice el

106 106 Implementación, programación y puesta en marcha rendimiento de las mismas y el espacio dentro y fuera del robot humanoide ROBOARD sobre mini-humanoide Puesto que una de las razones de selección de la tecnología ROBOARD a demás de sus capacidades computacionales fue también su tamaño, la ubicación de este procesador es la misma en la que estaba el procesador de original ROBOTIS el CM-510, es decir en la espalda del mini-humanoide (figura 6.1), sin embargo no se podía hacer un anclaje preciso, problema que fue solucionado mediante el diseño y la posterior impresión en plástico de una pequeña pieza, desarrollada con lenguaje OOML. Figura 6.1. Montaje de ROBOARD sobre Bioloid Minoru sobre mini-huanoide La webcam Minoru, se ha colocado en el lugar donde estaba ubicada la cabeza del mini-humanoide (figura 6.2), las condiciones ideales de esta cámara en tamaño y peso, otorgan la facilidad para ubicara en el lugar antes mencionado, además dada su movilidad ha permitido hacer movimientos horizontales y verticales una vez anclada sobre el robot.

107 Montaje de herramientas hardware 107 Figura 6.2. Montaje de la cámara Minoru Mini tarjeta wifi sobre mini-humanoide Ubicar la mini tarjeta wifi no representa un problema puesto que esta encaja dentro del mismo espacio asignado para la x86, sin embargo, la esta tarjeta cuenta con una antena bastante grande y esta si tiene que ser bien colocada (figura 6.3), gracias a que se creo una pieza extra para la x86, en el espacio restante entre la pieza y la x86 se abrió un pequeño canal en el que se insertó la antena Magnetómetro y acelerómetro sobre mini-humanoide Adicional a la electrónica mencionada, se añadió una última RM-G144, este módulo cuenta con dos más, un magnetómetro y un acelerómetro que han servido para la recolección de una infinidad de datos al momento del desplazamiento del mini-humanoide, ubicado en el lugar en el que estaba ubicado el sensor gyro original del robot, en el centro mismo del robot, en la figura 6.4) se puede visualizar una luz roja que indica que el sensor está activo.

108 108 Implementación, programación y puesta en marcha Figura 6.3. Montaje Mini tarjeta wifi. Figura 6.4. Montaje de RM-G144.

109 Ejecución de movimiento de un AX Ejecución de movimiento de un AX-12 Para iniciar con la ejecución de movimientos de un ax-12 desde ROBOARD, se ha implementado una breve codificación hecha en C++, iniciando por el establecimiento de la velocidad que será asignada al servomotor y su correspondiente ID, para lo cual se deben establecer varios parámetros obligatorios para AX-12 ver figura 6.5. Figura 6.5. Ejemplo de parámetros de velocidad para ax-12. Una vez definida la velocidad aplicada a un servomotor, de idéntica forma hay que definir los parámetro necesarios para realizar un movimiento angular en un ax-12 ver figura 6.6. Figura 6.6. Ejemplo de parámetros de movimiento angular para ax-12. Conociendo los posibles parámetros a ingresar, se han creado diferentes funciones que agilicen este proceso, tanto en la velocidad como en el movimiento, primero hay que mencionar que los parámetros de la velocidad como del movimiento necesitan dos valores hexa-decimales, definidos en los ejemplos como params[0] y params[1], donde params pueden tomar valores desde 0x00 hasta 0x03ff.

110 110 Implementación, programación y puesta en marcha speedmotor Esta función necesita de dos parámetros para su ejecución ejemplo: speedmotor(params[0], params[1]), donde params[0] será un valor decimal comprendido entre 0.0 sin velocidad y 5.0 para una máxima velocidad asignada al servomotor indicado por params[1] cuyo valor debe ser un número entero entre 0 y motionmotor Esta función recibe dos parámetros para su motionmotor(params[0], params[1]), donde params[0] ejecución ejemplo: será un valor entero entre 0 ángulo mínimo y 300 ángulo máximo (valores que pueden variar dependiendo de la configuración inicial del servomotor) asignado al servomotor indicado por params[1] cuyo valor debe ser un número entero entre 0 y torquemotor Esta función recibe dos parámetros para su ejecución ejemplo: torquemotor(params[0], params[1]), donde params[0] será un valor entero entre 0 torque mínimo y 5 torque máximo asignado al servomotor indicado por params[1] cuyo valor debe ser un número entero entre 0 y torquealarm Esta función recibe un solo parámetro para su ejecución ejemplo: torquealarm(params[0]), donde params[0] es el ID del servomotor, el led del servomotor indicado parpadeará hasta que se desactive el torque asignado cuando la temperatura de funcionamiento sobrepase los límites motorid Esta función recibe dos parámetros para su ejecución ejemplo: torquemotor(params[0], params[1]), donde params[0] será un número entero

111 Ejecución de movimiento de un AX entre 0 y 255 que será el ID original del servomotor y params[1] también será otro número entero entre 0 y 255 que indicará el nuevo ID del servomotor baudratemotor Esta función recibe dos parámetros para su ejecución ejemplo: bauderatemotor(params[0], params[1]), donde params[0] será un valor entero entre 0 y 1M que indicará la velocidad de transición y recepción de datos asignado al servomotor indicado por params[1] cuyo valor debe ser un número entero entre 0 y operationanglemotor Esta función recibe dos parámetros para su ejecución ejemplo: operationanglemotor(params[0], params[1]), donde params[0] será un valor entero que indicará el angulo máximo en el que actuará el servomotor, sabiendo que el ángulo mínimo siempre será 0, params[1] es un valor que debe ser un número entero entre 0 y 255 correspondiente al ID operationvoltagemotor Esta función recibe dos parámetros para su ejecución ejemplo: operationanglemotor(params[0], params[1]), donde params[0] será un valor entero que indicará el valor máximo de voltaje soportado por el servomotor, params[1] es un valor que debe ser un número entero entre 0 y 255 correspondiente al ID. Ahora como hemos podido notar, ya sea que se definan params[0] o params[1], estos valores son ingresados como números naturales y son convertidos a dos grupos hexa-decimales para que correspondan al ejemplo original. Implementados los comandos necesarios para dar ordenes de movimiento a los actuadores, solo hay que hacer que estas ordenes coincidan con los cálculo de

112 112 Implementación, programación y puesta en marcha cinemática hechos en el capítulo anterior, con lo que solo se ha codificado las fórmulas necesarias (figura 6.7.) y sus valores resultantes re direccionados a los actuadores correspondientes. Figura 6.7. Calculo de cinemática Inversa 3 DOFs. Una vez conocidos los procedimientos necesarios para el cálculo de la cinemática inversa nos queda por definir la trayectoria que seguirán las piernas, como se había mencionado esta trayectoria es un coseno normal, y después de este una trayectoria recta para volver al inicio, se reproducirá esta secuencia siempre que las condiciones del campo sean las apropiadas. y esto se controla las variables dadas por la una función típica f(x). frec= paso 6.28 f (w)= A cos ( ecu (15) w )+ A frec ecu (16) En la que la variable paso es un valor dado en centímetros, define el valor del tamaño del paso en centímetros que dará la pierna.

113 Ejecución de movimiento de un AX donde la variable A es el valor de amplitud vertical de un paso dado, es decir que tanto levantará la pierna desde el suelo. w será una serie de posiciones de atrás hasta adelante. frec es el valor resultante de la ecu (15) que a su vez definirá la frecuencia del coseno adecuada para que el tamaño del paso definido por la variable paso se cumpla. 6.3 Plano sagital Aplicando estas fórmulas con un paso igual a 4cm y la altura de elevación de pierna igual a 3cm, la trayectoria que se generará será igual a la de la figura 6.8, el cálculo de cinemática inversa se encargará de dar los correspondientes ángulos a los actuadores que deben intervenir, de tal modo que esta secuencia se deberá repetir indefinidamente. Figura 6.8. Trayectoria a seguir de una pierna. El procedimiento cumple con el accionar en el plano sagital y en condiciones óptimas de campo y de configuración del robot, el campo no debe tener desnivel ni cualquier cosa que obstruya el desempeño del robot, de la misma forma el robot debe tener una configuración de armado óptima es decir sus piezas deben ser simétricas unas con otras, por último las condiciones de resolución de los actuadores debe ser máxima, es decir llegar hasta un ángulo con máxima precisión

114 114 Implementación, programación y puesta en marcha aunque dicho ángulo sea un decimal. Pero ninguna de estas condiciones ambientales nunca serán óptimas, el suelo siempre tendrá defectos e imperfecciones, las piezas del robot nunca serán perfectas, y aunque las el suelo sea óptimo y las piezas también lo sean, los actuadores AX-12 aunque tienen muy buena resolución no tienen la suficiente y esto provocará que la curva teórica en el plano sagital no se cumpla dejándola solo en una curva teórica. 6.4 Plano axial De igual manera para el plano axial, no se cumplirá por completo, según los cálculos formulados, para este plano debería mostrar un movimiento en el plano axial, como el que se puede ver en la figura 6.9 (visto desde el punto central del robot ubicado en el centro de gravedad), pero como se ha mencionado no se posee las condiciones óptimas para el mini-humanoide y esta curva tampoco se cumple al 100%. Figura 6.9. Variación teórica en el plano axial. 6.5 Magnetómetro y acelerómetro Para el magnetómetro se ha implementado el código básico de ejemplo proporcionado por los desarrolladores (figura 6.10), código al que se le han agregado unas lineas para una mejor interpretación de sus datos, de igual manera, el código base (figura 6.11) del acelerómetro sufrió una serie de cambios similar

115 Magnetómetro y acelerómetro 115 para una mejor interpretación de datos. Figura Código base del magnetómetro. Se ha considerado como punto inicial el lugar al que apunta el magnetómetro, siendo este su norte de referencia de forma independiente de si lo es o no lo es, de tal manera que si al caminar cambia su rumbo por situaciones referentes al ambiente, al detectar un cambio de rumbo muy grande, se pueda hacer una corrección. Figura Código base del acelerómetro. Los resultados medidos por el acelerómetro muestran bastante oscilación en cada eje, a pesar que el algoritmo de movimiento funciona de forma correcta, sin embargo se han tomado varias muestras de las aceleraciones en las acciones de pasos derechos o izquierdos y cada grupo de datos muestra similitud, con lo que puede tomar acción con este grupo de datos, comparándolos, entrenándolos y al momento que exista demasiada discordia, tomar mediadas y acciones correctivas de acuerdo a los datos de aceleraciones en los diferentes ejes.

116 116 Implementación, programación y puesta en marcha 6.6 Visión Artificial Dado que una de las grandes ventajas de ROBOARD es que tiene la capacidad del tratamiento de imagen, para ello se ha trabajado con OpenCV en su versión 2.1 en el capítulo anterior se describió la forma de tratamiento de información que proporciona la cámara. Cada proceso de visión fue primero implementado sobre el ordenador personal mencionado al principio del capítulo 4, y de esto hay varias cosas a tomar en cuenta. El trabajo con una cámara en el ordenador personal o en ROBOARD, no causan ninguna clase de efecto negativo, retardo o incompatibilidad Visión Mono El proceso total seguido con una cámara hace una toma de imagen, como el campo de visión del robot esta reducido, se ha restringido la información importante a 2 colores principales, sabiendo que el suelo es verde y los obstáculos serán de color blanco se ha hecho una segmentación de acuerdo a estas afirmaciones (ver figura 6.12), estos datos permiten hacer un cálculo aproximado de distancia desde el robot hasta el objeto que tiene el color de interes. Dada la completa compatibilidad de la x86 con la usbwebcam, el procesamiento de la información obtenida por la cámara es continua a 30 fps, esto no ha afectado desenvolvimiento en el proceso de caminata dejando asó la posibilidad de hacer un procesamiento un poco más complejo Visión estero Pese a que la ejecución del comando luvcview (mostrado en la tabla 4.2) y que existe una total compatibilidad con la cámara estéreo MINORU, la implementación de estero sobre el ordenador personal y sobre ROBOARD ha causado más de un efecto negativo a ser tomado en consideración.

117 Visión Artificial 117 Figura Segmentación Imagen. En el caso del trabajo en el ordenador personal, después de la implementación de un ligero algoritmo escrito con OpenCV, en el que muestre la imagen de las dos cámaras, mostró un error (figura 6.13) que no permitió la visualización continua del par de imágenes. Figura Excepción en doble cámara. El error anterior fue solucionado, indicando a OpenCV (figura 6.14) que haga una disminución de la imagen, por defecto siempre mostrará un tamaño de (800 x 600 pixeles), la disminución de la imagen fue a (320 x 240 pixeles ). Sin embargo este procedimiento no funciono sobre el x86 ROBOARD, a pesar que se ha hecho la correspondiente disminución en el tamaño de imagen persiste un problema en la visualización de imágenes en paralelo, pues se llega una saturación de buffer en el USB.

118 118 Implementación, programación y puesta en marcha Figura Disminución de imagen tomada por el par de cámaras. Como se ha comentado, el comando luvcview se ejecuta de forma correcta en ROBOARD en su modo gráfico, pero al arrancar el modo texto este comando falla, y con la misma implementación de OpenCV en paralelo de las cámaras de igual manera, una solución provisional ha sido activar y desactivar las cámaras (figura 6.15), mientras la primera toma una imagen, la segunda esta desactivada, al finalizar la toma de imagen de la primera cámara la segunda se activará haciendo la extracción este proceso se repetirá de forma continua, evitando así la saturación de buffer y errores de lectura. De acuerdo al funcionamiento del robot, al final de un movimiento total en una pierna (un paso), se tomará un solo pare de imágenes derecha e izquierda, haciendo procesamiento de imagen cada 3s, dato que puede variar si el paso se hace más rápido o más lento. Figura Liberar imagen. Sin embargo esta no es la mejor opción para el tratamiento, esta solución es provisional puesto que el sistema muestra compatibilidad con las cámaras lo que se debe hacer es modificar el kernel del linux instalado en ROBOARD para que al explotar las cualidades de OpenCV ya sea en modo gráfico o en modo texto, el mismo algoritmo funcione sin necesidad de activar y desactivar las cámaras funcionales al momento, a demás que en modo texto también se puede mencionar que no es posible mostrar la imagen es posible encender las cámaras, procesar los datos, pero al mostrar la imagen se visualiza un nuevo error.

119 Unión ROBOARD, AX-12, OpenCV Unión ROBOARD, AX-12, OpenCV Una vez definida e implementada la programación individual de cada componente del sistema, hay que hacer que todas estas tecnologías trabajen en comunión, en un primer trabajo se ha hecho una programación lineal, separado por procedimientos y bibliotecas. Se comienza con la toma de una imagen, se la procesa, se encuentra la distancia del objeto al robot y dependiendo de estos datos se ejecuta una secuencia determinada de movimiento. Cabe decir que los resultados de procesamiento de imagen, de distancias, de movimientos angulares en AX-12 y demás cálculos no son mostrados en pantalla pues esto representa recursos computacionales que deben ser optimizados para así mejorar el rendimiento en ROBOARD. 6.8 Resultados Los resultados han sido divididos en dos artes, por una parte se muestran resultados provenientes de las caminata, y después se mostrarán datos provenientes del procesamiento de imagen Resultados en caminata Después de ejecutar la simulación con el nuevo algoritmo de caminado, se han obtenido una serie de curvas propias de cada actuador como se puede apreciar en la figura 6.7 se muestra los actuadores que interactuan en el algoritmo de cinemática inversa que son los de ID de la pierna derecha que se encuentran representadas en la parte superior de la gráfica, y para la pierna izquierda en la fila inferior de la gráfica. El eje x muestra el número movimiento siendo 40 los movimientos necesarios para realizar un paso, por lo que después del x=40 se deberá repetir la secuencia de valores en y, por parte del eje y los valores indicado entre mínimo -150 hasta un máximo de 150 son los grados que girará determinado actuador en un instante de tiempo. La figura 6.8 muestra la diferencia entre las evoluciones de los movimientos

120 120 Implementación, programación y puesta en marcha angulares en la serie de movimientos originales en ROBOTIS y el nuevo método. Figura 6.7. Curvas de los actuadores de las piernas. Figura 6.8a. Movimientos ROBOTIS Figura 6.8b. Nuevos movimientos Figura 6.8. Contraste de evolución angular ROBOTIS vs nuevo modelo. Por otra parte la curva más significativa se puede ver en la gráfica 6.9 que muestra el comportamiento teórico del mini-humanoide visto desde el punto central de equilibrio.

121 Resultados 121 Figura 6.9. Variación centro de gravedad. Después de realizar varias pruebas de caminata continua, se han tomado una serie de datos provenientes del acelerómetro, datos que han mostrado la variación en sus ejes, la figura 6.10 muestra las variaciones de aceleración en el eje x desde un acelerómetro ubicado en el centro de gravedad del robot. Figura Aceleración de ejes, desde el centro de gravedad en las piernas. Las variaciones de aceleración, ya sea en la ejecución de movimiento de una u otra pierna es muy similar por lo que se puede generalizar una regla para medidas de contingencia cuando la aceleración en uno u otro punto muestre un dato no esperado y hacer una corrección de movimiento evitando así la caída del robot.

122 122 Implementación, programación y puesta en marcha Resultados de procesamiento de imagen Como se ha mencionado en capítulos anteriores, se ha hecho un primer trabajo con una cámara, como se puede apreciar en la figura 6.11, donde se hace una segmentación de información importante, solo el color rojo será el que indique de la existencia de un obstáculo y para la comprobación de funcionamiento se ha pintado los pixels de este color rojo a negro, a demás se estima la distancia desde el punto central del robot hasta el punto medio del objeto encontrado en el ambiente, con lo que el robot puede tomar una acción de evasión. Figura Robot y procesamiento de imagen con una cámara. Sin lugar a duda el procesamiento de imagen exige un gasto computacional muy elevado, por lo que solo para las pruebas se han visualizado datos en pantalla (figura 6.12) pero para la ejecución de los algoritmo se han obviado la impresión de dichos datos.

123 Resultados 123 Figura Datos relevantes del procesamiento de imagen estereo. La búsqueda de características similares en el par de imágenes izquierda y derecha dependiendo de la posición de la cámara, ha mostrado gran cantidad de coincidencias y por cada coincidencia se hace el cálculo de aproximación de distancia, por lo que se ha probado hacer un procesamiento previo a esta búsqueda de dichas coincidencias. Se ha hecho una segmentación y umbralización previa de imagen buscando solo un determinado color de una imagen, eliminando el fondo de la misma, quedando así menor cantidad de color, la figura 6.12 muestra la eliminación de cualquier color obscuro, quedando solo un matiz blanco como información más importante, tomando en cuenta que el robot deberá esquivar obstáculos de color blanco. Figura Umbralización de un par de imagenes. Aunque el proceso de umbralización arroja buenos resultados, hay que destacar que ningún algoritmo es óptimo para cualquier tipo de escenas y pueden presentar errores en muchas partes del mapa de disparidad. Como sucede con muchos algoritmos, el funcionamiento es óptimo en cierta estructura geométrica de la escena, pero cuando alguna de las restricciones en la estructura o hipótesis

124 124 Implementación, programación y puesta en marcha de la escena no se verifican, se generan errores. Figura Disparidad imagen alterada Resumen de resultados Los resultados en cuanto al algoritmo de caminata muestra una clara mejora con respecto a los movimientos originales del robot mini-humanoide, tanto en el plano sagital como en el axial se puede apreciar una mejora en el rendimiento por cada actuador como en el movimiento total del agente robótico, por lo que se concluye que el algoritmo implementado es muy aplicable para una tecnología general de robot humanoide. El procesamiento de imagen siempre será una tarea igual de complicada, y siempre puede mejorar pero dado a las limitaciones de la tecnología utilizada, este procesamiento siempre tiene que buscar ser lo más ligero y completo posible para explotar todas sus capacidades.

125 Capítulo 7 7 Conclusiones y Trabajos Futuros En este capítulo final se presentan las conclusiones más relevantes derivadas de esta Tesis de Máster, enfocada en Robótica humanoide. También se hace unas breves propuestas en líneas de trabajo futuro, dado que las tecnologías utilizadas son bastante genéricas y pueden ser implementadas en otros proyectos en la Universidad Carlos III de Madrid. 7.1 Conclusiones Se ha conseguido cumplir con los objetivos principales presentados al inicio de este trabajo en el que se contemplaba el acondicionamiento sobre el robot minihumanoide a una tecnología más robusta y con esto unir un sistema de visión y uno de caminata dinámica, lo que ha conllevado a un desplazamiento más efectivo en determinado ambiente.

126 126 Conclusiones y Trabajos Futuros Gracias a las experiencias adquiridas en el concurso de Ceabot 2012 realizado en Vigo, se a podido compartir experiencias con los participantes y adquirir información de los alcances de los mini-humanoides y de los requerimientos más necesarios al momento de la implementación de un robot más robusto y efectivo en la navegación. Todos los algoritmos y rutinas mostrados en la presente tesis fueron probados y evaluados a fin de determinar la factibilidad de su uso, así como el de demostrar su utilidad y efectividad en situaciones reales. Cabe decir que después de una larga lectura de trabajos relacionados al tema y complicadas teorías acerca de la localización de centro de gravedad y la caminata basada en un triple péndulo aplicada a robots humanoides, se ha llegado a la conclusión de que una vez más las respuestas más sencillas han dado mejores resultados, cosa similar ha pasado el momento de hacer el procesamiento de imagen, se ha implementado pocas pero muy útiles lineas de código fuente que han servido en la aplicación práctica. 7.2 Trabajos Futuros El presente trabajo solamente marca un inicio en el campo de la robótica humanoide que en los últimos años ha tenido un desarrollo importante y que continuará siendo estudiado en el futuro por su importancia. Se ha comenzado haciendo un trabajo de entrenamiento del conjunto de datos angulares arrojados por cada actuador incidente en el movimiento sagital, este para este entrenamiento se utilizo una red neuronal del tipo MLP (Perceptrón Multicapa), los resultado de movimientos individuales muestran mejora, pero el movimiento total de cada pierna varía al modelo desarrollado, aunque el punto final del efector realiza el recorrido deseado, el actuador situado en el tobillo hace una incidencia contra el suelo en un ángulo no deseado, lo que causa un mal movimiento y produce la caída del robot, por lo que el entrenamiento de datos debe tener otro criterio.

127 127 Conclusiones y Trabajos Futuros Dado que se ha agregado el acelerómetro y se han obtenido una serie de datos provenientes del mismo, estos datos podrían servir como base para hacer un nuevo entrenamiento, siempre siguiendo la base de movimiento y calculando acciones correctivas al momento que estos datos del acelerómetro salgan de los rangos normales de funcionamiento. Se espera que el presente trabajo aporte una base para desarrollar futuros proyectos en en sistemas robóticos, ya que los algoritmos utilizados y desarrollados no solo servirían para robots mini-humanoides, podrían acoplarse para robots humanoides de mayor peso y tamaño que el biolid (robot base utilizado para la realización del presente trabajo).

128

129 Referencias [1] González Fierro, Miguel; Jardón, Alberto; Martínez de la Casa, Santiago; F.Stoelen, Martin; G.Victores, Juan y Balaguer, Carlos (2010), Educational initiatives related with the CEABOT contest, Robotics Lab, Universidad Carlos III de Madrid. [2] Alenyà, Guillem; García Sánchez, Juan; Rull Sanahuja, Aleix (2013), Normativa Ceabot'13. Barcelona, Universidad Politécnica de Cataluña. [3] Fernández, C; Vicente, M.A; Puerto, R y Ñeco, R.P (2010), Experiencias docentes con el robot humanoide Rovonova I y con el microbot MOWAY, Departamento de Ingeniería de Sistemas Industriales, Escuela Politécnica Superior de Elche. [4] Contreras Tapia, Luis Martín; Galicia Valdovinos, Jesús Aarón; Mayoral Baños, José Carlos y Parrales Salinas, Arturon (2012), Análisis Cinemático del Robot Humanoide: Darwin OP, Memorias del primer concurso de investigación, desarrollo e innovación tecnológica IDIT [5] Barrientos, Antonio ; Peñin, Luis Felipe; Balaguer, Carlos y Baracil, Rafael (2009). Fundamentos de Robótica. Madrid: Mc Graw Hill. [6] Rodriguez Morales, Roberto (2011). Procesamiento y análisis digitales de imagenes. Madrid: Ra-Ma. [7] Gonzales Pajares, Martínsanz y de la Cruz García, Jesús M (2008). Visión por computadora, Alfaomega Ra-Ma

130 130 [8] Referencias Tira-Thompson, Ethan (2009). Digital Servo Calibration and Modeling, Robotics Institute, Universidad Carnegie Mellon. [9] Akhtaruzzaman, Md. y Shafie, Amir A (2011). Geometrical Analysis on BIOLOID Humanoid System Standing on Single Leg, 4th International Conference on Mechatronics (ICOM 11), Kuala Lumpur, Malaysia. [10] Nunez, V. ; Olvera, L-I y Pamanes, J-A (2011). Simulation and Experimentation of Walking of the Bioloid Humanoid Robot, 3thWorld Congress in Mechanism and Machine Science, Guanajuato-México, División de Estudios de Posgrado e Investigación, Instituto Tecnológico de la LagunaTorrejón. [11] Vítores, J. G. (2012). Cartesian Server, Universidad Carlos III de Madrid, cartesianserver.html. [12] Fitzpatrick, Paul ; Natale, Lorenzo y Tikhanoff, Vadim (2013). Using YARP from python, java, ruby, C#, and other languages, [13] Reyes, Fernando (2012). MATLAB Aplicado a Robotica Y Mecatronica 1º Edición. Alfaomega. [14] Laganiere, Robert (2011). OpenCV 2 Computer Vision Application Programming Cookbook. Mumbai: Packt Publishing. [15] Proyectos Robóticos, marzo [16] Rublee, Ethan.; Rabaud, Vincent.; Konolige, Kurt.; Bradski, Gary (2011). ORB: an efficient alternative to SIFT or SURF, Willow Garage, Menlo Park, California. [17] Dávila.Q, Jacinto.A (2011). Lógica, Computacional Modelado y Simulación. Practica y Aprendizaje

131 ANEXOS En este apartado de anexos se detallaran ciertas configuraciones adicionales realizadas para la ejecución de nuestro trabajo. OpenRAVE En reiteradas veces en este documento se ha mencionado este simulador, el cual ha sido seleccionado por varias razones, permite integrar una secuencia de comandos a alto nivel, además que es de código abierto y permite hacer una animación del medio ambiente, este simulador esta dirigido a aplicaciones del mundo real robótico autónomo e incluye una buena integración 3D de simulación, visualización, planificación en secuencias de comandos de control, por último OpenRAVE posee una arquitectura plug-in que permite a un usuario escribir controladores personalizados o ampliar su funcionalidad.

132 132 ANEXOS Instalación de OpenRAVE La instalación de OpenRAVE es muy sencilla, se hace desde los repositorios, solo hay que abrir un terminal y agregar las siguientes lineas de comando: Tabla A.1. Instalación OpenRAVE. sudo add-apt-repository ppa:openrave/release sudo apt-get update sudo apt-get install openrave Nota: Hay que tomar en cuenta que el uso del comando sudo requiere de autenticación de usuario así que pedirá contraseña. Terminada la instalación de OpenRAVE podemos lanzarlo escribiendo la orden openrave en una terminal, teniendo una apariencia como la figura 8.1 que indica que openrave esta corriendo. Figura A.1. Apariencia OpenRAVE.

133 Yarp En el capítulo 2 se hizo una leve introducción de Yarp y los motivos por los que hemos utilizado este midleware son varios. Sabemos que Yarp cuenta con un conjunto de protocolos, librerías y herramientas que mantienen dispositivos desacoplados, en nuestro caso será el mediador entre nuestro simulador OpenRAVE y nuestro código de movimiento en c++ a demás que estableceremos un puerto de comunicaciones tcp por el que viajarán los datos, datos que serán recogidos posteriormente para su análisis en Matlab y este último también será configurado para reconocer el puerto creado por yarp. Instalación y configuración de yarp La instalación de yarp es muy sencilla, se hace desde los repositorios, solo hay que abrir un terminal y agregar las siguientes lineas de comando: Tabla A.2. Instalación Yarp. sudo apt-get install build-essential libace-dev subversion git sudo apt-get install libgsl0-dev # Needed for creating YARP lib_math we use for kinematics sudo apt-get install libgtkmm-2.4-dev # Needed for YARP GUIs: yarpview, gyarpmanager sudo apt-get install libjpeg8-dev # Needed for mjpeg_carrier for ravebot cam on web git clone cd yarp; mkdir build; cd build cmake.. -DCREATE_LIB_MATH=ON -DCREATE_GUIS=ON -DCREATE_OPTIONAL_CARRIERS=ON -DENABLE_yarpcar_mjpeg_carrier=ON make -j3; sudo make install; cd../.. Nota: Hay que tomar en cuenta que el uso del comando sudo requiere de autenticación de usuario así que pedirá contraseña. Posterior a la instalación es muy recomendable establecer las variables de entorno YARP_ROOT a yarp y la variable YARP_DIR a yarp/build y para

134 134 ANEXOS ello hay dos formas. Tabla A.3. Configuración de variables de entorno yarp. A través de./profile escribiendo: echo "export YARP_ROOT=$PWD/yarp" >> ~/.profile echo "export YARP_DIR=$PWD/yarp/build" >> ~/.profile source ~/.profile A través de./bashrc escribiendo: echo "export YARP_ROOT=$PWD/yarp" >> ~/.bashrc echo "export YARP_DIR=$PWD/yarp/build" >> ~/.bashrc source ~/.bashrc Una vez que se instalado y configurado yarp, este puede ser lanzado tecleando en el terminal yarpserver, ejecutando esta acción tendremos un resultado como la figura 8.2. Figura A.2. Lanzamiento de yarpserver exitoso. Matlab & YARP MATLAB (MATrix LABoratory, "laboratorio de matrices"), es un paquete de

135 software matemático orientado hacia el cálculo numérico científico y de ingeniería, Matlab hace una integración del cálculo numérico, computación de matrices y de gráficos en un entorno de desarrollo integrado (IDE), a demás que tiene un lenguaje de programación propio y está disponible para plataformas Unix. Windowx y Mac OS X. Para la configuración de yarp en Matlab, es decir que Matlab pueda escuchar un puerto tcp definido por yarp se ha seguido los pasos descritos en la wiki de icub [17], haremos una descripción de los pasos seguidos para establecer esta comunicación. Configuración de SWIG Hay que tomar en cuenta ciertas cosas antes de iniciar con la configuración como tal de yarp, sabemos que está escrito en C ++, si deseamos utilizar todas las características de yarp en un programa escrito en un lenguaje diferente, es recomendable utilizar SWIG42, creando así una interfaz entre yarp y el lenguaje de programación elegido en nuestro caso C++, a demás yarp acepta leguajes de programación como: Java, Python, Perl, Chicken Scheme, C#, Allegro Common Lisp, TCL y Ruby, la tabla 8.4 muestra la instalación de SWIG sobre linux, además de JAVA necesario para nuestra configuración. Tabla A.4. Instalación de SWIG sobre linux. sudo apt-get install swig sudo apt-get install openjdk-6-jdk La forma más fácil de usar yarp desde Matlab es a través de sus enlaces Java, ya para esto primero debemos construirlos enlaces correspondientes. Configuración de enlaces de lenguaje Yarp Ejecutamos el CMake GUI (o ccmake desde la línea de comandos), y estableciendo primero el directorio de origen a $ YARP_ROOT / bindings, donde YARP_ROOT es la ruta de acceso al código fuente YARP. Establecemos el 42 Es una herramienta de desarrollo de software que conecta programas escritos en C y C + + con una variedad de lenguajes de programación de alto nivel.

136 136 ANEXOS directorio de construcción en el lugar que deseemos siempre es recomendable crear una carpeta nosotros la llamaremos build. Cuando se realiza la configuración, hay que habilitar varias opciones de tal manera que se permitan una variedad de lenguajes por ejemplo (CREATE_JAVA, CREATE_PYTHON, y así sucesivamente). Debemos habilitar una de estas opciones (se puede llegar a conseguir conflictos entre ciertos pares de lenguajes, si decide construir más de uno solo, de ahí la necesidad de crear una carpeta build ). Superado este paso se debe tener un archivo de proyecto o Makefile en el directorio build. Lo construimos con un make y listo. La tabla 8.5 muestra los pasos exactos que debemos seguir, creamos una carpeta vacía de nombre build dentro del directorio, esta carpeta puede llevar cualquier otro nombre, ingresamos en ella, ejecutamos el comando ccmake.., ahora dentro del cmake buscamos el flag CREATE_*, la habilitamos en el lenguaje que utilizaremos, para nosotros C++, generamos el CMake y salimos. Tabla A.5. Pasos a seguir para configuración de enlaces yarp. cd $YARP_ROOT/bindings mkdir build cd build ccmake.. CREATE_<LANGUAGE>=ON Si todo ha salido bien tenemos listo el archivo CMake, lo único que queda por hacer es hacer una instalación normal(tabla 8.6). Tabla A.6. Instalación de Enlaces. make sudo make install # opcional Al superar todos estos pasos nos encontraremos con que se ha creado una nueva carpeta de nombre genrated_src, a demás de ella encontraremos un archivo de nombre libjyarp.so que es nuestra biblioteca de configuración generada, ingresamos en la carpeta genrated_src y generamos las clases faltantes (tabla 8.7) y con ello el proceso esta completo por parte de yarp.

137 Tabla A.7. Generación de clases faltantes para los enlaces yarp. cd $YARP_ROOT/build cp generated_src/*. javac -source 1.3 -target 1.3 *.java Llamado de yarp desde Matlab En el lado de Matlab el trabajo es mas sencillo, primero debemos encontrar dos archivos classpath.txt y librarypath.txt, hay varias formas de encontrar estos archivos en linux, usando el comando locate, whereis, etc., tambien se puede reguntar de la localización de estos archivos desde Matlab utilizando la orden which, pero por lo general estos archivos están dentro de /usr/local/matlab/r_version/toolbox/local/. En cada uno de estos archivos hay que agregar dos lineas que especifiquen el lugar dentro de yarp en el que se han creado los enlaces (tabla 8.8). Tabla A.8. Llamado de yarp desde Matlab. gvim /usr/local/matlab/r_version/toolbox/local/classpath.txt yarp root/example/bindings/generated src yarp root/example/bindings esc :wq! gvim /usr/local/matlab/r_version/toolbox/local/librarypath.txt yarp root/example/bindings/generated src yarp root/example/bindings esc :wq! Terminado con esto, yarp estará listo sobre Matlab, lo podemos comprobar escribiendo dentro del workspace de Matlab el comando LoadYarp, si esto nos da un puerto significa que todo esta correcto. Respaldo de Disco SD Como ya se sabe la x86 ROBOARD usa una micro SD como disco duro, donde se almacenará el S.O., diferentes configuraciones del sistema y los archivos

138 138 ANEXOS desarrollados en el trabajo, por motivos de seguridad se ha hecho un respaldo periódico de este disco duro, evitando así la perdida de información, de instalación de paquetes o configuraciones desarrolladas. Se ha hecho el volcado de dicha SD aplicando el comando ddrescue de la memoria microsd con el S.O. funcional a una nueva microsd nueva y formateada. Este comando asegura una copia e informa de errores bit-a-bit, se copian todos los enlaces simbólicos y elementos de sistema (tabla A9), cosa que un cp no lo asegura. La ejecución de este comando se ejecutará sin problemas siempre y cuando el espacio disponible en la memoria de respaldo sea el suficiente (mayor o igual al espacio de la memoria de origen), la figura A3 muestra el estado de progreso en la ejecución del comando. Al finalizar este proceso se obtendrá una copia por completo funcional del Sistema Operativo idéntico al original. Tabla A9. Respaldo de microsd. sudo apt-get install gddrescue # instala el paquete df # muestra la lista de particiones activas para hacer la copia sudo ddrescue -vf /dev/sd_origen /dev/sd_destino # realización de copia Figura A3. Ejecución en marcha ddrescue.