TFG Jimenez Garcia 2022

Universidad de Alcalá
Escuela Politécnica Superior
Grado en Ingeniería en Electrónica y Automática

Industrial
Trabajo Fin de Grado

Desarrollo de un interfaz de visualización de datos para un vehículo
autónomo
Autor: Víctor Jiménez García
Tutor: Rubén Izquierdo Gonzalo

Cotutor: Álvaro Quintanar Pascual
2022
GRADO EN INGENIERÍA EN ELECTRÓNICA Y

AUTOMÁTICA INDUSTRIAL
Trabajo Fin de Grado

Desarrollo de un interfaz de visualización de datos para un vehículo
autónomo
Autor: Víctor Jiménez García
Tutor: Rubén Izquierdo Gonzalo

Cotutor: Álvaro Quintanar Pascual
TRIBUNAL:
Presidente: D. Ignacio Parra Alonso
Vocal 1º: D. Iván García Daza
Vocal 2º: D. Javier Alonso Ruiz
FECHA: 26/09/2022
Agradecimientos
Me gustaría expresar mis agradecimientos al tutor de este TFG, D. Rubén Izquierdo Gonzalo, el
interés, apoyo, disponibilidad e implicación que ha mostrado en todo momento ha sido fundamental
para llevar este trabajo adelante. También agradecer la ayuda y el tiempo por parte de D. Álvaro
Quintanar Pascual y D. Ignacio Parra Alonso. Gracias a ellos ha sido posible llevar a cabo las pruebas
necesarias con el vehículo real para completar este TFG.
Índice general
Índice general I
Índice de figuras III
Índice de tablas V
Lista de acrónimos VII
Resumen IX
Abstract XI
Resumen extendido XV
1 Introducción 1
1.1 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Organización de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Estado del arte 5

2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Descripción del Sistema 13

3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Herramientas necesarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Vehículo autónomo y sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Sistema operativo utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 Herramientas necesarias para el desarrollo del proyecto. . . . . . . . . . . . . . 17
I
II ÍNDICE GENERAL
3.3 Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1 Diagrama de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Pruebas 29
4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Prueba de la interfaz mediante simulación . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Prueba de la interfaz en el vehículo autónomo . . . . . . . . . . . . . . . . . . . . . . . 31
5 Resultados 35
5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Resultados de la prueba mediante simulación . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 Resultados de la prueba con vehículo autónomo . . . . . . . . . . . . . . . . . . . . . . 37
6 Conclusiones y líneas futuras 43

6.1 Líneas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A Manual de usuario 45
A.1 Instalación de las herramientas necesarias . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.2 Uso de la interfaz y conĄguración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Bibliografía 49
Índice de figuras
2.1 Vista interna Cruise4U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Reconocimiento facial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Volvo automático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Interfaz Volvo XC90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Interfaz Mercedes-Benz 2024 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Interfaz Tesla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Vistas del vehículo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Grasshopper3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Continental ARS 308-2 | Radar de largo alcance . . . . . . . . . . . . . . . . . . . . . 15
3.4 Bus Controller Area Network (CAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Unidad de Medida Inercial (IMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Interfaz inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.7 Botón de representación en interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.8 Variación nivel de alejamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.9 Segunda pestaĳa trayectorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.10 Segunda pestaĳa sin trayectorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.11 Errores del vehículo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.12 Límite error lateral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.13 Diagrama primera pestaĳa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.14 Diagrama segunda pestaĳa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.15 Diagrama tercera pestaĳa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Prueba simulada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Red del vehículo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Cámara interior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Distribución de pantalla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
III
IV ÍNDICE DE FIGURAS
5.1 Resultado 1 simulado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 Resultado 2 simulado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Resultado errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Interior del vehículo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5 Exterior vehículo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6 Prueba real pestaĳa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.9 Prueba real pestaĳa errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.10 Prueba real pestaĳa errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.1 Botón Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

A.2 Casillas de las trayectorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Índice de tablas
3.1 Características del Citroën C4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Características del radar de largo alcance ARS 308-2 . . . . . . . . . . . . . . . . . . . 14
3.3 Datos obtenidos a través del bus CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
V
Lista de acrónimos
ADAS Advanced Driving Assistance Systems.
CAN Controller Area Network.
ECU Electronic Control Unit.
GPOS General Purpose Operating System.

GPS Global Positioning System.
IMU Unidad de Medida Inercial.
NASA National Aeronautics and Space Administration.
RAM Random Access Memory.

RTK Real Time Kinematic.
RTOS Real Time Operating System.
SAE Society of Automotive Engineers.
UFW Uncomplicated Firewall.

UTM Universal Transverse Mercator.
VPN Virtual Private Network.
VII
Resumen
Hoy en día el desarrollo de los vehículos autónomos está en auge. Para poder mejorar y avanzar
con el desarrollo de esta tecnología es fundamental tener conocimiento de los distintos parámetros
del vehículo. Con este propósito es necesario crear una interfaz en la que podamos ver el correcto
funcionamiento del vehículo en tiempo real, analizar datos y corregirlos de forma más precisa. Esta
interfaz será creada con el entorno de desarrollo integrado multiplataforma Qt Creator, un IDE
enfocado en el desarrollo de aplicaciones con Interfaces GráĄcas de Usuario con las bibliotecas de Qt.
Palabras clave: vehículo autónomo, interfaz, QtCreator, desarrollo.
IX
Abstract
Nowadays, the development of autonomous vehicles is growing. In order to improve and advance with
the development of this technology, it is essential to know the different parameters of the vehicle.
For this purpose, it is necessary to create an interface where we can see the correct operation of the
vehicle in real time, analyze data and correct it more precisely. This interface will be created with the
cross-platform integrated development environment Qt Creator, an IDE focused on the development
of applications with Graphical User Interfaces with the Qt libraries.
Keywords: autonomous vehícle, interface, QtCreator, development.
XI
Resumen extendido
Los vehículos autónomos son un tema de actualidad y de futuro. Cada día más empresas se unen
a la investigación y mejoran sus prototipos o productos. Al tratarse de vehículos autónomos es
fundamental tener control sobre estos y conocimiento sobre cada aspecto sobre el propio vehículo
o de aquellos parámetros que forman su trayectoria. Para tener un mayor conocimiento de estos y
poder estudiar mejor el comportamiento de este tipo de vehículos se ha querido desarrollar la interfaz
que se explica a continuación.
El principal objetivo de este proyecto es el diseĳo e implementación de un interfaz de repre-
sentación de datos para un vehículo autónomo. Principalmente se ha desarrollado un sistema de
visualización de la localización del vehículo sobre mapas de vista aérea, pudiendo ver en estos posi-
bles mapas de rutas. Se podrán seleccionar distintos tipos de visualización del recorrido del vehículo.
También se mostrará de forma gráĄca la variación de los errores laterales y angulares del vehículo,
así como los parámetros más importantes de forma numérica sobre el funcionamiento del vehícu-
lo. Este sistema se ejecutará en un ordenador independiente al del vehículo, siguiendo el modelo
vista-controlador.
Para la creación de la interfaz ha sido necesario el uso principalmente del entorno de desarrollo
integrado multiplataforma Qt Creator. Este programa será utilizado en el sistema operativo Ubuntu,
que es una distribución de Linux. Qt Creator permite la creación del interfaz con objetos y mediante
el código de lenguaje C++, se darán las funciones necesarias a estos objetos para que lleven a cabo
los objetivos del proyecto. La creación de los mapas ha sido posible gracias a la herramienta de
edición de imágenes Paint. Con capturas del campus CientíĄco-Tecnológico desde Google Earth, se
ha creado un mapa global que deberá recorrer el vehículo. Para la manipulación de este mapa creado
en la aplicación de Qt Creator ha sido necesario el uso e instalación de OpenCV. Se trata de una
biblioteca de código abierto, que permite la manipulación de las imágenes, en el caso de la interfaz,
se usará para ver distintas formas de representación de los mapas durante el recorrido del vehículo
autónomo.
La interfaz dispone de tres pestaĳas. Las dos primeras disponen de un botón que, al pulsarlo se
mostrará el mapa global utilizado desde el punto más alto. Debajo de este botón se encuentran dos
checkboxes que se pueden marcar y desmarcar. Estas casillas tienen la función de mostrar u ocultar
las dos trayectorias que se pueden representar en el mapa durante el recorrido. Se puede mostrar
cada trayectoria por separado marcando su respectiva checkboxe o la opción de representar ambas
trayectorias marcando las dos casillas. La visualización de las trayectorias se puede ocultar o cambiar
en cualquier momento durante el funcionamiento del vehículo. En caso de no marcarse ninguna se
podrá ver la representación del mapa sin ninguna de las trayectorias disponibles. Estas trayectorias se
XIII
XIV Resumen extendido
mostrarán en colores distintos para poder diferenciarlas claramente y son del mismo color en ambas
pestaĳas para evitar errores.
En la primera pestaĳa, la representación de la trayectoria del vehículo se podrá ver mediante un
rectángulo en el centro que representa el coche mientras que, el mapa gira alrededor de éste. Con esta
forma de visualización el vehículo siempre lo vemos avanzando hacia la parte superior de la interfaz,
como sería una conĄguración normal de un Global Positioning System (GPS). En la segunda pestaĳa
se tiene una visualización diferente del vehículo. En este caso también se encuentra en el centro de la
imagen pero, en vez de girar el mapa en torno a él, es el propio vehículo que gira en las curvas que se
encuentre. Para que coincida el movimiento del vehículo real con el representado en el mapa ha sido
necesario crear una conversión entre coordenadas Universal Transverse Mercator (UTM) que recoge
el vehículo a píxeles en el mapa. Para esta conversión ha sido necesario crear un factor de escala
para la coordenada x e y aunque deben ser iguales teóricamente. Este factor de escala multiplica a
la diferencia entre las coordenadas reales y un offset elegido en cualquier punto (del área que se vaya
a recorrer) en UTM. Para acabar la conversión se debe sumar el mismo offset que se ha usado en
la diferencia que multiplica el factor de escala pero, esta vez, en píxeles de la imagen. Incorporando
esta fórmula en el código se puede convertir las coordenadas en UTM que se reciben del vehículo a
píxeles de la imagen para que coincida la trayectoria real con la vista en el mapa creado.
En cuanto a la última pestaĳa hay una representación gráĄca del error lateral y angular del
vehículo cuando recorre las trayectorias que se pueden ver sobre el mapa. En esta pestaĳa no existe
ningún botón ni checkboxe para seleccionar algún tipo de representación como en las primeras pesta-
ĳas. Esta se trata únicamente de una pestaĳa de visualización. En esta representación se podrá ver
una línea verde central que separa la imagen en dos, y sobre esta un rectángulo verde con una cruz
en el centro representando el vehículo. A ambos laterales de la línea central verde se encuentran dos
líneas azules que marcarán una distancia de 1.5 metros, de esta forma será mucho más intuitivo saber
aproximadamente el error lateral del vehículo. En el caso de que este se salga de la trayectoria, ambos
errores se incrementarán signiĄcativamente, pero, a la hora de la representación, solo se podrá ver
un límite de 8 metros del error lateral. En caso de superar este valor la representación del vehículo
se situará en el borde de la imagen.
Para asegurar que la representación del error lateral se ajuste a la realidad, se ha tenido que hacer
una conversión de las medidas del vehículo a píxeles. Por ejemplo, si el vehículo mide 2 metros de
ancho y el error lateral es 1 metro, el desplazamiento será de la mitad a su ancho. Esto se consigue
asignando una cantidad de metros a otra de píxeles del vehículo, aplicándose a los datos del error
lateral que lleguen por parte del vehículo, consiguiendo que el desplazamiento sea acorde a la realidad.
Estas pestaĳas nos ofrecían distintas formas gráĄcas del movimiento del vehículo y sus errores,
pero la interfaz también ofrece la posibilidad de ver otros parámetros de importancia del vehículo.
Para ello, se ha creado a la izquierda de la interfaz un espacio con múltiples cajas, una debajo de otra
que mostrarán los distintos parámetros relevantes del vehículo. Estos parámetros son la velocidad,
orientación, las coordenadas que recorre el vehículo sobre el mapa, coordenadas UTM del vehículo,
error lateral y angular y el nivel de alejamiento de la cámara. Esta última caja no es un parámetro
del vehículo, se trata de un número modiĄcable que sirve para ajustar al gusto del usuario el nivel de
alejamiento con el que ver la trayectoria por el mapa. Se puede modiĄcar en todo momento y cuanto
mayor es el número, más mapa alrededor del vehículo se podrá ver.
Resumen extendido XV
Para comprobar el funcionamiento de la interfaz se han realizado dos pruebas. La primera me-
diante simulación y la última con el vehículo. Para la prueba mediante simulación ha sido necesario
implementar un mecanismo de envío de datos Ącticio para la simulación de la interfaz y su funcio-
namiento. Esto se ha conseguido con un código independiente a la interfaz, siendo su función leer
los archivos generados por el vehículo en pruebas reales y mandar los datos leídos al código de la
interfaz. Esta lectura y envío de datos se ha realizado en el mismo tiempo que lo haría el vehículo
para comprobar que la interfaz funciona correctamente. La segunda prueba se ha llevado a cabo con
el vehículo real, permitiendo comprobar si la representación de la interfaz sigue el recorrido y cambios
del vehículo.
Esta interfaz ha sido creada para ser usada por un desarrollador, no para Ąnes comerciales como
pueden ser las interfaces de grandes empresas automovilísticas. Se busca tener conocimiento del
vehículo y su movimiento, para poder ser corregido o analizado de forma más directa y simple en
tiempo real.
Capítulo 1
Introducción
1.1 Motivación
El interés por los vehículos autónomos crece cada vez más deprisa y es seguro que será una tecnología
indispensable el día del maĳana. Este tipo de vehículos se suelen asociar al transporte de personas,
pero su utilidad puede abarcar muchos más campos, por ejemplo, en el transporte de mercancías.
Todas aquellas actividades que impliquen un desplazamiento se pueden llevar a cabo con vehículos
autónomos. En países como Suiza o China ya se tienen planes o, incluso licencias, para el uso de esta
tecnología. A pesar de estos avances, todavía no se ha conseguido llegar al punto más óptimo y seguro
de este tipo de vehículos. Por ello, la industria está en pleno desarrollo e investigación y la mayoría de
las grandes empresas de vehículos más importantes están realizando sus propios proyectos. Este tipo
de transporte, con su debido tiempo, conseguirá ser más seguro y organizado que si es llevado por
el ser humano, lo que es una gran ventaja además de la comodidad que puede ser para las personas
pudiendo usar transporte privado si no pueden conducir por algún motivo de salud o físico.
En un nivel más privado, como puede ser el transporte que hace una persona todos los días, es
conveniente que el usuario pueda comprobar de primera mano y de forma visual el comportamiento
del vehículo. El hecho de que un vehículo sea autónomo implica que no hay un conductor humano,
por lo que es importante saber en todo momento la ruta que puede o va a recorrer el vehículo. Otro
aspecto importante es el conocer otros datos de interés del vehículo, como su dirección, errores en la
posición y otros parámetros que permitan conocer al usuario de forma más precisa el desplazamiento
del vehículo. Para poder controlar todos estos aspectos mencionados existe la interfaz, gracias a ella
permitirá un mayor control del coche por parte del usuario. Al tratarse de un vehículo autónomo no
supone ningún riesgo el uso de una interfaz táctil.
A nivel de desarrollo del vehículo es muy importante poder comprobar el estado del coche y
conocer de forma exacta los datos que este nos aporta en la conducción. De esta forma, se pueden
recoger los datos a tiempo real y sacar las conclusiones necesarias para poder corregir los posibles fallos
o mejorar aquellos aspectos que se consideren necesarios. La implementación de una interfaz puede
ser de gran ayuda y permite una mejor comprensión de los datos del vehículo en su funcionamiento,
permitiendo una mayor velocidad y precisión en su desarrollo.
1
2 Capítulo 1. Introducción
1.2 Objetivos
Se tiene como objetivo principal el diseĳo e implementación de un interfaz de representación de datos

para un vehículo autónomo. Los objetivos más importantes que se han buscado alcanzar en este
proyecto son:
• Como interfaz se empleará una pantalla táctil que permitirá interactuar al usuario y tendrá
diferentes características.
• Principalmente se desarrollará un sistema de visualización de la localización del vehículo sobre

mapas de vista aérea. Además, se visualizarán posibles mapas de rutas. Para los mapas de vista
aérea se utilizará las imágenes y localizaciones que nos proporciona Google Maps gracias a su
sistema de satélites.
• Se deberán visualizar, además, el estado de funcionamiento de los diferentes sistemas y variables

de estado del vehículo. Como variables de estado se podrán tener, entre otras: el ángulo entre
la dirección del eje mayor del coche y el eje central del segmento en el que está el coche o la
distancia lateral entre el eje central del coche y el eje del segmento por el que circula. Estas
variables permitirán conocer la dirección y posición del coche para poder corregirlas o saber la
trayectoria que sigue.
• El sistema de visualización se ejecutará en un ordenador independiente al del vehículo, siguiendo

el modelo vista-controlador.
• Implementar un protocolo de comunicación basado en red.
1.3 Organización de la memoria
La memoria de este proyecto está dividida en cinco capítulos y tres anexos:
• Capítulo 1: capítulo actual, donde se hace una pequeĳa introducción en forma de motiva-
ción, se concretan los objetivos a cumplir en el proyecto y se detalla la organización de este
documento.
• Capítulo 2: el estado del arte, donde se enumerarán y se dará una breve información sobre
los trabajos más relevantes de otros grupos de investigación.
• Capítulo 3: el capítulo más extenso, en el cual se hará la descripción del sistema realizado
durante estos últimos meses.
• Capítulo 4: se expondrán las pruebas que se han realizado a nuestro proyecto una vez termi-
nado.
• Capítulo 5: tras las pruebas expuestas en el capítulo cuatro se detallarán los resultados obte-
nidos.
1.3 Organización de la memoria 3
• Capítulo 6: se expondrán las conclusiones del trabajo detallando de forma resumida las apor-
taciones realizadas en el proyecto. Se enumerarán las líneas futuras
• Apéndice A: en este se detalla el pliego de condiciones. Se incluye las condiciones generales,

condiciones de materiales, de equipos y condiciones de ejecución.
• Apéndice B: se analizará las partidas monetarias presupuestadas para la consecución de este

proyecto. Será incluido la ejecución material, gastos generales y beneĄcio industrial, honorarios
de dirección y redacción, coste de ejecución por contrata y presupuesto total.
• Apéndice C: corresponde al manual de usuario.

Capítulo 2
Estado del arte
2.1 Introducción
En este capítulo hablaremos de los trabajos más relevantes de otros grupos de investigación sobre
los vehículos autónomos y sus interfaces interactivas. Hoy en día muchas empresas punteras de
automóviles están en proceso de desarrollo y mejora de sus propios vehículos autónomos, sin embargo,
se expondrán a continuación los proyectos futuros y presentes de las empresas más avanzadas o con
propuestas más interesantes en este ámbito. Al Ąnal del capítulo se resumirá el enfoque actual de
estas tecnologías y se explicará la diferencia con el proyecto que se expondrá en el siguiente capítulo.
2.2 Desarrollo
Un vehículo autónomo es realmente complejo, y lo es cada vez más a medida que se perfecciona e
investiga sobre el tema. Desde los inicios, los vehículos han sido en gran parte muy mecánicos, sin
embargo, con el paso de los aĳos la electrónica se ha ido adentrando en la industria automovilís-
tica hasta crear o en proceso de crear los vehículos autónomos. Este avance supone que al propio
vehículo se le pueda considerar una red de ordenadores conectado a distintas unidades de control
llamadas Electronic Control Unit (ECU) [1]. Estas unidades de control poseen distintos sistemas
operativos y gracias a estas el vehículo es capaz de tener control sobre ciertos aspectos de su correcto
funcionamiento, como la batería, el estado de las ruedas, la interfaz del vehículo...etc.
En cuanto a estos sistemas operativos, los más populares y utilizados para la gestión de informa-
ción y entretenimiento son Android Automotive y Apple CarPlay. Ambos son de las empresas más
punteras y reconocidas en la actualidad, y permiten dotar al ordenador de a bordo o interfaz de capa-
cidad para mostrar mapas, escuchar música y realizar llamadas con el propio móvil del usuario, entre
otras muchas funciones. Estos dos sistemas operativos de Android y Apple pertenecen a la categoría
de General Purpose Operating System (GPOS) [1], en la cual se encuentran la mayoría de sistemas
operativos que utilizamos en nuestra vida cotidiana como en el móvil u ordenador. Una categoría
muy importante para los vehículos autónomos serían los sistemas operativos de la categoría Real
Time Operating System (RTOS), estos se encargan de la parte más compleja y son en tiempo real.
Un ejemplo de sus tareas sería la corrección de dirección, los frenos, cambio de marchas y aquellas
5
6 Capítulo 2. Estado del arte
tareas necesarias para la conducción del vehículo por lo que deben ser capaces de realizar sus tareas
en milésimas de segundo.
Uno de los sistemas operativos más populares utilizados en vehículos autónomos de fabricantes
como Ford, Audi o BMW dentro de la categoría RTOS es el QNX Neutrino. Este sistema operativo
está basado en UNIX y permite centralizar todas las tareas de un vehículo autónomo incluyendo
la parte Advanced Driving Assistance Systems (ADAS) [1]. Otro sistema operativo de la misma
categoría muy popular es el WindRiver VxWorks utilizado en vehículos de marcas de coches y en el
robot Curiosity de la National Aeronautics and Space Administration (NASA). A pesar de todos los
aspectos positivos que nos aporta este tipo de tecnologías puede haber aspectos negativos como la
distracción. No todos los vehículos autónomos tienen una conducción autónoma por completo sino
que se puede utilizar este tipo de conducción activándolo en determinados tramos de carretera como
en las autovías. Al pasar de un modo a otro puede haber peligro por la distracción del conductor con
la interfaz con la que interactúa. Para esta situación, la empresa Valeo ofreció con su propuesta de
interfaz Mobius una solución a este problema. En esta interfaz, al entrar en el modo de conducción
autónoma se visualiza en parte lo que pertenezca a la interfaz (mapas, aplicaciones, tiempo en el
lugar..) y, además, se muestra información sobre el vehículo como la velocidad actual o el siguiente
giro o movimiento a realizar [2]. Así, se permite al conductor situarse y conocer en que situación está
el coche antes de tomar el control, siendo fácil mirar esta información, ya que la interfaz se sitúa cerca
de la carretera. La propia empresa realizó pruebas en el Laboratorio de Interacción con Vehículos del
Instituto Fraunhofer (Alemania) y comprobaron su teoría. Gracias a la posición e información de la
interfaz con la vista periférica es suĄciente para reducir el tiempo de reacción al cambiar el modo de
conducción autónomo a manual.
Figura 2.1: Vista interna del vehículo autónomo Cruise4U mediante simulación [3].
Esta tecnología fue utilizada en su primer gran prototipo funcional llamado ŞCruise4UŤ con con-
ducción autónoma tanto en carretera como autopista permitiendo al usuario decidir sobre la conduc-
ción automática o manual mediante la interfaz como se ha comentado anteriormente. Este prototipo
utiliza una tecnología de escáner láser Valeo SCALA®, esta permite un funcionamiento automático
gracias a su rango de detección extendido, amplio campo de visión y precisión. La tecnología de es-
cáner láser detecta con alta precisión obstáculos estáticos o en movimiento y puede anticipar eventos
[3]. Otra función que podría ser muy útil por parte de la propia interfaz sería tener control sobre los
ojos del propio conductor para saber si está pendiente de la carretera, para esto crearon un sistema
2.2 Desarrollo 7
en 2018 con una cámara para analizar el estado de atención del conductor. Su función principal es
alertar al conductor cuando se encuentre conduciendo manualmente si está distraído o cuando el
coche cambia de función autónoma a manual. También es capaz de detectar cuando el conductor
tiene signos de somnolencia, emitiendo una seĳal de alerta o la opción para el conductor de moverse
por la interfaz utilizando los ojos [4].
Figura 2.2: Sistema de reconocimiento facial creado por Valeo [4].
Durante el aĳo 2021 Valeo presentó su último modelo de vehículo al que han llamado ŞValeo
Drive4UŤ, este modelo tiene un nivel 4 de conducción autónoma. En cuanto a este tipo de conducción
existen 5 niveles creados por la americana Society of Automotive Engineers (SAE), en el nivel uno
existe una asistencia del vehículo al conductor encargándose de controlar la dirección o la aceleración
pero no los dos a la vez. En el nivel dos se avanza hasta una automatización parcial de la conducción,
en este caso el vehículo sí se encarga de la dirección y la aceleración pero el conductor debe llevar
el resto de aspectos relacionados con la conducción. Con el nivel tres se tiene una automatización
de conducción donde el vehículo se encarga de todas las actividades relacionadas con la conducción,
pero el conductor debe estar atento ante una posible intervención. En el penúltimo puesto se tiene el
nivel 4, en la que el vehículo posee una automatización de conducción alta y el vehículo no depende
de una posible intervención del conductor, como sí pasaba en el anterior nivel. Por último tenemos
el nivel cinco, donde hay una automatización completa de la conducción por parte del vehículo [5].
Este nuevo modelo de vehículo es capaz de gestionar el tráĄco urbano y periurbano, los atascos,
las intersecciones, las glorietas, los pasos de cebra, los semáforos o las zonas de obras [6]. Al tratarse
de un vehículo autónomo de nivel cuatro debe ser capaz también de adelantarse o predecir ciertos
sucesos, como los movimientos de personas alrededor del coche, frenando antes de que hayan siquiera
iniciado el movimiento. Esto lo llevan a cabo mediante un sistema llamado ŞValeo MovePredict.aiŤ.
Para mejorar la precisión de la localización del coche también incluye la tecnología llamada ŞValeo
Drive4U LocateŤ siendo capaz de dar una precisión de centímetros. Otra gran empresa pionera en
la conducción autónoma es Volvo. Actualmente disponen del modelo XC90, que ofrece tecnología de
asistencia a la conducción, esta tecnología supondría un nivel uno en la conducción autónoma, ya
que el vehículo puede modiĄcar la dirección y la aceleración si se pone en peligro la seguridad. Este
modelo posee un sistema de puntos ciegos, lo que permite al vehículo ajustar su dirección si detecta
que la trayectoria actual tiene riesgo de colisión al cambiar de carril. Otra ayuda a la conducción
gracias a este sistema es la posibilidad de detectar y corregir las salidas de carril como evitar las
colisiones. Si el vehículo empieza a pisar una línea central o lateral, este sistema es capaz de corregir
la dirección, también permite detectar y evitar otros vehículos, peatones, ciclistas o animales que se
encuentren cerca de la trayectoria del vehículo. La primera medida que se adopta es la advertencia
al conductor, y después frena automáticamente si este no reacciona. El vehículo cuenta con cuatro
cámaras distribuidas, de forma que se ofrece una visión de 360º y sensores laterales que hacen posible
todas estas medidas de seguridad en la conducción. Por último, este modelo actualmente dispone de
la función Cross Traffic Alert, puede detectar vehículos que se cruzan por detrás y, si es necesario,
puede aplicar el freno automático [7]. En este mismo modelo Volvo tiene grandes planes de futuro.
A los nuevos vehículos se les equipará un sistema de inteligencia artiĄcial llamado NVIDIA Drive
Orin [8] . Este sistema permitirá dotar al vehículo de una función de conducción autónoma sin
supervisión, esto supondría un nivel tres de autonomía, un gran salto desde el nivel uno del modelo
actual. Este nivel supone un control total de los movimientos del coche, detección y respuesta ante
obstáculos y eventualidades, así como de capacidad de avisar y ceder el control al conductor humano
en caso de problemas. Esta función de conducción autónoma, denominada Highway Pilot, se podrá
activar cuando se compruebe que es segura para ubicaciones y condiciones geográĄcas especíĄcas
[9]. Se espera que se puedan mejorar los sensores y radares del nuevo modelo gracias al software
desarrollado por Zenseact [10], empresa perteneciente a la conducción autónoma de Volvo Cars.
Figura 2.3: Vehículo Volvo automático [9].
Entre Ąnales de 2022 y 2023 Volvo tiene previsto poner en venta el nuevo XC90 eléctrico, en el que
uno de los grandes avances será la incorporación de Unreal Engine [11], el cual supondrá un enorme
avance para desarrollar una interfaz novedosa. Esta nueva incorporación ha sido gracias a la compaĳía
de Epic Games y está considerado por muchos expertos en la materia como la herramienta de creación
3D en tiempo real más avanzada del mundo. Se utilizará para crear animaciones fotorrealistas del
entorno que envuelve al vehículo y puede ser de utilidad o información para los pasajeros [12]. Estas
animaciones se podrán ver a tiempo real y con gráĄcos mejorados para ayudar la visualización de
2.2 Desarrollo 9
aspectos importantes, como el mapa de navegación. Volvo aĳadirá también nuevos procesadores
desarrollados por Qualcomm [13], permitiendo una gran cantidad de procesamiento gráĄco.
Figura 2.4: Futura interfaz del vehículo Volvo XC90 eléctrico [14].
Por otra parte, Mercedes-Benz también es una empresa pionera en los vehículos autónomos,
con planes de ofrecer a partir de 2024 una nueva generación de vehículos Mercedes con un nivel
de autonomía de nivel tres, incluso de funciones de estacionamiento automatizado hasta un nivel
cuatro, similar al Smart Summon de Tesla gracias a un software sobre la plataforma NVIDIA DRIVE
[15]. Mercedes-Benz va a apostar seriamente por una interfaz revolucionaria y nunca antes vista.
Actualmente disponen de un sistema llamado MBUX, siendo uno de los más avanzados del mercado.
Sin embargo, en el aĳo 2024 tienen planeado presentar MB.0S o Sistema Operativo Mercedes-Benz
[14].
Este nuevo sistema operativo llega con la ayuda de la compaĳía especializada en el desarrollo de
plataformas 3D en tiempo real Unity Technologies [16]. En Mercedes tienen planeado el uso de Unity
Industrial Collection, un paquete de gráĄcos y visualización de productos en 3D para completar
la interfaz de usuario. En cuanto al diseĳo de la propia interfaz dentro del vehículo incorporarán
la instrumentación digital, la pantalla central de información y entretenimiento, u otros paneles
repartidos por todo el interior [14].
Figura 2.5: Futura interfaz de Mercedes-Benz para 2024 [12].

Esta nueva tecnología a bordo abre muchas posibilidades de conĄguración y aplicaciones nuevas
de la interfaz. Una de las que pueden ser más útiles es la vinculación de todos los vehículos a la
nube y a internet, cuya información se dividirá en cuatro áreas principales: tren motriz, conducción
autónoma, info-entretenimiento y sistemas de seguridad y confort [14]. Con estos nuevos cambios se
pretende crear una nueva interfaz de usuario más trabajada, con objetivo de crear una comunicación
bidireccional con el cliente, es decir, crear líneas de contacto online permanente.
La compaĳía Unity Technologies también impulsa en gran parte el mercado de videojuegos, esto
permitirá con mayor facilidad contar en la interfaz con aplicaciones y hardware especíĄco para la
transmisión de audio y vídeo en alta calidad, así como de envío de mensajería instantánea y juegos
para los ocupantes del vehículo. Esto es un aspecto adicional a sus características principales, como la
recreación 3D y la realidad aumentada. En un principio el sistema operativo estaría sustentado por el
hardware que ya estrenó hace unos meses el Mercedes Vision EQXX Concept en su enorme pantalla
panorámica que cruza todo el salpicadero, permitiendo una mayor facilidad de visualización por parte
de todos los ocupantes, mayores usos de las diferentes aplicaciones y una notable comodidad [14].
Por último, la gran empresa puntera en vehículos eléctricos Tesla. A lo largo de los aĳos han ido
aumentando su popularidad por sus avanzados y novedosos vehículos. Actualmente disponen de un
vehículo capaz de cambiar de carril también en ciudad, junto a otros vehículos y objetos, pudiendo
hacer giros a la izquierda y a la derecha [17]. A pesar de este gran avance desde la compaĳía piden que
el conductor se mantenga siempre atento a la carretera y con las manos en el volante ante posibles
pero poco probables fallos. En este vehículo se ha aĳadido recientemente en su interfaz un sistema
Figura 2.6: Interfaz Tesla 2019 [17]
basado en en imágenes ópticas que permite al conductor ver lo que el coche ve mientras conduce.
Otra gran característica que ha aĳadido Tesla durante estos aĳos a su interfaz es el poder visualizar
en qué lugar va a estar el coche después de cambiar de carril [18]. Esta visualización es muy útil, ya
que permite al conductor comprobar el correcto cambio de carril y poder corregirlo en caso de ser
erróneo o haber algún problema que el coche no ha detectado. Este modo también se puede acercar
y rotar el renderizado en 3D, permitiendo ver con mucha más claridad los alrededores del vehículo
2.3 Conclusiones 11
desde cualquier vista [19]. Este modo de vista en 3D es muy útil también en situaciones donde el
conductor tome el mando para esquivar obstáculos o a la hora de pasar por lugares estrechos donde
haya peligro de colisión.
2.3 Conclusiones
Todas estas interfaces están enfocadas para un uso cotidiano y comercial. Sus grandes ventajas y
utilidades son facilitar la conducción o facilitar ayudas para esta. Hablando de vehículos autónomos
hemos visto que la mayoría de interfaces van a ser creadas para el entretenimiento y control del
entorno del vehículo. A los usuarios que tengan acceso a la conducción autónoma se les facilita
entretenimiento de forma visual, con conexión por internet o de las formas vistas anteriormente a lo
largo de su viaje. Sin embargo, la interfaz creada en este proyecto está enfocada en un uso para un
desarrollador. La principal ventaja es el conocimiento exacto de los valores que nos proporciona el
vehículo gracias a sus sensores, de esta forma se puede conocer de forma no solo visual, sino numérica
las trayectoria que sigue, la dirección, la orientación del vehículo y sus errores de posicionamiento,
entre otros. Este tipo de parámetros numéricos no son de interés para el público que busca desplazarse
en su día a día, no proporcionan entretenimiento y están enfocados a dar facilidad en el análisis del
funcionamiento del vehículo y aquellos aspectos a corregir por el desarrollador que los utiliza.
Capítulo 3
Descripción del Sistema
3.1 Introducción
Este proyecto tiene como objetivo principal crear una interfaz que se pueda manipular mediante una
pantalla táctil que permita interactuar al usuario y tendrá diversas características. Como principal
característica, se ha desarrollado un sistema de visualización de la localización del vehículo sobre
mapas de vista aérea. Además se visualizarán posibles mapas de rutas. También se deberá visualizar el
estado de funcionamiento de los diferentes sistemas y variables de estado del vehículo que permitirán
conocer la dirección y posición del vehículo para poder ser corregidas. Por último será necesario
implementar un protocolo de comunicación basado en red.
En este capítulo se explicará el proyecto en general pasando por cada uno de los objetivos iniciales
del proyecto. En el primer apartado se detallarán las herramientas necesarias y utilizadas para la
elaboración de este proyecto. En segundo lugar se repasará el funcionamiento y cada parte de la
interfaz dando a conocer su funcionamiento y utilidad. Para una mejor comprensión del proyecto se
explicarán aspectos más especíĄcos como las pequeĳas partes que componen la interfaz. Por último se
mostrarán tres diagramas de Ćujo sobre el funcionamiento de cada una de las pestaĳas de la interfaz.
3.2 Herramientas necesarias
3.2.1 Vehículo autónomo y sensores
En primer lugar se necesita un vehículo automatizado e instrumentalizado. El vehículo en cuestión

será un Citroën C4 cuyas características son las mostradas en la tabla 3.1.
Todo vehículo autónomo necesita de cámaras para reconocer el entorno en el que se mueve y
poder obtener los parámetros necesarios para funcionar correctamente. En este vehículo se utilizarán
las cámaras Grasshopper3 GigE.
Otro elemento hardware muy importante son los sensores. Los sensores son dispositivos capaces
de medir ciertas propiedades del medio que les rodea, siendo sensibles a las distintas magnitudes
del medio y pudiendo obtener los cambios de estas. Estos cambios que detectan los transforman en
seĳales que, posteriormente, se pueden analizar y obtener los datos precisos del entorno. En este
13
14 Capítulo 3. Descripción del Sistema
Figura 3.1: Vistas del vehículo.
Modelo Citroën C4 Hatchback 1.6i 16v VTR PLUS

Código de motor TU5JP4
Potencia máxima CV - kW | rpm 109 - 80 | 5750
Par máximo Nm | rpm 147 | 4000
Caja de cambios Automática, 4 velocidades
Embrague Centrífugo de Ćuido
Peso (kg) 1349
Largo | Ancho | Alto (mm) 4260 | 1773 | 1471
Batalla | vía delantera - trasera (mm) 2608 | 1505 | 1510
Tabla 3.1: Características del Citroën C4
vehículo se hará uso de un radar de largo alcance ARS 308-2 de la marca Continental. Este sensor
es capaz de medir la velocidad y la distancia según el efecto Doppler.
Este sensor es muy útil en este tipo de vehículos autónomos ya que es capaz de funcionar y medir
la distancia en tiempo real, lo cual es fundamental en un vehículo autónomo para poder reaccionar a
los cambios del entorno cuando suceden. Se trata de un sensor capaz de detectar posibles problemas
de su entorno y mostrarlo automáticamente tras la detección de este. Algunas características más
relevantes son las siguientes:
Rango largo 200 m

Apertura rango largo 17◦
Rango corto 60 m
Apertura rango corto 56 ◦
Frecuencia de operación del radar 77 GHz
Tiempo de medición 66 ms
Tipo de conexión CANBUS
Tabla 3.2: Características del radar de largo alcance ARS 308-2
A parte del sensor mencionado es necesario disponer del bus CAN, con el que podremos obtener
datos necesarios acerca del vehículo como la velocidad de las ruedas, la aceleración o la posición
del volante. Es un bus automotriz desarrollado por Bosch, que permite que los microcontroladores y
dispositivos se comuniquen entre sí dentro de un vehículo sin una computadora host. El bus CAN es un
3.2 Herramientas necesarias 15
Figura 3.2: Imagen oĄcial de la Grasshopper3
(a) (b)
Figura 3.3: Continental ARS 308-2 | Radar de largo alcance [20]
protocolo basado en mensajes, diseĳado especíĄcamente para aplicaciones automotrices. Conecta los
sistemas y sensores individuales como una alternativa a los telares de cables múltiples convencionales.
Permite que los componentes automotrices se comuniquen en un bus de datos en red de uno o dos
cables de hasta 1 Mbps [21].
Variable Unidades
Velocidad rueda trasera izquierda km/h
Velocidad rueda trasera derecha km/h
Aceleración m/s2
Posición del volante ◦
Tabla 3.3: Datos obtenidos a través del bus CAN
Un sensor fundamental para el funcionamiento del vehículo es la IMU. Se trata de un sensor

capaz de estimar y reportar estados dinámicos especíĄcos como velocidades angulares, aceleraciones,
actitud (roll y pitch), incrementos de la velocidad o la posición [22]. La IMU deberá recopilar los
Figura 3.4: Esquema del funcionamiento del bus CAN [21].
datos necesarios y, posteriormente, estos serán procesados por un ordenador. Estos mismos datos
recopilados y procesados son los que se enviarán a nuestro programa de la interfaz, que los recibirá
y utilizará para llevar a cabo sus funciones de representación. Para que la IMU pueda recopilar
los datos deberá disponer típicamente de tres componentes principales: acelerómetros, giróscopos y
magnetómetros.
Por último, otro sensor que permite obtener la posición del vehículo es el GPS. Este es un sistema
de navegación que utiliza satélites, un receptor y algoritmos para sincronizar datos de localización
[23]. De esta forma, uniendo la IMU con el GPS se obtendrá una mayor precisión en la posición
del vehículo. Para conseguir valores aún más exactos, se usará en complemento del GPS la técnica
llamada Real Time Kinematic (RTK). Con esta técnica se consigue obtener unos datos más ajustados
y correcciones en tiempo real, lo cual nos será de gran utilidad de cara a la representación en la
interfaz.
Figura 3.5: Aspecto de una IMU empotrable INS600 [24]

3.2 Herramientas necesarias 17
3.2.2 Sistema operativo utilizado
Para realizar esta interfaz necesitaremos instalar el sistema operativo Ubuntu que es una distribución
de Linux. Ubuntu es de código abierto, eso signiĄca que los usuarios pueden modiĄcar su código,
crear e instalar tantas copias como deseen y distribuir la personalización en cualquier lugar. Ubuntu
se caracteriza por tener gran facilidad de uso, por tener una seguridad sólida ya que no almacenan
ni comparten tus datos y una mayor privacidad entre otras características.
En cuanto a la seguridad de Ubuntu, este está constantemente en revisiones lo que permite
detectar y corregir cualquier problema que sufra. Generalmente las distintas distribuciones de Linux
suelen tener menos fallos en cuanto a su seguridad que otros sistemas operativos similares a ellos.
Además, Ubuntu emplea AppArmor, una mejora del núcleo que restringe el comportamiento de los
programas y limita sus recursos. AppArmor puede mitigar el alcance de las violaciones de seguridad,
ya que los programas no tienen permisos ilimitados. Además, hay una serie de prácticas de seguridad
que admite Ubuntu, como la instalación automática de actualizaciones de seguridad, el uso de sudo
en lugar del usuario root de Linux, la implementación de contraseĳas complejas, la conĄguración de
un servidor Virtual Private Network (VPN), la conĄguración del Ąrewall mediante Uncomplicated
Firewall (UFW) y la habilitación de iptables [25].
Otra gran ventaja de este sistema operativo es su escaso consumo de recursos siendo capaz de
funcionar en sistemas con 512 MB de Random Access Memory (RAM). Se trata de una gran ventaja ya
que otros sistemas operativos necesitan mucha más capacidad de esta memoria en sus actualizaciones
recientes ya que disponen de interfaces que consumen muchos recursos y disponen de funciones más
avanzadas.
Para poder realizar el proyecto propuesto estas características de Ubuntu van a ser fundamentales
ya que ha sido necesario crear una partición en el ordenador a utilizar en la que se compartirán dos
sistemas operativos, Ubuntu y Windows. Ubuntu será utilizado para todo el proceso de desarrollo de
la interfaz y Windows se utilizará para la edición de los mapas a representar que se detallarán más
adelante.
Una opción disponible puede ser usar un software de virtualización instalado desde Windows
donde podamos usar Ubuntu pero esta opción era incompatible por posibles errores en el envío de
datos al programa de la interfaz a la hora de comprobar su funcionamiento virtualmente. Este proceso
se detallará en el capítulo 4.
3.2.3 Herramientas necesarias para el desarrollo del proyecto.
En primer lugar para poder desarrollar la interfaz es necesario la creación del mapa que se va a utilizar
en la representación. Para este mapa de vista aérea se utilizarán las imágenes y localizaciones que nos
proporciona Google Earth gracias a su sistema de satélites. Como herramienta de edición de imagen
se utilizará Paint, disponible en Windows, por su simplicidad. Gracias a la aplicación Snipping Tool
se obtendrán capturas del Campus CientíĄco-Tecnológico de la Universidad de Alcalá desde Google
Earth. Se realizan desde la misma altura para poder conectarlas entre sí posteriormente. Una vez
unidas todas las capturas se ajusta el formato del mapa en la mejor resolución posible. El resto del
proyecto se realizará en el sistema operativo Ubuntu.
La parte más importante es la instalación de QtCreator, un entorno de desarrollo integrado

multiplataforma que se utilizará para crear la interfaz propuesta. Gracias a las facilidades que nos
aporta, se creará de forma visual con objetos la interfaz que se quiere desarrollar pudiendo modiĄcar
en todo momento y de manera simple la disposición de cada una de sus partes. Por otro lado, mediante
el código de lenguaje C++ podremos darle las funciones que queramos a los objetos incorporados para
que cumplan el objetivo de la interfaz. Para realizar esta tarea también será necesario la instalación
y el uso de OpenCV.
OpenCV es una biblioteca de código abierto. Generalmente tiene un uso enfocado a la inteligencia
artiĄcial, ya que puede analizar y extraer información de las imágenes que se le proporcione. En el caso
de este proyecto se utilizará dentro de QtCreator para permitir la manipulación del mapa creado en
función de los objetivos propuestos para la visualización del recorrido del vehículo y otras operaciones
para representar de forma gráĄca ciertas variables de estado del vehículo.
3.3 Descripción del sistema
Figura 3.6: Aspecto de la interfaz.
La interfaz creada cuenta con tres pestaĳas y representaciones gráĄcas diferentes en cada una de
ellas:
• En las dos primeras pestaĳas se encuentran dos representaciones diferentes de los mapas de
vista aérea creados como se ha explicado anteriormente, también disponen de un botón adicional
llamado Representación vista aérea que muestra el mapa global creado y el que se va a recorrer.
3.3 Descripción del sistema 19
• En la última pestaĳa se encuentra la representación de los errores lateral y angular del vehículo.
• Por otro lado, independientemente de la pestaĳa en la que nos situemos, se puede ver en el
lado izquierdo de la interfaz el estado de funcionamiento de los diferentes sistemas y variables
de estado del vehículo. A este espacio lo llamaremos Bloque de datos. Todas estas variables se
muestran numéricamente y no es posible su modiĄcación salvo el nivel de alejamiento para ver
los mapas desde la vista aérea. Esta variable será modiĄcada cuando el usuario quiera alejar
o acercar la vista al vehículo y su recorrido por el mapa, su funcionamiento se detallará a lo
largo de esta sección 3.3.
Para poder trabajar y mostrar los datos reales del vehículo autónomo en la interfaz se han
recogido los datos de interés mediante los sensores habilitados en el propio vehículo. Para ello, se
han realizado distintos recorridos sobre el campus CientíĄco-Tecnológico de la Universidad de Alcalá
y posteriormente se han almacenado todos los datos en Ącheros. Estos Ącheros se han enviado al
ordenador que ejecutará la interfaz. Posteriormente, con un programa independiente a la interfaz se
han leído y enviado al programa de la interfaz cada dato que contienen los Ącheros. El programa de
la interfaz mediante código, recibe estos datos y se guardan en variables de interés, las cuales servirán
para mostrar estos datos en cajas habilitadas detallarán en esta sección 3.3. Este método de envío y
lectura de datos es el empleado para probar el resultado Ąnal de la interfaz que se explicará con más
precisión en el capítulo 4 junto a las pruebas reales.
Respecto al movimiento del vehículo sobre el mapa se utilizarán las variables llamadas Northing
y Easting, proporcionadas por los Ącheros mencionados anteriormente, que sitúan la trayectoria del
vehículo en la tierra basados en el sistema de coordenadas UTM. El sistema de coordenadas UTM
es un sistema geográĄco de latitud y longitud que se expresa en una proyección bidimensional de
la superĄcie de la tierra donde el mapa se divide en 60 zonas, cada una de ellas separada por 6
grados de longitud y las ubicaciones se expresan en términos este y norte [26]. Este sistema está
basado en la proyección cartográĄca de Mercator. Se trata de una proyección cilíndrica donde los
meridianos son líneas verticales, paralelas entre sí y equidistantes. Por otro lado, las líneas de latitud
son rectas horizontales, perpendiculares a los meridianos y de la misma longitud que el ecuador, pero
su espaciado aumenta al acercarse a los polos [27].
Para poder visualizar la misma trayectoria en el mapa creado ha sido necesario la creación de
una conversión entre estas coordenadas para convertirlas en los píxeles del mapa. Las ecuaciones que
convertirán las coordenadas a píxeles son las siguientes:
imgx = fx (worldx − of f setworldx ) + of f setimagex (3.1)
imgy = fy (worldy − of f setworldy ) + of f setimagey (3.2)
Donde el valor de offsetimage para x e y son las coordenadas de un punto que se quiera de la
imagen del mapa a utilizar. Cogiendo este punto se debe buscar sus coordenadas UTM, obteniendo
los datos de offsetworld para x e y. El primer paso es coger dos puntos en la imagen del mapa lo más
alejados posibles para minimizar el error de escala. Con estos dos puntos se obtendrá pt1x , pt1y , pt2x
y pt2y , que son las componentes x e y de los dos puntos elegidos. En segundo lugar, se obtendrán las
coordenadas UTM de estos puntos elegidos y se llamarán W1 y W2. Las coordenadas en UTM que
se quieran convertir a píxeles se deben guardar en worldx y worldy .
Por último, se deben calcular los factores de escala fx y fy , que deberían ser idealmente iguales.
Para ello se utilizarán las siguientes ecuaciones a partir de la obtención de puntos explicados en el
párrafo anterior:
w = pt2x − pt1x (3.3)
h = pt2y − pt2y (3.4)
dw = world2x − world1x (3.5)
dh = world2y − world1y (3.6)
Una vez con todos los cálculos necesarios hechos, hay que sustituir en las siguientes expresiones para
obtener ambos factores de escala:
f x = w/dw (3.7)
f y = h/dh (3.8)
Teniendo todos los datos necesarios, se usarán en las ecuaciones iniciales para obtener las variables
imgx y imgy . Estas serán mostradas en las cajas numéricas habilitadas en el Bloque de datos como
CoordenadaX del mapa y CoordenadaY del mapa junto a las coordenadas en UTM mostradas como
Northing y Easting.
Para poder tener control sobre el vehículo y sus parámetros de interés en todo momento, estos
se mostrarán constantemente en el bloque de datos. Se han colocado en columna para permitir tener
mayor tamaĳo en las representaciones gráĄcas de las diferentes pestaĳas que componen la interfaz.
Los datos que se pueden ver en las distintas cajas habilitadas se irán actualizando constantemente
durante el funcionamiento del vehículo, a medida que se reciben. Estos datos son los siguientes:
• Coordenada X e Y del vehículo dibujado en el mapa.
• Nivel de alejamiento ajustable de la vista del mapa.
• Orientación del vehículo en grados.
• Error angular en grados y lateral en metros del vehículo.
• Velocidad del vehículo.
• Coordenadas Easting y Northing del vehículo.
La orientación del vehículo corresponde al ángulo respecto a la línea longitudinal del vehículo.
El ángulo de orientación del vehículo es antihorario, un giro del vehículo a la derecha produce una
variación negativa del ángulo mientras que un giro a la izquierda produce una variación positiva.
En la primera pestaĳa se tiene como parte principal una de las dos representaciones del mapa de
vista aérea. En esta representación se puede observar al vehículo como un rectángulo verde en las
coordenadas expresadas en píxeles sobre el mapa, convertidas de las coordenadas reales Northing y
Easting. Para un mejor seguimiento del vehículo se mostrará parte del mapa que le rodea. Podemos
decidir cuánto del mapa que rodea al vehículo queremos ver gracias a una caja situada en el apartado
izquierdo de la interfaz junto al resto de datos del vehículo. Esta caja tiene el nombre de Nivel
de alejamiento ajustable, cuanto mayor es el número que introduzcamos en esta caja, más mapa
veremos rodeando al vehículo, siendo lo contrario si el número es más pequeĳo. Los límites a la hora
de introducir este parámetro en los que mejor se puede apreciar la trayectoria del vehículo está entre
200 (se ve al vehículo muy cerca y poco entorno) y 800 (se ve al vehículo más alejado y más entorno).
Si el número es inferior al límite apenas se podrá ver el entorno que lo rodea y por lo tanto será difícil
saber en qué posición se encuentra. Por el otro lado, si el número introducido supera el máximo, no
será posible apreciar bien el seguimiento exacto del vehículo por la carretera.
Figura 3.7: Visualización del botón Representación vista aérea.
La principal característica de esta representación es que el vehículo se mantendrá siempre en

posición vertical en el centro de la imagen mostrada del mapa y su entorno irá girando a su alrededor
cuando en el recorrido haya curvas, glorietas, etc. Esta podría ser la forma de representación más
utilizada en GPS de uso cotidiano. Para lograr los ajustes de acercamiento de imagen o los giros que
se acaban de mencionar, ha sido necesario el uso de las librerías OpenCV explicadas en la subsección
3.2.3.
Como aspecto adicional, en esta interfaz también se mostrarán sobre el mapa diferentes rutas
que podrá recorrer el vehículo. Estas rutas se han obtenido con los datos recogidos por el vehículo
en la tierra y son de igual longitud pero de sentidos diferentes. Para poder diferenciarlas se han
dibujado con colores diferentes, rojo y azul. En la interfaz, al lado de la representación del mapa,
están disponibles dos checkboxes que pueden ser marcadas con los nombres de Mapa izquierdo y
Mapa derecho. Si seleccionamos la casilla con el nombre de Mapa izquierdo se mostrará en el mapa
un recorrido en azul, si se selecciona la casilla con el nombre de Mapa derecho se mostrará una
trayectoria en rojo.
(a)
(b)
Figura 3.8: (a) Primera pestaĳa con un menor nivel de alejamiento | (b) primera pestaĳa con ambas
trayectorias seleccionadas y mayor alejamiento
El nombre de los dos mapas se debe al carril empleado por el vehículo, siendo de esta manera
el Mapa derecho un recorrido que utiliza el carril derecho. Por otra parte el Mapa izquierdo es
la trayectoria en el carril izquierdo. Ambas trayectorias empiezan en la carretera entre el Centro
Internacional de Neurociencia Cajal y el ediĄcio de Enfermería y Fisioterapia, siguiendo hacia el
polideportivo. Existe la posibilidad de mostrar ambas trayectorias a la vez, esto se consigue marcando
ambos checkboxes, también se puede elegir si no se quiere mostrar ninguna trayectoria no marcando
ninguna. A lo largo de la representación de la posición del vehículo se pueden activar y desactivar
los checkboxes en función de lo que queramos ver en cada momento.
La función de la segunda pestaĳa es la misma que la primera, dispone de los mismos dos checkboxes
con el mismo funcionamiento que en la primera pestaĳa para mostrar las trayectorias disponibles en
el mapa. También está disponible el botón para ver la representación del mapa desde el punto más
alto. En este caso la representación del mapa es distinta, a diferencia del anterior, en esta pestaĳa
el vehículo dibujado sobre el mapa girará a medida que se encuentre con alguna curva y el mapa
se mantendrá estático. Con esta forma se puede decir que el vehículo recorre el mapa, también
situándose en el centro de la imagen que tenemos.
Figura 3.9: Representación de la segunda pestaĳa con ambas trayectorias seleccionadas y mayor
alejamiento.
Para la localización del vehículo sobre el mapa se ha hecho el mismo proceso, ya que tanto la
Coordenada X, Coordenada Y, Northing y Easting que vemos de forma numérica en el bloque de
datos son las mismas para ambas pestaĳas y no cambian. El proceso de obtención de coordenadas
se hace de forma global y después son compartidas a ambas pestaĳas, haciendo que se compartan
y, por lo tanto, el vehículo de una pestaĳa se encontrará en el mismo sitio que en la otra pestaĳa.
También desde esta pestaĳa se pueden ver el resto de parámetros que se muestran en la interfaz y
existe la posibilidad de modiĄcar el nivel de alejamiento en todo momento, siendo actualizado en el
mapa al instante. El funcionamiento del mapa y el dibujo de las trayectorias ha sido posible gracias
a las librerías de OpenCV.
En la última pestaĳa disponible en la interfaz tenemos una representación gráĄca diferente, ya
no se encuentran ni los checkboxes de selección de trayectoria ni el botón que muestra el mapa total.
En su lugar se puede ver en un inicio un rectángulo negro que ocupa gran parte de la pestaĳa. Esta
representación ha sido creada para tener un control visual del error angular y el error lateral del
vehículo. Durante el funcionamiento del vehículo se podrá ver en este rectángulo una línea vertical
verde en el centro, siendo su función mostrar un punto medio y de origen para la representación de
los errores del vehículo. Esta línea representa la trayectoria que el vehículo esta siguiendo. Encima
Figura 3.10: Representación de la segunda pestaĳa sin trayectorias seleccionadas y menor

alejamiento.
de esta línea central se tendrá un rectángulo del mismo color que representa al vehículo en cuestión
y una pequeĳa cruz para identiĄcar su centro. Si la representación del vehículo se encuentra en el
centro de esta línea indicará que el error lateral es cero; en caso de no serlo, este rectángulo rotará
en función del valor que le llegue sea positivo o negativo.
A ambos lados de la línea central verde están dibujadas dos líneas en azul y en la parte superior
de estas un indicador de 1.5 metros. Estas líneas azules se han incorporado para poder controlar de
forma más rápida el error lateral del vehículo. Se pueden observar numéricamente los valores del error
lateral en metros y el error angular en grados en el bloque de datos junto al resto de variables. Por lo
que respecta al error lateral, al disponer de estas líneas azules, podemos comprobar más rápidamente
y de forma visual si el vehículo tiene un error cercano o superior a 1.5 metros.
El funcionamiento es muy simple, a medida que se reciben los datos de ambos errores se van
mostrando en la representación y durante el funcionamiento del vehículo se puede ver cómo varía el
error lateral y angular de este. Estos errores se han medido respecto a las trayectorias ya mencionadas
que se pueden ver sobre el mapa para comprobar la precisión del vehículo al recorrerlas. Esto implica
que si el vehículo recorre una zona que no corresponde a las trayectorias, los errores serán muy
elevados. Para evitar que la representación del vehículo desaparezca del cuadrado negro donde se
muestra, se ha ajustado de forma que si el error lateral es mayor a 8 metros el centro del vehículo se
sitúe en el borde de la representación pero en la caja numérica se seguirá mostrando el valor exacto.
Para conseguir una representación Ąable en cuanto a dimensiones del vehículo y su desplazamiento se
han tenido que hacer conversiones de metros a píxeles. En función de las dimensiones de la ventana
de representación y las medidas en metros del vehículo se han asignado cierta cantidad de píxeles al
ancho y largo del vehículo. De esta forma el desplazamiento que sufre el coche lateralmente concuerda
con sus dimensiones y no se ve distorsionada la representación. Por ejemplo, si el vehículo tiene un
Figura 3.11: Representación del error lateral y angular del vehículo.
ancho de 2 metros y el error lateral que llega en un momento determinado es de 1 metro, el vehículo
se moverá la mitad de su ancho hacia un lateral. Por último, respecto al error angular se ha decidido
mostrar su valor en grados ya que es mucho más cómodo que si se hace en radianes, por ello, se hace
una conversión del dato en radianes que se recibe del vehículo a grados y posteriormente se muestran
en su respectiva caja numérica en el bloque de datos.
Figura 3.12: Representación del error lateral y angular superiores al límite establecido.
3.3.1 Diagrama de bloques
Para facilitar la comprensión de la función de la interfaz y su interacción con el usuario, se han creado
tres diagramas de bloques. Cada uno pertenece a una pestaĳa distinta y cubren el funcionamiento
y las distintas opciones que podemos elegir para la visualización de los mapas de las dos primeras
pestaĳas en la interfaz. En la última pestaĳa no puede haber interacciones en la interfaz ya que
únicamente es para observar los errores del vehículo, en su lugar, se mostrarán en el diagrama las
condiciones que puede haber con los límites de la representación de los errores.
Figura 3.13: Diagrama de estados de la primera pestaĳa de la interfaz.

Figura 3.14: Diagrama de estados de la segunda pestaĳa de la interfaz.

Figura 3.15: Diagrama de estados de la tercera pestaĳa de la interfaz.

Capítulo 4
Pruebas
4.1 Introducción
Para comprobar el correcto desarrollo de la interfaz creada se van a realizar dos tipos de pruebas.
La primera prueba a la que se someterá la interfaz será por medio de simulación con el ordenador
utilizado y la prueba deĄnitiva será con el vehículo autónomo en el campus CientíĄco-Tecnológico
de la Universidad de Alcalá. A continuación veremos las dos pruebas realizadas separadas en dos
secciones diferentes.
4.2 Prueba de la interfaz mediante simulación
Una vez creada la interfaz, el objetivo es probarla en el vehículo autónomo. Antes de llevarla a la
prueba real es conveniente comprobar que funciona correctamente para poder corregir los errores
que pueda tener o modiĄcar aquellos aspectos que lo necesiten. Para ello, se ha implementado un
mecanismo de envío de datos Ącticio para la simulación de la interfaz y su funcionamiento.
La interfaz debe actualizarse con la información recibida cada vez que llegue un nuevo bloque
de datos. Este interfaz está desarrollado para usarlo en el vehículo en tiempo real, por lo tanto, los
distintos parámetros los enviará el vehículo por una comunicación de red.
Para esta prueba simulada se ha creado un programa independiente que lee un Ąchero en el que
se encuentran los datos recogidos por el vehículo durante su recorrido por el campus. Tras leerlo y
cargar toda la información que se ha seleccionado para mostrarla en la interfaz este programa irá
enviando por la red esta información seleccionada de forma secuencial en una estructura que será
recibida por la interfaz como la recibiría estando en el vehículo real.
También se debe implementar un código en el programa creado para la interfaz que permita estar
monitorizando la red y recibir los paquetes de datos que envía el nuevo programa independiente a la
interfaz. Cada vez que se recibe un paquete de datos, la interfaz debe actualizarse con la información
recibida de los distintos parámetros que se quieren mostrar. Para que este proceso de comunicación
funcione correctamente se debe deĄnir una estructura que sea la misma para ambos programas, de
esta forma los dos enviarán y recibirán la misma información. La velocidad a la que se envían los datos
29
30 Capítulo 4. Pruebas
Figura 4.1: A la izquierda programa de envío de datos y código de la interfaz a la derecha
en un inicio no tiene importancia, se puede usar un valor de prueba. Para satisfacer las necesidades
de las pruebas reales es necesario que el envío de datos se realice a la misma velocidad por lo que es
necesario saber el tiempo entre dos datos enviados por el vehículo a tiempo real. Existe una variable
en los Ącheros que deben ser leídos con los datos recogidos por el vehículo, que indica el tiempo en el
que se envía cada dato. En el propio código a medida que se leen los datos del Ąchero se irá calculando
la diferencia de la variable del tiempo y la irá guardando en una nueva variable. Esta variable será
la utilizada para deĄnir el tiempo de espera entre envío de datos.
Dentro del programa de la interfaz se tienen dos principales tareas, de recepción y representación.
Para un mejor funcionamiento y una representación más Ćuida de la interfaz se ha decidido separar
en dos el hilo de recepción y crear uno nuevo para la representación de las pestaĳas de la interfaz. En
el hilo de recepción se ha dejado el código necesario para mandar los datos recibidos a sus respectivas
cajas. La función del nuevo hilo de representación es leer y guardar en una variable los datos que se
reciban desde el programa independiente de envío de datos. Este proceso estará protegido mediante
mutex para asegurar su correcto funcionamiento y no solape con otras partes del código que puedan
alterar la información. Una vez guardada esta nueva variable con los datos, se llama a las funciones
que muestran las representaciones de las pestaĳas. De esta forma, estas dos tareas principales pueden
funcionar de forma simultánea e independiente sin ocupar tiempos innecesarios.
Con ambos programas listos, para comprobar el resultado se debe ejecutar en primer lugar el
programa independiente que envía los datos y posteriormente poner en marcha la interfaz.
4.3 Prueba de la interfaz en el vehículo autónomo 31
4.3 Prueba de la interfaz en el vehículo autónomo
Tras la prueba simulada, es necesario una última prueba con el vehículo real para asegurar que la
interfaz es capaz de funcionar en circunstancias reales. Como la interfaz dispone de tres pestaĳas
diferentes, se deberá comprobar el funcionamiento de cada una de estas. Para las pestaĳas de la
representación del movimiento del vehículo por el campus se recorrerá principalmente la avenida
punto es y la calle 18. Estas han sido elegidas ya que se tiene una gran recta en la calle 18 y cuatro
glorietas en total, dos en los extremos de la avenida y otras dos en los extremos de la calle.
La primera prueba será para las dos primeras pestaĳas, se saldrá desde la calle, en el punto más
cercano al ediĄcio de enfermería y Ąsioterapia. Nos dirigiremos hacia el polideportivo donde se tomará
la glorieta girando en esta hacia la izquierda en la avenida. En el extremo de esta, se encuentra otra
glorieta, que será usada para cambiar el sentido y dirigirnos al otro extremo de la avenida, con una
glorieta más grande que servirá para cambiar el sentido y volver a la calle inicial. Para situarnos en
el punto de salida, se dará la vuelta en la glorieta situada en el otro extremo de la calle al lado del
ediĄcio de enfermería y Ąsioterapia. En total, durante este recorrido tomamos 6 veces por las glorietas
y tanto la calle como la avenida son de ambos sentidos. Este recorrido es perfecto para la prueba del
seguimiento con los mapas, con las rotondas veremos si los giros de ambas representaciones se hacen
correctamente. Al ser las glorietas de distintos tamaĳos, se tendrán giros más o menos cerrados,
poniendo a prueba si la representación es correcta para los distintos tipos de giros que nos podamos
encontrar. Por último, al tener ambos sentidos durante el recorrido, se podrá comprobar la precisión
en la representación del vehículo por la carretera en la interfaz, pudiendo apreciar la colocación en
los distintos carriles que dispone la calle.
En la segunda y última prueba, se deberá comprobar el correcto funcionamiento de la última
pestaĳa, la encargada de la representación del error lateral y angular del vehículo. Esta prueba se
realizará únicamente en la calle mencionada anteriormente. Esta calle dispone de cuatro carriles,
dos por cada sentido, lo que permitirá hacer un recorrido oscilante cambiando de carril para ver
la variación de ambos errores con mayores valores. A esta prueba hay que incluir los giros en las
glorietas de ambos extremos de la calle que también marcarán los errores que se analizan. También,
al ser una calle con una gran longitud, se comprobará que aumentando o reduciendo la velocidad de
circulación del vehículo la interfaz sigue siendo capaz de representar los errores de forma correcta y
seguir la trayectoria del vehículo.
Respecto a los parámetros del vehículo que podemos ver en el bloque de datos, se podrán observar
en todo momento independientemente de la pestaĳa en la que nos encontremos y, por lo tanto, ver
la actualización de las cajas que los representan y si los datos que llegan son acordes a lo que vemos
desde el vehículo.
En simulación los datos que se envían y reciben están guardados en unos archivos los cuales fueron
recogidos con el propio vehículo. En este caso los datos que se reciben en la interfaz son enviados en
tiempo real cuando el propio vehículo los genera. Para poder recibir los datos que envíe el vehículo
es necesario disponer de una conexión de red ethernet en el ordenador con el que se vaya a utilizar la
interfaz. Esta conexión permitirá conectarnos al switch del coche y estar compartiendo la misma red,
permitiendo el envío y recepción de datos. Si la conexión ha sido correcta podremos ver la siguiente
pestaĳa que se muestra en la Ągura 4.2 en el navegador utilizado.
32 Capítulo 4. Pruebas
Figura 4.2: Conexión a la red del vehículo.
En la prueba simulada, el programa independiente a la interfaz enviaba por la red la información

leída de los Ącheros de forma secuencial en una estructura. Esta estructura debía tener los mismos
nombres para las distintas variables que la estructura en el programa de la interfaz, es decir, la
misma estructura. En la prueba real se debe hacer lo mismo, para que los datos que se envían sean
entendidos por el código de la interfaz es necesario que tengan el mismo nombre en la estructura
compartida.
Para poder documentar estas pruebas se capturará la pantalla del ordenador mediante vídeo. En
la pantalla se encuentra la interfaz junto a la imagen que nos muestra una cámara web situada en
el interior del vehículo, junto a una GoPro para tener mayor resolución. Esta cámara web en un
inicio se tenía en mente situarla encima del vehículo pero el día en que se realizaron las pruebas hubo
temporal de lluvia y no dispone de ninguna protección ante esta situación meteorológica. Se quiere
que, en el vídeo de la pantalla del ordenador aparezca de forma simultánea la interfaz y la ventana
que muestra el exterior del vehículo gracias a la cámara web conectada también al ordenador. De esta
forma se podrá comprobar que la interfaz está mostrando la representación del vehículo en tiempo
real haciendo el mismo recorrido que el vehículo tal y como se ve en la Ągura 4.4.
La principal diferencia entre la prueba simulada y la real es el retraso que hay desde que se
envían los datos hasta que se representan con el vehículo real en funcionamiento. En la simulación
solo se puede comprobar si los datos y las distintas representaciones de las pestaĳas son correctas.
No se conoce si la representación de la interfaz se hace en el mismo instante en el que el vehículo
real se mueve. Este problema del retraso en la actualización de la interfaz en las pruebas reales se
debía principalmente a un problema con el tiempo que se tardaba en crear las representaciones de
las distintas pestaĳas.
Para que esto no ocurriese y pudiéramos tener unas representaciones que se mostrasen de forma
Ćuida y al mismo tiempo que el movimiento del vehículo real hubo que optimizar el código. Para
4.3 Prueba de la interfaz en el vehículo autónomo 33
Figura 4.3: Visión de la GoPro del interior del vehículo.
ello se decidió hacer solamente la representación de la pestaĳa activa en vez de actualizar todas las
pestaĳas aunque no se estuvieran observando.
Durante la prueba real se han ido detectando distintos aspectos del código que afectaban al
rendimiento de la interfaz y, posteriormente, se han ido optimizando. Estos problemas sobre el código
y cambios para mejorar el rendimiento de la interfaz se verán de forma más detallada en el capítulo
5.
Figura 4.4: Distribución de la pantalla del ordenador durante las pruebas.

Capítulo 5
Resultados
5.1 Introducción
Tras el capítulo anterior donde se detallaban las pruebas realizadas con el Ąn de comprobar el correcto
funcionamiento de la interfaz, en este capítulo se expondrán y analizarán los resultados. Al igual que
el capítulo anterior, este se dividirá en dos partes, los resultados de las pruebas simuladas y los de
las pruebas con el vehículo real.
5.2 Resultados de la prueba mediante simulación
Tras comprobar el correcto envío de datos al programa de la interfaz, para asegurar que los datos
recibidos son correctos se deben enviar a las cajas numéricas que se han puesto en la interfaz. Con
el código necesario para esto y poniendo en funcionamiento ambos programas se puede ver que los
datos de cada caja se muestran correctamente con los valores correctos en cada variable.
Una vez comprobada la llegada correcta de los datos y su visualización en sus correspondientes
casillas, debemos conĄrmar el buen funcionamiento de ambos mapas. Para esto solo es necesario
llamar a las funciones que ejecutan los mapas y leen los parámetros recibidos. De esta forma, la
representación de los mapas será siempre que se actualicen los datos mostrados. Para comprobar
la primera pestaĳa una vez estén en funcionamiento ambos programas, se deberá observar si la
trayectoria del vehículo sobre el mapa es correcta, así como sus giros en las distintas zonas que
vaya recorriendo. También es fundamental probar las dos casillas de visualización de trayectorias
explicadas en el capítulo tres. Para esto, a medida que avanza el vehículo se irán marcando estas
casillas con distintas combinaciones para asegurar que no existe ningún problema y las trayectorias
se muestran según lo esperado. Con las trayectorias puestas se observa que el vehículo las sigue
correctamente. Por último, es necesario comprobar que funciona correctamente el nivel de alejamiento
de la representación del mapa. Mientras el programa funciona debemos escribir el valor que queramos
probar en la caja habilitada para ello, dentro de los márgenes recomendados en el capítulo tres. En
las próximas dos Ąguras se mostrará a la izquierda el programa independiente de envío de datos y a la
derecha la interfaz para mostrar que la interfaz se va actualizando en función de los datos enviados.
35
36 Capítulo 5. Resultados
Figura 5.1: Simulación de la primera pestaĳa de la interfaz.
La pestaĳa dos muestra el otro tipo de representación con el mapa, como ya se ha comentado
anteriormente. Por ello, se deben comprobar las mismas partes que se han comentado para la primera
pestaĳa. Los botones de las distintas trayectorias, el giro del vehículo, el desplazamiento de este por
el mapa y el nivel de alejamiento también funcionan según lo esperado.
Figura 5.2: Simulación de la segunda pestaĳa de la interfaz.
Por último, se comprobará el resultado de la última pestaĳa: esta muestra la representación de los
errores lateral y angular. En esta pestaĳa, al no haber casillas de marcación, botones ni la posibilidad
5.3 Resultados de la prueba con vehículo autónomo 37
de ajuste del nivel de alejamiento la prueba será mucho más simple. Nos debemos Ąjar si durante
el recorrido del vehículo se representa correctamente en esta pestaĳa la evolución del error lateral
y angular. Al disponer en esta pestaĳa dos límites que marcan 1.5 metros el error lateral, podemos
comprobar si el valor que vemos de este error en su caja corresponde con el que vemos representado
en la pestaĳa. El último aspecto a comprobar es si la representación se queda en el límite en el caso
de que el error lateral aumente más del límite establecido.
Figura 5.3: Pestaĳa errores lateral y angular.
El funcionamiento de la interfaz ha sido el correcto y esperado en cada una de las pestaĳas.
5.3 Resultados de la prueba con vehículo autónomo
Tras realizar todos los pasos necesarios para que la interfaz reciba los datos recogidos por el vehículo,
ahora se probará el funcionamiento de esta. Como se ha explicado en el capítulo anterior, la primera
prueba servirá para comprobar el funcionamiento de las dos primeras pestaĳas.
La primera prueba se realizó mostrando en la interfaz uno de cada cien datos, esto supuso que,
a la hora de hacer el recorrido con el vehículo la interfaz iba considerablemente retrasada respecto
a la posición real. El funcionamiento fue el esperado, ambas pestaĳas de representación hacían su
función correctamente, las casillas disponibles para mostrar las trayectorias funcionaban bien, las
cajas del bloque de datos mostraban los valores reales y los botones de representación del mapa
también funcionaban. La tercera pestaĳa también representaba bien los errores lateral y angular de
acuerdo con la realidad. El problema era que reĆejaba la realidad, pero no la de cada momento. Lo
que se busca en la interfaz es que podamos ver los datos y las representaciones al mismo tiempo que
el vehículo nos lo manda y así poder hacer un mejor seguimiento. Para mejorar esta situación se
decidió mostrar en la interfaz cada dato que llegaba del vehículo modiĄcando el código necesario.
Figura 5.4: Vista del montaje en el interior del vehículo.
Tras este cambio observamos que las representaciones iban con un gran retraso, llegando a re-
presentar la posición del vehículo real 15 segundos más tarde. Este error se debía a una gestión del
tiempo en el código muy mejorable, es decir, había procesos innecesarios que se repetían cada vez
que la interfaz quería mostrar las distintas representaciones. Los procesos que retrasaban la repre-
sentación estaban principalmente en las funciones que se utilizaban para obtener datos necesarios
para la creación de los mapas y la pestaĳa de los errores. Para solucionar estos problemas se decidió
separar del hilo de recepción de datos la actualización de las funciones que mostraban las distintas
representaciones en las pestaĳas. En el hilo de recepción se dejó el código necesario para mandar
los datos recibidos a sus respectivas cajas. Para llamar a las funciones de representación se creó un
nuevo hilo, en el que se leía y guardaba con otro nombre la variable que se enviaba desde el vehículo
y contenía todos los datos necesarios para nuestra interfaz. Una vez guardada esta nueva variable
con los datos, se llamaba a las funciones que mostraban las representaciones de las pestaĳas.
Otra operación que consumía mucho tiempo era la lectura de la imagen del mapa creado. En
el antiguo código, cada vez que se actualizaba la interfaz se leía la imagen y se modiĄcaba. Para
ahorrar este paso, en el constructor del código se hizo la lectura de este mapa en distintas variables,
las cuales son utilizadas haciendo una copia cada vez que se quiera utilizar el mapa en cuestión. Por
último, se tenían activas funciones a parte que servían para recoger el dato recibido del vehículo,
transformarlo en otras unidades o escalas y mostrarlo. Estas funciones de manipulación de datos
también se llamaban dentro de las funciones que actualizaban las representaciones de las pestaĳas,
provocando un mayor retraso. Por ello, el código de estas funciones de transformación de datos se
llevó a cada una de las funciones que actualizan la interfaz, ahorrando el paso de tener que cambiar
de funciones para hacer las conversiones.
Tras estos cambios las distintas representaciones de la interfaz iban de una manera mucho más
Ćuida y actualizada con el movimiento en tiempo real del vehículo. Sin embargo, se podía mejorar
un poco más el rendimiento y, por lo tanto, la Ćuidez. Como última modiĄcación se decidió restringir
la actualización de las pestaĳas si no estaban en uso. Si en la interfaz nos encontrábamos usando la
primera pestaĳa, lo ideal es que el resto de pestaĳas no se actualizasen en segundo plano para no
ocupar tantos recursos. Para solucionar esto, en el nuevo hilo creado para las funciones que actualizan
las representaciones de las pestaĳas, se pusieron condiciones de forma que si se usaba una pestaĳa,
solo se actualizase esa. De esta forma se ha conseguido un mejor funcionamiento y mucha más Ćuidez
en todas las pestaĳas de la interfaz. Tras terminar estas modiĄcaciones se pasó a la realización de
las pruebas pendientes comentadas en el capítulo cuatro.
Figura 5.5: Vista del exterior del vehículo.
La primera prueba se realizó para ver el funcionamiento de la pestaĳa inicial. En la Ągura 5.4
podemos ver la interfaz en la primera pestaĳa a la derecha y la imagen que captamos del exterior con
la webcam. En esta pestaĳa podemos ver la representación del recorrido del vehículo en la que este
se sitúa en el centro de la imagen y su entorno gira a su alrededor para realizar los giros. Aunque se
tome una glorieta la representación del vehículo se mantendrá recta y en el centro, como podemos
ver. La parte delantera del vehículo que se muestra en la interfaz mira hacia la salida que tiene en
frente, esta posición coincide con la realidad como se puede ver a la izquierda de la misma Ągura,
donde el coche real apunta en ese punto de la glorieta a la misma salida que en la interfaz. Con
esta imagen se puede comprobar que el giro mediante esta representación está siendo correcto y que
la posición del vehículo real coincide con la vista en la interfaz. Esto se debe a que la interfaz está
leyendo correctamente los datos en tiempo real que le llegan del vehículo.
La siguiente pestaĳa a comprobar es la segunda, en la que el vehículo representado se sitúa en el

centro de la imagen y este es el que gira y no su entorno al tomar las curvas. En la Ągura 5.5 se ve
dicha representación con el nivel de alejamiento cambiado a un mayor valor. En esta Ągura, se puede
observar respecto a la Ągura 5.4 que, al variar este nivel a un número mayor, vemos al vehículo desde
una mayor altura, lo que permite ver más entorno a su alrededor. Como ya se comentó en el capítulo
Figura 5.6: Primera pestaĳa de la interfaz en la prueba real.
tres, este nivel de alejamiento se conĄguró para que se pueda modiĄcar en cualquier momento.
También en esta pestaĳa el vehículo representado coincide con su posición real. Aquí podemos ver
como el vehículo se encuentra entrando en la glorieta, la misma posición que vemos en la cámara a
la izquierda.
Figura 5.7: Segunda pestaĳa de la interfaz en la prueba real.
En la Ągura 5.6 seguimos en la misma pestaĳa, pero esta vez se ha vuelto a poner el mismo
nivel de alejamiento que se tenía desde el inicio, mostrando que se puede cambiar tantas veces como
se quiera sin importar la zona. Estos valores introducidos están dentro del límite 200 y 800, si se
superan estos valores seguirá funcionando según lo previsto la interfaz, pero se verá muy lejos o cerca
el vehículo, impidiendo apreciar correctamente su seguimiento. Una vez más podemos observar en la
misma Ągura como la posición del vehículo en la interfaz coinciden en el punto medio de la glorieta
mirando hacia la salida de su derecha. La representación del coche es correcta en cada parte del
mapa.
Figura 5.8: Segunda pestaĳa de la interfaz en la prueba real
La última prueba que se va a realizar es para comprobar el funcionamiento de la pestaĳa que

nos muestra el error lateral y angular. Esta representación se encuentra en la última posición y se
grabará junto a la imagen del exterior del vehículo, pero esta vez con un tamaĳo menor para poder
observar mejor el movimiento de este sobre la interfaz. Para esta prueba se ha recorrido la calle
de forma oscilante para poder comprobar mejor ambos errores. Como vemos en la Ągura 5.7 en el
vehículo real estamos cambiando del carril derecho al izquierdo, lo cual genera una representación de
este inclinado a la izquierda. La línea verde del centro en la interfaz representa el centro del carril
derecho, por eso el error lateral aumenta hacia la izquierda al estar separándonos de dicho carril.
Aunque con la cámara grabando el exterior no se percibe bien la orientación o posición del vehículo
en los carriles, podemos observar que la representación que vemos en la interfaz es muy similar a la
que se encuentra en realidad si lo viéramos desde arriba.
Para acabar la prueba se ha aumentado en la Ągura 5.8 la velocidad respecto a la Ągura 5.7. Con
esta prueba se ha querido comprobar si la representación en la interfaz seguía siendo Ćuida y si seguía
al vehículo real. Este aumento de la velocidad se puede observar en el bloque de datos habilitado para
ello, el dato que podemos ver se encuentra en metros por segundo. En este caso, a través de la cámara
que enfoca el exterior vemos que nos encontramos girando de izquierda a derecha ya situados en el
carril derecho. Con estas dos capturas de pantalla podemos observar que la representación de los
errores tanto positivos como negativos es correcta. En esta última Ągura como nos encontramos en
el carril derecho se puede apreciar que el error lateral es mucho menor que en la Ągura 5.7 y nos
Figura 5.9: Pestaĳa errores lateral y angular en la prueba real
encontramos prácticamente en el centro ligeramente inclinados, ya que venimos de un cambio de

carril.
Figura 5.10: Pestaĳa errores lateral y angular en la prueba real

Capítulo 6
Conclusiones y líneas futuras
Para acabar, a modo de resumen, en este trabajo se han realizado las siguientes aportaciones:
• Principalmente se ha desarrollado un sistema de visualización de la localización del vehículo

sobre mapas de vista aérea. Estos mapas cuentan con distintos modos de representación de la
trayectoria del vehículo en cuestión, pudiendo ajustar el nivel de alejamiento de la vista aérea.
Además, se visualizan posibles mapas de rutas.
• Se puede visualizar, además, el estado de funcionamiento de los diferentes sistemas y variables

de estado del vehículo. Como variables de estado se tiene la orientación del vehículo respecto a
la vertical, la velocidad, los errores lateral y angular y posición del vehículo en coordenadas.
• Control del error lateral y angular del vehículo de forma visual.
• Desarrollo de un sistema de visualización siguiendo el modelo vista-controlador.
• Implementación de un protocolo de comunicación basado en red.
6.1 Líneas Futuras
Al tratarse de una interfaz para un vehículo autónomo las posibilidades sobre funciones nuevas a
incorporar son muchas. También existen posibles mejoras a los objetivos ya cumplidos, dependiendo
siempre de las necesidades que se tengan. A continuación se van a nombrar algunas de las nuevas
funciones que se podrían aplicar a la interfaz ya creada.
• Una función adicional a la interfaz actual sería la posibilidad de enviar diferentes seĳales al
vehículo, como por ejemplo, puntos de destino. Estos puntos de destino se podrían seleccionar
al inicio del funcionamiento del vehículo, tras pulsar el botón que muestra el mapa creado, se
podría tener la opción de marcar en dicho mapa el punto de destino al que quiere dirigirse el
usuario.
• En la interfaz actual se tiene la opción de mostrar trayectorias ya deĄnidas, pero con la posible
incorporación de la elección de un punto de destino, se podría dibujar la trayectoria a dicho
punto que se seleccione en el mapa.
43
44 Capítulo 6. Conclusiones y líneas futuras
• Otra gran función a incorporar sería la opción de mandar seĳales de activación o desactivación
de sistemas del vehículo.
• Al tratarse de un vehículo autónomo sería de gran utilidad la posibilidad de elegir cambios

en los perĄles de conducción. En esta interfaz se han utilizado casillas para mostrar u ocultar
distintas trayectorias sobre el mapa, estas casillas podrían ser utilizadas para este nuevo Ąn.
En una nueva pestaĳa se podrían aĳadir estas pestaĳas donde permitan seleccionar en cada
momento el perĄl de conducción deseado.
• En cuanto a distintos parámetros a mostrar se podrían recoger y mostrar la distancia lateral

que hay hasta el límite de la carretera, bordillo o vehículo situado cerca. Este dato sería de gran
utilidad para el control del vehículo y del entorno que lo rodea. Otro dato interesante podría
ser la distancia que hay hasta la siguiente curva si estamos en una recta o el radio de curvatura
si estamos girando. Con este dato se podría ajustar más la velocidad del vehículo si vemos que
nos aproximamos a una curva o la velocidad que debemos llevar en esta si es muy cerrada.
• Por último, una seĳal posible a enviar al vehículo puede ser de inicio o parada. Esto se po-
dría realizar en la misma pestaĳa habilitada para seleccionar los cambios en los perĄles de
conducción, siendo esta pestaĳa dedicada al control del vehículo. Si se incorporan botones que
permitan el inicio o la parada del vehículo sería una gran medida de seguridad extra por si
existe algún problema y no se pudiera parar o iniciar de forma convencional.
Todas estas funcionalidades extra servirían para una gran y signiĄcante mejora en el control y
manejo del vehículo autónomo. También supondría un gran avance en el control del entorno que
rodea a los usuarios que utilicen este tipo de vehículo.
Apéndice A
Manual de usuario
A.1 Instalación de las herramientas necesarias
Lo más importante y principal es la instalación de Qt Creator, para ello, será necesario utilizar
el terminal que dispone Ubuntu. Para abrir el terminal se debe pulsar Ctrl+Alt+T. Tras haber
abierto el terminal, lo primero que se debe hacer es actualizar el software disponible para poder
hacer la instalación completa. Esta actualización se puede realizar escribiendo las siguientes líneas
en el terminal:
sudo apt update

sudo apt install build-essential
Tras la actualización ya se puede hacer la instalación del paquete de Qt Creator escribiendo en

la terminal la siguiente línea:
sudo apt install qtcreator
Como la versión utilizada de Ubuntu es la 20.04 se instalará Qt 5, para ello escribimos:
sudo apt install qt5-default
Por último, si queremos crear proyectos más completos y complejos es necesario la instalación de
la documentación y ejemplos de Qt. Esta instalación se llevará a cabo escribiendo en la terminal:
sudo apt-get install qt5-doc qtbase5-examples qtbase5-doc-html
Como se ha comentado anteriormente, es necesario el uso de OpenCV, para ello se instalarán las
librerías de visión artiĄcial para poder manipular imágenes escribiendo en la terminal:
sudo apt install libopencv-dev
Para la versión de Ubuntu utilizada también se puede hacer la instalación mediante:
45
46 Apéndice A. Manual de usuario
sudo apt install libopencv-dev python3-opencv
Si se quiere comprobar que se ha instalado correctamente se puede comprobar escribiendo:
python3 -c "import cv2; print(cv2.__version__)"
En la terminal se sacará la versión instalada si ha sido correcto el procedimiento y no ha habido

problemas, en mi caso la terminal saca la versión 4.2.0.
A.2 Uso de la interfaz y configuración
Para poder hacer funcionar la interfaz es necesario crear un mecanismo de envío de datos Ącticio.
Este programa independiente leerá el archivo con los datos recogidos por el vehículo y cargará la
información relevante elegida para la interfaz. Este programa irá enviando por la red la información
de forma secuencial en una estructura y la interfaz estará escuchando la red para recibirla. Para
que el proceso de comunicación funcione correctamente se deĄnirá una estructura en un Ąchero .h y
usarlo en los dos programas. Esta estructura tiene la siguiente forma:
typedef struct{
double programmTime,Count,GPSUTC,Height,Quality,Steer,Speed, YawRate,EKF_n;
double EKF_e, EKF_speed, EKF_yr, EKF_accel, SteerRef, SpeedRef, imu_yaw;
double imu_pitch, imu_roll, imu_gyro0, imu_gyro1, imu_gyro2, imu_acc0;
double imu_acc1, imu_acc2;
double northing;
double easting;
double EKF_h;
double LatError;
double AngError;
}comms_t;
Ambos programas deben compartir el siguiente Ąchero .h:
#ifndef SOCKETBROADCASTSENDERRECEIVER_H_
#define SOCKETBROADCASTSENDERRECEIVER_H_
#include <unistd.h>
#include <fcntl.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <string>
#define MAXRECVSTRING 6000 /* Longest string to receive */
class socketBroadcastSenderReceiver {
A.2 Uso de la interfaz y configuración 47
public:
socketBroadcastSenderReceiver();
virtual ~socketBroadcastSenderReceiver();
// SENDER //
bool openBroadcastSender(std::string ip, unsigned short port);
void closeBroadcastSender();
bool sendData(void* data, unsigned int sz);
// RECEIVER //
bool openBroadcastReceiver(unsigned short port);
void closeBroadcastReceiver();
bool receiveData(void* data, ssize_t *sz);
/////////////////////////////////////
bool isOpenBroadcast(){return(is_open_broadcast);} //};
private:
int sock; /* Socket */
struct sockaddr_in broadcastAddr; /* Broadcast address */
int broadcastPermission;/* Socket opt to set permission to broadcast */
bool is_open_broadcast;
};
#endif /* SOCKETBROADCASTSENDERRECEIVER_H_ */
Una vez que se tengan ambos programas funcionando correctamente ya se puede probar el fun-
cionamiento de la interfaz. Para poner en marcha la simulación se deben tener los dos programas
abiertos, primero se inicia la interfaz mediante el botón Run que dispone Qt Creator. Tras iniciar el
Figura A.1: Botón Run para el inicio del código
programa saltará la interfaz creada, aunque no se haya iniciado el programa independiente que envía
los datos se puede variar inicialmente el valor del nivel de alejamiento que queremos para observar el
recorrido o se pueden utilizar los botones habilitados en las primeras pestaĳas para observar el mapa
a utilizar. Cuando se quiera poner en marcha debemos utilizar el mismo botón Run pero que perte-
48 Apéndice A. Manual de usuario
nece al programa independiente. Tras pulsarlo empezará el envío y recepción de datos, a medida que
esto ocurre la interfaz empieza a mostrar en ambos mapas el recorrido del vehículo, la representación
de los errores en la última pestaĳa y los valores seleccionados del vehículo en la parte izquierda.
Mientras que se envían y reciben los datos se puede alternar entre las distintas pestaĳas, y cambiar
el valor del nivel de alejamiento para cambiar la altura de visión de la trayectoria del vehículo. En las
dos primeras pestaĳas, como ya se ha comentado en el capítulo 3, podemos activar las casillas que
se muestran para mostrar las dos trayectorias disponibles, por separado o juntas. La activación de
Figura A.2: Casillas de la interfaz para mostrar las trayectorias
estas casillas es independientes al resto de pestaĳas, si activo una trayectoria en una pestaĳa pero en
la otra pestaĳa no lo está, solo se mostrará en la que se ha activado. En todo momento estas casillas
se pueden marcar y desmarcar.
Bibliografía
[1] J. M. López. Los coches autónomos también quieren su sistema operativo completo. [Online]. Dis-
ponible en: https://www.movistar.es/blog/movistar-car/coche-autonomo-sistemas-operativos/
[2] W. Knight. Cómo controlar a los conductores de los co-

ches autónomos. [Online]. Disponible en: https://www.technologyreview.es/s/5066/
como-controlar-los-conductores-de-los-coches-autonomos
[3] Valeo. CRUISE4U AUTOMATED DRIVING. [Online]. Disponible en: https://www.valeo.com/

en/cruise4u-automated-driving/
[4] V. Service. DRIVER MONITORING. [Online]. Disponible en: https://www.valeo.com/en/

driver-monitoring/
[5] E. Vivó. ¿Qué nivel de conducción autónoma tiene mi coche? [Online]. Disponible en:
https://neomotor.sport.es/conduccion/que-nivel-de-conduccion-autonoma-tiene-mi-coche.html
[6] B. Díaz. Valeo ya tiene listo el Nivel 4 de conducción autónoma. [Online]. Disponible en:
https://www.caranddriver.com/es/movilidad/a37152011/valeo-conduccion-autonoma/
[7] Volvo. Prestaciones XC90. [Online]. Disponible en: https://www.volvocars.com/es/cars/xc90/

features/
[8] Nvidia. Hardware para coches de conducción autónoma. [Online]. Disponible en: https:
//www.nvidia.com/es-es/self-driving-cars/drive-platform/hardware/
[9] V. FUENTES. El Volvo XC90 eléctrico estrenará el avanzado software de conducción

autónoma de NVIDIA. [Online]. Disponible en: https://www.motorpasion.com/volvo/
volvo-xc90-electrico-estrenara-avanzado-software-conduccion-autonoma-nvidia
[10] Zenseact. Autonomous driving software on the path towards ZERO collisions. [Online].
Disponible en: https://www.zenseact.com/
[11] E. Games. The worldŠs most open and advanced real-time 3D creation tool. [Online]. Disponible
en: https://www.unrealengine.com/en-US
[12] A. PÉREZ. El Volvo XC90 eléctrico incorporará este destacado gadget tecno-
lógico. [Online]. Disponible en: https://www.hibridosyelectricos.com/articulo/actualidad/
volvo-xc90-electrico-incorporara-destacado-gadget-tecnologico/20220603164846058715.htlm
49
50 BIBLIOGRAFÍA
[13] Qualcomm. Qualcomm enables a world where everyone and everything can be intelligently
connected. [Online]. Disponible en: https://www.qualcomm.com/home
[14] A. PÉREZ. Unity co-desarrollará el nuevo sistema operativo de Mercedes-Benz que lle-
gará en 2024. [Online]. Disponible en: https://www.hibridosyelectricos.com/articulo/
actualidad/unity-impulsara-nuevo-sistema-operativo-mercedes-benz-que-llegara-2024/
20220809163023061244.html
[15] V. Fuentes. Mercedes-Benz implementará en sus coches un nue-

vo software de NVIDIA que tendrá actualizaciones al esti-
lo Tesla. [Online]. Disponible en: https://www.motorpasion.com/mercedes/
mercedes-benz-implementara-sus-coches-nuevo-software-nvidia-que-tendra-actualizaciones-al-estilo-tesla
[16] Unity. Los coches autónomos también quieren su sistema operativo completo. [Online]. Dispo-
nible en: https://www.movistar.es/blog/movistar-car/coche-autonomo-sistemas-operativos/
[17] V. Fuentes. Tesla actualiza su software para conquistar metas antes de tener un coche
realmente autónomo en la ciudad. [Online]. Disponible en: https://www.motorpasion.com/tesla/
tesla-actualiza-su-software-para-conquistar-metas-antes-tener-coche-realmente-autonomo-ciudad
[18] A. Otero. Las nuevas funciones del Autopilot de Tesla tendrán que esperar: de momento sólo
hay más cambios de interfaz. [Online]. Disponible en: https://www.motorpasion.com/tesla/
nuevas-funciones-autopilot-tesla-tendran-que-esperar-momento-solo-hay-cambios-interfaz
[19] A. Callejo. Tesla actualiza la interfaz del Autopilot. [Online]. Disponible en: https:
//forococheselectricos.com/2019/08/tesla-actualiza-la-interfaz-del-autopilot.html
[20] C. E. Components. Radares para vehículos no tripulados. [Online]. Disponible en:

http://www.compotrade.ru/catalog/10/1
[21] I. Y. M. AUTOMOTRIZ. ¿Qué es el CAN BUS y cómo funciona? [Online]. Disponible en:
https://www.ingenieriaymecanicaautomotriz.com/que-es-el-can-bus-y-como-funciona/
[22] U. Navigation. UAV Navigation En Profundidad: Qué Es Una IMU Y Para Qué Se Utiliza.
[Online]. Disponible en: https://www.uavnavigation.com/es/empresa/blog/que-es-un-imu
[23] J. Kyes. ¿Qué signiĄca GPS? [Online]. Disponible en: https://www.geotab.com/es/blog/

que-es-gps/
[24] D. Industry. Sistema de navegación inercial empotrable INS600. [Online]. Disponible en: https:
//www.directindustry.es/prod/shenzhen-rion-technology-co-ltd/product-144867-2238033.html
[25] B. V. ¿Qué es Ubuntu? Una guía rápida para principiantes. [Online]. Disponible en:
https://www.hostinger.es/tutoriales/que-es-ubuntu
[26] Convertir Lat Long a UTM. [Online]. Disponible en: https://www.latlong.net/lat-long-utm.html
[27] A. Pro. Mercator. [Online]. Disponible en: https://pro.arcgis.com/es/pro-app/latest/help/

mapping/properties/mercator.htm
Universidad de Alcalá
Universidad
de Alcalá

TFG Jimenez Garcia 2022

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Jimenez Garcia 2022

Cargado por

Copyright:

Formatos disponibles

Universidad de Alcalá

Escuela Politécnica Superior

Grado en Ingeniería en Electrónica y Automática

Trabajo Fin de Grado

Autor: Víctor Jiménez García

Tutor: Rubén Izquierdo Gonzalo

GRADO EN INGENIERÍA EN ELECTRÓNICA Y

Trabajo Fin de Grado

Autor: Víctor Jiménez García

Tutor: Rubén Izquierdo Gonzalo

Presidente: D. Ignacio Parra Alonso

Vocal 1º: D. Iván García Daza

Vocal 2º: D. Javier Alonso Ruiz

Índice de figuras III

Lista de acrónimos VII

2 Estado del arte 5

3 Descripción del Sistema 13

3.3 Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Conclusiones y líneas futuras 43

2.1 Vista interna Cruise4U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Vistas del vehículo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Prueba simulada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1 Resultado 1 simulado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

A.1 Botón Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.1 Características del Citroën C4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ADAS Advanced Driving Assistance Systems.

CAN Controller Area Network.

ECU Electronic Control Unit.

GPOS General Purpose Operating System.

IMU Unidad de Medida Inercial.

NASA National Aeronautics and Space Administration.

RAM Random Access Memory.

SAE Society of Automotive Engineers.

UFW Uncomplicated Firewall.

VPN Virtual Private Network.

Se tiene como objetivo principal el diseĳo e implementación de un interfaz de representación de datos

• Principalmente se desarrollará un sistema de visualización de la localización del vehículo sobre

• Se deberán visualizar, además, el estado de funcionamiento de los diferentes sistemas y variables

• El sistema de visualización se ejecutará en un ordenador independiente al del vehículo, siguiendo

• Implementar un protocolo de comunicación basado en red.

1.3 Organización de la memoria

La memoria de este proyecto está dividida en cinco capítulos y tres anexos:

• Apéndice A: en este se detalla el pliego de condiciones. Se incluye las condiciones generales,

• Apéndice B: se analizará las partidas monetarias presupuestadas para la consecución de este

• Apéndice C: corresponde al manual de usuario.

Estado del arte

Figura 2.2: Sistema de reconocimiento facial creado por Valeo [4].

Figura 2.3: Vehículo Volvo automático [9].

Figura 2.5: Futura interfaz de Mercedes-Benz para 2024 [12].

Figura 2.6: Interfaz Tesla 2019 [17]

Descripción del Sistema

3.2 Herramientas necesarias

3.2.1 Vehículo autónomo y sensores

En primer lugar se necesita un vehículo automatizado e instrumentalizado. El vehículo en cuestión

Figura 3.1: Vistas del vehículo.

Modelo Citroën C4 Hatchback 1.6i 16v VTR PLUS

Tabla 3.1: Características del Citroën C4

Rango largo 200 m

Tabla 3.2: Características del radar de largo alcance ARS 308-2

Figura 3.2: Imagen oĄcial de la Grasshopper3

Figura 3.3: Continental ARS 308-2 | Radar de largo alcance [20]

Tabla 3.3: Datos obtenidos a través del bus CAN

Un sensor fundamental para el funcionamiento del vehículo es la IMU. Se trata de un sensor

python3 -c "import cv2; print(cv2.version)"