INSTITUTO POLITÉCNICO NACIONAL Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas Trabajo Terminal Sistema Asistente de Navegación en Carretera Integrado en Autobuses Para obtener el título de Ingeniero en Mecatrónica Presentan: Salvador Martínez Luis Eduardo Ángel Medina Pablo Asesores: M. en C. Anzueto Ríos Álvaro Ing. Trejo Salazar David Benjamín México, D. F., a 18 de Diciembre del 2012
125
Embed
Ingeniero en Mecatrónica...Motocicletas Autobuses Camiones pesadoscarretero Peatones Otros Tabla 1 Promedio de muertes por año en accidentes viales. Tipo de Transporte Promedio …
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
INSTITUTO POLITÉCNICO NACIONAL
Unidad Profesional Interdisciplinaria en
Ingeniería y Tecnologías Avanzadas
Trabajo Terminal
Sistema Asistente de Navegación en
Carretera Integrado en Autobuses
Para obtener el título de
Ingeniero en Mecatrónica
Presentan:
Salvador Martínez Luis Eduardo
Ángel Medina Pablo
Asesores:
M. en C. Anzueto Ríos Álvaro
Ing. Trejo Salazar David Benjamín
México, D. F., a 18 de Diciembre del 2012
i
Í ndice de contenido
Resumen………………….…………………………………………………………………………………………………………………...1 Abstract………………………………………………………………………………………………………………………………………...1 Objetivo general…………………………………………………………………………………………………………………………….3 Objetivos específicos…………………………………………………………………………………………………………………….3 Capítulo 1 Introducción 1.1 Antecedentes…………………………………………………………………………………………………………………………..7 1.1.1 Causas de accidentes viales………………………………………………………………………………………8 1.1.2 Factores en accidentes viales……………………………………………………………………………………9 1.1.3 Prevención en factores de accidentalidad……………………………………………………….….…..10 1.2 Definición del problema…....…………………………………………..………………………….…………………………..11 1.2.1 Justificación del proyecto…………………………………..…………………………..……………………….12 Capítulo 2 Marco Teórico 2.1 Teoría: Estudios de Dr. Manuel Mateos de Vicente……………………………………………………..…………14 2.1.1 Método: Como aplicar seguridad activa en vehículos………………………………………………15 2.2 Sustentación: Tecnología y seguridad………………………………………..……………………………………………16 2.3 Benchmarking: por objetivos específicos de sistema ANC……………..……………………………………….17
2.3.1 Benchmarking: Sistemas en mercado congruentes con sistema ANC………………………18 2.4 Posibles soluciones: Ingeniería Mecatrónica……………………………………..……………………………………18 2.4.1 ¿Qué es la Mecatrónica? o ¿cómo se puede definir?..............................................18 Capítulo 3. Diseño conceptual 3.1 Diagrama de funciones…………………………………………………………………………………………………………..22 3.2 Diagrama morfológico………………………………………………………………………………………………………..….22 3.3 Solución propuesta…………………………………………………………………………………………………………………25 3.4 Conclusiones parciales Marco Teórico………………………………………………………………………………..….27 Capítulo 4. Desarrollo (Modelo en V) 4.1 Fase Inicio del Proyecto……………………………………………………………………………………….…………………31 4.2 Fase Especificaciones…………………………………………………………………………………………….……………….32
4.2.1 Fase Test especificaciones……………………………………………………………………………………….32 4.3 Fase Funcional……………………………………………………………………………………………………….………….……33
4.3.1 Fase Test Funcional…………………………………………………………………………………………………33 4.4 Fase Diseño ……………………………………………………………………………………………………………………………34
4.4.1 Simulador equipo Boletera…………………………………………………………………….…………….…35 4.4.2 Fase Test de Diseño ………………………………………………………………………………….………….…36 4.4.3 Diagramas IDEF……..……………………………………………………………………………….…………….…36 4.4.4 Simulador de codificación Matlab……………………………………………………………..………..….38
4.5 Fase Codificación……………………………………………………………………………………………………….………..…38 4.6 Conclusiones Parciales Desarrollo.…………………………………………………………………………….……………40
ii
Capítulo 5. Diseño a Detalle 5.1 Especificaciones indirectas…………………………………………………………………………………………....………42 5.2 Distancia de frenado y tiempo de procesamiento………………………………………………………..……..…42 5.3 Geometría de carretera…………………………………………………………………………………………………….……45
5.3.1 NORMA OFICIAL MEXICANA NOM-034-SCT2-2003…………………………………………………45 5.3.2 Adquisición de imagen de carretera…………………………………………………………………….…47
Capítulo 6. Detección de líneas verticales de carretera 6.1 Algoritmos para detección de bordes………………………………………………………….………………….........52
6.1.1 Fase Especificaciones………………………………………………………………………………………………53 6.1.2 Fase Funcional………………………………………………………………………………………………………...53 6.1.3 Fase Diseño …………………………………………………………………………………………………………….54 6.1.4 Fase Codificación………………………………………………………………………………………………….…56 6.1.5 Fase Test Diseño ………………………………………………………………………………………………….…57 6.1.6 Fase Test Funcional…………………………………………………………………………………………………57 6.1.7 Fase Test Especificaciones……………………………………………………………………….............…58
6.2 Algoritmo conversor de Escala de grises a Binario……………………………………………………………….…64 6.2.1 Histograma de bordes…………………………………………………………………………………………..…65 6.2.2 Fase de Especificaciones……………………………………………………………………………………….…66 6.2.3 Fase Funcional…………………………………………………………………………………………………………66 6.2.4 Fase Diseño…………………………………………………………………………………………………………..…67 6.2.5 Fase de Codificación……………………………………………………………………………………………..…67
6.3 Detector de líneas……………………………………………………………………………………………………………..……68 6.4 Conclusiones parciales detector de líneas……..…………………………………………………….………........…73 Capítulo 7.Deteccion de objetos en carretera 7.1 Detección de objetos sobre carretera……………………………………………………………………………….……76
7.1.1 Algoritmo para la detección de Blobs………………………………………………………………………76 7.1.2 Fase Especificaciones………………………………………………………………………………………………77 7.1.3 Fase Funcional…………………………………………………………………………………………………………77 7.1.4 Fase Diseño…….………………………………………………………………………………………………………78 7.1.5 Fase Codificación……………………………………………………………………………………………….……79
7.2 Filtro de objeto por área de pixeles…………………………………………………………………………..……………80 7.2.1 Fase de Especificaciones…………………………………………………………………………………….……81 7.2.2 Fase Funcional…………………………………………………………………………………………………………82 7.2.3 Fase Diseño…………………………………………………………………………………………………..…………83
7.3 Centroide de un blob………………………………………………………………………………………………………………83 7.4 Uso de parámetros…………………………………………………………………………………………………………………85 7.5 Conclusiones parciales detección de objetos en carretera………………………………………………………86 Capítulo 8.Distancia de seguridad entre vehículos 8.1 Distancia de seguridad entre vehículos……………………………………………………………………….……….…88 8.2 Conclusiones parciales detección de distancia de seguridad………………………………………………..…92
iii
Capítulo 9.Detección de baja luminosidad en carretera. 9.1 Detección de baja luminosidad en carretera………………………………………………………………………..…94 9.2 Procesamiento con cámara sensible al IR (infrarrojo)………………………….…………………………….……96
9.2.1 Detección de líneas de carretera en IR.……………………………..……………………………………96 9.3 Conclusiones parciales detección de baja luminosidad en carretera……………………………………….97 Capítulo 10.Discusión sobre la elección del diseño final. 10.1 Partiendo con un objetivo…………….………………………………………………..…………………………………...98 10.2 Atributos del sistema como parte de la elección de diseño……….…..…………………………………….99 10.3 Descripción de la cronología de diseño implementada en el sistema de navegación……………99
10.4 Conclusiones parciales discusión sobre la elección del diseño final…………………………………….100 Conclusiones generales……………………………………………………………………………………………………………...101 Anexos..……………………………………………………………………………………….........…………………………………….102 Referencias…………………………………………………………………………………………………………..…………………….120 Bibliografía………………………………………………………………….……………………………………………………………..121
1
Resumen: De acuerdo con las Estadísticas de Transporte de América del Norte; el número de percances fatales en medios de transporte en México provocaron 11,616 decesos en el 2010, tomando en cuenta que el número de accidentes en transporte carretero sumaron 11,584 decesos en el mismo año. Se puede decir que la gran incidencia de percances fatales sucede en carretera, teniendo estos incidentes los siguientes factores en común: Los accidentes ocurrieron súbita e inesperadamente, los percances fueron originados por condiciones y actos irresponsables, en su mayoría se catalogaron como “potencialmente previsibles”, mayoritariamente fueron atribuidos a factores humanos y acontecieron en vehículos preponderantemente automotores. Tomando en cuenta que los accidentes ocurridos fueron catalogados como “potencialmente previsibles”[…] (1),
con este proyecto de investigación se busca desarrollar un sistema asistente de navegación, el cual podría apoyar
al conductor a prevenir los percances o accidentes viales y con ello evitar lesiones, daños a terceros y tambien
prevenir la perdida prematura de vidas humanas.
En este proyecto se lograron detectar las lineas divisorias de carril para definir una posicion pertinente dentro del
carril transitado, tambien se logró detectar un índice de iluminación sobre el camino para definir baja luminosidad ,
se logró la detección de objetos sobre el carril, así como dar una aproximación de distancia entre vehiculos. Todos
estos parametros se obtuvieron en tiempo real. Realizando un prototipo para la empresa Actia de México, la cual
desarrolla equipo de diagnostico para autotransporte de pasajeros.
Abstract: According to Statistics North American Transportation, the number of fatal mishaps in transport caused 11.616 deaths in Mexico in 2010, taking into account that the number of accidents in road transport totaled 11.584 deaths in the same year. One can say that the high incidence of fatal mishaps happen on the road, having these incidents the following factors in common: The accidents occurred suddenly and unexpectedly, the mishaps were caused by conditions and irresponsible acts, most were classified as "potentially preventable" mostly were attributed to human factors and occurred predominantly in motor vehicles. Considering that the accidents were deemed "potentially preventable" [...] (1), this research project aims to develop a navigation assistant system, which could support the driver to prevent road accidents and mishaps or with thereby avoid injury, injury to others and also prevent premature loss of life. In this project we were able to detect the lane-dividing lines to define a relevant position within the traveled lane, it was also possible to detect a lighting ratio on the way to define low light, it was possible the detection of objects on the rail, so as to give an approximation of distance between vehicles. All these parameters In real-time were obtained. Making a prototype for the company Actia of Mexico, which develops diagnostic equipment for motor carriers of passengers.
2
3
Objetivo general: Desarrollar un sistema que permita colaborar a favor de la seguridad en la conducción de autobuses, alertando sobre obstáculos en situaciones de baja luminosidad y desviaciones del carril, así como proximidad riesgosa con otros vehículos.
Objetivos específicos:
Desarrollar un dispositivo capaz de realizar mediciones, durante el manejo en carretera, que permitan detectar
objetos en el camino, salidas del carril y vehículos demasiado cercanos que impliquen un riesgo potencial.
Desarrollar un dispositivo que alerte al operador sobre objetos en el camino incluso en condiciones de baja
luminosidad, salidas del carril y vehículos muy cercanos que impliquen riesgos.
4
5
Capítulo 1. Introducción.
En este capítulo se presenta una propuesta para reducir el número de muertes originadas por accidentes viales, partiendo de las causas que provocan la mayoría de incidentes, además, se presentan los factores específicos que contribuyen a cada percance y el tipo de seguridad que es aplicable a cada factor de accidentalidad. Finalmente se muestra el problema a resolver, así como los alcances que puede tener el sistema a desarrollar.
6
7
1.1 Antecedentes
Utilizando la definición de accidente o percance vial podemos obtener sus características particulares y basar la
investigación en sus causas. Se considera pertinente basarse en su accidentalidad y así como las respectivas
medidas que se han tomado para prevenir su ocurrencia.
Características comunes de accidentes viales
Las características particulares que presentan los accidentes viales se presentan a continuación:
Son sucesos eventuales de los que involuntariamente resulta un daño.
Se presentan súbita e inesperadamente.
Preponderantemente suceden en vehículos automotores.
Son determinados por condiciones potencialmente previsibles.
Causas aparentes de accidentes viales
Se presentan también algunas de las causas:
Condiciones climatológicas poco favorables para la navegación en carretera.
Escasa o incorrecta señalización.
Condiciones que limitan la visibilidad del operador.
Caminos en mal estado.
Consecuencias de accidentes viales
Las consecuencias de los accidentes viales son:
Lesiones.
Secuelas físicas o psicológicas.
Perjuicios materiales y daños a terceros.
Perdida prematura de vidas humanas.
Realizando una búsqueda de accidentalidad en fuentes de estadística, se presenta a continuación la Tabla 1 con
la información obtenida en el sitio web de Estadística de Transporte de América del Norte titulada “La seguridad
en el transporte”, en esta publicación se presenta de forma comparativa la información correspondientes a tres
países de América del Norte (Canadá, México y Estados Unidos). La medida de percances se presenta como el
número de muertes en medios de transporte en cada país en un lapso de tiempo de 10 años […] (3).
En los datos de la Tabla 1 se puede apreciar que el transporte carretero en México tiene una cantidad sumamente
alta de accidentes, en comparación con otros medios de transporte y para fines de esta investigación se limitará a
lo concerniente a transporte carretero.
En el mismo informe de Estadística de Transporte de América del Norte se
clasifican los diferentes tipos de transporte carretero comprendidos por:
Automóviles de pasajeros y camionetas.
Automóviles de pasajeros
Motocicletas
Autobuses
Camiones pesados
Peatones
Otros
Tabla 1 Promedio de muertes por año en accidentes viales.
Tipo de Transporte
Promedio de muertes por año
(1990-2010)
Transporte aéreo 45.2
Transporte carretero
9652.4
Transporte ferroviario
30.1
8
Una característica determinante encontrada en los accidentes viales y que es considerada importante en esta
investigación, es que los accidentes fueron “potencialmente previsibles” […] (1). Esto nos da un elemento
importante para el sistema ya que si los accidentes fueron considerados potencialmente previsibles, puede existir
un factor de prevención.
Para poder prevenir un accidente es importante conocer las causas que lo han propiciado. De estas causas se
pretende enfocar el desarrollo de este trabajo de investigación a las que tiene mayor incidencia. Por lo que el
siguiente paso es buscar en fuentes o estudios realizados en México con respecto a un término conocido como
accidentalidad.
1.1.1 Causas que provocan accidentes viales
Antes de mostrar las causas es importante mencionar que se toman en cuenta dos tipos de carretera, estos tipos
de carretera o caminos son: urbano y suburbano.
Entorno urbano
El entorno urbano o paisaje urbano sólo es un concepto que está previamente definido por criterios numéricos de
población sobre un espacio geográfico (más de 5000 habitantes en un poblado delimitado). En la ilustración 1
proporcionada por el CETYV (Consejo Estatal de Transporte y Vialidad) se muestra el porcentaje de accidentalidad
de cada una de las causas que generan los percances, algunas de estas causas son particulares del entorno
urbano, tales como” no respetar el alto”.
Ilustración 1 Principales Causas de Accidentes Viales en entornos urbanos
Entorno suburbano
El entorno suburbano o espacio suburbano se define por la cantidad de habitantes en un espacio geográfico
(menos de 5000 habitantes). Este entorno tiene algunas causas extrapolables al entorno urbano, por ejemplo la
velocidad inmoderada.
Al realizar comparaciones entre entorno urbano y suburbano se hace referencia a causas que provocan accidentes
muy similares o que es posible extrapolar entre ellos, tal es el caso de sobrecupo en entorno urbano.
9
Ilustración 2 Principales Causas de Accidentes Viales en entornos suburbanos.
Teniendo las causas de los dos diferentes entornos de carreteras, es posible hacer una selección de las causas
basándose en dos criterios: mayor índice de percances y similitud de causas de accidentes. En la tabla 2 se
enlistan las causas de accidentes de mayor a menor incidencia, en los dos diferentes entornos.
Radiografía de accidentalidad (entorno suburbano) CETyV (urbano)
1.-Velocidad inmoderada 1.-Distracción del conductor
2.-Invadir carril contrario 2.-No guardar distancia de seguridad
3.-Distancia de seguridad 3.-Invasión de carril
4.-No ceder el paso en vía principal 4.-Virar indebidamente
5.-Imprudencia o negligencia 5.-No respetar el alto
6.-Causas no identificadas 6.-Velocidad excesiva
Tabla 2 Accidentalidad en entornos urbano y suburbano
Para los objetivos de este proyecto de investigación se propondrá investigar las seis causas de accidentes en
entornos urbanos y suburbanos, ya que en estas seis se pueden encontrar similitudes por lo que son factores en
común en los dos entornos. Se buscarán algunas opciones de cómo implementar alguna medida de seguridad
dependiendo de cada causa. Tomando en cuenta las causas de accidentes urbanos se pretende prevenir el
85.93% de los accidentes tomando en cuenta las seis causas mencionadas. De igual forma se podrían prevenir el
82.5 % de accidentes en entornos suburbanos.
1.1.2 Factores de accidentalidad
Una forma de separar las causas de accidentes viales es identificar los tres diferentes factores en accidentes
viales. En el siguiente diagrama se muestran los tres factores de accidentes y las características de estos.
Diagrama 1 Factores que pueden generar accidentes en autotransporte en México.
Accidentalidad en el Autotransporte
de México
Factor Humano
Factor Camino
Factor Vehículo
Condiciones Físico-Mecánicas de la máquina: desprendimiento de neumáticos, fallas de frenos, de la dirección, etc.
Condiciones de la carretera: curvas, el clima, luminosidad, señalamiento, humo, etc.
Velocidad inmoderada, invadir carril contrario, no guardar distancia de seguridad, no ceder el paso en vía principal, negligencia o imprudencia entre otros.
10
El uso de estos tres tipos de factores en la seguridad vial es muy variado, esto debido a que poseen características
muy particulares, tales características hacen diferentes las aplicaciones de seguridad vial, debidas al tiempo de
implementación, variación de resultados y costo.
Factor Humano: Es el factor más manipulable. Pero su conducción la basa en su estado de ánimo. Y tiene la
desventaja de ser impredecible en situaciones de riesgo.
Factor Camino: Una característica que destaca de este factor; es que su impacto es de mayor magnitud, ya que
las aplicaciones de seguridad funcionan o son consideradas para todo el vehículo que circula sobre la carretera.
Su mayor desventaja es que requiere de una gran infraestructura o inversión gubernamental.
Factor vehículo: Este factor es el más eficiente, ya que la aplicación de seguridad que se puede realizar es
aplicable a cualquier tipo de conductor. La desventaja es que requiere estandarizarse a la mayoría e vehículos.
1.1.3 Prevención en factores de accidentalidad.
En un esfuerzo por prevenir los accidentes, el gobierno Mexicano ha tomado medidas en cada factor y se han
realizado campañas para generar la conciencia de los conductores. Las medidas que se han implementado a cada
factor son:
Factor humano: Las acciones realizadas para reducir la incidencia debida al factor humano van desde las
sanciones administrativas pasando por las acciones de patrullaje en autopistas y calles hasta la aplicación de
tecnología dentro de los caminos, esto con el objetivo de detectar acciones imprudentes e infracciones.
Factor camino: La SCT (Secretaria de Comunicaciones y Transportes) dio a conocer en el Diario oficial de la
Federación la Norma oficial Mexicana NOM-034-SCT2-2003, “Señalamiento horizontal y vertical de carreteras y
vialidades urbanas” con el objetivo de normalizar los señalamientos a fin de que se tenga uniformidad en todo el
territorio nacional y esto facilite a los usuarios comprender las indicaciones. Y se menciona que el propósito es
disminuir la ocurrencia de accidentes.
Factor vehículo: Las medidas que se toman en este factor han sido las menos efectivas ya que solo se puede
emitir una recomendación a los usuarios de los vehículos, en cuanto a dar el correspondiente mantenimiento a sus
automóviles, estas medidas se han dado a conocer por medio de CAPUFE (Caminos y Puentes Federales).
Tráfico y seguridad vial por el Dr. Manuel Mateos de Vicente
Resumiendo el documento se obtienen algunas conclusiones claves: Implementar seguridad a bordo de vehículos
resulta más barato y requiere menor tiempo hasta su aplicación. Un aspecto muy importante es que no se debe
intentar predecir el comportamiento del operador. Un buen inicio para una implementación de seguridad es generar
una alerta que indique el riesgo potencial.
Se toman en consideración las conclusiones de cada factor:
El factor humano: Varía abruptamente debido al tipo de cultura. Por lo que no se tiene garantía de eficiencia al
aplicar algún tipo de seguridad.
El factor camino: presenta variantes pero se rige bajo una normatividad.
El factor vehículo: Este factor presenta una menor variación o sus cambios no son tan abruptos. Esto debido a
estándares y normatividad de fabricación. Por lo que es una buena opción para implementar seguridad.
11
1.2 Definición del problema
Haciendo un resumen de los aspectos importantes identificados en la introducción. Se pueden identificar las
principales causas y se pueden determinar los factores de accidentalidad. Como último punto se pudo identificar el
tipo se seguridad aplicable a cada factor de accidentalidad. En las conclusiones de la introducción se tomó en
cuanta el criterio del Dr. Manuel Mateo de Vicente, en el cual menciona que es más efectiva la seguridad activa
(tipo de seguridad que protege al conductor antes de que suceda un accidente, por ejemplo el “cinturón de
seguridad”). En el siguiente diagrama se representan los factores de accidentalidad y en especial las causas
relacionadas con la mayoría de accidentes en México.
Es importante tener en cuenta que se aplicarán medidas de seguridad a cada uno de los aspectos, por lo que es
necesario realizar algunas propuestas que permitan prevenir los accidentes atribuibles a todas las causas
enlistadas, además es preciso hacer un análisis para las causas que coinciden en ambos entornos de carretera.
Tomando en cuenta los datos de la Tabla 2 es posible revisar la coincidencia de causas y verificar su similitud.
Entorno suburbano Coincidencia de
causas Entorno urbano
1.-Velocidad inmoderada 1.-Distracción del conductor
2.-Invadir carril contrario 2.-No guardar distancia de seguridad
3.-Distancia de seguridad 3.-Invasión de carril
4.-No ceder el paso en vía
principal
4.-Virar indebidamente
5.-Imprudencia o Negligencia 5.-No respetar el alto
6.-Causas no identificadas 6.-Velocidad excesiva
Tabla 3 Relación de coincidencia y entre entornos urbanos y suburbanos
Cabe señalar que la causa número 4 de entorno urbano, mostrada en la Tabla 3. Está directamente relacionada
con la cultura del conductor del vehículo y esto está en relación con el factor humano. Por lo que no es prudente
implementar algún tipo de seguridad, ya que como se había mencionado; se tiene una respuesta impredecible. De
igual forma se hará una exclusión de la causa 5 en entorno urbano, ya que en un entorno suburbano no se cuenta
con semáforos, esta causa estaría restringida a solamente los entornos urbanos. Por lo que para los objetivos de
este proyecto de investigación no se tomará en cuenta. Ahora es posible delimitar los objetivos de este proyecto de
investigación basados en los antecedentes de los mismos. Por lo que en este punto es posible proponer los
objetivos de investigación.
Generando un diagrama de conjuntos se pueden enlistar las causas de mayor incidencia de accidentes y
posteriormente definir los alcances de este proyecto de investigación.
Diagrama 2 Representación en diagrama de conjuntos de causas de accidentes en entornos urbanos y suburbanos
12
Delimitando las causas, es posible relacionar los datos anteriormente obtenidos, tales como los factores de
accidentalidad y el tipo de seguridad. Por lo que se genera el diagrama 2 en el que se muestran las causas
seleccionadas para este proyecto y el tipo de seguridad.
1.2.1 Justificación del proyecto
Teniendo como objetivos particulares para este proyecto, se tomarán las causas mostradas en el Diagrama 2 y se
harán propuestas de cómo generar un tipo de prevención a estas causas. Por lo que es necesario generar una
idea más clara de las propuestas y la forma en que se podrían implementar.
La prevención de las cuatro causas mostradas en el Diagrama 2 podrían prevenir hasta el 77.63% de
accidentes en entornos urbanos y 82.5% en entornos suburbanos.
Como objetivo principal del proyecto se propuso aumentar la seguridad de un vehículo en carretera. Por lo que se lograron identificar las causas más frecuentes de accidentes. Evitando dichas causas se podrían obtener los siguientes resultados: Reducir el número de percances fatales. Reducir las pérdidas materiales. Reducir las lesiones o secuelas físicas y/o psicológicas.
BID lanza Plan de Acción para mejorar seguridad vial en América Latina y el Caribe “Muertes relacionadas con accidentes de tránsito, actualmente el doble del promedio mundial, podrían incrementarse en un 82 por ciento en la próxima década, si no se adoptan medidas preventivas”.
13
Capítulo 2. Marco Teórico.
En este capítulo se describen los criterios a emplear para incrementar la seguridad en un vehículo, también se muestra la metodología para aplicar un elemento de seguridad. Además se generan las propuestas basadas en los objetivos específicos del proyecto.
14
2.1 Teoría: Estudios de Dr. Manuel Mateos de Vicente
El tipo de seguridad seleccionado para este proyecto de investigación, se adoptó de los resultados obtenidos en un
estudio que realizo el Dr. Manuel Mateo de Vicente, titulado Auditorias y propuestas para reducir los accidentes de
circulación. Ya que sus propuestas han sido implementadas en gran parte del mundo por los gobiernos y las
empresas fabricantes de automóviles, lo cual permite adecuar su estudio a la situación actual de los accidentes
vehiculares en México. También es importante señalar que el autor de las auditorias presenta una semejanza a los
resultados obtenidos por el gobierno Mexicano.
Este trabajo también menciona; que una medida tomada por un gobierno tiene un tiempo de implementación muy
extenso. Esto debido a toda la infraestructura que se tiene que desarrollar, así como la aprobación de
presupuestos o legislación de una nueva medida de seguridad. Por lo que el Dr. Mateos hace énfasis en realizar
medidas de seguridad a bordo de vehículos (implementar en factor vehículo).
Cabe señalar que cada tipo de seguridad tiene un tiempo diferente en el que actúa, por lo que con lo respectivo a
este proyecto de investigación y sus objetivos que persigue, es importante seleccionar el tipo de seguridad que
actúa antes del accidente. Además esta decisión está basada en las conclusiones del Dr. Manuel Mateo en las que
afirma que la seguridad activa ha obtenido buenos resultados en cuestión de prevención de accidentes. Para
poder aplicar algún tipo de seguridad en un vehículo, se muestra el diagrama 3 en el cual se presentan los tipos de
seguridad aplicables a cada factor de accidentalidad.
Diagrama 3 Tipos de seguridad aplicados a cada factor de accidentalidad.
En el Diagrama 4 se insertan las causas identificadas para realizar una conceptualización de los aspectos que se
investigaron como antecedentes, se muestran además las opciones que se tienen para implementar una medida
de seguridad.
Diagrama 4 Causas de accidentes, Factores de accidentalidad y tipos de seguridad.
15
Es posible determinar las ventajas por las cuales el autor de las auditorias ha validado la aplicación de seguridad
activa en vehículos, por lo que es posible basarnos en esa conclusión para tomar la decisión de aplicar seguridad
activa en el factor vehículo.
Tipo de seguridad vial Tiempo Costo Efectividad
Seguridad Activa Reducido Bajo (desde la línea de fabricación) Altamente efectiva.
Seguridad Pasiva Medio Alto (debido a la infraestructura) Efectividad media.
Seguridad Represiva Muy extenso Alto (debido al seguimiento) Efectividad baja.
Tabla 4, Tabla comparativa de los tipos de seguridad vial.
2.1.1 Método: Como aplicar seguridad activa en vehículos
En el trabajo Auditorias y Propuestas para reducir los accidentes de circulación el Dr. Mateos hace una gran referencia sobre el cinturón de seguridad, como ejemplo claro de la efectividad de la seguridad activa y enfatiza las opciones que las empresas fabricantes de automóviles han tomado al respecto y de cómo se ha impulsado su desarrollo. En el siguiente diagrama se ejemplifica como fue la evolución del cinturón de seguridad ya que es este en el que
se ha logrado grandes avances en materia de seguridad. De igual manera se muestra que tipo de seguridad está
siendo aplicada e incluso se hace mención de la seguridad Represiva implementada en el Factor humano.
Diagrama 5 Evolución de seguridad en el cinturón de seguridad
Las propuestas que indica el Dr. Marcos Mateos señalan una secuencia en la cual, es posible implementar una
propuesta con seguridad activa y puede existir una retroalimentación en caso de existir una propuesta más
efectiva. En caso de que la propuesta sea socialmente aceptada, podría tener el alcance de controlar algún
sistema o elemento del vehículo o en caso de que la propuesta se demasiado compleja, se limitaría a solo alertar
sobre algún riesgo potencial al conducir el vehículo.
Diagrama 6 Método para aplicar la seguridad activa en un vehículo
Cinturón de seguridad
Cinturón de seguridad
desde fábrica
Alerta auditiva en caso de no tener
puesto el cinturón de seguridad puesta desde
fábrica
Si el conductor no se ha puesto el
cinturón de seguridad el
vehículo no avanza
Uso obligatorio de
cinturón de seguridad
Implementación de bandolera en cinturón de
seguridad
Pasiva Pasiva Pasiva
Activa
Activa Activa
Represiva
Identificar la o las causas de
accidentes
Proponer una posible
solución
Implementar la mejor
propuesta
Retroalimentación para hacer más eficiente la propuesta
Pasiva Pasiva Pasiva
Control de un elemento del
vehículo
Activa
Implementar una alerta que
indique el riesgo potencial
Activa
Pasiva
16
2.2 Sustentación: Tecnología y seguridad
La completa adecuación de los estudios del autor de las auditorías a lo largo de este trabajo es de gran
importancia, dado que el autor de las auditorias define la forma en cómo implementar la seguridad activa en los
vehículos, así como validar el uso de tecnología para detectar una situación que se haya presentado como
antecedente de accidente. El uso de la tecnología el autor la valida como una acción preventiva por lo que se
menciona que “alertar es prevenir”. Para los objetivos de este proyecto de investigación se tomará en cuenta el
criterio del autor de las auditorias y posteriormente se podrá definir cómo implementar la tecnología.
Cabe señalar que el autor de las auditorias tiene una gran cantidad de aportaciones al desarrollo automovilístico,
por lo que se mencionan algunas de sus más importantes o que trascendieron satisfactoriamente a nivel social.
Encendido y control automático de faro-célula fotovoltaicos. Alerta de intermitentes-Aplicar una audible y más visible para el uso de intermitentes. Luz con niebla-una alerta más potente del uso de faros de niebla. Luz larga encendida-Requiere de un aviso más eficiente. Marcha de reversa-Aviso acústico de marcha de reversa. Mandos a distancia en radio-Colocar controles remotos o en volante para radios. Control de limpia parabrisas- colocar un reóstato para controlar su velocidad.
Estas son algunas de las propuestas que el Dr. Mateos hace mención en su trabajo, propuestas de las cuales ha escrito más de 250 publicaciones desde 1964. También es prudente señalar que esto lo ha realizado sin modificar o clasificar a los conductores, por lo que el tipo de seguridad activa y pasiva bien podría ser apoyada por la tecnología ya sea el caso de la mecánica y/o la electrónica.
Diagrama 7 Seguridad activa implementada en el diagrama de causas de accidentes en entornos urbanos y suburbanos
Retroalimentación
Mayores Causas
de accidentes
viales en entornos
urbano y
suburbano de
México
-Invasión de carril Detectar la posición del vehículo
en el carril
Alertar sobre una ubicación
en el límite del carril
Distancia de
seguridad
Medir la distancia de seguridad
con el vehículo de enfrente
Alertar en caso de que exista muy
poca distancia frontal con otro
vehículo
Distracción del
conductor
Adquirir parámetros para
determinar si el operador esta
distraído
Alertar cuando el conductor no
esté atento al conducir
Velocidad Inmoderada Adquirir la velocidad del vehículo Alertar si se excede
la velocidad
Problema. Uso de la Tecnología.
Retroalimentación
Retroalimentación
Retroalimentación
17
En las últimas décadas la industria automotriz ha sido muy beneficiada por los avances tecnológicos. Algunos de
los cuales no fueron diseñados para este sector, sin embargo se lograron aplicar a los vehículos. Esto se ha hecho
con la intención de aumentar la velocidad, reducir su tamaño, incrementar su eficiencia, mejorar su factor de
seguridad, etc. Ahora, se pueden retomar las secciones anteriores de esta investigación para tener un panorama
de cómo se podría aplicar la seguridad a bordo de vehículos teniendo en cuenta cuales son las causas, en que
factor afectan y como podría colaborar la tecnología.
Adecuando la seguridad activa implementada en vehículos es posible utilizar un criterio que se hace mención
“Alertar es Prevenir un riesgo Potencial”. Por lo que se propone generar alertas como prevención.
2.3 Benchmarking: por objetivos específicos de sistema ANC
Benchmarking es un estudio de mercado que puede definirse como un proceso sistemático y continuo para evaluar comparativamente los productos, servicios y procesos de trabajo en organizaciones. Dicho estudio consiste en tomar "comparadores" o benchmarks a aquellos productos, servicios y procesos de trabajo que pertenezcan a organizaciones que evidencien las mejores prácticas sobre el área de interés, con el propósito de transferir el conocimiento de las mejores prácticas y su aplicación. Con el objetivo de buscar sistemas similares, de inicio se hace una búsqueda que cubra los objetivos específicos, posteriormente se realizara una búsqueda dirigida hacia sistemas similares, que cubran en la mayoría las funciones del sistema ANC.
Fabricante Detección de
acotamiento de carretera
Detección de distancia de seguridad
Detección de distracción del
conductor o fatiga
Fecha de Lanzamiento
País de origen
Volvo FCW System Forward Collision Warning
FCW System FCW System Enero 2012 Suecia
Audi Audi Active Lane Assist
Audi parking system
Audi parking system
Julio 2012 Alemania
Mercedes Benz
Lane Departure Warning System
Road Care Road Care Octubre 2011
Alemania
Infiniti Lane departure warning system
Distance Control
Lane departure warning system
Marzo 2010 Japón
Citroën LDWS Lane Departure Warning System
Engine Comfort
Engine Comfort 2010 Francia
Tabla 5 Benchmarking orientado a objetivos específicos de sistema ANC.
Cabe señalar que los sistemas mostrados en la tabla 5 son desarrollos realizados en países con un alto desarrollo
tecnológico, por lo que es importante mencionar que un sistema similar al ANC no se ha realizado en México. Por
esta razón es importante hacer mención la importancia que podría tener un sistema similar o el desarrollo de un
sistema en México.
Invasion de carril: “lane departure warning system”
En la terminología del transporte por carretera, un sistema de alerta de cambio de carril es un mecanismo
diseñado para advertir al conductor cuando el vehículo comienza a salirse de su carril (a menos que una señal de
la vuelta es en esa dirección) en las autopistas y carreteras arteriales. Estos sistemas están diseñados para
minimizar los accidentes, abordando las principales causas de las colisiones: error del conductor, distracciones y
somnolencia. En 2009 los EE.UU. National Highway Traffic Safety Administration (NHTSA) comenzó a estudiar la
posibilidad de ordenar los sistemas de alerta de salida de carril y advertencia de colisión frontal sistemas en los
automóviles. A continuación se muestra una línea de tiempo en la que es posible apreciar la evolución de los
detectores de líneas de carretera:
2001 Nissan Motors comenzó a ofrecer un sistema de apoyo de mantenimiento de carril en la Cima vendido en
Japón. 2002 Toyota presentó su sistema de monitoreo Lane en modelos como el Cardina 2003 Honda lanzó su Carril Assist System (LKAS) en el Inspire 2005 Citroën se convirtió en la primera en Europa en ofrecer LDWS en 2005 su C4 y C5 modelos, y su C6 2007 En 2007, Audi comenzó a ofrecer su carril Audi función de asistencia.
18
2008 General Motors presentó Lane Departure Warning en su modelo 2008 STS Cadillac, DTS y los modelos
Buick Lucerne. 2009 Mercedes-Benz comenzó a ofrecer una función de carril Assist en el nuevo Clase E 2010 Kia Motors ofreció el sedán Cadenza 2011 premium con una clase Lane Departure Warning System opcional.
2.3.1 Benchmarking: Sistemas en mercado congruentes con sistema ANC
En Marzo del año 2012 Volvo buses México, presentó un sistema similar que eran congruentes con los objetivos
del sistema ANC, por lo que se realizó una investigación del sistema y se obtuvieron los siguientes resultados:
El sistema existe en el mercado y es conocido como FCW (Forward Collision Warning) de Movileye. El fabricante es de origen chino y desarrolla tecnología similar de visión para la industria automotriz.
Por lo que se podría contemplar la opción de que México genere tecnología de esta magnitud, o en el mejor de los casos que sea fabricante de un producto similar. Sin tener en cuenta las implicaciones del sistema y con el simple hecho de que empresas fabricantes de automóviles lo han logrado, se llevará a cabo un sistema que intente semejar las características o capacidades de un producto que ya se encuentra en el mercado. Por tal motivo se expone el potencial que comercialmente se podría lograr con este proyecto de investigación. 2.4 Posibles soluciones: Ingeniería Mecatrónica
Una vez detectadas las causas y justificado el hecho de implementar tecnología a bordo de vehículos automotores,
es posible proponer alguna solución con ingeniería mecatrónica, dado que los avances en cuestión de seguridad
han sido de varias ramas de la ingeniería, se expone alguna solución Mecatrónica. A continuación se expone
algunas de las definiciones de mecatrónica.
2.4.1 ¿Qué es la Mecatrónica? o ¿cómo se puede definir?
La siguiente definición fue propuesta por Yakasawa y fue acuñada en 1969.La cual menciona que es: “una disciplina integradora de las áreas mecánica, electrónica e informática cuyo objetivo es proporcionar mejores productos, procesos y sistemas”. Teniendo en cuenta que se trata de una definición propuesta hace ya más de 40 años, es preciso buscar una referencia actualizada, por lo que es necesario citar la descripción propuesta por J.A. Rietdijk (1989): Mecatrónica es la combinación sinérgica de la ingeniería Mecánica de precisión, de la electrónica
del control automático y de los sistemas para el diseño de productos y procesos”. Existen otras versiones de esta definición, pero en esta claramente enfatiza que la Mecatrónica está dirigida a las aplicaciones y al diseño. Partiendo de la definición ahora es posible especificar que es un sistema mecatrónico típico, esta definición fue propuesta por el CINVESTAV, la cual especifica que un sistema mecatrónico típico recoge señales, las procesa y, como salida, genera fuerzas y movimientos. Los sistemas mecatrónicos son entonces extendidos e integrados con sensores, microprocesadores y controladores. Los robots, las máquinas controladas digitalmente, los vehículos guiados automáticamente, las cámaras electrónicas, las máquinas de telefax y las fotocopiadoras pueden considerarse como productos mecatrónicos. Al aplicar una filosofía de integración en el diseño de productos y sistemas se obtienen ventajas importantes como son mayor flexibilidad, versatilidad, nivel de “inteligencia” de los productos, seguridad y confiabilidad así como bajo consumo de energía. Estas ventajas se traducen en un producto con más orientación hacia el usuario y que pueden producirse rápidamente a un costo reducido.
Diagrama 8 Sistema mecatrónico típico
19
La definición de un sistema mecatrónico típico se puede utilizar para aplicar tecnología a algún dispositivo en este caso se puede aplicar a prevenir las causas de accidentes antes seleccionadas. Las cuales provocan la mayoría de accidentes en México, por tal motivo es posible insertar el diagrama 8 en el “uso de la tecnología” del diagrama 7. En el diagrama 9 se muestra la aplicación de un sistema mecatrónico típico, aplicado a la causa de accidentalidad “invasión de carril”.
Diagrama 9 Sistema mecatrónico típico implementado en el Diagrama 6
Algunas de las definiciones que se presentaron anteriormente involucran varias ramas de la ingeniería, pero de igual forma nos podriamos preguntar si cada una de las diciplinas que conforman a la mecatrónica pueden solucionar el mismo problema únicamente utilizando una rama de la mecatrónica.
20
21
Capítulo 3. Diseño conceptual.
En este capítulo se realizan análisis de diseño en los cuales se utilizan algunas herramientas orientadas a definir el diseño conceptual además de realizarse propuestas para determinar su diseño final.
22
3.1 Diagrama de funciones
Una herramienta muy útil para definir un diseño conceptual es un diagrama de funciones, el cual se toma como una caja negra o como un diagrama de procesos. Dicho diagrama tiene como objetivo dar un bosquejo del sistema mostrando bloques, entradas y salidas. A continuación se muestra el diagrama de funciones del sistema a desarrollar, en él se pueden apreciar como entradas las conclusiones obtenidas en las secciones anteriores de este proyecto de investigación.
Diagrama 10 Diagrama de Funciones del sistema ANC.
Como se puede observar en el diagrama 10, se sigue el método del Dr. Manuel Mateo de Vicente. Este análisis sigue conservando el método para implementar seguridad activa a bordo de un vehículo. Por lo que en este punto de la investigación, se podrían proponer ciertas soluciones aplicando tecnología con un sistema mecatrónico típico, respetando el análisis de antecedentes en seguridad vial. Tomando en cuenta el benchmarking realizado a la industria automotriz, es posible generar algunas propuesta basadas en sistemas instalados, por lo que se requiere una herramienta más de diseño conceptual, esta herramienta nos permite realizar algunas propuestas, orientadas al diseño del sistema ANC. 3.2 Diagrama morfológico
Un diagrama morfológico es una herramienta en la cual se puede realizar un análisis de conceptualización, en el
cual se involucran las diferentes opciones que se tienen para cada objetivo específico, se realiza un análisis en el
cual se involucran aspectos directamente relacionados con las características del componente o del método a
seguir. De las conclusiones obtenidas anteriormente es posible determinar los objetivos como primarios y
secundarios, para realizar un Diagrama Morfológico. A continuación en el diagrama 11 se muestra la clasificación
de los objetivos:
Diagrama 11 Clasificación de objetivos en primarios y secundarios
Diagrama 12 Diagrama morfológico de opciones para seleccionar el objetivo primario y el objetivo secundario.
OBJETIVOS
ESPECIFICOS
(secundarios)
OPCIÓN 1
OPCIÓN 2
OPCIÓN 3
PROCESAMIENTO
DE DATOS
INTERFAZ DE
ENTRADA
ALERTAS
Micro-controlador Tarjeta de desarrollo Módulo FPGA
Protocolo RS232 Protocolo USB RADIO Frecuencia IA
Alerta Luminosa Alerta Sonora Display
25
Del diagrama anterior se realizaron tres configuraciones, estas configuraciones aún pueden estar sujetas a
cambios en el desarrollo, la forma en cómo se realizaron las propuestas estuvo basada en la cantidad de
datos que se requiere procesar, es de esperarse que los dispositivos más sencillos son los que requieren
menor cantidad de procesamiento, de igual forma los componentes que son más robustos o pueden ofrecer
mayor resolución en los datos presentados, requieren mayor cantidad de procesamiento, por tal motivo
requieren una unidad de procesamiento capaz de responder a esta cantidad de información, de esta forma se
generan tres diferentes propuestas para poder realizar este proyecto de investigación.
3.3 Solución propuesta
Propuesta 1
Esta propuesta se caracteriza por tener elementos que requieren poco procesamiento, estos elementos bien
podrían ser procesados por algún microprocesador de bajos recursos, ya sea PIC, AVR o Alguna tarjeta de
desarrollo como Arduino, El gran problema que podría enfrentar seria la baja resolución de sus elementos o el
espacio en el que convergen sus elementos. El problema de la resolución podría resolverse con una densidad
mayor de componentes, lo cual nos llevaría a hacer un muestreo en los ‘n’ elementos que se utilicen para
cada objetivo específico.
La propuesta 1 está compuesta de los siguientes elementos:
Ilustración 3 Elementos de Propuesta 1
Los retos más importantes que se podrían enfrentar en la configuración anterior:
1. Baja resolución. 2. Bajo Alcance. 3. Filtrar el ruido.
Una posible solución a la desventaja 1 es aumentar la densidad de componentes, Para la desventaja 2, probablemente sea adquirir componentes más sofisticados u orientados a objetivos más distantes, la adquisición de datos de una mayor densidad de dispositivos bien podría necesitar de una capacidad de procesamiento mayor, una fuente de alimentación, y una instalación que podría generar una modificación mayor al vehículo, por lo que dependería de la variedad de vehículos en el mercado. Esto provocaría una inconsistencia en las conclusiones del Dr. Manuel Mateos de Vicente en las que las modificaciones a un vehículo no pueden ser substanciales o de gran impacto a su estética.
Detección
de líneas
Detección de
Distancia Detección de Obstáculos
Procesamiento Alerta Sonora Detección de Luminosidad
26
Propuesta 2
Esta propuesta parte de la necesidad de mayor procesamiento, obtenida de la propuesta 1. Por lo que se propone aumentar la capacidad de un dispositivo de procesamiento, aumentando de igual forma las capacidades de los componentes del sistema. A continuación se presenta la propuesta 2:
Ilustración 4 Elementos de propuesta 2
En la propuesta 1 se detectaron 3 desventajas, de las cuales con la propuesta 2 se podrían contrarrestar con
la propuesta 2. Esta segunda propuesta surge de la necesidad de lograr un mayor alcance y una mejor
resolución del sistema sin ser invasivo en un vehículo. Aunque los componentes no se podrían adquirir tan
fácilmente además de que demandarían mayor costo.
Propuesta 3, propuesta Actia de México
En México se encuentra establecida una empresa de carácter internacional, llamada ACTIA México S.A de C.V. dicha empresa se dedica a la instalación de equipo en vehículos de autotransporte, preponderantemente autobuses, con la siguiente misión: ACTIA México es parte de ACTIA Automotive, empresa global especializada en electrónica y equipo de diagnóstico automotriz. Esta empresa da servicio desde 1994 al mercado del Autotransporte de pasajeros con más de 20,000 autobuses equipados con productos ACTIA. Por lo que para los fines de este proyecto de investigación se puede considerar como un buen cliente al que se podría dirigir el proyecto de investigación. Es importante señalar la posibilidad de diseñar un sistema ANC con la propuesta 2, por lo que se realizó una entrevista con el equipo de Ingeniería de Actia de México obteniendo los siguientes resultados:
Realizar el sistema ANC dirigido a un autobús. Demostrar la viabilidad del sistema ANC en un equipo de Actia de México. Investigar las capacidades de los equipos de Actia para poder generar una propuesta.
Teniendo en cuenta que el desarrollo está dirigido a un autobús es posible acotar el sistema y orientarlo a las capacidades de un equipo de diagnóstico de Actia. Se realizó una investigación de las capacidades de los equipos de Actia y se produjo la primera propuesta: Se demostrará la viabilidad de un sistema ANC como un desarrollo para el equipo “Boletera” con los objetivos del sistema ANC.
Detección
de líneas
Detección de
Distancia
Detección de
Obstáculos
Procesamiento Alerta Sonora Detección de Luminosidad
27
Se programó una segunda entrevista con el equipo de Ingeniería de Actia para conocer las especificaciones para la aplicación del sistema ANC en el equipo “Boletera” de estas especificaciones se podrá generar el diseño final. Por tal motivo se determina la propuesta Actia como la mejor propuesta que se logró generar Las capacidades del equipo permiten tener componentes muy diversos y se podría generar algunas propuestas realizando combinaciones del diagrama morfológico quedando la propuesta Actia de la siguiente forma:
Ilustración 5 Elementos de propuesta Actia
Se puede apreciar en la ilustración 5 que se mantienen los elementos de la propuesta 2, ahora con la etapa
de procesamiento del equipo “Boletera” de Actia de México.
3.4 Conclusiones parciales Marco Teórico
Conclusiones:
Se cambia el desarrollo de la propuesta 2 a la propuesta Actia, siendo esta ultima la más favorable
para los fines de este proyecto de investigación.
Se realizara el diseño orientado a un autobús.
Las capacidades del equipo Boletera, pueden permitir flexibilidad en el diseño del sistema ANC.
Detección
de líneas
Detección de
Distancia
Detección de
Obstáculos
Procesamiento Alerta Sonora Detección de Luminosidad
28
29
Capítulo 4. Desarrollo.
En este capítulo se presenta una metodología de desarrollo de software, se definen las especificaciones obtenidas de Actia México, se propone una etapa funcional y se define el diseño para llevar a cabo la codificación del Sistema (ANC).
30
Método-V o Modelo en V
El Método-V o Modelo en V define un procedimiento para el desarrollo de productos (aplicaciones de software) para las TIC, es el estándar utilizado para los proyectos de la Administración Federal Alemán y de defensa. Se encuentra disponible públicamente, por lo que es utilizado por muchas compañías, es un método de gestión de proyectos que describe tanto métodos para la gestión como para el desarrollo de sistemas. La implementación del Modelo en V para el desarrollo de la aplicación de software del Sistema ANC se adecuo, por las siguientes características:
1) El Método-V fue desarrollado para regular el proceso de desarrollo de software por la Administración Federal Alemana por lo que se utilizará en el desarrollo de la etapa de software, además porque describe las actividades y los resultados que se producen durante el desarrollo del software.
2) El Método-V es una representación gráfica del ciclo de vida del desarrollo del sistema, resume los pasos principales que hay que tomar en conjunción con las correspondientes entregas de los sistemas de validación.
En el siguiente diagrama se muestra gráficamente el Modelo en V.
Diagrama 13 Esquema por niveles del Método V o Modelo en V
La fase determinada como Inicio del Proyecto en la metodología del Modelo en V es en la que se realiza la
propuesta del proyecto o la oferta a algún cliente, ya que esta metodología no permite involucrar al cliente en
el desarrollo del Sistema.
El cliente al cual se propuso el desarrollo del sistema es la empresa Actia de México. Esta propuesta se
realizó con el objetivo de demostrar que uno de sus productos puede realizar una aplicación de seguridad vial
en carretera. Esta demostración está orientada a realizarse en el producto “Boletera”, ya que este desarrollo
permitiría ampliar la rentabilidad de su equipo.
EL sistema ANC debe funcionar como un complemento del Sistema Boletera, por lo se tomará como una
propuesta para demostrar que el hardware del sistema Boletera tiene la capacidad para realizar la función de
un asistente de navegación. Cabe señalar que el sistema boletera está dirigido al autotransporte y para acotar
la aplicación se dirigirá el desarrollo del sistema ANC sólo a transportes de tipo autobús.
Al buscar realizar el sistema ANC como complemento se necesita especificar las condiciones de operación del
sistema “Boletera”, los parámetros a seguir son los siguientes:
Parámetro a seguir Velocidad Puerta
Sistema Boletera Menor o igual a 10 km/h Puerta abierta
Sistema ANC Mayor a 10 km/h Puerta cerrada
Tabla 6 Parámetros a seguir para ejecutar el sistema ANC o sistema “Boletera”
De la tabla 6 se determina que los sistemas no deberían interferir mutuamente o provocar situaciones no
definidas. Los parámetros a seguir en el funcionamiento del sistema permiten ejecutar un sistema u otro, de
tal forma se puede describir su característica de funcionamiento, clasificado como complementos.
x.1 Fase Especificaciones
Diagrama 14 Funciones del equipo “Boletera”
eNOVA-ATOM (Administrador
“Boletera”)
Wi-Fi
GPS
GPRS
AT90CAN (computadora de viaje) IMPRIME BOLETOS
CUENTA PASAJE VENTA DE
BOLETOS
I/O DATOS
32
4.2 Fase Especificaciones
Para adquirir las especificaciones del cliente se realizó una entrevista con el equipo de ingeniería de Actia México. Esta entrevista permitió conocer los requerimientos de operación del equipo “Boletera” con una aplicación de un asistente de navegación. Las especificaciones aplican tanto para hardware como para software y se enlistan a continuación.
Especificaciones Actia Software Hardware
1 Utilizar Linux como plataforma. X
2 Desarrollo en lenguaje C. X
3 Utilizar máximo el 80% de la capacidad del CPU. X X
4 Diseño del sistema de navegación para un autobús. X
5 No realizar modificaciones en el tablero del autobús. X
Tabla 7 Especificaciones Actia para el sistema ANC
4.2.1 Fase Test especificaciones
Basándose en el Método-V se pueden evaluar las especificaciones para verificar si el proyecto es Posible, o en caso contrario se deben revisar las especificaciones o la inviabilidad del proyecto. Por lo cual se someten a un criterio las especificaciones del sistema. 1.- Utilizar Linux como plataforma: El uso de la plataforma Linux, nos permite adquirir un software gratuito y
con una amplia gama de aplicaciones, por lo que no existe alguna restricción a esta especificación. 2.-Desarrollo en Lenguaje C: De igual forma que la especificación 1, el desarrollo en lenguaje C, no genera un costo y el software de desarrollo es de uso libre. 3.-Utilizar máximo el 80% del CPU: Esta restricción se verificara en cada paso del sistema, ya que cualquier
aplicación dependerá de esta especificación. 4.-Diseño del sistema de ANC para un autobús: Para esta restricción es necesario conocer los parámetros
de instalación o de operación de un autobús comercial. 5.-No realizar modificaciones en el tablero: Con respecto a esta especificación, se aclara que no se podrá
cambiar ni el aspecto ni el diseño del tablero del autobús, así como algún cambio que obligue a modificar la apariencia del autobús. Por lo que se le dará seguimiento a esta especificación. Un análisis superficial de las especificaciones nos puede dar como resultado la validación del desempeño del sistema por lo que se continuará con el desarrollo del proyecto. Se tomara en cuenta que las especificaciones de software se cumplen desde el inicio y las especificaciones de hardware se verificaran en toda la etapa de diseño del sistema ANC.
33
4.3 Fase Funcional
En esta etapa es posible determinar las entradas y salidas del sistema ANC en forma de Diagrama de funciones para el hardware. De esta forma se pretenden mostrar las entradas y salidas del sistema en hardware, simulando una caja negra y posteriormente se propone utilizar los diagramas de diseño de software IDEF0. Esto con el objetivo de seguir las especificaciones de software y de hardware del sistema. El diseño del hardware se apega a las especificaciones 4 y 5 de la tabla de especificaciones. A continuación se muestra el diagrama de funciones del sistema ANC implementado en un equipo “Boletera”.
Diagrama 15 Diagrama de funciones para Hardware sistema ANC.
Teniendo en cuenta el diagrama de funciones anterior, es posible determinar los procesos involucrados con el
sistema ANC, de tal forma que se pueden determinar las entradas y salidas del sistema con la secuencia de
flechas. De esta forma también se pueden generar los parámetros con los cuales se puede determinar el
sistema que será activado (Boletera o ANC). Como se había comentado anteriormente el sistema ANC
funcionara como complemento del sistema Boletera, de esta forma es posible insertar el software dentro del
equipo Boletera sin alterar su funcionamiento.
4.3.1 Fase Test Funcional
Con el objetivo de cumplir con las especificaciones es posible tomar las especificaciones 3,4 y 5 de la tabla 7.
# Especificación Hardware
1 Utilizar máximo el 80% de la capacidad del CPU.
2 Diseño del sistema de navegación para un autobús.
3 No realizar modificaciones en el tablero del autobús.
Tabla 8 Especificaciones Actia para Hardware
Interfaz
Parámetro
Sub-sistema
Proceso
Atom
Sistema
Boletera
Sistema
ANC
Cámara
Boletera
Alertas
AT90CAN
Sensor de
Puerta
START
1
2
3
4
5
6
34
Para cumplir con las especificaciones del sistema ANC en la fase Test Funcionamiento, se respeta el
funcionamiento original de sistema Boletera. Se agregan elementos externos para intercalar las diferentes
etapas sin que los sistemas entren en conflicto.
Para representar los componentes del sistema ANC en su etapa funcional se añaden elementos adquiridos en
el análisis del Diagrama Morfológico. En el siguiente diagrama se muestra como se cumplirán las
especificaciones del sistema ANC implementado en el equipo Boletera:
Diagrama 16 Diagrama de funciones para Hardware con solución propuesta para Actia
4.4 Fase Diseño
En la etapa de diseño se requiere revisar las especificaciones de software, esto con el objetivo cumplir de
inicio las especificaciones y posteriormente realizar el diseño. Las especificaciones de software a seguir son
las siguientes:
# Especificaciones de software
1 Utilizar Linux como plataforma.
2 Desarrollo en lenguaje C.
3 Utilizar máximo el 80% de la capacidad del CPU.
Tabla 9 Especificaciones Actia para Hardware
Para cumplir con estas especificaciones se realiza el siguiente análisis en el cual se involucran los elementos
del Diagrama 16.
Atom
Sistema
Boletera
Sistema
ANC
AT90CAN
Sensor de
Puerta
START
1
2
3
4
5
6
35
4.4.1 Simulador equipo Boletera
1.-Se requiere utilizar Linux como plataforma: Este objetivo es preciso, ya el sistema “Boletera” tiene un funcionamiento desarrollado en plataforma Linux, teniendo en cuenta que el software es de distribución libre, se puede descargar e instalar en un computador portátil para poder simular el equipo de Actia. Para esto primero se requiere hacer una simulación del equipo de Actia en un computador que simule las capacidades y características del sistema Boletera, se necesitan la hoja de datos del procesador del sistema boletera, así como sus capacidades, A continuación se muestran las capacidades de desempeño del sistema Boletera adquiridas de la hoja de datos:
eNOVA Versión 1.0
Processor: N270 1.6GHz SDRAM SO-DIMM: 1GB Power Supply: Full Range (9V-28V) Power Consumption: 12V@ 1.52A Temperature Operation: 0°-60°
De estos datos los que se considera son las capacidades del procesador y de la memoria. Por lo que estas
capacidades son similares a un equipo Toshiba Satellite T215D, a continuación se enlistan las capacidades
encontradas en el website del fabricante.
Processor: AMD Athlon II 1.7GHz SDRAM SO-DIMM: 1 GB
Las capacidades físicas se cumplen, por lo que se puede seguir con la instalación de la plataforma Linux, de la cual se escoge la distribución OpenSUSE 11.4. Esta selección se realizó por ser más cercana a la distribución que se utiliza en Actia para el sistema Boletera, a continuación se muestra la implementación de la plataforma Linux en el equipo simulador de Boletera. Se describe el procedimiento completo de instalación en el Anexo 1.
Ilustración 6 Plataforma Linux instalada en equipo simulador
2.-Desarrollo en lenguaje C. La aplicación de este sistema requiere que sea un desarrollo en lenguaje C, para esto se requiere que muchos de los componentes descritos anteriormente adquieran datos desde una cámara y unos sensores ultrasónicos. Para esto es posible utilizar librerías de Visión artificial y algún puerto para comunicar los sensores ultrasónicos con el equipo Boletera. Se puede contemplar la adquisición de datos de la cámara en un puerto USB, por otro lado la adquisición de datos de los sensores ultrasónicos desde el puerto serial, por lo que el sistema se propone con la siguiente configuración:
Cámara interfaz USB Ultrasónicos Interfaz puerto serial
Al desarrollar un sistema en software es importante conocer un algoritmo para aplicarlo en la computadora. Al realizar un algoritmo en software es necesario un Ambiente de desarrollo, esto con el objetivo de convertir un algoritmo en un programa entendible a una computadora.
36
Esta es la razón principal por la que se requiere un Ambiente de desarrollo, la selección del ambiente de desarrollo se basó únicamente en codificar un programa en lenguaje C y ser compatible con las Librerías de Visión Artificial
Codificar un programa en lenguaje C Ser compatible con las librerías de Visión Artificial
El ambiente de desarrollo de nombre Monodevelop 2.3.1 cumple con estas dos características, por lo que se instaló en el equipo de simulación Boletera, se espera instalar el ambiente de desarrollo en el equipo Boletera y posteriormente poder desinstalarlo, de tal forma que se pueda comprobar la eficiencia de la aplicación del sistema ANC. Se cubren la especificación 1 y 2 al utilizar la plataforma Linux y el ambiente de desarrollo para codificar en C por lo que estas especificaciones no se necesitan verificar más adelante, solo se requiere verificar en cada subproceso la especificación 3, a continuación se describe el procedimiento.
Ilustración 7 Ambiente de Desarrollo Monodevelop 2.3.1
3.-Utilizar máximo el 80% de la capacidad del CPU. Esta especificación hace referencia en Hardware a las interfaces o puertos de entrada y a sus capacidades físicas. Esta misma especificación está orientada a no utilizar más del 80% del procesador, por lo que requiere ser monitoreada en cada etapa del desarrollo del sistema. Se investigaron algunas formas de monitorear el procesador, posteriormente se seleccionó una función de la terminal de Linux la cual nos permite verificar el estado de la memoria y el procesador, esta selección estuvo basada en mostrar el estado de la memoria y el procesador, para cumplir la especificación del 80 % de las capacidades del CPU. A continuación se muestra en la Ilustración 8 los parámetros que se pueden monitorear todo el sistema.
Ilustración 8 Verificar en una terminal de Linux el uso del procesador y la memoria
Ahora es pertinente proponer el diseño del sistema adquiriendo video en la cámara mediante USB. De igual forma se busca la detección de la luminosidad con el fotodiodo y la detección de distancia con los sensores ultrasónicos, estos dos últimos sensores se podrán comunicar por puerto serial con el simulador de Boletera. 4.4.2 Fase Test de Diseño
El planteamiento del diseño se apoyara con el uso de diagramas IDEF0, iniciando con el procesamiento de la
cámara, de tal manera que se pueda hacer un bosquejo de las etapas que puede llevar la detección de las
líneas de carretera y los obstáculos
4.4.3 Diagramas IDEF
37
Diagrama 17 Representación IDEF para detección de líneas de carretera
a
b c
38
El uso de los diagramas IDEF es para tener una idea más clara de la tarea que se requiere desempeñar con el
hecho de tener entradas, salidas esperadas, herramientas para el desarrollo y un tipo de control, se tiene una idea
similar a tener una caja negra en donde los procesos son desconocidos, sólo se tiene la entrada y la salida
esperada. Se ejemplifican los diagramas IDEF para el caso de la detección de líneas del sistema, en el resto de
este proyecto se abordarán los problemas con diagramas IDEF, como una herramienta del Método V.
Una vez planteado el diseño de una etapa del sistema se va a utilizar el ambiente de desarrollo descrito en la fase
de diseño. Este ambiente de desarrollo nos permite codificar un programa que está basado en un algoritmo, de
esta forma se desarrollará la codificación en este proyecto de investigación.
4.4.4 Simulador de codificación Matlab
Una herramienta muy importante en el desarrollo del sistema es el uso de un software de investigación de nombre
Matlab, el cual contiene herramientas que abarcan desde operadores matemáticos hasta procesamiento digital de
imágenes, por lo que es posible hacer una simulación antes de codificar un programa en C. Esto con la finalidad
de tener una ventaja o una predicción en los resultados esperados, ya que el proceso de codificación en lenguaje
C demanda más tiempo. En el diseño final se realizarán simulaciones de los procesos mediante Matlab, lo cual se
pretende sea parte del test de diseño, esto para verificar si los resultados son útiles a los procesos que forman
parte del sistema ANC.
Las funciones utilizadas en Matlab permiten la
verificación del proceso digital de las imágenes. En el
caso del filtro de color solo se hace uso de una función,
aunque este proceso solo se necesita de una función, a
medida que se avance los procesos se hacen más
complejos. Por lo que se introduce el uso de la
simulación en Matlab en el Test Diseño.
Ilustración 9 Simulación de diseño en Matlab.
4.5 Fase Codificación
El uso de los diagramas IDEF es para poder tener una idea más clara de la tarea que se requiere desempeñar,
una vez obtenido el Algoritmo se desea generar el programa en el Ambiente de desarrollo y verificar que se
obtengan los resultados esperados a la salida de su correspondiente diagrama IDEF. Se iniciará la codificación del
algoritmo para prevenir la salida del carril, este objetivo se desea obtener detectando las líneas de la carretera. En
el desarrollo de la codificación se hará uso de algunas herramientas utilizadas para el seguimiento de la
codificación. Para detectar las líneas de la carretera es necesario conocer el proceso de cómo una cámara digital
adquiere una imagen y la convierte en video, para esto es necesario conocer el termino frame. Se denomina frame
(del inglés), a un fotograma o cuadro. Esta es una imagen particular dentro de una sucesión de imágenes que
componen una animación. La continua sucesión de estos fotogramas producen a la vista la sensación de
movimiento. Fenómeno dado por las pequeñas diferencias que hay entre cada uno de ellos. De esta se busca
realizar el procesamiento de un frame aislado.
Para cumplir con los objetivos de seguridad de un autobús es necesario prevenir las causas de accidentes
anteriormente mencionadas, se empezará por la detección de líneas divisorias de carril. Este objetivo es el
más determinante en cuestión de seguridad ya que podría prevenir las siguientes casusas de accidentes:
Invasión de carril (urbano), distracción del conductor (urbano), invadir carril contrario (suburbano).
39
Ilustración 10 Frame aislado de un fotograma
Conversión de RGB a escala de grises
Para lograr detectar las líneas de la carretera es necesario despreciar algunas características de la imagen
o frame, estas características se requieren filtrar por el hecho de que nos son útiles y al procesarlas
requiere de mayor procesamiento. Por lo que se despreciara el color y se convertirá a escala de grises.
Una buena herramienta para implementar el algoritmo de programación en nuestro ambiente de desarrollo es diseñar un Diagrama de Flujo el cual realiza una representación gráfica del algoritmo de programación o de alguna parte del mismo. Ya que ayudan a la comprensión de las operaciones de las estructuras de control. La ventaja de realizar el diagrama de flujo es que se puede basar en el para poder construir o codificar de manera independiente del lenguaje de programación. Escala de grises: Es una escala empleada en la que el valor de un pixel posee una graduación de gris, y van del negro profundo al blanco.
Ilustración 11 Imagen o frame de color (RGB) convertido a escala de grises (gray)
El código que genera la imagen se muestra como parte de los anexos, mostrando una metodología de desarrollo de software, ya que este método fue indispensable en la etapa de codificación, por lo que en el desarrollo del sistema se van a mostrar los diagramas IDEF y los diagramas de flujo. Se muestran los resultados de aplicar un filtro de color a un frame, ya que al realizar este filtro se puede reducir el tamaño de la imagen al convertirla en una imagen de tres capas en una imagen de una sola capa.
Sucesión de imágenes
Filtro de color
40
Diagrama de Flujo 1 Adquisición y conversión de frame RGB-escala de grises
Los resultados obtenidos al implementar este filtro son satisfactorios por lo que se realiza el proceso de test de forma recursiva conforme al Modelo en V, este proceso se muestra a continuación y en caso de ser satisfactorio se valida la aplicación de este filtro de color. Cabe señalar que cada proceso que se adquiera es necesario realizarlo haciendo énfasis en la programación modular, la cual busca generar pequeños módulos para poder atacar un problema más pequeño y subsecuentemente resolver el problema principal. Por lo que es prudente aplicar el mismo Modelo en V para cada módulo del sistema. Los resultados obtenidos se muestran a continuación, ya que este mismo proceso es posible simularlo en un ambiente de desarrollo similar en el proceso de programación. La ventaja de simular los procesos en un ambiente de desarrollo de alto nivel es verificar si los resultados son útiles para las características que buscamos destacar en la imagen. Además de ser más fácil su programación y contar con herramientas desarrolladas, en los pasos siguientes se hará uso de esta herramienta de programación. Es un software que incluye módulos matemáticos, procesamiento digital de imágenes, entre muchas otras herramientas que se pueden utilizar para simular el funcionamiento del sistema ANC. 4.6 Conclusiones Parciales Desarrollo.
Conclusiones:
Se comprueba por medio de un equipo simulador que el equipo boletera tiene la capacidad para funcionar
como un sistema ANC.
Por medio del Método en V se pueden verificar las especificaciones a seguirse en el diseño final. Por lo
que se utilizara en cada proceso o desarrollo del sistema ANC.
Antes del proceso de codificación se realizara una simulación en Matlab, como una forma de comprobar
los resultados y se integra a la parte Fase de Diseño.
41
Capítulo 5. Diseño a Detalle.
En este capítulo se inicia el análisis del diseño dirigido a un autobús, utilizando el simulador de equipo boletera, se muestran los parámetros involucrados en el diseño y de cada desarrollo se realiza con la metodología del diseño modular para software, además de verificarse el diseño con el Método en V.
42
5.1 Especificaciones indirectas
El Método-V o Modelo en V define un procedimiento para el desarrollo de productos (aplicaciones de software)
dicho producto tiene parámetros físicos para los cuales está diseñado, para el caso del sistema ANC los
parámetros de diseño están definidos por el transporte para el cual está orientado. Una forma para dirigir el diseño
de un autobús es tomando en cuenta el estudio en la parte de Benchmarking. El diseño se hace semejante al
producto Movileye que es el producto que más se adecuó a los objetivos del sistema ANC.
Algunos de los aspectos que se buscan tratar en este desarrollo son:
Distancia de frenado VS tiempo de procesamiento Geometría de la carretera
5.2 Distancia de frenado y tiempo de procesamiento
Se iniciará el análisis de distancia de frenado contra tiempo de procesamiento, por la razón que aun existiendo una
alerta esta debe de ser oportuna al momento de emitirse, o debe de existir en un tiempo prudente anterior al riesgo
de colisión. Para esto existen múltiples factores a considerar, además de factores externos al vehículo. Por este
motivo se recurre a una normatividad SAE J1250 FEB80 y SAE J299 JAN80.
Conductor Tipo de freno Estado de la superficie Tipo de vehículo Carga del vehículo
En un artículo publicado por el gobierno del Distrito Federal se realizó el Test de Distancia de frenado a el
transporte público de la ciudad de México por lo que se agregan los datos. Tales datos se comparan con las
respuestas típicas de las normas antes descritas.
Tabla 10 Distancia de Frenado Metro-bus ciudad de México
43
Estos resultados están referenciados a las condiciones de vehículos que circulan en el corredor Metro-bus, por lo
que las condiciones que se aplican son muy similares a las que se requieren, dichas condiciones son el vehículo,
el tipo de suelo y un percentil de tiempo de respuesta del conductor. Para dar una aproximación de las normas
SAE J1250 FEB80 y SAE J299 JAN80 se toma la tabla de respuestas típicas para realizar una aproximación del
sistema.
Ilustración 12 Distancia de frenado típica
Tomando en cuenta los datos de la ilustración 12. Se puede contemplar el tiempo de reacción como el tiempo en el
que se genera una alerta, esto para tener en cuenta el tiempo de procesamiento que se requiere en el sistema.
Estos datos se introducen en una fórmula adquirida de una norma europea que simplifica sus datos para aproximar
el tiempo de respuesta y el tiempo de frenado. A continuación se presentan los cálculos para hacer una
aproximación del tiempo de respuesta y generar el tiempo de procesamiento máximo para el sistema.
Fórmula 1 Distancia de detención
En la fórmula 1 las literales tienen los siguientes significados:
V = velocidad inicial Dp = distancia de detención tp = tiempo de parada
i = inclinación de la rasante (pendiente) µl = coeficiente de rozamiento longitudinal
Tomando en cuenta que los autobuses tienen un límite de velocidad (90 km/h) se utilizara el límite de velocidad
para determinar su distancia de frenado. Además se espera poder tener un límite de tiempo de procesamiento
basándonos en estas cifras. De los cuales se tiene: la velocidad = 80 km/h y la distancia de frenado= 38m.
También se requieren investigar los datos que faltan, los cuales son: inclinación máxima y el coeficiente de
rozamiento promedio.
Se obtienen como resultado las tablas siguientes en donde es posible determinar los datos faltantes. En la tabla 11
se obtiene la inclinación máxima de carreteras mexicanas dependiendo de la velocidad máxima a la que transita,
en la tabla 12 se muestra el coeficiente aprobado para los pavimentos de las carreteras mexicanas, dado que
estas cifras aparecen en normas oficiales mexicanas, se puede aprobar su uso en la fórmula 1. En el caso especial
del coeficiente de fricción se tomara el promedio ya que este coeficiente depende de la temperatura de la
carretera. Por lo que es prudente tomas las temperaturas promedio de las carreteras mexicanas.
44
Vp (km/h) Inclinación
máxima Inclinación excepcional
100 0.4 0.5
80 0.5 0.7
60 0.6 0.8
40 0.7 1.0
Tabla 11 Inclinación máxima para una carretera.
Tabla 12 Coeficiente de fricción aprobado en pavimentos de carreteras Mexicanas.
El resultado de despejar la variable de tiempo y sustituir los datos adquiridos en la investigación, se muestran a
continuación. Este parámetro será el tiempo de procesamiento del sistema ANC.
Fórmula 2 Distancia de detención con datos de carreteras mexicanas.
Se despeja el tiempo de reacción y se obtiene el siguiente resultado, que está sometido a las condiciones máximas
que se pueden encontrar a esta velocidad.
s
Fórmula 3 Resultado del tiempo de procesamiento.
De igual forma si se toman los datos directamente de la ilustración 12 se puede obtener un resultado similar al
resultado presentado utilizando la fórmula 1. Este resultado se presenta a continuación y se muestra que tomando
en cuenta las características de suelo y los datos de normas mexicanas, se puede utilizar el tiempo de reacción
obtenido de la fórmula 3.
Se tomará como tiempo de procesamiento máximo igual al tiempo de respuesta que se muestra en la fórmula 3,
por lo que se hará el diseño a detalle respetando este parámetro.
45
Estos datos ayudan a definir el diseño del sistema. En el diagrama 18 se muestran los datos para los cuales es
posible generar un diseño, se presentan los parámetros para los cuales se está proponiendo el diseño.
Conociendo los datos el sistema puede realizar un análisis orientado a un tipo específico de vehículo.
Diagrama 18 Representación de datos obtenidos para tiempo de procesamiento.
El dato mostrado en el diagrama 18, como factor de seguridad es el alcance que se podría tener utilizando una
cámara como sensor de video. Estos datos nos dan un límite de tiempo de procesamiento al cual se debe adecuar
el sistema, este nuevo parámetro que se integra a las especificaciones del sistema ANC.
5.3 Geometría de carretera
Para definir los parámetros del sistema se ha hecho referencia a las normas oficiales vigentes, en el caso de la
geometría de la carretera, para el caso de la geometría de la carretera se hace referencia a una norma aplicable al
proyecto de investigación que sea vigente y que permita estandarizar las líneas en carretera, esto con la finalidad
de cumplir con uno de los objetivos propuestos.
5.3.1 Norma Oficial Mexicana NOM-034-SCT2-2003
Para conocer las medidas de las líneas que acotan el sistema carretero mexicano es necesario hacer referencia a
la norma oficial mexicana NOM-034-SCT2-2003 esta norma aún se encuentra vigente y está orientada a la
estandarización de carreteras y caminos urbanos en todo el país. El uso de esta norma es la detección de las
líneas en carretera, esto para generar una alerta de salida involuntaria del carril. Tomando en cuenta que el
sistema utilizará una cámara para poder detectar las líneas de carretera se requerirá de un algoritmo de
procesamiento digital de imágenes para detectar las líneas y procesarlas.
Señalamiento horizontal y vertical de carreteras y vialidades urbanas
En la introducción del documento se señala que en uno de los objetivos de esta norma se contemplaba la
reducción de accidentes viales, por lo que es importante para la prevención el hecho de la estandarización de las
carreteras. De igual forma una alerta de salida involuntaria de carril puede colaborar a prevenir los accidentes. A
continuación se presentan los trazados de las carreteras siendo los más importantes para este proyecto los
señalamientos verticales.
Tiempo de reacción a
80 km/h = 0.892 Factor de seguridad
46
Se lograron identificar diferentes tipos de medida para las cuales se debe realizar el sistema. Siendo estas
medidas los patrones para realizar la identificación de carriles.
Ilustración 11 Distancia de frenado típica
Ilustración 13 Señalamiento horizontal y vertical para carreteras mexicanas
En la ilustración 13 es posible definir la resolución del sistema, basándose en la línea de menores dimensiones, esta línea es la que marca el acotamiento derecho para cada carril. Cabe señalar que las líneas de mayor dimensión sería más fácil detectarlas por el sistema ANC. Cabe señalar que las líneas horizontales no presentan relevancia para este sistema.
Una vez definidos los parámetros para detectar las líneas es necesario conocer la geometría de una carretera
desde una cámara digital, para esto se requiere conocer el proceso de adquisición de la imagen de una carretera,
posteriormente se genera el proceso para codificar en el Modelo en V.
47
5.3.2 Adquisición de imagen de carretera
Como se había propuesto en las secciones anteriores la detección de las líneas de carretera se basará en
procesamiento digital de imágenes. Como inicio se basara en imágenes de carretera adquiridas por medios
digitales. Estos ejemplos pueden ser desde una web-cam hasta cámaras digitales con alta resolución a
continuación se muestran algunos ejemplos de carreteras en las cuales se busca realizar un ejemplo para la
detección de líneas en carretera. En la ilustración 14 se muestra una imagen de carretera, esto con la finalidad de
analizar los parámetros de diseño que deben de cumplir las imágenes que se desean adquirir desde una cámara
digital. Esto apoyado con el resultado obtenido de la parte de desarrollo en la que ya se podía adquirir una imagen
en escala de grises.
Ilustración 14 Adquisición de imagen digital de carretera
Al analizar esta imagen es posible determinar que el eje focal de la imagen es paralelo al camino por lo que se
requiere definir la orientación de la cámara de adquisición de datos, de tal manera que sea favorable a los
objetivos propuestos para este proyecto de investigación.
La orientación del eje focal de la cámara se muestra en la parte central de la imagen. Conocer u orientar el eje
focal de la cámara nos permitiría conocer el centro de la imagen y medir su alcance. De cierta forma la orientación
de la cámara y su ubicación en el vehículo podrán colaborar a un mejor desempeño del sistema. En la siguiente
ilustración se muestra la forma en como la orientación del eje focal de la cámara, permite adquirir datos relevantes
para nuestro sistema.
Ilustración 15 Cámara instalada en automóvil
Tomando en cuenta que la colocación de la cámara puede ofrecer ventajas en alcance, es posible determinar que
al colocar la cámara en un autobús es posible adquirir una distancia a la cual se mejore la detección de las líneas y
una distancia a la cual se pretendan localizar vehículos. Dependiendo de los alcances de su resolución y de su
nitidez. En el siguiente ejemplo se pretende ejemplificar el caso de la Ilustración 15 implementada en un autobús.
Eje focal de
cámara
48
Se puede tomar como referencia la colocación del producto Movileye instalado en un autobús Volvo, para esto es
necesario adquirir las especificaciones de un autobús Volvo, para conocer los parámetros del diseño. A
continuación se presentan los datos de un autobús Volvo 9700.
Ilustración 16 Autobús Volvo 9700 referencia de diseño.
Ahora se muestra la ventaja que se obtendría variando la orientación del eje focal de la cámara. Utilizando el CAD
del vehículo Volvo 9700. Además se adquieren los datos del vehículo para realizar el diseño y los parámetros que
se esperan en una imagen adquirida por la cámara.
Ilustración 17 Variación en la orientación del eje focal de la cámara
En la ilustración 17 se muestra como aprovechando la altura del vehículo es posible tomar ventaja al inclinar el eje
focal de la cámara. Esto para adquirir más datos de la carretera. Ahora es importante tomar en cuenta las
especificaciones del autobús volvo 9700 para determinar su posición en el carril y obtener las especificaciones
geométricas de la carretera. A continuación se presenta la hoja de especificaciones del Volvo 9700 para
desarrollar su análisis sobre un carril.
Ilustración 18 Hoja de especificaciones Volvo 9700
Eje focal de cámara
a)
b)
49
De la ilustración 18 se puede obtener el ancho del autobús, este dato es importante para determinar su posición
adecuada dentro del carril, tomando en cuenta la norma mexicana oficial.
Ilustración 19 Acotaciones norma oficial mexicana con acotación Volvo 9700
De este diagrama se pueden obtener los datos para los cuales se restringe la detección de líneas. Cabe señalar
que el ancho de autobús es un parámetro a seguir en la detección de líneas de carretera. Teniendo los datos de
geometría de carreteras es posible realizar el desarrollo de la detección de líneas de carretera por el sensor de
video.
3.2
5 m
2.6
0 m
50
51
Capítulo 6. Detección de líneas verticales
de carretera.
En este capítulo se desarrolla el método para segmentar las líneas de carril con las restricciones obtenidas en el capítulo anterior, orientadas a prevenir la invasión de carril y la distracción del conductor.
52
Proceso de detección de líneas
En el capítulo 4 se mostró el uso de los diagramas IDEF, en esta sección se propuso una forma de cómo obtener
las líneas de la carretera, posteriormente se hizo mención a las especificaciones que se deberían contemplar al
momento de la detección. Por tal motivo es posible añadir los datos obtenidos al Modelo en V para poder
comenzar el diseño específico de detección de líneas de acotamiento. A continuación se muestra el diagrama
IDEF para mostrar el proceso de detección de líneas, además es prudente contemplar la opción de utilizar el
código descrito en el capítulo 4 en el cual se obtuvo la imagen en escala de grises.
Diagrama 19 Diagrama IDEF para la detección de líneas de carretera
6.1 Algoritmos para detección de bordes
De acuerdo al diagrama 19 la detección de las líneas depende de tres procesos anteriores, por lo cual se requieren
realizar la detección de bordes y la conversión a binario. Esto se hace de manera secuencial para reducir el
procesamiento de atributos que nos son útiles para esta selección.
Diagrama en V
Para obtener las líneas de carretera se hace referencia al diagrama 17.b en el cual se había definido un método
para la adquisición de líneas, método para el cual se especifica el uso de una detector de bordes y un selector de
umbral. En la sección 4.4 se obtuvo un filtro de color para pasar una imagen de RGB a escala de grises. Para
seguir el procedimiento ahora se busca detectar bordes. Aplicando el Modelo en V se puede realizar el análisis de
la detección de bordes.
53
6.1.1 Fase Especificaciones
Los rasgos que se requieren para detectar líneas es detectar los bordes de una imagen o frame, para esto es
necesario filtrar la escala de grises. Se realiza una investigación para detectar bordes en una imagen y las
opciones que se tienen son:
Filtro Laplace
Filtro Sobel
Filtro Prewitt
Filtro Canny
Filtro Roberts
Ilustración 20 Método en V con especificaciones para detector de bordes
6.1.2 Fase Funcional
El proceso de selección se simplifica al descartar el filtro Laplace que se simula en Matlab y genera una imagen de
16 bits, los que genera dos imágenes y esto podría aumentar los procesos en el CPU. Posteriormente se
descartan el filtro Canny ya que utiliza la primera derivada de los filtros Roberts, Sobel y Prewitt. De igual forma se
elimina el Filtro Roberts ya que este es un filtro de frecuencia, lo que posiblemente genere perdidas de datos en
los procesos siguientes.
Se ha visto también que el filtro Sobel es empleado para la detección de bordes, requiere de menos operaciones
para ser funcional, entre otras ventajas que ofrece. Por lo que se pasa a la etapa de Funcionalidad y se realiza el
diseño del código además de realizar su simulación en Matlab.
Tiempo menor a 1 segundo
Menos de 80 % del CPU
Resolución de líneas de 2m x 10cm
Detección a más de 50 mts.
Obtención de datos por cámara
Utilizar la imagen de escala de grises
Simulación en Matlab
Selección de detector de bordes
Diagrama de Flujo
54
6.1.3 Fase Diseño
Se ha propuesto presentar un diagrama de flujo con las operaciones a realizar sobre imágenes con la finalidad de
tener un mejor control de las funciones utilizadas además de efectuar una descripción de las variables y las
herramientas que se utilizan. El operador Sobel es utilizado en procesamiento de imágenes, especialmente en
algoritmos de detección de bordes. Técnicamente es un operador diferencial discreto que calcula una
aproximación al gradiente de la función de intensidad de una imagen. Para cada punto de la imagen a procesar, el
resultado del operador Sobel es tanto el vector gradiente correspondiente como la norma de éste vector.
Matemáticamente, el gradiente de una función de dos variables (en este caso, la función de intensidad de la
imagen) para cada punto es un vector bidimensional cuyos componentes están dados por las primeras derivadas
de las direcciones verticales y horizontales. Para cada punto de la imagen, el vector gradiente apunta en dirección
del incremento máximo posible de la intensidad, y la magnitud del vector gradiente corresponde a la cantidad de
cambio de la intensidad en esa dirección.
El objetivo de la segmentación en el campo de la visión artificial es el proceso de dividir una imagen digital en
varias partes (grupos de píxeles) u objetos con atributos diferentes. La segmentación se utiliza para simplificar y/o
cambiar la representación de una imagen en otra más significativa y más fácil de analizar. La segmentación se
aplica tanto para localizar objetos como para encontrar los límites de estos dentro de una imagen digital. Con
mayor precisión, la segmentación de la imagen es el proceso de asignación de una etiqueta a cada pixel de la
imagen de forma que los píxeles que compartan la misma etiqueta también tendrán ciertas características visuales
similares. Realizando la segmentación de las líneas divisorias de carril se pretende procesar parámetros como la
dirección de la carretera o la distancia entre vehículos, realizando estos una función muy importante en el sistema.
Modelo matemático del filtro Sobel
Matemáticamente, el operador utiliza dos kernel de 3×3 elementos para aplicar convolución a la imagen original
para calcular aproximaciones a las derivadas, un kernel para los cambios horizontales y otro para las verticales. Si
definimos A como la imagen original y Gx y Gy son los dos kernel que representan para cada punto las
aproximaciones horizontal y vertical de las derivadas de intensidad, el resultado es calculado como se muestra en
la siguiente fórmula:
Fórmula 4, a) Kernel Sobel horizontal, b) Kernel Sobel Vertical
En cada punto de la imagen, los resultados de las aproximaciones de los gradientes horizontal y vertical pueden
ser combinados para obtener la magnitud del gradiente, mediante la operación presentada a continuación:
Para llevar a cabo la simulación del sistema se ha planeado la aplicación de los algoritmos de programación en el
programa MATLAB el cual por sus funciones ya definidas (filtros, matrices e impresión de imagen) resulta como
una buena opción de verificar los datos que necesitamos obtener. En la ilustración 21 se muestra la aplicación del
kernel Horizontal del filtro Sobel en una imagen en escala de grises. Se utiliza una imagen con una carretera en
curva debido a que la imagen tiene componentes en ambos kernel.
Ilustración 21 Resultados de aplicar kernel de Sobel Horizontal
De la Ilustración 21 es posible percibir que se pierden rasgos importantes de la imagen en su componente vertical,
por lo que se realiza la obtención del kernel vertical de Sobel. A continuación se presentan los resultados del uso
de kernel vertical de Sobel.
Ilustración 22 Resultados de aplicar kernel de Sobel Horizontal
Comparando los resultados obtenidos, correspondientes a cada Kernel se pueden tomar criterios de selección. Los
cuales estarán sustentados por los resultados perceptibles de una imagen. Además se propone utilizar el método
completo de Sobel, del cual es necesario unir los resultados de ambos kernel y obtener su gradiente. A
continuación se presenta el resultado de la gradiente de ambos kernel.
56
Ilustración 23 Resultados de aplicar modelo matemático de Sobel.
Es posible procesar una imagen que muestre líneas rectas en carretera para tomar la decisión de codificar este
algoritmo en lenguaje C. En la ilustración 23 se procesará la imagen obtenida en el capítulo 4 en escala de grises,
por lo que se espera se tenga una buena nitidez de las líneas de carretera. Esto se puede verificar al aumentar el
tamaño de una sección de la misma imagen y verificando su nitidez.
Ilustración 24 Resultados de aplicar modelo matemático de Sobel a una carretera con líneas rectas.
Al obtener buenos resultados en la nitidez de la imagen es posible pasar al último nivel del Modelo en V, para esto
es necesario definir el procedimiento del algoritmo en un diagrama de flujo. Teniendo en cuenta que lenguaje C no
usa las mismas funciones que Matlab, por lo cual es necesario generar las variables a controlar.
6.1.4 Fase Codificación
El proceso de codificación a lenguaje C tiene dos fases, la primera; procesar una imagen aislada. La segunda:
procesar una sucesión de imágenes o video en tiempo real. Esto se refiere a procesar los 24 frames que envía la
cámara en un segundo como máximo. Esto genera la secuencia de video. Para poder probar el código de lenguaje
C se introduce una imagen y se procesa con el filtro Sobel. A continuación se muestra el resultado en lenguaje C.
Ilustración 25 Imagen procesada con código en lenguaje C
57
6.1.5 Fase Test Diseño
Los resultados obtenidos en la codificación del
algoritmo de detector de bordes Sobel, son
aceptables, ya que se puede apreciar correctamente
las líneas divisorias de carril, por lo que se puede
validar la implementación del detector de bordes
Sobel. Una vez teniendo los resultados del
procesamiento en una imagen se puede utilizar el
mismo código para una secuencia de video.
6.1.6 Fase Test Funcional
Para esta etapa se verifica la unión del código
necesario para realizar la secuencia de imágenes, tal
es el caso para el filtro Sobel, lo que no genera
ningún problema. Cabe señalar que no se había
realizado la secuencia en video de la obtención de la
escala de grises.
Diagrama de Flujo 2 Procesamiento de una
imagen con lenguaje C
Diagrama de Flujo 3 Secuencia de imágenes (video)
RGB, escala de grises y filtro Sobel.
58
6.1.7 Fase Test Especificaciones
Para esta fase se requiere verificar las 4 especificaciones descritas anteriormente. Las cuales son:
Tiempo menor a 1 segundo Menos de 80 % del CPU Resolución de líneas de 2m x 10cm Detección a más de 50 mts.
Cada una de estas especificaciones requiere verificarse en cada proceso por lo que para la detección de líneas, se verifican en el orden propuesto.
1) Tiempo de procesamiento menor a 1 segundo 2) Menos de 80% del CPU 3) Resolución de líneas de 2m x 10cm 4) Detección a más de 50 mts
Tiempo de procesamiento menor a 1 segundo
Para comprobar esta especificación fue necesaria la realización de un programa que pueda medir el tiempo de procesamiento de cada frame desde que se adquiere hasta que se imprime en pantalla el frame procesado. Esto de igual forma se puede representar en el diagrama de flujo 3 con las imágenes y el tiempo de procesamiento.
Ilustración 26 Proceso de conversión de la imagen a filtro Sobel
Por medio de estos datos se puede verificar que el procesamiento del filtro Sobel requiere 6 operaciones por pixel. Esto es posible explicarlo como un proceso de barrido de la imagen con una ventana dinámica. Por tal motivo se hace mención de los kernel presentados en la fórmula 4, esto con la finalidad de mostrar el número de operaciones que se realizan por pixel.
Ilustración 27 Operaciones relacionadas con el proceso del filtro Sobel
9 operaciones por pixel
9 operaciones por pixel
2 operaciones por pixel
59
Una vez detectado el problema es posible hacer referencia al Modelo en V, para iterar el diseño. A continuación se muestra como el modelo en V nos puede ayudar a generar la iteración y las propuestas de solución del problema presentado. El problema se detectó en la etapa de especificaciones por lo que es posible regresar a la línea de la fase funcional para proponer un nuevo diseño.
Ilustración 28 Ruta de diseño para generar la nueva solución
Teniendo en cuenta que se procesan imágenes VGA (640 x 480) y se requieren 24 frames por segundo, la cantidad de operaciones incrementa y al mismo tiempo el procesamiento. Por esta razón es posible determinar que el algoritmo completo genera una cantidad muy grande de operaciones, por lo que la primera opción podría ser escalar la imagen, o modificar su tamaño de entrada por lo que se podría reducir el procesamiento a una cuarta parte. Se puede proponer una segunda opción, la cual se orienta a procesar solo una parte de la imagen, es posible procesar solo una tercera parte de la imagen para reducir el procesamiento, o en dado caso se podría hacer una combinación de ambas opciones.
Ilustración 29 Propuesta para reducir el procesamiento de la imagen
Ruta para iterar el
diseño Se revisan las especificaciones
para generar una nueva
propuesta
Se revisa la funcionalidad de la
nueva propuesta
640
480 320
240
60
De esta opción se obtienen resultados pero no son tan significativos por lo que se procede a utilizar la segunda opción en conjunto con la primera. Se escala la imagen de entrada y se reduce el procesamiento a dos terceras partes, ya que con esto se podría reducir la cantidad de operaciones que se realizan.
Ilustración 30 Reducción del procesamiento en una tercera parte.
Puesto que el uso de las dos propuestas anteriores no presentó resultados significativos, se amplía la modificación hasta la etapa del diseño. Este cambio abre la posibilidad de buscar otras opciones de detector de bordes. Se toma en cuenta que los filtros antes descartados tenían la cantidad similar en el número de operaciones. Por lo que no se requiere realizar el Método en V para ellos.
Ilustración 31 Reducción del procesamiento en una tercera parte.
En la investigación de aproximaciones u Homologías se manejan dos opciones, la primera es una homología basada en la máscara Bayer de adquisición de la imagen en una cámara digital. La segunda propuesta es una aproximación numérica del algoritmo matemático de Sobel. Se descartan los modelos matemáticos ya que estos utilizan algoritmos similares.
640
320 320
160
Ruta para iterar el
diseño Se revisan las especificaciones
para la nueva ruta
Se descartan opciones similares
Se busca información de
aproximaciones u Homologías
61
Opciones de diseño basados en aproximación u Homologías a un detector de bordes:
1) Imagen de mínimos. 2) Aproximación de Sobel.
De estas dos opciones la que menos operaciones requiere es la de Imagen de mínimos, la cual es generada por un efecto conocido como aberración digital, este efecto sucede cuando el filtro Bayer o mascara Bayer adquiere la imagen de forma digital en una imagen. Debido a la experiencia con los operadores matemáticos, se tomará la opción de la imagen de mínimos, por lo que es posible adecuar el diseño a la máscara de mínimos y en dado caso utilizar las opciones antes desarrolladas para reducir el número de operaciones. A continuación se describe el proceso de selección, en el caso especial de que este algoritmo no cuenta con antecedentes bibliográficos se puede asignar un nombre.
Imagen de mínimos
El algoritmo descrito no tiene referencias bibliográficas por lo que se manejara como imagen de mínimos, se describe la teoría involucrada con este método. Como principio de información se debe conocer el proceso de adquisición de la imagen, este proceso es electrónico y esta generado por un componente llamado Filtro o Mascara de Bayer, el cual es un arreglo matricial, que puede detectar la presencia de algún color en un pixel, dependiendo de la resolución de la cámara, el filtro Bayer adquiere la imagen en una forma como se muestra en la Ilustración 32, en esta ilustración se muestra la configuración o disposición de los colores en el filtro Bayer. En el proceso de adquisición de la imagen un filtro de colores permite adquirir la intensidad de ese color en un pixel o en su defecto si no existe el filtro en un pixel adecuado, el filtro calcula el promedio de color o la probabilidad de color en ese punto. Por lo que los bordes generan un pixel virtual. Teniendo en cuenta que debajo del filtro Bayer se encuentra un sensor monocromo.
Ilustración 32 Detección de aberración digital por filtro Bayer
Un dato importante para la implementación del detector de bordes por imagen de mínimos; es que como el filtro Bayer realiza este proceso, se reduce el procesamiento del CPU, por lo mismo sólo se requiere hacer dos operaciones, estas operaciones no requieren operadores complejos por lo que se espera el procesamiento se bajó y el tiempo sea mínimo.
Aberración digital debida a interpolación
de color en filtro Bayer
62
Las operaciones que se requieren para generar el detector de bordes, se ilustran las siguientes imágenes, en las cuales se hace referencia a la homología de la aberración digital del filtro Bayer. A continuación se presenta las operaciones en imágenes necesarias para adquirir un detector de bordes.
Ilustración 33 Resta de la imagen de mínimos de la imagen original.
En la ilustración 33 se demuestra su etapa funcional, por lo que es necesario simularla en Matlab, tal como se representa en el Método en V. Demostrando esta teoría se podría proceder a codificar la nueva propuesta. Cabe señalar que esta nueva propuesta está orientada a reducir el tiempo de procesamiento, al reducir el número de operaciones. A continuación se presentan los resultados de la codificación de la imagen de mínimos, en Matlab comparado con el filtro de Sobel también de Matlab.
Ilustración 34 Comparación de métodos detectores de bordes a) Sobel b) Mínimos
Es posible apreciar en la ilustración 34 que el método propuesto solo ha perdido un poco de resolución por lo que es posible implementarlo, con la expectativa de aumentar el desempeño en tiempo del sistema, además que se reduce el tiempo de procesamiento. Para poder realizar la codificación a lenguaje C, se requiere un diagrama de flujo, además de que puede ser un buen indicio en la comparación de los procesos que se realizaron, esta comparación nos puede ayudar a verificar que se espera un menor tiempo de procesamiento.
Imagen
mínimos
Imagen original Imagen bordes
a) b)
63
SE TOMA LA IMAGEN
GRAY Y SE REALIZA LA
OPERACIÓN DE
MÍNIMOS
Diagrama de Flujo 5 Método de mínimos
Diagrama de Flujo 4 Modelo matemático de Sobel
64
Se realiza la codificación del sistema en lenguaje C y se miden sus tiempos para verificar la especificación de tiempo. Se cubre la especificación y se añaden las características descritas las cuales se muestran en la Ilustración, las cuales permiten reducir el tiempo de procesamiento.
Ilustración 35 Se cumbre la especificación de tiempo y se finaliza el módulo de detector de bordes
6.2 Algoritmo conversor de Escala de grises a Binario
Como se había propuesto en el diagrama IDEF es necesario filtrar los pixeles menos significativos del detector de bordes, esto es posible generando un valor de umbral, dicho valor de umbral permite clasificar los valores de los bits de cada pixel en ceros lógicos (0 en escala de grises) o 1 lógicos (255 en escala de grises).
Ilustración 36 Conversión de escala de grises a imagen Binaria (blanco y negro)
Para calcular el umbral es necesario detectar la escala de grises en una imagen, por lo que se puede generar un histograma de la imagen de bordes, este histograma es un arreglo que contiene la distribución de cada valor de todos los pixeles de una imagen, por lo que es posible detectar en que región está trabajando la escala de grises. Cabe señalar que esta herramienta nos permite visualizar la cantidad de bordes que está manejando el sistema, debidos a la imagen de entrada. A continuación se muestra el diseño del histograma para el cálculo del umbral.
640
320 320
160
0 255
1 0 255 0
65
6.2.1 Histograma de bordes
En estadística, un histograma es una representación gráfica de una variable en forma de barras, donde la superficie de cada barra es proporcional a la frecuencia de los valores representados. En el eje vertical se representan las frecuencias, y en el eje horizontal los valores de las variables, normalmente señalando las marcas de clase, es decir, la mitad del intervalo en el que están agrupados los datos. En este caso los datos son los valores en escala de grises correspondientes a cada pixel. La selección del umbral está basada en el histograma de la imagen, el cual permite ver el número de valores en los que se encuentran los bordes (en escala de grises). A continuación se muestra el desarrollo del histograma con el modelo en V.
Ilustración 37 Modelo en V para el histograma de bordes
Es importante señalar que se requiere el código obtenido en la sección 6.1 será la entrada para el proceso de histograma de bordes. De igual forma se contemplan la misma cantidad de especificaciones para el proceso de adquisición de histograma. Un dato relevante en la detección de bordes del histograma es que el porcentaje de bordes es mínimo comparado a la cantidad de pixeles en la imagen.
Para esta fase es necesario comprender que el sistema ha adquirido una cantidad de datos considerable, por lo que es necesario cuidar el uso de las funciones y de la cantidad de operación que esta genera, dado que se está consumiendo tiempo de procesamiento.
Muestreo de valores de pixeles de imagen de bordes Histograma normalizado Obtención de datos en menos de 1 segundo
6.2.3 Fase Funcional
Con el desarrollo de más herramientas el sistema tiene una dependencia con las funciones anteriores, esto genera una secuencia de procesos. En el caso del histograma de bordes sólo es una herramienta para detectar los parámetros en los cuales es funcional el sistema. A continuación se presenta el diagrama de flujo correspondiente a la imagen de Bordes.
Diagrama de Flujo 6 Representación de histograma de bordes
En el caso especial del histograma de bordes no se realizara la simulación de código en Matlab, esto porque Matlab tiene una función en la cual se puede muestrear la imagen con el apuntador del mouse. A continuación se muestran el desempeño de esta función.
Ilustración 38 Uso de función IMVIEW de Matlab
INICIO
int num_filas, int num_columnasint Total_pixeles=0, int pixelesLk=0
Total_pixeles=num_filas*num_columnasInt Lk,0<=Lk<=10, float ilk
ilk= pixelesLk/Total_pixeles
0.9<=Ilk<=1
Activar visión nocturna
Si
No
INICIO
int num_filas, int num_columnasint Total_pixeles=0, int pixelesLk=0
Total_pixeles=num_filas*num_columnasInt Lk,0<=Lk<=10, float ilk
ilk= pixelesLk/Total_pixeles
0.9<=Ilk<=1
Activar visión nocturna
Si
No
67
6.2.4 Fase Diseño
Para el diseño de esta herramienta es necesario hacer uso de una herramienta para programación la cual es conocida como seudocódigo, esta herramienta ayuda a percibir las partes más elementales de un algoritmo, que posteriormente se convertirá en código. Seudocódigo
1.- Inicio 2.- Declarar una variable que represente el número total de pixeles en la imagen (Total_pixeles), declarar una variable que represente el número de pixeles con tono de gris predeterminado (pixeles_lk), declarar una variable que proporcione la probabilidad de ocurrencia del nivel de gris predeterminado (ilk). 3.- Total_pixeles = número_filas_imagen*número_columnas_imagen, 0 <= lk <= 10, Ilk = pixeles_lk/Total_pixeles. 6.2.5 Fase de Codificación
Los resultados de la codificación se presentan a continuación, con la imagen que se muestrea, cabe señalar que los bordes representan menos del 10 % de la imagen. Esto por la efectividad del filtro de bordes. Teniendo estos resultados es posible determinar el valor del umbral y realizar el código. Para una imagen de bordes se genera el Histograma en el cual se puede aprecia la mayor cantidad de datos de un borde.
Ilustración 39 Selector de umbral en bordes, imagen Binaria
selector de umbral
68
6.3 Detector de líneas
Para la detección de líneas se investigaron dos métodos, la transformada de Hough y la transformada de Radon
Transformada de Radon
En matemáticas, la transformada de Radon bidimensional, llamada así por Johann Radon, es una transformación integral que consiste en la integral de una función sobre un conjunto de rectas. Por ejemplo, si una línea la representamos por la siguiente ecuación:
Fórmula 6 Representación de una línea recta en la transformada de Radon
Donde es la mínima distancia desde la recta al origen y es el ángulo que forma el eje con el vector posición del punto de la recta más cercano al origen, entonces es posible determinar la integral como:
Fórmula 7 Integral de algoritmo de Radon
En un espacio -dimensional la transformada de Radon es la integral de una función sobre hiperplanos. La integral de una función sobre un conjunto de rectas en un espacio -dimensional se le denomina transformada de rayos-X, aunque a veces este término es adoptado por la transformada de Radon. Anteriormente se había detectado que una cantidad muy extensa de operaciones en un filtro, por lo que se buscan más opciones, y se contempla la posibilidad de una aproximación matemática o una homología a el proceso matemático. Por lo que se consulta otro tipo de transformación.
Transformada de Hough
La Transformada de Hough es un algoritmo empleado en reconocimiento de patrones en imágenes que permite encontrar ciertas formas dentro de una imagen, como líneas, círculos, etc. La versión más simple consiste en encontrar líneas. Su modo de operación es principalmente estadístico y consiste en que para cada punto que se desea averiguar si es parte de una línea se aplica una operación dentro de cierto rango, con lo que se averiguan las posibles líneas de las que puede ser parte el punto. Esto se continúa para todos los puntos en la imagen, al final se determina qué líneas fueron las que más puntos posibles tuvieron y esas son las líneas en la imagen. La transformada de Hough emplea una representación paramétrica de formas geométricas. Una recta, por ejemplo
se representa por un módulo (phi) (perpendicular a la recta y que pasa por el origen (0,0) y un ángulo (rho) (formado por el módulo y el eje positivo de las x's). Se representa así:
Fórmula 8 Representación matemática algoritmo de Hough
Cabe señalar que el proceso de adquisición de patrones de Hough es más simplificado, por lo que se propone para la detección de líneas. Por esta razón se persigue la especificación que directamente se relaciona con el tiempo de procesamiento, por tal motivo se requiere verificar el tiempo al termino del diseño.
Ilustración 20 BIS Método en V con especificaciones para detector de bordes
Parte de las aplicaciones de la librería de visión artificial tienen una función llamada Hough, esta función se adecua a las necesidades del sistema por lo que se utiliza teniendo en cuenta el algoritmo matemático, se pueden esperar ciertos valores y ciertas características, por lo que es necesario controlar la función y realizar filtro condicionales para disminuir la cantidad de ruido que pueda existir al momento de ejecutar la función. El resultado de implementar la función genera líneas en todas direcciones y posiciones de la imagen, lo cual se puede apreciar en la siguiente ilustración en donde se realizó un modelo a escala de una carretera, para poder definir el rango esperado de líneas.
Tiempo menor a 1 segundo
Menos de 80 % del CPU
Resolución de líneas de 2m x 10cm
Detección a más de 50 mts.
Obtención de datos por cámara
Utilizar la imagen de escala de al
grises
Simulación en Matlab
Selección de detector de bordes
Diagrama de Flujo
70
Ilustración 40 función Hough sobre modelo a escala de carretera.
Para filtrar los datos que se imprimen en la imagen se realiza la caracterización de un carril, en el cual se pueden apreciar las líneas de carril. Esto es posible condicionando la impresión de líneas en la imagen. Para esto se requiere un proceso condicional. Este proceso condicional parte de un diagrama de cómo puede ser las líneas en un carril. En la siguiente ilustración se plantea el procedimiento para determinar la idealización de líneas en un carril y con esta herramienta poder filtrarlas.
Ilustración 41 idealización de carretera
Para esto es necesario procesar un triángulo, en el cual se pretende idealizar la geometría de una carretera, por lo que sería posible adquirir los datos necesarios, en una impresión de pantalla. Con los puntos inicial y final de las líneas que se están generando.
Ilustración 42 Modelado de una carretera con un triángulo equilátero
71
Utilizando el software desarrollado hasta este punto, es posible obtener los siguientes datos, de los puntos en los que puede aparecer una línea de carretera, se procesan y se muestran los resultados del desarrollo. De igual forma se utilizan los datos de salida para generar un filtro antes de la impresión de las líneas que no corresponden a las líneas buscadas en una carretera.
Ilustración 43 Modelado de una carretera con un triángulo equilátero
Es posible apreciar en la imagen que se trazan las líneas y en qué punto se pueden llegar a trazar, de estas líneas dibujadas solo nos interesan las que se describen en el capítulo 5 (Diseño a Detalle) en el cual se determina la búsqueda de las líneas verticales de la carretera, En este caso se puede hace mención que las carreteras no pueden tener inclinaciones máximas por lo que el triángulo tiene una variación acotada, este dato es importante porque se da un factor de incertidumbre. Una vez encontrado el valor esperado de las líneas de carretera, es posible generar un filtro en el cual se muestran los valores esperados. Y se filtra la imagen de salida.
Ilustración 44 Filtro de líneas por ángulo
Una vez realizado el filtro angular de líneas, es posible procesar el video, con la detección de líneas, para esto se añade la función y el filtro condicional angular al código que se generó hasta la sección 6.2.
72
A continuación se muestra el filtro implementado en el modelo a escala, esto para comprobar su eficiencia en video, esto para comprobar las características de filtrado de las líneas. A continuación se muestra la implementación del filtro anular de líneas en video.
Ilustración 45 Filtro angular de líneas aplicado a modelo a escala
Cabe señalar que el sistema se está diseñando para un autobús, si se ajusta la altura en la que se coloca la cámara se puede modificar el ángulo con el que se visualizan las líneas, por lo que es importante hacer mención del modelo a bordo de un autobús. Para poder generar la comparación de la imagen vista desde un automóvil y posteriormente la vista generada por una cámara en un autobús.
Ilustración 46 geometría de líneas de carretera esperadas en autobús.
Esta geometría ofrece las ventajas de tener una mejor aproximación en la carretera al variar el ángulo de las líneas esperadas, esto se parte de la idea de segmentar un camino ideal, recto, plano y uniforme. Estas consideraciones son muy apropiadas al tener en cuenta que es cuando el vehículo alcanza la velocidad máxima permitida, al procesar una imagen de carretera con estas consideraciones. Para el siguiente ejemplo se realizó la prueba de un frame aislado, de la imagen que se ha mostrado como ejemplo de carretera. Esto con la finalidad de extrapolar los datos adquiridos a una fotografía real. Se esperan los resultados de la carretera ideal o una aproximación de ellos.
Proyección de líneas de
carretera. Variando la altura y
dirección de eje focal
73
Ilustración 47 Resultado de algoritmo de Hough a imagen de carretera real.
Los resultados que se adquieren son muy satisfactorios aunque se detectan más de una línea en la división de carriles las cuales no son necesarias, se espera realizar la simulación a escala de las diferentes líneas de carretera, además se consideran los criterios que se había tenido desde el principio de esta sección, al detectar una línea de carretera de 10 a 15 cm de grosor, esto puede ayudar a considerar si se planea un mayor alcance de segmentación de una carretera. 6.4 Conclusiones parciales detector de líneas
Conclusiones:
Se consideran los primeros 15 metros para la detección de la posición del vehículo sobre el carril.
Para segmentar el camino hasta la vista de alcance propuesta se puede considerar seccionar la imagen
dependiendo de la búsqueda de los patrones
74
75
Capítulo 7.Detección de objetos en
carretera.
En este capítulo se desarrolla un método para identificar y clasificar los objetos que se encuentran sobre el acotamiento de la carretera, específicamente en el carril donde transita el autobús. Se determinan objetos hasta el momento en que se puedan obtener características del objeto a clasificar, características como desplazamiento, área y centroide. Esto para poder generar un criterio y definir si es un obstáculo o vehículo.
76
7.1 Detección de objetos sobre carretera
Se trata como objeto a un elemento que se encuentra sobre el carril en el que circula el autobús. Esta descripción se da por la razón que la detección de un objeto en la carretera en una imagen aislada tiene solo relevancia si se conoce la velocidad a la que se mueve dicho objeto. Teniendo en cuenta este parámetro o una aproximación, es posible determinar si el objeto puede clasificarse, conociendo las características que se presentan a continuación.
Velocidad Área de pixeles Centroide o baricentro
Estas dos características no pueden permitir generar un criterio en el cual un objeto sobre la carretera puede clasificarse como un vehículo o un obstáculo en el siguiente diagrama se muestra una representación en la cual haciendo uso de dos parámetros es posible clasificar un objeto.
Diagrama de Flujo 7 Representación de selección de objeto
Con este criterio es posible determinar si un objeto en el camino es un obstáculo o un vehículo. Esto para generar una alerta, y en caso de aproximarse a un vehículo se pueda medir la distancia. En las siguientes secciones se detallará sobre la medida de la distancia con otros vehículos, por el momento se presenta el diseño del algoritmo para detección de objetos en el camino. 7.1.1 Algoritmo para la detección de Blobs
Antes de clasificar un objeto es necesario que pase por un proceso para segmentar un elemento de una imagen, de este proceso se determinan parámetros o características útiles para su clasificación posterior. A continuación se presenta un algoritmo para procesamiento de imágenes que es conocido como generador de Blobs (del inglés manchas).
Algoritmo para segmentar blobs
El algoritmo de blobs agrupa píxeles vecinos con las mismas características dentro de un mismo blob, formando así grupos de píxeles más grandes dentro de la imagen. Para esto es necesario aplicar un filtro a nuestra imagen, dicho filtro debe de separar las imágenes en imágenes binarias, que posean las mismas cualidades. Como inicio se trata una imagen la cual presente un algoritmo conocido como conectividad a 4, en este proceso se busca separar los elementos segmentados en una imagen, por lo que es importante realizar un algoritmo para separar los elementos de una imagen.
si
no
𝒗𝒂𝒖𝒕=𝒗𝒆𝒍𝒐𝒄𝒊𝒅𝒂𝒅 𝒅𝒆𝒍 𝒂𝒖𝒕𝒐𝒃𝒖𝒔
𝒗𝒐𝒃𝒋=𝒗𝒆𝒍𝒐𝒄𝒊𝒅𝒂𝒅 𝒅𝒆𝒍 𝒐𝒃𝒋𝒆𝒕𝒐
Objeto detectado
𝒗𝒂𝒖𝒕 ≅ 𝒗𝒐𝒃𝒋
Obstáculo
Vehículo
77
Conectividad
En este algoritmo se busca encontrar los diferentes elementos de una imagen, dicho elementos se encuentran segmentados pero aún no se pueden procesar independientemente. Por lo que se requiere del proceso de conexión a 4 para poder segmentar la totalidad de elementos de la imagen.
Ilustración 48 Modelo en V para Blobs
7.1.2 Fase Especificaciones
Para la fase de especificaciones se requiere separar los elementos de una imagen de acuerdo a su conexión con los pixeles vecinos, esto puede ser llevado a cabo con un algoritmo de conectividad entre pixeles. Esto se representa en la siguiente figura, en la cual se presenta la vecindad entre pixeles. Esta se presenta en vecindad a 4 y vecindad a 8.
Separar los elementos binarizados de una imagen. Etiquetar dichos elementos
7.1.3 Fase Funcional
Para desarrollar esta especificación es necesario determinar la vecindad entre pixeles para esto se requiere identificar los pixeles vecinos y posteriormente etiquetarlos de tal forma que se puedan separar. Para esto es necesario tener en cuenta los dos diferentes proceso en los cuales es posible separar los elementos de una imagen: conectividad a 4 y conectividad a 8. Haciendo la suposición que un pixel se requiere realizar su conectividad, se ubica la posición de un pixel y se coloca en el centro del kernel de 9, como se muestra en la siguiente figura.
Separar los elementos de una
matriz binaria.
.
Definir la conectividad a 4 para
separación de elementos binarizados
Simulación en Matlab
Prueba de conectividad
78
Ilustración 49 Conectividad a 4 y a 8.
7.1.4 Fase Diseño
Para esta fase es necesaria una imagen binarizada con elementos diferentes, en la cual se realiza el barrido de la imagen (traslación en cada uno de los píxeles de la imagen) para etiquetar cada píxel, basándose en la conectividad a 8. Debido que algunos elementos pertenecen a aberraciones digitales. Se realiza un barrido de la imagen teniendo en cuenta que el píxel central tiene coordenadas (X, Y). Esto para poder ubicar los pixeles vecinos, estos aparecen representados con las siguientes fórmulas.
Fórmula 9 Representación matemática de vecindad entre pixeles
Posteriormente se etiqueta la imagen con un contador para definir grupos, estos grupos se pueden procesar posteriormente para generar los elementos sin conectividad. A continuación se muestra una imagen en la cual se etiquetan los pixeles segmentados en una imagen. Además se muestra el contador que inicia en el primer pixel encontrado y etiquetado.
Ilustración 50 Conectividad a 4 y a 8.
Pixel de
Coordenadas(X,Y)
79
Se muestra el proceso codificado en Matlab para probar el algoritmo de conectividad a 8, se inicia con una simulación de una imagen binaria y posteriormente se retoma las imágenes obtenidas en la sección de detector de líneas y detector de bordes. Estas imágenes funcionan como imágenes de entrada para el procesamiento de la conectividad.
Ilustración 51 Imagen binaria etiquetada por elementos de conexión a 8
Ahora se realiza el segundo barrido de la imagen en el cual se hace la conectividad de elementos para obtener la separación de elementos que presentan la conectividad.
Ilustración 52 Representación de Blobs de una imagen binaria
7.1.5 Fase Codificación
A continuación se presenta la codificación de una imagen de carretera en la cual se ha logrado integrar las fases anteriormente descritas para las cuales se generan los blobs. La imagen de entrada es una imagen generada en la sección de detector de bordes. Al final del proceso de blobs se espera tener elementos diferentes de los cuales se puedan discernir de un elemento sobre la carretera, así como de las líneas que se lograron segmentar en las secciones anteriores. Se introduce la misma imagen de carretera para que los datos generados sean congruentes.
Ilustración 53 a) etiquetado de elementos, b) separación de blobs, c) elementos buscados
a)
b)
c)
80
7.2 Filtro de objeto por área de pixeles
En el capítulo anterior se propuso un método para discernir entre un objeto y un obstáculo, en esta sección se pretende generar un método para determinar si un obstáculo sobre la carretera es potencialmente peligroso, esto puede determinarse segmentando el obstáculo y separando los elementos que posiblemente sean ruido o de igual forma pequeños elementos que no generen algún riesgo sobre el camino. En la sección anterior se obtuvo un algoritmo para separar los diferentes elementos de la imagen. En esta sección se busca clasificar los objetos que se determinaron como obstáculos y determinar si son un riesgo potencial sobre el camino. Esto es posible calculando su área en pixeles y el incremento de esta área, este incremento es posible medirlo determinado un factor geométrico conocido como Centroide. Se modela un filtro por área de pixeles en el Método en V. A continuación se muestra el proceso de diseño basado en el modelo en V.
Ilustración 54 Modelo en para Filtro de área de pixeles
Área de un blob (área en pixeles)
Al inicio de esta sección se determinó que un objeto es posible clasificarlo como obstáculo o como vehículo, ahora es necesario clasificar los obstáculos, en potencialmente peligrosos o poco peligrosos, esto es para evitar una colisión con un elemento significativamente grande que pueda ocasionar: un daño, una pérdida material o un incidente. Por lo que es necesario conocer el área de un obstáculo y crear un criterio de riesgo potencial. El primer paso para generar este criterio es calcular el área de un obstáculo basada en la cantidad de pixeles que conforman este blob, este criterio es muy similar al área geométrica de un cuerpo, ya que bien se podría calcularse contando los pixeles que lo conforman y utilizar esta medida como estándar, por lo que se propone medir el área en pixeles de un objeto segmentado de una matriz binaria. Esta segmentación puede ser algunos de los procesos que se realizaron anteriormente, ya sea la matriz de escala de grises o la matriz de bordes.
Caracterizar los obstáculos que
presenten un riesgo de daño,
basándose en su área de pixeles
.
Calcular el área de pixeles de cada
obstáculo detectado
Simulación en Matlab
Selector del obstáculo más grande
81
7.2.1 Fase de Especificaciones
En esta fase es importante extraer la información de una imagen binaria, ya sea de una imagen de bordes o de la escala de grises utilizando un umbral (descrito en la sección 6.2 de este proyecto de investigación). Cabe señalar que en este punto del sistema ya se cuenta con una imagen binaria y en caso de necesitar una imagen binaria de otra imagen es posible efectuarla, esto con el anexo 1, en el cual se detallan en el desarrollo de software que el código para generar una aplicación es posible utilizarlo basta con adecuar los datos y conocer los resultados esperados. Teniendo en cuenta esto se hace referencia a un umbral en la imagen de bordes, este umbral no puede permitir adquirir información diferente que la que se requería en la imagen de líneas. A continuación se presenta la especificación para el filtro por área de pixeles.
Caracterizar los obstáculos que presenten un riesgo de daño, basándose en su área de pixeles
Para generar un criterio se podría tener como referencia la segmentación de una persona, esto porque podría generar un daño a algún peatón sobre la carretera, Para tener una idea de cómo generar el área de una persona y buscar sobre la imagen la relación que existe entre su área en pixeles y el área en la que aparece. Para mostrar esto es necesario adquirir una imagen segmentada de una persona, haciendo referencia de nueva cuenta a la imagen de blobs obtenida en la sección 7.1.4, es posible aprecia que un peatón circula sobre la avenida. A continuación se presenta la imagen donde se hará referencia a este concepto.
Ilustración 55 Proporción de área en pixeles para un peatón
=
Fórmula 10 Área total binaria y área del blob
≅
Fórmula 11 Proporción en área de pixeles
Si tomamos en cuenta que se procesan imágenes de 320 x 240 pixeles, y se tiene la misma imagen de carretera con la que se ha trabajado, también podemos tomar un criterio para el área en pixeles a partir de la cual se podría tener un riesgo potencial. A continuación se muestra la imagen de carretera con las medidas con las cuales se busca trabajar.
8 pix 1 6
pix
82
Ilustración 56 Imagen de carretera con blobs de ruido en el camino
7.2.2 Fase Funcional
De igual forma se toma la consideración que un obstáculo con proporciones que se consideran potencialmente peligrosas, puede presentarse a cierta distancia sobre el camino, Es necesario detectar un obstáculo a la distancia que se había propuesto en la sección 5.2 se hace referencia a la distancia de frenado en la cual si detecta un obstáculo potencialmente peligroso tenga el tiempo de frenar. Este obstáculo se vería a 53 metros con una proporción menos en área de pixeles, por lo que se puede contemplar una escala de este, por tal motivo es probable que el obstáculo se vea sobre el camino como una proporción de su medida real. Para esto es necesario, pensar que el autobús puede virar sobre el camino, teniendo en cuenta todos estos aspectos. Se presenta la justificación de un obstáculo potencialmente peligroso en carretera.
Diagrama 18 BIS Representación de datos obtenidos para tiempo de procesamiento.
Tomando en cuenta que el obstáculo podría ser visto a una distancia de 53 metros y que el autobús podría virar para evitarlo, sin salir del carril. Se tiene una longitud de seguridad de 65 cm, esta es la resta de la longitud del carril menos la longitud del autobús. Ahora es posible determinar el área en pixeles mínima para poder generar una alerta. Tomando en cuenta la lustración 56. En la que el carril aproximadamente a 50 metros utiliza aproximadamente 70 pixeles, es posible tener en cuenta que si el carril mide 3.25 m un obstáculo de 65 cm. Se aprecie un blob aproximadamente de 15 a 20 pixeles y se puede pensar que tenga un grosor de 3 pixeles. Por lo que se tiene un área en pixeles entre 45 y 60 pixeles. Tomando en cuenta que el blob puede no estar bien definido se propone un blob de un área de 35 pixeles.
Fórmula 12 Área de obstáculo potencialmente peligroso.
Tiempo de reacción a
80 km/h = 0.892 Factor de seguridad
320 pix
240
pix
Ruido presente en
imagen.
Vehículo aprox. a 50 m
83
7.2.3 Fase Diseño
Una vez adquiridos las especificaciones es posible generar una simulación en Matlab en la cual el programa pueda tener el criterio de discernir entre el blob más grande encontrado en una imagen. A continuación se muestra la simulación en Matlab con una imagen segmentada o binaria.
Ilustración 57 Clasificador de un obstáculo potencialmente peligroso a) Blob b) área en pixeles c) objeto potencialmente peligroso.
7.3 Centroide de un blob
Hasta este punto se han adquirido características en una imagen, estas características pueden ser trascendentales en cada imagen. Pero no es pertinente almacenar la imagen para analizar el frame siguiente. En la siguiente ilustración se hace referencia a la ilustración 10 de la sección 4.4 en la que se hace mención del proceso en el cual se puede aislar un frame de una sucesión de imágenes. Es por esta razón que en el procesamiento de una imagen se adquieren datos que son trascendentales solo para esa imagen. En esta sección se buscan parámetros que puedan servir para procesar toda una secuencia de imágenes o video.
Ilustración 10 BIS Frame aislado de un fotograma
Es posible adquirir parámetros de una imagen, solo haciendo unos cálculos que no demanden demasiado procesamiento, por lo que se puede pensar en adquirir algunos datos que describan un blob.
Sucesión de imágenes
a) b) c)
84
Centroide geométrico
El centroide geométrico o baricentro de un objeto X pertenece a un espacio n-dimensional. Es la intersección de todos los hiperplanos que dividen a X en dos partes de igual n-volumen con respecto al hiperplanos. Informalmente, es el promedio de todos los puntos de X. Para poder realizar el cálculo del centroide en una imagen es necesario de la imagen segmentada en blobs, esto con la finalidad de realizar el cálculo por filas y columnas del blob. Para poder darnos una mejor idea tomaremos la imagen ‘c’ de la ilustración 57 y para mostrar la propuesta para calcular el centroide de una imagen.
Ilustración 58 Método de selección de filas y columnas para cálculo del centroide.
Fórmula 13 Modelo matemático para calcular el centroide.
En la ecuación anterior Dx y Dy son las coordenadas del centroide del objeto, Ai y Aj representan la cantidad de píxeles tomados del origen de la imagen (punto marcado con rojo en ilustración 58) al inicio de Di para x y Dj para y respectivamente. El dato obtenido de este centroide es un dato que puede almacenarse de igual forma que el área de un blob, esto con la intención de que sea utilizado como una función que regrese los valores del centroide y del área en pixeles, esto para determinar si el objeto se acerca o se aleja. De igual forma es posible generar una trayectoria a lo largo de la imagen. Cualquiera de los datos permite conocer parámetros para clasificar al objeto en obstáculo o vehículo. A continuación se muestra la forma en como los elementos pueden ser encontrados dentro de una carretera y ser segmentados para su clasificación.
Ilustración 59 Resultado al procesar la secuencia completa a) blobs b) área en pixeles c) filtro de área d) centroide
𝐷𝑖
𝐴𝑗 𝐷𝑗
a) b)
c)
d)
85
7.4 Uso de parámetros
La forma en cómo se pretenden usar los parámetros desarrollados hasta esta sección se ejemplifican a continuación. En una imagen de carretera se ilustra la forma en como la obtención de estos parámetros nos pueden ayudar a procesar las imágenes o poder darle atributos en su desarrollo. Uno de los criterios más útiles en este desarrollo es la identificación de un obstáculo al cual se aproxima el autobús, a una determinada velocidad, se realiza la simulación de un objeto dentro de una carretera previamente segmentada. Para determinar cómo se pueden relacionar estos elementos, se hace una representación en las siguientes imágenes.
Ilustración 60 Resultado al procesar la secuencia completa de un frame.
Se genera la imagen binaria, según el criterio a seguir (bordes,
escala de grises, etc.).
Se segmenta el camino para poder analizar la trayectoria
Se buscan blobs y conectividad, se calcula el área por pixeles
Se determina si son potencialmente peligrosos y se almacena
su centroide y su área en pixeles.
86
Al obtener los parámetros correspondientes a cada blob filtrado, se puede dar seguimiento en el frame siguiente para generar un patrón de trayectorias o para determinar su peligro potencial. Esto puede entenderse en una secuencia de imágenes en las cuales puede mostrarse la secuencia de las imágenes y sus parámetros obtenidos.
7.5 Conclusiones parciales detección de objetos en carretera
Conclusiones:
Con los términos generados es posible discernir entre un vehículo y un obstáculo.
Las consideraciones que se tomaron para poder definir un obstáculo pueden cambiar dependiendo el tipo
de segmentación que se utiliza.
Hasta este punto se han tratado solo obstáculos, en la siguiente sección se definirá con más certeza un vehículo una posible detección de distancia potencialmente peligrosa.
87
Capítulo 8.Distancia de seguridad entre
vehículos.
En este capítulo se desarrolla un método para poder prevenir la distancia de seguridad con un vehículo frontal, esto para evitar una colisión o determinar si es una distancia prudente a determinada velocidad. Se sigue la línea de investigación que se utilizó para detectar un objeto sobre la carretera.
88
8.1 Distancia de seguridad entre vehículos
De acuerdo a los datos adquiridos en la sección 1 de este proyecto la distancia de seguridad es uno de los factores que cuando no se controlan pueden provocar un accidente. En la sección 7 se abordó ampliamente la detección de obstáculos en carretera, esto para poder prevenir un impacto con un obstáculo de dimensiones específicas. En esta sección se analiza el complemento del diagrama de flujo de la sección 7. A continuación se presenta una propuesta para poder medir distancia entre vehículos.
Diagrama de Flujo 7 BIS Representación de selección de objeto
De acuerdo al diseño definido en la sección 3 se había propuesto un diseño para poder medir la distancia entre vehículos, esto con la finalidad de evitar las colisiones frontales con vehículos debidos a no respetar la distancia de seguridad. A continuación se presenta la ilustración 5 del capítulo 3. En ella se puede hacer referencia al diseño propuesto.
Ilustración 5 BIS Elementos de propuesta Actia
El diseño que se había propuesto constaba de un sistema de detección de distancia basado en sensores ultrasónicos. Hasta este punto se ha logrado simplificar el sistema de forma tal, que no se ha requerido instalar un sistema de muestreo diferente al sensor de video. Y de acuerdo con las especificaciones otorgadas por el equipo Actia de México, se ha logrado integrar todo el sistema en solo sensor. Esto es uno de los beneficios de utilizar el modelo en V. Este modelo permite que el diseño sea iterativo de tal forma que el sistema ANC. Podría funcionar solo con la cámara. A continuación se presenta una propuesta para medir la distancia con otro vehículo a partir del sensor de video y un emisor laser.
𝒗𝒂𝒖𝒕=𝒗𝒆𝒍𝒐𝒄𝒊𝒅𝒂𝒅 𝒅𝒆𝒍 𝒂𝒖𝒕𝒐𝒃𝒖𝒔
𝒗𝒐𝒃𝒋=𝒗𝒆𝒍𝒐𝒄𝒊𝒅𝒂𝒅 𝒅𝒆𝒍 𝒐𝒃𝒋𝒆𝒕𝒐
Objeto detectado
𝒗𝒂𝒖𝒕 ≅ 𝒗𝒐𝒃𝒋
Obstáculo
Vehículo
Detección
de líneas
Detección de
Distancia
Detección de
Obstáculos
Procesamiento Alerta Sonora Detección de Luminosidad
89
Cálculo de distancia con objetos
La detección de distancia se realizó mediante el uso de una técnica propuesta debido a las dificultades que implican las opciones propuestas inicialmente en trabajo terminal I. Los problemas encontrados con las técnicas propuestas con anterioridad son los siguientes: Visión estereoscópica: resultó ser una técnica eficiente en cuanto al cálculo de distancia, pero ineficiente en el tiempo de procesamiento visto desde la utilización de las 2 cámaras que exige ésta técnica para hallar la distancia entre la cámara y el objeto colocado en frente de la misma. Como se informó oportunamente en el protocolo de investigación de trabajo terminal I, el tiempo de procesamiento del sistema de navegación es una característica sumamente importante para que el sistema realice oportunamente las tareas que se requieren. De manera que el uso de 2 cámaras exige el doble de recursos al sistema y lo hace lento, ineficaz para funcionar apropiadamente. Blobs: el uso del algoritmo de blobs presentado también en trabajo terminal I es bastante eficaz, pero presenta fallas al tener que procesar el cálculo de distancia con objetos de proporciones geométricas irregulares, lo cual implica un mal cálculo del centroide de la figura y del área que ocupa el objeto, haciendo así que el cálculo del dichos datos interfieran con la obtención de la distancia correcta entre la cámara y el objeto. Una vez mencionadas las razones por las cuales se han descartado momentáneamente el uso de las técnicas antes planteadas se procede a dar solución a dichas dificultades. El método propuesto consiste en la utilización de una sola cámara la cual realizará tomas que serán proporcionadas a un programa quien se hará cargo de calcular la distancia. Se considerará un punto de referencia en la cámara para procesar la distancia, éste punto de referencia será el centro de la imagen que proporciona la cámara. Una vez encontrado el punto de referencia se procede a hacer uso de un apuntador láser el cual será proyectado al frente de la cámara y éste se podrá ver como un punto para la cámara, dependiendo de la distancia a la que se encuentre el objeto de la cámara, la cantidad de píxeles entre el centro del punto de referencia y el centro del punto láser serán variables. La Ilustración 61 muestra lo que estaría observando la cámara si se encontrara frente a un objeto.
Ilustración 61 Detección del sensor de video en carretera.
Una vez presentada la visión que tendría la cámara, se procede al aislamiento del punto láser, de toda la escena proporcionada por la cámara, con lo cual se considerarán parámetros más específicos como los que se muestran en ilustración 62.
Punto central
de la cámara
Objeto cualquiera
Punto
láser
90
Ilustración 62 Aislamiento del punto láser de la escena.
Como se puede observar en la figura anterior, el punto representa el parámetro más importante y se aísla del resto de la escena proporcionada de la cámara, lo cual se hará basándose en la segmentación del punto láser. Se pretende hacer algo similar a lo que ve el ojo humano partiendo de la siguiente situación: Si tomamos una hoja en blanco, la pegamos en una pared, tomamos como referencia la mitad de la altura de la hoja y posteriormente pintamos en la hoja un punto como el de la Ilustración 62 y lo visualizamos fijamente acercándonos lo suficiente, de manera que el punto sea visible para nuestro campo visual, podremos ver que el punto se aleja de la referencia que en nuestro caso es la mitad de la hoja la cual se mantiene fija, y en el caso contrario si nos alejamos podremos ver que el punto se aproxima a la referencia que indicamos inicialmente (Ilustración 63) . De tal forma que el procesamiento realizará una tarea bastante similar a la descrita con anterioridad tomando en cuenta las siguientes consideraciones
Ilustración 63 Analogía de la visión de la cámara y el ojo humano.
Basándonos en el razonamiento anterior procedemos a un análisis más completo haciendo uso de parámetros más específicos. Inicialmente se tienen colocados la cámara y el láser en una posición que debe de ser fija para fines prácticos, un arreglo que nos permitiría que la cámara vea las escenas anteriores es el siguiente (Ilustración 64).
Ilustración 64 Arreglo de la cámara y el láser.
Láser
Cámara
91
De ésta forma la cámara proporcionará una imagen con determinado campo de visión el cual podrá ser visto de la siguiente forma:
Ilustración 65 Visualización del alto y ancho de una imagen.
Ahora la visión de la cámara sería la siguiente con base en la ilustración 65:
Ilustración 66 Altura proporcionada por la cámara.
Con base en las imágenes anteriores se realiza el siguiente análisis, partiendo de la idea de que podemos conocer el punto central de la imagen que proporciona la cámara, además la altura “h” del centro de la cámara con
respecto al láser es constante y conocida. El valor que se desea conocer es la distancia del objeto a la cámara, por lo que la incógnita de interés es llamada “D”. Con ayuda de la geometría que nos proporciona la imagen D2.4 se pueden obtener las siguientes relaciones.
Ilustración 67 Relaciones geométricas de la cámara y el láser.
Alto
Ancho
Alto
Centro de la
cámara
θ h
D
Punto láser
92
D
htg Fórmula 14
D
htg 1 Fórmula 15
tg
hD Fórmula 16
Finalmente de manera experimental se proyecta el láser en un objeto y se proponen diversas distancias para realizar las mediciones, con ello se puede analizar que a determinada distancia un píxel toma valores en grados, esto es haciendo referencia a la ilustración 67. Experimentalmente se comprobó que la variación en grados del valor de cada píxel a diferentes distancias no varía mucho. Se realizaron experimentos proponiendo una distancia constante “h” igual a 8cm y las mediciones de distancia “D” comenzaron desde 30cm hasta 290cm en intervalos de 10cm para cada medición, por lo que la distancia con la que se trabajó comenzó en 30cm, posteriormente 40cm, 50cm, etc. Con lo anterior se encontró un valor no tan variable del ángulo correspondiente a cada píxel, dicha variación se encontraba entre 0.015 y 0.02º aproximadamente., lo cual producía un error en el cálculo de “D” de [±5cm], lo cual para fines prácticos y considerando que se trabajará con distancias hasta 20 veces más grandes que el error encontrado no serán perjudiciales para hallar la distancia riesgosa para un vehículo aproximándose a un objeto. Para obtener el ángulo “θ” que será empleado para conocer finalmente la distancia “D” se propone la siguiente ecuación:
= C.P.*(Equivalencia de un píxel en grados) Fórmula 17
C.P.: representa la cantidad de píxeles del centro de la imagen al centroide del punto láser. Equivalencia de un píxel en grados: es el valor fijo encontrado de manera experimental para saber el valor correspondiente en grados para un solo píxel. θ: es el valor que se sustituirá en la fórmula 16 para hallar finalmente la distancia del objeto a la cámara.
8.2 Conclusiones parciales detección de distancia de seguridad
Conclusiones:
El uso de un láser convencional (1mW) puede restringir el sistema a pocos metros de distancia y
condiciones bajas de luminosidad, aunque la implementación de un láser más potente permitirá obtener una distancia con una mayor certeza y se podría realizar desde adentro del vehículo sin necesidad de instalar un sistema con sensores de entrada. Cabe señalar que las pruebas realizadas permitieron verificar este método.
93
Capítulo 9.Detección de baja luminosidad
en carretera.
En este capítulo se desarrolla un método para poder detectar un índice de baja luminosidad en carretera, debido a que la mayoría de los accidentes ocurre en condiciones climatológicas poco favorables y por la noche, debido a la limitación de visibilidad del conductor.
94
9.1 Detección de baja luminosidad en carretera
De acuerdo a los datos adquiridos en la sección 1 de este proyecto la incidencia de accidentes se incrementa debido a las condiciones climatológicas que limitan la visibilidad y en nivel de ocurrencia se incrementa por la noche, siendo este un factor que debido a la adaptabilidad del ojo humano, no permite tener una noción del índice de luminosidad que tiene la carretera, por esta razón se pretende alertar al conductor del autobús en condiciones de baja luminosidad, dichas condiciones están acotadas por el rango de operación de la cámara. Esto quiere decir que la adaptabilidad del sensor de la cámara está acotada a un límite del cual no se puede ampliar. En el capítulo 1 de este proyecto se propuso la implementación de un sistema, que por medio de fotodiodos pudiera detectar el nivel de luminosidad de la carretera. Este sistema permitiría conocer y medir la luminosidad, con lo que se podría alertar oportunamente al operador para poder encender sus faros ante cualquier situación que demande ayuda de una fuente de iluminación para poder realizar efectivamente su labor.
Ilustración 5 BIS Elementos de propuesta Actia
De acuerdo con los resultados obtenidos se puede detectar la cantidad de luminosidad en el camino partiendo de la teoría que el sensor de la cámara es un sensor monocromático, el cual funciona como el fotodiodo. Este planteamiento puede permitir obtener el nivel de luminosidad con una resolución tan grande como tener 76, 800 sensores fotodiodo debido a la resolución de entrada de su sensor. Los elementos de la solución propuesta han cambiado debido a que el método de diseño utilizado es iterativo, por lo que aunque se haya propuesto una solución, se puede evaluar con los requerimientos, permitiendo investigar si se puede tener una nueva propuesta que simplifique el sistema. A continuación se presenta una propuesta que pretende simplificar el sistema. La detección de las condiciones de luminosidad bajo las que trabajará el sistema de navegación será realizada por una técnica para la identificación de la cantidad de pixeles (histograma) que tienen valores en escala de grises muy bajos, indicando así que muy probablemente se trate de condiciones de muy poca luz, lo cual indicaría que prácticamente es de noche, o simplemente las condiciones luminosas son poco favorables para facilitar la visión del operador, en éste caso se considerará una escala de grises que va de 0 a 10. Si el 90% o más de la cantidad de pixeles de la imagen total tienen valores en escala de grises entre 0 y 10 se activará la visión nocturna, de otra forma el sistema continuará funcionando de manera típica, esto es sin activar la visión nocturna, muestreando el entorno de navegación en condiciones normales, percibiendo las características del camino sin alteraciones con la luminosidad que proporcione el ambiente en ese momento. En el capítulo 6 se propuso medir el umbral de bordes con un histograma, por lo que es posible realizar la misma acción para obtener una medida de intensidad luminosa. Esto sólo funcionará para medir la baja luminosidad basándose en el nivel de operación de la cámara, por lo que se presenta la propuesta de solución a este sistema.
Detección
de líneas
Detección de
Distancia
Detección de
Obstáculos
Procesamiento Alerta Sonora Detección de Luminosidad
95
Algoritmo para activación de visión nocturna:
1.- Inicio 2.- Declarar una variable que represente el número total de pixeles en la imagen (Total_pixeles), declarar una variable que represente el número de pixeles con tono de gris predeterminado (pixeles_lk), declarar una variable que proporcione la probabilidad de ocurrencia del nivel de gris predeterminado (ilk). 3.- Total_pixeles = número_filas_imagen * número_columnas_imagen, 0 <= lk <= 10, ilk = pixeles_lk/Total_pixeles. 4.- Preguntar ¿0.9 <= ilk <= 1?, si la respuesta es sí, seguir el paso 5, si la respuesta es no, regresar al paso 3. 5.- Activar visión nocturna, regresar al paso 3. Una vez explicado el algoritmo empleado para la detección de la intensidad luminosa, se procede a desarrollar el diagrama de flujo, quien contiene de forma visual el proceso descrito. En el diagrama que se muestra a continuación se puede observar un inicio, un proceso de declaración de variables, un bloque de toma de decisión quien indica si se realizará la acción de activar o no el sistema de visión nocturna, basándose directamente en la ecuación que describe la cantidad de pixeles encontrados en la imagen a procesar. El algoritmo descrito al inicio de este apartado involucra la parte elemental de los cálculos para el desarrollo de la técnica del histograma, con lo cual será posible la detección de la intensidad luminosa, destacando que los desplegados gráficos en cuanto al histograma se refiere, se realizarán solamente con fines visuales, de manera que no serán parte de la toma de decisión del sistema de detección de intensidad luminosa.
Diagrama de Flujo 6 BIS Representación de histograma de bordes
Con los elementos ya obtenidos anteriormente es posible adecuar el desarrollo al nuevo planteamiento, sin desarrollar nuevamente el modelo en V. A continuación se muestran los resultados obtenidos del planteamiento del problema.
INICIO
int num_filas, int num_columnasint Total_pixeles=0, int pixelesLk=0
Total_pixeles=num_filas*num_columnasInt Lk,0<=Lk<=10, float ilk
ilk= pixelesLk/Total_pixeles
0.9<=Ilk<=1
Activar visión nocturna
Si
No
INICIO
int num_filas, int num_columnasint Total_pixeles=0, int pixelesLk=0
Total_pixeles=num_filas*num_columnasInt Lk,0<=Lk<=10, float ilk
ilk= pixelesLk/Total_pixeles
0.9<=Ilk<=1
Activar visión nocturna
Si
No
96
Ilustración 68 Histograma de baja luminosidad
En la Ilustración 68 es posible apreciar que el histograma cuando está en baja luminosidad se aproxima a cero, con lo cual es posible determinar cuando las condiciones son de baja luminosidad. La implementación de una herramienta desarrollada puede aplicarse directamente sobre el sistema, ahora bien si el sistema detecta baja luminosidad que se puede hacer para poder que la cámara pueda efectuar alguna acción para corregir la escasa luminosidad. 9.2 Procesamiento con cámara sensible al IR (infrarrojo)
En el espectro electromagnético es posible ubicar el rango visible, este rango es donde el ojo humano funciona con efectividad, a medida que se aleja del rango visible, el ojo humano se ve limitado por la escaza percepción que tiene de su entorno. Es por eso que la conducción de vehículos en estas condiciones puede tener una mayor probabilidad de tener un percance o accidente viales. En esta sección se documenta la investigación acerca del procesamiento de una cámara de video en el ancho de banda del Infrarrojo cercano se ponen a prueba, los desarrollos antes obtenidos para poder determinar la efectividad de esta teoría. 9.2.1 Detección de líneas de carretera en IR.
En teoría todas las cámaras digitales son sensibles al infrarrojo cercano, pero su percepción está limitada por un filtro óptico colocado después del lente de la cámara. Si se retira el lente, la cámara podrá detectar la iluminación infrarroja en la carretera. Aplicando el mismo desarrollo a una cámara sensible al infrarrojo pudo generar las aplicaciones antes descritas. A continuación se presentan las etapas de desarrollo procesadas con una cámara sensible al infrarrojo.
Ilustración 69 a) cámara sensible al infrarrojo, b) cámara ordinaria
a) b)
97
Las imágenes encontradas en la ilustración 69 muestran una ligera pero trascendente variación de iluminación de
una escena para el resalte de los bordes (líneas en carretera) que se requiere obtener en una situación real de
conducción. Se ha logrado verificar que en el mercado existen algunas cámaras a las que se les puede quitar el
filtro infrarrojo y realizan la captura de imágenes de la misma forma que cualquier otra cámara, la diferencia es que
éstas cámaras pueden ser mucho más útiles durante la noche como se aprecia en la ilustración número 69.
La ventaja de usar una cámara con éstas características radica en el resalte de escenas con más luz y ligeramente
más nítidas durante la noche a diferencia de si se utilizara una cámara ordinaria.
Una vez que se ha logrado aclarar un poco más una imagen nocturna asemejándose a una imagen ordinaria de
día es posible aplicar exactamente todo el proceso que sigue el sistema de navegación donde ahora la entrada al
sistema será la que proporcione una cámara con distintas características la cual solamente funcionará durante la
noche.
Basándonos en la ilustración número 68 lo único que se requiere hacer para activar ésta parte del sistema es
situarse en el histograma dado por la cámara ordinaria el cual al detectar una escena nocturna una amplia
cantidad de píxeles obscuros (escala de grises) accionará la cámara infrarroja que ahora será la entrada al sistema
de navegación que procesará exactamente las imágenes entrantes como se ha explicado a lo largo de toda la
investigación.
9.3 Conclusiones parciales detección de baja luminosidad en carretera
Conclusiones:
Es importante resaltar que en muchas ocasiones la aplicación de un enfoque sistemático, disciplinado y
cuantificable al desarrollo, operación y mantenimiento de software llevan a un eficiente desarrollo de diseño, especialmente en el caso de la detección de baja luminosidad en carretera, ya que para este caso no fue necesario diseñar un sistema sumamente grande para realizar una tarea más, cuando en realidad solo se implementó una parte importante no tan grande que fue la vinculación de una nueva cámara con ciertas características. Implícitamente con todo lo dicho anteriormente se ha hecho uso del reciclaje de código el cual ya fue previamente introducido en el sistema y esto hace un diseño más rápido y eficaz.
98
Capítulo 10.Discusión sobre la elección del
diseño final. Para finalizar con éste trabajo de investigación se establece una discusión sobre cómo fue que finalmente se optó por realizar un diseño con las características específicas que ahora describen al sistema asistente de navegación, todo esto con la intención de retomar los puntos de diseño previamente considerados.
99
10.1 Partiendo con un objetivo
Éste trabajo de investigación comenzó planteando un objetivo que es sumamente importante en el ámbito de diseño, dicho objetivo es el siguiente: “Desarrollar un sistema que permita colaborar a favor de la seguridad en la conducción de autobuses, alertando sobre obstáculos en situaciones de baja luminosidad y desviaciones del carril, así como proximidad riesgosa con otros vehículos”. Una vez comentado lo anterior si tomamos en cuenta que el diseño en ingeniería es un proceso reflexivo sobre determinadas áreas para la realización de productos, procesos o sistemas con los requerimientos especificados debemos considerar que el diseño es una actividad multidisciplinaria que requiere de la integración de diversas áreas, para éste caso se han involucrado algunas de las áreas que contempla la mecatrónica. Evidentemente este trabajo de investigación se ha enfrentado a retos muy importantes que van desde la presión de tiempo el cual se ha estipulado en trabajo terminal I y II, así como los detalles propios del sistema de navegación en diversos rubros, entre otros, todo esto ha llevado a el planteamiento de un diseño específico. 10.2 Atributos del sistema como parte de la elección de diseño
En diversas teorías de diseño muchos autores se enfocan con mayor frecuencia a diseños que implican manufactura, sin embargo en éste caso particular se trabajó con el diseño de un sistema y a pesar de ello es posible introducir una metodología orientada al mismo. En concurridas ocasiones el diseño de un producto o sistema están presentes la creación y la innovación, sin embargo el sistema de navegación está dirigido a la satisfacción de una necesidad social, esto es posible de ver ya que el objetivo de la investigación menciona el “desarrollo de un sistema que permita colaborar a favor de la seguridad en la conducción de autobuses” donde implícitamente se está tomando en cuenta no solo a los conductores de un autobús, sino también a los pasajeros que abordan el mismo. Por otro lado un atributo importante del diseño fue el no intervenir en el diseño del tablero del vehículo y en ninguna otra área visible, requisito que se cumplió sin problemas al acoplar el sistema de navegación a la computadora abordo ya existente en el autobús 10.3 Descripción de la cronología de diseño implementada en el sistema de navegación
A pesar de haber revisado distintas metodologías de diseño se trató de extraer las partes más importantes de cada teoría. A lo largo de la investigación incluso se llegó a ver que algunas personas han realizado diseños sin una metodología específica lo cual no parece ser muy común, sin embargo hay muchas otras personas que se han dedicado a tratar el diseño como una metodología que permite llevar un orden, tal es el caso de Nigel Cross, entre otros quienes se enfocan en puntos muy similares referentes a la metodología de diseño. Éste trabajo de investigación consideraron diversas fases del diseño en ingeniería, una de ellas es la “planeación” donde se consideraron muchos puntos tomados específicamente de los capítulos 1, 2 y 3 de éste trabajo. Para ésta parte se tomó en cuenta sobre todo la evaluación de nuevas tecnologías existentes tanto en nuestro país como se menciona en el capítulo 1.1.2 hablando sobre vialidades, así como la tecnología existente en el extranjero tal y como se habla al respecto en el capítulo 2.3.1. En ésta fase también se identificaron las restricciones y limitaciones tanto del sistema de navegación propuesto en éste trabajo como los existentes en otros países. En la parte de “diseño conceptual” se hizo especial hincapié en un sistema previamente vinculado a un autobús el cual al no ser aprovechado en un 100% se logró integrar a el mismo el sistema de navegación propuesto, además de que al hacer esto se lograba incluso no hacer ninguna modificación al tablero del vehículo donde se situara el sistema con lo que el sistema de navegación resulta casi invisible al diseño de interiores y exteriores del autobús lo cual no afectaría en un futuro a diseñadores los de los vehículos. Por otra parte México se podría considerar como un país donde la tecnología implementada resulta no tan común y no sólo México, sino también la gran mayoría del resto del mundo no ha integrado ésta clase de sistemas a sus vehículos y quienes lo hacen solamente a algunos vehículos específicos tal y como se explica en el capítulo 2.3 de éste mismo trabajo donde se hace referencia al benchmarking. Pasando a otra fase del diseño donde se generaron arquitecturas alternativas y se definieron partes específicas del sistema de navegación tenemos el “diseño a nivel sistema” tal y como se vieron algunos puntos en el
100
capítulo 3 de diseño conceptual donde se ven algunas de las opciones de diseño a considerar como lo establece el diagrama morfológico, el capítulo 4 referente al desarrollo general del sistema y el capítulo 5 de diseño a detalle. La siguiente fase está totalmente ligada al “diseño a detalle”, una parte sumamente importante de cualquier tipo de diseño por lo que incluso se dedicó un capítulo completo a la descripción de éste punto (capítulo 5). Finalmente se llegó a la última fase “pruebas y refinamiento” donde con base en los diagramas de flujo
mostrados a lo largo de éste trabajo se probaron los algoritmos diseñados codificándolos en Matlab y lenguaje C tanto para simulación como para pruebas reales en carretera. Todo lo anterior fue útil para refinar especialmente los algoritmos de segmentación y desde luego también los códigos fuente de todo el sistema de navegación. Haciendo énfasis en la parte de diseño del sistema se optó por trabajar con lenguaje C para el sistema final, ya que inicialmente como lo describe parte del capítulo 4, el equipo donde se implementó el sistema de navegación está basado en Linux, por lo que para un tiempo de ejecución corto se requiere de un eficiente lenguaje de programación, donde se descubrió que dicha eficiencia no podía ser efectuada por Matlab por ejemplo, debido a la alta demanda de recursos del sistema donde se ejecuta. Todos los puntos citados en éste capítulo así como cada capítulo orientado al diseño en éste trabajo fueron considerados al momento de la selección del diseño final del sistema de navegación en carretera con la finalidad de hacer un ordenado y eficiente trabajo de investigación con la intención de cumplir los objetivos marcados por el mismo. 10.4 Conclusiones parciales discusión sobre la elección del diseño final
Conclusiones:
Mediante éste capítulo se manifestaron algunas de las razones por las que se decidió la elaboración de
un diseño final del sistema asistente de navegación en carretera. Como se mencionó al principio de éste capítulo se logró ver que algunos diseñadores del producto no necesariamente siguen una metodología de diseño para llegar a un modelo final, sin embargo la experiencia retribuida al realizar éste proyecto indica que seguir una metodología de diseño hace más cortos los tiempos de construcción de productos o sistemas por lo cual se invita a nuevos diseñadores a seguir metodologías para una elaboración de productos y sistemas más eficiente tanto en tiempo, costos y otros rubros importantes.
101
Conclusiones generales
El trabajo de investigación elaborado ha logrado cumplir con el objetivo primordial al ser finalmente probado en una escena real donde el sistema asistente de navegación en carretera se monta a un vehículo y efectúa las tareas descritas a lo largo de toda la investigación. Es importante señalar que una de las ramas de la inteligencia artificial es la visión artificial y esta área puede contribuir a la satisfacción de algunas necesidades sociales como se observó mediante este trabajo donde se colaboró a favor de la seguridad en la conducción de vehículos en carretera.
Es importante resaltar que las metodologías de diseño encaminan a un mejor desarrollo del producto y de sistemas teniendo un orden en la ejecución de cada paso efectuado por un diseñador especialmente en las áreas de ingeniería. Durante la investigación fue posible darse cuenta de que en México y en otros países aún no se han dado grandes pasos en cuanto al desarrollo de sistemas de visión artificial extremadamente eficientes, incluso se logró ver que los sistemas de visión artificial avanzados existentes en el mundo aún tienen problemas para contrarrestar los efectos que ocasiona la luz al desempeño de los mismos, al igual que en pruebas de laboratorio realizadas en éste trabajo, por tal motivo se puede decir que actualmente en México existe la autosuficiencia para realizar sistemas de visión artificial de clase mundial.
102
Anexos
CONSTRUCCIÓN DE SOFTWARE
Anexo 1
Planificación.
Establecimiento del orden en que los componentes tales como variables a utilizar se crean e
integran ilustraciones 1 y 2.
Ilustración 2 Creación de variables
Anexo 2
Codificación.
Código fuente comprensible, asignación de nombres, tal es el caso del arreglo matricial creado
en C++ llamado sobx[3][3], quien corresponde a una matriz de 3x3, la cual contendrá valores
numéricos en cada uno de sus elementos, correspondientes a un operador empleado para
resaltar bordes horizontales en una imagen llamado sobel horizontal, por lo que se representa
como “x” haciendo referencia al plano cartesiano x-y.
La prevención a saturación de recursos de la computadora ha sido considerada de manera que
las imágenes procesadas no excedan de una resolución superior a 5 megapíxeles (siendo un
pixel el elemento más pequeño de una imagen), debido a que en la práctica se ha comprobado
que el procesamiento demanda mucho más tiempo si se trabaja con más pixeles en la imagen
a procesar.
Ilustración 1 Declaración de librerías
103
La aplicación de filtros de tipo gradiente para el resalte de bordes arroja un resultado bastante
interesante que merece un apartado para su análisis.
Es importante señalar que el tiempo de cómputo demandado por ciertas operaciones como la
multiplicación o la elevación de alguna variable a una potencia determinada en la práctica
involucra un consumo de tiempo considerable, dicha cuestión se presenta de igual forma
cuando se realiza el llamado a funciones declaradas en el programa.
Minimización de la complejidad.
En esta sección se enfatiza sobre la facilidad para la comprensión del código a realizar, en éste
caso particular se ha hecho uso de los comentarios tanto en los lenguajes de programación
como lo son Matlab y C++, especificando de forma clara la razón por la cual se ha utilizado
ciertas líneas de código.
Un ejemplo de aplicación del punto anterior en el sistema asistente de navegación en
carretera se muestra en las ilustraciones con códigos 3 y 4.
Ilustración 3, minimización de la complejidad comentando líneas en lenguaje C++.
104
Ilustración 4, minimización de la complejidad comentando líneas en lenguaje C++.
Anticipación de cambios.
Al ser empleados continuamente códigos que ya han sido utilizados con anterioridad, es
evidente que los cambios serán frecuentes a lo largo de la construcción (vinculación de nuevas
variables para efectuar otra función), dichos cambios podrán ser empleados de forma más
sencilla al tener comentados los códigos como se ya se ha hecho anteriormente.
Algunos cambios realizados en el programa se enfocan directamente al procesamiento de
imágenes, haciendo especial énfasis en la respuesta del sistema.
Los cambios significativos y trascendentales realizados recientemente se muestran a
continuación, ilustración 5.
La modificación mostrada en la ilustración 5 sustituye a los arreglos bidimensionales, donde el
acceso a sus elementos era más complicado por el uso de bucles for en C++, mientras que en
arreglos de una sola dimensión se facilita el acceso a ellos mediante un solo ciclo for.
Cabe mencionar otra modificación al programa en general que tiene que ver con la
implementación de apuntadores para el acceso eficiente a sus elementos, lo cual implica la no
Ilustración 5, sustitución arreglos bidimensionales por arreglos de una sola dimensión.
105
manipulación directa de datos, sino la manipulación de direcciones de memoria, lo cual facilita
significativamente en la práctica el procesamiento del programa.
Calidad del código
La calidad del código se ha desarrollado mediante la comprobación del correcto
funcionamiento por bloques, esto es ejecutar el código por funciones (una por una), desde la
declaración de librerías, hasta la declaración de variables, así como el proceso de eliminación
de contenido no útil (basura), generado aleatoriamente en las variables del sistema que
propicia errores en el programa principal.
Otro método empleado reside en la ejecución del código línea por línea para la realización de
un análisis más profundo que conlleva al análisis de todo un código parte por parte.
Se ha visto que la modificación de ciertas operaciones matemáticas simples como lo son la
sustitución de multiplicaciones por sumas y la elevación de potencias por multiplicaciones
permite facilitar la tarea del procesamiento del hardware [2], lo cual se ve reflejado en un
tiempo de procesamiento el cual se ve reducido y beneficia notablemente al desempeño de un
programa, ilustración 6.
Otra técnica para verificar el tiempo de ejecución de las líneas del código desarrollado está relacionada
directamente con la medición del tiempo que tarda en procesar el programa desarrollado de
determinado bloque del programa, ilustración 7.
Ilustración 6, modificación en código de expresiones matemáticas por su equivalente.
106
Anexo 3
Reutilización.
Se relaciona directamente con el “reciclaje” de programas, lo cual tiene que ver con la
utilización de código antes probado y que funciona apropiadamente, pero que puede ser útil
para el ahorro de tiempo en cuanto a codificación se refiere y así evitar escribir un mismo
código más de una vez, ilustración 8.
Ilustración 7, función declarada para medir tiempo de ejecución en milisegundos.
Ilustración 8, reutilización código antes usado para procesar datos con una cámara.
107
VERIFICACIÓN Y VALIDACIÓN
Verificación.
¿Se está construyendo correctamente el producto (software)?. El software se está
construyendo correctamente, debido a que se está resaltando las características deseadas, en
éste caso líneas en carretera, que son vistas como bordes en una imagen.
El empleo de técnicas para el realce de bordes hace posible la verificación de las técnicas
empleadas para desarrollar el programa, gracias a que se han visualizado distintos resultados e
incluso se ha desarrollado la posibilidad de elegir el más apropiado para los fines del proyecto
en general.
Validación.
¿Se está construyendo el producto correcto?
La necesidad consiste en la colaboración a la seguridad de un pasajero en un sistema de
transporte terrestre (autobús), parte de ello reside en la identificación de líneas en carretera
para avisar de posibles salidas riesgosas del carril, lo cual influye directamente en la seguridad,
por lo que es algo que beneficia al usuario.
El informe de inspección que toma en cuenta éste punto al encontrarse en su fase de
desarrollo tiene que ver con el rendimiento del programa hasta ahora elaborado, el cual es
aceptable hasta el momento, debido a que el objetivo particular de resaltar los bordes en una
imagen para la segmentación de líneas ha sido llevado a cabo en su totalidad.
ANEXO 4
PRUEBAS (EJECUCIÓN DEL PROGRAMA)
108
Relaciones entre error, defecto y fallo.
Error: equivocación del programador. ¿2+2=4?
Defecto: calidad. El sistema no es robusto y es susceptible de no funcionar en ciertas
condiciones no previstas (condiciones de poca luminosidad).
Fallo: fiabilidad. Tiene características que a la menor perturbación podría suscitar un
accidente.
Un error suscitado en el programa afecta directamente al tiempo ejecución de todo el proceso,
de tal manera que surgen cuestionamientos como:
¿Se está empleando el tipo de datos apropiados para las operaciones del programa?
De tal manera que se observa que un posible error del programador es emplear funciones ya
contenidas en el paquete para visión artificial que maneja C++.
Las funciones mencionadas son relativamente sencillas de emplear, sólo que al profundizar en
el funcionamiento de las mismas se observa que se está trabajando con “arreglos” de una
dimensión, los cuales son relativamente menos eficientes que los apuntadores.
Pruebas unitarias.
Se analiza si efectivamente se está generando la matriz con quien se desea trabajar para la
realización de un proceso, tal es el caso de líneas de código individuales analizadas una por una
en Matlab como en la ilustración 9.
109
ANEXO 5
Pruebas de integración.
Interacción entre bloques de código, ilustración 10.
Se construyeron inicialmente arreglos matriciales bidimensionales de 3x3 elementos para
almacenar valores numéricos en cada uno de sus componentes, dichos parámetros son
necesarios para realizar el procedimiento de resalte de bordes.
El siguiente bloque del código permite que en caso de que los elementos del primer bloque
contengan valores numéricos aleatorios en sus componentes (basura), generados desde su
Ilustración 9, prueba de matrices, una por una ¿realmente tiene los valores apropiados?
Ilustración 10, integración entre bloques de código.
110
declaración como variables se supriman y cambien su contenido a valores numéricos iguales a
“cero”, lo cual permitirá que se eviten errores de tipos de datos, ya sean enteros (sin números
decimales) o flotantes (con números decimales).
El surgimiento del problema más reciente tiene que ver con la prueba de la integración
de un programa reciclado, el cual convierte a escala de grises una imagen de color, el cual
mediante un ciclo iterativo permite desplegar una secuencia de imágenes sucesivas las cuales
parecen ser de video.
El objetivo de unir un programa con otro es resaltar bordes en una sucesión de imágenes, de
manera que parezca que se está viendo un video de bordes como si se estuviese grabando
video resaltando bordes exclusivamente.
El error reside en que el programa despliega un error que impide ver lo antes mencionado tal y
como lo hace el programa reciclado que convierte del espacio de colores a escala de grises.
“En pruebas anteriores no se sabía cuál era el error que impedía ver la grabación de video
con el resalte de bordes, ahora se sabe que el problema estaba directamente relacionado con
la declaración apropiada de las operaciones matemáticas que ofrece la librería <math.h>,
perteneciente a C++, específicamente la declaración de la función pow( ) y sqrt( )”.
Error en cuestión ilustración 11.
Ilustración 11, código Diagrama error.
El proceso es iterativo, de tal manera que la retroalimentación hasta el paso de la construcción
de software podría llevar a la solución del problema aquí presentado.
Causa error detectado: “Declaración inadecuada de la función pow( )”.
CONVERSIÓN
ESCALA DE GRISES
RESALTE DE
BORDES
ENTRADA “IMAGEN CAPTURADA”
SALIDA “NO SE MUESTRA
NINGUNA IMAGEN”
111
Pruebas sistemáticas.
Toman en consideración un todo que
corresponde directamente a códigos
ya funcionales completos.
La ejecución de códigos en Matlab,
permite obtener resultados mediante
diferentes operadores para el resalte
de bordes, tal es el caso de la siguiente
Ilustración.
En esta imagen se observan los resultados obtenidos desde un principio con Matlab al aplicar
operadores para el realce de bordes, donde se observa que las líneas pueden sobresalir ya sea
horizontal o verticalmente, que es lo que se desea haga el sistema.
La respuesta en tiempo de Matlab suele ser lenta de tal
forma que a pesar de que el realce de bordes buscado se
efectúa correctamente, con la desventaja de que el
programa no posee la velocidad de procesamiento
requerida.
Como prueba sistemática el resultado es bastante bueno
pero bajo la restricción antes mencionada.
Se propone un código similar sin emplear funciones de
Matlab con el que se tiene lo siguiente, Ilustración 13.
Como se aprecia en la Ilustración 13, el resultado es bastante aceptable, con la restricción de
que el tiempo de procesamiento es superior a 10 segundos para una PC, lo cual implica una
fuerte desventaja si se desea procesar las imágenes en tiempo real.
Ilustración 12, aplicación de realzadores de bordes con funciones de Matlab.
Ilustración 13 Resultado realzar bordes sin funciones de Matlab.
112
La prueba sistemática que ofrece el código que despliega la imagen anterior resulta ser
aceptable, incluso en el número de líneas de código, por tal motivo se realizan más pruebas
empleando otro lenguaje de programación (C++).
El entorno parece ser no tan complejo y refleja bondades en su uso para la codificación, el
siguiente entorno es el referente a linux y se basa en C++.
El entorno para codificación antes mostrado es similar al de Matlab, con ciertas diferencias,
aunque la principal diferencia en cuanto a desarrollo de código reside directamente en la
complejidad que implica C++, esto debido a que C no posee tantas funciones al igual que
Matlab, por lo que la programación se vuelve
más compleja y dimensionalmente más grande.
La ventaja de emplear lenguaje c se refleja
principalmente en la velocidad de
procesamiento, el cual es bastante aceptable,
el procesamiento es incluso menor a 2
segundos, lo cual difiere enormemente con
Matlab, el resultado de realizar un código
equivalente de C a Matlab en el realce de
bordes es el siguiente Ilustración 15.
A pesar de obtener resultados bastante
similares a Matlab, el procesamiento es mucho
más rápido y eficiente, otorgándonos como
resultado la prueba sistemática que el lenguaje de programación más apropiado para el
sistema de navegación es lenguaje C, si es que se desea obtener un respuesta lo
Ilustración 14, entorno gráfico para codificación en C++.
Ilustración 15, resultado equivalente trasladado de Matlab a C++.
113
suficientemente rápida para realizar la acción que fungirá como colaboradora en términos de
seguridad.
El principal problema encontrado al ejecutar este programa en la grabación de video reside en
que las operaciones matemáticas de potencias fraccionarias y el llamado a funciones
encontradas en la librería <math.h> de C++ hacen que el procesamiento sea demasiado y por
tal motivo la ejecución del programa sea ineficiente para los fines establecidos.
La solución propuesta a este problema está enfocada directamente a la omisión de
operaciones que impliquen un trabajo excesivo para el procesamiento (multiplicación,
elevación a potencias), por tal razón se ha decidido implementar un filtro que de igual forma
realce bordes, pero que ahora solo el procesamiento se base en la simple detección del pixel
con el menor valor en una escala de 0 a 255, de tal forma que estos valores son los manejados
en una escala de grises.
Ventajas de emplear filtro por detección de mínimos:
Las operaciones matemáticas se ven reducidas significativamente al omitir
multiplicaciones y elevación a potencias por simples comparaciones entre variables (el
tiempo de procesamiento disminuye y el proceso es más eficiente).
Desventajas de emplear filtro por detección de mínimos:
La nitidez se pierde significativamente (se pierden algunos detalles de la imagen que
con el filtro gradiente de Sobel si se veían), se modifica una buena parte de la
estructura del programa en general.
Resultados obtenidos al emplear esta nueva técnica para el realce de bordes.
Las pruebas realizadas con éste filtro
arrojan información relevante, esto gracias
a que la detección de bordes es bastante
aceptable aunque la resolución no sea la
mejor, dichos resultados se muestran en la
Ilustración 16.
Ilustración 16, resultado detección de bordes empleando filtro por detección de mínimos.
114
Como se aprecia en la Ilustración 16 la detección de bordes es significativamente buena, de
manera que incluso se pueden ver los bordes
característicos en el ojo de una persona.
Por otra parte una segunda prueba nos
permite ver el buen desempeño para
imágenes que de igual forma en la que los
bordes definen perfectamente distintas
formas, Ilustración 18.
El tiempo de procesamiento en general no es
visible propiamente en imágenes, pero a
pesar de ello es claro que la nitidez de las
imágenes no es tan buena como con el filtro
de Sobel, pero que de igual forma el objetivo
de resaltar bordes está vigente y la nueva
aplicación es buena.
Es posible destacar que aunque se perdió
cierta nitidez en la imagen, pero se ganó
un tiempo de procesamiento relevante
que es bastante útil e incluso es el objetivo
ponderado más importante en los
objetivos específicos del sistema en
general, ya que se desea contribuir con la
seguridad en el transporte de pasajeros.
Se han efectuado pruebas en dos
máquinas distintas en cuanto a
rendimiento, los resultados al binarizar las
imágenes anteriormente mostradas son los
siguientes: Ilustración 20.
Se ha visto que el buen procesamiento de un
programa es bastante notorio si se efectúa en una
máquina con más recursos.
Ilustración 18, resultado prueba 2, detección de bordes empleando filtro por detección de mínimos.
Ilustración 19 Resultados binarización de bordes con una máquina de bajos recursos.
Ilustración 20, resultados binarización de bordes con una máquina con más recursos.
115
ANEXO 6
Fragmentos de códigos empleados “Sistema ANC”.
En la ilustración 21 se muestra un código opcional para comunicación mediante puerto
paralelo elaborado en C++ el cual fue desechado debido a la no compatibilidad con
Monodevelop (ambiente de desarrollo lenguaje C) en el cual se desarrolló el sistema de
navegación.
Ilustración 21, código generado para configuración de puerto paralelo en C.
116
La siguiente ilustración indica la forma en la que se comentaba y se declaraban variables en
código con base en metodologías de desarrollo de software.
Ilustración 22, metodología de declaración de variables en código fuente sistema ANC.
El siguiente código fue elaborado desde cero en Matlab para la simulación de mediciones con
la implementación del láser proyectado sobre objetos para medir distancia.
Ilustración 23, código para adquisición de imágenes y pruebas de mediciones con láser.
117
Codificación en C desechada para la adquisición de valores de píxeles por capas en los distintos
modelos de color que se trabajaron en el sistema de navegación.
Ilustración 24, código para adquisición de valores de píxeles.
En el siguiente código extraído del código fuente final del sistema de navegación se muestra
una simple conversión de radianes a grados para trabajar de una forma más sencilla los
ángulos en las pendientes halladas de las líneas en carretera así como su despliegue en
pantalla para confirmar resultados.
Ilustración 25, conversión de radianes a grados.
Declaración de apuntadores a imágenes empleadas en el sistema de navegación para el
procesamiento de líneas en carretera.
Ilustración 26, apuntadores a imágenes.
118
Como se observa en la ilustración 27, la limpieza de variables fue bastante útil para el desecho
de “basura” generada aleatoriamente cuando solamente se declaran variables. Las siguientes
líneas de código facilitaron la limpieza de variables utilizadas.
Ilustración 27, limpieza variables empleada para arreglos de una dimensión.
Eliminación de imágenes no necesarias en el proceso de segmentación del sistema de
navegación en carretera.
Ilustración 28, omisión de imágenes.
Declaración en cabecera del programa principal generada por default por el compilador
utilizado para el desarrollo del sistema.
Ilustración 29, primera línea de código generada por el compilador “using namespace”.
La última línea en el siguiente código muestra comentada la función del filtro Canny debido a
la generación de realce de bordes no deseado por lo que solo se realizaron pruebas de
eficiencia con ésta función propia de las librerías de opencv.
Ilustración 30, uso de la función cvCanny para pruebas de eficiencia en realce de bordes.
119
Configuración para abortar todos los procesos del sistema de navegación en carretera
mediante la tecla “Esc” del teclado principal, dicha tarea fue apoyada mediante funciones de
opencv y evidentemente también del código ASCII para definir los valores de cada tecla.
Ilustración 31, salida del sistema de navegación mediante la te tecla “Esc”.
Las siguientes ecuaciones codificadas en C fueron sumamente útiles para hallar la pendiente
de las rectas que se originan en carretera. El código de la ilustración 32 también muestra la
acción a realizar en caso de encontrarse con una indefinición o definición entre cero para no
afectar el funcionamiento del sistema.
Ilustración 32, ecuaciones para el cálculo de pendiente en lenguaje C.
120
Referencias
1. Geografia, Instituto Nacional De Estadistica y. Sintesis Metodologica de la Estadistica de Accidentes
De Transito Terrestre en Zonas Urbanas y Suburbanas (ATUS). Aguascalinetes Ags. : Instituto Nacional
De Estadistica y Geografia, 2009.
2. Luis Alvaro Moreno. Banco Interamericano de desarrollo. [En línea] 19 de Marzo de 2010. [Citado
el: 13 de Marzo de 2012.] http://www.iadb.org/es/noticias/comunicados-de-prensa/2010-03-