RECONSTRUCCION 3D DE FONDOS

MARINOS MEDIANTE SENSORES

ACUSTICOS SOBRE AUVs

Oscar L. Manrique Garcıa

Grado en Ingenierıa Electronica Industrial y Automatica

Escuela Tecnica Superior de Ingenieros Industriales - UPM

Proyecto de Fin de Grado

Propuesto por Antonio Barrientos Dirigido por Mario Garzon

Julio 2017

Resumen

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 misio-

nes 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, ası como parametrizar el entorno de manera que se ajuste lo mejor posi-

ble 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 vehıculo que se intro-

duzca en la escena, teniendo en cuenta siempre las relaciones entre los sistemas de

referencia de los distintos elementos, siendo necesario declarar estas relaciones pa-

ra 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 vehıculo, se trata de un vehıculo 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

mayorıa se basa en las mediciones de sonares. Debido a que el GPS pierde funcio-

nalidad 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 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 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, aquı 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 conside-

rar 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 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 disenados para la ejecucion de misiones subacuaticas, cada uno con sus

ventajas y desventajas. La caracterıstica 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, vehıculo 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 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 trans-

formarlas 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 reco-

lectar 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 podrıa realizarse de manera muy sencilla simplemente concatenando

las diferentes nubes de puntos para finalmente crear una nube de puntos que repre-

sente todo 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 pun-

tos 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 libpointmatcher

es 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 sı podemos destacar alguna observacion.

Ası mismo, y con el mismo objetivo de valoracion, se disenan tres trayectorias dife-

rentes, que requeriran tiempos de ejecucion distintos y produciran nubes de puntos

que se solapen mas o menos. En este caso, sı 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.

0.1. Codigos UNESCO

1203 CIENCIA DE LOS ORDENADORES

1203.04 INTELIGENCIA ARTIFICIAL

3311.01 TECNOLOGIA DE LA AUTOMATIZACION

3311.02 INGENIERIA DE CONTROL

3311.02 INGENIERIA DE CONTROL

3319.13 VEHICULOS SUBMARINOS

1203.21 SISTEMAS DE NAVEGACION Y TELEMETRIA DEL ESPACIO

1203.23 LENGUAJES DE PROGRAMACION

1209.03 ANALISIS DE DATOS

0.2. Palabras clave

Keywords: 3D mapping, pointcloud, laserScan, multibeam sensor, Sparus II ,lib-

pointmatcher, pointcloud filtering, seaflor, UWSim, map reconstruction, iterative

closest point, COLA2.

AGRADECIMIENTOS

Aprovecho este espacio para agradecer a las personas que me han acompanado durante esta

etapa.

Papa y Mama, gracias por no perder la confianza en mı, incluso en momentos donde yo sı lo

hice. Gracias por vuestro enorme sacrificio que ha hecho posible que hoy sea Ingeniero. Y sobre

todo, gracias por educarme y transmitirme vuestros valores.

Jorge y Debora, Amigos con mayuscula.

i

Indice general

0.1. Codigos UNESCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

0.2. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

AGRADECIMIENTOS I

Indice de figuras IV

1. INTRODUCCION 1

1.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Marco del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3. Objetivo del proyecto de fin de carrera . . . . . . . . . . . . . . . . . . . . . . . . 2

2. ESTADO DEL ARTE 3

2.1. Tecnologıas de representacion de mapas . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. Tecnologıas sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1. Elementos del sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2. Tipos de sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.3. Multibeam sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3. Mapeado del fondo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3. MATERIAL 9

3.1. ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2. UWSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3. COLA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4. Sparus II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4.1. Arquitectura del software . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.5. LibPointMatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

ii

INDICE GENERAL

4. METODOLOGIA Y DESARROLLO 21

4.1. Estudio y manejo de simulador de vehıculos en entornos submarinos . . . . . . . 21

4.2. Comunicacion entre ROS y UWSim . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3. Estudio y valoracion de sensores ofrecidos por el simulador . . . . . . . . . . . . 23

4.4. Adaptacion de multibeam sensor al Robot . . . . . . . . . . . . . . . . . . . . . . 25

4.5. Valoracion de la herramienta COLA2 . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.6. Comparacion de los dos modelos de robots que ofrece COLA2 . . . . . . . . . . . 26

4.7. Creacion de un path para el robot . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.8. Lectura de mediciones obtenidas por el multibeam sensor . . . . . . . . . . . . . 30

4.9. Transformacion de los datos a Pointclouds . . . . . . . . . . . . . . . . . . . . . . 32

4.10. Estudio de libpointmatcher para reconstruccion 3D . . . . . . . . . . . . . . . . . 35

4.11. Experimentos y Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5. EXPERIMENTOS Y RESULTADOS 40

5.1. Trayectorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2. Escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3. Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4. Observaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6. CONCLUSIONES Y LINEAS FUTURAS 56

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2. Lıneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7. PLANIFICACION Y PRESUPUESTO 58

7.1. Estructura de Descomposicion del Proyecto . . . . . . . . . . . . . . . . . . . . . 58

7.2. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Bibliografıa 62

iii

Indice de figuras

2.1. Sonar squeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2. Multibeam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3. Fondo Marino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1. Sparus II 3D model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2. Girona 500 3D model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3. Sparus II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4. Bloques ICP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1. Escena por defecto de UWSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2. Esquema de multibeam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3. Multibeam Draw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4. Rviz multibeam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.5. Secuencia de alcance de posicion objetivo. . . . . . . . . . . . . . . . . . . . . . . 29

4.6. Secuencia temporal de lectura de medidas del multibeam. . . . . . . . . . . . . . 31

4.7. Solapado Erroneo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.8. Ejemplo de union de nubes de puntos. . . . . . . . . . . . . . . . . . . . . . . . . 34

4.9. Ejemplo de escenario y nubes de puntos . . . . . . . . . . . . . . . . . . . . . . . 37

4.10. ICP sin Lımites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.11. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.12. ICP con Lımites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1. Trayectoria Rectangular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2. Trayectoria Circular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3. Trayectoria Triangular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.4. Escenario de conos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

iv

INDICE DE FIGURAS

5.5. Escenario de cilindros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.6. Escenario de prismas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.7. Trayectoria esferas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.8. Escenario de varias figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.9. Conos trayectoria rectangular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.10. Conos trayectoria circular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.11. Conos trayectoria triangular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.12. Prismas trayectoria rectangular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.13. Prismas trayectoria circular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.14. Prismas trayectoria triangular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.15. Cilindros trayectoria rectangular. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.16. Cilindros trayectoria circular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.17. Cilindros trayectoria triangular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.18. Esferas trayectoria rectangular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.19. Esferas trayectoria circular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.20. Esferas trayectoria triangular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.21. Varias figuras trayectoria rectangular. . . . . . . . . . . . . . . . . . . . . . . . . 52

5.22. Varias figuras trayectoria circular. . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.23. Varias figuras trayectoria triangular. . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.1. EDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.2. Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

v

1

INTRODUCCION

1.1. Motivacion

El reconocimiento del fondo marino siempre ha supuesto un reto para la navegacion subacuati-

ca, ya que las condiciones en este entorno son muy diferentes a las que se presentan en la superficie

terrestre y que, ademas, evitan el uso de tecnologıas hoy en dıa muy avanzadas que sirven para

la navegacion terrestre, como ejemplo tenemos el GPS. Es por estas restricciones lo que hace

difıcil la navegacion.

El estudio de los fondos marinos y su conocimiento a la hora de llevar a cabo las misiones,

supone una gran ventaja cuando hablamos de navegacion, y mas aun si se trata de navegacion

autonoma.

De esta manera, se realiza una investigacion de los distintos modos de generacion de mapas

3D y de las diferentes herramientas que se utilizan durante el proceso. Se pretende generar un

proceso de principio a fin, esto es, generando una mision y una recoleccion de datos para su

posterior procesamiento y generar ası el mapa 3D.

1.2. Marco del proyecto

Esta enmarcado en las actividades de investigacion del grupo Robotica y Cibernetica de la

Escuela Tecnica Superior de Ingenieros Industriales de Madrid, entre las cuales se encuentran

diferentes aplicaciones de tecnicas de navegacion autonoma de robots moviles y reconstruccion

3D de escenarios empleando diferentes metodos.

Las investigaciones realizadas, ası como el proyecto desarrollado, sera utilizado en un futuro

para proyectos de busqueda y rescate ademas de otras tareas y aplicaciones de la robotica de

1

1.3 Objetivo del proyecto de fin de carrera

alto nivel, pudiendose integrar en flotas heterogeneas de multiples robots.

1.3. Objetivo del proyecto de fin de carrera

El presente trabajo tiene como objetivo principal el desarrollo de una aplicacion de recons-

truccion 3D utilizando robots submarinos y los sensores usualmente utilizados en estos robots,

realizando un estudio de las diferentes herramientas existentes para su implementacion.

El proyecto se puede dividir en distintos sub-objetivos claramente diferenciados:

Estudio y manejo de un simulador de vehıculos en entornos acuaticos

Integracion de distintas herramientas de manera que puedan trabajar conjuntamente

Tratamiento de nubes de puntos

Filtrado y generacion de mapas 3D

2

2

ESTADO DEL ARTE

El problema de Localizacion y Mapeado Simultaneo (SLAM) requiere de dos tareas princi-

pales:

Generacion del mapa

Autolocalizacıon dentro de el mapa generado

Estas tareas deben realizarse durante la ejecucion de la mision, permitiendo que los vehıculos

puedan navegar de manera autonoma.

A lo largo de los anos se han ido desarrollando distintas tecnologıas para diferentes tipos de

misiones.

2.1. Tecnologıas de representacion de mapas

Centrandonos en el problema de generar un mapa de elevacion, nos encontramos distintos

modelos de representacion, a continuacion se citan solo algunos:

Modelo Digital de Elevacion (DEM) (1): representacion de la altura de la superficie

con respecto del nivel medio del mar.

Modelo Digital de Terreno (DTM): una derivacion del Modelo Digital de Elevacion, se

genera una serie de operaciones al DEM para obtener mapas con otro tipo de informacion

como puede ser pendientes, orientacion, curvatura, etc. (2)

Pointclouds o nube de puntos: como su propio nombre indica, se trata de una coleccion

de puntos que contienen informacion sobre sus coordenadas en el espacio. Esta tecnologıa

3

2.2 Tecnologıas sonar

ofrece una gran variedad de opciones de manipulacion, lo que hace que sea extensamente

utilizada en multitud de areas. (3)

OctoMap: se trata de un modelo probabilıstico de ocupacion. (4)

2.2. Tecnologıas sonar

Aunque en la actualidad existen distintos tipos de sonar (Sound Navigation and Ranging),

el funcionamiento de todos ellos se basa en el mismo fenomeno fısico, la transmision de ondas

sonoras por medio acuatico. Estas ondas son recogidas por un receptor para estudiarlas despues

y obtener los datos de interes.

Figura 2.1: Tecnologıa Sonar Esquema simple de la tecnologıa sonar

La duda que uno se plantea cuando no tiene conocimientos acerca de los sistemas de navega-

cion submarinos es por que no se usa la misma tecnologıa de navegacion terrestre. De un modo

mas tecnico, ¿por que no se usan ondas electromagneticas?

Las ondas electromagneticas sufren una amortiguacion enorme en agua salada, mientras

que las mecanicas (como las que usan los sonar) son transmitidas en el medio con gran

4

2.2 Tecnologıas sonar

facilidad.

La celeridad de propagacion del sonido es mayor en medios poco compresibles, por lo que

en el agua tendra una celeridad mayor que en el aire.

A pesar de que las ondas de propagacion del sonido son esfericas, este no se transmite de

forma uniforme, esto es debido a que la celeridad se ve afectada por varios factores fısicos, entre

los que destacan la temperatura, salinidad y la presion. Es por esto que los vehıculos deben

incluir sensores que obtengan mediciones de estas propiedades del medio acuatico para que las

lecturas recogidas por el sonar sean optimas.

2.2.1. Elementos del sonar

El sonar se compone de varios elementos:

Transmisor: se encarga de emitir impulsos ultrasonicos por el emisor.

Emisor

Receptor: capta los impulsos rebotados al colisionar con un objeto.

Indicador: muestra los objetos con los cuales los impulsos han rebotado

Cabe decir que no todos los sensores sonar estan compuestos por los cuatro elementos, a conti-

nuacion veremos los distintos tipos de sonar.

2.2.2. Tipos de sonar

Aunque en la actualidad existen varios tipos de sensores de tipo sonar, todos se pueden

dividir en 2 grandes grupos:

Sonar activo: consta de emisor y receptor. Cuando el receptor recibe los impulsos se

realiza un analisis de los tiempos y, conociendo la celeridad del sonido en el medio en el

que se encuentra el sonar se obtiene la distancia a la que el objeto se encuentra.

Sonar pasivo: son meros receptores de sonidos que emiten otros objetos.

5

2.2 Tecnologıas sonar

2.2.3. Multibeam sonar

Estos sensores son un conjunto de sonar acoplados de tal manera que se pueda barrer una

mayor superficie y ası cubrir mas espacio. Por ello, estos sensores son altamente utilizados en

batimetrıa (ciencia que estudia las profundidades marinas). Como caracterıstica especial de estos

sensores, es que implementan un filtrado espacial conocido como Conformacion de Haces

(Beamforming)(5) con el que se consigue informacion direccional de las ondas obteniendo ası un

barrido de lecturas de profundidad.

Figura 2.2: Multibeam Ejemplo de barrido que realiza un multibeam.

6

2.3 Mapeado del fondo

2.3. Mapeado del fondo

La reconstruccion del fondo marino es un tema que se lleva varios anos intentando resolver

para su uso en campos muy diversos y existen diversas formas de llevarlo a cabo.

Figura 2.3: Ejemplo de mapa de fondo marino. Representacion en distintos colores segun

niveles de profundidad.

Uno de los usos mas comunes es el de reconocimiento de objetos, para ello suele aplicarse un

algoritmo que detecta el suelo para quedarse con los objetos que no pertenecen al el, como es

el caso de (6). Otro ejemplo es el de (7), donde se presenta un programa que aplica algoritmos

estadısticos para la deteccion de objetos.

El proceso podrıa dividirse en 2 pasos bastante diferenciados:

Medicion y lectura del fondo: se toman mediciones del fondo durante un barrido de

la zona de interes. Estas mediciones se realizan coordinando distintos sensores, pero no

existe una combinacion de sensores idonea para realizar la tarea, sino que existen diversas

propuestas, como es el caso de (8) donde se plantea el uso combinado de sensores acusticos

con radares. Otro ejemplo es el de (9) donde se combina un multibeam con un sonar de

barrido lateral.

Procesado de los datos y reconstruccion de los mapas: una vez se tienen las me-

didas, es necesario darles un formato valido para segun que herramientas utilicemos a

continuacion. Ası, en este proyecto se utiliza libpointmatcher para la reconstruccion del

mapa, y esta herramienta acepta varios formatos, entre ellos el .vtk (Visualization tool

7

2.3 Mapeado del fondo

kit). Esta fase de procesado puede llegar a niveles de complejidad altos, dependiendo de

las necesidades del proyecto.

Una vez obtenido el mapa, se suelen aplicar distintos procesos con el fin de obtener informa-

cion mas especıfica, como pueden ser los mapas de inclinacion. Como nota a anadir, no debemos

olvidar que en el mundo real los resultados siempre se veran afectados por pequenos defectos de

los sensores o impurezas del entorno que producen ruidos en las mediciones. Esto tambien re-

quiere de un proceso de filtrado para poder trabajar con los datos mas limpios posibles. Tambien

los sensores impondran lımites al alcance de los experimentos debido a sus propias limitaciones

fısicas.

8

3

MATERIAL

Durante la realizacion de este proyecto se ha hecho uso de diferentes herramientas, algunas

de estas son extensamente conocidas en el mundo de la robotica por lo que simplemente se hace

una breve introduccion. Es importante destacar que todas las herramientas utilizadas son de

codigo libre, permitiendo ası que cualquier persona pueda acceder a ellas.

3.1. ROS

Robot Operating System (10), es un framework de codigo libre creado especıficamente para

dar soporte al desarrollo de proyectos roboticos. Contiene una gran variedad de librerıas y

herramientas que permite desarrollar software de todo tipo de nivel de complejidad.

El objetivo principal de sistema operativo es el de facilitar la comunicacion entre robots,

dando un gran impulso a todos los proyectos en los que se requiere una interaccion entre robots.

No se trata de un paquete fijo que ocupe un determinado espacio, sino que gracias a su

gran flexibilidad, solo ocupara el espacio mınimo necesario, es decir, solo se instalaran aquellas

herramientas o librerıas que sean necesarias. Algunos de las librerias o paquetes utilizados han

sido tf, rosbag, lasser assembler, pcl ros, rviz.

ROS se mantiene gracias a una gran comunidad de desarrolladores que dıa a dıa trabajan

para hacer de ROS un sistema cada vez mas estable y con mayor cantidad de librerıas.

3.2. UWSim

UWSim (UnderWater SIMulator) (11) es el software base del proyecto de codigo libre. Tras

hacer una busqueda de simuladores que nos permitieran trabajar con robots submarinos, nos

9

3.2 UWSim

encontramos con UWSim.

UWSim nacio bajo la necesidad de probar y simular diferentes algoritmos de control y per-

cepcion antes de su implementacion en el mundo real, desarrollado por la universidad Jaume

I.

Este simulador nos ofrece utilidades de gran importancia a la hora de simular nuestros

proyectos:

Entorno configurable: podemos crear escenarios propios de tal forma que se asemeje lo

maximo posible a nuestro entorno real. Cargar modelos 3D propios siempre que se carguen

en un formato valido para OSG (OpenSceneGraph). Nos permite ademas, modificar estados

fısicos como la superficie del oceano, oleaje, transparencia del agua, partıculas, etc.., de

manera dinamica.

Soporta diferentes robots: incluye ciertas caracterısticas independientes del robot en uso,

de forma que podamos anadirlas a nuevos modelos de robots. Ademas, UWSim nos permite

trabajar con mas de un robot a la vez.

Diferentes sensores: incluye un total de 12 sensores distintos (camara, GPS, Imu, DVL,

Multibeam, sensor de fuerza... entre otros).

UWSim esta integrado dentro de ROS. Gracias a ello, podemos establecer un mapa que nos

permita crear una red de comunicacion tanto interna para la ejecucion del propio proyecto como

externa, para poder comunicarnos con el simulador. COLA2 se apoya en el paquete auv msgs

de ROS.

La definicion de nuestro escenario se puede hacer de una manera sencilla por medio de un

fichero .xml, donde definiremos, aparte de nuestro modelo 3D, los sensores a utilizar y la interfaz

que se necesite de ROS para poder comunicarnos con el simulador.

Haciendo una profundizacion en los distintos tipos de interfaz que UWSim ofrece, nos en-

contramos con distintos elementos:

ROSOdomToPAT: lee mensajes de odometrıa de ROS y mueve el vehıculo segun corres-

ponda.

PATToROSOdom: publica mensajes de odometrıa a partir de los datos de posicion y

velocidad del vehıculo.

WorldToROSTF: publica la posicion y velocidad de cada objeto presente en el escenario.

10

3.2 UWSim

ArmToROSTF: interfaz de brazo robotico que publica los estados de las uniones.

ROSJointStateToArm: lee los mensajes de ROS de los estados de las uniones y mueve

el brazo segun corresponda.

VirtualCameraToROSImage: crea un emisor ROS de imagenes de la camara que se

especifique.

ROSImageToHUD: se subscribe a un emisor de imagenes y genera la camara dentro de

UWSim.

ROSTwistToPAT: lee mensajes de ROS de tipo Twist para establecer la velocidad del

vehıculo.

RangeSensorToROSRange: emite las distancias leıdas por el sensor virtual.

ROSPoseToPAT: lee mensajes de posicion de ROS y mueve el vehıculo segun correspon-

da.

ImuToROSImu: publica lecturas de la IMU.

PressureSensorToROS: emisor para los sensores de presion.

GPSSensorToROS: lee la informacion de los sensores GPS y los publica.

DVLSensorToROS: crea un emisor para los dispositivos DVL.

RangeImageSensorToROSImage: utiliza el emisor de imagenes de ROS para publicar

imagenes de profundidad.

multibeamSensorToLaserScan: transforma las lecturas del sensor multi-haz en men-

sajes tipo LaserScan y los publica.

contactSensorToROS: publica el estado de colision.

ForceSensorToROS: publica la informacion del sensor de fuerza.

ROSPointCloudLoader: lee mensajes de nubes de puntos de ROS y los representa en

3D.

Estos elementos son de gran importancia pues son los que permiten la comunicacion con

otros programas a traves de ROS.

11

3.3 COLA2

3.3. COLA2

Component Oriented Layer-based Architecture for Autonomy (COLA2) (12) es una

arquitectura de control para vehıculos autonomos submarinos. Desarrollada por la Universidad

de Girona, esta arquitectura se estructura en tres campos: de reaccion, de ejecucion y de mision.

COLA2 se puede usar en conjunto con UWSim y RVIz, permitiendonos ver una represen-

tacion en directo de toda la mision durante su ejecucion. El paquete incluye los modelos de los

robots Sparus II y Girona 500:

Sparus II (13):

Figura 3.1: Sparus II 3D model

Creado por el Centro de Investigacion de Robotica Submarina (CIRS) de la Universidad de

Girona. Se trata de un ligero Vehıculo Autonomo Submarino (AUV por sus siglas en ingles)

de tipo torpedo propulsado por helices y con una gran autonomıa gracias a su eficiencia

hidrodinamica. Esta disenado para misiones de poca profundidad (200 m) y ademas puede

ser modificado y personalizado por cada usuario ya que usa una arquitectura de libre uso

basada en ROS. Gracias a esta flexibilidad de adaptacion segun que misiones, el Sparus II

se utiliza hoy en dıa para aplicaciones industriales, cientıficas y academicas. Mas adelante

se entrara en detalle del Sparus II.

Girona 500 (14):

Creado tambien por el CIRS, se trata de un robot con una capacidad de movimiento

mayor que el Sparus II, ya que posee 4 helices (2 verticales y 2 horizontales), ademas de

que permite alcanzar cotas mayores de profundidad (hasta 500 m). Su estructura fısica

(3 cascos alargados, 2 arriba y uno abajo), hace que exista una separacion considerable

entre su centro de gravedad y el de flotabilidad, por lo que no se le considera un tıpico

12

3.3 COLA2

Figura 3.2: Girona 500 3D model

13

3.4 Sparus II

robot de tipo torpedo. Es un robot ideal para misiones en las que se requiera tener una

retransmision por imagen debido a su gran capacidad movil.

Tras un estudio de ambos modelos y de los servicios ROS que COLA2 nos ofrece para cada uno

de ellos y de las necesidades de nuestro objetivo, decidimos decantarnos por el robot Sparus II

por su mayor sencillez.

Dejando a un lado el contenido teorico de COLA2 y su modelo de control, pues no es esa la

razon de su uso, COLA2 ofrece una extensa lista de complementos y herramientas para extender

la utilidad de UWSim.

3.4. Sparus II

Sparus (version original) fue disenado en 2010 por el Centro de Investigacion de Robotica

Submarina (CIRS) de la Universidad de Girona. El objetivo de su diseno fue la participacion en

el European Student AUV Competition, organizado por el CMRE (Centre for Maritime Research

and Experimentation), en Italia. El Sparus fue el ganador de la competicion y desde entonces

no ha dejado de usarse. En 2013 se finalizo una nueva version del robot, el Sparus II.

Figura 3.3: Sparus II

Como se ha mencionado con anterioridad, se trata de un robot ligero con gran eficiencia

hidrodinamica lo que le permite tener una gran autonomıa en aguas poco profundas de hasta

200 metros. Su superficie es tipo torpedo y tiene la capacidad de flotar sobre el agua. El robot

proporciona un area de carga customizable ası como una arquitectura de software libre basada

14

3.4 Sparus II

en ROS. Esto hace que el Sparus II sea altamente personalizable por los usuarios finales para

segun que misiones se vayan a implementar. Debido a todas estas caracterısticas, el Sparus II

es un robot de facil uso y adaptabilidad que se utiliza hoy en dıa en aplicaciones industriales,

cientıficas y academicas.

Por resumir sus puntos fuertes:

Superficie tipo torpedo: eficiencia hidrodinamica y larga autonomıa

Flotabilidad

Ligero

Facil de operar: con 2 operarios desde un bote

Carga para misiones especıficas: hardware abierto para la integracion de equipos

Arquitectura software basada en ROS

Bajo coste

Con el motivo de no extender este documento mas de lo necesario, solo se expondra los nodos

que ofrece el software que implementa el robot. Sobre los mensajes y servicios, no se entrara en

detalle salvo aquellos que se hayan usado para este proyecto.

3.4.1. Arquitectura del software

Sparus II implementa COLA2 (Component Oriented Layered-based Architecture for Auto-

nomy) como arquitectura de control. A continuacion se explica los nodos mas importantes que

esta arquitectura ofrece:

/captain: es el encargado de cargar y ejecutar las misiones. Gracias a los servicios im-

plementados, el usuario puede comunicarse con el y mandarle instrucciones. Este nodo se

comunica principalmente con el nodo /pilot.

/dynamics: a traves de datos recogidos de los actuadores, se consigue simular el compor-

tamiento real del robot y su interaccion con el entorno. El usuario puede parametrizar el

entorno de modo que se pueda obtener diferentes simulaciones.

/ekf slam: implementa un EKF (Extended Kalman Filter) para calcular la posicion y

velocidad del AUV.

15

3.4 Sparus II

/keyboard: nodo que permite el control en tiempo real del robot a por medio del terminal

de Linux.

/map act: usado para juntar todos los dispositivos de entrada como teclado o joysticks.

/merge body force req: se usa para mensajes de distintos topics procedentes del sensor

de fuerza teniendo en cuenta las prioridades de estos.

/merge body velocity req: se usa para mensajes de velocidad de distintos topics te-

niendo en cuenta las prioridades de estos.

/merge world waypoint req: se usa para mensajes relacionados con los waypoints de

distintos topics teniendo en cuenta las prioridades de estos.

/navigator s2: se subscribe a los drivers de los sensores, interactua con el nodo /ekf slam

y publica datos de navegacion (posicion, velocidades, etc.).

/pilot: este nodo es dirigido por /captain publica posicion y velocidad de ajuste a sus

respectivos controladores.

/pose controller s2: controlador de posicion del Sparus II AUV.

/safe depth altitude: vigila la profundidad y altitud, se utiliza principalmente para evi-

tar colisiones.

/safety s2: se utiliza para revisar tiempos de espera absolutos.

/set zero pose: en caso de perdida de teleoperacion durante mas de 5 segundos, este

nodo envıa el AUV a la superficie.

/set zero velocity: si el robot se encuentra lo suficientemente profundo y las ordenes

que recibe por teleoperacion no son alcanzables, entonces el nodo manda al robot que

mantenga una velocidad cero.

/sim actuators s2: nodo que simula los actuadores del Sparus II, solo se usa durante

simulaciones.

/sim nav sensors s2: nodo que simula los sensores de navegacion del Sparus II, solo se

usa en simulacion.

16

3.5 LibPointMatcher

/teleoperation: este nodo recibe los mensajes que envıa /map act, calcula las ordenes de

velocidad y posicion que salen de los dispositivos de entrada.

/thruster allocator: nodo que traduce los comandos de fuerza para las helices.

/velocity controller s2: controlador de velocidad del Sparus II.

3.5. LibPointMatcher

Libpointmatcher (15) es un programa de codigo libre disenado para la alineacion de nubes

de puntos mediante la aplicacion del algoritmo Iterative Closest Point (ICP).

ICP (16): Se trata de un algoritmo empleado para la reconstruccion de imagenes 2D

y 3D a partir de dos o mas imagenes o nubes de puntos distintas que se solapan. El

algoritmo comprueba iterativamente diferentes transformaciones (rotacion y traslacion)

que se aplican a una de las imagenes con el fin de minimizar el error (distancia entre

ambas imagenes). La metodologıa del algoritmo es la siguiente:

• Para cada punto de la primera nube de puntos encuentra el punto mas cercano en la

segunda nube de puntos.

• Estimacion de una matriz de transformacion con el fin de alinear de la mejor manera

las dos nubes de puntos. Esta estimacion se realiza usando la tecnica de la raız

cuadrada del error cuadratico medio (17)

• Aplicacion de la transformacion a la nube de puntos.

• Volver a iterar.

Evidentemente, cuando se trata de nubes de puntos considerablemente grandes, el tiempo

de ejecucion del algoritmo se eleva considerablemente. Libpointmatcher ofrece la posibilidad de

realizar un filtrado a las nubes de puntos antes de implementar el algoritmo. Estos filtros aportan

varias ventajas :

Eliminacion de posibles ruidos que dificulten la alineacion de las nubes de puntos

Eliminacion de puntos repetidos

Adicion de informacion a los puntos, como puede ser el vector normal a la superficie o la

direccion del punto al sensor

17

3.5 LibPointMatcher

Ası podemos encontrar diferentes filtros dependiendo de si el objetivo de este es el de sim-

plificar la nube de puntos o anadir informacion util. Por mencionar algunos ejemplos de cada

tipo de filtro:

Simplificacion de nubes de puntos:

• Filtro de Densidad Maxima

• Filtro de Distancia Maxima

• Filtro de Distancia Mınima

• Filtro de Muestra Aleatoria

• Filtro de Sombras

Aporte de informacion:

• Filtro de Direccion de Observacion

• Filtro de Superficie Normal

• Filtro de Orientacion de las Normales

• Filtro de Ruido del Sensor

Libpointmatcher, nos permite ademas aplicar mas de un filtro a una misma nube de puntos,

lo que nos permite crear una cadena de filtros para conseguir una nube de puntos optima para

aplicar el ICP.

Pero este software no sirve solo para aplicar el ICP, sino que ademas ofrece distintos bloques

o elementos que se pueden implementar en la configuracion del programa:

Filtros: previamente se ha hablado sobre los filtros que libpointmatcher ofrece.

Alineador de puntos: se implementa el KDTree (18).

Filtros de puntos exteriores: para realizar un filtrado tras la alineacion, de esta forma se

pueden eliminar puntos que queden considerablemente desmarcados de la nube de puntos

obtenida.

Comprobantes de la Transformacion: bloque que sirve para limitar la matriz de trans-

formacion. Se pueden imponer lımites tanto inferiores como superiores (maximo angulo de

rotacion, o mınima traslacion) ası como lımites para la iteracion del propio algoritmo.

18

3.5 LibPointMatcher

Figura 3.4: Bloques de configuracion del ICP. Cadena de bloques que permite la configuracion

del ICP segun las necesidades del proyecto.

19

3.5 LibPointMatcher

Libpointmatcher ofrece una documentacion bastante completa que incluye una serie de tu-

toriales que permite una mejor comprension de este software y de su potencial.

20

4

METODOLOGIA Y DESARROLLO

Durante la realizacion del proyecto se ha pasado por varias fases cumpliendo los distintos

objetivos que se planteaban, tras la finalizacion, se pueden diferenciar distintas etapas por las

que se ha pasado.

4.1. Estudio y manejo de simulador de vehıculos en entornos

submarinos

Se realiza la busqueda de un software especıfico para la simulacion de entornos acuaticos y

nos encontramos rapidamente con UWSim, tras un breve estudio de sus capacidades y recursos

resulta el software elegido. Se trata de un software hasta ahora desconocido por el grupo de in-

vestigacion, esto supone un estudio desde cero del software que no ha cesado hasta practicamente

la finalizacion del proyecto.

El paquete de UWSim viene por defecto con suficientes recursos que permiten (siguiendo

tutoriales que ofrece su portal web) familiarizarse con el programa. Su comando basico de eje-

cucion ya nos ejecuta un entorno que incluye un escenario y un vehıculo con su correspondiente

interfaz ROS.

En los tutoriales se indica claramente como se pueden crear escenarios propios, insertando

en el todo objeto que se desee. Los escenarios se definen en archivos con formato .xml. Estas

configuraciones estan compuestas por diferentes bloques como puede ser el vehıculo, sensores,

objetos del entorno, interfaz ROS, etc., cuyo orden de aparicion en el archivo de configuracion

debe respetar las prioridades que se indican en la documentacion de la aplicacion.

21

4.1 Estudio y manejo de simulador de vehıculos en entornos submarinos

Figura 4.1: Escena por defecto de UWSim. Escena inicial que ofrece UWSim, en ella se pue-

de observar un escenario que simula un laboratorio, una piscina para realizar pruebas y el robot

Girona500.

Inicialmente realizamos ciertas modificaciones al escenario con el fin de familiarizarnos con

la herramienta, aunque estos escenarios modificados no seran utilizados en el futuro.

22

4.2 Comunicacion entre ROS y UWSim

4.2. Comunicacion entre ROS y UWSim

Nada mas ejecutar el entorno que UWSim ofrece por defecto, nos encontramos con una

multitud de servicios y topics definidos y preparados para usar.Sus nombres nos dan una ligera

idea de su funcionalidad, aunque en muchos casos se echa de menos una documentacion extensa

que explique bien cada uno de ellos. No hay otra forma que la de ensayo-error para probar y

entender las utilidades de los servicios y los datos que manejan los topics.

UWSim esta pensado de tal forma que su comunicacion con ROS sea especialmente sencilla.

Dentro del archivo de configuracion del escenario a simular, se incluye un bloque para definir

la interfaz de comunicacion con ROS, ofreciendonos 22 interfaces distintas hasta la fecha. En el

capıtulo de materiales 3.2 se detalla la funcionalidad de algunas.

Ası, por ejemplo, en nuestro trabajo se utilizara un sensor multibeam, por lo que basta con

anadir la interfaz multibeamSensorToLaserScan para disponer de un canal donde se publiquen

las medidas realizadas por el sensor correspondiente.

4.3. Estudio y valoracion de sensores ofrecidos por el simulador

Una vez tenemos ROS y UWSim trabajando conjuntamente, es la hora de estudiar que tipos

de sensores ofrece el simulador y cual de ellos es el que mejor se adapta a nuestro objetivo,

reconocer el fondo marino.

UWSim ofrece 12 sensores diferentes:

Camera: proporciona imagenes virtuales.

Range Camera: proporciona imagenes de profundidad.

Range sensor: devuelve la distancia al objeto mas cercano en la direccion que se le

configure.

Object picker: simula el agarre de un objeto que se encuentre mas cerca de una distancia

predefinida.

Pressure: sensore de presion.

DVL: sensor que devuelve la estimacion de velocidad lineal del vehıculo.

Imu: estima la orientacion del vehıculo respecto a la referencia espacial global.

23

4.3 Estudio y valoracion de sensores ofrecidos por el simulador

GPS: proporciona la posicion global del vehıculo respecto del sistema de referencia global,

pero al tratarse de medios acuaticos, solo funciona decentemente cuando el vehıculo se

encuentra en cerca de la superficie.

Multibeam: simula un conjunto de sensores de distancia cuya orientacion se configura

previamente.

Force: estima la fuerza y momento aplicados a una parte del vehıculo.

Structured light projector: proyecta una luz continua en el escenario.

Dredge: remueve el barro de objetos enterrados.

Entre estos sensores, se encuentra el Range Sensor. Surge la idea entonces de usar varios

y colocarlos en nuestro robot, definiendo las direcciones a las que queremos que apunte cada

uno pero UWSim ya tiene esto implementado en cierta manera, nos ofrece un Multibeam, que

no es mas que una coleccion de sensores de alcance colocados en un mismo punto apuntando

a distintos angulos contenidos en un mismo plano, tanto el angulo incremental como el angulo

lımite se puede configurar facilmente.

Figura 4.2: Sensor multibeam. Esquema simplificado del haz de sensores de distancia.

24

4.4 Adaptacion de multibeam sensor al Robot

Por ello, decidimos usar este sensor y colocarlo en la panza del robot para realizar un barrido

transversal a la direccion de navegacion del robot.

4.4. Adaptacion de multibeam sensor al Robot

La colocacion del sensor en la panza del robot se define cuando definimos el escenario a

simular en UWSim. Para ello debemos no solo posicionar el sensor en la posicion deseada, sino

tambien publicar la posicion relativa entre ambos para ası poder leer los datos recogidos por el

sensor respecto del sistema de referencia del robot. Para ello utilizamos el paquete tf2 de ROS.

Figura 4.3: Haz de sensores de distancia. Se puede apreciar en la figura el barrido que se hace

con el multibeam.

El paquete tf2 es una librerıa que permite publicar la relacion existente entre dos sistemas

de referencia, esto es, su matriz de transformacion. Sin utilizar esta herramienta, el sensor queda

acoplado perfectamente al vehıculo, pero cuando leemos las medidas que realiza, no sabemos

25

4.5 Valoracion de la herramienta COLA2

interpretarlo correctamente, ya que previamente necesitan que se les realice una transformacion

al sistema de referencia global y ası poder interpretar los datos correctamente.

Figura 4.4: Sensor multibeam. Representacion en Rviz de las lecturas recogidas por el multibeam.

4.5. Valoracion de la herramienta COLA2

Se nos presenta ahora el problema de navegacion, conseguir que el robot recorra un camino

predefinido. Tras investigar y consultar a colaboradores del departamento, nos recomiendan usar

la herramienta COLA2 (12). Se trata de una herramienta de control de vehıculos autonomos que

ofrece una muy completa interfaz para usar con ROS. Ademas incluye los modelos cinematicos

y dinamicos de 2 robots extensamente utilizados en la investigacion de robotica submarina

(Sparus II y Girona 500). Finalmente utilizaremos COLA2 para lanzar el simulador con nuestros

propios escenarios y para controlar el robot durante la mision. Haciendo uso de uno de los muchos

servicios que este software nos ofrece, conseguimos que el robot recorra el camino de la mision

y ası poder realizar un barrido del fondo marino a medida que el robot avanza.

4.6. Comparacion de los dos modelos de robots que ofrece CO-

LA2

Como se ha mencionado, COLA2 nos ofrece los modelos de 2 robots. Tras una valoracion de

las necesidades de nuestro proyecto y de las capacidades de cada uno, decidimos trabajar con el

26

4.7 Creacion de un path para el robot

robot Sparus II.

Los puntos a favor tenidos en cuenta para la eleccion del Sparus II frente al Girona 500 son:

Control mas sencillo.

Tipo torpedo.

Mas utilizado.

Menor resistencia hidrodinamica.

4.7. Creacion de un path para el robot

Necesitamos ahora crear un programa que envıe al robot diferentes posiciones que debe

alcanzar de manera que al final el robot haya recorrido una trayectoria deseada con el fin de

realizar un barrido de toda la superficie de interes.

Encontramos dos maneras de enviar una posicion al robot, una de ellas es de bajo nivel

usando ciertos canales de comunicacion donde se envıan los mensajes necesarios. La segunda es

mucho mas sencilla, pues se trata de un servicio que ofrece COLA2 con nombre /enable goto.

Este servicio utiliza de manera automatica los canales que se deberıan utilizar con el otro metodo.

Decidimos hacer uso del servicio por su sencillez. Para ello debemos pasarle los siguientes

parametros:

position: posicion deseada.

yaw: angulo del rotacion del eje Z.

altitude: altitud;

altitude mode: si es true”se mantiene la posicion Z relativa a la altitud, en caso contrario

se considera profundidad.

blocking: si es true”se bloqueara la aplicacion hasta que el vehıculo halla alcanzado la

posicion objetivo.

keep position: si es true”se establece el tiempo lımite de alcanzar la posicion a un valor

suficientemente grande como para que el servicio goto”solo finalice cuando el vehıculo halla

alcanzado la posicion.

27

4.7 Creacion de un path para el robot

priority: nivel de prioridad.

reference: sistema de referencia en el que se debe interpretar la posicion objetivo.

disable axis: posibilidad de bloquear el movimiento en el sentido de algun eje. En nuestro

caso lo bloqueamos en el sentido del eje Z ya que realizamos un barrido superficial.

position tolerance: tolerancia de alcanzar la posicion objetivo.

orientation tolerance: tolerancia de alcanzar la orientacion objetivo.

linear velocity: velocidad lineal a la que debe ejecutarse el desplazamiento.

angular velocity: velocidad angular a la que debe ejecutarse la rotacion.

Como se puede apreciar, existe una gran multitud de parametros con los que se pueden

conseguir configuraciones muy dispares. La configuracion que le pasemos afectara a la calidad

de los resultados. Por poner un ejemplo, cuanto mas rapido se ejecute el barrido, menos lecturas

del fondo se realizara por metro recorrido.

Desarrollamos entonces un algoritmo que enviara las posiciones objetivo consecutivamente

con el fin de que el robot recorra la trayectoria deseada. El algoritmo no enviara una nueva

posicion objetivo mientras que el vehıculo no halla alcanzado la posicion objetivo anterior.

La trayectoria se define a mano, es decir, nosotros definimos cada punto a alcanzar y los en-

viamos en orden segun que trayectoria queremos que se recorra. Serıa muy interesante desarrollar

otro algoritmo que genere la sucesion de puntos de forma automatica simplemente indicandole

el area de interes.

Como se aprecia en la figura 4.5, el algoritmo que implementa COLA2 para alcanzar la

posicion objetivo primero implementa una rotacion pura hasta orientarse correctamente con la

posicion objetivo para despues avanzar hacia ella. La secuencia de avance consta un periodo de

aceleracion, de avance a velocidad constante y una ultima fase de desaceleracion hasta alcanzar

la posicion objetivo.

En la imagen h) de la figura 4.5 el vehıculo ya ha alcanzado la posicion objetivo y automati-

camente se le ha enviado la siguiente posicion objetivo. De esta manera conseguimos que el

vehıculo recorra las trayectorias que deseemos.

28

4.7 Creacion de un path para el robot

(a) Rotacion 1 (b) Rotacion 2

(c) Rotacion 3 (d) Rotacion 4

(e) Aceleracion (f) Avance

(g) desaceleracion (h) Alcance

Figura 4.5: Secuencia de alcance de posicion objetivo.

29

4.8 Lectura de mediciones obtenidas por el multibeam sensor

4.8. Lectura de mediciones obtenidas por el multibeam sensor

Como se ha mencionado con anterioridad, UWSim ofrece distintas interfaces para comuni-

carse con ROS, una de ellas es multibeamSensorToLaserScan, para configurarla debemos

indicarle el nombre del nodo que debe crear, el nombre del canal por el que enviara los datos y

la frecuencia a la que queremos que se envıen los datos. Esta interfaz nos publica directamente

en el canal que hemos configurado las medidas recogidas por el sensor en forma de mensajes de

tipo LaserScan, que es un tipo de datos de ROS. Gracias a ello, podemos trabajar de manera

comoda con los datos obtenidos. En la figura 4.4 se puede ver claramente la sucesion de medidas

que el sensor esta devolviendo, para ello solamente hemos tenido que indicarle a Rviz que debe

representar datos de tipo multibeam que son enviados al canal configurado. Automaticamente

se representan los datos en el sistema global definido en Rviz (figura 4.6).

30

4.8 Lectura de mediciones obtenidas por el multibeam sensor

(a) (b)

(c) (d)

(e)

Figura 4.6: Secuencia temporal de lectura de medidas del multibeam.

31

4.9 Transformacion de los datos a Pointclouds

4.9. Transformacion de los datos a Pointclouds

Para poder trabajar con las medidas y visualizarlas en 3D, es necesario hacer una trans-

formacion de los mensajes de tipo LaserScan a Pointcloud2. Realizamos una investigacion para

encontrar alguna librerıa de ROS que realice este formateado y encontramos varias:

pointcloud to laserscan

laser geometry

laser assembler

La primera de ellas realiza justo el formateado en sentido inverso, aunque no nos sirve ahora,

guardamos alguna referencia por si en un futuro fuera necesario invertir la transformacion.

Examinamos las dos siguientes y nos encontramos con que la tercera opcion ofrece un servicio

que hace exactamente lo que buscamos: AssembleScans2.

Para ejecutar el servicio debemos pasarle 2 parametros que hacen referencia a distintos

tiempos de ejecucion, el primero es desde cuando queremos recoger las lecturas del multibeam

mientras que el segundo es hasta cuando queremos recogerlas. De esta manera definimos un

intervalo de tiempo. El servicio cogera todas las medidas publicadas por el multibeam y las

transformara devolviendo una nube de puntos con todos los datos. Esta nube de puntos es a su

vez publicada en un canal ya definido por la librerıa laser assembler.

Una vez que tenemos la librerıa necesaria y que sabemos como funciona, creamos una aplica-

cion que sera la encargada unicamente de generar las nubes de puntos en intervalos de tiempo.

Esta aplicacion ha tenido 2 planteamientos distintos:

Generacion de nube de puntos entre 2 posiciones objetivo consecutivas: inicialmente crea-

mos este metodo de generacion de nubes de puntos. Generamos ası nubes de puntos con las

medidas recogidas desde que se llego a la posicion objetivo anterior hasta el momento en

el que se ha alcanzado una nueva posicion objetivo. Mas tarde, cuando queramos utilizar

el libpointmatcher para generar el mapa final, nos daremos cuenta de que estas nubes de

puntos no nos sirven, pues no se solapan. Como se explico en 2.3 cuando se explico lib-

pointmatcher, esta aplicacion solo sirve cuando dos nubes de puntos se solapan, ya que el

algoritmo que implementa busca corregir que las distancias entre las nubes de puntos sean

lo mas pequenas posibles.

32

4.9 Transformacion de los datos a Pointclouds

Cuando intentamos generar el mapa con nubes de puntos que no se solapan, el algoritmo

las juntara, dando lugar a un mapa completamente irreal donde varias secciones del mapa

se superponen en una sola (figura 4.7).

Figura 4.7: Solapado erroneo. El algoritmo de libpointmatcher superpone las dos nubes de puntos

para reducir al mınimo la distancia entre ambas.

Generacion de nube de puntos solapadas: se crean nubes de puntos de tal manera que se

solapen ciertas medidas entre una nube de puntos y otra. De esta manera conseguimos

que el libpointmatcher trabaje mejor ya que en fondos suficientemente abruptos conse-

guira aplicar una transformacion a la segunda nube de puntos de tal manera que encaje y

minimice las distancias con la primera.

Haciendo uso del programa paraview (19), podemos ver las nubes de puntos generadas. En

el congunto de figuras 4.8 se pueden observar 2 nubes de puntos y la superposicion entre ambas.

33

4.9 Transformacion de los datos a Pointclouds

(a) Nube de puntos 1 (b) Nube de puntos 2

(c) Union de nubes de puntos (d) Diferenciacion de ambas nubes de puntos

Figura 4.8: Ejemplo de union de nubes de puntos.

34

4.10 Estudio de libpointmatcher para reconstruccion 3D

4.10. Estudio de libpointmatcher para reconstruccion 3D

Acercandonos al objetivo del proyecto, el siguiente paso es la reconstruccion del mapa 3D

juntando los Pointclouds en uno solo de tal forma que represente el escenario completo. Co-

menzamos ası el estudio del programa libpointmatcher (15). Este software implementa un

algoritmo para alinear dos Pointclouds que se superponen, de esta manera conseguimos corregir

posibles errores y generar un mapa que se ajuste mejor a la realidad.

El algoritmo que implementa es el ICP (Iteratice Closest Point). Reliza una medicion inicial

de las distancias de cada punto de una primera imagen o nube de puntos, con el punto mas

cercano de la segunda imagen. Una vez realizado las medidas, estima una matriz de transforma-

cion que aporte un movimiento de traslacion y otro de rotacion, aplica esta matriz a todos los

puntos de la nube de puntos a anadir y vuelve a medir distancias con sus nuevos puntos vecinos

mas cercanos. Este proceso se repite iterativamente hasta que se ha alcanzado unas distancias

mınimas entre ambas imagenes.

Libpointmatcher aporta otras funcionalidades aparte del algoritmo. Ası nos encontramos

con distintas herramientas utiles a la hora de ejecutar el mezclado de imagenes. Una de estas

herramientas es la de poder aplicar una cadena de filtros a las imagenes con el fin de eliminar

posibles ruidos durante la captura de estas, o si por ejemplo la velocidad del robot ha sido lenta

durante la ejecucion de la mision y su frecuencia de toma de medidas es elevada, conlleva a

una densidad de puntos excesivamente alta, lo que ralentiza considerablemente la ejecucion del

algoritmo. Algunos de los filtros que podrıamos usar para agilizar el proceso son el filtro de

densidad maxima (reduce la densidad de la nube de puntos) o el filtro de muestra aleatoria

(elimina puntos aleatoriamente segun un parametro que determina la probabilidad de que un

punto sea suprimido).

Se puede entender entonces que es mas que recomendable hacer un estudio de cierta profun-

didad de los filtros que ofrece libpointmatcher antes utilizarlo en nuestro proyecto. Supondrıa

ademas un ahorro de tiempo y esfuerzo considerable.

Otra funcionalidad que ofrece libpointmatcher y, como veremos mas adelante, ha sido clave

para la finalizacion del proyecto, es el TransformationChecker. Cuando el ICP estima una

transformacion, entra en accion este elemento que se encarga de comprobar si los resultados

del algoritmo cumple con los lımites que nosotros mismos hemos establecido. Este elemento

permite tres tipos de configuraciones que se pueden usar conjuntamente, permitiendo ası una

35

4.10 Estudio de libpointmatcher para reconstruccion 3D

gran variedad de opciones para regular tanto el tiempo de ejecucion como de la calidad del mapa

obtenido:

Lımite de numero de iteraciones: acota superiormente el numero de iteraciones que el

algoritmo pueda emplear para alcanzar su objetivo.

Limites de error: establece un valor mınimo de diferencia entre varias transformaciones

estimadas por debajo del cual consideramos que el resultado del algoritmo es aceptable.

De esta manera, si la diferencia de rotacion o traslacion aplicadas durante una serie de

transformaciones consecutivas se encuentra por debajo del mınimo, se terminara el proceso.

Se puede establecer el numero de transformaciones consecutivas tenidas en cuenta a la hora

de calcular las diferencias.

Acotacion superior de rotacion y traslacion: limitamos los movimientos estimados de tras-

lacion y de rotacion. Si el algoritmo estima unas transformaciones superiores, entonces el

proceso finaliza.

Para poder hacer uso del libpointmatcher, es necesario convertir los Pointclouds a un formato

valido para el programa, por ello se utiliza una herramienta desarrollada por el departamento

para un proyecto anterior. Esta aplicacion transforma los Pointclouds en formato .vtk, ademas,

libpointmatcher tambien acepta archivos de tipo .csv o .pcd entre otros.

Como se ha mencionado, el algoritmo que implementa libpointmatcher sirve para corregir

errores entre Pointclouds que se superponen. Nos encontramos entonces con un problema cuan-

do generamos Pointclouds que no se superponen lo suficiente, o cuando la superficie es muy

homogenea. Para explicar esta situacion, suponemos un entorno en el que solo exiten unos pocos

objetos y ejecutamos la mision para obtener los Pointclouds.

Como se puede ver en la figura, tenemos 3 nubes de puntos distintas a las que aplicaremos

el ICP. Cuando hacemos uso de libpointmatcher, el algoritmo va a buscar la transformacion

que consiga menos error entre los puntos de ambos Pointclouds. Evidentemente, el resultado

optimo es juntar los pointclouds, dando lugar a una representacion de la superficie irreal como

se muestra en la figura 4.10.

Darnos cuenta de esta situacion nos ocasiono varios dıas de retraso en los que se probo con

todo tipo de configuraciones del proceso de union de las imagenes. Hasta que finalmente entendi-

mos que libpointmatcher simplemente se encarga de superponer imagenes lo mas acertadamente

posible, nada mas.

36

4.10 Estudio de libpointmatcher para reconstruccion 3D

Figura 4.9: Ejemplo de escenario y nubes de puntos. Se presenta un esquema de un escenario

sencillo con 3 objetos y se senalizan tres nubes de puntos tomadas durante la ejecucion de la mision.

Figura 4.10: Resultados de aplicar el ICP sin lımites establecidos.

37

4.10 Estudio de libpointmatcher para reconstruccion 3D

Por ello se llevaron a cabo dos modificaciones importantes:

Conseguir una mayor superposicion de las nubes de puntos: hasta ahora generaba-

mos las nubes de puntos entre dos posiciones objetivo de la trayectoria, evidentemente,

esto supone que la superposicion de las imagenes sea practicamente nula salvo en los casos

en los que el robot realice alguna rotacion. Situacion ademas en las que se generan los

mayores errores en la medida. Por ello se decide modificar el metodo de obtencion de las

nubes de puntos, aislandolo completamente de la mision y generando una aplicacion exter-

na que genere las nubes de puntos cada cierto tiempo. Para conseguir una superposicion,

se desarrolla un algoritmo que tome referencias en el tiempo superpuestas.

Figura 4.11: Esquema de la toma de referencias temporales.

Como se aprecia en la figura 4.11, empleamos un temporizador que saltara cada cierto

tiempo. En este instante se toma la referencia del tiempo de manera alternativa y se

genera la nube de puntos de las medidas tomadas entre dos instantes.

De esta manera conseguimos un solapamiento que puede variar dependiendo de la velocidad

en que se ejecute la mision y del tiempo establecido en el temporizador.

Empleo de lımites para el ICP: como se ha explicado anteriormente, libpointmatcher

nos permite establecer ciertos lımites en el proceso de union de imagenes. Se decide por

ello imponer lımites superiores en la matriz de transformacion estimada por el ICP, tan-

to para la rotacion como para la traslacion y ademas, en los casos en que estos lımites

sean superados, simplemente se uniran las dos nubes de puntos sin transformacion alguna

intermedia.

38

4.11 Experimentos y Resultados

De esta manera, en el ejemplo presentado en la figura 4.9, conseguiremos que el ICP no

ejecute la correcion de las nubes de puntos y que simplemente las una generando una unica

imagen que represente el mapa de una manera mas real.

Figura 4.12: Resultados de aplicar el ICP acotando superiormente la rotacion y trasla-

cion.

4.11. Experimentos y Resultados

Llegados a este punto, el objetivo principal del proyecto ya se ha cumplido, pues hemos con-

seguido generar una representacion en 3D del fondo implementando todos los pasos intermedios.

Nos planteamos ahora hacer una pequena investigacion y valoracion de ciertos aspectos que

consideramos puedan afectar a la calidad de los mapas obtenidos. Evidentemente existe un gran

numero de factores que afectan a la calidad del resultado, desde el entorno acuatico simulado,

pasando por los no pocos parametros configurables de la mision que se ejecute y terminando por

el libpointmatcher.

Decidimos realizar una evaluacion del efecto que supone en el resultado el tipo de trayectoria

implementado y los diferentes objectos que se puedan encontrar en el fondo. Para ello se han

creado varios escenarios y trayectorias para los cuales se generaran los mapas. Este apartado se

explica mas detalladamente en el capıtulo 5.

39

5

EXPERIMENTOS Y

RESULTADOS

A la hora de valorar nuestro trabajo y su calidad, se nos plantean varias dudas importantes,

¿Influye el tipo de superficies detectadas en la calidad del mapa 3D creado?, ¿Que tipo de tra-

yectoria deberıamos realizar para obtener un mejor barrido del fondo?. Para intentar responder

estas dudas, se han creado distintos escenarios con diferentes tipos de superficies (esferas, pris-

mas, conos, etc...) y ademas, se han programado tres misiones diferentes para realizar distintas

trayectorias.

Es interesante destacar la importancia de la trayectoria elegida, pues como se ha explicado,

la superposicion de las nubes de puntos es un factor importante a la hora de aplicar el libpoint-

matcher. Ası, no son iguales las zonas del mapa por las que solo se han tomado datos una vez,

frente a las zonas por las que se ha pasado mas de una vez. Otro aspecto es que segun lo enre-

vesada que sea la trayectoria, la mision tardara mas o menos en realizarse, y como las nubes de

puntos son obtenidas cada cierto tiempo, obtendremos distinto numero de Pointclouds ası como

distinto grado de superposicion entre ellos.

5.1. Trayectorias

Las tres trayectorias llevadas a cabo son:

Rectangular 5.1: Se trata de la trayectoria por defecto que consta de 25 waypoints y 8

puntos de giro de 90 grados. El area de interes es recorrido de forma homogenea por lo

que obtendremos un mapa con una densidad de puntos bastante similar.

40

5.1 Trayectorias

Circular 5.2: Trayectoria de 17 waypoints con 8 puntos de giro de 90 grados. Esta trayec-

toria pasa de un bajo grado de superposicion para al final conseguir una superposicion de

Pointclouds bastante alta. Como se puede observar en la imagen, de la zona de inicio de

trayectoria solo tendremos de datos del primer barrido, mientras que del centro del mapa

dispondremos de varios pointclouds que abarquen la zona.

Triangular 5.3: Trayectoria de 19 waypoints con 8 puntos de giro de mas de 90 grados.

El objetivo de realizar esta trayectoria es la de estudiar casos en los que el robot tenga que

realizar rotaciones bruscas de casi 180o. Se consigue ademas un alto grado de superposicion

entre pointclouds.

Figura 5.1: Trayectoria Rectangular. Plano esquematico de una trayectoria de tipo rectangular.

41

5.1 Trayectorias

Figura 5.2: Trayectoria Circular. Plano esquematico de una trayectoria de tipo circular.

Figura 5.3: Trayectoria Triangular Plano esquematico de una trayectoria de tipo triangular.

42

5.2 Escenarios

5.2. Escenarios

Como se ha mencionado, se han creado escenarios que contengan distintos tipos de superficies

con el fin de evaluar si el tipo de objectos que se encuentran en el fondo influyen en la calidad

del mapa generado:

Escenario de conos 5.4.

Escenario de cilindros 5.5.

Escenario de prismas 5.6.

Escenario de esferas 5.7.

Escenario de varios tipos de figuras 5.8.

Figura 5.4: Escenario de conos.

43

5.2 Escenarios

Figura 5.5: Escenario de cilindros.

Figura 5.6: Escenario de prismas.

44

5.2 Escenarios

Figura 5.7: Escenario de esferas.

Figura 5.8: Escenario de varias figuras.

45

5.3 Maps

5.3. Maps

En esta seccion presentamos los resultados obtenidos para cada escenario y cada trayectoria.

Se debe tener en cuenta que para que esta valoracion sea consistente, todas las misiones se han

ejecutado con la misma configuracion, tanto del entorno acuatico como de los parametros del

vehıculo.

Las imagenes estan dispuestas de la siguiente manera: en la columna izquierda se muestra

la union de todas las nubes de puntos generadas durante la mision sin implementar algoritmo

alguno, mientras que en la columna de la derecha se muestran los mapas generados tras aplicarles

el ICP usando la herramienta libpointmatcher.

Con el fin de resaltar los objetos y evitar posibles confusiones con los puntos de la superficie,

a los mapas se les ha eliminado el suelo, de esta manera podemos centrarnos solo en los objetos

y en la calidad con la que se han representado.

(a) Antes (b) Despues

Figura 5.9: Conos trayectoria rectangular.

46

5.3 Maps

(a) Antes (b) Despues

Figura 5.10: Conos trayectoria circular.

(a) Antes (b) Despues

Figura 5.11: Conos trayectoria triangular.

47

5.3 Maps

(a) Antes (b) Despues

Figura 5.12: Prismas trayectoria rectangular.

(a) Antes (b) Despues

Figura 5.13: Prismas trayectoria circular.

48

5.3 Maps

(a) Antes (b) Despues

Figura 5.14: Prismas trayectoria triangular.

(a) Antes (b) Despues

Figura 5.15: Cilindros trayectoria rectangular.

49

5.3 Maps

(a) Antes (b) Despues

Figura 5.16: Cilindros trayectoria circular.

(a) Antes (b) Despues

Figura 5.17: Cilindros trayectoria triangular.

50

5.3 Maps

(a) Antes (b) Despues

Figura 5.18: Esferas trayectoria rectangular.

(a) Antes (b) Despues

Figura 5.19: Esferas trayectoria circular.

51

5.3 Maps

(a) Antes (b) Despues

Figura 5.20: Esferas trayectoria triangular.

(a) Antes (b) Despues

Figura 5.21: Varias figuras trayectoria rectangular.

52

5.3 Maps

(a) Antes (b) Despues

Figura 5.22: Varias figuras trayectoria circular.

(a) Antes (b) Despues

Figura 5.23: Varias figuras trayectoria triangular.

53

5.4 Observaciones

5.4. Observaciones

Giros durante la mision: se ha observado que los pointclouds que son tomados mientras

el robot realiza una rotacion contienen bastantes errores. Para obtener un mapa de mayor

calidad se podrıa realizar una seleccion previa con el fin de eliminar aquellas nubes de

puntos en las que el vehıculo haya realizado alguna rotacion.

Filtros de pointclouds: libpointmatcher ofrece una gran multitud de opciones de filtrado

de las nubes de puntos que permiten obtener procesos de ejecucion mas o menos rapidos y

unos resultados de mayor o menor calidad. Para este proyecto se han implementado unos

filtros y lımites sencillos, sin pararnos en exceso en el estudio profundo de libpointmatcher.

Es muy recomendable realizar un estudio de este software para conseguir mapas de la mejor

calidad posible.

Influencia de los objetos: aparentemente no podemos asegurar que el tipo de superficie

de los objetos influya directamente en la calidad de los mapas obtenidos. Donde se puede

apreciar mejor esta relacion es en los mapas generados del escenario que contiene una

mezcla de todo tipo de superficies. Como se puede apreciar, en todas las figuras existen

por igual los pequenos duplicados. Lo que sı podemos decir es que los errores se aprecian

mas en aquellas figuras de menor tamano, ya que la distorsion se aprecia con mayor

facilidad. Otro detalle que se observa es que los errores destacan mas tambien en aquellos

elementos que contengan vertices mas cerrados, por ejemplo, en los conos, el vertice es un

unico punto, por lo que resalta considerablemente mas cuando hay errores de duplicado o

distorsion.

Influencia de las trayectorias: en este caso sı que podemos apreciar unas diferencias

bastante claras entre unas trayectorias y otras. Parece que la mejor trayectoria para generar

los mapas es la circular, se aprecia una mejor definicion de los objetos ası como una

distribucion de errores no homogeneos. Esto es debido a que se realizan mas barridos por

la zona central que por el exterior. En cuanto a establecer si la trayectoria rectangular

es mejor o peor que la triangular, parece que los resultados no son concluyentes. En los

mapas de trayectorias circulares se puede observar un duplicado homogeneo en todos los

elementos del escenario, mientras que en la rectangular existen elementos con mayor grado

de distorsion que otros. Esto podrıa ser debido a que el numero de posiciones objetivo

son diferentes de una a otra trayectoria, o porque el tiempo de ejecucion de la mision es

54

5.4 Observaciones

considerablemente mayor en las misiones de trayectoria triangular. Habrıa que realizar un

numero mayor de pruebas para obtener una mejor muestra de resultados.

Calidad de nubes de puntos: la generacion de nubes de puntos de calidad es un factor

importante a la hora de generar nuestros mapas. Es por ello que las misiones se deben

plantear de tal manera que la velocidad sea la adecuada con respecto a la frecuencia del

multibeam. De esta manera podremos conseguir una mejor definicion del fondo con un

solo barrido del vehıculo.

Tiempo de generacion de mapas: existe un gran numero de factores que afecten al

tiempo de generacion de los mapas, pero si nos centramos en evaluarlos segun las trayec-

torias, las misiones de trayectoria circular precisan de un tiempo mayor para su ejecucion.

Esto afecta tambien al numero de nubes de puntos obtenidos, pues la generacion de estos

se realiza cada ciertos segundos, por lo que en el caso de las trayectorias triangulares se

obtienen muchas mas nubes de puntos. Y, como libpointmatcher corrige una a una las

nubes de puntos, el tiempo de ejecucion de los mapas de misiones de trayectoria triangular

es bastante mayor en comparacion con los otros.

55

6

CONCLUSIONES Y LINEAS

FUTURAS

6.1. Conclusiones

Este proyecto nos acerca a la solucion de generacion de mapas de fondos acuaticos, se hace un

estudio mas o menos profundo de las distintas herramientas que nos permiten generar los mapas

abarcando el proceso entero, es decir, desde la planificacion de una mision y los componentes

necesarios para obtener los datos, hasta un tratamiento de estos y la generacion del mapa.

Hemos estudiado UWSim y parece un simulador idoneo para la simulacion de misiones y

entornos marinos, ofreciendo una gran multitud elementos parametrizables sin perder simpli-

cidad de manejo. Existe ademas una documentacion bastante completa con algunos tutoriales

que permite un aprendizaje mas rapido de la herramienta. Sin olvidar la interfaz ROS que nos

facilita la comunicacion instantanea con otras aplicaciones.

Un reto que tenıa este proyecto era la integracion de distintas herramientas para conseguir,

paso a paso un mapa en 3D. Aquı juega un papel importante ROS, ya que es la plataforma de

comunicacion entre las distintas aplicaciones (UWSim, COLA2, Rviz.) y siempre que ha sido

preciso se han desarrollado programas que faciliten esta integracion.

Durante el desarrollo del proyecto hemos tenido que familiarizarnos con las nubes de puntos,

un concepto un tanto abstracto pero que ha sido indispensable para el exito del trabajo. Resulta

llamativo la facilidad con la que se acaban manejado distintas herramientas para el tratamiento

de las nubes de puntos como pueden ser Rviz o Paraview.

Para terminar con la ultima etapa del proyecto, podemos asegurar que libpointmatcher es

56

6.2 Lıneas futuras

una aplicacion mas compleja de lo que a simple vista puede parecer, quiza sea por eso por

lo que los tutoriales que ofrece su portal web esten divididos en tutoriales para principiantes,

para avanzados y para desarrolladores. El tratamiento de imagenes es un campo de la roboti-

ca muy extenso y requiere de unos conocimientos y estudios previos para conseguir trabajar

adecuadamente y obtener resultados de cierta calidad.

Este proyecto cumple perfectamente con su objetivo principal, pues tras su desarrollo se

observa un proceso continuo de investigacion, aprendizaje y aplicacion de herramientas que

permitiesen la continuidad del trabajo.

6.2. Lıneas futuras

Este proyecto ofrece un base consistente que se puede perfeccionar en muchos aspectos, asi

como utilizarlo para otros trabajos en los que se precise de un conocimiento del entorno. A

continuacion mencionamos algunas de ellas:

Generacion de la trayectoria y de las distintas posiciones objetivo de forma automatica,

indicando simplemente el area de interes.

Integracion simultanea de la navegacion con la herramienta libpointmatcher. Cuando se

ejecuta el ICP, este devuelve una matriz de transformacion, es decir la correccion de errores

de posicion. Si se consigue enviar esta transformacion al sistema de navegacion del vehıculo

durante la ejecucion de la mision, se podrıa realizar una correccion y afinar ası los datos

de navegacion.

Evaluacion de error del mapa generado con el mapa original. Se puede investigar alguna

herramienta que aplique algun algoritmo entre dos mapas y que calcule el error entre

ambos. Con esto se podrıan sacar afirmaciones mas concluyentes acerca de la influencia

tanto de las trayectorias como del tipo de superficie de los objetos.

Reconocimiento de objetos. Este proyecto puede servir como base a otro en el que se

persiga el reconocimiento de objetos, aportando al sistema cierta inteligencia. Ası a partir

de aquı, existe una gran variedad de aplicaciones, como puede ser el salvamento marıtimo

realizando busqueda de cuerpos.

57

7

PLANIFICACION Y

PRESUPUESTO

7.1. Estructura de Descomposicion del Proyecto

58

7.1 Estructura de Descomposicion del Proyecto

Figura 7.1: EDP. Estructura de descomposicion del proyecto dividido en 5 bloques.

59

7.2 Diagrama de Gantt

7.2. Diagrama de Gantt

Figura 7.2: Diagrama de Gantt.

7.3. Presupuesto

Se detalla a continuacion el presupuesto del proyecto. Para ello solo se han tenido en cuenta

los costes del personal, que suponemos un ingeniero en una empresa de I+D, y los costes que

supone un ordenador suficientemente potente capaz de soportar la carga de trabajo que este

proyecto exige:

Cuadro 7.1: Numero de horas de trabajo anuales

Duracion de un ano medio 365,25 dıas

Sabados y Domingos -104,36 dıas

Festivos -15 dıas

Total dıas efectivos de trabajo 245,64 dıas

Horas de trabajo diarias 8 horas

Total horas de trabajo efectivas anuales 1967 horas

60

7.3 Presupuesto

Cuadro 7.2: Coste anual del empleado

Concepto Coste en euros

Sueldo neto e incentivos 23.439,47 euros

Seguridad social (35 %) 8.203,82 euros

Coste total anual 31.643,29 euros

Cuadro 7.3: Coste efectivo por hora

Coste efectivo de cada hora 16,08 euros/hora

Cuadro 7.4: Coste del personal

Creditos ECTS del TFG 12.0 ECTS

Equivalencia 1 ECTS 30 horas

Horas totales 360 horas

Coste del personal 5788,8 euros

Cuadro 7.5: Caracterısticas del ordenador.

RAM 8GB

Disco duro 500GB

Tarjeta Grafica 2GB dedicada

Sistema operativo Linux

Coste Ordenador 800 euros

Cuadro 7.6: Coste total del proyecto.

Coste del personal 5788,8 euros

Ordenador 800 euros

Coste total del proyecto 6588,8 euros

61

Bibliografıa

[1] Author of DEM. [link]. 3

[2] Angel M. Felicısimo. 1999. [link]. 3

[3] Radu Bogdan Rusu and Steve Cousins. 3D is here: Point

Cloud Library (PCL). 2011. 4

[4] Armin Hornung, Kai M. Wurm, Maren Bennewitz, Cyrill Stach-

niss, and Wolfram Burgard. OctoMap: An Efficient Proba-

bilistic 3D Mapping Framework Based on Octrees. 2013.

4

[5] H. Cox, R. Zeskind, and M. Owen. Robust adaptive beamfor-

ming. pages 1365 – 1376, 1987. 6

[6] Albert Palomer, Pere Ridao, and David Rivas. Multi-beam te-

rrain/object classification for underwater navigation co-

rrection. pages 1365 – 1376, 2015. 7

[7] J.M. Preston, A.C. Christney, and S.F. Bloomer. Seabed clas-

sification of multibeam sonar images. pages 1365 – 1376,

2002. 7

[8] H. Manik and M. Furusawa. Combined underwater acous-

tic and radar instruments for assessing fish near seabed

and mapping seabed. 2002. 7

[9] Edward Thurman, James Riordan, and Daniel Toal. Automated

Optimisation of Simultaneous Multibeam and Sidescan

Sonar Seabed Mapping. 2007. 7

[10] ROS web page. 9

[11] M. Prats; Perez J.; J.J. Fernandez; P.J. Sanz. An open source

tool for simulation and supervision of underwater inter-

vention missions. (1):1247 – 1267, Oct 2012. 9

[12] Andres El-Fakdi y Marc Carreras Narcis Palomeras. COLA2:

A Control Architecture for AUVs. pages 695 – 716, Aug

2012. 12, 26

[13] Sparus II web page. 12

[14] Girona 500 web page. 12

[15] Libpointmatcher documentation. 17, 35

[16] Object modelling by registration of multiple range ima-

ges. pages 145–155. 17

[17] Root-mean-square deviation. 17

[18] Approximate k-d tree search for efficient ICP. 2003. 18

[19] Paraview web page. 33

62