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

El presente trabajo de fin de grado tiene como finalidad la obtencion de mapas 3D de fondos acuaticos poco profundos. Apoyandose en software ya desarrollado, se crea una nueva herramienta de reconstruccion del fondo a traves de medidas tomadas mediante un sonar acoplado a un robot submarino, el Sparus II. La idea del trabajo deriva del problema de Localizacion y Mapeado Simultaneo (SLAM). Esta tecnica consiste en la estimacion de la trayectoria del robot a la vez que se construye un mapa del entorno en el que se encuentra este, siendo el entorno desconocido. Se parte del simulador UWSim, una herramienta ideal para la simulacion de misiones marinas. La configuracion de los escenarios a simular se hace de manera sencilla mediante un documento de tipo .xml, donde podemos incluir tantos objetos como se desee, asi como parametrizar el entorno de manera que se ajuste lo mejor posible a las condiciones reales de trabajo, como puede ser el oleaje, presion, corrientes, claridad del agua, etc. Este simulador ofrece tambien una gran variedad de sensores que se pueden adaptar facilmente tanto al escenario como al vehiculo 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 mas rapido, uno de estos elementos que merece la pena destacar es el robot Girona500 que, aunque finalmente decidamos realizar el proyecto con otro vehiculo, se trata de un vehiculo subacuatico extensamente conocido por el mundo de la robotica marina. Indicar por ultimo que se trata de un software de codigo abierto y que ofrece una interfaz muy completa y configurable para hacer posible su comunicacion con ROS. Existe una gran cantidad de metodos de generacion de mapas 3D, pero una gran mayoria se basa en las mediciones de sonares. 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 navegacion o la deteccion de objetos. La tecnologia 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 tecnologia sonar) colocados de tal manera que se consigue un conjunto de medidas de distancia en la direccion a la que apunte el haz. Sera este sensor el que usaremos durante todo el proyecto para realizar barridos del fondo y se colocara en la panza del robot en sentido transversal al de avance de este. A continuacion se investigan las opciones que existen para implementar el control del robot, aqui nos encontramos con COLA2, una arquitectura de control y navegacion que ya implementa UWSim ademas de aportar su propia interfaz de comunicacion con ROS. Nuestra aplicacion entonces se comunicara con COLA2, y dejaremos que sea COLA2 el que controle UWSim. La documentacion 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 ordenes al vehiculo para que se desplace por el escenario. COLA2 nos proporciona dos vehiculos distintos: el Girona500 y el Sparus II. Ambos son robots disenados para la ejecucion de misiones subacuaticas, cada uno con sus ventajas y desventajas. La caracteristica que mas nos afecta es la facilidad de control de navegacion que ofrece cada uno de ellos. Por simplicidad, nos quedamos con el Sparus II, vehiculo sencillo, de tipo torpedo, pensado para misiones en aguas poco profundas. Desarrollamos ahora una aplicacion que se comunique con COLA2 a traves de ROS cuyo objetivo sera el de ejercer de capitan del vehiculo, 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 utiles que mas tarde constituiran el mapa 3D. Aparece entonces el termino de Pointclouds o nubes de puntos, que no son mas que una coleccion de puntos que hara extremadamente facil el manejo de todos los datos recibidos del sensor. Para esta tarea es necesario el desarrollo de otra aplicacion que consiga recolectar las medidas suministradas por el multibeam durante un periodo de tiempo y crear distintas nubes de puntos segun avanza el tiempo de ejecucion de la mision. Una vez tenemos las nubes de puntos almacenadas, llega la hora de generar los mapas 3D. Esta tarea podria realizarse de manera muy sencilla simplemente concatenando las diferentes nubes de puntos para finalmente crear una nube de puntos que represente toda el area barrida por el sensor multibeam. Pero al tratarse de una simulacion 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 pequenos ruidos se van arrastrando entre proceso y proceso, convirtiendose finalmente en errores de mayor o menor importancia. De esta manera, dos nubes de puntos pueden no coincidir perfectamente, por ejemplo, al implementar una rotacion en medios donde existan corrientes, puede provocar un desplazamiento en la lectura de las medidas del multibeam. Para solventar estos errores, se estudia a continuacion la aplicacion 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 area, o de dos areas distintas pero que se solapen entre ellas, el algoritmo intentara rotar y/o trasladar una de las nubes de puntos de tal manera que ambas coincidan lo maximo 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 mas de 10 tipos de filtros distintos, y no solo eso, sino que tambien se puede generar una cadena de filtros para cada imagen. Por otro lado existen distintos elementos para afinar aun mas el resultado final y conseguir una mejor calidad. Aunque libpointmatcher ofrece una buena documentacion con tutoriales y ejemplos para el aprendizaje de su uso, cuando se quiere profundizar y ejecutar unos procesos mas complejos la documentacion se queda un poco corta. Se dedica un tiempo considerable en ensayo y error para ejecutar el filtrado y la union de las nubes de puntos para construir el mapa final. Para finalizar, con el objetivo de realizar una valoracion del proyecto, se disenan distintos escenarios donde cada uno de ellos contiene objetos de diferentes tipos de superficies (conos, esferas, prismas). Esto nos permitira 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 si podemos destacar alguna observacion. Asi mismo, y con el mismo objetivo de valoracion, se disenan tres trayectorias diferentes, que requeriran tiempos de ejecucion distintos y produciran nubes de puntos que se solapen mas o menos. En este caso, si que hay una trayectoria que destaca del resto en la calidad de mapas que se generan posteriormente. Aunque quiza sea necesario aumentar la muestra para que la afirmacion sea mas consistente.