integraciÓn en tiempo real de un navegador basado...

UNIVERSIDAD POLITECNICA DE MADRID

ESCUELA TECNICA SUPERIOR DE INGENIEROSINDUSTRIALES

INTEGRACIÓN EN TIEMPO REAL DE UNNAVEGADOR BASADO EN

OPENSTREETMAP

TRABAJO PRESENTADO PARA OPTAR AL TITULO DE

MASTER EN AUTOMATICA Y ROBOTICA

POR

VACA RECALDE, MYRIAM ELIZABETH

MADRID, 15 DE ABRIL DE 2018

Departamento de Automatica, Ingenieria Electrica yElectronica e Informatica Industrial

INTEGRACIÓN EN TIEMPO REAL DE UNNAVEGADOR BASADO EN

OPENSTREETMAP

Autor:

VACA RECALDE, MYRIAM ELIZABETH

Tutores:

FERNANDO MATÍA ESPADA

JORGE LUIS GODOY MADRID

MADRID, 15 DE ABRIL DE 2018

A mi familia,por ser mi apoyo incondicional.

Hacer lo imposible es una forma de diversiónWalt Disney.

AGRADECIMIENTOS

En primer lugar, quiero agradecer a Fernando Matía, Jorge Godoy y a Jorge Villagra por darmela oportunidad de participar en este proyecto tan innovador e interesante.

Agradezco a mis padres y mis hermanas por su apoyo durante el desarrollo de este proyecto,por estar siempre presentes y por procurarme todos los medios que he necesitado para la rea-lización de mis estudios. Así mismo, a José Emilio por su comprensión y ayuda incondicional.También agradezco a Javier Álvarez por su amistad y su apoyo en cada momento.

Por último, a los componentes del programa AUTOPÍA, por desarrollar una investigación taninteresante y a todas las personas que se han interesado por mi trabajo.

RESUMEN

Este proyecto se basó en el desarrollo de un sistema de navegación fundamentado en una apli-cación de un dispositivo Android, para vehículos autónomos. La información a utilizar paralograr este objetivo fue la proporcionada por el proyecto OpenStreetMap y el soporte de códigoabierto de la aplicación OsmAnd.

El fin de este desarrollo es la implementación y comunicación del sistema de navegación conuno de los vehículos autónomos que pertenecen a la flota del grupo de investigación del pro-grama AUTOPIA, perteneciente al Centro de Automática y Robótica de la UPM y al ConsejoSuperior de Investigaciones Científicas (CSIC). El objetivo del proyecto es que la aplicación ac-túe como el planificador y navegador del vehículo interactuando con él y con cada uno de loselementos que forman su estructura.

Para lograr este cometido, primero se realizó un estudio previo de la comunicación LightweightCommunications and Marshalling (LCM) para conocer como se utiliza, cómo se codifican losdatos para enviarlos, cómo se reciben... A continuación se pasó al análisis del proyecto OpenS-treetMap (OSM), la información que contiene, como se estructura, que datos aporta y como sepueden utilizar, que herramientas podrían ayudar al desarrollo del proyecto... Por lo tanto, seestudiaron las ventajas que ofrecían las aplicaciones gratuitas y de código libre que empleanOSM con el fin de basarse en una para el desarrollo del proyecto.

La aplicación se programó en Andorid Studio a partir de una versión de OsmAnd, una aplicaciónde navegación de código abierto que trabaja con la totalidad de la información de OpenStreet-Map. Entre sus principales características destacan el funcionamiento con y sin conexión, lasindicaciones por voz, las indicaciones de carril, el soporte de puntos intermedios en la trayec-toria y el recálculo automático de ruta. No obstante, la versión libre no incluye todas estascaracterísticas.

Por otro lado, se implementan los recursos necesarios para la simulación del vehículo mediantela utilización de datos grabados por este, y un programa auxiliar que envía las alarmas comosi fuera el sistema de percepción del coche.

II

Por consiguiente, la aplicación recibe los datos obtenidos por el GPS del vehículo mediante lacomunicación LCM, al mismo tiempo que recibe las alarmas programadas y se envían los datosal coche para crear perfiles de velocidad, detener el vehículo por una alarma o indicar el modode conducción.

Finalmente se obtiene una interfaz gráfica amigable, sencilla que permite al usuario empezar lanavegación en el coche y capta su atención para diferentes situaciones que pasan a su alrededor.Se realiza la simulación para validar el sistema y se concluye con la obtención de un navegadorpara vehículos autónomos funcional.

III

ABSTRACT

This project was based on the development of a navigation system using an application on anAndroid device, for autonomous vehicles. The information to achieve this objective was provi-ded by the OpenStreetMap project and the open source support of OsmAnd application.

The purpose of this development is the implementation and communication of the navigationsystem with one of the autonomous vehicles belonging to the fleet of the AUTOPIA researchgroup, what is part of the Automation and Robotics Center of the UPM and the Higher Councilof Scientific Research. (CSIC) The objective of the project is the application has to act as thevehicle’s planner and navigator, interacting with it and with each of the elements that form itsstructure.

To achieve this goal, a preliminary study of the Lightweight Communications and Marshalling(LCM) communication was carried out to find out how it is used, how the data is encoded tosend it, how to receive it... Next, it was analyzed OpenStreetMap (OSM) project, the informa-tion that contains, how it is structured, what data it contributes and how it can be used, whattools could help the development of the project, etc. Thus, the advantages offered by free andopen source applications that use OSM, were studied in order to be based on one for the deve-lopment of the project.

The application was programmed in Andorid Studio based on OsmAnd, an open source naviga-tion application that operates with all the OpenStreetMap information, works with and withoutconnection, has voice notifications, lane indications, intermediate point support in the path andit recalculate the route automatically. The problem is that some of these functions are not activein the free version.

On the other hand, the necessary resources for the simulation of the vehicle are implementedthrough the use of data recorded by the vehicle, and an auxiliary program that sends the alarmsas if it were the perception system of car.Therefore, the application receives the data obtained by the GPS of the vehicle through theLCM communication, at the same time, it receives the programmed alarms and sends the datato the car to create speed profiles, stop the vehicle by an alarm or indicate the driving mode.

IV

Finally you get a friendly and simple graphical interface that allows the user to start naviga-tion in the car and get their attention for different situations that happen around them. Thesimulation is carried out for the validation of the system and it is concluded with a functionalnavigation system for autonomous vehicles.

V

ÍNDICE

1. INTRODUCCIÓN 11

1.1. Motivación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2. Objetivo del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3. Organización del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2. ESTADO DEL ARTE 15

2.1. Sistemas inteligentes de transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1. Niveles de autonomía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.2. AUTOPIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2. Sistemas de navegación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.1. Sistemas de planificación y navegadores comerciales . . . . . . . . . . . . . 21

2.2.2. Mapas digitales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.2.1. OpenStreetMap (OSM) . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.3. Aplicaciones de navegación y mapas . . . . . . . . . . . . . . . . . . . . . . . 26

3. SISTEMA DE COMUNICACIÓN 31

3.1. Lightweight Communications and Marshalling (LCM) . . . . . . . . . . . . . . . . . 31

3.2. Prueba de la comunicación LCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.1. Modo de programación del LCM . . . . . . . . . . . . . . . . . . . . . . . . . 34

4. DISEÑO DE LA INTERFAZ 37

4.1. OpenStreetMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2. OsmAnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3. Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

VII

ÍNDICE

4.4. Aplicación final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4.1. Envío/recepción de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4.2. Emulador de posicionamiento: GPS Autopia . . . . . . . . . . . . . . . . . . 45

4.4.3. AUTOPÍA Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5. VALIDACIÓN / RESULTADOS 57

5.1. Simulación de alarmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2. Resultados de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6. CONCLUSIONES Y FUTUROS TRABAJOS 67

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2. Futuros Trabajos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7. BIBLIOGRAFÍA 71

VIII

ÍNDICE DE FIGURAS

1.2.1. Cronograma del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1. Vehículo autopropulsado de Leonardo Da Vinci. . . . . . . . . . . . . . . . . . . . . 16

2.1.2. Ejemplos del avance tecnológico sigo XX. . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.3. Ejemplos de vehículos modernos de alta autonomía. . . . . . . . . . . . . . . . . . 17

2.1.4. Ejemplos de sistemas ADAS de un vehículo de autonomía nivel 1. . . . . . . . . . 18

2.1.5. Mercedes-Benz Clase E con Drive Pilot. . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1.6. Coche autónomo de Google de nivel 4. . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.7. Flota de vehículos del Programa AUTOPIA. . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.1. Sistema de navegación comercial de TomTom. . . . . . . . . . . . . . . . . . . . . . 22

2.2.2. Sistema de navegación comercial de Garmin. . . . . . . . . . . . . . . . . . . . . . 23

2.2.3. Sistema de navegación utilizando realidad aumentada. . . . . . . . . . . . . . . . 23

2.2.4. Logo de OSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.5. Google Maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.6. Waze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.7. Here WeGo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.8. MapFactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.9. OsmAnd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.10. iOnRoad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.1. Simulación del paquete de datos del vehículo. . . . . . . . . . . . . . . . . . . . . . 32

3.1.2. Ventana correspondiente al visualizador del LCM. . . . . . . . . . . . . . . . . . . 33

3.1.3. Visualizador de datos y estadisticas del canal GPSALL. . . . . . . . . . . . . . . . . 33

IX

ÍNDICE DE FIGURAS

3.2.1. Aplicación de prueba para la comunicación LCM. . . . . . . . . . . . . . . . . . . . 34

4.1.1. Herramienta online de OSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.2. API de OSM para la modificación de un elemento. . . . . . . . . . . . . . . . . . . 40

4.3.1. Android Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4.1. Ícono de la aplicación GPS AUTOPÍA. . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4.2. Cálculo del bearing entre dos puntos. . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4.3. Aplicación GPS AUTOPÍA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4.4. Boceto del diseño de la aplicación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4.5. Diferentes representaciones de la vía. . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.4.6. Paso de la actividad principal de OsmAnd a la de Autopia Route. . . . . . . . . . 51

4.4.7. Colocación de los botones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.4.8. Colocación de las alarmas y avisos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.4.9. Alertas de alarmas captadas por el sistema de percepción del vehículo. . . . . . 53

4.4.10. Alertas de alarmas captadas por el tratamiento del mapa. . . . . . . . . . . . . . . 53

4.4.11. Autopia Route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1. Envío de alarmas mediante LCM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.1. Ruta de navegación seleccionada para la validación (girada 90◦). . . . . . . . . . 59

5.2.2. Inicio de la aplicación Autopia Route. . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2.3. Captura de la aplicación Multicast Tester. . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.4. Alarma de velocidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2.5. Alarma de exceso de velocidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.6. Alarma de señal de semáforo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.7. Alarma de señal de ceda el paso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.8. Alarma de señal de STOP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.9. Alarma de señal de peatón. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2.10. Alarma de señal de cruce con vehículo por la derecha. . . . . . . . . . . . . . . . . 64

5.2.11. Cambio de visualización de la pantalla. . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.12. Llegada al destino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

X

Capítulo 1

INTRODUCCIÓN

En la actualidad, la investigación en el campo de los sistemas inteligentes de transporte(ITS, del inglés Intelligent Transportation System), ha aumentado debido a su versatilidad yadaptabilidad; liderando el desarrollo de varios Sistemas Avanzados de Asistencia al Conductor(ADAS, del inglés Advanced Driver Assistance System). Estos sistemas están diseñados paramejorar la experiencia y la seguridad de todos los pasajeros. El objetivo principal es ayudaral conductor, ya sea de forma parcial o total, advirtiendo sobre las circunstancias inesperadasque pueden llevar a situaciones de riesgo como la salida involuntaria del carril o la proximidada otros vehículos.

La seguridad es un aspecto crucial en el desarrollo de sistemas autónomos, siendo el principalobjetivo de los fabricantes de automóviles y grupos de investigación en el campo. Entrelos diferentes ADAS existentes en el mercado destaca: el control longitudinal (acciones delacelerador y del pedal de freno) y el lateral (acción en el volante). El primero sobresale porel Adaptive Cruise Control (ACC) que ajusta la velocidad según el vehículo precedente omantiene una velocidad establecida [1] [2]; y el City Brake Control (CBC), que es un sistemade seguridad activa que reconoce la presencia de vehículos u obstáculos frente al coche,evitando colisiones a baja velocidad o deteniendo el vehículo automáticamente cuando elconductor no reacciona [3] [4]. En relación con el control lateral, los más significativos sonel Lane Keeping Assist (LKA) que utiliza una videocámara para reconocer las líneas del carrily, si el coche se desvía involuntariamente, el sistema corrige la trayectoria para mantener alvehículo dentro del carril [5]; y el Sistema de Estacionamiento Automático (APS), que realizala maniobra de estacionamiento de forma completamente autónoma [6] [7]. Todos estossistemas desempeñan un papel importante en la mejora de la seguridad activa del vehículo yla estabilidad. A pesar de estas importantes contribuciones a la automatización del transportepor carretera, todavía queda mucho camino por recorrer antes de que los vehículos totalmenteautónomos circulen por la vía pública.

Este trabajo se enmarca dentro del programa AUTOPÍA del Centro de Automática y Robótica(CAR) de la UPM y del Consejo Superior de Investigaciones Científicas (CSIC), que desarrolla lainvestigación de vehículos autónomos desde 1998. Las diferentes publicaciones de este grupoen medios prestigiosos, demuestran su experiencia en la investigación de sistemas que permitenel avance en el desarrollo de los vehículos autónomos, como por ejemplo, el diseño de control

11

CAPÍTULO 1. INTRODUCCIÓN

avanzado, la localización, la planificación de la ruta, la navegación, la comunicación entre elvehículo y el conductor, etc.

1.1 Motivación del proyecto

Como se ha expuesto antes, el desarrollo de los sistemas de ayuda a la conducción ha permitidocontrolar los vehículos de forma adecuada y segura. Sin embargo, pese a que estos sistemasinteligentes acercan a la idea de la conducción 100% autónoma, aún no se alcanzado el nivelde exigencia necesaria para una autonomía completa como se ha demostrado con los casosde Tesla [8]. Es por esta razón por la que se ha querido desarrollar un sistema que permitaayudar al conductor para saber y estar atento a las diferentes circunstancias que lo rodeandurante todo el trayecto, usando una interfaz de usuario intuitiva y amigable. Así pues, se hapropuesto un planificador de alto nivel de la ruta a modo de un navegador comercial. Además,tiene la intención de servir de apoyo a un planificador de más bajo nivel para proporcionarleunos rasgos de velocidad, formando un perfil de conducción con características de la rutaque pueden influir en la conducción en tiempo real. La parte de la navegación se ha basadoen la integración con el sistema de localización GPS del coche, de tal forma que, según lainformación proporcionada, se calcula o recalcula la ruta.

Por lo tanto, la motivación para el desarrollo de este proyecto es la aportación de unaherramienta indispensable, que permita la circulación segura y autónoma del vehículo y, ala vez, proporcionar una interfaz con el conductor para que se pueda especificar el destino,cambiarlo si es necesario y observar el desarrollo de la navegación analizando con detalle loque sucede a su alrededor.

Desde un punto de vista global del proyecto, con este sistema, se consigue una mayor comodi-dad y seguridad a todos los pasajeros del vehículo. Además, proporciona una conducción máseficiente por la generación de un perfil de conducción menos agresivo, y por la optimizaciónde la ruta.

1.2 Objetivo del trabajo

El objetivo del proyecto es el desarrollo de un sistema de navegación para vehículos autóno-mos, es decir, la creación del planificador y navegador de alto nivel del coche. Entrando másen detalle, el proyecto de basa en la utilización de OpenStreetMap para la navegación y eldesarrollo de una interfaz de usuario que facilite la introducción de los datos de navegación yla visualización del recorrido.

OpenStreetMap es un proyecto colaborativo de creación y edición de mapas, y de acceso libre atoda su información. Su utilización en este proyecto no se basa únicamente en utilizarlo comoun navegador comercial con todas sus características (cálculo óptimo de trayectoria, interfazgráfica que permite visualizar al usuario el mapa y la posición actual, así como permitirlela interacción con el sistema, recálculo de la ruta si es necesario, etc.), sino que también sepretende que actúe como intermediario con los sistemas de bajo nivel. En otras palabras, la

12 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM)

INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP

información recopilada del mapa se envía al planificador del vehículo para que éste genere unperfil de conducción que se ajuste a las condiciones de la ruta en cada tramo, por ejemplo,la generación de un perfil de velocidad que no se contradiga con la información obtenida delmapa y la adquirida por los sensores del coche.

Para alcanzar este objetivo se han establecido un conjunto de hitos intermedios que estructurany facilitan la consecución del proyecto.

1. Familiarización con la comunicación utilizada en el vehículo.

a) Conocimiento del Lightweight Communications and Marshalling (LCM).

b) Conseguir la itinerancia de datos entre la tablet y el ordenador mediante LCM.

2. Estudio y familiarización con la aplicación OsmAnd, que permite la interacción con elconductor, especificando el destino y mostrando el recorrido del vehículo en el mapa.

a) Estudiar todas las posibilidades que ofrece la aplicación OsmAnd.

1) Utilización del proyecto OpenStreetMap.2) Empleo de su algoritmo de cálculo de rutas.3) Proyecto de código libre.

b) Seleccionar las actividades útiles para el desarrollo de la aplicación deseada.

3. Adaptación de la aplicación OsmAnd para el desarrollo del proyecto.

a) Diseño y creación de la actividad referida a la alarma de situaciones para el conduc-tor.

4. Simulación del funcionamiento de la aplicación.

a) Validar la aplicación.

1) Correcta lectura y envío de los datos.2) Correcta aparición de las advertencias con respecto a las diferentes situaciones

consideradas.

5. Validación de la aplicación.

a) Validar el sistema en modo de conducción manual.

1) Correcto funcionamiento de la interfaz gráfica.2) Generación de perfiles de conducción correctos.

6. Otros.

a) Adaptabilidad del sistema para la incorporación de información en el futuro.

VACA RECALDE, MYRIAM ELIZABETH 13

CAPÍTULO 1. INTRODUCCIÓN

Dichos objetivos se desarrollaran de acuerdo al siguiente el cronograma.

Figura 1.2.1 Cronograma del proyecto.

1.3 Organización del proyecto

El presente trabajo se estructura por los siguientes capítulos que se definen a continuación.

1. Capítulo 1. IntroducciónEn este apartado se explica por qué surge el proyecto, en que se basa a grandes rasgos ycuáles son los objetivos a cumplir.

2. Capítulo 2. Estado del arteEn este capítulo se introduce el concepto de ITS y se destacan los principales puntos tec-nológicos que han permitido el desarrollo de los coches autónomos hasta la actualidad.Además, se revisan los sistemas de planificación, los navegadores GPS comerciales exis-tentes y los hechos más influyentes que permitieron su desarrollo. También se explicaránlos mapas digitales y se introducirá OpenStreetMaps. Por último, se expondrán algunasde las actuales aplicaciones de navegación móviles.

3. Capítulo 3. Diseño de la interfazEn este capítulo se expondrán detalles de OpenStreetMaps, en especial se definirá elformato del mapa, la definición de dicha información, que servicios ofrece, etc. Posterior-mente se presentará el software de programación utilizado para el diseño y desarrollode la interfaz. Por último, se explicarán las ideas iniciales del diseño de la interfaz, eldesarrollo que se ha llevado a cabo para su elaboración y el resultado final obtenido.

4. Capítulo 4. Comunicación con el VehículoEn este capítulo se explica la comunicación que tiene el vehículo y como se ha logrado laconexión entre éste y la aplicación en la tablet.

5. Capítulo 5. Validación y resultadosEn este capítulo se explicarán con detalle las diferentes situaciones simuladas y se demos-trará el correcto funcionamiento de la aplicación realizada.

6. Capítulo 6. Conclusión y futuros trabajosFinalmente en este capítulo se exponen las conclusiones a las que se han llegado, lasmejoras y futuros trabajos que se pueden llegar a realizar en el futuro.


Capítulo 2

ESTADO DEL ARTE

Desde el punto de vista de los vehículos terrestres, durante el último siglo se ha avanza-do en el desarrollo de sistemas cada vez más eficientes para la ayuda a la conducción,permitiendo de esa forma estar un paso más cerca de conseguir vehículos totalmente autó-nomos. El principal motivo para el desarrollo de estos sistemas se centra en la búsqueda dela seguridad de los pasajeros pues, la alta utilización de los automóviles ha desembocadoen un aumento de accidentes que se cobran un número considerable de vidas cada año [9] [10].

El presente proyecto se basa en la creación de un navegador para coche autónomo, por ello, eneste capítulo se revisarán los avances más significativos de los ITS, el grupo de investigaciónAUTOPÍA, al que pertenece este proyecto, y los métodos de ayuda en la navegación como GPScomerciales, mapas digitales, aplicaciones de navegación, etc. Por otro lado, también se expli-carán las razones que llevaron a la elección de la utilización de OpenStreetMap y las diferentesaplicaciones que lo usan, hasta llegar a la aplicación en la que se basa el proyecto.

2.1 Sistemas inteligentes de transporte

Se puede definir un ITS como todas aquellas infraestructuras y vehículos a los que se les integratecnología avanzada de comunicación e información, con el fin de mejorar la sostenibilidad,seguridad y movilidad del transporte [11] [12] [13]. Enfocando esta definición a los sistemasde transporte terrestre, el desarrollo de estos vehículos se centra en obtener una infraestructurade transporte eficiente, es decir, con menos tráfico, reduciendo los accidentes en las vías,obteniendo un consumo bajo de energía y reduciendo las emisiones de dióxido de carbono(CO2).

Por lo tanto, se puede proceder a la definición de vehículo autónomo ya que es en este tipode automóvil en el que se centra este proyecto. Un vehículo autónomo es un ITS dotado decierta inteligencia, que es capaz de desplazarse de manera controlada a un destino específico,sin intervención humana. La idea de esta concepto no es actual, siendo uno de los primerosacercamientos con el vehículo autopropulsado de Leonardo Da Vinci (ver Figura 2.1.1). Sinembargo, no fue hasta comienzos del siglo XX, cuando se desarrollaron modelos más orientadosa este fin.

15

CAPÍTULO 2. ESTADO DEL ARTE

Figura 2.1.1 Vehículo autopropulsado de Leonardo Da Vinci.

Como punto de partida aparece la feria mundial Futurama en 1939, organizada por GeneralMotors, en donde se presentó un modelo en miniatura de carreteras que proporcionabanenergía a los coches y los controlaban mediante radiocontrol [14] como se muestra en la Figura2.1.2.a. En la mitad del siglo XX, el laboratorio de Transporte y carreteras del Reino Unidoutilizó cables magnéticos en las carreteras para controlar un Citroen DS mientras circulaba auna velocidad de 130 km/h aproximadamente, manteniendo constante su perfil de velocidady su recorrido. A finales de este siglo, la Universidad de Múnich diseñó una furgoneta que,mediante visión artificial, fue capaz de circular por calles sin tráfico a unos 60 km/h (verFigura 2.1.2.b) [14].

Figura 2.1.2 Ejemplos del avance tecnológico sigo XX.



A principios del siglo XXI apareció el DARPA Grand Challenge, desarrollado por la Agenciade Proyectos de Investigación Avanzada de Defensa (DARPA del inglés Defense AdvancedResearch Projects Agency). Este evento se basaba en una carrera de vehículos autónomos, quedebían llegar desde un punto de los Estados Unidos hasta otro sin intervención humana ydisponiendo únicamente de un listado de puntos intermedios entre el principio del circuito yel final. Cabe destacar que en la primera edición del DARPA, en el desierto del Mojave, ningúncoche consiguió terminarlo. Sin embargo, en 2005 varios vehículos lograron terminar elcircuito y, en ediciones posteriores se realizó la competición en un circuito urbano aumentandoasí el nivel de dificultad.

Actualmente todos los fabricantes incorporan sistemas inteligentes en los vehículos, poniendoa disposición del usuario mejoras y facilidades en la conducción que aumentan su seguridady facilidad. Así mismo, grandes compañías actuales han apostado por este tipo de movilidad ydestacan por sus proyectos como Google y Tesla (ver Figura 2.1.3). Cada una de estas empresastienen un enfoque distinto. Google apuesta por un coche totalmente autónomo mientras queTesla está desarrollando un nivel de autonomía menor con su sistema Autopiloto que requierede la supervisión del conductor.

Figura 2.1.3 Ejemplos de vehículos modernos de alta autonomía.

2.1.1 Niveles de autonomía

Un punto importante a tener en cuenta a la hora de hablar sobre vehículos autónomos es elnivel de autonomía, pudiendo clasificarse en 5 niveles, explicados a continuación.

• El nivel 0, donde el coche no tiene ningún sistema automatizado que le permita tomarel control, sólo tiene sistemas que emitan alguna advertencia. En este nivel entran todocoche convencional, moderno o antiguo.

• En el nivel 1, el vehículo cuenta con algún sistema de automatización de la conducción,ya sea para el control del movimiento longitudinal o lateral, pero no los dos a la vez, porejemplo, coches con control de crucero adaptativo (ver Figura 2.1.4.a) o con la tecnologíapara mantener el coche en el carril o con aparcamiento asistido que solo actúan sobre la



dirección (ver Figura 2.1.4.b). Esto implica que el conductor sigue realizando el resto delas tareas de conducción.

Figura 2.1.4 Ejemplos de sistemas ADAS de un vehículo de autonomía nivel 1.

• En el nivel 2, el vehículo puede denominarse parcialmente autónomo ya que el controldel movimiento es tanto lateral como longitudinal. El sistema no cuenta con detección yrespuesta ante objetos y eventualidades de manera completa, por lo que el funcionamien-to del sistema sigue siendo limitado a ciertas condiciones, lo que implica que el conductordebe estar atento a todo lo que sucede. En este aspecto entran los vehículos con pilotoautomático temporal para autopista como son el Mercedes-Benz Clase E con Drive Pilot(ver Figura 2.1.5), el nuevo Nissan Qashqai con ProPilot, o el nuevo Volvo XC60 con PilotAssist, entre algún otro; los vehículos con un sistema de asistente para atascos de tráfico,como por ejemplo los nuevos SEAT Ibiza 2017 y SEAT León 2017, el nuevo VolkswagenGolf, o el nuevo Audi A3, etc. Así mismo, los coches con sistema de aparcamiento asistidoque actúa sobre la dirección y también sobre el acelerador y el freno.

Figura 2.1.5 Mercedes-Benz Clase E con Drive Pilot.



• En el nivel 3, los vehículos se denominan semiautónomos y cuentan además con deteccióny respuesta ante objetos y eventualidades de manera completa aunque el sistema siguelimitado. En este nivel el usuario debe estar preparado para intervenir si el sistema losolicita o se produce un fallo o pérdida de las condiciones de funcionamiento, pasando aser en ese momento conductor. El estándar SAE J3016 establece que si se produjese unfallo del sistema, este debe informar al usuario con tiempo suficiente por medio de unmensaje o alerta. Un ejemplo para este nivel son los coches de Tesla Model S que constande un sistema de autopiloto AutoPilot 2.0 (ver Figura 2.1.3.b).

• En el nivel 4, los coches autónomos pueden circular sin supervisión del conductor en áreasacotadas donde el coche tenga suficiente información para no depender del conductor, esdecir, el propio sistema de automatización cuenta con un sistema de respaldo para actuaren caso de fallo y poder conducir hasta una situación de riesgo mínimo. Sin embargo,sigue limitado a condiciones especificas. En este punto es donde se encontraría el cocheautónomo de Google con conductor(ver Figura 2.1.6) y prototipos de diferentes marcas.

Figura 2.1.6 Coche autónomo de Google de nivel 4.

• En el nivel 5 la conducción autónoma es completa, es decir, ya no existen condicioneslimitantes para el funcionamiento del sistema, y por tanto el vehículo puede conducir entodo momento o circunstancia. La eliminación total de las condiciones limitantes, implica-ría por ejemplo la necesidad de sistemas complementarios de localización y balizamientoen la infraestructura, como hacen los aviones para volar con el piloto automático, y queserían en el fondo sistemas inalámbricos de comunicación vehículo a vehículo (V2V) yvehículo a infraestructura (V2I). A este nivel no ha llegado ningún vehículo estrictamen-te hablando, sin embargo, el prototipo de coche autónomo de Google sin conductor seacerca bastante a este nivel (ver Figura 2.1.3.a).

En los dos últimos niveles ya no harían falta los elementos de control y manejo del vehículo(volante, pedales...) puesto que no es necesario que haya un usuario de respaldo. Sin embargo,todavía queda mucho camino por recorrer antes de conseguir vehículos que se encuentren enel último nivel.



2.1.2 AUTOPIA

En las últimas décadas, la investigación en los ITS ha adquirido una gran importancia,ofreciendo un gran numero de lineas de estudio en grupos y centros de investigación comoel Programa AUTOPIA en el que se engloba totalmente este proyecto y el cual se presenta acontinuación.

El Programa AUTOPIA es un grupo de investigación español, perteneciente al Centro deAutomática y Robótica de la UPM y del CSIC. Se fundó en 1998 y su enfoque de investigaciónabarca desde las técnicas de control de robots móviles a la conducción autónoma con el uso deinteligencia artificial con lógica borrosa. Así pues, su principal objetivo es la conducción comple-tamente autónoma de vehículos, así como el desarrollo de aplicaciones que permitan mejorarla seguridad en la conducción, principalmente en entornos urbanos y situaciones de alto riesgo.

En la actualidad, el Programa dispone de la flota de vehículos que se muestra en la Figura 2.1.7,y que está compuesta por dos furgonetas Citroen Berlingo electricas, un minibús también eléc-trico para 14 pasajeros máximo, dos Citroen C3 con motor a gasolina y un Citroen DS3 Cabrio.Es en este último vehículo donde se quiere implementar y ejecutar el presente proyecto. La ex-perimentación con estos vehículos se desarrollan de una pista dentro del recinto del centro, quereproduce un entorno urbano por lo que contiene una rotonda, semáforos, señales de tráfico...y casi todas las calles son lo suficientemente anchas como para permitir la circulación de dosvehículos ya sea en sentido contrario o en el mismo.

Figura 2.1.7 Flota de vehículos del Programa AUTOPIA.



2.2 Sistemas de navegación

Un sistema de navegación es una unidad compuesta por mapas digitalizados y la indicaciónde la posición del vehículo, creado con el fin de guiar o ayudar en la navegación. Por lo tanto,la base del navegador de un vehículo autónomo es la planificación de la ruta que ha de seguirel coche para llegar a su destino teniendo en cuenta las restricciones existentes de las vías (i.e.la dirección de la vía, el carril en el que se tiene que mantener, etc.) y los criterios de elecciónentre las rutas posibles (i.e. recorrido de menor distancia, el más rápido, el más eficienteenergéticamente).

Así pues, la información y el detalle de los mapas utilizados son muy importantes y dependientesde su utilización. Como el sistema desarrollado en este trabajo se basa en la planificación ynavegación de un vehículo autónomo, se explicarán a continuación alguno de los hechos másrelevantes en la evolución de los sistemas de planificación y navegadores comerciales paracoches, así como la descripción de los mapas digitales y la introducción del mapa con el que setrabajará en este proyecto. También se comentarán algunas de las aplicaciones de navegaciónmás utilizadas actualmente.

2.2.1 Sistemas de planificación y navegadores comerciales

Los sistemas de navegación de vehículos son dependientes de la localización por satélite, sinembargo, antes de la existencia de esta tecnología, se encontraban proyectos en desarrollocomo el DAIR del inglés Driver Aid, Information & Routing. Creado por General MotorsResearch (GMR) en 1966, el DAIR es un sistema de comunicación bidireccional que podíarecibir desde una estación la información de las vías [15]. Unos imanes en la carretera hacíanque se escuchasen en el vehículo notificaciones audibles sobre salidas próximas, velocidadeslímite e incluso como navegar para llegar a un destino, según estaba codificado en la tarjetaperforada que se utilizaba en el vehículo para su programación.

El desarrollo más importante de los sistemas con uso de satélites tuvo lugar aproximadamenteentre las décadas de 1960 y 1970. Rockwell Collins empezó a trabajar en sistemas receptoresde GPS que vendía para aviación. Posteriormente vendería estas investigaciones a empresascomo Garmin y TomTom que le trataban de dar uso en vehículos. Así mismo, en 1981,Honda trabajaba en un sistema de localización para navegación de carreteras basado en girós-copos y la estimación por Dead Reckoning [16]. Sin embargo, este sistema no llegó a producirse.

Dos años más tarde, en 1983, se aprobó el uso del GPS para fines no militares, lo que permitiócomenzar con el desarrollo de sistemas comerciales. El nuevo acceso a esa tecnología llevóa la necesidad de contar con una actualización de los mapas, lo que implicó la apariciónde mapas digitales (que se explicarán en el siguiente subapartado). En este mismo año, lacompañía Honda empieza con la creación de que se podría denominar el primer sistema denavegación mediante el uso de un modelo analógico y un acelerómetro para fijar las posiciones.Este proyecto se terminó en 1990 para aplicarlo a los coches Legend Acura y Honda Acura [17].



En 1985, la empresa ETAK presentó un sistema de mapas con pintado vectorial que sealineaba con el coche permitiendo el registro de sus giros y su visualización en el mapa. Asípues, la empresa se dedicó a la digitalización de mapas. Más tarde vendió la base de da-tos a terceros, aunque al final la empresa fue absorbida, primero por Sony y luego por TomTom.

En 1987, Toyota incluyó en el Toyota Crown un sistema de navegación en CD-ROM, populari-zando así los sistemas embebidos en los coches. Hubo grandes avances para mejorar y ampliarlas funcionalidades de estos sistemas como la asistencia por voz introducida en 1992 porToyota, la incorporación de pantallas táctiles, los indicadores de giro a giro en la navegacióndesarrollado por ComRoad AG en 1995, etc.

Además, en el año 2000 se quitaron las restricciones a los sistemas GPS, lo que implicó unaumentando de su precisión y aplicación. Un evento que cabe destacar a partir de esa fecha esla creación de un navegador capaz de prever el tráfico por la compañía Honda en 2003, esto selograba mediante la integración de la red de comunicación de la infraestructura de carreterasdel país asiático en el vehículo.

Una de las empresas que destacó en esta época fue la compañía TomTom creada Ámsterdam en1991 por iniciativa de Pieter Geelen, Peter-Frans Pauwels y Corinne Vigreux. En 2002 desarro-llaron el primer producto de navegación para PDAs, el TomTom Navigator. Un año más tardeaparece TomTom Navigator 2 con el que comenzó el desarrollo de un producto de navega-ción todo en uno y en 2004 es la primera empresa en comercializar un sistema de navegaciónportable para vehículos denominado TomTom GO (ver Figura 2.2.1)

Figura 2.2.1 Sistema de navegación comercial de TomTom.

Este último hecho, es el punto de partida para las ventas de sistemas de navegación, refirién-dose a un producto pequeño con pantalla táctil, fácil de transportar, que obedece instruccionespor voz y permite al usuario interactuar con el mapa en todo momento.

En 1989 se funda Garmin Ltd., con sede en George Town (Islas Caimán), por Gary Burrel y MinKao. Esta empresa desarrolla y fabrica dispositivos de GPS principalmente para el transporteterrestre aunque también producen para el naval o aéreo (ver Figura 2.2.2). A nivel mundialcompiten directamente con la empresa TomTom.



Figura 2.2.2 Sistema de navegación comercial de Garmin.

Existen otras marcas como EasySMX, Noza tec, Becker, Hieha, entre otras que también pro-ducen estos dispositivos, sin embargo no son tan conocidas ni exitosas como TomTom y Garmin.

Desde el lanzamiento de este producto, se han ido añadiendo elementos adicionales queayudan a la navegación dando más información al usuario o facilitando su interacción con eldispositivo, por ejemplo, alertas de velocidad, predicción de la hora de llagada, aviso de laposición de radares fijos, navegación manos libres, sistema de reconocimiento de voz...

La búsqueda de una mejor interfaz de usuario tiene un gran peso ya que debe ayudar al con-ductor a tener un mayor entendimiento de las indicaciones mediante tecnologías como alertasde sonido, realidad aumentada en el parabrisas del vehículo, etc. Ejemplos de estos avancesse pueden observar en la Figura 2.2.3, en donde se observa el desarrollo del sistema AR-HUD(del inglés Augmented Reality Head-Up Display) por la firma Continental o el accesorio HUDde Garming en la que el propio dispositivo GPS es el que proyecta en el parabrisas la informa-ción recibida de un smartphone con Bluetooth que esté ejecutando aplicaciones como GarminStreetPilot, NAVIGON.

Figura 2.2.3 Sistema de navegación utilizando realidad aumentada.



Actualmente las investigaciones y avances se basan en la unificación de estos sistemas de nave-gación con los vehículos y la comunicación entre sí. La búsqueda y desarrollo de esta tecnologíaen el mundo automovilístico, ha permitido unificar los cuadros de instrumentos convenciona-les con avances tecnológicos como la realidad aumentada. Estos desarrollos permiten mostrarla información más relevante al conductor de forma más sencilla, directa y en tiempo real,aumentando la seguridad ya que no es necesario apartar la vista de la carretera.

2.2.2 Mapas digitales

Un mapa digital es un conjunto de datos almacenados en un ordenador, que representanuna formación espacial mediante elementos gráficos organizados en capas, con el objetivode una representación geográfica bidimensional o tridimensional que se plasma por pantalla.Al igual que los mapas clásicos, estas representaciones digitales tienen propiedades métricas(medir distancias, ángulos, tienen escala) con la singularidad de que se puede realizar elzoom con el fin de acercarse y ver con más detalle una zona, o alejarse para tener unaperspectiva más global. Además de la información gráfica que se visualiza, un mapa con-tiene muchos más datos dependiendo de la finalidad del mapa y el nivel de detalle que serequiera. En el caso de este proyecto, el mapa que se precisa necesita tener información de lasvías de circulación de los vehículos, las restricciones y propiedades de cada calle, las señalesde tráfico, pasos de peatones que se encuentran en el recorrido del coche, lugares de interés, etc.

Existen dos tipos de mapas digitales, los mapas raster o mapas de bits que son una imagenformada por una gran matriz de píxeles por lo que se suelen usar en el campo o en cartas denavegación y los mapas vectoriales en los que nos centraremos pues son los que se utilizarán eneste proyecto. Este tipo de mapas están representados por vectores o ecuaciones matemáticas,que se ven en la pantalla mediante figuras geométricas para formar la imagen. Gracias a estaforma de representación, estos mapas requieren de pocos recursos de almacenamiento y no sedeforman en los cambios de escala (Zoom+ o Zoom-), es por ello por lo que son los utilizadosen los GPS de coche como TomTom, Garmin, GoogleMaps, OpenStreetMaps, Waze, etc.

Una vez definidos los mapas digitales, procederemos a la presentación de la opción comercialque se va a utilizar en este proyecto y la justificación de su elección.

2.2.2.1 OpenStreetMap (OSM)

OpenStreetMap (OSM) es un proyecto colaborativo con el fin de crear mapas libres, editablesy detallados de todo el mundo por medio de su comunidad de usuarios, sin restricciones deningún tipo. Los mapas y datos almacenados en su base de datos se distribuyen bajo licenciaabierta y se crean utilizando información geográfica capturada con dispositivos GPS móviles,ortofotografías y otras fuentes libres [15].

En el último sondeo realizado en noviembre de 2017, el proyecto contaba con 4200000 deusuarios aproximadamente y creciendo [18]. Los registrados pueden subir sus trazas desdeel GPS, crear y corregir datos vectoriales mediante herramientas de edición creadas por lacomunidad OpenStreetMap. La información que se puede añadir es muy diversa pues no sólo



se amplían las vías sino que además se pueden colocar pistas, caminos, puntos de interés,señales de tráfico, velocidades, etc. Por lo tanto, el tamaño de la base de datos se situaba enjulio de 2017 por encima de los 800 gigabytes.

OSM se creó en julio de 2004 por Steve Coast debido a los altos precios que pedía la agenciacartográfica de Gran Bretaña, Ordance Survey, por la información geográfica. Su logo es el quese visualiza en la Figura 2.2.4. Desde una perspectiva global, se podría decir que OSM surgiódebido a que, en la mayoría de los países, la información geográfica no es de uso libre por loque el usuario normalmente paga por la información. Por otro lado, las licencias de uso a veceslimitan la utilización del usuario además de que, si la información no es del todo acertada, nose puede modificar directamente o añadir nuevos datos.

Figura 2.2.4 Logo de OSM.

Cabe destacar que, en los últimos años, empresas como TomTom o Google han creadoiniciativas comerciales parecidas como MapShare o Map Maker respectivamente. Sin embargo,la gran diferencia con OSM se basa en que en estos servicios los usuarios no tienen derechoalguno sobre la cartografía o los datos que han añadido o editado, sus contribuciones pasan aser de la empresa. En cambio, OSM reconoce estas aportaciones como propias del usuario yno se limita a ciudades principales, pudiendo añadir la cartografía de poblaciones pequeñas.Sin embargo, es un proyecto que aún está en desarrollo pues su información es ampliable y lacobertura de zonas no es equitativa ya que hay territorios con información insuficiente.

OSM es un proyecto utilizado por bastantes organismos importantes como la Universidad deOxford (diciembre del 2007), Wikimedia (abril del 2009), el Centro Común de Investigaciónde la Comisión Europea, el Banco Mundial, Foursquare, etc.

En definitiva, se ha elegido la utilización de OSM en este proyecto debido a que permite ellibre trabajo con datos cartográficos detallados y editables de grandes y pequeñas poblaciones,permitiendo un empleo más ágil, amplio y completo de los datos necesarios para este trabajo.Además, este proyecto da la facilidad de trabajar con las señales de tráfico indicados en susmapas y permite la adición de estos si no se encuentran. En el capítulo 4 se detallarán loselementos que lo componen y sus definiciones.



Por otro lado, como se iba a aplicar OSM en una aplicación Android, y con el fin de no partirde cero, se procedió a revisar las aplicaciones que principalmente usan OSM, incorporan elenrutamiento de la navegación y tengan el código a disposición del público. Entre las quese encuentran enumeradas en la wiki correspondiente1 se analizaron Navmii2, OsmAnd,MAPS.ME3 y ZANavi4. Finalmente se decidió por OsmAnd ya que era la que cumplía con losrequisitos mencionados antes.

A continuación se explicarán las aplicaciones de navegación más destacadas y utilizadas actual-mente así como la que se utilizará en el proyecto.

2.2.3 Aplicaciones de navegación y mapas

El dispositivo móvil se ha convertido en un complemento indispensable para las personas. Es-te hecho ha producido el desarrollo de aplicaciones que cubran la necesidad de sistemas denavegación sin tener que comprar otro dispositivo. Así pues, desde este punto de vista, se des-cribirán por encima algunos de los mejores navegadores GPS para Android que se encuentranactualmente en el mercado.

1. Google Maps es la aplicación de navegación y mapas más utilizada ya que viene de serieen la mayoría de los dispositivos, con lo que no se requiere de la instalación de otroprograma para obtener un navegador GPS gratuito y completo. Una gran ventaja de estesistema es que consta de alertas del tráfico a tiempo real y el recálculo automático dela ruta para evitar atascos. Además, permite el cálculo de rutas tanto en coche como apie, bicicleta, taxi y transporte público (autobuses, metro, tren...) como se visualiza en laFigura 2.2.5. Sin embargo, no se puede usar la navegación sin conexión de datos.

Figura 2.2.5 Google Maps.

1http://wiki.openstreetmap.org/wiki/Android2http://wiki.openstreetmap.org/wiki/Navmii3http://wiki.openstreetmap.org/wiki/MAPS.ME4http://wiki.openstreetmap.org/wiki/ZANavi



2. Waze es el navegador GPS más descargado después de Google Maps. Se trata de unaaplicación que permite a los usuarios conductores compartir la información del tráficoy de la carretera en tiempo real ahorrando tiempo y combustible. Esta aplicación utilizamapas de Google y unicamente permite los desplazamientos en coche, es gratuita perorequiere de conexión de datos para funcionar correctamente.

Figura 2.2.6 Waze.

3. Here WeGo es una aplicación que rivaliza bastante con Google Maps, ya que permitecalcular las rutas a coche, pié, bicicleta y transporte público (tanto autobuses, metro,taxi...), sin necesidad de conexión de Internet. Su interfaz gráfica es muy fácil de usar,además, muestra el tráfico en tiempo real e información sobre incidencias (ver Figura2.2.7).

Figura 2.2.7 Here WeGo.

4. MapFactor es una de las aplicaciones de navegación más descargadas y valoradas pese



a que tiene una interfaz desfasada como se puede observar en la Figura 2.2.8. Funcionacompletamente sin conexión a Internet, utiliza mapas libres del proyecto OpenStreetMapy permite comprar los mapas de TomTom. Pese a que su descarga es gratuita, se debepagar para utilizar algunas funciones como los mapas de TomTom o la Head Up Displayque permite ver las indicaciones reflejadas en el parabrisas y eliminar los anuncios.

Figura 2.2.8 MapFactor.

5. OsmAnd es una aplicación de navegación de código abierto (open source) aunque tieneproductos de pago. Trabaja con la totalidad de la información de OpenStreetMap. Entresus principales características destacan el funcionamiento con y sin conexión, las indica-ciones por voz, las indicaciones de carril, el soporte de puntos intermedios en la trayec-toria y el recálculo automático de ruta como se puede visualizar en la Figura 2.2.9. Estaaplicación es la escogida en este proyecto y se explicará con más detalle en el siguientecapítulo.

Figura 2.2.9 OsmAnd.



6. Otras aplicaciones son Maps.me, Sygic, CoPilot GPS, GPS Navigation (BeOnRoad), MagicEarth Pro Navigation, TomTom.

Por otro lado, hay aplicaciones que no se han diseñado para la navegación como las anteriores,sino que se desarrollan como ayuda en la conducción. Un ejemplo de esta es la aplicacióniOnRoad, creada para mantener la distancia y alertar al conductor cuando está demasiadocerca o la probabilidad de impacto (ver Figura 2.2.10). Es una aplicación de seguridad en laconducción que utiliza la cámara y el GPS del móvil para detectar una posible colisión con elvehículo de delante mediante realidad aumentada.

Figura 2.2.10 iOnRoad.

Así pues, la aplicación que se quiere desarrollar en este proyecto es una unión entre las dosideas anteriores definidas, es decir, obtener un sistema de navegación pero que además alerteal conductor de diferentes situaciones que requieran de su atención como la detección de unsemáforo en rojo, un peatón, otro coche en un cruce, etc.


Capítulo 3

SISTEMA DE COMUNICACIÓN

La investigación en este tipo de vehículos otorga un gran peso a la comunicación ya que, lainteracción hombre máquina (H2V) es fundamental en el buen funcionamiento del sistema.Sin embargo, en este tema entra el problema de la privacidad e integridad de los datos al estarlos coches conectados, es decir, asegurar la ciberseguridad. Este es el motivo por lo que sebusca una comunicación robusta y segura.

En este apartado se definirá el mecanismo de comunicación que se utiliza en los proyectos delgrupo AUTOPIA así como la aplicación que se diseñó para la prueba del correcto funcionamientode la comunicación entre la tablet y los datos que simulan el vehículo.

3.1 Lightweight Communications and Marshalling (LCM)

El grupo AUTOPIA trabaja con el Lightweight Communications and Marshalling (LCM), quees un conjunto de bibliotecas y herramientas para el envío de mensajes y clasificación dedatos, dirigido a sistemas en tiempo real donde el alto ancho de banda y la baja latencia soncríticos. Fue creado por el equipo MIT DARPA Grand Challenge Team para la comunicaciónentre procesos en sistemas de tiempo real. Además proporciona un modelo de envío/recepciónde mensajes y generación automática de códigos basado en la difusión multicast de mensajesUDP (del inglés User Datagram Protocol) mediante canales de comunicación que se identificande forma única [19] [20]. En resumen, esta herramienta permite que cada proceso publiquedirectamente su información en determinados canales y se reciben los datos suscribiéndose aellos, de tal manera que en la comunicación no se utiliza un proceso central.

Por otro lado, permite una amplia posibilidad de aplicaciones en una gran variedad delenguajes de programación (C, C++, Matlab, Java...), y plataformas (GNU/Linux, OS X,Windows...). Este mecanismo de comunicación es muy eficiente, tiene codificación de al-ta seguridad en los mensajes, fácil registro y reproducción de los datos, pocas dependencias, etc.

Para la programación de la comunicación, el programa AUTOPIA tiene creada una serie delibrerías en código Java que permiten la lectura de los datos del coche y facilitan su utilización.Para la prueba de la comunicación sin necesidad de conectarse al coche, se ha utilizado unpaquete de datos de un recorrido que se puede enviar mediante esta comunicación desde un

31

CAPÍTULO 3. SISTEMA DE COMUNICACIÓN

ordenador.

Para el funcionamiento del paquete de datos grabado (log) se utiliza un ordenador del depar-tamento con sistema operativo Linux. El envío de esta información se debe cargar y poner enfuncionamiento mediante un pequeño programa que se ejecuta con las siguientes líneas de có-digo en la consola del ordenador. Hay que tener en cuenta que en la consola se debe estar enla carpeta donde se encuentra guardado el log a usar.

1 export LCM_DEFAULT_URL=udpm://239.255.76.67:7667?ttl=12 lcm-logplayer-gui ./logs/XXXX

La segunda línea corresponde a una herramienta de reproducción de datos que retransmitea la red en tiempo real la información almacenada en un fichero de registro. Esto permiteseleccionar los canales que se quieren transmitir como se visualiza en la Figura 3.1.1. Conrespecto al código, donde se ha escrito XXXX se añade el nombre del log que se utilizará.

Figura 3.1.1 Simulación del paquete de datos del vehículo.

Para verificar el correcto funcionamiento del envío de datos por LCM, este tiene una herra-mienta de inspección que descodifica automáticamente todos los datos de la red, y muestra lainformación de los mensajes mediante la ventana que se muestra en la Figura 3.1.2. Ademásde esto, este software permite visualizar estadísticas de cada canal, su consumo de ancho debanda y el número de mensajes transmitidos (ver Figura 3.1.3). Para la visualización de estainformación se utiliza una consola secundaria y el código que se adjunta a continuación.



1 export CLASSPATH=./autopia_lcm/autopia_lcm.jar2 lcm-spy

La dirección que se coloca en la primera línea se corresponde a la localización del archivo .jar.

Figura 3.1.2 Ventana correspondiente al visualizador del LCM.

Figura 3.1.3 Visualizador de datos y estadisticas del canal GPSALL.

3.2 Prueba de la comunicación LCM

Con el fin de probar la comunicación se creó una aplicación de prueba en el que se visualizaen pantalla los datos que se reciben del coche, es decir, la posición tanto en coordenadasgeométricas (latitud, longitud y altura) como en coordenadas UTM (X, Y, Z en metros); lavelocidad del coche, la aceleración y en la zona de Lectura se visualiza el canal de datosque se recibe en ese momento. Esta aplicación de prueba se representa en la Figura 3.2.1y se corresponde a una captura de la aplicación recién abierta (a la izquierda) y otra enfuncionamiento mientras se reciben los datos del LCM (a la derecha).


CAPÍTULO 3. SISTEMA DE COMUNICACIÓN

Figura 3.2.1 Aplicación de prueba para la comunicación LCM.

Cabe destacar que, para el correcto funcionamiento de comunicación, se requiere que tantola tablet como el ordenador se encuentren conectados a la misma red ya que por ahora, lacomunicación entre ambos dispositivos se realiza mediante conexión inalámbrica WiFi.

3.2.1 Modo de programación del LCM

Las funciones diseñadas para esta aplicación se han intentado hacer lo más genéricas posiblespara ser utilizadas tanto en la app final como en futuras que requieran también de esta co-municación. Se creó una clase denominada LCMhandler en cuyo constructor se conecta al IPMulticast y al puerto utilizado mediante el LCM. Así mismo, se abre la suscripción a todos loscanales que reciba. Todo esto queda reflejado en las siguientes líneas de código.

1 this.mylcm = new LCM("udpm://239.255.76.67:7667?ttl=1");2 this.mylcm.subscribe(".*", this);

Por otro lado, dentro de esa clase se crearon una serie de funciones, una de lectura de losdatos provenientes del vehículo y una función de envío por cada canal necesario.



Desde un punto de vista más profundo en la programación, se debe tener en cuenta que todoslos componentes de la aplicación Android (actividades, servicios, broadcast receivers...) serealizan en el mismo hilo de ejecución denominado main thread o GUI thread junto a lasoperaciones que gestionan la interfaz de usuario de la aplicación. Debido a esto, si se va aejecutar una operación larga o costosa, este hilo se bloquearía deteniendo la ejecución delresto de los componentes y de la interfaz, creando fallos, un funcionamiento lento e inclusodejando la aplicación inutilizable.

Por otro lado, Android monitoriza las operaciones realizadas en el hilo de ejecución y, cuandoéstas superan un tiempo de aproximadamente cinco segundos, aparece el mensaje ApplicationNot Responding (ANR) obligando al usuario a esperar a que termine el proceso sin asegurarque esto pase o forzar el cierre de la aplicación. Como crear y realizar la comunicación LCMes un proceso de larga duración, ya que tiene que estar activo continuamente, se requieresu ejecución en segundo plano; esto implica crear y utilizar un nuevo hilo mediante la claseAsyncTask proporcionada por Android, dejando así el main thread libre.

La representación de los datos del LCM en cada uno de los campos asignados correspondea una tarea duradera por lo que, para su programación se creó una clase denominada Asyn-task_messageread y hereda de la clase AsyncTask que permite realizar fácilmente operacionesen segundo plano y publicar resultados en el subproceso de la interfaz de usuario. Las funcionesque se han sobrescrito son doInBackground que contiene el código principal de la tarea y onPro-gressUpdate que se ejecutará cada vez que se llama al método. Así pues, en la primera función,que es la única que corre en un hilo secundario, se crea uno con el código que se muestra acontinuación.

1 publishProgress();2 try {3 Thread.sleep(500);4 } catch (Exception e) {5 android.util.Log.e(TAG, e);6 }

Finalmente, en la segunda función se colocan los valores en la interfaz de usuario, ya que setiene acceso directo a ellos al ejecutarse en el hilo principal, y se igualan a los valores recibidosdel LCM.

Una vez analizado el método de comunicación LCM y verificado con éxito la prueba de conexiónentre los dos dispositivos, se procede al desarrollo de la aplicación objetivo de este proyecto.


Capítulo 4

DISEÑO DE LA INTERFAZ

La comunicación del vehículos con el usuario siguen siendo un factor de gran relevancia. Lainteracción entre conductor y vehículo (H2V) se realiza a través de medios informativos como:sistemas de realidad virtual incorporados en el parabrisas o salpicadero, anuncios en pantallao sistemas de voz. Dentro de este marco, el presente proyecto plantea el diseño de una interfazorientada a informar al usuario de las acciones de conducciones durante el recorrido y lasseñales que se encuentra a su paso.

En este capítulo se explicará con detenimiento los detalles del diseño y modificaciones realiza-das para llegar a la aplicación final. Por ello, primero se definirán las principales característicasde OSM, los elementos que contiene, su organización y aspectos relevantes que se requieranconocer para su apropiada utilización en el proyecto. Después se explicará con más detalle laaplicación de OsmAnd. Posteriormente se presentará el software de programación utilizado yfinalmente, se describirá la interfaz programada y los diferentes pasos que se realizaron parasu desarrollo.

4.1 OpenStreetMap

Como ya se introdujo OSM en el capítulo 2, se procederá a la descripción detallada de sufuncionamiento y de los componentes que lo forman. OSM consta de una API online (ver Figura4.1.1) que permite al usuario navegar por el mapa, descargar la zona del mapa visualizada,observar la información y modificar los elementos y capas que constituyen el mapa. Por otrolado, esta herramienta también permite al usuario planificar una ruta y representarla de formaonline en el mapa con las indicaciones necesarias del trayecto. Así mismo, se pueden importaro compartir trazas de datos GPS que se han tomado para describir caminos específicos. Todaaportación de los usuarios aumenta la precisión de la información y su fiabilidad a la hora deutilizar esta herramienta.

Como se puede observar en la Figura 4.1.1, el mapa contiene formas que definen las zonasurbanas (edificios, calles, plazas...), señales de tráfico como semáforos, indicadores de lugaresimportantes (cafeterías, farmacias, iglesias...), y restricciones en cada vía como son las pequeñasflechas que señalan el sentido de las calles. Todas estas representaciones se realizan mediantelos componentes básicos de OSM que se describen a continuación.

37

CAPÍTULO 4. DISEÑO DE LA INTERFAZ

Figura 4.1.1 Herramienta online de OSM.

El mapa de OSM se organiza con tres componentes principales que forman el núcleo del modelode datos, los nodos, las vías y las relaciones. La definición de estos elementos define la organiza-ción de toda la información y la adición de otras propiedades u otros detalles. Otra característicafundamental son las etiquetas, que se utilizan para describir las propiedades asignadas a cadaelemento.

1. Un nodo es un elemento puntual que se define por su posición, refiriéndose en latitud,longitud y algunos también altitud, un número de identificación (ID), y una etiqueta quese añade para especificar otras propiedades como el nivel en edificios o la capa en víasde distintas alturas, cruces o puentes. Los nodos se usan principalmente para agruparloscon el fin de definir elementos mayores como las vías. Así mismo se pueden utilizar paradefinir características puntuales en el mapa. Un dato curioso es que el identificador esúnico e incluso, cuando un nodo se elimina, su ID no vuelve a reutilizarse.

2. Una vía es una lista de nodos ordenada definida por etiquetas y sirven para determinarcarreteras, caminos, edificios, ríos, etc. Cada vía tiene que estar definida por al menos dosnodos llegando a un máximo de 2000. Al igual que los nodos, las vías tienen un númerode identificación único. Las vías tienen la posibilidad de ser cerradas o abiertas y, en elprimer caso se les puede considerar como áreas en las que se les considera la superficieque encierran como en las plazas, o como poli-líneas en la que sólo cuenta la vía.

3. Una relación se trata de una lista ordenada de nodos, vías e incluso de otras relaciones,que define las vinculaciones físicas o lógicas entre todos ellos. Un ejemplo de su uso sonla definición de rutas de autobús, fronteras, bosques, lagos...



4. Las etiquetas definen las categorías en las que se describen las características del elementoal que van ligadas. Constan de dos campos, uno denominado key que sirve como defini-ción de la característica que se va a dotar de valor, y otro llamado value que especificael valor de dicha característica. A continuación se describirán rápidamente las etiquetasmás comunes en OSM [15].

a) Para definir el tipo de carretera y vía se utiliza highway, busway o cycleway. La pri-mera es la más utilizada y sus valores pueden ser Primary (carretera convencional),Secundary (equivalente a carreteras secundarias), Residential (para accesos a zonasresidenciales o urbanizaciones), Pedestrian (zonas peatonales), Road (cuando no es-tá claro su clasificación), Construction (para vías en proceso de construcción o enobras), entre otros.

b) La etiqueta route se define para la características de ruta a un conjunto de nodos ovías y así se asignan caminos que tienen un nombre, un origen y un destino o unafunción determinada como las rutas de transporte público.

c) Para definir número de carriles se utiliza lanes. Así mismo, a los carriles se les puedeetiquetar restricciones para la conducción.

d) Para uniones de vías o cruces se aplica la etiqueta junction y en caso de rotondas seutiliza roundabout.

e) Las designadas a las capas denominadas layer, denominan las relaciones verticalesentre los elementos en el mapa como es el caso de túneles o puentes. Sus valoresson entre -5 y 5 (de menor a mayor altura respectivamenete), pero el 0 no se utilizadirectamente ya que obtiene ese valor si la capa no existe.

f) La etiqueta level se refiere al nivel vertical pero se utilixan unicamente en el casode espacios o vias que están ligados a un edificio o construcción de varios pisos, o arampas.

g) Si se quiere definir muros o vallas o similares en el paso de una vía, se utiliza laetiqueta barrier y con la etiqueta access se especifica el tipo de acceso que tiene.

h) La definición de edificios también es importante y se realiza con la etiqueta building.Como es lógico, una etiqueta ligada a esta definición es la correspondiente a ladirección, addr. Para su correcta especificación suele ir seguida por un sufijo condos puntos y el tipo de elemento de la dirección como .addr:street" para la calleespecíficamente o .addr:full" si se define todo en un mismo campo.

i) La etiqueta emergency define un elemento relacionado con una situación de emer-gencia como una estación de policías, una boca de riego, una estación de bomberos,etc.

j) Otras etiquetas destacadas son natural para elementos naturales como bosques, la-gos, árboles...; public_transport para transporte público como autobuses con la quese especifican paradas, estaciones, etc. Sin embargo, si se trata de ferrocarriles, me-tro, funicular o tranvías, la etiqueta específica es railway. Finalmente, para trans-porte aéreo se utiliza aeroway.



Cada uno de estos componentes se pueden visualizar en la Figura 4.1.2. Como se puede ob-servar, las vías están formadas por puntos blancos correspondientes a los nodos, y los edificiosestán definidos por vías creando áreas que se etiquetan como superficies. Así mismo, a la iz-quierda de la imagen se observa la representación gráfica de las etiquetas de la vía seleccionada,definiendo la información necesaria que se requiere para la navegación como el tipo de calle,el nombre, el sentido, la velocidad...

Figura 4.1.2 API de OSM para la modificación de un elemento.

Sin embargo, esta información se codifica en el mapa de forma más básica creando un archivodel que se ha extraído un ejemplo de la definición de cada elemento para su explicación. Comose expuso anteriormente, cada constituyente se define con su identificador único, su posición,el usuario que registró la última versión de ese componente, el identificador de esta persona,etc. Por otro lado, se puede ver como el nodo identifica tanto un edificio como un árbol. En lasvías se puede apreciar que contiene la referencia de cada uno de los nodos que la constituyen,y etiquetas referentes a su velocidad máxima, su nombre, si es privada o pública, si es peatonal,etc. Como ejemplo de las relaciones se ha cogido una ruta de autobús. Por otra parte, arriba seespecifican la especificación XML UTF8 para la codificación de los caracteres, la versión de laAPI utilizada, los límites del mapa mediante coordenadas geográficas y otras especificaciones.

1 <?xml version="1.0" encoding="UTF-8"?>2 <osm version="0.6" generator="CGImap 0.6.0 (2366 ...

thorn-03.openstreetmap.org)" copyright="OpenStreetMap and ...contributors" ...attribution="http://www.openstreetmap.org/copyright" ...license="http://opendatacommons.org/licenses/odbl/1-0/">



3 <bounds minlat="40.4371000" minlon="-3.6894400" ...maxlat="40.4401800" maxlon="-3.6838600"/>

4 ...5 <node id="4787000529" visible="true" version="3" ...

changeset="53207937" timestamp="2017-10-24T13:04:35Z" ...user="johanemilsson" uid="559500" lat="40.4385456" ...lon="-3.6857430">

6 <tag k="amenity" v="embassy"/>7 <tag k="country" v="FR"/>8 <tag k="diplomatic" v="ambassadors_residence"/>9 <tag k="name" v="Residencia de Francia"/>

10 <tag k="name:ru" v="Franta Ambasador rezidenta"/>11 <tag k="website" ...

v="https://es.ambafrance.org/La-Residencia-de-Francia"/>12 </node>13 ...14 <node id="5235732372" visible="true" version="1" ...

changeset="53890407" timestamp="2017-11-18T00:55:04Z" ...user="Cuenqui" uid="3649461" lat="40.4384556" lon="-3.6877223">

15 <tag k="natural" v="tree"/>16 </node>17 ...18 <way id="554230302" visible="true" version="1" ...

changeset="55574422" timestamp="2018-01-19T10:51:46Z" ...user="sanchi" uid="170106">

19 <nd ref="100891149"/>20 <nd ref="100891150"/>21 <tag k="highway" v="primary"/>22 <tag k="lanes" v="3"/>23 <tag k="maxspeed" v="50"/>24 <tag k="name" v="Calle de María de Molina"/>25 <tag k="oneway" v="yes"/>26 <tag k="pedestrian" v="yes"/>27 <tag k="surface" v="asphalt"/>28 </way>29 ...30 <relation id="7932559" visible="true" version="1" ...

changeset="55734559" timestamp="2018-01-25T09:16:33Z" ...user="sanchi" uid="170106">

31 <member type="relation" ref="2747816" role=""/>32 <member type="relation" ref="1687770" role=""/>33 <tag k="name" v="Bus 224A: Madrid (Avenida de América) => ...

Torrejón de Ardoz (La Mancha Amarilla)"/>34 <tag k="public_transport:version" v="2"/>35 <tag k="ref" v="224A"/>36 <tag k="route_master" v="bus"/>37 <tag k="type" v="route_master"/>38 </relation>39 </osm>



Como en este proyecto se utiliza una aplicación de base que ya trabaja con el mapa y lo pro-cesa, no se requiere profundizar en el tratamiento de estos datos. OsmAnd para el cálculo detrayectoria trata toda esta información y devuelve una lista de puntos de la cual se cogen losdatos necesarios para la aplicación. Otra información que se emplea es la velocidad máxima dela vía que se define en una de sus etiquetas como se ha visto antes.

4.2 OsmAnd

En este apartado se definirá más profundamente la aplicación OsmAnd, partiendo de lapresentación realizada en el capítulo 2.

OsmAnd es una aplicación móvil de código abierto que trabaja con la totalidad de la in-formación de OpenStreetMap, con el fin de ofrecer una solución de servicio de navegacióncompleta, fácil de usar y fuera de línea [21] [22]. Este software permite el trazado de mapas,la navegación, el enrutamiento, la colocación de los puntos de interés y las funciones derastreo. El programa está muy bien refinado, es confiable, utilizado de forma global y funcionaprácticamente en todos los teléfonos y tablets con Android. Además, también se puede utilizaren unos cuantos equipos basados en Linux.

Los mapas se descargan antes de ser utilizados, sin ningún costo, incluyendo actualizacionestan frecuentes como sean necesarias. Una vez descargados los mapas, los datos se almacenande forma permanente en la memoria del dispositivo por lo que no requiere de una conexión aInternet. Esto permite el uso ilimitado sin incurrir en costosos cargos por transferencia de datos.

Lo mejor de todo es que el sistema entero es desarrollado en colaboración abierta distribuida(crowdsourcing), es decir, cualquier usuario, con un registro libre y sencillo, puede corregirerrores de OpenStreetMap, agregar datos para mejorar las definiciones de puntos de interés,reportar errores de OsmAnd o sugerir potenciales mejoras. Este aspecto es de gran importanciaya que, mientras mejor estén definidas las vías, más información se obtendrá para optimizarla navegación.

La aplicación OsmAnd admite la definición de los lugares de destino y origen mediante coorde-nadas geográficas, con la dirección, el tipo (restaurantes, gasolineras, hospitales...) o indicandoel punto deseado en el mapa directamente. Así mismo permite conocer el tiempo estimadode la llegada, guarda los lugares más importantes como favoritos, conmuta automáticamentela vista día/noche del mapa, muestra el límite de velocidad indica la distancia al destino...Muchas de estas características interesan para su utilización en la aplicación de este proyecto.

A continuación se realizará el análisis del funcionamiento de la aplicación basándose en laejecución del código.

1. Revisa la versión de Android a compilar y la versión del propio OsmAnd, es decir, revisasi se corresponde con la aplicación gratuita o la de pago (OsmAnd+).

2. Carga la configuración correspondiente a la versión identificada.



3. Revisa la conexión a Internet para actualizaciones o descargas del mapa.

4. Coloca las preferencias de la aplicación y carga el fichero de los mapas existentes en lamemoria. Si no se encuentran archivos y hay conexión a Internet, se solicita al usuariola descarga del correspondiente a su zona y, de manera opcional, la de un mapamundi.Si la aplicación no se encuentra conectada al Internet, solicita al usuario que se conectepues no puede funcionar la aplicación sin mapas.

5. Prepara los diferentes menús y visualiza el mapa preparándose para la navegación alpulsar el botón correspondiente.

6. Inicia la navegación si el usuario lo ha solicitado.

7. Al llegar al destino, se le pregunta si se quiere parar la navegación, buscar parking orecalcular la ruta, manteniéndose a la espera de una respuesta.

8. Si el usuario decide finalizar la navegación, OsmAnd se espera hasta que cierre la aplica-ción o indique otra acción en algún botón o menú.

Una vez comprendido el funcionamiento de la aplicación y estudiado el código implementado,se procede a su modificación. Para ello, se debe definir un software que facilite la programación.

4.3 Android Studio

El software utilizado para la programación de la aplicación es Android Studio. Se eligió ya quees el entorno de desarrollo integrado oficial para la plataforma Android. Además, proporcionaherramientas más rápidas y fáciles para crear apps en todos los modelos de estos dispositivos,como su herramienta de depuración, un sistema instantáneo de compilación e implementaciónprincipalmente [23]. Está disponible para las plataformas Microsoft Windows, macOS y GNU/-Linux. Este programa se anunció en el 2013 pero la primera versión estable se publicó un añomás tarde. A continuación se enumeran las principales funciones de este software que permitenaumentar la productividad durante la creación y compilación de aplicaciones.

• Potente editor de códigos que te permite identificar rápidamente los fallos y además, tesugiere modificaciones para optimizar la programación.

• Las herramientas para desarrolladores de IntelliJ.

• Un sistema de compilación basado en Gradle flexible.

• Un entorno unificado.

• Instant Run para aplicar cambios mientras la app se ejecuta sin la necesidad de compilarun nuevo APK.

• La posibilidad de integrar plantillas de código y GitHub ayudando así a compilar funcionescomunes de las apps e importar ejemplos de código.



• Facilidad para realizar control de versiones con GitHub.

• Compatibilidad con C++ y NDK.

• Renderizado en tiempo real.

Desde el punto de vista visual, su editor de diseño permite reflejar el aspecto de la aplicaciónmientras añades los componentes, también cuenta con plantillas de diseños comunes y constade un dispositivo virtual Android que se utiliza para ejecutar y probar aplicaciones como sepuede observar en la Figura 4.3.1.

Figura 4.3.1 Android Studio.

Una vez familiarizado con el entorno de programación, se procede al desarrollo de la aplicaicónfinal.

4.4 Aplicación final

Una vez estudiado a fondo las posibilidades aportadas por el proyecto OpenStreetMap, se defi-nieron los objetivos enunciados en el capítulo 1 y se plantearon las formas de llegar al resultadofinal. Para ello es necesario saber de donde se parte, a donde se quiere llegar, como desarrollarla aplicación y que condiciones hacen falta para el desarrollo. Por este motivo a continuaciónse van a definir los parámetros que se deben enviar desde la tablet al vehículo y viceversa.



4.4.1 Envío/recepción de datos

Una vez verificado que el sistema de comunicación entre los dos dispositivos funciona correc-tamente, se detallarán a continuación los datos que debe recibir la app y los que debe enviar alcoche.

1. Datos a enviar desde la app al vehículo:

a) La ruta a recorrer por el coche: el ordenador del vehículo requiere de los datos dela ruta para poder controlarlo y seguir el trayecto especificado de manera segura.

b) La velocidad máxima de la calle por la que debe circular el vehículo, ya que el con-trolador requiere esta información para crear el perfil de velocidad.

c) Alertas definidas en el mapa que no haya detectado el vehículo como señales detráfico, semáforos, pasos de peatonales, etc, con el fin de alertarlo y que reaccionecorrectamente de manera segura.

d) La señal de paso entre modo de conducción manual y modo autónomo definido porel conductor mediante la interfaz.

2. Datos a enviar desde el vehículo a la app:

a) Información del GPS del coche (localización geográfica) para conocer la posicióndel vehículo y verificar que sigue la trayectoria calculada.

b) Velocidad a la que va el vehículo ya que, si ésta sobrepasa la máxima definida en laetiqueta de la vía, saltará una alarma en la interfaz del usuario para alertarlo. Asímismo, este dato se representará en la aplicación.

c) Alarmas identificadas por los sensores del vehículo para que se visualicen en pantallay alertar de la situación al conductor mediante la interfaz.

Una de las características más fundamental para el desarrollo de la aplicación es la obtención dela posición desde el GPS del vehículo a la aplicación como se ha determinado antes. Al principiose planteó hacer que la aplicación reciba la información del GPS directamente, sin embargo,se prefirió crear un simulador de GPS con la información del LCM en sustitución al dispositivopropio de la Tablet. Esta aplicación se define en el siguiente apartado

4.4.2 Emulador de posicionamiento: GPS Autopia

GPS Autopia es una aplicación que permite establecer la ubicación de la tablet mediante losdatos GPS del vehículo obtenidos a través del LCM. El ícono utilizado para su identificación esel que se muestra en la Figura 4.4.1. Con esta herramienta se logra que todas las aplicacionesinstaladas en la Tablet que requieran del conocimiento de la posición, obtengan la mismageolocalización que el vehículo.

El primer paso para la realización de esta aplicación es la adquisición de una serie de permisoscomo el que autoriza todo lo referente a la localización, conexión multicast entre otros, comoqueda representado en el siguiente código.



Figura 4.4.1 Ícono de la aplicación GPS AUTOPÍA.

1 <uses-permission ...android:name="android.permission.ACCESS_MOCK_LOCATION"/>

2 <uses-permission ...android:name="android.permission.INSTALL_LOCATION_PROVIDER"/>

3

4 <uses-permission ...android:name="android.permission.ACCESS_FINE_LOCATION"/>

5 <uses-permission ...android:name="android.permission.ACCESS_COARSE_LOCATION"/>

6 <uses-permission android:name="android.permission.WRITE_SETTINGS"/>7 <uses-permission ...

android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>8 <uses-permission ...

android:name="android.permission.SYSTEM_ALERT_WINDOW"/>9

10 <uses-permission ...android:name="android.permission.SET_DEBUG_APP"></uses-permission>

11 <uses-feature android:name="android.hardware.wifi" ...android:required="false" />

12 <uses-permission ...android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE" />

13 <uses-permission android:name="android.permission.INTERNET"/>14 <uses-permission ...

android:name="android.permission.ACCESS_NETWORK_STATE"/>15 <uses-permission ...

android:name="android.permission.ACCESS_WIFI_STATE"/>

Con los permisos programados, se procede a la configuración del proveedor de localizaciónmediante las clases Location, LocationListener, LocationManager y LocationProvider proporcio-nadas por Android.

Primero se crea un objeto del LocationProvider, lm, que se configura con las líneas de códigoque se muestran más abajo. Así mismo se crea un objeto del LocationListener, ll, para pasárseloal lm. Finalmente, se le pasan los datos de latitud, longitud, altitud y heading recibidos delLCM a un objeto de Location.

1 lm.setTestProviderEnabled(LocationManager.GPS_PROVIDER, true);



2 lm.setTestProviderStatus(LocationManager.GPS_PROVIDER, ...LocationProvider.AVAILABLE, null, System.currentTimeMillis());

3 lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, ll);

Cabe resaltar que, debido a que la recepción de la información de la posición es tan repetida,rápida y que el heading del GPS a muy bajas velocidades puede dar lecturas erróneas, se hacolocado como método de seguridad que se utilice el último heading recibido si la velocidades menor o igual a 5 km/h.

Normalmente en el desarrollo de este tipo de aplicaciones, se calcula el bearing para colocarlotambién como parámetro en el objeto Location. Este parámetro se corresponde al rumbo engrados entre dos puntos, es decir, es el ángulo formado con el norte del primer punto en direc-ción al segundo punto como se refleja en la Figura 4.4.2. Su cálculo se puede realizar mediantela ecuación 4.4.1. Sin embargo Android tiene su propia función, distanceBetween, que calculatanto la distancia aproximada en metros entre los dos puntos, como el bearing del camino máscorto entre ellos.

Figura 4.4.2 Cálculo del bearing entre dos puntos.

bearing = arctan!

sin(lon2 − lon1) ∗ cos(lat2)cos(lat1) ∗ sin(lat2)− sin(lat1) ∗ cos(lat2) ∗ cos(lon2 − lon1)

"(4.4.1)

Sin embargo, como el cálculo de este parámetro no era exacto y la rápida recepción de lospuntos provocan una errónea estimación, se decidió no introducirlo como parámetro.

Finalmente, la actividad principal de esta aplicación es la que se muestra en la Figura 4.4.3donde se muestra la posición recibida (latitud y longitud) y, en la zona de Status aparecen lossiguientes tres textos dependiendo de la información recibida. Esta última sección se colocócon el fin de verificar el correcto funcionamiento de la app.

1. Si no se ha creado la conexión LCM aparece "LCM NOT created: error correspondiente".

2. Si en algún momento se pausa la transferencia de datos, el mensaje sería "Send on pause,waiting for data."



3. Y por último, si la recepción de datos es la correcta y no hay problemas, el texto que semuestra se corresponde a "Sending position" con el canal que recibe y el bearing en lassiguientes líneas.

Figura 4.4.3 Aplicación GPS AUTOPÍA.

Una vez conseguida la localización del vehículo, se procede a la descripción de la aplicaciónobjetivo del proyecto.

4.4.3 AUTOPÍA Route

El proyecto comenzó partiendo de un trabajo final de máster del año pasado que se basaba enla misma idea base, el diseño de un sistema de navegación para vehículos autónomos, usandopara ello la información que ofrece el proyecto libre de mapas OpenStreetMap. En este caso, seutilizaba un ordenador a bordo del vehículo con sistema operativo Linux [15]. En la pantallatáctil se representaba el mapa de OSM para que el usuario introduzca el destino. Sin embargo,debido a un nuevo planteamiento del proyecto, se decidió que el trabajo actual continúe con lautilización de una tablet por lo que la programación del mapa y la interfaz se realiza mediantecódigo Android.



AUTOPÍA Route es una aplicación de navegación con acceso a todos los mapas de alta calidad ydatos de OSM mediante la utilización del código abierto de OsmAnd. Estos mapas se descarganal comenzar la aplicación y con conexión a Internet. Una vez descargados, se almacenan en lamemoria del dispositivo para su uso sin conexión.

El primer planteamiento de la aplicación se refleja en la Figura 4.4.4 donde se visualizan dosactividades, una es unicamente el mapa con el recorrido, y la otra es la división en dos de lapantalla. En la zona de abajo de la división, se visualiza el mapa con la trayectoria a seguir,en medio se refleja la velocidad del coche y arriba se ilustra la carretera y los cambios a dardurante la ruta así como los avisos o alertas de diferentes situaciones, por ejemplo la detecciónde un coche en un cruce, los peatones, conducir a mayor velocidad de la definida en la vía, etc.El objetivo principal de esta división es tener una zona específica que alerte al conductor de lasdiferentes etapas de la navegación.

Figura 4.4.4 Boceto del diseño de la aplicación.

Por otro lado, como se observa en la parte superior de la imagen, al principio el nombrede la aplicación era CSICMaps, sin embargo se decidió cambiar por AUTOPÍA Route ya queel proyecto pertenece al grupo de investigación del CSIC que lleva este nombre, ProgramaAUTOPIA, y que se presentó en el capítulo 2.

El boceto se diseñó utilizando el programa Balsamiq Mockups que es un software que permitecrear bocetos para aplicaciones de manera ágil y facilitando la creación de esquemas. Esteprograma cuenta con una aplicación nativa para OS X, además de versiones para Windows,Linux y una versión web que permite el trabajo desde cualquier lugar. Tiene bastantes imágenescargadas que ayudan al diseño como el mapa o la carcasa de la tablet que se ven en la Figuraanterior. También permite la inserción de imágenes como son la señal de ceda el paso o lade límite de velocidad. El único inconveniente es que tiene un precio de 79$ para la versiónnativa y una suscripción de 12$ al mes si se quiere acceso a la interfaz web.



Volviendo a la aplicación, la ventaja de utilizar el código OsmAnd es que no se parte deun proyecto en blanco, sin embargo, también plantea un reto ya que se trabaja con unacantidad elevada de funciones y clases que requieren de su estudio y entendimiento para serutilizadas. OsmAnd venía ya con la programación necesaria para la descarga de los mapas, elenrutamiento de las trayectorias, la visualización de la ruta en el mapa, el recálculo automáticode la trayectoria, entre otras funciones.

Una vez definidas y estudiadas las herramientas que proporcionaba OsmAnd al proyecto ycomo se debería proceder para su modificación si fuese necesaria, se pasó al cambio de laactividad principal para realizar la división de pantalla. Para ello, se le añadió un LinearLayoutvertical con el fin de poder controlar más cómodamente el espacio que se le adjudicaría a cadauna de las divisiones.

A continuación se añadieron las primeras imágenes a la parte superior correspondientes a lavía (ver Figura 4.4.5). Luego se introdujo en medio el texto de la velocidad. Este cambio serepresenta en la Figura 4.4.6. Se debe destacar, que las diferentes zonas así como sus elementos(imágenes, textos, botones...), deben tener bien definidas las medidas y límites ya que sino, alejecutar la aplicación en el dispositivo, el resultado no sea el esperando obteniendo zonas uobjetos que no aparezcan.

Figura 4.4.5 Diferentes representaciones de la vía.

Posteriormente se procedió a la programación de los botones, para ello, se analizó la con-figuración de la actividad. OsmAnd tiene programados los botones superiores e inferioresen otras actividades que se incluían en la principal. Por esta razón, se modificó la actividadcorrespondiente a los elementos inferiores añadiendo los tres botones necesarios para lograrel resultado esperado como se muestra en la Figura 4.4.7.

El primero y el segundo botón denominados MANUAL y AUTONOMOUS son los encargados demodificar el modo de conducción de autónomo a manual y viceversa respectivamente. Estacomunicación se realiza mediante el envío al vehículo por el LCM de un uno si se pasa a modoautónomo o un cero si se pasa a manual. La información es enviada en el canal denominado"DRIVE_MODE". Cabe destacar que el primer botón no aparece visible ya que la conduccióncomienza en modo manual por defecto. Se decidió utilizar dos botones en posiciones distintaspara evitar confusiones y saber en todo momento en que modo de conducción se encuentra yaque los botones se van alternando según sea el caso.



Figura 4.4.6 Paso de la actividad principal de OsmAnd a la de Autopia Route.

Finalmente el último botón es el que produce la aparición de la división de pantalla o delmapa, permitiendo al usuario pasar de una visión detallada a otra en la que se ve unicamentela trayectoria a seguir y las indicaciones como en los sistemas de navegación convencionales.Este hecho se apreciará mejor en las imágenes del capítulo 5 aunque la visualización de esto serepresenta en la Figura 4.4.8. El texto de este último botón cambia de MAP a MAIN dependiendode lo que se esté visualizando para volver al estado anterior.

Figura 4.4.7 Colocación de los botones.



Se debe resaltar que al comenzar la aplicación, la división y los botones no aparecerán hastaque se haya programado la primera ruta y empiece su simulación. Sin embargo, cuando sepase a ver unicamente el mapa, el texto de la mitad seguirá visible en la zona superior comose visualiza en la Figura 4.4.8.

Las visualización de las alarmas se colocó fuera del anterior LinearLayout vertical para queestuviesen visibles siempre durante el transcurso de la navegación. Para la explicación de lacolocación de las imágenes correspondientes a cada alerta, se ha representado su posición enla Figura 4.4.8. Por un lado, en la esquina superior izquierda se encuentra la señal del límite develocidad de la vía y en la zona media se dibujarán las diferentes señales de aviso, en el casode la imagen, se ha representado una señal de STOP como ejemplo.

Figura 4.4.8 Colocación de las alarmas y avisos.

La representación de las alertas en cada situación se ha realizado con las imágenes que semuestran en la Figura 4.4.9 donde se observa que se han contemplado cuatro posibles escena-rios, la detección de un semáforo, de una señal de ceda el paso, de una señal de STOP y de unobstáculo como un peatón o un vehículo acercándose en un cruce. Con respecto a esta últimasituación, adicionalmente a la señal se mostrará en la carretera la imagen correspondiente acada objeto, es decir, en el caso del peatón se representará un paso de cebra en la carretera yuna dibujo de una persona en color naranja, si el obstáculo es un coche, aparecerá en el carrilcorrespondiente del cruce.

Por otro lado, cuando el vehículo supera la velocidad permitida en la vía, el fondo delmedio cambia y se vuelve rojo con el fin de llamar la atención del conductor. Así mismo, lavelocidad máxima de la vía se obtiene mediante la información del mapa y se envía por LCMal vehículo con el fin de que el controlador de velocidad del bajo nivel la tenga como referencia.



En el capítulo 5 se visualizarán mejor todas las representaciones de cada situación.

Figura 4.4.9 Alertas de alarmas captadas por el sistema de percepción del vehículo.

Respecto a la programación, si se detecta el aviso de una alarma, se analiza su número deidentificación para distinguirla y ejecutar la operación correspondiente como cambiar lavisibilidad de la imagen que la define. La operación de interpretar cada caso se realiza en unhilo secundario ya que la verificación de la llegada de una alarma es una acción continua. Porotro lado, la modificación de la interfaz se ha realizado mediante el método propio de AndroidrunOnUiThread ya que esta función solo ejecuta una acción especifica desde un hilo que seesté ejecutando sobre un componente del hilo principal.

Por otro lado, se visualizaran una serie de alertas obtenidas desde el tratamiento del mapa. Estasalarmas se corresponden al aviso de la existencia de cámaras de tráfico, fronteras, resaltos,señales de STOP, señal de tren y pasos de cebra. Así pues, su visualización se ejecutará porencima de los botones inferiores del mapa. La imagen correspondiente a cada aviso se visualizanen la Figura 4.4.10.

Figura 4.4.10 Alertas de alarmas captadas por el tratamiento del mapa.



Una vez definidos todos los aspectos gráficos que se visualizarán en la aplicación, se procede ala programación del envío de datos de la navegación, desde la tablet al coche, es decir, la rutaa recorrer por el coche, el modo de conducción mediante los botones de la actividad principaly la velocidad referente a la calle por la que debe circular el vehículo.

Con respecto al primer bloque de datos, se aprovecha el procesamiento de OsmAnd y dela información que utiliza para crear la ruta de navegación. La aplicación guarda en unarray los datos más relevantes de cada vía a seguir en la trayectoria y la información de losnodos que la componen y que intervienen en el recorrido. Así pues, se recogen de esa listade datos el identificador que define la vía y cual es el nodo inicial y el final que se recorre.Esta información se transmite cada vez que se calcula la ruta a seguir, ya sea la inicial o laredirección al equivocarse en el seguimiento de la trayectoria. Cada vía se exporta del array yse manda por separado a través de LCM por el canal "RUTA".

Cuando se lanza la aplicación, el modo de conducción es manual por defecto por lo que, enel centro se encuentra el botón correspondiente para cambiar a modo autónomo. Al hacerclick en dicho botón, se envía por el canal "DRIVE_MODE.el valor 1 refiriéndose a su cambio aautónomo, desaparece el botón del centro y aparece otro a la izquierda el cual, al hacer clickmanda un 0 para volver a modo manual, desaparece y vuelve a surgir el primer botón.

Para la velocidad de la vía, se obtiene el dato también del procesamiento realizado por OsmAndy se envía por el canal "STREET_SPEED". Se tiene en cuenta que, cuando sucede una alarma develocidad, es decir, que el vehículo detecta una señal, es la lectura de este dato el que se envíaal planificador del vehículo y no la definida en el mapa pues este puede estar desactualizado oque la modificación de la velocidad proceda de una señal colocada en la vía de forma temporalpor obras u otras circunstancias.

El proceso de envío de datos se realiza como se indica en el siguiente código, es decir, se procedea la activación de una instancia del LCM, a continuación se procesan los datos codificándolosa bytes y se introducen en el buffer cuyo espacio se ha dejado guardado al crearlo, finalmentese publica indicando el canal, el array de variables a enviar y el inicio y final de la lectura delarray, en este caso se desea desde la primera posición hasta la longitud del array ya que sólocontiene las variables deseadas. Para la realización del envío se han creado hilos secundariosya que debe ser continuo y saturaría el hilo principal.

1 ...2 new Thread(new Runnable() {3 @Override4 public void run() {5 LCM lcm = LCM.getSingleton();6 // Serialize component data7 // The size changes depending on the type and number of ...

variables to send.8 ByteBuffer buffer = ByteBuffer.allocate(Long.BYTES + ...

Integer.BYTES);9 // Variable to send



10 buffer.putLong(variable1);11 buffer.putInt(variable2);12 lcm.publish(Canal, buffer.array(), 0, buffer.array().length);13 }14 }).start();15 ...

Finalmente, el ícono y el logo final que definen a la aplicación son los que se muestran en laFigura 4.4.11 de derecha a izquierda respectivamente.

Figura 4.4.11 Autopia Route.


Capítulo 5

VALIDACIÓN / RESULTADOS

Validar el correcto funcionamiento de la aplicación es un punto principal sin embargo, no se hapodido probar con el coche real debido a la falta de los sensores y equipamiento necesario parael testeo de las diferentes situaciones planteadas. Por ello, se ha decidido hacer la simulaciónde un recorrido utilizando una lista de datos grabados y modificados que harán el rol delvehículo.

En este capítulo se explicarán con detalle las diferentes situaciones estudiadas y simuladas quese han realizado y se demostrará que las respuestas a los avisos se realizan correctamente porparte de la aplicación.

5.1 Simulación de alarmas

Como se ha explicado anteriormente, debido a que no se va a poder validar la aplicación en elvehículo, se han programado una serie de alarmas mediante un pequeño programa en phyton.La programación se ha realizado de tal forma que estas señales lleguen al dispositivo Androidpor el LCM con el mismo formato que el resto de información enviado por el log grabado delvehículo.

Las alarmas se encuentran definidas mediante la estructura que se adjunta a continuación, porlo que tienen un identificador que indicará el tipo de alerta, la posición del objeto identificadopor coordenadas geográficas (latitud y longitud), el nivel de alerta que se corresponde a laprioridad y por último el flags que se utiliza para definir otro parámetro que se requiera por seruna alarma específica.

1 struct alarma {2 double longitud;3 double latitud;4 byte nivel_alerta;5 byte id;6 byte flags;7 }

57

CAPÍTULO 5. VALIDACIÓN / RESULTADOS

En la Tabla 5.1.1 se define como queda la programación de las alarmas y qué valores obtienencada variable que no se refiera a la posición. En el caso de los semáforos, el id se correspondea 1X definiendo la X como el tipo es decir, para coches o peatonal. Por el momento este id seutiliza como 1 ya que no se considera otra clase de semáforo. Así mismo, en la aplicación sólose tendrán en cuenta si están en rojo.

Tabla 5.1.1 Tabla de definición de alarmas.

Alarmasid nivel_alerta flags Comentario del valor de flags

Velocidad 0 4 X Velocidad

Semaforos1X 4 1 Rojo1X 3 2 Amarillo1X 0 3 Verde

Señal de tráfico 21 3 0 Señal de STOP22 2 0 Señal de Ceda el paso

Obstáculo 31 2 0 / 1 Coche der / izq32 3 0 / 1 Peatón der / izq

Por otro lado, estas alarmas se incorporan al array de alarmas del objeto osmand_alarmas quequeda definido de la siguiente forma.

1 struct osmand_alarmas2 {3 int32_t timestamp_sec;4 int32_t timestamp_nsec;5 int8_t n_alarmas;6 autopia_lcm.alarma alarmas[n_alarmas];7 }

Por último, el envío de las alarmas está sincronizado con los segundos de simulación del logdel vehículo como se muestra en la Figura 5.1.1. Así mismo, esta información es aportada porel GPS.

Figura 5.1.1 Envío de alarmas mediante LCM.



5.2 Resultados de la aplicación

Como se ha mencionado en el capítulo anterior, la aplicación comienza con el mapa en todala pantalla y los botones correspondientes para navegar por el o empezar una ruta. Para lavalidación del funcionamiento de la aplicación se ha escogido una navegación desde la salidadel CSIC en la calle Pedro de Valdivia hasta la salida dirección al retiro en la rotonda de laPuerta de Alcalá (ver Figura 5.2.1). Este segmento se corresponde a la información del log quesimula el comportamiento del vehículo. Se ha seleccionado este fragmento ya que a lo largo dela Calle Serrano se pueden colocar los diferentes avisos de las alarmas con facilidad.

Figura 5.2.1 Ruta de navegación seleccionada para la validación (girada 90◦).

Se comienza la ruta al darle al bóton de navegación que se ha señalizado con un recuadroverde en la imagen de la izquierda de la Figura 5.2.2. Esta acción abre un menú que permite alusuario colocar tanto el destino final como el de origen aunque por defecto este último puntoviene como la ubicación actual. En este caso se ha seleccionado el punto final colocando elpunto directamente en el mapa y la aplicación ha colocado una referencia de la posición, "Callede Alcalá (Jerónimos), Retiro".

Figura 5.2.2 Inicio de la aplicación Autopia Route.



Una vez seleccionado el destino, se comienza la navegación al hacer click en el botón "Ir"queestá resaltado con un recuadro rojo en la imagen derecha de la Figura 5.2.2. La aplicación pro-cede a calcular la trayectoria y la envía al vehículo como se programó. Se verifica que se haenviado correctamente por su visualización en la aplicación para lectura de puertos Multicastdenominada Multicas Tester1. Los datos de la ruta enviados se visualizan en la imagen de laFigura 5.2.3 que se corresponde a una captura de pantalla de dicha aplicación. Se han copiadoun par de líneas como ejemplo de esta información en el siguiente código. Como se observaos datos enviados están codificados y no son comprensibles a simple vista por lo que se en-vían además en el canal "RUTATxt"la misma información pero como cadena de caracteres paraaclarar y visualizar los datos. el número largo se corresponde al Identificador de la calle y lossiguientes números a los nodos iniciales y final que forman la ruta.

Figura 5.2.3 Captura de la aplicación Multicast Tester.

1 ...2 [You] LC02RUTA ? ?3 [You] LC02RUTATxt 29419688,0,24 [You] LC02RUTA Wr5 [You] LC02RUTATxt 437147506,0,26 ...

Así mismo, en la misma imagen se puede observar el envío del cambio del modo de conducción1Multicas Tester es una herramienta que permite visualizar paquetes multicast que se encuentren en la IP y el

puerto descrito y verificar su envío ya que visualiza la dirección IP del origen e cada paquete recibido. Ademáspermite no sólo la recepción sino también el envío de mensajes de este tipo. Como ventaja tiene una interfazsimple e intuitiva y permite visualizar el envío de datos en hexadecimal pudiendo así ver los datos descodificadosde cierta forma.



manual a autónomo y viceversa, mediante un 0 para el primer caso y 1 para el segundo; y ellímite de velocidad de la vía. Esta información se ha copiado en el siguiente código para mejorvisualización. Al igual que en el anterior caso, se han creado los canales "DRIVE_MODETxt 2

"STREET_SPEEDTxt"para visualizar mejor la información.

1 ...2 [You] LC02.STREET_SPEEDBH3 [You] LC02/STREET_SPEEDTxt 50.0 km/h4 [You] LC02?STREET_SPEEDA ?5 [You] LC02?STREET_SPEEDTxt 20.0 km/h6 ...7 [You] LC02 DRIVE_MODE8 [You] LC02 DRIVE_MODETxt 1, Modo Autónomo9 ...

10 [You] LC02 DRIVE_MODE11 [You] LC02 DRIVE_MODETxt 0, Modo Manual12 ...

Como ha surgido una alarma de velocidad que indica el cambio de 50 a 20 km/h, el dato enviadoal coche se corresponde a este último valor. El cambio de la alarma se percibe en la Figura 5.2.4,donde se observa que se ha modificado la señal superior. Por otro lado, en la misma imagen sepuede percibir que a la derecha el sistema se encuentra en modo de conducción Manual y a laderecha en Automático.

Figura 5.2.4 Alarma de velocidad.

Posteriormente, siguiendo la navegación del vehículo se observa que la velocidad de éste hasuperado el límite especificado por lo que se produce el cambio de fondo de la velocidad deblanco a rojo para llamar la atención al conductor ya que su velocidad es mayor a la máximaen ese tramo (ver Figura 5.2.5).



Figura 5.2.5 Alarma de exceso de velocidad.

Pasado el tiempo se llega a una alarma de señal de tráfico correspondiente a un semáforocomo se observa en la Figura 5.2.6. Como se ha señalado anteriormente, esta alerta se activaunicamente al identificar un semáforo en rojo.

Figura 5.2.6 Alarma de señal de semáforo.

Así mismo en las imágenes de las Figuras 5.2.7, 5.2.8, 5.2.9, 5.2.10 se observa el aviso de laalarma para una señal de ceda el paso, un STOP, y dos tipos de obstáculos, un peatón y un cruce



de un coche que viene por la derecha respectivamente. Como se ha comentado en el capítuloanterior, al detectar los obstáculos, la información gráfica avisa al usuario de que obstáculo setrata.

Figura 5.2.7 Alarma de señal de ceda el paso.

Figura 5.2.8 Alarma de señal de STOP.



Figura 5.2.9 Alarma de señal de peatón.

Figura 5.2.10 Alarma de señal de cruce con vehículo por la derecha.

Por otro lado, en la Figura 5.2.11 se visualiza el cambio de pantalla dividida a mapa durante eltrayecto, notando que las alarmas y el límite de velocidad se representan en los dos casos.



Figura 5.2.11 Cambio de visualización de la pantalla.

Una vez el vehículo se esté a una distancia corta del destino, la aplicación abre un menú en elusuario tiene la opción de elegir la búsqueda de un aparcamiento, recalcular la ruta o detenerla navegación como se muestra en la Figura 5.2.12.

Figura 5.2.12 Llegada al destino



Se puede concluir que los resultados obtenidos en estas pruebas, a pesar de ser en simulación,validan las funcionalidades definidas para la aplicación, es decir, las alarmas han saltadocorrectamente en los cruces señalados y el envío de la información al vehículo se ha realizadosatisfactoriamente.

Se corrobora la rapidez y el funcionamiento de la comunicación, ya que los datos del coche sereciben y representan al instante produciendo una simulación bastante real al comportamientoobtenido por un vehículo. La detección de las alarmas y su aviso en pantalla es claro y de fácilentendimiento para el conductor. Por último, se ha verificado que la información del mapa esbastante completa y mayoritariamente fiable ya que aún hay información que se puede añadir.


Capítulo 6

CONCLUSIONES Y FUTUROS TRABAJOS

La investigación en vehículos autónomos lleva varias décadas desarrollándose y el avancede la tecnología actual abre más puertas a su desarrollo permitiendo su comercialización nosolo como sistemas de asistencia a la conducción, sino también como vehículos con nivelesde autonomía 3 e incluso 4. Sin embargo, aún queda bastante para la implementación deun vehículo terrestre con completa autonomía. A pesar de ello, cada paso realizado en elperfeccionamiento de algún sistema implementado o la adición de un componente nuevoayuda a que se pueda lograr la hasta ahora utópica conducción autónoma.

En este capítulo se explicarán las conclusiones que se han alcanzado tras concluir este proyectoy los futuros trabajos que se pueden realizar para su mejora y continuidad.

6.1 Conclusiones

Una vez concluidos los objetivos fijados al principio del proyecto, haber concluido con sudesarrollo y obtener los resultados de la simulación para la validación del proyecto, se hallegado a las siguientes conclusiones:

1. Un vehículo autónomo requiere de navegador y planificador de rutas completo, efectivoy rápido por lo que la información de los mapas es fundamental para el correcto funcio-namiento del sistema de navegación.

2. Se ha comprendido la comunicación LCM así como su forma de programación y cómo elvehículo envía y reciba la información por este medio.

3. Se ha conseguido trabajar con las librerías ya creadas por el grupo de investigación fa-cilitando así la compatibilidad de las librerías y el código cuando se quiera utilizar elproyecto con otros dispositivos.

4. Se ha realizado con éxito una comunicación LCM en la tablet, logrando una recepción yenvío de datos rápido y fiable.

5. Se ha efectuado un estudio del proyecto OpenStreetMaps, llegando a entender la formade crear los mapas, el uso de la información y la filosofía del proyecto.

67

CAPÍTULO 6. CONCLUSIONES Y FUTUROS TRABAJOS

6. Se ha concluido que el proyecto OSM proporciona una amplia y completa librería de infor-mación de mapas que proporciona de forma libre y sin restricciones a uso. Sin embargo,hay información específica que no está incluida como la velocidad de algunas calles oseñales de tráfico.

7. Se ha hecho uso de las aportaciones estudiadas de OsmAnd para la realización del pro-yecto, facilitando así su implementación ya que no se tenía que trabajar directamente conel mapa o implementar el cálculo de rutas.

8. Se ha llegado a entender en gran medida mucho código de OsmAnd pese a que el proyectoconsta de decenas de archivos java, librerías y pocos comentarios explicativos.

9. La programación en un software como Android Studio que te ayuda a perfeccionar yoptimizar el código es una herramienta fundamental en la creación de aplicaciones.

10. Se ha conseguido una aplicación que cumple los requisitos esperados, es decir, la apli-cación cumple la función de navegador y además representa de forma clara las alarmaspara que el conductor pueda identificar la situación de inmediato.

11. Se ha podido crear una simulación de la conexión entre el vehículo y la tablet, lograndoasí validar su correcto funcionamiento tanto en la lectura y envío de datos como en lasanimaciones de las alertas en las diferentes situaciones consideradas.

12. Se finaliza una aplicación lista para su prueba con un vehículo real.

Por tanto se concluye que se han cumplido los objetivos planteados para el desarrollo del pro-yecto ya que se ha diseñado una aplicación que se comunica al vehículo del programa AUTOPIA,y que sirve como referencia para futuras modificaciones o ampliaciones.

6.2 Futuros Trabajos

Este trabajo es una aproximación a la unión del vehículo con los sistemas de navegación progra-mados en dispositivos Android que hasta ahora no tienen una conexión directa con el vehículo.Este proyecto es ampliable y se espera que se complete hasta poder obtener un sistema robustoy fluido para la navegación de vehículos completamente autónomos. Con este fin, se proponenla siguiente lista de trabajos futuros con los que se estima la mejora del proyecto y puntos queno se abarcaban pero que serían interesantes para desarrollar en un futuro.

1. Analizar a más profundidad la información utilizada en OsmAnd con el fin de aprovecharal máximo los datos del mapa ya procesados.

2. Mejorar el diseño de la interfaz, sobretodo la carretera, y lograr realizar la representaciónde una rotonda.

3. Añadir información externa en tiempo real para optimizar la aplicación como el nivel detráfico, accidentes, obras, meteorología, etc.



4. Revisar la información del mapa y mejorar su procesado para obtener más datos de otrasalarmas, detalles de la vía...

5. Adjuntar avisos sonoros a las alertas para asegurar la atención del conductor.

6. Optimizar el envío de alertas obtenidas desde el mapa hacia el vehículo.

7. Añadir el reconocimiento de voz para que no sea necesaria la introducción del punto dedestino manualmente.

8. Optimizar el cálculo de ruta y el refresco del mapa ya que es lento y tarda en obtener unaruta si el destino es muy lejano.

9. Intentar actualizar la base de datos de OSM con la información obtenida del sistema depercepción del vehículo, con el fin de tener actualizado el mapa aumentando su detalley precisión.

10. Realizar la conexión entre el vehículo y el dispositivo Android con el fin de realizar prue-bas experimentales.

Estas ideas junto a las que surgirán mientras se logra la conexión del dispotivo Android con elcoche y se hagan pruebas son el futuro trabajo que se puede realizar teniendo como base esteproyecto.


Capítulo 7

BIBLIOGRAFÍA

Bibliografía

[1] V. Milanés, M. Marouf, J. Pérez, D. González, and F. Nashashibi, “Low-speed cooperative car-following fuzzy controller for cybernetic transport systems,” in Intelligent Transportation Sys-tems (ITSC), 2014 IEEE 17th International Conference on, pp. 2075–2080, Oct 2014.

[2] B. van Arem, C. J. G. van Driel, and R. Visser, “The impact of cooperative adaptive cruisecontrol on traffic-flow characteristics,” IEEE Transactions on Intelligent Transportation Systems,vol. 7, no. 4, pp. 429–436, Dec 2006.

[3] H. Kopetz and S. Poledna, “Autonomous emergency braking: A system-of-systems perspecti-ve,” in Dependable Systems and Networks Workshop (DSN-W), 2013 43rd Annual IEEE/IFIPConference on, pp. 1–7, June 2013.

[4] V. Milanés, E. Onieva, J. Pérez, J. Simó, C. González, and T. De Pedro, “Making transportsafer: V2v-based automated emergency braking system,” Transport, vol. 26, no. 3, pp. 290–302, 2011.

[5] R. Marino, S. Scalzi, G. Orlando, and M. Netto, “A nested pid steering control for lane keepingin vision based autonomous vehicles,” in American Control Conference, 2009. ACC ’09., pp.2885–2890, June 2009.

[6] M. Marouf, E. Pollard, and F. Nashashibi, “Automatic parallel parking and platooning to redis-tribute electric vehicles in a car-sharing application,” in Intelligent Vehicles Symposium Procee-dings, 2014 IEEE, pp. 486–491, June 2014.

[7] T. H. S. Li and S.-J. Chang, “Autonomous fuzzy parking control of a car-like mobile robot,” IEEETransactions on Systems, Man, and Cybernetics - Part A: Systems and Humans, vol. 33, no. 4,pp. 451–465, July 2003.

[8] ElMundo. Tesla y general motors, investigadas por accidentes de sus co-ches autónomos. [Online]. Disponible en: http://www.elmundo.es/motor/2018/01/25/5a69b506268e3eca168b45fe.html

71

http://www.elmundo.es/motor/2018/01/25/5a69b506268e3eca168b45fe.html

http://www.elmundo.es/motor/2018/01/25/5a69b506268e3eca168b45fe.html

REFERENCIAS

[9] www.dgt.es. Dgt, tablas estadísticas. [Online]. Disponible en: http://www.dgt.es/es/seguridad-vial/estadisticas-e-indicadores/accidentes-30dias/tablas-estadisticas/

[10] ——. 1.160 fallecidos en accidente de tráfico. [Online]. Disponible en: http://revista.dgt.es/es/noticias/nacional/2017/01ENERO/0103balance-accidentes-2016.shtml#.WhXagExDlE4

[11] J. Godoy, “Arquitectura de control para la conducción autónoma de vehículos en entornosurbanos y autovías,” Ph.D. dissertation, Universidad Politécnica de Madrid, Escuela Superiorde Ingenieros Industriales, 2013.

[12] ieeexplore.ieee.org/Xplore/home.jsp. Ieee transactions on intelligent transportation systems.[Online]. Disponible en: http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=6979

[13] Ertico - its europe. [Online]. Disponible en: http://www.ertico.com/

[14] 2016, no. Num. Serie: WHEBN0001974050.

[15] A. Bernaldo de Quiros Sanz, “Sistema de navegación para vehículos autónomos basado enopenstreetmap,” Master’s thesis, Universidad Politécnica de Madrid, Escuela Superior de In-genieros Industriales, 2016.

[16] S. Hans, “The worlds first in-car navigation system: Pre-gps era,” in 1981 Honda Accord, 2015.

[17] Honda. (2011, 10 Jane) The car navigation system. [Online]. Disponible en: http://world.honda.com/history/challenge/1981navigationsystem/page09.html

[18] Press kit. [Online]. Disponible en: http://wiki.openstreetmap.org/wiki/Press_Kit

[19] A. Huang, E. Olson, and D. Moore, “Lcm: Lightweight communications and marshalling,” In-ternational Conference on Intelligent Robots and Systems, p. 4057 4062, 2010.

[20] Lightweight communications and marshalling (lcm). [Online]. Disponible en: https://lcm-proj.github.io

[21] Es:osmand. [Online]. Disponible en: http://wiki.openstreetmap.org/wiki/ES:OsmAnd

[22] Osmand. [Online]. Disponible en: https://es.wikipedia.org/wiki/OsmAnd

[23] developer.android.com. Conoce android studio. [Online]. Disponible en: https://developer.android.com/studio/intro/index.html?hl=es-419


integraciÓn en tiempo real de un navegador basado...

Documents