reconstruccion 3d de fondos marinos ...oa.upm.es/47382/1/tfg_oscar_leon_manrique_garcia.pdfpermite...
TRANSCRIPT
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