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

Objetivos Primarios Objetivos Secundarios

23

OBJETIVOS

ESPECIFICOS

(PRIMARIOS)

OPCIÓN 1 OPCIÓN 2 OPCIÓN 3

DETECCIÓN DE

LÍNEAS

CÁMARA

DETECCION DE

DISTANCIA

DETECCION DE

OBSTACULOS

CLASIFICACIÓN DE

LUMINOSIDAD

Sensor infrarrojo Detector Laser Sensor de video

Sensor de video Detector Laser Sensor Ultrasónico

Fotorresistencia Sensor Fotodiodo Sensor infrarrojo

Laser Cámara Ultrasónicos

Diagrama Morfológico

24

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

31

4.1 Fase Inicio del Proyecto

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:

Fórmula 5 Magnitud de la gradiente Sobel.

a) b)

55

Simulación en Matlab del filtro Sobel

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.

Muestreo de valores de pixeles de

bordes

Histograma normalizado

Obtención de datos en menos de 1

Obtención de datos por cámara

Utilizar la imagen de escala de bordes

Simulación en Matlab

Selección de detector de bordes

Diagrama de Flujo

66

6.2.2 Fase de Especificaciones

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

69

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-

19/seguridad-vial-de-america-latina-banco-interamericano-de-desarrollo-reunion-anual-

2010,6707.html.

3. Norte, Estadistica de Transporte de America del. Estadistica de Transporte de America del Norte.

[En línea] 1990-2010. http://nats.sct.gob.mx/nats/sys/tables.jsp?i=2&id=12.

4. Castañeda, Ramón Cerón. Transporte Informativo . Radiografía de accidentalidad en el

autotransporte de México. [En línea] 11 de Septiembre de 2008. [Citado el: 13 de Marzo de 2012.]

http://transporteinformativo.com/de-buena-fuente/radiografia-de-la-accidentalidad-en-el-

autotransporte-de-mexico.

5. León, Gobierno del Estado de Nuevo. Programa Sectorial de Vialidad y Transporte. www.nl.gob.mx.

[En línea] 2009. [Citado el: 13 de Marzo de 2012.]

http://www.nl.gob.mx/pics/pages/p_vialidad_transporte_base/vialidad_transporte.pdf.

6. POLTOLAREK, AARÓN DYCHTER. Secretaria de Comunicaciones y Transportes. [En línea] 8 de Abril

de 2005. [Citado el: 2012 de Marzo de 13.] http://www.sct.gob.mx/uploads/media/17_NOM-034-SCT-

2-2003_01.pdf.

7. CAPUFE Caminos y Puentes Federales. Recomendaciones Antes de Viajar en Carrtera. [En línea]

[Citado el: 13 de Marzo de 2012.]

http://www.capufe.gob.mx/portal/wwwCapufe/Inicio/RecomAntesViajarPorCarretera.pdf.

8. Mateos, Manuel. www.manuelmateos.info. [En línea] 2006. [Citado el: 13 de Marzo de 2012.]

http://www.manuelmateos.info/menu/trafico/257.propuestas.m.mateos.pdf.

9. Alcantarilla, Pablo Fernandez. ROBESAFE. [En línea] 2008. [Citado el: 2012 de Marzo de 13.]

http://www.robesafe.com/personal/pablo.alcantarilla/papers/Alcantarilla08pfm.pdf.

10. CINVESTAV. meca.cinvestav. [En línea] [Citado el: 2012 de Marzo de 13.]

http://www.meca.cinvestav.mx/quees.html.

121

Bibliografía

1.- Luis Joyanes Aguilar, Fundamentos de Programación, Mc Graw-Hill, México, 2007.

2.- Mario Ignacio Chacón M., Procesamiento Digital de Imágenes, Ed Trillas, México, 2007.

3.- Rafael C. González, Richard E. Woods, Tratamiento Digital de Imágenes, Ed. Addison Wesley,

España, 1993.

4.- Rosalía Díaz-Barriga Martínez, Redacción Técnica, Instituto Politécnico Nacional, México, 2001.