scieee AI-readable full text Open interactive document viewer

Detección de señales y planificación de trayectorias en un robot móvil

León Muñoz, Juan Manuel

Abstract

El proyecto ha sido realizado con el Rosbot 2.0, robot móvil desarrollado por la empresa Husarion que funciona a través de la programación mediante ROS (Robot Operating System). El dispositivo fue escogido debido a que el departamento cuenta con varios ejemplares recién adquiridos y considero una gran oportunidad el poder familiarizarme mejor con el mundo de la robótica en particular y la programación en general. El objetivo de este robot es educacional, cuenta con múltiples opciones de desarrollo, tiene motores independientes en cada una de las ruedas, un sensor LIDAR, una cámara RGBD además de varios sensores de infrarrojos. Todo ello se incluye para ofrecer la posibilidad de tener una primera toma de contacto con elementos que se usan de manera real en el mundo de la robótica actual. Además, el desarrollo del proyecto es interesante por el creciente uso de robots móviles en la industria actual. El hecho de poder planificar su trayectoria a distancia, mapear entornos de gran superficie, y obtener tanto imagen como video en tiempo real, nos abre un amplio margen de posibilidades. Gracias a todo este interés cada vez es más frecuente la investigación en estos temas y el desarrollo de los mismos. En mi trabajo me he centrado en el uso de la cámara RGBD junto con el sensor LIDAR. La idea principal es la implementación de un sistema detección de señales de tráfico que reaccione ante las mismas. Unido al desarrollo e implementación del mapeado de entornos mediante el LIDAR. Para posteriormente planificar trayectorias específicas en los mismos. Para ello se realizará una presentación del entorno de trabajo, así como una descripción del robot. Seguidamente se presentará la estructura de funcionamiento de ROS. A continuación, se desarrollarán los algoritmos encargados de la detección de señales fundamentada en el nodo “Find_Object”. Para seguir, explicaremos cómo es posible la realización del mapeado de entornos basado en el nodo “Gmapping”. Antes de acabar, será necesario presentar el funcionamiento de la planificación de trayectorias que trabaja a través del nodo “move_base”. Este se encarga de dirigir comandos a la base con el fin de diseñar su trayectoria. El proyecto se fundamentará en la puesta en marcha de todos estos nodos dentro de sus algoritmos particulares, para posteriormente ser capaces de hacer que funcionen todos en consonancia con el fin de alcanzar el objetivo. Con esto se llevará a cabo una familiarización con el entorno de trabajo de ROS. Así como un aprendizaje en el funcionamiento del robot tanto interna como externamente. Para finalizar, se mostrarán los resultados obtenidos con todas estas herramientas para demostrar el correcto funcionamiento de nuestros algoritmos. Seguidamente se ofrecerá una visión general del proyecto mediante las conclusiones a las que he llegado después de realizarlo. Como elementos extra se añadirán dos anexos, un manual de usuario y una librería con todos los códigos empleados explicados línea a línea.

Full text

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías Industriales Detección de señales y planificación de trayectorias en un robot móvil Autor: Juan Manuel León Muñoz Tutor: José Ramón Domínguez Frejo Tutor Externo: Ramón Andrés García Rodríguez Dpto. Teoría de Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 iii Proyecto Fin de Carrera Ingeniería de las Tecnologías Industriales Detección de señales y planificación de trayectorias en un robot móvil Autor: Juan Manuel León Muñoz Tutor: José Ramón Domínguez Frejo Tutor Externo: Ramón Andrés García Rodríguez Dpto. de Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 v Proyecto Fin de Carrera: Detección de señales y planificación de trayectorias en un robot móvil Autor: Juan Manuel León Muñoz Tutor: Tutor Externo: José Ramón Domínguez Frejo Ramón Andrés García Rodríguez El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2021 El Secretario del Tribunal vii A mis padres Manuel y Rosario A mis hermanos Curro y Jaime A mis eternos compañeros Paco y Oscar A mis educadores y maestros A Carolina ix Agradecimientos Sirvan estas líneas para agradecer a todos aquellos que me han ayudado a hacer posible terminar esta gran carrera. En primer lugar, como no podía ser de otra forma agradezco a mis padres Manuel y Rosario todo el apoyo, la motivación, la confianza y la sabiduría que durante estos años no han dejado de confiarme ni un momento. A mi hermano Curro gran artífice de este logro, gracias por marcar el camino como buen hermano mayor que siempre has sido. A mi hermano Jaime por hacer más livianas las duras tardes de estudio con tu simpatía y tu música. También es de agradecer el incondicional soporte que ha supuesto una persona tan especial como Carolina durante estos años, solo ha tenido palabras buenas y motivadoras hacia mí, forzándome siempre a dar el máximo y seguir peleando por lograr mis metas. Imposible no acordarme ahora de mis compañeros de carrera Paco y Oscar, siempre fueron los que me soportaron en los peores días. Entre los 3 hemos formado un equipo en el que siempre confiábamos ante cualquier adversidad. Nunca dejamos de creer en nosotros mismos y siempre estuvimos ahí los unos para los otros, sin importar el momento o las circunstancias. Gracias de veras porque sin vosotros todo esto nunca hubiera sido posible. Gracias a la Universidad de Sevilla y en especial al Departamento de Automática por prestarme el material necesario para desarrollar el proyecto sin el cual nada de esto hubiera sido posible. Por último, me gustaría agradecer la labor realizada por tantos y tantos profesores de la escuela que durante este tiempo me han transmitido conocimientos e ilusión a partes iguales, me siento eternamente en deuda por ayudarme a ser la persona que soy ahora mismo, consciente del mundo que me rodea y un poco más conocedor de cómo se desarrolla todo en esta vida. Juan Manuel León Muñoz Alumno de la Escuela Técnica Superior de Ingeniería de la Universidad de Sevilla Sevilla, 2021 xvii ÍNDICE DE FIGURAS Figura 2-1. Ejemplo de visión artificial 5 Figura 2-2. Ejemplo de etección de objetos en la función find_object 7 Figura 2-3 Nube de puntos generada por Lidar 8 Figura 2-4 Ejemplo de localización de identificadores en un robot móvil 10 Figura 3-1 Perspectivas del ROSbot2.0 11 Figura 3-2 Vista lateral y posicionamiento de dispositivos en el ROSBot2.0 12 Figura 3-3 Controlador de tiempo real core2 13 Figura 3-4 Logo Ubuntu 18.04 13 Figura 3-5 Logo ROS Melodic Morenia 13 Figura 3-6 Logo Husarion 14 Figura 3-7 Logo Comunidad ROS 14 Figura 4-1 Estructura básica de funcionamiento de ROS 15 Figura 4-2 Esquema de funcionamiento del protocolo Client-Server 16 Figura 4-3 Distribución de ficheros en el “workspace” 16 Figura 4-4 Distribución de archivos en el sistema ROS 17 Figura 4-5 Ejemplo del programa Find Object 2d 18 Figura 4-6 Logo Programa Rviz 18 Figura 4-7 Ejemplo funcionamiento Rviz 19 Figura 4-8 Ejemplo funcionamiento RQT Graph 19 Figura 4-9 distribución fichero espacio de trabajo 22 Figura 4-10 ejemplo funcionamiento ROS 23 Figura 4-11 detección de la señal IP 24 Figura 4-12 ejemplo conexión remota ROS 24 Figura 5-1 Ejemplo propio funcionamiento Find Object 27 Figura 5-2 ejemplo captura de imagen en Find Object 27 Figura 5-3 Detección de puntos característicos de una imagen 28 Figura 5-4 Detección de una imagen por parte del programa 28 Figura 5-5 Señal de giro a la derecha usado 30 Figura 5-6 Señal giro a la derecha no recomendada 30 Figura 5-7 ejemplo fichero almacenamiento de imágenes a comparar 31 Figura 5-8 ejemplo detección de imagen 31 Figura 5-9 Ejemplo filtro de Lowe 32 Figura 5-10 Señal Recto utilizada 34 Figura 5-11 Señal giro a la derecha utilizada 34 Figura 5-12. Señal giro izquierda utilizada 34 Figura 5-13 Señal STOP utilizada 35 Figura 5-14 Señal 120 utilizada 35 Figura 5-15 Señal 50 utilizada 35 Figura 5-16 Señal 90 utilizada 36 Figura 6-1 Ejemplo mapeado SLAM en Rviz 37 Figura 6-2 Ejemplo Display TF en RViz 37 Figura 6-3 Ejemplo mapeado salón 40 Figura 6-4 ejemplo mapeado casa 40 Figura 6-5 Ejemplo mapa.pgm 41 Figura 6-6 ejemplo mapeado planificación de trayectorias 43 Figura 6-7 ejemplo mapeado planificación de trayectorias 44 Figura 6-8 esquema funcionamiento nodo “move_base” 45 Figura 6-9 gráfica de asignación de valores para cada elemento de la matriz 46 Figura 6-10 visión de la cámara en un momento preciso 49 Figura 6-11 mapeado de obstáculos en 3 dimensiones 49 Figura 6-12 ejemplo mapeado entorno desconocido 50 Figura 6-13 ejemplo de funcionamiento del nodo “explore_lite” 52 Figura 7-1 Puntos clave de la señal de 120 53 Figura 7-2 Puntos clave señal de STOP 53 Figura 7-3 Puntos clave señal giro izquierda 54 Figura 7-4 Puntos clave señal recto 54 Figura 7-5 Reconocimiento de objetos mediante el tópico Objects 54 Figura 7-6 Reconocimiento de objetos mediante el tópico Objects 55 Figura 7-7 Primera distancia de reconocimiento 55 Figura 7-8 Reconocimiento en el programa find object 2d 55 Figura 7-9 Segunda distancia de reconocimiento 56 Figura 7-10 Reconocimiento en el programa find object 56 Figura 7-11 tercera distancia de reconocimiento 56 Figura 7-12 Reconocimiento en el programa Find object 56 Figura 7-13 Aspecto del entorno a mapear 59 Figura 7-14 Resultado del mapeo en Rviz 59 Figura 7-15 resultado del mapeo de una casa en Rviz 60 Figura 7-16 circuito elaborado en los laboratorios 61 Figura 7-17 Mapeo del circuito tras vuelta de reconocimiento. 62 Figura 7-18 Entorno para mapear mediante visión 63 Figura 7-19 resultado del mapeado con visión en Rviz 64 Figura 7-20 Resultado del mapeado con visión en Rviz 64 Figura 7-21 entorno para planificación de trayectorias 65 Figura 7-22 Resultado del mapa de coste en Rviz 66 Figura 8-1 Error en el mapeado 70 xix Índice de videos Video 7-1 Reacción de robot tras la visión 57 Video 7-2 Reacción del robot tras la visión 57 Video 7-3 Reacción del robot tras la detección 58 Video 7-4 ejemplo de planificación de trayectorias 67 Video 7-5 Ejemplo de planificación de trayectorias. 67 xxi Notación c.t.p. En casi todos los puntos c.q.d. Como queríamos demostrar e.o.c. En cualquier otro caso e número e : Tal que L W H V L (x,y, σ) D (x,y, σ) X Y σ H (x, σ) Lxx= (x, σ) Length Width Height Voltios Valor de cada punto en la matriz de la figura Valor de la diferencia gaussiana Valor en el eje de abcisas Valor en el eje de ordenadas Valor relativo a la orientación del punto Matriz Hessiana Producto de convolución de segundo orden derivativo xxiii Glosario ROS Robot Operating System LIDAR Laser Imaging Detection and Ranging CV Computer Vision SIFT Scale Invariant Feature Transformation SURF Speed Up Robust Feature ORB Oriented FAST and Rotated BRIEF FAST Features Accelerated Scaner Test BRIEF Binary Robust Independent Elementary Features PC Personal Computer RGBD Red Green Blue and distance SLAM Simultaneous Location and mapping SVM Support Vector Machine GPS Global Positioning System SBC Asus Tinker Board SSH Secure Shell DWA Dynamic Window Approach xxv Nociones básicas sobre visión artificial mapeado y planificación de trayectoria 6 Particularmente, en el entorno de ROS la visión artificial será desarrollada en su mayor parte por la función Find_object_2d, esta puede utilizar 3 algoritmos de implementación diferentes de la mano de la biblioteca de códigos de OpenCV, todo ello contribuirá a que una cámara cualquiera sea capaz de detectar un objeto y publicarlo dentro de un tópico de ROS. Básicamente nuestra función se basa en dos pilares. Por un lado, la detección de puntos clave, aquellos capaces de captar los elementos más representativos de la imagen para poder ser comparados luego. Por otro lado, tenemos los descriptores. Estos se encargan de definir la orientación de la imagen, la rotación, la escala en la que se encuentra y su distancia al objetivo. A continuación, se desarrollarán en profundidad los 3 algoritmos básicos que se utilizan en la visión artificial: • Scale Invariant Feature Transformation (SIFT): desarrollada por Lowe en 2004 [3] se utiliza para extraer características relevantes de las imágenes en cuanto a la cantidad de información de su entorno. Como la existencia de bordes o texturas. La mayoría de los algoritmos de visión se basan en la detección de esquinas. Estos son invariantes ante las rotaciones, es decir, que si la imagen es sometida a giros pueden encontrarse los mismos puntos. Sin embargo, no funcionan de igual manera ante el escalado de imágenes. Este problema se soluciona con este nuevo algoritmo que se mantiene invariante ante la escala. Su desarrollo se fundamenta en el filtro de la diferencia gaussiana. Este funciona de la siguiente manera: En esta fórmula, se trata de buscar puntos de L (matriz de cada imagen) en los que no varía la rotación. Para ello, se modifica el valor de sigma (parámetro descriptor de la orientación) y se seleccionan los puntos que obtengan un menor valor al realizar esta diferencia. Como se ha mencionado antes, este filtro de gauss se ejecuta para la detección de bordes, realiza dos desenfoques en la imagen con diferentes radios y sustrae las dos versiones para obtener un resultado final. Se considera bastante rápido porque puede aplicarse mediante diferentes métodos. Los parámetros a definir para el mismo son los radios de desenfoque utilizados. El segundo paso trata de localizar una serie de puntos clave que son refinados mediante un filtro eliminando aquellos que tengan un bajo contraste. En tercer lugar, el algoritmo es capaz de establecer la orientación de dichos puntos clave a través de la graduación de la imagen local. Por último, cuenta con un generador que computa la posición de cada punto clave en la imagen local basado en su graduación y orientación. • Speed Up Robust Feature (SURF): desarrollado por Herbert Bay en 2006 [27]. Este algoritmo es una variación de SIFT ya que fue desarrollado a partir del primero. En este caso la determinación de la escala se realiza mediante una serie de cajones filtrantes (box filters) en lugar de usar la diferencia gaussiana. Este algoritmo es capaz de obtener una representación visual de la imagen y extraer información detallada del contenido. Además, esto permite el uso en diferentes escalas al mismo tiempo. Empleando un método conocido como la pirámide. El algoritmo utiliza un detector BLOB que se basa en la matriz hessiana para la determinación de puntos de interés. Esta puede definirse de la siguiente forma: 7 Detección de señales y planificación de trayectorias en un robot móvil Donde es la convolución del segundo orden derivativo con la imagen en el punto x, y de manera similar para Para la orientación usa un sistema de respuesta de ondículas que es un tipo especial de transformada matemática que representa una señal dilatada de una onda finita, tanto en vertical como en horizontal. Para la detección de imágenes SURF utiliza también la respuesta de ondículas, que captura los puntos que rodean a aquellos que son clave, dividiéndolos en subregiones donde se toma la ondícula y posteriormente es representada para obtener la función descriptora del algoritmo. Se usa también para la detección el signo del laplaciano, para resaltar los puntos de interés, ya que es capaz de distinguir aquellos con más brillo dentro de fondos oscuros. En caso de coincidencia de características, solo se compararán imágenes si cuentan con el mismo tipo de contraste (basado en el signo laplaciano) lo que permite una detección más rápida. • Oriented FAST and Rotated BRIEF (ORB): desarrollado por Ethan Rublee en 2011 [26] esta técnica mezcla el algoritmo FAST (Features Accelerated Segment Test) junto con el BRIEF (Binary Robust Independent Elementary Features). El algoritmo FAST se centra en la detección de puntos mientras que BRIEF es un descriptor de estos. FAST no detecta la orientación ni la rotación de la imagen, sino que, calcula la intensidad de parches con una esquina ubicada en el centro del objeto. Posteriormente, calcula la dirección del vector que une el centro de la imagen con el centro del parche estudiado. Dándonos así la orientación del mismo. Por otro lado, el descriptor BRIEF, actúa pobremente si se produce una rotación en el plano, por tanto, las matrices de rotación se calculan utilizando la orientación hallada mediante FAST y luego son los descriptores BRIEF los que se dirigen conforme a esta. El algoritmo FAST, dado un píxel de una matriz, compara su brillo con el de los 16 píxeles circundantes que se encuentran en un círculo pequeño alrededor del píxel original. Estos se clasifican en tres clases (más claros, más oscuros o similares) si más de ocho píxeles son más claros u oscuros se selecciona como punto clave. Siendo así posible la detección de bordes de una imagen. Posteriormente, BRIEF toma todos los puntos clave encontrados y los convierte en un vector de características binarias para que juntos puedan representar un objeto. Es por ello que dicho vector también se conoce como descriptor de características. En nuestro caso, la función “Find_Object_2d” utiliza el algoritmo SIFT descrito previamente tanto para la extracción de puntos clave como para la de descriptores. La función para extraer ambos se toma de la biblioteca de OpenCV. Posteriormente se buscan coincidencias de dichos puntos con los 2 puntos vecinos que se encuentren más cerca de la imagen a comparar. Este proceso se realiza mediante el algoritmo ORB explicado con anterioridad. Se comparan los descriptores y puntos clave de los vecinos de la imagen propuesta con los originales de la imagen guardada. Con el fin de establecer una homografía o detección de coincidencia, además se muestra el número de elementos comunes de ambos. Por último, si hay coincidencia se configura una manera de mostrarla gráficamente que en nuestro caso es un rectángulo que rodea la imagen como se muestra en la figura 2.2. Nociones básicas sobre visión artificial mapeado y planificación de trayectoria 8 Figura 2-2 ejemplo de detección de objetos en la función “Find_Object” (Fuente: [3]) 2.2 Mapeado de entornos El mapeado de un entorno consiste en la realización de un mapa en 2 dimensiones donde se introduzcan los distintos obstáculos que se hayan encontrado recorriéndolo. Todo ello suele realizarse de múltiples formas como por ejemplo mediante el uso de un sensor LIDAR. Este es un dispositivo que emite un láser constantemente a su alrededor siendo capaz de recibirlo de nuevo pasado un tiempo. Debido al retraso entre la emisión de la señal y la recogida de la misma, se determina la distancia desde el dispositivo emisor al objeto en cuestión. Realizando el mismo procedimiento de manera repetida somos capaces de modelar un mapa completo de un determinado espacio. Particularizando su funcionamiento, el objetivo es la creación de una nube de puntos como la mostrada en la figura 2-3, que representa los objetos que hay a su alrededor. Para conocer las coordenadas de la propia nube de puntos debemos conocer la posición del sensor dentro de la misma por lo que también debería incluirse un sistema GPS integrado. Según el tipo de laser que se integre en el LIDAR este puede ser de varios tipos: • LIDAR de pulsos: el mapeado se realiza midiendo el retraso entre una señal emitida y su posterior recepción tras impactar en un objeto o superficie del entorno. • LIDAR de medición de fase: en este se emite un láser continuo, cuando se recibe la señal reflejada se mide la diferencia de fase entre la emitida y la de llegada. 9 Detección de señales y planificación de trayectorias en un robot móvil Figura 2-3 nube de puntos generada por LIDAR (Fuente: [4]) 2.2.1 Fundamentos del nodo “RPLidar” En particular, para nuestro proyecto, el paquete que da soporte al sensor LIDAR y nos muestra sus detecciones de manera gráfica es el “RPlidar” de ROS. Este da soporte tanto a los RPLIDAR A1 como a los A2 y A3. En nuestro caso, trabajaremos con el RPLIDAR A2. Este es un sensor de bajo coste utilizado para robots que trabajen en zonas de interior y cuya función sea la de la navegación SLAM que se explicará posteriormente en el proyecto. El procesamiento de imagen es bastante rápido y es tratado mediante un paquete desarrollado por RoboPeak. Un equipo de investigación y desarrollo de plataformas robóticas fundado en 2009 y conformado por ingenieros de software, electrónicos y expertos en redes. Por tanto, se considera ideal para el mapeado de entornos locales, ya sean casas o habitaciones, así como pequeños espacios cubiertos. El principal nodo usado para su desarrollo será el “RPlidarNode” que toma los resultados directamente del LIDAR en crudo, para posteriormente convertirlos al formato de ROS como mensaje del tipo “LaserScan” que pueden ser interpretado por el sistema. Posteriormente estos mensajes son publicados en el tópico “scan”. 2.2.2 Fundamentos del nodo “gmapping” La traslación de los datos publicados en este tópico al mapa es llevada a cabo mediante un nodo llamado “slam_gmapping” creado por Brian Gerkey, este es el encargado de crear un mapa de ocupación de celdas en 2 dimensiones a través de la información provista por el sensor en primera instancia. El funcionamiento del nodo se fundamenta en el “GMapping” que se centra en el uso de un filtro de partículas Rao-Blackwellized que realiza una marginación de la distribución de la probabilidad de su espacio de estado. Este se considera un medio eficaz para solventar el problema del mapeo SLAM. El filtro utiliza una serie de partículas en las que cada una cuenta con un mapa individual y propio del entorno, por tanto, se considera algo muy importante reducir el número de partículas que se presentan. Para ello se propone un enfoque que calcula la distribución de una propuesta en concreto teniendo en cuenta no solo el movimiento del robot sino también sus observaciones más recientes. Nociones básicas sobre visión artificial mapeado y planificación de trayectoria 10 Este hecho aclara la posición del dispositivo en cada momento. Además, el algoritmo es capaz de seleccionar aquellas áreas que quedan peor definidas y escogerlas para volver a realizar un muestreo posterior con el fin de completar la información faltante. Esto reduce el número de partículas necesarias para el mapeo y por tanto reduce el problema del exceso de información. 2.2.3 Fundamentos del nodo “tf” Para la obtención de la posición del dispositivo en cada momento en nuestro proyecto, vamos a basarnos en el nodo “Tf”. Creado por el equipo Tully Foote de la biblioteca de ROS. Este, nos permite hacer un seguimiento de una serie de marcos coordinados a través del tiempo. Su funcionamiento se basa en la en la transformación de diferentes puntos o vectores entre cualquiera de los marcos coordinados en cualquier momento del tiempo. Esto nos da la posibilidad no solo de saber la posición del dispositivo en cada momento, sino que también nos permite de manera más exacta hacer un seguimiento de cualquier parte de nuestro robot. Si contamos con un brazo robótico, por ejemplo, podremos saber dónde se encuentra la base, la articulación 1, la pinza final … como se muestra en la figura 2-4. En nuestro caso el nodo “tf” irá asociado a la base del robot ya que no cuenta con numerosas piezas que puedan ser interesantes de cara a un seguimiento. Como se ha explicado previamente el nodo no solo guarda la información de la posición actual, sino que también provee la localización del mismo en instantes anteriores. Además, es capaz de coordinarse con los marcos del propio mapa y situar el dispositivo dentro del mismo. Como bien hemos dicho, el funcionamiento del nodo se basa en los marcos. Estos, se definen como sistemas coordinados, en ROS siempre se representan en 3 dimensiones. Por tanto, el nodo, lo que estudia es la posición de una serie de puntos con 3 coordenadas dentro de un marco. La relación de posición de los distintos marcos se realiza mediante una matriz que representa 6 grados de libertad. Es decir, una traslación seguida de una rotación. La traslación la representa un vector de 3 coordenadas cada una identificada con un eje del espacio, mientras que la rotación es definida mediante una matriz. Con este sistema el nodo registra por completo el movimiento que realiza un dispositivo desde un marco al siguiente. Guardando así tanto la información relativa al proceso de traslación, como aquella referida a la rotación del mismo. Para el uso de toda esta información previamente descrita, el nodo “tf” está encargado de publicar tanto la matriz de rotación como el vector de traslación en el tópico “pose”. Esta se publica en forma de mensaje geométrico provisto por el nodo “geometry_msgs” desarrollado por Tully Foote. Lo que nos permite adaptar tanto la matriz como el vector a un formato utilizable por ROS para su adaptación y desarrollo. 11 Detección de señales y planificación de trayectorias en un robot móvil Figura 2-4 ejemplo de localización de identificadores en un robot móvil (Fuente [6]) Nociones básicas sobre visión artificial mapeado y planificación de trayectoria 12 2.3 Planificación de trayectorias En este apartado procederemos a desarrollar el fundamento en el cual se basa la planificación de trayectorias dentro de nuestro proyecto. Entendiendo la planificación como la capacidad de un dispositivo de trasladarse desde una posición de origen hasta otra de destino sin colisionar con ningún obstáculo y siendo capaz de diseñar la trayectoria más eficiente posible a través de un mapa. La mayor parte del desarrollo de la planificación de trayectorias dentro de un robot móvil se centra en la búsqueda y obtención de estrategias de control automático. Con el fin de que el dispositivo sea capaz de elaborar rutas adecuadas y seguras. Es decir, sin colisionar con nada y lo más eficientes posibles dentro de las posibilidades de desplazamiento de nuestro dispositivo. Por tanto, para poder llevar a cabo una correcta planificación, es indispensable el conocimiento total del modelo cinemático y dinámico del dispositivo. Con ello seremos conocedores de las limitaciones a las que se enfrenta y cuáles son sus posibilidades de uso. Ya que, solo serán realizables aquellos movimientos que puedan ser efectuados por el móvil sin llevarlo a posiciones límite. La planificación de trayectorias se basa en dos elementos, el primero de ellos es la traslación del robot a la posición idónea para la posterior manipulación. Es decir, en un brazo robótico significaría el desplazamiento de las principales articulaciones hasta la posición en la que la pinza o elemento final sea capaz de alcanzar la posición deseada. El segundo se corresponde con el control de cada uno de los movimientos descritos en el primer fundamento. Con el fin de que el efector final alcance la posición deseada sin sufrir ningún percance en el proceso. En nuestro caso, la planificación de trayectorias es llevada a cabo en su gran mayoría por el nodo “move_base” de ROS. Creado por Eitan Marder en 2009. 2.3.1 Fundamentos del nodo “move_base” Este Nodo provee una implementación de una acción que dada una posición de destino en el mundo tratará de alcanzarla desplazando hasta ella la propia base móvil. Para ello, el nodo funciona de manera conjunta con un planificador a nivel local, y otro a nivel global. Además, es capaz de trabajar con los mapas de obstáculos que previamente han sido creados durante el mapeado de entornos. Dentro de estos mapas se diferencia también la existencia de uno a nivel local, que se refiere a aquello que el dispositivo percibe en el momento exacto donde se estudia, y otro a nivel global que es el elaborado recorriendo la totalidad del mundo en el que se mueve nuestro robot. Su código y funcionamiento particular se explicará de manera más detallada en el apartado correspondiente de planificación de trayectorias. Aun así, el concepto básico de este nodo es que hace funcionar a la vez una serie de procesos como la rotación, la traslación y los giros; que siempre deben mostrar si están disponibles o no, es decir, si se encuentra algún obstáculo bloqueando alguno de estos movimientos. Cuando estos procesos se encuentran disponibles, se le pasa la información al proceso central de navegación. Este es capaz de tomar decisiones y aplicar cada uno de los procesos que corresponde para acercarse cada vez más a la posición final deseada. Si ninguno de los mismos se encuentra disponible, se produce un reset de la trayectoria y se vuelve sobre su propio camino hasta ser capaz de diseñar una alternativa. Este proceso central de navegación es regulado por el nodo “nav_core”, que se desarrollará en el apartado de planificación. Es el encargado de proveer una interfaz para la navegación específica del dispositivo. Ofrece un planificador tanto a nivel global como a nivel local. A nivel global, el nodo se fundamenta en los siguientes algoritmos: • “Global_Planner” planificador de trayectorias global, rápido y flexible basado en la interpolación. • “Navfn” planificador de trayectorias basado en celdas que utiliza la navegación para diseñar una trayectoria específica. • “Carrot_Planner” planificador simple que dado un punto específico trata de desplazar al robot lo más cerca posible incluso si se trata de un obstáculo. 13 Detección de señales y planificación de trayectorias en un robot móvil A nivel local, el nodo se fundamenta en los siguientes algoritmos: • “Base_Local_Planner” provee la implementación del Dynamic Window Approach (DWA) [28]. Método empleado en la evitación de obstáculos a partir de la búsqueda de un entorno seguro y la elección de la solución óptima en dicho espacio. • “DWA_Local_Planner” implementación del método DWA mucho más fácil y limpia. Es más flexible y sus ejes son variables. Cabe decir, que este nodo funciona solo ante obstáculos fijos. Es decir, aquellos que son móviles se consideran imposibles de esquivar por nuestro dispositivo. Además, es reseñable que puede ser capaz de detectar que posiciones son alcanzables y cuáles no, cuando va a comenzar a moverse reconoce su entorno local y si no encuentra salida por dos veces declara inalcanzable el objetivo 15 3 DESCRIPCIÓN DEL ROBOT En este capítulo voy a presentar el robot con el que la mayoría del trabajo ha sido desarrollado. Este es el modelo ROSbot 2.0, desarrollado por la empresa Husarion e impulsado mediante la plataforma de programación ROS. A continuación, se realizará un análisis de los distintos componentes que forman parte del dispositivo tanto a nivel de hardware como a nivel de software. 3.1 Descripción del Hardware El Rosbot 2.0 es un robot móvil 4x4 con conducción autónoma, cuenta con 4 ruedas independientes con un motor en cada una de ellas, un sensor LIDAR, una cámara Astra RGBD y varios sensores de distancia, velocidad y orientación, además de contar con una autonomía de 3 horas con su batería. Sus medidas básicas contando con la cámara y el LIDAR son 200x235x220mm [L x W x H]. Su peso total es de 2.84 kg. El cuerpo está compuesto por una placa de aluminio de 1.5mm de grosor, y se mueve a una velocidad máxima de 1m/s de manera lineal y a una velocidad radial máxima de 420 ë/s de manera rotacional. Figura 3-1 perspectivas del ROSbot2.0 (Fuente: [1]) A continuación, se realizará una descripción específica de cada uno de los componentes de nuestro robot de manera más específica: • 4 sensores infrarrojos de distancia modelo VL53L0X con un rango de funcionamiento que alcanza más allá de los 200cm. • Un controlador de tiempo real modelo CORE2 basado en el microcontrolador STM32F407. • 4 motores Xinhe XH-25D con 6V DC y una velocidad máxima de giro de 5000rpm. • Un sensor IMU que sirve como acelerómetro, giroscopio y velocímetro que funciona para los 9 ejes en los que se desplaza el robot. • 3 baterías recargables de 3500mAh de capacidad con un voltaje nominal de 3.7V estas pueden ser fácilmente sustituibles por unas del mismo tipo. • Una antena conectada directamente al módulo ASUS Tinker Board del wifi y unida mediante un cable específico al SBC. • Un SBC del tipo ASUS Tinker Board con 2GB de RAM , 4x1.80 Ghz y 32Gb de memoria en una micro SD, este utiliza el sistema operativo Ubuntu customizado para el uso de ROS. ROS. Estructura y Funcionamiento 22 4.2 Herramientas utilizadas en el entorno de ROS Como bien se ha descrito con anterioridad el framework de ROS es muy amplio y pone a nuestra disposición numerosas herramientas de gran utilidad para el desarrollo de trabajos. En este apartado, remarcaremos aquellas más importantes y sobre todo las utilizadas para nuestro proyecto particular. 4.2.1 Find Object 2D Este programa como su propio nombre indica es el empleado para la detección de imágenes en dos dimensiones directamente desde la cámara instalada en nuestro robot. La herramienta necesita una breve configuración inicial donde se le aclara a qué tópicos suscribirse para recibir información en tiempo real de la cámara. Su funcionamiento se muestra en la figura 4-5. Una vez configurado pone a nuestra disposición los servicios de detección de imágenes realizados mediante elementos de referencia dentro cada objeto. Para su correcto uso se deben desarrollar dos fases diferentes: • Aprendizaje: en esta parte será necesaria la muestra de la señal de forma repetida frente a la cámara tratando siempre de encontrar la posición en la que sea capaz de tomar más elementos de referencia, una vez hecho esto capturaremos la imagen y se almacenará en un repositorio local. • Reconocimiento: esta segunda parte no muestra obligatoriamente la cámara por pantalla, sino que simplemente comienza a detectar las imágenes previamente incorporadas y muestra por pantalla el identificador que anteriormente se le ha asignado a cada imagen en la parte de aprendizaje. Figura 4-5 Ejemplo del programa Find Object 2d (Fuente: [12 ]) 4.2.2 Rviz Este programa nos muestra por pantalla información en tiempo real aportada por el robot, se utiliza principalmente para el mapeado de entornos y la posterior detección de obstáculos, su funcionamiento se basa en las distintas “Displays” que pueden ser añadidas de manera manual según aquello que nos interese plasmar. Figura 4-6 Logo Programa Rviz (Fuente: [13 ]) 23 Detección de señales y planificación de trayectorias en un robot móvil En nuestro caso funcionaremos principalmente con los siguientes “displays”: “Tf” que se encarga de transformar la posición real del robot en datos para ubicarlo en el mapa en tiempo real. “LaserScan” que se encarga de tomar la información provista por el LIDAR para plasmarlo en el programa en forma de obstáculos y límites del entorno. “MAP” que muestra el desarrollo del mapa a tiempo real a medida que avanza el escaneo y “POSE” que realiza una aproximación de la trayectoria seguida por el robot en el entorno. Figura 4-7 ejemplo funcionamiento Rviz (Fuente: [12 ]) Como se observa en la imagen 4-7, el sistema nos permite una vez creado el mapa un desplazamiento por el mismo desde una posición inicial que siempre debe guardarse hasta otra de destino que puede elegirse arbitrariamente. El propio programa ya detecta como obstáculos todo aquello con lo que pueda colisionar y es capaz de crear una trayectoria evitando estos elementos. Aunque posteriormente se desarrollará el tema en profundidad, resulta interesante el hecho de que en nuestro robot, el LIDAR encargado de la detección de obstáculos y el mapeo se encuentra a una cierta altura. Es por ello por lo que devuelve ciertos errores al detectar la parte de debajo de sofás o mesas bajas. Esto podría solucionarse mediante el uso de infrarrojos o la propia cámara, pero se escapa a los objetivos del proyecto 4.2.3 RQT_graph Esta herramienta nos ayuda a apreciar de manera más gráfica y sencilla la cantidad de nodos que se encuentran activos y la suscripción o publicación en los mismos mediante los tópicos entre ellos. Resulta bastante útil a la hora de comprobar y cerciorarse de un correcto funcionamiento del sistema, ya que, con un simple vistazo somos capaces de detectar si hay alguna suscripción errónea, o si se nos ha olvidado iniciar algún nodo. Figura 4-8 ejemplo funcionamiento RQT Graph (Fuente: [13 ]) ROS. Estructura y Funcionamiento 24 4.3 ROSbot2.0 en ROS En este apartado procederemos a explicar el trabajo previo y los primeros pasos para poder trabajar con el robot mediante ROS. Comenzaremos explicando la creación del espacio de trabajo para seguir con la inicialización de paquetes, nodos como archivos c++ y por último la incorporación de archivos launch. Cabe destacar que en esta sección se describirán los pasos a seguir de manera no técnica quedando esta explicada en el anexo posterior donde se añaden las líneas de código específico para realizar cada función, 4.3.1 Configuración del espacio de trabajo Para poder trabajar con ROS y nuestro robot necesitaremos configurar un repositorio local dentro de nuestro dispositivo con el único fin de almacenar todos nuestros archivos, librerías, nodos y paquetes que posteriormente serán compilados. Crearemos por tanto una carpeta llamada “ros_workspace” y dentro de la misma añadiremos un fichero más llamado” src”. Posteriormente, necesitaremos inicializar nuestro espacio por lo que nos moveremos a la carpeta “src” recién creada y ejecutaremos la orden “catkin_init_workspace”. Tras esto nos dirigiremos a la carpeta “ros_workspace”, donde deberemos ejecutar la orden “catkin_make” esta actualizará nuestro espacio de trabajo. Será necesaria utilizarla cada vez que introduzcamos un nuevo paquete o nodo para ser reconocido y compilado para su correcto funcionamiento. Una vez ejecutadas estas órdenes, en nuestro espacio de trabajo aparecerán dos carpetas más “build” necesaria para almacenar elementos usados durante la compilación y “devel” que guardará ficheros externos. Tras esto nuestro espacio de trabajo quedará completamente configurado y listo para su desarrollo. Como se muestra en la imagen 4-9 Figura 4-9 distribución fichero espacio de trabajo (Fuente: [12 ]) 4.3.2 Creación de paquetes Como se ha explicado previamente la distribución de los nodos en ROS se realiza mediante paquetes. Estos almacenan varios nodos y los ejecutan a la vez si se utiliza el package. En este proyecto necesitaremos crear varios paquetes para introducir una serie de nodos de creación propia para el funcionamiento de nuestro robot. La creación de estos paquetes se realiza mediante la orden “catkin_create_pkg” seguido del nombre que deseemos ponerle y además de manera opcional puede añadirse entre corchetes los nombres de los paquetes necesarios para el desarrollo de nuestros nodos. A continuación, después de ejecutar nuestros comandos previamente descritos habremos creado un nuevo fichero donde nos aparecerán dos archivos. El primero de ellos es el “CMakeLists.txt” muy importante dentro del paquete. Ya que, contiene las instrucciones para los nodos. Será necesario modificarlo posteriormente para declarar un nodo (archivo c++) como ejecutable y que el sistema pueda reconocerlo cuando sea llamado a funcionar. El segundo es el “package.xml” que contiene datos como el autor del paquete, la versión requerida para su funcionamiento y los paquetes necesarios para un correcto desarrollo. Este no se modifica. 25 Detección de señales y planificación de trayectorias en un robot móvil 4.3.3 Creación de nodos Tras la configuración de nuestro espacio de trabajo y la posterior creación del paquete, somos capaces de crear y configurar nuestros nodos. Estos serán archivos c++ (.cpp) que se almacenarán en la carpeta “src” del paquete recién creado no del espacio de trabajo. Podemos crear un archivo normal y depositarlo en el fichero explicado previamente o podemos utilizar la orden “touch” seguido de la dirección de almacenamiento y el nombre del archivo. Finalmente, el resultado será el mismo, la introducción del archivo dentro de la carpeta correspondiente. Para cualquier nodo es indispensable seguir la siguiente estructura, en primer lugar, se añadirán las líneas correspondientes a la cabecera del archivo donde se declararán las librerías necesarias de ROS para el funcionamiento del nodo. Esta se realizará mediante #include, para seguir será necesaria la declaración de nuestra función principal con sus variables de entrada y salida como en cualquier otro archivo en “c”. Posteriormente se llamará a la inicialización del nodo mediante la orden “ros::init” que lo registrará en la tarea maestra. Se ejecutará también una comprobación de que todo sigue funcionando mediante la orden “ros::ok”, mientras esto se desarrolle correctamente el nodo se seguirá ejecutando sin problemas. A continuación, como he explicado previamente será necesaria la modificación del archivo CmakeLists.txt del paquete creado para la declaración de nuestro archivo como nodo. Este proceso se repetirá de igual manera cada vez que introduzcamos un nuevo nodo en el paquete. En primer lugar, se dará nombre al proyecto y se establecerá la versión mínima necesaria para su funcionamiento. Seguidamente, se configurará una serie de elementos básicos mediante la orden “add_compile_options”. A continuación, será necesario declarar el nodo como ejecutable mediante la orden “add_executable” seguido del nombre del proyecto y la ubicación del nodo. Por último, se declararán las librerías necesarias para dicho nodo. Como se ha explicado previamente, antes de que todo esto pueda ejecutarse debe compilarse y actualizar el espacio de trabajo de cara a sistema. Por ello nos moveremos a la carpeta “ros_workspace” y ejecutaremos de nuevo la orden “catkin_make”. Si todo ha ido como debiera, esta orden no devolverá ningún fallo. Si devuelve alguno, deberemos revisar el código o alguno de los pasos explicados previamente ya que habremos cometido un error con seguridad. Antes de ejecutar el nodo, debemos configurar la fuente de partida y las variables de entorno mediante la orden “source ~/ros_workspace/devel/setup.sh” esta deberá ser utilizada antes de comenzar a ejecutar cualquier paquete o nodo ya que sin ella no será posible su funcionamiento. Finalmente, para ejecutar el nodo recién creado solo debemos hacer uso de la orden “rosrun” seguida del nombre del paquete y del nombre del nodo. Para comprobar si todo funciona correctamente podemos ejecutar la orden “rosnode list” con la que debe aparecer toda la lista de nodos activos incluyendo este último recién creado. En la figura 4-10 se muestra un ejemplo de las diferentes opciones de funcionamiento ofrecidas por el programa incluyendo la de la lista de nodos activos. Figura 4-10 ejemplo funcionamiento ROS ROS. Estructura y Funcionamiento 26 4.3.4 Creación de archivos Launch Como se ha explicado previamente, los archivos. launch son bastante interesantes porque son capaces de lanzar varios nodos al mismo tiempo. Es necesario por otro lado, configurar un espacio para todos estos archivos dentro del paquete. Por tanto, lo primero que debemos hacer es crear una nueva carpeta dentro de nuestro paquete llamada “launch”. Una vez hecho esto podemos comenzar a introducir archivos de este tipo en el interior y ejecutarlos mediante la orden “roslaunch” seguido del nombre del paquete y del nombre del launch. Dentro del contenido de los archivos launch es necesario describir el paquete en el que se encuentra, el tipo de archivo que es, su nombre y el tópico al que se suscribe para comenzar a trabajar. Todo ello se añade antes y después de una serie de configuraciones y se hace una vez por cada nodo que queramos ejecutar. 4.3.5 Conexión remota Dentro de los primeros pasos necesarios para la configuración de nuestro dispositivo en ROS tenemos la opción de conectar un ordenador de manera externa para controlar telemáticamente nuestro dispositivo. Para ello será necesario que el ordenador desde el que vaya a realizarse la conexión tenga instalado Ubuntu (18.04 en nuestro caso) además del programa ROS. Si se cumplen los requisitos previos, el siguiente paso es cerciorarnos de que ambos dispositivos (robot y ordenador) están conectados a la misma red Wifi, de la que, por otro lado, necesitaremos su dirección IP. Para ello, debemos ejecutar el comando “ifconfig” y apuntar la dirección IPv4 (inet). Como muestra la imagen 4-11 Figura 4-11 detección de la señal IP Una vez hecho esto, solo deberemos ejecutar el comando “ssh [email protected]” donde en lugar de las x debemos introducir la dirección IP hallada previamente. Tras esto, se nos requerirá una contraseña que es “Husarion”. Si todo se ha realizado correctamente nos aparecerá por pantalla un pequeño mensaje como el de la figura 4-12 y significará que ya estamos conectados. En adición, nos informa de la última conexión que tuvo el dispositivo. Figura 4-12 ejemplo conexión remota ROS 27 Detección de señales y planificación de trayectorias en un robot móvil Desde este momento podremos controlar de manera telemática nuestro robot. Esto será muy útil de aquí en adelante para el control del dispositivo por teclado o la muestra de resultados en tiempo real mientras el dispositivo funciona. A modo de ejemplo puede ejecutarse desde el ordenador algún nodo para ver si funciona o abrir incluso la cámara. Cabe destacar que, como se ha explicado previamente, en ROS todo funciona mediante nodos. Por tanto, el nodo maestro es aquel que ha iniciado mediante “ROSCORE” el sistema, y este siempre suele ser el propio robot. Mediante la conexión ssh recientemente explicada lo que hacemos es introducir un nuevo nodo que cuenta con accesos y permisos a la ejecución de programas dentro del dispositivo. Detección de señales 28 5 DETECCIÓN DE SEÑALES En este capítulo nos centraremos en describir y comentar el proceso que se ha llevado a cabo para que nuestro robot sea capaz de reconocer, detectar y actuar en consecuencia de una serie de señales de tráfico. El objetivo principal de esta sección es llegar a definir la inteligencia artificial, en su vertiente del reconocimiento de imágenes dentro de videos en tiempo real. Con el fin de dejar explicado el funcionamiento de nuestro sistema. Comenzaremos, por tanto, analizando el método de reconocimiento visual con el que cuenta nuestro dispositivo. Además de la manera de configurar el mismo para el aprovechamiento y desarrollo de nuestro proyecto. Tras el aprendizaje de la detección, se pondrá a prueba su funcionamiento y se diseñará un ejecutable que sea capaz de tomar decisiones en consecuencia. Por otro lado, será necesario aclarar el archivo principal que rige al robot y que se ejecuta cuando se detecta alguna imagen, este va a ser capaz de tomar decisiones y actuar en consecuencia de la señal apercibida a su alrededor. 5.1 Introducción Como se ha explicado previamente el sistema de reconocimiento del robot funciona mediante su cámara RGBD integrada en el dispositivo. Esta es capaz de detectar imágenes mediante el reconocimiento de características básicas de las mismas, ya sean estas, puntos específicos, líneas, límites o colores. La detección de imágenes cuenta con dos partes bien diferenciadas. La primera de ellas es el aprendizaje del objeto en cuestión. La señal se presenta delante del sistema de visión y se extraen de la misma una serie de elementos interesantes para su posterior reconocimiento. Esto debe realizarse con cada una de las señales que nos interese detectar. La segunda parte es el reconocimiento, en esta el sistema funciona constantemente. Cada píxel de la cámara es analizado y tratado en busca de coincidencias con las imágenes previamente guardadas. Si finalmente se consigue el número mínimo de coincidencias necesarias, entonces se considera una imagen detectada. Si no, se continua con el proceso hasta que ocurra. En esta sección necesitaremos usar como nodos básicos el “find_object_2d” utilizado para la detección de objetos en videos de tiempo real y el “Astra.launch” que se encarga del funcionamiento de la cámara y su configuración básica. 5.2 Aprendizaje de imágenes Para esta primera parte se procederá al aprendizaje de objetos, en este caso señales a detectar por nuestro sistema. Cabe destacar que cualquier elemento puede servir para ser detectado, pero mientras más limites, colores, elementos y puntos característicos tenga más fácil será posteriormente su detección. 5.2.1 Configuración previa aprendizaje de imágenes Lo primero que debemos hacer es ejecutar el nodo “find_object_2d” que por defecto está suscrito al tópico “image” y que deberemos cambiar al tópico “image_raw”. Para cambiar la suscripción de un nodo a otro tópico se usa la orden “remap” seguido del tópico original y el nuevo de destino. Para el correcto funcionamiento de la cámara debemos ejecutar el nodo “Astra.launch” que se encarga de su configuración e inicialización. Para automatizar todo este proceso se utiliza un archivo launch que es capaz de realizar todo lo descrito anteriormente de manera simultánea. Una vez ejecutemos este archivo, nos aparecerá una ventana del programa “find_object_2d” donde podremos apreciar como el sistema busca características de los objetos que percibe como muestra la imagen 5-1. 29 Detección de señales y planificación de trayectorias en un robot móvil Figura 5-1 Ejemplo propio funcionamiento Find Object 5.2.2 Inclusión de objetos en “Find_Object_2d” En nuestro caso y a modo de ejemplo utilizaremos una señal de limitación de velocidad a 40km/h como la que se muestra en la figura 5-2. Una vez la coloquemos delante de la cámara y percibamos que el sistema toma el mayor número de puntos de referencia posible (puntos amarillos) entonces abrimos “edit” y seleccionamos “add object”. Con lo que nos aparecerá una ventana muy similar a la anterior, pero en blanco y negro en esta ocasión. Figura 5-2 ejemplo captura de imagen en Find Object Como puede observarse el programa es capaz de detectar con mayor facilidad los números que cualquier otra cosa, es por ello por lo que las señales alfanuméricas serán las que tengan una mayor facilidad de reconocimiento en nuestro proyecto. Tras cuadrar la imagen correctamente en la ventana de opciones nos permiten seleccionar el área de interés. Será por tanto necesario recortar la imagen para eliminar aquellos elementos inútiles dentro de la fotografía y centrarnos únicamente en la parte que incluye la señal u objeto deseado. Este proceso debe ser llevado a cabo con cautela para evitar que se guarden elementos innecesarios en la memoria del objeto. Una correcta selección donde solo se toman puntos identificativos de la señal aparece en la imagen 5-3 añadida a continuación. Detección de señales 30 Figura 5-3 Detección de puntos característicos de una imagen Una vez realizado este último paso solo debemos guardar el objeto y volveremos a la pantalla principal del sistema donde podremos apreciar que un nuevo elemento ha sido añadido. Además, si acercamos a la cámara la señal previamente mostrada, puede observarse como se detecta y se rodea de un color característico indicando que se han encontrado el mínimo de características comunes con la imagen enseñada previamente. Este proceso aparece gráficamente en la imagen 5-4 Figura 5-4 Detección de una imagen por parte del programa Por último, solo deberemos guardar todos los objetos que hayan sido añadidos en un fichero local y guardar la dirección de este. Ya que, será necesaria para el desarrollo posterior del proyecto. Esto puede hacerse fácilmente en la pestaña de “file” donde seleccionaremos “save objects” y nos derivarán a la elección de la carpeta deseada para su almacenaje. Es destacable el hecho de que el funcionamiento de la cámara más la detección de objetos, supone una gran ocupación de la RAM del dispositivo. Por tanto, muchas veces cuando tratamos de guardar los objetos, el sistema se queda algo colgado. Como recomendación puede ser necesario pausar la cámara en este momento. Dicha opción está disponible en la pestaña “file”, ya que con esto se hace más liviana la carga y se posibilita guardar las imágenes sin dificultad. 31 Detección de señales y planificación de trayectorias en un robot móvil 5.2.3 Funcionamiento del nodo “Find_object” En cuanto al algoritmo utilizado por la función Find_object_2d, al que ya se hizo referencia en el capítulo dos de este mismo proyecto, si nos centramos en su funcionamiento en profundidad, cabe decir que, en primer lugar, toma las siguientes bibliotecas de la librería de OpenCV: • “core” nos permite generar interfaces gráficas. • “highgui” nos permite abrir fácilmente ventanas, mostrar imágenes, leer o escribir archivos relacionados con imágenes y principalmente operar con la cámara del dispositivo. • “features2d” relaciona características bidimensionales, usa principalmente funciones de comparación y detección de puntos característicos basados en el algoritmo ORB explicado previamente. Cabe decir que los algoritmos que usa son de software libre. • “nonfree” forma parte de la propia biblioteca de “features2d” pero en este caso incluye algoritmos del tipo SIFT y SURF que están protegidos por ciertas patentes. • “calib3d” en ella encontramos funciones relacionadas con la reconstrucción de imágenes en 3 dimensiones, la visión estéreo y la calibración de la propia cámara. Posteriormente, la función carga las imágenes en escala de grises en su memoria interna para que sea más fácil su detección y posterior comparación. Además, crea tanto vectores que almacenen los puntos clave del objeto en cuestión como variables encargadas de almacenar los elementos descriptores de la imagen. Como ya se ha definido previamente los puntos clave serán los encargados de definir la forma y los caracteres del elemento mientras que, los descriptores, se encargarán de definir la situación de la misma en el momento de la captación. Definiendo así la escala del objeto, la orientación de la imagen, la luminosidad y el tamaño del elemento en cuestión. Seguidamente, la función “features2d” comienza a realizar la detección y posterior extracción de puntos clave para introducirlos en el vector previamente creado. Dicha función ofrece la posibilidad de trabajar con multitud de los algoritmos explicados en el capítulo dos, pero en nuestro caso usará SIFT. Este realizará la escala de la imagen, posteriormente hallará y hará un refinado de los puntos clave de la misma y tras esto, especificará la orientación de dichos puntos para por último particularizar la posición de los mismos dentro del objeto. Para todo ello, los parámetros que necesita que se le pasen son los siguientes: • “nfeautes” número de puntos característicos que retener, estos se organizan de mayor a menor importancia según sus propiedades, primando en los mismos aquellos con un mayor contraste. • “noctavelayers” número de capas usadas en la resolución de la imagen, su valor habitual es 3, aunque actualmente el algoritmo determina su valor de manera automática al percibir la misma. • “contrastThreshold” se usa con el fin de filtrar aquellos puntos clave con bajo contraste y con características semi uniformes en el plano de la imagen, mientras mayor sea su valor menor será el número de puntos característicos detectados. • “EdgeThreshold” se usa para filtrar los puntos clave que se encuentren en los límites o bordes del objeto. Su funcionamiento es contrario al anterior ya que mientras mayor sea su valor, mayor será el número de puntos característicos extraídos. • “sigma” valor que determina el funcionamiento de la diferencia gaussiana, filtro empleado en la detección de bordes, su valor debe ser menor mientras menor sea la calidad de la imagen tomada ya que la detección de bordes y los radios de desenfoque se realizarán de manera más abrupta. • “Descriptortype” valor que determina el tipo de descriptores que van a utilizarse, solo puede darse el valor CV_32F, que corresponde con el algoritmo SIFT que va a utilizarse. Tras la configuración de todos estos parámetros, la función es capaz de extraer tanto los puntos clave del objeto como los descriptores del mismo. Seguidamente, los almacena en los vectores descritos previamente y con esto termina la parte de aprendizaje de la función en el contexto de la detección de imágenes. En el apartado de reconocimiento se continuará desarrollando el algoritmo de funcionamiento. Detección de señales 38 • Señal de velocidad 90: este objeto cuenta con el identificador número 6 en el sistema, sus características son similares a las dos anteriormente descritas, en el dispositivo es conocida como “med_vel”, cuando es detectada el sistema actualiza la velocidad lineal del robot a su capacidad media. Figura 5-16 Señal 90 utilizada (Fuente: [14 ]) 39 Detección de señales y planificación de trayectorias en un robot móvil 6 NAVEGACIÓN SLAM 6.1 Introducción La navegación SLAM (simultaneous localization and mapping), consiste en un método capaz de crear el mapeado de un entorno al mismo tiempo que se determina la posición del robot dentro del mismo. la idea principal es que cada vez que el dispositivo se desplaza, se actualiza su posición con respecto a la justo anterior. Es por ello por lo que se considera indispensable conocer la localización inicial del robot en el mapa. En nuestro caso no contamos con sistemas de localización global (GPS), por lo que sería recomendable colocar siempre al dispositivo en la misma posición al comenzar. Cosa que con el GPS no sería necesaria. Si bien la finalidad de realizar un mapeado en nuestro proyecto era la de situar los posibles objetos a detectar con las técnicas anteriormente expuestas, el desarrollo y explicación del mismo finalmente, se ha ejecutado como fundamento de la planificación de trayectorias. Que se ha convertido en uno de los objetivos finalistas de nuestro trabajo. Además, se considera indispensable que, si se quiere lograr el objetivo final en trabajos futuros, se conozca de primera mano el funcionamiento de dicho proceso y los problemas que puede entrañar su desarrollo. El mapeado de entornos se realizará mediante cuadriculas en las que se dividirá el espacio como aparece en la imagen 6-1 que se irán rellenando a medida que sean recorridas. Para saber la transformación que se realiza de una cuadrícula a la siguiente se utiliza el tópico “tf” del paquete “tf2” de ROS, este nos muestra tanto la traslación como la rotación realizada para el paso de una casilla a la siguiente. Figura 6-1 Ejemplo mapeado SLAM en Rviz Para conseguir llevar a cabo la navegación deseada, crearemos un nodo que se suscribirá al tópico “/pose” publicando un mensaje del tipo “/posestamped” donde irá incluida la información de la transformación de los distintos objetos que nos interesan. El nodo creado para controlar todo esto se llamará “drive_controller” y su código se incluye comentado en el anexoB del proyecto [3]. Cabe destacar, que en este trabajo utilizamos un sistema de tiempo real que varía su posición en cada momento. Ya que existe también la posibilidad de publicar información de manera estática. Es decir, transformar posiciones que no cambian en el tiempo. Esta por ejemplo es interesante para la posición del láser del robot con respecto a su base. Porque a pesar de que el conjunto se mueve, la diferencia entre uno y otro nunca varía. Navegación Slam 40 Como será habitual casi siempre, la información obtenida podrá ser observada a través de la herramienta “Rviz”. Dónde añadiremos una nueva pantalla o “display” con el tópico “tf”. Además, podremos añadir “pose” lo que nos permitirá observar el desplazamiento del mismo. La configuración del display se muestra en la imagen 6-2. Figura 6-2 Ejemplo Display TF en RViz 41 Detección de señales y planificación de trayectorias en un robot móvil 6.2 Control remoto del Robot En este apartado se resumirá el sistema que rige el movimiento de nuestro dispositivo. Este se coordina mayormente mediante comandos del tipo “/Twist”. Comandos que son almacenados por el controlador del motor para posteriormente ser ejecutados, en estos comandos básicamente se describen dos campos: 1. “Vector3_Linear” en este campo se especifica la velocidad lineal en [m/s] del dispositivo, por así decirlo describe el movimiento hacia adelante o atrás del robot. 2. “Vector3_angular” en este campo se especifica la velocidad radial del robot. Esta se mide en [rad/s] un valor positivo del mismo produce un giro hacia la derecha, mientras que un valor negativo produciría un desplazamiento a la izquierda. Una vez comprendido cómo funciona el movimiento de nuestro dispositivo nos disponemos a describir la manera de controlarlo remotamente. Esto se conseguirá mediante una serie de sencillos pasos: • Conectar de manera remota un portátil o ordenador al dispositivo como se ha explicado previamente. Como es obvio, el control del robot puede hacerse de manera remota mediante un ordenador externo o de manera directa con un teclado conectado al propio robot, ambos son válidos. • Lanzar el nodo “rosbot_ekf” encargado de utilizar el filtro de Kalman extendido, utilizado para calcular de manera mucho más aproximada la posición y orientación del sistema. • Ejecutar el nodo “Teleop_twist_keyboard” encargado de coordinar el movimiento del robot mediante el teclado del dispositivo ejecutor del mismo. Este se encarga de crear los mensajes al pulsar cada tecla y enviarlo al motor correspondiente. • Ejecutar el nodo “Teleop_twist_keyboard.py” que convierte los mensajes creados por el nodo anterior a aquellos más funcionales que pueden interpretar los controladores de cada motor. Al cumplir todos estos pasos podremos al fin controlar el sistema de manera remota mediante el teclado de nuestro dispositivo conectado al robot. Los comandos que coordinan el movimiento se describen a continuación: • “i” para desplazar al dispositivo hacia adelante. • “,” para desplazar el robot hacia detrás. • “j” para girar el sistema hacia la izquierda. • “l” para girar el dispositivo hacia la derecha. • “k” para parar el robot. • “q” para aumentar la velocidad del sistema. • “z” para disminuir la velocidad del dispositivo. Para terminar con el apartado se aclara que es posible configurar diferentes dispositivos de control remoto para trabajar con el robot, esto queda fuera del alcance del proyecto y por tanto no se desarrollará, pero queda constancia de la posibilidad de hacerlo. Navegación Slam 42 6.3 Implementación en ROS de la navegación SLAM En nuestro caso la manera más sencilla de implementar este tipo de navegación en ROS a través de nuestro robot es mediante el uso del escáner laser con el que cuenta el dispositivo. Es por ello por lo que utilizaremos el sensor LIDAR integrado dentro de nuestro sistema que junto con los sistemas de odometría con los que cuenta nos permitirán realizar un mapeado del entorno bastante correcto. Debido a esto, nuestro robot utilizará el “RPlidarNode” encargado de comunicar el sistema con el sensor para permitirle publicar lo escaneado en el tópico “/scan” con un mensaje del tipo “/LaserScan”. Esto será lo que recogerán los sistemas de mapeado para rellenar casilla a casilla el entorno del dispositivo y esbozar un mapa con los posibles obstáculos de alrededor. Para comenzar a realizar el propio mapeado deberemos iniciar una serie de nodos particulares que se describen a continuación: 1. El “RPlidarNode” indispensable para que el sensor comience a escanear el entorno y publique los datos con el objetivo de que sean transformados en el posterior mapa. 2. El “drive_controller” creado por nosotros mismos anteriormente, encargado de publicar las transformaciones (traslación y rotación) realizadas por el dispositivo para avanzar de una casilla a la siguiente del mapa cuadriculado. Este nodo en particular se explica en el anexo posterior de manera detallada [ 3]. 3. El “teleop_twist_keyboard” que nos va a permitir controlar el dispositivo de manera remota mediante el teclado, como se ha explicado anteriormente. 4. El “Rviz” como herramienta de visualización de todos los datos recopilados por el sensor LIDAR. 5. El “gmapping” paquete de ros que trabaja mediante el sensor laser incluido dentro del LIDAR basado en la navegación SLAM. Tal y como nosotros buscamos donde la localización y el mapeado se realizan de manera simultánea. Cuando nos aparezca la interfaz de la herramienta Rviz debemos configurarla correctamente, para ello añadiremos nuevos objetos o pantallas, seleccionaremos “add object” y en la nueva ventana escogeremos “by_topic” donde escogeremos “/scan” y dentro del mismo los distintos marcos de encasillado del mapa los cambiaremos a “laser_frame” esto nos devolverá lo que detecta el láser a través del LIDAR del entorno que rodea al dispositivo. Si queremos comenzar a explorar lo que se encuentra alrededor del robot, cambiaremos los “frames” del mapa de “laser_frame” a “odom”, añadiremos el objeto “TF” que nos indica la posición del robot en cada momento, y comenzaremos a desplazarnos mediante el teclado para detectar los obstáculos que nos rodean. Para ser capaces de versar toda esta información en un mapa usaremos el nodo “slam_gmapping”. Este se suscribe al tópico “/tf” que consigue la posición del robot en cada momento. También se suscribe al tópico “/scan” para recabar la información vertida por el LIDAR. El nodo publica todo esto en el tópico “/map” donde se guarda la información relativa al mapeado. En Rviz debemos añadir el objeto “/map” de la carpeta de tópicos, en un principio este será un mapa por defecto provisto por el sistema, pero a medida que avance nuestro dispositivo será capaz de modelar un entorno cercano al que de verdad lo rodea. 43 Detección de señales y planificación de trayectorias en un robot móvil A continuación, se dejan una serie de imágenes como ejemplo de cómo el dispositivo ha mapeado una casa. Estas son la figura 6-3 y 6-4. Figura 6-3 ejemplo mapeado salón En esta primera figura se observa el mapeado realizado al salón de mi casa. En ella puede observarse como el robot es capaz de detectar los sofás como obstáculos que suponen límites infranqueables, además de las patas de los muebles en altura, ya sean sillas o mesas o elementos por el estilo que suponen las marcas negras de la derecha de la imagen. En rojo podemos observar los límites que provee el escáner láser de los obstáculos que detecta en ese momento. Figura 6-4 ejemplo mapeado casa En esta segunda figura podemos apreciar un entorno algo más amplio de mi hogar donde queda recogido el salón en la parte superior, la cocina, un aseo y una habitación en la parte inferior. En este caso es destacable el hecho de la capacidad de mapeado de grandes superficies que lleva a cabo el dispositivo con buenos resultados. Navegación Slam 44 Detecta con un mayor acierto los obstáculos que suponen las patas de las sillas, y de la mesa. Detecta correctamente también las puertas de las habitaciones abiertas, y los obstáculos referidos a muebles de cada estancia. Comete ciertos errores como se aprecia en la línea que se pierde en el infinito, pero pueden considerarse aislados, ya que en líneas generales el resultado es muy correcto. Cuando consigamos el resultado deseado en nuestro mapeado será indispensable guardar los resultados, con la finalidad de poder ser reutilizados en el futuro sin necesidad de volver a mapear el entorno al completo. Para ello nos serviremos del nodo “map_saver”, cabe destacar que sin él cuando el nodo deje de funcionar perderemos toda la información obtenida y deberemos empezar de nuevo. Lo primero será crear un nuevo directorio en nuestro paquete que llamaremos “maps” y cuando en Rviz el mapa sea el deseado nos cambiaremos a dicha carpeta para que los avances se guarden ahí. Entonces ejecutaremos el nodo de la siguiente forma “rosrun map_server map_saver -f nombre mapa” y el mapa en cuestión quedará guardado. En ese momento, se crearán dos archivos, uno del tipo “yaml” y otro del tipo “pgm” el de tipo yaml contiene toda la información del mapa, su resolución, la posición de origen, la zona ocupada y la libre. El de tipo pgm es una imagen del mapa recogido en escala de grises. En nuestro caso el archivo pgm generado, luego de ser abierto por una aplicación particular llamada GIMP que gestiona este tipo de imágenes, se muestra como aparece en la figura 6-5. Puede considerarse el resultado muy parecido al original previamente mostrado. Figura 6-5 Ejemplo mapa.pgm En el mapa se aprecia de nuevo en la parte superior el salón de la casa, seguido de un pasillo del hall de entrada, la cocina a la izquierda y un aseo junto con una habitación a la derecha. 45 Detección de señales y planificación de trayectorias en un robot móvil 6.4 Planificación de trayectorias La planificación de trayectorias consiste en la determinación de la secuencia de movimientos necesaria para trasladar al dispositivo de una posición inicial a otra final o destino evitando la colisión con los obstáculos encontrados en el camino. El método de planificación utilizado es una mezcla entre el método gráfico y el de celdas ocupadas. El método gráfico sirve para definir los límites de la estancia, además de determinar las posibles puertas abiertas, que conectan habitaciones o pasillos. En adición, cada límite puede tener asignada su anchura para determinar la dificultad de atravesarlo en un futuro. Encontrar la trayectoria se fundamenta en determinar el camino más eficiente posible de conexión entre las posiciones inicial y final. Por otro lado, el método de celdas empleado divide el área en casillas a modo de pixeles. A estas se les asigna la categoría de ocupadas o libres. Además, una de las celdas es marcada como el origen y otra como el destino final. Por tanto, en este caso encontrar la trayectoria se fundamenta en trazar la línea más corta posible que conecte las dos celdas de origen y destino sin cruzar por ninguna que esté ocupada. Es indispensable para la realización de este apartado la configuración del nodo “move_base” este es el encargado de crear el llamado “costmap” que determina un valor a cada celda del mapa dependiendo de lo cerca o lejos que se encuentre del obstáculo. Mediante el mismo somos capaces de crear la trayectoria con menor “coste” es decir aquella más corta y con menos posibilidades de chocar con un obstáculo. 6.4.1 Configuración previa del nodo “Path_Planning” Para determinar el “costmap” descrito previamente debemos configurar una serie de parámetros que se describen a continuación: • Sensor_frame: coordina el marco de acción relacionado con el sensor. • Data_type: determina el tipo de mensaje enviado por el sensor. • Marking: se activa cuando una celda se marca como ocupada. • Clearing: se activa cuando una celda se marca como libre. • Obstacle_range: determina el rango en el que se comienzan a incluir obstáculos en el costmap gracias al sensor. De la misma manera que se ha configurado el “costmap” deberíamos ajustar también el “local_costmap” y el “global_costmap” con parámetros muy similares a los descritos anteriormente. En el apartado de la configuración de la propia planificación de trayectorias cabe destacar una serie de parámetros como la velocidad máxima o mínima de desplazamiento tanto lineal como radial, la diferencia entre su posición y la posición de destino deseada que es aceptable o la aceleración máxima del conjunto. Todo esto se ha automatizado mediante un archivo launch que se incluye en el anexo donde todos los parámetros necesarios para el correcto desarrollo del sistema se ajustan instantáneamente al ejecutar el archivo en cuestión. Navegación Slam 46 6.4.2 Lanzamiento del nodo “Path_Planning” Una vez configurado el sistema, podremos ser capaces de ejecutarlo y comprobar su funcionamiento. Para ello deben seguirse los siguientes pasos, donde se determinan los nodos a lanzar: 1. Ejecutar el nodo “move_base” descrito previamente. 2. Lanzar el nodo “teleop_twist_keyboard” para el control mediante el teclado del dispositivo. 3. Activar el nodo que desarrolla el filtro de Kalman extendido “rosbot_ekf”. 4. Ejecutar el nodo “tf” encargado de transformar la posición real del robot en la que puede ser leída por el sistema. 5. Lanzar el nodo “slam_gmapping” encargado de generar un mapa del entorno que rodea al robot. 6. Activar el programa Rviz que nos permite visualizar todo lo explicado de manera más gráfica. Una vez abierto Rviz como se ha explicado antes deberemos configurar las distintas “displays” o pantallas que nos serán útiles para la visualización del proyecto, los elementos son los mismos empleados en ocasiones anteriores salvo que, se añadirán las pantallas “path” del fichero “move_base/TrajectoryPlanerROS” tanto a nivel global como a nivel local. Además, será necesario añadir la pantalla “Polygon” del “global_costmap” y los propios “costmaps” global y local definidos previamente. Tras un ajuste del color de visualización de ambos podremos apreciar nuestro entorno con los obstáculos que nos rodean de una manera llamativa como se muestra en la figura 6-6. Figura 6-6 ejemplo mapeado planificación de trayectorias Como puede observarse el entorno es el mismo que el previamente descrito en la navegación SLAM. Con la diferencia de que en este apartado con la finalidad de la planificación de trayectorias, el sistema es capaz de detectar de manera más exacta los obstáculos que lo rodean con el fin de no chocar con ellos en la trayectoria. 47 Detección de señales y planificación de trayectorias en un robot móvil 6.4.3 Funcionamiento de la planificación de trayectorias Posteriormente, mediante una de las posibilidades que nos brinda el programa Rviz seremos capaces por fin de determinar un punto de destino final y que el sistema programe una trayectoria siguiendo los criterios previamente descritos, mínimo coste posible, mínima distancia y mayor evitación de obstáculos. En la figura 6-7 puede apreciarse en la parte superior la opción de navegación “2D Nav Goal” que nos da la posibilidad de seleccionar un punto de destino determinado dentro del mapa previamente elaborado. Una vez hecho esto el robot automáticamente detecta la trayectoria más correcta y comienza a ejecutarla. Figura 6-7 ejemplo mapeado planificación de trayectorias La trayectoria quedará definida mediante una serie de líneas discontinuas de color amarillo. Cabe destacar que es muy importante la posición inicial y actual del robot en cada momento. Ya que las trayectorias son calculadas con respecto a ellas y si difieren de la realidad es posible que colisione contra obstáculos debido a la falta de exactitud. Llegados a este punto es mejor comenzar de nuevo y colocar al robot en la posición de partida original. 6.4.4 Fundamentos de la planificación de trayectorias en ROS Particularmente en nuestro entorno de ROS podemos explicar de manera más detallada el funcionamiento de cada nodo que interviene en el desarrollo de la planificación de trayectorias. Como se ha explicado previamente, el nodo principal es el “move_base” que proviene del paquete “navigation” este es bastante sencillo conceptualmente, ya que toma información de la odometría y los sensores que la emiten, para ajustar los comandos de velocidad y movimiento enviados al robot. En particular el nodo “move_base” de este paquete busca como se ha descrito previamente que, dada una posición final de destino, esta sea alcanzada por la base móvil. Su funcionamiento se aclara en la figura 6-8 incluida a continuación, en ella puede observarse como la información que llega desde la odometría y los distintos sensores, son transformados mediante el nodo “tf” descrito con anterioridad, o el nodo “odom”, que transforma la información odométrica en otra utilizable por el dispositivo. Navegación Slam 54 • “potential_scale” este parámetro determina la distancia a partir de la cual el dispositivo es capaz de detectar una frontera. Todos estos parámetros serán configurados en un archivo yaml que se adjunta en el anexo del final del trabajo donde se explica de nuevo línea a línea. Una vez realizada la configuración previa ya podemos seguir los siguientes pasos para comenzar a trabajar con el nodo de exploración de espacios desconocidos. 1. Lanzar el nodo “rosbot_ekf” ya explicado previamente. 2. Ejecutar el nodo “rpLidar” también explicado con anterioridad. 3. Activar el transformador de la posición estático del paquete “tf” anteriormente descrito. 4. Lanzar el nodo “slam_mapping” para crear un mapa vacío en el que poder comenzar a introducir la información. 5. Ejecutar el nodo “explore_lite” que se encargará del movimiento dentro del entorno desconocido y versará la información sobre fronteras detectadas en el mapa creado antes. 6. Activar la herramienta “Rviz” como visualizadora de la información recogida. Debido a la enorme cantidad de acciones a realizar se incluye todo lo anteriormente descrito en un archivo launch llamado “exploration” que se añade al final del trabajo dentro del anexo donde se automatiza todo este proceso. Para el correcto desarrollo del paquete, su funcionamiento se basa en el uso del nodo “costmap” descrito con anterioridad, que se utiliza para rellenar el mapa con los obstáculos encontrados, y en el uso del nodo “navfn” que provee una rápida interpolación de una función de navegación que planifica trayectorias para la base del robot. Este nodo opera suponiendo un robot circular, que a efectos prácticos no nos supone un gran problema para nuestro dispositivo, además, se sirve del mapa de obstáculos para diseñar una trayectoria con el mínimo coste posible desde un punto inicial hasta otro final. En general el nodo que coordina el funcionamiento de todo lo anteriormente explicado, es el “explore_lite” que trata de definir las fronteras de un entorno determinado basado en la exploración del mismo. Este nodo se encargará de enviar comandos a la base para determinar sus movimientos. Además, se suscribirá al tópico que envía la información relativa a la ocupación de celdas del paquete de navegación SLAM. Otra opción es que se suscriba al tópico que crea los “costmap” donde en lugar de servirse de un mapeado estándar como en el caso de la navegación SLAM, utilizará un mapa de obstáculos más completo. La elección de uno u otro depende del entorno en el que vaya a explorarse, de esta forma, cobrará una mayor importancia la determinación de una serie de parámetros relacionados con la configuración del funcionamiento como son la mínima altura que supone una frontera, o la distancia a la que puede acercarse de la misma. Para su configuración debe lanzarse el nodo “move_base” para posteriormente ser capaz de controlarlo desde Rviz. Tras esto, para cerciorarse de una correcta configuración del paquete, debemos emplear el nodo “navfn” para mover el robot hasta una posición deseada. Además, será necesario tomar información del mapa de obstáculos activando el parámetro “track_unknown_space”. Una vez hecho todo esto puede lanzarse el nodo “explore_lite” que nada más ejecutarse comenzará instantáneamente a explorar su entorno. 55 Detección de señales y planificación de trayectorias en un robot móvil A medida que vaya detectando fronteras publicará en el tópico “frontiers” la ubicación de las mismas para evitar colisiones y determinar un mapeado correcto del entorno. En la figura 6-13 se muestra el recorrido que realiza el dispositivo mediante flechas en color azul, y como va aumentando el mapa a través de la ubicación de fronteras. Figura 6-13 ejemplo de funcionamiento del nodo “explore_lite” (Fuente: [11 ]) Resultados 56 7 RESULTADOS En este apartado el objetivo será mostrar que todos los métodos anteriormente descritos funcionan y que por tanto lo que se ha ido exponiendo en este trabajo previamente tiene un resultado positivo y favorable. La muestra de resultados contará con aquellos referidos al apartado de visión, más concretamente al reconocimiento de señales y actuación en consecuencia. Además de aquellos del mapeado de entornos y planificación de trayectorias. 7.1 Resultados de detección de objetos En cuanto a los resultados de visión se subdividirán en dos apartados diferentes. El primero de ellos, consistirá en el aprendizaje y posterior reconocimiento de imágenes. Dónde se mostrará la eficiencia del proceso descrito. En el otro se mostrarán las reacciones del dispositivo frente a la detección de las propias señales. 7.1.1 Resultados del reconocimiento de señales. Como se ha aclarado con anterioridad en el apartado de las características de los componentes, la cámara es capaz de percibir cualquier objeto con un rango de entre 0.6 y 8m de distancia al objetivo. Por tanto, en las pruebas realizadas se ha tratado de evaluar ese rango colocando señales a distintas distancias. Como se ha aclarado en el apartado de limitaciones, el dispositivo no reacciona igual ante todas las señales y por tanto los resultados con algunas han sido más favorables y con otras no tanto. Los resultados en cuanto al aprendizaje de imágenes mediante la detección de sus puntos clave han sido los siguientes: Figura 7-1 Puntos clave de la señal de 120 Figura 7-2 Puntos clave señal de STOP 57 Detección de señales y planificación de trayectorias en un robot móvil Figura 7-3 Puntos clave señal giro izquierda Figura 7-4 Puntos clave señal recto Como puede apreciarse en las imágenes y como se explicó en el apartado de limitaciones, las señales con flechas tienen muchos menos puntos clave que aquellas con letras o números. Cabe destacar el hecho de que entre las dos son las señales con números las que tienen más puntos clave. Por tanto, son más fáciles de detectar. A continuación, se muestran los resultados obtenidos en cuanto a la detección de imágenes. En el propio Programa “find object 2d” y a través del tópico objects como se explicó anteriormente. Figura 7-5 Reconocimiento de objetos mediante el tópico Objects Resultados 58 Figura 7-6 Reconocimiento de objetos mediante el tópico Objects Como ya se explicó con anterioridad, el tópico objects devuelve el identificador de cada imagen además de su Distancia y orientación con respecto a la cámara. Para determinar el rango de detección de nuestra cámara se han tratado de detectar objetos a 3 distancias distintas, La primera a 80cm la segunda a 120cm y la tercera a 220cm los resultados han sido los siguientes: Figura 7-7 Primera distancia de reconocimiento Figura 7-8 Reconocimiento en el programa find object 2d 59 Detección de señales y planificación de trayectorias en un robot móvil Figura 7-10 Reconocimiento en el programa find object Figura 7-9 Segunda distancia de reconocimiento Figura 7-12 Reconocimiento en el programa Find object Figura 7-11 tercera distancia de reconocimiento Resultados 60 Como puede apreciarse en las imágenes se ha usado una señal distinta a la del modelo ya que proveía mejores resultados como se ha explicado previamente. Aun así, la tercera distancia de reconocimiento no llegó a superarla ya que el sistema no reconocía la señal con tanta separación. Debe aclararse que la luminosidad se ha regularizado para mejorar los resultados, ya que un cambio en la misma puede suponer un desfase en la detección de puntos y la comparación con los ya existentes. Por último, cabe decir que se ha empleado el programa únicamente para la detección de señales, pero podría utilizarse para la detección de otros muchos objetos o incluso caras. Ya que, la detección de puntos clave en objetos con numerosas características le resulta mucho más sencilla. 7.1.2 Resultados de la reacción tras detección En este apartado se mostrarán los resultados obtenidos en la reacción del dispositivo tras la detección de algunas de las señales. En primer lugar, se adjuntan una serie de videos en los que se muestra la reacción del dispositivo tras detectar la señal de giro a la derecha o la señal de giro a la izquierda. En estos puede apreciarse como actúa correctamente y vira en mayor o menor medida dependiendo del tiempo de detección de la imagen. Video 7-1 Reacción de robot tras la visión Video 7-2 Reacción del robot tras la visión 61 Detección de señales y planificación de trayectorias en un robot móvil Tras esto, y con el fin de evaluar la mayor parte de las señales que se introdujeron en el dispositivo, se creó un circuito con sillas de las que pendían las señales que debían ser detectadas. En esta ocasión al estar fijas dichas señales, se consigue que se estabilice el tiempo de detección de las mismas y que el resultado sea más exacto. El circuito consiste en una primera señal de limitación de velocidad a 80Km/h que aumenta la velocidad del dispositivo, posteriormente una señal de 50km/h hace que el robot reduzca su velocidad, a continuación, una señal de giro a la derecha obliga a virar a la base. Seguidamente, gira hacia la izquierda y por último, para al detectar la señal de STOP. Se adjunta un video con el resultado obtenido. Video 7-3 Reacción del robot tras la detección Cabe decir que esta prueba es bastante complicada, como ya hemos visto la detección de señales depende en gran medida de la luminosidad de cada uno, de la comparación de las mismas con el momento en que fueron detectadas, de su orientación en cada situación y de varios factores más. En el apartado de los giros, estas señales son algo más difíciles de ser detectadas y por tanto el tiempo de reacción del robot varía. Todo ello podría configurarse modificando la velocidad radial de giro con la que se mueve cada vez que detecta la imagen. Por otro lado, las señales de limitaciones de velocidad, así como la de STOP funcionan bastante bien, son detectadas desde casi cualquier ángulo y la reacción no se hace esperar, además no tiene casi retraso y la adaptación tras dejar de verlas es casi inmediata. Por último, cabe decir que las posibilidades que ofrece este programa son muchísimas, el circuito podría variar de muchas maneras, el tamaño de las señales podría ser mayor para ser detectadas desde mucha más distancia, o el empleo de ciertos elementos podría hacerse de modos distintos. Resultados 62 7.2 Resultados de mapeado y planificación de trayectorias En este apartado se mostrarán los resultados obtenidos del mapeado de entornos en un primer subcapítulo seguido de la planificación de trayectorias. Además del mapeado de un circuito limitado por conos y la inclusión de los sistemas de visión dentro del mapeado. 7.2.1 Resultados del mapeado de entornos En este primer apartado van a mostrarse los resultados del mapeado de un entorno determinado. En este caso los lugares escogidos para que la experiencia sea realizada son el salón de mi casa y mi propia casa al completo. Se adjuntarán una serie de imágenes para comparar el trabajo realizado por el dispositivo con la realidad en la que explora. Para la realización de este apartado se ha controlado el dispositivo de manera manual para que recorra la totalidad del entorno que nos interesaba que mapease. Cabe destacar que el mapa creado se muestra desde el punto de vista de la planta mientras que las imágenes son tomadas desde una perspectiva diferente. Aun así, se pretenderá aclarar cada elemento para que todo concuerde. Las imágenes de mapeados que van a mostrarse como se ha explicado con anterioridad son tomadas de la herramienta Rviz con la que se ha trabajado en este proyecto para el desarrollo de este apartado. Los resultados obtenidos han sido los siguientes: Figura 7-13 Aspecto del entorno a mapear Figura 7-14 Resultado del mapeo en Rviz Como puede apreciarse los resultados son bastante buenos, el sistema muestra los sofás como fronteras ya que el sensor no detecta que cuentan con espacio por debajo, esto podría solucionarse empleando los sensores de infrarrojos o la cámara, pero se escapa a los objetivos de nuestro trabajo. De igual manera, los puntos negros de la parte izquierda de la imagen se corresponden con las patas de las sillas y la mesa. Se pueden apreciar también como fronteras el resto de los muebles que ocupan la habitación. 63 Detección de señales y planificación de trayectorias en un robot móvil Figura 7-15 resultado del mapeo de una casa en Rviz En esta imagen podemos apreciar el resultado de mapear no solo el salón que se encuentra en la parte inferior de la figura, si no también unas cuantas más de habitaciones del hogar. En la parte superior, nos encontramos la cocina además del aseo y una de las habitaciones. Cabe destacar que en el salón se han detectado con más exactitud los huecos que se encuentran entre los sofás, así como la totalidad de las sillas y las mesas que allí se encuentran. Como se ha dicho previamente, los resultados obtenidos son muy buenos y se ajustan a la perfección a la realidad. Esta parte del proyecto es indispensable ya que posteriormente la planificación de trayectorias se basará en lo bien o mal que se haya hecho esta sección. Cabe decir que este mapa no es una captura directamente tomada del programa si no que ha sido extraído en un archivo particular. Como aplicación de este proyecto se plantea la adaptación del mapeado a la detección de una serie de obstáculos, en este caso conos, que delimiten el recorrido de un circuito en particular, la idea es que, mediante una vuelta de reconocimiento, el dispositivo sea capaz de detectar el circuito y mapearlo de manera simultánea. Es por ello por lo que se realizó la compra de una serie de conos, se buscó un espacio abierto en el edificio de laboratorios y se elaboró un circuito para que fuese mapeado. Este cuenta con dos conos que delimitan por donde debe cruzar el robot para avanzar. En una primera figura, se mostrará el circuito elaborado visto desde la altura, asemejándose así a lo que el programa plasma posteriormente en su herramienta, después, se adjuntará el mapeado que se crea en el sistema. Los resultados obtenidos son los siguientes: Resultados 70 Video 7-4 ejemplo de planificación de trayectorias Video 7-5 Ejemplo de planificación de trayectorias. 71 Detección de señales y planificación de trayectorias en un robot móvil Como puede apreciarse en los videos existen ciertas limitaciones relacionadas con la obligación de estar conectado a un monitor para designar el punto de destino al que dirigirse. Aun así, el funcionamiento es bueno y el dispositivo es capaz de alcanzar los objetivos marcados sin problema. Como conclusión, cabe decir que, en el apartado de planificación de trayectorias, como culmen al mapeado de entornos y la detección de obstáculos, el correcto funcionamiento de la planificación plasmado en resultados prácticos supone una gran cantidad de posibilidades de desarrollo para un futuro. Al no contar con limitaciones espaciales, el dispositivo sería capaz de explorar entornos mucho más grandes que el actual. Podría moverse por dichas zonas de manera autónoma y el resultado puede ser el de tener información de un punto en particular. Sin importar el tamaño del entorno que se estudie y sin tener que desplazar una persona física hasta esa posición. Conclusiones 72 8 CONCLUSIONES Una vez presentados los resultados en el apartado anterior, con este capítulo, se pretende valorar de manera genérica el trabajo realizado. Además de hablar de los posibles avances que realizar en el futuro y de comentar las limitaciones que en el desarrollo del proyecto se han encontrado. 8.1 Conclusiones Para comenzar, es importante decir que al inicio de este proyecto nunca había trabajado si quiera con un sistema operativo Ubuntu en profundidad. La programación en terminales, los comandos útiles y el trabajo con dicho entorno, para mi han supuesto el primer reto y también el primer incentivo. Además, he sido capaz de conocer la magnitud de la comunidad de ROS que es enorme, ofrece muchas posibilidades diferentes, y ha puesto al alcance de mi mano un gran número de conocimientos. Es por ello por lo que el poder moverme en su entorno y programar en el mismo ha sido uno de los alicientes más importantes en la realización del proyecto. Cabe decir que no soy ningún experto, aún queda mucho por aprender, pero la realización del trabajo me ha supuesto un gran avance en cuanto a entendimiento con el programa se refiere. Es también importante destacar, la importancia de la comunidad de la empresa Husarion. En su foro, siempre he hallado respuestas, además de muchísima información extra. En cuanto a los objetivos de este proyecto en el apartado de visión, puedo decir que son extremadamente satisfactorios. Cabe destacar que todo lo realizado ha sido en la realidad, en ningún momento se ha empleado simulador alguno y como se ha aclarado en momentos anteriores, los inconvenientes son muchos. Estos aparecen cuando varían ciertos aspectos como son: • La luminosidad del objeto al tomar la imagen y a la hora de compararla. • La orientación o rotación del mismo en la situación en la que se encuentre. • El tiempo que transcurre detectando la señal en sí. Además de un largo etcétera que hace que cada intento sea distinto al anterior. Normalizar todo esto es muy complicado, sobre todo cuando hay una serie de factores que no dependen de uno mismo. Sin embargo, la reacción del dispositivo ante la detección de señales es un éxito y funciona correctamente. Es importante señalar que los algoritmos empleados en este apartado, así como los programas utilizados, se fundamentan en su mayoría en la biblioteca de OpenCV de la que me he nutrido a la hora de fundamentar los distintos códigos empleados en estos procesos. Por otro lado, en lo relativo al mapeado de entornos y la planificación de trayectorias los resultados obtenidos también me congratulan. En el apartado del mapeado de entornos, he sido gratamente sorprendido por la eficiencia y exactitud con la que el sistema trabaja, los distintos resultados realizados en los ensayos se adaptan a la realidad con un grado de acierto elevado. En un futuro, me gustaría hacer más hincapié en la importancia de situar dentro de un mapa objetos específicos que posteriormente puedan ser detectados mediante los sistemas de visión, con el fin de entrelazar de manera más palpable la detección de objetos y el mapeado de entornos. Hay que ser consciente de la limitación con la que trabajamos, ya que, en un principio, el mapeado de entornos se realiza solo en 2 dimensiones, lo que supone un problema a la hora de detectar obstáculos que se encuentren por encima o por debajo del sensor LIDAR. Sin embargo, con la inclusión de los sistemas de visión en el mapeado se produce un gran avance, siendo capaz de introducir la altura y por tanto una tercera dimensión. 73 Detección de señales y planificación de trayectorias en un robot móvil Para trabajos futuros, creo que es de suma importancia que este apartado se desarrolle con mayor profundidad, debido a las enormes posibilidades que ofrece en comparación con el trabajo a emplear para su inclusión. En cuanto a la planificación de trayectorias, tras haber conocido el funcionamiento del algoritmo y configurarlo para su desarrollo posterior, creo que arroja resultados muy buenos. Es importante conocer que tener que estar conectados a un monitor para poder seleccionar los puntos de destino deseados limitaba mucho el radio de funcionamiento del dispositivo. Este hecho se produce ya que la conexión de manera remota al robot se ha podido realizar en numerosas ocasiones, pero cuenta con ciertas limitaciones en mi caso. Como el hecho de no poder abrir ventanas en Rviz. En el futuro debe trabajarse de manera más profunda en el control del dispositivo de manera telemática para evitar estos problemas. Aun así, el funcionamiento de la herramienta es correcto y ha mostrado buenos resultados en la puesta en escena. En resumen, de todo lo anteriormente descrito, caben destacar las siguientes conclusiones de carácter general: • En la detección de objetos encontramos una limitación alcanzada la distancia de los 150cm. • El reconocimiento de señales funciona correctamente limitado solo por las condiciones del entorno y la restricción a figuras en 2 dimensiones. • La reacción tras la detección de objetos es correcta, pero mejoraría si se estandarizase el tiempo que el dispositivo permanece reconociendo la señal. • El mapeado de entornos se considera excelente, aunque tiene amplias posibilidades de mejora incorporando el uso de infrarrojos y uno más desarrollado de la cámara. Para así añadir una tercera dimensión • La planificación de trayectorias es la esperada. A pesar de ello, se debe profundizar en el control de manera telemática del dispositivo para aumentar el rango de funcionamiento. En el apartado de errores del proyecto se pueden destacar algunos en visión, que como se ha dicho depende de numerosas variables cambiantes y que particularizan cada ensayo. Quizás el momento en el que se capturen las imágenes que luego van a ser reconocidas, debería tener las mismas situaciones de luminosidad, orientación altura, inclinación que el momento en el que se detectan, ya que, aunque soporte cierto grado de variación, los resultados mejorarían mucho. En la detección de obstáculos empleando la visión hay un error en el encuadramiento de los conos creados como nubes de puntos por la cámara, y la detección como obstáculos por parte del LIDAR, esto se muestra en la figura 8-1 que se adjunta a continuación. Figura 8-1 Error en el mapeado Conclusiones 74 Como se ha explicado anteriormente, la inclusión de la cámara supone un gran avance en el mapeado. Aun así, su funcionamiento en concordancia con el resto de los sensores puede ser algo a tratar en un futuro. Es obvio que en nuestro caso no funciona con exactitud, ya que hay una diferencia considerable entre la nube de puntos y su posición según el LIDAR. 8.2 Limitaciones y posibles mejoras Las limitaciones que se han encontrado en este proyecto se dividen en 3 apartados, el primero de ellos es el relativo al hardware del dispositivo, su sistema operativo, es limitado, no cuenta con una gran cantidad de programas para el desarrollo de código y además tan solo cuenta con 2GB de memoria RAM, esto en un momento determinado supone que al lanzar numerosos nodos a la vez y tratar de hacer funcionar la cámara junto con el LIDAR, y alguna otra herramienta el sistema colapsa y da fallos, generalmente termina cerrando todos los programas y debemos volver a empezar. Como posible mejora no hay mucho que proponer ya que el departamento cuenta con el modelo PRO de la empresa que dobla la memoria RAM y ofrece una serie de posibilidades más amplias, si en un futuro se profundiza en este objetivo, sería recomendable trabajar con dicho modelo desde un primer momento. El segundo apartado de las limitaciones es el referido a la visión, ya se ha comentado mucho la limitación que suponen los factores externos, pero en este caso me gustaría resaltar el hecho de que nuestro programa de detección de características trabaja únicamente en 2 dimensiones, por tanto, es difícil realizar la detección de elementos u objetos en 3 dimensiones. Como por ejemplo los conos empleados en la realización de este proyecto. Como posible mejora, en un futuro creo que podría implementarse un sistema que detecte obstáculos en 3 dimensiones ya que facilitaría mucho la labor de planificación de trayectorias por ejemplo en un circuito limitado por conos. Que es la idea de la que se partía en el trabajo. En el tercer apartado de nuestras limitaciones se comentará todo lo relativo a la planificación de trayectorias. Cabe destacar que la mayor parte de las mismas ya se han explicado con anterioridad, pero a modo de resumen se dirá que el principal impedimento es la necesidad de estar conectado a un monitor de manera constante, además de tener que contar con un ratón que se encargue de la elección del punto de destino. Como posible mejora, ya se ha aclarado antes que se debería extender el uso de la pantalla portátil que puede desplazarse y seguir el dispositivo, además esta es táctil por lo que también eliminaría la necesidad de usar un ratón conectado al dispositivo. Objetivamente pienso que cada robot debe contar con una para alcanzar el máximo de posibilidades que ofrece. Como análisis general, las limitaciones encontradas son las siguientes: • Escasez de memoria RAM (2Gb) que limita el funcionamiento de varios procesos en paralelo. • Factores externos cambiantes (luminosidad, tamaño, orientación) en la detección de señales que limita el tiempo de reconocimiento de cada una de ellas. • Limitación de detección de objetos en 2 dimensiones por parte de nuestro algoritmo. • Conexión constante a monitor en la planificación de trayectorias que reduce el rango de funcionamiento. 75 Detección de señales y planificación de trayectorias en un robot móvil Anexo A guía de uso 76 ANEXO A GUÍA DE USO A. 1. Instalación de Ubuntu 18.04 en windows 10 A continuación, se explicará como se procede a la instalación del sistema operativo Ubuntu en su versión 18.04 en el sistema operativo Windows 10, esta guía será lo más breve posible y se advierte que puede variar en función del sistema operativo usado o el ordenador desde el que se parta. Los datos de partida en mi caso son los siguientes: • Portátil: Acer Aspire F5 • Sistema operativo instalado: Windows 10 • Sistema operativo que instalar: Ubuntu 18.04 LTS • Procesador: Intel Core i5 10th gen • Ram: 12Gb Seguidamente, se enumeran los pasos a seguir para realizar el proceso deseado: 1. Realizar una partición del disco duro donde se instalará el sistema operativo, esta se describe en el siguiente enlace: https://www.profesionalreview.com/2018/11/02/particionar-disco-duro-windows-10/ Figura A-1 Administrador de discos del PC 2. Descargar la imagen del sistema operativo en formato ISO, puede hacerse desde la propia página oficial ya que es gratuito: https://releases.ubuntu.com/18.04/ 3. Flashear una memoria USB de la mano del programa RUFUS cuya instalación puede realizarse mediante el siguiente enlace: https://rufus.ie/es/ 4. Modificar la Bios del ordenador configurando las prioridades de arranque del sistema para que lo haga desde el propio usb y no desde el sistema operativo preinstalado. 5. Iniciar el sistema finalmente desde la memoria USB y escoger la instalación del sistema operativo, no la prueba del mismo. 77 Detección de señales y planificación de trayectorias en un robot móvil Figura A-2 Captura instalación ubuntu 6. Elegir la instalación normal, y escoger correctamente el disco creado anteriormente para realizar la instalación Figura A-3 Proceso instalación ubuntu 7. Hecha por fin la instalación, una vez iniciado el sistema debemos pulsar la tecla F2 repetidas veces hasta que nos muestre las distintas opciones de arranque, donde se encontrará nuestro sistema operativo original y también el propio sistema Ubuntu recién instalado, puede escogerse la que se prefiera. Anexo A guía de uso 78 A. 2. Instalación alternativa. Uso de Máquina virtual Para aquellos que no les agrade el realizar una partición de discos e instalar un nuevo sistema operativo en su dispositivo se presenta una alternativa también viable que nos provee una solución a la necesidad del uso de Ubuntu. Esta consiste en el uso de una máquina virtual que nos simplifica el trabajo y no necesita tantos pasos como en el caso anterior. En este manual mostraremos la manera más sencilla de utilizar Ubuntu en tu dispositivo, aunque cabe decir que el hecho de que sea una máquina virtual y no una partición del disco nos limita el trabajo en ciertas funciones específicas. Los datos de partida son iguales al caso anterior, los pasos a seguir en este caso son los siguientes: 1. Descarga de la máquina virtual VMware Workstation PRO cuya instalación puede hacerse desde la web oficial del sistema en este enlace: https://www.vmware.com/products/workstationpro/workstation-pro-evaluation.html Figura A-4 Logo VMware (Fuente:[]) 2. Descarga de la imagen del sistema operativo en formato ISO en este caso Ubuntu 18.04 LTS de su web oficial ya mencionada en el apartado anterior. https://releases.ubuntu.com/18.04/ 3. Creación de una nueva máquina virtual dentro de VM Ware esto es fácilmente realizable desde su pantalla de inicio. No supone ningún problema. 4. En ella le ponemos el nombre que queramos como por ejemplo “Ubuntu” escogemos el tipo Linux, y la versión Ubuntu de 64 bit (en mi caso) 5. Elegimos el tamaño de memoria deseado para esta máquina y seleccionamos el archivo del sistema operativo de entre nuestros archivos. 6. Nos aparecerá una nueva máquina dentro de las ya existentes y podremos trabajar con ella con facilidad. Figura A-5 Ejemplo ventana VMware 79 Detección de señales y planificación de trayectorias en un robot móvil A. 3. Instalación de ROS Melodic Morenia Como es lógico, ROS es indispensable dentro de nuestro proyecto ya que en él se fundamenta casi todo el mismo, su instalación una vez contemos con Ubuntu en el dispositivo es bastante sencilla. En el robot tenemos la suerte de ya viene instalado de fábrica y por tanto podemos trabajar directamente con el mismo. Sin embargo, en el PC seremos nosotros los que instalemos el programa. Recordemos que la instalación se hace en el sistema operativo Ubuntu 18.04 LTS, y la versión de ROS es Melodic Morenia. Para ello seguiremos los siguientes pasos: 1. Configurar los repositorios de Ubuntu para permitir la instalación de cualquier fuente. Esto se explica en la siguiente guía: https://help.ubuntu.com/community/Repositories/Ubuntu 2. Abrir una ventana de terminal dentro de Ubuntu 3. Configuración del dispositivo para que acepte el software de packages.ros.org mediante el siguiente comando en la terminal: sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc /apt/sources.list.d/ros-latest.list' 4. Se configuran e introducen las claves de acceso para permitir la instalación en el sistema mediante el siguiente comando: sudo apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1 CF6E31E6BADE8868B172B4F42ED6FBAB17C654 5. Se actualiza el paquete debian mediante el siguiente comando: sudo apt update Es posible que cuando hagamos esto nos demande la clave de acceso predefinida para acceder al sistema operativo. 6. Instalación de ROS, existen varios paquetes distintos, algunos más livianos con menos programas y otros completos que cuentan con todas las herramientas, nosotros instalaremos el paquete completo, mediante la siguiente orden: sudo apt install ros-melodic-desktop-full Una vez hecho esto ya contamos con ROS en nuestro dispositivo de manera física. 7. Configuración del entorno añadimos las nuevas variables automáticamente a nuestra sesión de bash con el siguiente comando. echo "source /opt/ros/melodic/setup.bash" >> ~/.bashrc source ~/.bashrc y con esto hemos terminado con la instalación e ROS, podemos probarlo mediante el uso de la orden “roscore” que iniciará la tarea maestra. Anexo B Archivos Programados 86 B. 4. Archivo para iniciar el mapeado de entornos: Maping.launch 87 Detección de señales y planificación de trayectorias en un robot móvil B. 5. Congiuración de parámetros comunes para el mapeado de obstáculos: costmap_common_params.yaml Anexo B Archivos Programados 88 B. 6. Congiuración de parámetros locales para el mapeado de obstáculos: costmap_local_params.yaml B. 7. Congiuración de parámetros globales para el mapeado de obstáculos: costmap_global_params.yaml 89 Detección de señales y planificación de trayectorias en un robot móvil B. 8. Parámetros para la planificación de trayectorias: trajectory_planner.yaml Anexo B Archivos Programados 90 B. 9. Archivo que ejecuta la planificación de trayectorias: Path_planning.launch 91 Detección de señales y planificación de trayectorias en un robot móvil B. 10. Parámetros para la exploración autónoma: exploration.yaml Anexo B Archivos Programados 92 B. 11. archivo que ejecuta la exploración autónoma: exploration.launch 93 Detección de señales y planificación de trayectorias en un robot móvil Anexo B Archivos Programados 94 B. 12. Ejemplo de CMakeLists.txt 95 Detección de señales y planificación de trayectorias en un robot móvil REFERENCIAS 1 Husarion Manuals. (2021) Autonomous Mobile Robots [Online]. https://husarion.com/manuals/ 2 Blog Medium. (2018) Detección de objetos en Tiempo Real con python y OpenCV [Online]. https://medium.com/@di3cruz/detecci%C3%B3n-de-objetos-en-tiempo-real-con-python-y-opencv- e760fdaad58e 3 Introlab. (2020) wiki de la función find_object. [Online] http://introlab.github.io/find-object/ 4 Blog Pocket Link. (2020) Ejemplo funcionamiento LIDAR en iphone. [Online] https://www.pocketlint.com/es-es/tabletas/noticias/apple/151476-que-es-lidar-ipad-por-que-arkit-medida 5 Slamtec. (2021) proveedor de sensores LIDAR del ROSbot2.0. [Online] http://www.slamtec.com/en/Lidar/A2 6 Wiki de ROS. (2017) información sobre el nodo “tf”. [Online] http://wiki.ros.org/tf 7 Ubuntu (2018) información y descarga del sistema operativo 18.04 LTS. [Online]. https://ubuntu.com/#community 8 Wiki de ros melodic morenia (2018) información de descarga e instalación del software. [Online]. http://wiki.ros.org/melodic 9 Biblioteca de proyectos fing (2017) Integración y funcionamiento de ROS en un S.O. [Online]. https://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Integracion_ros_butia 10 Husarion Community (2021) Blog de preguntas y respuestas sobre el funcionamiento de los dispositivos. [Online]. https://community.husarion.com/ 11 Wiki de ROS (2021) biblioteca de nodos y tópicos. [Online]. http://wiki.ros.org/es 12 Husarion tutorials (2021) tutoriales de manejo y programación del ROSbot2.0 [Online]. https://husarion.com/tutorials/ 13 Github (2021) foro de preguntas y respuestas a cerca de software. [Online]. https://github.com/ 14 Marve (2015) Empresa de señalización y seguridad. [Online]. http://www.marve.es/ 15 Visión artificial en Wikipedia (2021) Fundamentos de la visión artificial. [Online]. https://n9.cl/k43m1 16 Research gate. Image Matching using SIFT, SURF, BRIEF and ORB. [Online]. https://n9.cl/t9io5 17 Wiki de ROS nodo de RPLIDAR. (2017) información y desarrollo del nodo. [Online] http://wiki.ros.org/rplidar 18 Wiki de ROS nodo de Gmapping. (2017) información y desarrollo del nodo. [Online] http://wiki.ros.org/gmapping