Ingeniería Industrial
Intensificación en sistemas eléctricos
Departamento de Ingeniería de Sistemas y Automática Año académico: 2014/2015
Diseño de trayectorias del efector final de un robot manipulador para la
evitación de obstáculos
PROYECTO FIN DE CARRERA
Autor: José Antonio Torres Sánchez
Directores: Jorge Feliu Batlle / José Luis Muñoz Lozano
Cartagena, 9 de diciembre de 2015
- 1 - | P á g i n a
PREAMBULO
El actual proyecto se ha desarrollado en el laboratorio de I+D del Departamento de Ingeniería de Sistemas y Automática de la Universidad Politécnica de Cartagena, al que queremos agradecer el apoyo y la cesión de su instalaciones, especialmente a Jorge Feliu y a José Luis Muñoz por haberse ofrecido a dirigir nuestro proyecto.
También queremos dar las gracias a Carlos Díaz por su ayuda y paciencia, lo que nos ha resultado clave para llevar a buen puerto todo lo que hemos realizado. También a Pablo Martínez por estar siempre dispuesto a echar una mano y prestarnos el equipo de grabación.
El objetivo que se va a perseguir en los próximos capítulos es la planificación de trayectorias a seguir por un brazo robótico para conseguir la evitación de los obstáculos que se encuentre para llegar a una posición final.
Este proyecto se ha llevado a cabo de forma conjunta con el proyecto de Lidia Sánchez Martínez en el que se muestra como reconocer objetos y obstáculos a través del sensor Sick LMS 200 cuyas características se especifican en el Capítulo 4.
Mostraremos como conseguir que el extremo del brazo se desplace desde un punto inicial hasta un punto final, evitando los objetos en su camino detectados por el sensor, todo ello programado en C++ empleando Visual Studio 2010 Ultimate.
Indicaremos todos los pasos a seguir para conseguir dicho objetivo con el fin de que, cualquier otro estudiante o persona con limitados conocimientos de programación y automática pueda reproducir rápidamente y sin ningún problema todo lo que hemos conseguido.
- 2 - | P á g i n a
- 3 - | P á g i n a
ÍNDICE
CAPÍTULO 1: MOTIVACIONES ... - 11 -
1.Motivaciones ... - 13 -
CAPÍTULO 2:INTRODUCCIÓN ... - 15 -
2.Introducción ... - 17 -
2.1. Estado del arte ... - 17 -
2.1.1. Robots ... - 17 -
2.1.2. Cinemática del robot ... - 17 -
2.1.3. Jacobiano ... - 18 -
2.1.4. Articulaciones y grados de libertad... - 18 -
2.2. Un poco de historia... ... - 19 -
CAPÍTULO 3:MICROSOFT VISUAL STUDIO 2010 ULTIMATE ... - 23 -
3. Microsoft Visual Studio 2010 Ultimate ... - 25 -
3.1. Descripción ... - 25 -
3.2. Ventajas ... - 25 -
3.3. Microsoft Foundation Classes (MFC) ... - 29 -
3.3.1. Características ... - 30 -
3.3.2. Tipos de aplicaciones: ... - 30 -
3.4. Creación de nuestro proyecto ... - 31 -
3.5. Requisitos del sistema ... - 36 -
CAPÍTULO 4:DESCRIPCIÓN DEL HARDWARE UTILIZADO ... - 37 -
4. Descripción del Hardware utilizado. ... - 39 -
4.1.Sick LMS 200. ... - 39 -
- 4 - | P á g i n a
4.1.1. Descripción ... - 39 -
4.1.3. Funcionamiento ... - 40 -
4.1.4. Mecánica / electrónica ... - 40 -
4.1.5. Dimensiones ... - 41 -
4.1.6. Diagrama de rango de operación ... - 42 -
4.1.7. Adaptador de puerto serie a USB ... - 42 -
4.2. Robotnik Modular Arm ... - 43 -
4.2.1. Descripción ... - 44 -
4.2.2. Componentes ... - 44 -
4.2.3. Seguridad ... - 48 -
4.3. Objetos empleados ... - 49 -
CAPÍTULO 5:DESARROLLO DEL PROYECTO ... - 51 -
5. Desarrollo del Proyecto ... - 53 -
5.1. Librerías empleadas ... - 53 -
5.2. Definición de variables ... - 54 -
5.3. Obtención de coordenadas de objetos ... - 55 -
5.3.1. Solicitud al usuario ... - 55 -
5.3.2. Recepción de datos del sensor ... - 55 -
5.3.2.1. Abrir el puerto de comunicación con el sensor ... - 56 -
5.3.2.2. Intercambio de datos con el sensor. ... - 57 -
5.3.2.3. Función deteccionobjetos ... - 60 -
5.3.3. Datos obtenidos del sensor como punto de partida. ... - 62 -
5.4. Transformación de coordenadas ... - 63 -
5.5. Selección de la tarea a realizar ... - 65 -
5.5.1. Trayectoria en zig-zag ... - 67 -
- 5 - | P á g i n a
5.5.1.1. Habilitar la ejecución de esta variante del código ... - 67 -
5.5.1.2. Planificación de los puntos de paso. ... - 67 -
5.5.1.3. Ejecución de los movimientos... - 70 -
5.5.1.4. Problemática de objetos demasiado juntos. ... - 72 -
5.5.1.4.1Objetos 1 y 2 muy cercanos. ... - 73 -
5.5.1.4.2Objetos 2 y 3 muy cercanos ... - 73 -
5.5.2. Trayectoria circular ... - 76 -
5.5.2.1. Habilitar la ejecución de esta variante del código ... - 76 -
5.5.2.2. Planificación de los puntos de paso ... - 76 -
CAPÍTULO 6:CÁLCULOS DE LA CINEMÁTICA ... - 79 -
6. Cálculos de la cinemática ... - 81 -
6.1. Definiciones y objetivos ... - 81 -
6.2. Cálculos ... - 82 -
CAPÍTULO 7:ERRORES FRECUENTES ... - 85 -
7. Errores frecuentes ... - 87 -
CAPÍTULO 8:DESARROLLOS FUTUROS ... - 89 -
8. Desarrollos futuros ... - 91 -
CAPÍTULO 9:OTRAS ALTERNATIVAS ... - 93 -
9. OTRAS ALTERNATIVAS ... - 95 -
9.1. ROS ... - 95 -
9.1.1. ROS Hydro ... - 95 -
9.2. Move it! ... - 100 -
- 6 - | P á g i n a
9.2.1. Introducción ... - 100 -
9.2.2. Instalación del paquete ... - 100 -
9.2.3. Errores aparecidos ... - 101 -
CAPÍTULO 10:BIBLIOGRAFÍA ... - 103 -
10. BIBLIOGRAFIA ... - 105 -
ANEXO I: LIBRERÍA M5APIW32 ... - 111 -
- 7 - | P á g i n a
ÍNDICE DE FIGURAS
Ilustración 2.1. Telar de J. Jacquard………20
Ilustración 2.2 Cronología de los avances modernos de la robótica………...21
Ilustración 3.1. Pruebas durante el desarrollo de la aplicación………..…….…29
Ilustración 3.2. Nuevo proyecto de Microsoft Visual Studio………..…………....31
Ilustración 3.3. Selección de tipo de aplicación y nombre………..…...32
Ilustración 3.4. Selección de parámetros I………..32
Ilustración 3.5. Selección de parámetros II………..33
Ilustración 3.6. Selección de parámetros III………34
Ilustración 3.7. Selección de parámetros IV………34
Ilustración 3.8. Selección de parámetros V……….35
Ilustración 3.9. Distribución del proyecto………...……35
Ilustración 4.1. Escáner Sick LMS 200………...39
Ilustración 4.2. Características Sick LMS 200………....39
Ilustración 4.3. Funcionamiento………..40
Ilustración 4.4. Mecánica y electrónica del escáner………41
Ilustración 4.5. Dimensiones y topología del escáner………...…..41
Ilustración 4.6. Rango de operación Sick LMS 200………42
Ilustración 4.7. Adaptador de puerto Serie a USB………..42
Ilustración 4.8. Adaptador en el puerto COM 5……….43
Ilustración 4.9. Brazo robótico modular………..43
Ilustración 4.10. Enlace 1 del robot………...44
Ilustración 4.11. Enlace 2 del robot………...45
Ilustración 4.12. Enlace 3 del robot……….45
Ilustración 4.13. Enlace 4 del robot……….46
Ilustración 4.14. Enlace 5 del robot……….…46
Ilustración 4.15. Tabla resumen COM y parámetros de inercia………..47
Ilustración 4.16. Seta de emergencia del robot………48
Ilustración 4.17. Alzado Objeto 1……….………..………49
Ilustración 4.18. Planta Objeto 1……….………49
Ilustración 4.19. Alzado Objeto 2……….………..…50
Ilustración 4.20. Planta Objeto 2……….………..………50
- 8 - | P á g i n a
Ilustración 4.21. Alzado Objeto 3….……….………50
Ilustración 4.22. Planta Objeto 3……….………50
Ilustración 4.23. Vista general del emplazamiento de trabajo….………50
Ilustración 5.1. Librerías empleadas………53
Ilustración 5.2. Análisis de librerías………54
Ilustración 5.3. Definición de variables………...54
Ilustración 5.4. Solicitud de datos al usuario………..….……....55
Ilustración 5.5. Exportar datos a Excel………56
Ilustración 5.6. Apertura del puerto serie de comunicación con escáner………56
Ilustración 5.7. Datagrama Sick LMS 200………..57
Ilustración 5.8. Solicitud de datos al escáner………...58
Ilustración 5.9. Recuperación de datos del escáner………...59
Ilustración 5.10. Recuperar la longitud del datagrama a enviar………..59
Ilustración 5.11. Mensajes de respuesta equivocada del sensor………..60
Ilustración 5.12. Función deteccionobjetos……….61
Ilustración 5.13. Definición de estructura de medición y posición objetos……….63
Ilustración 5.14. Obtención de coordenadas cartesianas respecto sensor………63
Ilustración 5.15 Escena escáner y objetos……….64
Ilustración 5.16. Transformación al sistema de referencia del robot………..65
Ilustración 5.17. Trayectoria zig-zag en situación normal………...65
Ilustración 5.18. Trayectoria en zig-zag objetos 1 y 2 muy juntos……….……….66
Ilustración 5.19. Trayectoria en zig-zag objetos 2 y 3 muy juntos……….……….66
Ilustración 5.20. Trayectoria circular……….………….67
Ilustración 5.21. Selección secuencia trayectoria en zig-zag………..67
Ilustración 5.22. Transformación al sistema de referencia del robot………..69
Ilustración 5.23. Cálculo del punto de paso 1………..69
Ilustración 5.24. Ejecución punto de paso 1………71
Ilustración 5.25. Puntos de paso situación normal en zig-zag…….………72
Ilustración 5.26. Ejecución punto de paso 2………73
Ilustración 5.27. Secuencia puntos de paso (objetos 1 y 2 demasiado cercanos)………74
Ilustración 5.28. Ejecución punto de paso 4………...………74
Ilustración 5.29. Ejecución punto de paso 5………..….………75
Ilustración 5.30. Secuencia puntos de paso (objetos 2 y 3 muy cercanos)…….………75
- 9 - | P á g i n a
Ilustración 5.31. Selección secuencia trayectoria circular……..……….………76
Ilustración 5.32. Puntos de paso para la Trayectoria circular...………..……….76
Ilustración 6.1. Objetivos de la cinemática inversa……….81
Ilustración 6.2. Ejes del robot………..82
Ilustración 6.3. Representación de la cinemática inversa………83
Ilustración 6.4. Solución a la cinemática inversa………83
Ilustración 6.5. Programación de la cinemática inversa………..84
Ilustración 7.1. Empleo de los Breakpoints……….88
Ilustración 9.1. Verificación orígenes software………...97
- 10 - | P á g i n a
- 11 - | P á g i n a
CAPÍTULO 1:
Motivaciones
- 12 - | P á g i n a
- 13 - | P á g i n a
1. MOTIVACIONES
Hay grandes dudas sobre cómo se desarrollarán a corto, medio y largo plazo los posibles caminos que pueden tomar la evolución la industria, el comercio y la búsqueda de nuevas fuentes y recursos energéticos. Tampoco se ponen de acuerdo los expertos en la forma de salir de la actual crisis económica, ni siquiera en cuando estaremos preparados para dar el salto definitivo a las energías renovables. Sin embargo, de lo que no hay duda pase lo que pase en el futuro es del papel primordial y absolutamente necesario de la robótica, la automatización industrial y la ingeniería de control.
Cuesta imaginarse cualquier empresa que no pueda resultar ampliamente beneficiada económicamente de la automatización de sus procesos. Es por ello que, sin duda alguna, siempre serán valorados conocimientos de programación y de ingeniería de control, independientemente del resto de requisitos que se precisen.
Asimismo, una de las grandes ambiciones de la Humanidad desde el origen de los tiempos es conocer el universo que nos rodea, más allá de nuestro planeta y del Sistema Solar. Las grandes empresas espaciales, como la N.A.S.A. o la agencia Espacial Europea (E.S.A.) no cesan en sus intentos por llegar más lejos posible y descubrir el origen del agua y de la vida. Todo ello no sería posible sin el desarrollo de la Ingeniería de Control.
Todo lo anteriormente descrito, sin duda, hace que desarrollar un proyecto que permita profundizar en los conocimientos sobre esta materia sea una experiencia muy atractiva para cualquier estudiante. Todo ello unido a la magnífica labor docente llevada a cabo por el departamento en asignaturas como “Teoría de Sistemas”, “Ingeniería de control” o “Robótica Industrial” me han animado a dar el paso definitivo a realizar este proyecto.
- 14 - | P á g i n a
- 15 - | P á g i n a
CAPÍTULO 2:
Introducción
- 16 - | P á g i n a
- 17 - | P á g i n a
2. INTRODUCCIÓN
2.1. ESTADO DEL ARTE
Hay multitud de trabajos, especialmente aquellos que implican un esfuerzo físico excesivo o bien son extremadamente monótonos o peligrosos, que a las personas no les gusta o no están dispuestas a hacer.
Es aquí donde la evolución de la robótica juega un papel primordial. Además, la velocidad y precisión de los equipos automatizados hacen de ellos el trabajador más eficiente con el que ningún otro trabajador humano podría competir. Además, parece obvio que los máquinas no necesitan descansar (salvo en determinadas circunstancias especiales, como de mantenimiento), comer, un salario o una zona segura para trabajar.
2.1.1. Robots
Podemos definir un robot como un conjunto de dispositivos que reciben información (sensores) y que, por medio de la interfaz adecuada, emplean dichos datos para realizar un movimiento de salida (evitar obstáculos, sujeción de objetos, etc.) bien a través de sistema operativo externo conectado con el robot y con los sensores, o bien a través de microprocesadores implementados en el propio robot.
2.1.2. Cinemática del robot
Estudio de su movimiento con respecto a un sistema de referencia. Hay dos tipos de análisis cinemáticas posibles:
Análisis cinemático directo: Determinar la posición y orientación del extremo final del robot, con respecto a un sistema de coordenadas de referencia, conocidos los ángulos de las articulaciones y los parámetros geométricos de los elementos del robot.
Problema cinemático inverso: Determinar la configuración que debe adoptar el robot para una posición y orientación del extremo conocidas.
- 18 - | P á g i n a
2.1.3. Jacobiano
Matemáticamente las ecuaciones cinemáticas directas definen una función entre el espacio cartesiano de posiciones y orientaciones y el espacio de las articulaciones.
Las relaciones de velocidad se determinan por el Jacobiano de esta función.
El Jacobiano es una matriz compuesta por las derivadas de una función escalar.
Es imprescindible su uso en el análisis y control del movimiento de un robot (planificación y ejecución de trayectorias suaves, determinación de configuraciones singulares, ejecución de movimientos coordinados, derivación de ecuaciones dinámicas).
En muchos casos y sistemas operativos modernos las librerías encargadas de crear la trayectoria de cada articulación para alcanzar la posición deseada vienen preconfiguradas, por lo que se facilita su uso en aquellas personas con limitado o nulo conocimiento de programación.
2.1.4. Articulaciones y grados de libertad
Con la misma morfología que un brazo humano, un brazo robótico industrial está formado por una serie de partes rígidas unidas por articulaciones. A esta unión se le denomina cadena.
Al inicio de esta cadena se le denomina base. En el caso que nos ocupa (brazo robótico) esta base será fija (fixed), aunque también podría no serlo si estamos considerando un robot móvil.
En el extremo opuesto a la base se acopla la herramienta de trabajo (desde una mano para el agarre hasta cualquier otro utensilio para pintar, atornillar, etc.).
En muchos casos, las articulaciones permiten que entre las partes que unen (también llamadas ejes), se pueda producir un movimiento de desplazamiento, de giro o una combinación de ambos.
- 19 - | P á g i n a Con tres traslaciones según el respectivo eje X, Y o Z y tres giros o rotaciones (yaw, pitch, roll) relacionadas con estos mismos ejes, podemos posicionar cualquier elemento, objeto u herramienta en el espacio. Generalmente los robots consiguen el posicionado por medio de sus tres primeras articulaciones a partir de la base y la orientación de su elemento terminal o herramienta con el resto de articulaciones. No es necesario que un robot tenga los 6 GDL para todas las aplicaciones, hay robots con solo 3 GDL.
Por otro lado, también se habla de robots con más de 6 articulaciones y GDL, que permiten aumentar la accesibilidad a ciertas zonas de trabajo; en este caso y para un solo brazo-robot, no se tienen más de 6 GDL, pues alguna de las articulaciones o ejes proporcionan falsos GDL que son repetidos de los proporcionados por otras articulaciones.
2.2. UN POCO DE HISTORIA...
Desde la Antigüedad, los hombres han intentado construir máquinas automáticas que faciliten su trabajo, hagan más cómoda su existencia, satisfagan su curiosidad y su afán de aprender e investigar, o simplemente les sirvan de entretenimiento.
Ya en la Antigua Grecia se construyeron ingenios de funcionamiento automático a los que llamaron autómatas; posteriormente en la Edad Media y en el Renacimiento se siguieron fabricando diversos autómatas, entre ellos el Gallo de Estrasburgo (1230) y el León Animado de Leonardo Da Vinci.
Durante los siglos XVII y XVIII se crearon ingenios mecánicos de mayor complejidad que tenían alguna de las características de los robots actuales. Jacques de Vaucanson (1709-1782) construyó varios autómatas, uno de los más conocidos es un pato mecánico, que bebe, come, grazna, chapotea en el agua y digiere su comida “como un pato verdadero”; estos primeros autómatas estaban destinados fundamentalmente a ser exhibidos en las ferias y servir de entretenimiento en las Cortes y entre la nobleza.
- 20 - | P á g i n a A finales del siglo XVIII y también a principios del XIX se desarrollaron algunas máquinas para empleo en la industria textil, entre las que ya había algún telar en el que mediante el uso de tarjetas perforadas se podía elegir el tipo de tela a tejer, este hito, constituyó uno de los primeros precedentes históricos de las máquinas programadas por control numérico.
Un poco más tarde que en la industria textil, se incorporan los automatismos en las industrias mineras y metalúrgicas, es la época de las máquinas de vapor; James Watt (1736-1819) contribuyó decisivamente al desarrollo de estas máquinas e inventó el llamado regulador de Watt, que es un regulador centrifugo de acción proporcional; con él nació el concepto de realimentación y la regulación automática, que es una de las bases de los robots industriales actuales, pues entre otros elementos, incorporan diversos sensores y reguladores PID.
La palabra robot se empleó por primera vez en 1920 en una obra de teatro llamada Robots Universales Rossum escrita por el dramaturgo checo Karel Capek, se deriva de la palabra checa “robotnik” y significa, siervo, servidor o trabajador forzado.
Es en el siglo XX cuando se empieza a hablar de robots y se produce el desarrollo de estos, que va ligado con el desarrollo de los microprocesadores. En la tabla siguiente se citan algunos hechos destacables con sus fechas aproximadas:
1954
A partir de esta fecha, el estadounidense George Devol, comienza la construcción de un brazo articulado que realiza una secuencia de movimientos programables por medio de computador; se considera que este “brazo” es el primer robot industrial.
1956 Devol conoció a Joseph Engelberger y juntos fundaron en 1960 la empresa Unimation dedicada a la fabricación de robots.
Ilustración 2.1. Telar de J.
Jacquard
- 21 - | P á g i n a 1961 Se realizan pruebas de un robot Unimate accionado hidráulicamente, en
un proceso de fundición en molde en General Motors.
1968
Kawasaki se une a Unimation y comienza la fabricación y el empleo de robots industriales en Japón. En este año General Motors, emplea baterías de robots en el proceso de fabricación de las carrocerías de los coches 1973
La empresa sueca ASEA, fabrica el primer robot completamente eléctrico, es el tipo de accionamiento que ha acabado imponiéndose, debido a los avances registrados en el control de motores eléctricos.
1974
Se introduce el primer robot industrial en España. También es el año en el que se comienza a usar el lenguaje de programación AL, del que derivarán otros de uso posterior como el VAL (Victor´s Assembly Languaje) de los robots PUMA, implementado en 1975 por Victor Scheinman, que junto a Devol y Engelberger, son pioneros en la robótica industrial.
1978
Comienza a emplearse el robot PUMA (Programmable Universal Machine for Assambly) de Unimatión, que es uno de los modelos que más se ha usado, su diseño de “brazo” multiarticulado es la base de la mayoría de los robots actuales.
1981 Comienza la comercialización del robot tipo SCARA (Selective Compliance Arm for Robotic Assambly) en Japón.
1987 Se constituye la Federación Internacional de Robótica con sede en Estocolmo.
Ilustración 2.2.Cronología de los avances modernos de la robótica
Durante estos años, se sientan las bases de la robótica industrial, posteriormente irá aumentando el empleo y la sofisticación de los robots con el aumento de las prestaciones de los microprocesadores y las posibilidades de la informática.
- 22 - | P á g i n a
- 23 - | P á g i n a
CAPÍTULO 3:
Microsoft Visual
Studio 2010 Ultimate
- 24 - | P á g i n a
- 25 - | P á g i n a
3. MICROSOFT VISUAL STUDIO 2010 ULTIMATE
Como se ha dicho anteriormente, para llevar a cabo la programación necesaria en este proyecto se ha empleado este software, cuyas características se exponen a continuación:
3.1. DESCRIPCIÓN
Microsoft Visual Studio 2010 Ultimate es un exhaustivo paquete de herramientas de administración del ciclo de vida de las aplicaciones para equipos. Con este paquete es posible garantizar la calidad de los resultados, desde el diseño hasta la implementación. Tanto para soluciones nuevas como para mejorar las aplicaciones ya existentes, Visual Studio 2010 Ultimate resulta una herramienta de gran utilidad gracias a que admite un número cada vez mayor de plataformas y tecnologías (incluídos los sistemas informáticos en cloud y en paralelo).
3.2. VENTAJAS
Son muchas las ventajas del empleo de este software, enumeramos algunas de ellas:
Permite una actitud proactiva, así como la administración ágil de un proyecto
Visual Studio 2010 Ultimate está optimizado para el proceso de desarrollo iterativo actual con características que ayudan a mantener la productividad y a reaccionar frente a posibles riesgos antes de que se produzcan. Permite supervisar el estado del proyecto mediante informes que se generan automáticamente. Además, es posible administrar la capacidad del proyecto con datos históricos y documentos de planificación basados en Microsoft Excel.
Características de Visual Studio 2010 Ultimate
Microsoft Visual Studio 2010 Ultimate incluye potentes herramientas que simplifican todo el proceso de desarrollo de aplicaciones, de principio a fin. Los equipos pueden observar una mayor productividad y ahorro de costes al utilizar características de colaboración avanzadas, así como herramientas de pruebas y depuración integradas que le ayudarán a crear siempre un código de gran calidad.
- 26 - | P á g i n a
Administración del ciclo de vida de las aplicaciones (ALM)
La creación de aplicaciones de éxito requiere un proceso de ejecución uniforme que beneficie a todos los componentes del equipo. Las herramientas de ALM integradas en Visual Studio 2010 Ultimate contribuyen a que las organizaciones colaboren y se comuniquen de forma efectiva en todos los niveles, y a que se hagan una idea precisa del estado real del proyecto, lo que garantiza que se ofrezcan soluciones de gran calidad al tiempo que se reducen los costos.
Depuración y diagnóstico
Visual Studio 2010 Ultimate presenta IntelliTrace, una valiosa característica de depuración que hace que el argumento “no reproducible” sea cosa del pasado. Los evaluadores pueden archivar errores enriquecidos y modificables para que los desarrolladores puedan reproducir siempre el error del que se informe en el estado en el que se encontró. Otras características incluyen análisis de código estático, métricas de código y creación de perfiles.
Herramientas de prueba
Visual Studio 2010 Ultimate incorpora multitud de herramientas avanzadas de pruebas para ayudar a garantizar la calidad del código en todo momento. Pruebas de IU codificadas, que automatizan la realización de pruebas de la interfaz de usuario en aplicaciones basadas en web y en Windows®, así como de pruebas manuales, Test Professional, pruebas de rendimiento de web, pruebas de carga, cobertura de código y otras características completas que no se encuentran en otras ediciones de Visual Studio.
Arquitectura y modelado
El Explorador de arquitectura de Visual Studio 2010 Ultimate ayuda a entender los activos de código existentes y otras interdependencias. Los diagramas por capas ayudan a garantizar el cumplimiento de la arquitectura y permiten validar artefactos de código con respecto al diagrama. Además, Visual Studio 2010 Ultimate admite los cinco diagramas de UML más comunes que conviven junto con su código.
Desarrollo de bases de datos
El desarrollo de bases de datos requiere el mismo cuidado y atención que el desarrollo de aplicaciones. Visual Studio 2010 Ultimate es consciente de ello y
- 27 - | P á g i n a proporciona potentes herramientas de implementación y administración de cambios que garantizan que la base de datos y la aplicación estén siempre sincronizadas.
Entorno de desarrollo integrado
Multitud de características personalizables como, por ejemplo, compatibilidad con varios monitores. Es posible dar rienda suelta a la creatividad utilizando los diseñadores visuales para mejorar las últimas plataformas, incluido Windows 7.
Compatibilidad con la plataforma de desarrollo
Tanto para crear soluciones nuevas como para mejorar las aplicaciones ya existentes, Visual Studio 2010 Ultimate permite hacer realidad dicha idea en una gran variedad de plataformas, entre las que se incluyen Windows, Windows Server, Web, Cloud, Office y SharePoint, entre otras, todo en un único entorno de desarrollo integrado.
Team Foundation Server
Team Foundation Server (TFS) es la plataforma de colaboración sobre la que se asienta la solución de administración de ciclo de vida de aplicaciones de Microsoft. TFS automatiza y simplifica el proceso de entrega de software, y proporciona rastreabilidad completa y la posibilidad de comprobar en tiempo real el estado de los proyectos (para todos los miembros del equipo) con potentes herramientas de elaboración de informes y paneles.
Lab Management
Visual Studio 2010 Ultimate ofrece un conjunto completo de características de laboratorio de pruebas, incluido el aprovisionamiento de entornos a partir de plantillas, la configuración y el desmontaje de entornos virtuales y entornos de puntos de comprobación. (Lab Management estará disponible como candidato a la versión comercial como RTM y se distribuirá posteriormente.)
Suscripción a MSDN
Visual Studio 2010 Ultimate con MSDN es la oferta más completa para los desarrolladores. Además de todas las características incluidas en Visual Studio 2010 Professional con MSDN y Visual Studio 2010 Premium con MSDN, Ultimate con
- 28 - | P á g i n a MSDN incluye más horas de uso de Azure, acceso no Visual Studio a Team Foundation Server a través de Teamprise y software de administración de pruebas y laboratorio.
Comprobar el código usando la automatización de IU
Las pruebas automatizadas que controlan la aplicación a través de la interfaz de usuario se conocen como pruebas de IU codificadas (CUIT). Estas pruebas incluyen una comprobación funcional de los controles de la interfaz de usuario. Permiten comprobar si toda la aplicación, incluida la interfaz de usuario, funciona correctamente. Las pruebas de IU codificadas son especialmente útiles donde haya una validación o cualquier otra lógica en la interfaz de usuario, por ejemplo, en una página web. También se suelen usar para automatizar una prueba manual existente.
Como se muestra en la ilustración siguiente, una experiencia típica de desarrollo podría ser aquella donde, inicialmente, el usuario se limite a compilar la aplicación (F5) y a hacer clic en los controles de la interfaz de usuario a fin de comprobar que todo funciona correctamente. Después, se puede decidir crear una prueba codificada de forma que no sea necesario seguir probando la aplicación manualmente. Dependiendo de la funcionalidad concreta que se prueba en la aplicación, se puede escribir código para una prueba funcional o bien una prueba de integración que puede que incluya o no la realización de pruebas en el nivel de interfaz de usuario. Si simplemente se desea tener acceso directamente a alguna lógica de negocios, se puede codificar una prueba unitaria. Sin embargo, en algunas circunstancias, puede ser beneficioso incluir pruebas de los diversos controles de IU en la aplicación. Una prueba de IU codificada puede automatizar el escenario inicial (F5), comprobando que la renovación de código no afecte a la funcionalidad de la aplicación.
- 29 - | P á g i n a Ilustración 3.1. Pruebas durante el desarrollo de la aplicación
3.3. MICROSOFT FOUNDATION CLASSES (MFC)
Dentro de las posibilidades en cuanto a la selección de la interfaz para trabajar en C++, seleccionamos la descrita a continuación, la más ampliamente utilizada en la actualidad y con expectativas de que siga siendo así en el futuro. En este apartado nos referiremos a un conjunto de clases interconectadas por múltiples relaciones de herencia, que proveen un acceso más sencillo a las API de Windows. Fueron introducidas por Microsoft en 1992 y desde entonces fueron apareciendo nuevas versiones con las actualizaciones del entorno de programación Visual C++, gracias a las cuales éste se convierte en un generador de programas C++ para Windows. Tiene una gran complejidad añadida debido a la necesidad de que el programador ahora no sólo debe controlar C/C++, sino que además debe conocer las clases de la MFC para poder utilizar su potencia. Con el paso del tiempo Microsoft Foundation Classes se ha convertido en la implementación estándar de la industria para la creación de aplicaciones gráficas en plataformas PC. A pesar de tener sus limitaciones, su adopción demuestra los beneficios de productividad de la reutilización de marcos comunes para desarrollar aplicaciones gráficas para negocios.
- 30 - | P á g i n a
3.3.1. Características
MFC proporciona C++ para Windows macros de tratamiento de mensajes (a través de mapas de mensajes), las excepciones en tiempo de ejecución e identificación del tipo RTTI, la serialización y la creación de instancias de clases dinámicas. Las macros para manejo de mensajes dirigidos a reducir el consumo de memoria, evitando el uso gratuito de tablas virtuales y también para proporcionar una estructura más concreta para diversos Visual C++ -suministrado herramientas para editar y manipular el código sin necesidad de analizar el lenguaje completo. Las macros de tratamiento de mensajes reemplazado el mecanismo de función virtual proporcionada por el C++.
Usos
El Microsoft Foundation Class (MFC) de la biblioteca ofrece un ejemplo bien conocido de un software eficaz marco. El MFC es una biblioteca de clases C++ que proporciona una interfaz para la programación de Windows y al mismo tiempo encapsula el nivel inferior de la API Win32. Proporciona una gran cantidad de funcionalidades que se encuentran en Aplicaciones de Windows, como la gestión de documentos y la gestión de los distintos puntos de vista sobre los datos del documento, y a su vez proporciona una interfaz orientada a objetos que solucionan las complejas tareas que involucran la comunicación a través redes, el acceso a la base de datos y gestión de documentos compuestos. Las aplicaciones de Windows se construyen mediante la especialización de los componentes que se encuentran en el marco de trabajo de MFC, como la Clases C View y C Document, para cumplir con los requisitos de la aplicación.
3.3.2. Tipos de aplicaciones:
Es posible crear tres tipos de aplicaciones por medio de MFC.
Single-document interface (SDI): cada documento viene asociado con una vista simple, en una única ventana, aunque en ocasiones sería deseable tener la capacidad de cambiar la vista actual del documento por otra nueva. single- document interface (SDI)-
Multiple-document interface (MDI) permite crear aplicaciones en las que sea posible mostrar múltiples documentos simultáneamente, cada uno de ellos en su
- 31 - | P á g i n a propia ventana. A menudo se ofrece un menú con submenús para cambiar entre ventanas y documentos.
Dialog-based: de corta duración, las aplicaciones para tareas simples se pueden implementar en los cuadros de diálogo. Usaremos esta interfaz al ser la más apropiada para el fin que buscamos.
Multiple top-level documents: permite abrir muchas partes del documento, cada una con su propio menú e iconos. También se pueden cerrar individualmente, pero si se selecciona la opción de salir desde el menú principal la aplicación Cierra todas sus partes.
3.4. CREACIÓN DE NUESTRTO PROYECTO
Después de instalarla, abrimos nuestra versión de Microsoft Visual Studio 2010 Ultimate.
En el menú principal seleccionamos File > New > Project
Ilustración 3.2. Nuevo proyecto de Microsoft Visual Studio.
- 32 - | P á g i n a
A continuación: Visual C++ > MFC > MFC Application.Ilustración 3.3. Selección de tipo de aplicación y nombre.
Seleccionamos el nombre del proyecto, sin espacios ni caracteres especiales, así como la carpeta donde queremos localizar el archivo.Ilustración 3.4. Selección de parámetros I.
- 33 - | P á g i n a
A continuación nos aparece una ventana donde se nos indica las características por defecto del proyecto actual. Podemos confirmarlas pulsando “Finish” o bien modificarlas pulsando “Next”. En nuestro caso vamos a modificar algunos de estos parámetros.
Ilustración 3.5. Selección de parámetros II.
Seleccionamos la aplicación de tipo cuadros de diálogo (Application Type >
Dialog based) por los motivos comentados en el apartado 3.3 de este capítulo.
- 34 - | P á g i n a Ilustración 3.6. Selección de parámetros III.
A continuación se nos solicita el estilo que queremos dar al borde externo de la interfaz gráfica donde vamos a ejecutar el código. Además de “Thick frame”,
“System menu” y “About box” que vienen por defecto, añadimos por comodidad “Minimize box” para poder minimar dicha ventana.
Ilustración 3.7. Selección de parámetros IV.
- 35 - | P á g i n a
En esta ventana se nos permite modificar algunas características avanzadas. No será necesario modificar lo que aparece por defecto.
Ilustración 3.8. Selección de parámetros V.
Igualmente, en esta última ventana dejaremos los parámetros que aparecen por defecto.
Ilustración 3.9. Distribución del proyecto.
- 36 - | P á g i n a
3.5. REQUISITOS DEL SISTEMA
Requisitos de software
Visual Studio 2010 puede instalarse en los sistemas operativos siguientes:
Windows XP (x86) con Service Pack 3 – todas las ediciones, excepto Starter Edition Windows Vista (x86 y x64) con Service Pack 1 – todas las ediciones, excepto Starter Edition
Windows 7 (x86 y x64)
Windows Server 2003 (x86 y x64) con Service Pack 2 Windows Server 2003 R2 (x86 y x64)
Windows Server 2008 (x86 y x64) con Service Pack 2 Windows Server 2008 R2 (x64)
Arquitecturas compatibles:
32 bits (x86) 64 bits (x64)
Requisitos de hardware
Equipo con un procesador de al menos 1,6 GHz 1024 MB de RAM
Espacio disponible en disco duro de 3 GB Unidad de disco duro de 5.400 RPM
Tarjeta de vídeo compatible con DirectX 9 con una resolución de 1280 x 1024 o superior
Unidad de DVD-ROM
-Ver más aquí: http://www.identi.li/index.php?topic=178232#sthash.ehn9s0PM.dpuf
- 37 - | P á g i n a
CAPÍTULO 4:
Descripción del
Hardware utilizado
- 38 - | P á g i n a
- 39 - | P á g i n a
4. DESCRIPCIÓN DEL HARDWARE UTILIZADO.
En este capítulo presentaremos las características del Hardware que hemos empleado para llevar a cabo el proyecto descrito en los sucesivos capítulos.
4.1. SICK LMS 200.
4.1.1. Descripción
Dispositivo que permite medir distancias en una ángulo de 180º. Se ha colocado enfrente del robot y se comunica por el puerto serie con la CPU del mismo. Su funcionamiento se basa en un mecanismo de espejo rotatorio, que va dirigiendo un pulso láser. Las medidas se calculan por tiempo de vuelo, en tiempos inferiores a 70ms, y da medidas correctas sobre casi todo tipo de superficies. Más información en:
https://www.mysick.com
Ilustración 4.1. Escáner Sick LMS 200.
4.1.2. Características
Ilustración 4.2. Características Sick LMS 200.
- 40 - | P á g i n a
4.1.3. Funcionamiento
Es muy importante detenerse un momento en este punto para percatarse del error sistemática ( +/- 15 mm) y del error estadístico (+/- 5 mm) de las mediciones proporcionadas por el sensor. Esto ocasionará, si estamos interactuando con objetos pequeños y a distancia pequeña, una fuente de error. Por ello, es posible que, a pesar de ser el código correcto, pueda generarse un comportamiento no deseado. La única solución es emplear un margen de maniobra mayor al previsto inicialmente, o bien alejar el escáner y emplear objetos de mayores dimensiones. Si se quiere verificar la exactitud del código y no perder la cabeza con este error no controlable, se recomiendo comentar en un primer momento las líneas que proporcionan las medidas SDIST [0], SDIST [1] y SDIST [2] y sustituirlo por la distancia real medida manualmente del objeto al origen del sensor. No será necesario modificar en ningún momento los valores de SANG [i], pues los ángulos recogidos no están sometidos a ningún error que se necesario considerar y podrán ser tomados como los valores reales.
Ilustración 4.3. Funcionamiento.
4.1.4. Mecánica / electrónica
El sensor deberá ser alimentado mediante una fuente de tensión externa a 24 V DC y se alimentará a 0,6 A. Sabremos que está perfectamente preparado para la toma de datos cuando únicamente permanezca una luz verde fija en el mismo.
- 41 - | P á g i n a Ilustración 4.4. Mecánica y electrónica del escáner.
4.1.5. Dimensiones
Mostramos en el siguiente esquema cuales son las dimensiones del escáner que estamos empleando:
Ilustración 4.5. Dimensiones y topología del escáner.
- 42 - | P á g i n a
4.1.6. Diagrama de rango de operación
Ilustración 4.6. Rango de operación Sick LMS 200.
4.1.7. Adaptador de puerto serie a USB
Empleamos el siguiente adaptador de puerto serie a USB. En función de en qué puerto sea conectado, será necesario cambiar el nombre del puerto dentro de nuestro código. No hacerlo implicará la imposibilidad de obtener los datos del escáner.
Ilustración 4.7. Adaptador de puerto Serie a USB
- 43 - | P á g i n a Mostramos como ha sido conectado nuestro escáner al PC, si volvemos a conectarlo en el puerto USB mostrado no habrá que modificar el código en ningún punto.
Ilustración 4.8. Adaptador en el puerto COM 5
4.2. ROBOTNIK MODULAR ARM
Para nuestro desarrollo emplearemos el brazo robótico modular de Robotnik cuyas principales características describiremos a continuación.
Ilustración 4.9. Brazo robótico modular.
- 44 - | P á g i n a
4.2.1. Descripción
El Brazo Modular de Robotnik Automation es un brazo sobre la base de los módulos PowerCube Schunk. Estos módulos incluyen engranajes reductores de la velocidad proporcionada por el motor, la etapa de potencia y el controlador, por lo que el brazo resultante no necesita un armario de control externo. En su lugar, la conexión externa del brazo se reduce a sólo 24 VDC y comunicación a través del bus CAN.
4.2.2. Componentes
El brazo empleado dispone de piezas o enlaces independientes que, una vez ensamblados, formarán el conjunto deseado. Mostramos cada una de esas piezas.
Enlace 1:
Ilustración 4.10. Enlace 1 del robot.
- 45 - | P á g i n a
Enlace 2:
Ilustración 4.11. Enlace 2 del robot.
Enlace 3:
Ilustración 4.12. Enlace 3 del robot.
- 46 - | P á g i n a
Enlace 4:
Ilustración 4.13. Enlace 4 del robot.
Enlace 5:
Ilustración 4.14. Enlace 5 del robot.
- 47 - | P á g i n a Además, es posible colocar una pieza que sería considerada enlace 6 en el extremo que será la encargada de interactuar con el entorno, una pinza, una mano robótica, etc.
Mostramos a continuación una tabla resumen con los centros de masa o COM (center of mass) y parámetros de inercia. Los ejes de los motores 1, 4 y 6 están alineados, mientras que los ejes 2,3 y 5 son paralelos.
Ilustración 4.15. Tabla resumen COM y parámetros de inercia.
- 48 - | P á g i n a
4.2.3. Seguridad
El Robotnik Modular Arm es un poderoso robot capaz de moverse a velocidades de alrededor de 1 m/s. Debe concienciarse a toda persona de los principios de seguridad que deben seguirse para trabajar con él:
Es imprescindible mantener el pulsador de parada de emergencia a mano para poder ser empleado en caso de movimiento inesperado del brazo. Es necesario comprobar regularmente que dicho pulsador funciona adecuadamente.
Ilustración 4.16. Seta de emergencia del robot.
No rociar agua o aceite en el robot, caja de operación, o el poder espinal. El contacto con agua o aceite puede causar descargas eléctricas o mal funcionamiento de la unidad.
Confirme que el robot de alimentación está correctamente conectado a tierra antes de usar. Una conexión a tierra insuficiente puede causar descargas eléctricas, fuego, mal funcionamiento o averías.
No intentar desamblar o modificar el robot sin la presencia de personal autorizado.
No utilice la unidad en lugares expuestos a gases inflamables o corrosivos. Gas filtrado acumulado alrededor de la unidad puede provocar un incendio o explosión.
- 49 - | P á g i n a
Instalar el robot en un lugar que pueda soportar su peso y condiciones mientras se ejecuta. Una superficie inestable puede causar que la unidad se caiga, vuelque o averías, lo que podría provocar lesiones al operador.
Conecte el cable de alimentación firmemente a la toma de pared. La inserción incompleta en la toma de corriente hace que la conexión se caliente y puede provocar un incendio.
Compruebe que el enchufe no está cubierto de polvo.
Asegúrese de apagar la fuente de alimentación antes de conectar el cable de alimentación espinal con el robot.
Apague la unidad antes de insertar y extraer cables
4.3. OBJETOS EMPLEADOS
Para el desarrollo del proyecto emplearemos los siguientes 3 objetos.
Prisma de base hexagonal.
Cilindro cortado por un plano inclinado.
Pirámide de base hexagonal.
Todos ellos tienen una base de radio (o apotema) de 5 cm. Esta información será imprescindible a la hora de diseñar el código del que hablaremos en el próximo capítulo.
Ilustración 4.17. Alzado Objeto 1 Ilustración 4.18. Planta Objeto 1
- 50 - | P á g i n a Ilustración 4.19. Alzado Objeto 2. Ilustración 4.20. Planta Objeto 2.
Ilustración 4.21. Alzado Objeto 3. Ilustración 4.22. Planta Objeto 3
Ilustración 4.23. Vista general del escenario de trabajo.
- 51 - | P á g i n a
CAPÍTULO 5:
Desarrollo del
Proyecto
- 52 - | P á g i n a
- 53 - | P á g i n a
5. DESARROLLO DEL PROYECTO
A continuación vamos a explicar paso por paso como hemos desarrollado el actual Proyecto, tratando de ser lo más claro posible a fin de poder ser lo más útil posible de cara a futuros proyectos o trabajos de investigación.
5.1. LIBRERÍAS EMPLEADAS
Como en todo proyecto será necesario emplear una serie de librerías, algunas ya pertenecientes al propio lenguaje de programación e incluidos en Microsoft Visual Studio 2010 Ultimate, otras pertenecientes al propio software del brazo robótico y otras elaboradas por nosotros mismos. Es importante destacar en su definición, especialmente si no se está acostumbrado a trabajar en C++. Las librerías internas a Visual Studio y que no es necesaria añadir al proyecto se definen entre los signos < y >. Las incluidas por el programador en archivos de cabecera locales (.h o header) deben ser incluidas entre “comillas”. Aquí las tenemos:
Ilustración 5.1. Librerías empleadas.
“stdafx.h”: archivos de inclusión para archivos de inclusión estándar del sistema, o archivos de inclusión específicos del proyecto utilizados frecuentemente, pero cambiados rara vez. Aquí estarán definidas a su vez otras librerías, la mayoría internas y ya incluidas en el programa necesarias para su correcto funcionamiento y también otras dos que merecen un tratamiento especial, específicamente de nuestro proyecto y que trataremos independientemente:
#include "m5apiw32.h"
#include "Prueba.h"
"DemoRobotnik2.h" y "DemoRobotnik2Dlg.h": archivos de encabezado del programa y cuadros de diálogo.
- 54 - | P á g i n a
"afxdialogex.h": parte de la librería de Microsoft Foundation Classes C++
(MFC) y que sirve de apoyo a la misma. Al ser parte de MFC no se define con los signos < >. Es posible obtener más información sobre la misma pulsando el botón derecho sobre la misma y abrir el documento:
I
lustración 5.2. Análisis de librerías.
El resto son librerías internas de C++ y no es posible verificar el contenido, simplemente añadirlas y emplear las funciones que aportan. Por ejemlo, la librería stdio.h permite acciones como mostrar en pantalla (printf) o solicitar datos al usuario (scanf); la librería math.h permite realizar operaciones matemáticas de mayor nivel y la librería string.h permite emplear cadenas de caracteres.
5.2. DEFINICIÓN DE VARIABLES
Es necesario definir todas las variables que vamos a emplear. Debido a las innumerables modificaciones realizadas en el código han tenido que ser reescritos en múltiples ocasiones. Más adelante explicaremos el fin de cada una de ellas:
Ilustración 5.3. Definición de variables.
- 55 - | P á g i n a
5.3. OBTENCIÓN DE COORDENADAS DE OBJETOS
5.3.1. Solicitud al usuario
Inicialmente se planteó dar la opción al programa de solicitar al usuario la posición de los objetos para poder realizar los movimientos evitando los obstáculos.
En la función basado en diálogos realizada (“dialog based”) no es posible emplear los comandos printf y scanf para realizar esto (sólo pueden ejecutarse en documentos que muestren los resultados secuencialmente por consola o “single document”) y habría que emplear cuadros de texto (TextBox) para realizar esta petición. No obstante, mostramos la parte del código que ha quedado comentada y en desuso, además de por todo lo anterior, por introducir un proceso lo más automatizado posible.
Ilustración 5.4. Solicitud de datos al usuario.
5.3.2. Recepción de datos del sensor
Como se ha dicho anteriormente, el trabajo y recogida de datos del sensor se ha desarrollado paralelamente en el Proyecto Fin de Carrera de Lidia Sánchez Martínez; no obstante, y al haberse desarrollado de forma paralela y ser imprescindible para el presente proyecto vamos a exponer los apartados clave del mismo.
- 56 - | P á g i n a Para interactuar con el sensor se ha desarrollado un programa tomando como base el proporcionado por SICK. Originalmente este programa estaba orientado a tomar las lecturas y generar un fichero Excel con ellas. Puesto que nuestro objeto era emplear dichos datos para automatizar los movimientos del robot se han prescindido de estas funciones. No las hemos borrado por si pudieran ser de interés de cara a desarrollos futuros. Mostramos un ejemplo:
Ilustración 5.5. Exportar datos a Excel
5.3.2.1. Abrir el puerto de comunicación con el sensor
Lo primero será abrir el puerto serie para comunicarnos con el sensor, en nuestro caso será el COM 5 mediante la función lmsapi_serial_open_port.
Mostramos a continuación una parte de la misma.
Ilustración 5.6. Apertura del puerto serie de comunicación con escáner.
- 57 - | P á g i n a Para ello comprobamos que lo primero que hace es llamar a la función _lmsapi_init_serial. Esta nos dará información sobre el estado del puerto, y en caso de estar cerrado se procederá a abrirlo.
5.3.2.2. Intercambio de datos con el sensor
.De la misma manera que es necesario preguntar para obtener la respuesta a de alguien sobre cualquier situación, es necesario solicitar al sensor los datos que queremos para ser capaces de interpretarlos y obtener la respuesta que buscamos. Para ello, es necesario enviar un código en hexadecimal a través de nuestro programa e interpretar la respuesta obtenida. Los caracteres específicos para establecer esta comunicación se establecen en los manuales proporcionados en la bibliografía y que se adjuntan en el cd de este proyecto. Se envía un datagrama, y cuando este ha sido enviado satisfactoriamente recibe el mensaje de respuesta del sensor en un buffer de recepción.
Ilustración 5.7. Datagrama Sick LMS 200.
Pasamos a describir los parámetros usados en este punto, también comentados en el código para servir de ayuda a la hora de enfrentarse a los varios miles de líneas que han resultado del código.
Connection: Debe ser una conexión abierta a un puerto serial.
Packet: Datagrama a enviar
Len: largo del datagrama a enviar.
Outpacket: Datagrama de respuesta
Outlen: tamaño máximo del datagrama de respuesta.
- 58 - | P á g i n a expected_response: Código de respuesta esperado en la recepción del mensaje.
Si se obtiene un código de respuesta diferente, se interpretará como una respuesta incorrecta.
\return: un entero positivo si el comando fue procesado con éxito, si no entregara un número negativo que indica un error.
La función _lmsapi_read_measurement_data que mostramos a continuación realiza la lectura de medidas del sensor. Para ello será necesario definir el vector raw_data de tipo unit8_t que albergará las mediciones en bruto obtenidas del sensor.
Asimismo definimos el vector packet [20] que tendremos que analizar con calma, pues contendrá no sólo las peticiones al sensor láser, sino también la confirmación de lectura, mediciones y otras variables basura que en principio no serán de interés. Para ello, deberemos analizar detenidamente los manuales adjuntos a la memoria.
La introducción del comando packet[0] = 0x30; será la orden emitida al sensor para que nos proporcione las mediciones.
Ilustración 5.8. Solicitud de datos al escáner.
- 59 - | P á g i n a Ilustración 5.9. Recuperación de datos del escáner.
Como vemos anteriormente, en la línea 1655 se define la variable len, que como define la longitud del datagrama a enviar, y tomará el valor de retorno (siempre un entero) de la función lmsapi_send_command.
Vemos como el valor “retlen” local a la función se transforma posteriormente en la variable “len” definida.
Ilustración 5.10. Recuperar la longitud del datagrama a enviar.
- 60 - | P á g i n a Ilustración 5.11. Mensajes de respuesta equivocada del sensor.
Como vemos, el programa devuelve múltiples mensajes de error en caso de que se detecte alguna anomía en el funcionamiento del mismo. Todo está perfectamente comentado en el código que se encuentre en el cd del presente proyecto, de modo que no profundizaremos más en ese ámbito.
5.3.2.3. Función deteccionobjetos
Nuestro escáner realizará un barrido de 180º y obtendrá para cada uno de ellos (estamos empleando resolución de 1º) la distancia a la que se encuentra el objeto. Sin embargo, de esos 180 datos que obtendremos únicamente nos interesa quedarnos con 3 (la posición de los 3 objetos que vamos a emplear) y desechar el resto. Para ello se hace imprescindible establecer un filtro a partir de la siguiente función.
Para comprender la función es necesario tener en cuenta que i corresponde a la posición angular en grados; data[i] a la distancia en mm del objeto en el ángulo i; j corresponde al número de objetos y k al número de datos recogidos para un mismo objeto (dicho de otra manera, al número de grados que ocupa el objeto).
- 61 - | P á g i n a Ilustración 5.12. Función deteccionobjetos.
En el primer bucle for asignamos una distancia de 8000 mm a todos los objetos que estén a más de 1 m (consiguiendo filtrar tanto la base del robot como el trípode y la cámara de video empleada) y los que estén en una posición angular menor de 70º y mayor de 135º (filtrando también también la estantería y el cable que va al ordenador, cuyas datos tampoco nos interesan a pesar de ser menores de 1m.
En el segundo bucle for vamos haciendo un barrido mientras los objetos estén a 8000 mm (datos basura) y nos detendremos cuando nos encontremos un dato válido (inferior a 1000 mm o podríamos haber definido como distinto a 8000 mm pues sería equivalente). En ese momento vamos acumulando todos los valores de distancias en el vector SDIST [j] y de ángulos en el vector SANG [j].
Para el primer objeto (j=0):
o SDIST [j] = SDIST [0] = SDIST [0] + data (i) o SANG [j] = SANG [0] = SANG [0] + i
- 62 - | P á g i n a
Añadimos una unidad al ángulo i para verificar si el objeto j = 0 también ocupa esta posición. También añadimos una unidad a la variable k, la cual deberá ser inicializada a 0 cada vez que volvamos a ver un dato a 8000 (sólo así podremos reiniciar el contador para ver cuantas posiciones angulares respecto al escáner).
Finalmente, cuando dejemos de observar un data[i] < 1000, esto implicará que ya se han acabado las mediciones que correspondían a ese objeto.
En ese momento, dividimos todo lo acumulado entre el número de mediciones consideradas k. Y obtendremos SDIST[0] y SANG [0] como la distancia y el ángulo a la que se encuentran el primer objeto. Entonces se añadirá una unidad a la variable j y se buscará el siguiente objeto sobre la mesa.
NOTA IMPORTANTE: los datos obtenidos no se corresponden exactamente con el centro geométrico de las figuras al ser una media entre los puntos que ve el sensor, y no tener en cuenta la profundidad de los objetos. Sería necesario, al menos en caso de emplear este mismo escáner, realizar un algoritmo que tuviera en cuenta las dimensiones de cada objeto (no podríamos establecer un código generalista como el que hemos obtenido nosotros), así como identificarlos. Ello se escapa de los objetivos de este proyecto. En cualquier caso, las posiciones obtenidas por este procedimiento serán más que suficientes para nuestro desarrollo.
5.3.3. Datos obtenidos del sensor como punto de partida.
Tras definir la variable j y el número máximo de objetos que tomaremos como 10 (aunque sólo consideraremos 3 objetos sobre la mesa) será necesario definir los vectores SDIT y SANG que guardarán las coordenadas polares de los objetos. También definiremos una estructura de medición que llamaremos “mediciones” en la línea 280.
Se recomienda entrar en estas funciones del código para ver cómo se han creado.
A continuación se llama a la función deteccionobjetos que hemos comentado anteriormente y que está definida más avanzado el código que obtener las medidas deseadas. Es necesario dividir el rango entre 1000, pues las medidas del escáner
- 63 - | P á g i n a vendrán en mm, mientras que en el código de interacción con el robot que trataremos posteriormente estaremos empleando medidas en m.
Ilustración 5.13. Definición de estructura de medición y posición objetos.
´
5.4. TRANSFORMACIÓN DE COORDENADAS
Ya hemos sido capaces de obtener las coordenadas polares de los objetos respecto al sensor. Ahora es momento de referirlas al origen de coordenadas del brazo robótico, al ser este el punto de partida para generar los movimientos de cada una de las articulaciones que nos permitirán generar las trayectorias necesarias para nuestro proyecto. Para ello, hemos seguido los siguientes pasos:
Una vez asignados los valores de Distancia1, Angulo1, Distancia2, Angulo2, Distancia3 y Angulo3 como las coordenadas polares de los 3 objetos respecto al escáner, debemos transformamos las coordenadas polares a cartesianas respecto al mismo origen. Puesto que las funciones trigonométricas son referidas a radianes y nosotros las tenemos en grados, debemos multiplicar nuestros ángulos por pi/180. Olvidar esto implicará un funcionamiento anómalo.
Ilustración 5.14. Obtención de coordenadas cartesianas respecto sensor.
- 64 - | P á g i n a
Sin dejar de trabajar en coordenadas cartesianas, debemos referir dicho origen al origen del brazo robótico. Como podemos ver en la siguiente perspectiva desde el punto de vista del origen de coordenadas del brazo robótico, tanto robot como escáner láser se encuentran alineados. De modo que el eje X será el mismo pero con una rotación de 180º debido a que ambos tienen el eje X positivo hacía su derecha y están uno frente al otro. Por ejemplo, el prisma de base hexagonal de la figura está colocado a X = + 0,268 m respecto al escáner, lo que implicará decir que se encuentra a Xr = - 0,268 m respecto al brazo.
Ilustración 5.15 Escena sensor y objetos.
En cuanto a la coordenada Y, al estar colocados ambos dispositivos perpendiculares entre sí, no tendremos que emplear matrices de rotación para referir ambos orígenes de coordenadas. Dicho eje tendrá la misma orientación;
sin embargo, al estar separados ambos dispositivos una distancia de 1,080 m, deberá restarse dicho valor al proporcionado por el escáner. Siguiendo con el ejemplo del prisma de base hexagonal de la figura anterior, si está situado en una posición Y = + 0,671 m respecto al escáser, ello implicará una posición respecto al robot de Yr = 1,080 – 0,671 = 0,409 m.
Con todo lo anterior, la transformación del sistema de referencia quedará en nuestro programa de la siguiente manera:
- 65 - | P á g i n a Ilustración 5.16. Transformación al sistema de referencia del robot.
5.5. SELECCIÓN DE LA TAREA A REALIZAR
Vamos a diseñar dos posibles trayectorias que deberá seguir nuestro brazo robótico.
Para ello definimos la variable trayectoria, la cual podrá tener dos posibles valores:
a) Trayectoria en zig-zag: en este caso asignaremos a la variable el valor 1. El puntero que hemos atado con cinta americana al extremo del brazo robótico deberá llegar desde la posición inicial a la posición final de mesa evitando los obstáculos que se encuentre generando una trayectoria en forma de zigzag.
Además, en caso de que algunos objetos estén tan cerca que sea físicamente imposible atravesarlos por su punto medio, se generará un mensaje en nuestro programa: “Objetos demasiado juntos. Buscando trayectoria alternativa.” Se considerarán los objetos como si fueran un todo y seguirá la trayectoria en zig- zag.
Ilustración 5.17. Trayectoria zig-zag en situación normal.
- 66 - | P á g i n a Ilustración 5.18. Trayectoria en zig-zag objetos 1 y 2 muy juntos.
Ilustración 5.19. Trayectoria en zig-zag objetos 2 y 3 muy juntos.
b) Trayectoria circular: en este caso el puntero rodeará por completo cada uno de los objetos antes de pasar al siguiente objeto, hasta alcanzar el punto final. Para simplificar el código y el razonamiento no consideraremos aquí el caso de que los objetos estén demasiado juntos.
- 67 - | P á g i n a Ilustración 5.20. Trayectoria circular.
5.5.1. Trayectoria en zig-zag
Como hemos comentado anteriormente, en esta función el robot irá desde una posición inicial variable hasta una posición final dada, evitando todos los objetos que se encuentre.
5.5.1.1. Habilitar la ejecución de esta variante del código
Lo primero será indicar al programa que ejecute esta secuencia, para ello debemos habilitar la línea que nos permitirá entrar posteriormente en ella.
Ilustración 5.21. Selección secuencia trayectoria en zig-zag
5.5.1.2. Planificación de los puntos de paso.
Ahora tendremos que establecer los puntos por los que queremos que pase el robot, para ello debemos tener en cuenta las limitaciones del mismo, así como la forma en que recibimos los datos del escáner.
Vamos a establecer que el robot esquive el primer objeto por la parte más cercana al origen del robot, el segundo por la parte más lejana y nuevamente el tercero
