Sistema de detección de obstáculos para robot móvil SUMMIT

i Equation Chapter 1 Section 1 Trabajo Fin de Máster Máster Universitario en Ingeniería Industrial Sistema de detección de obstáculos para robot móvil SUMMIT Autor: Manuel Mora Nieto Tutor: Miguel Ángel Ridao Carlini Tutor externo: Ramón Andrés García Rodríguez Dep. de Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 i Trabajo Fin de Máster Máster Universitario en Ingeniería Industrial Sistema de detección de obstáculos para robot móvil SUMMIT Autor: Manuel Mora Nieto Tutor: Miguel Ángel Ridao Carlini Catedrático de Universidad Tutor externo: Ramón Andrés García Rodríguez Dep. de Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 iii Trabajo Fin de Máster: Sistema de detección de obstáculos para robot móvil SUMMIT Autor: Manuel Mora Nieto Tutor: Miguel Ángel Ridao Carlini Tutor externo: 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, 2020 El Secretario del Tribunal v A mi familia A mis maestros vii Agradecimientos Con este trabajo cierro otra importante etapa de mi vida. Es el paso final para convertirme en Ingeniero Industrial de manera oficial tras varios años de continua formación. Ha sido un camino duro, por lo que no quiero dejar de mencionar a toda mi familia y amigos por sus ánimos, consejos y, en definitiva, acompañarme en esta etapa. Gracias a mi tutores Miguel Ángel y Ramón por estar siempre disponibles y asesorarme a lo largo del trabajo. Con ellos el trabajo ha sido más fácil. Por último, debo agradecer a la Universidad de Sevilla, y en concreto al Departamento de Ingeniería de Sistemas y Automática de la Escuela Técnica Superior de Ingeniería, el esfuerzo que realizan para que los alumnos puedan acceder a tareas propias de la investigación. Poder contar con la plataforma robótica para el desarrollo de este trabajo ha sido una gran oportunidad para seguir aprendiendo y para confirmar, aún más si cabe, mi pasión por la robótica. Manuel Mora Nieto Alumno de la Escuela Técnica Superior de Ingeniería de la Universidad de Sevilla Sevilla, 2020 xiv 4.5.3 OctoMap en ROS 46 5 Resultados 49 5.1 Filtro para la medida del lidar 49 5.2 Interiores 53 5.3 Exteriores 57 6 Conclusiones 65 6.1 Conclusiones 65 6.2 Limitaciones y mejoras futuras 68 Anexo. Manual de usuario 71 A. 1. Actualización de Ubuntu y ROS 71 A. 2. Descarga packages y simulación completa 72 A. 3. Conexión real con el Summit-XL 74 A. 4. Configuración y visualización de RViz 77 A. 5. Corrección visualización sensores 79 A. 6. Descarga package mapeado e implementación del filtro 80 A. 7. Lanzamiento proyecto completo 82 Bibliografía 85 Glosario 87 xv ÍNDICE DE TABLAS Tabla 4-1. Estudio de alcance de los sensores lidar y cámara 34 Tabla 4-2. Comparativa de valores del campo de visión vertical del lidar CE30-C Benewake 38 Tabla 4-3. Coordenadas respecto a los ejes del lidar CE30-C Benewake de los puntos límites de su campo de visión horizontal 38 Tabla 4-4. Comparativa de valores del campo de visión vertical de la cámara Orbbec Astra 40 Tabla 4-5. Tabla resumen de los puntos característicos del campo de visión vertical 41 Tabla 4-6. Coordenadas respecto a los ejes de la cámara Orbbec Astra de los puntos límites de su campo de visión horizontal 42 Tabla 4-7. Estudio de precisión en interiores para lidar y cámara 44 Tabla 4-8. Estudio de precisión en exteriores para lidar y cámara 44 Tabla 4-9. Tipos de voxel en la representación de OctoMap 46 xvii ÍNDICE DE FIGURAS Figura 1-1. Proyecto de investigación OCONTSOLAR (Fuente: [3]) 2 Figura 2-1. Vista frontal del Summit-XL 5 Figura 2-2. Vista lateral del Summit-XL 5 Figura 2-3. Dimensiones del Summit-XL (Fuente: [6]) 6 Figura 2-4. Elementos externos del Summit-XL (Fuente: [4]) 6 Figura 2-5. Panel trasero del Summit-XL 6 Figura 2-6. Configuración diferencial para robots móviles (Fuente: [7]) 7 Figura 2-7. Tipos de rueda para robots móviles con configuración diferencial (Fuente: [8]) 7 Figura 2-8. Elementos internos del Summit-XL (Fuente: [4]) 8 Figura 2-9. Ejemplo a nivel gráfico de un sistema ROS 9 Figura 2-10. Ejemplo de simulación en Gazebo 10 Figura 2-11. Ejemplo de visualización de datos en RViz 10 Figura 2-12. Ejemplo de grafo obtenido con rqt_graph 11 Figura 3-1. Situación cámara y lidar en el Summit-XL 13 Figura 3-2. Principio de funcionamiento basado en ToF del lidar CE30-C Benewake (Fuente: [18]) 14 Figura 3-3. Detalle del lidar CE30-C Benewake y sus componentes (Fuente: [18]) 14 Figura 3-4. Campo de visión del lidar CE30-C Benewake (Fuente: [18]) 14 Figura 3-5. Rango de detección del lidar CE30-C Benewake (Fuente: [18]) 15 Figura 3-6. Zona ciega del Lidar CE30-C Benewake (Fuente: [18]) 15 Figura 3-7. Detalle de la cámara RGBD Orbbec Astra y sus componentes (Fuente: [20]) 16 Figura 4-1. Simulación del trabajo de [1]. A la izquierda, visualización del mapa 2D en RViz e imagen en tiempo real de la cámara. A la derecha, simulación en Gazebo que da lugar a ese mapa 19 Figura 4-2. Controles del mando de PS4 para teleoperación (Fuente: [4]) 21 Figura 4-3. Vista frontal de la escena de pruebas 22 Figura 4-4. Vista lateral de la escena de pruebas 22 Figura 4-5. Nube de puntos del lidar 22 Figura 4-6. Nube de puntos de la cámara 23 Figura 4-7. Nubes de puntos del lidar y la cámara 23 Figura 4-8. Escenario de pruebas offset 24 Figura 4-9. Ilustración del offset de profundidad 24 Figura 4-10. Medida de la distancia del robot a la nube de puntos del lidar 25 Figura 4-11. Medida de la distancia del robot a la nube de puntos de la cámara 25 Figura 4-12. Representación de los ejes de los sensores para confirmar la situación previa de la cámara en el modelo URDF del robot 26 xviii Figura 4-13. Resultado del ajuste de la cámara en el modelo URDF del robot 26 Figura 4-14. Representación de las dos nubes de puntos tras el ajuste de la cámara 27 Figura 4-15. Medida proporcionada por el lidar tras el ajuste de la cámara 27 Figura 4-16. Medida proporcionada por la cámara tras su ajuste 27 Figura 4-17. Ilustración 1 del offset de altura 28 Figura 4-18. Ilustración 2 del offset de altura 28 Figura 4-19. Ilustración offset altura con mapas 29 Figura 4-20. Confirmación de altura correcta de los obstáculos representados por la cámara 29 Figura 4-21. Representación errónea del lidar en el modelo URDF del robot 30 Figura 4-22. Resultado del ajuste del lidar en el modelo URDF del robot 30 Figura 4-23. Representación de la nube de puntos del lidar tras su ajuste 31 Figura 4-24. Representación del mapa obtenido con el lidar tras su ajuste 31 Figura 4-25. Visión del nodo relay de manera global dentro del trabajo 32 Figura 4-26. Escenario de pruebas fusión lidar y cámara 32 Figura 4-27. Vistas frontal, lateral y superior de la nube de puntos del lidar 33 Figura 4-28. Vistas frontal, lateral y superior de la nube de puntos de la cámara 33 Figura 4-29. Vistas frontal, lateral y superior de las dos nubes de puntos 33 Figura 4-30. Nube de puntos para lidar (izquierda) y cámara (derecha) con obstáculo alejado 35 Figura 4-31. Nube de puntos para lidar (izquierda) y cámara (derecha) con obstáculo fuera de sus zonas ciegas 35 Figura 4-32. Nube de puntos para lidar (izquierda, con distorsión) y cámara (derecha, sin detección) con obstáculo dentro de sus zonas ciegas 35 Figura 4-33. Resumen de la zona ciega del lidar (izquierda) y la cámara (derecha) 36 Figura 4-34. Vista lateral del campo de visión del lidar CE30-C Benewake (Imagen original cedida por Robotnik con modificaciones de elaboración propia) 36 Figura 4-35. Campo de visión horizontal del lidar CE30-C Benewake obtenido experimentalmente 39 Figura 4-36. Vista lateral del campo de visión de la cámara Orbbec Astra (Imagen original cedida por Robotnik con modificaciones de elaboración propia) 40 Figura 4-37. Resumen campo de visión vertical (Imagen original cedida por Robotnik con modificaciones de elaboración propia) 41 Figura 4-38. Campo de visión horizontal de la cámara Orbbec Astra obtenido experimentalmente 42 Figura 4-39. Resumen campo de visión horizontal (Imagen original cedida por Robotnik con modificaciones de elaboración propia) 43 Figura 4-40. Ejemplo del procedimiento para el estudio de precisión de sensores 44 Figura 4-41. Representación del espacio tridimensional en voxels y su correspondencia con una estructura en árbol (Fuente: [24]) 46 Figura 5-1. Nube de puntos del lidar en el problema de ruido 49 Figura 5-2. Nube de puntos del lidar en el problema de ruido sin el modelo del robot 50 Figura 5-3. Representación del mapa 3D por el lidar con ruido 50 Figura 5-4. Representación del mapa 3D por el lidar con ruido sin el modelo del robot 50 xix Figura 5-5. Hilera de puntos ocupados que queda en el mapa 3D tras el paso del robot 51 Figura 5-6. Nube de puntos del lidar en el filtro solución 51 Figura 5-7. Nube de puntos del lidar en el filtro solución sin el modelo del robot 52 Figura 5-8. Representación del mapa 3D por el lidar sin ruido 52 Figura 5-9. Representación del mapa 3D por el lidar sin ruido y sin el modelo del robot 52 Figura 5-10. Resultado de mover el robot sin dejar hilera de puntos a su paso en el mapa 3D 53 Figura 5-11. Escenario de pruebas general para interiores 53 Figura 5-12. Zona 1 del escenario de pruebas para interiores 54 Figura 5-13. Zona 2 del escenario de pruebas para interiores 54 Figura 5-14. Zona 3 del escenario de pruebas para interiores 54 Figura 5-15. Zona 4 del escenario de pruebas para interiores 54 Figura 5-16. Mapa 3D del lidar para interiores 54 Figura 5-17. Mapa 2D del lidar para interiores 55 Figura 5-18. Mapas 2D y 3D del lidar para interiores 55 Figura 5-19. Mapa 3D de la cámara para interiores 55 Figura 5-20. Mapa 2D de la cámara para interiores 56 Figura 5-21. Mapas 2D y 3D de la cámara para interiores 56 Figura 5-22. Mapa 3D de la fusión para interiores 56 Figura 5-23. Mapa 2D de la fusión para interiores 57 Figura 5-24. Mapas 2D y 3D de la fusión para interiores 57 Figura 5-25. Escenario de pruebas para exteriores general 58 Figura 5-26. Zona 1 escenario pruebas para exteriores 58 Figura 5-27. Zona 2 escenario pruebas para exteriores 58 Figura 5-28. Primera parte del recorrido para exteriores 58 Figura 5-29. Segunda parte del recorrido para exteriores 58 Figura 5-30. Tercera parte del recorrido para exteriores 59 Figura 5-31. Cuarta parte del recorrido para exteriores 59 Figura 5-32. Quinta parte del recorrido para exteriores 59 Figura 5-33. Sexta parte del recorrido para exteriores 59 Figura 5-34. Mapa 3D del lidar para exteriores 59 Figura 5-35. Mapa 2D del lidar para exteriores 60 Figura 5-36. Mapas 2D y 3D del lidar para exteriores 60 Figura 5-37. Mapa 3D de la cámara para exteriores 60 Figura 5-38. Mapa 2D de la cámara para exteriores 61 Figura 5-39. Mapas 2D y 3D de la cámara para exteriores 61 Figura 5-40. Mapa 3D de la fusión para exteriores 61 Figura 5-41. Mapa 2D de la fusión para exteriores 62 Figura 5-42. Mapas 2D y 3D de la fusión para exteriores 62 Figura 5-43. Mapa 3D de la fusión para exteriores con altura máxima detectable de 1 metro 63 xx Figura 5-44. Mapa 2D de la fusión para exteriores con altura máxima detectable de 1 metro 63 Figura 5-45. Mapas 2D y 3D de la fusión para exteriores con altura máxima detectable de 1 metro 63 Figura 6-1. Escenario de pruebas para desnivel 66 Figura 6-2. Robot al borde de la caída 66 Figura 6-3. Visualización de la nube de puntos del lidar con robot al borde de la caída 67 Figura 6-4. Visualización de la nube de puntos de la cámara con robot al borde de la caída 67 Figura 6-5. Robot más alejado de la caída 67 Figura 6-6. Visualización de la nube de puntos del lidar con el robot más alejado de la caída 68 Figura 6-7. Visualización de la nube de puntos de la cámara con el robot más alejado de la caída 68 Figura A-0-1. Resultado de arrancar el PC con el Pen Drive con la imagen montada de Ubuntu 71 Figura A-0-2. Resultado de ejecutar rqt_graph tras una simulación con teleoperación 74 Figura A-0-3. Aspecto de la pantalla de interacción con el Summit-XL en su programa principal 76 Figura A-0-4. Aspecto del apartado de la batería en el HMI del robot 77 Figura A-0-5. Resultado de consultar el topic con información del estado de la batería 77 Figura A-0-6. Configuración usada para RViz 78 1 1 INTRODUCCIÓN os avances en tecnología son diarios y cada vez se consiguen teorías, métodos y productos más sofisticados dentro de la misma. Esto tiene una clara ventaja, ya que permite al ser humano comprender mejor el entorno en el que vive y el comportamiento de la naturaleza. Con ello, buscamos la comodidad en nuestra vida diaria con dispositivos que hagan tareas antes reservadas únicamente a humanos. Entre otros, destaca el papel de la Inteligencia Artificial, en la que hay muchas aplicaciones que permiten tareas arduas de clasificación, reconocimiento o tratamiento de datos en general que se pueden resolver con técnicas de Deep Learning, algo cada vez más importante en la era del Big Data en la que nos encontramos. Pero sacar partido a todas las ventajas posibles supone un gran reto. En concreto, el uso de diferentes avances tecnológicos en conjunto tendrá más repercusión que usarlos cada uno por separado. Con esto me refiero a tratar grandes problemas a los que se enfrenta actualmente el ser humano, como puede ser el cambio climático. Se requiere de un esfuerzo enorme en el que equipos multidisciplinares deben buscar la integración de diferentes tecnologías avanzadas para que nos hagan la vida más fácil y también más limpia. Todo lo anterior tiene ciertamente que ver con este trabajo. En lo que se refiere a avances tecnológicos nos encontramos con el crecimiento exponencial de la robótica, motivado entre otros factores por una mejora de los sensores que se emplean y el tratamiento que se dé le da a la información que se recibe de los mismos. El robot empleado cuenta con dos sensores clave en la percepción del entorno y que están a la última en sensorización, como son el lidar 3D y la cámara RGBD. Por otro lado, con la aplicación de este robot junto a otros, se pretende buscar nuevas técnicas para mejorar el control en plantas solares, contribuyendo así a un uso más eficiente de los recursos que posee el humano. 1.1 Marco contextual Este Trabajo Fin de Máster (TFM) surge en primera instancia como la continuación de los trabajos que realicé en 2018 en el Trabajo Fin de Grado (TFG) [1]. Aquel trabajo, denominado Integración de sistema láser y visión en la navegación de un robot móvil, se basó en la construcción de un mapa 2D de obstáculos del entorno para usarlo en un futuro para navegación autónoma del Summit-XL. Para ello se contaba con un sensor láser sobre el chasis del robot que permitía hacer un barrido de 270º a la altura que se encontraba. Como ese sensor sólo detectaba obstáculos a la altura del láser, se incluyó un tratamiento de imágenes con la cámara PTZ del robot apuntando al suelo y tratando de detectar objetos conocidos en él. En concreto, reconocía agujeros oscuros, estimaba su posición y tamaño y los incluía en el mapa 2D que se obtenía con el láser. Sin embargo, debido a la disponibilidad del ejemplar del Summit-XL que poseía el grupo de investigación en aquellas fechas, no se pudieron probar los algoritmos en el robot real. Por tanto, el trabajo se basó en simulación con la herramienta Gazebo y, por supuesto, en la familiarización con el framework ROS (Robot Operating System), algo a lo que haremos alusión en varias ocasiones a lo largo de esta memoria para evitar repeticiones innecesarias. Así, la primera idea es empezar a probar los algoritmos desarrollados en 2018 para el nuevo ejemplar del Summit-XL recién adquirido por el grupo de investigación Automática y Robótica Industrial. Esto supone una actualización de las versiones de Ubuntu y ROS y, lo más importante, el hardware correspondiente a los sensores láser y cámara son distintos a los empleados en el TFG. Ahora, tanto lidar como cámara tienen posibilidades de percepción 3D del entorno, con lo que el problema de las alturas de los obstáculos parece quedar más completo. De esta manera, el enfoque y objetivos del trabajo son algo distintos, quedando recogidos en el apartado 1.2. L Introducción 2 En este punto hay que mencionar que la finalidad última del robot será intervenir en el proyecto de investigación OCONTSOLAR (Optimal Control of Thermal Solar Energy Systems) [2] y [3], cuyo logo aparece representado en la Figura 1-1. Figura 1-1. Proyecto de investigación OCONTSOLAR (Fuente: [3]) El proyecto está dirigido por el grupo de investigación Automática y Robótica Industrial de la Universidad de Sevilla. Se buscan nuevas técnicas para sistemas de control de plantas solares térmicas que, entre otras, incluyan sensores móviles, bien aéreos (drones) o bien terrestres (UGV). Se espera que estos sensores sirvan para ofrecer las estimaciones y predicciones necesarias para la implementación de las conocidas técnicas de Control Predictivo por Modelo (o más conocido por Model Predictive Control, MPC) que a día de hoy se emplean en el control de estos sistemas. Se trata de una aplicación particular de lo que podrían ser nuevos sistemas de control que incluyan sensores móviles, por lo que podría extenderse a otros ámbitos de aplicación en un futuro. En cualquier caso, hay que ser capaz de controlar esos dispositivos móviles para tratar de que su navegación sea autónoma, de una manera segura y fiable. Es ahí donde entra la robótica y con este trabajo se pretende entablar el camino hacia esa autonomía de los vehículos terrestres. 1.2 Objetivo del trabajo Principalmente, en este trabajo se pretende la construcción de un mapa de obstáculos del entorno lo más completo posible para que sea fiable de cara a la futura navegación autónoma. Dicho mapa debe incluir obstáculos con los que el robot pueda colisionar. Teniendo en cuenta que el punto más alto del robot es el bloque para GPS, a una altura de unos 80cm, se deben tener en cuenta por seguridad todos los obstáculos desde el suelo hasta una altura aproximada de un metro. Al estar aún en fase inicial, el mapa se construirá teleoperando y supervisando al robot. Se hará un estudio de la información que podemos usar de los sensores lidar y cámara, para ver las ventajas que ofrece cada uno y tratar de aprovecharlas al máximo. En concreto, se pretende comprobar el alcance, ángulo de visión y precisión de las nubes de puntos que muestran las distancias a obstáculos y ofrecen tanto el lidar 3D como el canal de profundidad o depth de la cámara RGBD. Por último, y en relación a lo trabajado en [1], se persigue la continuidad de lo aprendido sobre ROS. Con ello se busca sacar partido a la dura curva de aprendizaje del entorno tras haber superado la parte más tediosa de iniciación. Esto es, aprender a usar este framework y llegar a desenvolverse con soltura en él requiere bastante tiempo y esfuerzo, y en este caso se cuenta con la experiencia del TFG. De esta manera, continuar aprendiendo ROS con una plataforma robótica disponible en el laboratorio aumenta en gran medida las posibilidades de desarrollo y permite enfrentarnos a otros problemas que no existen en el idílico mundo de la simulación. 1.3 Metodología empleada Para llevar a cabo los objetivos anteriormente citados, se han seguido una serie de pasos:  Actualización de Ubuntu y ROS en el PC.  Obtención de información acerca del nuevo Summit-XL de [4] y códigos de partida de [5] para 3 Sistema de detección de obstáculos para robot móvil SUMMIT pruebas de simulación previas.  Repaso del TFG para refrescar conceptos sobre ROS y la plataforma robótica Summit-XL. Simulación en Gazebo del mismo en la nueva versión de Ubuntu y ROS con los sensores usados en [1].  Conexión real al Summit-XL en remoto desde nuestro PC y teleoperación con mando de PS4.  Visión de información de los sensores en RViz, estudio e integración de los mismos.  Obtención de la librería para el mapeado 3D e inclusión en el ordenador de a bordo del Summit-XL. Pruebas de obtención de mapas 3D y 2D en entornos de interiores en el laboratorio.  Pruebas en exteriores para mapeado del Summit-XL. A la vista de lo anterior, la memoria se divide en diferentes partes. A esta introducción le sigue un capítulo de descripción del robot, en el que se trata de mostrar los diferentes sistemas que lo componen. En concreto, se verán la arquitectura hardware y software de la plataforma robótica. El capítulo 3, está reservado para los sensores cámara y lidar. De nuevo, es un capítulo descriptivo para conocer mejor los dispositivos a través de los cuáles el robot obtiene información del entorno. Es en el capítulo 4 donde se concentra la mayor parte del trabajo llevado a cabo con el Summit-XL. En primer lugar, se expone la información previa que tenemos de esta plataforma robótica, desde trabajos realizados previamente hasta el software disponible. Una vez conocida bien la situación de partida, se pretende mostrar el lanzamiento e inicialización del robot, así como la visualización de la información que es capaz de capturar. Esto nos permite llevar a cabo un estudio y análisis de los sensores, teniendo que realizar una serie de correcciones para posteriormente fusionarlos de manera correcta. También en este capítulo se presenta la librería Octomap, herramienta fundamental en la construcción de mapas 3D en ROS. Con la exposición de sus características principales y la metodología empleada en la construcción de mapas se pretende justificar su elección como procedimiento fiable en este trabajo. Los resultados serán analizados en el capítulo 5. Se mostrarán diferentes situaciones de construcción de mapas 3D y conversión a 2D tanto en interiores como en exteriores. Por último, se cierra la memoria con el capítulo 6, dedicado a las conclusiones de este trabajo y a los trabajos futuros que quedan pendiente con la plataforma Summit-XL. Al igual que se hizo en [1], se incluye al final de la memoria un “Anexo. Manual de usuario” que pretende tratar temas menos descriptivos como son la obtención de código, modificación de parámetros e incluso algo que a veces suele ser más problemático, como es la conexión real de manera remota con el robot. Summit-XL 10 2.2.2 Herramientas complementarias En primer lugar, aunque contamos con el robot real, siempre es aconsejable contar con una herramienta de simulación que nos permita realizar pruebas rápidas y previas. En este contexto, ROS cuenta con Gazebo, entorno de simulación bastante realista donde podemos simular diferentes escenarios o worlds e incluir nuestro robot a través del formato URDF (Unified Robot Description Format). A través de plugins, Gazebo nos permite interaccionar con el entorno, obteniendo información del medio y enviándosela cuando sea necesario. En la Figura 2-10, se puede observar un ejemplo de una simulación en dicho entorno en un escenario con obstáculos. Figura 2-10. Ejemplo de simulación en Gazebo El complemento imprescindible para este trabajo ha sido sin lugar a dudas el visualizador de datos RViz, cuyo aspecto se puede ver en la Figura 2-11, imagen tomada en una prueba real con el robot en el laboratorio (la configuración de la pantalla puede verse en el “Anexo. Manual de usuario”). Usando de nuevo el modelo URDF del robot, podemos añadir Displays a la pantalla que nos permiten obtener información de los sensores en tiempo real. En nuestro caso, se ha empleado principalmente para analizar la información obtenida por el lidar y la cámara y para la representación de los mapas de obstáculos en 3D y 2D. Figura 2-11. Ejemplo de visualización de datos en RViz Otra herramienta que por su contenido gráfico es de gran utilidad es rqt_graph. Básicamente nos permite ver esquemas como el de la Figura 2-9 para nuestro robot. De esta manera podemos ver rápidamente cómo está 11 Sistema de detección de obstáculos para robot móvil SUMMIT conectada la red de nodos de nuestro sistema e identificar subsistemas dentro de él. En la Figura 2-12 se muestra a modo de ejemplo el grafo obtenido en una simulación sencilla. Se explicará cómo acceder a esta herramienta de ROS en el “Anexo. Manual de usuario”. Figura 2-12. Ejemplo de grafo obtenido con rqt_graph Por último, hay que mencionar la librería que permite la representación de mapas de obstáculos en 3D: OctoMap. Emplea una técnica eficiente en la construcción de mapas y es de código abierto escrito en lenguaje C++, lo que permite la conexión con ROS [16]. Será objeto de la parte final del capítulo 4, en el que explicaremos más en detalle su funcionamiento. 13 3 DESCRIPCIÓN DE SENSORES n este capítulo se analizan los sensores principales para la elaboración del mapa: el lidar y la cámara. Si bien es cierto que una tarea implícita importante es la estimación de la posición con sensores como la IMU o el GPS, es algo en lo que no nos centramos. Se describirán, por tanto, los dos sensores, presentando sus características, ventajas, inconvenientes y principios de funcionamiento. 3.1 Descripción A continuación pasamos a describir las características y el funcionamiento de la cámara y el lidar, cuya situación en el robot podemos ver en la Figura 3-1. Figura 3-1. Situación cámara y lidar en el Summit-XL 3.1.1 Lidar CE30-C Benewake El sensor lidar que posee el robot es un lidar 3D de estado sólido fabricado y distribuido por la empresa Benewake [17]. Es apto para escáner 3D y está pensado, entre otras cosas, para incorporarse a robots. Su SDK funciona en Linux y el lenguaje de programación es C++ [18], por lo que es perfectamente integrable con ROS. Este sensor está basado en el ToF (Time of Flight o Tiempo de Vuelo) de la luz modulada cercana a la infrarroja, cuya longitud tiene un pico de 850nm. A través de esta técnica, como puede observarse en la Figura 3-2, un emisor envía la luz y un receptor la recibe en caso de que la onda llegue a un obstáculo, que la refleja. Calculando la diferencia de fase y tiempo entre la luz emitida y recibida, es capaz de obtener información de la distancia y posición del objeto respecto al lidar. En la Figura 3-3 puede verse su apariencia, siendo el receptor identificado con el número 2 (Reception panel) y el emisor con el número 3 (Emitting panel). E Descripción de sensores 14 Figura 3-2. Principio de funcionamiento basado en ToF del lidar CE30-C Benewake (Fuente: [18]) Figura 3-3. Detalle del lidar CE30-C Benewake y sus componentes (Fuente: [18]) Según la hoja de datos del fabricante [18], tiene una resolución de 320x24 píxeles (que pasa a ser de 660x24 tras la acción del SDK) a una velocidad de captura de 20fps, un tiempo de respuesta de 200ms y un rango de resolución de 1cm. El FOV o campo de visión es de 132º en la horizontal y 9º en la vertical, quedando un campo de visión con la forma mostrada en la Figura 3-4. Figura 3-4. Campo de visión del lidar CE30-C Benewake (Fuente: [18]) La conexión con la CPU del robot es a través de interfaz TCP con cable Ethernet y el rango de detección está entre 0.1 y 4 metros para zonas centradas en el FOV y entre 0.1 y 2 metros en los bordes de dicho FOV, como puede verse en la Figura 3-5. La precisión es menor o igual a 6cm. En cualquier caso, según el fabricante, todos los datos reflejados en esta descripción están probados en entornos oscuros de interiores y para objetos de cartón blanco cuya reflectividad es del 90%. Para objetos con otras reflectividades habrá que acudir al manual de usuario para ver cómo podrían variar las características. Además, en entornos de exteriores se pierde precisión y sobre todo alcance debido el aumento de luz natural. 15 Sistema de detección de obstáculos para robot móvil SUMMIT Figura 3-5. Rango de detección del lidar CE30-C Benewake (Fuente: [18]) Las ventajas principales de este tipo de sensor son carecer de elementos rotativos como los que suelen tener los escáneres, lo que mejora su fiabilidad en términos mecánicos, y que, a pesar de ello, posee un campo de visión bastante amplio. En concreto, el campo de visión vertical le permite detectar objetos a diferentes alturas como no lo hacen muchos escáneres en los que la única altura detectable es a la que emiten el haz de luz. Sin embargo, como señala el fabricante, tiene el inconveniente de que empeora sus prestaciones en entornos exteriores. Otra desventaja es que su campo de visión posee una Blind Zone o zona ciega en las distancias próximas al sensor, que se corresponde con la zona gris de la Figura 3-6 que se encuentra dentro de la zona de visión (por encima de las líneas negras). Figura 3-6. Zona ciega del Lidar CE30-C Benewake (Fuente: [18]) Descripción de sensores 16 Por último, hay diferentes formas de obtener la información del lidar:  Imagen de profundidad: consiste en una sola matriz de píxeles de tamaño 320x24 en el dispositivo y de 660x24 en el software, en la que cada píxel contiene la información de distancia de ese punto correspondiente a la imagen real respecto al lidar. Se trata en ROS como un mensaje del tipo sensors_msgs/Image. No se usará en este proyecto.  Nube de puntos de profundidad: se trata de un mensaje de ROS del tipo sensors_msgs/PointCloud2 que ofrece un conjunto de puntos dentro del rango, alcance y campo de visión del lidar cuyas posiciones en el espacio corresponden a obstáculos detectados. Es un tipo de dato útil para la construcción de mapas, por lo que será el que usaremos. 3.1.2 Cámara Orbbec Astra La serie Astra [19] es un tipo de cámara con capacidad de visión 3D que comercializa la empresa Orbbec. Se denomina cámara RGBD porque combina la información de color de una cámara RGB (Red, Green, Blue) con la de profundidad del canal depth D, basado en un par emisor-receptor de luz infrarroja similar a como lo hace el lidar descrito previamente. En la Figura 3-7 puede identificarse el receptor de imagen a color como RGB Sensor, el emisor de infrarrojo como Projector y el receptor de infrarrojo como IR Sensor. La medida de la profundidad se realiza haciendo uso nuevamente de la técnica ToF, que permite calcular la distancia de la cámara a un obstáculo en función del tiempo que tarde el haz de luz desde que es enviado por el emisor hasta que es capturado por el receptor tras el rebote en el obstáculo. Según la hoja de datos del fabricante [20], tanto la imagen RGB de vídeo captada como la de profundidad tienen una resolución de 640x480 píxeles a una velocidad de captura de 30fps. El FOV es de 60º en la horizontal, 49.5º en la vertical y 73º en la diagonal. Se conecta a la CPU y alimentación a través de USB 2.0 y opera en un rango entre los 0.4 y los 6 metros. La precisión que se consigue está entre ±1 y ±3mm en distancias en torno a un metro y de ±12.7mm en torno a los 2-3 metros. Además, entre sus aplicaciones típicas [19] se encuentra la visión robótica y, en particular, el mapeado, siendo compatible con ROS y ajustándose en gran medida a los requerimientos de este proyecto. Figura 3-7. Detalle de la cámara RGBD Orbbec Astra y sus componentes (Fuente: [20]) Al igual que ocurre con el lidar, la cámara empeora sus prestaciones en el exterior debido a que aumenta la luz natural, por lo que la precisión y alcance serán menores que los proporcionados por el fabricante. Por otro lado, aunque el fabricante no lo especifica explícitamente, se verá en los próximos apartados cómo también presenta una especie de zona ciega. Si miramos los datos del fabricante, parece que la cámara ofrecerá un ángulo de visión vertical y un alcance para zonas centradas en el FOV mayor que el lidar. Lo primero es una ventaja del uso de la cámara, ya que permitirá aumentar el rango de alturas detectables. Sin embargo, el mayor alcance sólo se producirá para condiciones favorables de iluminación, tal y como veremos en el análisis real de los sensores del capítulo 4. En cuanto a los datos que proporciona la cámara, tenemos tres opciones: 17 Sistema de detección de obstáculos para robot móvil SUMMIT  Imagen a color: procesable en una computadora como tres capas o matrices de píxeles (una para cada canal de color) de tamaño 640x480 cada una. Se puede obtener como un tipo de mensaje de ROS denominado sensors_msgs/Image y convertirlo, por ejemplo, a tipo de dato compatible con la librería OpenCV para así realizar un tratamiento de la imagen eficaz. No será el caso en este proyecto, aunque podría añadirse más adelante para mejorar la percepción del entorno, tal y como se hizo en [1].  Imagen de profundidad: igual que en el caso del lidar es una matriz de píxeles, en este caso de tamaño 640x480. De nuevo, se trata en ROS como un mensaje del tipo sensors_msgs/Image y puede ser útil para estimar la posición y tamaño de los obstáculos identificados mediante el análisis de la imagen a color anterior. Tampoco se ha usado en este proyecto.  Nube de puntos de profundidad: idéntica descripción que en el caso del lidar, siendo por tanto el tipo de dato usado para el mapeado. 19 4 DISEÑO Y DESARROLLO DEL SISTEMA DE DETECCIÓN DE OBSTÁCULOS omo ya se ha comentado, este es el capítulo más importante de la memoria, pues se recoge en él todo lo trabajado con el robot. En la primera parte, se da una visión sobre el estado inicial del robot, tratando los packages que incluye y otros trabajos realizados previamente con la versión anterior que se tenía en el laboratorio. Se usará esa información para lanzar el robot y recrear de una forma completa la información obtenida por los sensores cámara y lidar, cuyos campos de visión, alcance y precisión serán estudiados en detalle. Por último, se analizará la librería de construcción de mapas OctoMap. 4.1 Trabajos previos con el Summit-XL A menudo se ha hecho referencia en esta memoria al trabajo de simulación que llevé a cabo hace dos años con el Summit-XL [1]. Es sin duda la base sobre la que se sustenta este trabajo, sirviendo como continuación del mismo aunque en un contexto algo distinto y con los objetivos ciertamente modificados, incluyendo las pruebas en el robot real. Aquel trabajo, al igual que este, tenía como fin último conseguir un mapa de obstáculos en 2 dimensiones lo más completo posible, incluyendo objetos del mayor rango de alturas colisionables con el Summit-XL posibles. Como era una versión antigua del robot, los sensores eran diferentes y permitían una funcionalidad más limitada para la tarea encomendada. En concreto, como se ve en el trabajo llevado a cabo en [21], la navegación autónoma estaba limitada por el hecho de que el mapa se construía con el sensor láser que tenía el Summit-XL. Este hacía un barrido en un plano horizontal a la altura del chasis superior donde se encontraba. La solución que se probó en [1] fue la fusión de la cámara tipo PTZ con el escáner de ese láser, de manera que la cámara reconocía ciertos patrones en el suelo. En concreto, como la navegación estaba orientada a exteriores, se implementó con éxito el reconocimiento de agujeros oscuros que pudieran aparecer en el terreno y su inclusión en el mapa. En la Figura 4-1, se puede ver una simulación de [1] en la que se incluyen tres agujeros en el mapa que crea el robot. Figura 4-1. Simulación del trabajo de [1]. A la izquierda, visualización del mapa 2D en RViz e imagen en tiempo real de la cámara. A la derecha, simulación en Gazebo que da lugar a ese mapa La limitación de [1] es que los algoritmos desarrollados no pudieron probarse en el robot real. Sin embargo, en [21] y [22] sí fue posible trabajar con el robot en el laboratorio, implementándose la navegación autónoma en ambos, si bien tenían la limitación de alturas reconocibles comentada. Además, en [22] se estudia la autonomía del Summit-XL en términos energéticos. Tanto [21] como [22] sirven de gran referencia en lo que a conexión remota con el Summit-XL se refiere. Se detallará dicha conexión en el “Anexo. Manual de usuario”. C Diseño y desarrollo del sistema de detección de obstáculos 26 modelo el URDF visible en RViz. Los detalles sobre las modificaciones se tratan en el “Anexo. Manual de usuario”. Una vez resuelto, la representación en RViz del robot queda como la de la Figura 4-13. Figura 4-12. Representación de los ejes de los sensores para confirmar la situación previa de la cámara en el modelo URDF del robot Figura 4-13. Resultado del ajuste de la cámara en el modelo URDF del robot En la esquina inferior izquierda de la Figura 4-13 se puede observar una medida que apareció en la captura. Aunque no era objeto de la imagen mostrar medida alguna, se quedó el resultado de una medida previa para confirmar aproximadamente en RViz que la parte frontal de la cámara se situaba ahora a unos 6cm del chasis. Una vez solucionado el problema del offset que aparece en profundidad entre los dos sensores, se vuelve a la escena de prueba de la Figura 4-3 y Figura 4-4 y se representa conjuntamente las nubes de puntos de lidar y cámara. En la Figura 4-14 se observa como las nubes de puntos de ambos sensores coinciden. En concreto, el obstáculo de color blanco de la escena se detecta y no es posible distinguir las dos nubes de puntos en cuanto a distancia respecto al robot. Para más detalle, en la Figura 4-15 y la Figura 4-16 se mide la distancia del chasis del robot al obstáculo mencionado con cada sensor y el resultado es prácticamente el mismo: 1.64m para el lidar y 1.63m para la cámara. 27 Sistema de detección de obstáculos para robot móvil SUMMIT Figura 4-14. Representación de las dos nubes de puntos tras el ajuste de la cámara Figura 4-15. Medida proporcionada por el lidar tras el ajuste de la cámara Figura 4-16. Medida proporcionada por la cámara tras su ajuste Diseño y desarrollo del sistema de detección de obstáculos 28 4.3.2 Offset altura Para realizar la comprobación del offset de altura, se realiza una primera prueba con el robot en la misma escena que en el apartado anterior, es decir, la mostrada en la Figura 4-8. En la Figura 4-17 y la Figura 4-18 se ve la diferencia de altura entre las nubes de puntos de cada sensor para el mismo obstáculo y escena (también se ve la diferencia de profundidad porque se arregló después de estas capturas), La nube de puntos que parece estar elevada, aunque de menor rango de altura, corresponde al lidar. Figura 4-17. Ilustración 1 del offset de altura Figura 4-18. Ilustración 2 del offset de altura Es claro que el lidar eleva los obstáculos. Para mayor claridad, se van a mostrar aquí capturas del mapa 3D junto al 2D, a pesar de que aún no se ha presentado la librería que permite su realización, objeto del apartado 4.5 de esta memoria. La razón por la cual se ha decidido incluir aquí de manera complementaria la representación de mapas 2D y 3D es simplemente porque el mapa 3D se transforma en uno 2D que se representa a la altura del suelo donde está el robot. Esto deja ver de una manera más evidente el offset de altura que estamos tratando de solucionar, pues el mapa 2D aporta una referencia visual de altura cero. 29 Sistema de detección de obstáculos para robot móvil SUMMIT En la Figura 4-19 se representa con el lidar un ejemplo de mapa 3D (a color) junto a otro 2D (en tonos grises) correspondiente con el escenario de prueba de la Figura 4-3 y Figura 4-4, en el que se observa más claramente el offset de altura. En la Figura 4-20 se hace lo mismo para la cámara, aunque correspondiente a otra escena (ver esquina inferior izquierda para ver el obstáculo). Esta, sin embargo, no eleva los obstáculos. Figura 4-19. Ilustración offset altura con mapas Figura 4-20. Confirmación de altura correcta de los obstáculos representados por la cámara El problema de nuevo radica en la representación del robot en RViz a través de su modelo URDF. En la realidad, el fabricante del robot nos dice que el lidar está inclinado respecto a la horizontal un ángulo de 8º, confirmado midiendo en el laboratorio. Sin embargo, como se puede observar en la Figura 4-21, el lidar aparece totalmente en horizontal en el modelo representado en RViz. Igual que antes, la medida proporcionada por el lidar parece ser la correcta desde sus ejes de coordenadas. El problema es que al tener ángulos distintos en la realidad y la representación URDF, la nube de puntos se gira un ángulo igual al ángulo de diferencia. Así, la solución de este problema pasa por acceder y modificar el código fuente de representación del robot en modelo el URDF visible en RViz. Los detalles sobre las modificaciones se tratan en el “Anexo. Manual de usuario”. Una vez resuelto, la representación en RViz del robot queda como la de la Figura 4-22. Diseño y desarrollo del sistema de detección de obstáculos 30 Figura 4-21. Representación errónea del lidar en el modelo URDF del robot Figura 4-22. Resultado del ajuste del lidar en el modelo URDF del robot Aunque es difícil apreciar variación de la inclinación del lidar entre la Figura 4-21 y la Figura 4-22 al girar un ángulo tan pequeño, aproximadamente se puede ver. Con el problema del offset que aparece en la altura de los obstáculos entre los dos sensores, se vuelve a la escena de prueba de la Figura 4-3 y Figura 4-4 para visualizar de manera más clara que la representación de las alturas es ahora correcta por parte del lidar. Tal y como se usó previamente, se recurre a la representación del mapa 3D junto al 2D. Se muestra en la Figura 4-23 la nube de puntos proporcionada por el lidar en la que se puede distinguir fácilmente el obstáculo de color blanco. En la Figura 4-24 se representa el mapa 3D (a color) junto con su correspondiente mapa 2D (en tonos grises y negros, recordando que es un mapa representado a altura cero). Queda reflejado que el problema se ha resuelto a la vista de la representación a color del obstáculo. Se podría pensar que el obstáculo que aparece a la derecha del robot sigue teniendo altura elevada y se estaría en lo cierto, pues corresponde en la escena de la Figura 4-4 con una caja de madera apoyada en el suelo. Sin embargo, esta representación “elevada” se debe a que la caja está a una distancia con respecto al lidar inferior a 1.75m. Como se verá en el apartado 4.4 de esta memoria, a esa distancia el robot no detecta aún el suelo dentro 31 Sistema de detección de obstáculos para robot móvil SUMMIT de su campo de visión. También podría influir que la caja está en los límites del campo de visión del lidar. En cualquier caso, en este ejemplo concreto, el hecho de que el lidar permita ampliar el campo de visión horizontal sigue siendo útil, pues el mapa 2D que se usará en un futuro para la navegación autónoma incluye esas coordenadas en el plano del suelo como ocupadas, no siendo necesario en este caso reconocer la caja completa. Figura 4-23. Representación de la nube de puntos del lidar tras su ajuste Figura 4-24. Representación del mapa obtenido con el lidar tras su ajuste 4.3.3 Fusión cámara y lidar Antes de entrar en el análisis detallado de las prestaciones de lidar y cámara, se pretende mostrar la idea de la fusión de ambos sensores a la hora de obtener una información más completa del entorno. De hecho, ya sabemos por los fabricantes y por las pruebas mostradas hasta el momento que el lidar permitirá obtener mayor anchura en el campo de visión y la cámara, por su parte, más altura. Esta es una de las razones principales por las que se optará por fusionarlos. Otro motivo es que aumentaría la fiabilidad del sistema de percepción del entorno, ya que si falla un sensor, está el otro ofreciendo información igualmente válida. Existen diferentes maneras de fusionar la información de los dos sensores, como podría ser crear un nodo desde su código fuente, suscribirse a los dos topics (cámara y lidar), tratarlos y unirlos en uno sólo. Pero existe Diseño y desarrollo del sistema de detección de obstáculos 32 un método más sencillo que se basa en el uso de una herramienta incorporada en la instalación completa de ROS. Se trata del nodo relay, que se encuentra dentro de un package que ofrece una serie de herramientas para trabajar con los topics de ROS, denominado topic_tools [23]. La función de este nodo es sencilla: se suscribe a un topic y lo publica en otro nodo. La estrategia será mantener el topic de la cámara y del lidar por separado y, a la vez, mapear la información de ambos en un topic que será el empleado en para la fusión. De esta manera se consigue mantener la información de partida, además de tener acceso a la fusión. Sobre esto ya se habló en el apartado 2.2.1, en el que se mostraba en la Figura 2-9 un ejemplo de varios nodos que publicaban en un mismo topic, siendo el mensaje resultado de este topic la suma de los mensajes enviados por los nodos publicadores. Realmente no es una fusión como tal. Es decir, no tenemos un mensaje que sea la suma de los dos mensajes, sino que el mensaje resultado es la alternancia de los dos mensajes que entran a distinta frecuencia en el topic, alternándose uno tras otro. En definitiva, la situación y actuación del nodo relay será la esquematizada en la Figura 4-25. Para su uso en ROS se remite al lector al “Anexo. Manual de usuario”. Figura 4-25. Visión del nodo relay de manera global dentro del trabajo Por último, se va a mostrar una representación completa que servirá para dos cosas. El primer objetivo será observar que las nubes de puntos coinciden, tal y como se ha estudiado en la primera parte de este punto. En segundo lugar, se quiere justificar la fusión con el aumento del campo de visión. En primer lugar, se muestra la escena de pruebas, similar a otras ya vistas pero con otros obstáculos, en la Figura 4-26. Tras esto, se observa la escena con el lidar (Figura 4-27), con la cámara (Figura 4-28) y con la fusión (Figura 4-29). Para cada una de las figuras anteriores se representa la nube de puntos desde tres ángulos diferentes: de manera frontal, lateral y desde arriba. Para la vista frontal se ha ocultado la representación del robot para mayor claridad. Figura 4-26. Escenario de pruebas fusión lidar y cámara 33 Sistema de detección de obstáculos para robot móvil SUMMIT Figura 4-27. Vistas frontal, lateral y superior de la nube de puntos del lidar Figura 4-28. Vistas frontal, lateral y superior de la nube de puntos de la cámara Figura 4-29. Vistas frontal, lateral y superior de las dos nubes de puntos En concreto, de las figuras anteriores es interesante observar las vistas frontal y superior, pues permiten ver de forma muy clara que con la cámara ganamos altura detectable y que con el lidar ganamos anchura, respectivamente. También se deduce algo de estas imágenes. Las nubes de puntos obtenidas con la cámara tienen considerablemente más datos. Además de tener en general mayor campo de visión teórico, son nubes de puntos más densas. Esto hará que la cantidad de información de la cámara sea mayor, por lo que su velocidad de procesamiento será menor. Es decir, cabe esperar que el lidar sea más rápido en la detección de obstáculos. Se recuerda que según los fabricantes de dichos sensores, el lidar tiene un tiempo de respuesta de 200ms, mientras que de la cámara no se proporciona dicha información. Además, es un parámetro difícil de medir para nosotros en el laboratorio con los recursos disponibles. No obstante, en las pruebas que se mostrarán en el capítulo 5 dedicado a resultados se hablará un poco más sobre la incidencia de la velocidad de respuesta. 4.4 Estudio y análisis experimental de las prestaciones de los sensores Antes de usar la cámara y el lidar, es preciso conocer en detalle las características reales que pueden ofrecer. 4.4.1 Alcance A continuación se lleva a cabo un estudio comparativo sobre el alcance que tienen los dos sensores. Para ello se hacen dos comparativas, una interna propia de cada sensor y otra entre ambos sensores. En la primera de Diseño y desarrollo del sistema de detección de obstáculos 34 ellas se trata de mostrar las diferencias entre el alcance que garantiza el fabricante en el datasheet y los alcances reales medidos tanto en interiores como en exteriores (mayor luz natural). En la segunda comparativa se intenta ver las diferencias entre el lidar y la cámara en todas las medidas de alcance. Antes de mostrar los datos es conveniente aclarar los siguientes puntos:  Las medidas de las hojas de datos de los fabricantes se refieren a situaciones donde la iluminación apenas influye y en entornos favorables de interiores. Incluso para el lidar se especifica el tipo de material detectado y su reflectividad, ya que si cambia pueden cambiar determinadas características.  Las medidas de interiores se realizan tanto en el aula como en el pasillo de los laboratorios, donde la luz existente procede de lámparas led colgadas del techo y luz natural de las ventanas (situadas en puntos relativamente altos respecto al Summit-XL).  Las condiciones para pruebas exteriores son entorno al aire libre en mañanas de días soleados de noviembre en Sevilla. La temperatura aproximada de las pruebas oscila entre los 16ºC y 20ºC, lo cual es adecuado para el rango de temperaturas de operación de ambos sensores: 0-50ºC para el lidar y -10- 50ºC para la cámara.  Alcance central se refiere a obstáculos situados en una zona céntrica dentro del campo de visión (cuya forma se pudo ver en el apartado anterior, Figura 3-4). Estas medidas se refieren a la distancia desde el sensor (lidar o cámara según corresponda) hasta el obstáculo. Por su parte, el Alcance lateral se puede medir en los límites de dicho campo de visión. Siguiendo las pautas del fabricante Benewake en [18], este parámetro se toma en los extremos del campo de visión horizontal como la máxima anchura horizontal detectable midiendo desde el eje de simetría del sensor (el mismo que el del robot).  Mínimo y máximo delimitan el rango para las medidas detalladas anteriormente.  Un guion en alguna celda de la tabla significa dato no disponible.  Todas las medidas están expresadas en metros. Una vez conocemos la manera de proceder, los datos del estudio de alcance se recogen en la Tabla 4-1. Sensor Valor Alcance central (m) (1) Alcance lateral (m) (2) Datasheet Interiores Exteriores Datasheet Interiores Exteriores Lidar Mínimo (3) 0.430 0.460 0.460 0.150 - - Máximo 4.000 4.050 3.740 2.000 1.945 1.800 Cámara Mínimo (3) 0.400 0.330 0.330 - - - Máximo 6.000 5.740 3.040 - 1.685 1.400 (1) Medidas desde la parte delantera del sensor (lidar o cámara según corresponda) (2) Medidas desde el centro (eje de simetría) del robot (3) Estas medidas requieren explicación adicional sobre zona ciega Tabla 4-1. Estudio de alcance de los sensores lidar y cámara Como se puede deducir de la Tabla 4-1, las condiciones de prueba del fabricante son idílicas y, por lo general, van empeorando hasta la peor situación en la que el robot está en exteriores, pasando por la situación intermedia de lugar cerrado con cierta luz natural. Especialmente llamativo es la pérdida de alcance de la cámara, que pasa de 6m según el datasheet a unos 3m en exteriores. En ese aspecto, el lidar es más estable. En cuanto a las medidas mínimas es necesario hacer una serie de consideraciones aparte. Para el lidar, el fabricante ofrece una curva de la denominada zona ciega, donde el lidar no detecta obstáculos debido a su cercanía. Esta curva ya fue explicada en la Figura 3-6. Según esta curva, dentro de su campo de visión, el lidar puede detectar obstáculos a partir de los 10cm de distancia (coincide con el alcance que proporcionan como característica del dispositivo, recogido en el apartado 3.1.1 de esta memoria. Sin embargo, para obstáculos centrados en el campo de visión, la zona ciega se incrementa siendo el alcance central mínimo de unos 43cm y el alcance lateral mínimo de unos 15cm. En las pruebas realizadas el mínimo alcance central es relativamente fácil de medir, pues supone el punto a 35 Sistema de detección de obstáculos para robot móvil SUMMIT partir del cual el lidar proporciona una nube de puntos clara y fiable, siendo este 46cm de distancia tanto para interiores como para exteriores. Sin embargo, debido a la zona ciega de la que habla el fabricante, es difícil medir el alcance lateral mínimo, ya que se produce una distorsión de los obstáculos cercanos. Es decir, realmente detecta obstáculos entre las distancias de 10cm y 46cm, pero estos aparecen distorsionados y distorsionan a otros obstáculos visto en otras regiones normales del campo de visión. Para mostrar lo anterior, se muestra una comparativa entre la cámara y el lidar para explicar esta distorsión que aparece en el lidar. En la Figura 4-30, se observa la nube de puntos para lidar y cámara correspondiente a un obstáculo situado a una distancia mayor a la mínima que puede ver con claridad (46cm para el lidar y 43cm para la cámara). En la Figura 4-31, se sitúa una persona como obstáculo entre el obstáculo anterior y el robot, de nuevo en una zona dentro de la visibilidad fiable de ambos sensores. Como se puede ver, no se produce distorsión en ninguna de ellas. Por último, se coloca en la Figura 4-32 el obstáculo persona dentro de las zonas mínimas comentadas y el resultado es que el lidar detecta la nube de puntos pero distorsiona toda la escena y la cámara no detecta nada. Es interesante ver que la cámara no detecta nada pero el obstáculo dentro de su zona ciega le impide ver más allá. Figura 4-30. Nube de puntos para lidar (izquierda) y cámara (derecha) con obstáculo alejado Figura 4-31. Nube de puntos para lidar (izquierda) y cámara (derecha) con obstáculo fuera de sus zonas ciegas Figura 4-32. Nube de puntos para lidar (izquierda, con distorsión) y cámara (derecha, sin detección) con obstáculo dentro de sus zonas ciegas Diseño y desarrollo del sistema de detección de obstáculos 42 S -0.615 1.300 T -0.410 0.820 U 0.000 0.000 Tabla 4-6. Coordenadas respecto a los ejes de la cámara Orbbec Astra de los puntos límites de su campo de visión horizontal Si se representa los puntos de la Tabla 4-6, queda la forma del campo de visión horizontal de la Figura 4-38. Figura 4-38. Campo de visión horizontal de la cámara Orbbec Astra obtenido experimentalmente De nuevo, haciendo uso de la tangente al campo de visión horizontal, se puede hacer una aproximación del ángulo de visión horizontal según la ecuación (4–15). 43 Sistema de detección de obstáculos para robot móvil SUMMIT 𝐹𝑂𝑉ℎ [°]=2∗(90− tan−1(𝑑𝑖𝑠𝑡𝐴 𝑎𝑛𝑐ℎ𝑢𝑟𝑎𝐴)) (4–15) Siendo distA y anchuraA las coordenadas del punto por el que pasa la tangente: 0.820m y 0.410m respectivamente. El resultado es de 53.130º, similar a los 60º que apuntaba el fabricante. Al igual que se hiciera con el campo de visión vertical, la Figura 4-39 permite comparar y resumir los campos de visión horizontal de ambos sensores. Figura 4-39. Resumen campo de visión horizontal (Imagen original cedida por Robotnik con modificaciones de elaboración propia) Diseño y desarrollo del sistema de detección de obstáculos 44 4.4.3 Precisión Finalmente, se lleva a cabo un estudio para comprobar la precisión de lidar y cámara. Se realizan pruebas a tres distancias diferentes dentro del campo de visión de los dos sensores y se toman medidas tanto en interiores como en exteriores. Los resultados se recogen en la Tabla 4-7 y la Tabla 4-8, estando todas las medidas tomadas desde la parte delantera de la rueda. Prueba Distancia real [m] Distancia medida por lidar [m] Error lidar [%] Distancia medida por cámara [m] Error cámara [%] 1 1.39 1.39 0.00 1.38 0.72 2 2.19 2.20 0.46 2.15 1.86 3 3.00 2.98 0.67 2.96 1.35 Tabla 4-7. Estudio de precisión en interiores para lidar y cámara Prueba Distancia real [m] Distancia medida por lidar [m] Error lidar [%] Distancia medida por cámara [m] Error cámara [%] 1 1.00 1.02 2.00 1.03 3.00 2 2.19 2.18 0.46 2.18 0.46 3 3.00 3.02 0.67 2.97 1.01 Tabla 4-8. Estudio de precisión en exteriores para lidar y cámara A la vista de las dos tablas, el lidar proporciona medidas más exactas que la cámara. En cualquier caso, las variaciones suelen ser de uno o dos centímetros, lo cual no supone problema alguno de cara a la aplicación del robot y el rango de distancias en el que nos movemos. Sin embargo, si es conveniente comentar un problema que surgió durante las pruebas de precisión en exteriores con la cámara. Al tratar de medir la distancia al punto situado a 3m de la parte delantera de la rueda, la cámara presentó dificultades para detectar obstáculos a esa distancia debido a la iluminación solar. Finalmente, la manera de tomar esa medida pasó por cambiar el material del obstáculo. A diferencia del resto de la tabla, hecha detectando el mismo obstáculo (pared blanca), para los 3m de la cámara se cambió a un folio blanco. El hecho de que a cierta distancia pueda detectar unos materiales y otros no se debe a la diferencia de reflectividades de dichos materiales. Además, el día de mayor iluminación solar se probó tanto la cámara como el lidar. Con el lidar se seguía obteniendo resultados muy similares. Sin embargo, con la cámara se producían ciertos fallos en función del material a detectar, situándose en el peor de los casos su alcance central en un metro con el sol de frente y en 2.8m a la sombra. Figura 4-40. Ejemplo del procedimiento para el estudio de precisión de sensores 45 Sistema de detección de obstáculos para robot móvil SUMMIT Para terminar, se comenta la manera de tomar medidas. El procedimiento consiste en situar al robot a la distancia requerida por la prueba y representar en RViz la nube de puntos con el sensor a medir. Para medir, RViz cuenta con la herramienta Measure, que determina la distancia en línea recta entre dos puntos de la escena a escoger con el puntero. Como ejemplo, se muestra en la Figura 4-40 el procedimiento de medida en exteriores para el lidar y a una distancia de 3m. 4.5 OctoMap Se pretende justificar la elección de la librería OctoMap así como realizar una breve descripción de su principio de elaboración de mapas. Además, se incluye información útil para trabajar en ROS con la funcionalidad de construcción de mapas 3D que ofrece. 4.5.1 Introducción y características OctoMap es una librería de funciones de código abierto escritas en lenguaje C++ creada en la Universidad de Friburgo (Alemania) para la representación de mapas de obstáculos 3D, que además permite su conversión a mapas 2D [24]. La elección de la librería OctoMap es adecuada para la realización de este trabajo debido a que presenta una serie de características interesantes. Entre ellas destacan: - Orientada a navegación de robots autónomos. - Funcionamiento en Linux (por tanto, Ubuntu) e integrada en ROS. - Válida para información de representación 3D de sensores. - Representación probabilística de la escena. Esto permite la utilización de sensores con las incertidumbres de medida que presentan, además de la integración de diferentes medidas e incluso robots para la construcción de los mapas. - Resolución configurable. En función de cuál sea el objetivo, se afina más o menos en la resolución. Por ejemplo, si construimos el mapa para una planificación de alto nivel como puede ser un guiado, se puede hacer un mapa con poca resolución. Por el contrario, para planificadores de bajo nivel, se necesitará aumentar la resolución, y con ello el conocimiento del entorno. - Zonas no visitadas. A diferencia de muchos de los trabajos que se conocían hasta el momento que se publicó [24], esta representación distingue entre tres zonas claramente diferenciadas: zonas visitadas y ocupadas, zonas visitadas y no ocupadas y zonas no visitadas. Esta última es la novedad y es muy importante para la planificación de la navegación en entornos desconocidos. - Actualización. No se necesita conocer el tamaño del mapa a priori, sino que se va aumentando el mismo a medida que los sensores recorren la escena. Además, se permite trabajar con escenas dinámicas, permitiendo que si volvemos a visitar una zona cuyo aspecto y obstáculos han cambiado, el mapa se actualice correctamente. Esto es una característica importante ya que se puede partir de un mapa conocido e ir actualizándolo conforme se navegue por la zona. - Eficiencia. Esto es otro de sus puntos fuertes, ya que permite llevar a cabo todas las características anteriores de una manera eficiente en tiempo de acceso al disco y consumo de memoria, lo que es crucial para aplicaciones de sistemas embebidos robóticos. 4.5.2 Metodología de construcción de mapas Para llevar a cabo la tarea, la idea se basa en dividir el espacio en volúmenes con forma cúbica [24]. Cada cubo del espacio tridimensional, denominado voxel, se divide a su vez en ocho cubos o voxels. Esta operación se repite hasta alcanzar la resolución que se requiera, cuyo valor se corresponderá con la medida del lado del cubo de menor tamaño en metros. Esta división en voxels del espacio tridimensional, conocida como octree, se puede representar mediante una estructura de árbol de nodos como la representada en la Figura 4-41. Las diferentes opciones que se pueden encontrar en un voxel se recogen en la Tabla 4-9. Diseño y desarrollo del sistema de detección de obstáculos 46 Figura 4-41. Representación del espacio tridimensional en voxels y su correspondencia con una estructura en árbol (Fuente: [24]) Descripción Estado del voxel Probabilidad Representación 3D en RViz Representación de su proyección 2D en RViz Voxel visitado y ocupado Inicializado 1 A color en función de su altura Color negro Voxel visitado y no ocupado Inicializado 0 No representado Color gris claro Voxel no visitado No inicializado - No representado Color gris oscuro Tabla 4-9. Tipos de voxel en la representación de OctoMap Realmente, los valores de la Tabla 4-9 no son binarios (0 y 1) para las zonas visitadas. Se hace un análisis para cada voxel en el que se determina la probabilidad de que esté ocupado basándose en la medida de los sensores. Esta probabilidad se calcula con un filtro Bayesiano binario recursivo. Para el análisis típicamente lo que se usa (por ser más eficiente) es el valor log-odd, que se define como el logaritmo del cociente entre la probabilidad de que un nodo esté ocupado y la probabilidad de que no lo esté. Para decidir si está ocupado o no, se define un umbral de probabilidad. Si lo supera, se cataloga como ocupado (probabilidad se convierte a 1); si no, como espacio libre (probabilidad se convierte a 0). Además, para la actualización y que se cambie una zona visitada de ocupada a libre o viceversa, se requiere como mínimo el mismo número de medidas tomadas para catalogarla en la categoría anterior. Por ejemplo, si un voxel se observó durante diez ocasiones como ocupado, para cambiarlo a libre ha de observarse como tal al menos en diez ocasiones. Esto en la práctica no es así, pues se relajan los límites de las probabilidades, llegando a un compromiso entre la fiabilidad de no actualizar tan rápido (podría ser ruido o incertidumbre en la medida) y la mejor adaptabilidad en entornos cambiantes. Cuando queremos cambiar la resolución, en lugar de acceder a la probabilidad de los nodos terminales, se accede a la de un nodo o voxel intermedio correspondiente a la profundidad necesaria para obtener esa resolución. La probabilidad (o en su defecto el valor log-odd) de que un voxel interno del árbol con ocho nodos hijos esté ocupado se puede calcular como la media o como el máximo de sus hijos, según sea la aplicación. Por ejemplo, se usa el máximo para estrategias de navegación, siendo más conservativa para evitar daños al robot. Si en la representación en árbol, todas las hojas (voxels) que salen de un voxel tienen el mismo estado y valor, y además son estables, se pueden podar y se ahorra ese espacio en memoria, mejorando la eficiencia. Esto es posible debido a que octree es una estructura de datos jerárquica. Aun así, siempre puede actualizarse y requerir mayor división hasta un máximo de la resolución fijada. Un voxel se considera estable si supera los límites relajados (mínimo o máximo) del umbral de cambio de estado ocupado-libre. 4.5.3 OctoMap en ROS Existen diferentes opciones de instalación de OctoMap en ROS, aunque en la instalación completa viene incluido. Sin embargo, como se explica en el “Anexo. Manual de usuario”, se opta en este caso por descargar de [25] manualmente el stack octomap_mapping, en cuyo interior se encuentra el package octomap_server. 47 Sistema de detección de obstáculos para robot móvil SUMMIT De dicho package resulta interesante el nodo que crea los mapas, de nombre octomap_server (nodo tipo octomap_server_node) y el que los guarda, llamado octomap_saver. Es último no se ha usado, aunque será necesario en un futuro. El package usado es octomap_server, el cual permite el mapeado 3D [26]. Para ello, el topic de entrada al que se suscribe, de nombre cloud_in, tiene que ser del tipo sensor_msgs/PointCloud2 (el cual ofrecen tanto la cámara como el lidar). Hay que remapear los topics que publican esos sensores o el de su fusión al topic cloud_in. En cuanto a los topics publicados, tiene diferentes salidas posibles. Sin embargo, sólo las genera si a ese topic de suscribe otro nodo, por ejemplo RViz para la visualización, contribuyendo así a la eficiencia que caracteriza a la librería. Entre los cinco topics que puede publicar, se emplean los dos siguientes: - occupied_cells_vis_array. Produce mensajes del tipo visualization_msgs/MarkerArray, visible con el Display MarkerArray en RViz. Permite ver el mapa 3D. - projected_map. Topic con mensajes del tipo nav_msgs/OccupancyGrid. Crea el mapa 2D a la altura del suelo como la proyección del mapa 3D. Es decir, para todas las coordenadas en un plano horizontal, si existe algún voxel ocupado (sea cual sea su altura), se proyecta en el suelo como celda ocupada. Es el tipo de mapas típicos que se obtiene en ROS con otras metodologías como gmapping. Por último, es posible lanzar la construcción del mapa ajustando una serie de parámetros predefinidos. Si no se ajustan, adoptan unos valores por defecto que se pueden consultar en [26]. Para definirlos de forma compacta en el lanzamiento se remite al lector al “Anexo. Manual de usuario”. Entre los más interesantes para nuestra aplicación, se encuentran los parámetros detallados a continuación: - frame_id. Eje de coordenadas respecto al cual se construye el mapa. Es necesaria la transformación con el package tf desde el eje de coordenadas del sensor (que viene incluido en el tipo de mensaje que ofrece) hasta dicho eje de referencia. Típicamente se escoge un eje de referencias dedicado al mapa o la odometría. - resolution. Tamaño en metros de la arista del voxel más pequeño. A mayor resolución, más exacto será el mapa pero más tiempo tardará en construirse, disminuyendo su eficiencia. - height_map. Establecer a True para ver los obstáculos con colores diferentes en función de su altura. - sensor_model/max_range. Máxima distancia desde el sensor a considerar en el mapa. Por ejemplo, la cámara tiene un alcance idílico de casi 6 metros pero puede fallar en su último metro. En ese caso, convendría escoger la distancia máxima de 5 metros para aumentar la fiabilidad. El valor -1 se usa para distancia ilimitada. - latch. Configurar a True para mapa conocido y estático y a False para mapa dinámico. - pointcloud_min_z. Máxima altura de la nube de puntos en metros a considerar en el mapa. En nuestro caso, conviene establecerla a 1 metro para ahorrar representación y hacerla más eficiente. - pointcloud_max_z. Igual que antes, pero con la altura mínima. En este proyecto se ha establecido en 0.02 metros para no considerar el suelo como obstáculo. Existen más parámetros modificables que no se usan como son los umbrales máximo y mínimo para decidir si un voxel está ocupado o varios parámetros dedicados a un filtro para no considerar el suelo. En este caso si queremos eliminar el suelo de la representación del mapa, pero se hace de una forma más directa con el parámetro pointcloud_min_z. 49 5 RESULTADOS ste capítulo muestra la validación del trabajo desarrollado. En primer lugar se muestran las pruebas iniciales de mapeado, en las cuales aparece un problema de ruido en los sensores para el cual se propone un filtro como solución. Tras esto, se muestran los resultados de las pruebas tanto en interiores como en exteriores. En ambos casos se muestran por separado las pruebas para cámara, lidar y, por último, para la fusión de ambos. 5.1 Filtro para la medida del lidar Al lanzar inicialmente el mapeado con el lidar, se observa que aparece un voxel del mapa 3D ocupado justo sobre dicho sensor a pesar de no haber obstáculo alguno. Para observar la supuesta presencia de un obstáculo en esa posición con la nube de puntos es necesario representar la escena en RViz sin incluir el modelo del robot. Para describir mejor el problema, se presenta una secuencia de imágenes. En la Figura 5-1, se observa la nube de puntos que proporciona el lidar, sin poder apreciarse ruido alguno a simple vista. Sin embargo, si quitamos el modelo del robot, se puede ver en la Figura 5-2 que aparece un punto como ruido en la posición donde antes estaba el lidar. Esto es más visible con la representación del mapa 3D. En la Figura 5-3 se muestra el voxel ocupado (de color naranja) que aparece sobre el lidar y en la Figura 5-4 igual, pero sin el modelo del robot. Para descartar que sea ruido del ambiente o de una posición concreta, se mueve el robot, en este ejemplo hacia delante, y se refleja en la Figura 5-5 cómo la posición del lidar se va acumulando por todos los puntos por los que pasa. En toda la secuencia de imágenes que se presenta a continuación, la escena es la misma, pudiendo verse a través del display tipo cámara de RViz que aparece en la esquina inferior izquierda de la pantalla. Aunque se trate de una escena en interiores, dentro del laboratorio, donde realmente se vio detecto el problema fue en una zona más libre de obstáculos en exteriores. Es decir, el problema es común a ambos escenarios. Figura 5-1. Nube de puntos del lidar en el problema de ruido E Resultados 50 Figura 5-2. Nube de puntos del lidar en el problema de ruido sin el modelo del robot Figura 5-3. Representación del mapa 3D por el lidar con ruido Figura 5-4. Representación del mapa 3D por el lidar con ruido sin el modelo del robot 51 Sistema de detección de obstáculos para robot móvil SUMMIT Figura 5-5. Hilera de puntos ocupados que queda en el mapa 3D tras el paso del robot Como las soluciones básicas, tales como limpiar las lentes o reorientar el lidar por si estuviera detectando algún objeto fijo del robot, no funcionan, se deduce que es un problema hardware del sensor lidar, con el cual poco más se puede hacer. Para solventarlo, se aplica un filtro que consistirá en no condiserar como obstáculo a incluir en el mapa todo aquel objeto que se sitúe a una distancia igual o inferior a 13cm respecto al lidar. Esto es, la nube de puntos seguirá mostrando ese ruido pero cuando el nodo que realiza el mapa 3D recorre esa nube de puntos no tiene en cuenta lo que esté dentro de una circunferencia de radio 13cm con centro el lidar. La aplicación de este filtro no afecta negativamente al campo de visión del lidar por dos motivos. El primero de ellos es que cómo se ha visto en esta memoria, el lidar tiene una zona ciega de unos 10cm y una zona de distorsión entre los 10 y los 46cm, por lo que los obstáculos que “se descartan” no se habrían detectado correctamente. Por otro lado, si hubiera un obstáculo a 13cm o menos del lidar, el robot ya habría colisionado con él. Hay que tener en cuenta que la parte delantera de la cámara se encuentra a una distancia de 12cm respecto al lidar y que a los laterales de este se encuentra el chasis y las ruedas del robot, siendo la distancia de la parte externa de las ruedas al lidar de unos 30cm. Por tanto, se muestra a continuación la misma secuencia de imágenes que anteriormente para mostrar que había ruido (Figura 5-6, Figura 5-7, Figura 5-8, Figura 5-9 y Figura 5-10). De nuevo, las capturas son para interiores (con una escena similar a la que se mostró en las imágenes de ruido), funcionando a la perfección también para exteriores como veremos en el apartado 5.3. Para detalles de implementación del filtro en ROS, se remite al lector al “Anexo. Manual de usuario”. Figura 5-6. Nube de puntos del lidar en el filtro solución Resultados 58 Figura 5-25. Escenario de pruebas para exteriores general Figura 5-26. Zona 1 escenario pruebas para exteriores Figura 5-27. Zona 2 escenario pruebas para exteriores Figura 5-28. Primera parte del recorrido para exteriores Figura 5-29. Segunda parte del recorrido para exteriores 59 Sistema de detección de obstáculos para robot móvil SUMMIT Figura 5-30. Tercera parte del recorrido para exteriores Figura 5-31. Cuarta parte del recorrido para exteriores Figura 5-32. Quinta parte del recorrido para exteriores Figura 5-33. Sexta parte del recorrido para exteriores Figura 5-34. Mapa 3D del lidar para exteriores Resultados 60 Figura 5-35. Mapa 2D del lidar para exteriores Figura 5-36. Mapas 2D y 3D del lidar para exteriores Figura 5-37. Mapa 3D de la cámara para exteriores 61 Sistema de detección de obstáculos para robot móvil SUMMIT Figura 5-38. Mapa 2D de la cámara para exteriores Figura 5-39. Mapas 2D y 3D de la cámara para exteriores Figura 5-40. Mapa 3D de la fusión para exteriores Resultados 62 Figura 5-41. Mapa 2D de la fusión para exteriores Figura 5-42. Mapas 2D y 3D de la fusión para exteriores En el caso de exteriores se pueden identificar los obstáculos sobre el mapa de manera más clara debido a que hay menos densidad de los mismos. Los resultados son prácticamente igual de buenos que en interiores y, además, es posible ver las ventajas de fusionar ambos sensores. En concreto, entre la Figura 5-34 y la Figura 5-37 se puede observar cómo la cámara detecta mayor altura que el lidar y cómo el lidar en la parte trasera de donde aparece posicionado el robot en la imagen detecta más cantidad de la pared que deja a su derecha circulando paralelo a la misma. Por último, se muestran los mismos resultados que antes para la fusión pero esta vez sí se le pasa como argumento al nodo del mapeado la altura máxima a detectar de un metro, para poder comparar con interiores en igualdad de condiciones. De nuevo, se representan el mapa 3D, el 2D y uno conjunto de ambos para la fusión en la Figura 5-43, la Figura 5-44 y la Figura 5-45. 63 Sistema de detección de obstáculos para robot móvil SUMMIT Figura 5-43. Mapa 3D de la fusión para exteriores con altura máxima detectable de 1 metro Figura 5-44. Mapa 2D de la fusión para exteriores con altura máxima detectable de 1 metro Figura 5-45. Mapas 2D y 3D de la fusión para exteriores con altura máxima detectable de 1 metro 65 6 CONCLUSIONES on el procedimiento y los resultados mostrados a lo largo de la memoria, se pueden sacar conclusiones y valores el trabajo realizado. Además, se describirán los puntos débiles y el posible trabajo futuro en el que habría que centrarse para mejorar las prestaciones del robot y adecuarlo a su tarea. 6.1 Conclusiones Una forma efectiva de valorar la adecuación de este trabajo es compararlo con el trabajo que le precede [1]. En ese trabajo anterior, se usaba un lidar de tipo escáner el cual tenía un alcance de 8m y un ángulo de visión horizontal de 270º. Es cierto que en esto se mejora a los sensores actuales, pero la fortaleza del lidar y la cámara reside en su visión 3D, más importante de cara a la construcción de un mapa más completo que de seguridad a la navegación. Es decir, el mapa 2D de obstáculos en [1] se construía más rápido, pues se barría más campo de visión. Sin embargo, era un barrido incompleto en el que sólo se consideraban obstáculos a una determinada altura. El hecho de incorporar lidar y cámara con posibilidades de visión 3D permite la construcción de un mapa más completo. La velocidad de procesamiento y construcción del mapa es similar en ambos trabajos, ralentizándose en el caso de [1] por la gran cantidad de datos del análisis de la imagen y en el caso de este trabajo debido a la necesidad de procesar de manera alterna dos nubes de puntos a la vez y representarlas en 3D. Aun así, se construye el mapa a una velocidad aceptable. Por otro lado, resulta evidente que la integración de lidar 3D con información de profundidad de la cámara aporta ventajas respecto a la utilización por separado de ambos sensores, a pesar de necesitar más recursos para procesar la gran cantidad de datos. Debido a esta enorme cantidad de datos resulta muy interesante la aplicación de la librería OctoMap empleada, debido a la eficiencia y otras características descritas en el apartado 4.5.1 de esta memoria. En primer lugar, como se ha comentado en varias ocasiones, el lidar permite aumentar el campo de visión horizontal hasta 132º y resulta más fiable que la cámara en entornos exteriores. A pesar de disminuir levemente sus prestaciones en estos entornos, se mantiene considerablemente estable ante condiciones adversas de iluminación. Por su parte, la cámara permite al robot aumentar su campo de visión vertical hasta los 49.5º. Si bien es cierto que a partir de la distancia de 1.64m desde la parte delantera de la rueda del robot este campo de visión deja de tener interés para el robot por su parte alta ya que supera la altura detectable de 1m con la que el robot ya no puede colisionar. En cualquier caso, sirve para identificar objetos colisionables con la parte alta del chasis y con el GPS, situado sobre un mástil en la parte más alta del robot, siendo este un elemento crítico en la localización del robot. Además, la cámara, en condiciones favorables, tiene unas prestaciones muy buenas en cuanto a alcance, superando los 4m aproximados que ve el lidar hasta conseguir algo menos de 6m. Pero es cierto que la fuerte iluminación natural puede perjudicar gravemente estas características. Es por eso, que en cuanto a fiabilidad, el lidar ofrece mejores prestaciones que la cámara. La otra ventaja clara de la fusión de ambos sensores es el aumento de la fiabilidad a la hora de construir el mapa. Al incorporar dos dispositivos con capacidades aceptables según se ha podido ver en el capítulo 5 dedicado a resultados, tenemos la garantía de que si uno falla y deja funcionar, el otro construye un mapa fiable. Para terminar, el caso en que el robot se encuentre con agujeros en el suelo (como podría ser una alcantarilla que esté destapada) o un cambio de alturas brusco, supone una situación peligrosa. Esto se debe a que el C Conclusiones 66 Summit-XL sólo puede bajar escalones de unos 10cm. Para este caso se consiguió probar lo que detectan tanto cámara como lidar en una situación comprometida de este tipo. Se muestra en la Figura 6-1 la situación genérica del desnivel probado. En la Figura 6-2 se muestra la situación con el robot al borde de la caída. Esta prueba se acompaña de la Figura 6-3 en la que se puede observar la nube de puntos que ofrece el lidar y la Figura 6-4, que ofrece la nube de puntos de la cámara. A la vista de estas imágenes, se puede concluir que la cámara sí detecta como obstáculo el cambio de altura; sin embargo, el lidar no. Se incluye la misma prueba para el robot más alejado de la caída (ver Figura 6-5), obteniéndose resultados idénticos para lidar (Figura 6-6) y cámara (Figura 6-7). Figura 6-1. Escenario de pruebas para desnivel Figura 6-2. Robot al borde de la caída 67 Sistema de detección de obstáculos para robot móvil SUMMIT Figura 6-3. Visualización de la nube de puntos del lidar con robot al borde de la caída Figura 6-4. Visualización de la nube de puntos de la cámara con robot al borde de la caída Figura 6-5. Robot más alejado de la caída Anexo. Manual de usuario 74 source devel/setup.bash roslaunch summit_xl_sim_bringup summit_xl_complete.launch 10. En otra terminal ejecutar la teleoperación con el teclado. Para ello, hay que ejecutar el nodo key_teleop, pasándole como argumento el topic /robot/cmd_vel, que es donde queremos que redirija su salida, siendo este topic la entrada de comandos de velocidad para el robot. Escribir en la terminal: rosrun key_teleop key_teleop.py key_vel:=/robot/cmd_vel Es importante señalar varios aspectos. En primer lugar, la configuración lanzada por defecto tanto de Gazebo como de RViz se puede modificar al gusto. Más adelante en este manual de usuario se explicará cómo hacerlo para RViz. Para modificar Gazebo, acudir a [1]. El código disponible para simulación del lidar nos devuelve un topic con mensajes del tipo sensor_msgs/PointCloud y no del tipo sensor_msgs/PointCloud2 como necesitará el nodo del mapa 3D. Por tanto, para probar aspectos de fusión en simulación no es posible usar el lidar. Como alternativa se propone añadir una cámara tipo Kinect, de características similares a la Orbbec, en lugar del lidar. Esta cámara, al igual que la Orbbec, nos devuelve mensajes para la nube de puntos del tipo sensor_msgs/PointCloud2, tal y como necesitamos. Para ello, modificar el código comentado previamente en el que se incluyen los sensores (summit_xl_std.urdf.xacro) y sustituir las líneas de código correspondiente al lidar por las siguientes: <!-- RGBD Kinect --> <xacro:sensor_kinect prefix="$(arg prefix)kinect" parent="$(arg prefix)base_link"> <origin xyz="0.27 0.0 0.275" rpy="0 ${7*PI/180} ${30*PI/180}"/> </xacro:sensor_kinect> Por su parte, para que la teleoperación funcione, la ventana activa del PC debe ser la terminal de comandos en la que se ejecuta el nodo key_teleop. Además, para que se puedan ver los movimientos del robot en RViz, hay que escoger el eje de coordenadas /robot_odom en el Display “Global Options” → “Fixed Frame”. Por último, se muestra en la Figura A-0-2 el resultado de ejecutar rqt_graph en una terminal de comandos distinta con una simulación y teleoperación lanzadas. Figura A-0-2. Resultado de ejecutar rqt_graph tras una simulación con teleoperación A. 3. Conexión real con el Summit-XL A continuación se explica cómo conectarnos al ordenador de a bordo del robot real en remoto desde nuestro PC. El procedimiento está sacado del manual de usuario del Summit-XL [4]. Sin embargo, hay cosas que difieren con respecto al manual o que no se especifican de manera explícita. Para detectar estas diferencias, se usa como referencia los textos de [21] y [22]. Antes de describir el procedimiento, es necesario definir los siguientes parámetros de nuestro PC: - Nombre del PC o hostname. 75 Sistema de detección de obstáculos para robot móvil SUMMIT - Dirección IP del PC. Debe tener una configuración del estilo 192.168.x.x. Para averiguar esos dos datos, hay que escribir lo siguiente en la terminal de comandos: hostname ifconfig Además, se debe diferenciar entre dos parámetros clave en el robot: - SerialNumber. Es el número de serie del robot: SXL00-190926AA. - hostname. Es el nombre del ordenador de a bordo del Summit-XL: summit. Cuando en el manual de usuario indique que se escriba o añada el SerialNumber del robot, realmente se refiere a esto, su hostname. Ahora sí, se describe el procedimiento de conexión al Summit-XL. Hay dos pasos previos: 1. Encender el Summit-XL (girar el selector de encendido principal a ON, a diferencia del procedimiento descrito en el manual de usuario). Para apagar el robot, la secuencia es la inversa a esta, es decir, girar el selector de encendido a OFF). De nuevo, difiere con lo que aparece en el manual de usuario. 2. Conectarse en el PC a la red WiFi del Summit: a. Red: SXL00-190926AA b. Clave: R0b0tn1K (R y K mayúsculas y vocales son números) Con esto ya podemos usar la funcionalidad básica, como es teleoperarlo con el mando de la PS4. Ahora tenemos dos opciones: A. Acceder al HMI del robot. Desde él podemos ver diferentes datos (estado sensores, motores, batería, cámara, etc.), además de poder teleoperarlo con el mando de la PS4 como antes. Su apariencia es ligeramente distinta a la descrita en el manual de usuario. Pasos para entrar: 1. Acceder a la dirección de internet: http://192.168.0.200/robotnik_hmi 2. Entrar a la interfaz con:  Usuario: admin  Contraseña: 4dm1n (las vocales son números) B. Acceder al ordenador de a bordo del Summit en forma remota desde el PC. Los pasos seguidos son: 1. Anadir el hostname del robot a nuestro archivo /etc/hosts. Para ello habrá que usar el editor de archivos nano con permisos de superusuario escribiendo en la terminal: cd /etc sudo nano hosts La contraseña que pedirá el comando sudo es la del PC personal que se esté usando. Escribir al principio del archivo lo siguiente: 192.168.0.200 summit Guardar y cerrar. 2. Ejecutamos el ordenador de a bordo del Summit en nuestro PC escribiendo en la terminal: export ROS_MASTER_URI= http://summit:11311 (Define el nodo Master del robot en la variable del sistema que corresponde) ssh summit@summit (Contraseña: R0b0tn1K. R y K mayúsculas. Vocales → números) cd ~/catkin_ws source devel/setup.bash 3. Si todo ha ido bien, ya podremos ver los topics que publica el robot y demás. Por ejemplo: rostopic list Anexo. Manual de usuario 76 4. Antes de comenzar a ver otras cosas, y que de cara al futuro todo funcione con normalidad, hay que añadir el hostname de nuestro PC al archivo /etc/hosts del robot. En la misma terminal donde se ejecutaron export y ssh: cd /etc sudo nano hosts La contraseña que pedirá el comando sudo es la del robot (R0b0tn1K). Escribir al principio del archivo lo siguiente: YourHostname YourIP Nótese que el hostname y la IP de arriba dependen del PC personal que se esté usando. Guardar y cerrar. 5. Para ver herramientas de tipo gráfico como rqt_graph o RViz, en otra terminal tenemos que ejecutar lo siguiente (cambiar ssh summit@summit por ssh -X summit@summit, ejecutando así el servidor X, apto para representaciones gráficas): export ROS_MASTER_URI= http://summit:11311 ssh -X summit@summit (Contraseña: R0b0tn1K. R y K Mayúsculas. Voca les → números) rosrun rviz rviz export ROS_MASTER_URI= http://summit:11311 ssh -X summit@summit (Contraseña: R0b0tn1K. R y K Mayúsculas. Voca les → números) rqt Tras el procedimiento de conexión y lanzamiento del robot real, puede ser necesario dar un paso más, ya que a veces al iniciar el robot en RViz no se visualiza el lidar, pero en el topic del mismo se sigue publicando. Si también miramos el estado de los sensores con el HMI, el Benewake aparece alternándose en tres modos: Init- Standby-Emergency. Para arreglarlo, lanzar el programa por defecto de la siguiente manera desde la terminal: export ROS_MASTER_URI=http://summit:11311 ssh summit@summit (Contraseña: R0b0tn1K. Vocales → números) cd ~/catkin_ws source devel/setup.bash screen -r bringup Esto muestra una pantalla de interacción con el robot en la que se puede interactuar con el mismo. El aspecto de dicha pantalla en la terminal de comandos es el de la Figura A-0-3. Figura A-0-3. Aspecto de la pantalla de interacción con el Summit-XL en su programa principal 77 Sistema de detección de obstáculos para robot móvil SUMMIT Cuando cargue esa pantalla en la terminal, si el lidar (benewake_c30) aparece en rojo, pulsar la tecla “m” y luego “s” (Start). Tras esto, debe aparecer en verde y, si miramos el HMI, el estado del lidar debe ser “Ready”. También se podrá visualizar correctamente en RViz. En el caso del robot real también es posible ejecutar el comando rqt_graph, como ya se ha comentado. Sin embargo, no se añade capturas debido a la dimensión del grafo, donde se forma una red bastante grande. Se detalla también cómo obtener información acerca del estado de la batería, que es de 24V a diferencia de lo que aparece en el manual de usuario. Para ello, tenemos dos opciones: 1. Acceder al HMI del robot como se ha explicado anteriormente. En dicha interfaz aparece una pantalla con información de la batería como se muestra en la Figura A-0-4. Figura A-0-4. Aspecto del apartado de la batería en el HMI del robot 2. Consultar lo publicado en el topic /robot/battery_estimator/data, escribiendo en la terminal de comandos: rostopic echo /robot/battery_estimator/data El resultado de aplicar lo anterior aparece en la terminal con un aspecto como el de la Figura A-0-5. Figura A-0-5. Resultado de consultar el topic con información del estado de la batería Por último, hay que tener cuidado de que el mando no se quede sin batería. Para ello, mantener siempre enchufado al USB del PC por si acaso (aunque funciona bien si está desenchufado con batería). El problema es que debido a problemas de configuración del fabricante, si el mando se queda sin batería, el Summit-XL ejecuta su última orden, que podría ser avanzar hacia delante, con el peligro que ello conlleva. A. 4. Configuración y visualización de RViz Es importante saber qué información queremos representar en RViz para que, a la hora de lanzarlo, se haga con una configuración por defecto que guardemos. La idea es abrir RViz por primera vez con los comandos ya explicados y configurar todos los displays de interés. Una vez hecho, se accede a “Files” → “Save as” y se guarda en la ruta deseada. Cuando se vuelva a llamar a la ejecución de RViz, se hará desde la terminal de Anexo. Manual de usuario 78 comandos pasando como argumento la configuración por defecto. En la Figura A-0-6 se puede observar una visualización de RViz con la configuración usada para el proyecto. Figura A-0-6. Configuración usada para RViz En la parte izquierda de la captura anterior se tiene el apartado de Displays donde se podrá añadir el tipo tantos tipos de visualización como se quiera de entre los disponibles. En este proyecto la configuración guardada presenta las siguientes características: - Nombre del archivo. Situado en la zona superior izquierda: config_rviz_mmn.rviz. - Display “Global Options” → “Fixed Frame”. Elegir /robot_odom para poder ver el mapa y los movimientos del robot. - Display “RobotModel”. Se completa desplegándolo y seleccionando el modelo URDF del robot, lo que permite su representación (viene por defecto). - Displays “Benewake PointCloud2” y “Orbbec PointCloud2”. Ambos son del tipo “PointCloud2” pero se les ha cambiado el nombre para identificarlos. Se emplean para representar las nubes de puntos del lidar y la cámara, respectivamente. Previamente hay que desplegarlos y seleccionar al topic al que se suscriben: /robot/front_3d_laser/scan para el lidar y /robot/front_rgbd_camera/depth/points para la cámara. - Display “TF”. Permite seleccionar uno o varios ejes de referencia para visualizarlos, conociendo así su posición y orientación. - Display “Camera”. Desplegándolo y suscribiéndose al topic de la imagen de la cámara (/robot/front_rgbd_camera/rgb/image_raw), hace posible la retransmisión de la escena en la esquina inferior izquierda. - Display “LaserScan”. A través de un conversor lanzado por defecto al iniciar el robot (nodo 3d_laser_to_2d), que convierte el tipo de mensaje sensor_msgs/PointCloud2 en mensajes del tipo sensor_msgs/LaserScan, se obtiene un escáner láser del lidar. Para configurarlo, desplegar y suscribir al topic que se obtiene (/robot/front_3d_laser/scan_2d o /robot/front_3d_laser/scan_2d_filtered). Sin embargo, a pesar de estar representado en esta imagen, no se usa mucho en el proyecto. - Display “DepthCloud”. Con él se puede representar la nube de puntos del canal de profundidad de una cámara RGBD. Además, se le puede superponer la imagen a color, tal y como se representa en la 79 Sistema de detección de obstáculos para robot móvil SUMMIT Figura A-0-6, sin más que configurar los dos topics necesarios a los que se suscribe el display. - Display “MarkerArray”. Este display sirve para representar el mapa 3D obtenido con la librería OctoMap. Hay que suscribirse al topic que genera el nodo del mapeado: /occupied_cells_vis_array. - Display “Map”. Se emplea para la representación de mapas 2D, en este caso el que la librería OctoMap permite obtener a partir del mapa 3D. Para ello, el display ha de suscribirse al topic /projected_map. Una vez configurado RViz para el robot real, se guarda en la ruta /home/summit/.rviz con el nombre config_rviz_mmn.rviz. Por tanto, para lanzar RViz con esa configuración hay que ejecutar lo siguiente en una terminal de comandos: export ROS_MASTER_URI=http://summit:11311 ssh –X summit@summit (Contraseña: R0b0tn1K. Vocales → números) cd /home/summit/.rviz rosrun rviz rviz -d config_rviz_mmn.rviz Para simulación, aunque no se especifique aquí, también se puede seguir el procedimiento explicado y configurarse la visualización por defecto de RViz según las necesidades. A. 5. Corrección visualización sensores El problema comentado durante el apartado 4.3 de esta memoria relativo al offset inicial en profundidad y altura entre ambos sensores se debía a un problema de situación de los mismos en el modelo URDF del robot que se representaba en RViz. Para corregirlo hay que acceder al código que define este modelo URDF, de nombre summit_xl_std.urdf.xacro, y modificarlo. Para ello, en una terminal: export ROS_MASTER_URI=http://summit:11311 ssh summit@summit (Contraseña: R0b0tn1K. Vocales → números) cd ~/catkin_ws/src/robot/summit_xl_common/summit_xl_description/robots sudo nano summit_xl_std.urdf.xacro (Contraseña: R0b0tn1K. Vocales → número s) Dentro de la modificación de ese archivo, hay que buscar la definición de la cámara y configurar la posición y orientación de la cámara RGBD para arreglar el offset de profundidad con la siguiente línea de código: <origin xyz="0.385 0.012 0.172" rpy="0 0 0"/> Por su parte, para arreglar el offset de altura, la línea de código del lidar Benewake es: <origin xyz="0.250 0.012 0.243" rpy="0 ${8*PI/180} 0"/> Una vez cambiado, se guarda el archivo y se cierra. Para compilar los cambios, se ejecuta lo siguiente en la terminal de comandos: cd ~/catkin_ws catkin build source devel/setup.bash Si al abrir de nuevo RViz, la configuración no se ha cambiado, puede que sea necesario reiniciar el robot, repitiendo todo el proceso de conexión explicado en otros apartados. Anexo. Manual de usuario 80 A. 6. Descarga package mapeado e implementación del filtro En este apartado se pretende mostrar cómo introducir la funcionalidad del mapeado 3D en el ordenador de a bordo del Summit-XL (y cualquier otro archivo) y cómo configurarlo. Para ello se recurre a [30]. Además se explica la manera de implementar el filtro del que se habló en el apartado 5.1. Los pasos seguidos para introducir la funcionalidad de mapeado 3D son: 1. Antes de conectar el PC a la WiFi del Summit-XL (para poder tener internet), se descarga de [25] manualmente el stack de ROS octomap_mapping, en cuyo interior se encuentra el package octomap_server, que es el que se usará. Acto seguido se descomprime. 2. En una terminal nos conectamos al Summit-XL y creamos todas las carpetas y subcarpetas necesarias para el stack y sus packages con el comando mkdir nombre_directorio, previa situación en la ruta que se quiera (~/catkin_ws/src/octomap_mapping/…) con el comando cd. 3. En otra terminal trabajamos con nuestro ordenador. Podremos mover archivos (NO directorios) al Summit-XL. Para ello empleamos el comando scp, previa situación con el comando cd en el directorio de nuestro PC donde se encuentre el archivo a copiar o mover. Un ejemplo: scp CMakeLists.txt summit@summit:~/catkin_ws/src/octomap_mapping/octoma p_server El ejemplo anterior copia el archivo CMakeLists.txt desde el directorio de trabajo actual del PC hasta la ruta del ordenador del Summit-XL detallada. Repetir esto para todos los archivos del stack octomap_mapping hasta replicar su estructura en el ordenador del robot. 4. Entrar en los lanzadores del package octomap_server y modificar el archivo que permite lanzar el mapeado 3D, pudiendo así configurar los parámetros que se le pasan a la función del mapa. Para ello, en una terminal de comandos conectada al Summit-XL: cd ~/catkin_ws/src/octomap_mapping/octomap_server/launch sudo nano octomap_mapping.launch (Contraseña: R0b0tn1K. Vocales → númer os) Dentro de ese archivo, el código de lanzamiento será el siguiente [26]: <launch> <node pkg="octomap_server" type="octomap_server_node" name="octomap_server"> <param name="resolution" value="0.05" /> <!-- fixed map frame (set to 'map' if SLAM or localization running!) --> <param name="frame_id" type="string" value="robot_odom" /> <!-- maximum range to integrate (speedup!) --> <param name="sensor_model/max_range" value="5.0" /> <param name="height_map" value="true" /> <param name="latch" value="false" /> <!-- <param name="filter_ground" value="false" /> --> <param name="pointcloud_min_z" value="0.02" /> <param name="pointcloud_max_z" value="1.0" /> <!-- data source to integrate (PointCloud2) --> <remap from="cloud_in" to="/robot/pointcloud2/fusion" /> </node> 81 Sistema de detección de obstáculos para robot móvil SUMMIT </launch> Estos parámetros, como ya se ha explicado en el apartado 4.5.3, permiten la representación de mapas con una resolución de 5cm, respecto al eje de coordenadas /robot_odom, considerar puntos de la nube de puntos de distancia máxima de 5m, altura mínima de 0.02m (para no incluir el suelo como un obstáculo) y altura máxima 1m (ya que no nos interesan alturas mayores para el Summit-XL). Además, el topic de nube de puntos al que se suscribe tendrá que ser modificado según se quiera usar: o Lidar: /robot/front_3d_laser/scan o Cámara: /robot/front_rgbd_camera/depth/points o Fusión (que se explica en el próximo apartado cómo obtenerla): /robot/pointcloud2/fusión 5. Volver a la carpeta principal y compilar los cambios. Este paso tardará unos minutos debido a que se ha incluido un nuevo stack en el ordenado del robot. En la terminal de comandos conectada al robot: cd ~/catkin_ws catkin build source devel/setup.bash Si al intentar compilar con el comando catkin build salta un error sobre el CMakeLists.txt, configurar este según lo descrito en [31] y volver a compilar, ahora sí, con éxito. 6. En la terminal de comandos, con el robot ya iniciado (puede que para visualizar los cambios en el lanzamiento de la librería OctoMap haya que reiniciar el robot, teniendo que conectarse de nuevo al mismo), lanzar el mapeado: roslaunch octomap_server octomap_mapping.launch 7. En otra terminal, abrir RViz según lo explicado en el apartado anterior y configurar el Display “MarkerArray” para que quede suscrito al topic de nombre /occupied_cells_vis_array, observándose de esta manera el mapa 3D en RViz. Para ver el mapa 2D, suscribirse con el Display “Map” al topic /projected_map. De esta manera se ha conseguido visualizar los mapas 2D y 3D en el robot real. De igual forma que se ha procedido para la realidad, se puede hacer para la simulación, siendo más fácil la inclusión del package en el workspace (se puede hacer una copia manual desde la interfaz del directorio de archivos). Hay que tener en cuenta que el nombre de los topics en simulación puede variar (buscar con el comando rostopic list) y que el nodo del mapa tiene que suscribirse a un topic cuyo mensaje sea del tipo sensor_msgs/PointCloud2, no siendo por tanto válido el lidar del que se dispone para simulación. Realmente no parece que sea necesario incluir el stack octomap_mapping en nuestro workspace, pues suele venir instalado con ROS por defecto. Sin embargo, en este caso se ha optado por incluirlo para modificar el archivo de lanzamiento (y con ello los parámetros del mapeado) de una manera más fácil. Además, se va a comentar a continuación cómo se implementó el filtro necesario, por lo que hay que modificar más archivos del package octomap_server. Para aplicar el filtro, hay que llevar a cabo los siguientes pasos: 1. Modificar la librería OctomapServer.h, cuya ruta es ~/catkin_ws/src/octomap_mapping/octomap_server/include/octomap_server. Se incluye en la clase OctomapServer el parámetro m_minRange. Su uso será análogo al parámetro ya existente de nombre m_maxRange, siendo en este caso una distancia mínima desde el lidar para considerar el punto de la nube de puntos como obstáculo. Se accede al código OctomapServer.h: cd ~/catkin_ws/src/octomap_mapping/octomap_server/include/octomap_serve r sudo nano OctomapServer.h (Contraseña: R0b0tn1K. Vocales → números) Y se añade la siguiente línea de código en la línea 217: Anexo. Manual de usuario 82 double m_minRange; 2. Modificar el código fuente OctomapServer.cpp, cuya ruta es ~/catkin_ws/src/octomap_mapping/octomap_server/src. Se incluye la definición del parámetro m_minRange y su uso como condición para considerar los puntos las nubes de puntos que estén dentro del rango de distancias delimitado por m_minRange y m_maxRange. Para acceder al código: cd ~/catkin_ws/src/octomap_mapping/octomap_server/src sudo nano OctomapServer.cpp (Contraseña: R0b0tn1K. Vocales → números) Añadiendo las siguientes líneas de código (se pone en color verde el número de línea entre paréntesis a la derecha): m_minRange(0.0), (Línea 50) m_nh_private.param("sensor_model/min_range", m_minRange, m_minRange); (Línea 104) if ((m_maxRange > 0.0) && ((point - sensorOrigin).norm() > m_maxRange) && ((point - sensorOrigin).norm() < m_minRange)) { (Línea 376) if (((m_maxRange < 0.0) || ((point - sensorOrigin).norm() <= m_maxRange)) && ((point - sensorOrigin).norm() >= m_minRange)) { (Línea 398) 3. Modificar el archivo de lanzamiento octomap_mapping.launch, cuya ruta es ~/catkin_ws/src/octomap_mapping/octomap_server/launch. Se incluye como argumento al parámetro sensor_model/min_range, que así se ha definido en la línea 104 del código OctomapServer.cpp, y se le pasa el valor que se desee. Es importante saber que si no se pasa este argumento, el mapeado no funciona. Por tanto, si no se quiere usar el filtro, pasar como argumento para ese parámetro el valor cero o deshacer los cambios en los códigos OctomapServer.h y OctomapServer.cpp. Se accede al código del lanzamiento del mapeado: cd ~/catkin_ws/src/octomap_mapping/octomap_server/launch sudo nano octomap_mapping.launch (Contraseña: R0b0tn1K. Vocales → númer os) La línea que hay que añadir a los argumentos es: <!-- minimum range to integrate --> <param name="sensor_model/min_range" value="0.12" /> 4. Por último, volver a la carpeta principal, compilar los cambios y lanzar de nuevo el mapeado. Si no se observa el efecto del filtro, reiniciar el robot, repitiendo el proceso de conexión remoto al mismo desde el PC. En la terminal de comandos: cd ~/catkin_ws catkin build source devel/setup.bash roslaunch octomap_server octomap_mapping.launch A. 7. Lanzamiento proyecto completo Finalmente, y a modo de resumen, para probar la aplicación completa de este trabajo es necesario lanzar, en el siguiente orden: lanzamiento robot, visualización en RViz, redireccionamiento del topic del lidar al topic de fusión, redireccionamiento del topic de la cámara al topic de fusión, mapeado 3D. Se requiere, por tanto, los siguientes pasos: 83 Sistema de detección de obstáculos para robot móvil SUMMIT 1. En una terminal, tras iniciar el robot y conectarnos a su red WiFi: export ROS_MASTER_URI=http://summit:11311 ssh summit@summit (Contraseña: R0b0tn1K. Vocales → números) cd ~/catkin_ws source devel/setup.bash screen -r bringup Cuando cargue el programa en la terminal, si Benewake aparece en rojo, pulsar m (Benewake) y luego s (Start). 2. En otra: export ROS_MASTER_URI=http://summit:11311 ssh -X summit@summit (Contraseña: R0b0tn1K. Vocales → números) cd /home/summit/.rviz rosrun rviz rviz -d config_rviz_mmn.rviz 3. En otra: export ROS_MASTER_URI=http://summit:11311 ssh summit@summit (Contraseña: R0b0tn1K. Vocales → números) rosrun topic_tools relay /robot/front_3d_laser/scan /robot/pointcloud2/ fusion 4. En otra: export ROS_MASTER_URI=http://summit:11311 ssh summit@summit (Contraseña: R0b0tn1K. Vocales → números) rosrun topic_tools relay /robot/front_rgbd_camera/depth/points /robot/p ointcloud2/fusion 5. Y, por último, en otra terminal: export ROS_MASTER_URI=http://summit:11311 ssh summit@summit (Contraseña: R0b0tn1K. Vocales → números) cd ~/catkin_ws source devel/setup.bash roslaunch octomap_server octomap_mapping.launch