DETECCIÓN DE SEÑALES Y LÍNEAS DE CARRIL PARA …oa.upm.es/54102/1/TFG_RODRIGO_LADERO_GARCIA.pdf · 2019-02-25 · más amplia y proponiendo un enfoque con aproximaciones polinomiales

DETECCIÓN DE SEÑALES Y LÍNEAS DE CARRIL PARA CONDUCCIÓN AUTÓNOMA CON VEHÍCULO A ESCALA

FEBRERO 2019

Rodrigo Ladero García

DIRECTOR DEL TRABAJO FIN DE GRADO:

Jorge Godoy Madrid Manuel Ferre Pérez

Ro

dri

go

Lad

ero

Gar

cía

TRABAJO FIN DE GRADO PARA

LA OBTENCIÓN DEL TÍTULO DE

GRADUADO EN INGENIERÍA EN

TECNOLOGÍAS INDUSTRIALES

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES

DEPARTAMENTO DE AUTOMÁTICA, INGENIERÍA ELÉCTRICA YELECTRÓNICA E INFORMÁTICA INDUSTRIAL

Trabajo Fin de Grado:DETECCIÓN DE SEÑALES Y LÍNEAS DE CARRIL PARACONDUCCIÓN AUTÓNOMA CON VEHÍCULO A ESCALA

Autor: Rodrigo Ladero García

Tutor 1: Jorge Godoy Madrid

Tutor 2: Manuel Ferre Pérez

La vida es y seguirá siendo unaecuación incapaz de solución,pero contiene ciertos factoresconocidos.

Nikola Tesla

Agradecimientos

Tras unos meses de intenso trabajo y esfuerzo por cumplir los objetivos de ganar lacompetición y terminar de la mejor forma posible mis estudios de grado es momentode agradecer a todas las personas que han hecho posible este proyecto.

En primer lugar destacar los esfuerzos de mis padres por hacer viables mis estudios,a mi hermana y mis sobrinas, Vera y Jara.

Agradecer también a Adrián, Alonso, Almudena, Carlos, Jorge, Juan, Maca,Marina, Marta P., Marta F. , Nieves y Víctor, compañeros y amigos que te recuerdanque no todo es estudiar y te regalan grandes momentos dentro y fuera de la escuela.

Nada hubiese sido posible sin el trabajo en equipo junto a Victor Jiménez yVíctor Sánchez, responsables del éxito en la competición y excelentes compañeros.Agradecer también a Antonio Artuñedo y a mi tutor, Jorge Godoy, por ser unareferencia de conocimientos para mí y darme la oportunidad de aprender algo nuevocada día. Y, por supuesto, a Jorge Villagrá por el esfuerzo dedicado a organizar alequipo y estar al frente del proyecto.

Por último, dedicar este trabajo a Raquel, quién consigue como nadie que seacapaz de cualquier cosa. Harían falta muchos trabajos como este para agradecerletodo lo que merece, gracias por ser como eres.

Resumen

El presente trabajo presenta la solución a los aspectos de detección de señales detráfico y el seguimiento de líneas de carretera en un vehículo autónomo a escala.

El objetivo del trabajo es integrar las partes mencionadas dentro del sistema delcoche autónomo y presentar el conjunto a la competición Seat Autonomous DrivingChallenge, debiendo superar una serie de desafíos con una conducción completamenteautónoma.

La detección de las señales incluye la identificación de los marcadores AR yclasificación en función del tipo de señal correspondiente además de la segmentaciónen la imagen de los marcadores luminosos en las señales que lo requieran paraidentificar el color y, con ello, el estado de la señal.

El seguimiento de líneas tiene como objetivo mejorar la detección que se tenía elaño pasado, que abarcaba una zona limitada frente al coche, buscando una visiónmás amplia y proponiendo un enfoque con aproximaciones polinomiales de las líneasde carretera para mejorar el control.

Abstract

This paper presents the solution to the aspects of detection of traffic signals andthe detection and tracking of road lines in an autonomous vehicle at scale.

The aim of the work is to integrate the aforementioned parts within the autono-mous car system and present the whole solution to the Seat Autonomous DrivingChallenge competition, having to overcome a series of challenges with a completelyautonomous driving.

The detection of traffic signals includes the identification and classification ofthe AR markers associated to each type of signal and the segmentation of the lightmarkers area in the signals that require it to identify the color and, with it, the stateof the signal.

The tracking of the road lines aims to improve the detection that was has lastyear, which covered a limited area in front of the car, seeking a broader vision andproposing an approach with polynomial functions of the road lines to improve control.

Resumen ejecutivo

El trabajo aquí desarrollado tiene como marco motivacional la participación enla competeción Seat Autonomous Driving Challenge, en que la que los participantesdesarrollan sus soluciones para que un coche autónomo a escala supere una seriede pruebas. El año pasado, en la primera edición de la competición el equipo de laUniversidad Politécnica de Madrid(UPM) quedó en segundo lugar y, este año, elnuevo equipo tiene como objetivo ganar la competición.

El equipo está formado por tres estudiantes de la Universidad Politécnica deMadrid (UPM) en colaboración con integrantes del programa AUTOPÍA del Centrode Automática y Robótica (CAR) de Madrid, habiéndose desarrollado la totalidaddel trabajo en sus instalaciones de Arganda del Rey (Madrid).

Los componentes hardware son cedidos por la organización de la competición ycorresponde al equipo desarrollar y programar el sistema que haga capaz al vehículode llevar a cabo una conducción sin asistencia, empleando como herramienta softwareROS (Robot Operating System) y como lenguaje de programación principal C++.

El desarrollo del trabajo se divide principalmente en tres partes: una primeraparte en la que se aplican las soluciones a un simulador del coche en Gazebo, unasegunda parte en la que se pasa al control del coche real en la pista de pruebas y unatercera parte en la que se recogen los resultados obtenidos después de la competiciónpara un análisis de los mismos.

(a) Imagen del simulador (b) Imagen de la pista de pruebas

El sistema del coche se puede dividir en los siguientes subsistemas: localizacióncon un sistema GPS adaptado al coche, detección de obstáculos, detección de laslíneas de carretera, detección de las señales, maniobra de parking y el supervisor delcoche. Los sistemas desarrollados en el presente trabajo son, por un lado, la detecciónde las señales y semáforos, y la detección y seguimiento de las líneas de carretera.

La detección de las señales se basa en la detección de marcadores AR, asignándoseun marcador para cada tipo de señal y teniendo en total ocho tipos diferentes. Deentre ellos, el semáforo, que puede estar en verde o en rojo, y la señal de parking, quepuede estar encendida o apagada, cuentan con indicadores luminosos para conocer el

(a) Señales en el simulador (b) Señales en real

estado de la misma. Por ello, aparte de determinar el tipo de señal es importantehacer una segmentación de la imagen para acceder al color del indicador.

En lo referente a la detección y seguimiento de líneas el objetivo era plantear unenfoque distinto respecto al trabajo que se tenía de la edición previa. El problemaprincipal era la carencia de rango que se tenía en la imagen que se utilizaba parala detección de las líneas respecto a la visión que podía llegar a alcanzar realmenteel coche y que llevaba a basar todas las líneas detectadas como rectas. Por ello seha propuesto un modelo que amplía el campo de visión de las líneas y aplica unaaproximación polinomial para representar las detecciones, teniendo una modelizaciónmás real y con más información de la carretera. Además, se aprovechan las propiedadesy funciones matemáticas de los polinomios para obtener los parámetros que permitenel control del coche.

(a) Aproximación polinomial en tramo incli-nado

(b) Aproximación polinomial en curva

Como se explicará a lo largo del trabajo, exiten grandes diferencias entre hacerlas pruebas con el simulador y pasar más tarde al coche real, teniendo que haceradaptaciones de código y parametrizaciones condicionadas por circuntancias físicas ylumínicas referentes al tratamiento de las imágenes tomadas por la cámara.

Códigos UNESCO:

120113 Polinomios

331101 Tecnología de la automatización

331102 Ingeniería de control

330405 Sistemas de Reconocimiento de Caracteres

2 Rodrigo Ladero García

Índice general

1. Introducción y objetivos 5

1.1. Ámbito del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2. Objetivos del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Estado del arte 9

3. Seat Autonomous DrivingChallenge 15

3.1. Descripción de la competición . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1. Circuito y obstáculos . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.2. Elementos del circuito . . . . . . . . . . . . . . . . . . . . . . 17

3.1.3. Señales de tráfico . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.4.1. Navegación simple . . . . . . . . . . . . . . . . . . . 21

3.1.4.2. Navegación con señales de tráfico . . . . . . . . . . . 21

3.1.4.3. Navegación con señales de tráfico, evasión de obstácu-los ymaniobra de aparcamiento . . . . . . . . . . . . . . . 22

3.2. Plataforma utlizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.2.1. Ubuntu 16.04 . . . . . . . . . . . . . . . . . . . . . . 31

3.2.2.2. GitLab . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.2.3. ROS Kinetic . . . . . . . . . . . . . . . . . . . . . . 33

3.2.2.4. OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . 38

3

ÍNDICE GENERAL

4. Estructura de software 43

4.1. Estructura de software inicial . . . . . . . . . . . . . . . . . . . . . . 43

4.2. Estructura de software desarrollada . . . . . . . . . . . . . . . . . . . 47

5. Detección de señales y semáforos 51

5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2. Trabajo previo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3. Algoritmos de detección y clasificación . . . . . . . . . . . . . . . . . 62

5.4. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6. Detección y seguimiento de líneas 77

6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.2. Herramientas empleadas . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2.1. Filtros de imagen . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2.2. Herramientas matemáticas . . . . . . . . . . . . . . . . . . . . 89

6.3. Algoritmo de clasificación y análisis matemático . . . . . . . . . . . . 93

6.4. Ánalisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7. Conclusiones y líneas futuras 115

7.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.2. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

8. Planificación temporal y costes 117

8.1. Planificación temporal . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.2. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Referencias 123

Anexo I: Índice de figuras 129

Anexo II: Índice de tablas 132

Anexo III: Glosario y abreviaturas 133


1. Introducción y objetivos

1.1. Ámbito del trabajo

El presente Trabajo de Final del Grado en Ingeniería en Tecnologías Industriales,especialidad en Automática y Electrónica se ha realizado en el Centro de Automáticay Robótica (CAR), un centro conjunto entre la Universidad Politécnica de Madrid(UPM) y el Consejo Superior de Investigaciones Científicas (CSIC). Concretamente, lamayor parte del trabajo se realizó en sus instalaciones de Arganda del Rey (Madrid).

El Centro de Automática y Robótica fue fundado en 2008 con el objetivo de desa-rrollar investigaciones en los campos de Ingeniería de Control, Percepción Artificialy Robótica, proporcionando soluciones útiles y beneficiosas para la sociedad. Desdeentonces, han demostrado su potencial en las áreas de la automatización, basándoseen la experiencia de sus investigadores y en sus investigadores. CAR participa en ungran número de proyectos y programas de la Comisión Europea, el Plan Nacionalde España, programas de Comunidades Autónomas y numerosas colaboraciones conempresas.

En el año 2017 el programa AUTOPÍA participa en la primera edición del SeatAutonomous Driving Challenge (SADC), evento dedicado a la conducción autónomay llevado a cabo por CARNET (Cooperative Automotive Research Network) ySEAT España. Se menciona únicamente el meritorio segundo puesto obtenido en lacompetición, con la participación de cuatro estudiantes de Máster Universitario deAutomática y Robótica de la UPM, ya que en un capítulo posterior se darán detallesde la competición.

Con motivo de la importancia del evento y de la relación que mantiene con lasactividades del programa AUTOPÍA, se decide volver a participar por segundo añoen la competición. A partir de una de las vacantes de participación parte el presenteTrabajo de Fin de Grado. Teniendo en cuenta la amplia extensión que implica eldesarrollo del sistema de conducción autónoma para el proyecto, se llevó a cabo ladivisión que se comentará más adelante, y que dio lugar a que este trabajo trate sobrela detección y seguimiento de líneas de carretera, y sobre la detección de señales ysemáforos.

5

CAPÍTULO 1. INTRODUCCIÓN Y OBJETIVOS

Figura 1.1: Coche del programa AUTOPIA

1.2. Objetivos del trabajo

El objetivo principal de llevar a cabo el trabajo es ganar la competición SADCque se ha mencionado desarrollando una solución tecnológicamente eficiente que seacapaz de superar todas las pruebas.

Además, se ha valorado personalmente el ámbito del trabajo, ya que representaaspectos como la visión artificial y el control de un vehículo autónomo, disciplinasque se han pasado únicamente por encima durante los estudios del Grado y que seconsideran interesantes y campos de estudio con futuro.

Desde el punto de vista del aprendizaje resultan importantes el trabajo enequipo, dependiendo de los progresos de los otros miembros y que ellos dependan deuno mismo. Además, haber compartido el trabajo con ellos ha supuesto conseguirconocimientos en las partes de la solución desarrollada en el coche que no son motivode este trabajo.

En lo que respecta al desarrollo de este trabajo, los objetivos se pueden resumir enconseguir una detección e interpretación precisa y eficiente de las señales, y ampliarel rango de visión de la detección y seguimiento de líneas respecto al seguimientoque se tenía del año pasado.

1.3. Estructura de la memoria

Se detalla a continuación los capítulos en los que se divide la presente memoria,junto a un escueto resumen de la temática que les acompaña.

La estructura de esta memoria es la siguiente:

Capítulo 1: Introducción y objetivos

En el presente capítulo se pretende establecer un primer contacto con el entornoen el que se ha trabajado y la materia estudiada a lo largo del trabajo, sin entrar en


DETECCIÓN DE SEÑALES Y LÍNEAS DE CARRIL PARA CONDUCCIÓN AUTÓNOMA CONVEHÍCULO A ESCALA

detalles. Además, se establecen los objetivos académicos y de conocimiento a adquirira lo largo del proyecto.

Capítulo 2: Estado del arte

Se realiza una exposición de la temática del trabajo, haciendo referencia a lopublicado en la actualidad acerca de la misma, así como la situación en la que seencuentra aquello relacionado con el trabajo, mostrando las principales plataformasde conducción autónoma actuales.

Capítulo 3: Seat Autonomous Driving Challenge

Durante este capítulo se darán los detalles relacionados con la competición. Seempezará especificando las normas y condiciones del concurso, el circuito por el quecirculará el coche. Posteriormente se presentarán las pruebas de las que consta eldesafío y el sistema de puntuaciones.

Se explica el entorno utilizado durante la competición, desde el punto de vista dehardware, detallando los componentes que integran los coches de la competición, y desoftware, explicando los lenguajes de programación y sistemas operativos utilizados,los programas y las herramientas empleadas.

Capítulo 4: Desarrollo del proyecto

En este capítulo se explica la estructura de software de la que se parte paraterminar explicando la estructura desarrollada, con el reparto de tareas y las relacionesentre los subsistemas que integran el coche.

Capítulo 5: Detección de señales y semáforos

Se explican todos los detalles referentes a la detección y clasificación de las señalesy los indicadores luminosos que las acompañan, comprendiendo desde el trabajoprevio hasta el desarrollo de los algoritmos y relación con el resto del proyecto,pasando por los métodos y algoritmos empleados y los problemas encontrados.

Capítulo 6: Detección de líneas y seguimiento de carril

Se explican todos los detalles que hacen referencia a la detección y seguimiento decarril, desde el tratamiento de la imagen que capta la cámara hasta la interpretacióny análisis matemático de las líneas.

Capítulo 7: Conclusiones y líneas futuras

Tratando de sintetizar las ideas obtenidas durante el proyecto, se resumen lasideas más importantes, las conclusiones a las que se llegan y algunos apuntes sobretrabajos futuros a partir del presente.

Capítulo 8: Planificación temporal

Se muestran las tareas en las que se divide el trabajo, con su correspondienteestructura de descomposición del proyecto o EDP, el consiguiente diagrama de Gantty el presupuesto estimado para el proyecto.

Escuela Técnica Superior de Ingenieros Industriales (UPM) 7

CAPÍTULO 1. INTRODUCCIÓN Y OBJETIVOS


2. Estado del arte

En el año 2002, la Agencia de Proyectos de Investigación Avanzados de Defensade Estados Unidos, DARPA, anuncia un desafío de conducción autónoma en el quelos coches debían conducir 142 millas a través del desierto de Mojave [1]. Durantesu primera edición en el año 2004, ninguno de los participantes consiguió completarel desafío. En competiciones sucesivas las mejoras en la conducción eran cada vezmayores y en el año 2007 se introdujo un circuito urbano en la competición. Numerososfactores han contribuido a la mejora de la conducción, tales como un mejor softwarede seguimiento de carretera y evasión de obstáculos, mejoras en el radar y en lossensores láser, además de avances en el mapeado del entorno.

Figura 2.1: DARPA Grand Challenge

A partir del año 2009, la compañía estadounidense Google comienza el desarrollode su proyecto de automóvil autónomo, llamado Waymo. El proyecto estuvo almando de Sebastian Thrun, exdirector del Laboratorio de Inteligencia Artificial de launiversidad de Standford y co-inventor de Google Street View. El proyecto fue llevadoinicialmente en secreto, hasta que, pasados unos años, Google anuncia que sus cocheshabían recorrido colectivamente alrededor de 300.000 millas de forma completamenteautónoma y sin ningún accidente. En 2014 se desvela su coche sin conductor al volante,prescindiendo del acelerador y pedal de freno, siendo completamente autónomo. Afinales del año pasado, el coche había recorrido más de dos millones de millas.

Waymo está dotado de múltiples sensores y sistemas de navegación y detecciónde obstáculos. La plataforma base es una caravana híbrida creada por Fiat Chrysler,sobre las que se han integrada los sensores que permiten la conducción autónoma. Sepuede destacar una cámara frontal que funciona en conjunción con otras 8 cámarasposicionadas alrededor del coche para ofrecer una visión de 360 grados. Sus sistemas

9

CAPÍTULO 2. ESTADO DEL ARTE

lidar disparan láser para detectar objetos alrededor del coche, teniendo un alcancemáximo de unos 200 metros. Además, su sensor radar puede detectar objetos encondiciones meteorológicas adversas como lluvia, nieve o niebla [2].

En la actualidad, un gran número de fabricantes de automóviles han apostado suinvestigación y desarrollo a un sector que está en su punto álgido. Compañías comoAudi, Mercedes Benz, BMW o General Motors entre otros, están desarrollando suspropios sistemas de conducción autónoma. Dado que el lanzamiento de un coche quese conduzca sin conductor es un cambio demasiado radical, muchos fabricantes secentran en sistemas de conducción semiautónoma, que conllevan una implicacióncada vez menor del conductor. Por ello, se han establecido diferentes clasificaciones deniveles de conducción. La más ampliamente aceptada es la publicada por la Societyof Automotive Engineers, SAE, publicada en el año 2014 y con su última revisiónen el año 2016. Según esta clasificación podemos encontrar los siguientes niveles deconducción [3]:

Nivel 0: Cualquier coche convencional, que no cuente con ningún sistema deautomatización de la conducción. Los coches con asistente de carril o frenadoautónomo de emergencia también se consideran en este grupo.

Nivel 1: Coches con sistema de control de velocidad de crucero adaptativo,capaz de acelerar, frenar y mantener una distancia de seguridad. También seincluyen los coches con sistema de aparcamiento asistido que sólo actúan sobrela dirección, no sobre la aceleración y el freno.

Nivel 2: Vehículos con sistemas de automatización de la conducción tanto parael movimiento longitudinal, como para el movimiento lateral, o ambos a lavez. El sistema no cuenta con detección y respuesta ante objetos. Se incluyenlos coches con sistema de aparcamiento asistido que actúan sobre dirección,aceleración y freno. También se consideran los coches con asistente para atascosde tráfico, aunque con condiciones de funcionamiento limitadas a velocidadesbajas.

Nivel 3: El vehículo podría detectar y responder a objetos o eventos de maneracompleta. El conductor únicamente tendría la función de intervenir en caso defallo o pérdida de las condiciones de funcionamiento.

Nivel 4: Deja de ser necesario el conductor, siendo el propio coche el queintervenga en caso de fallo o pérdida de funcionamiento, mediante un sistemade respaldo para actuar y poder conducir hasta una situación de riesgo mínimo.El funcionamiento del sistema sigue limitado a ciertas condiciones y el vehículono circulará en algunas situaciones.

Nivel 5: Desaparece por completo la figura del conductor y no habrá condicionesespecíficas limitantes para el funcionamiento del sistema, y el vehículo podráconducir en todo momento o circunstancia.



A parte de Google, por su amplía y estrecha relación con la tecnología y lainnovación, y de las marcas de automóviles más tradicionales, un fabricante queha sabido llamar la atención en materia de conducción autónoma actualmente hasido la compañía creada por Elon Musk, Tesla Motors [4]. Sus coches desatacan enprimer lugar, por su propulsión a partir de motores completamente eléctricos, peroademás, cuentan con Autopilot, un conjunto de sistemas semiautónomos de asistenciaal conductor que espera conseguir la capacidad de conducción autónoma total algúndía. Un hecho importante de este tipo de vehículos es la posibilidad de actualizar susoftware vía OTA, Over the air, lo cual facilita la implementación de sistemas cadavez más avanzados con solo una actualización.

El Autopilot de Tesla emplea ocho cámaras distribuidas por el vehículo, ofreciendouna visión de 360 grados del entorno del vehículo, además de doce sensores paracomplementar la visión a través de la detección de obstáculos. El sistema permiteajustar la velocidad del vehículo en función de las condiciones del tráfico, manteniendoel carril y realizando maniobras como aparcamiento al llegar a su destino.

Figura 2.2: Visión de las cámaras en el sistema Autopilot

Por el momento, la existencia de vehículos que alcancen el nivel máximo deconducción autónoma podría reducirse al Waymo de Google, siendo por el momentoun proyecto de futuro. Incluso los coches de Tesla Motors, considerados unos de losmás avanzados en este campo, aún tienen un nivel 2. En el año 2018, Audi lanza almercado su renovado buque insignia, el nuevo Audi A8. Se trata de un coche conel que Audi puso su enfoque en la tecnología, siendo el primer coche de produccióncon nivel 3 de conducción autónoma. Su sistema Traffic Jam Pilot pertmite que elautomóvil se maneje sin intervención humana en tráfico con velocidades de hasta 60kilómetros por hora [5].

El futuro de la conducción autónoma avanza hacia la idea de hacer del conductorun pasajero sin ninguna labor de control sobre el vehículo. Para ello, los avancesactuales y futuros están focalizados en la inteligencia artificial, en dotar de inteligenciaa los sistemas de conducción, de manera que puedan razonar, perbibir su entorno yllevar a cabo las acciones necesarias para garantizar la seguridad de sus pasajeros.

En el CES 2018 celebrado en Las Vegas, uno de los eventos más importantes sobretecnología de consumo, el fabricante de dispositivos electrónicos Nvidia presentasu nuevo chip dedicado a la conducción autónoma, que incorpora capacidades de



Figura 2.3: Audi A8

inteligencia artificial. Además, se anunció su acuerdo con el fabricante de automóvilesVolkswagen para desarrollar IA en sus futuros coches sin conductor [6]. Habían habidootros acuerdos de entidades relacionadas con dispositivos electrónicos con fabricantesde automóviles en el pasado, como Toyota con el MIT, pero la colaboración entreVolkswagen y Nvidia es la primera en llevar la IA unida al hardware directamente a lalínea de producción. Este hecho descubre la necesidad de coordinación entre empresasde diferentes sectores para integrar un sistema final de conducción autónoma.

Uno de los aspectos fundamentales en la integración de sistemas de conducciónautónoma radica en la detección de las señales de tráfico, campo en el que se hanhecho importantes avances en la clasificación del tipo de señal y en la determinaciónde parámetros como el color o la posición de la misma.

Los enfoques actuales se basan en mecanismos de deep learning debido a que lasseñales pueden representarse y aparecer en multitud de posiciones, formas, colores,diseños y tamaños, haciendo necesario tener una base en la que poder consultar ladetección a realizar y poder comparar.

Por otro lado, dentro de la imagen que se obtiene con la cámara se busca delimitaruna región de interés que delimite la zona en la que se encuentre la señal o el semáforocon el color a identificar, de forma que se mejore la estimación y proporcionandoinformación más fiable sobre la posición de la misma.

Figura 2.4: Detección y delimitación de los semáforos[7]



Un equipo de ingenieros de Google emplea un método para la detección desemáforos que extrae en primer lugar el semáforo detectado, ejecutando una segundaclasificación sobre el mismo. Lo que se pretende es utilizar el conocimiento previode la ubicación del semáforo para después aplicar una red neuronal en la segundaclasificación que le permite entrenar, aprender, etc. Se trata de un enfoque flexible,pero que puede conllevar un importante coste computacional que limita la velocidadde circulación del coche [8].

Figura 2.5: Diagrama de deteccion de semáforos[8]




3. Seat Autonomous DrivingChallenge

3.1. Descripción de la competición

Seat Autonomous Driving Challenge (SADC) es una competición dirigida aestudiantes universitarios con formación técnica en robótica con el objetivo dedesarrollar la tecnología del automóvil del futuro. Los participantes desarrollanfunciones de conducción totalmente autónomas, además de las arquitecturas desoftware necesarias. Su alcance permite que este desarrollo sea aplicable y escalablea algoritmos de conducción autónoma reales y proporciona a los estudiantes lacapacidad de participar en la creación de este concepto de movilidad para el futuro.

La primera edición de SADC tuvo lugar el año 2018 en la Smart City ExpoWorld Congress en la ciudad de Barcelona. En esta ocasión, más de 50 estudiantesde 7 universidades españolas presentaron sus soluciones durante las que estuvierontrabajando durante los meses de preparación. El equipo Autopía terminó en segundolugar y el objetivo para la edición de este año fue obtener el primer puesto.

La edición de 2018 comenzó en Barcelona los días 14 y 15 de mayo, con unevento de preparación organizado por los patrocinadores y coordinadores del evento,y un taller llevado a cabo por el Institut de Robòtica i Informàtica Industrial, IRI.Durante estos días se conocieron los vehículos a utilizar, las normas provisionales dela competición y se realizaron pruebas para comprobar el correcto funcionamiento delos coches antes de regresar a las ciudades de origen. Además, se empezó a trabajarcon el simulador que la organización puso a la disposición de los participantes paraensayar y trabajar durante los meses de competición, a modo de ensayo antes derealizar pruebas sobre los coches reales.

Durante los meses de preparación, los equipos participantes deben implementarsus soluciones con el objetivo de superar las pruebas que se detallarán más adelante.Destacar la presencia de dos entregables, con valor en la calificación final. El primerode ellos fue a finales de julio y el segundo, a finales de octubre, a falta de un mespara la competición.

En el primer entregable, cada equipo debía enviar a la organización un vídeoen el que se muestre el seguimiento de rectas y curvas, una maniobra de

15

CAPÍTULO 3. SEAT AUTONOMOUS DRIVINGCHALLENGE

aparcamiento y la detección de señales por parte del coche, siendo todo ello enel simulador.

En el segundo entregable, las tareas a realizar por el coche serían las mismasque en el primero, pero en este caso, el coche debía realizarlas con el modeloreal.

Los días de competición tuvieron lugar en Madrid los días 22 y 23 de noviembre,más el día 21 dedicado a que los equipos pudieran realizar pruebas y calibracionesen el circuito real antes del evento. Durante estos días las actividades y programafueron los siguientes:

El primer día los equipos tuvieron acceso al circuito para llevar a cabo lapreparación y las calibraciones necesarias. Cada equipo tuvo 2 rondas de 15minutos para ello, con acceso exclusivo al circuito. El resto del tiempo, todoslos equipos tuvieron acceso al circuito a la vez. Además, este primer día sellevó a cabo la presentación técnica de los equipos.

El segundo día tuvieron lugar las primeras pruebas de la competición, estandoel circuito disponible para los equipos antes y después de la prueba.

El último día se llevó a cabo la tercera prueba y la ceremonia de entrega detrofeos.

14 y 15 de Mayo 2018 Workshop Barcelona

31 de Julio 2018 Primer entregable

22 de Octubre 2018 Segundo entregable

21, 22 y 23 de Noviembre 2018 Competición

Tabla 3.1: Programa de la competición

Todas las normas y especificaciones de las pruebas y elementos del circuito seencuentran recogidos en el Rule Book aportado por la organzación [9].

3.1.1. Circuito y obstáculos

El circuito utilizado a lo largo de toda la competición sería el mismo a lo largode las tres pruebas, pero no iba a ser desvelado hasta el primer día de competición,siendo dependiente del espacio disponible en la zona de la competición final. Laorganización facilitó el circuito de la figura 3.1 como referencia para trabajar durantelos meses de preparación.



Figura 3.1: Circuito de preparación

El circuito de la figura superior corresponde a una captura de pantalla delsimulador aportado por la organización. El circuito real sobre el que se realizó lacompetición se mostrará más adelante.

3.1.2. Elementos del circuito

A pesar de no proporcionar la forma y trazado final del circuito, la organizacióncomunicó los elementos que habría presentes en el mismo y que podían afectar a laconducción.

Rotonda de 100 cm de radio de curvatura mínimo, con un carril de ancho únicode 60 cm.

Figura 3.2: Disposición de la rotonda

Segmentos rectos sin limitación de longitud con delimitación por dos líneascontinuas de 2 cm de grosor y una línea discontinua de líneas de 25 cm separadas25 cm. Los carriles tienen un ancho de 40 cm



Figura 3.3: Segmentos rectos

Segmentos curvos con un radio de curvatura mínimo de 80 cm y las mismascaracterísticas referentes a las líneas de carretera. Cabe mencionar que no habráseñal que indique el inicio de una curva después de un segmento recto, deberáser detectado por el coche a partir de las líneas

Figura 3.4: Carretera curva

Intersecciones en a 90 grados y en cruz a 90 grados. La zona intermedia notendrá línea discontinua separando los carriles. Como se indica en las imágenes,las intersecciones se indicarán en sus inicios con la correspondiente señal.

Figura 3.5: Disposición de intersección en T (izquierda) y intersección en X (derecha)

Como puede observarse, en este tipo de zonas puede haber más de una señaljunta, de forma que quede la señal de giro o seguir recto en la parte más alejadade la carretera, y la señal de stop o semáforo más cercana a la carretera.



Zonas de aparcamiento en batería y en paralelo. Tendrán tres plazas de aparca-miento cada una, de las cuales habrá, al menos, una de ellas libre para poderaparcar.

Figura 3.6: Disposición de zonas de parking en paralelo (izquierda) y batería (derecha)

A lo largo del recorrido, fuera y dentro de la carretera, existirán obstáculosestáticos, simulando coches parados, bicicletas o trabajos de reparación dela vía. Además, habrá también obstáculos dinámicos simulando otros cochesmoviéndose por la carretera. Los obstáculos dinámicos comenzarán parados yempezarán a moverse al acercarse el coche, para poder ejecutar la maniobrade adelantamiento que se comentará más adelante. Las dimensiones de losobstáculos son conocidas.

Figura 3.7: Dimensiones de los obstáculos

3.1.3. Señales de tráfico

El apartado de las señales de tráfico y su explicación será tratado más adelante, yaque es un parte fundamental de este trabajo. A continuación, se explicará brevementesu influencia en la competición.

Se establece que a lo largo de todo el circuito habrá señales identificadas con unaetiqueta AR que indicarán un determinado tipo de evento. Además, las señales desemáforos y de parking irán acompañas de un indicador luminoso integrado en lapropia señal, de forma que se pueda conocer el estado de la misma. Las dimensionesde las señales son conocidas y se indican a continuación 3.8.



Figura 3.8: Detalles de las señales (mm)

Los distintos tipos de señales presentes en el circuito serán:

Semáforos con luz verde y roja. Al igual que un semáforo convencional, la luzverde indica al coche que puede continuar su movimiento y el rojo indica alcoche que debe pararse.

Semáforos de parking con luz azul. Estos semáforos indican la presencia deuna zona de aparcamiento en la misma zona en la que está colocada la señal.Además el testigo luminoso encendido indica al coche que debe aparcar.

Señales de giro derecha, giro izquierda y continuar recto. Estas señales secolocan en las intersecciones para señalar al coche la dirección deseada y en lasrotondas para indicar la salida que debe tomar el coche.

Señal de rotonda. Señales colocadas al inicio de una rotonda para alertar alvehículo de su presencia.

Señal de stop. Señales que pueden ser utilizadas en intersecciones para sustituira los semáforos. En este caso, el coche deberá pararse siempre y comprobar eltráfico en ambas direcciones, pasando la intersección cuando sea seguro.

3.1.4. Pruebas

Durante los días de preparación en Barcelona se dieron las ideas preliminares delos organizadores acerca de las pruebas de la competición. Una vez establecidos losdetalles, los equipos recibieron la información completa acerca de las tres pruebasque debían superar con sus vehículos. El número total de pruebas son 3, con unadificultad que se va incrementando. Además, se tendrán en cuenta para la calificaciónfinal obtenida los entregables parciales a lo largo de los meses de preparación y unapresentación, el día antes de la competición final, por parte de cada equipo sobrela metodología técnica seguida para superar los retos. El valor de cada apartado se



detalla en la siguiente tabla. Se diferencia entre la puntuación que corresponde a losdías de competición y la puntuación extra de los entregables y la presentación.

Días de competición

Primera prueba 20 puntos

Segunda prueba 35 puntos

Tercera prueba 45 puntos

Puntuación adicional

Entregables temporales 2.5 puntos cada uno = 5 puntos

Presentación técnica 5 puntos

Tabla 3.2: Puntuación de la competición

3.1.4.1. Navegación simple

En la primera prueba el coche deberá dar una vuelta completa al circuito deforma totalmente autónoma, sin ningún obstáculo, estático o dinámico, y sin teneren cuenta las señales de tráfico. El automóvil debe permanecer dentro de su carrily navegar por líneas rectas y curvas. El recorrido no incluirá ninguna rotonda ylas intersecciones que aparezcan en la ruta del coche serán ignoradas y continuaráhacia adelante. Respecto a las zonas de aparcamiento, estarán presentes físicamente,pero se ignorarán si se detectan. Respecto a la ruta a seguir, podrá ser cualquierade los dos sentidos posibles en un circuito que se establecerá antes de que comienceel desafío. La prueba para cada equipo comenzará cuando el jurado active la señalde inicio del coche correspondiente. Se valorará positivamente que, al dar comienzola prueba, el coche haga parpadear dos veces las luces frontales. El desafío habráterminado cuando el coche atraviesa de nuevo la línea de inicio. En caso de habertiempo restante, el líder del equipo puede elegir reposicionar el coche y realizar unnuevo intento para tratar de mejorar el anterior o anteriores.

3.1.4.2. Navegación con señales de tráfico

En la segunda prueba el coche completará una vuelta completa al igual queen la prueba anterior, sin obstáculos, pero en este caso deberá tener en cuenta lasseñales de tráfico presentes. Los semáforos son controlados por el jurado. El recorridopodrá incluir rotondas, indicadas con su correspondiente señal a la entrada de lasmismas. Se podrán encontrar intersecciones en T e intersecciones en X, que el cochedeberá interpretar debidamente de acuerdo a las especificaciones y normas. Ambascircunstancias se explicarán más adelante. En este caso, al existir señales, el iniciode la prueba tendrá lugar cuando el jurado active la luz verde del semáforo de inicio.Para esta prueba se valorarán positivamente la activación de las luces en las siguientescondiciones.



Acción o evento Señal luminosa

Espera en una señal de stop o se-máforo

Encender las dos luces rojas trase-ras

Girar a la izquierda en una inter-sección

Parpadear luz intermitente iz-quierda durante la maniobra

Girar a la derecha en una intersec-ción o rotonda

Parpadear luz intermitente dere-cha durante la maniobra

Continuar recto en una intersec-ción

Parpadear ambas luces durante 2segundos

Tabla 3.3: Activación de luces en la segunda prueba

En esta prueba existen dos penalizaciones adicionales relacionadas con los semá-foros y las luces del coche:

Ignorar un semáforo supone una penalización de 2 puntos. Adicionalmente, siel semáforo es ignorado, el equipo tendrá una penalización de tiempo igualal doble de tiempo que el semáforo esté rojo. En este caso, el coche podrácontinuar sin ninguna intervención del jurado.

No usar las luces del coche o usarlas incorrectamente supone 1 punto depenalización, hasta un máximo de 5 puntos.

Al igual que en la anterior prueba, el desafío termina al pasar por el punto de inicio,pudiendo realizar intentos extra mientras se encuentre dentro del tiempo.

3.1.4.3. Navegación con señales de tráfico, evasión de obstáculos ymaniobra de aparcamiento

En la última prueba, el coche deberá completar una vuelta completa al circuitode forma completamente autónoma, teniendo en cuenta las señales de tráfico, ade-lantando obstáculos estáticos o dinámicos presentes en la carretera, y realizando unamaniobra de aparcamiento. Durante el recorrido, cuando un obstáculo es detectado, elcoche deberá empezar la maniobra de adelantamiento sin colisionar con el obstáculo.Durante el adelantamiento será el único momento en el que el vehículo podrá cruzaral carril contrario sin ser penalizado. Puede haber obstáculos estáticos en el ladoopuesto del carril que deberán ser ignorados, ya que no interfieren en la ruta delcoche. Al encontrar una señal de parking, el vehículo buscará el hueco vacío máspróximo, detectar si el parking es en paralelo o en batería, y ejecutar la maniobracorrespondiente. En la zona de parking habrá obstáculos estáticos, pero al menos unsitio libre. El jurado decidirá cuál de los semáforos de parking encender. En la terceraprueba se tendrá en cuenta el encendido de las luces del coche en las siguientessituaciones, además de las ya mencionadas en las dos pruebas anteriores.



Acción o evento Señal luminosa

Primera mitad de maniobra deadelantamiento

Parpadear luz intermitente iz-quierda

Segunda mitad de maniobra deadelantamiento

Parpadear luz intermitente dere-cha

Detección de área de aparcamien-to

Parpadear luz intermitente delmismo lado dónde se encuentrael área

Completada maniobra de aparca-miento

Parpadear ambas luces durante al-gunos segundos

Tabla 3.4: Activación de luces en la tercera prueba

Además de las penalizaciones adicionales detalladas para la prueba anterior, seañaden algunas específicas para esta prueba relacionadas con los obstáculos y elaparcamiento.

Si el coche no completa la maniobra de adelantamiento del obstáculo dinámicoantes de que se detenga, tendrá una penalización de 3 puntos.

En caso de que el coche sea colocado por el jurado delante de un obstáculo porel jurado, después de haber chocado contra él 3 veces, tendrá una penalizaciónde 10 puntos.

Cruzar una intersección cuando hay un coche cercano se penalizará con 2puntos. En este caso el coche podrá continuar sin intervención del jurado, perosi los coches colisionan se penalizará con 3 puntos.

No completar la maniobra de parking en el tiempo establecido supondrá unapenalización de 3 puntos.



3.2. Plataforma utlizada

3.2.1. Hardware

Durante la presente sección se conocerá el hardware integrado en los cochesutilizados durante la competición, así como la influencia que puedan tener en otraspartes relacionadas con el trabajo.

Los coches utilizados son modelos a escala 1:10 desarrollados en la universidadalemana Freie Universität Berlin, con propósitos educativos. Pueden ser controladosremotamente a través de una aplicación, para teléfonos móviles, por ejemplo, opueden ser programados para conducir en modo completamente autónomo.

Figura 3.9: Coche a escala dearrollado por la Freie Universität Berlin

El coche recibe el nombre ‘AutoNOMOS Mini v3.1’ [10], aunque la carcasa queacompaña la imagen superior se sustituye en el caso de la competición por unacarcasa personalizada con aspecto de vehículo SEAT.

Los sensores del coche se componen de un escáner láser rotatorio (RPLidar) quese encarga de la detección de obstáculos alrededor del coche, una cámara de tipoKinect que provee al coche de una nube de puntos en 3D que pueden ser utilizadospara la detección de objetos y detectar los carriles enfrente del coche, y una cámarafish-eye apuntando al techo utilizada para identificar marcadores, relacionados con elsistema de Visual GPS utilizado en interiores.

Como actuadores, el coche cuenta con dos tiras LED para simular las lucesdelanteras y traseras del coche, un motor brushless que ejerce de fuerza motriz, unservomotor usado para controlar la dirección y una unidad de medición inercial paracomplementar la odometría y medir la rotación del coche.

La parte de control está formada por una placa Odroid como ordenador principal,a la que se conectan los sensores, y una placa Arduino, conectada a las luces, a losdos motores y a la IMU.



En las figuras siguientes se pueden observar las distintas conexiones entre losmódulos electrónicos y un gráfico con un resumen de las interconexiones.

Figura 3.10: Módulos electrónicos y conexiones [10]

Figura 3.11: Árbol de conexiones entre módulos [10]



La placa Odroid es el ordenador principal y funciona con Ubuntu Linux yROS (Robot Operating System) por encima. Fabricada por HardKernel, podemoscompararla a modelos en teoría más conocidos, como Raspberry, pero con mayorpotencia y opciones.

Figura 3.12: Placa Odroid-XU4 64GB

La placa Arduino integrada en el sistema se encarga de controlar el motorbrushless, el servomotor, la unidad de medición inercial (IMU) MPU-6050 y las tirasde LED que simulan las luces del coche. A su vez, la placa Arduino está conectada ala Odroid a través de conexión USB.

Figura 3.13: Arduino Nano v3

Las luces LED son controladas por un pin digital de la placa Arduino y permiteel encendido y el apagado como en un coche real.

En lo que se refiere al control del servomotor, Arduino puede leer el ángulo dedirección deseado a tráves del puerto en serie con la Odroid y establecerá la señalPWM adecuada para el servomotor. Se envía un pulso cada 10 milisegundos. Elservomotor se controlada mandando una señal PWM a través del cable de control yel ancho del pulso determina la posición del eje.

El motor encargado del giro de las ruedas delanteras, ya que las traseras noson motrices, es un motor brushless FAULHABER 2232. Se trata de un motor decorriente continua sin escobillas.



(a) Motor brushless FAULHABER 2232(b) Servomotor Analog Feedback Servo Ada-

fruit 1404

Figura 3.14: Motores del coche

Respecto al servomotor, se emplea un Analog Feedback Servo Adafruit 1404. Esteservomotor tiene la peculiaridad de poseer un cuarto cable que permite leer a travésde una entrada analógica, por ejemplo una de Arduino, la posición del servo, deforma que se pueda mejorar la estabilidad o conocer en todo momento el movimientodel servomotor.

Figura 3.15: Retroalimentación del servomotor

En este caso la retroalimentación al microcontrolador permite controlar y corregirlos errores en el funcionamiento del servomotor. Podemos hablar de interferenciaseléctricas y físicas, pérdidas de conexión o incluso alimentación insuficiente del motor.

La cámara encargada de aportar una imagen de la parte delantera del vehículoes una cámara Intel Realsense SR300. Se trata de un modelo de cámara frontal,con profundidad 3D de corto alcance y un módulo 2D, combinando la detección deprofundidad con una cámara RGB de 1080p.

Figura 3.16: Cámara Intel Realsense SR300

Algunos ejemplos de aplicaciones de esta cámara son el análisis de rostros ydetección, escaneado y mapeado, segmentación de escenas, seguimiento de la mano ydetección de gesto, y realidad aumentada. En el caso de nuestro coche, nos proporciona



una imagen en 2D de lo que nuestro coche se encuentra en su parte delantera, ademásde la herramienta de profundidad que puede ser útil para detectar obstáculos.

Respecto a la cámara utilizada para obtener una imagen de la parte superiordel coche, se emplea una cámara fish-eye ELP 1080p. Es una cámara utilizada enaplicaciones de monitoreo, seguridad y control, debido a alta densidad de píxeles, subuena interpretación de los colores y sus prestaciones para cualquier condición deluz.

Figura 3.17: Cámara ELP 1080p

La cámara fish-eye se utiliza en nuestro coche para el sistema Visual GPS,teniendo la misión de localizar los paneles y simuladar de esta forma un sistema delocalización GPS. La lente proporciona una imagen de 180º, sin embargo, dado queel sensor no es cuadrado, los campos de visión horizontal son diferentes. Este hechoda como resultado un campo de visión hacia delante y hacia atrás reducido, ademásde regiones negras en los bordes de la imagen. Las resoluciones óptimas para obtenerel máxima campo horizontal y vertical son 1920x1080 y 1280x1024.

Se debe destacar la influencia de la exposición de la cámara. Dado que los panelesdel Visual GPS generan luz, el sensor se satura fácilmente y dificulta la diferenciaciónde los colores, ya que tiende a ver todos como blancos. Si se disminuye la exposición,únicamente las luces de colores se verán por la cámara y podrán ser detectadas.

El modelo de LIDAR (Light or Laser Detection and Ranging) es el SLAMTECRPLidar A2 360. Este tipo de sistemas se emplear en labores de mapeado, localizacióny modelado de objetos y entorno.

Figura 3.18: SLAMTEC RPLidar A2 360

Se trata de un láser 2D 360º de bajo coste capaz de tomar hasta 8000 muestraspor segundo debido a su alta velocidad de rotación. El alcance del sistema es de 18metros, con una frecuencia de escaneo de 10Hz, lo que supone una velocidad de 600rpm y una resolución de 0,9º. La frecuencia de escaneo puede ser modificada en elrango de 5–15 Hz para ajustarse a la aplicación.



El sistema de triangulación desarrollado por SLAMTEC ofrece al sistema unexcelente rendimiento en interiores y exteriores sin exposición a luz solar directa.Este hecho, unido al pequeño tamaño del dispositivo lo hace especialmente adecuadopara la integración en nuestro coche a escala.

La alimentación de sistema se lleva a cabo por una batería tipo LiPo utilizadacomúnmente en maquetas y coches radiocontrol. El modelo cuenta con 4 celdas enserie y 1 celda en paralelo, con un voltaje nominal de 14.8V y una capacidad de3800mAh. Cuenta con un conector de potencia XT60 y un conector de equilibrioJST XH.

(a) Bateria LiPo del coche (b) Indicador del nivel de batería

Figura 3.19: Sistema de alimentación

Además, la batería cuenta con un tester para comprobar el nivel de carga dela batería que se conecta al conector de equilibrio. Nos muestra numéricamente elnivel de carga y emite un sonido de verificación al conectar que indica el correctofuncionamiento de la batería.

Cómo se ha comentado en el apartado referido al Arduino, el sistema cuentacon una unidad de medición inercial IMU MPU-6050. Posee seis grados de libertad,combinando un acelerómetro de 3 ejes y un giroscopio de 3 ejes.

Figura 3.20: IMU MPU-6050

Debido a la inexistencia de un módulo Wi-Fi en la placa Odroid será necesariointegrar un adaptador Edimax Wi-Fi USB AC600 de doble banda y alta ganancia,modelo concreto EW-7811UAC.

Las conexiones USB procedentes de la Odroid, del Arduino, de la cámara fish-eye,del módulo Wi-Fi y del serial del RPLidar están conectadas a través de un USBHUB LogiLink con 4 puertos de entrada y 1 puerto de salida.



(a) Módulo Wi-Fi Edimax EW-7811UAC (b) HUB USB LogiLink

Figura 3.21: Sistemas de comunicación

Por último, la carcasa utilizada está fabricada en fibra de vidrio, un materialeconómico y de baja fragilidad, pudiendo ser colocado y extraído del resto delconjunto sin riesgo de romperse. La forma de la carcasa se asemeja a un modelo realdel fabricante y organizador del evento, SEAT.

(a) Parte delantera (b) Parte trasera

Figura 3.22: Carcasa del coche



3.2.2. Software

El software requerido para la competición es Ubuntu 16.04 y la distribución deROS Kinetic. Además, se han utilizado la biblioteca de visión artificial OpenCV,la herramienta de software matemático MATLAB, como lenguaje de programaciónpara la creación del código de funcionamiento del coche C++ y como plataformapara coordinar el trabajo y los archivos de todos los miembros del equipo, GitLab.

3.2.2.1. Ubuntu 16.04

Ubuntu es un sistema de código abierto basado en GNU/Linux que se distribuyebajo una licencia de software libre y tiene como base un sistema gráfico basado enUnity. En la actulidad se puede encontrar en ordenadores de escritorio, servidoresinformáticos, ordenadores empresariales, teléfonos móviles o incluso televisores, debidoa las distintas versiones del sistema operativo.

Figura 3.23: Logo de Ubuntu

La versión utilizada en el presente trabajo es Ubuntu 16.04 Xenial Xerus, unaversión LTS lanzada en abril de 2016. Se usa esta versión principalmente por sucompatibilidad con la distribución de ROS, de la que se hablará más adelante, y porser, por el momento, la versión más desarrollada y mantenida.

3.2.2.2. GitLab

GitLab es un servicio web de control de versiones y desarrollo de softwarecolaborativo basado en Git, un software pensado para llevar registro de los cambiosen archivos y coordinar el trabajo que varias personas realizan sobre los archivoscompartidos.

Los sistemas de control de versiones son una herramienta imprescindible para losequipos dedicados al desarrollo de software para administrar y registrar los cambiosque se producen en el código fuente a lo largo del tiempo. En caso de cometer un error,los desarrolladores pueden retroceder y comparar versiones anteriores del código paraayudar a corregir el error y minimizar la interrupción de todos los miembros delequipo. También se puede dar la circunstancia de que dos o más miembros del equipoestén trabajando sobre el mismo código de forma simultánea, siendo el control deversiones una valiosa herramienta para evitar conflictos y rastreando los cambiosindividuales de cada desarrollador.



(a) Git

(b) GitLab

Figura 3.24: Logos de Git y GitLab

Git tiene tres estados principales en los que se pueden encontrar los archivos:commited, modified y staged. Se han evitado las traducciones de los términos, yaque se considera fundamental nombrarlos de esta forma.

Commited significa que los datos están guardados de forma segura en tu basede datos local.

Modified significa que el archivo ha sido modificado, pero aún ha pasado a sercommited en la base de datos.

Staged significa que un archivo ha sido marcado en su versión actual para ir asu próxima instantánea de confirmación.

A partir de los estados de los archivos se establecen las tres secciones principales deun proyecto Git:

Figura 3.25: Flujo de trabajo en Git



El flujo de trabajo convencional en Git es el siguiente:

1. Se modifican los archivos en el directorio de trabajo Working Directory.

2. Se seleccionan aquellas modificaciones que se quieren llevar a la Staging Area.Dichos cambios serán parte del próximo commit.

3. Se realiza el commit, que toma los archivos tal como están en la Staging Areay almacena esta instantánea en el directorio Git.

Un concepto importante en el trabajo con sistemas de control de versiones esel de rama o branch. Se emplean para trabajar de forma paralela y eficaz en unproyecto, quedando la rama principal master intacta. Al finalizar el desarrollo que sequería probar en esa rama, se puede fusionar con la rama master.

Algunos comandos básicos de Git empleados durante el trabajo se detallan acontinuación:

3.2.2.3. ROS Kinetic

Robot Operating System,ROS, es un framework para el desarrollo de softwareutilizado en robótica que provee la funcionalidad de un sistema operativo en unclúster heterogéneo. Su historia es reciente, comenzando su desarrollo en el año 2007en el laboratorio de inteligencia artificial de la universidad de Standford.

Figura 3.26: Logo de ROS

ROS es un software libre bajo términos de licencia BSD, una licencia de softwareotorgada a sistemas BSD (Berkeley Software Distribution), un tipo del sistemaoperativo Unix-like. De este modo, ROS se extiende a disciplinas de investigación,desarrollo de robots industriales, propósitos educativos y con fines de ocio.

ROS proporciona bibliotecas y herramientas que, mediante una abstracción delhardware, permite el acceso a los componentes del mismo y el diseño de complejasaplicaciones software teniendo una idea superficial de cómo funciona el hardware.

El método principal para crear una red de comunicación entre los distintoscomponentes es proporcionar servicios que puedan ser consultados o definir conexionespublisher/subscriber entre los nodos. Las comunicaciones se realizan a través de



mensajes de un tipo específico proporcionado por los paquetes generales o porpaquetes individuales.

El sistema operativo que cuenta con soporte oficial es Ubuntu, debiendo tener encuenta la versión que tiene, a su vez, soporte y compatibilidad para la distribuciónde ROS seleccionada. En nuestro caso, al trabajar con la distribución ROS Kinetic,la elección fue Ubuntu 16.04. Por otro lado, ROS permite trabajar en Python o C++como lenguajes de programación, habiéndose seleccionado C++ por sus cualidades yrendimiento.

A continuación, se presentan algunos conceptos y fundamentos de ROS paraentender con mayor facilidad capítulos posteriores [11].

NodosSon procesos o ejecutables que realizan algún tipo de tarea, proceso o cálculo.Normalmente se utilizan varios nodos, cada uno de ellos con un propósito ofunción concreta. Los nodos se escriben con una librería de cliente, por ejemploroscpp.

Los nodos pueden publicar o subscribirse a uno o varios topic para intercambiarmensajes, pudiendo enviar y recibir datos desde otro nodo. Además, los nodospueden también proporcionar o usar un servicio.

TopicsSon canales de información entre los nodos. Cualquier nodo puede publicar osubscribirse a un topic, no pudiendo controlar el nodo que publica quién puedeestar suscrito. De este modo, se puede desacoplar la producción de datos einformación de su propio consumo.

Es fundamental que cada topic tenga un nombre específico para evitar erroresy se debe entender que son canales de información unidireccionales, desde elnodo que publica hasta el nodo que está suscrito. En caso de requerir unacomunicación bidireccional se puede emplear un servicio.

Los topic se caracterizan por ser asíncronos y se utilizan para el intercambiocontinuo de datos.

MensajesSe trata de una estructura de datos simples que se pasa entre los nodos y quese corresponde con el contenido de los topic. Se pueden crear tipos de mensajespersonalizados, aunque los más comunes son variables como enteros, booleanos,datos en coma flotante, así como vectores o estructuras.

La estructura de datos de un mensaje se especifica en los ficheros msg, ubicadosen el subdirectorio msg de un paquete.

ServiciosComo se ha comentado en los topic, se trata de sistemas de comunicaciónunidireccional. Sin embargo, en múltiples aplicaciones que requieran un carácterbidireccional, por ejemplo modelos de petición y respuesta, se emplearán los



servicios. En este tipo de comunicaciones serán necesarias dos estructuras paralos mensajes, una para la petición y otra para la respuesta. Un nodo proveedorofrece un servicio bajo un nombre concreto y un cliente usa el servicio enviandoun mensaje de solicitud y esperando la respuesta. Las bibliotecas cliente deROS generalmente permiten este tipo de interacción a modo de llamada deprocedimiento remoto. Por otro lado, un cliente puede establecer una conexiónpersistente a un servicio, lo que permite obtener un mayor rendimiento a costade una menor robustez a los cambios del proveedor de servicios. Los serviciosse caracterizan por ser síncronos y se utilizan cuando se solicitan unos datosy se espera una respuesta por la otra parte. Los servicios se definen usandoficheros srv, que son compilados en el código fuente por una biblioteca clientede ROS.

MasterPara gestionar el entorno de ROS es necesaria la presencia de un masterproporciona servicios de nomenclatura y registro para el resto de nodos en elsistema. Realiza un seguimiento de subscriptores y publicadores de topics yservicios. El papel del master es permitir que los nodos individuales de ROS seencuentren entre sí. Sin el master, los nodos no serían capaces de encontrarseentre sí o de invocar servicios.

Bags Son formatos de fichero para almacenar datos de mensajes en ROS. Losbags son típicamente creados por una herramienta como rosbag, revisada másadelante, que se suscribe a uno o varios topics y almacena los datos en formade mensaje que recibe. Estos archivos bag pueden ser reproducidos más tardepara los mismos topics o remapearlos para otros topics.

Los ficheros bag son el mecanismo principal en ROS para el registro de datosy su utilización sin conexión posteriormente. Los investigadores utilizan elconjunto de herramientas de los archivos bag para registrar conjuntos de datosaportados por sensores u otros elementos, etiquetarlos y almacenarlos parausarlos en el futuro.

A modo de resumen de los conceptos aportados, se adjunta un esquema que explica lasrelaciones que se establecen entre dos nodos, ya sea a través de servicios o medianteun topic 3.27. También se muestra la importancia del master.

Con el fin de entender mejor el funcionamiento y adquirir una visión global dela organización de ficheros de ROS, a continuación se muestra la organización ypropiedades de algunos ficheros importantes de ROS y su localización dentro de lascarpetas 3.28.

En primer lugar, se muestra el método recomendado de trabajo con paquetescatkin, usando un espacio de trabajo catkin, de la manera más simplificada. Acontinuación, se explican los conceptos referentes.

Source space - srcEspacio que contiene el código fuente de los paquetes catkin. Aquí se puede



Figura 3.27: Relación entre los elementos en ROS

Figura 3.28: Estructura de carpetas y ficheros en ROS

extraer, verificar o clonar dicho código para los paquetes que se desean construir.Cada carpeta dentro del espacio catkin contiene uno o más paquetes catkin.La raíz del archivo src contiene un archivo CmakeLists.txt, que será invocadopor Cmake durante la configuración de los proyectos catkin en el espacio detrabajo.

Build space - buildEspacio dónde Cmake es invocado para construir los paquetes catkin delespacio src. Cmake y catkin mantienen la información de caché y otros archivosintermedios aquí. El espacio build no tiene por qué estar contenido dentro delespacio de trabajo como tampoco es necesario que esté fuera del espacio src,pero es recomendable.

Development space - develEn este espacio se colocan los elementos antes de ser instalados, organizándoseen el espacio de la misma forma que cuando se instalan. De esta forma, se



consigue un entorno de prueba y desarrollo útil que no requiere la instalación.

Install space - installUna vez que los elementos que se desean instalar son construidos, puedenser instalado en el espacio install, generalmente mediante el comando make_install. El espacio de trabajo install no es necesario que esté contenido en elespacio de trabajo.

CMakeLists.txtFichero que es la entrada al sistema de compilación Cmake para la creaciónde paquetes de software. Cualquier paquete compatible con Cmake contieneuno o más archivos CMakeLists.txt que describen cómo crear el código y dondeinstalarlo. El código contenido en un fichero CMakeLists.txt debe seguir unformato estandarizado para su correcto funcionamiento especificando la versiónde Cmake requerida, el nombre del paquete, paquetes adicionales necesariospara la compilación, generadores de mensajes o servicios, librerías o ejecutablesnecesarios o normas de instalación, entre otros elementos.

package.xmlManifiesto del paquete en formato XML que se debe incluir en la carpeta raízde cualquier paquete compatible con catkin. Mediante este archivo se definenpropiedades del paquete, como el propio nombre, la versión, autores, licencias,mantenedores y dependencias de otros paquetes catkin.

Para finalizar el apartado referente a la introducción de ROS se tratarán algunasherramientas utilizadas a lo largo del trabajo.

rvizSe trata de un visualizador 3D que muestra los datos de los sensores e informa-ción de estado de ROS. Mediante rviz se puede visualizar la configuración delmodelo de nuestro coche y representaciones en tiempo real de los valores de lossensores que aparecen en los topics, las imágenes tomadas por la cámara, lasdetecciones del lidar, etc.

Figura 3.29: Simulador visualizado en rviz



rqtFramework que implementa en forma de plugins varias herramientas en me-diante una interfaz gráfica o GUI. Algunos plugins importantes son:

– Topic Monitor: muestra información sobre topics, incluyendo subscribers,publishers, tasa de publicación y mensajes publicados.

– Image View: muestra imágenes o vídeos mediante image_transport.

– Node Graph: visualiza el gráfico computacional de ROS, con los nodos ylas conexiones entre ellos.

– Service Caller: permite llamar a determinados servicios y muestra surespuesta.

3.2.2.4. OpenCV

OpenCV es una biblioteca libre de computación visual creada por Intel. Apareciópor primera vez en 1999 y desde entonces ha sido utilizada en numerosas aplicaciones.Al igual que ROS, cuenta con licencia BSD, que le permite ser usada libremente condeterminados propósitos comerciales y de investigación.

Figura 3.30: Logo de OpenCV

Entre sus aplicaciones más destacadas podemos encontrar el tratamiento deimágenes en 2D y 3D, sistemas de reconocimiento facial y de gestos, identificacióny modelación de objetos y obstáculos, segmentación y reconocimiento, rastreo demovimientos, realidad aumentada, etc. Además, permite la integración de sistemasde percepción de profundidad con dos cámaras. Es multiplataforma, pudiendo serutilizada en Windows, Linux, MacOS, iOS y Android. Además, cuente con soportepara C++, Java y Python, aunque esté escrita en C++. En la actualidad se han idoincorporando otros lenguajes de programación como C# o Ruby, para fomentar laadopción por un público más amplio.

La versión de OpenCV utilizada es OpenCV 3.3.1 [12]. A continuación, se muestrany explican algunas funciones y clases propias de OpenCV empleadas durante eltrabajo.



cv::MatClase que nos permite y manipular los pixeles de una imagen. Representauna matriz n-dimensional y permite almacenar vectores y matrices con valoresreales y complejos, imágenes en escala de grises o a color, campos vectoriales,tensores, etc.

Para representar una imagen en formato digital se representa cada pixel dela imagen en una celda de la matriz, con un valor numérico que puede variarsegún el formato que se utilice para representar la imagen. En una imagen enblanco y negro, cada celda tendrá un valor entre 0 y 255, representando laintensidad de color gris, con 0 para el color negro y 255 para el blanco. Paraimágenes a color tendremos una matriz multidimensional para representar cadauno de los canales de la imagen, siendo el formato por defecto el BGR quecorresponde a los canales azul, verde y rojo. Puede existir un cuarto canalde información para representar la opacidad de la imagen. La organización yvalores de los canales pueden variar según el formato que utilicemos.

imshow(‘image_window’,image_name)Función que permite crear una ventana nueva y mostrar una imagen en ella.La ventana se ajusta automáticamente al tamaño de la imagen. El primerparámetro image_window de la función es el nombre que queremos dar a laventana y el segundo parámetro image_name es el nombre de la imagen quese quiere mostrar.

line(image_name, pt1, pt2, color, thickness, lineType, shift)Función que permite dibujar una línea recta sobre una imagen image_name ,desde un punto pt1 a otro punto pt2 con color color y un grosor thickness. Eltipo de línea lineType será LINE_8 y shift será el número de bits fraccionariosen las coordenadas de los puntos, que en este caso es 0.

polylines(image_name, pts, npts, ncontours, isClosed, color, thick-ness, lineType, shift)Función que permite dibujar varias curvas poligonales en una imagen determi-nada. El parámetro image_name indica el nombre la imagen, pts es el vectorde curvas poligonales, npts el vector con los vértices poligonales, ncontours esel número de curvas, isClosed indica si las curvas forman un polígono cerrado,color establece el color y thickness el grosor de trazado, lineType el tipo delínea que es LINE_8 en este caso y shift el número de bits fraccionarios en lascoordenadas de los vértices.

putText(image_name, ‘Text’, origin, fontFace, fontScale, color,thickness)Función que permite la introducción de texto en una imagen. El parámetroimage_name indica el nombre la imagen, ‘Text’ es el texto que se desea incluiren la imagen, origin es el punto de la imagen que se toma como origen paraser la esquina inferior izquierda de la casilla de texto, fontFace es la fuente deltexto, fontScale es la escala del texto, color el color y thickness el grosor.



(a) Imagen original (b) Imagen con elementos

Figura 3.31: Modificación sencilla de imagen

cvtColor (input_image, output_image, code)Función que permite convertir una imagen desde un espacio de color a otro.Esta función permite un gran número de conversiones. En este trabajo se harealizado la conversión de color BGR a escala de grises y de color BGR a colorHSV. El primer parámetro es la imagen de entrada, el segundo es la imagen desalida y el tercero indica el código de la transformación que se quiere realizar:

– CV_BGR2GRAY : conversión de color BGR a escala de grises

– COLOR_BGR2HSV : conversión de color BGR a color HSV

(a) Imagen original (b) Imagen en HSV

Figura 3.32: Modificación de imagen a HSV

(a) Imagen original (b) Imagen en HSV

Figura 3.33: Modificación de imagen a HSV



En el presente apartado se han presentado algunas funciones básicas de OpenCV, ha-biéndose reservado funciones más específicas para capítulos posteriores que requierenuna explicación más detallada y un contexto en el que incluirlas.

Para finalizar este apartado referente herramientas dedicadas al tratamiento deimágenes, se considera recomendable dar un último concepto referente a este campo.El sistema de coordenadas en dos dimensiones utilizado en imágenes sigue un modelocartesiano, pero la disposición de los ejes es ligeramente distinta. Mientras el ejex tiene la misma dirección y sentido que el convencional, el eje y tiene la mismadirección, pero sentido opuesto. Se muestra en la siguiente imagen la disposición delos ejes.

Figura 3.34: Sistema de ejes de coordenadas en la imagen




4. Estructura de software

En este apartado se pretende aportar una visión general de la estructura decomunicación y relación que existe entre los distintos nodos de la plataforma. Nose incluye este apartado en el de software ya visto, ya que se considera parte deldesarrollo del trabajo interpretar la estructura y ampliarla para implementar lassoluciones en el coche.

4.1. Estructura de software inicial

Se presenta a continuación la estructura general inicial del software proporcionadapara controlar el coche. Aún no se incluyen nodos, topics, o cualquier elemento desa-rrollado por el equipo, únicamente lo entregado por la organización. A continuación,se muestra una figura que representa los nodos, con el nombre del mensaje que seenvían entre ellos 4.1.

Figura 4.1: Estructura de software inicial

43

CAPÍTULO 4. ESTRUCTURA DE SOFTWARE

A partir de la figura anterior se explicarán los nodos con detalle, con los topics alos que están suscritos y en los que publican, y el tipo del mensaje de dichos topics.

serial_nodeEste nodo se comunica con el módulo de Arduino a través del puerto USB ypermite controlar:

– La velocidad lineal del coche.

– El ángulo de giro del servomotor, aunque no coincide con el ángulo degiro real del coche.

– Las luces LED frontales y traseras del coche.

Además, recoge la siguiente información:

– El ángulo de giro del servomotor, sin coincidir con el ángulo de giro realdel coche.

– Los ángulos de cabeceo, guiñada y alabeo del coche respecto a la posicióndesde la que se encendió el coche.

– Un mensaje de tipo twist con la velocidad lineal del coche.

Los dos parámetros que permiten configurar el nodo son:

– baud: la tasa de baudios usada para la comunicación con el móduloArduino. Por defecto, 500000.

– port: el dispositivo Linux utilizado para las comunicaciones con el móduloArduino. Por defecto, /dev/ttyArduino.

Figura 4.2: Estructura del nodo serial_node



odometry_publisherEste nodo utiliza la información retroalimentada que le proporciona serial_nodey genera un mensaje de odometría con la estimación de posición del cocherespecto a la inicial dónde se encendió el coche, y también las velocidadeslineales y angulares del coche. Los parámetros que permiten configurar el cocheson:

– initial_x: posición inicial en el eje X del mensaje de odometría expresadaen metros. Por defecto, 0.

– initial_y: posición inicial en el eje Y del mensaje de odometría expresadaen metros. Por defecto, 0.

– initial_yaw: orientación inicial del ángulo de guiñada del mensaje deodometría expresada en radianes.

– file_name: el directorio y el nombre del archivo de calibración generadopor los procedimientos de calibración de la dirección.

Figura 4.3: Estructura del nodo odometry_publisher

rplidarNode Este nodo interactúa con el sensor RPLidar y proporciona unescaneo láser con las distancias de todos los obstáculos circundantes. Especialatención a las partes del coche que son detectadas y deben ser ignoradas.

Figura 4.4: Estructura del nodo rplidarNode



auto_stopNodo empleado para filtrar las velocidades lineales del coche en caso de queexista un obstáculo cercano y detenerlo. Para detectar los posibles obstáculosse emplean los datos proporcionados por el nodo rplidarNode. Los parámetrospara la configuración del nodo son:

– angle_back: ángulo medido en grados de detección del obstáculo cuandoel coche se mueve hacia atrás. Por defecto, 35.

– angle_front: ángulo medido en grados de detección del obstáculo cuandoel coche se mueve hacia adelante. Por defecto, 35.

– brake_distance: distancia mínima en metros para detener el coche. Pordefecto, 0.4.

– brake_distance_base_on_speed: determina si usar o no la velocidad realdel coche para cambiar dinámicamente la distancia de frenado.

Figura 4.5: Estructura del nodo auto_stop

usb_camEste nodo interactúa con la cámara fish-eye superior y proporciona tanto laimagen como un mensaje adicional con la información de calibración de lacámara. La cámara deberá estar calibrada para que este mensaje sea válido.

Figura 4.6: Estructura del nodo usb_cam



app/cameraEste nodo interactúa con la cámara frontal y proporciona la nube de puntos conla información de la profundidad, la imagen raw, las imágenes rectificadas tantoen escala de grises como en color, además de un mensaje con la información decalibración de la cámara.

Figura 4.7: Estructura del nodo app/camera

4.2. Estructura de software desarrollada

Como se ha comentado previamente, el sistema del coche autónomo se divideen diferentes subsistemas con funciones específicas y que, en conjunto, permiten alcoche superar todas las pruebas de la competición.

El subsistema principal del coche es el supervisor, encargado de tomar las decisio-nes adecuadas y estando condicionado por la información que el resto de subsistemastomen del entorno. De esta forma se coloca al supervisor como subsistema central,con la estructura en torno a él 4.8.

La descripción de los subistemas que integran el coche se resumen a continuación:

– Localización: subsistema que emplea una fusión sensorial con la informaciónaportada por la odometría, a través del encoder del motor y la IMU, y por elsistema de localización Visual GPS mediante la cámara fish-eye situada en laparte superior del coche.

– Detección de líneas: a partir de la imagen tomada por la cámara delanteradel coche se consigue una perspectiva de las líneas de carretera interpretablepor el coche mediante la manipulación de dicha imagen y el posterior análisismatemático.

– Detección de señales: a partir de la imagen tomada por la cámara delantera delcoche se detectan los códigos AR correspondientes a las señales y los coloresde los indicadores luminosos cuando corresponda.



Figura 4.8: Estructura de software desarrollada

– Detección de obstáculos: a través del LIDAR situado en el centro del coche selogra una detección de los obstáculos que rodean al coche, evitando el choquecon los mismos y sirviendo de apoyo en las maniobras de aparcamiento yadelantamiento.

– Supervisor: subsistema principal del coche, encargado de coordinar la informa-ción recibida y mandar las órdenes al resto de subsistemas.

– Parking: subsistema dedicado exclusivamente a la maniobra de aparcamiento,dada la dificultad que la misma presenta.

Se desarrolla además un mapa topológico del circuito, que representa las tipos detramo (curva, recta, intersección, etc.) con la posición de los mismos y los nexos conel resto de tramos. Su función es almacenar la posible ruta a seguir por le coche ycomunicarse con el supervisor para servir de apoyo al sistema de localización.

Los subsistemas de localización y parking fueron desarrollados por Victor Jímenez;los subsistemas de detección de obstáculos y el supervisor por Victor Sánchez; y elseguimiento de líneas y la detección de señales serán el objeto del presente trabajo.

Se muestra la estructura del software desarrollado para el presente trabajo, siendolos nodos de detección de señales deteccion_senales y del seguimiento de lineaslineas_ampliadas 4.9.

El nodo de la cámara app/camera proporciona las imágenes que posteriormente seinterpretan en cada uno de los nodos a través del topic /rgb/image_raw/compressed.

La comunicación entre el supervisor y la detección de líneas está condicionadapor el estado que se manda en el topic del mismo nombre. Los posibles estados semuestran en la tabla 4.1, y denotan las posibles situaciones en las que puede hallarel coche en los desafíos.



Figura 4.9: Estructura de software desarrollada

Estados de

circulación

Estados de

adelantamiento

Estados de

aparcamiento

Apagado 0 Seguir coche 9 Buscar aparcamiento 20

Parar 1 Iniciar adelantamiento 10 Aparcar 21

Seguir recto 2 Alinear izquierda 11 Aparcar 22

Curva 3 Adelantar 12

Navegar rotonda 4 Volver derecha 13

Previo rotonda 41 Alinear derecha 14

Salida rotonda 42

Previo intersección 5

Intersección izquierda 51

Intersección derecha 52

Tabla 4.1: Estados del topic /estado



Los estados de circulación representan situaciones de navegación por el circuito,a los que se pueden acceder al detectar señales o en función de la zona en la que seencuentre el vehículo.

Los estados de adelantamiento corresponden, como indica su división en las corres-pondientes maniobras, a las distintas etapas en las que se divide un adelantamiento.

Los estados de aparcamiento corresponden a las etapas desde que se detectala identifica la señal de parking y se detecta que se puede aparcar, hasta que secompleta la maniobra.


5. Detección de señales y semáforos

5.1. Introducción

En el presente capítulo se explicarán los conceptos y desarrollo del trabajoreferente a la detección y clasificación de señales y semáforos. Como se ha explicado,existen distintos tipos de señales que el coche se puede encontrar en su recorrido,caracterizadas por un código AR que distingue a las señales entre sí. Además, aquellasque se corresponden con los semáforos de avance o parada y parking, se complementancon un testigo luminoso que indica su estado.

La herramienta empleada para la detección de los códigos de las señales es elpaquete de ROS ar_track_alvar, basado en el entorno de desarrollo ALVAR, quees una biblioteca de detección y seguimiento de etiquetas AR de código abierto.Mediante este paquete es posible identificar y calcular la posición de los marcadoresAR visibles.

Antes de comenzar con el trabajo de la detección como tal, se acordó entre elnodo supervisor y el nodo de la detección de señales el tipo de mensaje que se iba apublicar en el topic, de forma que fuera sencillo para el supervisor interpretarlo alsuscribirse al topic, y para la detección de señales publicarlo en dicho topic. Además, alo largo del trascurso del trabajo, el nodo encargado del parking parking_2018_nodese vio en la necesidad de conocer información acerca de las señales como apoyo enla maniobra de aparcamiento. Así, el nodo deteccion_senales publica en el topic/senales un vector de tipo std_msgs::Uint8MultiArray de hasta 10 elementos. Elprimero corresponde a número de señales cercanas que se detectan y está limitadoa 3. Los 9 siguientes elementos se dividen en tres grupos, dentro de los cuales seencuentran el tipo de señal detectado, el estado del indicador luminoso que acompañaa la señal en caso de tenerlo y la distancia a la cual se encuentra dicha señal. De estaforma, el mensaje que le llega a los nodos seat_supervisor y parking_2018_node esfácilmente interpretable 5.1.

La elección de un tipo de dato entero de 8 bits se debe al menor consumo dememoria que se hace durante la ejecución de los programas y mayor facilidad delectura por parte de quién recibe la información. Será de importancia mayor la tasade refresco o actualización de la información, ya que ignorar una señal o un semáforopuede ser fatal para los resultados.

51

CAPÍTULO 5. DETECCIÓN DE SEÑALES Y SEMÁFOROS

Figura 5.1: Nodos implicados en la comunicación de las señales

Señales

0 Por defecto/Sin detección

1 Semáforo verde/rojo

2 Semáforo parking

3 Giro derecha

4 Giro izquierda

5 Seguir recto

6 Rotonda

7 STOP

Tabla 5.1: ID de las señales

Estados


1 Verde

2 Rojo

3 Encendido

4 Apagado

Tabla 5.2: Estado de las señales



En los algoritmos de clasificación que se comentarán más adelante se explicará laprioridad que pueda existir entre los tipos de señales y los criterios que se establecenpara su detección.

Haber ordenado de esta forma las señales se fundamenta en el orden seguido parala distinción de los diferentes tipos de códigos AR, siendo que sus identificadores oID están ordenados de una forma muy similar a la arriba expuesta. Las imágenescorrespondientes a los identificadores AR se almacenan en una de las carpetas delespacio de trabajo. En la tabla que se muestra a continuación se relacionan losindicadores AR con su identificador ID y con la señal correspondiente.

Identificadores ID


1 Semóforo verde/rojo

2 Semáforo parking

3 Giro derecha

4 Giro izquierda

5 Seguir recto

6 Rotonda

7 STOP

Tabla 5.3: Identificadores ID de las señales



5.2. Trabajo previo

Antes de comenzar con la explicación del método de detección y clasificación delos distintos tipos de señales fue necesario una serie de preparaciones. En primer lugar,se determinaron experimentalmente los umbrales dentro de los cuales se encuentranlos colores proyectados los indicadores luminosos de los semáforos.

Los umbrales de detección de colores tienen un modelo de color HSV, siglas que secorresponden con matiz, saturación y brillo o valor. Se trata de una transformaciónno lineal del espacio de color RGB muy utilizada en visión por computador.

Figura 5.2: Modelo de color HSV

La herramienta utilizada para la detección de rangos de los colores fue la aplicaciónde MATLAB colorThresholder, que permite cargar ficheros de imagen y manipularlas componentes de color, creando una máscara de segmentación para una imagenen color. Se representa como ejemplo la segmentación del color rojo en una imagendel simulador. Como se observa, a partir de la imagen original se modifican losvalores hasta que únicamente el color rojo sea visible. Se realiza el proceso con variasimágenes tomadas, teniendo de esta forma rangos de valores más precisos.

(a) Imagen de las señales en el simulador(b) Aplicación de la máscara de color rojo

Figura 5.3: Imagen del simulador al aplicar la máscara de color rojo



Con esta herramienta se consiguen valores normalizados para H, S y V en elintervalo [0,1]. Para convertirlos a valores de OpenCV se tiene que multiplicar laH por 180, y la S y V por 255. De esta forma, los resultados ya son compatiblescon las funciones de OpenCV. Además, para el color rojo se tuvieron que definirdos umbrales y combinarlos, ya que este color se encuentra justo en el límite. Semuestran a continuación los rangos de valores para el simulador en formato (MínimoH – Máximo H, Mínimo S – Máximo S, Mínimo V – Máximo V).

UmbralValores

Ejemplo imagenH S V

Umbral Rojo 1Mínimo 0.000 0.215 0.215

Máximo 0.012 0.255 0.255


Máximo 0.170 0.255 0.255

Umbral AzulMínimo 0.090 0.057 0.100

Máximo 0.120 0.255 0.255

Umbral VerdeMínimo 0.040 0.025 0.100

Máximo 0.080 0.255 0.255

Tabla 5.4: Umbrales de color HSV en el simulador

Para realizar el mismo proceso, pero en el coche real es necesario tener en cuentauna circunstancia que se ha corregido este año debido a problemas de interpretaciónde los colores el año pasado. Las luces de los semáforos presentan el mismo problemaque los paneles de luz del sistema Visual GPS, saturan el sensor de la cámara. Eneste caso, reducir el tiempo de exposición de la cámara no es una opción porque lacámara debe utilizarse también para detectar las líneas de la carretera y necesita unmínimo de exposición. La solución será añadir un filtro en la salida de la fuente deluz. A través de un fichero STL se generó la pieza en 3D necesaria para acoplarla alsemáforo durante los días de competición. Sin embargo, durante la preparación en elCAR con el coche real se empleó un filtro manual realizado con papel y plástico queconsiguiese el efecto de visualizar correctamente el color de los semáforos sin saturarel color por los LED. En la siguiente imagen se puede ver la diferencia entre la luzcon y sin filtro.



Figura 5.4: Filtro de luz empleado en la competición

De esta forma, ya se podría realizar el proceso de detección de los umbralesde los colores para el coche real. Debido a la incertidumbre de las condicioneslumínicas y la posible variación del color en función de la distancia entre el coche yla señal, se realizaron varias muestras de imágenes, posteriormente analizadas concolorThresholder para determinar con exactitud los umbrales de los colores. De entretodos los valores obtenidos se coge el menor valor de los mínimos y el mayor valor delos máximos para cada H, S y V. Los valores mostrados en las tablas siguientes sonlos normalizados en el intervalo [0,1]. Posteriormente se muestran los umbrales enformato HSV de OpenCV.

Figura 5.5: Muestras de imágenes del semáforo azul



AZUL H S V

Imagen1Mínimo 0.521 0.397 0.411

Máximo 0.707 1.000 1.000

Imagen2Mínimo 0.514 0.362 0.362

Máximo 0.689 1.000 1.000

Imagen3Mínimo 0.522 0.383 0.387

Máximo 0.691 1.000 1.000

Imagen4Mínimo 0.552 0.291 0.434

Máximo 0.722 1.000 1.000

Imagen5Mínimo 0.569 0.462 0.307

Máximo 0.725 1.000 1.000


Máximo 0.725 1.000 1.000

Tabla 5.5: Medidas de los umbrales para el color azul real

Figura 5.6: Muestras de imágenes del semáforo rojo



ROJO1 H S V

Imagen1Mínimo 0.006 0.411 0.349

Máximo 0.069 1.000 1.000

Imagen2Mínimo 0.004 0.401 0.350

Máximo 0.070 1.000 1.000

Imagen3Mínimo 0.002 0.422 0.343

Máximo 0.071 1.000 1.000

Imagen4Mínimo 0.004 0.402 0.352

Máximo 0.074 1.000 1.000

Imagen5Mínimo 0.005 0.403 0.339

Máximo 0.070 1.000 1.000

Umbral Rojo1Mínimo 0.002 0.401 0.352

Máximo 0.074 1.000 1.000

Tabla 5.6: Medidas de los umbrales para el color rojo 1 real

ROJO2 H S V

Imagen1Mínimo 0.901 0.439 0.454

Máximo 0.979 1.000 1.000

Imagen2Mínimo 0.879 0.422 0.429

Máximo 0.965 1.000 1.000

Imagen3Mínimo 0.859 0.490 0.434

Máximo 0.976 1.000 1.000

Imagen4Mínimo 0.867 0.432 0.429

Máximo 0.957 1.000 1.000

Imagen5Mínimo 0.875 0.449 0.438

Máximo 0.973 1.000 1.000

Umbral Rojo2Mínimo 0.875 0.422 0.429

Máximo 0.074 1.000 1.000

Tabla 5.7: Medidas de los umbrales para el color rojo 2 real



Figura 5.7: Muestras de imágenes del semáforo verde

VERDE H S V

Imagen1Mínimo 0.233 0.108 0.446

Máximo 0.493 1.000 1.000

Imagen20.213 0.108 0.389

Máximo 0.461 1.000 1.000

Imagen3Mínimo 0.216 0.220 0.324

Máximo 0.454 1.000 1.000

Imagen4Mínimo 0.195 0.181 0.467

Máximo 0.442 1.000 1.000

Imagen5Mínimo 0.219 0.275 0.226

Máximo 0.428 1.000 1.000


Máximo 0.493 1.000 1.000

Tabla 5.8: Medidas de los umbrales para el color verde real



UmbralValores

Ejemplo de imagenH S V

Umbral Rojo 1Mínimo 0 103 90

Máximo 13 255 255

Umbral Rojo 2Mínimo 158 108 110

Máximo 177 255 255

Umbral AzulMínimo 92 74 78

Máximo 131 255 255

Umbral VerdeMínimo 35 27 57

Máximo 89 255 255

Tabla 5.9: Umbrales de los colores reales

Las imágenes binarizadas que se obtienen al aplicar estos umbrales nos permitendetectar la zona con el color que buscamos. Se muestran a continuación la comparaciónentre la imagen tomada por la cámara y la imagen con máscara para detectar sólo elcolor buscado en cada caso.

(a) Imagen de las señal azul real (b) Aplicación de la máscara de color azul

Figura 5.8: Imagen real al aplicar la máscara de color azul



(a) Imagen de la señal verde real (b) Aplicación de la máscara de color verde

Figura 5.9: Imagen real al aplicar la máscara de color verde

(a) Imagen de la señal roja real (b) Aplicación de la máscara de color rojo

Figura 5.10: Imagen reales al aplicar las máscaras de color



5.3. Algoritmos de detección y clasificación

A partir de la imagen obtenida se comienza detectando la posición y el identificadorID de los marcadores AR detectados en la imagen. Al ejecutar la detección de AR,los datos correspondientes a cada uno de ellos quedan almacenados y se realiza elmismo procedimiento para cada uno de los detectados. La detección proporciona laposición en función de un vector de 3 componentes que representa la traslación y unvector de 4 componentes en forma de cuaternio que representa la orientación. Dichaposición es relativa al sistema de referencia de salida y será necesario convertirla alsistema de referencia de la cámara.

La representación del cuaternio en ROS sigue las componentes [x, y, z, w]. Sedebe prestar atención a la componente w en último lugar, ya que la presentaciónmatemática la coloca en primer lugar en el vector. Para representar la orientaciónmediante un cuaternio se debe tener en cuenta el ángulo de rotación θ alrededor deun eje definido por un vector unitario ~u.

~q =

[

ux · sin

(

θ

2

)

, uy · sin

(

θ

2

)

, uz · sin

(

θ

2

)

, cos

(

θ

2

)]

(5.1)

~q = cos

(

θ

2

)

+[

ux~i + uy

~j + uz~k]

· sin

(

θ

2

)

(5.2)

Más adelante se tratará la clasificación de las señales detectadas. Ahora, una vezestablecida la posición del marcador AR se debe establecer la posición del indicadorluminoso, en aquellas señales que lo tengan adherido, para conocer el estado en el quese encuentra. Entra en juego el concepto de región de interés o ROI, por sus siglasen inglés region of interest, llamado así al sector de la imagen que se aísla para unestudio particular.A partir de la posición del marcador se pueden conocer la posiciónen coordenadas de la imagen de las esquinas del mismo. Dichas se almacenan enun vector de 4 componentes, siendo el primer elemento del vector la posición de laesquina inferior izquierda y sigue la secuencia en sentido opuesto a las agujas delreloj 5.11.

Figura 5.11: Numeración de las esquinas del marcador



Para facilitar el trabajo con las distancias conocidas de los marcadores y surepresentación en la imagen tomada por la cámara se calcula la relación entre lospíxeles de la imagen y la distancia en milímetros de la realidad. Teniendo en cuentaque el ancho del marcador son 50 milímetros en la realidad, como se representa enla figura correspondiente a las señales, se relaciona esta distancia con la distanciaen píxeles entre la coordenada X de las dos esquinas inferiores del marcador en laimagen. Para una mayor precisión, esta relación corresponderá al eje X, y para el ejeY se hará lo mismo, pero con la coordenada Y de las esquinas superior izquierda einferior izquierda.

relacionX(pixeles

milímetros) =|markerCorner [0] .x−markerCorner [1] .x|

50(5.3)

relacionY (pixeles

milímetros) =|markerCorner [0] .y −markerCorner [3] .y|

50(5.4)

Además, se ha tenido en cuenta la posible desviación respecto a la figura ideal decuadrado que pueda presentar el marcador. Para ello, se ha calculado la pendiente dedistorsión en el eje X que pueda presentar la imagen, mediante el triángulo rectánguloque se presenta a continuación. Con esta medida se podrá encuadrar con más precisiónla región donde se encuentra la luz. Se realiza un proceso similar para la pendientede desviación en el eje Y, aunque en este caso el valor sea significativamente menorrespecto al eje X.

Figura 5.12: Esquema de la distorsión en las medidas

distorsionX = tan(α) =|markerCorner [0] .x−markerCorner [3] .x||markerCorner [0] .y −markerCorner [3] .y| (5.5)

distorsionX = tan(β) =|markerCorner [0] .y −markerCorner [1] .y||markerCorner [0] .x−markerCorner [1] .x| (5.6)



A partir de las medidas que se conocen de las señales se puede establecer lazona de la región de interés para el estudio del color proyectado. Para evitar falsasindicaciones no se hará sobre el rectángulo de 50x25 milímetros. Se toma comoesquina superior izquierda del rectángulo un punto situado a +15 mm en distanciareal y a -79.5 mm de la esquina inferior izquierda del marcador AR. Se aplicanademás las correspondientes correcciones en las distancias con las pendientes dedesviación. Los otros parámetros necesarios para el constructor son el ancho, que setoma de 30 mm en vez de 50 mm, y el largo, que se toma de 15 mm en vez de 25mm. Se adjunta a continuación un esquema que complementa la explicación, ademásde un breve recordatorio con las medidas más significativas de las señales 5.13.

(a) Posición de la luz respecto al AR (b) Dimensiones de las señales

Figura 5.13: Determinación de la región de interés del color

ROIX = markerCorner [0] .x + 15 · relacionX + tan(α) · 84, 5 · relacionX

ROIY = markerCorner [0] .y − 79,5 · relacionY + tan(β) · 50 · relacionY(5.7)

Una vez definida la región de interés, se procede a detectar el color del semáforo.Se presenta el caso de los semáforos verde/rojo. A partir de la región delimitada porel punto (ROY.x y ROY.y), un ancho de 30 mm y un largo de 15 mm de la imagenen formato de color HSV se aplica la función de OpenCV inRange. Mediante estafunción permite obtener una imagen binaria a partir de una imagen a color, filtrandoa partir de los valores minimos y máximos del filtro de colores. En el caso de lasimágenes tratadas, al ser de 3 canales, la función inRange aplica la lógica siguiente:

dst =

lowerb(I)0 ≤ src(I)0 ≤ upperb(I)0



(5.8)



Se muestra a continuación un ejemplo en el que se ha descuadrado la zona ROIa propósito para ver cómo intepreta el rojo como un 1 al binarizar, y lo representacomo blanco, y cómo el resto de colores fuera de rango los interpreta como 0 y losrepresenta como negro. En el caso del color rojo, al haber dos intervalos, se aplica lafunción inRange para cada uno de ellos y después se emplea la función addWeighted,que calcula la suma ponderada de las dos matrices que se obtienen.

(a) Imagen de ROI rojo en el simulador (b) Imagen binarizada

Figura 5.14: Binarización de la región de interés para el color rojo en el simulador

Una vez se obtiene una matriz con valores binarios se obtienen dos matrices, unapara el color rojo y otra para el color verde, y mediante la función countNonZero seobtiene el número decimal de valores distintos de cero. Para fijarlo en el intervalo[0, 1] se divide entre el tamaño de la región de interés. Comparando el valor para elverde y el rojo se determina el color del semáforo. Sin embargo, para evitar lecturaserróneas, se exige que dichos valores sean mayores que 0.7, lo que implica que debehaber más de un 70 % de píxeles en la imagen del color que se precisa.

El último detalle que se comentará antes de presentar el algoritmo de detección yclasificación es el filtro de las señales observadas en función de la distancia a la quese encuentren del coche, calculándose la distancia de la forma habitual a partir delas coordenadas del vector obtenido en la detección de cada marcador.

distancia =√

(poseMarker [0])2 + (poseMarker [1])2 + (poseMarker [2])2 (5.9)

El valor de la distancia mínima para una detección válida se calculó experimen-talmente para el coche, estableciendo un valor de 250 centímetros. Además, paragarantizar la exactitud de las distancias a las señales medidas desde el coche y ladistancia real correspondiente, se realizaron varias medidas para comprobar el errorpresentado.

εr =|valorMedido− valorReal|

valorReal(5.10)

Como se ha comentado previamente, se tendrán en cuenta como máximo 3 tiposde señales, ya que se considera que es el número máximo de circunstancias queel coche deba manejar, teniendo en cuenta que habrá situaciones en las que seencuentren dos señales juntas, como un stop junto a una señal de giro. Una vez que



se actualiza el vector que se publica en /senales y ya no quedan más señales o, siquedan, ya se han hecho 3 iteraciones, se publica el mensaje.

En la figura que se muestra a continuación 5.15 se presenta el algoritmo completoempleado para la detección de señales y la publicación de los datos obtenidos en eltopic /senales.



Figura 5.15: Algoritmo de detección de las señales



A modo de ejemplo del mensaje publicado en /senales se muestra una captura depantalla con la vista de la cámara y, mediante rostopic echo, el vector que se envía aseat_supervisor. En ella se puede ver cómo el número de señales es 2, la más cercanaes Señal1=1 (semáforo) y está Estado1=2 (rojo), y la siguiente es Señal2=2 (parking)y está Estado2=3 (encendido). Además, se muestran las respectivas distancias encentímetros y los elementos del vector restantes como ceros 5.16.

(a) Señales en el simulador

(b) Mensaje publicado

Figura 5.16: Publicación de mensaje en el topic /senales al ser detectadas

Con este algoritmo únicamente enviamos los datos a seat_supervisor, pero en elcódigo se han ido incluyendo algunas funciones que permiten la visualización de ladetección de señales. A continuación, se muestra la identificación de dos señales, unade semáforo y otra de parking, junto a sus correspondientes indicadores luminosos.Los polígonos y los textos que se muestran se han generado con la función polylinesy putText de OpenCV 5.17. Además de ser una ayuda en el desarrollo del programa,estas imágenes formaron parte de los entregables de la competición.

(a) Semáforo rojo y parking encendido (b) Semáforo verde y parking apagado

Figura 5.17: Visualización de las señales en el simulador con OpenCV



Para el caso de la detección de señales con el coche real se muestran las deteccionesdel semáforo , identificando también el color. Se puede comprobar que la detecciónes posible en condiciones de luz favorables y aquellas más complicadas 5.19.

(a) Semáforo verde (b) Semáforo rojo

Figura 5.18: Imagen real al aplicar la máscara de color verde

(a) Giro derecha (b) Parking encendido

Figura 5.19: Detección de señales con el coche real



5.4. Problemas encontrados

La detección de los marcadores AR de las señales así como la identificación delos colores presentó resultados óptimos durante la etapa de pruebas en la pista deensayos. Sin embargo, en la competición no se obtuvieron los mismos resultados. Enprimer lugar, se tuvieron que reajustar los umbrales de los colores rojo, verde y azula los indicadores que la organización colocó en la pista. A pesar de que el filtro quese colocó para evitar la sobreexposición de los colores no era adecuado, los colores seconsiguieron detectar satisfactoriamente.

El principal problema encontrado fueron las detecciones de los códigos AR,motivado por la falta de iluminación y las variaciones en las dimensiones de losmismos respecto a lo establecido en la normativa. Habiendo ajustado en el códigodel programa la solución a las dimensiones y comprobando a simple vista que ladetección debería tener lugar por la claridad con la que se veían los marcadores, secontinuaba por no detectar los AR, por lo que se debía trabajar con la imagen parasolucionar el problema.

Figura 5.20: Semáforo en la competición

Para disminuir el coste computacional que implica el proceso, ya que la existenciade retardos en la detección puede implicar saltarse señales, se reducirá el área dela imagen a tratar. Para ello, a partir de una imagen de 640x480 píxeles se tomaráun rectángulo de tamaño 640x220 píxeles desde la ordenada y = 60, zona dóndeprevisiblemente se detectan las señales cercanas y a una cierta distancia 5.21.



Figura 5.21: Área de trabajo en la imagen

El siguiente paso será convertir la imagen recortada a escala de grises. A partir dela misma el objetivo será mejorar el contraste de la imagen, de forma que se puedandistinguir mejor los marcadores.

Figura 5.22: Imagen en escala de grises

A partir de la imagen en escala de grises se extrae el histograma o distribucióngráfica de la intensidad de píxeles de la imagen. Se programa una aplicación enOpenCV que se apoya en la función calcHist, la cual obtiene un vector con los valoresde cada intensidad. Su muestra también el histograma calculado con MATLABmediante imhist 5.23.



Figura 5.23: Histograma de la imagen

Lo que se va a hacer a partir del histograma es extender el rango dónde se sitúan lamayor parte de las intensidades mediante una ecualización que mapea la distribucióndada y la lleva a otra distribución, una más amplia y uniforme de los valores deintensidad. Dicha ecualización se lleva a cabo mediante la función de distribuciónacumulativa, que se define como:

H ′(i) =∑

0≤j<i

H(j)

Estableciendo el valor máximo de 255 para H ′(i), valor máximo para las intensi-dades en la imagen. Por último, se emplea un remapeado para obtener la intensidadde valores de la imagen ecualizada.

equalized(x, y) = H ′(src(x, y))

La imagen ecualizada que se obtiene es la siguiente

Figura 5.24: Imagen ecualizada

Además, se muestra el histograma de la imagen ecualizada, dónde se observaque los valores de intensidad muestran una distribución más uniforme sobre los quepresentaban mayor densidad 5.25.




Como se puede apreciar en la imagen, el contraste obtenido es muy bueno, sinembargo siguen sin poder detectarse los marcadores AR, principalmente por la zonaoscura en la parte superior del marcador creado por la sombra proyectada por elsaliente dónde se alojan los indicadores luminosos.

El proceso que se va a seguir parte de la imagen en escala de grises y se pretendeaplicar mediante código la operación de corrección gamma que se lleva a cabo en losprogramas de edición fotográfica. Con ello, se busca aumentar o disminuir el brillode una imagen mediante la corrección de gamma, que evite la alteración entre laimagen captada por la cámara y se compense para mostrar una imagen inalterada yreal. La corrección de gamma suele estar definida de forma no lineal mediante unaley de potencias

Vout = AVinγ

Donde Vout es el valor de luminancia de salida, Vin es el valor de entrada o valorreal de luminancia y A es generalmente una constante de valor 1.

Para aplicar la corrección gamma a la imagen emplearemos un mapa de color deuna columna, ya que la imagen tiene un único canal, a través de una lookup table oLUT que guardará un vector de 256x1 para aplicarlo sobre la imagen. El valor decada elemento del vector será

vi =(

i

255

)γ

· 255



De esta forma, los elementos de la matriz correspondiente a la imagen modificadaserán valores de la lookup table. Se realiza el proceso con la función LUT, que procesacada elemento de la matriz de entrada src de la forma

dst(I)← lut(src(I))

La imagen que se obtiene con la correción gamma es la siguiente:

Figura 5.26: Imagen con corrección gamma

Se adjunta además el histograma de la imagen con la correción gamma 5.27,comprobando que se han normalizado los valores de intensidad y se han llevado auna escala mayor:




A dicha imagen se le aplica la ecualización comentada previamente, a partir delhistograma de la imagen con corrección gamma, obteniendo como resultado:

Figura 5.28: Imagen con corrección gamma y ecualización

A partir de la imagen obtenida es posible detectar los marcadores AR y el siguientepaso será proporcionar una imagen en formato HSV para permitir la detección delos colores. Por tanto, una vez que el programa detecta el marcador, se convierte laimagen a formato HSV para detectar el color del indicador.

Los valores de los umbrales de color empleados en la competición se muestran acontinuación

UmbralValores

H S V


Máximo 0.074 1.000 1.000


Máximo 0.994 1.000 1.000


Máximo 0.775 1.000 1.000


Máximo 0.506 1.000 1.000

Tabla 5.10: Umbrales de los colores en la competición

Por último se muestran algunos ejemplos de detecciones de señales una vezcompletados los cambios en el código. Se muestran claramente las zonas que delimitanel marcador AR, demostrando que se detecta, además de la zona correspondiente alindicador luminoso en el caso de los semáforos y parking.



Figura 5.29: Detección del semáforo verde

Figura 5.30: Detección del parking encendido

Figura 5.31: Detección de la rotonda

Figura 5.32: Detección del giro a la derecha


6. Detección y seguimiento de líneas

6.1. Introducción

En el presente capítulo se desarrolla el modelo de detección y seguimiento delas líneas de carril de la carretera. El objetivo es obtener una visión más ampliay permitir una mayor capacidad de predicción y anticipación del coche que con elmodelo seguido hasta ahora, que limitaba la visión a un rango cercano.

El nodo desarrollado es lineas_ampliadas, el cual obtiene la imagen suscribiendosedirectamente al topic de la imagen tomada por la cámara y realiza el procesado einterpretación. El mensaje que transmite lineas_ampliadas es un vector de cincoelementos de tipo std_msgs::Float32MultiArray en el topic /polinomio. Los tresprimeros elementos (p0, p1 y p2 ) representan los coeficientes de la aproximaciónpolinomial que se comentará más adelante y errorCabeceo y errorDeriva representanel error de cabeceo y error de deriva necesarios para el control del coche.

Los nodos implicados en la comunicación con lineas_ampliadas son seat_supervisor,centro de mando del coche, control_coche_node para llevar a cabo el control delcoche y parking_2018_node, al cual se le asiste con el error de deriva para llevar acabo la maniobra de aparcamiento 6.1.

Figura 6.1: Nodos implicados en la comunicación de las líneas

77

CAPÍTULO 6. DETECCIÓN Y SEGUIMIENTO DE LÍNEAS

6.2. Herramientas empleadas

Los algoritmos que se explicarán posteriormente para la detección y el seguimientode carriles por parte del coche requiere una serie de herramientas que permitaninterpretar dichas líneas para posteriormente tratarlas matemáticamente. En elpresente apartado se buscar introducir las herramientas que permiten un tratamientode la imagen óptimo.

A partir de la imagen a color obtenida con la cámara, el primer paso seráconvertir a escala de grises la imagen. Se utiliza la función de OpenCV cvtColor yaexplicada anteriormente. En este caso, el parámetro code será CV_BGR2GRAY. Acontinuación, se muestra esta primera transformación de la imagen con una capturaobtenida con la cámara del coche en la pista de pruebas construida 6.2.

(a) Imagen original tomada por la cámara (b) Imagen en escala de grises

Figura 6.2: Conversión a escala de grises de la imagen

A continuación, es necesario corregir la distorsión que pueda existir en la imagendebido a la propia cámara, transformado dicha imagen para compensar la distorsión dela lente. Es cierto que los problemas de distorsión de imágenes están más relacionadoscon cámaras que tengan un campo de visión amplio, pero se realiza en este casotambién para mejorar los resultados. La matriz intrínseca de la cámara k y el vectorcon los coeficientes de distorsión d son obtenidos con el método que se explicará másadelante mediante el tablero de calibración y son utilizados en la función undistortparacorregir la distorsión.

k =

fx 0 cx

0 fy cy

0 0 1

d = [d0, d1, ..., dn−1] n = 4, 5, 8, 12, 14 (6.1)

En la imagen inferior se muestra la imagen obtenida anteriormente en escala degrises antes de aplicar undistort y después de aplicar la función. Como se puedeobservar las diferencias son prácticamente inapreciables 6.3.



(a) Imagen inicial en escala de grises (b) Imagen con la distorsión corregida

Figura 6.3: Correción de la distorsión de la imagen

Los parámetros de la función undistort son:

– InputArray src: imagen de entrada distorsionada

– OutputArray dst: imagen de salida corregida con el mismo tamaño que laimagen de entrada

– InputArray cameraMatrix: matriz intrínseca de la cámara k

– InputArray distCoeffs: vector de coeficientes de distorsión d

El siguiente paso será conseguir una perspectiva adecuada de dicha imagen,de forma que la orientación y posición de las líneas de carretera permitan unainterpretación adecuada y manteniendo un paralelismo adecuado. Para cumplireste cometido se emplean las funciones de OpenCV getPerspectiveTransform ywarpPerspective. Con la función getPerspectiveTrasnform(InputArray src, InputArraydst) se obtiene la matriz de transformación 3x3 a partir de las coordenadas de 4puntos en la imagen de entrada y 4 puntos en la imagen de salida.

tixi′

tiyi′

ti

= M ·

xi

yi

1

dst(i) = (xi

′, yi′) src(i) = (xi, yi) i = 0, 1, 2, 3, ... (6.2)

Los parámetros de la función getPerspectiveTransform son:

– InputArray src: coordenadas de los vértices del cuadrángulo en la imagen deentrada.

– InputArray dst: coordenadas de los correspondientes vértices del cuadránguloen la imagen de destino.



En la imagen inferior se muestra una captura obtenida con la cámara del coche,en la que aparece una toma de la carretera 6.4. En la imagen derecha se muestra encolor rojo el polígono en la imagen de entrada que se va a proyectar y en rojo, laposición que ocupará en la imagen de salida

(a) Puntos del IPM en la imagen original (b) Puntos del IPM en la imagen proyectada

Figura 6.4: Proyección del rectángulo del IPM

Una vez obtenida la matriz de transformación, se aplica la función warpPerspective,la cual aplica una transformación de perspectiva a la imagen. Dicha transformaciónse produce de la forma:

dst(x, y) = src(M11x + M12y + M13

M31x + M32y + M33

,M21x + M22y + M23

M31x + M32y + M33

) (6.3)

Los parámetros de la función warpPerspective son:

– InputArray src: imagen de entrada.

– OutputArray dst: imagen de salida con el mismo tamaño dsize que src.

– InputArray M: matriz de transformación 3x3.

– Size dsize: tamaño de la imagen de salida

– int flags: combinación de los métodos de interpolación. En este caso se empleaINTER_LINEAR por defecto.

– int borderMode: método de extrapolación de los píxeles. No es necesario incluireste parámetro, pero, en caso de incluirlo, por defecto es BORDER_CONSTANT.

– Scalar borderValue: valor usado en caso de usar una constante de borde. Pordefecto es 0.

A partir de la imagen mostrada anteriormente de las líneas de carretera tomadacon la cámara, se muestra la imagen que se obtiene al aplicar warpPerspective unavez obtenida la matriz de transformación con getPerspectiveTransform 6.5.



(a) Imagen inicial en escala de grises (b) Imagen proyectada

Figura 6.5: Transformación de perspectiva de la carretera

Con objeto de suavizar la imagen y permitir una mejorar distinción de las líneasen pasos posteriores, se aplica un filtrado [14]. Los filtros que se ha probado seexplican a continuación en el siguiente apartado.

6.2.1. Filtros de imagen

Filtro gaussiano

Filtro de paso bajo que atenúa las señales de alta frecuencia y, en el caso de imá-genes, elimina el contenido de alta frecuencia, como el ruido y los bordes, resultandoen bordes difuminados al aplicar el filtro.

La transformación aplicada a cada punto de la imagen es el producto de dosecuaciones de distribución normal de Gauss

G(x, y) =

(

1√2πσx

e−x2

2σx2

)(

1√2πσy

e−y2

2σy2

)

(6.4)

Dónde x es la distancia desde el origen al eje horizontal, y es la distancia delorigen al eje vertical y sigma es la desviación típica de la distribución de Gauss. Alaplicar la fórmula, la imagen se convierte en una superficie cuyos contornos seráncírculos concéntricos con una distribución gaussiana desde el punto central. Cadapíxel tomará el valor de la media ponderada de los píxeles vecinos. El valor originalde cada píxel recibe el mayor peso y los píxeles vecinos tendrán menor peso cuantomayor sea su distancia a dicho píxel original. De esta forma, se consigue una imagenborrosa, pero que conserva los bordes mejor que otros filtros difuminados.

Se muestra a continuación una imagen antes y después de aplicar el desenfoquegaussiano con GaussianBlur(src,dst,Size(3,3),0.5,0.5) 6.6.



(a) Imagen sin filtro aplicado (b) Filtro gaussiano

Figura 6.6: Aplicación de filtro gaussiano

El desenfoque gaussiano se aplica a través de la función de OpenCV GaussianBlur(InputArray src, OutputArray dst, Size ksize, double sigmaX, double sigmaY, intborderType) cuyos parámetros expresan:

– InputArray src: imagen de entrada.

– OutputArray dst: imagen de salida del mismo tipo y tamaño que src.

– Size ksize: tamaño del kernel gaussiano, cuyas dimensiones deben ser positivase impares.

– double sigmaX : desviación típica en el eje X.

– double sigmaY : desviación típica en el eje Y, generalmente la misma que en elX.

– int borderType: método de extrapolación de los píxeles.

Filtro de mediana

Calcula la media ponderada de todos los píxeles bajo el alcance del kernel y elpixel central será reemplazado por el dicho valor. Se trata de un filtro especialmenteefectivo en la eliminación del ruido conocido como ‘sal y pimienta’. A diferenciade otros filtros como el gaussiano, el valor del elemento central tomará un valorque previamente existiese en la imagen y no como un valor calculado que podíapreviamente no existir.

El filtro de mediana se aplica mediante la función de OpenCV medianBlur y losparámetros expresan:

– InputArray src: imagen de entrada

– OutputArray dst: imagen de salida del mismo tipo y tamaño que src



Figura 6.7: Aplicación de un filtro de mediana

– Size ksize: tamaño del kernel gaussiano, cuyas dimensiones deben ser positivase impares.

Se muestra a continuación una imagen antes y después de aplicar el filtro demediana con medianBlur(src, dst, 9) 6.8

(a) Imagen sin filtro aplicado (b) Filtro de mediana

Figura 6.8: Aplicación de filtro de mediana

Filtro bilateral

Filtro que permite eliminar el ruido de la imagen y mantener unos bordes afilados.El filtro bilateral emplea también un filtro gaussiano en el espacio, pero también leaplica uno adicional que es función de la diferencia de intensidad de los píxeles. Elfiltro gaussiano convencional sólo se asegura de que los píxeles cercanos se consideranborrosos, mientras que al tener en cuenta la diferencia de intensidad únicamente lospíxeles con una intensidad similar al píxel central se consideran borrosos. De estaforma, los bordes se conservan, ya que los píxeles en estas zonas tendrán una granvariación de intensidad.

Matemáticamente, en el filtro bilateral, el valor del píxel de salida dependerá dela suma ponderada de los píxeles vecinos:



dst(i, j) =∑

k,l f(k, l)w(i, j, k, l)∑

k,l w(i, j, k, l)(6.5)

El coeficiente de ponderación w = (x, y, z, w) dependerá del dominio del productoentre el dominio del kernel y el rango del kernel:

d(i, j, k, l) = exp

(

−(i− k)2 + (j − l)2

2σd2

)

r(i, j, k, l) = exp

(

−‖f(i, j)− f(k, l)‖2

2σr2

)

w(i, j, k, l) = exp

(

−(i− k)2 + (j − l)2

2σd2

− −‖f(i, j)− f(k, l)‖2

2σr2

)

(6.6)

La imagen que se obtiene al aplicar el filtro bilateral se muestra a continuacióncon bilateralFilter(src,dst,9,75,75) 6.9

(a) Imagen sin filtro aplicado (b) Filtro bilateral

Figura 6.9: Aplicación de filtro bilateral

El filtro bilateral se aplica mediante la función de OpenCV bilateralFilter cuyosparámetros expresan:

– InputArray src: imagen de entrada

– OutputArray dst: imagen de salida del mismo tipo y tamaño que src

– int d: diámetro del cada píxel vecino utilizado durante el filtrado

– double sigmaColor : valor de sigma en el espacio de color. Un valor mayorimplica que los colores más lejanos respecto al píxel vecino serán mezclados,resultando en áreas mayores con un color cuasi idéntico.

– double sigmaSpace: valor de sigma en el espacio de coordenadas. Un valor mayorindica que los píxeles más lejanos se influenciarán mutuamente siempre quesus colores estén lo suficientemente cerca.



– int borderType: método de extrapolación de los píxeles.

A partir de los resultados obtenidos en la aplicación de los filtros y habiendoprobado cada uno de ellos, los mejores resultados se obtienen con el filtro gaussiano.Los filtros de mediana y bilateral provocan una distorsión y suavización excesivasen la imagen, pudiendo dar lugar a regiones blancas de dimensiones mayores a laoriginal después de aplicar el siguiente paso, la binarización.

El siguiente paso a realizar es binarizar la imagen para convertirla a unos y cerosfáciles de interpretar. Se emplea la función threshold. En este caso, se emplea el tipode binarizado binario, el cual se fundamenta en que, si la intensidad del pixel src(x,y) es mayor que el umbral thresh, entonces la intensidad del nuevo píxel se estableceen MaxVal. En caso contrario, se establece en 0.

dst(x, y) =

{

maxV al if src(x, i) > thresh0 otherwise

(6.7)

Los parámetros de la función threshold son:

– InputArray src: imagen de entrada, generalmente en escala de grises.

– OutputArray dst: imagen de salida binarizada

– double thresh: valor del umbral

– double maxVal: valor máximo asignado a los píxeles que superen el umbralthresh. Normalmente se establece en 255 para hacerlo blanco o 1 absoluto.

– int type: tipo de threshold aplicado. En este caso, THRESH_BINARY.

(a) Imagen con filtro gaussiano (b) Imagen binarizada

Figura 6.10: Imagen binarizada después de aplicar los filtros

La imagen 6.10 muestra la imagen binarizada obtenida a partir de la imagen enescala de grises.



A partir de la imagen binaria se pueden aplicar, si se considera necesario, trans-formaciones morfológicas en la imagen. Se trata de operaciones simples basadas enla forma de la imagen. Necesitan una imagen binaria de entrada y un kernel quedetermina la naturaleza de la operación. En el caso del presente trabajo, se hanevaluado las siguientes transformaciones morfológicas:

Erosion

El kernel se desplaza por toda la imagen, aplicándose a todos los píxeles de laimagen original. Si un píxel, siendo un 1 o 0, está rodeada por un kernel en el quetodos los elementos son 1, será considerado como un 1, y viceversa.

De esta forma, los píxeles próximos a los bordes serán descartados, dando lugar aimágenes con objetos en los que disminuye su tamaño y grosor. También es útil paraeliminar el ruido blanco o separar dos objetos cercanos de una imagen.

Para su aplicación práctica se utiliza la función de OpenCV erode la cual tienelos siguientes parámetros:

– InputArray src: imagen de entrada, con un número arbitrario de canales.

– OutputArray dst: imagen de salida con el mismo tamaño y tipo que src.

– InputArray kernel: elemento estructural empleado para la erosión.

Con un kernel de 7x7 se obtiene la siguiente imagen con la operación de erode:

(a) Ruido binario (b) Operación de erode

Figura 6.11: Operación de erode a la imagen con ruido binario

Dilation

Es la operación opuesta a la erosión. Con un determinado kernel, un pixel de laimagen original será un 1, independientemente de si es un 1 o un 0, si al menos unode los píxeles vecinos es un 1.

Con la dilatación se consigue aumentar el área blanca de la imagen, siendonormalmente utilizada después de un proceso de erosión para evitar la disminucióndel tamaño del objeto o unir las partes rotas de objetos presentes en la imagen.



Para su aplicación práctica se utiliza la función de OpenCV dilate, la cual tienelos siguientes parámetros:



– InputArray kernel: elemento estructural empleado para la erosión.

Con un kernel de 7x7 se obtiene la siguiente imagen con la operación de dilation:

(a) Ruido binario (b) Operación de dilation

Figura 6.12: Operación de dilation a la imagen con ruido binario

Opening

Consiste en realizar una erosión seguida de una dilatación. Permite eliminar ruidode la imagen principalmente.

Para su aplicación práctica se utiliza la función de OpenCV morphologyEx lacual tiene los siguientes parámetros:



– int op: tipo de operación morfológica. En este caso MORPH_OPEN.

– InputArray kernel: elemento estructural empleado para la erosión y dilatación.

– Point anchor: posición del anclaje con el kernel. Valores negativos indican quees el centro del kernel. Por defecto es (-1,-1).

– int iterations: número de veces que se aplican la erosión y la dilatación



Con un kernel de tamaño 7x7 y dos iteraciones del proceso de opening se obtienela siguiente imagen:

(a) Ruido binario (b) Operación de opening

Figura 6.13: Operación de opening a la imagen con ruido binario

Como se puede comprobar a partir de las imágenes anteriores no se consigueeliminar completamente el ruido en la imagen binaria con las operaciones de erosion,dilation y opening. La solución adoptada por tanto es aumentar el umbral debinarización hasta un valor de 200, suficiente para eliminar el ruido de la imagen.

(a) Imagen binaria con ruido (b) Imagen binaria sin ruido

Figura 6.14: Imagen binaria con aumento del umbral de binarizado

El tratamiento de la imagen concluye en este punto. Lo necesario ahora es emplearlas herramientas matemáticas para interpretar dicha imagen.



6.2.2. Herramientas matemáticas

Algoritmo de Canny

La primera de estas herramientas es el algoritmo de Canny desarrollado por JohnF.Canny en 1986, empleado para la detección de bordes [15]. Se trata de un algoritmoque se realiza en varias fases, las cuales se enumeran a continuación:

1. En primer lugar, en busca de evitar los falsos positivos, elimina el ruido con unfiltro gaussiano a partir de un kernel de 5x5.

2. A partir de la imagen suavizada, se aplica un kernel de Sobel en direcciónhorizontal y vertical para obtener la primera derivada en dirección horizontalGx y vertical Gy. A partir de las dos imágenes, es posible encontrar el gradiantede borde G y la dirección de cada píxel:

Gx =

−1 0 1−2 0 2−1 0 1

· I Gy =

−1 −2 −10 0 01 2 1

· I (6.8)

G =√

Gx2 + Gy

2 θ = arctan(

Gy

Gx

)

(6.9)

3. La dirección de gradiante es siempre perpendicular a los bordes, redondeadosiempre a uno de los cuatro ángulos de las direcciones vertical, horizontal y lasdos diagonales.

4. Después de obtener la magnitud y dirección del degradado, se realiza un escaneocompleto de la imagen para eliminar los píxeles no deseados que pueden noconstituir los bordes. Para ello, en cada píxel se verifica si se trata de un máximolocal en su vecindad en la dirección del gradiante. El resultado obtenido es unaimagen binaria con bordes finos.

5. La última etapa es un proceso de histéresis que permite clasificar entre aquellosque son verdaderos bordes y aquellos que no lo son. Para ello, a partir de losvalores minVal y maxVal que establecen los umbrales de detección, aquellosbordes con un gradiante de intensidad mayor que maxVal serán bordes y losque están por debajo de minVal se puede afirmar que no lo serán, por lo que sedescartan. De esta forma se eliminan además los píxeles con ruido que puedenexistir, al considerarse que los bordes son líneas de mayor longitud.

La aplicación del algoritmo de Canny para detectar los bordes en la imagen serealiza a través de la función de OpenCV Canny.

Se muestra el reseultado que lleva desde la imagen binarizada hasta la imagenobtenida al detectar los bordes con Canny(src,dst,252,255,3)



(a) Imagen binaria (b) Bordes de las líneas

Figura 6.15: Detección de bordes con Canny

Los parámetros de la función canny son:

– InputArray image: imagen de entrada, con un único canal de 8 bits.

– OutputArray edges: mapa de bordes con el mismo tamaño y tipo que image.

– double threshold1: valor del umbral minVal para el proceso de histéresis.

– double threshold2: valor del umbral maxVal para el proceso de histéresis.

– int apertureSize: tamaño del kernel de Sobel. Se establece un valor de 3.

Transformada de Hough

Una vez detectados los bordes de las líneas, se aplica el algoritmo desarrolladopor Paul Hough en 1962, denominado transformada de Hough, el cual permitela detección de cualquier forma, siempre que sea posible representar dicha formamatemáticamente. La detección es robusta y consigue detectar formas, aunque existadetección o la imagen esté dañada. Para el presente caso se utiliza el algoritmoprimitivo, aplicado a la parametrización de líneas rectas [16].

Las rectas pueden ser representadas matemáticamente en el espacio de dos formasdiferentes y a través de dos variables:

– En el sistema de coordenadas cartesiano. Parámetros (m, b).

y = mx + b

– En el sistema de coordenadas polares. Parámetros (ρ, θ).

ρ = xcosθ + ysenθ



En el caso de la transformada de Hough, las líneas se expresan en el sistemapolar, quedando la ecuación de recta como:

y =

(

−cosθ

senθ

)

x +(

ρ

senθ

)

(6.10)

Para cada punto (x0, y0) se puede definir una familia de rectas que pasa por dichopunto de la forma:

ρθ = x0cosθ + y0senθ ρ > 0 0 < θ < 2π (6.11)

Figura 6.16: Transformada de Hough

Realizando el proceso para todos los puntos de la imagen, se buscan las intersec-ciones de las correspondientes familias de rectas, significando dichas interseccionesla pertenencia a la misma recta. De esta forma, las rectas se pueden detectar alencontrar el número de intersecciones entre las curvas, estando la recta formada pormás puntos cuantas más intersecciones se detecten. Para asegurar una detecciónrobusta, se define un umbral mínimo de intersecciones necesarias para detectar unalínea.

OpenCV implementa dos tipos de Transformada de Hough de Rectas:

1. Transformada de Hough estándar. Sigue la teoría explicada hasta ahora, dandocomo resultado un vector de parejas para los parámetros (ρ, θ).

2. Transformada de Hough probabilística. Implementación más eficiente de laTransformada de Hough para rectas, dando como resultado los extremos de laslíneas detectadas (x0, y0, x1, y1).



De las dos implementaciones posibles, se escoge la Transformada de Houghprobabilística, que permite encontrar segmentos rectos a partir de la imagen binariade la que se parte. La función de OpenCV que la aplica es HoughLinesP.

Al aplicar la función a la imagen de bordes obtenida a partir de Canny, el resultadoes el siguiente con HoughLinesP(src,dst,1,CV_PI/180,30,40,20)

(a) Bordes de las líneas (b) Transformada de Hough

Figura 6.17: Aplicación de la transformada de Hough

Los parámetros de la función HoughLinesP son:

– InputArray image: imagen de entrada, con un único canal de 8 bits.

– OutputArray lines: vector de salida. Constituye los puntos que representan lasrectas

– double rho: resolución de la distancia del acumulador en píxeles.

– double theta: resolución del ángulo del acumulador en radianes.

– int threshold: parámetro de umbral del acumulador. Sólo son válidas las rectascon un valor por encima.

– int minLineLenght: longitud de recta mínimo. Por debajo de este umbral, larecta será descartada.

– int maxLineGap: máximo espacio permitido entre dos puntos para vincularlosa la misma recta.



6.3. Algoritmo de clasificación y análisis matemá-tico

A partir de la transformada de Hough obtenemos un conjunto de líneas en laimagen que se procede a clasificar en función de que se encuentren en el carrilizquierdo, central o derecho.

Para comenzar la clasificación se fijan los puntos centrales de los carriles izquierdoy derecho en función de las dimensiones conocidas de los carriles. En la imagenobtenida después de todas las transformaciones y modificaciones muestra un anchodel carril en píxeles de 120 y sabiendo que la distancia real es de 40 centímetros, seestablece un parámetro de conversión 0, 4m/120px.

Figura 6.18: Medidas en centímetros y en píxeles de los carriles

A partir de la gráfica anterior se puede extraer un factor de conversión entrepíxeles y metros fundamental en el análisis posterior.

El método para conocer la inclinación de los carriles y hacer un seguimientoo tracking tiene en cuenta las coordenadas en la imagen, con el eje Y en sentidocontrario, a partir de la ecuación de una recta x = my + b. Sabiendo que el puntoanterior central del carril es Pcd = (x0, y0) y el ángulo de la medición anterior fueθ0 = −π

2− θ0 se calcula la nueva posición del punto central del carril a partir de las

relaciones trigonométricas siguientes:

x = (m · y0 + b) +d

sen(θ0)y = y0 (6.12)

Para evitar falsas detecciones, ya sea con las rectas de las intersecciones, con laslineas que pueden detectarse de las señales o cualquier obstáculo, se establece un



Figura 6.19: Cálculo de ángulo de seguimiento

umbral de detección para las rectas. Aquellas rectas con un ángulo inferior a π3

no seconsideran en el análisis y son descartadas.

Para la clasificación de las rectas se calculan dos vectores ~Vcd y ~Vci, que tienensu origen en los puntos centrales de los carriles derecho e izquierdo respectivamentey presentan un ángulo respecto a la vertical correspondiente con el ángulo deseguimiento θ0. Porteriormente, se toma el punto inicial y final de la recta detectaday se calculan los vectores que unen dicho punto con los puntos centrales de los carrilesderecho ( ~dn,i, ~dn,f ) e izquierdo ( ~in,i, ~in,f ).

Figura 6.20: Vectores para la clasificación de rectas



Para determinar la clasificación de la línea se calcula el producto vectorial de losvectores ~Vcd y ~Vci por los vectores ~dn,i,

−−→dn,f , ~in,i, ~in,f según el algoritmo siguiente.

Figura 6.21: Algoritmo de clasificación de rectas

El resultado de clasificar las rectas se muestra a continuación 6.22. Se muestrauna captura con un carril completamente recto dónde aparecen la línea derecha encolor azul, las líneas centrales en color verde y una recta amarilla con punto inicialen el centro del carril y un punto final según la inclinación del carril.

Figura 6.22: Clasificación de las lineas



En el caso de no estar centrado y tener visión de la línea izquierda, se muestraésta en color rosa 6.23.

Figura 6.23: Clasificación de las lineas inclinadas

Dado que el objetivo era ampliar la visión que se tiene de las líneas de carretera,se plantea un método para aproximar las rectas observadas mediante polinomios desegundo grado que se mandan directamente al control del coche.

El polinomio que se quiere obtener evalúa x en función de y, x = f(y), obtenién-dose un polinomio aplicado a cada punto de la forma:

xi = p0 + p1yi + p2yi2 (6.13)

A partir de la clasificación anterior de las rectas se tomarán todas las rectas decada uno de los tipos, veáse rectas derechas, rectas izquierdas y rectas centrales. Cadauna de las rectas de estos grupos se divide en un número de puntos proporcinal a lalongitud de dicha recta. Este paso es importante tenerlo en cuenta, ya que se pretendedar mayor importancia o peso a las rectas de mayor longitud, que previsiblementemarcarán con mayor claridad el camino de la recta. Posteriormente se mostrarán losresultados en función del número de puntos en los que se divida la recta.

Una vez obtenidos los puntos de cada uno de los grupos, es decir, puntos dere-chos, puntos izquierdos y puntos centrales, se aplica un algoritmo de aproximaciónpolinomial de segundo grado para cada uno de los grupos. Se explica para un grupoconcreto, por ejemplo, para los puntos derechos, siendo igual para los izquierdos ycentrales.



Se obtienen los vectores ~x e ~y con los pares en abscisas y ordenadas de los Npuntos (xi, yi) obtenidos.

x =

x0

x1

x2

...xN−1

y =

y0

y1

y2

...yN−1

La aproximación para polinomios de orden M se muestra a continuación

x0

x1

x2

...xN−1

=

1 y0 y02 . . . y0

M

1 y1 y12 . . . y1

M

1 y2 y22 . . . y2

M

......

.... . .

...1 yN−1 yN−1

2 . . . yN−1M

p0

p1

p2

. . .pM

(6.14)

Particularizando la ecuación 6.14 para el caso de M = 2:

x0

x1

x2

...xN−1

=

1 y0 y02

1 y1 y12

1 y2 y22

......

...1 yN−1 yN−1

2

p0

p1

p2

~x = X · ~p (6.15)

Y el vector de los coeficientes de regresión polinomial estimados mediante estima-ción por mínimos cuadrados se calcula:

~p = (XT X)−1

XT ~x (6.16)

Para que la matriz X sea invertible se debe cumplir que el número de puntos seamayor que el grado del polinomio N > M , lo cual se comprueba antes del cálculodel vector de coeficientes.

El siguiente ejemplo representa la clasificación de las líneas previamente mostradajunto con la aproximación polinomial de las líneas de los carriles para la mismaimagen 6.24.



Figura 6.24: Aproximación polinomial de las lineas clasificadas

En el caso de la aproximación anterior obtenemos como polinomios de las líneascentral y derecha, haciendo la evaluación en píxeles y en metros:

Polinomio derecha(px) : x = Pd(y) = 199,461 + 0,017449y − 3,15155 · 10−5y2

Polinomio centro(px) : x = Pc(y) = 99,3635− 0,0310802y + 1,85551 · 10−6y2

Polinomio derecha(m) : x = Pd(y) = 0,36847 +−0,0181601y + 0,0189209y2

Polinomio centro(m) : x = Pc(y) = 0,17371 +−0,0227544y + 0,00783768y2

Para el caso de claficación sin estar el coche centrado en el carril y con ángulo decabeceo no perpendicular a las líneas de carril, se compara el resultado con las líneasclafisicadas y la aproximación polinomial calculada.

Figura 6.25: Aproximación polinomial de las lineas clasificadas



Los polinomios que se obtienen en el caso de que aparezcan los tres grupos delineas son:

Polinomio derecha(px) : x = Pd(y) = 246,018− 0,0581768y − 9,28035 · 10−5y2

Polinomio centro(px) : x = Pc(y) = 141,786− 0,0780588y − 6,36075 · 10−6y2

Polinomio izquierda(px) : x = Pi(y) = 36,5872− 0,170015y + 0,000214702 · 10−6y2

Polinomio derecha(m) : x = Pd(y) = 0,503074 +−0,312593y + 0,258009y2

Polinomio centro(m) : x = Pc(y) = 0,267907 +−0,101039y + 0,00110795y2

Polinomio izquierda(m) : x = Pi(y) = 0,0447444 +−0,133014y + 0,141518y2

Para el caso de encontrarse en una curva:

Figura 6.26: Aproximación polinomial en curva

Polinomio derecha(px) : x = Pd(y) = −170,565 + 1,6943y +−0,00180594y2

Polinomio centro(px) : x = Pc(y) = −689,302 + 3,68992y +−0,00428048y2

Polinomio derecha(m) : x = Pd(y) = −0,30981 + 1,69339y +−0,992614y2

Polinomio centro(m) : x = Pc(y) = −1,43549 + 4,15709y +−2,65332y2



Como se ha comentado previamente, el número de puntos en el que se dividecada una de las rectas para luego hacer la aproximación polinomial puede suponerun tiempo de computación importante, por lo que es necesario evaluarlo. Partiendode que el número de divisiones es proporcional a la longitud de la recta evaluada,se muestran algunas mediciones de tiempos para el cálculo de los coeficientes delpolinomio a partir de los puntos en un tramo recto para la linea derecha.

divisiones = k ·√

(x0 − x1)2 + (y0 − y1)

2 (6.17)

k Puntos Tiempo(s)

0,1 45 6,67 · 10−5

0,5 249 2,75 · 10−4

0,9 416 4,56 · 10−4

1,0 514 6,14 · 10−4

Tabla 6.1: Comparativa de tiempo de procesamiento

Aunque puedan parecer poco significativas las diferencias, se debe tener en cuentaque estas pruebas se han hecho en un ordenador con un procesador más potente queel que lleva el coche, por lo que puede resultar un factor diferencial.

A partir de los polinomio obtenidos se pretende llevar a cabo el control del coche,mediante los parámetros de error de cabeceo y error de deriva.

Para calcular el error de cabeceo se parte de un punto auxiliar o punto delook ahead que se va a situar en y=420 pixeles. Se hace uso de las derivadas delos polinomios para calcular la tangente en el punto de look ahead y obtener suinclinación respecto a la vertical.

x1 = p0 + p1 + p2x2

x2 = x1 − y1 · x′(y1) = x1 − (p1 + 2p2y1) y2 = 0

ǫθ,n = arctan(

x1−x2

y1−y2

)

Valores positivos del error de cabeceo indican un ángulo en sentido antihorario,mientras que valores negativos indican un ángulo en sentido horario.



Figura 6.27: Cálculo del error de cabeceo

En el caso del error de deriva se tiene como referencia el punto central del carrilderecho y del carril izquierdo. A partir del número de grupos de líneas (derecha,centro, izquierda) que se detecten se calcula el error de deriva.

Figura 6.28: Cálculo del error de deriva

Dónde las líneas continuas representan la posición de referencia, de la que seobtienen los centros de los carriles y las líneas discontinuas la posición actual.

ǫDd = xd − Pcd ǫDi = Pci − xi

ǫDcd = Pcd − xc ǫDci = xi − Pci(6.18)



Línea derecha:ǫD = ǫD,d

Líneas central y derecha:

ǫD = (ǫD,d − ǫD,cd)/2

Línea central:ǫD = (ǫD,cd − ǫD,ci)/2

Líneas izquierda y central:

ǫD = (ǫD,i − ǫD,ci)/2

Línea izquierda:ǫD = ǫD,i

Líneas izquierda, central y derecha

ǫD = ((ǫD,d − ǫD,cd) + (ǫD,i − ǫD,ci))/2

Al calcularlo de esta forma, valores positivos del error de deriva indican que elcoche se encuentra desplazado hacia la derecha y valores negativos que lo está haciala izquierda. Además, la deriva en metros se obtiene haciendo la conversión de píxelesa metros.

A modo de ejemplo se muestra gráficamente, con las rectas auxiliares en colornaranja y el error de cabeceo de la línea derecha y línea central.

Figura 6.29: Error de cabeceo a partir de los polinomios

ǫθd = 0,0118673 rad = 0,680◦ ǫθc = 0,0127608 rad = 0,731◦

ǫθ = 0,01231405 rad = 0,705◦

ǫD = −0,01245 m



Figura 6.30: Error de cabeceo en un tramo recto

Para el caso de un tramo completamente recto se obtienen:

ǫθd = −0,0009697 rad = −0,055◦ ǫθc = −0,0012483rad = −0,071◦

ǫθ = −0,001109 rad = −0,063◦

ǫD = −0,01534 m

En el caso de las curvas, el inicio de las mismas queda perfectamente especificado,mientras que, debido al método de clasificación de las rectas explicado previamente,no es posible llevar a cabo el método, especialmente en curvas cerradas.

Figura 6.31: Error de cabeceo en una curva

ǫθd = 0,283618 rad = 16,250◦ ǫθc = 0,308694rad = 17,686◦

ǫθ = 0,296156 rad = 16,968◦

ǫD = 0,03341 m



6.4. Ánalisis de resultados

Dado que el fundamento del trabajo era conseguir una visión más amplia dela carretera, se empiezan ofreciendo los resultados de haber ampliado dicha visiónrespecto al trabajo del que se partía.

En el tramo recto mostrado en la imagen se consigue una proyección de las líneasmucho más amplio. Se muestra tanto el IPM de la imagen como el resultado dela transformada de Hough, dado que es el paso previo al análisis matemático y elresultado que se obtenía el año pasado comparado con la aproximación polinomial.

Figura 6.32: Imagen en tramo recto

(a) IPM previo (b) Hough previo (c) Resultado previo

(d) IPM obtenido (e) Hough obtenido (f) Resultado obtenido

Figura 6.33: Comparación de resultados en recta



El siguiente caso se corresponde con una situación en la que el coche se encuentraligeramente inclinado. Como se puede apreciar, se ha conseguido obtener informaciónde los tres grupos de líneas.

Figura 6.34: Imagen en tramo inclinado



Figura 6.35: Comparación de resultados con el coche inclinado



Uno de los casos más críticos en la detección que se hacía el año pasado era elpaso por intersecciones, ya que existen varios frames en los que no se visualizanlíneas. Esto se ve solucionado con el modelo obtenido. Se puede observar como sepasa de no tener información apenas de la intersección a poder ver las líneas que vanantes y después de la misma.

Figura 6.36: Imagen en intersección



Figura 6.37: Comparación de resultados en intersección



Para el caso de entrada a curvas, como la que se muestra a continuación se vecomo se ha conseguido ver el inicio de la curva, respecto a lo que parecía un segmentorecto en la interpretación anterior.

Figura 6.38: Imagen en curva



Figura 6.39: Comparación de resultados en inicio de curva



Para el caso de las curvas se diferencias también son notables. En las imágenesinferiores se comprueba como antes no se tenía perspectiva de la curva y el cocheentendía que estaba dentro de ella una vez que empezaba a girar, mientras que conla ampliación de la visión ya tenemos una perspectiva de la curva antes de empezara tomarla.

Figura 6.40: Imagen en curva



Figura 6.41: Comparación de resultados en curva



Para complementar el análisis de resultados se muestran unas gráficas dondeaparecen los errores de cabeceo de los polinomios ǫθd, ǫθi, ǫθc , ǫθ, y los errores dederiva ǫD,d, ǫD,c, ǫD,i, ǫD para distintos tipos de tramos.

En primer lugar, para un tramo completamente recto, que se puede correspondercon el mostrado en la figura 6.32. Como se puede observar, la mayor inestabilidad sepresenta en el error de cabeceo correspondiente al polinomio central. Ello se puededeber a que, al tratarse líneas discontinuas, los polinomios calculados pueden variarligeramente, aunque se encuentra en un intervalo adecuado.

El orden de magnitud para el error de deriva que se mantiene durante el trayectoes de ǫD ≃ −0,013 m, mientras que el error de cabeceo se sitúa en ǫθ ≃ +0,03 radde valor medio.

Figura 6.42: Gráfica del cabeceo tramo recto

Figura 6.43: Gráfica de la deriva en tramo recto



También se muestran unas gráficas en la que se incluyen un tramo recto, unaparada del coche y a continuación una curva hacia la izquierda correspondiente a lamostrada en la figura 6.40 con sus errores de deriva y cabeceo.

Figura 6.44: Gráfica del cabeceo en curva

Figura 6.45: Gráfica de la deriva en curva

A partir de los datos obtenidos se ha hecho un análisis estadístico de los erroresde cabeceo de los polinomios ǫθd, ǫθi, ǫθc respecto al cabeceo total ǫθ, y de los erroresde deriva ǫD,d, ǫD,c, ǫD,i respecto a la deriva total ǫθD en los tramos que se hanrepresentado en las figuras anteriores. Por lo tanto, se definen los errores porcentualesa analizar de la forma:

εθ,d = |ǫθ,d−ǫθ|ǫθ

εθ,c = |ǫθ,c−ǫθ|ǫθ

εθ,i = |ǫθ,i−ǫθ|ǫθ

εD,d = |ǫθ,d−ǫD|ǫD

εD,c = |ǫD,c−ǫD|ǫD

εD,i = |ǫD,i−ǫD|ǫD

(6.19)



Con el coche parado, como corresponde al tramo recto de las gráficas 6.44 y 6.45se obtienen las medias de errores porcentuales:

µεθd( %) µεθc

( %) µεθi( %) µεD,d

( %) µεD,c( %) µεD,i

( %)

8.856 10.967 N/A 0.0068 0.0067 N/A

Tabla 6.2: Medias de los errores con el coche parado

Para el caso de un tramo recto, se obtienen las medias de los errores porcentuales:

µεθd( %) µεθc



( %)

9.097 12.342 N/A 0.0176 0.0172 N/A

Tabla 6.3: Medias de los errores en tramo recto

En una curva como la mostrada en 6.44 y 6.45 se obtienen los errores porcentuales:

µεθd( %) µεθc



( %)

22.365 28.439 N/A 0.0308 0.0414 N/A

Tabla 6.4: Medias de los errores en curva

Como se puede observar a partir de los resultados obtenidos, las mayores diferen-cias se obtienen para la línea central discontinua que separa los carriles entendiendoque, al haber zonas dónde no se encuentran puntos, la aproxamación polinomial noes tan precisa como en el caso de las líneas derecha e izquierda, donde la líneas escontinua.



Para finalizar el análisis se comparan los resultados obtenidos para los errores decabeceo y deriva con los obtenidos en el trabajo del año pasado.

En primer lugar se realiza un tramo recto en el que se incluye una intersección6.46 6.47. Se aprecia como se ha conseguido un error de cabeceo similar al que setenía antes, mientras que en el error de deriva se consiguen transiciones más suaves alno encontrarse el coche perfectamente centrado en el carril. Además, en el sector quese corresponde con la intersección se consigue información de la deriva y el cabeceo,mientras que antes en ese tramo se tomaban la deriva y el cabeceo del instanteprevio a que se dejasen de ver las líneas, teniendo un tramo sin información real dela carretera.

Figura 6.46: Comparación del error de cabeceo en recto

Figura 6.47: Comparación del error de deriva en recto



En segundo lugar se realiza un tramo recto, seguido de una parada del coche yluego una curva a la izquierda 6.48 6.49. El error deriva muestra un comportamientomás estable, con cambios más suaves y un mantenimiento en un valor fijo en recta yen la parada del coche, mientras que en curva no sufre la variación tan exageradaque se mostraba el año pasado. El error de cabeceo mantiene valores similares altrabajo previo en recta, mientras que en la parada se muestra más estable y la curvacomienza a verla antes y deja de marcar cabeceo a la vez cuando termina la curva.

Figura 6.48: Comparación del error de cabeceo en curva

Figura 6.49: Comparación del error de deriva en curva




7. Conclusiones y líneas futuras

7.1. Conclusiones

El trabajo realizado ha permitido obtener el primer puesto en la competición,lo cual es un buen indicativo de los resultados obtenidos. El funcionamiento de ladetección de señales ha sido óptimo, salvo los problemas encontrados y solucionadosen la competición, y la detección de líneas ha supuesto una mejora respecto al trabajoprevio sin embargo, requiere una evolución para algunas situaciones concretas.

En relación a la detección de señales la estrategia seguida detectando en primerlugar la señal y, posteriormente establecer una región de interés para los indicadoresluminosos a partir de las características geométricas ha resultado exitosa, consiguiendode esta forma evitar falsos positivos en la detección del color en situaciones en lasque un error hubiese resultado crítico, como confundir el color del semáforo o nollevar a cabo la maniobra de aparcamiento.

Respecto al enfoque dado a la detección de líneas, la obtención de polinomios paraidentificar las línesa de carretera han permitido el uso de las propiedades matemáticaspara el cálculo directo de los parámetros de control que precisa el coche como sonel error de deriva y de cabeceo. Además, la elección de aproximar por polinomiosde segundo grado consigue que los polinomios obtenidos representen con exactitudla línea de carretera, siendo la aproximación por rectas que se hacía en el trabajoprevio una limitación.

En comparación con el trabajo de detección de líneas del que se partía y que sepretendía mejorar, se han conseguido importantes mejoras en la tarea de ampliarel rango de visión, contando con más rango para la planificación del vehículo. Lasmejoras más significativas se observan en las intersecciones, en las que antes no setenía información al pasar por ellas, y en curvas, en las que ahora se muestran laslíneas detectadas como curvas gracias a la aproximación polinomial.

Por otro lado, haber hecho uso de librerías y herramientas de desarrolladores deROS y OpenCV ha facilitado el desarrollo de las soluciones, ya que se cuenta conuna referencia, unas funciones específicas para cada aplicación y una comunidad enque encontrar posibles consultas.

115

CAPÍTULO 7. CONCLUSIONES Y LÍNEAS FUTURAS

Desde el punto de vista del hardware, el empleado ha representado una importantelimitación al no tener suficiente capacidad de cómputo, especialmente en las tareasque empleaban el tratamiento de imágenes y su posterior procesado. Ello ha llevadoa emplear un único topic para todos los nodos que usaban imágenes, teniendo quehacer un tratamiento invidual dependiendo de la aplicación a pesar de que la cámaraproporciona más posibilidades.

7.2. Líneas futuras

Una de las características del evento era que el desarrollo del mismo se llevaba acabo dentro de unas condiciones y en un entorno más o menos controlados, con loque la conducción no sufre perturbaciones externas derivadas de cambios bruscos deluminosidad, defectos en la carretera o posibles peatones. Una ampliación progresivade la dificultad incluyendo factores externos llevarían a soluciones cada vez máspróximas a los automóviles reales.

En referencia al empleo de marcadores AR que representen las señales, unaevolución podría venir representada por el empleo de señales con un aspecto más realy parecido a las señales encontradas en carretera. La identificación de dichas señalesimplicaría una normalización de la forma y colores de cada señale, pero representaríaun importante avance respecto a tener que detectar marcadores AR.

Por otro lado, los indicadores luminosos asociados a las señales tenían una formarectangular con unas dimensiones perfectamente conocidos. En este apartado sepodría pasar a utilizar indicadores con forma circular parecidos a los semáforosreales e incluso no tener asociado una señale que lleve a identificar después el color,debiendo buscar sólo los testigos luminosos.

Respecto a la detección de líneas, los resultados obtenidos para tramos en recto,intersecciones y curvas han sido buenos por lo que la evolución se debe centrar enaplicar el enfoque a las rotondas y posibles situaciones más complejas. La aproxima-ción polinomial obtiene buenos resultados, pero requiere de una previa clasificaciónde las líneas por lo que conseguir distinguir los puntos que corresponden a cadagrupo resulta fundamental.

Por otra parte, se propone avanzar en el método de traking que se hace de laslíneas de carretera, tratando de predecir el camino que marcan las mismas, siendoespecialmente útil en situaciones como curvas o rotondas.

También se proponen situaciones adiciones que condicionan la detección de líneascomo pasos de peatones, siendo estos condicionantes en la detección de señales, ointersecciones con un ángulo diferente a los noventa grados.


8. Planificación temporal y costes

8.1. Planificación temporal

Este capítulo engloba tanto la estructura de descomposición del proyecto (EDP)como la planificación temporal en forma de diagrama de Gantt.

El proyecto comienza el 15 de mayo de 2018 con la formación del equipo para lacompetición y termina el 31 de enero de 2019 con la finalización de la redacción dela memoria.

La estructura de descomposición del proyecto que se muestra a continuaciónenuncia las áreas principales en las que se divide el proyecto y las actividades dentrode cada una de ellas 8.1.

Figura 8.1: EDP del proyecto

117

CAPÍTULO 8. PLANIFICACIÓN TEMPORAL Y COSTES

Tarea Horas dedicadas

Formación previa 15

Desarrollo en simulador 100

Desarrollo con coche real 350

Análisis de resultados 30

Redacción de memoria 120

Reuniones 30

TOTAL 645

Tabla 8.1: Horas dedicadas al proyecto

Las horas dedicadas al proyecto se muestran en la tabla 8.1.

La formación previa engloba los tutoriales de repaso de C++, ROS y git llevadosa cabo antes de comenzar la parte práctica del proyecto.

El desarrollo en simulador empieza desde el comienzo del proyecto y concluyecon el primer entregable de la competición la semana del 30 de julio.

El desarrollo con el coche real comienza al terminar con el simulador y terminacon el inicio de los días de competición, incluyéndose en este periodo la preparacióndel segundo entregable de la competición la semana del 29 de octubre.

El análisis de los resultados y la redacción de la memoria comienzan con el finalde la competición y la parte práctica y llegan hasta la finalización del proyecto.

Por último, se incluyen las reuniones llevabas a cabo por el equipo cuyo objetivoera hacer un seguimiento de los progresos y plantear las metas a conseguir. Dichasreuniones se realizaban con carácter semanal desde el inicio del proyecto hasta lacompetición.

Con todo lo anterior se elabora el diagrama de Gantt 8.2, mostrando la evolucióntemporal por semanas comenzando la semana del 14 de mayo de 2018 y terminandola semana del 28 de enero de 2019.



Figura 8.2: Diagrama de Gantt



8.2. Presupuesto

En primer lugar se detallan los costes de personal, que constan del trabajo delestudiante de grado que realiza este trabajo y el investigador del CAR que hace lafunción de tutor.

Costes de personal

Trabajador Horas dedicadasCoste estimado por la

realización del proyecto

Estudiante GITI 645 6.450€

Investigador CAR 50 1.000€

Coste total = 7.450€

Tabla 8.2: Costes de personal del proyecto

Dentro de los costes materiales se encuentran el coche a escala cedido por laorganización, el cual no supone coste para el proyecto ya se cede a los equiposal inicio de la competición y se devuelve al terminar; el material necesario paramontar la pista de pruebas, comprendiendo el material del suelo, la fabricación de lasseñales, el sistema de GPS Visual y las líneas de carretera; y el ordenador de trabajodel estudiante, tanto para la realización de la parte práctica del trabajo, como laredacción del mismo.

Costes materiales

Equipo Coste Coste en el proyecto

Coche autónomo a escala 0 0

Material de la pista de prueba 300€ 300€

Ordenador de trabajo 700€ 105€

Coste total = 405€

Tabla 8.3: Costes materiales del proyecto



Los costes de desarrollo de código, aplicaciones informáticas y de composición detexto no suponen coste alguno por ser la mayoría de software libre, con la excepciónde MATLAB, que se emplea la licencia educativa de la Universidad Politécnica deMadrid.

Costes de software

Programa o aplicación Coste Coste en el proyecto

LibreOffice 0 0

LATEX 0 0

MATLAB 0 0

ROS 0 0

Ubuntu 16.04 0 0

OpenCV 0 0

Coste total = 0€

Tabla 8.4: Costes de software del proyecto

Con todo lo anterior de imputan unos costes totales al proyecto de 7.855€, SIETEMIL OCHOCIENTOS CINCUENTA Y CINCO EUROS.




Referencias

[1] Alex Davies, Inside the races that jump-started the self-driving car.https://www.wired.com/story/darpa-grand-urban-challenge-self-driving-car/

[2] Alan Ohnsman, At Waymo, It’s Launch Time For Google’s Biggest Moonshot.https://www.forbes.com/sites/alanohnsman/2018/11/30/10-million-miles-later-waymo-ceo-says-its-self-driving-cars-are-ready-for-prime-time/cc89d3075e7e

[3] P. Ibánez, De 0 a 5: cuáles son los diferentes niveles de conducción autónoma,a fondo, https://www.xataka.com/automovil/de-0-a-5-cuales-son-los-diferentes-niveles-de-conduccion-autonoma

[4] Tesla Autopilot https://www.tesla.com/autopilot?redirect=no

[5] Audi Technology Portal, Audi A8 - Audi AI traffic jam pilot.https://www.audi-technology-portal.de/en/electrics-electronics/driver-assistant-systems/audi-a8-audi-ai-traffic-jam-pilot

[6] Wayne Cunnigham, Next-gen VWs to get Nvidia-powered AI atCES 2018. https://www.cnet.com/roadshow/news/next-gen-vws-nvidia-artificial-intelligence-ces-2018/

[7] Anthony Sarkis, Self-Driving Cars: Implementing Real-Time Traffic LightDetection and Classification in 2017. https://medium.com/@anthony_sarkis/self-driving-cars-implementing-real-time-traffic-light-detection-and-classification-in-2017-7d9ae8df1c58

[8] Nathaniel Fairfield, Chris Urmson (Google Inc.) Traffic Light Mappingand Detectionhttps://static.googleusercontent.com/media/research.google.com/en/pubs/archive/37259.pdf

[9] Autonomous Driving Challenge 2018 Rule Bookhttps://docs.google.com/document/d/1_hmeI8pAYU75J6U-WfjQtp9SrrOT8er-Xq1rdMCJ0SE/edit

[10] AutoModelCarWiki in GitHubhttps://github.com/AutoModelCar/AutoModelCarWiki/wiki

123

REFERENCIAS

[11] ROS Wiki http://wiki.ros.org/es

[12] OpenCV 3.3.1 https://docs.opencv.org/3.3.1/index.html

[13] ar_track_alvar in GitHubhttps://github.com/ros-perception/ar_track_alvar

[14] Image Filtering OpenCV https://docs.opencv.org/2.4/modules/imgproc/doc/filtering.htmlMat %20getStructuringElement(int %20shape, %20Size %20ksize,%20Point %20anchor)

[15] Justin Liang Canny Edge Detection http://justin-liang.com/tutorials/canny/

[16] Hough Line Transform in OpenCVhttps://docs.opencv.org/3.4/d9/db0/tutorial_hough_lines.html


Anexo I: Índice de figuras

1.1. Coche del programa AUTOPIA . . . . . . . . . . . . . . . . . . . . . 6

2.1. DARPA Grand Challenge . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2. Visión de las cámaras en el sistema Autopilot . . . . . . . . . . . . . . 11

2.3. Audi A8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4. Detección y delimitación de los semáforos[7] . . . . . . . . . . . . . . 12

2.5. Diagrama de deteccion de semáforos[8] . . . . . . . . . . . . . . . . . 13

3.1. Circuito de preparación . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2. Disposición de la rotonda . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3. Segmentos rectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4. Carretera curva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5. Disposición de intersección en T (izquierda) y intersección en X (derecha) 18

3.6. Disposición de zonas de parking en paralelo (izquierda) y batería(derecha) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.7. Dimensiones de los obstáculos . . . . . . . . . . . . . . . . . . . . . . 19

3.8. Detalles de las señales (mm) . . . . . . . . . . . . . . . . . . . . . . . 20

3.9. Coche a escala dearrollado por la Freie Universität Berlin . . . . . . 24

3.10. Módulos electrónicos y conexiones [10] . . . . . . . . . . . . . . . . . 25

3.11. Árbol de conexiones entre módulos [10] . . . . . . . . . . . . . . . . . 25

3.12. Placa Odroid-XU4 64GB . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.13. Arduino Nano v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.14. Motores del coche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.15. Retroalimentación del servomotor . . . . . . . . . . . . . . . . . . . . 27

3.16. Cámara Intel Realsense SR300 . . . . . . . . . . . . . . . . . . . . . . 27

125

3.17. Cámara ELP 1080p . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.18. SLAMTEC RPLidar A2 360 . . . . . . . . . . . . . . . . . . . . . . . 28

3.19. Sistema de alimentación . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.20. IMU MPU-6050 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.21. Sistemas de comunicación . . . . . . . . . . . . . . . . . . . . . . . . 30

3.22. Carcasa del coche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.23. Logo de Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.24. Logos de Git y GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.25. Flujo de trabajo en Git . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.26. Logo de ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.27. Relación entre los elementos en ROS . . . . . . . . . . . . . . . . . . 36

3.28. Estructura de carpetas y ficheros en ROS . . . . . . . . . . . . . . . . 36

3.29. Simulador visualizado en rviz . . . . . . . . . . . . . . . . . . . . . . 37

3.30. Logo de OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.31. Modificación sencilla de imagen . . . . . . . . . . . . . . . . . . . . . 40

3.32. Modificación de imagen a HSV . . . . . . . . . . . . . . . . . . . . . 40

3.33. Modificación de imagen a HSV . . . . . . . . . . . . . . . . . . . . . 40

3.34. Sistema de ejes de coordenadas en la imagen . . . . . . . . . . . . . . 41

4.1. Estructura de software inicial . . . . . . . . . . . . . . . . . . . . . . 43

4.2. Estructura del nodo serial_node . . . . . . . . . . . . . . . . . . . . . 44

4.3. Estructura del nodo odometry_publisher . . . . . . . . . . . . . . . . 45

4.4. Estructura del nodo rplidarNode . . . . . . . . . . . . . . . . . . . . . 45

4.5. Estructura del nodo auto_stop . . . . . . . . . . . . . . . . . . . . . 46

4.6. Estructura del nodo usb_cam . . . . . . . . . . . . . . . . . . . . . . 46

4.7. Estructura del nodo app/camera . . . . . . . . . . . . . . . . . . . . . 47



5.1. Nodos implicados en la comunicación de las señales . . . . . . . . . . 52

5.2. Modelo de color HSV . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3. Imagen del simulador al aplicar la máscara de color rojo . . . . . . . 54

5.4. Filtro de luz empleado en la competición . . . . . . . . . . . . . . . . 56



5.5. Muestras de imágenes del semáforo azul . . . . . . . . . . . . . . . . 56

5.6. Muestras de imágenes del semáforo rojo . . . . . . . . . . . . . . . . . 57

5.7. Muestras de imágenes del semáforo verde . . . . . . . . . . . . . . . . 59

5.8. Imagen real al aplicar la máscara de color azul . . . . . . . . . . . . . 60

5.9. Imagen real al aplicar la máscara de color verde . . . . . . . . . . . . 61

5.10. Imagen reales al aplicar las máscaras de color . . . . . . . . . . . . . 61

5.11. Numeración de las esquinas del marcador . . . . . . . . . . . . . . . . 62

5.12. Esquema de la distorsión en las medidas . . . . . . . . . . . . . . . . 63

5.13. Determinación de la región de interés del color . . . . . . . . . . . . . 64

5.14. Binarización de la región de interés para el color rojo en el simulador 65

5.15. Algoritmo de detección de las señales . . . . . . . . . . . . . . . . . . 67

5.16. Publicación de mensaje en el topic /senales al ser detectadas . . . . . 68

5.17. Visualización de las señales en el simulador con OpenCV . . . . . . . 68

5.18. Imagen real al aplicar la máscara de color verde . . . . . . . . . . . . 69

5.19. Detección de señales con el coche real . . . . . . . . . . . . . . . . . . 69

5.20. Semáforo en la competición . . . . . . . . . . . . . . . . . . . . . . . 70

5.21. Área de trabajo en la imagen . . . . . . . . . . . . . . . . . . . . . . 71

5.22. Imagen en escala de grises . . . . . . . . . . . . . . . . . . . . . . . . 71

5.23. Histograma de la imagen . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.24. Imagen ecualizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72


5.26. Imagen con corrección gamma . . . . . . . . . . . . . . . . . . . . . . 74


5.28. Imagen con corrección gamma y ecualización . . . . . . . . . . . . . . 75

5.29. Detección del semáforo verde . . . . . . . . . . . . . . . . . . . . . . . 76

5.30. Detección del parking encendido . . . . . . . . . . . . . . . . . . . . . 76

5.31. Detección de la rotonda . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.32. Detección del giro a la derecha . . . . . . . . . . . . . . . . . . . . . . 76

6.1. Nodos implicados en la comunicación de las líneas . . . . . . . . . . . 77

6.2. Conversión a escala de grises de la imagen . . . . . . . . . . . . . . . 78

6.3. Correción de la distorsión de la imagen . . . . . . . . . . . . . . . . . 79

6.4. Proyección del rectángulo del IPM . . . . . . . . . . . . . . . . . . . . 80


6.5. Transformación de perspectiva de la carretera . . . . . . . . . . . . . 81

6.6. Aplicación de filtro gaussiano . . . . . . . . . . . . . . . . . . . . . . 82

6.7. Aplicación de un filtro de mediana . . . . . . . . . . . . . . . . . . . 83

6.8. Aplicación de filtro de mediana . . . . . . . . . . . . . . . . . . . . . 83

6.9. Aplicación de filtro bilateral . . . . . . . . . . . . . . . . . . . . . . . 84

6.10. Imagen binarizada después de aplicar los filtros . . . . . . . . . . . . 85

6.11. Operación de erode a la imagen con ruido binario . . . . . . . . . . . 86

6.12. Operación de dilation a la imagen con ruido binario . . . . . . . . . . 87

6.13. Operación de opening a la imagen con ruido binario . . . . . . . . . . 88

6.14. Imagen binaria con aumento del umbral de binarizado . . . . . . . . . 88

6.15. Detección de bordes con Canny . . . . . . . . . . . . . . . . . . . . . 90

6.16. Transformada de Hough . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.17. Aplicación de la transformada de Hough . . . . . . . . . . . . . . . . 92

6.18. Medidas en centímetros y en píxeles de los carriles . . . . . . . . . . . 93

6.19. Cálculo de ángulo de seguimiento . . . . . . . . . . . . . . . . . . . . 94

6.20. Vectores para la clasificación de rectas . . . . . . . . . . . . . . . . . 94

6.21. Algoritmo de clasificación de rectas . . . . . . . . . . . . . . . . . . . 95

6.22. Clasificación de las lineas . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.23. Clasificación de las lineas inclinadas . . . . . . . . . . . . . . . . . . . 96

6.24. Aproximación polinomial de las lineas clasificadas . . . . . . . . . . . 98

6.25. Aproximación polinomial de las lineas clasificadas . . . . . . . . . . . 98

6.26. Aproximación polinomial en curva . . . . . . . . . . . . . . . . . . . . 99

6.27. Cálculo del error de cabeceo . . . . . . . . . . . . . . . . . . . . . . . 101

6.28. Cálculo del error de deriva . . . . . . . . . . . . . . . . . . . . . . . . 101

6.29. Error de cabeceo a partir de los polinomios . . . . . . . . . . . . . . . 102

6.30. Error de cabeceo en un tramo recto . . . . . . . . . . . . . . . . . . . 103

6.31. Error de cabeceo en una curva . . . . . . . . . . . . . . . . . . . . . . 103

6.32. Imagen en tramo recto . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.33. Comparación de resultados en recta . . . . . . . . . . . . . . . . . . . 104

6.34. Imagen en tramo inclinado . . . . . . . . . . . . . . . . . . . . . . . . 105

6.35. Comparación de resultados con el coche inclinado . . . . . . . . . . . 105

6.36. Imagen en intersección . . . . . . . . . . . . . . . . . . . . . . . . . . 106



6.37. Comparación de resultados en intersección . . . . . . . . . . . . . . . 106

6.38. Imagen en curva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.39. Comparación de resultados en inicio de curva . . . . . . . . . . . . . 107

6.40. Imagen en curva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.41. Comparación de resultados en curva . . . . . . . . . . . . . . . . . . . 108

6.42. Gráfica del cabeceo tramo recto . . . . . . . . . . . . . . . . . . . . . 109

6.43. Gráfica de la deriva en tramo recto . . . . . . . . . . . . . . . . . . . 109

6.44. Gráfica del cabeceo en curva . . . . . . . . . . . . . . . . . . . . . . . 110

6.45. Gráfica de la deriva en curva . . . . . . . . . . . . . . . . . . . . . . . 110

6.46. Comparación del error de cabeceo en recto . . . . . . . . . . . . . . . 112

6.47. Comparación del error de deriva en recto . . . . . . . . . . . . . . . . 112

6.48. Comparación del error de cabeceo en curva . . . . . . . . . . . . . . . 113

6.49. Comparación del error de deriva en curva . . . . . . . . . . . . . . . . 113

8.1. EDP del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.2. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119



Anexo II: Índice de tablas

3.1. Programa de la competición . . . . . . . . . . . . . . . . . . . . . . . 16

3.2. Puntuación de la competición . . . . . . . . . . . . . . . . . . . . . . 21

3.3. Activación de luces en la segunda prueba . . . . . . . . . . . . . . . . 22

3.4. Activación de luces en la tercera prueba . . . . . . . . . . . . . . . . . 23

4.1. Estados del topic /estado . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1. ID de las señales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2. Estado de las señales . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3. Identificadores ID de las señales . . . . . . . . . . . . . . . . . . . . . 53

5.4. Umbrales de color HSV en el simulador . . . . . . . . . . . . . . . . . 55

5.5. Medidas de los umbrales para el color azul real . . . . . . . . . . . . . 57

5.6. Medidas de los umbrales para el color rojo 1 real . . . . . . . . . . . . 58

5.7. Medidas de los umbrales para el color rojo 2 real . . . . . . . . . . . . 58

5.8. Medidas de los umbrales para el color verde real . . . . . . . . . . . . 59

5.9. Umbrales de los colores reales . . . . . . . . . . . . . . . . . . . . . . 60

5.10. Umbrales de los colores en la competición . . . . . . . . . . . . . . . . 75

6.1. Comparativa de tiempo de procesamiento . . . . . . . . . . . . . . . . 100

6.2. Medias de los errores con el coche parado . . . . . . . . . . . . . . . . 111

6.3. Medias de los errores en tramo recto . . . . . . . . . . . . . . . . . . 111

6.4. Medias de los errores en curva . . . . . . . . . . . . . . . . . . . . . . 111

8.1. Horas dedicadas al proyecto . . . . . . . . . . . . . . . . . . . . . . . 118

8.2. Costes de personal del proyecto . . . . . . . . . . . . . . . . . . . . . 120

8.3. Costes materiales del proyecto . . . . . . . . . . . . . . . . . . . . . . 120

131

8.4. Costes de software del proyecto . . . . . . . . . . . . . . . . . . . . . 121


Anexo III: Glosario y abreviaturas

AR: Augmented Reality. Realidad aumentada

BGR: Blue Green Red. Azul, Verde, Rojo. Escala cromática.

OpenCV: Open Computer Vision. Visión por computador de uso libre.

ROI: Region of interest. Región de interés de la imagen.

ROS: Robotic Operating System. Sistema operativo robótico.

133

DETECCIÓN DE SEÑALES Y LÍNEAS DE CARRIL PARA …oa.upm.es/54102/1/TFG_RODRIGO_LADERO_GARCIA.pdf · 2019-02-25 · más amplia y proponiendo un enfoque con aproximaciones polinomiales

Documents