Desarrollo de una tiflo-aplicación Android para el reconocimiento de códigos QR

Desarrollo de una tiflo-aplicación Android para el reconocimiento de códigos QR Trabajo Fin de Grado 21/22 Development of an Android tiflo-application for QR code recognition Autores Mónica Gabriela Bogado Villalba Antonio Lucas Simón Miguel Mordillo Mendoza Pablo Ortuño Ibáñez Directores María Guijarro Mata-García Joaquín Recas Piorno Grado en Ingeniería del Software Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid Desarrollo de una tiflo-aplicación Android para el reconocimiento de códigos QR Trabajo Fin de Grado del Curso 2021/2022 Development of an Android tiflo-application for QR code recognition Autores Mónica Gabriela Bogado Villalba Antonio Lucas Simón Miguel Mordillo Mendoza Pablo Ortuño Ibáñez Directores María Guijarro Mata-García Joaquín Recas Piorno Grado en Ingeniería del Software Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid 14 de septiembre de 2022 A a nuestros tutores y a la ONCE por hacernos partícipes de este proyecto. A David Peña por aportarnos experiencia en desarrollos accesibles. A Cecilia y Jesús por sus consejos y su inestimable ayuda. A todos los amigos y familiares que nos han apoyado. Resumen Este trabajo de fin de grado tiene como objetivo el desarrollo de una aplicación Android accesible para la lectura de códigos QR, que sea capaz de reconocer partes del QR o QRs no legibles e indicar al usuario como mover su dispositivo con el fin de detectar todo el QR y decodificarlo. Actualmente no se ha desarrollado ninguna aplicación con esta funcionalidad y, por lo tanto, el uso de códigos QR queda muy limitado en personas con discapacidad visual. Con la pandemia global, causada por la COVID-19 vivida en los últimos años, ha sido necesaria la aplicación de medidas excepcionales en todo tipo de establecimientos y servicios centradas en evitar el contacto, siendo una de ellas la sustitución de numerosos textos físicos por equivalentes digitales. Estos textos son accedidos normalmente mediante códigos QR, que al depender principalmente de las referencias visuales que identifique la persona, aquellas con discapacidad visual tendrán dificultades para su uso. El desarrollo exponencial de la tecnología en los últimos años, adquiriendo cada vez más importancia en nuestras vidas, conlleva la necesidad de seguir unas pautas de accesibilidad para que pueda estar disponible a la mayor cantidad de gente posible. El desarrollo de esta aplicación se hace a través de Android Studio, con el lenguaje de programación Java y con el uso de la inteligencia artificial, más específicamente visión por computador y aprendizaje automático. Palabras clave 1. QR 2. Lector de códigos 3. Accesibilidad 4. Visión por computador 5. Aprendizaje automático vi Resumen vii 6. Aprendizaje profundo 7. Escáner 8. Algoritmo 9. Patrones 10. Redes neuronales 11. Android 12. ONCE 13. Talkback Summary This project’s objective is the development of an accessible Android application for QR code reading , which will be able to recognize parts of the QR code or a not readable QR code and guide the user on how to move their device in order to detect the entire QR code and decode it. Currently no application has been developed with this functionality and therefore the use of QR codes is very limited for the visually impaired. With the global pandemic caused by COVID-19 in recent years, it has been necessary to implement exceptional measures in all types of establishments and services focused on avoiding contact, one of them being the replacement of numerous physical texts by digital equivalents. These texts are normally accessed through QR codes, which, depending mainly on the visual references identified by the person, are difficult to use for the visually impaired. The exponential development of technology in recent years, acquiring more and more importance in our lives, brings with it the need to follow accessibility guidelines so that it can be available to as many people as possible. The development of this application is done through Android Studio, with the Java programming language and with the use of artificial intelligence, more specifically computer vision and machine learning. Keywords 1. QR 2. Code reader 3. Accessibility 4. Computer vision 5. Machine learning 6. Deep learning 7. Scanner viii Summary ix 8. Algorithm 9. Patterns 10. Neural network 11. Android 12. ONCE 13. Talkback Capítulo 1 Introducción En esta introducción se explican los antecedentes necesarios para el entendimiento del proyecto, como la accesibilidad, los códigos QR, el aprendizaje automático y la visión por computador. A partir de ahí, se exponen nuestros objetivos y motivación. 1.1. Antecedentes 1.1.1. Accesibilidad Una tecnología se denomina accesible cuando cualquier persona puede utilizarla de manera fluida y aprovechar todas sus funcionalidades, sin ningún tipo de discriminación según sus capacidades o cualidades. De aquí surge el término “Diseño para todos” [1]. La accesibilidad es un término reciente, hasta el siglo XX se disponía de pocas adaptaciones para que personas con discapacidad pudieran realizar las mismas tareas que personas con otras características o capacidades. En este siglo se empezaron a adaptar los diseños a las personas con discapacidad, pero este concepto no coincide con el que mencionamos previamente [2]. En España una de las primeras muestras del concepto de accesibilidad se encuentra en la constitución española de 1978, cuando recoge como derechos fundamentales la formación y el desarrollo del individuo, pues es necesario que todos los medios para conseguirlos sean accesibles [3]. En el ámbito del software, la accesibilidad está orientada a la usabilidad, las primeras pautas de accesibilidad software fueron las ”Directrices de Accesibilidad para el Contenido Web (WCAG)” creadas por la ”World Wide Web Consortium (W3C)” en 1995. Esta guía representa el primer esfuerzo por parte de una entidad en crear una aplicación accesible real y se encuentra en 1 1.1. Antecedentes 2 constante evolución. A partir de la versión 2.0 de WCAG, se crearon cuatro principios fundamentales para los desarrollos web accesibles, estos definen que una aplicación web debe ser Perceptible, Operable, Comprensible y Robusta. Estos, a su vez, están subdivididos en distintas normas bien regladas y especificadas. También compone de un sistema de evaluación con tres niveles, A, AA y AAA, ordenados de menos a más accesibles, según la cantidad de normas que cumplan en la última versión de este documento [4]. La normativa actual sobre accesibilidad para el software en general (no solo web) es la ISO 9241-171, que se encuentra en varios idiomas. Esta la siguen los principales sistemas operativos de usuario, de Microsoft, Google y Apple. Estas compañías tienen en cuenta que su software nativo ha de presentar un diseño accesible, así como la compatibilidad con tecnologías auxiliares como los lectores de pantalla. Esta normativa también debería cumplirse en las aplicaciones de estos sistemas operativos. En Europa y EEUU, las entidades públicas y algunas organizaciones tienen la obligatoriedad de cumplir una legislación específica para que sus contenidos sean accesibles, en España concretamente es el “Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público” [4]. 1.1.2. Códigos QR El código QR es un tipo de código de barras en 2D, una matriz de puntos (por lo general en blanco y negro), que consiste en un array de módulos (puntos) puestos de manera contigua en los que se guarda la información [5]. Algunas de las características que hacen ”especiales” a los códigos QR son la gran capacidad de datos que pueden almacenar (hasta 23,648 bits con la última versión), su resistencia a los daños (o manchas) y la lectura en 360° (desde cualquier dirección) [6]. Un código QR funciona de manera similar a un código de barras. Es una imagen escaneable (ya sea con un escáner, smartphone, etc.) de manera instantánea a través de una cámara. Cada módulo representa una pequeña pieza de información que, al escanearlo, se traduce en algo que los seres humanos podemos entender. Los datos en un código QR pueden ser numéricos, alfanuméricos, binarios o Kanji1[5]. 1Kanji es una forma de caracteres chinos que se utilizan en el sistema de escritura japonés moderno. 1.1. Antecedentes 3 Figura 1.1: Partes del código QR En la figura 1.1 vemos las distintas partes de un código QR [5]: En azul,Position Detection Patterns oFinder Patterns, 3 cuadrículas en las esquinas superiores izquierda y derecha e inferior izquierda del código. Estos sirven para informar al escáner la posición y cuáles son los bordes. En naranja,Timing Patterns, son secuencias de módulos blancos y negros, puestas de manera que sirven para indicar dónde están las filas y las columnas del resto de módulos blancos y negros. En rojo,Format Information, contiene información sobre los niveles de corrección de errores y el patrón de máscara que se ha utilizado. En verde, las áreas que representan la versión de código QR. En amarillo,Alignment Pattern, una cuadricula fija (similar al Finder Patterns) que permite corregir cualquier distorsión en la imagen y asegurar una alineación más precisa. 1.1.3. Aprendizaje automático: Deep Learning El aprendizaje automático (AA), del inglés Machine Learning, es una rama de la inteligencia artificial especializada en el reconocimiento de patrones y aplicable a cualquier tipología de datos. El factor diferencial del AA respecto otras técnicas de inteligencia artificial, es que, gracias a los algoritmos que utiliza, puede obtener inferencias y reconocer patrones con un nuevo conjunto de datos distinto, generando unas reglas que permitan reconocer esos datos sin modificar la programación de los algoritmos utilizados [7]. 1.2. Objetivos y motivación 4 El campo del AA abarca distintas subramas, pero en este proyecto se ha aplicado la rama del aprendizaje profundo (Deep Learning), que se basa en el modelo de redes neuronales. Es importante aclarar que, para que un modelo de aprendizaje profundo funcione correctamente, hay que facilitarle múltiples datos identificativos [7]. 1.1.4. Visión por computador La visión por computador [8] es una rama y/o campo de la inteligencia artificial que permite a un sistema obtener información relevante a partir de imágenes y vídeos, con el fin de realizar acciones o recomendaciones basadas en toda la información obtenida. Las aplicaciones que se utilizan hoy en día demuestran cuán importante es la visión por computador para los negocios, el ocio, el transporte, la atención sanitaria y, en general, para la vida cotidiana. Un factor clave a tener en cuenta en el crecimiento de este campo es la gran cantidad de información visual que fluye desde que existen los teléfonos inteligentes (smartphones), redes sociales, sistemas de seguridad, cámaras de tráfico y otros, ya que estos datos desempeñan un papel fundamental en casi todas las operaciones de las industrias existentes. Algunos ejemplos de uso de la visión por computador son: Clasificación de imágenes: capaz de clasificar una imagen completa asociándola a una clase única, por ejemplo flores. Detección de objetos: permite clasificar varios objetos dentro de una imagen, así como agruparlos, por ejemplo: rosas y margaritas. 1.2. Objetivos y motivación Los escáneres de códigos QR actuales requieren enfocar todas las marcas que contiene y, en caso de que no se detecte el código completo y legible, el escáner no devuelve ningún tipo de información ni indicación. Al requerir del correcto posicionado del código, sin ninguna indicación aparte de las referencias visuales que pueda observar el usuario, la lectura de un QR se vuelve un proceso no accesible que, con la expansión de su uso en los últimos años, excluye a una parte de la población en cada vez más situaciones. El objetivo de este proyecto es el diseño y la implementación de una aplicación capaz de identificar QRs (sean posibles de decodificar o no) o QRs parciales (fragmentos de QR). Al reconocerlos debe guiar al usuario final en 1.2. Objetivos y motivación 5 la correcta lectura del mismo, cumpliendo los requisitos de accesibilidad. La aplicación será desarrollada para la plataforma móvil Android de manera nativa, utilizando Android Studio y el lenguaje Java. Para el desarrollo del algoritmo se investigarán dos metodologías de reconocimiento de imágenes, en las cuales se probarán distintas técnicas: Reconocimiento de imágenes mediante patrones. Reconocimiento de imágenes con aprendizaje profundo. Vamos a investigar estos dos métodos, para evaluar cuál de las dos es más funcional en nuestro caso de uso particular. Otros aspectos a tener en cuenta serán la escalabilidad y el bajo acoplamiento, entendiendo esto como la facilidad de mejorar el algoritmo de reconocimiento de QRs, así como la comodidad para exportarlo a otras plataformas de desarrollo como iOS [9]. Capítulo 2 Estado del arte En el ámbito del desarrollo móvil, siendo este una herramienta de uso diario para la mayoría de personas, en España, las primeras aplicaciones accesibles surgen alrededor de 2015. Este acontecimiento se origina con una aplicación de banca móvil accesible creada por ABANCA [10] y la primera app de turismo accesible para la localidad de Segovia [11]. Estas aplicaciones han teniendo influencia en el origen del decreto sobre desarrollos móviles, que tenemos actualmente en nuestro país. En cuanto a la lectura de códigos QR de manera accesible, a día de hoy no existen alternativas a la aplicación que planteamos. Sin embargo, vamos a estudiar otros acercamientos a problemas similares, bien implementando nuevas tecnologías de etiquetas codificadas, o intentando facilitar la lectura de estas. 2.1. ScanLife (Barcode & QR Reader) ScanLife fue lanzado por Sprint yScanBuy en 2008 para leer códigos de barras u otros códigos bidimensionales desde el móvil. La idea era acceder fácilmente a diversos medios que incluirían información extra, como periódicos que incluyeran código en dos dimensiones con datos adicionales o información extra en un cartel del cine. A día de hoy permite escanear códigos de barras, códigos en formato EZcode, Datamatrix o QR de un producto (todos los tipos admitidos en la figura 2.3), para descubrir información adicional e interactuar con la marca y los usuarios. 6 2.2. NaviLens y las ddTags 7 Figura 2.1: Tipos de códigos bidimensionales admitidos por ScanLife Para obtener la información del producto, así como precios de distintos proveedores, basta con leer mediante la aplicación alguno de estos códigos en un producto que los contenga. Hace uso de la base de datos de ScanBuy para mostrar opiniones de otros usuarios, así como posibles ofertas y cupones relacionados [12]. Esto puede ser muy útil para personas con discapacidad visual a la hora de identificar o comparar productos en las tiendas o supermercados, pues no suelen incluir braille en los mismos. Este asistente personal facilitará información sobre el nombre y la descripción del producto, así como ingredientes o fecha de caducidad, pudiendo ser dispuesta de manera accesible. La aplicación también guarda un historial de las lecturas realizadas y ofrece la posibilidad de crear una lista de favoritos para poder acceder más rápidamente a la información, sin tener que repetir el proceso de volver a leer el código. Si bien es muy útil tras haber localizado el código en cuestión, identificar dichos códigos no es tarea sencilla para todo el mundo (por ejemplo, personas con discapacidad visual), al variar su localización con cada producto e incluso con cada marca comercial. Además estos códigos requieren ser enfocados por la cámara, lo que resulta imposible sin indicaciones de donde se encuentran, haciendo este un sistema que no cumple con los requisitos de accesibilidad. 2.2. NaviLens y las ddTags NaviLens es una aplicación que permite la creación y lectura accesible de etiquetas conocidas como ”ddTags”, cuyo funcionamiento se explicará a continuación. 2.2. NaviLens y las ddTags 8 2.2.1. ddTags La empresa Neosistec presentó en 2018 en el Mobile World Congress (tras probarla en 2017 en el congreso de tecnología de accesibilidad TifloInnova), una nueva tecnología de codificación bidimensional: las ddTags [13]. En la figura 2.2 podemos ver un ejemplo de este tipos de códigos. Figura 2.2: ddTag en un lugar público Las ddTags pretenden sustituir a otros formatos BIDI, como los QR o los códigos de barras (comparación en la figura 2.3) que, pese a la gran información que ofrecen, son complicados de leer, especialmente para personas invidentes. Figura 2.3: Diferencia entre QR y ddTag Con sus etiquetas basadas en colores, las ddTags permiten superar eficientemente a los anteriormente mencionados, aportando las siguientes ventajas [14]: Mayor distancia de lectura (12 veces superior a la de los QR). Mayor densidad de código, permitiendo reducir el tamaño de las etiquetas. 2.2. NaviLens y las ddTags 9 Facilidad de lectura, al ser posible a ángulos de hasta 160º, condiciones pobres de iluminación o lectura sin necesidad de enfoque. Mayor velocidad de lectura basada en visión artificial. Lectura múltiple de hasta 200 códigos por imagen. Capacidad de detectar la distancia hasta la etiqueta (en centímetros y pulgadas). La empresa inicialmente pretendía estandarizar el uso de las ddTags para servir de ayuda a personas con dificultades de visión a ubicarse en lugares públicos, pero, viendo su gran potencial, se está estudiando la posibilidad de utilizarlas en otros ámbitos. Entre ellos, la optimización del inventario en almacenes (identificando velozmente el contenido gracias a la lectura múltiple y su gran velocidad de lectura) o dar información sobre horarios en transportes públicos. Dado que este proyecto está centrado en la lectura accesible de códigos QR, se ha realizado un análisis de la aplicación móvil que implementa estas etiquetas para dicho propósito: NaviLens. 2.2.2. NaviLens Esta aplicación [15], como ya hemos indicado antes, será la encargada de identificar y leer las ddTags. Con solo apuntar el móvil a donde se pueda encontrar una, hasta a 15 metros de distancia, la aplicación la detectará, permitiendo leer su contenido y la información sobre su posición. Una de sus funcionalidades más interesantes es, una vez detectada la ddTag, guiar al usuario hasta la misma, indicando auditivamente si este se está desviando del camino y la distancia a la que se encuentra. Esto sería de gran utilidad en caso de ser un estándar para lugares públicos, pudiendo detectar fácilmente paradas de bus, monumentos emblemáticos, etc. A elección del usuario esto puede ser, bien mediante pitidos, variando frecuencia y tono dependiendo de hacia donde se tenga que mover, o bien, mediante instrucciones directas (delante, derecha, arriba o abajo). Esto se complementa muy bien con el modo ”Magnet”, que una vez leída la etiqueta, guiará al usuario hasta ella, aunque ésta salga del campo de visión de la cámara. Complementado con una interfaz sencilla, como observamos en la figura 2.4, da como resultado una aplicación fácil de usar y con gran funcionalidad. 2.2. NaviLens y las ddTags 10 Figura 2.4: Interfaz de usuario de NaviLens La aplicación permite a su usuario generar ddTags personalizadas asociadas a un texto para su posterior impresión, de esta manera las puede ubicar en el lugar que precise para su lectura. Un caso de uso sería situar las etiquetas en los muebles de una habitación para conocer información sobre su entorno a través de la cámara del dispositivo móvil: datos como distancia, posición y otra información descriptiva. Otra utilidad es etiquetar objetos similares al tacto para diferenciarlos, como por ejemplo, botes de especias. Está claro que la aplicación tiene gran potencial, pero para resultar útil, el formato que utiliza tendría que estar estandarizado. Este proyecto surgió en 2017 y si bien parece el futuro de la codificación bidimensional, a día de hoy se sigue manteniendo el formato QR, que además se ha extendido aún más con motivo del Covid, para facilitar el acceso a información digitalmente. 3.1. Reconocimiento de imágenes mediante patrones 17 suma de las segundas derivadas y se calcula como la suma de las diferencias sobre los píxeles cercanos al píxel actual: ∆f=∂2f ∂x2+∂2f ∂y2 Es importante que la imagen no contenga ruido, pues el método no distingue entre el ruido y los bordes reales. Por lo que el método indicaría bordes dónde no existen. La figura 3.4 muestra la imagen tras aplicar la función de Laplace. Figura 3.4: Imagen tras haber aplicado Laplaciano 3.1.1.4. Obtención de contornos OpenCV dispone de métodos que encuentran contornos [23]. Los contornos quedan definidos como líneas de puntos contiguas de píxeles, del mismo color o intensidad. El método guarda cada punto de cada contorno para poder hacer operaciones sobre los contornos, como calcular el área o calcular el centro. 3.1. Reconocimiento de imágenes mediante patrones 18 La figura 3.5 muestra la imagen base con los contornos encontrados en la figura 3.1 dibujados por encima. Figura 3.5: Imagen base con contornos encontrados por encima 3.1.1.5. Localización de centros de contornos mediante momentos Los contornos encontrados tienen momentos [24]. Los momentos de una imagen en visión por computador son las medias de las intensidades de los píxeles según coordenadas. Los momentos Mij se calculan: Mij =X xX y xiyjI(x, y) Siendo I(x,y) las intensidades de los píxeles en una imagen en blanco y negro. Dividiendo lo anterior entre: X xX y I(x, y) Obtenemos los centros geométricos de los contornos: {¯x, ¯y}=nM10 M00 ,M01 M00 o 3.1. Reconocimiento de imágenes mediante patrones 19 Una vez obtenidos los centros de los contornos de la imagen, se buscan centros que estén compartidos por 3 o más contornos. En la imagen preprocesada, los únicos casos en los que 3 o más contornos comparten el mismo centro, son las apariciones de los Finder Pattern del código QR. 3.1.1.6. Localización en pantalla Para indicar al usuario hacia dónde debe dirigir el dispositivo, se divide la pantalla en cuatro mitades/cuadrantes. Así para una imagen de 1280x720px habrá cuatro cuadrantes de 640x360px. Obtenidos estos datos junto con las coordenadas xeydel centro del Finder Pattern se conoce en qué cuadrante se encuentra de la siguiente manera (siendo width el ancho de la imagen y height el alto de la imagen): Si x < width 2∧y < height 2, entonces se encuentra en el cuadrante A. Si x > width 2∧y < height 2, entonces se encuentra en el cuadrante B. Si x < width 2∧y > height 2, entonces se encuentra en el cuadrante C. Si x > width 2∧y > height 2, entonces se encuentra en el cuadrante D. Conociendo el cuadrante donde se ha detectado se informa al usuario la dirección teniendo en cuenta lo siguiente: Si se encuentra en el Cuadrante A, debe mover el móvil hacia la parte superior izquierda. Si se encuentra en el Cuadrante B, debe mover el móvil hacia la parte superior derecha. Si se encuentra en el Cuadrante C, debe mover el móvil hacia la parte inferior izquierda. Si se encuentra en el Cuadrante D, debe mover el móvil hacia la parte inferior derecha. Los cuadrantes indican las posiciones en el dispositivo mostradas en la figura 3.6. 3.1. Reconocimiento de imágenes mediante patrones 20 Figura 3.6: Pantalla de móvil divido en 4 cuadrantes Esta manera de indicar tiene deficiencias. Suponiendo que se ha detectado un Finder Pattern en la zona A, de la figura 3.6, el algoritmo estaría dirigiendo al usuario en la dirección superior izquierda llevándolo al cuadrante D, una vez detectado en este cuadrante, lo dirigirá hacia la dirección inferior derecha devolviéndole al cuadrante A, entrando en bucle. Además, en el caso de detectar 2 o 3 Finder Patterns en el centro de la pantalla, daría múltiples direcciones simultáneamente, confundiendo al usuario. En la siguiente iteración se resuelven estos problemas. En la figura 3.7 se muestran los Finder Pattern encontrados y la dirección con respecto al centro de la imagen. 3.1. Reconocimiento de imágenes mediante patrones 21 Figura 3.7: Imagen base con Finder Pattern encontrados mediante búsqueda de centros concéntricos 3.1.1.7. Implementación en Android Tras la demo satisfactoria del funcionamiento del algoritmo en Python, se procedió a implementarlo en Java [25] para su funcionamiento en una aplicación Android [26]. Una de las razones más importantes para elegir la librería OpenCV fue la facilidad de transformar su código entre lenguajes de programación. Después de algunos días de pruebas e implementación no conseguimos que la aplicación tuviese un rendimiento similar al conseguido en Python. El principal problema era el uso del algoritmo Laplaciano para el preprocesamiento de la imagen, ya que provocaba que la aplicación funcionase a menos de 5 fotogramas por segundo, creando una experiencia de uso muy negativa. Después de ponderar las opciones disponibles, entre otras implementar el algoritmo en C++ [27] y aplicarlo a la aplicación Android (descartada por 3.1. Reconocimiento de imágenes mediante patrones 22 dificultades de interacción entre librerías), decidimos realizar el preprocesamiento de la imagen con otros métodos, mencionados a continuación. 3.1.2. Segunda iteración Tras los resultados fallidos en la implementación, investigamos otros métodos de preprocesar la imagen que tuviesen un rendimiento mejor en dispositivos menos potentes, como móviles. Estos métodos nuevos se detallan en las siguientes secciones. 3.1.2.1. Algoritmo de Canny Este algoritmo fue desarrollado por John F. Canny en 1986 [28]. El método Canny() de OpenCV realiza varios pasos para obtener una imagen ”limpia” y detectar los contornos [29]: 1. Reducción de ruido: reduce el ruido de la imagen utilizando el filtro Gaussiano de 3x3 (aunque también se puede utilizar uno de 5x5, en nuestro caso es demasiado agresivo, ya que cuanto más pequeña sea la matriz, menos detalle se pierde). 2. Gradiente de intensidad de la imagen: una vez reducido el ruido de la imagen, se calcula el gradiente de la intensidad de esta utilizando el operador Sobel. Este operador utiliza un kernel de 3x3 (uno para la imagen en dirección horizontal y otro para el vertical) para calcular aproximaciones a las primeras derivadas de cada punto en cada dirección. 3. Supresión no máxima: después de obtener el gradiente y la dirección, se recorre toda la imagen en búsqueda de cualquier píxel que no se encuentre dentro de los márgenes dados por los píxeles que tiene alrededor. 4. Umbral de histéresis (Thresholding): En este paso se descarta cualquier margen que no esté dentro de los valores proporcionados (min y max) por el parámetro y no estén conectados. Por lo tanto, cualquier borde con un gradiente mayor que el valor máximo dado se considera ”sure-edge” y los bordes con un gradiente menor que el valor mínimo dado se descartan. Los bordes con gradientes que se encuentran dentro del rango de valores dados se consideran bordes solo si están conectados a un sure-edge, sino se descartan. En la figura 3.8 se muestra como el borde B se descarta al no estar unido a ningún sure-edge. 3.1. Reconocimiento de imágenes mediante patrones 23 Figura 3.8: Imagen gráfica de líneas de contornos Finalizados estos pasos, el método devuelve la imagen obtenida en el último paso. Tras realizar varias pruebas se consideró esta como la mejor opción ya que proporcionaba un rendimiento óptimo frente al método laplaciano. 3.1.2.2. Reconocimiento de Finder Pattern mediante jerarquías de contornos. Las jerarquías [30] son contornos anidados uno dentro de otro, las contornos externos son los contornos ”padre” y los contornos anidados son contornos ”hijo”. Un Finder Pattern tiene la estructura indicada en la figura 3.9. En esta figura, A es el padre de B (o B es el hijo de A). 3.1. Reconocimiento de imágenes mediante patrones 24 Figura 3.9: Imagen de un Finder Pattern señalando contornos El método mencionado anteriormente que encuentra los contornos en OpenCV (findContours()) tiene un parámetro llamado hierarchy, que, según el modo indicado, devuelve un array con la siguiente información de cada contorno: Next: indica el siguiente contorno al mismo nivel. Previous: indica el contorno anterior al mismo nivel. FirstChild: indica el primer contorno hijo. Parent: indica el índice del array en donde se encuentra el contorno padre. En nuestro caso nos interesa utilizar el que ocupa la tercera posición, FirstChild. Este método recibe como parámetro 4 modos distintos de retorno: RETR_LIST: Es el más simple de los 4. Retorna todos los contornos pero no recupera ninguna información sobre las relaciones ”padre”/”hijo”. RETR_EXTERNAL: Este modo solo devuelve los contornos externos, por lo que todos los contornos ”hijo” son descartados. RETR_CCOMP: Este modo ordena los contornos en jerarquías de 2 niveles. De este modo el contorno externo de una figura estaría en el nivel 1 y el interior en el nivel 2. 3.1. Reconocimiento de imágenes mediante patrones 25 RETR_TREE: Este modo retorna todos los contornos y todas las relaciones entre entre ellas, por lo que este modo es el que se aplica para poder obtener información sobre cómo están anidados los contornos. Como es necesario toda la información, utilizamos el parámetro RETR_TREE. Así, cuando se encuentran 5 o más contornos anidados, como se muestra en la figura 3.10, se deduce que es un Finder Pattern. Figura 3.10: Finder Pattern con contornos enumerado 3.1.2.3. Localización en pantalla mejorado Una manera de solucionar los fallos encontrados en las indicaciones al usuario consiste en minimizar los cuadrantes mencionados en la figura 3.6 a los bordes de las pantalla, añadiendo más zonas de detección. De modo que ahora proporcione indicaciones respecto a 8 zonas, frente a las 4 del prototipo anterior, siendo más efectiva. Además de las 4 esquinas/cuadrantes que se identifican en la imagen 3.6, aquí también se distinguen los centros en horizontal y vertical (E, F, G, H), como se muestra en la figura 3.11. 3.1. Reconocimiento de imágenes mediante patrones 26 Figura 3.11: Imagen base con Finder Pattern encontrados mediante búsqueda de centros concéntricos Para estos 4 nuevos casos la lógica a seguir es la siguiente: Si se encuentra en el cuadrante E, solo se dirige hacia la parte superior y, en el caso del cuadrante H, hacia la parte inferior. Si se encuentra en el cuadrante F, solo se dirige hacia la izquierda y, en el caso del cuadrante G, hacia la derecha. De esta manera se consigue que el QR se posicione lo más centrado posible. Además, al ignorar el cuadrante central, ya que se asume que el lector de QR ya lo habrá decodificado al encontrarse en el centro de la pantalla, no se dan direcciones confusas en caso de encontrar Finder Pattern en cuadrantes opuestos. 3.1.2.4. Zxing Zxing (Zebra Crossing) [31] es una librería de código abierto implementada en Java que facilita la lectura/decodificación de una amplia gama de códigos, entre ellos los QRs. Esta librería se ha descartado tras haber realizado pruebas y llegado a la conclusión de que, para el algoritmo en desarrollo, no tenía un buen rendimiento y terminaba por ralentizar el funcionamiento principal de la aplicación. Para leer y decodificar los códigos QR se utiliza ML Kit [32], incluido en Android. El uso de esta librería se explicará más adelante. 3.2. Reconocimiento mediante Deep Learning 33 la partición de cada imagen ha sido como se muestra en la siguiente figura 3.15: Figura 3.15: Diagrama de desarrollo para el recorte de imágenes Para detectar los QRs se ha hecho uso de la librería “QRCodeDetector” [55] de OpenCV, que permite la detección y lectura de QRs. Con esta librería se detecta si la imagen tiene un QR legible y los puntos donde están las esquinas. Los puntos de interés del QR son las esquinas, la mitad de las esquinas y el centro del QR, estos se obtienen gracias a las esquinas del recuadro que proporciona el detector de OpenCV. Una vez hecho esto se realiza un giro de la imagen desde el centro del QR. Para el ángulo de giro se ha utilizado la siguiente fórmula [56]: angle =arctan (y2−y1, x2−x1) ·180 π Esta fórmula utiliza dos puntos, que corresponden a los puntos medios determinados por las esquinas de la derecha y las de la izquierda, representadas en la figura 3.16: Figura 3.16: Puntos medios de un QR 3.2. Reconocimiento mediante Deep Learning 34 Después de girar la imagen, se comprueba que no se haya salido del encuadre detectando otra vez el QR y obteniendo otra vez los puntos de interés. Una vez llevado a cabo este paso, se procede al corte, los puntos de corte se hallan con los puntos medios, prolongándolos hasta el límite de la imagen con si se tratara de una línea recta, al haber girado el QR el procedimiento es más sencillo y se realizan los cortes correctamente. Se intentó realizar el mismo procedimiento mediante el cálculo del vector generado por los dos puntos medios opuestos, sin embargo, generaba mucha complejidad al algoritmo y errores en muchas ocasiones, pues había una limitación con OpenCV, que solo admite tipos enteros para los puntos. Además, el coste de procesado era mucho mayor y el ángulo de giro no iba a influir a la hora de entrenar el modelo, por eso lo desestimamos y optamos por esta opción más sencilla y eficaz. Se hace uso de OpenCV para realizar estos pasos. Fase 2. Entrenamiento del modelo Para el entrenamiento del modelo se ha hecho uso de Tensorflow Lite Model Maker [57], que es una librería de alto nivel que facilita la creación de modelos optimizados para dispositivos móviles. Esta elección se produjo debido a que al convertir los modelos creados con tensorflow a modelos ligeros .tflite, Android devolvía un error de arquitectura al cargarlos en la aplicación, el mismo error recomendaba el uso de Tensorflow Lite Model Maker para crear el modelo. Para el entrenamiento del modelo con Tensorflow Lite Model Maker se probaron todos los modelos base que permite la librería [58]: •efficientnet_lite0. •efficientnet_lite1. •efficientnet_lite2. •efficientnet_lite3. •efficientnet_lite4. •mobilenet_v2. •resnet_50. Para el entrenamiento de estos modelos se utilizó un conjunto de datos compuesto por más de 22000 imágenes y los resultados obtenidos no fueron válidos, debido a la presencia de falsos positivos en objetos comunes de la vida cotidiana como teclados de ordenador, pantallas, 3.2. Reconocimiento mediante Deep Learning 35 cajas y similares. Según se pudo observar reconocía como QRs, tanto completos como parciales, objetos que presentaban formas cuadradas y rectangulares en su composición. La conclusión a la que se llegó es que había que utilizar otro tipo de arquitectura de visión artificial debido a que la clasificación de imágenes no daba unos resultados válidos con una buena cantidad de datos. Tampoco se debía a un mal entrenamiento del modelo, pues los tests realizados en el modelo a través de Tensorflow devolvían un “accuracy” superior al 90 %, lo que indicaba que estaba bien entrenado según los datos facilitados. Por este motivo se decidió optar por una estrategia de detección de objetos, la cual permite realizar anotaciones sobre las imágenes indicando donde se encuentra el objeto y obteniendo una precisión mucho mayor, pues permite incluir varias etiquetas en una sola imagen. 3.2.4.2. Estrategia 2. Algoritmo de detección de objetos AutoML El aprendizaje automático automatizado, también denominado ML automatizado o AutoML, es el proceso de automatizar las tareas lentas e iterativas del desarrollo de modelos de Machine Learning [59]. En este caso hemos utilizado AutoML Vision, un paquete de herramientas de Machine Learning desarrollado por Google que permite a los desarrolladores poco experimentados de herramientas y un entorno sencillo para entrenar modelos adaptados a sus necesidades. La herramienta de detección de objetos de Cloud AutoML Vision da la posibilidad de entrenar modelos personalizados de aprendizaje automático capaces de detectar objetos en una imagen, con su etiqueta correspondiente y su cuadro de ubicación, dándonos información respecto a su posición en el espacio. Una vez entrenado el modelo, disponemos de herramientas para añadir y eliminar anotaciones de imágenes, revisar las métricas obtenidas o ajustar el margen de precisión, entre otras [60]. •Entrenamiento del modelo Utilizando los servicios Cloud de Google, podemos subir un conjunto de imágenes, que hará las veces de dataset, y procederemos a etiquetarlo manualmente con la herramienta que se nos proporciona (3.17). 3.2. Reconocimiento mediante Deep Learning 36 Figura 3.17: Herramienta de etiquetado de Auto Ml Una vez terminado el etiquetado, podemos entrenar un modelo, obteniendo las métricas que aparecen en la figura 3.18 para su evaluación. Figura 3.18: Gráficas de evaluación de un modelo Auto Ml Cuando nos encontremos satisfechos con el resultado, bien podemos exportarlo a .tflite o alojarlo en la nube y obtener una API para utilizar en nuestra aplicación. Esta última opción fue descartada por la necesidad de conexión a internet para que funcione la aplicación y el hecho de que a partir de determinado número de accesos conlleve un coste monetario. Esta herramienta nos facilita considerablemente la tarea de entrenar un modelo, permitiendo hacerlo sin mucho conocimiento y de manera rápida, al solo tener que centrarnos en el etiquetado de imágenes y la evaluación del modelo entrenado. La gran desventaja, sin embargo, es precisamente lo que hace más sencilla esta herramienta, la automatización. No nos permite 3.2. Reconocimiento mediante Deep Learning 37 el nivel de personalización que necesitamos para el desarrollo de la aplicación (selección de algoritmo, método de cuantificación, etc) y es muy opaca respecto a su funcionamiento interno, dificultando la tarea de hacer un estudio comparativo entre esta y otras opciones. Es por esto que nos hemos decantado por un acercamiento más manual para el entrenamiento del modelo. Tensorflow Para la creación del modelo de detección de objetos con Tensorflow, al igual que con el modelo de clasificación de imágenes, se ha utilizado Tensorflow Lite Model Maker [57], por la simplicidad y optimización que permite a la hora de generar modelos de aprendizaje automático para dispositivos móviles. 3.2.5. Generar un modelo con Tensorflow A la hora de crear un modelo de aprendizaje automático hay que tener en cuenta las herramientas a utilizar y seleccionar bien los datos a utilizar, en esta sección se van a explicar los motivos por lo que se han utilizado estos datos y las herramientas con las que se han adaptado de manera detallada. 3.2.5.1. Creación del dataset Los modelos de detección de objetos requieren de imágenes anotadas para su funcionamiento, hay diversos estándares definidos para anotar las imágenes, cada uno caracterizado por cómo se almacenan estas etiquetas, pero son similares. Aunque cada uno tiene sus peculiaridades, el punto en común es el denominado “bounding box” o cuadro límite, que es el recuadro donde se encapsula el objeto a identificar y la parte más importante de la creación de un modelo de detección de objetos [50]. 3.2.5.2. Etiquetado Tensorflow Lite Model Maker admite tres tipos de etiquetado que se explican a continuación. COCO [61]: El etiquetado de las imágenes se almacena en un único fichero JSON que contiene toda la información. El fichero JSON se compone de los siguientes atributos: •Info: contiene la información sobre el dataset. •Licenses: contiene un listado de licencias que se aplicarán sobre las imágenes del dataset. 3.2. Reconocimiento mediante Deep Learning 38 •Categories: son agrupaciones de objetos, estas agrupaciones se pueden agrupar también en lo que se denominan “supercategorías”. •Images: contiene la información de las imágenes pero sin la información de los objetos que contiene, cada imagen tiene un identificador único. •Annotations: una lista con las anotaciones para los objetos de cada imagen. En COCO se crea una anotación por cada objeto detectado, esta anotación es la que contiene el cuadro límite. Las anotaciones a su vez tienen varios atributos que son el área del cuadro límite, “iscrowd” que se habilita cuando en una imagen hay más de un objeto y activa la segmentación, el id de la imagen y el cuadro límite con 4 componentes (x-arriba izquierda, y-arriba derecha, ancho, alto). Pascal VOC [61]: El formato de este sistema de anotaciones es diferente, crea un xml por cada una de las imágenes del dataset y hay que almacenarlas en un directorio diferente de las imágenes. Cada fichero de anotaciones tiene las siguientes etiquetas XML: •Folder: El directorio que contiene la imagen. •Filename: el nombre de la imagen que referencia. •Size: Contiene ancho, alto y profundidad, la profundidad es 1 para las imágenes en blanco y negro y 3 para las imágenes a color. •Object: Una por cada objeto en la imagen, contiene los detalles del objeto y los identifica con los siguientes atributos: ◦Name: nombre del objeto, comúnmente lo llamamos etiqueta. ◦Truncated: Indica si el objeto se ve de manera parcial (1) o completo (0). ◦Difficult: Indica si el objeto es difícil de reconocer (1) o fácilmente reconocible (0), se utiliza para descartar las imágenes que contengan este atributo si el entrenamiento resultante no ha producido los resultados esperados. ◦Bounding box: diferente al de COCO, en este caso se marcan las esquinas (x-arriba izquierda, y-arriba izquierda, xabajo derecha, y-abajo derecha). CSV [62]: Es el formato que utiliza Auto ML por defecto, por lo tanto, no es un formato estandarizado en el ámbito del aprendizaje por transferencia de imágenes. 3.2. Reconocimiento mediante Deep Learning 39 El fichero debe ser un .csv codificado en UTF-8 y una fila por cada objeto dentro de una imagen, la cual contendrá la información del cuadro límite, que en este formato no tiene esta denominación, sino que se denomina “vertex”. El vertex se puede representar con solo 2 vértices, con una estructura similar al cuadro límite de Pascal VOC ( x_relative_min, y_relative_min, x_relative_max, y_relative_max ), o representando los 4 vértices ( x_relative_min, y_relative_min, x_relative_max, y_relative_min, x_relative_max, y_relative_max, x_relative_min, y_relative_max ). Un ejemplo de línea del CSV de un objeto con este formato sería similar a: •2 vértices: rutaCompletaImagen.png, etiqueta, 0.1, 0.1„, 0.3, 0.3„ •4 vértices: rutaCompletaImagen.png, etiqueta, 0.2, 0.2, 0.3, 0.3, 0.4, 0.5, 0.3, 0.6 Como se aprecia, este formato es más simple, pues no permite opciones de especificación del objeto más completas como los otros dos. 3.2.5.3. Elección de la herramienta y el formato de anotaciones Se ha decidido optar por un etiquetado manual de las imágenes para que la detección de los QRs y QRs parciales sea más completa y variada, manualmente nunca se selecciona el QR con precisión exacta, gracias a la cual, permite generar unos datos de entrenamiento más completos y diferenciales para entrenar el modelo. Para la elección de la herramienta de etiquetado [63] había que tener en cuenta los formatos de etiquetado que admitía [64], que fueran compatibles con Pascal VOC o COCO, que la herramienta fuera de uso sencillo y que permitiera etiquetar las imágenes de manera rápida. Respecto al formato de etiquetado, se ha optado por Pascal VOC debido a que las anotaciones se encuentran definidas en varios ficheros frente a COCO, que en caso de que el JSON generado se corrompa se pierden todas las anotaciones. No hay más motivos de peso pues el resto de características son similares entre ambos formatos. Y para la herramienta de etiquetado, se ha decidido optar por “labelImg” [65], un software desarrollado en Python con licencia de código abierto, que permite anotar las imágenes de manera sencilla y generar un formato Pascal VOC o YOLO, así como convertir las anotaciones generadas a formato CSV. Esta herramienta se ha seleccionado por la facilidad de uso y porque tiene atajos de teclado, los cuales permiten un etiquetado mucho más ágil frente a otras herramientas. 3.2. Reconocimiento mediante Deep Learning 40 3.2.5.4. Selección del conjunto de datos El banco de imágenes que se ha empleado es “finderPatterns” [51], obtenido de Kaggle junto con algunas imágenes hechas por miembros del equipo. Se ha optado por este porque tiene imágenes de QRs en diversos entornos, muy variadas y, lo más importante, en entornos del mundo real, no obtenidas de manera digital, que complementadas con las que habían realizado los miembros del equipo eran similares a los casos de uso reales de la aplicación. Estas imágenes se han dividido en tres tipos que especifican su finalidad: Training: 1770 imágenes que se han utilizado para realizar el entrenamiento del modelo Validation: 208 imágenes que se han utilizado para aumentar la precisión del modelo, realizando una validación durante su entrenamiento. Test: 101 imágenes que se han utilizado para obtener los datos de precisión del modelo y así evaluar el modelo generado 3.2.5.5. Creación del modelo Redes neuronales base Las redes neuronales base son el modelo de partida que se utiliza para empezar a entrenar la red con los nuevos objetos que se quieren identificar. Para este proyecto se han utilizado las redes neuronales de EfficientDet-Lite, una derivación de EfficientDet optimizadas con los modelos de TensorFlow para los dispositivos móviles. En concreto, Model Maker cuenta con la implementación de 5 redes EfficientDet-Lite de detección de objetos: EfficientDet-Lite0,EfficientDetLite1,EfficientDet-Lite2,EfficientDet-Lite3 yEfficientDet-Lite4 [66]. Estas redes van en orden de menor a mayor precisión, pero a costa de una mayor exigencia de procesamiento, tanto a la hora de entrenar el modelo como de procesar el modelo entrenado en el dispositivo. Por este motivo es necesario que se realice una prueba exhaustiva según el caso de uso, teniendo en cuenta la capacidad de procesamiento del dispositivo, la latencia máxima que se puede permitir, así como de disponer de un equipo lo suficientemente potente como para poder entrenar la red. EfficientDet [67] es una mejora de las redes EfficientNet que se encuentran preentrenadas con ImageNet [68] como red base, que mejora la precisión de estas y la latencia haciéndola ideal para los modelos de detección de objetos. Para optimizar EfficientNet se ha aplicado la denominada BiFPN, que elimina los nodos poco relevantes, que solo aportan una característica, simplificando la red y a su vez pondera estas características para aproximarlas entre sí. También hace uso de una arquitectura piramidal, según el modelo tiene más capas, desde EfficientDet-D0 hasta EfficientDet-D7, aumentando 3.2. Reconocimiento mediante Deep Learning 41 la precisión pero también produciendo un aumento de la latencia y el coste procesamiento. Cuantificación post-entrenamiento Es una técnica de conversión que se aplica una vez terminado el entrenamiento que, dependiendo del método utilizado permite reducir el tamaño del modelo y/o mejorar la latencia del mismo, a costa de una mínima pérdida en cuanto a precisión [69]. Entre los métodos que se han valorado para el proyecto encontramos: Cuantificación completa de enteros: Asegura que todas las matemáticas del modelo estén cuantificadas con números enteros, traduciendo los números de coma flotante de 32 bits originales, a números de 8 bits con coma fija (enteros) [70]. La reducción del tamaño será por tanto unas cuatro veces menor a la original, y además proporcionará una mejora en la latencia de hasta el triple, al realizar operaciones con enteros en vez de en coma flotante. Puede suponer una ligera bajada de precisión. Cuantificación de rango dinámico: Similar a la cuantificación completa de enteros pero no cuantifica las entradas ni las activaciones (funciones internas) como enteros, las tiene como punto flotante y, antes del procesamiento, las cuantifica dinámicamente para funcionar como enteros de 8 bits. Una vez terminado, vuelve a descuantificar para añadir los bits de precisión [71]. Conlleva una menor pérdida de precisión que la cuantificación completa de enteros, al recuperar los bits de precisión, pero a coste de una menor eficiencia, al tener que realizar operaciones extra dinámicamente Cuantificación float16: Convierte los pesos a valores de coma flotante de 16 bits, reduciendo el tamaño del modelo original (en float32) prácticamente a la mitad [72]. Al ser compatible con GPU (unidad gráfica) , que puede operar en float16, no se requerirá muestrear los valores a float32 de nuevo en la ejecución. Aún si esto fuera necesario, por utilizar la CPU, sería una considerable reducción del tamaño a cambio de un mínimo coste en latencia y precisión. Tras diversas pruebas se ha optado por utilizar float16 como método de cuantificación, ya que con el uso de GPU se puede obtener una latencia más que suficiente para el análisis en tiempo real, sin necesidad de utilizar otro método que pueda suponer una pérdida en precisión. Se amplía en la sección 4.4.4.6. Capítulo 4 Desarrollo e implementación 4.1. Casos de uso A continuación, un diagrama con los casos de uso generales de la aplicación, figura 4.1 Figura 4.1: Casos de uso En las siguientes tablas, podemos estudiar los casos de uso de la aplicación más detalladamente. Entre estos encontramos: Lector de QR, tabla 4.1 Lector de QR con Talkback [73] activado, tabla 4.2 Lectura de texto, tabla 4.3 Lectura de enlace, tabla 4.4 Lectura de credenciales para acceso a red Wifi, tabla 4.5 42 4.3. Reconocimiento de imágenes mediante patrones 49 Figura 4.4: OpenCV: settings.gradle 5. ”File>Project Structure>Dependencies”. Añadir un nuevo ”module dependency”, seleccionar el sdk y aplicar el cambio como en la figura 4.5. Figura 4.5: OpenCV: agregar módulo 6. ”File>Project Structure>Modules>sdk”. Finalmente, seleccionar una versión del desplegable “Build Tools Version” y aplicar el cambio (figura 4.6). 4.3. Reconocimiento de imágenes mediante patrones 50 Figura 4.6: OpenCV: modificar SDK 4.3.3. Estructura de carpetas de la aplicación El código de la aplicación se ha estructurado como se muestra en la siguiente figura: 4.7 Figura 4.7: Estructura del proyecto 4.3. Reconocimiento de imágenes mediante patrones 51 MainActivity.java: es la actividad principal y el punto de entrada de la aplicación. Al ejecutar la aplicación el sistema carga una instancia de esta actividad y su componente visual. En esta clase se encuentra la lógica de la aplicación. PopUpDialogFragment.java: en esta clase se encuentra el cuadro de diálogo utilizado para enseñar los mensajes al usuario. activity_main.xml: en este archivo xml (eXtensible Markup Language) se define el componente visual para la interfaz de usuario. AndroidManifest.xml: este fichero describe toda la información esencial de la aplicación (características de cada componente). build.gradle: en este fichero se puede configurar las opciones de compilación para el módulo en donde está localizado. En este caso para la aplicación. 4.3.4. Diagrama de funcionamiento de la aplicación Al iniciar la aplicación, se comprueba que el usuario autorice la utilización de la cámara del móvil y se ejecuta el algoritmo en bucle hasta que encuentre el QR, lo decodifique y redirige a la ventana de aviso para posteriormente abrir o leer el contenido según su tipo. El funcionamiento de la aplicación es como se demuestra en la siguiente imagen: 4.8 4.3. Reconocimiento de imágenes mediante patrones 52 Figura 4.8: Flujo de la aplicación 4.3.5. Cámara Para utilizar la cámara del móvil en la aplicación es necesario que la actividad principal (MainActivity.java) implemente la interfaz ”CameraBridge- 4.3. Reconocimiento de imágenes mediante patrones 53 ViewBase.CvCameraViewListener2” y sobreescriba los siguientes métodos: onCreate(),onCameraViewStarted(),onCameraViewStopped(),onCameraFrame(),onDestroy(),onPause(),onResume(). Los métodos onCameraViewStarted() yonCameraViewStopped() son eventos que se ejecutan cuando se inicia la cámara y cuando se pausa. En está aplicación, el algoritmo se encuentra en el método onCameraFrame() que se ejecuta en cada frame (fotograma) infinitamente hasta cerrar la aplicación. Además de implementar la interfaz, también se necesita una instancia de la clase JavaCameraView, integrada en OpenCV, para poder utilizar la API de cámara de Android. Utilizando métodos de esta clase se puede habilitar la cámara y también solicitar los permisos necesarios. 4.3.6. Implementación del algoritmo Las instrucciones que sigue el algoritmo que se ha implementado para reconocer los patrones del QR son las siguientes: 1. Se lee el frame proveniente de la cámara y se guarda en una matriz de OpenCV. 2. Se aplica el algoritmo de canny (3.1.2.1) a la matriz guardada. 3. Se buscan contornos en el resultado de la imagen preprocesada por canny. 4. Se recorren todos los contornos encontrados, buscando contornos que tengan más de 5 contornos ”padre”. 5. Para los contornos con padres encontrados, se busca su centro geométrico y se guarda su posición. 6. Se dirige al usuario según la posición de los centros encontrados respecto al centro de la imagen encontrada por la cámara. 7. En cada frame encontrado, se ejecuta el algoritmo de detección de códigos de ML Kit. Al encontrar un código válido, se para la ejecución de la cámara y se muestra en un PopUp la información leída. Si se trata de un link, permite acceder a su contenido abriéndolo en el navegador. 4.4. Reconocimiento mediante Deep Learning 54 4.3.7. Escáner y decodificador de QR Se utiliza el scanner que proporciona ML Kit. El método de análisis y decodificación del QR recibe cómo parámetro un tipo Mat, que representa la imagen en un array de píxeles, que se convierte a un Bitmap y luego a una imagen que es lo que utiliza ML Kit para procesar la imagen y devolver una lista con todos lo QRs que ha encontrado en la imagen. 4.4. Reconocimiento mediante Deep Learning 4.4.1. Tecnologías utilizadas Python [18]: Para la creación del modelo de AA, se ha utilizado la versión 3.7 que es la que presenta compatibilidad completa con la librería utilizada, el resto de versiones (3.6-3.9) presentaban algunos errores de compatibilidad. Tensorflow [33]: Framework para la creación de modelos de Machine Learning, concretamente la versión 2.8. Visual studio [78]: IDE utilizado para el desarrollo de la aplicación batch en Python. Java [25]: Lenguaje de programación utilizado para el desarrollo de la aplicación en Android. Android Studio [80]: IDE oficial para desarrollar aplicaciones nativas en la plataforma Android. ML Kit [32]: Herramienta de utilidades con tecnologías de AA y reconocimiento de patrones que integra Android a modo de API utilizando los servicios de google. 4.4.2. Estructura de carpetas de la aplicación El código de la aplicación se ha estructurado como se muestra en la siguiente figura: 4.9 4.4. Reconocimiento mediante Deep Learning 55 Figura 4.9: Estructura del proyecto MainActivity.java: es la actividad principal y el punto de entrada de la aplicación. Al ejecutar la aplicación el sistema carga una instancia de esta actividad y su componente visual. En esta clase se encuentra la lógica de la aplicación. Tiene asociado un fichero xml, denominado activity_main.xml, que define la interfaz de usuario. MonitorPermision.java: controla la exclusión mutua al acceso de imágenes y la activación/desactivación del decodificador y el identificador de QR. Overlay.java: clase auxiliar para dibujar en pantalla el borde de los objetos encontrados por el modelo de aprendizaje automático. TextViewerActivity.java: se utiliza para mostrar (y narrar dependiendo del caso) QR que contengan texto. Tiene asociado un fichero xml denominado activity_text_viewer.xml, que define su interfaz gráfica. AndroidManifest.xml: este fichero describe toda la información esencial de la aplicación (características de cada componente). build.gradle: en este fichero se puede configurar las opciones de compilación para el módulo en donde está localizado. En este caso para la aplicación. 4.4. Reconocimiento mediante Deep Learning 56 4.4.3. Creación del modelo Para la creación del modelo se programado una aplicación en Python tipo batch oscript, que se ejecuta solamente cuando se quiere crear un nuevo modelo, y se ha hecho uso de las librerías tflite_model_maker [57] y Tensorflow, este último en su versión 2.8, pues versiones posteriores producían problemas de compatibilidad con algunos métodos de tflite_model_maker. Para el entrenamiento del modelo se ha utilizado el conjunto de datos mencionado en la sección 3.2.5.4, el cual se ha cargado haciendo uso en Model Maker del cargador de datos (Dataloader) que implementa por defecto, al que se facilitan las etiquetas en un listado y carga los datos de manera automática. Estos modelos se han entrenado mediante GPU, en caso de las redes 0-3, y con CPU, en la red 4, por falta de memoria requerida en la GPU disponible para el entrenamiento (Nvidia RTX3060 6GB), con los datos de entrenamiento y validación, así como probado con los datos de test, aplicando en cada caso la siguiente configuración: EfficientDet-Lite0 →batch 16 y epochs 50 EfficientDet-Lite1 →batch 8 y epochs 50 EfficientDet-Lite2 →batch 4 y epochs 50 EfficientDet-Lite3 →batch 2 y epochs 50 EfficientDet-Lite4 →batch 2 y epochs 50 El ”batch” es la cantidad de imágenes que se cargan a la vez, según un estudio reciente consultado [81], se ha demostrado que los modelos producen mejores resultados con un lote de potencias de 2 en el rango 2-32. Los ”epochs” son la cantidad de veces que se procesan las imágenes, un epoch procesa todas las imágenes de entrenamiento y validación, hay que buscar un rango amplio para que produzca un mejor entrenamiento, pero no demasiado porque hay riesgo de sobreentrenar el modelo. Sobreentrenar un modelo consiste en ajustarlo tanto a los datos facilitados que sólo produzca resultados satisfactorios para estos, no de manera generalizada [82]. En el caso de este proyecto se ha comprobado que 50 epochs producen buenos resultados. Se han creado múltiples modelos para así poder evaluarlos en la aplicación final, estos modelos presentan casi todas todas las configuraciones posibles que permite la librería. En primera instancia se han creado 8 modelos, 4 EfficientDetLite0 y 4 con EfficientDetLite1, cada uno con un tipo de cuantificación para así poder 4.4. Reconocimiento mediante Deep Learning 57 evaluarlos directamente en el dispositivo. Los resultados han sido favorables en los modelos sin cuantificación y los que presentan cuantificación con float16, mostrando más precisión en las pruebas realizadas el modelo EfficientDetLite1, al ser una red más completa. Una vez probado esto, se han evaluado modelos cuantificados en float16 con las redes EfficientDetLite2 yEfficientDetLite3, siendo estas inutilizables en algunos dispositivos de menor potencia al producir una latencia que hace inutilizable la aplicación, motivo por el cual se ha decidido optar por EfficientDetLite1, que funciona en todos los dispositivos y ha producido resultados muy positivos. 4.4.4. Creación de la aplicación Para explicar el proceso de desarrollo de esta aplicación se va a explicar en distintas secciones el flujo que sigue el funcionamiento de la aplicación desde la perspectiva del usuario, así como los componentes involucrados en el desarrollo para que este funcionamiento se haya podido llevar a cabo. 4.4.4.1. Diagrama de funcionamiento de la aplicación A continuación se muestra un diagrama (figura 4.10) que representa el flujo de ejecución de la aplicación desde que el usuario la inicia hasta que lee el QR: 4.4. Reconocimiento mediante Deep Learning 58 Figura 4.10: Flujo de la aplicación 4.4.4.2. Sensor de luminosidad Para implementar esta funcionalidad se ha utilizado la librería nativa de android Sensor [83]. Utilizando el sensor de luminosidad (integrado en las cámaras del dispositivo), se registra el nivel de luz cada 15 segundos, para no abrumar al usuario con notificaciones, y si es menor al márgen establecido, se le notifica que sería conveniente iluminar la estancia o encender el flash. En un principio se planteó la posibilidad de encender el flash de la cámara, si lo hubiera, automáticamente, pero esta opción podría resultar inconvenien- 4.4. Reconocimiento mediante Deep Learning 65 niente se da porque muchos de los dispositivos que admiten el uso de NNAPI pero solo contienen GPU, dan peores resultados que simplemente usando el delegado de GPU e incluso en algunos casos peor que con la CPU directamente. Por lo que se sabe, este problema se puede dar dependiendo de la arquitectura del procesador y otros factores cuyo estudio queda fuera del contexto de este TFG. Es importante tener en cuenta también que a la hora de usar un delegado u otro, este debe ser compatible con la cuantificación que usemos. En la siguiente tabla 4.6 se muestran los aceleradores y el tipo de cuantificación compatible (marcados con una X): Tipo de cuantificación GPU NNAPI Hexagon CoreML Coma flotante X X Cuantificación float16 posterior al entrenamiento X X Cuantificación de rango dinámico posterior al entrenamiento X X Cuantificación de enteros posterior al entrenamiento X X X Entrenamiento consciente de la cuantificación X X X Tabla 4.6: Aceleradores hardware y cuantificación compatibles Aunque teóricamente el uso de NNAPI podría ser muy beneficioso en determinados dispositivos, al ser la filosofía del proyecto facilitar la lectura de QR a la mayor cantidad de personas posibles, no sería viable su uso. Además nos hemos decantado por una cuantificación float16 posterior al entrenamiento, poco compatible con NNAPI, ya que los aceleradores que utiliza (excepto la GPU, claro) requieren descuantificar las operaciones nuevamente a 32 bits, bajando el rendimiento. Esta técnica nos permite reducir el tamaño sin pérdida de precisión. Utilizando el delgado de GPU en este modelo cuantificado, obtenemos una latencia más que suficiente, que nos permite no tener que recurrir a otras técnicas que si supusieran una pérdida en precisión. Por los motivos explicados previamente finalmente se ha implementado exclusivamente el delegado GPU. 4.4. Reconocimiento mediante Deep Learning 66 (a) (b) Figura 4.13: Ejemplos de interfaz en distintas vistas de la aplicación 4.4.4.7. Interfaz de usuario La interfaz de usuario es sencilla, centrada en la accesibilidad. Todo el texto en la aplicación es de gran tamaño, con un alto contraste con color blanco sobre fondo negro (ejemplos en figura 4.13). En caso de tener activado TalkBack, las instrucciones serán dadas por comandos de voz claros y concisos. Una vez leído un código QR, se emite un sonido de acierto y se le indica al usuario por voz también de qué tipo es, realizando después la acción pertinente (abrir una página web, conectarse a una red wifi etc). Capítulo 5 Ingeniería del software En este capítulo se habla de las técnicas de ingeniería del software que se han aplicado al desarrollo de este proyecto: los requisitos tenidos en cuenta, el plan de proyecto para la gestión de los recursos humanos del equipo y la gestión de riesgos del proyecto. 5.1. Especificación de requisitos Los requisitos considerados durante el periodo de planificación fueron los siguientes: 1. Detectar y leer QR sin necesidad de encuadrarlos en la pantalla. 2. Identificar la presencia de un QR (o fragmentos del mismo) mediante el siguiente proceso: a) Búsqueda en la imagen de un código QR o partes de un código QR. b) Proporcionar instrucciones para poder leer dicho QR una vez detectado (por ejemplo: mueve el móvil más arriba, a la izquierda, a la derecha, acércalo, etc). c) Notificar al usuario sobre las condiciones lumínicas (En caso de oscuridad). d) Notificar cuando se ha leído con éxito el QR. 3. Identifica el contenido del QR y lo lee de forma accesible: a) Abrir un enlace web del QR. b) Mostrar el texto leído en el código para que lo narre el móvil. c) Narrar un PDF (descargado con el QR). d) Leer de una página web. 67 5.2. Plan del proyecto software 68 e) Conectar a red Wi-Fi en caso de ser un QR de conexión. Para las funcionalidades propuestas, se requerirán permisos de acceso a la cámara. 5.2. Plan del proyecto software En la ingeniería del software es importante la gestión de las personas que participan en el proyecto. A la hora de organizar los equipos hay que tener en cuenta los siguientes factores: el número de personas que lo componen, su cualificación para el problema a resolver, teniendo en cuenta tanto la experiencia como los conocimientos en el área, y el alcance del proyecto. Mantei agrupa la gestión en tres tipologías de organización principales atendiendo a los niveles de decisión y la jerarquía dentro los equipos [89; 90]: Centralizado Controlado (CC): Un miembro del equipo se sitúa en lo alto de la jerarquía y toma la responsabilidad de la toma de decisiones y coordinación del equipo, actúa como jefe del equipo, el resto del equipo sigue las directrices que marca el jefe de equipo, siguiendo un tipo de comunicación vertical entre el jefe y el resto de componentes del equipo. Descentralizado Controlado (DC): En esta variante el equipo se divide en sub-equipos más pequeños que siguen una organización similar a la CC, sin embargo, hay un jefe principal para todo el proyecto. La comunicación entre los grupos es horizontal y entre jefes es vertical, sin embargo, la toma de decisiones se lleva a cabo por consenso de todos los miembros. Descentralizado Democrático (DD): Es el más flexible, no hay ningún jefe definido, para cada una de las tareas una persona toma el mando y todas las decisiones, resoluciones y enfoques del proyecto se realizan mediante un consenso del grupo. La comunicación es siempre horizontal en esta variante. En la figura 5.1 se muestra una representación visual de estos tres tipos de organizaciones. 5.2. Plan del proyecto software 69 Figura 5.1: Tipos de organización Para este proyecto se ha decidido establecer una organización de tipo descentralizado democrático (DD), pues es la que más se ajusta a este tipo de proyecto ya que permite una participación mucho más activa en el desarrollo del proyecto y un proceso de investigación más fluido. 5.2.1. Metodología de desarrollo En IS hay dos tipos de metodología de desarrollo principales, las metodologías ágiles y las metodologías tradicionales. Las metodologías ágiles tienen como ventaja que son más flexibles y adaptativas en comparación con las tradicionales, por este mismo motivo podríamos decir que son más adecuadas para un proyecto de investigación como este. Sin embargo, las metodologías ágiles están orientadas a equipos expertos, que tienen experiencia previa en el desarrollo de aplicaciones similares, y se caracterizan por una documentación menos extensa y un plazo de entrega más flexible [91]. Nuestro equipo de desarrollo no tiene la experiencia necesaria para aplicar una metodología ágil de la manera más adecuada. Por este motivo se ha decidido adoptar una metodología híbrida, combinando características de ambas metodologías: De las metodologías tradicionales se ha adoptado la capacidad de planificación a medio y largo plazo así como la extensa documentación. De las metodologías ágiles se ha aplicado un modelo iterativo incremental de desarrollo ágil, que consiste en un desarrollo de funcionalidades de manera parcial y orientadas a la mejora continua de las mismas, nunca una funcionalidad es definitiva, siempre se busca la mejora en la medida que sea posible. Además de las reuniones continuas (1-3 semanales), decidiendo las funcionalidades a desarrollar en cada incremento y exponiendo los problemas para tratarlos en conjunto entre todos los miembros del equipo. 5.2. Plan del proyecto software 70 Un diagrama de Gantt con las fechas en las que se ha ido desarrollando este trabajo de fin de grado se puede encontrar en la figura 5.2. Las fechas indicadas son: Investigación - Estado del arte: De octubre de 2021 a diciembre de 2021. Investigación - Reconocimiento de patrones: De noviembre de 2021 a marzo de 2022. Redacción de la memoria: De noviembre de 2021 a julio de 2022. Desarrollo y pruebas - Reconocimiento de patrones: De diciembre de 2021 a marzo 2022. Investigación - Aprendizaje profundo: De enero de 2022 a julio 2022. Desarrollo y pruebas - Aprendizaje profundo: De febrero de 2022 a julio 2022. Figura 5.2: Diagrama de Gantt 5.2.2. Estrategia de gestión de riesgos En ingeniería del software, riesgo es todo aquello que pueda afectar negativamente a un proyecto de software [89; 90]. Existen dos tipos de estrategias para la gestión de riesgos: Estrategia reactiva: en esta estrategia el equipo no se preocupa de los riesgos hasta que estos se hayan hecho reales y se conviertan en problemas. 5.2. Plan del proyecto software 71 Estrategia proactiva: en esta estrategia se evalúan y se priorizan los posibles riesgos antes de empezar el proyecto de manera que haya un plan de gestión del riesgo. Para la gestión de riesgos de este proyecto se aplica la estrategia proactiva ya que se considera la más adecuada al ser un TFG. Además, existen 3 tipos de riesgos: Del proyecto: este tipo de riesgos, si se hacen reales, provocan un aumento del esfuerzo y/o costes. Identifican problemas en presupuestos, planificaciones, recursos, personas, entre otras. Técnicos: estos riesgos aparecen cuando el producto o sistema puede ser más difícil de construir de lo que se había estimado previamente. identifican problemas en los requisitos, diseño, implementación, entre otras. Del negocio: estos riesgos amenazan a la viabilidad del proyecto. identifican problemas tales como la construcción de una sistema innecesario, construcción de un producto difícil de vender, entre otras. Al ser este proyecto un TFG, solo se tienen en cuenta los riesgos del proyecto. 5.2.2.1. Riesgos tenidos en cuenta Abandono de un miembro del equipo. Rendimiento de un miembro menor al esperado. Miembro del equipo ausente en un momento clave del proyecto. Falta de conocimiento de la tecnología empleada. Miembro del equipo sin realizar sus tareas. Miembros sin iniciativa. 5.2.2.2. Análisis de riesgos La probabilidad de un riesgo se mide de la siguiente forma 5.1: Frecuente: 75 %-100 % Probable: 50%-75% Ocasional: 25%-50% Baja: 10%-25% Improbable: 0%-10% Tabla 5.1: Tabla de medición de probabilidad de riesgos 5.2. Plan del proyecto software 72 La consecuencia de un riesgo indica la gravedad si ese riesgo se hace real, ordenada de mayor a menor gravedad, puede ser: Catastrófica Crítica Seria Menor Despreciable En la siguiente tabla (5.2) se muestra un resumen de la evaluación de los riesgos llevada a cabo en este proyecto. Riesgo Riesgo Consecuencia Abandono de un miembro del equipo Ocasional Crítica Rendimiento de un miembro menor al esperado Ocasional Crítica Miembro del equipo ausente en un momento clave del proyecto Baja Crítica Falta de conocimiento de la tecnología empleada Ocasional Seria Miembro del equipo sin realizar sus tareas Frecuente Catastrófica Miembros sin iniciativa Ocasional Menor Tabla 5.2: Medición de gravedad de riesgos 5.2.2.3. Priorización de riesgos del proyecto Las siguientes tablas muestran el criterio a seguir a la hora de priorizar los riesgos: la tabla 5.3 el impacto en el proyecto en caso de que el riesgo se haga real [92] y la tabla 5.4 la evaluación del riesgo. Consecuencia Probabilidad Frecuente Probable Ocasional Baja Improbable Catastrófica IN IN IN A M Crítica IN IN A M B Seria A A M B T Menor M M B T T Despreciable M B T T T Tabla 5.3: Consecuencia de riesgos 5.2. Plan del proyecto software 73 Prioridad Riesgo Probabilidad Consecuencia Intolerable Miembro del equipo sin realizar sus tareas Frecuente Catastrófica Alto Abandono de un miembro del equipo Ocasional Crítica Alto Rendimiento de un miembro menor al esperado Ocasional Crítica Medio Miembro del equipo ausente en un momento clave del proyecto Baja Crítica Medio Falta de conocimiento de la tecnología empleada Ocasional Seria Bajo Miembros sin iniciativa Ocasional Menor Tabla 5.4: Priorización de riesgos 5.2.2.4. Reducción, supervisión y gestión del riesgo Las siguientes tablas muestran la planificación de los riesgos evaluados, se han evaluado los siguientes: Miembro del equipo sin realizar sus tareas, en la tabla 5.5. Abandono de un miembro del equipo, en la tabla 5.6. Rendimiento de un miembro menor al esperado, en la tabla 5.7. Miembro del equipo ausente en un momento clave del proyecto, en la tabla 5.8. Falta de conocimiento de la tecnología empleada, en la tabla 5.9 Miembros sin iniciativa, en la tabla 5.10. Riesgo: Miembro del equipo sin realizar sus tareas Descripción Miembro del proyecto no realiza ninguna de sus tareas asignadas Reducción Realizar un seguimiento de las tareas de cada miembro Supervisión Tener en cuenta retrasos en entregas de tareas Plan de contingencia Repartir tareas entre los demás miembros Tabla 5.5: Riesgo 1 5.2. Plan del proyecto software 74 Riesgo: Abandono de un miembro del equipo Descripción Un miembro del equipo abandona el proyecto Reducción Preocuparse por el tiempo disponible de cada miembro Supervisión Reuniones y comunicación entre los miembros del equipo para comprobar la motivación y posibles razones de abandono Plan de contingencia Repartir la tarea entre los demás miembros Tabla 5.6: Riesgo 2 Riesgo: Rendimiento de un miembro menor al esperado Descripción Tareas entregadas con retraso por parte de algún miembro del equipo Reducción Conocer las capacidades de cada miembro del equipo Supervisión Preguntar estado de las tareas asignadas Plan de contingencia Ayudar con la entrega de esa tarea entre el resto de miembros+ Tabla 5.7: Riesgo 3 Riesgo: Miembro del equipo ausente en un momento clave del proyecto Descripción Conocimiento nulo o escaso de las herramientas a utilizar Reducción Ofrecer ayuda para el uso de las herramientas a utilizar Supervisión Repartir las tareas entre un número de personas acorde a su nivel de trabajo Plan de contingencia Repartir la tarea entre los demás miembros Tabla 5.8: Riesgo 4 6.4. Entorno con baja luminosidad 81 Figura 6.5: QR leído de tipo enlace 6.4. Entorno con baja luminosidad En caso de que el entorno donde se encuentre el QR presente un nivel de luminosidad que dificulte su lectura, se avisará al usuario para que ilumine el entorno mediante una alerta de Android, como se puede ver en la figura 6.6. Si el Talkback está activado, la alerta es por voz. 6.4. Entorno con baja luminosidad 82 Figura 6.6: Aviso de baja luminosidad Capítulo 7 Resultados Tras una serie de pruebas y comparativas entre las dos aplicaciones desarrolladas se obtuvieron unos resultados esclarecedores. También añadir que, en complemento a las pruebas realizadas por parte del equipo, se ha obtenido ayuda de personas con discapacidad visual (nºde afiliación de la ONCE 50672 y 53807). Estas personas han probado ambas aplicaciones y aportado una valoración que, en conjunto con las demás, nos han permitido llegar a las siguientes conclusiones: Importancia de indicar el éxito de la lectura de un código QR, tanto por un sonido como mediante la función accesible del móvil, al ser fundamental que la persona sepa en todo momento lo que está ocurriendo en el dispositivo. La opción que se valoró en un inicio de encender el flash de manera automática o mediante un botón al detectar un bajo nivel de luz, resulta inconveniente. Muchas localizaciones en las que se podría dar el caso (museos, locales nocturnos etc) prohíben el uso de la luz flash, pudiendo suponer un problema. Nos indicaron por tanto que era más cómodo informar de la situación lumínica al usuario y darle la opción a éste de tomar las medidas que considere. Es importante aclarar al usuario que los movimientos del dispositivo deben ser suaves, ya que los movimientos muy rápidos podrían provocar que las indicaciones por voz no lleguen a tiempo al usuario antes de que la posición de la cámara vuelva a variar respecto al QR. Es más cómodo para el usuario que se den unas instrucciones sencillas, en vez de habilitar un botón (o en nuestro caso, doble click en la pantalla) para darle unas más detalladas. 83 84 Respecto a los puntos diferenciales entre ambas aplicaciones, podemos extraer estas comparativas en favor de la aplicación que hace uso de aprendizaje automático: Ambas aplicaciones tenían una disposición fija del dispositivo, concretamente la aplicación de patrones hacia la lectura con el dispositivo horizontal y la de aprendizaje automático en vertical. Según el uso habitual de los dispositivos móviles, los usuarios mostraban que sentían mayor comodidad con la disposición fija vertical. Añadir que el hecho de que la posición fuera fija se valoraba positivamente. Respecto a la parte esencial, que es la lectura, la lectura por patrones presentaba una alta tasa de éxito en cuanto al reconocimiento de fragmentos de QR, pero menor al de reconocimiento mediante redes neuronales en QR más complejos. No se detecta apenas diferencia entre la precisión y latencia de ambas al realizar pruebas con esquinas de QR legibles, dando ambas instrucciones correctas y precisas al usuario. Donde más se diferencian, es en las funcionalidades que evalúan la distancia. Pudimos comprobar en las pruebas realizadas que estas eran esenciales a la hora de guiar al usuario y ya que en la aplicación de lectura por patrones era complejo discernir la distancia conociendo solo los centros de los patrones, requiriendo mayor numero de cálculos (influyendo negativamente en el rendimiento) fue una razón determinante a la hora de descartarla. Estos factores nos hicieron concluir que la estrategia de aprendizaje profundo resulta más viable en el uso final de la aplicación y, por ende, optamos con perfeccionar esta última. Una vez pulida la aplicación final, se realizó la evaluación de los resultados obtenidos. Con el objetivo de obtener unos resultados contrastables con datos, se ha modificado la aplicación para que indique el valor de precisión de la detección de los QRs (completos o parciales) y poder realizar las pruebas de manera manual en entornos reales: un centro comercial, consulta médica, transporte público, etc. En rasgos generales los datos obtenidos son muy satisfactorios, se ha probado la aplicación en cuatro dispositivos Android [26] diferentes y se ha realizado la lectura de más de 100 QRs. Adjuntamos una muestra representativa con los resultados de precisión obtenidos por el modelo al identificar algún QR o fragmento con el que guiar al usuario 7.1 7.2. Se incluyen algunos ejemplos obtenidos en la figura 7.1. Cabe mencionar que en numerosos casos con buenas condiciones lumínicas y el QR encuadrado en la pantalla al abrir la aplicación, este se lee de 85 manera directa sin necesidad de instrucciones. 86 (a) (b) (c) (d) Figura 7.1: Ejemplos de instrucciones con indicación de precisión en la esquina superior izquierda 87 Dispositivo Nombre de imagen Precisión Google Pixel 6 als1_p677.png 0.677 Google Pixel 6 als2_p858.png 0.858 Google Pixel 6 als3_p928.png 0.928 Google Pixel 6 als5_p963.png 0.963 Google Pixel 6 als6_p877.png 0.877 Google Pixel 6 als7_p677.png 0.677 Google Pixel 6 als7_p970.png 0.970 Google Pixel 6 als8_p651.png 0.651 Google Pixel 6 als9_p905.png 0.905 Google Pixel 6 als10_p949.png 0.949 Google Pixel 6 als11_p744.png 0.744 Google Pixel 6 als11_p873.png 0.873 Google Pixel 6 als12_p840.png 0.840 Google Pixel 6 als13_p844.png 0.844 Google Pixel 6 als14_p669.png 0.669 Google Pixel 6 als15_p822.png 0.822 Google Pixel 6 als17_p729.png 0.729 Google Pixel 6 als18_p804.png 0.804 Google Pixel 6 als18_p926.png 0.926 Google Pixel 6 als19_p785.png 0.785 Google Pixel 6 als19_p963.png 0.963 Google Pixel 6 als20_p974.png 0.974 Google Pixel 6 als20_p934.png 0.934 Google Pixel 6 als21_p747.png 0.747 Google Pixel 6 als22_p836.png 0.836 Google Pixel 6 als22_p981.png 0.981 Google Pixel 6 als23_p916.png 0.916 Google Pixel 6 als24_p724.png 0.724 Google Pixel 6 als25_p775.png 0.775 Google Pixel 6 als26_p769.png 0.769 Google Pixel 6 als26_p676.png 0.676 Google Pixel 6 als27_p955.png 0.955 Google Pixel 6 als28_p781.png 0.781 Google Pixel 6 als28_p876.png 0.876 POCO F2 Pro mmm_01_p92.JPG 0.926 POCO F2 Pro mmm_02_p96.JPG 0.965 POCO F2 Pro mmm_03_p85.JPG 0.856 POCO F2 Pro mmm_04_p82.JPG 0.828 POCO F2 Pro mmm_05_p66.JPG 0.660 Tabla 7.1: Resultados de las pruebas 1/2 88 Dispositivo Nombre de imagen Precisión POCO F2 Pro mmm_06_p80.JPG 0.802 POCO F2 Pro mmm_07_p88.JPG 0.880 POCO F2 Pro mmm_09_p85.JPG 0.855 POCO F2 Pro mmm_10_p92.JPG 0.923 Galaxy A51 mgbv1.png 0.751 Galaxy A51 mgbv2.png 0.926 Galaxy A51 mgbv3.png 0.735 Galaxy A51 mgbv4.png 0.953 Galaxy A51 mgbv5.png 0.930 Galaxy A51 mgbv6.png 0.736 Galaxy A51 mgbv7.png 0.778 Galaxy A51 mgbv8.png 0.699 Galaxy A51 mgbv9.png 0.748 Galaxy A51 mgbv10.png 0.842 Galaxy A51 mgbv11.png 0.661 Galaxy A51 mgbv13.png 0.741 Galaxy A51 mgbv14.png 0.885 Realme GT Neo 2 poi1_p823.png 0.823 Realme GT Neo 2 poi2_p914.png 0.914 Realme GT Neo 2 poi3_p951.png 0.951 Realme GT Neo 2 poi4_p974.png 0.974 Realme GT Neo 2 poi5_p971.png 0.971 Realme GT Neo 2 poi6_p900.png 0.900 Realme GT Neo 2 poi7_p945.png 0.945 Realme GT Neo 2 poi8_p654.png 0.654 Realme GT Neo 2 poi9_p833.png 0.833 Realme GT Neo 2 poi10_p843.png 0.843 Realme GT Neo 2 poi11_p727.png 0.727 Realme GT Neo 2 poi12_p873.png 0.873 Realme GT Neo 2 poi13_p793.png 0.793 Realme GT Neo 2 poi14_p909.png 0.909 Realme GT Neo 2 poi15_p919.png 0.919 Realme GT Neo 2 poi16_p815.png 0.815 Realme GT Neo 2 poi17_p848.png 0.848 Realme GT Neo 2 poi18_p719.png 0.719 Realme GT Neo 2 poi19_p968.png 0.968 Realme GT Neo 2 poi21_p875.png 0.875 Realme GT Neo 2 poi22_p838.png 0.838 Realme GT Neo 2 poi23_p927.png 0.927 Realme GT Neo 2 poi24_p826.png 0.826 Tabla 7.2: Resultados de las pruebas 2/2 89 Respecto a las situaciones en las que no se ha podido realizar la lectura del QR, principalmente se han debido a factores externos (QR cortado, poco legible, formato incorrecto) que impiden su lectura en general a cualquier aplicación. Sin embargo, sí hemos observado que, en contadas ocasiones, las indicaciones de guiado eran incorrectas cuando había elementos cercanos con patrones que pudieran asemejare a QRs. Al suponer una cantidad marginal de situaciones, hemos decidido no aumentar el umbral mínimo de puntuación a la hora de evaluar el objeto, ya que este es con el que mejores resultados hemos obtenido en la generalidad de los casos (QRs de colores, con formas redondeadas, logos, etc). Se pueden apreciar los ejemplos que hemos encontrado en la figura 7.2. 90 (a) (b) (c) (d) Figura 7.2: Ejemplos de instrucciones incorrectas con indicación de precisión en la esquina superior izquierda 8.4. Pablo Ortuño Ibáñez 97 8.4. Pablo Ortuño Ibáñez Este TFG fue propuesto por la ONCE, en respuesta a una necesidad de los usuarios con discapacidad visual. El primer paso fue definir el objetivo, motivación y alcance de la aplicación, que desarrollamos en común entre todos y, con ello, una serie de requisitos. Estos requisitos, también realizados en conjunto, fueron mostrados a la ONCE para su aprobación que, tras evaluarlos, también nos dieron información sobre los puntos en los que centrarnos y pautas de desarrollo accesible. En un principio, decidimos investigar tanto ciertos conceptos relacionados con la aplicación que planeábamos desarrollar (accesibilidad y QR principalmente), como el estado actual de aplicaciones similares para problemas parecidos. Aunque la investigación se realizó de manera conjunta, dándonos reatroalimentación en las distintas partes, yo me encargué principalmente de esto último: la investigación de otras aplicaciones similares. En las distintas tiendas de aplicaciones podemos encontrarnos con cientos con funcionamiento similar, por eso elegí las más representativas que dieran solución a distintos problemas. Una vez realizada la investigación, pusimos en común todos los conceptos y la información nueva que habíamos adquirido, y pudimos decidir el flujo de acción para iniciar el desarrollo. A la hora de enfocar el problema de la identificación de un código QR que no puede ser decodificado, se decidió investigar dos posibles vías: identificación de patrones yaprendizaje automático. Antonio y yo investigamos esta última. Al haber estudiado la rama de computación en Ingeniería Informática, he cursado la asignatura de ”Inteligencia Artificial” y también escogí la asignatura de ”Programación Evolutiva”, por lo que tenía una base sólida de conocimiento que me instó a centrarme en esta vía. La primera tecnología que investigué fue AutoML. Con un dataset básico (apenas 150 imágenes) me encargué de etiquetarlas a mano con la herramienta disponible en Google Cloud y de desarrollar una aplicación que se encargase de reconocer dichas etiquetas. Aunque finalmente el modelo implementado no usara los recursos de AutoML, sus decentes resultados daban buena impresión sobre la técnica de detección de objetos para nuestro aplicación. Además, algunas de sus funcionalidades fueron migradas a la aplicación final. Una vez descartada AutoML (como tratamos en la sección 3.2.4.2), An- 8.4. Pablo Ortuño Ibáñez 98 tonio y yo pusimos en común nuestros desarrollos y, utilizando de base su aplicación de reconocimiento de imágenes, la adapté para funcionar con modelos de detección de objetos, reutilizando código de la aplicación original de AutoML. También le añadí alguna funcionalidad extra como el Talkback o el sensor de luz. Con una aplicación funcional, faltaba un modelo preciso y con poca latencia. Investigamos en conjunto la tecnología de Tflite y las redes compatibles, realizando tareas en común que iban mejorando la aplicación a cada nueva versión. Entre las realizadas por mi podemos mencionar la optimización de la aplicación, tanto por hardware, con el uso de aceleradores, como por software, reestructurando código e investigando sobre los tipos de cuantificación; pero al fin y al cabo fue un trabajo conjunto. A la hora de entrenar el modelo, nos dividimos las 2079 imágenes del conjunto de datos final a partes iguales y procedimos a etiquetarlas (cada QR con etiqueta de completo y una por cada esquina). Con la primera versión de aplicación final y el modelo entrenado, me encargué de entrevistar y realizar un caso de uso real con usuarios finales posibles de la aplicación. En concreto, dos personas con discapacidad visual. Tras recoger su retroalimentación y compartirla con el grupo, me encargué de implementar los cambios necesarios. A lo largo de este trabajo también he ido recopilando información para introducirla posteriormente en la memoria, pero hemos requerido realizar un trabajo de redacción y revisión extenso al final del proyecto. Si bien la memoria ha sido un trabajo grupal, donde cada uno ha escrito partes, reformulado y revisado las de los demás, las partes que me han correspondido han sido: En la introducción, la parte de objetivos y motivación. Realicé la sección del estado del arte. Del apartado de fundamentos teóricos, la parte de AutoML en conjunto con Antonio, secciones referentes a machine learning. Respecto al apartado de Desarrollo e implementación, la parte referente a la aplicación Android. En cuanto a los resultados, la parte referente a las pruebas con personas con discapacidad visual. Tareas de referenciado y reestructuración, así como de limpieza y corrección de la memoria. Capítulo 9 Conclusión Los códigos QR están estandarizados como fuente de información en muchos ámbitos de la vida cotidiana. Actualmente no hay ninguna aplicación móvil, ni Android ni iOS, que cumpla con los criterios de accesibilidad para que personas con dificultades para visualizar las pantallas puedan leer este tipo de códigos, por este motivo la ONCE propuso este proyecto. Esta aplicación se ha desarrollado únicamente para dispositivos móviles Android, dejando la solución de iOS de lado. Sin embargo, todas las tecnologías y técnicas aplicadas en este proyecto son compatibles y escalables a una solución iOS. Teniendo en cuenta las dos soluciones investigadas para resolver este problema, reconocimiento de patrones y aprendizaje automático, se ha concluido que la solución que utiliza técnicas de aprendizaje profundo proporciona mayor versatilidad y mejor rendimiento. Esto se debe a que, a la hora de búsqueda y lectura de códigos QR, permite realizar un reconocimiento más completo. Con la solución de patrones, las instrucciones relativas a la distancia del QR se volvieron inviables por la manera en la que el algoritmo encontraba los códigos QR. Para poder añadir estas instrucciones, habría que buscar otra manera de implementar el algoritmo, por lo que se decidió centrarse en la solución basada en aprendizaje automático. Además, el modelo de aprendizaje automático siempre se va a poder mejorar, añadiendo más datos representativos al entrenamiento. Respecto a la solución final obtenida, ha recibido buena valoración por parte de las personas que la han utilizado, tanto con Talkback como sin él, pues facilita mucho la lectura de estos códigos respecto a los lectores habituales, no solo para las personas tienen problemas de visión, sino también para las personas que no presentan estas dificultades, pues la pantalla les indica la parte donde ha detectado el QR. Teniendo en cuenta estos resultados, está claro que la aplicación final con la solución de aprendizaje automático cumple con los criterios de accesibili99 100 dad y es altamente utilizable en el día a día de todas las personas. Nosotros nos llevamos la satisfacción de haber realizado una herramienta que podrá ayudar a todas las personas que necesiten interactuar con QRs. Capítulo 10 Conclusion QR codes are standardized as a source of information in many areas of everyday life. Currently there is no mobile application, neither Android nor iOS, that meets the accessibility criteria for people with visual impairment to read this type of codes, that’s the reason why ONCE proposed this project. This application has been developed only for Android mobile devices, leaving the iOS solution aside. However, all the technologies and techniques applied in this project are compatible and scalable to an iOS solution. Taking into account the two solutions investigated to solve this problem, pattern recognition and machine learning, it has been concluded that the solution using deep learning techniques provides greater versatility and better performance. This is due to the fact that, when it comes to searching and reading QR codes, it allows a more complete recognition. With the pattern solution, the instructions regarding the distance of the QR code became non-viable because of the way the algorithm worked out the position of the QR codes. In order to add these instructions, another way to implement the algorithm had to be found, so it was decided to focus on the machine learning based solution. In addition, the machine learning model can always be improved by adding more representative data to the training. The final solution obtained has received good feedback from the people who have used it, both with and without Talkback, as it makes it very easy to read these codes compared to the usual readers, not only for people who have vision problems but also for people who are not visually impaired, because the screen indicates the part where it has detected the QR. Taking these results into account, it is clear that the final application with the machine learning solution meets the criteria of accessibility and is 101 102 highly usable in the daily life of all people. We take with us the satisfaction of having created a tool that will be able to help all people who need to interact with QRs. Bibliografía [1] A. C. Pinar, “Accesibilidad y tecnologÍa.” http://www. accesibilidadglobal.com/2012/04/accesibilidad-y-tecnologia. html, 2012. [2] WPUSROBSERACC, “Breve historia de la accesibilidad universal.” https://observatoriodelaaccesibilidad.es/archivos/30, s.f. [3] M. Sánchez Caballero, “Accesibilidad en la escuela tecnológica.” https://www.nosolousabilidad.com/articulos/accesibilidad_ escuela_tecnologica.htm, 2012. [4] N. Madrid, “Accesibilidad tic, más que accesibilidad web.” https:// www.nachomadrid.com/2020/03/accesibilidad-tic/, 2020. [5] INFORMATION TECHNOLOGY - AUTOMATIC IDENTIFICACION AND DATA CAPTURE TECHNIQUES - BAR CODE SYMBOLOGY - QR CODE. 2000. [6] E. U. C. QR?, “¿quÉ es un cÓdigo qr?.” https://www.qrcode.com/ en/about/, s.f. [7] M. Herranz, “¿cuál es la diferencia entre el aprendizaje automático y el aprendizaje profundo? (machine learning vs deep learning).” https://blog.pangeanic.es/cu% C3%A1l-es-la-diferencia-entre-el-aprendizaje-autom%C3% A1tico-y-el-aprendizaje-profundo-machine-learning-vs-deep-learning, s.f. [8] “¿quÉ es visiÓn por computador?.” https://www.ibm.com/topics/ computer-vision, s.f. [9] iOS, “ios.” https://www.apple.com/es/ios/ios-15/, s.f. [10] L. C. Accesible, “Lanzan la primera aplicación de banca móvil accesible.” http://periodico.laciudadaccesible.com/tecnologia/item/ 103 Bibliografía 104 6201-lanzan-la-primera-aplicacion-de-banca-movil-accesible, 2015. [11] R. Shimosakai, “Segovia, pionera en lanzar una ápp’sobre turismo accesible.” https://ricardoshimosakai.com.br/ segovia-pionera-en-lanzar-una-app-sobre-turismo-accesible/, 2015. [12] S. B. . Q. R. APK, “Scanlife barcode qr reader apk.” https://www. appsapk.com/scanlife-barcode-qr-reader/, s.f. [13] J. Payá, “La ua exhibe su tecnología en el mobile world congress de barcelona.” https://www.informacion.es/cultura/2018/02/20/ ua-exhibe-tecnologia-mobile-world-5802524.html, 2018. [14] Neosistec, “The new bidi code.” https://ddtags.com/, s.f. [15] Neosistec, “Empoderando a las personas con discapacidad visual.” https://www.navilens.com/es/, s.f. [16] R. MP, “Lector de codigos qr y barras accesible – vip code reader.” https://www.accesibles.org/ lector-de-codigos-qr-y-barras-accesible-vip-code-reader/, 2020. [17] “Librería opencv.” https://https://opencv.org/, authorVarios, year=s.f. [18] P. 3.7, “documentación de python - 3.7.13.” https://docs.python.org/ es/3.7/, s.f. [19] “Método para convertir a escala de grises.” https://docs.opencv. org/3.4/d8/d01/group__imgproc__color__conversions.html# ga397ae87e1288a81d2363b61574eb8cab, s.f. [20] Wikipedia, “Thresholding — wikipedia, the free encyclopedia.” https: //en.wikipedia.org/wiki/Thresholding_(image_processing), 2022. [21] Wikipedia, “Otsu’s method — wikipedia, the free encyclopedia.” https: //en.wikipedia.org/wiki/Otsu’s_method, 2022. [22] Wikipedia, “Laplace operator — wikipedia, the free encyclopedia.” https://en.wikipedia.org/wiki/Laplace_operator, 2022. [23] “Método para encontrar contornos.” https://docs. opencv.org/4.x/d3/dc0/group__imgproc__shape.html# gadf1ad6a0b82947fa1fe3c3d497f260e0, s.f. Bibliografía 105 [24] Wikipedia, “Image moment — wikipedia, the free encyclopedia.” https: //en.wikipedia.org/wiki/Image_moment, 2022. [25] es la tecnología Java y por qué la necesito?, “¿qué es la tecnología java y por qué la necesito?.” https://www.java.com/es/download/help/ whatis_java.html, s.f. [26] Android, “Android.” https://www.android.com/intl/es_es/, s.f. [27] C. reference, “C++ reference.” https://en.cppreference.com/w/, s.f. [28] C. E. DETECTOR, “Canny edge detector.” https://en.wikipedia. org/wiki/Canny_edge_detector/, s.f. [29] C. E. DETECTOR, “Canny edge detector.” https://docs.opencv. org/4.5.2/da/d22/tutorial_py_canny.html/, 2021. [30] O. J. D. CONTORNOS, “Opencv: Jerarqu´ Ía de contornos.” https://docs.opencv.org/4.x/d9/d8b/tutorial_py_contours_ hierarchy.html, 2022. [31] Varios, “Zxing.” https://github.com/zxing/zxing, 2022. [32] M. learning for mobile developers, “Machine learning for mobile developers.” https://developers.google.com/ml-kit, s.f. [33] P. qué TensorFlow, “Por qué tensorflow.” https://www.tensorflow. org/?hl=es-419, s.f. [34] D. machine learning models on mobile and edge devices, “Deploy machine learning models on mobile and edge devices.” https://www. tensorflow.org/lite, s.f. [35] B. Diaz, “12 aprendizaje profundo: desmontando las redes neuronales..” https://impulsatek.com/ 12-aprendizaje-profundo-desmontando-las-redes-neuronales/, 2021. [36] D. Calvo, “Perceptrón multicapa – red neuronal.” https://www. diegocalvo.es/perceptron-multicapa/, 2018. [37] y. Miguel Sotaquirá, “La función de activación.” https://www.codificandobits.com/blog/ funcion-de-activacion/#las-funciones-de-activaci%C3%B3n-m% C3%A1s-usadas-endeep-learning. [38] J. Durán, “Qué es la transferencia de aprendizaje y cómo aplicarla a tu red neuronal.” https://medium.com/metadatos/ qu%C3%A9-es-la-transferencia-de-aprendizaje-y-c%C3% B3mo-aplicarla-a-tu-red-neuronal-e0e120156e40, 2020. Bibliografía 106 [39] I. classification with TensorFlow Lite Model Maker, “Image classification with tensorflow lite model maker.” https: //www.tensorflow.org/lite/models/modify/model_maker/image_ classification#detailed_process, 2022. [40] T. D. L. N. to Classify New Images, “Train deep learning network to classify new images.” https://es.mathworks.com/help/deeplearning/ ug/train-deep-learning-network-to-classify-new-images.html; jsessionid=b279c84f9db65fef2865188f3511, s.f. [41] PyTorch, “Pytorch.” https://pytorch.org/, s.f. [42] N. Boldrini, “Deep learning, qué es el aprendizaje profundo, cómo funciona y cuáles son los casos de aplicación.” https://www.innovaciondigital360.com/i-a/ deep-learning-que-es-el-aprendizaje-profundo-como-funciona-y-cuales-son-los-casos-de-aplicacion/, 2021. [43] R. de la API de TensorFlow Lite, “Referencia de la api de tensorflow lite.” https://www.tensorflow.org/lite/api_docs, s.f. [44] t. g. s. y. o. Conceptos básicos de TensorFlow: tensor, forma, “Conceptos básicos de tensorflow: tensor, forma, tipo, gráfico, sesiones y operadores.” https://guru99.es/tensor-tensorflow/, 2022. [45] K. biblioteca de código abierto para crear redes neuronales, “Keras: biblioteca de código abierto para crear redes neuronales.” https://www.ionos.es/digitalguide/online-marketing/ marketing-para-motores-de-busqueda/que-es-keras/, 2020. [46] M. learning for mobile developers, “Machine learning for mobile developers.” https://developers.google.com/ml-kit/vision/ image-labeling, s.f. [47] I. Labeling, “Image labeling.” https://developers.google.com/ ml-kit/vision/image-labeling, s.f. [48] O. Detection and Tracking, “Object detection and trackings.” https: //developers.google.com/ml-kit/vision/object-detection, s.f. [49] T. Huellmann, “How to build an image classification dataset.” https: //levity.ai/blog/create-image-classification-dataset, 2022. [50] C. Lasorsa, “An introduction to bounding boxes [+ best practices].” https://www.superb-ai.com/blog/ an-introduction-to-bounding-boxes-best-practices, s.f. [51] S. G., “Finder patterns (qr code).” https://www.kaggle.com/ datasets/samygrisard/finder-patterns-qr-code, 2021.