Embed Size (px)
Citation preview
TRABAJO FIN DE MÁSTER
Diseño e implementación de un sistema de gestión de tráfico basado
en vehículos automatizados y comunicaciones inalámbricas
MÁSTER EN AUTOMÁTICA Y ROBÓTICA
División de Ingeniería de Sistemas y AutomáticaDepartamento de Automática, Ingeniería Electrónicae Informática Industrial
Jorge Luis Godoy Madrid
Dedicado a
Mi madre y mi abuela, quienes a pesar de estar a mas de 7.000 km
de distancia me han brindado todo su apoyo, animo y comprension
durante toda esta nueva etapa en mi vida.
Agradecimientos
Al Consejo Superior de Investigaciones Cientıficas, por financiar mi formacion
por medio del programa de becas Junta para la Ampliacion de Estudios.
A Carlos Gonzalez, quien dıa a dıa ha actuado como guıa directa o indirecta-
mente en mi camino tanto dentro del Programa AUTOPIA como en la sociedad
espanola; a Teresa de Pedro y Ricardo Garcıa, quienes me han recibido con los
brazos abiertos y se han preocupado en todo momento de que mi estancia en el
grupo sea una de mis mejores experiencias.
A los chicos del grupo AUTOPIA, por acompanarme en estos dos anos de
trabajo y de antemano por los anos venideros. A Vicente Milanes, uno de los
lıderes de la manada y principal encargado de devolverme al camino correcto luego
de mis momentos de dispersion; a Joshue Perez, amigo y colega desde hace mas
de 5 anos y quien me ha ayudado siempre de forma incondicional tanto personal
como profesionalmente; a Jorge Villagra, por recordame que la practica pierde
su esencia si se deja de lado su base teorica; a Enrique Onieva, por ayudarme
siempre a encontrar el camino mas sencillo para salir de los vasos de agua; a
Javier Alonso, por su apoyo en la caseta de control, aun en los dıas mas duros
de invierno; a Roberto Sanz, por recordarme que la electronica no es siempre lo
mas importante;
Al personal del DISAM en la ETSII-UPM, quienes me han aportado parte del
conocimiento necesario para la realizacion de este trabajo. Al profesor Ramon
Galan, por su disposicion en todo momento para la realizacion de esta memoria,
haciendo que todo resultara mas facil. A Teresa Olmos, quien amablemente
contesto todas mis dudas cuando era necesario.
Al personal de la sede del CAR en Arganda, Lola, Nacho, Jaime, Angel,
Jesus, Bego, Rodolfo, Agustın, Raul, Ma Eugenia y tantos otros con los que
he compartido dıa a dıa en los ultimos dos anos y que han hecho mas llevadera
mi estancia en Espana.
A mis amigos Peter, Mirvy, Nats, Andres, Grey, Manuel, Gaby, Emmi, Leo y
todos los que me han permitido tener un pedacito de la USB y de Venezuela en
Madrid.
A mes amis francais Sylvia, PA, Erwan, Gaelle, Mael, Julie, Corinne et Doro,
qui m’ont soutenu pendant tout ce temps et m’ont permis de mieux connaıtre
certaines parties de la culture francaise.
A toda mi familia, que son tantos que me ocuparıan un capıtulo entero y que
han estado pendientes de mı y de mi trabajo en todo momento y a pesar de la
distancia y la diferencia horarıa que nos separa. Gracias a todos por su apoyo
para seguir adelante.
A todas estas personas y a alguna mas que haya podido olvidar y que con su
apoyo personal o profesional hayan contribuıdo al desarrollo de este trabajo.
A todos, ¡Muchas gracias!
Pidamos que cuando nos vaya mal
nos vaya como nos ha ido hoy.
Gerardo Fernandez
Go as far as you can see, when you got there,
you will be able to see farther.
John Pierpont Morgan
Contenido
1 Introduccion 1
1.1 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . 2
2 Estado del Arte 5
2.1 Grupos de Investigacion . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Europa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1.1 INSIA . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1.2 Lara . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1.3 Centro de Investigacion FIAT . . . . . . . . . . . 7
2.1.2 America . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2.1 NAVLAB . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2.2 Virginia Tech . . . . . . . . . . . . . . . . . . . . 10
2.1.2.3 Tartan Racing Team . . . . . . . . . . . . . . . . 10
2.1.2.4 PATH . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Asia y Australia . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3.1 Ministerio de Transporte de Japon . . . . . . . . 12
2.1.3.2 Universidad de Griffith . . . . . . . . . . . . . . . 13
2.2 Proyectos de Investigacion . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Proyectos Europeos . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1.1 Safespot . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1.2 CVIS . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1.3 COOPERS . . . . . . . . . . . . . . . . . . . . . 15
2.2.1.4 CyberCars . . . . . . . . . . . . . . . . . . . . . 15
2.2.1.5 e-Safety . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1.6 Consorcio Car2Car . . . . . . . . . . . . . . . . . 17
2.2.1.7 PReVENT . . . . . . . . . . . . . . . . . . . . . 17
2.2.1.8 INTERSAFE 2 . . . . . . . . . . . . . . . . . . . 18
2.2.2 Proyectos Americanos . . . . . . . . . . . . . . . . . . . . 19
2.2.2.1 DARPA . . . . . . . . . . . . . . . . . . . . . . . 19
i
CONTENIDO
2.2.2.2 Google Driverless Car . . . . . . . . . . . . . . . 19
2.3 Programa AUTOPIA . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 ORBEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.2 Vehıculos . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.3 Zona de Conduccion . . . . . . . . . . . . . . . . . . . . . 26
3 Platero y su instrumentacion 29
3.1 El vehıculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Ordenador a Bordo . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Sensores Embarcados . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 BUS CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.3 Tarjeta WiFi . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 Actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.1 Acelerador . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.2 Sistema de frenado electro-hidraulico . . . . . . . . . . . . 38
3.4.2.1 Validacion del sistema de frenado . . . . . . . . . 41
3.4.3 Volante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.3.1 Controlador borroso . . . . . . . . . . . . . . . . 46
3.4.3.2 Validacion del sistema . . . . . . . . . . . . . . . 48
3.4.3.3 Dificultades encontradas durante la implementacion 50
4 Comunicaciones 51
4.1 Evolucion previa de la arquitectura de comunicacion . . . . . . . . 52
4.2 Esquema global de comunicacion . . . . . . . . . . . . . . . . . . 55
4.3 Arquitectura de comunicacion implementada . . . . . . . . . . . . 55
4.3.1 Nivel principal o superior . . . . . . . . . . . . . . . . . . . 57
4.3.1.1 UDP vs TCP. . . . . . . . . . . . . . . . . . . . . 57
4.3.1.2 Reenvıo de paquetes . . . . . . . . . . . . . . . . 59
4.3.1.3 Centralizacion de la informacion . . . . . . . . . 60
4.3.1.4 Estructuras de datos . . . . . . . . . . . . . . . . 61
4.3.2 Nivel secundario o auxiliar . . . . . . . . . . . . . . . . . . 63
4.3.2.1 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.2.2 Arquitectura de red ZigBee auxiliar . . . . . . . . 64
4.3.2.2.1 Seccion estatica . . . . . . . . . . . . . . 64
4.3.2.2.2 Seccion dinamica . . . . . . . . . . . . . 65
4.3.2.3 Implementacion fısica . . . . . . . . . . . . . . . 67
4.3.2.4 Estructuras de datos . . . . . . . . . . . . . . . . 68
ii
CONTENIDO
4.3.2.5 Validacion del nivel . . . . . . . . . . . . . . . . . 70
5 Resultados experimentales 73
5.1 Gestion automatica de la velocidad . . . . . . . . . . . . . . . . . 73
5.1.1 Implementacion . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2 Control bajo demanda de semaforos . . . . . . . . . . . . . . . . . 75
5.2.1 Implementacion . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.3 Control de incorporaciones . . . . . . . . . . . . . . . . . . . . . . 79
5.3.1 Diseno e implementacion . . . . . . . . . . . . . . . . . . . 80
5.3.1.1 Sistema de decision . . . . . . . . . . . . . . . . . 81
5.3.1.2 Sistema de control . . . . . . . . . . . . . . . . . 83
5.3.2 Pruebas y resultados . . . . . . . . . . . . . . . . . . . . . 85
6 Conclusiones 89
iii
CONTENIDO
iv
Indice de Figuras
2.1 Vehıculos de La Route Automatisee. . . . . . . . . . . . . . . . . 7
2.2 Vehıculo del programa FIAT Autonomy. . . . . . . . . . . . . . . 9
2.3 Vehıculo NavLab11. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Prototipo de la Universidad de Virginia. . . . . . . . . . . . . . . 10
2.5 Prototipo “Boss” del Tartan Racing Team. . . . . . . . . . . . . . 11
2.6 Vehıculos del programa PATH durante un experimento de Pla-
tooning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Nissan ASV-4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 Vehıculo e Interfaz desarrolladas por COOPERS. . . . . . . . . . 15
2.9 Vehıculo CyberCar. . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.10 Camion instrumentado para el proyecto INTERSAFE 2. . . . . . 18
2.11 Vehıculo prototipo utilizado por Google. . . . . . . . . . . . . . . 20
2.12 Furgonetas electricas Babieca y Rocinante. . . . . . . . . . . . . . 24
2.13 Vehıculo Clavileno. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.14 Vehıculo Platero. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.15 Imagen de Molinero. . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.16 Vista aerea de la Zona de Conduccion. Trazado original (arriba)
y trazado actual (abajo). . . . . . . . . . . . . . . . . . . . . . . . 26
2.17 Plano esquematico de la Zona de Conduccion. . . . . . . . . . . . 27
2.18 Imagen de la estacion de control y antena de comunicaciones. . . . 28
3.1 Modificaciones previas realizadas al vehıculo. . . . . . . . . . . . . 30
3.2 Arriba: Ordenador embarcado en el vehıculo. Abajo: Teclado y
Pantalla del ordenador. . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Imagen del DGPS Modelo BD960. . . . . . . . . . . . . . . . . . . 32
3.4 Programas de correccion diferencial utilizados. Izquierda: Version
con comunicacion serial. Derecha: nueva version con conexion TCP 34
3.5 Adaptador USB-to-CAN incorporado al ordenador a bordo. . . . . 35
3.6 Esquema de la comunicacion WiFi. . . . . . . . . . . . . . . . . . 36
v
INDICE DE FIGURAS
3.7 Esquema general de la automatizacion del acelerador. . . . . . . . 37
3.8 Esquema general del sistema de frenado implementado en Platero. 39
3.9 Fotografıa del sistema de frenado electro-hidraulico instalado en
Platero. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.10 Pruebas de frenado sobre asfalto: Evolucion de la velocidad del
vehıculo (arriba). Indicador ABS (abajo). . . . . . . . . . . . . . 41
3.11 Pruebas de frenado sobre superficie deslizante: Evolucion de la
velocidad del vehıculo (arriba). Indicador ABS (abajo). . . . . . . 42
3.12 Imagen del controlador MDL-BDC24. . . . . . . . . . . . . . . . . 45
3.13 Esquema del sistema de control del volante. . . . . . . . . . . . . 46
3.14 Entradas del controlador de posicion del volante. . . . . . . . . . . 47
3.15 Salida del controlador de posicion del volante. . . . . . . . . . . . 47
3.16 Superficie de control para el volante. . . . . . . . . . . . . . . . . 48
3.17 Pruebas del controlador del volante con el vehıculo sobre asfalto. . 49
3.18 Pruebas del controlador del volante con el vehıculo sobre zona no
asfaltada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.19 Pruebas del volante controlado a traves del teclado. . . . . . . . . 50
4.1 Procedimiento para iniciar la comunicacion en el antıguo esquema
de conexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Procedimiento para establecer el enlace de comunicaciones. . . . . 54
4.3 Escenario 1: Perdida de comunicacion temporal. . . . . . . . . . . 59
4.4 Escenario 2: Perdida de comunicacion periodica. . . . . . . . . . . 60
4.5 Interfaz de control implementada en la caseta de la Zona de
Conduccion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6 Esquema de la estructura de notificacion del nivel auxiliar. . . . . 65
4.7 Dispositivos IRIS fabricados por CrossBow. . . . . . . . . . . . . 67
4.8 Imagen de las tarjetas MIB520. . . . . . . . . . . . . . . . . . . . 68
4.9 Distribucion de los nodos de la seccion estatica sobre el ZOCO. . 68
4.10 Dispositivos instalados en la caseta de control y en Platero. . . . . 69
4.11 Ubicaciones del NM al momento de enviar el mensaje. . . . . . . . 71
4.12 Tiempos de respuesta de la red. . . . . . . . . . . . . . . . . . . . 72
5.1 Esquema general de las pruebas de control automatico de velocidad 74
5.2 Resultados para una prueba promedio: evolucion temporal de la
distancia (arriba) y de la velocidad (abajo). . . . . . . . . . . . . 75
5.3 Aplicacion auxiliar para el control de semaforos. . . . . . . . . . . 77
5.4 Semaforos disponibles y numeracion de las entradas a la interseccion. 78
vi
INDICE DE FIGURAS
5.5 Evolucion temporal del estado de los semaforos. . . . . . . . . . . 79
5.6 Esquema de la maniobra de incoporacion. . . . . . . . . . . . . . 82
5.7 Funciones de pertenencia para las entradas del controlador. . . . . 84
5.8 Funciones de pertenencia para la salida del controlador. . . . . . . 84
5.9 Superficie de control para las incorporaciones. . . . . . . . . . . . 85
5.10 Esquema de las pruebas del sistema de control de intersecciones. . 86
5.11 Evolucion de los vehıculos en durante el experimento. . . . . . . . 87
vii
INDICE DE FIGURAS
viii
Indice de Tablas
2.1 Coordenadas UTM de la Zona de Conduccion. . . . . . . . . . . . 27
3.1 Caracterısticas del equipo BD960 . . . . . . . . . . . . . . . . . . 32
3.2 Contenido del mensaje GGA del protocolo NMEA . . . . . . . . . 33
3.3 Contenido del mensaje VTG del protocolo NMEA . . . . . . . . . 33
4.1 Estructura general de los mensajes enviados por los vehıculos y la
caseta de control. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2 Estructuras de datos implementadas. . . . . . . . . . . . . . . . . 62
4.3 Caracterısticas de dispositivos Zigbee comerciales [Milanes 10b]. . 67
4.4 Estructuras de mensajes definidas para el nivel auxiliar. . . . . . . 70
ix
INDICE DE TABLAS
x
Capıtulo 1
Introduccion
Durante la ultima decada la cantidad de vehıculos en las carreteras ha crecido
continuamente en el mundo entero. Solo en la Union Europea (UE27) se registro
un incremento de 12,77% en el numero de vehıculos particulares – disenados para
un maximo de nueve pasajeros. Este incremento se ha reflejado a su vez en
un aumento de los atascos en entornos urbanos y por ende, de las emisiones de
dioxido de carbono. Mas alla de este crecimiento, la tasa anual de accidentes
ha disminuıdo en torno a un 23% en el mismo perıodo de tiempo, lo cual
indica que tanto los vehıculos como las carreteras se estan haciendo mas seguras
[E-Safety 11].
En lo referente a los vehıculos los primeros pasos en materia de seguridad se
realizaron con la inclusion de sistemas como los cinturones de seguridad o las
bolsas de aire. Sin embargo, mas alla de la indiscutible proteccion que pueden
brindar estos sistemas, su actuacion se puede considerar bastante pasiva ya que
solo actuan cuando una situacion crıtica ocurre – e.g. cuando una colision es
practicamente inevitable. Posteriormente, con la implementacion del sistema
antibloqueo de ruedas (ABS por sus siglas en ingles) los fabricantes de vehıculos
iniciaron lo que serıa el camino al desarrollo de sistemas avanzados de asistencia
al conductor (ADAS por sus siglas en ingles), pensados para ayudar al conductor
de forma activa durante la conduccion.
Hoy en dıa es posible encontrar vehıculos comerciales que incorporan algunas
soluciones ADAS orientadas a la seguridad, los cuales pueden desde alertar al
conductor sobre situaciones de riesgo hasta actuar directamente sobre el vehıculo
si detectan que el conductor se encuentra distraıdo. Dos ejemplos de ello son
el sistema Lane Keeping, disponible en los Mercedes clase E y S, el cual genera
una vibracion sobre el volante cuando detecta que el vehıculo esta abandonando
su canal de forma involuntaria; y el sistema City Safety desarollado por Volvo
1
1. INTRODUCCION
e incorporado recientemente en el modelo XC60 el cual, a velocidades menores
de 20 km/h, es capaz de detener el vehıculo cuando detecta algun obstaculo en
frente de este, reduciendo ası la posibilidad de colisiones en entornos urbanos.
Aunque la idea de tener vehıculos totalmente automatizados circulando en las
calles sigue siendo una utopıa, es posible encontrar actualmente una gran cantidad
de grupos, proyectos y competiciones a nivel mundial orientados a esta lınea de
investigacion, como lo son el programa PATH, de la universidad de Berkeley;
la competencia DARPA Grand Challenge, de la Agencia de Investigacion de
Proyectos Avanzados de Defensa de los EE.UU.; y el Programa AUTOPIA,
del Centro de Automatica y Robotica UPM-CSIC. Mas alla de que todos estos
grupos tengan como objetivo principal la total automatizacion de los vehıculos
y las carreteras, toda la investigacion realizada con este fin conlleva a su vez
al desarrollo de otros subsistemas que pueden ser implementados, de forma mas
inmediata, como sistemas de ayuda a la conduccion.
Partiendo de esta idea, en este trabajo se presentan los detalles de la entera
automatizacion de un vehıculo comercial, ası como la implementacion de una
arquitectura de comunicacion multinivel que sirva de base para el desarrollo
de diversas maniobras cooperativas entre vehıculos. En lo referente a la
automatizacion del vehıculo, todo el trabajo realizado parte del esquema general
de control del Programa AUTOPIA, grupo receptor donde se ha desarrollado
este trabajo. Por otra parte, la arquitectura de comunicaciones planteada tiene
como base la combinacion de diferentes tecnologıas de comunicacion dentro del
esquema general basado en areas locales y planteado en [Milanes 10a].
1.1 Estructura de la memoria
A continuacion se detalla el contenido de los 5 capıtulos restantes de este
trabajo:
En el Capıtulo 2 se presenta el estado actual de la tecnica en lo que
respecta a los Sistemas Inteligentes de Transporte, haciendo hincapie en los
grupos y proyectos de investigacion mas relevantes en el campo a nivel mundial.
Finalmente se presenta el Programa AUTOPIA, dentro del cual se desarrolla el
trabajo presentado.
En el Capıtulo 3 se describe de forma detallada la instrumentacion realizada
sobre cada uno de los actuadores claves de Platero – uno de los vehıculos del
Programa AUTOPIA – con el objetivo de lograr su completa automatizacion.
El Capıtulo 4 introduce una nueva arquitectura multinivel para la comuni-
2
1.1 Estructura de la memoria
cacion entre vehıculos y la infraestructura. La arquitectura presentada se basa en
la combinacion de distintas tecnologıas de la comunicacion dentro de un entorno
dividido en areas locales. Como validacion del sistema se presentan los resultados
de las pruebas realizadas para determinar el tiempo de respuesta de la red ante
incidencias en el entorno.
En el Capıtulo 5 se incluyen los resultados de varios experimentos realizados
en base a los sistemas implementados en el vehıculo y la infraestructura. Todas
las pruebas presentadas se han llevado a cabo en las instalaciones del CAR.
El Capıtulo 6 explica las principales aportaciones del trabajo presentado,
enfatizando en la experiencia extraıda lograda y comentando las futuras lıneas de
investigacion.
Por ultimo, se recoge la Bibliografıa que ha resultado indispensable para la
realizacion de este trabajo.
3
1. INTRODUCCION
4
Capıtulo 2
Estado del Arte
Los Sistemas Inteligentes de Transporte (ITS por sus siglas en ingles) surgen
en la decada de los anos 90 con el objetivo principal de incrementar la eficacia,
eficiencia y seguridad del transporte. Normalmente, los ITS se presentan como
una combinacion de distintos sistemas avanzados de informacion, comunicacion
y control aplicados tanto en los vehıculos como a la infraestructura. Aunque es
posible que el termino se asocie directamente a su aplicacion en las carreteras, esta
se extiende mucho mas alla. Un ejemplo de ello es la definicion proporcionada
por la Direccion General de Energıa y Transporte de la Union Europea en la
que se considera que los ITS pueden ser aplicados perfectamente a autopistas,
ferrocarriles, transporte marıtimo y aereo, ası como las conexiones entre estos
distintos tipos de transporte.
Enfocandonos solo en el ambito del transporte en las carreteras, los ITS pueden
– dependiendo de su complejidad – desde interactuar con un solo vehıculo hasta
controlar el trafico de toda una red de carreteras. Entre sus objetivos especıficos
se encuentran la mejora de la seguridad en las carreteras, la optimizacion de la
fluidez del trafico, la reduccion de emisiones y el control de sistemas de transporte
publico. La amplitud de estos objetivos provoca que sea practicamente imposible
que un mismo grupo o proyecto de investigacion cubra todas las areas que los
integran, por lo que hoy en dıa podemos encontrar una gran diversidad de grupos
especializados en areas concretas en busca de avances significativos.
A lo largo de este capıtulo se presentara una breve descripcion de los principales
grupos y proyectos de investigacion enfocados al desarrollo e implementacion de
distintos sistemas ITS.
5
2. ESTADO DEL ARTE
2.1 Grupos de Investigacion
Mas alla de que los fabricantes de automoviles invierten grandes cantidades
de dinero para el desarrollo de vehıculos mas seguros, exıste a nivel mundial un
gran numero de grupos de investigacion dedicados a las mejoras de los sistemas
que ya se encuentran en el mercado y a la incorporacion de otros mas modernos
y eficientes. A continuacion se repasan algunos de los grupos mas influyentes en
esta lınea de investigacion.
2.1.1 Europa
2.1.1.1 INSIA
El Instituto Universitario de Investigacion del Automovil (INSIA) es un centro
perteneciente a la Universidad Politecnica de Madrid (UPM), adscrito a la Escuela
Tecnica Superior de Ingenieros Industriales (ETSII) e integrado en el parque
cientıfico y tecnologico de la UPM.
Actualmente, el INSIA representa uno de los centros de I+D+I de mayor
referencia en sector de la automocion, ademas de ser un laboratorio oficial
autorizado para la homologacion en diversos reglamentos y directivas, ası como
en reformas de importancia. Dentro del mismo, se llevan a cabo actividades
de investigacion, formacion, desarrollo e innovacion en diversas areas como los
accidentes de trafico, la seguridad pasiva en vehıculos de transporte (autobuses,
autocares y vehıculos industriales), sistemas inteligentes, ingenierıa de vehıculos
y biomecanica.
Los estudios desarrollados por este instituto se guıan por 7 lıneas de investi-
gacion fundamentales: 1) la mejora de la seguridad en autobuses, autocares y
en el transporte de mercancıas, 2) analisis de las causas y consecuencias de los
accidentes de trafico, 3) biomecanica aplicada a la mejora de la seguridad pasiva
de vehıculos, 4) desarrollo y aplicacion de modelos para la evaluacion y prediccion
de los impactos del transporte por carretera en la seguridad y medio ambiente, 5)
sistemas de asistencia al conductor (ADAS) relacionados con el control inteligente
de la velocidad, 6) sistemas alternativos de propulsion e impacto medioambiental
de los vehıculos automoviles y 7) mecanica computacional aplicada al estudio del
comportamiento dinamico de los vehıculos.
Al ser un centro I+D+I de referencia, el INSIA ha comenzado, desde el 2007,
a gestionar y establecer alianzas estrategicas con otros centros de investigacion
y desarrollo con el objetivo de intercambiar experiencias, desarrollar capacidades
complementarias y concurrir conjuntamente a convocatorias de proyectos de
6
2.1 Grupos de Investigacion
Figura 2.1: Vehıculos de La Route Automatisee.
I+D+I, siendo un ejemplo de esta estrategia el convenio Marco firmado con
el Centro de Innovacion Tecnologica de Automocion de Navarra (CITEAN).
Ademas de estas alianzas con centros I+D+I, el INSIA coopera con empresas
e instituciones para las cuales sus estudios son de gran interes, como es el caso
de ALSA, IRIZAR, EMT Madrid y la DGT.
2.1.1.2 Lara
El programa LaRA (acronimo frances, La Route Automatisee) surge en el ano
1997 como un consorcio de investigacion enfocado al estudio de los sistemas para
la asistencia y automatizacion de la conduccion. Promovido inicialmente por
3 organismos del gobierno Frances: el INRETS (Institut National de Recherche
sur les Transports et leur Securite), el INRIA (Institut National de Recherche
en Informatique et Automatique) y el LCPC (Laboratoire Central des Ponts
et Chaussees); el programa LaRA se enfoca en el estudio de cuatro escenarios
claves en las carreteras francesas: las carreteras rurales, locales, interurbanas y
las redes de autopistas que rodean a las grandes ciudades; desarrollando nuevas
tecnologıas que incrementen la seguridad, el confort y la eficiencia del transporte
por carreteras. La filosofıa de este grupo es ayudar a los conductores para mejorar
la seguridad, confort y eficiencia del transporte por carretera, siendo la meta
final eliminar la necesidad de un conductor humano, al menos en situaciones
particulares tales como autopistas dedicadas y situaciones de trafico urbano a
bajas velocidades.
2.1.1.3 Centro de Investigacion FIAT
El Centro de Investigacion FIAT (CRF por sus siglas en italiano) se creo en
1976 como un centro de referencia para la innovacion, investigacion y desarrollo
del grupo FIAT. Actualmente es reconocido a nivel internacional como un
centro de excelencia para el desarrollo de soluciones efectivas e innovadoras
con costes competitivos, que ademas promueve la transferencia tecnologica y
7
2. ESTADO DEL ARTE
el entrenamiento de personal altamente calificado. Todas las companıas del
grupo FIAT consideran al CRF como la bandera estrategica de innovacion que
desempena el papel fundamental para el crecimiento tecnologico del grupo.
Luego de casi 35 anos en el sector de la investigacion, el CRF cuenta hoy en dıa
con mas de 150 universidades y centros de investigacion aliados a nivel mundial,
los cuales, sumados a los mas de 1.000 colaboradores del sector industrial,
constituyen una amplia red global de innovacion. En cuanto a sus lıneas de
investigacion, el CRF se centra en el estudio de nuevas soluciones enfocadas al
sistema de propulsion de los vehıculos que permitan reducir tanto las emisiones
como la contaminacion acustica generada. Adicionalmente, el CRF estudia la
optimizacion del consumo de combustible a traves de la inclusion de nuevos
materiales que permitan disminuir el peso del vehıculo e introducir mejoras
aerodinamicas que aumenten la eficiencia de la conduccion, sin olvidar nunca
que el objetivo final es el desarrollo de vehıculos mas seguros, confortables y
cuidadosos con el medio ambiente.
Uno de los aportes mas relevantes del CRF y el grupo FIAT al dıa de
hoy ha sido el programa AUTONOMY. Este programa, iniciado en 1994, se
enfoca en el desarrollo y adaptacion de vehıculos para facilitar el acceso y
mejorar tanto el confort como la independencia de los conductores y pasajeros
con discapacidades fısicas. Este programa cuenta ademas con simuladores de
conduccion que permiten a un personal especializado el estudio de las capacidades
de conduccion de las personas con necesidades especiales, analizando tanto las
capacidades motrices del conductor como su capacidad de reaccion ante estımulos
visuales y auditivos.
Actualmente el CRF cuenta con mas de 2.300 patentes y esta involucrado en
mas de 70 proyectos del septimo programa marco 2007-2013 de la comunidad
europea, demostrando su alto nivel de contribucion a la investigacion en Europa.
2.1.2 America
2.1.2.1 NAVLAB
El grupo Natlab trabaja en la implementacion de sistemas para coches,
camiones y autobuses con el objetivo de dotarlos de la capacidad de ralizar una
conduccion autonoma o asistir a los conductores. Desde su creacion en 1984 el
grupo ha producido una serie de once vehıculos, desde el Navlab 1 hasta el Navlab
11 (ver figura 2.3). Entre sus objetivos se incluyen la exploracion en cualquier
tipo de terreno, la automatizacion en carretera, la reduccion de las colisiones en
8
2.1 Grupos de Investigacion
Figura 2.2: Vehıculo del programa FIAT Autonomy.
Figura 2.3: Vehıculo NavLab11.
circulacion y la asistencia al conductor en entornos urbanos.
El primer vehıculo de esta serie, NavLab1, alcanzaba velocidades de 32 Km/h
en conduccion automatica. Posteriormente su evolucion, el NavLab2, alcanzo
velocidades de hasta 88 Km/h. En 1995, el grupo NavLab realizo el experimento
denominado “No hands Across America”, durante el cual el Navlab 5 circulo
desde Washinton a California por autopista, controlando de forma automatica la
direccion (durante el 98,8% del recorrido) y manual la velocidad.
Actualmente se encuentran desarrollando el proyecto CTA Robotics centrando
sus investigaciones en la capacidad del vehıculo para interpretar el entorno en
el que se encuentra y hallar una solucion optima para moverse a traves de el
[Wang 07].
9
2. ESTADO DEL ARTE
Figura 2.4: Prototipo de la Universidad de Virginia.
2.1.2.2 Virginia Tech
La Universidad de Virginia ha formado un grupo compuesto por estudiantes,
doctorandos y profesores provenientes de la universidad y companias dedicadas
a los sistemas autonomos. El equipo ha construıdo un prototipo (figura 2.4) que
ha participado en el DARPA Urban Challenge en 2007, alcanzando la segunda
posicion.
El equipo esta organizado en distintos departamentos para afrontar cada uno
de los campos necesarios para desarrollar un vehıculo autonomo. Adicional-
mente, cuentan con una potente herramienta de simulacion de entornos reales
desarrollada por TORC Technologies que tambien participa en el proyecto. Esta
herramienta les permite simular entornos 3D para estudiar diferentes compor-
tamientos de conduccion, algoritmos de prediccion del trafico con varios vehıculos
y sistemas de posicionamiento avanzados para casos de perdida de la senal GPS.
2.1.2.3 Tartan Racing Team
Este grupo de investigacion esta formado por la universidad Carnegie Mellon
en colaboracion con General Motors Corporation, una de las mayores companias
de automocion del mundo. Su prototipo Boss (figura 2.5 es el campeon del
DARPA Urban Challenge 2007 [Urmson 08].
El equipo es liderado por el Dr. Whittaker con el apoyo del Dr. Urmson en
la parte tecnica. Ademas de los investigadores de la universidad y de GM, el
equipo cuenta con el apoyo de empresas como Cartepillar, Continental AG, Intel,
Google, Appplanix, TeleAtlas, vector, Ibeo y Hewlett Packard entre otras.
Su ultimo prototipo, Boss, es una Chevrolet Tahoe del ano 2007 al cual se
le han incorporado una serie de modificaciones para permitir su conduccion
10
2.1 Grupos de Investigacion
Figura 2.5: Prototipo “Boss” del Tartan Racing Team.
autonoma. Por razones de seguridad, este vehıculo mantiene los controles
normales de conduccion (volante, freno y acelerador) de modo que un conductor
humano pueda tomar el control del vehıculo de forma rapida y sencilla en caso
de fallo del controlador durante los experimentos. Adicionalmente, cuenta con
un sistema que protege a los ocupantes del vehıculo en caso de colision o vuelco
del mismo.
La ejecucion del codigo de control del Boss se realiza en un set de 10
procesadores Core2Duo con una frecuencia de operacion de 2,16 GHz y 2 GB
de memoria para cada uno de ellos. Todos los equipos se inician mediante una
unidad flash externa de 4GB, lo que permite reducir la posibilidad de un fallo de
disco. Sin embargo, dos ordenadores cuentan con unidades de disco con capacidad
de 500GB para el registro de datos.
La captura del entorno se realiza con una amplia combinacion de sensores
que le permiten contar con la redundancia y cobertura necesaria para navegar de
forma segura en un entorno urbano. En total, Boss cuenta con mas de 18 sensores
entre los que se encuentran camaras de vision, lidar, GPS, radares y unidades de
medicion inercial.
2.1.2.4 PATH
El consorcio PATH (Partners for Advance Transit and Highways) se creo en
1986. Esta formado por el Instituto de Estudios de Transporte (ITS por sus
siglas en ingles) de la Universidad de California (UC), Berkeley, en colaboracion
con el Departamento de Transporte de California. PATH es un programa
multidisciplinario que cuenta con investigadores, profesores y estudiantes de
11
2. ESTADO DEL ARTE
Figura 2.6: Vehıculos del programa PATH durante un experimento de Platooning.
todas las universidades del estado de California ademas de la colaboracion de
la industria privada, agencias gubernamentales e instituciones sin fines de lucro.
Actualmente se encuentra bajo la direccion del profesor Alexander Skabardonis
del Departamento de Ingenierıa Civil y Ambiental de la UC Berkeley y cuenta con
un personal de 45 personas a tiempo completo. Adicionalmente este programa
apoya la investigacion de cerca de 50 profesores de la universidad y 90 estudiantes.
El objetivo de este programa es el desarrollo de estrategias y tecnologıas
innovadoras en el campo de los sistemas inteligentes de transporte con la finalidad
de mejorar la seguridad, flexibilidad, movilidad y administracion de los sistemas
de transporte del estado de California, Estados Unidos y todo el mundo.
A largo plazo, este programa plantea la resolucion de los problemas de
trafico mediante la automatizacion total o parcial de los vehıculos. Su trabajo
se centra en el establecimiento de vıas cerradas para el uso exclusivo de
vehıculos autonomos. Su principal foco de atencion esta en las caravanas
de vehıculos autonomos (Platooning) [Sheikholeslam 93], principalmente en
autopistas [Shladover 92]. En el ano 1997 tuvo lugar una demostracion con ocho
vehıculos autonomos capaces de circular con una distancia de separacıon entre
ellos de 6.5 metros (figura 2.6).
2.1.3 Asia y Australia
2.1.3.1 Ministerio de Transporte de Japon
El Ministerio de Transporte de Japon se ocupa de regular la seguridad de
la industria del automovil. Su programa mas relevante es el Advance Safety
12
2.1 Grupos de Investigacion
Figura 2.7: Nissan ASV-4.
Vehicle (ASV), bajo cuyos auspicios todos los grandes OEM japoneses han
desarrollado tecnicas para mejorar la seguridad, como sistemas ITS de advertencia
y ayuda. Por ejemplo, airbags externos para proteger a los peatones o para
ciclomotores, parabrisas que repelen el agua, etc. Es importante mencionar
que estos desarrollos son financiados por las companias, el ministerio se limita
a dirigirlos y coordinarlos. Este programa fue la base de la Demo 2000 del
SmartCruise21 realizada en la pista del Japan Automobile Research Institute.
En el ano 2007 se inicio la cuarta fase del programa ASV y Nissan ha presentado
la cuarta generacion, denominada Nissan ASV-4 (ver figura 2.7) cuyo objetivo
es la reduccion de los accidentes de trafico mediante la comunicacion vehıculo
- vehıculo en la que se avisa al conductor de la existencia de otro vehıculo en
condiciones de climatologıa adversas o intersecciones de riesgo.
2.1.3.2 Universidad de Griffith
La Universidad de Griffith ha creado, en conjunto con el gobierno australiano,
el sector privado y otras universidades del paıs; un laboratorio para la investi-
gacion de ITS con sede en la Universidad. Dentro de este laboratorio trabajan
en la cooperacion de vehıculos autonomos en tareas como el control de la distan-
cia al vehıculo precedente en cruces, adelantamientos y conduccion cooperativa
[Baber 05]. Ademas, se han realizado experimentos con prototipos en los que
intervienen varios vehıculos que confluyen en un cruce, siendo capaces de salir de
la interseccion de manera coordinada y sin colisionar.
13
2. ESTADO DEL ARTE
2.2 Proyectos de Investigacion
En esta seccion se presenta una breve descripcion de los proyectos de
investigacion mas importantes orientados al desarrollo de los ITS. En la mayorıa
de estos proyectos participan, o han participado, los grupos presentados en la
seccion anterior.
2.2.1 Proyectos Europeos
2.2.1.1 Safespot
Safespot es un proyecto englobado en el sexto programa marco de la
Comunidad Europea (FP6) y dedicado al estudio de la cooperacion entre vehıculos
e infraestructura con la finalidad de incrementar la seguridad en las carreteras.
Su objetivo principal es el desarrollo de un Asistente de Seguridad Marginal que
permita detectar con anticipacion una posible situacion de riesgo, incrementanto
el tiempo disponible para evitarlo. La base de este asistente son una serie de
mapas dinamicos digitales del entorno local, elaborados a partir de la informacion
obtenida a traves de las comunicaciones vehıculo-vehıculo (V2V) y vehıculo-
infraestructura (V2I).
2.2.1.2 CVIS
El proyecto Cooperative Vehicle Infrastructure Systems (CVIS) es un proyecto
FP6 orientado a la creacion de una solucion unificada que permita a los vehıculos
y elementos de la infraestructura comunicarse de forma bidireccional, contınua
y transparente; utilizando para ello la variedad de medios disponibles. Para
alcanzar este objetivo, CVIS desarrolla un router movil basado en la arquitectura
CALM estandar ISO, que permite enlazar continuamente los vehıculos con las
unidades y equipos de carretera utilizando tecnologıas como: redes moviles
2G/3G, infrarrojos, WiFi (IEEE 802.11 a/b/g) y WAVE (Wireless Access in
Vehicular Enviroments) entre otros. CVIS tambien desarrolla una arquitectura
abierta para conectar en el vehıculo sistemas de gestion de trafico con servicios
telematicos en la carretera.
CVIS proporciona una capa middleware con un entorno de desarrollo que
contiene modulos de identificacion y seguridad e interfaces de programacion de
aplicaciones para los vehıculos, unidades de carretera y los conductores [Ernst 09].
Estas interfaces se basan en estandares abiertos para asegurar que los usuarios
de CVIS puedan acceder a ellas en cualquier parte y que los proveedores puedan
14
2.2 Proyectos de Investigacion
Figura 2.8: Vehıculo e Interfaz desarrolladas por COOPERS.
proporcionar servicios a todos los vehıculos.
2.2.1.3 COOPERS
COOPERS (CO-OPerative SystEms for Intelligent Road Safety) es un proyecto
FP6, al igual que CIVIS y Safespot, enfocado al desarrollo de aplicaciones
telematicas innovadoras para la infraestructura [Toulminet 08]. El objetivo
principal de este proyecto es la gestion del trafico de forma cooperativa entre
el vehıculo y la infraestructura, permitiendo ası reducir la brecha que existe en
el desarrollo de aplicaciones telematicas entre la industria automovilıstica y los
operadores de la infraestructura. Esta arquitectura de gestion de trafico planteada
por COOPERS esta basada en un enlace contınuo de comunicaciones V2I, que
permite el intercambio de la informacion relevante para un segmento especıfico
de las carreteras, incrementando el nivel de seguridad en estas.
A fin de lograr un enlace permanente de comunicacion bidireccional V2I,
COOPERS ha estudiado las prestaciones de diversas tecnologıas de la comuni-
cacion, entre las que destacan: DAB, DVB-H, GSM / GPRS, CALM-IR, CALM-
M5 y WiMAX. La unidad embarcada en este proyecto consiste en una puerta de
comunicacion para las tecnologıas definidas y en un Automotive PC que incluye un
sistema robusto de posicionamiento, mientras que del lado de la infraestructura,
la unidad de carretera (RSU por sus siglas en ingles) combinara un controlador
con una puerta de comunicacion de corto alcance, ası como un centro de control
y una plataforma de gestion de sensores. En la figura 2.8 se puede apreciar una
imagen de uno de los vehıculos del proyecto, ası como la interfaz del vehıculo.
2.2.1.4 CyberCars
A principios de los anos 90 surge en Europa la primera idea sobre los Sistemas
de Transporte Cibernetico (CTS por sus siglas en ingles) para referirse a una
flota de vehıculos totalmente automatizados. Sin embargo, esta idea no se
15
2. ESTADO DEL ARTE
Figura 2.9: Vehıculo CyberCar.
implemento hasta el ano 1997 en el que una flota entera se coloco en marcha
en el aeopuerto de Schophol (Amsterdam, Holanda) [Parent 05]. Basados en la
idea de que a corto plazo circularıan por las ciudades y carreteras flotas enteras
de CTS, un grupo de investigacion del INRIA (Francia) ha desarrollado una serie
de proyectos denominados Cybercars, Cybercars-2 y CyberC3; en alusion a los
vehıculos biplaza de propulsion electrica que fueron disenados y ensamblados para
el desarrollo de dichos proyectos (ver figura 2.9).
El proyecto CYBERCARS-2, se oriento al estudio de la cooperacion basada
en comunicaciones de corto alcance entre vehıculos autonomos y vehıculos
operados por personas. Los resultados presentados para esta segunda version
del proyecto fueron de gran relevancia debido a que se desarrollo e implemento
una arquitectura de control de vehıculos autonomos que, mediante un sistema
de comunicaciones, eran capaces de implementar maniobras de cooperacion
entre tres vehıculos completamente automatizados [Naranjo 09]. Los vehıculos
utilizados fueron un CyberCar del INRIA, un smart de TNO (Holanda) y un
Citroen C3 Pluriel del Programa AUTOPIA.
La tercera, y hasta ahora ultima version de esta serie de proyectos, tenıa
como objetivo el analisis del desempeno de este tipo de vehıculos electricos
biplaza en zonas con alta densidad de trafico [Xia 10]. El sistema se valido
experimentalmente en ciudades asiaticas de alta densidad de poblacion, las cuales
presentan optimas condiciones para la inclusion de este tipo de vehıculos en el
mercado.
16
2.2 Proyectos de Investigacion
2.2.1.5 e-Safety
e-Safety es una iniciativa conjunta de la Comision Europea, la industria y otros
organismos con la finalidad de promover el desarrollo, despliegue y utilizacion
de sistemas inteligentes de seguridad en vehıculos. Estos sistemas utilizan
tecnologıas de la informacion y la comunicacion en soluciones inteligentes con el
fin de incrementar la seguridad y reducir el numero de accidentes en las carreteras
europeas.
eSafety es el pilar primordial de la Iniciativa para el Vehıculo Inteligente,
englobando diversos proyectos financiados por la Comunidad Europea - 38
proyectos del FP6 y 25 del FP7 - y realizando diversas actividades de investigacion
y desarrollo para alcanzar su objetivo principal: Reducir en un 50% el numero
de fallecidos para el fin del ano 2010.
2.2.1.6 Consorcio Car2Car
Car2Car es un cosorcio sin fines de lucro iniciado por los diversos fabricantes
europeos de vehıculos y apoyado por los proveedores de equipos y centros de
investigacion. El consorcio Car2Car se dedica principalmente al desarrollo de
sistemas de comunicacion intervehiculares para aplicaciones ITS que permitan
incrementar la seguridad y la eficiencia en las carreteras. Car2Car promueve
ademas la creacion de un estandar europeo con el fin de facilitar una futura
comunicacion V2V entre las diversas marcas, incluyendo la asignacion de una
banda de frecuencia exclusiva y gratuita para aplicaciones Car2Car en toda
Europa. Por esta razon el consorcio trabaja en cooperacion con las organizaciones
de estadarizacion europea e internacional, en particular con ETSI TC ITS.
2.2.1.7 PReVENT
PReVENT es un proyecto de la industria automotriz europea que esta
cofinanciado por la Comunidad Europea y tiene como objetivo la mejora de la
seguridad en la carretera mediante el desarrollo y demostracion de aplicaciones
y tecnologıas de seguridad preventiva. El uso de estas aplicaciones ayudara a los
conductores a evitar o reducir el impacto de un accidente. Gracias a diversos
sistemas intalados a bordo del vehıculo, sera posible determinar los posibles
riesgos presentes en el entorno para avisar de forma oportuna al conductor o
incluso, en casos de riesgo extremo, generar una accion directamente sobre el
vehıculo que contribuya a minimizar las consecuencias del accidente. Para ello
se integra un amplio rango de sensores (infrarrojos, giroscopos, acelerometros,
17
2. ESTADO DEL ARTE
Figura 2.10: Camion instrumentado para el proyecto INTERSAFE 2.
unidades de medicion inercial, camaras de video, radar, lidar, etc.) a partir de los
cuales es posible generar un entorno virtual del vehıculo, permitiendo determinar
por ejemplo la posicion y trayectoria de un peaton.
Al igual que los proyectos mencionados anteriormente, PReVENT considera
las comunicaciones V2V y V2I como un sensor adicional y necesario que permite
el envıo de informacion entre los vehıculos y la infraestructura para complementar
la informacion capturada por los sensores a bordo del vehıculo.
2.2.1.8 INTERSAFE 2
El proyecto INTERSAFE 2, que se encontraba en ejecucion hasta mayo del
2011, es la continuacion del subprograma INTERSAFE que se encontraba dentro
del proyecto PReVENT. El objetivo principal del proyecto consistıa en el desar-
rollo y demostracion de Sistemas Cooperativos de Seguridad para Intersecciones
(CISS por sus siglas en ingles) que permitieran reducir significativamente los ac-
cidentes que ocurren de manera frecuente en las intersecciones, llegando a generar
en algunos casos vıctimas mortales. La prueba final de este proyecto fue un esce-
nario de interseccion con 3 vehıculos (2 coches y 1 camion) en el que el sistema
de control fue capaz de gestionarlos para evitar un posible accidente, iniciando
siempre con una etapa de advertencia a los conductores pero tomando el control
de los mismos en los casos que se hacıa necesario. En la figura 2.10 se puede
apreciar el camion instrumentado para este proyecto.
18
2.2 Proyectos de Investigacion
2.2.2 Proyectos Americanos
2.2.2.1 DARPA
DARPA (Defense Advance Research Projects Agency) no es propiamente un
proyecto de investigacion sino una competicion de vehıculos autonomos. Sin
embargo, y debido a los grandes avances obtenidos a traves de la misma, merece
la pena ser citada.
Este programa de investigacion y desarrollo en vehıculos autonomos esta
orientado a su utilizacion en el campo militar para mantener a los soldados
fuera de peligro, evitando posibles amenazas. En esta competicion intervienen
vehıculos terrestres autonomos, maniobrando en un entorno que simula una
ciudad, realizando misiones de suministro militar mientras interacciona con el
trafico existente, evitando obstaculos e intersecciones peligrosas. La competicion
se divide en una serie de rondas clasificatorias que culminan con un evento final
cuya ultima edicion se ha desarrollado en Noviembre de 2007 en Victorville,
California. En esta edicion, el vehıculo BOSS, del equipo Tartan Racing (ver
seccion 2.1.2.3) resulto ganador luego de recorrer 85 km en algo mas de cuatro
horas.
Este programa es la continuacion de dos competiciones precedentes de
vehıculos autonomos denominadas DARPA Grand Challenge. La primera de ellas
tuvo lugar en marzo de 2004 y el objetivo era cubrir 230 kilometros de desierto.
Un total de cincuenta vehıculos formaron parte de esta primera edicion aunque
ninguno consiguio terminarla. En la edicion de 2005, cuatro vehıculos concluyeron
con exito la prueba, completando una ruta de 213 Km donde el vehıculo ganador
demoro un total de 10 horas en completarla.
2.2.2.2 Google Driverless Car
Google Driverless Car es un proyecto de la compania Google enfocado al
desarrollo de vehıculos sin conductor. El proyecto es liderado por el ingeniero
Sebastian Thrun, director del Laboratorio de Inteligencia Artificial Stanford y
co-inventor de Google Street View. Thrun ademas dirigio el equipo Stanford
Racing Team que en 2005 gano la competicion DARPA Grand Challenge con el
vehıculo Stanley. El proyecto cuenta con 15 ingenieros de Google, algunos de los
cuales han trabajado en el DARPA Challenge.
El proyecto cuenta con una flota de 7 vehıculos, formada por seis Toyota Prius
y un Audi TT ; cada uno de ellos equipado con un software de inteligencia artificial
que combina la informacion obtenida a partir de camaras de video, un sensor
19
2. ESTADO DEL ARTE
Figura 2.11: Vehıculo prototipo utilizado por Google.
LIDAR, radares y un sensor de posicion acoplado a una de la ruedas traseras con
la informacion obtenida desde Google Street View para determinar la ubicacion
del vehıculo en el mapa. En la figura 2.11 se puede apreciar uno de los vehıculos
equipados. Este sistema es capaz de conducir el vehıculo a la velocidad lımite de
la zona mientras mantiene la distancia adecuada con el resto de los vehıculos del
entorno, permitiendo en todo momento la intervencion humana en caso de falla
del mismo.
En el ano 2010, Google realizo diversos experimentos de su sistema en
las carreteras de Estados Unidos, donde el vehıculo circulo por entornos de
bastante trafico como el puente Golden Gate en San Francisco. Durante estos
experimentos, Google sumo 1.600 Km de conduccion totalmente autonoma,
ademas de 230.000 Km con alguna intervencion ocasional del conductor humano.
El unico inconveniente reportado ocurrio cuando uno de los vehıculos fue chocado
por otro vehıculo no autonomo al detenerse en un semaforo.
Google estima que su sistema ayudara a reducir el numero de accidentes de
trafico, reduciendo ası el numero de vıctimas mortales y lesionados, ayudando a
su vez a un manejo mas eficiente de la energıa y el espacio en las carreteras.
2.3 Programa AUTOPIA
El Programa AUTOPIA es uno de los principales grupos de investigacion
espanoles enfocado a la conduccion autonoma de vehıculos y dentro del cual
se desarrolla el trabajo presentado. Fue creado en el ano 1996 dentro del
departamento de informatica del antiguo Instituto de Automatica Industrial y
20
2.3 Programa AUTOPIA
actualmente pertenece al Centro de Automatica y Robotica de la Universidad
Politecnica de Madrid y el Consejo Superior de Investigaciones Cientıficas. Su
objetivo principal es la conduccion 100% autonoma de los vehıculos, ası como
el desarrollo de soluciones que permitan mejorar la seguridad en la conduccion,
principalmente en entornos urbanos y situaciones de alto riesgo.
Desde sus inicios, el Programa AUTOPIA ha enfocado sus estudios a la
transferencia de las tecnicas de inteligencia artificial desarrolladas por sus
investigadores para el control de robots autonomos al control de vehıculos,
evitando en la mayor medida posible la introduccion de modificaciones al entorno
en el que los vehıculos han de evolucionar. Estas tecnicas se basan en la aplicacion
de la logica borrosa al control de los vehıculos debido a que permiten emular con
mayor facilidad el razonamiento humano durante la conduccion.
Al dıa de hoy, el Programa AUTOPIA ha participado en una gran variedad
de proyectos, entre los cuales se pueden destacar los siguientes: ORBEX, ZOCO,
COVAN, GLOBO, CIBERCARS-2, MARTA, GUIADE y CITYELEC.
A continuacion se presenta una descripcion de los principales elementos del
programa AUTOPIA.
2.3.1 ORBEX
ORBEX es el acronimo utilizado para definir la base de la arquitectura de
control y navegacion de los vehıculos: el ORdenador Borroso EXperimental.
El ORBEX, desarrollado por el Programa AUTOPIA durante la ejecucion
del proyecto homonimo financiado por la CICYT, consiste en un motor de
inferencia de logica borrosa con un lenguaje de entrada muy sencillo basado en
el lenguaje natural. Esta caracterıstica permite al desarrollador implementar
diversas estrategias de control mediante la definicion de un conjunto de reglas
difusas del tipo SI... ENTONCES... [Garcıa 98; Garcıa 00]. Al igual que en
otras herramientas de control borroso, el razonamiento del ORBEX se ejecuta en
tres etapas: fuzificacion, inferencia y desfuzificacion.
• Fuzificacion: en esta primera etapa se transforma el valor numerico de
la variable de entrada en un valor liguistico que pueda ser procesado por
el ORBEX. Esta transformacion asigna un grado de pertenencia del valor
numerico a cada uno de los valores liguisticos de entrada. Las funciones
de pertenencia utilizadas para la fuzificacion de las variables son de forma
trapezoidal.
21
2. ESTADO DEL ARTE
• Inferencia: En esta etapa se detemina la contribucion de cada una de las
reglas definidas por el usuario a la salida correspondiente. El metodo de
inferencia utilizado por el ORBEX se corresponde al definido por Mamdani.
• Defuzificacion: Luego de haber completado el razonamiento, el ORBEX
determina en esta etapa los valores correspondientes de cada una de las
variables de salida. Las variables de salida borrosa son definidas como
singletons de Sugeno y el metodo definido para la defuzificacion es el del
centro de masas. Esto permite tomar las decisiones de control en un lapso
de tiempo muy pequeno, lo cual resulta ideal para sistema de tiempo real
como puede ser la conduccion automatica de un vehıculo.
Esta herramienta de control borroso ORBEX es utilizada por el Programa
AUTOPIA para el modelado y ejecucion en tiempo real de los controladores
borrosos que controlan a los vehıculos. Gracias a el es posible describir diferentes
formas de conduccion con el fin de emular el comportamiento de diferentes tipos
de conductores y adaptar la conduccion a la situacion actual del trafico. Para
definir un controlador borroso utilizando la herramienta ORBEX es necesario
especificar un fichero .orb con 3 secciones fundamentales:
Variables de entrada al sistema con sus respectivas funciones de pertenen-
cia. Esta seccion se inicia con una lınea que contiene la cadena Entradas:,
seguida de la definicion de cada una de las variables de entrada. La definicion
de las variables se realiza con el siguiente formato, donde A, B, C, D definen
un trapecio de una funcion de pertenencia:
Entrada1 { Etiqueta11 A11 B11 C11 D11 Etiqueta12 A12 B12 C12 D12 ... }
Entrada2 { Etiqueta21 A21 B21 C21 D21 Etiqueta22 A22 B22 C22 D22 ... }
Variables de salida del sistema con sus respectivas particiones o singletons.
Esta seccion se inicia con una lınea que contiene la cadena Salidas:, seguida
de la definicion de cada una de las variables de salida. La definicion de
las variables se realiza de forma similar a las variables de entradas, con
la excepcion de que en este caso se utiliza un unico valor para definir la
posicion del Singleton:
Salida1 { Valor11 A11 Valor12 A12 ... }
Salida2 { Valor21 A21 Valor22 A22 ... }
22
2.3 Programa AUTOPIA
Un conjunto de reglas de inferencia que operan sobre las variables de en-
trada y salida de forma tal que a las variables de salida les sea asignado un
valor. Esta seccion tiene la particularidad de que permite escribir e iden-
tificar varios juegos excluyentes de reglas denominados contextos. Cada
contexto debe iniciarse con la palabra Reglas seguida del nombre del con-
texto. Para describir las reglas, ORBEX permite el uso de una sintaxis
que le hace muy potente y flexible en la definicion de reglas o en el uso de
modificadores, aunque principalmente se utilizan las reglas del tipo:
SI Entradax Etiquetaxa Y Entraday Etiquetayb ENTONCES Salidaz Valorzc
Un ejemplo de archivo .orb para definir un controlador en ORBEX podrıa el
siguiente:
Entradas:
Entrada1 { Bajo 0 0 0 5 Medio 0 5 10 15 Alto 10 15 30 40 }
Entrada2 { Negativa -10 -10 -1 0 Cero -1 0 0 1 Positiva 0 1 10 10 }
Salidas:
Salida1 { Nula 0 Pequena 1 Mediana 5 Grande 12 }
Reglas Contexto1
SI Entrada1 Bajo Y Entrada2 Negativa ENTONCES Salida1 Nula
SI Entrada2 Cero ENTONCES Salida1 Pequena
SI Entrada1 Medio ENTONCES Salida1 Mediana
SI Entrada2 Positiva O Entrada1 Alto ENTONCES Salida1 Grande
2.3.2 Vehıculos
Al dıa de hoy, el programa AUTOPIA cuenta con una flota de 5 vehıculos, los
cuales se describen a continuacion.
Dos furgonetas Citroen Berlingo de propulsion electrica que fueron adquiridas
durante la ejecucion de los proyectos COVAN y GLOBO; ambos financiados por
la CICYT. Estos vehıculos, denominados Babieca y Rocinante (ver figura 2.12,
cuentan con un motor electrico de 15KW que les permite alcanzar velocidades de
hasta 90 Km/h y son los primeros modelos automatizados, en su totalidad, por
el Programa AUTOPIA [Alcalde 00].
El Programa posee ademas dos vehıculos Citroen C3 con motor a gasolina. El
primero de ellos, denominado Clavileno (ver figura 2.13), es un modelo Pluriel
(descapotable) que ha sido totalmente automatizado como una evolucion de los
23
2. ESTADO DEL ARTE
Figura 2.12: Furgonetas electricas Babieca y Rocinante.
Figura 2.13: Vehıculo Clavileno.
primeros 2 vehıculos. Clavileno, ademas de contribuir a la investigacion dentro del
Programa AUTOPIA, ha servido como banco de pruebas para algunos sistemas de
control y prevencion desarrollados por otros grupos de investigacion. El segundo
coche, denominado Platero, es el vehıculo utilizado para el desarrollo de este
trabajo (ver figura 2.14). En una fase previa a este trabajo, el autor incorporo
a Platero un equipo DGPS y un ordenador portatil con el fin de habilitarlo
como vehıculo de apoyo para las pruebas de maniobras cooperativas desarrolladas
por otros integrantes del programa [Godoy 07; Milanes 10a]. Sin embargo, estas
modificaciones solo le permitıan dar a conocer su posicion y velocidad al resto
de los vehıculos del entorno con baja precision. A lo largo de este trabajo se
presentaran las modificaciones incorporadas para su automatizacion.
Por ultimo, el Programa AUTOPIA ha adquirido recientemente un minibus
electrico fabricado por la empresa espanola ConMasAuto con la finalidad de
extrapolar las tecnicas de conduccion autonoma a los servicios de transporte
publico. Este vehıculo, denominado Molinero (ver figura 2.15 se encuentra
actualmente en la primera fase de automatizacion.
24
2.3 Programa AUTOPIA
Figura 2.14: Vehıculo Platero.
Figura 2.15: Imagen de Molinero.
25
2. ESTADO DEL ARTE
Figura 2.16: Vista aerea de la Zona de Conduccion. Trazado original (arriba) ytrazado actual (abajo).
2.3.3 Zona de Conduccion
El Programa AUTOPIA dispone de una pista de pruebas dedicada exclusi-
vamente a tareas de investigacion, ya que por razones obvias de seguridad en
ella no existe ningun otro tipo de trafico de vehıculos. Esta pista de pruebas fue
construıda durante la ejecucion del proyecto ZOCO (ZOna de COnduccion) finan-
ciado por la CICYT. Tiene una forma reticulada, como las manzanas o cuadras de
una ciudad, con algunas irregularidades menores. Las calles poseen una anchura
de 6 metros, lo que permite la circulacion en ambos sentidos.
Durante los anos 2009 y 2010 se realizaron algunas modificaciones al diseno
original, con la finalidad de lograr un conjunto mas amplio de curvas y crear ası
un entorno mas urbano. Para ello se anadio una pequena rotonda en uno de los
cuadrantes de la pista, semaforos en el cruce central, y curvas adicionales en la
recta principal. En la figura 2.16 se puede apreciar una vista aerea comparativa
del plano original del ZOCO y su situacion actual.
Las calles del diseno original del ZOCO fueron nombradas para ası poder definir
los recorridos. Las calles horizontales tienen nombres de personajes dedicados a la
automatizacion mientras que las verticales estan dedicadas a antıguos cientıficos
y personajes que disenaron y crearon instrumentos de navegacion.
26
2.3 Programa AUTOPIA
Figura 2.17: Plano esquematico de la Zona de Conduccion.
Punto Latitud Norte (m) Latitud Este (m)
Puerta del Sol 4462550.89 459059.8Cruce (Zadeh - Mercator) 4462556.52 458953.91Cruce (Zadeh - Enrique) 4462561.23 458882.06
Plaza Sugeno 4462564.74 458808.31Cruce (Azarquiel - Quevedo) 4462499.55 459056.88Cruce (Quevedo - Mercator) 4462510.23 458953.13Cruce (Quevedo - Enrique) 4462517.51 458877.4Cruce (Mercator - Juanelo) 4462459.75 458951.86Cruce (Enrique - Juanelo) 4462479.49 458873.76
Tabla 2.1: Coordenadas UTM de la Zona de Conduccion.
En la figura 2.17 pueden apreciarse los nombres de cada una de las calles.
Esta denominacion de las calles permite especificar los recorridos que han de
hacer los coches de manera simbolica, de tal forma que sean transformados por
un interprete virtual en un conjunto de maniobras elementales a partir del plano
digital del ZOCO. La tabla 2.1 muestra las coordenadas de cada una de las calles
originales del ZOCO.
Durante las ultimas modificaciones realizadas al circuito, se anadio tambien
una estacion base de posicionamiento GPS para la transmision de correcciones
diferenciales de la red de satelites GPS y GLONNASS. Esta informacion le per-
mite a los sistemas de posicionamiento embarcados en los vehıculos obtener su
posicion con una precision inferior al centımetro. Adicionalmente, esta estacion
base actua como estacion central de comunicaciones y control, actuando como
nodo central en algunos experimentos de comunicaciones Vehıculo-Infraestructura.
En la figura 2.18 se puede apreciar una imagen de la estacion de control.
27
2. ESTADO DEL ARTE
Figura 2.18: Imagen de la estacion de control y antena de comunicaciones.
28
Capıtulo 3
Platero y su instrumentacion
A lo largo de este capıtulo se presentara la descripcion detallada de la ar-
quitectura de control que ha sido implantada en Platero durante el desarollo de
este trabajo, incluyendo cada uno de los sensores y sistemas de actuacion incor-
porados para su entera automatizacion. El trabajo realizado se presenta como
una evolucion de los primeros sistemas implementados en los vehıculos Babieca
y Rocinante [Naranjo 05], ası como de aquellos incorporados posteriormente en
Clavileno [Milanes 10a].
3.1 El vehıculo
Platero es un modelo C3 de serie de la casa Citroen adquirido por el Programa
AUTOPIA en el ano 2003. El vehıculo es propulsado por un motor a gasolina
y cuenta con una caja de cambios robotizada. Esta ultima caracterıstica ha
sido fundamental durante el proceso de seleccion del vehıculo prototipo ya
que simplifica notablemente el proceso de automatizacion al no requerir la
implementacion de actuadores especiales para el control de la palanca de cambios
y/o el embrague.
A pesar de formar parte del programa durante varios anos, la unica instru-
mentacion realizada previamente al vehıculo ha sido la instalacion temporal de
un equipo DGPS y un ordenador portatil (ver figura 3.1) con la finalidad de ha-
bilitarlo como vehıculo de apoyo para los diversos experimentos realizados con la
flota automatizada [Godoy 07]. Por esta razon, la intrumentacion que se describe
en las secciones siguientes parte de la idea de que ninguna modificacion ha sido
realizada previamente en el vehıculo.
29
3. PLATERO Y SU INSTRUMENTACION
Figura 3.1: Modificaciones previas realizadas al vehıculo.
3.2 Ordenador a Bordo
La arquitectura de control del Programa AUTOPIA esta basada en la idea de
que cada vehıculo, automatizado o solo sensorizado, cuenta con un ordenador a
bordo. Esta unidad es la encargada de recolectar toda la informacion proveniente
de los sensores embarcados, gestionar los enlaces de comunicacion y, en el caso
de los vehıculos automatizados, ejecutar los distintos programas de control.
Durante la automatizacion de los primeros vehıculos del programa se utilizaron
ordenadores convencionales de escritorio [Perez 09]; sin embargo, posteriormente
se determino que estos equipos resultaban muy susceptibles a sufrir danos en
el disco duro debido a las vibraciones presentes en el vehıculo cuando este se
encuentra en marcha. Partiendo de este hecho, se ha seleccionado un ordenador
con un disco duro de tecnologıa de estado solido para la automatizacion de
Platero.
El ordenador seleccionado se corresponde con el modelo AEC6915 del fabri-
cante AAEON. Esta unidad cuenta con un procesador Intel Pentium M, 1 Gb
de memoria RAM y un disco duro de 40 Gb de capacidad. Adicionalmente, este
modelo cuenta con 1 puerto VGA, 1 puerto Ethernet, 4 puertos PCI para la
conexion de otros perifericos y Microsoft Windows XP como sistema operativo.
Por motivos de espacio en el interior del vehıculo se ha decidido instalar el orde-
nador en el maletero del mismo. La figura 3.2 muestra una imagen de la unidad
30
3.3 Sensores Embarcados
Figura 3.2: Arriba: Ordenador embarcado en el vehıculo. Abajo: Teclado yPantalla del ordenador.
ya instalada.
Para comodidad del usuario se ha colocado una pantalla LCD en la parte
frontal del coche, especıficamente en el parabrisas frente al asiento del copiloto,
ası como un teclado inalambrico con raton incorporado que evita los problemas
de conexion y movilidad de los perifericos en el interior del coche. En la figura
3.2 se puede apreciar una imagen de ambos componentes.
La alimentacion del ordenador, ası como la de algunos de los sistemas descritos
en las secciones siguientes, se realiza mediante un Punto General de Alimentacion
(PGA), el cual es gestionado directamente por el conductor a traves de un
interruptor instalado en el tablero del coche.
3.3 Sensores Embarcados
3.3.1 GPS
La unidad GPS es el sensor mas importante para la arquitectura de control
del Programa AUTOPIA, ya que a partir de el se determina la posicion del
vehıculo sobre los mapas digitales. Debido a que el desempeno de la conduccion
automatica depende de la precision de esta medida, AUTOPIA utiliza equipos
GPS con capacidad de funcionamiento en modo diferencial, bien sea a traves
31
3. PLATERO Y SU INSTRUMENTACION
Alimentacion 9 - 28 VdcFrecuencias de operacion L1, L2, L2C, L5 GPS
Puertos de salida 2 Serie y 1 EthernetInterfaz de configuracion Web o comandos binarios
Frecuencia de actualizacion 5, 10 o 20 HzSalidas adicionales Senal de 1PPS
Tabla 3.1: Caracterısticas del equipo BD960
Figura 3.3: Imagen del DGPS Modelo BD960.
de los sistemas de mejora WAAS (Wide Area Augmentation System) y EGNOS
(European Geostationary Navigation Overlay System) o bien mediante estaciones
de referencia locales (Real Time Kinematics - RTK ).
Para la instrumentacion de Platero se ha elegido equipo GPS modelo BD960
del fabricante Trimble (ver figura 3.3). En la tabla 3.1 se muestran las
caracterısticas de este equipo, siendo las de mayor peso en el momento de la
eleccion la cantidad de puertos de salida independientes y su frecuencia maxima
de muestreo. Al igual que el ordenador a bordo, la unidad GPS ha sido instalada
en el maletero del coche y se alimenta directamente desde el PGA. La antena
GPS se ha ubicado en la parte central del vehıculo a la altura del eje trasero del
mismo.
El GPS se ha configurado para emitir a traves del puerto serie 1 las tramas
GGA y VTG del protocolo NMEA (National Marine Electronics Association) a
una frecuencia de 5 o 10Hz seleccionada por el usuario. En las tablas 3.2 y 3.3
se puede apreciar la informacion contenida en cada uno de estos mensajes, donde
cada campo se encuentra separado del siguiente por comas.
Tal como se describe en [Godoy 10], el Programa AUTOPIA cuenta con su
32
3.3 Sensores Embarcados
Campo Contenido
0 ID Mensaje = $GPGGA1 Tiempo UTC de la adquisicion de los datos
2 y 3 Latitud y su direccion: GGMM.mmmm,DGG: GradosMM.mmmm: Minutos y diezmilesima de minutosD: N = Norte & S = Sur
4 y 5 Longitud y su direccion: GGMM.mmmm,DGG: GradosMM.mmmm: Minutos y diezmilesima de minutosD: E = Este & W = Oeste
6 Calidad o Tipo del GPS0 = No hay satelites suficientes1 = Datos GPS2 = Datos DGPS4 = Datos RTK, Fixed5 = Datos RTK, Float
7 Numero de satelites a la vista8 Precision Relativa
9 y 10 Altura sobre el nivel del mar y sus unidades11 y 12 Altura sobre la elipsoide y sus unidades
13 Tiempo desde la ultima actualizacion DGPS14 ID de la estacion DGPS de referencia15 Checksum
Tabla 3.2: Contenido del mensaje GGA del protocolo NMEA
Campo Contenido
0 ID Mensaje = $GPVTG
1 y 2 Angulo respecto al norte en grados.3 y 4 No utilizados5 y 6 Velocidad en Nudos:0.00,N7 y 8 Velocidad en Km/h: 0.00,K9 Checksum
Tabla 3.3: Contenido del mensaje VTG del protocolo NMEA
33
3. PLATERO Y SU INSTRUMENTACION
Figura 3.4: Programas de correccion diferencial utilizados. Izquierda: Versioncon comunicacion serial. Derecha: nueva version con conexion TCP
propia estacion de correccion RTK dentro de las instalaciones del ZOCO. La
transmision de los datos de correccion desde la estacion base a los vehıculos
se realiza a traves de la red de comunicaciones inalambricas, empleando para
ello un programa auxiliar en el ordenador a bordo que redirige posteriormente
la informacion al GPS. A diferencia de los vehıculos anteriores del Programa,
el envıo de los datos de correccion diferencial al GPS se realiza a traves de la
conexion Ethernet empleando un puerto TCP (5008). Se ha decidido implementar
configuracion con la finalidad de dejar libre el segundo puerto serie del equipo
para futuras integraciones con otros sensores. Para ello, se ha creado una nueva
version del programa de correccion diferencial. La interfaz de ambas versiones se
puede apreciar en la figura 3.4.
3.3.2 BUS CAN
Como todos los vehıculos modernos, Platero dispone de un bus CAN que
interconecta todos los sistemas y modulos embarcados: ABS, EPS, direccion
asistida, etc. A traves de este bus, cada sistema envıa diversos mensajes con
informacion relevante para el resto de los modulos, como puede ser la velocidad
de cada una de las ruedas del vehıculo, las revoluciones del motor, el estado del
ABS, la posicion y velocidad del volante, entre otros.
Al disponer de tanta informacion dentro de la red del vehıculo, es innecesario
anadir nuevos sensores para la medicion de variables que ya han sido determinadas
por los propios sensores del vehıculo. Por esta razon se incorporo al ordenador
principal un adaptador USB-to-CAN (ver figura 3.5) de la empresa Lawicel el
cual le permite recibir todos los mensajes que circulan a traves de este bus. Las
principales caracterısticas de este adaptador se listan a continuacion:
• Pequeno tamano: 36 mm de ancho, 16 mm de altura y 55 mm de longitud.
• Capacidad de operar con el protocolo CAN 2.0A (ID 11 Bits) y CAN 2.0B
34
3.3 Sensores Embarcados
Figura 3.5: Adaptador USB-to-CAN incorporado al ordenador a bordo.
(ID 29 Bits).
• Velocidad maxima de 1Mbit/s.
• Buffer FIFO interno de 32 tramas.
• Controlador ActiveX que permite su integracion a distintos compiladores
(Borland C++, Visual Basic, etc).
Los valores que circulan a traves del bus CAN son actualizados a una frecuencia
de 25 Hz. Esta frecuencia de actualizacion es mayor que la frecuencia de control
empleada normalmente por AUTOPIA (5 o 10 Hz), por lo que la informacion
recibida puede ser perfectamente utilizada por el programa de control automatico
del vehıculo. Los datos extraıdos por el programa son: la velocidad media del
vehıculo, velocidad de cada una de las ruedas, posicion del volante y velocidad
de giro del volante.
3.3.3 Tarjeta WiFi
Desde el punto de vista de la arquitectura de control del Programa AUTOPIA,
las comunicaciones V2V y V2I representan un sensor adicional que incrementa el
entorno percibido por el vehıculo. Por esta razon se lista como sensor embarcado
todo el hardware utilizado para las comunicaciones inalambricas.
A fin de maximizar la compatibilidad entre toda la flota de vehıculos y par-
tiendo del hecho de que los resultados obtenidos previamente son practicamente
optimos, se decidio implementar en Platero el mismo hardware de comunicaciones
utilizado en los modelos anteriores. El conjuto esta formado por una tarjeta WiFi
PCMCIA, un amplificador de medio vatio y una antena omnidireccional. Adi-
cionalmente, fue necesario instalar un adaptador PCI-PCMCIA en el ordenador
a bordo debido a que el mismo no contaba con un puerto PCMCIA.
35
3. PLATERO Y SU INSTRUMENTACION
Figura 3.6: Esquema de la comunicacion WiFi.
La tarjeta WiFi utilizada se corresponde con el modelo GOLD del fabricante
Orinoco. Esta tarjeta puede funcionar bajo las especificaciones b y g de la norma
IEEE 802.11. Ademas de contar con una antena interna, este modelo permite
tambien el uso de antenas externas mediante un conector MC-Card.
Para la instalacion final del sistema, la antena externa se ha colocado en el
centro geometrico del techo del vehıculo. Una pequena base eleva la antena unos
12 centımetros sobre el techo a fin de evitar posibles atenuaciones en la senal
provocadas por la proximidad al mismo. Por otra parte, el amplificador RF se
ha instalado en paralelo al ordenador, entre la salida de la tarjeta PCMCIA y la
antena externa. Como los otros equipos, su alimentacion se toma directamente
del PGA. En la figura 3.6 puede apreciarse una imagen de todos los componentes
instalados en el vehıculo.
3.4 Actuadores
3.4.1 Acelerador
Al igual que su predecesor Clavileno, Platero dispone de un pedal acelerador
electronico, por lo que la automatizacion de este componente ha resultado
36
3.4 Actuadores
Figura 3.7: Esquema general de la automatizacion del acelerador.
bastante sencilla. Bajo condiciones normales de conduccion, el pedal electronico
transmite la presion que ejerce el conductor sobre el acelerador como una
senal analogica entre 0 y 5 voltios. Por motivos de seguridad y deteccion de
fallos, el pedal transmite ademas una senal secundaria equivalente al 50% de
la senal original, permitiendo al calculador del vehıculo comprobar el correcto
funcionamiento de este componente.
A fin de emular el comportamiento del pedal electronico desde el ordenador
a bordo, se ha instalado en este ultimo una tarjeta de salidas analogicas, de
tal forma que ambas senales puedan ser controladas desde el programa de
control automatico. La tarjeta utilizada se corresponde con el modelo PCI-1723
fabricado por Advantech. La tarjeta cuenta con 8 canales analogicos, cada uno
de ellos con una resolucion de 16 bits para salidas de entre -10 y 10 voltios,
permitiendo una intensidad maxima de salida de 5mA por canal. Adicionalmente,
la tarjeta cuenta con 16 canales digitales que pueden actuar como entradas o
salidas segun la configuracion seleccionada por el usuario. Como lo indica su
cabera de modelo, esta tarjeta se conecta al ordenador a traves de un puerto
PCI.
A pesar de que existıa la posibilidad de utilizar un solo canal para generar
la senal principal de aceleracion y un divisor de tension para la secundaria, se
ha decidido finalmente implementar dos canales independientes con el objetivo
de utilizar el mismo sistema de seguridad del calculador para detectar cualquier
posible fallo de la tarjeta analogica. La conmutacion entre el sistema automatico
y manual se efectua mediante un interruptor DPDT (Double Pole, Double Throw)
ubicado en el tablero del vehıculo. En la figura 3.7 se puede apreciar un esquema
general del sistema implementado.
37
3. PLATERO Y SU INSTRUMENTACION
3.4.2 Sistema de frenado electro-hidraulico
Una de las principales aportaciones realizadas por [Milanes 10a] a la arqui-
tectura de control del Programa AUTOPIA ha sido el sistema de frenado elec-
trohidraulico. En las furgonetas Babieca y Rocinante el sistema de frenado au-
tomatico consistıa basicamente en el control de posicion de un motor DC que, me-
diante un sistema de cables y poleas, controlaba la posicion del pedal [Naranjo 05].
Este sistema, aunque simple y funcional, no es muy fiable debido a que trae con-
sigo complicaciones relacionadas con el tiempo de respuesta del motor para la
actuacion sobre el pedal, lo cual resulta crıtico para algunas maniobras de con-
duccion. Partiendo de este hecho, y de la similitud que existe entre Clavileno y
Platero, se opto por instalar en este ultimo el sistema disenado por [Milanes 10a]
para la automatizacion del freno. La idea basica de este diseno consiste en anadir
al circuito hidraulico principal un circuito electrohidraulico secundario que es
controlado directamente desde el ordenador a bordo.
En el sistema implementado la fuerza hidraulica es generada por una bomba
propulsada por un motor electrico de 12 voltios y 350 vatios de potencia.
Esta bomba cuenta con un deposito acoplado de 1 litro de capacidad para el
almacenamiento del lıquido de frenos. La presion ejercida sobre los discos de
freno es controlada mediante un sencillo sistema de 3 valvulas. La primera
de ellas es una valvula limitadora que regula a 60 bares la presion maxima de
salida del sistema, evitando posibles danos en los componentes mecanicos del
sistema de frenado del vehıculo por exceso de presion, especıficamente sobre los
discos de freno. Este valor ha sido determinado experimentalmente colocando un
manometro en la zapata de freno mientras que un conductor humano pisaba a
fondo el pedal de freno. La segunda valvula es electro-proporcional. Esta valvula
permite controlar su presion de salida en un rango de 12 a 250 bares mediante
una tension de entrada de entre 0 y 10 voltios. La tercera valvula es una todo
o nada que al ser activada permite la circulacion del lıquido de freno desde la
bomba hasta las zapatas. Esta valvula se hace necesaria debido a que la mınima
presion de la valvula electro-proporcional es superior a 0 bares. Por ultimo, un
manometro colocado a la salida del circuito permite conocer en todo momento la
presion aplicada.
Como es habitual en los vehıculos comerciales, el sistema de frenado original
de Platero cuenta con dos circuitos independientes. Por esta razon fue necesario
instalar ademas 2 valvulas selectoras para conmutar automaticamente entre el
sistema original y el sistema electrohidraulico. Cada valvula selectora permite la
circulacion del lıquido desde dos puertos de entrada a uno de salida. Una pequena
38
3.4 Actuadores
Figura 3.8: Esquema general del sistema de frenado implementado en Platero.
bola de metal que flota libremente entre ambas entradas se encarga de permitir
el paso del lıquido desde la entrada de mayor presion a la salida. Las salidas de
ambas valvulas se han conectado a la entrada del modulo ABS, evitando ası la
perdida de funcionalidad de este modulo de seguridad durante el modo de frenado
automatico.
Un interruptor colocado en el tablero del vehıculo permite activar o desactivar
el sistema de frenado automatico. Cuando el conductor activa el interruptor,
conmuta a su vez un rele que activa el motor de corriente contınua. Mientras que
el freno automatico no se esta utilizando, la valvula todo o nada redirige el lıquido
de frenos de vuelta al deposito. Cuando se activa el frenado, la valvula todo o
nada se cierra, permitiendo la circulacion del lıquido hacia el circuito original y
por lo tanto hacia las zapatas. A partir de ese momento es posible controlar la
presion de frenado con la valvula electroproporcional.
Tanto el control de la valvula electro-proporcional como el de la valvula todo o
nada se realiza a traves de un modulo CAN compuesto de un rele de 6 amperios
y una salida analogica. Este modulo es controlado desde el ordenador mediante
un adapatador USB-to-CAN como el descrito en la seccion 3.3.2. En las figuras
3.8 y 3.9 se puede apreciar respectivamente un esquema general y una fotografıa
del sistema instalado en el vehıculo.
39
3. PLATERO Y SU INSTRUMENTACION
Figura 3.9: Fotografıa del sistema de frenado electro-hidraulico instalado enPlatero.
40
3.4 Actuadores
0 1 2 3 4 5 60
5
10
15
20
25
30
35
40
Vel
ocid
ad [K
m/h
]
0 1 2 3 4 5 6
0
0.2
0.4
0.6
0.8
1
Ban
dera
AB
S
Tiempo [s]
1 V1.5 V2 V3 V
1 V1.5 V2 V3 V
Figura 3.10: Pruebas de frenado sobre asfalto: Evolucion de la velocidad delvehıculo (arriba). Indicador ABS (abajo).
3.4.2.1 Validacion del sistema de frenado
Con la finalidad de evaluar el desempeno del sistema electro-hidraulico
instalado se realizaron varias pruebas de frenado sobre dos superficies de distinta
adherencia. En cada prueba, el vehıculo fue acelerado hasta alcanzar una
velocidad de 40 km/h, para posteriormente aplicar una presion de frenada
constante a traves del software de control. En todas las pruebas la velocidad del
vehıculo se determino a partir del equipo GPS a fin de evitar que el deslizamiento
o bloqueo de las ruedas alterara la medicion.
En la figura 3.10 se muestran los resultados obtenidos en las pruebas realizadas
sobre asfalto convencional. La grafica superior presenta los distintos perfiles de
deceleracion obtenidos para 4 valores de voltaje aplicados sobre la valvula electro-
proporcional: 1, 1.5, 2 y 3 voltios; mientras que la grafica inferior muestra el
estado del indicador de activacion/desactivacion del sistema ABS del vehıculo.
Los perfiles obtenidos para 1, 1.5 y 2 voltios validan la relacion proporcional
que existe entre el voltaje aplicado y la deceleracion del vehıculo, ası como el
correcto funcionamiento del sistema. En cuanto al perfil obtenido con la salida
de 3 voltios, se puede apreciar una gran semejanza con el perfil de 2 voltios. Esto
se debe a que en este caso el sistema ABS se ha activado, regulando la presion
final aplicada y evitando una frenada brusca del vehıculo. Este ultimo valor se
establecio como el lımite maximo para la salida del sistema de control a la valvula
electro-proporcional.
De forma analoga a la figura 3.10, la figura 3.11 presenta los resultados
41
3. PLATERO Y SU INSTRUMENTACION
0 1 2 3 4 5 6 7 80
5
10
15
20
25
30
35
40
Vel
ocid
ad [K
m/h
]
0 1 2 3 4 5 6 7 8
0
0.2
0.4
0.6
0.8
1
Ban
dera
AB
S
Tiempo [s]
1 V1.5 V2 V
1 V1.5 V2 V
Figura 3.11: Pruebas de frenado sobre superficie deslizante: Evolucion de lavelocidad del vehıculo (arriba). Indicador ABS (abajo).
obtenidos sobre una superficie de muy baja adherencia. Este experimento fue
llevado a cabo en las instalaciones del Instituto de Tecnica Aeroespacial (INTA),
donde una superficie compuesta de paneles de vidrio humedecidos emula la
adherencia de un camino cubierto de nieve. En la grafica inferior se puede apreciar
que el sistema ABS se activo en cada una de las pruebas realizadas. Esto explica
la similitud que existe entre los perfiles de deceleracion correspondientes a valores
distintos de voltaje de control, ya que en cada caso fue el sistema ABS quien regulo
la frenada del vehıculo.
Los resultados obtenidos sobre ambas superficies validan el funcionamiento
del sistema de frenado implementado. De igual forma, se ha demostrado que la
inclusion de este sistema en paralelo con el sistema original del vehıculo no afecta
el funcionamiento del sistema ABS.
3.4.3 Volante
El sistema que ha resultado mas complicado al momento de realizar la
automatizacion del vehıculo ha sido el control de la direccion, ya que normalmente
no existe mucho espacio disponible donde se puedan anadir sistemas paralelos
de actuacion y control sin alterar considerablemente el sistema de conduccion
utilizado por un conductor humano.
En los dos primeros vehıculos del Programa – Babieca y Rocinante – el
sistema de actuacion del volante esta compuesto por un motor DC que, mediante
una determinada combinacion de engranajes, actua directamente sobre la barra
42
3.4 Actuadores
de direccion del vehıculo [Perez 10; Naranjo 05]. Una palanca al alcance del
conductor permite acoplar y desacoplar el sistema a la barra de direccion,
de forma tal que el conductor humano no perciba la carga extra durante la
conduccion convencional. Este sistema, aunque eficiente, presenta un tiempo de
respuesta lento ya que el espacio disponible ha limitado el tamano de los motores
utilizados y con ello la potencia de los mismos.
En el caso de Clavileno se realizo una modificacion a la Direccion Asistida
Electrica (DAE) para la automatizacion del volante. La DAE esta disenada
de forma tal que, bajo condiciones normales de conduccion, un sensor de par
acoplado a la barra de direccion del volante le indica a la Unidad Electronica
Central (ECU por sus siglas en ingles) de la DAE la fuerza que esta ejerciendo
el conductor sobre el volante. Basada en esta medicion, la ECU colabora con
el conductor actuando sobre la direccion mediante un motor electrico que se
encuentra acoplado a la misma, reduciendo ası el esfuerzo del conductor para el
giro del volante. Para la intervencion de este sistema se incorporo al vehıculo una
etapa de potencia especialmente disenada por el Programa, la cual transforma una
salida analogica del ordenador en un tren de pulsos que mueve el motor. Una
etapa de conmutacion, controlada por el conductor desde el tablero del coche,
permite intercambiar las conexiones del motor entre la DAE – modo manual – y
la etapa de potencia – modo automatico.
A partir de los resultados obtenidos con cada unos de los sistemas implemen-
tados anteriormente para el control de la direccion se considero que el esquema de
control mas adecuado para Platero serıa uno similar al de Clavileno; es decir, uti-
lizando directamente el motor de la direccion asistida como actuador del sistema.
La direccion asistida de Platero, al igual que la del resto de C3 comerciales, es
un diseno exclusivo de la empresa Koyo para Citroen. Debido a la exclusividad
de este diseno resulto imposible obtener informacion tecnica detallada sobre el
funcionamiento de este sistema. Solo se logro conocer que el motor acoplado a
la direccion, tambien de la empresa Koyo, es un motor DC de 12 voltios y una
intensidad maxima de 60 amperios que permite realizar la asistencia al conductor
de forma instantanea. Estas caracterısticas – alta intensidad con bajo voltaje –
dificultaron la busqueda de un controlador adecuado. Por otra parte se considero
que, al ser un diseno exclusivo, la mejor solucion para el control del motor serıa
intervenir directamente la ECU de la DAE, emulando la senal del sensor de par.
La intervencion de esta senal resulto relativamente sencilla, pero a la vez com-
plicada debido a la carencia de documentacion tecnica adecuada. Experimental-
mente fue posible determinar que el sensor de par transmite de forma redundante
43
3. PLATERO Y SU INSTRUMENTACION
una senal de entre 1,5 y 3,5 voltios para indicar el torque que ejerce el conduc-
tor sobre el volante; siendo 2,5 voltios el valor para indicar un torque nulo. A
traves de la tarjeta analogica instalada en el ordenador a bordo para el control
del acelerador (ver seccion 3.4.1) se emulo el comportamiento de esta senal y fue
posible controlar el movimiento del volante entre ambos extremos utilizando los
valores maximos de torque (valores de entrada de 1,5 o 3,5 voltios). Sin embargo,
para niveles bajos de entrada (senales entre 1,8 y 2,2 voltios o 2,7 y 3,1 voltios)
el sistema describıa un comportamiento bastante irregular, ocasionando la propia
desactivacion del sistema por parte de la ECU como medida de seguridad. Por
otra parte, se determino que la asistencia sobre la direccion es inversamente pro-
porcional a la velocidad del vehıculo, por lo que a altas velocidades es imposible
emplear la ECU como controlador del motor. Esta variacion de la asistencia en
funcion de la velocidad del vehıculo, sumada a la imposibilidad de controlar la
velocidad de giro del motor con bajos valores de entrada, hizo que se descartara
finalmente este esquema de control como posible solucion.
Luego de este intento fallido, se decidio incorporar – como se hizo anteriormente
en Clavileno – un controlador externo para el control del motor acoplado a la
direccion. Sin embargo como se menciono anteriormente, las caracterısticas del
motor dificultaron la busqueda de un controlador adecuado, ya que la mayorıa
de los fabricantes reconocidos (como Faulhaber y MaxonMotor entre otros) solo
ofrecen soluciones de 24 y 36 voltios con baja capacidad de corriente (de 2 a
10 amperios). Finalmente, la busqueda guio al modelo MDL-BDC24 de Texas
Instruments, un producto de bajo coste disenado especialmente para la FIRST
Robotics Competition y conocido como Black Jaguar.
El MDL-BDC24 (figura 3.12) tiene la capacidad de funcionar con motores de
12 o 24 voltios, manejando corrientes continuas de hasta 40 amperios y soportando
picos de 60 amperios durante un maximo de dos segundos. La senal PWM
para el control de motor tiene una frecuencia de 15KHz y es regulada por un
microcontrolador de 32 bits. El Black Jaguar cuenta ademas con dos interfaces
de comunicacion – RS-232 y bus CAN – ası como de entradas para un encoder
en cuadratura y un encoder analogico. Este dispositivo permite al usuario 4
modos de funcionamiento: control de voltaje a lazo abierto y control de corriente,
posicion o velocidad a lazo cerrado. Como sistema de seguridad, este controlador
debe debe recibir un mensaje de heartbeat a traves de alguno de sus puertos al
menos cada 100 milisegundos o en caso contrario desactiva su funcionamiento.
Como primera opcion para la implementacion del control a traves del Black
Jaguar se penso en utilizar el control de posicion a lazo cerrado. Para ello, la
44
3.4 Actuadores
Figura 3.12: Imagen del controlador MDL-BDC24.
posicion del volante – medida por el ordenador a bordo desde el bus CAN – se
transmitıa al controlador como una senal analogica de 0 a 3 voltios a traves de
un canal de la tarjeta PCI-1723, emulando el comportamiento de un encoder
analogico. Sin embargo como se menciono en la seccion 3.3.2, los datos de
posicion del volante se actualizan a una frecuencia de 25 Hz, lo que requerirıa la
implementacion de un PID discreto mas que un PID contınuo. Adicionalmente
se comprobo de forma experimental que la transmision de la posicion del volante
como una senal analogica se carga de ruido cuando el vehıculo se pone en
marcha. Esto hace necesaria la implementacion de filtros que generarıan retrasos
adicionales en la senal y por ende en la respuesta del controlador. Por todas estas
razones se dejo de lado esta opcion.
Partiendo de las conclusiones obtenidas con los experimentos descritos anteri-
ormente se decidio finalmente utilizar el controlador Black Jaguar a lazo abierto,
cerrando el lazo de control a nivel de software. Para ello se desarrollo un hilo den-
tro del programa principal que se encarga de ejecutar un controlador de posicion
para el volante a la misma frecuencia del bus CAN (25 Hz). Este controlador
se basa en logica borrosa y ha sido implementado con la herramienta ORBEX –
ver seccion 2.3.1. La figura 3.13 presenta un esquema general del lazo de control
mientras que el funcionamiento del sistema se describe a continuacion:
1. Al recibir un mensaje de posicion y velocidad del volante desde el bus CAN
del vehıculo, el programa de control transmite ambas variables al Hilo de
Control del Volante (HCV).
45
3. PLATERO Y SU INSTRUMENTACION
Figura 3.13: Esquema del sistema de control del volante.
2. Al recibir las variables, el HCV reinicia su ejecucion, determina el error de
posicion y ejecuta una llamada al ORBEX.
3. El ORBEX, a partir del error de posicion del volante y la velocidad del
mismo, determina la consigna de voltaje adecuada para el motor.
4. El HCV recibe la consigna del ORBEX, la encapsula adecuadamente y
transmite la informacion al controlador a traves del bus CAN dedicado al
mismo. Acto seguido envıa un mensaje de heartbeat y se auto-suspende a
la espera de nuevos datos.
3.4.3.1 Controlador borroso
Como se ha mencionado anteriormente, la base del control de posicion del
volante es el controlador borroso que ha sido implementado a nivel de software.
Este controlador considera tanto el error de posicion como la velocidad de giro
del volante como variables de entrada para luego definir el valor de voltaje que
se debe aplicar al motor para realizar la correccion.
Cada vez que se ejecuta una llamada a este controlador, los valores de ambas
entradas son codificados en diferentes etiquetas linguisticas, empleando para ello
un conjunto de funciones de pertenencia trapezoidales. Las figuras 3.14a y 3.14b
muestran, respectivamente, las funciones definidas para cada una de las entradas
46
3.4 Actuadores
−200 −150 −100 −50 0 50 100 150 2000
0.2
0.4
0.6
0.8
1
1.2
Negativo CeroN Cero CeroP Positivo
ErrorPos
−200 −150 −100 −50 0 50 100 150 2000
0.2
0.4
0.6
0.8
1Negativa Nula Positiva
VelVol
Figura 3.14: Entradas del controlador de posicion del volante.
−1 −0.8 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 10
0.2
0.4
0.6
0.8
1
1.2
MaxDer PocoDer Nada PocoIzq MaxIzq
VolMotor
Figura 3.15: Salida del controlador de posicion del volante.
con sus correspondientes etiquetas linguisticas. Aun cuando se ha definido el
rango de valores de entrada entre -1.000 y 1.000 para el error de posicion y entre
-600 y 600 para la velocidad de giro, las graficas muestran un rango inferior
a fin de facilitar la visualizacion grafica de las funciones de pertenencia. De
forma analoga, los posibles valores de salida para el voltaje aplicado al motor
son representados por 5 singletons normalizados, siendo ±1 el equivalente a ±12
voltios – ver figura 3.15.
Luego de haber codificado los valores recibidos para cada entrada, el contro-
lador calcula la correspondiente accion de control – voltaje a aplicar sobre el motor
– a traves de un conjunto de siete reglas borrosas enumeradas a continuacion:
SI ErrorPos Negativo ENTONCES VolMotor MaxDer
SI ErrorPos Negativo Y VelVol Nula ENTONCES VolMotor PocoDer
47
3. PLATERO Y SU INSTRUMENTACION
−200 −100 0 100 200
−200−1000100200−1
−0.5
0
0.5
1
ErrorPosVelVol
Vol
Mot
or
Figura 3.16: Superficie de control para el volante.
SI ErrorPos CeroN ENTONCES VolMotor PocoDer
SI ErrorPos Cero ENTONCES VolMotor Nada
SI ErrorPos CeroP ENTONCES VolMotor PocoIzq
SI ErrorPos Positivo Y VelVol Nula ENTONCES VolMotor PocoIzq
SI ErrorPos Positivo ENTONCES VolMotor MaxIzq
La figura 3.16 muestra la superficie de control generada por la combinacion de
este conjunto de reglas.
3.4.3.2 Validacion del sistema
Luego de implementar el sistema de bajo nivel descrito en las secciones previas
para el control del volante, se procedio a la realizacion de varias pruebas con
el objetivo de validar su funcionamiento. En primera instancia, y por motivos
de seguridad, todas las pruebas de controlador se realizaron con el vehıculo
totalmente parado.
Para la primera prueba, el vehıculo se coloco sobre asfalto y se realizaron
cambios de forma escalonada en la referencia de posicion siguiendo el patron
Centro - Izquierda - Centro - Derecha - Centro. Los resultados de la prueba se
muestran en la figura 3.17. A partir de los resultados obtenidos se ha determinado
que, en promedio, el tiempo de respuesta del controlador para cambios en la
referencia de 400 grados es de 1,1 segundos aproximadamente. De igual forma se
puede apreciar en la grafica que el sistema presenta un error en estado estacionario
en torno a los 20 grados para cada uno de los escalones de la referencia. A
primera impresion este error puede parecer elevado para el control de posicion
pero se debe considerar que (i) la relacion volante-direccion es de 15:1 grados
48
3.4 Actuadores
0 10 20 30 40 50 60 70
−400
−300
−200
−100
0
100
200
300
400
Tiempo [s]
Pos
ició
n [º
]
ReferenciaVolante
30 35 40
05
1015
Figura 3.17: Pruebas del controlador del volante con el vehıculo sobre asfalto.
0 10 20 30 40 50 60 70
−400
−300
−200
−100
0
100
200
300
400
Tiempo [s]
Pos
ició
n [º
]
ReferenciaVolante
30 35 40
05
10
Figura 3.18: Pruebas del controlador del volante con el vehıculo sobre zona noasfaltada.
aproximadamente, por lo que el error de 20 grados en la posicion del volante solo
representa un error de 1,3 grados en la direccion y (ii) el vehıculo se encuentra
parado, por lo que la respuesta del sistema es afectada por la alta friccion que
existe entre las ruedas y el asfalto ya que el controlador ha sido disenado para
funcionar con el vehıculo en movimiento.
Como segunda prueba se procedio a repetir el experimento anterior pero esta
vez ubicando el vehıculo sobre una superficie no asfaltada – cubierta de tierra. Los
resultados obtenidos (ver figura 3.18) son bastante similares a los de la primera
prueba con la excepcion de que el error en estado estacionario es levemente inferior
– en torno a los 12 grados.
Una vez comprobado que el comportamiento del controlador es adecuado para
realizar pruebas con el vehıculo en movimiento sin comprometer la seguridad de
los pasajeros se procedio a la realizacion de las mismas. Para este experimento se
49
3. PLATERO Y SU INSTRUMENTACION
0 100 200 300 400 500 600 700
−400
−300
−200
−100
0
100
200
300
400
Tiempo [s]
Pos
ició
n [º
]
ReferenciaVolante
280 290 300 310 320
100
200
300
Figura 3.19: Pruebas del volante controlado a traves del teclado.
desarrollo una sencilla aplicacion que permite al conductor controlar la posicion
del volante utilizando el raton del ordenador a bordo como joystick al mismo
tiempo que controla la velocidad del vehıculo de forma convencional. Los
resultados obtenidos se presentan en la figura 3.19. Se puede apreciar en esta
grafica que el controlador borroso implementado sigue casi a la perfeccion la
referencia fijada por el conductor a traves del programa. A partir de estos
resultados se ha concluido que el controlador borroso de bajo nivel desarrollado
para el control de posicion del volante es adecuado para su implementacion en la
conduccion autonoma de vehıculos, ya que la evolucion de la referencia generada
por el controlador de alto nivel sera muy similar a la referencia que ha sido
introducida por el conductor humano durante esta prueba.
3.4.3.3 Dificultades encontradas durante la implementacion
A pesar de que el Black Jaguar es un equipo fabricado por Texas Instruments,
empresa reconocida a nivel mundial, la reciente salida al mercado del mismo venıa
acompanada de una cierta cantidad de errores en los manuales de usuario, lo cual
retraso en cierta medida el desarrollo de la aplicacion aqui presentada.
50
Capıtulo 4
Comunicaciones
Al dıa de hoy, los resultados de varios experimentos con diversos prototipos
han demostrado que un sistema basado en inteligencia artificial es totalmente
capaz de conducir un vehıculo de forma autonoma de la misma forma que lo hace
un conductor humano, es decir, basado solo en la informacion recibida por el
propio vehıculo a traves de los sensores embarcados. Tal es el caso del prototipo
BOSS del Tartan Racing Team que logro recorrer 85 km en un entorno urbano
de forma totalmente autonoma, resultando ganador del DARPA Urban Challenge
(ver seccion 2.1.2.3). Sin embargo, las ultimas lıneas de investigacion apuntan
al uso de la comunicacion vehıculo-vehıculo (V2V) y/o vehıculo-infraestructura
(V2I) como una fuente de informacion adicional que aumenta el entorno percibido
y por ende el tiempo disponible para la planificacion de sus acciones.
Actualmente existen en todo el mundo diversos grupos y centros de inves-
tigacion dedicados a encontrar la solucion mas adecuada para la comunicacion
V2V y V2I. Sin embargo, al dıa de hoy no se ha definido aun un estandar global
de equipos y protocolos que deban ser utilizados para estas aplicaciones, ya que
la mayorıa de ellos se encuentran aun en fase de desarrollo. A pesar de esto,
es posible encontrar algunas semejanzas entre las principales arquitecturas prop-
uestas hasta el dıa de hoy. La mas clara de estas semejanzas es la necesidad
de la creacion de un espacio de radiofrecuencia exclusivo para la transferencıa
de informacion V2V y V2I, conocido como Dedicated Short Range Communica-
tions - DSRC. El mayor avance que se ha presentado hasta el momento en esta
lınea ha sido la creacion, en Estados Unidos, de los estandares IEEE 802.11p
e IEEE 1609, este ultimo conocido como WAVE por Wireless Access for Ve-
hicular Enviroments. Estos estandares senalan, entre otras cosas, la creacion
de un espacio dedicado en la banda de 5.9 GHz para aplicaciones vehiculares
[Uzcategui 09; IEEE 10a; IEEE 10b]. Por otro lado, la Comision Europea ha
51
4. COMUNICACIONES
aprobado en el el ano 2008 la reserva de una parte de la banda de 5.9 GHz para
aplicaciones de seguridad en carreteras basadas en comunicacion V2V y V2I, a fin
de garantizar la compatibilidad con los sistemas desarrollados en Estados Unidos.
Considerando (i) que no existe aun una solucion estandar y definitiva para
las comunicaciones V2V y V2I, (ii) que no se encuentra contemplado dentro de
los objetivos del Programa AUTOPIA el desarrollo de este tipo de soluciones y
(iii) que el sistema de comunicaciones es una capa de bajo nivel dentro de la
arquitectura de control, por lo que no afecta radicalmente el desarrollo de las
capas superiores; se ha optado por utilizar sistemas de comunicacion inalambrica
comerciales – basados en el estandar WiFi (IEEE 802.11 b/g) – en las aplicaciones
desarrolladas por el Programa.
En este capitulo se presentara, en primer lugar, una descripcion de la
arquitectura de comunicaciones de la que parte el trabajo realizado y, en
segundo lugar, se presentaran las aportaciones fundamentales realizadas a esta
arquitectura para mejorar su funcionamiento.
4.1 Evolucion previa de la arquitectura de co-
municacion
Paso a paso, el Programa AUTOPIA ha evolucionado desde los primeros
sistemas implementados para la conduccion autonoma de un vehıculo, hasta
novedosas maniobras de conduccion cooperativa entre varios vehıculos. En
un principio, las soluciones desarrolladas para los escenarios de conduccion
cooperativa se basaron en una arquitectura de comunicacion bastante sencilla con
un esquema Cliente - Servidor, la cual permitıa tan solo a 2 vehıculos comunicarse
dentro de un determinado entorno, limitando la informacion transmitida a una
cadena de texto con la posicion y velocidad de los mismos.
A pesar de la simplicidad de esta primera arquitectura de comunicacion,
justificada en gran parte por las limitaciones de computo de las unidades
a bordo de los primeros vehıculos autonomos, AUTOPIA logro desarrollar e
implementar diversos sistemas basados en la cooperacion entre vehıculos con
excelentes resultados; entre los que se destacan las maniobras de adelantamiento
[Naranjo 08], control de crucero adaptativo [Naranjo 03] y parada y arranque
[Naranjo 07]. Mas alla de estos resultados, pronto se empezo a notar la necesidad
de una arquitectura de comunicacion mas completa, que permitiese aumentar el
entorno de percepcion del vehıculo y con ello la complejidad de las maniobras
de conduccion cooperativa. A partir de esta necesidad y aprovechando la para
52
4.1 Evolucion previa de la arquitectura de comunicacion
ese entonces reciente actualizacion de los ordenadores a bordo, el autor propuso
en un trabajo anterior [Godoy 07] lo que serıa la primera evolucion del sistema
de comunicaciones del Programa AUTOPIA: un algoritmo de establecimiento de
conexion para el esquema Clientes - Servidor utilizando el protocolo TCP.
Este algoritmo utiliza 1 socket servidor y 4 sockets clientes en cada vehıculo,
estos ultimos configurados previamente con las direcciones IP de otros 4 vehıculos
del entorno. En el momento de iniciar la conexion, el algoritmo abre el puerto
servidor y se queda a la espera de cualquier conexion entrante. Al mismo tiempo,
intenta conectarse como cliente a las direcciones IP almacenadas de los otros
vehıculos del entorno, respetando un numero maximo de intentos para cada uno
de ellos. Un esquema general de este procedimiento puede verse en la figura 4.1.
Recepción Orden
Conectar
¿Establecidas
todas las
conexiones?
Abrir
Servidor
Conectar
Clientes
Fin
¿Intentos
Disponibles?
NO
NO
SI
SI
Esperar Tiempo
Aleatorio
Figura 4.1: Procedimiento para iniciar la comunicacion en el antıguo esquema deconexion.
Luego de esto, el algoritmo se queda a la espera del establecimiento de
cualquiera de las conexiones con algun otro vehıculo, bien sea en modo cliente
o en modo servidor. En caso de se establezca una conexion con alguno de ellos,
el sistema verifica que no exista una conexion previa con ese vehıculo y, de no
53
4. COMUNICACIONES
existir, guarda el socket correspondiente al nuevo enlace. La figura 4.2 muestra
un esquema general de este procedimiento. Respecto a los datos, el unico cambio
introducido fue el reemplazo de la cadena de caracteres por una estructura de
datos, ya que esta ultima resulta mas practica al momento de construir y analizar
los paquetes enviados y recibidos.
Evento
Socket Conectado
Revisar
Lista de
conexión
Cerrar
Socket
Guardar
Socket
Status =
Conectado
Fin
NO
SIStatus Previo
==
Conectado
Figura 4.2: Procedimiento para establecer el enlace de comunicaciones.
La principal contribucion de esta primera evolucion fue la expansion de la
comunicacion con hasta 4 vehıculos de forma simultanea, lo que permitio al
Programa AUTOPIA implementar maniobras de conduccion cooperativa mas
complejas como los adelantamientos en carreteras de doble sentido [Perez 10] y
algoritmos de gestion de cruces e intersecciones [Milanes 10].
54
4.2 Esquema global de comunicacion
4.2 Esquema global de comunicacion
El doctor Vicente Milanes, quien trabaja junto con el Programa AUTOPIA
desde el ano 2006, planteo en su tesis doctoral un esquema global de comunica-
ciones V2V y V2I que permite conocer y controlar en todo momento la ubicacion
de todos los vehıculos que circulan a traves de ella, permitiendo que los vehıculos
guiados automaticamente tomen las decisiones oportunas en funcion de las condi-
ciones del trafico con el fin de aumentar la fluidez y seguridad [Milanes 10a].
Considerando el alcance la senal como el parametro limitante en las comunica-
ciones, Milanes planteo entonces una estructura basada en Areas Locales (ALs)
interconectadas para la gestion de la comunicacion – similares a las celdas que
se definen en una red de telefonıa movil – donde los lımites de cada una de el-
las estan definidos por la tecnologıa empleada en cada caso. Cada una de estas
ALs dispone de una unidad central de gestion de la informacion, la cual recibe
todos los datos suministrados por los vehıculos e infrastructura presentes en su
entorno y reenvıa la informacion que considere relevante para cada vehıculo, per-
mitiendoles tomar las acciones oportunas. Adicionalmente, Milanes sugiere la
implementacion conjunta de diversas tecnologıas de comunicacion, como las re-
des WiFi, WiMax o GSM 2G/3G en funcion de los requisitos de trafico presentes
en cada una de las zonas a gestionar.
Los resultados obtenidos y presentados por [Milanes 10a] verifican la validez de
su propuesta como una solucion plausible para el desarrollo de sistemas de gestion
de trafico inteligentes y mas avanzados. Partiendo de esta idea como base, el autor
ha desarrollado e implementado una nueva arquitectura de comunicacion para el
Programa AUTOPIA basada en la combinacion de tecnologıas de comunicacion.
Esta nueva propuesta se describe detalladamente en la siguiente seccion.
4.3 Arquitectura de comunicacion implementada
De primera mano, la propuesta de [Milanes 10a] – descrita brevemente en la
seccion anterior – de dividir del entorno global en varias ALs permite reducir la
carga de procesamiento de datos en los vehıculos y la infraestructura; ya que se
limita, de forma razonada, el entorno de percepcion de estos (e.g. un vehıculo
A no tiene, en principio, necesidad de conocer la informacion detallada de un
vehıculo B ubicado a 5 km de distancia y viceversa). Para el caso de vehıculos
ubicados en la proximidades de la frontera entre areas vecinas, la comunicacion
permanente entre areas garantiza que estos puedan compartir informacion. Sin
embargo mas alla de las ventajas, el punto mas debil de esta propuesta es la total
55
4. COMUNICACIONES
centralizacion de la informacion, ya que si bien se ha logrado reducir la carga en
los vehıculos y la infraestructura, se ha aumentado considerablemente la carga
del nodo central encargado de recibir y gestionar toda la informacion del AL.
Por otra parte, la informacion que circula en las carreteras se puede dividir,
desde el punto de vista de la tasa de cambio de los datos, en dos clases: la
Informacion de Alta Frecuencia (IAF) como la posicion, orientacion, velocidad y
estado de cada uno de los vehıculos; y la Informacion de Baja Frecuencia (IBF)
como los lımites de velocidad, el estado del trafico y las condiciones climatologicas.
Dentro de un AL, en el que toda la informacion es procesada por el nodo central, la
transmision de IBF podrıa generar problemas si los diferentes escenarios posibles
no se gestionan adecuadamente.
Supongamos que se decide que el nodo central envıe periodicamente la IBF
en modo broadcast a todos los nodos dentro de su alcance. Esta condicion
provocarıa que el conjunto de vehıculos que han entrado recientemente a la zona
deban esperar hasta el siguiente mensaje para recibir la informacion, reduciendo
temporalmente su perspectiva del entorno. De igual forma, todos los nodos dentro
del AL deberan, al menos, procesar la informacion de toda la zona; aun cuando
se encuentren en un sector en el que parte de la informacion resulte irrelevante
en ese instante. Por otro lado, si para evitar este problema se decide que la
unidad central debe enviar periodicamente un mensaje con la IBF a cada vehıculo
entrando o circulando en la zona, entonces la carga de procesamiento de este nodo
se incrementara notablemente, afectando su capacidad de analizar y gestionar la
IAF.
Hoy en dıa, cuando no se ha implantado aun una solucion definitiva de
comunicacion en las carreteras, los conductores obtienen la IBF a partir
de las senales de transito estaticas y dinamicas tan pronto como estas se
encuentran dentro de su rango visual. Normalmente las senales estaticas
indican los lımites de velocidad, la proximidad de curvas y otras advertencias
a considerar bajo condiciones normales de la carretera, mientras que las
senales o paneles dinamicos comunican informacion actualizada sobre cambios
en las condiciones meteorologicas, accidentes, atascos o cualquier otra condicion
anormal. Analizando su funcionalidad se podrıa decir entonces que, desde
la perspectiva de los vehıculos, las senales de transito actuan como faros,
transmitiendo constantemente determinada informacion a los vehıculos proximos
a ellas.
Partiendo del esquema de gestion basado en ALs y con el objetivo de integrar
la funcionalidad de las senales de transito en la arquitectura de comunicacion
56
4.3 Arquitectura de comunicacion implementada
sin sobrepasar la capacidad del nodo central, se ha planteado entonces la
combinacion de dos tecnologıas de comunicacion – WiFi y ZigBee – en una
arquitectura multinivel para su implementacion dentro de cada AL. Basicamente
la arquitectura se divide en dos niveles: un nivel superior, destinado a la
transmision de IAF siguiendo el esquema propuesto por [Milanes 10a]; y un nivel
inferior en el que se transmite la IBF de distintos sectores del AL mediante una red
auxiliar de Unidades de Camino (RSU por sus siglas en ingles). A continuacion
se presenta la descripcion detallada de ambos niveles.
4.3.1 Nivel principal o superior
Este nivel se encarga de la gestion de la IAF, es decir, de transmitir la
informacion relativa al estado de cada uno de los vehıculos. Su funcionamiento
se basa en el esquema de gestion introducido previamente en la seccion y ha sido
implementado con tecnologıa WiFi.
4.3.1.1 UDP vs TCP.
Los primeros sistemas de comunicaciones implementados en los vehıculos del
Programa AUTOPIA se basaban en conexiones TCP, sin embargo, para el
desarrollo de esta nueva arquitectura se ha optado por la utilizacion del protocolo
UDP. La razon fundamental de este cambio reside en la necesidad de reducir al
mınimo posible los tiempos de establecimiento de los enlaces.
El protocolo TCP, al ser un protocolo orientado a la conexion, requiere que los
extremos de un enlace se sincronicen mutuamente para manejar correctamente
el flujo de paquetes y adaptarse a la congestion de la red antes de iniciar el
intercambio de informacion. Sin embargo, debe considerarse que en el caso de una
red de vehıculos este proceso de conexion puede ser afectado por las constantes
variaciones en la calidad de la conexion provocadas por el desplazamiento de los
nodos. Por otra parte, la implementacion de mensajes ACK y el permanente
control de flujo sobre canal aumentan las posibilidades sufrir retrasos en la
comunicacion.
Un escenario que demuestra mas facilmente las limitaciones de este protocolo es
el siguiente: supongamos un entorno urbano donde la comunicacion entre el nodo
central del AL y un vehıculo se realiza a traves de un enlace TCP. Partiendo de
que la conexion ha sido establecida previamente y que existe ya un intercambio de
informacion entre ambos nodos, consideremos entonces que el vehıculo se desplaza
dentro de una zona de no cobertura o baja calidad del enlace por un instante de
57
4. COMUNICACIONES
tiempo ∆t. Dependiendo de la duracion de ∆t pueden ocurrir dos casos:
La comunicacion con el vehıculo se interrumpe temporalmente , generando
una acumulacion de paquetes en el bufer de salida de ambos nodos. Cuando
el vehıculo vuelve a una zona de cobertura o buena calidad se envıan, en
ambos sentidos, todos los paquetes acumulados, requiriendo entonces el
procesamiento en ambos nodos de una mayor cantidad de datos en menor
cantidad de tiempo. Adicionalmente, se debe considerar que al tratarse de
un sistema en tiempo real, los datos mas antıguos podrıan perder relevancia
al obtener los datos mas recientes, por lo que su envıo puede no ser necesario
despues de cierto tiempo.
La comunicacion con el vehıculo se interrumpe totalmente generando una
perdida total de los datos enviados en ambos sentidos. Sin embargo, el fac-
tor mas crıtico en este caso es la necesidad de reestablecer la conexion TCP
al volver a la zona de cobertura, lo cual ocupa un determinado tiempo antes
de iniciar la transferencia de informacion en ambos sentidos.
Este caso podrıa ser aun mas crıtico si la situacion que ocasiona la
perdida de cobertura se repitese de forma periodica, llegando a evitar el
reestablecimiento del enlace debido a que el tiempo en la zona de cobertura
sea inferior al tiempo necesario para el reestablecimiento de la conexion.
Por su parte, al ser el protocolo UDP un protocolo mucho mas sencillo, que
no requiere de un establecimiento previo de conexion, del envıo de paquetes ACK
o de un control de flujo permanente; su desempeno en estos escenarios ante el
protocolo TCP resulta mucho mejor. Para el primer caso planteado la unica
diferencia entre ambos protocolos es que, al utilizar el protocolo UDP, los paquetes
enviados en la zona de no cobertura se pierden totalmente. Sin embargo, como
se menciono anteriormente, en algunos casos la relevancia de los mismos puede
resultar mınima cuando ya se han generado nuevos datos. Si ocurriese el caso
en el que la perdida de cobertura es muy pequena y no existen nuevos datos, la
utilizacion del protocolo UDP generarıa una perdida de paquetes que el protocolo
TCP podrıa recuperar. Por esta razon se ha incluıdo a nivel de aplicacion la
funcion de reenvıo automatico de paquetes. Esta caraterıstica se describira mas
detalladamente en la seccion 4.3.1.2.
En el segundo caso, la diferencia entre ambos protocolos es mas notoria. Si el
escenario de perdida de cobertura es temporal (ver figura 4.3, tanto el protocolo
TCP como el UDP permitiran recuperar el intercambio de informacion en la zona
58
4.3 Arquitectura de comunicacion implementada
Desconectado
Conectando
Enviando
Sin cobertura
TCP
UDP
Obstáculo
Obstáculo
Figura 4.3: Escenario 1: Perdida de comunicacion temporal.
de cobertura. Sin embargo, el reestablecimiento se realizara mas rapidamente al
utilizar el protocolo UDP ya que no es necesaria la conexion previa. En caso
de que el escenario de perdida de cobertura sea periodico (ver figura 4.4), la
utilizacion del protocolo UDP podrıa permitir el intercambio de datos en las
pequenas zonas de cobertura – siempre que las mismas no sean muy estrechas
– mientras que el protocolo TCP no podrıa hacerlo debido al tiempo requerido
para reestablecer la conexion.
4.3.1.2 Reenvıo de paquetes
Como se menciono anteriormente, la implementacion del protocolo UDP
presenta la desventaja de que no existe ninguna garantıa en la entrega de los
paquetes, por lo que en zonas de perdida de cobertura muy pequenas – dentro de
las cuales no existe la posibilidad de generar nuevos datos – el protocolo TCP es
mejor puesto que reenvıa los datos de forma automatica mientras que el UDP los
pierde. Por esta razon se ha decidido anadir, a nivel de aplicacion, la opcion de
enviar varias veces el mismo paquete en un lapso de tiempo.
Esta funcion se ha implementado mediante un hilo auxiliar que es ejecutado
cada vez que se envıa un mensaje. Debido a que el ciclo de control utilizado
habitualmente en el Programa AUTOPIA es de 200 ms, se ha configurado el hilo
para transmitir 3 veces cada mensaje en un lapso de 100 ms, i.e. con un intervalo
de 50 ms entre intentos. Esta redundancia en el envıo de paquetes garantiza, en
59
4. COMUNICACIONES
Desconectado Conectando
Enviando
Sin cobertura
TCP
Obstáculo
UDP
Figura 4.4: Escenario 2: Perdida de comunicacion periodica.
cierto nivel, la transmision de la informacion en casos de perdida de cobertura
muy pequenos. El numero de intentos ası como el tiempo para ellos puede ser
configurado desde los ficheros de configuracion creados para la aplicacion.
4.3.1.3 Centralizacion de la informacion
La centralizacion de la informacion es uno de los principales requerimientos
del esquema de gestion de trafico en el que se basa esta nueva arquitectura de
comunicaciones. De acuerdo a este esquema, la centralizacion permite realizar
una gestion adecuada de los datos, dirigiendo a cada vehıculo la informacion
correspondiente al entorno dentro del cual se encuentra. Esto permite reducir la
cantidad de informacion irrelevante que los mismos podrıan recibir si los datos
se transmitieran por igual en toda el AL, ası como los enlaces de comunicacion
necesarios.
Por otra parte, al utilizar una estacion central de gestion de la informacion
es posible desarrollar aplicaciones que, basadas en la informacion obtenida de
todos los vehıculos dentro del AL, sean capaces de predecir situaciones de riesgo
y transmitir ordenes a los vehıculos y senales de transito con la finalidad de
evitar accidentes o, en caso de que sean inevitables, reducir su impacto. Para
esta nueva propuesta de comunicaciones la unidad central representa, ademas, el
punto comun entre los dos niveles de la arquitectura.
Para la implementacion de la arquitectura en el Programa AUTOPIA se
desarrollo una aplicacion para la caseta de control ubicada en la pista de pruebas
60
4.3 Arquitectura de comunicacion implementada
Figura 4.5: Interfaz de control implementada en la caseta de la Zona deConduccion.
(ver seccion 2.3.3). Desde el punto de vista de los vehıculos, esta aplicacion resulta
totalmente transparente, ya que la misma se limita a reenviar la IAF recibida de
los coches dentro del ZOCO. Este programa permite ademas que un usuario, o
bien a una tercera aplicacion, envıe ordenes basicas de control a los vehıculos
(e.g. establecimiento de una nueva velocidad consigna). En la figura 4.5 se puede
apreciar una imagen de la interfaz de esta aplicacion.
4.3.1.4 Estructuras de datos
Los sistemas de comunicaciones inicialmente desarrollados por el Programa
AUTOPIA se limitaban a una unica estructura de datos que contenıa la
informacion de posicion y velocidad del vehıculo emisor, lo cual era mas que
suficiente para determinadas maniobras cooperativas basadas en la comunicacion
V2V. Sin embargo, la implementacion del nuevo esquema de comunicaciones abre
las puertas a la utilizacion de diversas estructuras de datos que bien pueden
contener la informacion de posicion/velocidad de un vehıculo u ordenes de control
de velocidad y/o estado de senales de trafico.
Basado en ello, se ha incorporado a los programas de control de los vehıculos
la capacidad de analisis de diversas estructuras de datos previamente definidas.
61
4. COMUNICACIONES
0 1 2...n n+1
ID Trama ID Nodo Datos CRC
Tabla 4.1: Estructura general de los mensajes enviados por los vehıculos y lacaseta de control.
Trama ID Tipo de Trama Contenido
0x1APosiciony
velocidad
Coord. EsteCoord. NorteVelocidad
Tiempo VehıculoHora del GPS
AlturaCalidad del GPSIntencion de Cruce
0x1BControlde
Velocidad
VelocidadEste P1Norte P1Este P2Norte P2
Tabla 4.2: Estructuras de datos implementadas.
En la tabla 4.1 se puede apreciar el esquema general de los mensajes.
El primer campo – Trama ID – permite a los programas de control identificar
la estrutura de datos recibida. Hasta el momento solo se han empleado dos
estructuras, cuyos identificadores y contenido se puede apreciar en la tabla 4.2.
El campo ID Nodo es utilizado para identificar al nodo emisor del mensaje.
Anteriormente el emisor se identificaba utilizando la direccion IP contenida en
el paquete, sin embargo, ya que en este caso todos los mensajes son reenvıados
por la caseta de control se ha tenido que utilizar una numeracion adicional. Los
identificadores de los nodos correspondientes a vehıculos e infraestructura han
sido implementados a partir del valor 0x1A, dejando los valores del 0x01 al 0x19
para futuras aplicaciones con nodos de alta prioridad. El valor 0x00 es utilizado
como identificador de la caseta de control.
La longitud de los datos de cada trama es variable, ya que como puede verse en
la tabla 4.2, cada trama tiene un contenido predefinido y, debido a la diversidad
de tramas que podrıan ser utilizadas, no tiene ningun sentido implementar una
estructura de datos de longitud constante.
Finalmente, el campo CRC contiene el checksum de todos los bytes de la
trama. Ha sido implementado como medio de comprobacion de errores en la
transmision de los datos.
62
4.3 Arquitectura de comunicacion implementada
4.3.2 Nivel secundario o auxiliar
La principal contribucion del trabajo realizado a nivel de comunicaciones ha
sido la inclusion del nivel secundario dentro del esquema de gestion de ALs. Este
nivel es el encargado del manejo de la informacion de baja frecuencia emulando
el funcionamiento de las senales de transito dinamicas. Su implementacion se ha
realizado utilizando tecnologıa ZigBee en una nueva arquitectura.
4.3.2.1 ZigBee
ZigBee es un estandar para comunicaciones inalambricas desarrollado por
la ZigBee Aliance. Su base es el estandar IEEE 802.15.4 el cual se orienta a
comunicaciones bidireccionales de bajo coste y bajo consumo de energıa. A pesar
de que en un principio fue desarrollado para aplicaciones de domotica, control
industrial o incluso juguetes, es posible encontrar en la literatura aplicaciones
vehiculares basadas en ZigBee. Entre estas aplicaciones se destacan el sistema
de prioridad para autobuses en intersecciones presentado por [Kinney 03], los
controles de acceso para estacionamientos de [Zhou 10] y [Xia 10], el control de
estaciones de carga para vehıculos electricos de [Kulshrestha 09] y la propuesta
de combinacion con tecnologıa GPRS para comunicaciones en las carreteras
[Chumkamon 10].
Con una red Zigbee convencional es posible conectar hasta un total de 255
nodos en diferentes topologıas – estrella, arbol o malla. Dentro de cada red
pueden existir hasta 3 tipos de nodos: el nodo coordinador, el cual se encarga de
gestionar la conectividad de la red y permite la comunicacion entre varias redes;
los nodos enrutadores, los cuales comunican los distintos dispositivos dentro la
red, y los nodos terminadores, que solo pueden transmitir informacion a su nodo
padre (un nodo enrutador o el nodo coordinador).
Dependiendo de la inteligencia de los nodos para el enrutamiento de los
mensajes las redes ZigBee se pueden clasificar en estaticas y dinamicas. Dentro de
una red estatica las rutas de transmision de cada nodo son definidas al momento
del desarrollo de la red y solo se pueden cambiar si se reprograman los nodos.
Por otro lado, en las redes dinamicas las tablas de enrutamiento son elaboradas
en tiempo real, permitiendo que la red se reconfigure automaticamente en caso
de falla de alguno de los nodos. Actualmente existen numerosos algoritmos para
resolver el problema del enrutamiento en las redes ZigBee, sin embargo ninguno
de ellos es capaz de resolver el problema del enrutamiendo en entornos dinamicos,
como es el escenario urbano en el que una gran parte de los nodos se encuentran
instalados en vehıculos moviles.
63
4. COMUNICACIONES
4.3.2.2 Arquitectura de red ZigBee auxiliar
El nivel auxiliar debe satisfacer dos requisitos esenciales: (i) ser capaz de alertar
a los conductores tan pronto como sea posible de cualquier condicion inusual
como atascos, accidentes o averıas de vehıculos y (ii) tener la capacidad para
manejar el entorno altamente dinamico con un gran numero de nodos en contınuo
movimiento. A partir de estos requerimientos y con el objetivo de aprovechar
las ventajas de las caracterısticas de la red ZigBee, se propone para este nivel
una arquitectura dividida en dos secciones: estatica y dinamica. Esta propuesta
utiliza, ademas del nodo coordinador, nodos enrutadores conectados en malla con
el objetivo de garantizar la conectividad de la red en caso de fallo o desconexion
de alguno de los nodos.
4.3.2.2.1 Seccion estatica Esta seccion del nivel incluye todos los elementos
que se encuentran relativamente estaticos considerando el desplazamiento de los
vehıculos. Esta compuesta por la unidad central del AL – comun a ambos niveles,
el nodo coordinador y los nodos enrutadores (estos ultimos mencionados a partir
de ahora como Nodos de Infraestructura - NI). La funcion de cada uno de estos
elementos se describe en los parrafos siguientes.
El nodo coordinador se debe instalar en la unidad central. A nivel de
aplicacion, este nodo es programado para actuar como una puerta de enlace
bidireccional entre la red ZigBee y la unidad central. La combinacion del
nodo coordinador y la unidad central sera mencionada a partir de ahora como
Nodo Central (NC). Los nodos de infraestructura estan pensados para ser
distribuidos de manera uniforme en el AL, siendo instalados en los elementos de
la insfraestructura – semaforos o senales de transito. Estos nodos actuaran como
faros, difundiendo periodicamente un conjunto de mensajes a todos los nodos
ubicados a “un salto” de distancia. Adicionalmente, un mensaje de estado debe
ser enviado de forma periodica desde cada NI al NC para reportar su estado actual
y el estado de los vecinos “escuchados”. Esta ultima funcionalidad permitira que
la unidad central pueda monitorear y verificar constantemente el estado de la red.
Como funcion secundaria, los NI retrasnmitiran al NC todos y cada uno de los
mensajes recibidos de la seccion dinamica de la red.
Por su parte, el NC se encargara de analizar toda la informacion recibida a
traves de ambos niveles de la red, ası como de aquella relacionada con las AL
colindantes, y determinara en base a ello los mensajes que deben transmitir los
NI. En cada NI la frecuencia de transmision sera establecida de acuerdo al estado
del mismo.
64
4.3 Arquitectura de comunicacion implementada
Figura 4.6: Esquema de la estructura de notificacion del nivel auxiliar.
Para el control de los eventos se ha definido una estructura gerarquica de tres
niveles de notificacion: normal, advertencia y alarma; asociados respectivamente
a intervalos de transmision de cinco, tres y un segundo. En caso de que ocurra
un evento inesperado la unidad central debe, antes que nada, definir una zona de
alarma alrededor del evento, permitiendo una rapida notificacion a los vehıculos
que se encuentran mas cerca del mismo. Como segundo paso, se define una zona
de advertencia alrededor de la zona de alarma. Esto permite que los vehıculos
que se aproximan al evento puedan replantear su ruta o adaptarse con antelacion
a la situacion de alarma. Los nodos que no se encuentren dentro de la zona de
alarma o de la zona de advertencia mantendran su estado normal. En la figura
4.6 se puede apreciar un esquema general de esta estructura de notificacion.
Para esta seccion de la arquitectura la conectividad entre los nodos se puede
gestionar utilizando alguno de los algoritmos de enrutamiento planteados hasta el
momento para esta tecnologıa ya que ninguno de los nodos presenta, en principio,
movimiento alguno. La implementacion de alguno de estos algoritmos permitira
que esta seccion sea capaz de reconfigurarse automaticamente en caso de falla o
desconexion de alguno de los nodos.
4.3.2.2.2 Seccion dinamica La seccion dinamica esta compuesta de todos
los nodos instalados en los vehıculos – a partir de ahora mencionados como
Nodos Moviles (NM). En un escenario urbano dividido en ALs los vehıculos
se encontraran en movimiento contınuo dentro de una zona o bien entre zonas
vecinas, resultando imposible determinar de primera mano la configuracion
adecuada para cada NM sin implementar mapas complejos que contengan los
parametros de cada AL. Ademas, el uso de mapas requerirıa a su vez la
implementacion de un sistema de localizacion fiable, creando una dependencia
innecesaria al sistema y reduciendo la adaptabilidad de la red. Por otra parte,
65
4. COMUNICACIONES
debido a la velocidad de desplazamiento de los nodos resultarıa practicamente
imposible mantener actualizadas las tablas de enrutamiento para cada nodo de
la red sin generar la saturacion del sistema. Es por ello que resulta necesaria
una solucion que garantice que todos los vehıculos son capaces de recibir y enviar
informacion sin importar la zona en la que se encuentren. Para satisfacer esta
condicion los NM deben ser programados como puertas de enlace promiscuas
entre la red ZigBee y las unidades de control embarcadas en los vehıculos.
Al ser configurados en modo promiscuo los NM son capaces de recibir cualquier
mensaje independientemente de la configuracion de la red que los envıa y, lo que
es mas importante, sin ser parte de la misma. Con los NM actuando como puertas
de enlace, todos los mensajes recibidos seran redirigidos a la unidad a bordo del
vehıculo. A partir del analisis de los mensajes recibidos, la unidad a bordo es
capaz de extraer los parametros de configuracion de la red en la que se encuentra
actualmente con el fin de autoconfigurarse con los mismos en caso de que sea
necesario enviar un mensaje a la red. Como se menciono en la seccion anterior,
los NI son los responsables de escuchar cualquier mensaje de la seccion dinamica
y retrasmitirlo al NC. Esta funcionalidad de los NI es fundamental debido a
que los NM no pertenecen a ninguna red, por lo que no existe informacion de
enrutamiento asociada a los mismos.
Ya que los NM no pertenecen a ninguna red de forma permanente y con el
objetivo de evadir la limitacion del maximo numero de nodos por red ZigBee (255)
es necesario reservar una parte del rango de identificadores para uso exclusivo de
los NM. Este rango de valores, igual para todas las ALs, debe ser compartido por
todos los NM en el momento de enviar un mensaje de la siguiente manera: cuando
un NM desea enviar un mensaje a la infraestructura este debe autoconfigurarse
con los parametros de la red mas cercana, tomar temporalmente un identificador
aleatorio dentro del rango compartido y enviar el mensaje. El mensaje sera
recibido por los NI y reenviado al NC. Esta asignacion aleatoria de identificadores
no causa conflicto alguno en la red ya que este campo es utilizado unicamente
por los NI para identificar los mensajes que provienen de la seccion dinamica.
Sin embargo, a fin de identificar correctamente el mensaje vehıculo que envıa
la informacion, la unidad a bordo debe encargarse de incluir internamente en el
mensaje el identificador unico asociado al vehıculo – normalmente definido por el
nivel superior.
66
4.3 Arquitectura de comunicacion implementada
Figura 4.7: Dispositivos IRIS fabricados por CrossBow.
Modelo Tamano Alcance Consumo inactivo
Imote2 36x48x9mm 30 m 390 uAIRIS 58x32x7mm 250 m 8 uAMicaZ 58x32x7mm 90 m 15 uATelosB 65x31x6mm 90 m 5 uAWeBee 3 31x14x3mm 30 m 0,5 uAKMote 40x22x8mm 150 m 7 uA
SunSPOT 64x38x25mm 100 m 36 uA
Tabla 4.3: Caracterısticas de dispositivos Zigbee comerciales [Milanes 10b].
4.3.2.3 Implementacion fısica
El primer paso para la instalacion del nivel auxiliar en la pista de pruebas del
Programa AUTOPIA fue determinar el tipo de dispositivos mas adecuado para
la implementacion. Previamente en [Milanes 10b] se realizo la implementacion
de redes de sensores para la comunicacion V2I. En este estudio se compararon
las caracterısticas de las principales opciones del mercado y se determino que los
dispositivos IRIS fabricados por CrossBow (ver figura 4.7) son una de las mejores
opciones para esta aplicacion debido a su alcance – 250 metros – y bajo consumo
– 8 uA en modo de espera. La tabla 4.3 muestra las caracterısticas de los modelos
comerciales considerados.
Otra ventaja de los dispositivos IRIS es que integran un algoritmo de
enrutamiento conocido como XMesh. Este algoritmo, disenado especialmente
por CrossBow para redes ad-hoc con topologıa de malla, tiene la capacidad
de construir de cero la estructura entera de la seccion estatica y mantenerla
actualizada en tiempo real, agregando y eliminando rutas entre los nodos sin
necesidad de intervencion humana o reinicio de la red [Teo 06].
67
4. COMUNICACIONES
Figura 4.8: Imagen de las tarjetas MIB520.
Figura 4.9: Distribucion de los nodos de la seccion estatica sobre el ZOCO.
Dada las dimensiones de la pista de pruebas del Programa AUTOPIA (300 x
150 m) solo ha sido necesaria la implementacion de un AL. Para ello, un total de
15 dispositivos fueron utilizados: 1 nodo coordinador, 10 nodos de infraestructura
y 4 nodos moviles. Adicionalmente, 5 tarjetas modelo MIB520 fabricadas tambien
por CrossBow (ver figura 4.8) fueron utilizadas para proporcionar la interfaz USB
a los nodos que debıan ser conectados a ordenadores, especıficamente el nodo
coordinador y los NM. La figura 4.9 muestra una imagen de la distribucion de los
NI sobre la pista de pruebas mientras que la figura 4.10 muestra una imagen de
los dispositivos instalados en la caseta de control y en Platero.
4.3.2.4 Estructuras de datos
Al igual que para el nivel superior, un conjunto de estrucuras de datos fueron
definidas para su uso en el nivel auxiliar. Sin embargo, debido al reducido ancho
de banda de los dispositivos ZigBee ha resultado crıtica la longitud de los mensajes
utilizados. En total se han considerado 4 estructuras de datos posibles (ver tabla
4.4):
68
4.3 Arquitectura de comunicacion implementada
Figura 4.10: Dispositivos instalados en la caseta de control y en Platero.
• Reporte: Utilizada por los NI para comunicar periodicamente su estado
al NC. Esta estructura tiene 4 campos: IDMensaje, Estado, IDEvento y
Edad. Para todos los mensajes de reporte el campo IDMensaje tiene el
valor de 0x10 mientras que los campos Estado, IDEvento y Edad indican
respectivamente el estado actual del nodo, el evento que esta transmitiendo
y el tiempo en segundos desde la ultima actualizacion recibida desde el NC.
• Normal: Utilizada por los NI en estado normal. Esta estructura contiene
solo dos campos: IDMensaje, con un valor de 0x21 para todos los mensajes,
y Edad, con el tiempo en segundos desde la ultima actualizacion.
• Advertencia: Utilizada por los NI en los estados de alarma y advertencia.
Esta estructura esta compuesta de siete campos: IDMensaje, IDEvento,
Este, Norte, Radio, Velocidad y Edad. El campo IDMensaje puede tener
dos valores posibles: 0x54 en modo de advertencia y 0x55 en modo de
alarma. Por su parte, el campo IDEvento indica el evento actual que se esta
transmitiendo. Esto permite que los vehıculos puedan procesar al mismo
tiempo varios eventos diferentes. Los campos Este y Norte contienen las
coordenadas UTM del centro geometrico del area de alarma/advertencia,
las cuales son definidas de forma circular y el radio de la misma la indica el
campo Radio. El campo Velocidad indica la velocidad recomendada dentro
del area de alarma/advertencia. Al igual que en las estructuras anteriores,
69
4. COMUNICACIONES
el campo Edad indica el tiempo desde la ultima actualizacion recibida.
• Vehıculo: Utilizada unicamente por los NM para transmitir informacion al
NC. Esta estructura esta compuesta de 5 campos: IDMensaje, IDVehiculo,
Este, Norte y Evento. Para todos los mensajes, el campo IDMensaje tiene
el valor de 0x42. El campo IDVehiculo contiene el identificador del vehıculo
en el nivel superior de la red. Los campos Este y Norte indican la posicion
del vehıculo al momento de enviar el mensaje y el campo Evento indica el
tipo de evento que se desea notificar al NC.
Las estructuras Normal y Advertencia son utilizadas tambien por el NC como
mensajes de orden para ser enviadas a los NI. Esto permite reducir la carga en
los NI relacionada al analisis de las ordenes.
4.3.2.5 Validacion del nivel
Con el objetivo de validar la arquitectura propuesta para este nivel como una
solucion para informar en tiempo real a los vehıculos sobre posibles incidencias en
las carreteras, se realizo un experimento para evaluar el tiempo de respuesta de
la red ante eventos comunicados por NMs. Para la prueba, el NC fue programado
para conmutar automaticamente al estado de alarma todos aquellos nodos que
retranmitieran con exito un mensaje enviado por un NM. El lapso de tiempo
entre la transmision del mensaje por parte del NM y la conmutacion de los NIs
ha sido medido a traves de un ordenador externo a la red con un programa de
monitoreo.
La figura 4.11 muestra las posibles posiciones del NM consideradas para
la transmision del mensaje. Un total de tres transmisiones diferentes fueron
realizadas desde cada una de estas ubicaciones. En la figura 4.12 se muestran los
tiempos mınimos, maximos y promedios obtenidos tanto para el primer nodo en
responder como para el ultimo. Sin embargo, debido a que segun de la ubicacion
del NM el numero de NI que podıan retrasnmitir el mensaje variaba, se considero
Struct Report Normal Warning Vehicle
MessageID = 0x54/0x55 (1)MessageID = 0x10 (1) EventID (1) MessageID = 0x42 (1)
Fields State (1) MessageID = 0x21 (1) East (4) VehicleID (4)(#bytes) EventID (1) Age (2) North (4) East (4)
Age (2) Radius (2) North (4)Speed(1) VehicleEvent (1)Age (2)
Length 5 3 15 14
Tabla 4.4: Estructuras de mensajes definidas para el nivel auxiliar.
70
4.3 Arquitectura de comunicacion implementada
Figura 4.11: Ubicaciones del NM al momento de enviar el mensaje.
como ultimo nodo el cuarto nodo cuyo estado fue conmutado a fin de poder
comparar mas facilmente los resultados.
Como puede verse en la figura 4.11a, el tiempo maximo entre la transmision
del mensaje y la declaracion de la zona de alarma con al menos 4 nodos fue, en el
peor de los casos, menor de 250 milisegundos para todas las ubicaciones, siendo
125 milisegundos el valor mas pequeno obtenido (ubicacion 6). Por su parte en
la figura 4.11b se puede ver que el retraso mas grande en la respuesta del primer
nodo ocurrio en las ubicaciones 3 y 5 con un valor de 120 milisegundos, y el mas
pequeno en las ubicaciones 2 y 6 con un valor en torno a 80 milisegundos. Gracias
a la informacion guardada por el programa de monitoreo fue posible determinar
que los retrasos en la conmutacion del primer nodo son proporcionales al numero
de nodos que retransmitıan los mensajes al NC, estando el maximo valor en la
ubicacion 4 donde todos los NI retransmitieron el mensaje, salvo el 3 y 7 que se
encontraban fuera del alcance.
Diversos estudios han determinado que el tiempo promedio de respuesta de
un conductor humano se encuentra entre 1 y 2 segundos [Olson 86; Kestinga 08].
Esto quiere decir que aun en el peor escenario, el tiempo de respuesta de la red es
al menos cuatro veces mas rapido. A partir de estos resultados se puede concluir
que la arquitectura planteada para el nivel inferior del esquema de comunicaciones
satisface los requerimientos necesarios para la implementacion de aplicaciones de
seguridad y mobilidad en las carreteras, siendo el factor limitante la longitud, en
bytes, de los mensajes transmitidos.
71
4. COMUNICACIONES
1 2 3 4 5 6 7 8 90
50
100
150
200
250
(a)
Tie
mp
o [
ms]
Mínimo Promedio Máximo
1 2 3 4 5 6 7 8 90
50
100
150
Nodo(b)
Tie
mp
o [
ms]
Mínimo Promedio Máximo
Figura 4.12: Tiempos de respuesta de la red.
72
Capıtulo 5
Resultados experimentales
En este capıtulo se presentan todos los resultados obtenidos en los diversos
experimentos realizados a partir de la automatizacion del vehıculo Platero y la
implementacion de la nueva arquitectura de comunicaciones en la zona de pruebas
del Programa AUTOPIA. En primer lugar se presentara la implementacion de una
aplicacion para la gestion de la velocidad de los vehıculos en forma dinamica de
acuerdo a la situacion del entorno. Posteriormente se presentara una aplicacion
para el control bajo peticion de semaforos, la cual esta destinada a vehıculos
prioritarios. El tercer y ultimo experimento sigue la lınea de cooperacion entre
vehıculos y consiste en sistema de gestion automatica de incorporaciones.
5.1 Gestion automatica de la velocidad
Como se menciono en la seccion 4.3, uno de los objetivos principales de la nueva
arquitectura de comunicaciones multinivel es la integracion de la funcionalidad
de las senales de transito a la red de comunicaciones del Programa AUTOPIA.
Para demostrar la capacidad de esta funcionalidad se desarrollo una aplicacion
que permite controlar de manera automatica la velocidad de los vehıculos a partir
de la informacion recibida a traves del nivel auxiliar sobre el estado actual de la
vıa.
5.1.1 Implementacion
Normalmente cuando los vehıculos del Programa se encuentran en modo de
conduccion automatica, la referencia de velocidad para cada seccion del camino
a recorrer se toma de los mapas digitales almacenados. Para permitir que esta
referencia sea actualizada en tiempo real en funcion del estado del camino, se
73
5. RESULTADOS EXPERIMENTALES
−200 −150 −100 −50 0 50 100 150−80
−60
−40
−20
0
20
40
60
Este [m]
No
rte
[m
]
Centro de la zona
Zona de Advertencia
NI en modo Advertencia
NI en modo Normal
Trayectoria del vehículo
Inicio
Fin
Figura 5.1: Esquema general de las pruebas de control automatico de velocidad
agrego un sub-proceso – a partir de ahora mencionado como WSNMap (Wireless
Sensor Network Map) – al programa de control de Platero. Este proceso es el
encargado de escuchar y analizar toda la informacion recibida del nivel auxiliar de
la red, actualizando el mapa de velocidad en tiempo real con cambios temporales.
El campo IDEvento de la estructura de datos implementada permite al WSNMap
contemplar varios cambios en el mapa de forma simultanea. El control de
velocidad se realiza de forma automatica utlizando los controladores desarrollados
en trabajos previos para el seguimiento de una determinada consigna.
5.1.2 Resultados
Para las pruebas de esta aplicacion se definio, a traves del nivel auxiliar de
comunicaciones, una zona de advertencia alrededor de la esquina noreste de la
pista de pruebas, utilizando para ello los NI 1 al 3 (la numeracion de los nodos se
presento en la seccion 4.3.2.3). Con la zona de advertencia definida, se procedıa
a realizar un recorrido de forma totalmente automatica con el vehıculo, iniciando
en el punto mas alejado de la zona de advertencia para luego cruzarla y volver
finalmente al punto de inicio. La figura 5.1 muestra un esquema general de las
condiciones del experimento y de la trayectoria del vehıculo.
La figura 5.2 muestra los resultados obtenidos para una de las pruebas
realizadas. La grafica superior muestra la evolucion temporal de la distancia
euclidiana del vehıculo a la esquina afectada. Por su parte, la grafica inferior
muestra tanto la referencia de velocidad como la velocidad real del vehıculo,
ambas en funcion del tiempo. Es posible apreciar en esta figura que la referencia
de velocidad cambia automaticamente de 40 a 15 km/h tan pronto como el
vehıculo entra en la zona restringida, volviendo a su valor normal cuando este
74
5.2 Control bajo demanda de semaforos
0 10 20 30 40 50 60 700
50
100
150
200
250
300
Dis
tan
cia
[m
]
En la zona Normal En la zona de Advertencia
0 10 20 30 40 50 60 700
5
10
15
20
25
30
35
40
45
Tiempo [s]
Ve
loci
da
d [
km/h
]
Referencia de velocidad Velocidad real
Figura 5.2: Resultados para una prueba promedio: evolucion temporal de ladistancia (arriba) y de la velocidad (abajo).
sale de la misma. En promedio de las pruebas realizadas, el vehıculo detecta
la zona restringida aproximadamente 160 metros antes de entrar en ella, lo cual
corresponde a unos 12 segundos de antelacion.
Mas alla del control de velocidad del vehıculo – lo cual es un tema sumamente
dominado por el Programa – los resultados de las pruebas realizadas demuestran
que se ha integrado correctamente en el nivel auxiliar de la red la funcionalidad
equivalente a los paneles dinamicos de informacion. Por otra parte, la principal
ventaja de la aplicacion desarrollada es la capacidad de actualizar en tiempo
real la consigna de velocidad para distintos sectores del mapa conforme a la
proximidad de los vehıculos al area afectada. Esto evita que se realicen cambios
innecesarios en vehıculos que no se veran afectados por la incidencia en el camino
o bien que esta haya sido solventada al momento de que estos circulan por la
zona.
5.2 Control bajo demanda de semaforos
El artıculo 67 del capıtulo III seccion 4a del Reglamento General de Circulacion
de indica claramente en su primer parrafo lo siguiente: Tendran prioridad de paso
75
5. RESULTADOS EXPERIMENTALES
sobre los demas vehıculos y otros usuarios de la vıa los vehıculos de servicios
de urgencia, publicos o privados, cuando se hallen en servicio de tal caracter.
Podran circular por encima de los lımites de velocidad y estaran excentos de
cumplir otras normas o senales en los casos y con las condiciones que se indican
en esta seccion. Sin embargo, hoy en dıa es comun encontrarse con el escenario
en el que una ambulancia, una patrulla de policia o un coche de bomberos se
encuentra en medio de un atasco urbano, donde la maniobrabilidad del resto de
los conductores se encuentra reducida y se dificulta que estos ultimos puedan
ceder el paso al vehıculo de emergencia. Esta situacion se complica aun mas
cuando el escenario incluye intersecciones controladas por semaforos ya que si
bien los conductores deben ceder el paso, los mismos no se arriesgan a saltarse la
luz roja por miedo, perfectamente justificado, a colisionar con los vehıculos que
circulan perpendicularmente. De igual forma, se han documentado algunos casos
de accidentes provocados por la reaccion lenta de algunos conductores ante un
vehıculo de emergencia que cruza con la luz en rojo y provoca una colision.
Estos escenarios se podrıan reducir e incluso eliminar con la implementacion
de un sistema de control bajo demanda de semaforos basado en la comunicacion
entre los vehıculos de emergencia y la infraestructura. Utilizando este sistema,
los vehıculos de emergencia podrıan indicar, al momento de aproximarse a una
interseccion o en el medio de un atasco, su posicion e intencion de cruce a la
infraestructura del AL. De esta forma, la estacion central de control realizarıa las
gestiones necesarias sobre semaforos y otras senales para detener, de forma segura,
el resto de vehıculos y/o peatones del entorno y facilitar el paso del vehıculo con
prioridad.
5.2.1 Implementacion
Para el desarrollo de esta aplicacion se agrego al programa de control de
Platero la opcion de vehıculo de prioridad. Cuando esta opcion es activada por el
conductor se habilita a su vez el envıo automatico de un mensaje de notificacion
a la infraestructura cada vez que el vehıculo se aproxima a una interseccion. El
mensaje ha sido programado para ser envıado cuando el tiempo para llegar a la
interseccion (TTI) es menor a 5 segundos, ya que como se indica en [Misener 10]
este es el tiempo adecuado para iniciar la accion de control en una interseccion.
Debido a que el tiempo de conmutacion habitual de los semaforos se encuentra
entre 1 y 2 segundos, y la cantidad de informacion enviada en cada mensaje es
bastante reducida, se ha implementado esta funcion a traves del nivel auxiliar
de la red. La intencion de cruce se ha codificado utilizando el campo Evento
76
5.2 Control bajo demanda de semaforos
Figura 5.3: Aplicacion auxiliar para el control de semaforos.
de la estructura de mensaje del vehıculo para el nivel auxiliar. Se han definido
tres posibles opciones: giro a la derecha, trayectoria recta o giro a la izquierda.
La gestion del estado de los semaforos se realizo a traves de una aplicacion
auxiliar (ver figura 5.3) conectada directamente al regulador de la empresa SICE,
fabricante de los semaforos instalados en la pista de pruebas.
El sistema implementado funciona de la siguienta manera: al aproximarse a la
interseccion el vehıculo con prioridad informa de su posicion e intencion de cruce
a la unidad central a traves de la red de comunicacion. Al recibir el mensaje,
la unidad central verifica el estado actual de cada uno de los semaforos de la
interseccion y determina la modificacion a realizar en caso de que sea necesaria.
Una vez que se ha determinado el estado necesario se comunica el mismo a la
aplicaccion auxiliar del regulador, la cual se encarga de conmutar de forma logica
cada uno de los semaforos hasta obtener el estado solicitado.
5.2.2 Resultados
Las pruebas de este sistema se llevaron a cabo en la interseccion con forma
de cruz disponible en la zona de pruebas del Programa AUTOPIA. La figura
77
5. RESULTADOS EXPERIMENTALES
Figura 5.4: Semaforos disponibles y numeracion de las entradas a la interseccion.
5.4 muestra la numeracion asociada a cada una de las entradas a la interseccion
– ignorando la entrada a la glorieta – y los distintos semaforos disponibles en
la interseccion – representados por flechas y pasos de peatones. La numeracion
utilizada permite identificar las distintas trayectorias del vehıculo en el formato
ENTRADA-SALIDA (e.g. 1-4 y 3-2 son ejemplos de una trayectoria con giro a la
derecha). Para cada prueba realizada se incicializo el estado de los semaforos en el
peor estado posible para la solicitud del vehıculo con prioridad. La sincronizacion
temporal de los ordenadores – unidad central y unidad a bordo – se ha realizado
gracias al tiempo del GPS. Dada la similitud entre los resultados obtenidos se
presentan solo los resultados de una de las pruebas.
La figura 5.5 muestra la evolucion temporal del estado de los semaforos para
una trayectoria de prueba 4-1 (giro izquierda). Se puede apreciar que en t = 0 –
imagen (a) – el vehıculo no ha alcanzado aun el umbral de notificacion y las luces
se encuentran en estado desfavorable. Tan pronto como el vehıculo se encuentra
debajo del umbral de proximidad – imagen (b) – se envıa la notificacion a la
unidad central del AL. Menos de 200 milisegundos despues de que el mensaje
ha sido enviado – imagen (c) – el regulador empieza a conmutar cada uno de los
semaforos de forma logica hasta que se alcanza el estado deseado – imagen (d). Si
bien es cierto que el color ambar no esta disponible para los semaforos peatonales,
este ha sido utilizado en la imagen (c) para mostrar la transicion entre los estados
verde y rojo. Esta transicion realmente se implemento utilizando el estado verde
parpadeante.
Como ha quedado demostrado en los resultados presentados esta aplicacion
permite que los vehıculos de emergencia, adecuados al nivel auxiliar de comu-
nicaciones implementado, sean capaces de informar a la infraestructura de la
78
5.3 Control de incorporaciones
Figura 5.5: Evolucion temporal del estado de los semaforos.
situacion en la que se encuentran – posicion e intencion en intersecciones – para
que la unidad central del area local se encargue de gestionar adecuadamente el
estado actual de los semaforos cercanos a fin permitirles el paso de forma mas
rapida y segura, reduciendo ası el riesgo de colisiones y el tiempo de espera en
situaciones de atasco.
5.3 Control de incorporaciones
Una de las principales causas de atascos en las grandes ciudades son las
incorporaciones. Desde el punto de vista de control, la incorporacion presenta
cierto nivel de complejidad ya que tanto el conductor que realiza la maniobra como
aquellos que se encuentran en la vıa principal deben ser capaces de interpretar
correctamente la situacion del trafico alrededor de ellos para evitar una colision.
Los primeros resultados relacionados con el analisis de las incorporaciones
fueron presentados por [Godfrey 68] a finales de los anos 60. Su trabajo es
considerado el comienzo de la investigacion para el control de incorporaciones
en sistemas de transporte automatizados. Casi 13 anos mas tarde, [Shladover 80]
estudio mediante simulaciones el control de incorporaciones en sistemas guiados
por carril con el objetivo de maximizar la capacidad de la vıa. Posteriormente
[Lu 00] – uno de los discıpulos de Shladover en el programa PATH (ver seccion
2.1.2.4) – desarollo un algoritmo de control longitudinal que utilizaba marcas
magneticas instaladas en las carreteras y un sistema de comunicacion entre los
vehıculos para la gestion de incorporaciones. Mas recientemente [Chevallier 09] y
[Jin 10] han estudiado mediante simulaciones distintos modelos para el analisis del
flujo de vehıculos en incorporaciones en situaciones de atascos de la vıa principal.
Mas alla de los resultados alentadores de las simulaciones, la implementacion
en real de sistemas para el control automatico de vehıculos en incoporaciones
congestionadas es una tarea mucho mas complicada. Esto se debe principalmente
79
5. RESULTADOS EXPERIMENTALES
a que, a bajas velocidades, la dinamica de los vehıculos es altamente no lineal,
por lo que no existe un modelo verdaderamente adecuado para la descripcion del
sistema.
Partiendo de la automatizacion de Platero y de la nueva arquitectura de
comunicaciones del Programa AUTOPIA se ha desarrollado e implementado un
sistema de gestion de incorporaciones basado en logica borrosa. A partir de la
informacion recolectada por la unidad central del AL, una aplicacion auxiliar se
encarga de calcular el punto optimo – entre dos vehıculos de la vıa principal
– para la incorporacion del vehıculo que se aproxima a la incorporacion y en
base a ello envıa las correspondientes consignas de referencia a cada uno de
los vehıculos involucrados en la maniobra. Durante esta seccion se utilizaran
continuamente una serie de terminos, listados a continuacion, para referirse a los
diferentes elementos involucrados en la maniobra:
• Carretera o vıa principal (CP): Carretera principal en la que se desea
incorporar el vehıculo.
• Carretera o vıa secundaria (CS): Carretera o rampa de acceso a la vıa
principal.
• Vehıculo a Incorporar (VI): Vehıculo que se aproxıma por la vıa
secundaria a la vıa principal.
• Vehıculo Lıder (VL): Vehıculo detras del cual se incorporara el VI.
• Vehıculo Seguidor (VS): Vehıculo que, estando al inicio detras del VL,
cede el paso al VI en la incorporacion.
5.3.1 Diseno e implementacion
Antes de iniciar el diseno de la aplicacion se establecio como requisito principal
que la accion del sistema de control debıa ser un compromiso entre la solucion
optima – desde el punto de vista teorico – para insertar el VI en la vıa principal
y la necesidad de evitar frenadas bruscas del VS, lo cual generarıa una cadena
expansiva de frenado de los vehıculos en la vıa principal. Partiendo de ello, el
diseno de la aplicacion se dividio en tres fases:
1. Detectar cuando un vehıculo se aproxima sobre la vıa secundaria a la vıa
principal para realizar la incorporacion, seleccionando adecuadamente los
vehıculos en la vıa principal que actuaran como VL y VS.
80
5.3 Control de incorporaciones
2. Desarrollar un algoritmo de control que sea capaz de optimizar la maniobra,
afectando lo menos posible el trafico de la vıa principal. Como salida
este algoritmo debera proporcionar los datos de referencia de velocidad y
posicion para cada uno de los vehıculos.
3. Desarollar un sistema de control inteligente capaz de seguir la referencia
generada por el algoritmo de control.
La implementacion de este sistema para las pruebas reales se ha realizado
utilizando los vehıculos Rocinante, Clavileno y Platero como VL, VI y VS
respectivamente. El sistema de decision se ha desarrollado como una aplicacion
auxiliar en la estacion central de control.
5.3.1.1 Sistema de decision
Por una parte, el sistema de control de la incorporacion debe garantizar que
el espacio disponible entre el VL y el VS sea el el adecuado para realizar la
incorporacion al momento de que el VI alcanza el punto de union de ambas vıas.
Por otra parte, esta distancia entre ambos vehıculos debe alcanzarse de forma
progresiva evitando frenadas bruscas. Para ello, se ha utilizado el concepto de
vehıculo virtual [Sakaguchi 99] para proyectar el VI sobre la vıa principal.
Como punto de partida del diseno se ha considerado que, al estar congestionada
la vıa principal, los vehıculos en ella se encuentran en modo de control de
crucero adaptativo (ACC) [Naranjo 03], manteniendo una distancia de separacion
longitudinal L entre ellos. Por lo tanto, en el momento final de la incorporacion
tanto la separacion entre el VL y el VI como entre el VI y el VS debe ser igual a
L. La figura 5.6 muestra un esquema general de la situacion de cada vehıculo al
inicio y al final de la maniobra.
Una vez que se ha iniciado la maniobra de incoporacion, el calculo de las
distancias de referencia entre vehıculos, expresadas en funcion del VL, se realiza
de la siguiente manera:
dr1 = d10 + s1 (5.1)
dr2 = L+ s2 (5.2)
donde dr1 es la distancia de referencia entre VL y VI, dr2 es la distancia de
referencia entre VL y VS, d10 es la distancia entre VL y VI al momento de iniciar
la maniobra y s1 y s2 son las variaciones en la distancia de referencia para VI
81
5. RESULTADOS EXPERIMENTALES
Figura 5.6: Esquema de la maniobra de incoporacion.
y VS respectivamente. Las variables s1 ∈ [0, L − d10 ] y s2 ∈ [0, L] han sido
definidas para permitir que las distancias de referencia del VI y VS respecto al
VL evolucionen hasta L y 2L al final de la maniobra. Estos valores pueden ser
normalizados en funcion de la posicion real de los vehıculos de la siguiente manera:
s1(t) =(L− d10)(xV L(t)− xV L0
)
L3
(5.3)
s2(t) =(xV I(t)− xV I0)L
L1
(5.4)
Notese que las unicas variables dependientes del tiempo en las ecuaciones 5.3
y 5.4 son xV L y xV I . El resto de parametros son valores constantes: L1 y L3
son las correspondientes distancias mostradas en la figura 5.6 y (xV L0, yV L0
) y
(xV I0 , yV I0) son las posiciones de VL y VI al inicio de la maniobra. Se puede
apreciar que s2, y por lo tanto dr2 , depende solo de xV I(t) y es independiente
de yV I(t). Esto se debe a que se toma como referencia la posicion del vehıculo
virtual, el cual esta proyectado sobre la vıa principal. Finalmente, la distancias
de referencia son:
dr1 =
{
d10 +(L−d10 )(xV L−xV L0
)
L3
si (xV L − xV L0) < L3
L si (xV L(t)− xV L0) > L3
(5.5)
dr2 =
{
L+(xV I−xV I0
)L
L1
si (xV I − xV I0) < L1
2L si (xV I(t)− xV I0) > L1
(5.6)
82
5.3 Control de incorporaciones
5.3.1.2 Sistema de control
Al igual que con otras maniobras de conduccion cooperativa implementadas
previamente por el Programa AUTOPIA, se ha optado por utilizar un controlador
basado en logica borrosa para el control de la maniobra de incorporaciones.
Dada la similitud que existe entre los sistemas de control longitudinal de
Platero y Clavileno, ha sido posible implementar el mismo controlador en ambos
vehıculos. Por esta razon, y debido a que los dos seguiran, a su modo, las
referencias de distancia respecto al VL, el VI tambien sera mencionado como
VS solo en esta seccion.
Como entradas del controlador se han considerado (i) el error de velocidad –
ErrorVel en km/h – definido como la diferencia entre la velocidad del VL y los VS
y (ii) el error de distancia – ErrorDis en metros – definido como la diferencia entre
las distancias deseadas – dr1 y dr2 – y las distancias reales entre los vehıculos.
La figura 5.7 muestra las funciones de pertenencia definidas para cada una de
las variables de entrada. Para la entrada ErrorVel se han definido tres funciones
de pertenencia asociadas a cada una de las tres etiquetas linguisticas consideradas.
La etiqueta Nulo indica que el VS se encuentra a la misma velocidad que el VL
con un margen de error de ±3 km/h. Por su parte, las etiquetas Positivo y
Negativo indican respectivamente que se debe acelerar o frenar el vehıculo.
De forma analoga se han definido tres funciones de pertenencia para la entrada
ErrorDis. En este caso las etiquetas Positivo y Negativo tienen funciones
asimetricas debido a que la respuesta del sistema de frenado es mas fuerte que la
del acelerador para permitir frenadas de emergencia – no necesarias en este caso.
Por su parte, la etiqueta Nulo tiene una funcion de pertenencia trapezoidal. Esto
ha sido necesario para tener cierta tolerancia a los errores de posicionamiento de
los equipos DGPS que han sido utilizados en modo diferencial.
Como salida del controlador se ha definido la accion de control sobre los
sistemas de actuacion del acelerador y freno. Ambos sistemas han sido codificados
en una sola variable de salida llamada Pedal con un rango de valores de [−1, 1],
donde −1 indica la maxima actuacion del freno y 1 la maxima actuacion sobre el
acelerador. En la figura 5.8 se pueden apreciar los 5 singletons definidos para la
variable de salida.
La accion de control es calculada utilizando el conjunto de 9 reglas borrosas
cruzadas que se menciona a continuacion:
SI ErrorDis Negativo Y ErrorVel Negativo ENTONCES Pedal FrenaM
SI ErrorDis Negativo Y ErrorVel Nulo ENTONCES Pedal FrenaM
SI ErrorDis Negativo Y ErrorVel Positivo ENTONCES Pedal Frena
83
5. RESULTADOS EXPERIMENTALES
−4 −3 −2 −1 0 1 2 3 40
0.2
0.4
0.6
0.8
1Negativo Nulo Positivo
ErrorVel
−4 −3 −2 −1 0 1 20
0.2
0.4
0.6
0.8
1Negativo Nulo Positivo
ErrorDis
Figura 5.7: Funciones de pertenencia para las entradas del controlador.
−1 −0.8 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 10
0.2
0.4
0.6
0.8
1Frena FrenaM Nada AceleraM Acelera
Pedal
Figura 5.8: Funciones de pertenencia para la salida del controlador.
84
5.3 Control de incorporaciones
−4−2
02
4 −4−2
02
−1
−0.5
0
0.5
1
ErrorDisErrorVel
Ped
al
Figura 5.9: Superficie de control para las incorporaciones.
SI ErrorDis Nulo Y ErrorVel Negativo ENTONCES Pedal AceleraM
SI ErrorDis Nulo Y ErrorVel Nulo ENTONCES Pedal Nada
SI ErrorDis Nulo Y ErrorVel Positivo ENTONCES Pedal FrenaM
SI ErrorDis Positivo Y ErrorVel Negativo ENTONCES Pedal Acelera
SI ErrorDis Positivo Y ErrorVel Nulo ENTONCES Pedal AceleraM
SI ErrorDis Positivo Y ErrorVel Positivo ENTONCES Pedal AceleraM
La figura 5.9 muestra la superficie de control asociada a este conjunto de reglas
borrosas.
5.3.2 Pruebas y resultados
El sistema desarrollado ha sido sometido a prueba en las instalaciones del
Programa AUTOPIA. Para los experimentos se utilizaron los vehıculos Rocinante,
Clavileno y el recien automatizado Platero, actuando como VL, VI y VS
respectivamente. La figura 5.10 muestra el esquema general de la maniobra
realizada. Al inicio de cada prueba, los vehıculos eran ubicados de forma tal que
el sistema de control determinase que el mejor lugar para realizar la incorporacion
estaba entre Rocinante y Platero y no antes o despues de ambos.
Los resultados obtenidos durante una de las pruebas se muestran en la figura
5.11. La grafica superior – imagen (a) – muestra la evolucion de las posiciones
de los vehıculos sobre la pista de pruebas, considerando como el origen de
coordenadas el punto de union de ambas vıas y como t = 0 el momento en
el que el sistema detecta que hay un vehıculo aproximandose a la incorporacion.
Por su parte, la imagen (b) muestra la evolucion de la velocidad de los vehıculos
durante las pruebas y la grafica inferior – imagen (c) – la distancia entre los
85
5. RESULTADOS EXPERIMENTALES
Figura 5.10: Esquema de las pruebas del sistema de control de intersecciones.
vehıculos. La distancia de referencia L se fijo en 12 metros – medida de antena a
antena.
De la grafica de velocidades es posible apreciar como el VI, antes de iniciar la
maniobra, sigue aproximadamente la velocidad de referencia predefinida hasta el
instante t = 0 donde la estacion de control detecta al VI aproximandose por la
vıa secundaria. Como en ese instante la separacion entre los vehıculos es aun muy
grande, la velocidad de cada uno de ellos se mantiene hasta t = 7s. A partir de ese
momento se puede ver como el VS disminuye su velocidad – sin detenerse – para
ceder el espacio al VI. De igual forma se puede ver que la velocidad del VI sufre un
pequeno incremento con la finalidad de lograr la distancia de referencia. Por su
parte, se puede apreciar en la grafica de la evolucion de las distancias como el VS
duplica suavemente la distancia con el VL. Esta suavidad es importante debido
a que, en una vıa congestionada, reduce la cadena de frenadas de los vehıculos
que se encuentran detras del VS. Adicionalmente se puede ver que cuando el VI
alcanza el punto de fusion de ambas vıas (t = 20s) tanto la distancia VL-VI como
VI-VS se aproximan a la distancia L.
Los resultados obtenidos para la implementacion de esta maniobra son bastante
alentadores. Por una parte, se ha demostrado que el sistema es capaz de predecir
cual es la mejor opcion para incorporar al VI a la vıa principal. Por otra parte, es
posible apreciar como se ha logrado modificar de forma adecuada las velocidades
del VI y VS para permitir que la maniobra se realice delicadamente, afectando lo
menos posible el trafico detras de ambos vehıculos.
86
5.3 Control de incorporaciones
−30 −20 −10 0 10 20 30 40 50 60−40
−35
−30
−25
−20
−15
−10
−5
0
5
Este [m]
(a)
No
rte
[m
]
Platero
Rocinante
Clavileño
t=0st=5st=10st=15st=20st=22.2s
t=0st=5st=10st=20st=22.2s
t=0s
t=5s
t=10s
t=15s
t=20s
t=22.2s
t=15s
−5 0 5 10 15 200
2
4
6
8
10
12
Tiempo [s](b)
Ve
loci
da
d [
km/h
]
Platero
Rocinante
Clavileño
−5 0 5 10 15 205
10
15
20
25
30
35
40
45
Tiempo [s](b)
Dis
tan
cia
en
tre
ve
híc
ulo
s [m
]
Platero−Rocinante
Platero−Clavileño
Clavileño−Rocinante
Figura 5.11: Evolucion de los vehıculos en durante el experimento.
87
5. RESULTADOS EXPERIMENTALES
88
Capıtulo 6
Conclusiones
En esta memoria se ha presentado, al detalle, la entera instrumentacion
realizada sobre un vehıculo comercial con el objetivo de dotarlo de la capacidad
de conducirse de forma totalmente autonoma dentro de un entorno parcialmente
controlado. Por otra parte, se ha desarrollado, implementado y validado en las
instalaciones del CAR una nueva arquitectura multinivel de comunicacion para
aplicaciones cooperativas entre vehıculos.
En lo que respecta a la automatizacion del vehıculo, se ha considerado en todo
momento la experiencia obtenida previamente por los miembros del Programa
AUTOPIA durante la instrumentacion de los vehıculos anteriores. Mas en detalle,
el esquema empleado para la automatizacion de la direccion representa, sin
duda alguna, la mayor contribucion de este trabajo a la arquitectura de control
del Programa, ya que ha permitido aumentar considerablemente la velocidad
de respuesta del sistema en comparacion con la instrumentacion de los otros
vehıculos.
En cuanto a la arquitectura de comunicaciones, el trabajo realizado se inicia
como una continuacion de la propuesta presentada en [Milanes 10a] para la
gestion de la informacion en entornos urbanos, incluyendo diversas modificaciones
para transformarla en una arquitectura multinivel enfocada a la comunicacion
V2I. Las principales aportaciones en este ambito son:
• El cambio del protocolo de comunicaciones de TCP a UDP. Gracias
a ello se ha logrado reducir el tiempo necesario para el establecimiento de
los enlaces, eliminando los grandes retardos en el restablecimiento de la
conexion en caso de perdida del mismo.
• La inclusion del nivel auxiliar, lo que ha permitido emular el compor-
tamiento de las senales de transito dinamicas garantizando que no se genera
89
6. CONCLUSIONES
un exceso de carga de procesamiento en el nodo central del area local ni en
los nodos moviles del entorno. Por otra parte, la validacion de este nivel
implementado con tecnologıa ZigBee demostro que el tiempo de respuesta
de la red es hasta 4 veces mas rapido que el de un conductor humano, por
lo que puede ser la base para el desarrollo de aplicaciones de seguridad e
informacion en las carreteras.
• El esquema estatico-dinamico del nivel auxiliar, el cual ha permitido
sortear parte de las limitaciones de las redes ZigBee en cuanto al maximo
numero de nodos permitidos en una red y al enrutamiento de los mensajes
dentro de la misma.
Ademas de las aportaciones a la arquitectura de control y comunicacion del
Programa, se han presentado tres experimentos de distintas aplicaciones basados
en los sistemas implementados. Por una parte tanto la aplicacion para el control
automatico de la velocidad a partir de la situacion actual del entorno como la
aplicacion para el control bajo demanda de los semaforos destinada a vehıculos de
emergencia, han demostrado el potencial del nivel auxiliar – basado en tecnologıa
ZigBee – para el desarrollo de aplicaciones de seguridad y movilidad en entornos
urbanos. Por otra parte, la inclusion de las incorporaciones dentro del abanico
de maniobras implementadas en los vehıculos del Programa valida por un lado,
la arquitectura de control implementada en el vehıculo Platero y por otro lado
la capacidad del esquema de comunicaciones para el desarrollo de aplicaciones de
gestion del trafico.
Por ultimo, es importante destacar que parte del trabajo aquı realizado ha
permitido la participacion del Programa AUTOPIA dentro del Grand Cooperative
Driving Challenge, llevado a cabo durante la segunda semana de Mayo en Holanda
y donde el cual se obtuvo la posicion numero 5 de entre 10 participantes.
Como trabajo a futuro se prevee incrementar a nivel general la capacidad
del sistema de comunicaciones, incorporando otras tecnologıas como WiMax y
GPRS 3G que permitan aumentar aun mas el entorno percibido. Adicionalmente
se esta trabajando en la incorporacion al vehıculo de un algoritmo de fusion de
datos multimodelo que permita conocer la localizacion de este aun en casos de
perdida de la senal GPS, deslizamiento de las ruedas e incluso derrapes sobre
superficies deslizantes.
90
Bibliografıa
[Alcalde 00] S. Alcalde. Intrumentacion de un vehıculo electrico parauna conduccion autonoma. Master’s thesis, UniversidadPolitecnica de Madrid, 2000. 23
[Baber 05] Jonathan Baber, Julian P. Kolodko, Tony Noel, Michael Par-ent, Ljubo Vlacic and Kimon P. Valavanis. Cooperative Au-tonomous Driving: Intelligent Vehicles Sharing City Roads.2005. 13
[Chevallier 09] E. Chevallier and L. Leclercq. Do microscopic merging modelsreproduce the observed priority sharing ratio in congestion?Transportation Research Part C, Vol. 17, pp. 328–336, 2009.79
[Chumkamon 10] S. Chumkamon, P. Tuvaphanthaphiphat and P. Keeratiwin-takorn. The vertical handoff between GSM and Zigbee net-works for vehicular communication. In Proc. Int Electri-cal Engineering/Electronics Computer Telecommunicationsand Information Technology (ECTI-CON) Conf, pp. 603–606,2010. 63
[E-Safety 11] E-Safety. http://www.esafetysupport.org/, 2011. 1
[Ernst 09] T. Ernst, V. Nebehaj and R. Srasen. CVIS: CALM proofof concept preliminary results. In Proc. Intelligent TransportSystems Telecommunications,(ITST),2009 9th Int. Conf, pp.80–85, 2009. 14
[Garcıa 98] R Garcıa and T. de Pedro. Modeling a fuzzy coprocessor andits programming language. In Mathware and Soft Computing,volume 5, pp. 167–174, 1998. 21
[Garcıa 00] R Garcıa and T. de Pedro. First application of the ORBEXCoprocessor: Control of Unmanned Vehicles. In Matware andSoft Computing, volume 7, pp. 265–273, 2000. 21
[Godfrey 68] M. B. Godfrey. Merging in Automated Transportation System.PhD thesis, Massachusetts Institute of Technology, 1968. 79
91
BIBLIOGRAFIA
[Godoy 07] J. Godoy. Diseno, Unificacion, y Mejora de los Sistemas deDecision y Control en Vehiculos sin Conductor. UniversidadSimon Bolıvar, 2007. 24, 29, 53
[Godoy 10] J. Godoy, V. Milanes, J. Perez, J. Villagra and C. De Pe-dro T. & Gonzalez. Implementacion de un sistema de local-izacion para vehıculos sin conductor. In Seminario Anual deAutomatica, Electronica Industrial e Instrumentacion, 2010.32
[IEEE 10a] IEEE. IEEE Draft Standard for Wireless Access in VehicularEnvironments (WAVE) - Multi-Channel Operation. IEEE1609.4/D8.0, June 2010, pp. 1 –92, jul. 2010. 51
[IEEE 10b] IEEE. IEEE Standard for Information technology–Telecommunications and information exchange betweensystems–Local and metropolitan area networks–Specific re-quirements Part 11: Wireless LAN Medium Access Con-trol (MAC) and Physical Layer (PHY) Specifications Amend-ment 6: Wireless Access in Vehicular Environments. IEEEStd 802.11p-2010 (Amendment to IEEE Std 802.11-2007 asamended by IEEE Std 802.11k-2008, IEEE Std 802.11r-2008,IEEE Std 802.11y-2008, IEEE Std 802.11n-2009, and IEEEStd 802.11w-2009), pp. 1 –51, jul. 2010. 51
[Jin 10] W. Jin. Continuous kinematic wave models of merging trafficflow. Transportation Research Part B, Vol. 44, No. 8-9, pp.1084–1103, 2010. 79
[Kestinga 08] A. Kestinga, M. Treibera, M. Schonhofa and D. Helbinga.Adaptive cruise control design for active congestion avoid-ance. Transportation Research Part C: Emerging Technolo-gies, Vol. 16, No. 6, pp. 668–683, 2008. 71
[Kinney 03] P. Kinney. ZigBee Technology: Wireless Control that SimplyWorks. ZigBee Alliance, October 2003. 63
[Kulshrestha 09] P. Kulshrestha, K. Swaminathan, Mo-Yuen Chow and S. Lu-kic. Evaluation of ZigBee communication platform for con-trolling the charging of PHEVs at a municipal parking deck.In Proc. IEEE Vehicle Power and Propulsion Conf., pp. 1211–1214, 2009. 63
[Lu 00] X. Lu, H. Tan, S. Shladover and J.K. Hedrick. Implementa-tion of Lontigudinal Control Algorithm for Vehicle Merging.In Proc. 5th International Symposium on Advance VehicleControl, p. 25.32, August 2000. 79
92
BIBLIOGRAFIA
[Milanes 10] V. Milanes, J. Perez, E. Onieva and C. Gonzalez. Controllerfor Urban Intersections Based on Wireless Communicationsand Fuzzy Logic. IEEE Transactions on Intelligent Trans-portation Systems, Vol. 11, No. 1, pp. 243–248, 2010. 54
[Milanes 10a] V. Milanes. Sistema de control de trafico para la coexisten-cia entre vehıculos autonomos y manuales mediante comuni-caciones inalambricas. PhD thesis, Universidad de Alcala,2010. 2, 24, 29, 38, 55, 57, 89
[Milanes 10b] V. Milanes, E. Onieva, B. Vinagre, C. Gonzalez, J. Perez andJ. Alonso. Sistema de Asistencia a la conduccion basado enuna red de comunicaciones de bajo coste. DYNA, Vol. 85,No. 3, pp. 245–254, April 2010. ix, 67
[Misener 10] J. Misener. Cooperative Intersection Collision AvoidanceSystem (CICAS): Signalized Left Turn Assist and TrafficSignal Adaptation. Rapport technique, California PATHProgram, 2010. 76
[Naranjo 03] J. E. Naranjo, C. Gonzalez, J. Reviejo, R. Garcia andT. de Pedro. Adaptive fuzzy control for inter-vehicle gapkeeping. IEEE Transactions on Intelligent TransportationSystems, Vol. 4, No. 3, pp. 132–142, 2003. 52, 81
[Naranjo 05] J. E. Naranjo. Sistemas de Conduccion Automatica deVehıculos Basado en Logica Borrosa y Sistemas Globalesde Posicionamiento por Satelite: Programa Autopia,. PhDthesis, Universidad Politecnica de Madrid, 2005. 29, 38, 43
[Naranjo 07] J. E. Naranjo, C. Gonzalez, R. Garcia and T. de Pedro. Coop-erative Throttle and Brake Fuzzy Control for ACC+Stop&GoManeuvers. IEEE Transactions on Vehicular Technology,Vol. 56, No. 4, pp. 1623–1630, 2007. 52
[Naranjo 08] J. E. Naranjo, C. Gonzalez, R. Garcia and T. de Pedro.Lane-Change Fuzzy Control in Autonomous Vehicles for theOvertaking Maneuver. IEEE Transactions on IntelligentTransportation Systems, Vol. 9, No. 3, pp. 438–450, 2008.52
[Naranjo 09] J. E. Naranjo, L. Bouraoui, R. Garcia, M. Parent andM. A. Sotelo. Interoperable Control Architecture for Cybercarsand Dual-Mode Cars. IEEE Transactions on IntelligentTransportation Systems, Vol. 10, No. 1, pp. 146–154, 2009.16
[Olson 86] P. L. Olson and M. Sivak. Perception-response time tounexpected roadway hazards. Human Factors, Vol. 28, pp.91–96, 1986. 71
93
BIBLIOGRAFIA
[Parent 05] Michel Parent and Arnaud De La Fortelle. Cybercars : Past,Present and Future of the Technology. In ITS World Congress2005, San Francisco, USA, 11 2005. 16
[Perez 09] J. Perez, C. Gonzalez, V. Milanes, E. Onieva, J. Godoy andT. de Pedro. Modularity, adaptability and evolution in theAUTOPIA architecture for control of autonomous vehicles.In Proc. IEEE Int. Conf. Mechatronics ICM 2009, pp. 1–5,2009. 30
[Perez 10] J. Perez, V. Milanes, J. Alonso, E. Onieva and T. De Pedro.Adelantamiento con vehiculos autonomos en carreteras dedoble sentido. In Revista Iberoamericana de Automatica eInformatica Industrial, volume 7, pp. 25–33, 2010. 43, 54
[Sakaguchi 99] T. Sakaguchi, A. Uno and S. Tsugawa. Inter-vehicle commu-nications for merging control. In Proc. of the IEEE Interna-tional Vehicle Electronics Conference (IVEC), pp. 365 –370vol.1, 1999. 81
[Sheikholeslam 93] C. A. Sheikholeslam S.and Desoer. Longitudinal control ofa platoon of vehicles with no communication of lead vehicleinformation: a system level study. In Vehicular Technology,IEEE Transactions on, volume 42, pp. 546–554, 1993. 12
[Shladover 80] Steven E. Shladover. Operation of merge junctions in adynamically entrained automated guideway transit system.Transportation Research Part A: General, Vol. 14, No. 2, pp.85 – 112, 1980. 79
[Shladover 92] S. E. Shladover. The California PATH Program of IVHSresearch and its approach to vehicle-highway automation. InIntelligent Vehicles ’92 Symposium., Proceedings of the, pp.347–352, 1992. 12
[Teo 06] A. Teo, G. Singh and J. C. McEachen. Evaluation of theXMesh Routing Protocol in Wireless Sensor Networks. InProc. 49th IEEE Int. Midwest Symp. Circuits and Systems,volume 2, pp. 113–117, 2006. 67
[Toulminet 08] G. Toulminet, J. Boussuge and C. Laurgeau. Comparativesynthesis of the 3 main European projects dealing with Co-operative Systems (CVIS, SAFESPOT and COOPERS) anddescription of COOPERS Demonstration Site 4. pp. 809 –814, oct. 2008. 15
[Urmson 08] Christopher Urmson, Joshua Anhalt, Hong Bae, J. An-drew (Drew) Bagnell, Christopher Baker, Robert E. Bittner,
94
BIBLIOGRAFIA
Thomas Brown, M. N. Clark, Michael Darms, Daniel Demitr-ish, John M. Dolan, David Duggins, David Ferguson, Tu-grul Galatali, Christopher M. Geyer, Michele Gittleman, SamHarbaugh, Martial Hebert, Thomas Howard, Sascha Kolski,Maxim Likhachev, Bakhtiar Litkouhi, Alonzo Kelly, MatthewMcNaughton, Nick Miller, Jim Nickolaou, Kevin Peterson,Brian Pilnick, Raj Rajkumar, Paul Rybski, Varsha Sadekar,Bryan Salesky, Young-Woo Seo, Sanjiv Singh, Jarrod M.Snider, Joshua C. Struble, Anthony (Tony) Stentz, MichaelTaylor, William (Red) L. Whittaker, Ziv Wolkowicki, WendeZhang and Jason Ziglar. Autonomous driving in urban envi-ronments: Boss and the Urban Challenge. Journal of FieldRobotics Special Issue on the 2007 DARPA Urban Challenge,Part I, Vol. 25, No. 1, pp. 425–466, June 2008. 10
[Uzcategui 09] R. Uzcategui and G. Acosta-Marum. Wave: A tutorial.Communications Magazine, IEEE, Vol. 47, No. 5, pp. 126–133, may. 2009. 51
[Wang 07] Chieh-Chih Wang, Chuck Thorpe, Martial Hebert, SebastianThrun and H. Durrant-Whyte. Simultaneous Localization,Mapping and Moving Object Tracking. The InternationalJournal of Robotics Research, Vol. 26, No. 1, June 2007. 9
[Xia 10] Tingkai Xia, Ming Yang, Ruqing Yang and Chunxiang Wang.CyberC3: A Prototype Cybernetic Transportation Systemfor Urban Applications. IEEE Transactions on IntelligentTransportation Systems, Vol. 11, No. 1, pp. 142–152, 2010.16, 63
[Zhou 10] Rong Zhou, Chunyue Zhao, Lili Fu, Ao Chen and MeiqianYe. ZigBee-based Vehicle Access Control System. In Proc.Third Int Intelligent Information Technology and SecurityInformatics Symp, pp. 232–235, 2010. 63
95
División de Ingeniería de Sistemas y Automática
![[XLS] · Web viewMI DARUL FALAH MIDARUSSAADAH MI MAMUROTUL HUSNA MI MIFTAHUL ULUM BUKUR MI MIFTAHUL ULUM MI Miftahul Ulum MI NURUL ULUM MI ROHMATUL UMMAH MI ULUMIYAH MI AL FAJAR MI](https://img.pdfslide.tips/doc/110x75/5aa191977f8b9a84398bd72c/xls-viewmi-darul-falah-midarussaadah-mi-mamurotul-husna-mi-miftahul-ulum-bukur.jpg)
