UNIVERSIDAD POLITECNICA DE MADRID ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES
INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR 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 y Electronica e Informatica Industrial
INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR 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ón Walt Disney.
AGRADECIMIENTOS
En primer lugar, quiero agradecer a Fernando Matía, Jorge Godoy y a Jorge Villagra por darme la 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 tan interesante 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 para lograr este objetivo fue la proporcionada por el proyecto OpenStreetMap y el soporte de código abierto de la aplicación OsmAnd.
El fin de este desarrollo es la implementación y comunicación del sistema de navegación con uno 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 Consejo Superior 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 los elementos que forman su estructura.
Para lograr este cometido, primero se realizó un estudio previo de la comunicación Lightweight Communications and Marshalling (LCM) para conocer como se utiliza, cómo se codifican los datos 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 se pueden utilizar, que herramientas podrían ayudar al desarrollo del proyecto... Por lo tanto, se estudiaron las ventajas que ofrecían las aplicaciones gratuitas y de código libre que emplean OSM 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ón de 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, las indicaciones 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 estas características.
Por otro lado, se implementan los recursos necesarios para la simulación del vehículo mediante la utilización de datos grabados por este, y un programa auxiliar que envía las alarmas como si 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 la comunicación LCM, al mismo tiempo que recibe las alarmas programadas y se envían los datos al coche para crear perfiles de velocidad, detener el vehículo por una alarma o indicar el modo de conducción.
Finalmente se obtiene una interfaz gráfica amigable, sencilla que permite al usuario empezar la navegació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 navegador para vehículos autónomos funcional.
III ABSTRACT
This project was based on the development of a navigation system using an application on an Android 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 navigation system with one of the autonomous vehicles belonging to the fleet of the AUTOPIA research group, what is part of the Automation and Robotics Center of the UPM and the Higher Council of Scientific Research. (CSIC) The objective of the project is the application has to act as the vehicle’s planner and navigator, interacting with it and with each of the elements that form its structure.
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 to send 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, what tools could help the development of the project, etc. Thus, the advantages offered by free and open 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 without connection, has voice notifications, lane indications, intermediate point support in the path and it recalculate the route automatically. The problem is that some of these functions are not active in the free version.
On the other hand, the necessary resources for the simulation of the vehicle are implemented through the use of data recorded by the vehicle, and an auxiliary program that sends the alarms as if it were the perception system of car. Therefore, the application receives the data obtained by the GPS of the vehicle through the LCM communication, at the same time, it receives the programmed alarms and sends the data to 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. The simulation is carried out for the validation of the system and it is concluded with a functional navigation 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 y adaptabilidad; 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 para mejorar la experiencia y la seguridad de todos los pasajeros. El objetivo principal es ayudar al conductor, ya sea de forma parcial o total, advirtiendo sobre las circunstancias inesperadas que pueden llevar a situaciones de riesgo como la salida involuntaria del carril o la proximidad a otros vehículos.
La seguridad es un aspecto crucial en el desarrollo de sistemas autónomos, siendo el principal objetivo de los fabricantes de automóviles y grupos de investigación en el campo. Entre los diferentes ADAS existentes en el mercado destaca: el control longitudinal (acciones del acelerador y del pedal de freno) y el lateral (acción en el volante). El primero sobresale por el Adaptive Cruise Control (ACC) que ajusta la velocidad según el vehículo precedente o mantiene una velocidad establecida [1][2]; y el City Brake Control (CBC), que es un sistema de 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 el conductor no reacciona [3][4]. En relación con el control lateral, los más significativos son el Lane Keeping Assist (LKA) que utiliza una videocámara para reconocer las líneas del carril y, si el coche se desvía involuntariamente, el sistema corrige la trayectoria para mantener al vehículo dentro del carril [5]; y el Sistema de Estacionamiento Automático (APS), que realiza la maniobra de estacionamiento de forma completamente autónoma [6][7]. Todos estos sistemas desempeñan un papel importante en la mejora de la seguridad activa del vehículo y la estabilidad. A pesar de estas importantes contribuciones a la automatización del transporte por carretera, todavía queda mucho camino por recorrer antes de que los vehículos totalmente autó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 la investigación de vehículos autónomos desde 1998. Las diferentes publicaciones de este grupo en medios prestigiosos, demuestran su experiencia en la investigación de sistemas que permiten el 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 el vehí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 permitido controlar los vehículos de forma adecuada y segura. Sin embargo, pese a que estos sistemas inteligentes acercan a la idea de la conducción 100 % autónoma, aún no se alcanzado el nivel de exigencia necesaria para una autonomía completa como se ha demostrado con los casos de Tesla [8]. Es por esta razón por la que se ha querido desarrollar un sistema que permita ayudar al conductor para saber y estar atento a las diferentes circunstancias que lo rodean durante todo el trayecto, usando una interfaz de usuario intuitiva y amigable. Así pues, se ha propuesto 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 proporcionarle unos rasgos de velocidad, formando un perfil de conducción con características de la ruta que pueden influir en la conducción en tiempo real. La parte de la navegación se ha basado en la integración con el sistema de localización GPS del coche, de tal forma que, según la informació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 una herramienta indispensable, que permita la circulación segura y autónoma del vehículo y, a la 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 lo que 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ás eficiente por la generación de un perfil de conducción menos agresivo, y por la optimización de 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ás en detalle, el proyecto de basa en la utilización de OpenStreetMap para la navegación y el desarrollo de una interfaz de usuario que facilite la introducción de los datos de navegación y la visualización del recorrido.
OpenStreetMap es un proyecto colaborativo de creación y edición de mapas, y de acceso libre a toda su información. Su utilización en este proyecto no se basa únicamente en utilizarlo como un navegador comercial con todas sus características (cálculo óptimo de trayectoria, interfaz gráfica que permite visualizar al usuario el mapa y la posición actual, así como permitirle la interacción con el sistema, recálculo de la ruta si es necesario, etc.), sino que también se pretende 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 un perfil 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 del mapa y la adquirida por los sensores del coche.
Para alcanzar este objetivo se han establecido un conjunto de hitos intermedios que estructuran y 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 el conductor, 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ón En este apartado se explica por qué surge el proyecto, en que se basa a grandes rasgos y cuáles son los objetivos a cumplir. 2. Capítulo 2. Estado del arte En 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án los mapas digitales y se introducirá OpenStreetMaps. Por último, se expondrán algunas de las actuales aplicaciones de navegación móviles. 3. Capítulo 3. Diseño de la interfaz En este capítulo se expondrán detalles de OpenStreetMaps, en especial se definirá el formato 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 desarrollo de la interfaz. Por último, se explicarán las ideas iniciales del diseño de la interfaz, el desarrollo que se ha llevado a cabo para su elaboración y el resultado final obtenido. 4. Capítulo 4. Comunicación con el Vehículo En este capítulo se explica la comunicación que tiene el vehículo y como se ha logrado la conexión entre éste y la aplicación en la tablet. 5. Capítulo 5. Validación y resultados En 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 trabajos Finalmente en este capítulo se exponen las conclusiones a las que se han llegado, las mejoras y futuros trabajos que se pueden llegar a realizar en el futuro.
14 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) 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 de la seguridad de los pasajeros pues, la alta utilización de los automóviles ha desembocado en 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, en este capítulo se revisarán los avances más significativos de los ITS, el grupo de investigación AUTOPÍA, al que pertenece este proyecto, y los métodos de ayuda en la navegación como GPS comerciales, 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 diferentes aplicaciones 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 integra tecnologí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 sistemas de transporte terrestre, el desarrollo de estos vehículos se centra en obtener una infraestructura de 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 tipo de automóvil en el que se centra este proyecto. Un vehículo autónomo es un ITS dotado de cierta 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 primeros acercamientos con el vehículo autopropulsado de Leonardo Da Vinci (ver Figura 2.1.1). Sin embargo, no fue hasta comienzos del siglo XX, cuando se desarrollaron modelos más orientados a 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 General Motors, en donde se presentó un modelo en miniatura de carreteras que proporcionaban energía a los coches y los controlaban mediante radiocontrol [14] como se muestra en la Figura 2.1.2.a. En la mitad del siglo XX, el laboratorio de Transporte y carreteras del Reino Unido utilizó cables magnéticos en las carreteras para controlar un Citroen DS mientras circulaba a una velocidad de 130 km/h aproximadamente, manteniendo constante su perfil de velocidad y 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 (ver Figura 2.1.2.b) [14].
Figura 2.1.2 Ejemplos del avance tecnológico sigo XX.
16 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
A principios del siglo XXI apareció el DARPA Grand Challenge, desarrollado por la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA del inglés Defense Advanced Research Projects Agency). Este evento se basaba en una carrera de vehículos autónomos, que debían llegar desde un punto de los Estados Unidos hasta otro sin intervención humana y disponiendo únicamente de un listado de puntos intermedios entre el principio del circuito y el final. Cabe destacar que en la primera edición del DARPA, en el desierto del Mojave, ningún coche consiguió terminarlo. Sin embargo, en 2005 varios vehículos lograron terminar el circuito y, en ediciones posteriores se realizó la competición en un circuito urbano aumentando así el nivel de dificultad.
Actualmente todos los fabricantes incorporan sistemas inteligentes en los vehículos, poniendo a disposición del usuario mejoras y facilidades en la conducción que aumentan su seguridad y facilidad. Así mismo, grandes compañías actuales han apostado por este tipo de movilidad y destacan por sus proyectos como Google y Tesla (ver Figura 2.1.3). Cada una de estas empresas tienen un enfoque distinto. Google apuesta por un coche totalmente autónomo mientras que Tesla está desarrollando un nivel de autonomía menor con su sistema Autopiloto que requiere de 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 el nivel 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 tomar • el control, sólo tiene sistemas que emitan alguna advertencia. En este nivel entran todo coche 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, por ejemplo, coches con control de crucero adaptativo (ver Figura 2.1.4.a) o con la tecnología para mantener el coche en el carril o con aparcamiento asistido que solo actúan sobre la
VACA RECALDE, MYRIAM ELIZABETH 17 CAPÍTULO 2. ESTADO DEL ARTE
dirección (ver Figura 2.1.4.b). Esto implica que el conductor sigue realizando el resto de las 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 control • del movimiento es tanto lateral como longitudinal. El sistema no cuenta con detección y respuesta 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 conductor debe estar atento a todo lo que sucede. En este aspecto entran los vehículos con piloto automá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 Pilot Assist, 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 Volkswagen Golf, o el nuevo Audi A3, etc. Así mismo, los coches con sistema de aparcamiento asistido que 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.
18 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
En el nivel 3, los vehículos se denominan semiautónomos y cuentan además con detección • y respuesta ante objetos y eventualidades de manera completa aunque el sistema sigue limitado. En este nivel el usuario debe estar preparado para intervenir si el sistema lo solicita o se produce un fallo o pérdida de las condiciones de funcionamiento, pasando a ser en ese momento conductor. El estándar SAE J3016 establece que si se produjese un fallo del sistema, este debe informar al usuario con tiempo suficiente por medio de un mensaje o alerta. Un ejemplo para este nivel son los coches de Tesla Model S que constan de 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 áreas • acotadas donde el coche tenga suficiente información para no depender del conductor, es decir, el propio sistema de automatización cuenta con un sistema de respaldo para actuar en 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 coche autó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 condiciones • limitantes para el funcionamiento del sistema, y por tanto el vehículo puede conducir en todo 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 balizamiento en la infraestructura, como hacen los aviones para volar con el piloto automático, y que serían en el fondo sistemas inalámbricos de comunicación vehículo a vehículo (V2V) y vehí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 se acerca 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 en el último nivel.
VACA RECALDE, MYRIAM ELIZABETH 19 CAPÍTULO 2. ESTADO DEL ARTE
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 como el Programa AUTOPIA en el que se engloba totalmente este proyecto y el cual se presenta a continuación.
El Programa AUTOPIA es un grupo de investigación español, perteneciente al Centro de Automática y Robótica de la UPM y del CSIC. Se fundó en 1998 y su enfoque de investigación abarca desde las técnicas de control de robots móviles a la conducción autónoma con el uso de inteligencia 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 mejorar la 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, que reproduce 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 dos vehículos ya sea en sentido contrario o en el mismo.
Figura 2.1.7 Flota de vehículos del Programa AUTOPIA.
20 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
2.2 Sistemas de navegación
Un sistema de navegación es una unidad compuesta por mapas digitalizados y la indicación de 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 seguir el 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ón entre las rutas posibles (i.e. recorrido de menor distancia, el más rápido, el más eficiente energéticamente).
Así pues, la información y el detalle de los mapas utilizados son muy importantes y dependientes de su utilización. Como el sistema desarrollado en este trabajo se basa en la planificación y navegación de un vehículo autónomo, se explicarán a continuación alguno de los hechos más relevantes en la evolución de los sistemas de planificación y navegadores comerciales para coches, así como la descripción de los mapas digitales y la introducción del mapa con el que se trabajará en este proyecto. También se comentarán algunas de las aplicaciones de navegación má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, sin embargo, antes de la existencia de esta tecnología, se encontraban proyectos en desarrollo como el DAIR del inglés Driver Aid, Information & Routing. Creado por General Motors Research (GMR) en 1966, el DAIR es un sistema de comunicación bidireccional que podía recibir desde una estación la información de las vías [15]. Unos imanes en la carretera hacían que se escuchasen en el vehículo notificaciones audibles sobre salidas próximas, velocidades límite e incluso como navegar para llegar a un destino, según estaba codificado en la tarjeta perforada 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 aproximadamente entre las décadas de 1960 y 1970. Rockwell Collins empezó a trabajar en sistemas receptores de GPS que vendía para aviación. Posteriormente vendería estas investigaciones a empresas como 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ón de mapas digitales (que se explicarán en el siguiente subapartado). En este mismo año, la compañía Honda empieza con la creación de que se podría denominar el primer sistema de navegació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].
VACA RECALDE, MYRIAM ELIZABETH 21 CAPÍTULO 2. ESTADO DEL ARTE
En 1985, la empresa ETAK presentó un sistema de mapas con pintado vectorial que se alineaba 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 ampliar las funcionalidades de estos sistemas como la asistencia por voz introducida en 1992 por Toyota, la incorporación de pantallas táctiles, los indicadores de giro a giro en la navegación desarrollado por ComRoad AG en 1995, etc.
Además, en el año 2000 se quitaron las restricciones a los sistemas GPS, lo que implicó un aumentando de su precisión y aplicación. Un evento que cabe destacar a partir de esa fecha es la creación de un navegador capaz de prever el tráfico por la compañía Honda en 2003, esto se lograba mediante la integración de la red de comunicación de la infraestructura de carreteras del país asiático en el vehículo.
Una de las empresas que destacó en esta época fue la compañía TomTom creada Ámsterdam en 1991 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 tarde aparece 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ón portable 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 instrucciones por 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 Min Kao. Esta empresa desarrolla y fabrica dispositivos de GPS principalmente para el transporte terrestre aunque también producen para el naval o aéreo (ver Figura 2.2.2). A nivel mundial compiten directamente con la empresa TomTom.
22 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
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 que ayudan a la navegación dando más información al usuario o facilitando su interacción con el dispositivo, por ejemplo, alertas de velocidad, predicción de la hora de llagada, aviso de la posició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 alertas de sonido, realidad aumentada en el parabrisas del vehículo, etc. Ejemplos de estos avances se 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 HUD de 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 Garmin StreetPilot, NAVIGON.
Figura 2.2.3 Sistema de navegación utilizando realidad aumentada.
VACA RECALDE, MYRIAM ELIZABETH 23 CAPÍTULO 2. ESTADO DEL ARTE
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ía en el mundo automovilístico, ha permitido unificar los cuadros de instrumentos convenciona- les con avances tecnológicos como la realidad aumentada. Estos desarrollos permiten mostrar la 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 representan una formación espacial mediante elementos gráficos organizados en capas, con el objetivo de 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 el zoom con el fin de acercarse y ver con más detalle una zona, o alejarse para tener una perspectiva 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 se requiera. En el caso de este proyecto, el mapa que se precisa necesita tener información de las vías de circulación de los vehículos, las restricciones y propiedades de cada calle, las señales de 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 imagen formada por una gran matriz de píxeles por lo que se suelen usar en el campo o en cartas de navegación y los mapas vectoriales en los que nos centraremos pues son los que se utilizarán en este 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 esta forma de representación, estos mapas requieren de pocos recursos de almacenamiento y no se deforman en los cambios de escala (Zoom+ o Zoom-), es por ello por lo que son los utilizados en 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 comercial que 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, editables y detallados de todo el mundo por medio de su comunidad de usuarios, sin restricciones de ningún tipo. Los mapas y datos almacenados en su base de datos se distribuyen bajo licencia abierta 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 de usuarios aproximadamente y creciendo [18]. Los registrados pueden subir sus trazas desde el GPS, crear y corregir datos vectoriales mediante herramientas de edición creadas por la comunidad OpenStreetMap. La información que se puede añadir es muy diversa pues no sólo
24 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP 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 en julio 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 agencia cartográfica de Gran Bretaña, Ordance Survey, por la información geográfica. Su logo es el que se 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 lo que el usuario normalmente paga por la información. Por otro lado, las licencias de uso a veces limitan la utilización del usuario además de que, si la información no es del todo acertada, no se 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 creado iniciativas 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 derecho alguno sobre la cartografía o los datos que han añadido o editado, sus contribuciones pasan a ser de la empresa. En cambio, OSM reconoce estas aportaciones como propias del usuario y no 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 la cobertura 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 de Oxford (diciembre del 2007), Wikimedia (abril del 2009), el Centro Común de Investigación de 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 el libre 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 sus mapas y permite la adición de estos si no se encuentran. En el capítulo 4 se detallarán los elementos que lo componen y sus definiciones.
VACA RECALDE, MYRIAM ELIZABETH 25 CAPÍTULO 2. ESTADO DEL ARTE
Por otro lado, como se iba a aplicar OSM en una aplicación Android, y con el fin de no partir de cero, se procedió a revisar las aplicaciones que principalmente usan OSM, incorporan el enrutamiento de la navegación y tengan el código a disposición del público. Entre las que se 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 los requisitos 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 de navegació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 encuentran actualmente en el mercado.
1. Google Maps es la aplicación de navegación y mapas más utilizada ya que viene de serie en la mayoría de los dispositivos, con lo que no se requiere de la instalación de otro programa para obtener un navegador GPS gratuito y completo. Una gran ventaja de este sistema es que consta de alertas del tráfico a tiempo real y el recálculo automático de la ruta para evitar atascos. Además, permite el cálculo de rutas tanto en coche como a pie, bicicleta, taxi y transporte público (autobuses, metro, tren...) como se visualiza en la Figura 2.2.5. Sin embargo, no se puede usar la navegación sin conexión de datos.
Figura 2.2.5 Google Maps.
1 http://wiki.openstreetmap.org/wiki/Android 2 http://wiki.openstreetmap.org/wiki/Navmii 3 http://wiki.openstreetmap.org/wiki/MAPS.ME 4 http://wiki.openstreetmap.org/wiki/ZANavi
26 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
2. Waze es el navegador GPS más descargado después de Google Maps. Se trata de una aplicación que permite a los usuarios conductores compartir la información del tráfico y de la carretera en tiempo real ahorrando tiempo y combustible. Esta aplicación utiliza mapas de Google y unicamente permite los desplazamientos en coche, es gratuita pero requiere 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 permite calcular 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 Figura 2.2.7).
Figura 2.2.7 Here WeGo.
4. MapFactor es una de las aplicaciones de navegación más descargadas y valoradas pese
VACA RECALDE, MYRIAM ELIZABETH 27 CAPÍTULO 2. ESTADO DEL ARTE
a que tiene una interfaz desfasada como se puede observar en la Figura 2.2.8. Funciona completamente sin conexión a Internet, utiliza mapas libres del proyecto OpenStreetMap y permite comprar los mapas de TomTom. Pese a que su descarga es gratuita, se debe pagar para utilizar algunas funciones como los mapas de TomTom o la Head Up Display que 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 tiene productos de pago. Trabaja con la totalidad de la información de OpenStreetMap. Entre sus 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. Esta aplicación es la escogida en este proyecto y se explicará con más detalle en el siguiente capítulo.
Figura 2.2.9 OsmAnd.
28 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
6. Otras aplicaciones son Maps.me, Sygic, CoPilot GPS, GPS Navigation (BeOnRoad), Magic Earth 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ón iOnRoad, creada para mantener la distancia y alertar al conductor cuando está demasiado cerca o la probabilidad de impacto (ver Figura 2.2.10). Es una aplicación de seguridad en la conducción que utiliza la cámara y el GPS del móvil para detectar una posible colisión con el vehí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 dos ideas anteriores definidas, es decir, obtener un sistema de navegación pero que además alerte al conductor de diferentes situaciones que requieran de su atención como la detección de un semáforo en rojo, un peatón, otro coche en un cruce, etc.
VACA RECALDE, MYRIAM ELIZABETH 29
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, la interacció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 estar los coches conectados, es decir, asegurar la ciberseguridad. Este es el motivo por lo que se busca una comunicación robusta y segura.
En este apartado se definirá el mecanismo de comunicación que se utiliza en los proyectos del grupo AUTOPIA así como la aplicación que se diseñó para la prueba del correcto funcionamiento de 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), que es un conjunto de bibliotecas y herramientas para el envío de mensajes y clasificación de datos, dirigido a sistemas en tiempo real donde el alto ancho de banda y la baja latencia son críticos. Fue creado por el equipo MIT DARPA Grand Challenge Team para la comunicación entre procesos en sistemas de tiempo real. Además proporciona un modelo de envío/recepción de mensajes y generación automática de códigos basado en la difusión multicast de mensajes UDP (del inglés User Datagram Protocol) mediante canales de comunicación que se identifican de forma única [19][20]. En resumen, esta herramienta permite que cada proceso publique directamente su información en determinados canales y se reciben los datos suscribiéndose a ellos, 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 de lenguajes 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 de librerí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 un paquete 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 en funcionamiento 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 en la carpeta donde se encuentra guardado el log a usar.
1 export LCM_DEFAULT_URL=udpm://239.255.76.67:7667?ttl=1 2 lcm-logplayer-gui ./logs/XXXX
La segunda línea corresponde a una herramienta de reproducción de datos que retransmite a la red en tiempo real la información almacenada en un fichero de registro. Esto permite seleccionar los canales que se quieren transmitir como se visualiza en la Figura 3.1.1. Con respecto 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 la información de los mensajes mediante la ventana que se muestra en la Figura 3.1.2. Además de esto, este software permite visualizar estadísticas de cada canal, su consumo de ancho de banda y el número de mensajes transmitidos (ver Figura 3.1.3). Para la visualización de esta información se utiliza una consola secundaria y el código que se adjunta a continuación.
32 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
1 export CLASSPATH=./autopia_lcm/autopia_lcm.jar 2 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 visualiza en pantalla los datos que se reciben del coche, es decir, la posición tanto en coordenadas geométricas (latitud, longitud y altura) como en coordenadas UTM (X, Y, Z en metros); la velocidad del coche, la aceleración y en la zona de Lectura se visualiza el canal de datos que se recibe en ese momento. Esta aplicación de prueba se representa en la Figura 3.2.1 y se corresponde a una captura de la aplicación recién abierta (a la izquierda) y otra en funcionamiento mientras se reciben los datos del LCM (a la derecha).
VACA RECALDE, MYRIAM ELIZABETH 33 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 tanto la tablet como el ordenador se encuentren conectados a la misma red ya que por ahora, la comunicació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 posibles para 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 IP Multicast y al puerto utilizado mediante el LCM. Así mismo, se abre la suscripción a todos los canales 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 los datos provenientes del vehículo y una función de envío por cada canal necesario.
34 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
Desde un punto de vista más profundo en la programación, se debe tener en cuenta que todos los componentes de la aplicación Android (actividades, servicios, broadcast receivers...) se realizan en el mismo hilo de ejecución denominado main thread o GUI thread junto a las operaciones que gestionan la interfaz de usuario de la aplicación. Debido a esto, si se va a ejecutar una operación larga o costosa, este hilo se bloquearía deteniendo la ejecución del resto de los componentes y de la interfaz, creando fallos, un funcionamiento lento e incluso dejando 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 Application Not Responding (ANR) obligando al usuario a esperar a que termine el proceso sin asegurar que esto pase o forzar el cierre de la aplicación. Como crear y realizar la comunicación LCM es un proceso de larga duración, ya que tiene que estar activo continuamente, se requiere su ejecución en segundo plano; esto implica crear y utilizar un nuevo hilo mediante la clase AsyncTask proporcionada por Android, dejando así el main thread libre.
La representación de los datos del LCM en cada uno de los campos asignados corresponde a 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 operaciones en segundo plano y publicar resultados en el subproceso de la interfaz de usuario. Las funciones que 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 a continuació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 se tiene acceso directo a ellos al ejecutarse en el hilo principal, y se igualan a los valores recibidos del LCM.
Una vez analizado el método de comunicación LCM y verificado con éxito la prueba de conexión entre los dos dispositivos, se procede al desarrollo de la aplicación objetivo de este proyecto.
VACA RECALDE, MYRIAM ELIZABETH 35
Capítulo 4
DISEÑO DE LA INTERFAZ
La comunicación del vehículos con el usuario siguen siendo un factor de gran relevancia. La interacció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 pantalla o sistemas de voz. Dentro de este marco, el presente proyecto plantea el diseño de una interfaz orientada a informar al usuario de las acciones de conducciones durante el recorrido y las señ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ísticas de OSM, los elementos que contiene, su organización y aspectos relevantes que se requieran conocer para su apropiada utilización en el proyecto. Después se explicará con más detalle la aplicación de OsmAnd. Posteriormente se presentará el software de programación utilizado y finalmente, se describirá la interfaz programada y los diferentes pasos que se realizaron para su desarrollo.
4.1 OpenStreetMap
Como ya se introdujo OSM en el capítulo 2, se procederá a la descripción detallada de su funcionamiento y de los componentes que lo forman. OSM consta de una API online (ver Figura 4.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 otro lado, esta herramienta también permite al usuario planificar una ruta y representarla de forma online en el mapa con las indicaciones necesarias del trayecto. Así mismo, se pueden importar o compartir trazas de datos GPS que se han tomado para describir caminos específicos. Toda aportación de los usuarios aumenta la precisión de la información y su fiabilidad a la hora de utilizar esta herramienta.
Como se puede observar en la Figura 4.1.1, el mapa contiene formas que definen las zonas urbanas (edificios, calles, plazas...), señales de tráfico como semáforos, indicadores de lugares importantes (cafeterías, farmacias, iglesias...), y restricciones en cada vía como son las pequeñas flechas que señalan el sentido de las calles. Todas estas representaciones se realizan mediante los 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 modelo de 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ística fundamental son las etiquetas, que se utilizan para describir las propiedades asignadas a cada elemento.
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 que se añade para especificar otras propiedades como el nivel en edificios o la capa en vías de distintas alturas, cruces o puentes. Los nodos se usan principalmente para agruparlos con el fin de definir elementos mayores como las vías. Así mismo se pueden utilizar para definir 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 determinar carreteras, caminos, edificios, ríos, etc. Cada vía tiene que estar definida por al menos dos nodos llegando a un máximo de 2000. Al igual que los nodos, las vías tienen un número de identificación único. Las vías tienen la posibilidad de ser cerradas o abiertas y, en el primer caso se les puede considerar como áreas en las que se les considera la superficie que 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 son la definición de rutas de autobús, fronteras, bosques, lagos...
38 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
4. Las etiquetas definen las categorías en las que se describen las características del elemento al 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 especifica el valor de dicha característica. A continuación se describirán rápidamente las etiquetas má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 zonas residenciales o urbanizaciones), Pedestrian (zonas peatonales), Road (cuando no es- tá claro su clasificación), Construction (para vías en proceso de construcción o en obras), entre otros. b) La etiqueta route se define para la características de ruta a un conjunto de nodos o vías y así se asignan caminos que tienen un nombre, un origen y un destino o una funció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 puede etiquetar restricciones para la conducción. d) Para uniones de vías o cruces se aplica la etiqueta junction y en caso de rotondas se utiliza roundabout. e) Las designadas a las capas denominadas layer, denominan las relaciones verticales entre los elementos en el mapa como es el caso de túneles o puentes. Sus valores son entre -5 y 5 (de menor a mayor altura respectivamenete), pero el 0 no se utiliza directamente 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 caso de espacios o vias que están ligados a un edificio o construcción de varios pisos, o a rampas. g) Si se quiere definir muros o vallas o similares en el paso de una vía, se utiliza la etiqueta 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 la dirección, addr. Para su correcta especificación suele ir seguida por un sufijo con dos puntos y el tipo de elemento de la dirección como .addr:street" para la calle especí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 que se 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.
VACA RECALDE, MYRIAM ELIZABETH 39 CAPÍTULO 4. DISEÑO DE LA INTERFAZ
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 edificios está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 archivo del que se ha extraído un ejemplo de la definición de cada elemento para su explicación. Como se 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 las ví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 se especifican la especificación XML UTF8 para la codificación de los caracteres, la versión de la API utilizada, los límites del mapa mediante coordenadas geográficas y otras especificaciones.
1 2
40 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
3
VACA RECALDE, MYRIAM ELIZABETH 41 CAPÍTULO 4. DISEÑO DE LA INTERFAZ
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 de trayectoria trata toda esta información y devuelve una lista de puntos de la cual se cogen los datos necesarios para la aplicación. Otra información que se emplea es la velocidad máxima de la 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 la presentació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ón completa, 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 de rastreo. El programa está muy bien refinado, es confiable, utilizado de forma global y funciona prácticamente en todos los teléfonos y tablets con Android. Además, también se puede utilizar en unos cuantos equipos basados en Linux.
Los mapas se descargan antes de ser utilizados, sin ningún costo, incluyendo actualizaciones tan frecuentes como sean necesarias. Una vez descargados los mapas, los datos se almacenan de forma permanente en la memoria del dispositivo por lo que no requiere de una conexión a Internet. 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 corregir errores 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 importancia ya que, mientras mejor estén definidas las vías, más información se obtendrá para optimizar la 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 indicando el punto deseado en el mapa directamente. Así mismo permite conocer el tiempo estimado de la llegada, guarda los lugares más importantes como favoritos, conmuta automáticamente la 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 la ejecución del código.
1. Revisa la versión de Android a compilar y la versión del propio OsmAnd, es decir, revisa si se corresponde con la aplicación gratuita o la de pago (OsmAnd+). 2. Carga la configuración correspondiente a la versión identificada.
42 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
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 la memoria. Si no se encuentran archivos y hay conexión a Internet, se solicita al usuario la 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 conecte pues no puede funcionar la aplicación sin mapas.
5. Prepara los diferentes menús y visualiza el mapa preparándose para la navegación al pulsar 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 o recalcular 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 que es el entorno de desarrollo integrado oficial para la plataforma Android. Además, proporciona herramientas 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ón principalmente [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ño más tarde. A continuación se enumeran las principales funciones de este software que permiten aumentar 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, te • sugiere 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 compilar • un nuevo APK.
La posibilidad de integrar plantillas de código y GitHub ayudando así a compilar funciones • comunes de las apps e importar ejemplos de código.
VACA RECALDE, MYRIAM ELIZABETH 43 CAPÍTULO 4. DISEÑO DE LA INTERFAZ
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ón mientras añades los componentes, también cuenta con plantillas de diseños comunes y consta de un dispositivo virtual Android que se utiliza para ejecutar y probar aplicaciones como se puede 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ón final.
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 resultado final. Para ello es necesario saber de donde se parte, a donde se quiere llegar, como desarrollar la aplicación y que condiciones hacen falta para el desarrollo. Por este motivo a continuación se van a definir los parámetros que se deben enviar desde la tablet al vehículo y viceversa.
44 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
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 al coche.
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 de la 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 de tráfico, semáforos, pasos de peatonales, etc, con el fin de alertarlo y que reaccione correctamente de manera segura. d) La señal de paso entre modo de conducción manual y modo autónomo definido por el 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ón del 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 la etiqueta 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 pantalla y 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 de la posición desde el GPS del vehículo a la aplicación como se ha determinado antes. Al principio se 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 dispositivo propio 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 los datos GPS del vehículo obtenidos a través del LCM. El ícono utilizado para su identificación es el que se muestra en la Figura 4.4.1. Con esta herramienta se logra que todas las aplicaciones instaladas en la Tablet que requieran del conocimiento de la posición, obtengan la misma geolocalización que el vehículo.
El primer paso para la realización de esta aplicación es la adquisición de una serie de permisos como el que autoriza todo lo referente a la localización, conexión multicast entre otros, como queda representado en el siguiente código.
VACA RECALDE, MYRIAM ELIZABETH 45 CAPÍTULO 4. DISEÑO DE LA INTERFAZ
Figura 4.4.1 Ícono de la aplicación GPS AUTOPÍA.
1
Con los permisos programados, se procede a la configuración del proveedor de localización mediante 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ódigo que se muestran más abajo. Así mismo se crea un objeto del LocationListener, ll, para pasárselo al lm. Finalmente, se le pasan los datos de latitud, longitud, altitud y heading recibidos del LCM a un objeto de Location.
1 lm.setTestProviderEnabled(LocationManager.GPS_PROVIDER, true);
46 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
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 ha colocado como método de seguridad que se utilice el último heading recibido si la velocidad es menor o igual a 5 km/h.
Normalmente en el desarrollo de este tipo de aplicaciones, se calcula el bearing para colocarlo también como parámetro en el objeto Location. Este parámetro se corresponde al rumbo en grados 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 mediante la ecuación 4.4.1. Sin embargo Android tiene su propia función, distanceBetween, que calcula tanto la distancia aproximada en metros entre los dos puntos, como el bearing del camino más corto entre ellos.
Figura 4.4.2 Cálculo del bearing entre dos puntos.
sin(lon2 lon1) cos(lat2) bearing = arctan − ∗ (4.4.1) cos(lat1) sin(lat2) sin(lat1) cos(lat2) cos(lon2 lon1) ! ∗ − ∗ ∗ − "
Sin embargo, como el cálculo de este parámetro no era exacto y la rápida recepción de los puntos 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.3 donde se muestra la posición recibida (latitud y longitud) y, en la zona de Status aparecen los siguientes 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."
VACA RECALDE, MYRIAM ELIZABETH 47 CAPÍTULO 4. DISEÑO DE LA INTERFAZ
3. Y por último, si la recepción de datos es la correcta y no hay problemas, el texto que se muestra se corresponde a "Sending position" con el canal que recibe y el bearing en las siguientes 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ón objetivo 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 en la misma idea base, el diseño de un sistema de navegación para vehículos autónomos, usando para ello la información que ofrece el proyecto libre de mapas OpenStreetMap. En este caso, se utilizaba un ordenador a bordo del vehículo con sistema operativo Linux [15]. En la pantalla tá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 la utilización de una tablet por lo que la programación del mapa y la interfaz se realiza mediante código Android.
48 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
AUTOPÍA Route es una aplicación de navegación con acceso a todos los mapas de alta calidad y datos de OSM mediante la utilización del código abierto de OsmAnd. Estos mapas se descargan al comenzar la aplicación y con conexión a Internet. Una vez descargados, se almacenan en la memoria 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 dos actividades, una es unicamente el mapa con el recorrido, y la otra es la división en dos de la pantalla. 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 dar durante la ruta así como los avisos o alertas de diferentes situaciones, por ejemplo la detección de 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 las diferentes 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 nombre de la aplicación era CSICMaps, sin embargo se decidió cambiar por AUTOPÍA Route ya que el proyecto pertenece al grupo de investigación del CSIC que lleva este nombre, Programa AUTOPIA, y que se presentó en el capítulo 2.
El boceto se diseñó utilizando el programa Balsamiq Mockups que es un software que permite crear bocetos para aplicaciones de manera ágil y facilitando la creación de esquemas. Este programa 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ágenes cargadas que ayudan al diseño como el mapa o la carcasa de la tablet que se ven en la Figura anterior. También permite la inserción de imágenes como son la señal de ceda el paso o la de límite de velocidad. El único inconveniente es que tiene un precio de 79$ para la versión nativa y una suscripción de 12$ al mes si se quiere acceso a la interfaz web.
VACA RECALDE, MYRIAM ELIZABETH 49 CAPÍTULO 4. DISEÑO DE LA INTERFAZ
Volviendo a la aplicación, la ventaja de utilizar el código OsmAnd es que no se parte de un proyecto en blanco, sin embargo, también plantea un reto ya que se trabaja con una cantidad elevada de funciones y clases que requieren de su estudio y entendimiento para ser utilizadas. OsmAnd venía ya con la programación necesaria para la descarga de los mapas, el enrutamiento de las trayectorias, la visualización de la ruta en el mapa, el recálculo automático de la trayectoria, entre otras funciones.
Una vez definidas y estudiadas las herramientas que proporcionaba OsmAnd al proyecto y como se debería proceder para su modificación si fuese necesaria, se pasó al cambio de la actividad principal para realizar la división de pantalla. Para ello, se le añadió un LinearLayout vertical con el fin de poder controlar más cómodamente el espacio que se le adjudicaría a cada una de las divisiones.
A continuación se añadieron las primeras imágenes a la parte superior correspondientes a la vía (ver Figura 4.4.5). Luego se introdujo en medio el texto de la velocidad. Este cambio se representa 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, al ejecutar la aplicación en el dispositivo, el resultado no sea el esperando obteniendo zonas u objetos 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 inferiores en otras actividades que se incluían en la principal. Por esta razón, se modificó la actividad correspondiente a los elementos inferiores añadiendo los tres botones necesarios para lograr el 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 de modificar el modo de conducción de autónomo a manual y viceversa respectivamente. Esta comunicación se realiza mediante el envío al vehículo por el LCM de un uno si se pasa a modo autó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ón comienza en modo manual por defecto. Se decidió utilizar dos botones en posiciones distintas para evitar confusiones y saber en todo momento en que modo de conducción se encuentra ya que los botones se van alternando según sea el caso.
50 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
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 del mapa, permitiendo al usuario pasar de una visión detallada a otra en la que se ve unicamente la 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 se representa en la Figura 4.4.8. El texto de este último botón cambia de MAP a MAIN dependiendo de lo que se esté visualizando para volver al estado anterior.
Figura 4.4.7 Colocación de los botones.
VACA RECALDE, MYRIAM ELIZABETH 51 CAPÍTULO 4. DISEÑO DE LA INTERFAZ
Se debe resaltar que al comenzar la aplicación, la división y los botones no aparecerán hasta que se haya programado la primera ruta y empiece su simulación. Sin embargo, cuando se pase a ver unicamente el mapa, el texto de la mitad seguirá visible en la zona superior como se visualiza en la Figura 4.4.8.
Las visualización de las alarmas se colocó fuera del anterior LinearLayout vertical para que estuviesen visibles siempre durante el transcurso de la navegación. Para la explicación de la colocación de las imágenes correspondientes a cada alerta, se ha representado su posición en la Figura 4.4.8. Por un lado, en la esquina superior izquierda se encuentra la señal del límite de velocidad de la vía y en la zona media se dibujarán las diferentes señales de aviso, en el caso de 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 se muestran 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 un obstáculo como un peatón o un vehículo acercándose en un cruce. Con respecto a esta última situación, adicionalmente a la señal se mostrará en la carretera la imagen correspondiente a cada objeto, es decir, en el caso del peatón se representará un paso de cebra en la carretera y una dibujo de una persona en color naranja, si el obstáculo es un coche, aparecerá en el carril correspondiente del cruce.
Por otro lado, cuando el vehículo supera la velocidad permitida en la vía, el fondo del medio cambia y se vuelve rojo con el fin de llamar la atención del conductor. Así mismo, la velocidad máxima de la vía se obtiene mediante la información del mapa y se envía por LCM al vehículo con el fin de que el controlador de velocidad del bajo nivel la tenga como referencia.
52 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
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 de identificación para distinguirla y ejecutar la operación correspondiente como cambiar la visibilidad de la imagen que la define. La operación de interpretar cada caso se realiza en un hilo secundario ya que la verificación de la llegada de una alarma es una acción continua. Por otro lado, la modificación de la interfaz se ha realizado mediante el método propio de Android runOnUiThread ya que esta función solo ejecuta una acción especifica desde un hilo que se esté ejecutando sobre un componente del hilo principal.
Por otro lado, se visualizaran una serie de alertas obtenidas desde el tratamiento del mapa. Estas alarmas 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á por encima de los botones inferiores del mapa. La imagen correspondiente a cada aviso se visualizan en la Figura 4.4.10.
Figura 4.4.10 Alertas de alarmas captadas por el tratamiento del mapa.
VACA RECALDE, MYRIAM ELIZABETH 53 CAPÍTULO 4. DISEÑO DE LA INTERFAZ
Una vez definidos todos los aspectos gráficos que se visualizarán en la aplicación, se procede a la programación del envío de datos de la navegación, desde la tablet al coche, es decir, la ruta a recorrer por el coche, el modo de conducción mediante los botones de la actividad principal y 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 de la información que utiliza para crear la ruta de navegación. La aplicación guarda en un array los datos más relevantes de cada vía a seguir en la trayectoria y la información de los nodos que la componen y que intervienen en el recorrido. Así pues, se recogen de esa lista de 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 la redirección al equivocarse en el seguimiento de la trayectoria. Cada vía se exporta del array y se 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, en el centro se encuentra el botón correspondiente para cambiar a modo autónomo. Al hacer click en dicho botón, se envía por el canal "DRIVE_MODE.el valor 1 refiriéndose a su cambio a autónomo, desaparece el botón del centro y aparece otro a la izquierda el cual, al hacer click manda 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 OsmAnd y se envía por el canal "STREET_SPEED". Se tiene en cuenta que, cuando sucede una alarma de velocidad, es decir, que el vehículo detecta una señal, es la lectura de este dato el que se envía al planificador del vehículo y no la definida en el mapa pues este puede estar desactualizado o que la modificación de la velocidad proceda de una señal colocada en la vía de forma temporal por obras u otras circunstancias.
El proceso de envío de datos se realiza como se indica en el siguiente código, es decir, se procede a la activación de una instancia del LCM, a continuación se procesan los datos codificándolos a bytes y se introducen en el buffer cuyo espacio se ha dejado guardado al crearlo, finalmente se publica indicando el canal, el array de variables a enviar y el inicio y final de la lectura del array, en este caso se desea desde la primera posición hasta la longitud del array ya que sólo contiene las variables deseadas. Para la realización del envío se han creado hilos secundarios ya que debe ser continuo y saturaría el hilo principal.
1 ... 2 new Thread(new Runnable() { 3 @Override 4 public void run() { 5 LCM lcm = LCM.getSingleton(); 6 // Serialize component data 7 // 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
54 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
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 la Figura 4.4.11 de derecha a izquierda respectivamente.
Figura 4.4.11 Autopia Route.
VACA RECALDE, MYRIAM ELIZABETH 55
Capítulo 5
VALIDACIÓN / RESULTADOS
Validar el correcto funcionamiento de la aplicación es un punto principal sin embargo, no se ha podido probar con el coche real debido a la falta de los sensores y equipamiento necesario para el testeo de las diferentes situaciones planteadas. Por ello, se ha decidido hacer la simulación de un recorrido utilizando una lista de datos grabados y modificados que harán el rol del vehículo.
En este capítulo se explicarán con detalle las diferentes situaciones estudiadas y simuladas que se han realizado y se demostrará que las respuestas a los avisos se realizan correctamente por parte 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 el vehí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 Android por el LCM con el mismo formato que el resto de información enviado por el log grabado del vehículo.
Las alarmas se encuentran definidas mediante la estructura que se adjunta a continuación, por lo que tienen un identificador que indicará el tipo de alerta, la posición del objeto identificado por coordenadas geográficas (latitud y longitud), el nivel de alerta que se corresponde a la prioridad y por último el flags que se utiliza para definir otro parámetro que se requiera por ser una 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 obtienen cada variable que no se refiera a la posición. En el caso de los semáforos, el id se corresponde a 1X definiendo la X como el tipo es decir, para coches o peatonal. Por el momento este id se utiliza como 1 ya que no se considera otra clase de semáforo. Así mismo, en la aplicación sólo se tendrán en cuenta si están en rojo.
Tabla 5.1.1 Tabla de definición de alarmas.
Alarmas id nivel_alerta flags Comentario del valor de flags Velocidad 0 4 X Velocidad 1X 4 1 Rojo Semaforos 1X 3 2 Amarillo 1X 0 3 Verde 21 3 0 Señal de STOP Señal de tráfico 22 2 0 Señal de Ceda el paso 31 2 0 1 Coche der izq Obstáculo / / 32 3 0 / 1 Peatón der / izq
Por otro lado, estas alarmas se incorporan al array de alarmas del objeto osmand_alarmas que queda definido de la siguiente forma.
1 struct osmand_alarmas 2 { 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 log del vehículo como se muestra en la Figura 5.1.1. Así mismo, esta información es aportada por el GPS.
Figura 5.1.1 Envío de alarmas mediante LCM.
58 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
5.2 Resultados de la aplicación
Como se ha mencionado en el capítulo anterior, la aplicación comienza con el mapa en toda la pantalla y los botones correspondientes para navegar por el o empezar una ruta. Para la validación del funcionamiento de la aplicación se ha escogido una navegación desde la salida del CSIC en la calle Pedro de Valdivia hasta la salida dirección al retiro en la rotonda de la Puerta de Alcalá (ver Figura 5.2.1). Este segmento se corresponde a la información del log que simula el comportamiento del vehículo. Se ha seleccionado este fragmento ya que a lo largo de la 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 recuadro verde en la imagen de la izquierda de la Figura 5.2.2. Esta acción abre un menú que permite al usuario colocar tanto el destino final como el de origen aunque por defecto este último punto viene como la ubicación actual. En este caso se ha seleccionado el punto final colocando el punto directamente en el mapa y la aplicación ha colocado una referencia de la posición, "Calle de Alcalá (Jerónimos), Retiro".
Figura 5.2.2 Inicio de la aplicación Autopia Route.
VACA RECALDE, MYRIAM ELIZABETH 59 CAPÍTULO 5. VALIDACIÓN / RESULTADOS
Una vez seleccionado el destino, se comienza la navegación al hacer click en el botón "Ir"que está 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 ha enviado correctamente por su visualización en la aplicación para lectura de puertos Multicast denominada Multicas Tester1. Los datos de la ruta enviados se visualizan en la imagen de la Figura 5.2.3 que se corresponde a una captura de pantalla de dicha aplicación. Se han copiado un par de líneas como ejemplo de esta información en el siguiente código. Como se observa os 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 para aclarar y visualizar los datos. el número largo se corresponde al Identificador de la calle y los siguientes 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,2 4 [You] LC02RUTA Wr 5 [You] LC02RUTATxt 437147506,0,2 6 ...
Así mismo, en la misma imagen se puede observar el envío del cambio del modo de conducción
1Multicas 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ás permite no sólo la recepción sino también el envío de mensajes de este tipo. Como ventaja tiene una interfaz simple e intuitiva y permite visualizar el envío de datos en hexadecimal pudiendo así ver los datos descodificados de cierta forma.
60 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP manual a autónomo y viceversa, mediante un 0 para el primer caso y 1 para el segundo; y el límite de velocidad de la vía. Esta información se ha copiado en el siguiente código para mejor
visualizació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_SPEEDBH 3 [You] LC02/STREET_SPEEDTxt 50.0 km/h 4 [You] LC02?STREET_SPEEDA ? 5 [You] LC02?STREET_SPEEDTxt 20.0 km/h 6 ... 7 [You] LC02 DRIVE_MODE 8 [You] LC02 DRIVE_MODETxt 1, Modo Autónomo 9 ... 10 [You] LC02 DRIVE_MODE 11 [You] LC02 DRIVE_MODETxt 0, Modo Manual 12 ...
Como ha surgido una alarma de velocidad que indica el cambio de 50 a 20 km/h, el dato enviado al 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 se puede percibir que a la derecha el sistema se encuentra en modo de conducción Manual y a la derecha 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 ha superado el límite especificado por lo que se produce el cambio de fondo de la velocidad de blanco a rojo para llamar la atención al conductor ya que su velocidad es mayor a la máxima en ese tramo (ver Figura 5.2.5).
VACA RECALDE, MYRIAM ELIZABETH 61 CAPÍTULO 5. VALIDACIÓN / RESULTADOS
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áforo como se observa en la Figura 5.2.6. Como se ha señalado anteriormente, esta alerta se activa unicamente 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 la alarma para una señal de ceda el paso, un STOP,y dos tipos de obstáculos, un peatón y un cruce
62 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP de un coche que viene por la derecha respectivamente. Como se ha comentado en el capítulo anterior, al detectar los obstáculos, la información gráfica avisa al usuario de que obstáculo se trata.
Figura 5.2.7 Alarma de señal de ceda el paso.
Figura 5.2.8 Alarma de señal de STOP.
VACA RECALDE, MYRIAM ELIZABETH 63 CAPÍTULO 5. VALIDACIÓN / RESULTADOS
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 el trayecto, notando que las alarmas y el límite de velocidad se representan en los dos casos.
64 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
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 el usuario tiene la opción de elegir la búsqueda de un aparcamiento, recalcular la ruta o detener la navegación como se muestra en la Figura 5.2.12.
Figura 5.2.12 Llegada al destino
VACA RECALDE, MYRIAM ELIZABETH 65 CAPÍTULO 5. VALIDACIÓN / RESULTADOS
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 saltado correctamente en los cruces señalados y el envío de la información al vehículo se ha realizado satisfactoriamente.
Se corrobora la rapidez y el funcionamiento de la comunicación, ya que los datos del coche se reciben y representan al instante produciendo una simulación bastante real al comportamiento obtenido por un vehículo. La detección de las alarmas y su aviso en pantalla es claro y de fácil entendimiento para el conductor. Por último, se ha verificado que la información del mapa es bastante completa y mayoritariamente fiable ya que aún hay información que se puede añadir.
66 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) Capítulo 6
CONCLUSIONES Y FUTUROS TRABAJOS
La investigación en vehículos autónomos lleva varias décadas desarrollándose y el avance de la tecnología actual abre más puertas a su desarrollo permitiendo su comercialización no solo como sistemas de asistencia a la conducción, sino también como vehículos con niveles de autonomía 3 e incluso 4. Sin embargo, aún queda bastante para la implementación de un vehículo terrestre con completa autonomía. A pesar de ello, cada paso realizado en el perfeccionamiento de algún sistema implementado o la adición de un componente nuevo ayuda 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 proyecto y 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 su desarrollo y obtener los resultados de la simulación para la validación del proyecto, se ha llegado a las siguientes conclusiones:
1. Un vehículo autónomo requiere de navegador y planificador de rutas completo, efectivo y 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 el vehí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 el proyecto con otros dispositivos.
4. Se ha realizado con éxito una comunicación LCM en la tablet, logrando una recepción y envío de datos rápido y fiable.
5. Se ha efectuado un estudio del proyecto OpenStreetMaps, llegando a entender la forma de 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 o señ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 con el 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 proyecto consta 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 y optimizar 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 alarmas para 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, logrando así validar su correcto funcionamiento tanto en la lectura y envío de datos como en las animaciones 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 robusto y fluido para la navegación de vehículos completamente autónomos. Con este fin, se proponen la siguiente lista de trabajos futuros con los que se estima la mejora del proyecto y puntos que no 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 aprovechar al máximo los datos del mapa ya procesados.
2. Mejorar el diseño de la interfaz, sobretodo la carretera, y lograr realizar la representación de una rotonda.
3. Añadir información externa en tiempo real para optimizar la aplicación como el nivel de tráfico, accidentes, obras, meteorología, etc.
68 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM) INTEGRACIÓN EN TIEMPO REAL DE UN NAVEGADOR BASADO EN OPENSTREETMAP
4. Revisar la información del mapa y mejorar su procesado para obtener más datos de otras alarmas, 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 de destino manualmente.
8. Optimizar el cálculo de ruta y el refresco del mapa ya que es lento y tarda en obtener una ruta si el destino es muy lejano.
9. Intentar actualizar la base de datos de OSM con la información obtenida del sistema de percepción del vehículo, con el fin de tener actualizado el mapa aumentando su detalle y 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 el coche y se hagan pruebas son el futuro trabajo que se puede realizar teniendo como base este proyecto.
VACA RECALDE, MYRIAM ELIZABETH 69
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 cruise control 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/IFIP Conference 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 transport safer: 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 keeping in 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,” IEEE Transactions 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 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 entornos urbanos y autovías,” Ph.D. dissertation, Universidad Politécnica de Madrid, Escuela Superior de 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 en openstreetmap,” 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
72 ESCUELA TECNICA SUPERIOR DE INGENIEROS INDUSTRIALES (UPM)