Semf Imagenes y Blue Toot PDF

UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)

INGENIERO EN INFORMTICA
PROYECTO FIN DE CARRERA
MEJORA DEL TRFICO EN UN CRUCE

REGULADO POR SEMFOROS,
MEDIANTE UN SISTEMA BASADO EN
VISIN ARTIFICIAL
AUTOR: ERNESTO DE LA ROCHA GMEZ
MADRID, JUNIO 2009
Autorizada la entrega del proyecto del alumno:

ERNESTO DE LA ROCHA GMEZ
El Co-Director del Proyecto

DAVID CONTRERAS BRCENA
Fdo.: .. Fecha:
El Co-Director del Proyecto

RAFAEL PALACIOS HIELSCHER
Fdo.: .. Fecha:
V B del Coordinador de Proyectos

DAVID CONTRERAS BRCENA
Fdo.: .. Fecha:
UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)
INGENIERO EN INFORMTICA
PROYECTO FIN DE CARRERA
MEJORA DEL TRFICO EN UN CRUCE

REGULADO POR SEMFOROS,
MEDIANTE UN SISTEMA BASADO EN
VISIN ARTIFICIAL
AUTOR: ERNESTO DE LA ROCHA GMEZ

CO-DIRECTOR: DAVID CONTRERAS BRCENA
CO-DIRECTOR: RAFAEL PALACIOS HIELSCHER
MADRID, JUNIO 2009
Nobody said it was easy,

No one ever said it would be this hard.
Take me back to the start.
Coldplay The scientist
AGRADECIMIENTOS
Desde aquel verano de 2005, cuando Jess Machuca y Fernando Gonzlez
queriendo o sin querer enunciaron las bases de este proyecto, una gran cantidad de
personas han colaborado de manera directa o indirecta en este proyecto y por
tanto deben ser mencionados en este pequeo espacio de agradecimientos.
Pequeo espacio es pues, se necesitara otro documento de la misma

extensin que esta memoria para poder mencionar a todos los que han hecho
posible transformar una simple idea en realidad.
Comenzando con la idea de aquella noche de 2005, a lo largo de estos

cuatro aos, el destino o tal vez la suerte, han ido dando forma a este proyecto.
Siguiendo la lnea del tiempo, a travs de la educacin ntegra que he recibido en el
ICAI, me ha hecho capaz de afrontar el difcil reto que supona este proyecto.
Otro momento importante para el desarrollo de este proyecto fue durante

mi ao Erasmus en University of Southampton, donde pude trabajar con gente
experta en el tema de tratamiento digital de imgenes y entonces fue cuando pude
saber que, an siendo una tarea muy complicada, podra llevarse a cabo.
Parte importante de culpa de la existencia de este proyecto es tambin

debida a mis directores de proyecto, tanto Rafael Palacios como David Contreras
han aportado su amplio conocimiento e increble experiencia para completar este
proyecto, y por tanto les estar eternamente agradecidos que me hayan guiado en
este difcil camino.
Por ltimo, debo agradecer y agradezco la colaboracin de toda esa gente,

tanto familia como amigos/as, que tambin han hecho posible llevar a cabo este
proyecto. Sin su particin, de una manera exhaustiva para realizar el punto crtico
de este proyecto, las pruebas en un entorno real, y sin su apoyo continuo no
hubiera sido posible realizar con ilusin tal difcil tarea.
II
RESUMEN
Este proyecto supone el desarrollo y pruebas experimentales de un sistema
inteligente que, a partir de cmaras IP y antenas Bluetooth instaladas en los
semforos, ejecute en tiempo real decisiones sobre los semforos para la
optimizacin del trfico en una interseccin.
El sistema, denominado TEA (Traffic Enhancement Application) tiene como

objetivos principales:
Reducir el tiempo medio de espera de los vehculos que circulan por la
interseccin.
Reducir el nmero de paradas/arranques que se producen. De esta manera
se reduce el gasto de combustible y tambin se reducen las emisiones
contaminantes.
Dotar de prioridad de paso al transporte pblico y a los equipos de
emergencia.
Reducir el nmero de accidentes potenciales que se pueden producir en una
interseccin cuando algn vehculo cruza la interseccin an estando su
semforo cerrado.
Tras un estudio del estado de arte en cuanto a los sensores para la deteccin
y conteo de vehculos, la manera de detectar los vehculos que se encuentran
parados en el semforo o que se aproximan a la interseccin, est basada en el
tratamiento digital de las imgenes tomadas mediante cmaras inalmbricas
montadas en el semforo. Para realizar dicho tratamiento digital de imgenes se
han desarrollado dos algoritmos, uno para la deteccin de vehculos de da y otro
para la deteccin de vehculos de noche. Los resultados de fiabilidad de estos
algoritmos, usando alrededor de 400 imgenes de prueba, son del 98.8% de
aciertos y del 95.5% de aciertos respectivamente. Adicionalmente, para la transicin
entre estos dos algoritmos se ha desarrollado un detector del entorno de luz
ambiente, tambin basado en tcnicas de tratamiento digital de imgenes.
III
Como valor aadido de este proyecto, tambin gracias al tratamiento digital

de las imgenes, se ha desarrollado un algoritmo para la estimacin de la velocidad
de los vehculos que se aproximan a la interseccin. Esta informacin permite saber
si se puede llegar a producir una colisin de un vehculo con otro en la interseccin
en el caso de que alguno de ellos cruce la interseccin sin el permiso concedido
por los semforos.
Por otro lado, la manera de discrepar entre vehculos de emergencia,

transporte pblico y vehculos corrientes se realiza mediante tcnicas de
comunicacin Bluetooth, ya que las tcnicas de tratamiento digital de imgenes no
han resultado efectivas para discriminar vehculos prioritarios. Adems, se han
desarrollado prototipos de antenas unidireccionales Bluetooth, las recomendadas
para la deteccin unvoca del tipo de vehculo que se aproxima por cada va de la
interseccin.
Tanto los resultados de la deteccin de los vehculos que se aproximan a la

interseccin como los resultados de la comprobacin de la existencia de vehculos
prioritarios, son tratados en un sistema de toma de decisiones desarrollado en base
a reglas, con el fin de generar la decisin ptima de regulacin de los semforos y
que esta sea propagada, en tiempo real, a los semforos de la interseccin para su
implantacin.
Los tres mdulos anteriormente citados: deteccin y contabilizacin de

vehculos, deteccin de vehculos prioritarios y sistema de toma de decisiones, han
sido evaluados utilizando un entorno simulado y un entorno real.
Respecto a la evaluacin en un entorno simulado, se incluye en este

proyecto un simulador del trfico que fluye en una interseccin. Tras un proceso de
ajuste y parametrizacin del citado simulador, se han realizado simulaciones
durante 270 minutos, para las dos posibles formas de regulacin semafrica: por
patrones de tiempos fijos y mediante la regulacin inteligente propuesta por este
proyecto. Los resultados que se obtienen mediante simulacin son alentadores, el
control inteligente reduce los tiempos de espera un 74%, desde 20.849 segundos de
IV
espera acumulados durante 270 minutos de simulacin a 5.430 segundos. Por otro
lado, el nmero de arranques se reducen en 70 arranques, de 1.903 arranques
sobre 3.240 vehculos servidos, a 1.820 arranques sobre 3.265 vehculos servidos.
Respecto a la evaluacin en un entorno real, se han realizado pruebas

experimentales utilizando semforos de obra para ejecutar las decisiones de
regulacin semafrica inteligente, sobre una interseccin real por donde circulan un
flujo medio de vehculos. Durante 30 minutos se tomaron medidas del trfico que
circulaba por dicha interseccin, en trminos de tiempos de espera, arranques
producidos y nmero de vehculos servidos. Seguidamente, durante otros 30
minutos se tomaron las mismas medidas pero esta vez siendo el trfico regulado
mediante la regulacin inteligente que propone este proyecto.
Los resultados de las pruebas experimentales son satisfactorios, reafirmando

las estimaciones realizadas mediante la ejecucin de este proyecto en entornos
simulados. Concretamente los resultados obtenidos durante las pruebas
experimentales fueron:
Reduccin de los tiempos de espera para cruzar la interseccin un 56.3%,
desde 2.217 segundos de espera acumulados durante los primeros 30
minutos, a 968 segundos de los siguientes 30 minutos.
Reduccin del nmero de arranques en 70, de 142 arranques sobre 252
vehculos servidos durante los primeros 30 minutos, a 72 arranques sobre
otros 252 vehculos servidos durante los siguientes 30 minutos.
Reduccin del consumo medio de combustible en 0.564 litros, durante la
segunda media hora de pruebas experimentales.
Reduccin de 1.922,83 gramos de CO2, durante la segunda media hora de
pruebas experimentales.
En definitiva, se cubren satisfactoriamente los objetivos propuestos para

este proyecto, ya que se ha realizado un sistema inteligente para la regulacin del
trfico en funcin de una alta exigencia en los conceptos de calidad y coste del
proyecto.
ABSTRACT
This project is based on creating and carrying out experimental tests of an
intelligent system that, using IP cameras and Bluetooth antennas installed on traffic
lights, executes in real-time generated decisions to traffic lights in order to optimize
traffic flows in a junction.
This intelligent system, also known as TEA (Traffic Enhancement

Application), has the following objectives:
Reducing queuing times for vehicles that are in a junction.
Reducing the number of stops/starts that occur in a traffic junction. Because
of this, fuel consumption and pollutant emissions are reduced also.
Giving priority to cross a junction to emergency equipment and public
transport.
Reducing potential vehicle crashes that could be caused by vehicles that
cross the junction despite the fact they are not allowed to.
After a state of the art study on vehicle detection and counting techniques
using sensors, the method used for detecting vehicles that are approaching the
junction is based on digital image processing technique. This technique is applied to
images retrieved by IP cameras installed on the top of traffic lights. In order to
implement this method two algorithms have been developed, one for detecting
vehicles under daytime conditions, and another for detecting vehicles under
nighttime conditions. Results of reliability tests of these algorithms, using over 400
images, show 98.8% and 95.5% effectiveness respectively. In addition, so as to use
daytime algorithm or nighttime algorithm, a time condition detector has also been
developed, using digital image processing techniques again.
As an added value to this project, an algorithm for estimating current vehicle

speed that is coming to the junction has been developed too. Using this data, it
could be known if a potential vehicle crash could happen by a vehicle that is trying
to cross the junction without the permission given by traffic lights.
VI
The way of identifying the kind of vehicle that is approaching, is based on

Bluetooth communication techniques. Thereby, public transport and emergency
equipment can be detected so as to give them priority to cross the junction. Results
using digital image processing so as to detect this kind of vehicle were unsuccessful,
that is why Bluetooth communication techniques are used. Moreover,
unidirectional Bluetooth antennas prototypes have been created, making clear
what kind of vehicle is approaching the junction.
Counting vehicles that are coming to the intersection and checking if any of
them belongs to emergency equipment, are results that must be processed by a
decision support system. That is why; a decision support system has been also
developed and included in this project. As a result, the best decision for that right
instant is generated in real-time so as to propagate it to intersections traffic lights.
Modules referenced above: detecting and counting vehicles, detecting

emergency equipment and decision support system, have been evaluated using
simulated and real environments.
In reference to this project evaluation on simulated environments, a traffic

flow simulator on intersection has been created and it is included in this project.
After an adjustment process for this simulator, two simulations have been done
during 270 minutes, testing two traffic regulation systems: using fixed periods of
time and using an intelligent regulation. Results are promising; on the one hand,
intelligent regulation reduces queuing times over a 74%, from 20.849 seconds of
accumulated waiting times for 270 minutes of simulation, to 5.430 seconds. On the
other hand, stops/starts events are also reduced by the intelligent regulation, from
1.903 stops/starts produced by 3.240 vehicles serve, to 1.820 stops/starts produced
by 3.265 vehicles served.
In reference to this project evaluation on real environments, experimental

tests have been carried out using temporary traffic lights to execute intelligent
decisions, generated by this project, to an intersection where real traffic flows.
VII
During 30 minutes, traffic flows measures were taken in terms of queuing times,
stops/stars produced and number of vehicles that crossed the intersection. During
another period of time of 30 minutes, the same traffic flow measures were taken
but this time the traffic was being regulated by the intelligent system proposed on
this project.
Results from these experimental tests are quite successful, reassuring estimations
made by executing this intelligent system on simulated environments. More
precisely, results obtained during experimental tests were:
56.3% queuing times reduction. From 2.217 seconds of accumulated waiting
time over the first 30 minutes, to 968 seconds over the last 30 minutes.
70 stops/starts events are eliminated. From 142 stops/starts over 252
vehicles that crossed the junction during the first 30 minutes, to 72
stops/starts over 252 vehicles served during the last 30 minutes.
0.564 fuel consumption reduction over the last 30 minutes.
1.922,83 CO2 grams reduction over the last 30 minutes.
In a nutshell, objectives proposed for this project have been successfully met
because an intelligent traffic regulation system has been created in terms of high
quality and low cost.
VIII
ndice
1. Motivacin ................................................................................................................ 1
2. Concepto principal ................................................................................................. 4
3. Estado del arte ......................................................................................................... 9
4. Objetivos .................................................................................................................. 13
5. Descripcin del sistema ...................................................................................... 15
5.1. Metodologa empleada........................................................................................... 17
6. Mdulo de tratamiento digital de imgenes ............................................. 18

6.1. Estudio de diferentes tcnicas ................................................................................ 19
6.1.1. Deteccin de vehculos basada en redes neuronales ......................................... 20
6.1.2. Deteccin de vehculos basada en movimiento ................................................ 22
6.1.3. Deteccin de vehculos basada en luminosidad ................................................ 23
6.1.4. Deteccin de vehculos basada en contraste ..................................................... 27
6.2. Deteccin de vehculos que se aproximan a la interseccin ................................... 32
6.3. Algoritmo de deteccin de vehculos de da ........................................................... 37
6.4. Evaluacin del algoritmo de deteccin de vehculos de da .................................... 55
6.5. Algoritmo de deteccin de vehculos de noche....................................................... 59
6.6. Evaluacin del algoritmo de deteccin de vehculos de noche ............................... 68
6.7. Estimacin de la velocidad de vehculos que se aproximan a la interseccin ......... 72
6.8. Algoritmo de estimacin de la velocidad de vehculos que se aproximan a la
interseccin ................................................................................................................... 78
6.9. Evaluacin del algoritmo de estimacin de la velocidad de vehculos que se
aproximan a la interseccin ........................................................................................... 87
7. Mdulo de deteccin de vehculos prioritarios ........................................ 90

7.1. Deteccin basada en tratamiento de imgenes ...................................................... 92
7.2. Deteccin basada en tecnologa Bluetooth............................................................. 94
7.2.1. Tipos de antenas............................................................................................... 94
7.2.2. Cdigos de identificacin .................................................................................. 95
IX
7.3. Algoritmo de deteccin de vehculos de emergencia .............................................. 97

7.4. Conclusiones sobre el sistema de deteccin de vehculos con prioridad .............. 104
8. Sistema de toma de decisiones ..................................................................... 105

8.1. Estudio de diferentes tcnicas .............................................................................. 107
8.2. Captura del estado del trfico............................................................................... 108
8.2.1. Algoritmo de integracin con el sistema de toma de decisiones...................... 109
8.3. Verificacin contra accidentes .............................................................................. 115
8.4. Generacin de la decisin ptima ......................................................................... 117
8.4.1. Algoritmo de generacin de la decisin ptima .............................................. 118
8.5. Ejecucin de la decisin ptima ............................................................................ 126
9. Evaluacin del sistema ..................................................................................... 127

9.1. Pruebas en entorno simulado ............................................................................... 129
9.1.1. Simulacin del trfico ..................................................................................... 129
9.1.2. Ejecucin de la simulacin .............................................................................. 130
9.1.3. Comparacin de resultados ............................................................................ 131
9.2. Pruebas en entorno real ....................................................................................... 134
9.2.1. Pruebas realizadas .......................................................................................... 135
9.2.2. Resultados obtenidos ..................................................................................... 136
10. Conclusiones ...................................................................................................... 139

10.1. Trabajos futuros.................................................................................................. 141
10.2. Otras aplicaciones del sistema ............................................................................ 143
11. Planificacin ....................................................................................................... 145

12. Estimacin econmica .................................................................................... 149
13. Bibliografa .......................................................................................................... 151
Apndice I. Manual de instalacin .................................................................... 154
Mejora del trfico en un cruce regulado por semforos, mediante un sistema basado en visin artificial.
Captulo 1
Motivacin
Ernesto de la Rocha Gmez
~1~
Universidad Pontificia Comillas
1. Motivacin
La motivacin principal de este proyecto es la mejora de una accin cotidiana de la
sociedad actual. Esta accin es la de tener que cruzar una interseccin en un cruce
de trfico regulado por semforos. En innumerables ocasiones las siguientes
preguntas han sido lanzadas al aire sin respuesta obvia:
Por qu est el semforo en rojo y no puedo pasar aunque no haya otros

vehculos en la interseccin?
Por qu los semforos duran siempre lo mismo si el nmero de vehculos que

entran por cada calle son siempre distintos y variables?
Este proyecto quiere responder a las anteriores preguntas enunciando que

los semforos actuales son elementos pasivos de las intersecciones ya que no
tienen en cuenta la situacin actual de la interseccin sino que actan en funcin de
reglas predefinidas o en funcin de patrones fijos de tiempo.
Por tanto, como motivacin principal de este proyecto est la comprobacin

de que la regulacin semafrica en funcin de patrones fijos de tiempo no es
efectiva. Adems se pretende verificar que hay soluciones para este problema.
Dicha comprobacin ser mediante la solucin de transformar los semforos
actuales en elementos activos de las intersecciones, que conozcan la situacin
actual de la interseccin para tomar las decisiones ms apropiadas en cada instante
con el fin de mejorar el flujo de trfico de las intersecciones reguladas por
semforos.
Existen otras dos realidades ms que, extrapolando los datos que exponen,
sirven como motivacin extra para la realizacin de este proyecto:
~2~
Fuente: [DGT_07]
Fuente: [GRAD07]
Se puede considerar a este proyecto de ambicioso y de largo alcance,

ciertamente su motivacin es esa al intentar solucionar un problema que afecta a
toda a la poblacin de pases desarrollados y donde sus resultados pueden causar
altos beneficios para el desarrollo sostenible.
De forma paralela a toda la motivacin comentada, hay que aadir que el

desarrollo de este proyecto debe realizarse en unas condiciones de tiempo limitado
e intentando minimizar el coste.
A lo largo de esta memoria se van a ir realizando desarrollos y conclusiones

en funcin de la motivacin aqu recogida. Adems, en el captulo 7 se recogen
todas estas conclusiones conectadas, en cierta manera, con la motivacin
presentada.
~3~
Captulo 2
Concepto principal
~4~
2. Concepto principal
En la siguiente figura se puede observar una representacin de una interseccin de
trfico regulada por semforos. Est compuesta por cuatro vas que acceden a dicha
interseccin, cada una de estas vas con doble sentido de circulacin.
Figura 1. Ilustracin de una interseccin cualquiera
El concepto principal de este proyecto es la creacin de un sistema

inteligente para mejora del trfico, de aqu que este proyecto tambin se conozca
como TEA (Traffic Enhancement Application). Instalando cmaras IP y antenas
Bluetooth en la parte superior de estos semforos se puede conocer el estado del
trfico en un determinado instante para regular el trfico de la manera ms
adecuada y equitativa para ese determinado instante.
Los beneficios que pueden resultar de la aplicacin de este proyecto son

numerosos y hasta que una vez se simulen o se ponga en funcionamiento una
prueba real a gran escala no se pueden cuantificar con precisin. Sin embargo, a
modo de resumen se presenta la siguiente figura que enuncia los beneficios de
instalar cmaras IP y antenas Bluetooth en los semforos
~5~
Figura 2. Esquema de beneficios que se obtienen al instalar cmaras IP y antenas Bluetooth
El siguiente paso al conocimiento del estado del trfico en cada instante

consiste en la toma de decisiones. La forma de generacin de la decisin ptima y
equitativa se realiza en los siguientes pasos:
Semforos
Control de
interseccin
Capturan una imagen de la va que regulan para un determinado

instante, usando la cmara IP instalada.
Buscan si algn equipo de emergencia se aproxima por la va que
regulan, usando la antena Bluetooth instalada.
Envan la imagen de la va que regulan y los datos de los equipos de
emergencia que se aproximan (si existiesen) a un sistema, denominado
centro de control de interseccin.
Procesa las imgenes de todos los semforos para un determinado
instante.
Procesa la informacin sobre equipos de emergencia que se aproximan a
la interseccin (si existiesen).
A travs de su sistema de toma de decisiones y de los datos que
maneja, manda la decisin ptima a los semforos para que estos la
ejecuten y regulen el trfico acorde a la decisin tomada.
Ejecutan la decisin tomada por el centro de control de interseccin.
Semforos
Figura 3. Esquema de integracin de los distintos elementos de este proyecto

~6~
Este proceso se repite continuamente, siguiendo siempre los mismos pasos y

en el mismo estricto orden, caracterstica imprescindible para que la optimizacin
del trfico sea un proceso robusto que no dependa de otros condicionantes.
La siguiente figura, representa el proceso de generacin de la decisin

ptima y equitativa.
Figura 4. Esquema de intercomunicacin de los elementos de este proyecto
A modo de resumen, se describen los elementos que intervienen en este

proyecto y que deben ser instalados en las intersecciones para hacerlo funcionar.
Los modelos que se explican a continuacin son modelos ejemplo con los requisitos
mnimos, otros modelos con caractersticas parecidas pueden funcionar en las
mismas condiciones. Las caractersticas usadas para la realizacin de las pruebas en
un entorno real se encuentran en el apartado 9.2 del presente documento. Las
instrucciones de instalacin se encuentran en el Apndice I.
La siguiente figura muestra los elementos bsicos a instalar para el correcto
funcionamiento del sistema propuesto por este proyecto
~7~
Cmara IP WiFi Conceptronic CAM2

Sensor CMOS 640x480
Compatible con: DHCP, DNS y FTP
Servidor WEB integrado
Sistema de proteccin inalmbrica WPA/WPA2
Antena Bluetooth Unidireccional

USB Dongle 100m
Antena unidireccional para cada va
Equipo de interseccin Mac Mini
Procesador Core 2 Duo de Intel a 2 GHz
1 GB de SDRAM DDR3 a 1.066 MHz
Disco duro Serial ATA de 120 GB
Cinco puertos USB 2.0
Conexiones inalmbricas Wi-Fi y Bluetooth
Figura 5. Conjunto de requisitos mnimos para el funcionamiento de este proyecto
El conexionado entre los elementos anteriores se realiza siguiendo las

siguientes tcnicas:
WiFi
USB
Figura 6. Esquema de ejemplo de conectividad entre elementos de este proyecto
~8~
Captulo 3
Estado del arte
~9~
3. Estado del arte

Los sistemas de regulacin inteligente de transporte (Intelligent Transportation
Systems) estn actualmente en auge. El problema del trfico est siendo estudiado
en todo el mundo, intentando buscar soluciones para los atascos y soluciones desde
un punto de vista sostenible. Cabe destacar los grandes esfuerzos de los pases de la
regin asitica, teniendo como ejemplos los estudios realizados en ciudades donde
el trfico experimenta un crecimiento muy destacado, como Bangkok y Pekn.
Ms concretamente, se van a enumerar una serie de sistemas que ya se

encuentran instalados, enumerando sus ventajas y sus inconvenientes.
Figura 7. Esquema de situacin del estado del arte
~ 10 ~
A modo de resumen se ha especificado una solucin, de las mltiples

existentes, para cada una de las tres alternativas de los sistemas de regulacin
inteligente de transporte. Este proyecto es parte de la alternativa de la generacin
de Decisiones Dinmicas Automticas y resuelve todos los problemas que tienen
las instalaciones especificadas. Los anteriores problemas han sido resueltos por este
proyecto debido a las siguientes razones:
No se discrepa entre horas punta y valle, no se basa en el nmero

medio de vehculos que se aproximan. Se toma la decisin ptima,
en funcin de la afluencia de trfico medido en tiempo real.
No es necesaria la creacin de patrones ya que se tomar la

decisin ptima para cada instante sin atender a otras
condiciones.
La instalacin de espiras magnticas requiere cortar el pavimento

para su instalacin, interrumpiendo la circulacin. Este proyecto
slo requiere de la instalacin de cmaras IP y antenas Bluetooth.
Usando espiras magnticas slo se puede detectar un vehculo por

espira. Con las cmaras utilizadas para el desarrollo del proyecto se
han contado hasta 8 vehculos en ensayos experimentales reales.
La necesidad de personal es un requerimiento que este proyecto

salva generando la decisin automticamente gracias al Sistema de
Toma de Decisiones desarrollado.
Problemas
Soluciones
Poblemas
Figura 8. Esquema de ventajas de este proyecto frente a otros productos
~ 11 ~
La implantacin de sistemas inteligentes para regular el trfico se basa en la

utilizacin de sensores que proporcionan informacin en tiempo real sobre el
estado del trfico. Dichos sensores estn basados en las siguientes tecnologas:
Espiras magnticas [GAJD01]: son precisas pero slo detectan la presencia
de un vehculo. Es necesario instalar un conjunto de espiras para poder
contar varios vehculos. Sin embargo su instalacin es cara e invasiva ya
que requiere instalar mucho cableado y cortar el trfico para su instalacin.
Sensores de microondas [WANG92]: de bajo coste de instalacin pero no
son fiables ante vehculos parados. Se considera crtico este apartado ya
que en intersecciones priman los vehculos parados.
Sensores de ultrasonidos [CARU01]: tambin de bajo coste e instalacin
sencilla pero no son capaces de detectar vehculos a larga distancia y por
tanto no pueden detectar los vehculos cuando se estn aproximando y
tomar la decisin ptima para los prximos instantes.
Sensores de infrarrojos [ANDR02]: pueden ser la eleccin perfecta para la
deteccin de vehculos pero pierden efectividad en entornos de ruido
como puede ser su instalacin en entornos reales.
La utilizacin de cmaras IP solventa los problemas citados anteriormente. Se

consigue un sistema ms verstil con respuestas en tiempo real, capacidad de
monitorizar zonas mucho ms amplias [KAST01] y procedimientos de instalacin
sencillos y econmicos. Adems cabe destacar la completa eliminacin de cables de
interconexin. La nica pega sera el desarrollo de algoritmos sofisticados de
tratamiento de imgenes, que han sido creados en este proyecto.
A lo largo de esta memoria se encuentra el estudio del estado del arte

especfico de las tcnicas de procesado digital de imgenes para la deteccin de
vehculos y su posterior conteo. Anlogamente tambin se describe el estado del
arte en cuanto a los diferentes tcnicas de deteccin de vehculos prioritarios y de
sistemas de toma de decisiones.
~ 12 ~
Captulo 4
Objetivos
~ 13 ~
4. Objetivos
Los objetivos principales de este proyecto son los que se muestran en el siguiente
diagrama. Estos objetivos sern transformados en funcionalidades o caractersticas
de este proyecto, tal y como se indica en los siguientes apartados de esta memoria.
Minimizar tiempos de espera

Vehculos que entran a una interseccin vaca, tienen que pasar sin
esperas.
Vehculos que entran primero deben salir primero.
Tiempo medio de espera de los vehculos en una interseccin debe ser
equitativo sin depender de la va en la que se encuentren.
Minimizar emisiones contaminantes

Al reducir tiempos de espera, se reducen las emisiones contaminantes.
Paradas y arranques de vehculos deben ser minimizadas tambin ya
que son las actividades ms contaminantes.
Reduccin del nmero de accidentes

Conocer en todo momento si hay algn vehculo atravesando la
interseccin despus del cambio a rojo, para retrasar el cambio a verde
de las dems vas de la interseccin.
Facilitar la coordinacin del trfico en interseccines de escasa/nula
visibilidad.
Prioridad a equipos de emergencia

Los vehculos de emergencia tienen prioridad absoluta de paso, el
sistema puede regular los semforos para facilitar el paso.
Entre estos, tienen mayor prioridad los que lleguen primero a la
interseccin.
Desarrollo low-cost
El coste del desarrollo del proyecto debe ser lo ms ajustado posible.
Los elementos necesarios para su desarrollo deben ajustarse a los
requerimientos mnimos.
Los costes de instalacin deben ser mnimos, aunque esto requiera un
coste de desarrollo ms elevado.
El proceso de instalacin debe ser lo menos invasible posible.
Figura 9. Esquema de objetivos a cubrir por este proyecto
~ 14 ~
Captulo 5
Descripcin del sistema
~ 15 ~
5. Descripcin del sistema

El sistema desarrollado en este proyecto, denominado como TEA (Traffic
Enhancement Application), se encuentra dividido en los siguientes tres subsistemas:
mdulo de tratamiento digital de imgenes (captulo 6), mdulo de deteccin de
vehculos prioritarios (captulo 7) y el sistema de toma de decisiones (captulo 8).
En la figura se muestra la disposicin de estos subsistemas, siendo el mdulo de
tratamiento digital de imgenes, componente esencial del sistema de toma de
decisiones, y este a su vez es tambin componente esencial del mdulo que ejecuta
la decisin.
Estos subsistemas y sus mdulos correspondientes van a ser descritos a lo largo de
los siguientes captulos.
Figura 10. Esquema de subsistemas de este proyecto
~ 16 ~
5.1 Metodologa empleada

De las mltiples metodologas de ingeniera de desarrollo de software existentes, se
ha seleccionado Extreme Programming [BECK99], tambin conocida como XP, para
ser empleada en la realizacin de este proyecto.
Las razones de esta eleccin son mltiples pero principalmente se encuentra

la caracterstica de no continuar con la siguiente fase mientras no se haya
confirmado la anterior. Otra caracterstica clave son las pruebas unitarias, pieza
base de este proyecto ya que se divide en tres subsistemas y cada subsistema ha
sido verificado por separado antes de ser integrados en un solo sistema.
A grandes rasgos, la metodologa Extreme Programming se basa en las

siguientes etapas que siguen un ciclo reiterativo:
Anlisis y descripcin informal: requisitos y objetivos a cubrir han sido
fusionados para alcanzar un grado de compromiso entre ellos.
Planificacin y diseo: todo lo desarrollado ha sido antes planificado, con o
sin desviaciones posteriores.
Desarrollo y pruebas: realizando pruebas unitarias para liberar de errores a
los mdulos que se han ido desarrollando, antes de proceder a desarrollar
otros mdulos.
Implementacin y pruebas: las pruebas del sistema integrado han sido
realizadas tanto en entorno simulado como en entorno real. Ambas pruebas
estn explicadas en el captulo 9 de este documento.
Documentacin: realizada de manera simultnea al desarrollo de todas las
componentes de este proyecto.
Otro aspecto de vital importancia son las constantes reuniones del equipo
de proyecto para comentar mejoras, solventar errores e informar del estado del
desarrollo. Estas reuniones han sido llevadas a cabo semanalmente, tal y como
muestra la planificacin de este proyecto explicada en el captulo 8 de esta
memoria.
~ 17 ~
Captulo 6
Mdulo de tratamiento
digital de imgenes
~ 18 ~
6. Mdulo de tratamiento digital de imgenes

El mdulo de tratamiento digital de imgenes tiene por objeto identificar y contar
los vehculos que se encuentran en una va, con el fin de proporcionar estos
resultados al sistema de toma de decisiones para generar la decisin ptima en
tiempo real.
El subsistema de tratamiento digital de imgenes tiene como mdulos

internos la deteccin de los vehculos que aparecen en cada imagen as como hacer
una estimacin de la velocidad de estos a partir de las imgenes de entrada, estos
dos elementos son medidas en tiempo real sobre el estado del trfico que se
obtienen, gracias a las cmaras IP instaladas en la parte superior de los semforos.
A lo largo de este captulo se describe en profundidad la creacin, desarrollo

y puesta en funcionamiento de este mdulo de tratamiento de imgenes en el
contexto en el que este proyecto se sita.
~ 19 ~
6.1 Estudio de diferentes tcnicas

En las ltimas dcadas se han desarrollado teoras y tcnicas con el fin de discernir
caractersticas a partir de imgenes. Para este proyecto se han estudiado varias de
estas tcnicas. En este documento se recogen y se explican las ventajas/desventajas
de cada tcnica respecto al contexto y a los objetivos de este proyecto. Como
requisitos indispensables se encuentran la rapidez de proceso y sobre todo la
fiabilidad de los resultados que se obtienen al aplicar estos procedimientos.
6.1.1. Deteccin de vehculos basada en redes neuronales

Mediante el concepto de redes neuronales [ENGH08] y [PAPA00] se puede resolver
el problema de deteccin de vehculos en una imagen. La tcnica consiste
bsicamente en la introduccin de una serie de patrones, los tipos de vehculos a
detectar, para que estos sean detectados en las imgenes de entrada.
Como ventaja de esta tcnica se encuentra la robustez de sus resultados,

una vez que se ha introducido un gran nmero de patrones, la red neuronal puede
reconocer los vehculos.
Por otro lado, se encuentra la desventaja de que el nmero de patrones que

siguen los vehculos es muy amplio y deben ser todos introducidos en un
procedimiento de aprendizaje. Adems hay que aadir el problema del enfoque de
las cmaras ya que los patrones no pueden ser cualesquiera, deben coincidir con el
punto de vista que posean las cmaras del sistema instalado.
Figura 11. Patrones introducidos a la red para su aprendizaje
~ 20 ~
Tras comprobar su funcionamiento mediante utilidades gratuitas disponibles

para MATLAB, se descarta esta teora por no satisfacer las necesidades de este
proyecto. Las siguientes figuran muestran la ejecucin de dichas utilidades con los
resultados correspondientes.
Figura 12. Resultado 1 de uso de red neuronal. Tiempo de proceso = 147,61 segundos.
Figura 13. Resultado 2 de uso de red neuronal. Tiempo de proceso = 57,87 segundos.
~ 21 ~
6.1.2. Deteccin de vehculos basada en movimiento

Esta tcnica se basa en el estudio de una secuencia de imgenes separadas entre s
por muy poco tiempo, del orden de milisegundos, con el fin de detectar si ha habido
cambios entre unas y otras capturas para conocer si han entrado o han salido
vehculos en la interseccin [PORN08].
Como ventaja de este procedimiento est la facilidad de desarrollo e

implementacin pero como desventaja se encuentra la escasa fiabilidad de este
proceso ya que si hay retraso significativo entre las secuencias de imgenes, los
resultados que devuelve no son fiables. Adems esa probabilidad de retraso entre la
llegada de imgenes es muy alta debido a la conectividad Wireless entre las
cmaras y el centro de interseccin donde se procesan las fotos.
En un proceso anlogo al caso de las redes neuronales, se han realizado

pruebas de fiabilidad de esta tcnica. En las siguientes figuras se puede comprobar
cmo puede llegar a detectar un vehculo debido al movimiento. El resto de los
vehculos no son detectados porque su desplazamiento es casi nulo debido a la
perspectiva de la imagen.
Figura 14. Resultado 1 de uso de deteccin de movimiento.

~ 22 ~
Figura 15. Resultado 2 de uso de deteccin de movimiento.
6.1.3. Deteccin de vehculos basada en luminosidad

Este proyecto adapt en primera opcin el estudio de la luminosidad de los
componentes de las imgenes como tcnica para la deteccin de vehculos. El
objetivo es detectar vehculos en la imagen debido al cambio de luminosidad que se
produce entre el carril donde se encuentran y el propio vehculo.
Este procedimiento se basa en el estudio de los componentes que superan

un cierto umbral de luminosidad en una imagen. Una vez discrepados estos
elementos, se estudian sus caractersticas principales, sobre todo su morfologa
para diferenciar entre vehculos y no vehculos.
A la hora de realizar las pruebas de fiabilidad de este procedimiento se han

descubierto las siguientes debilidades. Cada debilidad identificada se muestra con
un ejemplo elaborado usando MATLAB como herramienta de tratamiento digital de
imgenes. A la izquierda se muestra la imagen original y a la derecha la imagen tras
haber sido procesada digitalmente con esta tcnica.
~ 23 ~
Problemas de deteccin de vehculos oscuros, tales como vehculo de

colores negro o similar. No se distingue el vehculo de la calzada, slo
aparecen algunos elementos del vehculo en la imagen procesada.
Figura 16. Resultado 1 de usar deteccin por discrepancia de luminosidad
Consideracin como vehculo de zonas donde se produce un contraste de

sol y sombra. En esta imagen se pone de manifiesto tambin la debilidad
anterior ya que vehculos oscuros como los que aparecen a la derecha de la
imagen no son identificados por esta tcnica. Tambin se puede comprobar
que las zonas donde no hay sombra producida por los rboles, se crean
manchas de sol donde la luminosidad supera el umbral establecido y por
tanto lo identifica como regin de inters.
Figura 17. Resultado 2 de usar deteccin por discrepancia de luminosidad.
~ 24 ~
Como resultado de las pruebas de fiabilidad realizadas a este procedimiento,

se ha obtenido la siguiente grfica, de donde se muestra la cantidad de aciertos y de
errores de esta tcnica ante 66 de imgenes de pruebas.
En esta grfica se representa el nivel de discrepancia entre el nmero de

vehculos detectados en la imagen y el nmero de vehculos que realmente hay. En
la mayora de los casos el resultado es correcto (discrepancia 0), sin embargo en
bastantes casos hay errores: se detecta un vehculo adicional en 30% de los casos y
uno o dos menos en 25% de los casos.
30
Evaluacin de deteccin por discrepancia

de luminosidad
Cantidad de ejemplos
25
20
15
10
5
0
-5
-4
-3
-2
-1
Cantidad de ejemplos
Figura 18. Grfica de errores de la deteccin de vehculos mediante discrepancia por luminosidad
En contraposicin a los resultados anteriormente expuestos, esta tcnica es

completamente vlida para la deteccin de vehculos durante condiciones donde no
existe luz natural o es muy escasa. Ajustando el umbral de corte adecuadamente se
pueden discrepar perfectamente los faros de los vehculos, cuya luminosidad es
elevada.
Como resultado de esta conclusin, el mdulo de deteccin de vehculos

debe precederse de la comprobacin del grado de luz natural existente a la hora de
~ 25 ~
tomar la imagen. En funcin de este grado se usa la tcnica de deteccin por

discrepancia de contraste, expuesta en el siguiente apartado de este documento, o
bien se usa la expuesta en este apartado del documento para localizar los faros de
los vehculos.
Como verificacin de la bondad de la tcnica de discrepancia de luminosidad

para una situacin donde no exista luz natural, se muestra el siguiente ejemplo. La
imagen superior es la imagen original, tomada durante la fase de pruebas en
entorno real que se describe en el captulo 6.2 del presente documento. La imagen
inferior es el resultado tras el tratamiento digital usando el mtodo de discrepancia
por luminosidad. Como se puede comprobar slo aparecen los faros del vehculo y
por tanto se puede concluir que hay un vehculo en ese carril en ese instante.
Figura 19. Resultado de ejecutar la tcnica de discrepancia de luminosidad en un entorno con escasa luz
natural.
~ 26 ~
6.1.4. Deteccin de vehculos basada en contraste

En este apartado se va a describir la tcnica de deteccin de zonas de inters en
imgenes utilizando una medida discrepancia de contraste de todos los elementos
de una imagen.
El mtodo de la deteccin de vehculos mediante contraste se basa en la
tcnica de deteccin de bordes. Esta forma de detectar bordes est constituida por
el clculo de la entropa de los elementos que aparecen en una imagen. A grandes
rasgos, la entropa es el contraste que existe entre dos o ms elementos de una
imagen. La deteccin de los elementos que se encuentran en la calzada se realiza
fcilmente mediante esta tcnica ya que existe un alto contraste entre el pavimento
de la calzada con los vehculos que circulan por ella.
Una grfica que muestra la fiabilidad de este mtodo es la siguiente. Se han

usado en total 481 imgenes de muestra (entre imgenes de noche e imgenes de
da), tomadas con cmaras IP instaladas en semforos en una interseccin real.
Figura 20. Grfica de fiabilidad de la deteccin de vehculos mediante discrepancia por contraste
Con esta tcnica se resuelven todos los problemas enunciados en el

apartado anterior sobre la tcnica de deteccin de vehculos usando discrepancia
por luminosidad. Adems los siguientes factores son resueltos por esta tcnica:
~ 27 ~
No son necesarios valores fijos de binarizacin. Valores que son

obligatorios a la hora de hacer una discrepancia por luminosidad para
separar los elementos pertenecientes a las zonas de inters y los elementos
que no son importantes.
o Se ahorran por tanto valores de configuracin a la hora de instalar
este proyecto, creando una solucin ms robusta para ms tipo de
situaciones.
Los problemas de deteccin de vehculos oscuros son solucionados. Esto es

debido al contraste existe entre el vehculo y la calzada. La siguiente figura
muestra la comparacin con el mtodo de discrepancia por luminosidad. Se
puede comprobar que la deteccin de bordes funciona mejor, teniendo ms
forma de vehculo, que la deteccin usando discrepancia por luminosidad.
(a)
(b)
(c)
Figura 21. Comparacin de tcnicas de deteccin de vehculos. (a) Imagen original, (b) discrepancia por
luminosidad y (c) discrepancia por contraste.
~ 28 ~
Problemas en zonas de sol y sombra son solucionados. En este caso, el

contraste entre las zonas de sol y sombra se produce de manera gradual en
nivel de entropa demasiado bajo como para que pertenezca a una zona de
inters a estudiar. La siguiente figura muestra la comparacin con el mtodo
de discrepancia por luminosidad. Se puede comprobar que la deteccin de
bordes funciona mejor, no detectando como regin de inters la zona donde
se produce la transicin de sol y sombra. Los pequeos puntos que se
detectan en la zona de carril no tienen importancia ya que son filtrados en
un proceso posterior que estudia la morfologa del los elementos detectados
para comprobar si son vehculos o no.
(a)
(b)
(c)
Figura 22. Segunda comparacin de tcnicas de deteccin de vehculos. (a) Imagen original, (b)
discrepancia por luminosidad y (c) discrepancia por contraste.
~ 29 ~
Mejora en la deteccin del volumen de los vehculos. Ya que la deteccin

de bordes devuelve un permetro fidedigno de los elementos que detecta, se
concluye que este mtodo presenta una mejora a la hora de estimar el
volumen de los vehculos que el sistema detecta y por tanto se pueden dar
valores ms fiables de nmero de vehculos que se aproximan hacia la
interseccin. En la siguiente figura, se muestra una comparacin entre los
mtodos de discrepancia por luminosidad y el mtodo de deteccin de
bordes en el contexto de esta situacin.
(a)
(b)
(c)
Figura 23. Tercera comparacin de tcnicas de deteccin de vehculos. (a) Imagen original, (b)
discrepancia por luminosidad y (c) discrepancia por contraste.
~ 30 ~
Mejora en la deteccin de varios vehculos que se encuentren bastante

lejanos. Como se puede comprobar en la siguiente figura, cuando se
encuentran varios vehculos juntos y algunos de ellos no son bien detectados
se puede llegar a confundir la manera de contar el nmero de vehculos.
Gracias a la tcnica de deteccin de bordes se puede individualizar cada
vehculo para ser procesado de manera independiente.
(a)
(b)
(c)
Figura 24. Cuarta comparacin de tcnicas de deteccin de vehculos. (a) Imagen original, (b) discrepancia
por luminosidad y (c) discrepancia por contraste.
Como resultado de todo lo enunciado en este apartado, esta tcnica de

deteccin de vehculos usando discrepancia por contraste es la utilizada por este
proyecto para el conteo de vehculos. La forma de implementar este mtodo se
encuentra en el apartado 6.3 de esta memoria.
~ 31 ~
6.2 Deteccin de vehculos que se aproximan a la

interseccin
Dado el anterior estudio de las diferentes tcnicas de deteccin de vehculos
mediante tratamiento digital de imgenes se realiza el siguiente desarrollo para
ello. Este primer componente del proyecto es la parte que ha requerido de ms
investigacin y tiempo de desarrollo, debido a su complejidad. Sin embargo es el
componente que mayor beneficio aporta en cuanto al objetivo de reduccin de
coste del sistema final.
Como se ha concluido en apartados anteriores, hay que aplicar una tcnica

diferente segn las condiciones de luz que tenga la imagen de estudio. De esta
manera queda como parmetro necesario, entre otros, el algoritmo a utilizar segn
el estudio de la luz natural de las imgenes.
Un esquema que muestra las entradas, los parmetros de configuracin y las

salidas de este mdulo es el siguiente:
Imagen de
entrada
MATLAB
Image Processing Toolbox
Parmetros:
-Posicin del carril de
estudio
- Algoritmo a usar
- Imagen del carril sin
vehculos
Carril para
correlacin
Nmero de vehculos detectados
Imagen
resultado
Figura 25. Esquema de funcionamiento del mdulo de deteccin de vehculos que se aproximan a la
interseccin
~ 32 ~
Como resultados se encuentran:

Carril de correlacin: es la lnea que describe el movimiento del vehculo
dentro del carril. Este resultado va a ser usado en el apartado 6.8 de esta
memoria para estimar la velocidad de los vehculos que se encuentran en el
carril de estudio.
Imagen resultado: usada para mostrar los resultados en el sistema de toma

de decisiones explicado en el captulo 8.
Por otro lado, los parmetros necesarios para la ejecucin de este algoritmo
y que indica la figura anterior son los siguientes:
Posicin del carril de estudio: utilizando este parmetro slo se procesa el
carril donde se encuentran los vehculos. Como ventajas de realizar esta
reduccin del problema estn las siguientes:
o Menor tiempo de proceso. A menos pxeles de la imagen a procesar,
menos tiempo necesario para procesar la imagen completa. A baja
escala las diferencias son mnimas pero a larga escala el ahorro es
significativo.
o Solucin de errores de deteccin. Sin recortar el carril, hay
elementos que pueden ser detectados como regiones de inters
pero que estn fueras de las zonas por donde circulan los vehculos.
Por esta razn la deteccin de esos elementos es evitada si se
recorta el carril. Por ejemplo evita contar vehculos estacionados y
adems evita confundir los vehculos que se alejan del cruce, de los
que se aproximan a este.
o Tratamiento especial a carriles. En vas de varios carriles permite
contabilizar cada carril independientemente, permitiendo realizar un
tratamiento especial a los carriles de giro obligatorio.
En las siguientes imgenes se puede comprobar la deteccin de elementos

que no deben ser tenidos en cuenta en este proyecto, como por ejemplo los
vehculos aparcados a los laterales de los carriles de estudio. Al recortar el
~ 33 ~
carril no se detectan estos y se obtienen solamente los datos necesarios

para la toma de decisiones.
Figura 26. Ejemplo de beneficio al recortar el carril para no detectar vehculos aparcados
En este otro caso, al recortar el carril no se tienen en cuenta vehculos que

ya han cruzado la interseccin, o que no van en direccin a la interseccin y
por tanto no deben ser contabilizados para la toma de decisiones.
Figura 27. Ejemplo de beneficio al recortar el carril para no detectar vehculos que no intervienen en la
interseccin
~ 34 ~
Seleccin automtica del algoritmo a usar: tal y como se ha concluido en los

anteriormente en esta memoria, es necesario utilizar distintos algoritmos
segn la luminosidad que se ha ido observando en las ltimas imgenes
procesados. De esta manera los porcentajes de fiabilidad que se alcanza
giran en torno al 95%. En las siguientes imgenes se puede comprobar las
distintas luminosidades medias de cada imagen, por tanto se puede inferir
que algoritmo a utilizar segn estos valores.
Amanecer
Luminosidad
media = 37.4
Medioda
Luminosidad
media = 114.5
Atardecer
Luminosidad
media = 90.7
Noche
Luminosidad
media = 35.5
Figura 28. Imgenes que muestran los distintos rangos de luminosidades medias
La manera en que se toma la decisin de qu algoritmo utilizar, no se

basa exclusivamente en la luminosidad de la imagen sino en la progresin a
lo largo del tiempo. El algoritmo ser descrito en el apartado 6.8 de este
documento con el cdigo desarrollado explicado en amplio detalle.
Imagen del carril sin vehculos: es completamente normal que existan

elementos en los carriles de estudio que se encuentren de manera
constante y esttica. Estos elementos pueden ser flechas de direccin,
limitadores de velocidad imprimidos en el pavimento y lneas divisoras de
carril. Todos estos elementos se encuentran en el carril de estudio y al
ejecutar el algoritmo pueden ser detectados y clasificados como vehculos,
siendo errores de contabilizacin que intervienen en el sistema de toma de
decisiones como una desviacin. Para contrarrestar esta desviacin es
necesario una imagen del carril de estudio sin vehculos en l, para
identificar estas zonas de inters estacionarias para no tenerlas en cuenta y
~ 35 ~
discreparlas de las zonas de inters verdaderamente identificadas como

vehculos.
Imagen a procesar
Elementos que
no deben ser
contabilizados
Imagen sin vehculos
Figura 29. Conjunto de imgenes que muestran los elementos que no deben ser contabilizados
En el siguiente apartado, se detalla exhaustivamente como es utilizada esta

imagen del carril sin vehculos para no contabilizar elementos estacionarios en los
carriles de estudio.
La funcin general para detectar y contabilizar el nmero de vehculos en la

llegada a una interseccin, se ha denominado TEA. Esta funcin realiza el anlisis de
la imagen adquirida por las cmaras IP, de acuerdo al algoritmo de deteccin de da
o de noche y devuelve el nmero de vehculos y una imagen relacionada con el
proceso de clculo. Los detalles de la funcin se presentan en el siguiente apartado.
~ 36 ~
6.3 Algoritmo de deteccin de vehculos de da

A continuacin se muestra el cdigo fuente en entorno de desarrollo MATLAB para
la deteccin de vehculos durante la existencia de luz natural. De forma paralela, se
aaden un conjunto de imgenes de ejemplo para ilustrar el proceso. Tal y como se
ha explicado en apartados anteriores de esta memoria, este algoritmo se basa en la
discrepancia por contrastes usando tcnicas de deteccin de bordes.
La funcin que se presenta a lo largo de este apartado es llamada por otra

funcin MATLAB que se presenta en el apartado 6.8 del presente documento. Dicha
funcin es la encargada de hacer el estudio de correlacin para la estimacin de la
velocidad y por tanto necesita de la siguiente funcin, que es llamada TEA con el fin
de simplificar.
function [carrilCorrelacion, vehiculosDetectados, imagenResultado] = TEA (imagen,
algoritmo, carrilCoordX, carrilCoordY)
La declaracin de la funcin es la correspondiente al esquema presentado en la

figura 26. Como resultados de ejecutar este algoritmo deben estar: el carril para
el estudio de correlacin con las imgenes anteriores (matriz lgica), el nmero
de vehculos detectados (entero) y la imagen resultado para que esta sea
mostrada en el sistema de toma de decisiones de este proyecto (matriz 3D de
enteros en RGB). Anlogamente como argumentos a esta funcin se encuentran:
la propia imagen a ser procesada (matriz de enteros en escala de grises), una
cadena de caracteres indicando el algoritmo a seguir, sea de da o de noche y
las coordenadas del eje de abscisas y de ordenadas para poder recortar el carril
haciendo que este algoritmo sea lo ms efectivo posible (matrices de enteros).
coordenadasCarril = roipoly(imagen,carrilCoordX,carrilCoordY);
imagen(~coordenadasCarril) = NaN;
carril = imagen;
~ 37 ~
Como primer paso, se encuentra el recorte de la imagen de entrada para

solamente quedarse con el carril por donde circulan los vehculos potenciales que
se quieren detectar. La funcin roipoly recibe la imagen de entrada y las
coordenadas sobre los ejes de abscisas y ordenadas para crear una mscara. Esta
mscara es usada en la lnea 4 y elimina toda la informacin que no pertenece al
carril. Por ltimo la imagen pasa a llamarse carril para su posterior proceso, con el
algoritmo de da o de noche.
Figura 30. Pareja de imgenes que demuestran cmo se extrae el carril. Imagen original a la izquierda y
carril extrado a la derecha
A continuacin se describen los detalles de la deteccin en condiciones de da,

dentro de la funcin general denominada como TEA.
if(strcmp(algoritmo,'Dia'))
carrilSobel = edge(carril,'sobel', 0.08);
carrilMediaSobel = edge(carrilMedia,'sobel', 0.08);
Tras la comprobacin de cul algoritmo hay que ejecutar en funcin de la

luminosidad de la imagen, al pertenecer la imagen al algoritmo de da se procede
a aplicar la discrepancia por contraste utilizando la tcnica de deteccin de
bordes. La funcin edge recibe la imagen a procesar en escala de grises, el
mtodo a aplicar que en este caso es Sobel y un valor de threshold para que slo
devuelva aquellos bordes ms fuertes que el valor indicado de 0.08. La eleccin
del mtodo de Sobel y de ese valor de threshold no son casuales, tras un
exhaustivo proceso de prueba y verificacin de resultados se concluye que Sobel
era el mtodo cuyos resultados son ms simples y claros y que ese valor de
threshold era suficiente para no perder bordes dbiles y para eliminar bordes que
no intervienen a la hora de discrepar entre vehculos.
~ 38 ~
Figura 31. Imgenes que representan la aplicacin del mtodo de Sobel sobre el carril con vehculos
(arriba) y sobre el carril sin vehculos (abajo)
carrilSobelCorrelacion = edge(carril, 'sobel', 0.08, 'horizontal');
Como caso particular de la aplicacin del mtodo de deteccin de bordes, se

encuentra la aplicacin de dicho mtodo a la hora de obtener el carril que se usa
para el estudio de correlacin. Las anteriores aplicaciones del mtodo de Sobel
detectan bordes tanto de manera horizontal como vertical, pero para el estudio
de correlaciones es necesario que los bordes verticales no aparezcan. La razn de
este proceder es que los bordes verticales pueden inducir errores a la hora de
realizar el estudio de correlacin tal y como se explica en el apartado 6.8 de este
documento.
Figura 32. Imgenes que muestran como es la aplicacin del mtodo de Sobel pero slo de manera
horizontal
~ 39 ~
10
coordenadasCarrilDilatadas = imerode(coordenadasCarril,strel('disk',2));
11
carrilSobelSinBordes = carrilSobel;
12
carrilMediaSobelSinBordes = carrilMediaSobel;
13
carrilSobelCorrelacionSinBordes = carrilSobelCorrelacion;
14
carrilSobelSinBordes(~coordenadasCarrilDilatadas) = 0;
15
carrilMediaSobelSinBordes(~coordenadasCarrilDilatadas) = 0;
16
carrilSobelCorrelacionSinBordes(~coordenadasCarrilDilatadas) = 0;
17
carrilCorrelacion = carrilSobelCorrelacion;
Al aplicar la deteccin de bordes, obviamente se introduce otro borde propio

alrededor del carril que se extrae ya que existe un contraste muy pronunciado
entre el carril y el fondo negro que se crea al extraer el carril. Las anteriores lneas
se encargan de eliminar este borde usando la funcin imerode que se encarga de
eliminar ese borde indicndole como argumentos las coordenadas del carril y una
estructura de disk de radio 2 pxeles para eliminar ese borde extra que se
introduce y sus alrededores. Un conjunto de imgenes que ilustra lo anterior se
presenta a continuacin.
Figura 33. Resultado tras eliminar el borde extra que se introduce al recortar el carril en cada una de las
imgenes anteriores.
~ 40 ~
18
carrilDilatado = imdilate(carrilSobelSinBordes,strel('disk',3));
19
carrilMediaDilatado = imdilate(carrilMediaSobelSinBordes,strel('disk',3));
Una vez preparado el carril con los bordes de los vehculos ya detectados, se
procede a dilatar los bordes (usando imdilate) para llegar a unir bordes difusos
que no se han detectado e intentar conseguir crear elementos lo ms completos
posibles.
Figura 34. Pareja de imgenes donde se puede comprobar la ganancia al dilatar los bordes encontrados
20
carrilClosed = imclose(carrilDilatado,strel('disk',3));
21
carrilMediaClosed = imclose(carrilMediaDilatado,strel('disk',3));
22
carrilFilled = imfill(carrilClosed,'holes');
23
carrilMediaFilled = imfill(carrilMediaClosed,'holes');
El siguiente paso sirve para cerrar los bordes que se encuentran cercanos (usando
imclose) as como para rellenar los huecos que existen entre los bordes
(mediante imfill). Gracias a estos dos procedimientos se consigue, hasta cierto
grado, la morfologa completa del vehculo que se detecta. En la siguiente pareja
de imgenes se comprueba que el vehculo que se encuentra en la parte de arriba
se ha detectado de manera casi perfecta su morfologa. En cambio en el vehculo
en la parte de abajo, an estando ms cerca, su morfologa no se detecta en su
totalidad. Esto es debido a que los bordes detectados no se encuentran
suficientemente cercanos para que sean unidos, y que la seleccin de carril
recorta el vehculo a la mitad. An as, ya que el nmero de pxeles que se
detectan para el vehculo que se encuentra abajo y adems su tamao
~ 41 ~
corresponden con los de un vehculo, en posteriores pasos de clasificacin es

contabilizado como vehculo. Queda latente que con imgenes tomadas desde
una parte ms superior del carril, la deteccin sera mucho ms fiable.
Figura 35. Pareja de imgenes que muestra el proceso de las funciones imclose e imfill
24
carrilFinal = bwareaopen(carrilFilled,1500);
25
carrilMediaFinal = bwareaopen(carrilMediaFilled,1500);
El ltimo paso es limpiar los resultados de elementos que claramente no son

vehculos. Los grupos de pxeles que no superan 1500 pxeles son eliminados
(mediante la funcin bwareaopen) para reducir el nmero de zonas de inters de
estudio as como para eliminar posibles casos errneos. En el siguiente par de
imgenes se muestra como se eliminan algunos conjuntos de pxeles ya que no
superan este lmite de 1500 pxeles, lmite que est fijado para imgenes de
640x480 ya que son las imgenes que suele devolver una cmara IP.
Figura 36. Imgenes que muestran el proceso de limpieza de elementos que no superan el tamao mnimo
en pxeles de un vehculo
26
[labelled,nComponents] = bwlabel(carrilFinal);
~ 42 ~
Mediante la funcin bwlabel se separan definitivamente los elementos que se

han detectado antes de pasar a la clasificacin e identificacin como vehculos. En
las siguientes imgenes se comprueba como los dos elementos son coloreados
con distintos tonos para diferenciarlos.
Figura 37. Imgenes donde se muestra como se pasa a identificar de manera separada a los dos
componentes.
27
caracRegion = regionprops(labelled,'basic');
28
vehiculosEsperando = 0;
29
vehiculosEsperandoLongitud = 0;
30
arrayIndicesProcesados = zeros(nComponents,1)
31
for indice=1:nComponents
Una vez realizado todos los procesos anteriores, se obtienen una serie de
elementos que, en las siguientes lneas de cdigo, van a ser estudiados, uno por
uno, sobre su morfologa gracias a la funcin regionprops. Esta devuelve el
centroide del elemento y el rectngulo que mejor envuelve al elemento
(denominado minimum bounding box) facilitando el clculo de su morfologa.
Tambin se puede comprobar que en las lneas anteriores se inicializan las
variables para el conteo de vehculos.
32
if(arrayIndicesProcesados(indice) == 0)
33
[filasFirst, columFirst] = find(labelled == indice,1,'first');
34
[filasLast, columLast] = find(labelled == indice,1,'last');
35
filas = (filasFirst+filasLast)/2;
36
coordX = caracRegion(indice).Centroid(1);
~ 43 ~
37
coordY = caracRegion(indice).Centroid(2);
38
volumen = 0;
39
longitud = 0;
40
arrayIndicesProcesados(indice) = 1;
41
42
43
for indiceCercano=indice:nComponents
if(arrayIndicesProcesados(indiceCercano) == 0)
44
coordXSiguiente = caracRegion(indiceCercano).Centroid(1);
45
coordYSiguiente = caracRegion(indiceCercano).Centroid(2);
46
47
if(coordY < 200)
48
separacionOKCoordX = 20;
49
separacionOKCoordY = 20;
50
elseif(coordY >= 200 && coordY < 300)
51
52
53
elseif(coordY >= 300 && coordY < 400)
54
55
56
elseif(coordY >= 400)
57
58
59
end
60
61
62
if( abs(coordXSiguiente - coordX) < separacionOKCoordX &&

abs(coordYSiguiente - coordY) < separacionOKCoordY)
63
arrayIndicesProcesados(indiceCercano) = 1;
64
volumen = volumen + length(find(labelled == indiceCercano));
65
[filasLastSiguiente, columLastSiguiente] = find(labelled ==
66
67
68
indiceCercano,1,'last');
if(filasLastSiguiente > filasLast || columLastSiguiente > columLast)
filasLast = filasLastSiguiente;
~ 44 ~
69
columLast = columLastSiguiente;
70
coordX = caracRegion(indiceCercano).Centroid(1);
71
coordY = caracRegion(indiceCercano).Centroid(2);
end
72
73
longitudSiguiente = abs(filasLast - filasFirst);
74
75
76
if(longitudSiguiente > longitud)
77
longitud = longitudSiguiente;
end
78
end
79
80
81
end
end
En la parte de cdigo que precede se comparan los elementos entre s con el fin
de contabilizar alguno de ellos de manera conjunta. Tras numerosas pruebas se
concluye que este proceso es necesario ya que en algunos casos los vehculos
aparecen divididos en dos objetos muy prximos pero disjuntos. En la realizacin
de este proceso intervienen una serie de parmetros fijos, tales como la
separacin permitida entre elementos para ser unidos. Estos parmetros fijos han
sido calculados en funcin de pruebas, todas ellas en imgenes de tamao
640x480 pxeles que es el tamao estndar que devuelven las cmaras IP y el
recomendando para intentar detectar el mximo nmero de vehculos.
Figura 38. Imgenes donde se muestra como el vehculo que se muestra a la izquierda, es dividido en dos
elementos debido a un reflejo.
~ 45 ~
82
volumen = volumen + length(find(labelled == indice));
83
84
if(volumen > 20000)
85
pxNecesarios = 7000;
86
vehiculosEsperando = vehiculosEsperando + floor(volumen /
87
pxNecesarios);
88
89
90
elseif(filas >= 0 && filas < 135)

if(volumen > 1500)
91
92
93
94
95
96
pxNecesarios);
elseif (volumen > 800)
vehiculosEsperando = vehiculosEsperando + 1;
end
97
98
99

if(volumen > 2500)
100
101
102
103
104
105
106
107
pxNecesarios);
elseif(volumen > 1000)
end
if(volumen > 2800) %2500
108
pxNecesarios = 2800; % 2500
109
110
111
112
113
pxNecesarios);
end
~ 46 ~
114
115
elseif(filas >=250 && filas < 300)

if(volumen > 6500)
116
117
118
119
pxNecesarios);
120
121
end
122
123
124
elseif(filas >=300)
if(volumen > 9000)
125
126
127
128
pxNecesarios);
129
130
131
end
end
El proceso anterior realiza la primera aproximacin para contabilizar los vehculos

detectados. En primer lugar calcula el nmero de pxeles que tiene la
componente que se est estudiando en ese momento, de todas las que haya. Una
vez calculado el nmero de pxeles se hace una primera comprobacin con un
nmero de pxeles elevado, concretamente 20.000. Este valor es un valor
estimado de nmero de pxeles para un elemento de un tamao muy grande,
tales como autobuses o camiones largos.
En el caso de superar ese valor de 20.000, el nmero de pxeles detectados
es dividido entre 7.000, valor de nmero de pxeles medio de un vehculo
para transformar ese posible vehculo de gran tamao en varios vehculos de
tamao normal. De aqu se puede inferir la regla de que 1 camin equivale a
entre 2 y 3 vehculos de tamao normal a la hora de contabilizar vehculos
por este algoritmo.
~ 47 ~
En caso contrario, el nmero de pxeles es estudiado en funcin de su

posicin ya que es muy importante la posicin en la que se encuentre la
componente que se est estudiando. No es lo mismo 3.000 pxeles en la
parte de alta (lejana) del carril, ya que podran ser dos vehculos, que 3.000
pxeles en la parte baja (cercana) del carril, ya que solamente puede ser un
vehculo de bajo tamao.
Volumen = 2.331 pxeles
Volumen = 9.769 pxeles
Figura 29. Imagen que muestra el volumen en pxeles de dos vehculos
132
longitudActual = caracRegion(indice).BoundingBox(4);
133
if(longitudActual > longitud)
134
longitud = longitudActual;
135
end
136
137
if(longitud > 550)
138
longNecesaria = 50;
139
vehiculosEsperandoLongitud = vehiculosEsperandoLongitud +
140
floor(longitud / longNecesaria);
141
142
143

if(longitud >= 40)
144
longNecesaria = 30;
145
146
147
elseif (longitud > 20)
~ 48 ~
148
149
vehiculosEsperandoLongitud = vehiculosEsperandoLongitud + 1;
end
150
151
152

if(longitud >= 55)
153
longNecesaria = 45;
154
155
156
157
158
end
159
160
161

if(longitud >= 60)
162
longNecesaria = 60;
163
164
165
166
167
end
168
169
170
elseif(filas >=250 && filas < 300)

if(longitud >= 65)
171
longNecesaria = 80;
172
173
174
175
176
elseif(longitud > 30)
end
177
178
179
elseif(filas >=300)
if(longitud >= 150)
~ 49 ~
180
longNecesaria = 150;
181
182
elseif(longitud > 30)
183
184
end
185
end
186
187
188
end
end
En un proceso anlogo al anterior, se procede a contabilizar de otra manera los

vehculos detectados. Primeramente, calcula la altura del rectngulo que mejor
envuelve a la componente que se est procesado. Una vez obtenido ese valor de
altura del elemento se hace una primera comprobacin con un valor de altura
elevado, concretamente 550. Este valor es un valor estimado de altura para un
elemento de un tamao muy grande, tales como autobuses o camiones largos.
En el caso de superar ese valor de 550, la altura es dividida entre 50, valor de
altura media de un vehculo para transformar ese posible vehculo de gran
tamao en varios vehculos de tamao normal. De aqu tambin se puede
inferir que 1 camin equivale a entre 2 y 3 vehculos de tamao normal a la
hora de contabilizar vehculos por este algoritmo.
En caso contrario, el valor de la altura tambin es estudiada en funcin de
su posicin ya que otra vez se concluye que es muy importante la posicin
en la que se encuentre la componente que se est estudiando. No es lo
mismo 80 pxeles de altura en la parte de alta (lejana) del carril, ya que
podran ser dos vehculos, que esos mismos 80 pxeles de altura en la parte
baja (cercana) del carril, ya que solamente puede ser un vehculo de bajo
tamao.
~ 50 ~
Longitud = 55 pxeles
Longitud = 143 pxeles
Figura 40. Imagen que muestra la longitud en pxeles de dos vehculos
189
vehiculosDetectados = ((vehiculosEsperando + vehiculosEsperandoLongitud)/2);
190
vehiculosDetectados = ceil(vehiculosDetectados);
Ya que la manera de contabilizar se ha realizado por medio de dos mtodos

diferentes: mediante el clculo del nmero de pxeles y, mediante el clculo de la
altura del elemento, ambas formas de contabilizar vehculos deben ser
unificadas. Una manera de hacerlo es mediante las dos lneas anteriores, con una
simple media y un redondeo hacia arriba. Como se puede comprobar en la
evaluacin de este algoritmo, los resultados de deteccin de vehculos en
entornos de da son excelentes ya que las dos maneras de contabilizar coinciden
en la amplia mayora de casos y la media que se realiza no tiene efecto. Por
ltimo, es necesario destacar que el redondeo se hace hacia arriba ya que es
mejor detectar de ms que no detectar, ya que como se estudia en el sistema de
toma de decisiones, si no hay elementos detectados en las vas, los semforos se
encontrarn en rojo para la libre circulacin de los peatones.
191
[labelledMedia,nComponentsMedia] = bwlabel(carrilMediaFinal);
192
bbElementosMedia = regionprops(labelledMedia,'BoundingBox');
193
194
for indiceElemento=1:nComponentsMedia
195
196
boundingBox = bbElementosMedia(indiceElemento).BoundingBox;
~ 51 ~
197
boundingBox = floor(boundingBox);
198
elementoMedia = carrilMediaFinal(boundingBox(2)-
199
10:boundingBox(2)+boundingBox(4)+10,...
boundingBox(1)-10:boundingBox(1)+boundingBox(3)+10);
200
201
elementoActual = carrilFinal(boundingBox(2)-
202
203
10:boundingBox(2)+boundingBox(4)+10,...
boundingBox(1)-10:boundingBox(1)+boundingBox(3)+10);
204
205
if(sum(sum(elementoActual)) / sum(sum(elementoMedia)) > 0.9)
206
207
if(sum(sum(elementoActual)) > 1500 && sum(sum(elementoActual) < 6000))
208
209
210
errorElementos = sum(sum(xor(elementoActual,elementoMedia)));
211
if((errorElementos > 1500) && (errorElementos < 2000) || errorElementos
212
== 0)
213
if(vehiculosEsperando > 0)
214
vehiculosEsperando = vehiculosEsperando - 1;
215
216
end
217
if(vehiculosEsperandoLongitud > 0)
vehiculosEsperandoLongitud = vehiculosEsperandoLongitud - 1;
218
end
219
end
220
end
221
end
222
223
224
end
end
Para finalizar, tal y como se concluyo en apartados anteriores, es necesario

eliminar elementos estacionarios que se encuentran en la calzada tales como
flechas, seales impresas, bolardos... Para tal fin, las anteriores lneas de cdigo
~ 52 ~
realizan la comparacin de cada elemento detectado con los elementos

detectados en la imagen del carril de estudio pero sin vehculos. Por ejemplo, se
comprobarn las flechas detectadas en la imagen sin vehculos con cada
elemento detectado en la imagen con vehculos para no confundir la morfologa
de las flechas con la morfologa de los vehculos. La manera de discrepar entre
por ejemplo, flecha y vehculo, se realiza de la siguiente manera:
- Primero se comprueba si hay el mismo nmero de pxeles de manera
proporcionada entre los dos elementos.
- En segundo lugar se comprueba si el tamao se encuentra entre los lmites
establecidos de 1.500 y 6.000 pxeles, de elementos no estacionarios en un carril
por donde circulan vehculos.
- Por ltimo, mediante la operacin lgica XOR se mide el rango del error al hacer
la operacin lgica entre los dos elementos.
Si se han pasado las tres condiciones anteriores, se resta un vehculo detectado
ya que se haba contabilizado como vehculo un elemento estacionario del carril.
En la siguiente figura se muestra el tratamiento de una imagen real, donde slo
interviene una flecha y es eliminada, por tanto no contabilizada.
Figura 41. Resultado que devuelve este algoritmo demostrando la no contabilizacin de elementos
estacionarios en la calzada
~ 53 ~
A modo de resumen de todas las rutinas presentadas a lo largo del anterior cdigo
fuente, se acompaa la siguiente figura que es el resultado de aplicar el algoritmo
de da sobre otra imagen real, tomada con una cmara IP instalada en un semforo.
A la izquierda se encuentra la imagen resultado tras la ejecucin del algoritmo y a la
derecha se encuentra la imagen original completa. Bajo ambas imgenes se
encuentran los resultados numricos de la deteccin de vehculos, con una
comparacin de ambos resultados entre el nmero que devuelve este algoritmo y
los vehculos que se encuentran en realidad presentes en el carril de estudio,
habiendo sido introducidos estos valores de realidad de manera manual previa a
la ejecucin del algoritmo.
Figura 42. Resultado de aplicar el algoritmo de deteccin de vehculos en entornos de da
~ 54 ~
6.4 Evaluacin del algoritmo de deteccin de

vehculos de da
En funcin de un exhaustivo proceso de evaluacin del algoritmo presentado se
concluye que la fiabilidad de este es satisfactoria y muestra robustez cuando varias
situaciones con distintas orientaciones y luminosidad de las imgenes son
evaluadas.
Utilizando una muestra de 417 imgenes obtenidas en una interseccin real

utilizando cmaras IP situadas en la parte ms alta de los semforos, se consigue la
siguiente grfica de aciertos / fallos a la hora de detectar vehculos.
Figura 43. Grfica de evaluacin del algoritmo de deteccin de vehculos en entornos de da. Evaluacin
realizada sobre 417 imgenes
Como se ha comentado, el conjunto de imgenes son reales y fueron

obtenidas en la interseccin sita en la ciudad de Talavera de la Reina tal y como
muestra la siguiente figura:
~ 55 ~
Calle
Alfares
Calle
Mesones
Figura 44. Mapa de situacin de la interseccin de donde proceden las imgenes para la evaluacin del
algoritmo de deteccin de vehculos en entornos de da
Ejemplos de imgenes de cada uno de los semforos donde fueron

instaladas las cmaras son las siguientes:
Calle Alfares
Carretera CM-4101
Calle Mesones
Figura 45. Conjunto de imgenes de ejemplos de las capturas realizadas en la interseccin
~ 56 ~
El nmero medio de vehculos en este conjunto de imgenes se encuentra

entre 2 y 3 vehculos. Adems se presentaron varias situaciones de alta densidad de
vehculos, confirmando la fiabilidad y robustez de este algoritmo.
A continuacin se muestra una de las pocas imgenes donde el algoritmo

propuesto comete un error a la hora de detectar el nmero de vehculos que se
encuentran en la interseccin. Como se puede comprobar, el algoritmo detecta
satisfactoriamente el vehculo que entra por la parte izquierda de la imagen y as
mismo tambin detecta correctamente el vehculo que se aproxima por la parte
superior del carril. Sin embargo, el vehculo que est desapareciendo de la imagen
para introducirse en la interseccin no es detectado.
Figura 46. Captura del algoritmo fallando en la deteccin de vehculos usando el algoritmo en entornos de
da
La causa de este fallo radica esencialmente en la eleccin del carril de

estudio. Este carril elegido recoge muy poca parte del vehculo que no es detectado,
ya que se intenta recortar siguiendo al mximo posible los lmites establecidos por
las lneas divisoras de los carriles con el fin de no contabilizar vehculos que no
intervienen en la interseccin.
~ 57 ~
A consecuencia del poco tamao del citado vehculo, la parte del algoritmo
recogido en las lneas 24 y 25 del cdigo anteriormente explicado, elimina las partes
del vehculo que no se detecta.
La situacin que aqu se comenta es particular y aislada. La deteccin falla en

este punto pero en la imagen anterior y en la siguiente, el algoritmo no comete
error y por tanto minimiza el impacto de este fallo.
~ 58 ~
6.5 Algoritmo de deteccin de vehculos de noche

De forma similar a lo desarrollado a lo largo del apartado anterior de este
documento, a continuacin se presenta el cdigo fuente en entorno de desarrollo
MATLAB para la deteccin de vehculos durante la noche. Junto con la descripcin
se va incluyendo el cdigo y se van aadiendo imgenes para clarificar el proceso.
Tal y como se ha explicado en los apartados 6.1.3 y 6.1.4 del presente documento,
este algoritmo se basa en la discrepancia por luminosidad para detectar los faros de
los vehculos que aparecen en las imgenes.
El siguiente cdigo es continuacin del cdigo mostrado en el apartado 6.3

ya que todo junto forma la funcin TEA completa, de ah que la numeracin de
lneas contine donde termin la anterior.
Como paso previo a procesar la imagen, el carril de estudio debe ser

recortado como se procedi en apartados anteriores. Como resultado se encuentra
la siguiente figura que incluye la imagen original y otra imagen con el carril de
estudio ya recortado.
Figura 47. Pareja de imgenes que muestran la imagen real y la imagen que se va a procesar una vez
recortado el carril de estudio
Una vez recortado el carril de estudio, se procede a ejecutar el algoritmo de

deteccin de vehculos en entornos de noche.
~ 59 ~
225
226
if(strcmp(algoritmo,'Noche'))
carrilFaros = carril>245;
El primer paso es realizar un proceso de binarizacin. Este proceso consiste en

seleccionar slo los pxeles que superen un cierto nivel de luminosidad, concepto
base en la deteccin por discrepancia de luminosidad. El valor de 245 es un valor
bastante alto y que filtra demasiado pero se concluye que es el correcto tras
varias pruebas realizadas. Depende bastante de la instalacin pero ese valor de
245 ha mostrado resultados fiables ante varios escenarios. En la siguiente figura,
se muestra una imagen real y junto a ella, la imagen binarizada con el valor de
245 como umbral de binarizacin. Como se puede comprobar, se consigue el
primer objetivo de este algoritmo al quedarse slo con los faros de los vehculos y
con algo de ruido, que ser eliminado posteriormente.
Figura 48. Imgenes que muestran el resultado del proceso de binarizacin. A la izquierda el carril de
estudio original, a la derecha el carril binarizado.
227
carrilFinal = bwareaopen(carrilFaros,400);
Tal y como se comprueba en la pareja de imgenes anteriores, el proceso de

binarizacin es efectivo pero deja restos de elementos (brillos) que tambin
tienen una luminosidad que supera el umbral de binarizacin. Por esta razn, es
necesario un proceso de eliminacin de esos elementos de ruido que son en su
mayora reflejos que producen los faros de los vehculos sobre otros vehculos,
sobre la calzada, o sobre otros elementos anexos a ellos. Mediante la funcin
bwareaopen, que ya haba sido utilizada para el algoritmo de deteccin de
~ 60 ~
vehculos en entorno de da, se eliminan aquellos elementos que no superen

cierto tamao. En el caso del entorno de noche, se consideran 400 pxeles como
el tamao mnimo que debe tener un faro de un vehculo para poder ser
clasificado. Elementos mayores de 400 pxeles son aceptados tambin ya que
como se puede comprobar en el siguiente par de imgenes, hay elementos que
son faros de un vehculo y tambin parte del gran reflejo que hacen sobre el
vehculo que le precede. Este valor de 400 pxeles es el ptimo para imgenes de
640x480, imgenes que suele devolver una cmara IP.
Figura 39. Imgenes que muestran el proceso de limpieza de elementos que no superan el tamao mnimo
en pxeles para los faros de un vehculo
228
[labelled,nComponents] = bwlabel(carrilFinal);
Usando la funcin bwlabel, se identifican todos los elementos detectados para

que sean procesados de manera independiente. En la siguiente figura se
encuentran coloreados con distintos tonos los distintos elementos.
Figura 50. Imgenes donde se muestra el resultado de aplicar la funcin bwlabel, identificado cada
elemento de manera independiente.
~ 61 ~
229
vehiculosDetectados = 0;
230
arrayIndicesProcesados = zeros(nComponents,1);
231
Una vez identificados de manera independiente todos los elementos de la imagen

que se quieren procesar, se procede a iterar sobre ellos para comprobar segn,
su morfologa y posicin, si corresponden a los faros de los vehculos que se
buscan. Se puede comprobar que en las lneas anteriores tambin se inicializan
las variables para el conteo de vehculos.
232
if( arrayIndicesProcesados(indice) == 0 )
233
234
[filas, colum] = find(labelled == indice,1,'last');
235
236
237
238
239
if(filas >= 0 && filas < 50)

pxNecesarios = 300;
else
240
end
241
if( length(find(labelled == indice)) > pxNecesarios)
242
vehiculosDetectados = vehiculosDetectados + 1;
243
244
245
246
continue;
end
Como primer paso en la deteccin de faros de vehculos, se comprueba si los

elementos exceden de un tamao lmite. Como por ejemplo puede pasar cuando
los faros de un vehculo se unen al reflejo que causan sobre el vehculo que tiene
delante. En este caso dicho elemento es ya contabilizado como vehculo y no ser
tenido en cuenta en los siguientes procesos de clasificacin como faros de
vehculos. La siguiente figura muestra un ejemplo de ello.
~ 62 ~
Contabilizados como vehculos

porque sus volmenes son 2.269
pxeles (arriba) y 6.337 pxeles
(abajo). Estos volmenes superan el
lmite impuesto de 800 pxeles.
Figura 51. Imagen donde se muestra el volumen excesivo de dos faros independientes, por lo cual son
contabilizados como vehculos por s mismos.
247
248
for indiceNoVisitado=1:nComponents
if(arrayIndicesProcesados(indice) == 0 &&
249
arrayIndicesProcesados(indiceNoVisitado) == 0 && indice ~= indiceNoVisitado
250
&& indice < indiceNoVisitado)
251
252
[filasIzqFirst, columIzqFirst] = find(labelled == indice,1,'first');
253
[filasIzqLast, columIzqLast] = find(labelled == indice,1,'last');
254
filasIzq = floor( (filasIzqFirst + filasIzqLast) / 2);
255
columIzq = floor( (columIzqFirst + columIzqLast) / 2);
256
[filasDerFirst, columDerFirst] = find(labelled ==
257
258
259
indiceNoVisitado,1,'first');
[filasDerLast, columDerLast] = find(labelled ==
indiceNoVisitado,1,'last');
260
filasDer = floor( (filasDerFirst + filasDerLast) / 2);
261
columDer = floor( (columDerFirst + columDerLast) / 2);
262
263
difFilas = abs(filasDer - filasIzq);
264
difColum = abs(columDer - columIzq);
265
separacion = abs(difColum - difFilas);

~ 63 ~
266
if(filasDer > 185 || filasIzq > 185)
267
268
separacionOK = 10;
269
difFilasOK = 40;
270
difColumnasOK = 100;
else
271
272
separacionOK = 5;
273
difFilasOK = 10;
274
difColumnasOK = 100;
end
275
276
if(difFilas > -1 && difFilas < difFilasOK && difColum > -1 &&
277
278
difColum < difColumnasOK && separacion > separacionOK)
279
280
281
arrayIndicesProcesados(indiceNoVisitado) = 1;
282
break;
283
end
284
end
285
end
286
287
288
end
end
En el caso de que los elementos detectados no cumplan la restriccin sobre el

volumen detallada anteriormente, se procesan los elementos buscando posibles
parejas de elementos que coincidan con los faros de un vehculo. Este proceso
evita clasificar como faros ciertos brillos que pueden superar el tamao del
filtrado inicial. Para ello, primeramente se calculan los centros de gravedad de los
elementos y se calculan las distancias entre ellos. Si las distancias calculadas
estn en un rango especificado se pueden contabilizar como parejas de faros de
un vehculo y por tanto aadir un vehculo a la cuenta de vehculos detectados. El
rango de distancias permitidas para ser clasificada una pareja de elementos como
faros de un vehculo, est determinada en funcin de su posicin ya que existe
un problema de escalado. No es lo mismo la distancia de separacin que hay
entre dos faros en la parte alta del carril (muy reducida), que la distancia de
~ 64 ~
separacin que hay entre dos faros en la parte baja del carril (muy amplia). En el
siguiente par de imgenes se demuestra como la separacin es muy distinta
segn la posicin. A la izquierda se encuentra la imagen original y a la derecha los
faros detectados y las distancias entre dos parejas de faros.
Figura 52. Par de imgenes para comprobar cmo la distancia entre faros depende de la posicin donde se
encuentren.
289
290
if( arrayIndicesProcesados(indice) == 0)
291
292
[filasFirst, columFirst] = find(labelled == indice,1,'first');
293
[filasLast, columLast] = find(labelled == indice,1,'last');
294
filas = abs(filasLast-filasFirst);
295
296
if( filasFirst < 110 )

separacionOK = 10;
297
298
else
separacionOK = 30;
299
300
end
301
302
if(nComponents > 2 && indice > 1 && indice+1<=nComponents)

[filasLastSiguiente, columLastSiguiente] = find(labelled ==
303
304
indice+1,1,'last');
305
separacionFilasSiguiente = abs(filasLast-filasLastSiguiente);
306
[filasLastAnterior, columLastAnterior] = find(labelled == indice-
307
308
309
310
1,1,'last');
separacionFilasAnterior = abs(filasLast-filasLastAnterior);
else
separacionFilasSiguiente = separacionOK+1;
~ 65 ~
separacionFilasAnterior = separacionOK+1;
311
end
312
313
if( filas < 13 && filasFirst < 250 && columFirst < 250 &&
314
315
separacionFilasSiguiente > separacionOK && separacionFilasAnterior >
316
separacionOK)
317
318
end
319
320
321
end
end
El proceso que se incluye en el cdigo fuente anterior se basa en la clasificacin

como vehculo a faros que se encuentran aislados. Esto se aplica a casos de
vehculos muy juntos, vehculos que existen delante de l tapan la pareja de faros
y slo dejan ver a uno de ellos. Este proceso es de vital importancia para
contabilizar de manera efectiva el nmero de vehculos que estn esperando a
acceder a la interseccin ya que se suelen colocar en fila juntndose unos
vehculos con otros, haciendo bastante difcil su deteccin si no se realiza un
proceso como este. En la siguiente figura, se muestran dos imgenes, la original a
la izquierda con 8 vehculos presentes en ella, y a la derecha la imagen resultado
al aplicar este algoritmo donde aparecen slo 6 parejas de faros de vehculos
pero como resultado del proceso anteriormente citado se contabilizan 8
vehculos.
Figura 53. Pareja de imgenes que muestran la situacin de faros de vehculos ocultos por vehculos
delante de ellos.
~ 66 ~
322
imagenResultado = label2rgb(labelled);
323
carrilCorrelacion = carrilFinal;
324
end
Para finalizar el proceso de deteccin de vehculos en entornos de noche, se

devuelve como resultado la imagen con los elementos detectados por el proceso
digital de imgenes. As mismo se devuelve el carril para el estudio de
correlacin, denominado final, donde se encuentran solamente los elementos
detectados por este algoritmo, para que en procesos posteriores pueda hacerse
la estimacin de la velocidad de los vehculos que aparecen en la calzada. En la
siguiente imagen se incluye el resultado de aplicar este algoritmo sobre una de
las fotos usadas anteriormente como ejemplo. Se comprueba la fiabilidad del
algoritmo propuesto ya que contabiliza satisfactoriamente como vehculo
aquellos faros ocultos por otros vehculos, cuenta el primer vehculo donde los
faros se juntan con el brillo del parachoques, y evitar contar el brillo del techo del
primer vehculo.
Figura 54. Captura del resultado de aplicar el algoritmo de deteccin de vehculos en entorno de noche a
una imagen donde algunos faros de vehculos estn tapados por otros vehculos.
~ 67 ~
6.6 Evaluacin del algoritmo de deteccin de

vehculos de noche
De manera anloga a lo realizado en el apartado 6.4 de este documento, se evala
el algoritmo en entornos de noche. Gracias a este proceso de evaluacin del
algoritmo propuesto se concluye que la fiabilidad es satisfactoria y muestra
robustez cuando varias situaciones con distintas condiciones de las imgenes son
presentadas.
Para evaluar este algoritmo, se han utilizado 68 imgenes utilizando una

cmara de fotos convencional situada a una altura similar a la que posee un
semforo con abrazadera, unos 5 metros, con el fin de asemejar al mximo posible
las condiciones de altura que debe soportar una cmara instalada en un semforo
de este estilo. Como resultado, la grfica de fiabilidad al usar el algoritmo sobre las
imgenes citadas, es la siguiente:
Figura 45. Grfica de evaluacin del algoritmo de deteccin de vehculos en entornos de noche. Evaluacin
realizada sobre 68 imgenes
El tamao de la muestra no es insuficiente ya que como se puede comprobar

en el apartado 9 de esta memoria, este algoritmo ha sido utilizado para realizar las
pruebas en un entorno real obteniendo resultados muy satisfactorios.
~ 68 ~
El conjunto de imgenes para la muestra de evaluacin son tambin

tomadas en un entorno real y han sido obtenidas en la posicin que indica el
siguiente mapa de Talavera de la Reina.
Figura 56. Mapa de situacin desde donde se tomaron las fotos para la evaluacin del algoritmo de
deteccin de vehculos en entornos de noche
Un par de ejemplos que muestran la altura desde donde se tomaron las

imgenes se encuentran representados en la siguiente figura.
Figura 57. Pareja de imgenes que muestran ejemplos de la altura desde la que fueron tomadas las
imgenes para la evaluacin del algoritmo de deteccin de vehculos en entornos de noche
El nmero medio de vehculos que se encontraban en este conjunto de

imgenes de test es aproximadamente entre 5 y 7 vehculos. Adems se
presentaron varias situaciones de alta densidad de vehculos, confirmando la
fiabilidad y robustez de este algoritmo.
~ 69 ~
A continuacin se muestra una de las pocas imgenes donde el algoritmo

propuesto comete dos errores a la hora de detectar el nmero de vehculos que se
encuentran en la imagen proporcionada. Tras realizar el conteo de vehculos que
existen en realidad en la imagen, se puede comprobar que el resultado es de 8.
Pero el algoritmo propuesto slo detecta 6 como se detalla en la siguiente figura.
Figura 58. Captura del algoritmo fallando en la deteccin de vehculos usando el algoritmo en entornos de
noche
El primer vehculo que no detecta es la furgoneta que aparece en la parte

inferior del carril en la imagen original. La razn de la no deteccin es obvia, no
aparecen los faros de esta furgoneta en la imagen original y este algoritmo
propuesto para la deteccin de vehculos en entornos de noche se basa en la
deteccin de faros. Se trata de un problema de montaje de la cmara IP, para poder
observar con mayor exactitud todo el carril en toda su extensin. Otra opcin sera
colocar los semforos tal y como se encuentran dispuestos en Amrica, una vez ya
cruzada la interseccin.
El segundo vehculo que no detecta es aquel que sus faros se encuentra

totalmente tapados por otro vehculo que est delante de l. Como el problema
anterior, es insalvable a no ser que se posicionen las cmaras de una manera
estratgica para capturar toda la dimensin del carril.
~ 70 ~
Las situaciones que aqu se comentan son particulares y aisladas. La

deteccin falla en este punto pero en la imagen anterior y en la siguiente, el
algoritmo no comete error y por tanto minimiza el impacto de este fallo.
De los errores aqu expuestos, nacen las conclusiones detalladas en el

captulo 7 de esta memoria, donde se detallan posibles mejoras que se pueden
llevar a cabo para aumentar, la robustez de las soluciones que se proponen en este
proyecto y hacerlo ms verstil para un mayor nmero de escenarios.
~ 71 ~
6.7 Estimacin de la velocidad de vehculos que

se aproximan a la interseccin
Este mdulo tambin pertenece y complementa al subsistema de tratamiento
digital de imgenes. En un primer momento no estaba previsto que se realizase
pero se ha credo conveniente ya que introduce la capacidad de estimar la velocidad
de los vehculos que aproximan a la interseccin. Esta informacin permite saber si
se puede llegar a producir una colisin de un vehculo con otro en la interseccin en
el caso de que alguno de ellos cruce la interseccin sin el permiso concedido por
los semforos.
La deteccin de vehculos en movimiento se basa en el concepto del estudio

de la correlacin existente entre dos imgenes consecutivas. Este concepto consiste
en obtener dos imgenes separadas por muy poco espacio de tiempo para calcular
el desplazamiento de los objetos de las imgenes. La manera de calcular de la
separacin existente entre las dos imgenes en el intervalo de tiempo especificado
se realiza a travs de un desplazamiento iterativo y continuo, segn unos
parmetros de direccin de desplazamiento fijados, y midiendo en cada iteracin el
nivel de correlacin. El clculo se realiza sobre el resultado de la deteccin de
bordes horizontales.
Para reforzar el concepto de estudio de correlacin, la siguiente imagen

recoge un ejemplo de distintos desplazamientos. Las lneas rojas, corresponden al
primer fotograma, son las estticas (no se mueven para poder ser comparadas), y
las lneas negras, corresponden al segundo fotograma y son las que se van
desplazando hasta alcanzar la correlacin, marcada en color verde. Como se puede
comprobar la sub-imagen que se encuentra en el centro es donde se alcanza el
mayor valor de fitness entre imgenes las dos imgenes. El resto de imgenes que
las rodean son los desplazamientos previos y posteriores a la localizacin del
desplazamiento exacto para alcanzar el mayor grado de correlacin.
~ 72 ~
Figura 59. Imagen que muestra distintos desplazamientos hasta alcanzar el mximo grado de fitness
La siguiente figura presenta, a modo de resumen, un esquema que incluye

las entradas, parmetros de configuracin y las salidas de este mdulo.
Carriles para
estudio de
correlacin
MATLAB
Image Processing Toolbox
Parmetros:
-Recta de movimiento
de los vehculos
-Zona de estudio de
correlacin
Estimacin velocidad
Figura 60. Esquema de funcionamiento del mdulo de deteccin de vehculos en movimiento
~ 73 ~
La entrada a este mdulo son una secuencia de imgenes separadas por

muy poco espacio de tiempo entre ellas, siendo este valor de tiempo aproximado ya
que las cmaras introducen un retardo no fijo entre la captura de imgenes a lo que
hay que sumarle el retardo producido por su transferencia a travs de
interconexin wireless. Estas imgenes no son imgenes completas, sino los carriles
preparados para el estudio de correlacin obtenidos con el mdulo de deteccin de
vehculos que se aproximan a la interseccin.
Como resultado, se encuentra la estimacin de la velocidad, estimacin de

manera cuantitativa de la velocidad (aunque no exacta) que lleva el vehculo
situado en la zona de estudio de correlacin indicada como parmetro a este
algoritmo. An siendo esta estimacin de baja precisin, los resultados se han
discretizado en un rango amplio: parado, muy despacio, despacio, deprisa, muy
deprisa. En funcin a este resultado, el sistema de toma de decisiones tiene en
cuenta este factor para la regulacin semafrica ptima.
La estimacin de la velocidad tambin se puede realizar de manera precisa.

Para este fin, solamente es necesario incorporar la fase de clculos trigonomtricos
pertinentes teniendo en cuenta la altura a la que la cmara ha sido instalada y la
correspondencia entre pxeles/metros segn la instalacin de la cmara.
Los parmetros necesarios que indica la figura de este mdulo son los
siguientes:
Recta de movimiento de los vehculos: es estrictamente necesario la
especificacin de una recta que indique la direccin del movimiento que
realiza un vehculo en el carril en el que se encuentra. La recta de
movimiento de vehculos se utiliza para simular el desplazamiento de
fotogramas hasta obtener un buen grado de solape. Si se especifica
errneamente, el estudio de correlacin resulta en valores no fehacientes y
no podr facilitar la estimacin cualitativa que pretende. A continuacin se
muestran los resultados correspondientes al ejemplo de la figura 60 tras una
~ 74 ~
introduccin errnea de los parmetros de la recta de movimiento de los

vehculos.
Figura 61. Imagen que muestra los resultados errneos tras introducir los parmetros de la recta de
manera incorrecta
Como se puede comprobar, en ningn momento llegan a coincidir los

elementos rojos (estticos) con los elementos en negro (que se estn
desplazando).
Los parmetros de la recta no requieren de complicadas funciones
matemticas para su clculo. En general, basta con situar dos puntos para
formar una recta que divida en dos partes iguales al carril de estudio. Con
esos dos se pueden inferir los parmetros que forman una recta que pasa
por esos dos puntos para despus introducirlos como parmetros del
algoritmo propuesto. La siguiente imagen muestra un ejemplo de recta que
marca la direccin que siguen los vehculos en ese determinado carril.
Figura 62. Imagen que muestra un ejemplo de recta de direccin de los vehculos en cierto carril
~ 75 ~
Zona de estudio de correlacin: el segundo y ltimo parmetro a introducir

para el correcto funcionamiento del algoritmo propuesto, es la
especificacin de un cuadrado que recoja la zona de estudio de correlacin.
Al igual que el anterior parmetro, es de vital importancia para poder
obtener resultados fehacientes y correctos para la estimacin cualitativa de
la velocidad. A estos efectos se concluye que es correcta la especificacin
como zona de estudio de correlacin, una zona de las imgenes donde
confluyan bastantes bordes. Una de ellas, y la utilizada para la elaboracin
de la evaluacin de este algoritmo, es la zona de la matrcula y el frontal del
vehculo. Una especificacin errnea de la zona de estudio de correlacin,
da como resultado pocos bordes para poder evaluar el grado de correlacin
entre dos imgenes consecutivas, tal y como muestra la siguiente imagen.
Figura 63. Imagen que muestra el escaso nmero de bordes al especificar de manera errnea la zona de
estudio de correlacin
Para introducir, como parmetro de este algoritmo, la zona de estudio de

correlacin basta con especificar un punto para realizar un cuadrado de 100
pxeles por pxeles a partir de este punto. La siguiente figura muestra una
imagen con el cuadrado alrededor de la zona donde confluye la matrcula y
~ 76 ~
el frontal del vehculo ya que esta zona ha sido citada por poseer muchos
bordes y ser ptima para realizar el estudio de correlacin.
Figura 64. Imagen que muestra una zona de estudio de correlacin ptima al ser zona donde existen
muchos bordes
En el siguiente aparatado se va a detallar como se integran, las entradas,

parmetros y resultados anteriormente expuestos en el cdigo fuente del algoritmo
propuesto.
~ 77 ~
6.8 Algoritmo para la estimacin de la velocidad

de vehculos que se aproximan a la interseccin
A continuacin se muestra el cdigo fuente en entorno de desarrollo MATLAB para
estimar de manera cualitativa la velocidad de los vehculos que se aproximan a la
interseccin. De forma paralela, se aaden un conjunto de imgenes para ilustrar el
proceso.
Es importante destacar que la siguiente funcin es una funcin que debe ser
retro-alimentada para alguno de sus argumentos. La primera ejecucin recibe como
argumentos lo siguiente:
luminosidadesMedias: matriz de 1 fila y tres columnas con los tres valores a
cero para que vayan siendo rellenados a lo largo de su ejecucin.
carrilEnMomentoAnterior: matriz del tamao de las imgenes que captura la
cmara IP pero con todos sus valores a cero. Esta matriz cambia sus valores
tambin a lo largo de la ejecucin de esta funcin.
indiceImagen: entero con valor igual a 1 para poder llevar una cuenta del
nmero de imgenes procesadas y que sus luminosidades medias pueden
ser guardadas en el vector de luminosidadesMedias en su correspondiente
orden. Este ndice ser incrementado a lo largo de la ejecucin de esta
funcin.
Los argumentos que deben ser retro-alimentados son luminosidadesMedias y
carrilEnMomentoAnterior.
Las salidas o resultados de este algoritmo son las siguientes:

carrilEnMomentoT: devuelve el carril recin tratado en el estudio de
correlacin para que sea tratado en la siguiente iteracin.
luminosidadesMedias: vector con datos de las luminosidades medias de
las tres ltimas imgenes procesadas.
vehiculosDetectados: nmero entero con el nmero de vehculos
detectados para esa iteracin. Este valor ser devuelto al sistema de
~ 78 ~
toma de decisiones para elaborar la decisin ptima de regulacin

semafrica para ese momento.
indiceMaximo: nmero entero con el desplazamiento necesario para
alcanzar el mayor valor de fitness. Comprende un valor de 1 a 30. Este
valor es tambin pasado al sistema de toma de decisiones para la
creacin de la decisin ptima para ese instante.
imagenResultado: imagen que resulta tras todo el tratamiento de
imgenes realizado a la imagen original. Es devuelta al sistema de toma
de decisiones para ser mostrada por pantalla con efectos de control y
supervisin.
imagenOriginal: imagen sin tratar, tal cual fue obtenida de la cmara IP.
Enviada con efectos de control y supervisin.
La forma de retro-alimentar los argumentos con las salidas o resultados del
algoritmo propuesto se hace tal y como indica el siguiente esquema:
carrilEnMomentoAnterior
luminosidadesMedias
indiceImagen
Algoritmo
Estimacin
Velocidad
carrilEnMomentoT
vehiculosDetectados
indiceMaximo
imagenResultado
imagenOriginal
luminosidadesMedias
Figura 65. Esquema que representa la forma de retro-alimentacin de ciertas variables que intervienen en
el algoritmo de estimacin de velocidad
Como se puede comprobar en la figura anterior, existen dos parejas de

variables que deben ser retroalimentada
~ 79 ~
carrilEnMomentoAnterior y carrilEnMomentoT: variables que guardan

distintos carriles de correlacin para que intervengan en el estudio de
correlacin de manera conjunta.
luminosidadesMedias: vector de tres valores que van cambiando segn
nuevas imgenes son procesadas para tomar la decisin de que algoritmo de
deteccin vehculos usar.
En el cdigo mostrado a continuacin se puede comprobar cmo se integran

todas las variables anunciadas anteriormente.
function [carrilEnMomentoT, luminosidadesMedias, vehiculosDetectados,
indiceMaximo, imagenResultado, imagenOriginal] =
ProcesarFotosOnline(luminosidadesMedias, carrilEnMomentoAnterior,
indiceImagen)
Tal y como se ha especificado en los anteriores prrafos, las salidas de este

algoritmo y los argumentos son los que declara la funcin ProcesarFotosOnline
que se acompaa. Los tipos de datos de cada variable que interviene en la
definicin son los siguientes:
carrilEnMomentoT => matriz lgica de tamao el de la imagen capturada
por la cmara IP.
luminosidadesMedias => matriz de enteros de 1 fila y 3 columnas.
vehiculosDetectados => entero.
indiceMaximo => entero.
imagenResultado => matriz de enteros de tamao el de la imagen
capturada por la cmara IP.
imagenOriginal => matriz de enteros de tamao el de la imagen capturada
por la cmara IP.
carrilEnMomentoAnterior => matriz lgica de tamao el de la imagen
capturada por la cmara IP.
indiceImagen => entero.
~ 80 ~
carrilCoordX = [640 250 217 495 640];
carrilCoordY = [452 82 91 480 480];
mRecta = 1.1458;
bRecta = 15.9430;
zonaCorrelacionPuntoY = 280;
10
zonaCorrelacionPuntoX = 220;
11
correlacion = 0;
Los parmetros necesarios para un proceso efectivo de estimacin de la

velocidad son los que aqu se recoge. Es muy importante conocer que estos
parmetros se han establecido para un entorno concreto ya que dependen de las
condiciones de altura y posicin a la hora de la instalacin de la cmara. Adems
las variables locales han sido inicializadas para incrementar la velocidad de
proceso. La siguiente imagen recoge como se aplican los parmetros anteriores,
para recortar el carril de estudio, situar la recta de direccin (en rojo) que siguen
los vehculos y situar la zona de estudio de correlacin (en azul).
Figura 66. Imagen que representa los efectos de la aplicacin de los parmetros necesarios para la
correcta estimacin de la velocidad
~ 81 ~
12
imagenOriginal = imread('http://192.168.0.21/axis-
13
cgi/jpg/image.cgi?resolution=640x480&color=1&compression=60');
14
imagen = rgb2gray(imagenOriginal);
En la anterior pareja de instrucciones se obtiene la imagen desde la cmara IP y

se pasa a escala de grises. La forma de obtener la imagen desde la cmara IP es a
travs de un servidor WEB que lleva incorporado dicha cmara IP. Con otros
modelos / fabricantes, la forma de obtener las imgenes puede variar. Pero lo
comn es que deben ser ledas por MATLAB usando la funcin imread.
15
luminosidadesMedias(mod(indiceImagen-1,3) + 1) = mean(imagen(:));
16
acumuladorDiferencias = abs(luminosidadesMedias(2) - luminosidadesMedias(1));
17
acumuladorDiferencias = acumuladorDiferencias + abs(luminosidadesMedias(3) -
18
luminosidadesMedias(2));
19
if(acumuladorDiferencias > 35 && luminosidadesMedias(2) > 0 &&
20
luminosidadesMedias(3) > 0)
21
if(mean(imagen(:)) < 50)
22
algoritmo = 'Noche';
23
else
algoritmo = 'Dia';
24
25
26
27
end
else
if(mean(imagen(:)) > 50)
algoritmo = 'Dia';
28
29
else
algoritmo = 'Noche';
30
31
32
end
end
Las anteriores rutinas se encargan de la eleccin del algoritmo para procesar la

imagen. Como se puede comprobar, se estudia la luminosidad media de la
imagen que se quiere procesar y de las dos anteriores para, en funcin de la
~ 82 ~
diferencia de luminosidad de imgenes recientes, poder detectar si se est

produciendo una situacin de amanecer o anochecer y seleccionar el algoritmo
correcto para la deteccin de vehculos. La razn de realizar este proceso
teniendo en cuenta imgenes tomadas anteriormente es cubrir el objetivo de que
este proyecto pueda ser utilizado en distintos entornos con el mnimo nmero de
cambios. Por esta razn, no se utiliza un valor fijo para discrepar si es las
imgenes han sido adquiridas en entornos de da o de noche sino que se requiere
de una secuencia de saltos de luminosidad crecientes o decrecientes para tener
certeza del cambio de entorno. En la siguiente pareja de imgenes se puede
comprobar la imposibilidad de usar valores fijos para detectar el entorno de
luminosidad que tiene la imagen. La imagen de la izquierda, est realizada en un
entorno de da pero tiene la misma luminosidad que una realizada en un entorno
de noche, dejando claro la no efectividad de un solo valor como forma de
discrepar entre da y noche.
Figura 67. Pareja de imgenes con parecida luminosidad, izquierda de da (99) y derecha de noche (90),
para comprobar la no efectividad de utilizar umbrales fijos de luminosidad para discrepar entre da y
noche
33
[carrilEnMomentoT, vehiculosDetectados, imagenResultado] =
34
TEA(imagen,algoritmo,carrilCoordX, carrilCoordY);
Totalmente necesario es realizar la llamada correspondiente a la funcin TEA,

explicada exhaustivamente en los apartados de este captulo 6 a travs de sus
325 lneas de cdigo, con el objetivo de que se procese la imagen que se acaba de
capturar. Se recuerda que la funcin TEA es la encargada de detectar y contar
vehculos, pero se encarga de realizar un pre-procesado de la imagen que es el
~ 83 ~
punto de partida de la estimacin de velocidad.
35
36
37
if(size(carrilEnMomentoAnterior) > 1)
zonaCorrelacion =
carrilEnMomentoT(zonaCorrelacionPuntoY:ZonaCorrelacionPuntoY+100,...
38
zonaCorrelacionPuntoX:zonaCorrelacionPuntoX+100);
39
capturaMomentoT = zonaCorrelacion(10:101,10:101);
40
capturaMomentoT = imdilate(capturaMomentoT,strel('rectangle',[2 1]));
En esta parte del cdigo da comienzo el verdadero estudio de correlacin. Lo

primero que se realiza son dos recortes de la zona de correlacin para que no se
tengan en cuenta otras zonas del carril que no son ptimas para el estudio de
correlacin. El segundo recorte que se realiza es para quedarse con los pxeles
ms centrados. De vital importancia es tambin la dilatacin de uno de los
fotogramas que va a ser usado para el estudio de correlacin ya que es bastante
difcil especificar con absoluta precisin la direccin del movimiento de los
vehculos a lo largo del carril de estudio. La siguiente pareja de imgenes muestra
un estudio de correlacin, sin incluir e incluyendo la dilatacin de uno de los dos
carriles de estudio. Se puede comprobar cmo queda mucho ms claro el
proceso, y por tanto ms fiables son los resultados de la imagen donde el carril
queda dilatado.
Figura 68. A la izquierda se encuentra un estudio de correlacin sin dilatar uno de los carriles. A la
derecha se encuentra un estudio de correlacin diltandao uno de los carriles, quedando ms claro el
proceso.
~ 84 ~
41
correlacion = zeros(30,1);
42
for i=1:30
43
valorX = i+250;
44
valorY = floor(mRecta*valorX + bRecta);
45
capturaAnterior = carrilEnMomentoAnterior(valorY-60:valorY+31,valorX-
46
60:valorX+31);
47
imagenAnd = and(capturaAnterior,capturaMomentoT);
48
correlacion(i) = sum(sum(imagenAnd));
49
end
50
end
51
[valorMaximo, indiceMaximo] = max(correlacion);
52
end
La parte de cdigo anterior refleja los 30 desplazamientos realizados por el

algoritmo propuesto. Tambin se puede observar cmo influyen los parmetros
de la recta de direccin de los vehculos para ir realizando los desplazamientos
uno a uno. Una vez realizado el desplazamiento, se realiza la operacin lgica
AND para obtener el nmero de pxeles que coinciden, concepto tambin
conocido como fitness o correlacin entre dos imgenes.
Por ltimo, se obtiene el ndice donde se encuentra el valor mximo de fitness
para poder concluir con el desplazamiento ocurrido entre las dos imgenes
comparadas.
El desplazamiento que es necesario aplicar al segundo fotograma para que la
imagen coincida con el primero, est directamente relacionado con el
desplazamiento del vehculo en el intervalo de tiempo que separa los dos
fotogramas. Por lo tanto la informacin de velocidad se deduce de estos valores.
En la siguiente imagen a modo de resultado de la ejecucin de este algoritmo, se
incluyen los 30 desplazamientos realizados entre dos imgenes y en un recuadro,
seleccionada la imagen con mayor valor de fitness.
~ 85 ~
Figura 69. Imagen resultado de la aplicacin del algoritmo de estimacin de la velocidad.
~ 86 ~
6.9 Evaluacin del algoritmo para la estimacin

de la velocidad de vehculos que se aproximan a
la interseccin
Para la realizacin de las tareas de evaluacin de este algoritmo se ha realizado un
proceso de validacin del algoritmo propuesto utilizando, al igual que en el resto de
procesos de evaluacin, imgenes capturadas en un entorno real. Ms
concretamente las imgenes fueron recogidas durante un largo perodo de tiempo
en la siguiente calle, denominada calle Mesones, cuyo mapa de situacin se
adjunta.
Calle
Mesones
Figura 70. Mapa de situacin de la calle de donde proceden las imgenes para la evaluacin del algoritmo
de estimacin de la velocidad
Una pareja de imgenes capturadas de manera consecutiva que reflejan las

caractersticas del conjunto de imgenes usadas para la evaluacin de este
algoritmo se presenta a continuacin.
Figura 71. Pareja de imgenes consecutivas que muestran las caractersticas del conjunto de ejemplos
usados para la evaluacin del algoritmo de estimacin de la velocidad
~ 87 ~
La manera de evaluar este algoritmo es en gran parte subjetiva, ya que los

resultados que devuelve el algoritmo son de manera cualitativa (velocidad baja,
media, alta). Por esta razn la evaluacin de este algoritmo est supeditada a su
implementacin para la realizacin de las pruebas en un entorno real. Observando
el apartado 9.2 de este documento y a la vista de los resultados obtenidos, se
puede confirmar la fiabilidad de este algoritmo.
Sin embargo, es conveniente destacar un aspecto de la evaluacin de este

algoritmo para confirmar su robustez. Este aspecto es la aparicin de lbulos
alrededor de los mximos grados de fitness, como se puede observar en las
siguientes imgenes.
Mximo grado de fitness
Fase de crecimiento del
grado de fitness
Lbulos
Figura 72. Imgenes que muestran la existencia de lbulos y su correspondencia entre la grfica de
evolucin del fitness y cada una de los desplazamientos realizados
~ 88 ~
Durante el desarrollo de este algoritmo y con el objetivo de comprobar su

correcto funcionamiento, se descubri que debido a los bordes que posee un
vehculo, y cmo son realizados los desplazamientos salen a relucir lbulos
alrededor de los mximos grados de fitness.
Ms claramente se puede observar este concepto en las anteriores figuras.

En la grfica 73 se muestra el desarrollo de la correlacin entre dos imgenes a lo
largo de los sucesivos desplazamientos realizados. Y en la parte inferior se muestran
los distintos 30 desplazamientos. Con las flechas se muestran las distintas
correspondencias entre lbulos / desplazamientos. Para ver de una manera ms
detallada se muestra la figura 74 que muestra los desplazamientos que
corresponden al lbulo izquierdo, al mximo grado de fitness y al lbulo derecho.
Figura 53. Imgenes que muestran la correspondencia entre lbulos / desplazamientos
La aparicin de dichos lbulos, aporta coherencia en el algoritmo propuesto,

puesto que se est trabajando con bordes de vehculos que se confirma su correcto
funcionamiento. Al hacer el primer desplazamiento del carril de color negro, se
produce el lbulo situado a la izquierda. Al realizar el segundo desplazamiento se
produce el mximo nivel de fitness. Y por ltimo al realizar el tercer desplazamiento
se produce otro lbulo, el situado a la derecha.
Por otro lado, situndose sobre una imagen de una matrcula, que tiene dos
lneas horizontales, es esperable la aparicin de lbulos a distancias equivalentes a
la altura de la matrcula (en pxeles).
~ 89 ~
Captulo 7
Mdulo de deteccin de
vehculos prioritarios
~ 90 ~
7. Mdulo de deteccin de vehculos prioritarios

En este captulo se detallan los procedimientos realizados con el fin cubrir uno de
los objetivos importantes a cubrir por este proyecto, poder conocer si se aproximan
vehculos con prioridad de paso.
Los vehculos con prioridad pueden ser servicios de emergencia (bomberos,

ambulancias, policas) o bien servicios pblicos (autobuses fundamentalmente).
~ 91 ~
7.1 Deteccin basada en tratamiento de

imgenes
En un primer momento, se intento realizar esta deteccin utilizando
exclusivamente tcnicas de tratamiento digital de imgenes. La forma de deteccin
de equipos de emergencia se basaba en la deteccin de patrones de luces que se
encienden y se apagan, tal y como sucede con las luces de emergencia que portan
estos vehculos de emergencia. Sin embargo, se lleg a las siguientes conclusiones
haciendo inviable tal forma de detectar vehculos de emergencia:
No existe un nmero reducido de patrones: las luces que llevan los equipos
de emergencia siguen un patrn fijo para encenderse y apagarse segn unos
intervalos pre-fijados, pero este patrn es exclusivo para el tipo de vehculo.
En otras palabras, los bomberos de la Comunidad de Madrid llevan un
patrn para encender/apagar sus luces de emergencia, pero por otro lado
los vehculos de emergencia de la provincia de Toledo, llevan otro patrn
distinto para encender/apagar sus luces de emergencia. Incluso dentro del
mismo equipo de emergencia, hay distintos patrones dependiendo del tipo
de vehculos. Por esta razn, sera una tarea inviable reconocer todos y cada
uno de los patrones existentes.
El tiempo transcurrido entre dos capturas consecutivas no siempre es el

mismo:
esta
situacin
hace
tambin
inviable
la
posibilidad
de
reconocimiento de patrones ya que el retraso que introduce la captura de

las imgenes a travs de las cmaras IP no siempre es el mismo.
Tcnicamente tendra solucin, pero encareciendo el sistema. En la siguiente
figura, se encuentran 4 imgenes que representan esta situacin, con
retraso excesivo. En la parte de la izquierda se encuentran las luces de
emergencia que se detectan y en la parte de la derecha se encuentran las
imgenes originales. Como se puede comprobar entre dos imgenes
consecutivas, el nmero de luces de emergencia que se detectan, difiere.
~ 92 ~
Figura 74. Conjunto de imgenes que demuestran la imposibilidad de reconocer patrones
Existen otros vehculos con luces en el techo que no son vehculos de

emergencia: algunos ejemplos son los vehculos de limpieza, los vehculos
de mantenimiento de carretera, las gras Se trata de vehculos que pueden
circular a velocidad excesivamente baja.
En funcin de las razones expuestas anteriormente, se ha tenido que

encontrar otra alternativa para la deteccin de vehculos de emergencia. Esta otra
alternativa es mediante la utilizacin de la tecnologa Bluetooth.
~ 93 ~
7.2 Deteccin basada en tecnologa Bluetooth

Utilizando antenas receptoras Bluetooth instaladas en los semforos y
dispositivos emisores Bluetooth en los vehculos de emergencia, se puede detectar
perfectamente y con suficiente antelacin, cuando se aproximan equipos de
emergencia a una interseccin. El procedimiento consiste en estar constante
buscando dispositivos a travs de la antena Bluetooth instalada en los semforos,
para que cuando se aproxime un equipo de emergencia con un dispositivo emisor,
pueda ser detectado. Si el dispositivo mvil emite las seales adecuadas, se procede
a abrir ese semforo hasta que pase este equipo de emergencia y volver a la
situacin normal de operacin. Un esquema que representa este procedimiento es
el que se muestra en la siguiente figura.
Figura 75. Esquema de la funcionalidad de deteccin de equipos de emergencia usando Bluetooth
7.2.1. Tipos de antenas

El nico obstculo que hay que salvar a la hora de utilizar este
procedimiento es la utilizacin de antenas Bluetooth unidireccionales. Son
necesarias ya que la utilizacin de antenas omnidireccionales no aportan la
capacidad de conocer unvocamente por qu va se aproxima el equipo de
~ 94 ~
emergencia. Ejemplos de antenas de este estilo se encuentran en la siguiente

figura. Las antenas de la parte inferior son prototipos de antenas unidireccionales,
desarrollados para este proyecto con un alcance de 18 metros en dicha direccin.
Figura 76. Ejemplos de antenas unidireccionales.
Otra ventaja de las antenas unidireccionales es que tienen mayor alcance en

la direccin principal, por lo tanto pueden detectar el vehculo con mayor
antelacin.
7.2.2. Cdigos de identificacin

La manera de discrepar entre vehculos de emergencia y otras seales es
mediante un mecanismo de autenticacin. Este mecanismo se basa en la
codificacin de la direccin MAC del dispositivo Bluetooth usando el algoritmo de
cifrado simtrico RC4 resultando en una cadena de caracteres que pasan a ser el
nombre del dispositivo. De esta manera la pareja direccin MAC y nombre pasan a
ser una dupla de datos de autenticacin. Las ventajas de este procedimiento son las
siguientes:
~ 95 ~
No son necesarias tablas de dispositivos Bluetooth dados de alta: cuando

se aproximan los vehculos a la interseccin, el sistema de toma de
decisiones transforma la direccin MAC de cada dispositivo encontrado,
usando RC4 y la clave previamente configurada en l. Si alguna pareja de
direccin MAC y nombre de los vehculos que se aproximan coinciden con
las parejas resultado que obtiene el sistema de toma de decisiones,
entonces se considera que existe un equipo de emergencia que se aproxima
a la interseccin y se le procede a dar paso.
No son necesarios procesos de handshaking: otra solucin sera establecer
un proceso de handshaking entre el sistema de toma de decisiones y cada
dispositivo Bluetooth que se aproxime mediante una clave comn, pero
entonces el proceso durara de validacin sera ms lento y podra haber
problemas de deteccin en la parte mvil.
Rapidez del procedimiento: usando RC4, el proceso de cifrado no requiere
de mucha carga computacional, pudiendo ser realizado este proceso en
tiempo real. Sera ms seguro utilizar algoritmos de criptografa asimtrica,
codificando la direccin MAC con la clave privada de alguna entidad de
referencia (vase el ayuntamiento de la ciudad de instalacin del sistema) y
ms tarde verificando el cdigo en cada cruce con la clave pblica de la
citada entidad de referencia. Esta ltima estrategia, con algoritmos RSA es
ms costosa que con RC4.
Este concepto se puede ver claramente como se realiza en el siguiente

apartado, donde mediante el cdigo fuente desarrollado se llevan a cabo las
comparaciones de parejas MAC y nombre de dispositivo Bluetooth.
~ 96 ~
7.3 Algoritmo de deteccin de vehculos que se

aproximan a la interseccin
Finalmente se seleccion el mtodo de deteccin basado en Bluetooth, de esta
manera, a continuacin se muestra el algoritmo propuesto para la deteccin de
vehculos de emergencia, usando como lenguaje de programacin JAVA. Este
algoritmo se compone de dos clases: MultipleBTRadios, la primera que se va a
desarrollar y ThreadDiscovery que se explica despus.
import sistematomadecisiones.SimCanvas;
De manera anloga al algoritmo de integracin entre tratamiento digital de

imgenes y sistema de toma de decisiones, elaborado en el apartado 8.2.1 de
esta memoria, es necesario realizar la anterior sentencia import para enlazar la
bsqueda de vehculos de emergencia con el sistema de toma de decisiones, a
travs de la clase SimCanvas.
public class MultipleBTRadios
private ThreadDiscovery radio0, radio1, radio2, radio3;
private SimCanvas simCanvas;
6
7
public MultipleBTRadios(SimCanvas _simCanvas)
{
simCanvas = _simCanvas;
9
10
radio0 = new ThreadDiscovery(simCanvas,"0",6000);
11
12
13
14
En el cdigo adjuntado anteriormente, se realiza la declaracin de las variables

que se van a necesitar durante el proceso y se define el constructor necesario
para este clase. En este constructor es donde, solamente se crea referencia a los
~ 97 ~
distintos Threads encargados de la bsqueda de dispositivos Bluetooth cercanos.

A la vez que se crean dichos Threads, se les pasa como argumentos la referencia
con el sistema de toma de decisiones, el nmero de radio Bluetooth con la que
trabaja y el tiempo de polling especificado en milisegundos. Debido a que un
equipo puede tener varias emisoras de Bluetooth instaladas y las intersecciones
slo tienen cuatro vas como mximo, se han creado las cuatro oportunas
variables.
15
public void startScan()
16
17
radio0.start();
18
radio1.start();
19
radio2.start();
20
radio3.start();
}
21
22
Para finalizar, en este metodo startScan() es donde arrancan los Threads

anteriormente creados, y por consiguiente, las bsquedas en paralelo de
dispositivos tambin arrancan.
La siguiente clase es ThreadDiscovery, bsicamente es un Thread que realiza

las rutinas necesarias para realizar la bsqueda de dispositivos Bluetooth usando la
pila BlueZ (http://www.bluez.org/). Cabe destacar que hay algunas clases que se
usan en el siguiente cdigo fuente pero que no es necesario incluir.
~ 98 ~
import java.io.*;
import java.util.*;
import sistematomadecisiones.SimCanvas;
Inicialmente, se incluyen las sentencias import necesarias. Las dos primeras son
para utilizar clases de I/O necesarias y manejar colecciones de elementos. La
tercera y ltima es la necesaria para integrarse con el sistema de toma de
decisiones a travs de la clase SimCanvas.
4
public class ThreadDiscovery extends Thread
private String idDevice;
private int pollingMillis;
private HashMap detectionMap;
private boolean emergencyEquipment = false;
10
11
12
13
14
public ThreadDiscovery(SimCanvas _simCanvas, String _idDevice, int

_pollingMillis)
{
15
idDevice = _idDevice;
16
pollingMillis = _pollingMillis;
17
18
En la parte de cdigo incluida arriba se produce la declaracin de las variables

necesarias y tambin se encuentra el constructor con la inicializacin de ciertas
variables que se reciben como argumentos en el constructor.
19
@Override
20
public void run()
21
22
while(true)
23
24
try
25
26
detectionMap = new HashMap();
~ 99 ~
27
28
StringBuffer execCommand = new StringBuffer();
29
execCommand = new StringBuffer();
30
execCommand.append("hcitool -i hci");
31
execCommand.append(idDevice);
32
execCommand.append(" scan");
33
ProcessBuilder btDiscovery = new ProcessBuilder("bash", "-c",
34
35
execCommand.toString());
Process currentScan = btDiscovery.start();
36
Durante las rutinas incluidas anteriormente se produce la bsqueda de

dispositivos Bluetooth. A travs de la ejecucin del comando hcitool que contiene
la pila BlueZ se produce la bsqueda de elementos cercanos. Las lneas de cdigo
45, 46 y 47 recogen la manera de ejecutar un comando por consola en un
entorno de Linux sin la necesidad de abrir una consola. Adems la variable
currentScan guarda referencia al proceso en ejecucin para que posteriormente
se pueda capturar todos los resultados tras ejecutar este proceso de bsqueda de
dispositivos Bluetooth cercanos.
37
Thread.yield();
38
Thread.sleep(pollingMillis);
Estas dos lneas de cdigo son de vital importancia ya que mediante ellas se
realiza el proceso de polling. Debido a que se ha realizado un estudio sobre cmo
influye el tiempo de polling a la hora de descubrir la mayor cantidad de
dispositivos y a la mayor distancia posible se opta a poder variar el polling segn
necesidades, de ah que sea un argumento a la hora de instanciar un objeto de
esta clase.
39
40
BufferedReader br = new BufferedReader(new

InputStreamReader(currentScan.getInputStream()));
41
42
String line = br.readLine();
43
while(line != null)
44
{
~ 100 ~
45
if(!line.contains("Scanning"))
46
47
StringTokenizer st = new StringTokenizer(line);
48
String macAddress = st.nextToken();
49
String deviceName = st.nextToken();
50
detectionMap.put(macAddress, deviceName);
51
System.out.println("hci" + idDevice + " =>" + macAddress
52
53
+ " " + deviceName);
54
55
line = br.readLine();
56
57
58
currentScan.destroy();
En las anteriores lneas de cdigo se muestra como se guarda la informacin que

devuelve la ejecucin del comando hcitool. De toda la informacin que devuelve,
slo se necesita la pareja de direccin MAC del dispositivo y el nombre de
dispositivo. Tambin se aprovecha para destruir el proceso de bsqueda de
dispositivos que se encontraba en ejecucin puesto que otro va a ser creado en la
siguiente iteracin.
59
Set entrySet = detectionMap.entrySet();
60
Iterator it = entrySet.iterator();
61
while(it.hasNext())
62
63
Map.Entry entry = (Map.Entry) it.next();
64
String macAddress = (String) entry.getKey();
65
String deviceName = (String) entry.getValue();
En las lneas que se presentan arriba es donde se da comienzo al proceso de

comprobar si alguna de las parejas de direccin MAC y nombre de los dispositivos
Bluetooth detectados, puede corresponder con el de un equipo de emergencia.
En la variable macAddress se encuentra la direccin MAC y en la variable
deviceName se encuentra el nombre del dispositivo.
66
RC4 myRC4 = new
~ 101 ~
67
RC4("fernandoGonzalezSanchezMartinezDeMedinilla");
68
byte[] cipheredDeviceName = myRC4.rc4(macAddress);
69
String cipheredDeviceNameToString =
70
asHex(cipheredDeviceName);
cipheredDeviceNameToString =
71
72
cipheredDeviceNameToString.substring(cipheredDeviceNameToString.length()-
73
15, cipheredDeviceNameToString.length());
Como se puede comprobar en las anteriores lneas de cdigo, se convierte

mediante RC4 y usando la clave predefinida, la direccin MAC obtenida en un
array de bytes que posteriormente es convertido a valores hexadecimales. Por
ltimo se recorta una serie de todos los valores obtenidos para hacer los nombres
ms cortos ya que algunos dispositivos Bluetooth slo soportan hasta cierto
nmero de caracteres como nombre de dispositivo.
if(deviceName.compareTo(cipheredDeviceNameToString) ==
74
75
0)
{
76
77
emergencyEquipment = true;
78
if(idDevice.compareTo("0") == 0)
simCanvas.setEmergenciaMesones(true);
79
else if(idDevice.compareTo("1") == 0)
80
simCanvas.setEmergenciaCarretera(true);
81
else
82
simCanvas.setEmergenciaAlfares(true);
83
84
85
else
86
87
emergencyEquipment = false;
88
if(idDevice.compareTo("0") == 0)
simCanvas.setEmergenciaMesones(false);
89
else if(idDevice.compareTo("1") == 0)
90
simCanvas.setEmergenciaCarretera(false);
91
else
92
simCanvas.setEmergenciaAlfares(false);
93
}
94
95
~ 102 ~
96
if(entrySet.size() == 0)
97
{
emergencyEquipment = false;
98
}
99
Si la comparacin entre, el nombre del dispositivo detectado y el cifrado de la

direccin MAC usando RC4 con la clave pre-definida, coinciden entonces se llama
a un mtodo existente en el sistema de toma de decisiones para alertar de
presencia de equipos de emergencia que se aproximan a la interseccin. Debido a
que hay que especificar unvocamente por cual va de las mltiples posibles que
tiene la interseccin se aproxima el vehculo de emergencia, se discrepa entre el
nmero que identifica a las distintas radios Bluetooth instaladas en el sistema
para conocer por cual va se aproxima el equipo de emergencia.
100
101
catch(Exception e)
102
{
e.printStackTrace();
103
}
104
}
105
}
106
107
108
Por ltimo, el resto del cdigo incluido se encarga de imprimir por consola
cualquier error por producido para que sea observado en tareas de depuracin.
Es importante destacar, que de manera paralela a la ejecucin de este

proceso de deteccin de vehculos de emergencia, deber haber otro proceso
corriendo que elimine la cach que genera el comando hcitool de la pila BlueZ. De
esta manera se evitan resultados falsos.
~ 103 ~
7.4 Conclusiones sobre el sistema de deteccin de

vehculos con prioridad
Con respecto a la evaluacin del algoritmo recientemente propuesto, se
concluye que dicho algoritmo funciona de manera satisfactoria ya que intervino tal
y como aparece en la realizacin de las pruebas en entorno real detalladas en el
apartado 9.2 de esta memoria. Durante dichas pruebas en entorno real se probaron
diferentes
tipos
de
antenas
concluyendo
que
son
necesarias
antenas
unidireccionales y que tengan un alcance de unos 40-50 metros para detectar los
vehculos de emergencia que se aproximan con la suficiente antelacin.
Sin embargo, este algoritmo y su forma de proceder tienen una desventaja.

Tal y como se indica en [CHAK04], la cantidad de dispositivos Bluetooth que se
encuentren en el mbito de bsqueda impactan sobre el rendimiento y el tiempo
de resolucin de las bsquedas. Por tanto a mayor nmero de dispositivos que se
encuentren alrededor del equipo de emergencia, mayor ser el tiempo que se
tardar en detectar la presencia de un vehculo de emergencia aproximndose a la
interseccin. Debido a la gran cantidad de dispositivos Bluetooth que hay en uso en
la poblacin, este aspecto puede ocasionar problemas. La manera de solucionarlo
es mediante la instalacin de antenas Bluetooth unidireccionales con la potencia
adecuada para la tarea que tiene que realizar, es decir, que tenga como
caracterstica de alcance unos 40-50 metros aunque en general siempre funcionar
mejor en calles anchas y espaciosas para evitar posibles rebotes de la seal.
Para dar prioridad a transporte pblico se puede utilizar una variante de la

codificacin propuesta. De esta manera se puede diferenciar los tipos de vehculos
con prioridad y operar los semforos de distinta manera.
~ 104 ~
Captulo 8
Sistema de toma de
decisiones
~ 105 ~
8. Sistema de toma de decisiones

Por definicin, el concepto de sistema de toma de decisiones viene a significar el
conjunto de rutinas que, a partir de una serie de variables de entrada, permitan
generar la decisin ptima. En el contexto en el que este proyecto se sita, las
variables de entrada son aquellas que recogen el estado de la interseccin para un
determinado instante y el sistema de toma de decisiones, en funcin de estas
variables de entradas, genera la decisin ptima de regulacin semafrica para ese
determinado instante.
El sistema de toma de decisiones que este proyecto propone tiene como

mdulos internos la captura del trfico entrante a la interseccin por cualquiera de
sus vas, la deteccin de vehculos de emergencia que se aproximan a la
interseccin, la comprobacin de que la interseccin se encuentra libre (verificando
que ningn vehculo va a cruzar dicha interseccin con su semforo cerrado) y por
ltimo la generacin de la decisin ptima.
Previamente a la explicacin de los mdulos citados, se procede a realizar un

estudio de las tcnicas existentes para la toma de decisiones sobre el contexto de
regulacin semafrica.
~ 106 ~
8.1 Estudio de diferentes tcnicas

Tras una bsqueda de posibles tcnicas ya realizadas, se concluye que cada solucin
implementa su decisin en funcin de patrones [ANGU08] o en funcin de
decisiones tomadas de manera independiente para cada instante [GRAD07].
Como soluciones implementadas completas, se encuentra el simulador

titulado como Microscopic Online Simulation for Real Time Traffic Management
[MISK07].
Debido a que la regulacin en funcin de patrones pre-establecidos requiere

de un complicado proceso de configuracin de manera previa a la instalacin del
sistema, este proyecto realiza la toma de decisiones de manera independiente y
particular para cada situacin e instante. De esta manera, se concluye que este
proyecto pretende eliminar el concepto de ciclos de regulacin de semforos ya que
los vehculos que se aproximan y las situaciones que se producen no se rigen en
funcin de patrones en la amplia mayora de los casos.
Por tanto, como razones para utilizar un sistema de toma de decisiones de

manera independiente, se encuentran la sencillez de configuracin a la hora de
realizar la instalacin y adems la facilidad de promover este sistema a gran escala
ya que se adapta a cualquier tipo de escenario.
~ 107 ~
8.2 Captura del estado del trfico

Para conocer el estado de la interseccin, tanto a nivel de vehculos que se
aproximan como para poder llegar a saber si se puede producir una colisin, se
realiza el proceso de tratamiento digital de imgenes detallado en el captulo 6 de
esta memoria.
Por otro lado, el sistema de deteccin de vehculos prioritarios mediante la

utilizacin de tcnicas Bluetooth, detallado en el captulo 7 de esta memoria,
permite determinar si existe algn vehculo con prioridad de paso acercndose a la
interseccin.
Dado que todos los procedimientos del tratamiento digital de imgenes son
realizados en un entorno de desarrollo MATLAB, suponiendo esto un impedimento
a la hora de manejar muchos dispositivos en paralelo, se ha usado la toolbox que
incorpora MATLAB llamada MATLAB JA Builder (for Java language) para llevar a
cabo la integracin entre los procesos de tratamiento digital de imgenes y el
sistema de toma de decisiones que ha sido desarrollado en lenguaje Java por
motivos de portabilidad para trabajos futuros.
Con la integracin anterior, se completa la unin de los dos subsistemas

crticos de este proyecto. A partir de las imgenes y las seales Bluetooth, obtenidas
de las cmaras IP y antenas instaladas en los semforos, se realiza el proceso de
tratamiento digital de imgenes (usando MATLAB) y la comprobacin de la
existencia de equipos de emergencia (usando JAVA). Lo anterior, resulta en las
variables de entrada para el sistema de toma de decisiones que en funcin de estas
genera la decisin ptima (usando JAVA). Dicha integracin est resumida en la
siguiente figura.
~ 108 ~
Tratamiento digital de
imgenes
Sistema de toma de
decisiones
Decisin
ptima
Figura 77. Esquema que muestra la integracin entre los subsistemas crticos de este proyecto
8.2.1. Algoritmo de integracin con el sistema de toma de

decisiones
En este apartado se incluye el cdigo fuente en el lenguaje de programacin JAVA
para llevar a cabo la integracin entre los dos subsistemas crticos de este proyecto.
Como paso previo a la ejecucin del siguiente cdigo fuente, es necesario la

creacin de una librera en formato JAR a partir de los cdigos fuentes de
tratamiento digital de imgenes. Para realizar esta librera, se requiere de la
herramienta Deployment Tool que aparece en el entorno de desarrollo MATLAB.
Tras aadir todos los cdigos fuente necesarios, MATLAB empaqueta esos archivos
como una nica librera en formato JAR.
En el siguiente cdigo, dicha librera tiene el nombre de fusionTEAAlfares y

debe ser perfectamente referenciada por el cdigo en JAVA que se adjunta para la
~ 109 ~
correcta integracin de los dos subsistemas. Ms claramente se puede ver en el

desarrollo del cdigo del algoritmo de integracin propuesto.
import com.mathworks.toolbox.javabuilder.*;
import fusionTEAAlfares.*;
Con estas dos sentencias import, se referencian las libreras necesarias para la
ejecucin del resto de cdigo fuente adjuntado. La primera corresponde a unas
libreras creadas por defecto por MATLAB. La segunda es la librera que tiene que
ser creada
utilizando la
herramienta
Deployment
Tool
anteriormente
mencionada. En este caso, la librera se llama fusionTEAAlfares ya que ha sido una

de las libreras utilizadas para las pruebas en entorno real detalladas en el
captulo de evaluacin del sistema (captulo 9).
import java.awt.image.BufferedImage;
import sistematomadecisiones.SimCanv
Estas dos sentencias import son tambin estrictamente necesarias. La primera

tiene como funcin la conversin de los datos que devuelve MATLAB entre un
tipo de datos JAVA. La segunda es la manera de enlazar con el sistema de toma
de decisiones, es decir, a travs de la clase SimCanvas se van a comunicar los
resultados del tratamiento digital de imgenes con el sistema de toma de
decisiones.
5
public class SemaforoAlfares extends Thread
private int vehiculosEsperando;
private int indiceZonaCritica;
private BufferedImage imagenOriginalJava;
10
private BufferedImage imagenResultadoJava;
11
12
13
public SemaforoAlfares(SimCanvas _simCanvas)
14
15
~ 110 ~
16
Como se puede comprobar en el cdigo anterior, se declara una clase tpica de

JAVA pero que extiende de la clase Thread para sacar el mximo partido al
concepto de multi-threading, creando un Thread independiente para cada
semforo de la interseccin. Tambin las variables a utilizar son declaradas y se
recibe una referencia a la clase simCanvas para poder intercomunicar los dos
subsistemas de este proyecto.
17
@Override
18
public void run()
19
20
MWNumericArray luminosidadesMedias = null;
21
MWArray imagenOriginalMatlab = null, imagenResultadoMatlab = null;
22
FusionTEAAlfares TEA = null;
23
int indiceImagen = 1;
24
Object[] results = null;
25
try
26
27
int[] dims = {1, 3};
28
luminosidadesMedias = MWNumericArray.newInstance(dims,
29
MWClassID.DOUBLE, MWComplexity.REAL);
30
31
32
for (int i = 1; i <= 3; i++)

luminosidadesMedias.set(i, 0);
Mediante las anteriores retinas, se preparan las variables que van a ser utilizadas
a lo largo de las siguientes partes de cdigo. Ms en concreto, la variable
luminosidadesMedias, es instanciada como MWNumericArray ya que va a ser
utilizada tanto por MATLAB como por JAVA y MATLAB requiere que las variables
sean de ciertas clases.
33
TEA = new FusionTEAAlfares();
34
results = TEA.ProcesarFotosOnline(6,luminosidadesMedias, 0,
35
indiceImagen);
~ 111 ~
En las dos lneas anteriores, se crea la puerta de acceso al conjunto de rutinas

creadas en MATLAB y se realiza la primera iteracin del tratamiento digital de
imgenes. Se llama a la funcin ProcesarFotosOnline detallada en el apartado 6.8
y como es la primera vez, se le introducen argumentos vacos para que sean
rellenados en sucesivas iteraciones. Los argumentos son los siguientes:
Primer argumento: valor igual a 6, por ser 6 los resultados esperados.
Segundo
argumento:
se
introduce
el
MWNumericArray
luminosidadesMedias con sus tres componentes iguales a 0, para que

vayan siendo rellenadas en las siguientes iteraciones.
Tercer argumento: valor igual a 0, el primer carril de correlacin est
vaco. En las siguientes iteraciones ya se dispone de este argumento
completo.
Cuarto argumento: indiceImagen igual a 1, ya que es la primera imagen a
procesar y ser colocada su luminosidad media en la primera posicin del
vector luminosidadesMedias.
En la variable results, dado que los tipos de los datos devueltos varan, es de tipo
Object, se guardarn los 6 resultados que genera la funcin ProcesarFotosOnline.
36
vehiculosEsperando = ((MWNumericArray)results[2]).getInt(1);
37
simCanvas.setCurrentCarsAlfares(vehiculosEsperando);
38
39
indiceZonaCritica = ((MWNumericArray)results[3]).getInt(1);
40
if(indiceZonaCritica > 22)
41
42
43
simCanvas.setZonaCriticaAlfares(true);
else
simCanvas.setZonaCriticaAlfares(false);
44
45
imagenResultadoMatlab = (MWArray)results[4];
46
imagenResultadoJava =
47
Images.renderArrayData((MWNumericArray)imagenResultadoMatlab);
48
imagenOriginalMatlab = (MWArray)results[5];
49
imagenOriginalJava =
50
Images.renderArrayData(((MWNumericArray)imagenOriginalMatlab));
51
simCanvas.setImagenOriginalAlfares(imagenOriginalJava);
52
simCanvas.setImagenResultadoAlfares(imagenResultadoJava);
~ 112 ~
Los resultados son recogidos y tratados para que puedan ser utilizados por JAVA
en las anteriores lneas de cdigo. Como se puede comprobar, primero se recoge
el resultado para que posteriormente sea enviado al sistema de toma de
decisiones a travs de la variable simCanvas. En el apartado 8.4.1 se puede
comprobar cmo estas variables forman parte crtica de la generacin de la
decisin ptima. Cabe destacar, que en este momento se realiza la comprobacin
de si en la estimacin de la velocidad de los vehculos se ha detectado un vehculo
que va demasiado deprisa, para en tal caso activar la variable zonaCriticaAlfares.
Tambin en este paso se realiza el proceso de rendering necesario para convertir
las imgenes que devuelve MATLAB en un formato reconocible por JAVA.
53
while(true)
54
{
indiceImagen++;
55
56
results = TEA.ProcesarFotosOnline(6,(MWNumericArray)results[1],
57
58
results[0] , indiceImagen);
59
vehiculosEsperando = ((MWNumericArray)results[2]).getInt(1);
60
simCanvas.setCurrentCarsAlfares(vehiculosEsperando);
61
62
indiceZonaCritica = ((MWNumericArray)results[3]).getInt(1);
63
if(indiceZonaCritica > 22)

simCanvas.setZonaCriticaAlfares(true);
64
else
65
simCanvas.setZonaCriticaAlfares(false);
66
67
68
imagenResultadoMatlab = (MWArray)results[4];
69
imagenResultadoJava =
70
Images.renderArrayData((MWNumericArray)imagenResultadoMatlab);
71
imagenOriginalMatlab = (MWArray)results[5];
72
imagenOriginalJava =
73
Images.renderArrayData(((MWNumericArray)imagenOriginalMatlab));
74
simCanvas.setImagenOriginalAlfares(imagenOriginalJava);
75
simCanvas.setImagenResultadoAlfares(imagenResultadoJava);
76
En la parte del cdigo que se adjunta arriba, es donde se realizan las siguientes
~ 113 ~
iteraciones del tratamiento digital de imgenes a partir de la primera utilizando

un bucle infinito. No muy recomendable es esta tcnica, pero en principio no se
ha planteado que pueda ser parado el proceso de tratamiento digital de
imgenes. Es muy importante conocer que aqu es donde se produce el proceso
de retro-alimentacin que se explica en la figura 66 de esta documentacin.
}
77
78
catch (Exception e)
79
{
System.out.println("Exception: " + e.toString());
80
81
82
finally
83
84
MWArray.disposeArray(luminosidadesMedias);
85
if (TEA != null)
TEA.dispose();
86
}
87
}
88
89
Por ltimo, las anteriores lneas son necesarias para los procesos de depuracin
necesarios a la hora del desarrollo de este algoritmo.
Para finalizar este apartado, la evaluacin de este algoritmo no necesita de

grficas de fiabilidad ya que se reduce a funcionar o a no funcionar. Gracias a lo
comentado en el apartado 9.2 de esta memoria, su funcionamiento resulta
satisfactorio. Sin embargo en el apartado 10.1 sobre trabajos futuros se recogen
una serie de recomendaciones que podran llegar a mejorar su rendimiento.
~ 114 ~
8.3 Verificacin contra accidentes

Este mdulo se basa en la comprobacin de que ningn vehculo pretende cruzar la
interseccin an teniendo su semforo cerrado. En relacin a la motivacin de este
proyecto, se puede disminuir el nmero de colisiones existentes en intersecciones si
se puede cambiar la regulacin semafrica existente en el caso de que se produzca
una situacin de riesgo. La situacin de riesgo ms habitual la provocan los
vehculos que apuran la seal de mbar y terminan entrando en la interseccin a
gran velocidad y con el semforo en rojo. Esto supone un riesgo tanto para los
peatones como para los vehculos de las otras vas del cruce.
En los sistemas de regulacin actual, no hay manera de conocer si los

vehculos obedecen a los semforos instalados. En contraposicin, con el sistema
que este proyecto propone se puede llegar a conocer de manera incipiente una
posible situacin de colisin.
De acuerdo a lo mencionado y desarrollado en el apartado 6.8 de esta

memoria, se puede estimar la velocidad que tiene todo vehculo que va a cruzar la
interseccin. En funcin de esta estimacin, si se detecta que un vehculo que va a
cruzar la interseccin va a una velocidad elevada, se informa al sistema de toma de
decisiones para que tenga en cuenta esta situacin crtica y resuelva de la mejor
manera dicha situacin.
Mltiples procedimientos pueden llevarse a cabo en el caso de que se

produzca esta situacin crtica. Este proyecto y ms concretamente su sistema de
toma de decisiones, cuando detecta tal situacin crtica opta por cerrar todos los
semforos de la interseccin, de manera instantnea.
La forma de implementar la solucin a esta situacin crtica se encuentra

detallada de manera exhaustiva en el siguiente apartado donde se incluyen las
reglas y directrices por las que se rige el sistema de toma de decisiones propuesto.
~ 115 ~
Otra estrategia es retrasar el cambio a verde de las vas perpendiculares a la

va de la infraccin. Tpicamente hay un retraso de dos segundos desde que una va
cambia a rojo hasta que la va perpendicular cambia a verde. Si al cambiar a rojo el
sistema detecta un vehculo a velocidad elevada, debe alargar el tiempo del cambio
a verde, la estrategia implementada y probada durante las pruebas experimentales
tiene el mismo efecto.
~ 116 ~
8.4 Generacin de la decisin ptima

Este ltimo mdulo es el encargado de crear el producto final, la decisin ptima a
ejecutar. Mltiples formas existen para crear un algoritmo que, a partir de unas
variables de entrada y unas restricciones a cumplir, pueda tomar la decisin ptima.
El sistema de decisin se basa en un conjunto de reglas que utilizan toda la
informacin facilitada por los sensores.
En el sistema propuesto, las variables de entrada a la hora de tomar la

decisin ptima son las siguientes:
Nmero de vehculos en cada va de la interseccin: a travs de las
variables, currentCarsAlfares, currentCarsCarretera y currentCarsMesones.
Seal de presencia de vehculos de emergencia en cada va de la
interseccin:
travs
de
las
variables,
emergenciaAlfares,
emergenciaCarretera y emergenciaMesones.
Existencia de posibilidad de colisin debido a vehculos con velocidad
excesiva y que pueden llegar a la interseccin an estando su semforo
cerrado: a travs de las variables, zonaCriticaAlfares, zonaCriticaCarretera y
zonaCriticaMesones.
El conjunto de reglas implementadas para una ptima regulacin de los

semforos son las que se especifican en la siguiente figura.
~ 117 ~
Cerrar todos los semforos no se aproximan equipos de emergencia y no hay

vehculos esperando en la interseccin. Paso abierto para posibles peatones
Cerrar todos los semforos ante situacin crtica, de posible colisin con
vehculos que cruzan la interseccin an teniendo el semforo cerrado
Prioridad si hay equipos de emergencia que se aproximan a la

interseccin
Regulacin equitativa ante condiciones iguales en las vas de la

interseccin
Solventar problemas de monopolizacin ante prioridad

segn nmero de vehculos
Prioridad segn el nmero de vehculos que espera en cada va

Figura 78. Conjunto de reglas del sistema de toma de decisiones
El algoritmo propuesto y expuesto en el siguiente apartado es un ejemplo de

cmo implementar las variables de entrada y reglas citadas, usando el lenguaje de
programacin JAVA.
8.4.1. Algoritmo de generacin de la decisin ptima

A travs de las siguientes rutinas, envueltas en un bucle infinito para que se
generen decisiones constantemente, se tomar la decisin ptima en funcin de las
reglas enunciadas y detalladas anteriormente. La declaracin de variables no se
incluye con el fin de simplificar, as como algunas funciones no son incluidas ya que
~ 118 ~
no procede su inclusin en el contexto de este proyecto. El siguiente cdigo ha sido

el usado para las pruebas en un entorno real, por esta razn las variables poseen
nombres de calles donde se instal el sistema. La implementacin completa de
estas rutinas se encuentra en el CD-ROM adjunto a esta memoria.
it = tsPriorities.iterator();
TrafficState currentTS;
while(it.hasNext())
try
currentTS = (TrafficState) it.next();
if( currentTS.getDirection().equals("Mesones") )
currentTS.setCars(currentCarsMesones);
10
else if( currentTS.getDirection().equals("Alfares") )

currentTS.setCars(currentCarsAlfares);
11
else if( currentTS.getDirection().equals("Carretera") )
12
currentTS.setCars(currentCarsCarretera);
13
14
15
catch(NoSuchElementException rareException)
16
{
rareException.printStackTrace();
17
}
18
19
20
antePreviousTsPriorities = previousTsPriorities;
21
previousTsPriorities = tsPriorities;
22
Collections.sort(tsPriorities, new SortByNumberOfCars());
Lo primero que se realiza es la ordenacin de la prioridad de las vas que

componen la interseccin. La ordenacin se realiza mediante el mtodo
Collection.sort(). Los elementos que se encuentran en tsPriorities se ordenan
atendiendo al nmero de vehculos que hay en cada va en ese instante. Los
vehculos que hay en cada va se encuentran en las siguientes variables:
currentCarsAlfares, currentCarsMesones y currentCarsCarretera. Tambin se
guardan los esquemas de prioridad anteriores para ms adelante evitar
situaciones de monopolizacin, es decir, que un semforo este siempre abierto y
~ 119 ~
los otros cerrados.

23
if( (currentTrafficLight.equals("Mesones") &&

currentCarsMesones == 0 && (currentCarsAlfares > 0 ||
24
25
currentCarsCarretera > 0)) ||

(currentTrafficLight.equals("Alfares") &&
26
currentCarsAlfares == 0 && (currentCarsMesones > 0 ||
27
28
currentCarsCarretera > 0)) ||

(currentTrafficLight.equals("Carretera") &&
29
currentCarsCarretera == 0 && (currentCarsMesones > 0
30
31
|| currentCarsAlfares > 0)) )
32
time = timeGap + 1;
33
Se comprueba que si no hay vehculos en la va que est abierta al trfico, se

proceda a crear una nueva decisin de regulacin desechando la actual, haciendo
que el tiempo que se tena que ejecutar la anterior decisin, expire.
34
if(emergenciaAlfares || emergenciaCarretera || emergenciaMesones)
35
36
time = timeGap + 1;
37
emergenciaPresente = true;
38
if(emergenciaAlfares)
previousEmergencia = "Alfares";
39
else if(emergenciaCarretera)
40
previousEmergencia = "Carretera";
41
else
42
previousEmergencia = "Mesones";
43
44
En esta parte, se comprueba si se ha detectado algn equipo de emergencia

aproximndose por cualquiera de las vas que componen la interseccin. En caso
afirmativo, la actual decisin es desechada haciendo que el tiempo fijado que se
ejecutase, expire. De esta manera se proceder a crear una nueva decisin.
45
46
if(emergenciaPresente && !emergenciaAlfares && !emergenciaCarretera

&& !emergenciaMesones)
~ 120 ~
47
48
time = timeGap + 1;
49
emergenciaPresente = false;
50
Si la seal Bluetooth que emite el equipo de emergencia deja de recibirse

entonces se concluye que ya no hay vehculos de emergencia cercanos y el
tiempo fijado para que el equipo de emergencia pase con prioridad expira y una
nueva decisin debe ser generada.
51
if(time >= timeGap)
52
53
antePreviousTrafficLight = previousTrafficLight;
54
previousTrafficLight = currentTrafficLight;
55
currentTrafficLight = tsPriorities.get(0).getDirection();
Cuando expira el tiempo definido para el ciclo artificial de regulacin semafrica,

es necesario crear una nueva decisin. La primera regla, y la de menor prioridad
respecto al resto de reglas, es dar paso a la va que tiene ms importancia
respecto al nmero de vehculos, tal y como guarda la variable tsPriorities.
56
57
if(currentTrafficLight.equals(previousTrafficLight) &&
previousTrafficLight.equals(antePreviousTrafficLight))
58
En la anterior condicin se evitan situaciones de monopolizacin. Si durante dos

ciclos artificiales de regulacin semafrica, la misma va sigue abierta, entonces
se abre la va siguiente en prioridad atendiendo al nmero de vehculos.
59
60
if(currentCarsMesones == currentCarsCarretera &&

currentCarsCarretera == currentCarsAlfares
&& !emergenciaMesones && !emergenciaCarretera &&
61
62
!emergenciaAlfares
63
&& tsPriorities.equals(previousTsPriorities)
64
&& previousTsPriorities.equals(antePreviousTsPriorities))
65
~ 121 ~
currentTrafficLight = tsPriorities.get(
66
67
(indiceRotatorio%3)).getDirection();
indiceRotatorio++;
68
69
if(indiceRotatorio >= 1000)
70
indiceRotatorio = 0;
71
}
72
Esta regla es bsica en regulacin semafrica. Dicha regla reparte el trfico de

manera equitativa ante la situacin de exactitud de condiciones en todas las vas
de la interseccin. La variable indiceRotatorio se restaura a 0 cuando llega al
lmite de 1000 para evitar alcanzar nmeros muy grandes cuando el sistema est
funcionando durante muchas horas.
if( (previousEmergencia.equals("Alfares") &&
73
74
currentTrafficLight.equals("Alfares")) ||
(previousEmergencia.equals("Mesones") &&
75
76
currentTrafficLight.equals("Mesones")) ||
(previousEmergencia.equals("Carretera") &&
77
78
currentTrafficLight.equals("Carretera")))
{
79
80
81
previousEmergencia = "";
}
82
En el caso de que se detecte un vehculo de emergencia, una vez haya cruzado

este la interseccin, con esta regla se evita que vuelva a estar abierta la va por
donde ha pasado el equipo de emergencia con el fin de evitar monopolizacin.
if( (currentTrafficLight.equals("Alfares") ||
83
84
currentTrafficLight.equals("Carretera"))
&& (previousTrafficLight.equals("Alfares") ||
85
86
previousTrafficLight.equals("Carretera"))
&& currentCarsMesones > 0)
87
88
{
currentTrafficLight = "Mesones";
89
90
~ 122 ~
Esta regla es particular para la situacin donde fue instalado el sistema de toma
de decisiones durante las pruebas en entorno real. La interseccin donde se
realizaban las pruebas, se compona de 3 vas y 2 de ellas se abran de manera
simultnea. Con la ejecucin de esta regla se evita que exista una monopolizacin
entre estas dos vas que se abran de manera simultnea para dar paso a la
tercera.
91
92
if(currentTrafficLight.equals("Mesones") && !emergenciaMesones &&

!emergenciaCarretera
&& !emergenciaAlfares || emergenciaMesones)
93
94
95
openTrafficMesones = true;
96
openTrafficAlfares = false;
97
openTrafficCarretera = false;
98
99
else if(currentTrafficLight.equals("Alfares") && !emergenciaMesones
100
&& !emergenciaCarretera
&& !emergenciaAlfares || emergenciaAlfares)
101
102
103
openTrafficMesones = false;
104
openTrafficAlfares = true;
105
openTrafficCarretera = true;
106
if(emergenciaAlfares)
107
108
109
else if(currentTrafficLight.equals("Carretera") &&
110
!emergenciaMesones && !emergenciaCarretera

&& !emergenciaAlfares || emergenciaCarretera)
111
112
113
114
openTrafficAlfares = true;
115
openTrafficCarretera = true;
116
if(emergenciaCarretera)
117
118
~ 123 ~
En las anteriores lneas de cdigo es donde se hace efectiva la regulacin

semafrica. Como se puede comprar mediante las variables openTrafficXXXXX
siendo XXXXX el nombre de la va, se abren o cierran sus semforos. En el caso
particular de la interseccin citada en las pruebas en entorno real,
openTrafficAlfares y openTrafficCarretera siempre valen lo mismo excepto en las
situaciones donde existen equipos de emergencia aproximndose que slo se
abre el semforo correspondiente a la va por donde se aproximan.
119
if(zonaCriticaAlfares || zonaCriticaCarretera || zonaCriticaMesones)
120
121
122
123
}
124
125
time = 0;
126
127
Una de las ltimas reglas a comprobar y por tanto de las ms importantes es la

que controla que si se produce alguna situacin de las denominadas crticas. con
posibilidad de accidente ante algn vehculo que se ha introducido en la
interseccin an cuando estaba su semforo cerrado. En tal caso, se cierran todos
los semforos hasta que la situacin pase.
128
129
if(currentCarsMesones == 0 && currentCarsAlfares == 0 &&

currentCarsCarretera == 0
&& !emergenciaAlfares && !emergenciaCarretera &&
130
131
!emergenciaMesones && !zonaCriticaAlfares && !zonaCriticaCarretera &&
132
!zonaCriticaMesones)
133
134
time = timeGap + 1;
135
136
137
138
~ 124 ~
La ltima regla es la que cierra todos los semforos s no hay ninguna situacin
prioritaria. Los posibles peatones tienen paso libre.
~ 125 ~
8.5 Ejecucin de la decisin ptima

Este ltimo subsistema permite la implementacin real de los desarrollos de este
proyecto, ya que es el mdulo que se comunica directamente con el sistema de
semforos. Todos los procesos realizados en los dos anteriores subsistemas, el de
tratamiento digital de imgenes y el de sistema de toma de decisiones, desembocan
en este subsistema para que la decisin ptima, sea implementada en los
semforos que regulan una interseccin.
A la hora de hacer las simulaciones pertinentes, detalladas en el apartado

9.1 de este documento, no existe ninguna limitacin de implementacin ya que
todo se realiza por cdigo. La decisin ptima es ejecutada en tiempo real,
mediante este mdulo.
Sobre un entorno real existen muchas ms limitaciones para que esta

decisin sea implementada. Durante las pruebas en entorno real, detalladas en el
apartado 9.2 de esta memoria, las decisiones han sido implementadas utilizando
semforos de obra instalados en paralelo con los existentes. La decisin ptima
generada se ejecutaba en los semforos de obra mediante intervencin humana, no
pudiendo ser implementada la regulacin semafrica inteligente en tiempo real
sino con retardo. Sin embargo, los resultados obtenidos son prometedores tambin.
La integracin de seales en los sistemas de regulacin por semforos, que

depende del tipo de fabricante, queda fuera del alcance de este proyecto.
~ 126 ~
Captulo 9
Evaluacin del sistema
~ 127 ~
9. Evaluacin del sistema

A lo largo de este captulo se muestran y explican los resultados obtenidos al aplicar
el sistema desarrollado en este proyecto. Para una correcta interpretacin de los
resultados, se han realizado dos tipos de pruebas, unas usando entornos simulados
y otras usando un entorno experimental real.
Para evaluar la efectividad del sistema se han definido dos parmetros

calificables numricamente:
Tiempo de espera de los vehculos que atraviesan a la interseccin.
Nmero de arrancadas realizadas por los vehculos que se atraviesan a la
interseccin.
De los dos parmetros anteriores se infieren los ahorros en tiempos de

espera y la reduccin de emisiones contaminantes. En cambio, resulta imposible
mostrar con objetividad los resultados comparativos sobre paso prioritario de
vehculos de emergencia y sobre reduccin de accidentes potenciales. Para este fin,
durante las pruebas reales se realizaron aproximaciones a estos eventos, con
pruebas de estimacin de velocidad y de deteccin de un vehculo de emergencia
artificial mediante un dispositivo Bluetooth. Los resultados a estas aproximaciones
fueron satisfactorios, en cuanto a deteccin de los eventos, pero estos eventos no
fueron reales sino provocados intencionadamente.
~ 128 ~
9.1 Pruebas en entorno simulado

Con objeto de definir y ajustar las estrategias de control de trfico inteligente, se ha
utilizado un simulador, que permite analizar el comportamiento y obtener medidas
de la efectividad en tiempo acelerado.
Para el desarrollo de estas pruebas en entorno simulado se han estudiado

varios simuladores, entre ellos el desarrollado en [MISK07]. Pero por la simpleza
que muestra, se ha modificado
un simulador de trfico existente,
(http://vwisb7.vkw.tu-dresden.de/~treiber/MicroApplet/),
para
adecuarlo
al
contexto de este proyecto, la mejora del trfico en intersecciones reguladas por

semforos. El citado simulador fue modificado para que el trfico fluyese en modo
de interseccin o cruce. Por tanto ha sido necesaria la parametrizacin de este
simulador para que se pudiese simular una situacin aproximada a la que acontece
en las pruebas experimentales en entorno real.
9.1.1. Simulacin del trfico

En primer lugar, es necesario el estudio y ajuste de las distribuciones de
probabilidad para los tiempos entre llegada de vehculos a la interseccin. Gracias a
los datos de tiempos entre llegadas recabados durante pruebas experimentales, se
concluye que los tiempos de llegada entre vehculos por las tres vas que confluyen
en la interseccin analizada, se rigen por una distribucin exponencial.
Obviamente las tres vas tienen distinta afluencia de trfico con lo que los
parmetros de ajuste de las distribuciones son distintos para cada va. La
distribucin exponencial slo necesita de un parmetro, que es la media de los
tiempos entre llegadas. En la siguiente tabla se recogen los parmetros de ajuste de
cada va que confluye en la interseccin.
Va de estudio
Tiempo medio entre llegadas
Calle Alfares
11.5 segundos
Carretera CM-4101
24 segundos
Calle Mesones
16.5 segundos
Figura 79. Tabla que muestra la media de las distribuciones exponenciales que rigen los tiempos entre
llegadas de vehculos a la interseccin de estudio
~ 129 ~
9.1.2. Ejecucin de la simulacin

Para la contrastacin de resultados entre un esquema de regulacin
inteligente y un esquema de regulacin por patrones de tiempos fijos se han
ejecutado dos simulaciones distintas alimentadas con la misma secuencia de trfico
simulado, una para cada sistema de regulacin.
En las dos figuras se muestran los resultados obtenidos tras ejecutar la

simulacin durante un tiempo equivalente a 270 minutos, para las dos posibles
formas de regulacin semafrica. En cada imagen se muestran los segundos en
espera, arranques producidos, vehculos presentes en ese momento los vehculos
servidos desde el inicio de la simulacin (entre parntesis).
Figura 80. Simulacin de la interseccin de estudio usando una regulacin basada en patrones
Figura 81. Simulacin de la interseccin de estudio usando la regulacin inteligente propuesta
~ 130 ~
De las figuras anteriores se pueden inferir los resultados que,

presumiblemente, pueden ser obtenidos tras la aplicacin de una regulacin
inteligente sobre la interseccin actualmente regulada por patrones fijos preestablecidos.
9.1.3. Comparacin de resultados

El nmero de vehculos servidos durante ambas simulaciones, como se
puede comprobar en las figuras anteriores, es bastante similar. De otro modo, los
resultados que se pueden inferir no seran vlidos, pues corresponderan a
condiciones diferentes. La evaluacin se realiza atendiendo a dos conceptos: tiempo
de espera ahorrado y cantidad de arranques no realizados.
Como se muestran las siguientes figuras, el control inteligente reduce los

tiempos de espera un 74%, desde 20.849 segundos de espera acumulados durante
270 minutos de simulacin a 5.430 segundos. Por otro lado, el nmero de
arranques se reducen en 70 arranques, de 1.903 arranques sobre 3.240 vehculos
servidos, a 1.820 arranques sobre 3.265 vehculos servidos.
Figura 82. Grficas de resultados en entorno simulados que muestra la diferencia en tiempos de espera
entre una regulacin semafrica en funcin de patrones y una regulacin semafrica inteligente
~ 131 ~
Figura 83. Grficas de resultados en entorno simulados que muestra la variacin en trminos de arranques
producidos entre una regulacin semafrica por patrones y una regulacin semafrica inteligente
Las grficas anteriores muestran los datos recogidos por ambas

simulaciones, enfrentados en cierta manera para poder obtener la variacin
existente entre las simulaciones mediante una regulacin semafrica basada en
patrones y una regulacin inteligente. En tonos verdes se muestra una variacin
negativa que significa una ganancia de la regulacin inteligente propuesta en este
proyecto en comparacin con una regulacin en funcin de patrones fijos preestablecidos. Anlogamente en tonos rojos, se muestra una variacin positiva que
significa un empeoramiento de la regulacin inteligente.
Los resultados de la simulacin son muy alentadores y motivaron la

realizacin de pruebas experimentales que se exponen ms adelante en este
captulo. Sin embargo hay que tener en cuenta que estos resultados son simples
simulaciones en un entorno ideal donde imperan las siguientes caractersticas:
El ajuste de las distribuciones de tiempos entre llegadas de vehculos
infiere un cierto grado de error.
A la hora de contrastar estos resultados con situaciones reales hay
que tener en cuenta los errores de medicin inherentes a cualquier
proceso experimental.
Hay que tener en cuenta que en simulacin, se pasa de manera
instantnea de semforo abierto a semforo cerrado y viceversa. Por
~ 132 ~
lo que las diferencias entre los tiempos de espera son mucho ms

pronunciadas que las que se pueden llegar a conseguir en un entorno
real.
El simulador donde se han ejecutado estas simulaciones de trfico,
no es del todo perfecto con pequeos errores en el clculo de los
nmeros de arranques realizados.
A pesar de estas limitaciones, se considera que el simulador desarrollado

tiene gran valor para evaluar las mejoras que la regulacin inteligente puede
aportar a una interseccin concreta sin necesidad de realizar la instalacin.
~ 133 ~
9.2 Pruebas en entorno real

Gracias a la colaboracin del Excelentsimo Ayuntamiento de Talavera de la Reina y
de la Polica Local de esta ciudad, fue posible realizar unas pruebas experimentales
en un entorno real, utilizando una interseccin de la ciudad de Talavera de la Reina
por donde circulan un flujo medio de vehculos. Adems gracias al Instituto de
Investigacin Tecnolgica (IIT), centro de la Escuela Tcnica Superior de Ingeniera
(ICAI) de la Universidad Pontificia Comillas de Madrid, se han utilizado elementos
importantes para la realizacin de estas pruebas, como semforos de obra para
regular el trfico y cmaras IP para la captura de imgenes de la va. Estas pruebas
son el complemento perfecto para evaluar este proyecto con el fin de probar su
efectividad.
Para llevar a cabo estas pruebas, se utilizaron semforos de obra para que
fuesen instalados en paralelo con los semforos existentes. Sobre estos semforos
de obra se instalaron cmaras IP y antenas Bluetooth, que aportaron informacin
de todas las intersecciones del cruce. Para ms informacin sobre cmo llevar a
cabo la instalacin de todos los elementos de este proyecto, es debido consultar el
apndice 1 Manual de Instalacin, incluido en esta memoria.
La siguiente figura muestra la interseccin real en la que se realizaron las

pruebas experimentales.
Calle
Alfares
Calle
Mesones
Figura 84. Mapa de situacin de la interseccin donde se realizaron las pruebas en entorno real
~ 134 ~
Ejemplos de imgenes de cada uno de los semforos donde fueron

instaladas las cmaras son las siguientes:
Calle Alfares
Carretera CM-4101
Calle Mesones
Figura 85. Conjunto de imgenes de ejemplos de las capturas realizadas en la interseccin
9.2.1. Pruebas realizadas

El plan de pruebas diseado por el equipo de este proyecto estaba formado
por los siguientes pasos:
Instalacin de todos los elementos necesarios para la puesta en marcha de
este proyecto. El orden y la forma de instalacin se encuentran detallados
en el apndice 1 de esta memoria.
Grabacin durante 25 minutos del trfico que fluye sobre la interseccin
para que comparar datos obtenidos sobre tiempos de espera, nmero de
arrancadas y vehculos servidos.
Durante 5 minutos, proceder a la puesta en marcha de los semforos de
obra, cmaras IP, antenas Bluetooth y sistema de toma de decisiones.
Durante otros 25 minutos, grabar como el fluye el trfico sobre la
interseccin atendiendo a la regulacin semafrica inteligente que se
aplicaba sobre los semforos de obra.
~ 135 ~
5 minutos para desinstalar toda la instrumentacin de este proyecto.

Realizar un anlisis para comparar entre los datos obtenidos durante las dos
grabaciones de 25 minutos, para obtener las diferencias de usar una
regulacin basada en patrones de tiempos fijos y una regulacin de
semforos inteligente.
El esquema de regulacin actualmente implementado, tiene un periodo de

60 segundos y consiste en dos ciclos. Uno de ellos era de 45 segundos de duracin
teniendo los semforos de la calle Alfares y de la carretera CM-4101 abiertos, el
semforo de la calle Mesones permaneca cerrado, como es obvio. El otro ciclo era
de 15 segundos, teniendo abierto el semforo de la calle Mesones y cerrados los
otros dos.
Los ensayos experimentales se realizaron el sbado 23 de Mayo de 2009

entre las 21:30 horas y las 22:30 horas. La eleccin de este horario fue debida a dos
razones: no se quera intervenir en un trfico demasiado denso y adems se quera
afrontar el reto de detectar vehculos en zonas sin luz natural, puesto que es ms
difcil la deteccin de vehculos que en zonas con luz natural.
9.2.2. Resultados obtenidos

Los resultados en funcin de tiempos de espera y nmero de arrancadas se
muestran en las siguientes grficas. Las barras representan la suma de todos los
tiempos de espera en cada calle, durante los 25 minutos que dur cada ensayo.
Aplicando el sistema de regulacin inteligente se disminuye a la mitad los

tiempos de espera.
~ 136 ~
Figura 86. Grficas de resultados de diferencia en tiempos de espera entre una regulacin semafrica en
funcin de patrones y una regulacin semafrica inteligente
Anlogamente, en la siguiente figura se representa el nmero de

operaciones de parada y arranque que se producen en cada va durante los
ensayos.
Figura 87. Grficas de resultados de diferencia en nmero de arrancadas entre una regulacin semafrica
en funcin de patrones y una regulacin semafrica inteligente
~ 137 ~
En relacin al ahorro en cuanto a emisiones contaminantes, es necesario

transformar el tiempo de espera y el nmero de arrancadas en su correspondencia
en emisiones. Para ello se utilizan valores de consumo y emisiones obtenidos a
partir de un estudio realizado en vehculos ligeros [GON05]. Segn este artculo,
un vehculo ligero como un Opel Corsa 1.2 tiene los siguientes valores de consumo y
emisiones, significando LSG: Long Stop and Go.
Figura 88. Tabla de consumos y emisiones para un Opel Corsa 1.2
Por tanto, los valores correspondientes a los ensayos realizados son los
siguientes:
Combustible
Calle Alfares
Calle Mesones
Carretera CM-4101
TOTALES
Calle Alfares
Calle Mesones
Carretera CM-4101
TOTALES
1 arranque
55
4
9
68
1 segundo parado sin A/C

780
284
185
1249
CO2
CO
NOx
5 gramos
275
20
45
340
17.8 gramos
979
71,2
160,2
1210,4
-4
-4
Combustible
CO2
CO
0.18 gramos
140,4
51,12
33,3
224,82
0.57 gramos
444,6
161,88
105,45
711,93
2.5 * 10-4 gramos

0,195
0,071
0,04625
0,31225
HC
1.1 * 10 gramos 9.5 * 10 gramos 8.5 * 10-4 gramos

0,00605
0,05225
0,04675
0,00044
0,0038
0,0034
0,00099
0,00855
0,00765
0,00748
0,0646
0,0578
Figura 89. Tabla que cuantifica los ahorros de combustible y de emisiones contaminantes para un vehculo
ligero durante las pruebas ejecutadas en entorno real
~ 138 ~
Captulo 10
Conclusiones
~ 139 ~
10. Conclusiones
A modo de resumen, se enumeran las conclusiones ms importantes y las que
impactan de lleno con la motivacin y objetivos planteados al inicio.
La regulacin de semforos basada en patrones de tiempo pre-establecidos,

es efectiva, pero puede ser mejorada sensiblemente.
Es posible la creacin de un sistema de regulacin inteligente utilizando

recursos mnimos. El sistema propuesto se basa en la utilizacin de cmaras
de fcil instalacin que permiten obtener el nmero de vehculos mediante
tratamiento digital de imgenes.
La implantacin de un sistema de regulacin inteligente mejora con creces el

rendimiento de un esquema de regulacin tradicional, como se ha
demostrado mediante simulacin y ensayos experimentales.
Los tiempos de espera de los vehculos que circulan por una interseccin y el
nmero de paradas y arranques pueden ser reducidos por medio de
sistemas de regulacin inteligente de trfico.
Como consecuencia del punto anterior, las emisiones contaminantes

tambin pueden reducirse al permanecer los vehculos durante menos
tiempo esperando en la interseccin y al reducir el nmero de arrancadas.
Se puede dotar de prioridad de paso absoluta a equipos de emergencia y

transporte pblico mediante el uso de sistemas de detectores Bluetooth
desarrollados en el proyecto.
El nmero de accidentes en intersecciones debido a vehculos que cruzan la

interseccin an cuando no les est permitido, puede reducirse gracias al
detector de velocidad basado en tratamiento de imgenes.
~ 140 ~
10.1 Trabajos futuros

Las siguientes directrices recogen una serie de mejoras que se pueden realizar a
este proyecto, siendo base todo lo desarrollado e incluido en esta memoria.
Mejorar tiempo de respuesta del proceso de tratamiento digital de

imgenes: el citado proceso de tratamiento digital de imgenes no tiene una
duracin fija, puesto que vara en funcin del nmero de elementos que
detecta en la imagen y que deben ser clasificados o no como vehculos.
Mediante la utilizacin de Simulink, integrando todo el proceso de
tratamiento digital de imgenes en un microprocesador, el tiempo de
respuesta al procesar una imagen puede reducir drsticamente, aunque
seguira siendo indeterminado. Sin tener que depender de la ejecucin de
MATLAB y de la integracin necesaria para que se comunique con el sistema
de decisiones, el tiempo de respuesta de todo el sistema se vera reducido.
Mejorar tiempo de respuesta del sistema de toma de decisiones: en las

pruebas experimentales se ha utilizado slo un equipo porttil para todo el
proceso: tratamiento digital de imgenes y generacin de la decisin
ptima. Por este motivo, el tiempo de respuesta del sistema de toma de
decisiones no era todo lo rpido que se puede esperar. Este aspecto fue
detectado a la hora de realizar las pruebas en entorno real ya que la
informacin de las tres vas de la interseccin era procesada por un nico
equipo.
Mltiples soluciones para mejorar este aspecto pueden ser llevadas a cabo:
o Realizar todo el proceso con un equipo ms potente. Sobre todo en
cuanto a capacidad de memoria RAM.
o Procesar cada va en equipos separados y que el sistema de toma de
decisiones slo sea un equipo que se encargue de tomar la decisin y
no de realizar todo el proceso de tratamiento de imgenes.
~ 141 ~
Deteccin de vehculos especiales: no ha sido posible realizar una deteccin

automtica de vehculos de emergencia basada exclusivamente en
tratamiento de imgenes, por lo que se ha optado por la deteccin
mediante el uso de antenas Bluetooth unidireccionales. Sin embargo esta
solucin requiere que los vehculos autorizados dispongan de emisores
Bluetooth validados, lo cual encarece el sistema en ciudades medianas o
grandes. Sera mucho ms interesante conseguir detectar los vehculos
especiales mediante tratamiento de imgenes o con apoyo de sensores de
sonido que detectan sirenas. Otra posibilidad ms sofisticada sera habilitar
la posibilidad de recibir mensajes de prioridad de paso. Estos mensajes
podran estar emitidos por los sistemas de control de flotas de los equipos
de emergencia, ya que estos conocen la posicin y trayectoria inmediata de
estos vehculos prioritarios.
Mejorar algoritmo de estimacin de la velocidad de vehculos que se

aproximan a la interseccin: el algoritmo propuesto en el apartado 6.8 de
esta memoria, realiza la estimacin de la velocidad cumpliendo
perfectamente los requisitos necesarios para detectar si un vehculo va a
cruzar indebidamente. Aplicando clculo trigonomtrico se puede obtener
una estimacin precisa de la velocidad de los vehculos en cada momento,
que puede resultar interesante como dato del estado del trfico.
~ 142 ~
10.2 Otras aplicaciones del sistema

Modificaciones del desarrollo de este proyecto pueden ser realizadas para cubrir
requisitos y objetivos en otros contextos. Algunas ideas, de las muchas posibles, se
enumeran a continuacin.
Implementar un sistema de regulacin inteligente de semforos en

entornos que no sean intersecciones: existen ms mbitos de aplicacin de
este proyecto donde existen semforos pero no necesariamente en
intersecciones. Desde estaciones de autobuses, para regular la entrada y
salida ordenada de ellos, hasta lneas industriales donde slo es posible el
proceso de una serie de elementos a la vez a seleccionar entre varios que
confluyan hacia una misma mquina. El concepto es el mismo, detectar y
contabilizar elementos, y a partir de los elementos detectados y a unas
restricciones a cubrir tomar la decisin ptima.
Creacin de un sistema inteligente de enrutamiento del trfico: mediante

la utilizacin del subsistema de tratamiento digital de imgenes de este
proyecto, se podra detectar el grado de ocupacin de las vas de una ciudad
usando las cmaras de trfico instaladas a lo largo de la ciudad. Ya que estas
cmaras son accesibles por Internet, se podra crear una aplicacin online
que mediante el tratamiento de estas imgenes disponibles al pblico pueda
indicar la ruta ptima a tomar, en funcin del grado de ocupacin de las
vas. Los sistemas actuales de generacin de trayectorias (navegadores GPS)
ya tienen algoritmos preparados para utilizar la informacin del estado del
trfico. Una solucin ya implementada es la que se encuentra en
http://infocar.dgt.es/etraffic/. El enfoque utilizando este proyecto es realizar
la misma solucin pero sin tener que recurrir a los sensores que se utilizan
para la solucin de la Direccin General de Trfico. El nico problema
potencial que puede darse es que las cmaras cambien su posicin y por
tanto habra que actualizar el sistema para indicar donde se encuentra el
carril de estudio para ver la ocupacin exacta de las vas. Ejemplos de la
~ 143 ~
aplicacin del subsistema de tratamiento digital de imgenes sobre capturas

realizadas por las cmaras de la Direccin General de Trfico son las
siguientes:
Figura 90. Grado de ocupacin rojo debido a la cantidad de vehculos en entornos de noche
Figura 91. Grado de ocupacin amarillo puesto que hay buena circulacin aunque no del todo fluida
Figura 92. Grado de ocupacin verde ya que la circulacin es fluida
~ 144 ~
Captulo 11
Planificacin
~ 145 ~
11. Planificacin
En relacin a la planificacin seguida para el desarrollo satisfactorio de este
proyecto, es necesario detallar completamente tanto el equipo de proyecto como
los distintos paquetes en los que se ha subdividido el trabajo para integrar ambos
aspectos.
El equipo de proyecto, compuesto por tres personas que realizan varios

roles a la vez, es el que muestra la siguiente figura:
Coordinador (CO)
David Contreras
Director de Proyecto 1
(DP1)
Director de Proyecto 2
Rafael Palacios
David Contreras
(DP2)
Jefe de Proyecto
(JP)
Ernesto de la Rocha
Analista (A)
Investigador 1 (I1)
Investigador 2 (I2)
Programador (P)
Tester (T)
Ernesto de la Rocha
Rafael Palacios
David Contreras
Ernesto de la Rocha
Ernesto de la Rocha
Figura 93. Esquema de distribucin de los roles a travs del equipo de proyecto
Como se puede comprobar en la anterior figura, como posiciones de gestin,

existe la figura del coordinador del proyecto y por debajo de l existen los
directores de proyecto. El resto de posiciones, que no son de gestin, son cubiertas
por todo el equipo de proyecto.
Los distintos paquetes de trabajos en los que queda divido se encuentran

definidos en la siguiente figura, denominada Estructura de Divisin del Trabajo
(EDT). La subdivisin generada puede llegar a considerarse demasiado generalista,
pero es la enunciada por la metodologa empleada por el desarrollo de este
proyecto, Extreme Programming.
~ 146 ~
Proyecto
TEA
WP 01
WP 02
WP 03
Gestin Proyecto
Desarrollo Sistema
Pruebas
WP 01.01
Documentacin
WP 02.01
WP 03.01
Algoritmo deteccin
de vehculos
Creacin del
simulador
WP 01.02
WP 02.02
WP 03.02
Seguimiento
Proyecto
Algoritmo estimacin
de velocidad
Ejecucin de pruebas
en simulador
WP 02.03
WP 03.03
Algoritmo deteccin de
vehculos de emergencia
Creacin de plan de
pruebas en entorno real
WP 02.04
WP 03.04
Sistema de toma de
decisiones
Ejecucin de pruebas
en entorno real
WP 02.05
WP 03.05
Integracin de todos
los mdulos
Estudio de resultados
obtenidos
Figura 94. Estructura de Divisin del Trabajo
De la integracin entre las funciones que ejecutan los distintos miembros del
equipo de trabajo con la Estructura de Divisin del Trabajo propuesta, resulta en la
siguiente tabla de ocupacin de rol por cada paquete de trabajo.
Horas/Hombre por Work Package/Rol
CO DP1 DP2 JP
WP - 01.01 Documentacin
16
WP - 01.02 Seguimiento proyecto
8
TOTALES WP - 01 GESTIN PROYECTO
24
WP - 02.01 Algoritmo deteccin de vehculos
WP - 02.02 Algoritmo estimacin de velocidad
WP - 02.03 Algoritmo deteccin de vehculos de emergencia
WP - 02.04 Sistema de toma de decisiones
WP - 02.05 Integracin de todos los mdulos
TOTALES WP - 02 DESARROLLO SISTEMA
WP - 03.01 Creacin del simulador
WP - 03.02 Ejecucin de pruebas en simulador
WP - 03.03 Creacin de plan de pruebas en entorno real
WP - 03.04 Ejecucin de pruebas en entorno real
WP - 03.05 Estudio de resultados obtenidos
TOTALES WP - 03 PRUEBAS
Totales por Rol 24
8
32
40
16
8
8
16
24
16
4
28
8
8
8
4
28
96
8
24
4
4
8
8
4
28
76
40
40
80
16
8
4
4
4
36
4
16
16
4
40
156
I1
I2
24
24
4
4
4
4
8
24
4
4
4
4
8
24
72
8
8
8
16
16
Totales por Work Package
8
40
8
8
16
24
96
40
4
32
16
4
4
16
72
8
8
16
108
96
204
116
52
44
32
60
304
56
28
36
60
20
200
708
Horas/Hombre
48 32
152 108
Figura 95. Tabla de distribucin del trabajo en funcin del rol y del paquete de trabajo
~ 147 ~
~ 148 ~
WP - 01.01 Documentacin
WP - 01.02 Seguimiento proyecto
WP - 02.01 Algoritmo deteccin de vehculos
WP - 02.02 Algoritmo estimacin de velocidad
WP - 02.03 Algoritmo deteccin de vehculos de emergencia
WP - 02.04 Sistema de toma de decisiones
WP - 02.05 Integracin de todos los mdulos
WP - 03.01 Creacin del simulador
WP - 03.02 Ejecucin de pruebas en simulador
WP - 03.03 Creacin de plan de pruebas en entorno real
WP - 03.04 Ejecucin de pruebas en entorno real
WP - 03.05 Estudio de resultados obtenidos
Work Package
Sept. 2008
2
Oct. 2008
6
Nov. 2008
Dic. 2008
Ene. 2009
Feb. 2009
Mar. 2009
Abr. 2009
May. 2009
Jun. 2009
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Una vez finalizado el proyecto, se concluye que la carga en horas de trabajo
ha resultado ser de 708 horas de trabajo y la manera de distribuir esas horas a lo
largo de 9 meses se detalla en el siguiente esquema.
Figura 96. Planificacin a lo largo de los nueve meses de desarrollo
Captulo 12
Estimacin econmica
~ 149 ~
12. Estimacin econmica

En este captulo se muestra una estimacin en trminos monetarios del coste que
ha supuesto realizar este proyecto.
Para la realizacin de este proyecto slo han intervenido dos entidades. Por
un lado se encuentra el trabajo realizado por el equipo de proyecto, recogido en
unidades de horas/hombre. Y por otro lado se han utilizado ciertos materiales para
llevar a cabo el desarrollo del proyecto y las pruebas pertinentes.
En las siguientes tablas se encuentran las estimaciones del coste tanto de

personal como de instrumentos. Ya que el siguiente clculo es una estimacin, se
han utilizado precios estndares de horas / hombre para la estimacin del coste de
personal.
Rol
Coordinador
Director de proyecto
Jefe de proyecto
Analista
Investigador
Programador
Tester
Horas
24
172
152
72
24
152
108
Precio por hora

70
60
40
30
30
20
20
Total por rol

1.680
10.320
6.080
2.160
720
3.040
2.160
Total personal
26.160
Figura 97. Estimacin del coste de personal para realizar este proyecto
Instrumento
Cmaras IP
Antenas Bluetooth
Alquiler semforos de obra. Medidos en das
Router wireless
Otros componentes hardware (cables, bateras, pilas)
Cantidad Precio Unitario

3
210
1
10
9
30
1
50
//
50
Total Instrumentos
Coste
630
10
270
50
50
1.010
Figura 98. Estimacin del coste de instrumentos necesarios para realizar este proyecto
Para finalizar, el resultado total de las estimaciones es el siguiente:

Total personal
26.160
Total instrumentos
1.010
Total Proyecto
27.170
Figura 99. Estimacin del coste total para realizar este proyecto
~ 150 ~
Captulo 13
Bibliografa
~ 151 ~
13. Bibliografa
[DGT_07] Direccin General de Trfico, Anuario estadstico de accidentes 2007.
Pgina 100. 2007
[GRAD07] Gradinescu, V., Gorgorin, C., Diaconescu, R., Cristea, V., Iftode, L.,
Departament of Computer Science, Politehnica University of Bucharest, Adaptive
Traffic Lights Using Car-to-Car Communication. 2007
[BECK99] Beck. K., Embracing change with Extreme Programming,
Computer
Volume 32, Number 10, pp. 70-77, 1999.
[GAJD01] Gajda, J., Sroka, M., Stencel, A., Wajda, A., Zeglen, T., A vehicle
classification based on inductive loop detectors, Proc. 18th IEEE Conf. IMTC, vol. 1,
pp.460-464, 2001.
[WANG92] Wang, J., Case, E.R., Manor, D., The Road Traffic Microwave Sensor
(RTMS), Int. Conf. Vehicle Navigation and Information System, pp. 83-90, 1992.
[CARU01] Carullo, A., Parvis, M., An ultrasonic sensor for distance measurement in
automotive applications, Sensors Journal, IEEE, vol. 1, pp. 143-147, August 2001.
[ANDR02] Andreone, L., Antonello, P.C., Bertozzi, M., Broggi, A., Fascioli, A.,
Ranzato, D., Vehicle detection and localization in infra-red images, The IEEE 5th
International Conference on Intelligent Transportation Systems, 2002.
[KAST01] Kastrinaki, V., Zervakis, M., Kalaitzakis, K., A survey of video processing
techniques for traffic applications, Image and Vision Computing, vol. 21, pp. 257261, June 2001.
[ENGH08] Eng How-Lung, Thida, M., Boon-Fong, C., Leman, K., Anggrelly, S.Y.,
Model-based detection and segmentation of vehicles for intelligent transportation
~ 152 ~
system 2008 3rd IEEE Conference on Industrial Electronics and Applications, vol. 1,
pp. 2127-2132, June 2008.
[PAPA00] Papageorgiou, C., Poggio, T., A trainable system for object detection
International Journal Computer Vision, vol.38, no. 1, pp. 15-33, 2000.
[PORN08] Pornpanomchai, C., Liamsanguan, T., Vannakosit, V., Vehicle detection
and counting from a video frame 2008 International Conference on Wavelet
Analysis and Pattern Recognition, vol. 1, pp. 356-361, August 2008.
[ANGU08] Angulo, E., Romero, F.P., Garca, R., Serrano-Guerrero, J., Olivas, J.A, A
methodology for the automatic regulation of intersections in real time using softcomputing techniques, Modelling, Computation and Optimization in Information
Systems and Management Sciences Second International Conference MCO 2008.
[CHAK04] Chakraborty, G., Naik, K., Chakraborty, D., Shiratori, N., Wei, D., Analysis
of the Bluetooth device discovery protocol, Vehicular Technology Conference, 2004.
[MISK07] Miska, M.P., Microscopic Online Simulation for Real Time Traffic
Management, 2007.
[GON05] Gonalves, G.A., Farias, T.L., On-road measurements of emissions and
fuel consumption of gasoline fuelled light duty vehicles, Clean Air 2005 - Eight
International Conference on Technologies and Combustion for a Clean
Environment, 2005.
~ 153 ~
Apndice I
Manual de instalacin
~ 154 ~
Apndice 1. Manual de instalacin

En relacin con las pruebas realizadas en un entorno real, detalladas en el apartado
9.2 del presente documento, se incluyen a continuacin el orden de pasos
realizados para llevar a cabo toda la instalacin de la instrumentacin vinculada a
este proyecto.
Este manual de instalacin puede ser extrapolado para ser utilizado a la hora
de instalar el sistema que propone este proyecto en otros entornos reales. Sin
embargo el entorno software debe ser el mismo al utilizado para el desarrollo de
este proyecto. Los siguientes programas y las correspondientes versiones que
deben ser previamente instaladas son las siguientes:
MATLAB 7.6.0 para Linux.
o Toolbox de tratamiento digital de imgenes.
o Toolbox de MATLAB JA Builder.
JAVA JDK 1.6 o anterior.
Los pasos para llevar a cabo una ejecucin de este proyecto son los que se
indican en el siguiente orden:
1. Identificar cada cmara IP instalada con la IP esttica que le corresponda.

2. Instalar un nuevo set de pilas a las cmaras IP.
3. Posicionar cmaras IP y antenas Bluetooth sobre los semforos. Con la mayor
altura posible, intentando alcanzar el mayor ngulo posible de visin centrada
sobre el carril de estudio.
4. Conectar antenas Bluetooth al centro de control del sistema de toma de
decisiones.
5. Conectar batera a router Wireless.
6. Verificar conexionado correcto entre cmaras mediante un acceso web.
7. Clculo e introduccin de parmetros necesarios:
a. Carril de estudio.
~ 155 ~
b. Imagen de carril de estudio sin vehculos.

c. Recta de direccin de los vehculos sobre el carril de estudio.
d. Zona de estudio de correlacin.
8. Puesta en funcionamiento de todo el sistema, vinculado las decisiones
mostradas por el centro del control del sistema de toma de decisiones con los
semforos.
~ 156 ~

Semf Imagenes y Blue Toot PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Semf Imagenes y Blue Toot PDF

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)

PROYECTO FIN DE CARRERA

MEJORA DEL TRFICO EN UN CRUCE

AUTOR: ERNESTO DE LA ROCHA GMEZ

MADRID, JUNIO 2009

Autorizada la entrega del proyecto del alumno:

El Co-Director del Proyecto

El Co-Director del Proyecto

V B del Coordinador de Proyectos

UNIVERSIDAD PONTIFICIA COMILLAS

PROYECTO FIN DE CARRERA

MEJORA DEL TRFICO EN UN CRUCE

AUTOR: ERNESTO DE LA ROCHA GMEZ

MADRID, JUNIO 2009

Nobody said it was easy,

Pequeo espacio es pues, se necesitara otro documento de la misma

Comenzando con la idea de aquella noche de 2005, a lo largo de estos

Otro momento importante para el desarrollo de este proyecto fue durante

Parte importante de culpa de la existencia de este proyecto es tambin

Por ltimo, debo agradecer y agradezco la colaboracin de toda esa gente,

El sistema, denominado TEA (Traffic Enhancement Application) tiene como

Como valor aadido de este proyecto, tambin gracias al tratamiento digital

Por otro lado, la manera de discrepar entre vehculos de emergencia,

Tanto los resultados de la deteccin de los vehculos que se aproximan a la

Los tres mdulos anteriormente citados: deteccin y contabilizacin de

Respecto a la evaluacin en un entorno simulado, se incluye en este

Respecto a la evaluacin en un entorno real, se han realizado pruebas

Los resultados de las pruebas experimentales son satisfactorios, reafirmando

En definitiva, se cubren satisfactoriamente los objetivos propuestos para

This intelligent system, also known as TEA (Traffic Enhancement

As an added value to this project, an algorithm for estimating current vehicle

The way of identifying the kind of vehicle that is approaching, is based on

Modules referenced above: detecting and counting vehicles, detecting

In reference to this project evaluation on simulated environments, a traffic

In reference to this project evaluation on real environments, experimental

6. Mdulo de tratamiento digital de imgenes ............................................. 18

7. Mdulo de deteccin de vehculos prioritarios ........................................ 90

7.3. Algoritmo de deteccin de vehculos de emergencia .............................................. 97

8. Sistema de toma de decisiones ..................................................................... 105

9. Evaluacin del sistema ..................................................................................... 127

10. Conclusiones ...................................................................................................... 139

11. Planificacin ....................................................................................................... 145

Ernesto de la Rocha Gmez

Universidad Pontificia Comillas

Por qu est el semforo en rojo y no puedo pasar aunque no haya otros

Por qu los semforos duran siempre lo mismo si el nmero de vehculos que

Este proyecto quiere responder a las anteriores preguntas enunciando que

Por tanto, como motivacin principal de este proyecto est la comprobacin

Ernesto de la Rocha Gmez

Universidad Pontificia Comillas

Se puede considerar a este proyecto de ambicioso y de largo alcance,

De forma paralela a toda la motivacin comentada, hay que aadir que el

A lo largo de esta memoria se van a ir realizando desarrollos y conclusiones

Ernesto de la Rocha Gmez

Universidad Pontificia Comillas

Ernesto de la Rocha Gmez

Universidad Pontificia Comillas

Figura 1. Ilustracin de una interseccin cualquiera

El concepto principal de este proyecto es la creacin de un sistema

Los beneficios que pueden resultar de la aplicacin de este proyecto son

Ernesto de la Rocha Gmez

Universidad Pontificia Comillas