Reconstrucción 3D de fondos marinos mediante sensores acústicos sobre AUVs

El presente trabajo de fin de grado tiene como finalidad la obtención de mapas 3D de fondos acuáticos poco profundos. Apoyándose en software ya desarrollado, se crea una nueva herramienta de reconstrucción del fondo a través de medidas tomadas mediante un sonar acoplado a un robot submarino, el Sparus II. La idea del trabajo deriva del problema de Localización y Mapeado Simultáneo (SLAM). Esta técnica consiste en la estimación de la trayectoria del robot a la vez que se construye un mapa del entorno en el que se encuentra éste, siendo el entorno desconocido. Se parte del simulador UWSim, una herramienta ideal para la simulación de misiones marinas. La configuración de los escenarios a simular se hace de manera sencilla mediante un documento de tipo .xml, donde podemos incluir tantos objetos como se desee, así como parametrizar el entorno de manera que se ajuste lo mejor posible a las condiciones reales de trabajo, como puede ser el oleaje, presión, corrientes, claridad del agua, etc. Este simulador ofrece también una gran variedad de sensores que se pueden adaptar fácilmente tanto al escenario como al vehículo que se introduzca en la escena, teniendo en cuenta siempre las relaciones entre los sistemas de referencia de los distintos elementos, siendo necesario declarar estas relaciones para una correcta lectura de los datos que ofrecen los sensores. UWSim incluye por defecto distintos elementos que permiten un aprendizaje más rápido, uno de estos elementos que merece la pena destacar es el robot Girona500 que, aunque finalmente decidamos realizar el proyecto con otro vehículo, se trata de un vehículo subacuático extensamente conocido por el mundo de la robótica marina. Indicar por último que se trata de un software de código abierto y que ofrece una interfaz muy completa y configurable para hacer posible su comunicación con ROS. Existe una gran cantidad de métodos de generación de mapas 3D, pero una gran mayoría se basa en las mediciones de sónares. Debido a que el GPS pierde funcionalidad bajo el agua, se precisa de otros sensores con los que tras un tratamiento de sus medidas sea posible la navegación o la detección de objetos. La tecnología sonar es la indicada para suplir la carencia del GPS. UWSim nos proporciona un sensor llamado multibeam, que consiste en un array de sensores de distancia (que implementan tecnología sonar) colocados de tal manera que se consigue un conjunto de medidas de distancia en la dirección a la que apunte el haz. Será este sensor el que usaremos durante todo el proyecto para realizar barridos del fondo y se colocará en la panza del robot en sentido transversal al de avance de éste. A continuación se investigan las opciones que existen para implementar el control del robot, aquí nos encontramos con COLA2, una arquitectura de control y navegación que ya implementa UWSim además de aportar su propia interfaz de comunicación con ROS. Nuestra aplicación entonces se comunicará con COLA2, y dejaremos que sea COLA2 el que controle UWSim. La documentación de COLA2 se puede considerar un tanto escasa, por lo que se implementa un tiempo considerable en el estudio de esta arquitectura y de su interfaz con el objetivo de obtener el servicio que nos permite enviar órdenes al vehículo para que se desplace por el escenario. COLA2 nos proporciona dos vehículos distintos: el Girona500 y el Sparus II. Ambos son robots diseñados para la ejecución de misiones subacuáticas, cada uno con sus ventajas y desventajas. La característica que más nos afecta es la facilidad de control de navegación que ofrece cada uno de ellos. Por simplicidad, nos quedamos con el Sparus II, vehículo sencillo, de tipo torpedo, pensado para misiones en aguas poco profundas. Desarrollamos ahora una aplicación que se comunique con COLA2 a través de ROS cuyo objetivo será el de ejercer de capitán del vehículo, esto es, enviar punto a punto las sucesivas posiciones objetivo que se desea que el robot alcance. De esta manera conseguimos que el Sparus recorra una trayectoria predefinida. A medida que el robot se desplaza por el escenario, el multibeam va publicando sus mediciones continuamente. Debemos encargarnos de recoger las mediciones y transformarlas en datos útiles que más tarde constituirán el mapa 3D. Aparece entonces el término de Pointclouds o nubes de puntos, que no son más que una colección de puntos que hará extremadamente fácil el manejo de todos los datos recibidos del sensor. Para esta tarea es necesario el desarrollo de otra aplicación que consiga recolectar las medidas suministradas por el multibeam durante un periodo de tiempo y crear distintas nubes de puntos según avanza el tiempo de ejecución de la misión. Una vez tenemos las nubes de puntos almacenadas, llega la hora de generar los mapas 3D. Esta tarea podría realizarse de manera muy sencilla simplemente concatenando las diferentes nubes de puntos para finalmente crear una nube de puntos que represente toda el área barrida por el sensor multibeam. Pero al tratarse de una simulación de entornos reales, nada es ideal, existen multitud de elementos que producen errores en las mediciones, estos errores son conocidos como ruidos. Al ser un proyecto en el que se sigue un flujo continuo, los pequeños ruidos se van arrastrando entre proceso y proceso, convirtiéndose finalmente en errores de mayor o menor importancia. De esta manera, dos nubes de puntos pueden no coincidir perfectamente, por ejemplo, al implementar una rotación en medios donde existan corrientes, puede provocar un desplazamiento en la lectura de las medidas del multibeam. Para solventar estos errores, se estudia a continuación la aplicación libpointmatcher. Esta herramienta ejecuta un algoritmo que se encarga de corregir una nube de puntos respecto otra, es decir, teniendo dos nubes de puntos de una misma área, o de dos áreas distintas pero que se solapen entre ellas, el algoritmo intentará rotar y/o trasladar una de las nubes de puntos de tal manera que ambas coincidan lo máximo posible. Esto solventa en cierta medida los errores que se han ido arrastrando desde el inicio del trabajo. Pero no es todo tan sencillo, descubrimos que libpointmatcheres una herramienta que cuando se profundiza en su estudio, ofrece toda una variedad de configuraciones posibles a la hora de corregir una imagen respecto de otra. Por ejemplo, se pueden implementar más de 10 tipos de filtros distintos, y no solo eso, sino que también se puede generar una cadena de filtros para cada imagen. Por otro lado existen distintos elementos para afinar aún más el resultado final y conseguir una mejor calidad. Aunque libpointmatcher ofrece una buena documentación con tutoriales y ejemplos para el aprendizaje de su uso, cuando se quiere profundizar y ejecutar unos procesos más complejos la documentación se queda un poco corta. Se dedica un tiempo considerable en ensayo y error para ejecutar el filtrado y la unión de las nubes de puntos para construir el mapa final. Para finalizar, con el objetivo de realizar una valoración del proyecto, se diseñan distintos escenarios donde cada uno de ellos contiene objetos de diferentes tipos de superficies (conos, esferas, prismas). Esto nos permitirá establecer en cierta medida el efecto que tienen los objetos presentes en el entorno en la calidad del mapa generado. Finalmente se descubre que no se puede afirmar nada sobre el efecto que tienen los cuerpos en la calidad del mapa, aunque sí podemos destacar alguna observación. Así mismo, y con el mismo objetivo de valoración, se diseñan tres trayectorias diferentes, que requerirán tiempos de ejecución distintos y producirán nubes de puntos que se solapen más o menos. En este caso, sí que hay una trayectoria que destaca del resto en la calidad de mapas que se generan posteriormente. Aunque quizá sea necesario aumentar la muestra para que la afirmación sea más consistente