BLIPAPP: PIZARRA VIRTUAL BASADA EN DISPOSITIVO MÓVIL ... · BLIPAPP: PIZARRA VIRTUAL BASADA EN...

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

MÁSTER EN INGENIERÍA DE TELECOMUNICACIÓN

BLIPAPP: PIZARRA VIRTUAL BASADA

EN DISPOSITIVO MÓVIL (SISTEMA DE

DETECCIÓN DE PUNTERO LÁSER)

Autor: Miguel Fernández García

Director: Cynthia Hood

Madrid Agosto 2016

Declaro, bajo mi responsabilidad, que el Proyecto presentado con el título

BLIPAPP: PIZARRA VIRTUAL BASADA EN DISPOSITIVO MÓVIL (SISTEMA DE


en la ETS de Ingeniería - ICAI de la Universidad Pontificia Comillas en el

curso académico 2015/2016 es de mi autoría, original e inédito y

no ha sido presentado con anterioridad a otros efectos.

El Proyecto no es plagio de otro, ni total ni parcialmente y la información que ha sido

tomada de otros documentos está debidamente referenciada.

Fdo.: Miguel Fernández García Fecha: ……/ ……/ ……

Autorizada la entrega del proyecto

EL DIRECTOR DEL PROYECTO

Fdo.: Cynthia Hood Fecha: ……/ ……/ ……

Vº Bº del Coordinador de Proyectos

Fdo.: David Contreras Bárcena Fecha: ……/ ……/ ……

AUTORIZACIÓN PARA LA DIGITALIZACIÓN, DEPÓSITO Y DIVULGACIÓN EN RED DE PROYECTOS FIN DE GRADO, FIN DE MÁSTER, TESINAS O MEMORIAS DE BACHILLERATO

1º. Declaración de la autoría y acreditación de la misma. El autor D.____________________________________________________________________ DECLARA ser el titular de los derechos de propiedad intelectual de la obra: ______________________________________________________________________________, que ésta es una obra original, y que ostenta la condición de autor en el sentido que otorga la Ley de Propiedad Intelectual. 2º. Objeto y fines de la cesión. Con el fin de dar la máxima difusión a la obra citada a través del Repositorio institucional de la Universidad, el autor CEDE a la Universidad Pontificia Comillas, de forma gratuita y no exclusiva, por el máximo plazo legal y con ámbito universal, los derechos de digitalización, de archivo, de reproducción, de distribución y de comunicación pública, incluido el derecho de puesta a disposición electrónica, tal y como se describen en la Ley de Propiedad Intelectual. El derecho de transformación se cede a los únicos efectos de lo dispuesto en la letra a) del apartado siguiente. 3º. Condiciones de la cesión y acceso Sin perjuicio de la titularidad de la obra, que sigue correspondiendo a su autor, la cesión de derechos contemplada en esta licencia habilita para:

a) Transformarla con el fin de adaptarla a cualquier tecnología que permita incorporarla a internet y hacerla accesible; incorporar metadatos para realizar el registro de la obra e incorporar “marcas de agua” o cualquier otro sistema de seguridad o de protección.

b) Reproducirla en un soporte digital para su incorporación a una base de datos electrónica, incluyendo el derecho de reproducir y almacenar la obra en servidores, a los efectos de garantizar su seguridad, conservación y preservar el formato.

c) Comunicarla, por defecto, a través de un archivo institucional abierto, accesible de modo libre y gratuito a través de internet.

d) Cualquier otra forma de acceso (restringido, embargado, cerrado) deberá solicitarse expresamente y obedecer a causas justificadas.

e) Asignar por defecto a estos trabajos una licencia Creative Commons. f) Asignar por defecto a estos trabajos un HANDLE (URL persistente).

4º. Derechos del autor. El autor, en tanto que titular de una obra tiene derecho a:

a) Que la Universidad identifique claramente su nombre como autor de la misma b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a través de

cualquier medio. c) Solicitar la retirada de la obra del repositorio por causa justificada. d) Recibir notificación fehaciente de cualquier reclamación que puedan formular terceras personas

en relación con la obra y, en particular, de reclamaciones relativas a los derechos de propiedad intelectual sobre ella.

5º. Deberes del autor.

• El autor se compromete a:

a) Garantizar que el compromiso que adquiere mediante el presente escrito no infringe ningún derecho de terceros, ya sean de propiedad industrial, intelectual o cualquier otro.

b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la intimidad y a la imagen de terceros.

c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por daños, que pudieran ejercitarse contra la Universidad por terceros que vieran infringidos sus derechos e

intereses a causa de la cesión. d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por infracción

de derechos derivada de las obras objeto de la cesión. 6º. Fines y funcionamiento del Repositorio Institucional. La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y respetuoso con los derechos del autor, según lo permitido por la legislación aplicable, y con fines de estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la Universidad asume los siguientes deberes y se reserva las siguientes facultades: Ø La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no

garantiza ni asume responsabilidad alguna por otras formas en que los usuarios hagan un uso posterior de las obras no conforme con la legislación vigente. El uso posterior, más allá de la copia privada, requerirá que se cite la fuente y se reconozca la autoría, que no se obtenga beneficio comercial, y que no se realicen obras derivadas.

Ø La Universidad no revisará el contenido de las obras, que en todo caso permanecerá bajo la responsabilidad exclusive del autor y no estará obligada a ejercitar acciones legales en nombre del autor en el supuesto de infracciones a derechos de propiedad intelectual derivados del depósito y archivo de las obras. El autor renuncia a cualquier reclamación frente a la Universidad por las formas no ajustadas a la legislación vigente en que los usuarios hagan uso de las obras.

Ø La Universidad adoptará las medidas necesarias para la preservación de la obra en un futuro. Ø La Universidad se reserva la facultad de retirar la obra, previa notificación al autor, en supuestos

suficientemente justificados, o en caso de reclamaciones de terceros. Madrid, a ……….. de …………………………... de ……….

ACEPTA

Fdo……………………………………………… Motivos para solicitar el acceso restringido, cerrado o embargado del trabajo en el Repositorio Institucional:

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)


BLIPAPP: PIZARRA VIRTUAL BASADA

EN DISPOSITIVO MÓVIL (SISTEMA DE


Autor: Miguel Fernández García

Director: Cynthia Hood

Madrid Agosto 2016

BLIPAPP: PIZARRA VIRTUAL BASADA EN DISPOSITIVO MÓVIL (SISTEMA DE DETECCIÓN DE PUNTERO LÁSER) Autor: Fernández García, Miguel. Director: Hood, Cynthia. RESUMEN DEL PROYECTO Este proyecto consiste en la realización de una aplicación móvil para iOS, que permita usar

un puntero láser como sistema para controlar e interaccionar con una presentación de

diapositivas.

Palabras clave: iOs, Intranet, Wi-Fi.

1. Introducción

Actualmente la educación esta evolucionando, la forma en que los profesores imparten

sus clases y comparten sus conocimientos está mejorando drásticamente debido a la

tecnología. Mediante Internet, se están compartiendo apuntes, ejercicios resueltos,

grabaciones de las clases de los profesores, etc. Las notas las recibes conectándote a la

intranet de tu universidad, y puedes hacer preguntas sobre los deberes o sobre la

lección también mediante tu ordenador desde casa.

Aquí se presenta una tecnología, cuyo objetivo es mejorar la interacción del usuario

con su presentación PowerPoint o cualquier otro tipo de presentación. Esta aplicación

esta encaminada a mejorar la enseñanza y la calidad de cualquier presentación ya sea

en el colegio, universidad o la presentación realizada por una empresa.

2. Definición del proyecto

Se propone la realización de una aplicación móvil y otra de ordenador, que permita la

utilización de un puntero láser como sistema para controlar e interaccionar con una

presentación de diapositivas.

Debido a que la mayor parte de la aplicación de ordenador ya había sido desarrollada

con anterioridad, este proyecto se centra en el desarrollo de la aplicación móvil para

iOS. Además se han incluido una serie de funciones nuevas a la aplicación de

ordenador, las cuales también serán descritas aquí.

3. Descripción del sistema

La idea principal del proyecto es situar el teléfono móvil (mediante la utilización de un

soporte) en frente de donde el proyector donde se están representando las diapositivas,

y mientras llevas acabo tu presentación, podrás usar el puntero laser para dibujar

distintas figuras o realizar una serie de acciones, por ejemplo recuadrar una fórmula

importante o pasar de diapositiva. El móvil hará uso de la cámara para reconocer

formas o acciones realizadas por el usuario mediante el láser (acciones realizadas en

donde se proyecten las diapositivas), para luego enviárselas al ordenador, donde

tendrán lugar una serie de procesamientos, y este representará lo pintado por el usuario

o realizará la acción indicada.

Ilustración 1. Esquema del funcionamiento de la aplicación

4. Resultados y Conclusiones

Se ha conseguido realizar una aplicación innovadora, que cumple todas las funciones

establecidas para este proyecto, es decir, que la aplicación móvil sea capaz de detectar la

posición del puntero láser en tiempo real, mediante el análisis de los fotogramas obtenidos

por la cámara de este. Envie correctamente esta información al ordenador por medio de

Wi-Fi. Además de incluir ciertas mejoras en la aplicación de ordenador, añadiendo un

menu que proporciona nuevas funcionalidades al usuario.

5. Referencias

A continuación se muestran las referencias más importantes:

[1] Stack Overflow questions and answers.

http://www.stackoverflow.com/

[2] Matteo Caldari “Camera capture on iOS”.

https://www.objc.io/issues/21-camera-and-photos/camera-capture-on-ios/

[3] Apple documentation for Swift.

https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Pro

gramming_Language/

BLIPAPP: VIRTUAL BLACKBOARD BASED ON A MOBILE DEVICE (LASER DETECTION SYSTEM) Author: Fernández García, Miguel. Director: Hood, Cynthia. ABSTRACT In this project we propose a system that improves the interaction between the user and

his/her slide presentation. This project involves the implementation of a mobile application

for iOS, which allows the user to use a laser pointer as a system to control and interact with

the presentation.

Keywords: iOs, Wi-Fi.

1. Introduction

Nowadays the education is evolving, the way that teachers share their knowledge is

improving, and this is basically happening because of technology. Through Internet,

you are able to see solved problems, student notes, recordings of teacher’s lectures and

many other teaching materials are being shared. You receive your grades, you upload

your homework and can ask questions to the teacher all online.

What is presented here is a technology used to improve the interaction between the user

and his/her slide presentation, therefore the student’s learning quality and experience

will improve, as well as the quality of the presentations given by companies or by

anyone. This is done by using a mobile and computer application.

2. Proyect definition

The implementation of a mobile and computer application, that allows you to use a

laser pointer as a system to control and interact with the slideshow.

Since most of the computer application had already been developed, this project

focuses on the development of the mobile application for iOS. In addition some new

functions have been added to the computer application. These are also described in the

following proyect.

3. System description

The main idea of this project is to locate a mobile device in front of the board where

the user is projecting the slides. Then while you are carrying out your presentation, you

will be able to use a laser pointer in order to draw different figures (for example a box

around an important formula, underline some text) or do some actions (such as going to

the next or previous slide). When you point with your laser to the slides, the mobile

will gather information about the points you draw, send it to the computer, where some

Machine Learning algorithm will take place, and what you draw will appear in the

presentation slideshows. The application will have two options, to do it in real time, so

that it appears as if you where actually drawing in the slides with your laser pointer,

and not in real time so that it waits until you stop using the laser pointer to recognize

the figure.

Figure 1. Representation of the functioning of the app

4. Results and conclusions

An innovative application that satisfies all the requirements for this project has been

created. The mobile application is able to detect the position of the laser pointer in real

time, by analyzing the frames obtained by the camera and correctly send this

information to the computer via Wi-Fi. In addition certain improvements have been

made to the computer application, such as adding a menu that provides new

functionalities to the user.

5. References

Some of the most important references are the following:



[2] Matteo Caldari “Camera capture on iOS”.



https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Pro

gramming_Language/

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)


ÍNDICE DE LA MEMORIA

I

Índice de la memoria

Capítulo 1. Introducción .................................................................................................... 71.1 Motivación del proyecto ........................................................................................................ 81.2 Problemas abordados ............................................................................................................. 91.3 Herramientas utilizadas ....................................................................................................... 101.4 Tecnologías y herramientas de desarrollo ........................................................................... 11

Capítulo 2. Estado de la Cuestión .................................................................................... 132.1 Competidores ....................................................................................................................... 132.2 Ventajas y desventajas frente a competidores ..................................................................... 162.3 Análisis de mercado ............................................................................................................. 17

2.3.1 Grupo 1 (individuales) .................................................................................................... 182.3.2 Grupo 2 (Compañías) ..................................................................................................... 19

2.4 Análisis dafo ........................................................................................................................ 20

Capítulo 3. Definición del Trabajo .................................................................................. 253.1 Justificación ......................................................................................................................... 253.2 Objetivos .............................................................................................................................. 253.3 Metodología ......................................................................................................................... 263.4 Planificación y Estimación Económica ............................................................................... 30

Capítulo 4. Sistema Desarrollado .................................................................................... 334.1 Aplicación de ordenador ...................................................................................................... 334.2 Aplicación móvil ................................................................................................................. 38

4.2.1 Obtención de los fotogramas .......................................................................................... 394.2.2 Calibración y análisis de los fotogramas ....................................................................... 434.2.3 Conexión ......................................................................................................................... 564.2.4 Interfaz de usuario .......................................................................................................... 58

4.3 Casos de uso ........................................................................................................................ 614.3.1 Diagrama de casos de uso .............................................................................................. 624.3.2 Descripción de los casos de usos .................................................................................... 63

Capítulo 5. Análisis de Resultados ................................................................................... 69



ÍNDICE DE LA MEMORIA

II

Capítulo 6. Conclusiones y Trabajos Futuros ................................................................. 716.1 Conclusiones ........................................................................................................................ 716.2 Trabajos futuros ................................................................................................................... 72

Capítulo 7. Bibliografía .................................................................................................... 75



ÍNDICE DE FIGURAS

III

Índice de figuras

Figura 1. Imagen del dispositivo móvil usado para el desarrollo ........................................ 10

Figura 2. Imagen del puntero láser usado para el desarrollo ............................................... 10

Figura 3. Imagen del soporte utilizado para el desarrollo ................................................... 11

Figura 4. Imagen del ordenador utilizado para el desarrollo ............................................... 11

Figura 5. Imagen del controlador remoto de Targus. .......................................................... 14

Figura 6. Imagen que muestra el funcionamiento de Ubi Microsoft ................................... 14

Figura 7. Muestra de los dos grupos de público objetivo .................................................... 18

Figura 8. Análisis DAFO de BlipApp ................................................................................. 21

Figura 9. Esquema de las distintas fases de desarrollo de software de BlipApp ................. 26

Figura 10. Muestra la correción automática de figuras ....................................................... 34

Figura 11. Interfaz de ordenador con la presentación en pantalla completa ....................... 35

Figura 12. Interfaz de la aplicación de ordenador ............................................................... 37

Figura 13. Aplicación móvil de BlipApp ............................................................................ 39

Figura 14. Representa el funcionamiento de la clase AVCapture Session .......................... 40

Figura 15. Representa un fotograma en el que se observa la primera calibración .............. 44

Figura 16. Patrón encontrado al usar OpenCv para detectar el tablero de ajedrez .............. 46

Figura 17. Representa el algoritmo de análisis de fotogramas ............................................ 48

Figura 18. Representa como se obtienen las coordenadas del buffer de píxeles ................. 51

Figura 19. Muestra el funcionamiento del algoritmo DBSCAN ......................................... 52

Figura 20. Representa lo que se obtiene al aplicar el DBSCAN para corregir el error de los

brillos ................................................................................................................................... 55

Figura 21. Muestra el procedimiento de obtención de datos para la segunda calibración .. 57

Figura 22. Muestra las distintas vistas que existen en la interfaz de usuario de la aplicación

móvil .................................................................................................................................... 59

Figura 23. Casos de uso aplicación móvil ........................................................................... 62

Figura 24. Casos de uso aplicación de ordenador ............................................................... 63

Figura 25. Imagen de BlipApp en funcionamiento ............................................................. 72



ÍNDICE DE FIGURAS

IV



ÍNDICE DE FIGURAS

V

Índice de tablas

Tabla 1. Muestra las diferencias entre BlipApp y sus competidores ................................... 15

Tabla 2. Organización de las distintas etapas de desarrollo ................................................ 30

Tabla 3. Costes de las distintas etapas de desarrollo ........................................................... 32

Tabla 4. Primer caso de uso aplicación móvil ..................................................................... 64

Tabla 5. Segundo caso de uso aplicación móvil .................................................................. 64

Tabla 6. Primer caso de uso aplicación de ordenador ......................................................... 65

Tabla 7. Segundo caso de uso aplicación de ordenador ...................................................... 66

Tabla 8. Tercer caso de uso aplicación de ordenador .......................................................... 66

Tabla 9. Cuarto caso de uso aplicación de ordenador ......................................................... 67



6



INTRODUCCIÓN

7

Capítulo 1. INTRODUCCIÓN

Como todos sabemos, hoy en día la educación que estamos recibiendo es muy diferente de

la recibida por nuestros padres. Gracias a las nuevas tecnologías, como las plataformas en

línea para compartir archivos, videos de clases grabadas o problemas resueltos, la

educación está evolucionando muy rápido.

El uso de smartphones también está aumentando, ya que se están creando nuevas

aplicaciones cada día. Cada vez más personas en todo el mundo están empezando a utilizar

las aplicaciones para ayudarles en su rutina diaria, y para ayudarles a estudiar.

En este proyecto se presenta una tecnología utilizada para mejorar la interacción entre el

usuario y su presentación de diapositivas. Gracias a esta aplicación mejorarán tanto la

calidad del aprendizaje del estudiante como la calidad de las presentaciones realizadas por

las empresas o por cualquiera que la utilice.

La combinación de una aplicación móvil y una de ordenador están siendo utilizado con el

fin de poner en práctica este sistema. La idea principal es que el usuario sea capaz de

controlar su presentación de diapositivas mediante el uso de un puntero láser. Para ello el

usuario tendrá que posicionar el teléfono móvil en frente de donde se proyectan las

diapositivas, de modo que la cámara sea capaz de ver lo que se está dibujando con el láser.

Posteriormente, el móvil envía la información de la posición del láser al ordenador, donde

se realiza el procesamiento de esta información.

Debido a que parte de la aplicación de ordenador ya estaba desarrollada, este proyecto se

centra en el desarrollo de la aplicación móvil para iOS. Además se han introducido una

serie de mejoras en la aplicación de ordenador, que también serán descritas en este

proyecto.



INTRODUCCIÓN

8

1.1 MOTIVACIÓN DEL PROYECTO

Estos últimos 10 años la tecnología a evolucionado de manera increíble, tenemos móviles

que nos pueden llevar a cualquier lado, wearables que nos dicen cuantas calorías hemos

quemado en un día o lo bien que dormimos, etc. Sin embargo las presentaciones llevan

mucho sin mejorar. El presentador llega con su USB o portátil a clase se conecta al

proyector y comienza la presentación tratando de hacer hincapié en distintas partes. Para

pasar las diapositivas tiene que volver al ordenador, a no ser que tenga un mando

inalámbrico para pasar las diapositivas, pero con este mando no puede escribir nada en

ellas, lo que hace que al alumno le cueste más estudiarlas cuando está en casa ya que no se

ha resaltado lo más importante en ellas.

En este proyecto se describe una aplicación que no tiene esos problemas, ya que con ella el

profesor puede pasar de diapositiva en dispositiva, pero además puede pintar en ellas y

crear un pdf con las diapositivas y lo escrito en ellas, facilitando con ello el posterior

estudio de estas.

Algunas de las razones más importantes por las que se ha desarrollado este proyecto, son

las siguientes:

• Enseñanza:

La enseñanza es uno de los aspectos mas importantes de nuestra sociedad, y esta

aplicación busca suponer una mejora en este campo, mejorando la interacción de la

presentación, la atención de los alumnos en clase, y facilitando a los alumnos el

posterior estudio del material.

• Aplicación móvil:

Hoy en día casi todo el mundo tiene un smartphone, por ello se decidió desarrollar

una aplicación móvil de tal manera que el usuario no tuviera que pagar por el

hardware.



INTRODUCCIÓN

9

• Oportunidad de negocio:

Debido a que la tecnología es nueva e innovadora y no tiene competidores directos

(sea por el precio o por las funciones que proporciona), podría suponer una buena

oportunidad de negocio.

1.2 PROBLEMAS ABORDADOS

Este proyecto tenía el propósito de resolver varios problemas, los dos más importantes son

los siguientes:

• Interactividad:

Normalmente la única interacción que hay entre el presentador y su presentación es

el paso de diapositivas si este posee un mando inalámbrico.

• Malas presentaciones:

En la actualidad, algunas de las presentaciones tiene demasiada información. Este

proyecto aborda este problema con la capacidad de hacer hincapié en las partes más

importantes de esta.

• Toma de apuntes:

Muchas veces para los alumnos es difícil tomar apuntes y atender bien a la vez, ya

que se pierden cosas que se están explicando en ese momento por estar acabando de

copiar lo dicho en la anterior diapositiva.



INTRODUCCIÓN

10

1.3 HERRAMIENTAS UTILIZADAS

Para probar el funcionamiento correcto del desarrollo se han utilizado las siguientes

herramientas:

• Móvil:

Para el desarrollo de la aplicación se ha utilizado un IPhone 5c. Ya que se

necesitaba un móvil bastante reciente con sistema operativo iOS, y este modelo era

el más barato.

Figura 1. Imagen del dispositivo móvil usado para el desarrollo

• Puntero láser:

Se ha utilizado el puntero láser que se puede ver en la siguiente imagen. Este

puntero láser ha sido la herramienta que se ha utilizado para interactuar con la

presentación.

Figura 2. Imagen del puntero láser usado para el desarrollo

• Soporte:

Para el funcionamiento correcto de la aplicación, se necesita que el móvil esté en

una posición estática durante toda la presentación, ya que si se desplaza la

calibración que detecta la posición exacta del láser, no funcionará correctamente.



INTRODUCCIÓN

11

Figura 3. Imagen del soporte utilizado para el desarrollo

• Ordenador:

El ordenador utilizado ha sido un MacBook Pro, ya que se necesitaba un ordenador

con el entorno de desarrollo Xcode que te permite crear aplicaciones para iOS.

Figura 4. Imagen del ordenador utilizado para el desarrollo

1.4 TECNOLOGÍAS Y HERRAMIENTAS DE DESARROLLO

• Java:

Java es un lenguaje de programación de propósito general, concurrente, orientado a

objetos que fue diseñado específicamente para tener tan pocas dependencias de

implementación como fuera posible. Su intención es permitir que

los desarrolladores de aplicaciones escriban el programa una vez y lo ejecuten en

cualquier dispositivo, lo que quiere decir que el código que es ejecutado en una

plataforma no tiene que ser recompilado para correr en otra.



INTRODUCCIÓN

12

• JFC/Swing:

JFC es la abreviatura de Java Foundation Classes, que abarcan un grupo de

características para la creación de interfaces gráficas de usuario (GUI) y la adición

de la funcionalidad de gráficos ricos e interactividad a las aplicaciones Java.

• Swift:

Swift es un lenguaje de programación multiparadigma creado por Apple enfocado

en el desarrollo de aplicaciones para iOS y Mac OS X. Está diseñado para

integrarse con los Frameworks Cocoa y Cocoa Touch, puede usar cualquier

biblioteca programada en Objective-C y llamar a funciones de C. Swift tiene la

intención de ser un lenguaje seguro, de desarrollo rápido y conciso.

• Eclipse:

Con el fin de facilitar el desarrollo, y para escribir el código lo más rápido y más

correcta posible, utilizamos Eclipse. En este caso utilizamos Eclipse Kepler liberar

4.3.2. Eclipse es un entorno de desarrollo integrado (IDE), en su mayoría escrito en

Java, que sirve como una plataforma donde se puede desarrollar sus aplicaciones.

Además, se pueden añadir diferentes frascos para su proyecto de manera que se

pueden utilizar diferentes bibliotecas en él.

• Xcode:

Xcode es el entorno de desarrollo integrado (IDE, en sus siglas en inglés) de Apple.

Xcode trabaja conjuntamente con Interface Builder, una herencia de NeXT, una

herramienta gráfica para la creación de interfaces de usuario. Xcode incluye la

colección de compiladores del proyecto GNU (GCC), y puede compilar

código C, C++, Swift, Objective-C, Objective-C++, Java y AppleScript.



ESTADO DE LA CUESTIÓN

13

Capítulo 2. ESTADO DE LA CUESTIÓN

En este segundo capítulo, se van a describir las diferentes ventajas y desventajas de

BlipApp, además de realizar una comparativa entre esta y los diferentes productos que

existen hoy en día. Por último se realizará un análisis de mercado el cual incluirá un

análisis DAFO.

2.1 COMPETIDORES

En los siguientes párrafos se van a analizar tecnologías similares o que pueden ser

competidores indirectos de BlipApp, con el fin de ver cuáles son las mejores oportunidades

de esta y cuáles son las diferencias con las otras aplicaciones.

• Controladores remotos: Hay diferentes tipos de mandos a distancia, todos ellos con el fin

de pasar de una diapositiva a otra mediante un botón, de manera que el presentador no

tiene que estar presionando las flechas en su teclado o el ratón para cambiar la diapositiva.

Esta es una de las tecnologías más utilizadas hoy en día.

• Targus Presentador: ([TARG16]) Esta tecnología también esta destinada a mejorar las

presentaciones, el concepto es simple, este presentador permite controlar el paso de

diapositivas de la presentación de PowerPoint de forma remota, con una tecnología

KeyLock que bloquea los botones no esenciales cuando no se necesitan, para ayudar a

eliminar la posibilidad de pulsar un botón accidentalmente. También tiene integrado un

puntero láser que permite al presentador resaltar el contenido más importante.




14

Figura 5. Imagen del controlador remoto de Targus.

• Ubi: ([UBI16]) Es una aplicación que utiliza el sensor Kinect para Windows y la idea

principal es ser capaz de controlar la presentación mediante el uso de las manos. Usted

sería capaz de tocar en la superficie donde se proyectan las diapositivas, y controlar su

presentación con los dedos. Además se puede ejecutar en modo Ubi pluma y ser capaz de

utilizar un lápiz para dibujar en las diapositivas. Para ello se utiliza el sensor Kinect con el

que se obtiene la ubicación de los dedos de los usuarios. El principal problema de esta

aplicación es que es mucho más cara que la descrita en este proyecto, además de no ser

portable.

Figura 6. Imagen que muestra el funcionamiento de Ubi Microsoft

• PowerPoint Pen: Es una herramienta que se usa con una pantalla táctil donde se puede

rodear, subrayar, dibujar flechas, o realizar anotaciones en las diapositivas. No se puede

cambiar de una diapositiva, y hay que estar al lado de la pantalla táctil todo el tiempo

durante la escritura.




15

• ZoomIt: Esta es otra aplicación de ordenador que se utiliza para dibujar en las

diapositivas, para ello se usa el ratón del ordenador.

Nombre Control

diapositivas

Dibujar Puntero

láser

Portable Precio

BlipApp

Si

Si

Si

Si

25$ aprox.

Controlador

remoto

Si

No

No

Si

15$

Targus

Si

No

Si

Si

70$

Ubi

Si

Si

No

No

Basic:350$

Enterprise:1700$

Pizarras

digitales

Si

Si

No

No

>=5000$

Zoomit

No

Si

No

Si

Gratuita

Tabla 1. Muestra las diferencias entre BlipApp y sus competidores




16

2.2 VENTAJAS Y DESVENTAJAS FRENTE A COMPETIDORES

En este aparatado analizaremos las ventajas y desventajas de BlipApp.

Para empezar, revisaremos las ventajas. Como podemos ver en la tabla de comparación,

este proyecto posee varias ventajas respecto a sus competidores:

1. Precio:

En comparación con los otros, y teniendo en cuenta todas las características que

tiene BlipApp, su precio es mucho más bajo. Cualquier otro producto en el

mercado, que sea capaz de pintar en las diapositivas, es mucho más caro.

2. Portabilidad:

Las tecnologías que permiten pintar y que son directas competidoras de BlipApp,

como Ubi o las pantallas táctiles, no son portables. Es decir que tienen que estar en

una sala instaladas, un consultor no puede llevarse la tecnología para hacerle una

presentación a su cliente en otras oficinas.

3. Memoria:

BlipApp incluye la posibilidad de guardar todo lo que se ha escrito en las

diapositivas durante la presentación. Ninguno de los otros competidores incluyen

esta funcionalidad.




17

A pesar de todas sus ventajas, este proyecto también tiene ciertas desventajas que tienen

que ser resueltas en el trabajo futuro.

1. Brillo:

Al calibrar la aplicación, el móvil utiliza su cámara para obtener el brillo de la

escena. El láser también es detectado mediante el brillo, y por lo tanto si la

proyección es muy brillante, esto puede causar algunos problemas.

2. Conexión:

Si la velocidad de la conexión Wi-Fi es lenta se pueden ver afectada la

funcionalidad de pintado en tiempo real. Por lo tanto hay hacer la conexión entre el

móvil y el ordenador más rápida. Una posible solución es conectar el móvil y el

ordenador mediante un USB que se enchufa en el ordenador y sirve de un punto de

acceso.

3. Escritura:

Escribir con un puntero láser no es muy precioso, y por ello solo sirve para hacer

pequeñas anotaciones. La idea en un futuro es poder sustituir el láser con una

especie de bolígrafo que tenga una luz trasera y con ello conseguir una escritura

mucho más precisa.

2.3 ANÁLISIS DE MERCADO

Este apartado define el público objetivo de esta aplicación. Se han identificado segmentos

de mercado con necesidades similares, con el objetivo de realizar una estrategia de

marketing que se ajuste a las expectativas de los consumidores de cada sector. El público

objetivo se ha divido principalmente en dos grupos.




18

Figura 7. Muestra de los dos grupos de público objetivo

2.3.1 GRUPO 1 (INDIVIDUALES)

Individuales como son consultores, profesores o cualquiera que de una presentación a

diario. Podrán elegir entre nuestra aplicación gratis o la Premium obteniendo así todas las

ventajas y funciones de esta. Se han clasificado de la siguiente manera:

1. Profesores: A los profesores se les suele proporcionar un ordenador y un proyector

para dar la clase, pero si quieren un mando para pasar diapositivas o alguna otra

tecnología que mejore sus clases, normalmente se la tienen que comprar ellos.

Estos podrían ser una manera estupenda de promocionar BlipApp, y con su apoyo

sería más fácil vendérselo a una escuela o universidad para que lo instancie en

todas sus aulas.

2. Consultores: Sólo en España el sector de la consultoría emplea aproximadamente a

140,000 personas, si sólo un 10% de estos dan presentaciones a menudo, existirían

14,000 clientes potenciales. Los consultores tienen que presentarles distintas

propuestas e ideas a sus clientes, de nuevo la mejora en interacción y control de las




19

presentaciones ofrecida por esta aplicación, ayudará a sus clientes a comprender de

manera más fácil sus propuestas, facilitándoles así el conseguir el proyecto.

3. Estudiantes: Estos normalmente tienen una serie de proyectos que suelen incluir el

realizado de alguna presentación. Con esta aplicación conseguirán presentaciones

que destacan, haciéndolas más interactivas y consiguiendo una mayor atención por

parte de sus compañeros.

Este primer grupo conllevará parte de las ganancias de BlipApp y además son una manera

espléndida de llegar a este segundo grupo, que es del cual más se puede beneficiar esta

compañía.

2.3.2 GRUPO 2 (COMPAÑÍAS)

Este segundo grupo son las compañías, grandes empresas e instituciones que presentan

productos diariamente a sus clientes, compañías que organizan conferencias, y compañías

del sector de la educación. A continuación se describen estas de manera detallada:

1. Sector educativo: El sector de la educación contiene un Mercado extenso, con más

de 38 millones de clases y 1,5 billones de estudiantes matriculados y profesores

alrededor del mundo. Las universidades invierten 20% de su presupuesto en

innovación o rehabilitación. Alrededor de España existen más de 80 universidades

y en otros países como Estados Unidos los números son mucho mayores llegando a

más de 4000 Universidades (4140) combinando sector público y privado. Tampoco

hay que olvidarse de las escuelas, tan sólo en Madrid hay aproximadamente 1650

escuelas privadas, las cuales serían también una buena fuente de ingresos.

El mercado de la educación es una de las mejores oportunidades de implementar

BlipApp, ya que las universidades y colegios siempre buscan la mejora de sus

métodos educativos para estudiantes actuales y para la captación de nuevos

estudiantes.




20

2. Compañías privadas: Otro posible cliente son las compañías privadas. Estas ya

están gastando actualmente muchísimo dinero en mejorar sus instalaciones para dar

presentaciones. BlipApp ofrece una solución barata comparada con Ubi-Interactive

o las pizarras electrónicas.

Este mercado también es enorme, en España hay más de 3 millones de empresas y

aproximadamente 20,000 son medianas (50-250 empleados) y grandes (más de 250

empleados) y la mayoría dan presentaciones a diario. Además las compañías gastan

más dinero y tienen menos limitaciones de presupuesto que las universidades.

3. Conferencias: También se podría usar en distintas conferencias o eventos como las

TEDx talks, o cualquier otro evento que se lleve a cabo en grandes auditorios.

2.4 ANÁLISIS DAFO

El análisis DAFO (alternativamente llamado SWOT en inglés) es un método de

planificación estructurado que se usa para evaluar las debilidades, amenazas, fortalezas y

oportunidades que existen en un proyecto. Este análisis incluye una identificación de los

factores internos y externos que pueden favorecer o no a que un proyecto pueda conseguir

su objetivo.




21

A continuación se presenta el análisis DAFO realizado para BlipApp:

Figura 8. Análisis DAFO de BlipApp

Debilidades:

• El dibujar no es tan preciso como cuando usas bolígrafo táctil (como el usado en las

pizarras electrónicas).

• Lleva un poco más de tiempo ponerlo en marcha que un mando para pasar

diapositivas, aproximadamente 2 minutos más.

• El móvil necesita conexión WiFi para poder enviar la información al ordenador.

• Si se usa durante bastante tiempo (alrededor de 4 o 5 horas) podría gastar la batería

del móvil.




22

Amenazas:

• La educación es un mercado al que es difícil entrar, porque normalmente a la gente

no le gustan los cambios.

• Aunque sea un producto patentado, si la aplicación no se desarrolla lo

suficientemente rápido con el objetivo de llegar al mercado lo antes posible, es

probable que aparezcan imitadores y puedan conseguir parte de nuestro público

objetivo.

Fortalezas:

• Producto innovador: El núcleo del producto y de la compañía es la innovación.

Muchas ideas ya están instanciadas, pero muchas otras aún están por venir.

• Aplicación móvil: El hecho de que hoy en día casi todo el mundo tiene un

Smartphone, hace que los usuarios puedan fácilmente obtener esta aplicación y

utilizarla.

• Mejora el aprendizaje y la atención: Visualmente atractiva para los oyentes y el

hecho de que se puedan guardar las anotaciones, además de conseguir

explicaciones más visuales, mejora todo el proceso de aprendizaje.

• Portable: Se puede llevar a cualquier lado, sólo se necesita un Smartphone, un

puntero láser y un soporte para el móvil. El poder crear una pizarra interactiva,

aunque sea en un gran auditorio, es una gran ventaja.

• Los competidores similares existentes son mucho más caros.

Oportunidades:

• Cualquiera que de una presentación a diario es un usuario potencial, además de

compañías, universidades y colegios.

• El hecho de que los móviles están mejorando muy rápidamente proporcionará la

oportunidad de crear nuevas e increíbles funciones.




23

• Crowd funding es ahora mismo una de las mejores opciones para que

emprendedores obtengan financiación, pudiendo llevar al mercado aplicaciones

como esta de manera más fácil.




24



DEFINICIÓN DEL TRABAJO

25

Capítulo 3. DEFINICIÓN DEL TRABAJO

Este capítulo comienza justificando la compra del producto, posteriormente se describirán

los objetivos del proyecto, cual ha sido el camino seguido para conseguirlos y se realizará

una estimación de coste de desarrollo del producto.

3.1 JUSTIFICACIÓN

Como se ha observado en el análisis realizado en el apartado anterior, BlipApp tiene varias

ventajas sobre sus competidores. Los que tienen un precio similar a BlipApp no ofrecen

muchas funciones que esta si posee, y las otras son muy caras, no son portátiles, o

sencillamente no se pueden usar en una serie de sitios. Por ejemplo las pizarras virtuales

sólo se pueden usar en clases pequeñas (no más grandes de 30 metros cuadrados si cabe),

dejando aulas de 60 estudiantes o espectadores fuera del público objetivo. Esto quiere decir

que la única tecnología interactiva que se puede implementar en auditorios es BlipApp.

Esto crea la situación perfecta para esta aplicación, en la que no tiene ningún competidor

directo, además de que opera en un mercado (como es el mercado de aplicaciones móviles)

que está creciendo de manera exponencial y genera cantidades astronómicas de dinero.

Todo esto sin incluir el hecho de que el crecimiento del número de usuarios con teléfonos

inteligentes (Smartphone), facilita la distribución de la aplicación.

3.2 OBJETIVOS

El principal objetivo de este proyecto es desarrollar la aplicación móvil de BlipApp para

iOS, es decir, una aplicación móvil que sea capaz de detectar un puntero láser en tiempo

real y pueda enviar esa información a la aplicación de ordenador por medio de una

conexión Wi-Fi. Además se introducirán una serie de mejoras en la aplicación de

ordenador, como son una serie de nuevas funcionalidades que mejorarán la experiencia de

usuario.




26

A continuación se muestra una lista de los objetivos que hay que cumplir:

- Implementar la interfaz de la aplicación móvil.

- Implementar una serie de calibraciones que permiten detectar el puntero láser.

- Detectar el láser en tiempo real mediante el análisis de los fotogramas.

- Crear una conexión Wi-Fi mediante la que puedan intercambiar información la

aplicación de ordenador y la de móvil.

- Añadir varias funcionalidades a la aplicación de ordenador.

3.3 METODOLOGÍA

La metodología de desarrollo de software utilizada para el desarrollo del proyecto es

el desarrollo en cascada [2], también llamado modelo en cascada, y es el enfoque

metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de

software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa

anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión

final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente

fase.

Figura 9. Esquema de las distintas fases de desarrollo de software de BlipApp




27

El desarrollo del proyecto se ha dividido en varias fases. A continuación se va a describir

lo que ha sido implementado en cada una de ellas: �

1. Etapa de análisis de requisitos: Durante esta etapa se analizan los distintos

requisitos que la aplicación tiene que tener, para satisfacer las necesidades de los

usuarios finales del software.

2. Etapa de análisis del desarrollo: Durante esta etapa las diferentes necesidades del

proyecto y cómo se van a desarrollar son estudiados, con el fin de hacer este

modelo el dominio tiene que ser creado, así como los modelos de casos de uso.

3. Etapa de implementación de las nuevas funcionalidades de la aplicación de

ordenador: En esta etapa se desarrollarán y se añadirán a la interfaz de ordenador

una serie de nuevas funcionalidades que se explicarán en el siguiente capítulo.

4. Etapa de implementación de la interfaz de la aplicación móvil: Durante esta etapa

se creará la interfaz de la aplicación móvil.

5. Etapa de análisis de los fotogramas: El objetivo de esta etapa es conseguir analizar

el brillo que tiene cada pixel en los fotogramas obtenidos desde la cámara.

6. Etapa de implementación de la conexión: Durante esta etapa, se implementará una

conexión Wi-Fi entre el móvil y el ordenador, que se utilizará para enviar

información acerca de la calibración y sobre los puntos obtenidos de la posición del

láser.




28

7. Etapa de desarrollo de la calibración: En esta etapa es necesario implementar dos

calibraciones distintas, una que obtenga el brillo de la escena y otra para fijar la

posición de la pantalla en la que se puede reconocer el láser.

8. Etapa de reconocimiento del láser: Una vez ya se han hecho ambas calibraciones,

el objetivo es analizar cada fotograma rápidamente para obtener la posición a la que

el usuario esta apuntando el láser, mandando posteriormente esa información al

ordenador.

9. Etapa de implementación del algoritmo de clustering DBSCAN: Por último, y para

evitar que haya problemas en la calibración debido a un brillo en la pantalla, se

implementará el algoritmo DBSCAN consiguiendo con el agrupar los puntos

brillantes en clusters, evitando así el fallo en la calibración.

Por último, se realizarán una serie de etapas de verificación o testing, donde se comprobará

el correcto funcionamiento del código, además de corregir todos los fallos que se observen

durante esta etapa.

Nombre

Fecha de inicio

Fecha de fin

Número de horas

Etapa de análisis

de requisitos

10-04-2016

13-04-2016

8h * 3 = 24h

Etapa de análisis

del desarrollo

14-04-2016

16-04-2016

6h * 2 = 12h




29

Etapa de

implementación

funcionalidades

ordenador

17-04-2016

25-04-2016

6h * 8 = 48h

Etapa de

implementación de

la interfaz de la

aplicación móvil

26-04-2016

5-05-2016

6h * 9 = 54h

Etapa de análisis

de los fotogramas

6-05-2016

12-05-2016

6h * 6 = 36h

Etapa de

implementación de

la conexión

13-05-2016

17-05-2016

6h * 4 = 24h

Etapa de desarrollo

de la calibración

18-05-2016

7-06-2016

6h * 20 = 120h

Etapa de

reconocimiento del

8-06-2016

26-06-2016

4h * 18 = 72h




30

láser

Etapa de

implementación de

DBSCAN

27-06-2016

11-07-2016

3h * 11 = 33h

Verificación

12-07-2016

22-07-2016

2h * 10 = 20h

TOTAL

10-04-2016

22-07-2016

443h

Tabla 2. Organización de las distintas etapas de desarrollo

3.4 PLANIFICACIÓN Y ESTIMACIÓN ECONÓMICA

En este apartado se ha realizado una estimación del coste de desarrollo del proyecto. A

continuación se muestran los distintos gastos que se han realizado:

- Un ingeniero junior de desarrollo de software cobra alrededor de 30$ la hora.

- Teniendo en cuenta los gastos adicionales de internet y electricidad,

consideraremos un total de 32$ la hora.

- La compra de un iPhone 5c son aproximadamente 120$ por Ebay.

- La compra de un puntero láser y un soporte son 15$ por Amazon.

- No se tiene en cuenta el precio del ordenador.




31

Nombre

Fecha de inicio

Fecha de fin

Número de horas

Etapa de análisis

de requisitos

10-04-2016

13-04-2016

768$

Etapa de análisis

del desarrollo

14-04-2016

16-04-2016

384$

Etapa de

implementación

funcionalidades

ordenador

17-04-2016

25-04-2016

1536$

Etapa de

implementación de

la interfaz de la

aplicación móvil

26-04-2016

5-05-2016

1728$

Etapa de análisis

de los fotogramas

6-05-2016

12-05-2016

1152$




32

Etapa de

implementación de

la conexión

13-05-2016 17-05-2016 768$

Etapa de desarrollo

de la calibración

18-05-2016

7-06-2016

3840$

Etapa de

reconocimiento del

láser

8-06-2016

26-06-2016

2304$

Etapa de

implementación de

DBSCAN

27-06-2016

11-07-2016

1056$

Verificación

12-07-2016

22-07-2016

640$

TOTAL

10-04-2016

22-07-2016

14176$

Tabla 3. Costes de las distintas etapas de desarrollo

La estimación económica del proyecto asciende a 14176$, más los gastos incurridos en la

tecnología anteriormente mencionada, alcanza un total de 14311$.



SISTEMA DESARROLLADO

33

Capítulo 4. SISTEMA DESARROLLADO

Al principio de este capitulo se da una descripción detallada de cómo funciona cada una de

las partes de la aplicación. Posteriormente se describe de manera general el proyecto, y

como interaccionan unas clases con otras.

4.1 APLICACIÓN DE ORDENADOR

La mayor parte de la aplicación de ordenador de BlipApp ya había sido desarrollada en un

proyecto anterior, por ello en este documento no se describe su implementación. Sin

embargo en este proyecto se le han añadido varias mejoras que se describirán en los

siguientes apartados.

La aplicación de ordenador recibe la información enviada por el móvil, la analiza, y realiza

las acciones indicadas por el usuario con el puntero láser. Estas son las funciones que

habían sido previamente implementadas en la aplicación:

• Función de pintado:

El móvil reconoce donde está el usuario apuntando con el láser, y pasándole la

información al ordenador, se consigue en tiempo real el efecto de estar pintando en

las diapositivas con el puntero láser. Debido a que dibujar con un puntero láser no

es muy preciso, se desarrollaron una serie de procesos capaces de reconocer un

conjunto de formas típicas, como son líneas, cuadrados, triángulos y círculos. Esto

hace que cuando por ejemplo el usuario quiera recuadrar una fórmula, pinte un

cuadrado que no será perfecto, pero gracias a esta función de aprendizaje

automático (machine learning) la aplicación lo reconocerá y lo corregirá.

Además, este reconocimiento de formas, permite añadir funcionalidades al láser

para realizar otra serie de acciones, ya que se pueden asignar acciones a formas

dibujadas.




34

Figura 10. Muestra la corrección automática de figuras

• Función de borrado:

Al apuntar a la esquina superior izquierda (donde hay un icono de una basura), se

borrará todo lo anteriormente pintado.

• Función de control de la presentación:

Con el puntero láser se puede controlar el cambio de diapositivas, como se haría

con cualquier mando de control remoto para pasar de diapositivas.

• Generación de PDF:

Como esta aplicación también está orientada para el uso en universidades y

colegios, se le añadió esta función. Gracias a ella se puede generar un documento

PDF con las diapositivas y lo que ha escrito o resaltado el profesor en estas, con el

que los estudiantes recordarán mejor lo que se ha tratado en clase, mejorando con

esto su aprendizaje.

Todas las funciones que se han añadido en este proyecto forman parte de la interfaz de

usuario. Las siguientes funciones son las que se han desarrollado en este proyecto.




35

• Control del cursor:

Función que permite al usuario controlar el cursor del ratón con el láser, habilitando

con ello muchas funciones más. Mientras el usuario vaya pintando con el láser,

también irá moviendo el cursor, de manera que el usuario pueda ver fácilmente

donde está apuntando.

• Menú interactivo:

Se ha creado un menú en el que hay una serie de botones, que el usuario puede

seleccionar usando el láser. A continuación se muestra en la Figura 11 una imagen

del menú:

Figura 11. Interfaz de ordenador con la presentación en pantalla completa

Como se puede observar en la imagen anterior, se han añadido 3 botones al menú, y

las funcionalidades de cada uno de ellos se explica a continuación:

1. Parar de pintar: Este botón se ha añadido para que el usuario pueda

indicar cosas con el cursor pero que necesariamente no tenga que pintar.




36

Cuando el usuario seleccione este botón desaparecerá la “X” que hay en

el, y el usuario podrá mover el cursor sin pintar.

2. Nueva diapositiva: Al seleccionar este botón, se creará una nueva

diapositiva en la presentación, de tal manera que el usuario pueda

explicar algo en una diapositiva en blanco, y luego esto se guarde en el

PDF final.

3. Cambio de color: Este botón sirve para cambiar el color con el que se

está pintando en la presentación. Ahora mismo se puede seleccionar

entre los colores verde, azul y rojo. Para ello, cuando el usuario

mantenga apuntando el láser encima de ese botón, los colores que

aparecen en el botón irán cambiando y para seleccionar un color el

usuario deberá dejar de apuntar al botón.

• Función de pantalla completa:

La aplicación de ordenador se desarrolló, como un panel transparente que se puede

poner encima de cualquier aplicación, de tal manera que se pudiera usar no sólo

con PowerPoint, si no con otros programas de presentaciones, o también para poder

dibujar encima de un PDF o en una página web.

Debido a como esta implementada, el usuario no puede presionar ningún botón que

esté detrás de este panel. Por ejemplo para poner la pantalla completa en

PowerPoint, se usaba la clase Robot. Esta clase la proporciona Java para poder

generar eventos nativos del sistema con los que puedes controlar los inputs del

ratón y del teclado. Por ello para conseguir la pantalla completa se accionaba el

comando para pantalla completa, estando seguros de que el input lo recibía

PowerPoint.




37

Esto ocasionaba un problema, que cuando el usuario salía de pantalla completa en

PowerPoint, para poder mostrar un vídeo de YouTube o una página web, no podía

volver a pantalla completa, ya que cuando abría BlipApp otra vez, no podía

presionar el botón de pantalla completa en PowerPoint. Para solucionar esto, había

que crear un botón en BlipApp, que pudiera presionar el usuario y que le devolviera

a pantalla completa. A continuación se muestra una captura de pantalla de la

interfaz donde se puede observar este botón de color verde en la esquina superior

izquierda:

Figura 12. Interfaz de la aplicación de ordenador

Para hacerlo en MacOS fue fácil, cuando el usuario presiona el botón, se da la

orden de volver a abrir la misma presentación, el sistema operativo detecta que eso

ya está abierto, pone el foco sobre PowerPoint y usando la clase Robot se acciona el

comando de pantalla completa. Sin embargo, para hacerlo en Windows esto no

funcionaba, entonces se tuvo que usar una librería para Java llamada JNA [6] (Java

Native Access) con la que un programa Java pueda realizar llamadas nativas al

sistema de Windows. Con esto se detectaban todos los programas que estaban

abiertos en ese momento, y se filtraba buscando el PowerPoint, consiguiendo con




38

esto traer el foco de vuelta a PowerPoint para poder ejecutar el comando de pantalla

completa. El siguiente es el código que se usó para conseguir ese comportamiento:

public void showPPWindow(){ final User32 user32 = User32.INSTANCE; user32.EnumWindows(new WNDENUMPROC() { int count = 0; @Override public boolean callback(HWND hWnd, Pointer arg1) { byte[] windowText = new byte[512]; user32.GetWindowTextA(hWnd, windowText, 512); String wText = Native.toString(windowText); //To remove windows that don't have any text if (wText.isEmpty()) { return true; } if(wText.contains("PowerP")) { User32.INSTANCE.ShowWindow(hWnd, 9 ); // SW_RESTORE User32.INSTANCE.SetForegroundWindow(hWnd); } return true; } }, null); }

4.2 APLICACIÓN MÓVIL

Una aplicación móvil es un tipo de aplicación software diseñada para funcionar en un

dispositivo móvil, como un smartphone o una tablet. Las aplicaciones móviles con

frecuencia sirven para proporcionar servicios similares a los existentes en los ordenadores.

Las aplicaciones son unidades de software en general pequeñas, individuales y con función

limitada.

BlipApp es parte del mundo de aplicaciones móviles y está diseñada para funcionar

principalmente en dispositivos móviles, pero también podría funcionar en tablets. Utiliza la




39

pantalla táctil para interaccionar con el usuario y la cámara para el reconocimiento de los

puntos.

Figura 13. Aplicación móvil de BlipApp

Con el objetivo de mejorar el entendimiento sobre el porque de las distintas partes de la

aplicación, en el siguiente párrafo se va a describir el funcionamiento de la aplicación

móvil, de manera general.

Para empezar, el móvil va a estar situado en frente de donde se proyectan las diapositivas

con la cámara apuntando hacia ellas. De tal manera que después de un proceso de

calibración sea capaz de detectar hacia donde está apuntado el láser el usuario. Esta

información será enviada al ordenador mediante la conexión Wi-Fi y el ordenador

representará lo pintado o realizará las acciones indicadas por el usuario.

4.2.1 OBTENCIÓN DE LOS FOTOGRAMAS

El objetivo principal de esta aplicación es ser capaz de reconocer el láser, para ello la única

forma es usar la cámara y analizar cada uno de los fotogramas buscándolo. En los

siguientes párrafos se describirá la implementación que se ha seguido para obtener los

resultados deseados.




40

Para gestionar la captura de un dispositivo, como una cámara o un micrófono, se utiliza

una instancia de AVCaptureSession para coordinar el flujo de datos entre un dispositivo de

entrada (la cámara en este caso) y un dispositivo de salida. En este caso los objetos de

salida son tres, AVCaptureVideoPreviewLayer (que es el que se utiliza para mostrar la

cámara al usuario en la aplicación móvil), AVCaptureStillImageOutput (que se utiliza para

hacer una foto a lo que está viendo la cámara, esta foto se utilizará en la calibración

posteriormente) y AVCaptureVideoDataOutput (que es la clase que produce los fotogramas

que luego tendremos que analizar).

Figura 14. Representa el funcionamiento de la clase AVCapture Session

A continuación se muestra para del código que se utiliza para enlazar la sesión con las

entradas y salidas especificadas:

let backCameraDevice = AVCaptureDevice.defaultDeviceWithMediaType(AVMediaTypeVideo) //Uso try porque el método tiene un throw let input = try? AVCaptureDeviceInput(device: backCameraDevice) if (input != nil && session?.canAddInput(input) != nil){




41

//le metes su input a la session y luego lo tienes que juntar con su output session?.addInput(input) //Esto solo se crea para posteriormente chequear si puedes añadir el output stillImageOutput = AVCaptureStillImageOutput() stillImageOutput?.outputSettings = [AVVideoCodecKey : AVVideoCodecJPEG] if (session?.canAddOutput(stillImageOutput) != nil) { session?.addOutput(stillImageOutput) //The AVCaptureVideoPreviewLayer will automatically display the output from the camera previewLayer = AVCaptureVideoPreviewLayer(session: session)

Una vez se han agregado a la sesión los dispositivos de entrada y salida, a continuación se

inicia el flujo de datos mediante el envío de un mensaje de la sesión startRunning, y

detener el flujo de datos mediante el envío de un mensaje stopRunning.

//empiezas el data flow between input and output devices session!.startRunning() //stop session session!.stopRunning() Una vez creamos una instancia de la clase AVCaptureVideoDataOutput, tenemos que

indicarle en que formato queremos que nos devuelva los fotogramas de los siguientes

posibles:

- BGRA: un solo plano en el que se almacenan los valores de color azul, verde y rojo

además de un valor alfa en un número entero de 32 bits cada uno.

- 420YpCbCr8BiPlanarFullRange: Dos planos, el primero que contiene un byte para

cada píxel con el valor de Y (luma), el segundo contiene los valores de Cb y Cr

(croma) para los grupos de píxeles.




42

- 420YpCbCr8BiPlanarVideoRange: El mismo que 420YpCbCr8BiPlanarFullRange

pero los valores de Y se limitan a la gama de 16 a 235 (por razones históricas).

BGRA es el formato más simple, y es el que se utilizaría si no nos importara la velocidad

(o frecuencia máxima obtención de fotogramas) y si estuviéramos interesados en el color.

Sin embargo, para nosotros es muy importante la velocidad y por ello se ha elegido uno de

los dos formatos nativos de video ya que son más eficientes. En nuestro caso se ha elegido

el tercer formato y en el siguiente código podemos observar como se inicializa el objeto

AVCaptureVideoDataOutput para que nos devuelva los fotogramas en ese formato.

//inicializas AVCaptureVideoDataOutput que es la clase que produces video frames suitable for processing videoOutput = AVCaptureVideoDataOutput() videoOutput?.videoSettings=[(kCVPixelBufferPixelFormatTypeKey as NSString) : NSNumber(unsignedInt: kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange)]

Posteriormente nuestra clase tendrá que extender el delegate

AVCaptureVideoDataOutputSampleBufferDelegate, para que podamos implementar el

método captureOutput(…) en el cual recibiremos un buffer o matriz de píxeles que

representan el fotograma obtenido por la cámara.

Como se indicó antes el formato en el que recibimos el buffer contiene dos planos, uno con

un byte para el valor luma (Y) y otro con los valores Cb y Cr que son los componentes

de crominancia diferencia de azul y diferencia de rojo, respectivamente. Estos dos últimos

no se utilizan, ya que nosotros nos vamos a centrar en el valor luma, que es la componente

que codifica la información de luminosidad de la imagen. La luminosidad, es una

propiedad de los colores que da una indicación sobre el aspecto luminoso del color

estudiado: cuanto más oscuro es el color, la luminosidad es más débil.

La luminosidad es un atributo básico para BlipApp, debido a que como el láser es muy

brillante, la mejor manera de reconocer los puntos, es a través de este atributo. Por lo tanto

utilizaremos el valor luma que contiene cada píxel del buffer para detectar el láser. En el




43

siguiente código se muestra parte de la implementación del método captureOutput, donde

se obtiene el buffer:

//This function will be called each time AVCaptureVideoDataOutput instance outputs a new video frame func captureOutput(captureOutput: AVCaptureOutput!, didOutputSampleBuffer sampleBuffer: CMSampleBuffer!, fromConnection connection: AVCaptureConnection!) { let pixelBuffer : CVPixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer)! //devuelve CVImageBuffer? //You must call the CVPixelBufferLockBaseAddress function before accessing pixel data with the CPU CVPixelBufferLockBaseAddress(pixelBuffer, 0) //For planar buffers, this function(la de arriba) returns a rowBytes value such that bytesPerRow * height covers the entire image bytesPerRow = CVPixelBufferGetBytesPerRowOfPlane(pixelBuffer, 0) height = CVPixelBufferGetHeightOfPlane(pixelBuffer,0) //returns a pointer to the pixel at (0,0) in the buffer //We pick the first plane (0). The Y component in YUV determines the brightness of the color (referred to as luminance or luma). Luma has values between 16-235 let byteBuffer=UnsafeMutablePointer<UInt8>(CVPixelBufferGetBaseAddressOfPlane(pixelBuffer, 0))

Primero se obtiene el buffer de la imagen y luego nos quedamos con el primer plano de ese

buffer, que como se describió anteriormente, es el que nos interesa porque contiene los

valores luma.

De este plano obtenemos el número de bytes que hay por cada fila (bytesPerRow) y el

número de filas que hay (height). Estos dos parámetros se usarán posteriormente para

obtener las coordenadas de los puntos que hay en el buffer.

4.2.2 CALIBRACIÓN Y ANÁLISIS DE LOS FOTOGRAMAS

Este proyecto consta de dos etapas de calibración, cuyo objetivo es hacer posible la

detección del puntero láser en tiempo real.




44

La primera calibración es necesaria para hacer una conversión entre los puntos que se

detectan en la pantalla donde se están proyectando las diapositivas y los puntos que se

representan en el ordenador, en definitiva busca reconocer en el fotograma la posición de

la pantalla en la que se están proyectando las diapositivas.

La segunda se utiliza para ser capaz de reconocer la posición a la que el usuario está

apuntando el láser. Para ello se hace uso del brillo de este, que normalmente tiene un valor

luma más alto que cualquier otro valor en el fotograma.

En los siguientes párrafos se describirán detalladamente cada una de ellas.

4.2.2.1 Calibración de la pantalla

El objetivo principal de esta primera calibración es detectar donde está la pantalla de

proyección en el fotograma. En la siguiente figura se muestra un imagen en la que se

explica esto:

Figura 15. Representa un fotograma en el que se observa la primera calibración




45

Esta imagen representa un fotograma obtenido por la cámara (es decir, que esto es lo que

esta viendo la cámara del móvil). El fotograma está representado con el rectángulo de color

rosa y la pantalla de proyección se representa con uno de color verde. Como se ha dicho

antes buscamos hallar los cuatro puntos que representan el rectángulo verde, consiguiendo

con ello:

1. Poder hacer una conversión entre el punto en el fotograma y el punto que será

representado en la pantalla del ordenador.

2. Poder agilizar mucho el análisis del fotograma en busca de el puntero láser, ya que

en vez de analizar todos los píxeles del fotograma buscando los puntos brillantes,

sólo necesitamos analizar los que estén dentro del rectángulo verde.

Para detectar la posición del rectángulo verde se ha utilizado una librería llamada OpenCV,

la cual contiene una serie de algoritmos de “computer vision”. Para ello la aplicación de

ordenador muestra un tablero de ajedrez al inicio de la calibración, cuando esto sucede el

móvil realiza una foto y se la manda al ordenador.

Para que mientras se realiza la foto, se vayan analizando los fotogramas en la segunda

calibración, se utiliza una clase que se ha creado llamada Dispatch. Esta clase utiliza el

GDC (Grand Central Dispatch), que es una capa intermedia que proporcionan las librerías

de iOS, que se encarga de gestionar, crear, destruir y ver donde corre cada thread. Para

utilizarla, en la clase Dispatch se crea una cola con bloques de código que necesitamos

ejecutar y el GDC se encarga de crear los threads necesarios y correr el código.

Una vez el ordenador recibe la imagen, la analiza y envía al móvil la información sobre

donde están todos los puntos que se muestran en la siguiente imagen además de el tamaño

de los cuadrados.




46

Figura 16. Patrón encontrado al usar OpenCv para detectar el tablero de ajedrez

Como se puede observar una vez se obtienen todos esos puntos y el tamaño de los

cuadrados se puede fácilmente obtener el tamaño de la pantalla de proyección (rectángulo

verde). La parte de la aplicación de ordenador que analiza la imagen con OpenCV y

devuelve los puntos ya había sido implementada anteriormente y no forma parte de este

proyecto.

Una vez tenemos el rectángulo verde, tenemos que ir analizando los píxeles que están

dentro de este, en cada fotograma. Esto se lleva a cabo con el siguiente código:

//It only checks inside the calibrated region for var i:Int in cornerY1*bytesPerRow+cornerX1...cornerY3*bytesPerRow+cornerX3{

//x coordinate of the byte being analyzed x = i % bytesPerRow //so that it does not check the sides out of the calibrated region if(x > cornerX1 && x < cornerX3){ lumaValue = Int(byteBuffer[i]) //Looks for the brightest point in all the buffer if(lumaValue>brightness){ //to see if the points are inside the cluster if(insideRedZone(i)){ if(!insideCluster(i)){ index = i brightness = lumaValue }




47

}else{ index = i brightness = lumaValue } } }else{ i += bytesPerRow - cornerX3 + cornerX1 } i+=4; } //No point was founded because brightness has not changed if(brightness==barrier){ return nil }else{ foundPoint.setX(index%bytesPerRow) foundPoint.setY(Int(floor(Double(index/bytesPerRow)))) return foundPoint } }

Podemos observar que el bucle for empieza en el punto superior izquierdo del rectángulo

verde y acaba en el punto inferior derecho del mismo. Esto se representa en la siguiente

imagen:




48

Figura 17. Representa el algoritmo de análisis de fotogramas

El bucle for está recorriendo el rectángulo morado y para que no recorra los píxeles que

están a la izquierda o derecha del rectángulo verde, se comprueba que la coordenada x sea

mayor que cornerX1 y menor que cornerX3. Cuando está fuera del verde, se salta hasta el

nuevo píxel que esté dentro del rectángulo. Además se va avanzando en el bucle de cuatro

en cuatro, porque el brillo del láser es mayor que cuatro píxeles, y así conseguimos

optimizar la velocidad de análisis del fotograma. Este método busca encontrar el punto más

brillante del fotograma, ya que ese punto será el láser, a no ser que haya algún brillo en el

rectángulo verde que no vea sea láser y este problema veremos como solucionarlo en la

siguiente calibración.

4.2.2.2 Calibración del brillo ambiente

Como se describió anteriormente, la primera calibración busca el punto más brillante de la

escena y establece el valor luma de este punto como barrera de brillo para el

reconocimiento del láser. Es decir que si posteriormente se detecta un pixel con un valor




49

luma por encima de esa barrera, significará que es el láser. El siguiente código es el que ha

sido usado para obtener la barrera de brillo.

func findBrightestInitialPoint(byteBuffer:UnsafeMutablePointer<UInt8>, camSize:Int)-> Int { var lumaValue=0, bright=0 //I iterate through all the byte array checking for the brightest point for i in 0..<camSize{ lumaValue = Int(byteBuffer[i]) //Looking for the barrier if lumaValue > bright{ bright=lumaValue } ... }

Iteramos sobre el fotograma, que como se dijo anteriormente es un buffer de bytes, donde

cada uno de ellos contiene la información de cada píxel. Y vamos mirando si cada valor

luma es mayor que la barrera (representada por la variable bright) establecida

anteriormente, si lo es, copiamos el valor de ese píxel en la variable bright, si no seguimos

iterando hasta haber comprobado todos los píxeles del fotograma.

El proceso de calibración no sigue avanzando hasta que no se encuentre una barrera brillo

válida.

Uno de los problemas que se encontraron al probar esta aplicación, fue que en algunos

casos cuando la escena es demasiado brillante, es decir, que había alguna zona en el

fotograma en la que había un brillo que era igual o superior al valor luma máximo que

puede tener un píxel, no se podía detectar el láser. Esto es debido a que cuando la barrera

establecida es demasiado alta, la cámara no reconoce ningún punto del láser, ya que la

barrera ya tiene el valor máximo que puede tener un píxel. Esto supone un grave problema,




50

ya que cada vez que esto sucede, la aplicación deja de funcionar. Para solucionar el

problema descrito se ha establecido la siguiente solución.

A la hora de establecer el valor de la barrera, si obtenemos un punto que tiene un valor

luma superior o igual a el valor luma máximo que puede tener cualquier píxel (en este caso

el valor máximo es 235), lo guardamos en un array de puntos brillantes, que luego

procesaremos, y que no serán usados para establecer la barrera (estos puntos demasiado

brillantes los denominaremos “blind spots”). Para ello el código mostrado anteriormente

ahora se convertirá en el siguiente:

for i in 0..<camSize{

lumaValue = Int(byteBuffer[i]) //Looking for the barrier and saving blind spots if lumaValue > bright{ if lumaValue >= brightness_threshold{ //addPoint so that I can create the clusters afterwards addPointBlindspot(i); }else{ bright=lumaValue } } }

Y el método addPointBlindspot es el siguiente:

func addPointBlindspot(index: Int){ let x = index%bytesPerRow let y = Int(floor(Double(index/bytesPerRow))) blind_spot_pixels.append(Point(x: x,y: y)) }

En este método primero se realiza una conversión de la posición del punto en el buffer de

píxeles a un punto con coordenadas. Esto se hace así ya que el buffer es como un array con




51

todos los valores, pero si lo vas cortando y representado como una matriz que tiene de

ancho el número de bytes por fila, para obtener la coordenada “x” realizas el resto entero

de la posición en el array y el número de bytes y para obtener la coordenada “y” en vez de

hacer el resto entero, divides. A continuación se muestra lo descrito con un ejemplo:

Figura 18. Representa como se obtienen las coordenadas del buffer de píxeles

Posteriormente se van añadiendo los puntos al array blind_spot_pixels . Una vez se ha

procesado la imagen y tenemos todos los puntos que son demasiado brillantes en este

array, se llama al método createBlindSpotCorners el cual llama al método DBSCAN que

será encargado de crear clusters con estos puntos.




52

El agrupamiento espacial basado en densidad de aplicaciones con ruido o Density-based

spatial clustering of applications with noise (DBSCAN) es un algoritmo de agrupamiento

de datos (data clustering) propuesto por Martin Ester, Hans-Peter Kriegel, Jörg Sander y

Xiaowei Xu en 1996. Es un algoritmo de agrupamiento basado en densidad (density-based

clustering) porque encuentra un número de grupos (clusters) comenzando por una

estimación de la distribución de densidad de los nodos correspondientes.

El algoritmo DBSCAN es uno de los algoritmos de agrupamiento más usados y citados en

la literatura científica. La idea principal es ir buscando puntos que estén unos de otros a

una distancia máxima ε y estos puntos serán considerados vecinos. Después todos esos

vecinos se agruparán en clusters, y para que se consideren cluster tendrán que tener un

número mínimo de puntos dentro de ellos.

DBSCAN requiere dos parámetros: ε (epsilon) que es la distancia máxima para la cual dos

puntos que estén a esa distancia uno de otro serán considerados vecinos, y la que se ha

denominado en el código MinPts, que es el número mínimo de puntos necesarios para

formar una región densa o cluster.

Figura 19. Muestra el funcionamiento del algoritmo DBSCAN




53

En la imagen de arriba se muestra un ejemplo de el algoritmo en el que MinPts = 4. El

punto A y los otros puntos rojos son considerados puntos principales, por que la zona que

rodea a estos puntos en un radio ε contiene al menos 4 puntos. Debido a que todos son

accesibles entre sí, forman un solo grupo. Los puntos B y C no son puntos principales, pero

se puede llegar desde la A (a través de los otros puntos rojos) y por lo tanto pertenecen a la

agrupación también. El punto N no se consideraría un cluster, ya que no cumple los

requisitos de los parámetros.

En este proyecto los valores asignados a los parámetros han sido 150 para ε, ya que se ha

comprobado que con esa distancia los clusters creados no son muy grandes y a MinPts se

le ha asignado el valor 1, porque cualquier píxel que tenga un valor superior o igual al

valor luma máximo, si no es considerado blind spot, nos causará el problema que estamos

intentado solucionar.

El algoritmo empieza con un punto de partida arbitrario que no ha sido visitado y se sigue

adelante hasta que cada punto luminoso se ha tenido en cuenta.

Algunas de las ventajas de DBSCAN son que, al contrario que k-means (otro algoritmo de

clustering), no requiere de un parámetro para especificar el número de clusters necesarios.

A continuación se muestra el método en el que se ha implementado este algoritmo:

func runDbscan(pointList: [Point]) -> Array<Array<Point>> { print("Starting Dbscan") let utility = Utility(maxDist: dist) var clusters = [[Point]]() for i:Int in 0..<pointList.count{ //get each point and, if it is not visited, find its neighbours let point:Point = pointList[i]; if(!utility.isVisited(point)){ utility.addVisited(point); neighbours = utility.getNeighbours(point,pointList: pointList);




54

if(neighbours.count>minPoints){

//for each point that is a neighbour of the visited point, see if they also have a cluster around for neighPoint in neighbours{ if(!utility.isVisited(neighPoint)){ utility.addVisited(neighPoint); let neighbours2:[Point] = utility.getNeighbours(neighPoint,pointList: pointList); if(neighbours2.count>minPoints){ neighbours = mergeToNeighbours(neighbours2) } } } clusters.append(neighbours) } } } return clusters }

Después de usar DBSCAN, obtenemos una serie de agrupamientos o clusters de puntos

brillantes, que serán representados como rectángulos azules en la interfaz de usuario.

En estos clusters el láser no será detectado, ya que la cámara no puede distinguir entre el

brillo de los blind spots y el brillo del láser. Esto es un problema, debido a que una de las

funcionalidades que tiene esta aplicación, es ser capaz de pintar en las diapositivas con el

láser, pero no podrá pintar en estos clusters. Pero no es un problema tan grave como

anteriormente, ya que permite que funcione la aplicación con normalidad y a menudo no

hay zonas brillantes en la pantalla de proyección.

Estos clusters hacen que el tratamiento de los fotogramas sea más lento en el proceso de

buscar el láser, ya que tenemos que ir comprobando si el punto brillante que hemos

detectado se encuentra dentro de alguno de los clusters, si es así significa que ese punto

brillante estaba anteriormente ahí y por ello no se trata del láser. Para evitar que el

procesamiento se vea tan afectado, se crea una zona que se representará como un

rectángulo rojo en la interfaz de usuario, que incluye todos los clusters. El único objetivo




55

de la zona roja es agilizar el procesamiento, ya que nos permitirá comprobar rápidamente

si un punto brillante detectado es candidato a ser blind spot, si no está en la zona roja no

puede estar dentro de un cluster (por lo que nos ahorramos comprobarlo), y si está dentro,

tendremos que comprobar si es un blind spot. La siguiente figura es una representación de

lo que se acaba de explicar:

Figura 20. Representa lo que se obtiene al aplicar el DBSCAN para corregir el error de los brillos

Por lo tanto al código mostrado en la anterior calibración al que añadirle lo siguiente:

if(lumaValue>brightness){

//to see if the points are inside the cluster if(insideRedZone(i)){ if(!insideCluster(i)){ brightness = lumaValue




56

index = i }else{

brightness = lumaValue index = i } } }

Como podemos observar, primero comprobamos si está en la zona roja (en este método

también comprobamos si existe algún cluster, si no existe ninguno, no hay zona roja), y

luego comprobamos si está dentro de alguno de los clusters, si no está dentro de ninguno

significa que hemos identificado un punto brillante.

4.2.3 CONEXIÓN

Con el objetivo de que el móvil pueda comunicarse con el ordenador y enviarle toda la

información sobre lo que el usuario realiza con el láser, se establece una conexión Wi-Fi

entre ambos. Se ha elegido usar Wi-Fi en vez de bluetooth ya que la velocidad de conexión

tiene que ser muy rápida para que se procese la información en tiempo real.

Se han implementado dos sockets distintos, el primero de ellos es el encargado de enviar y

recibir la información necesaria para la calibración del tamaño de la pantalla (la primera

calibración), y el segundo es el que se usa para transmitir la información de la posición del

láser en cada momento.

Para crear los sockets en la aplicación móvil se usan los objetos NSInputStream y

NSOutputStream. El usuario por medio de la interfaz indica a que IP se quiere conectar, y

se crea un socket entre el móvil y el ordenador en el puerto indicado, para ello ambos

dispositivos deben estar conectados a la misma red.

Las dos clases que se han usado en la aplicación móvil para implementar estos sockets son

las siguientes:

1. ConnectionImage: Como se dijo antes es la encargada de enviar y recibir la

información acerca de el rectángulo verde. Esta clase recibe la foto realizada por el




57

móvil al tablero de ajedrez como un objeto NSData que es un objeto de

información estática. Posteriormente se codifica esta información en base64 ya que

al ser la imagen una información que puede presentar caracteres problemáticos para

ser transmitidos, es recomendable realizar esta codificación antes de transmitir la

imagen por el socket.

Para transmitir la imagen, se divide en trozos de 2Kb (Kilobits), ya que al intentar

mandar trozos más grandes se perdía información.

Después de que se analice el ajedrez usando OpenCV, el ordenador envía los

puntos detectados en formato JSON. El objeto JSON tiene un campo Corners que

identifica todos los bordes identificados de los cuadrados del ajedrez, y unos

campos DistanceX y DistanceY, que representan el tamaño de uno de los cuadrados

del ajedrez. Una vez parseamos toda esta información, obtenemos el tamaño de la

pantalla de proyección o rectángulo verde.

Figura 21. Muestra el procedimiento de obtención de datos para la segunda calibración




58

2. ConnectionWifi: Esta clase es la encargada de enviar los puntos detectados sobre la

posición a la que el usuario está apuntando el láser. Se envían dos puntos, también

en formato JSON, que representan una línea. Se envía siempre el último punto

detectado y el anterior, a no ser que el usuario haya dejado de pintar, que entonces

se reinicia.

El servidor del ordenador ya había sido implementado anteriormente, pero se tuvieron

que realizar unos cambios, para que se pudiera leer la información del socket

correctamente. Específicamente en vez de usar un DataInputStream (como se usó para

la aplicación Android):

DataInputStream stream = new DataInputStream(clientSocket.getInputStream());

Se tuvo que usar un BufferedReader:

BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));

4.2.4 INTERFAZ DE USUARIO

En este apartado se proporcionará primeramente una visión general de la interfaz de

usuario, y posteriormente se explicará en detalle como se ha implementado esta.

Al inicio, la aplicación pedirá al usuario que introduzca el IP que se muestra en la

aplicación de ordenador. Una vez se introduce y se presiona el botón Adjust, se mostrará la

cámara y en la aplicación de ordenador se mostrará el tablero de ajedrez. La cámara deberá

ver todo el tablero, para asegurarse de eso, el usuario podrá mirarlo en la pantalla del

móvil, y cuando este listo podrá presionar el botón Start, que hará que el móvil saque la

foto y empiece todo el proceso de calibración. Si el proceso de calibración funciona

correctamente, se representará en el móvil el rectángulo verde, lo que indicará que el




59

usuario puede empezar a usar la aplicación. Si se encuentran puntos brillantes como los

explicados en la segunda calibración, también se representarán los rectángulos azules y el

de la zona roja.

En la siguiente figura se muestra unas imágenes de la interfaz de usuario en las que

podemos observar el flujo de la aplicación:

Figura 22. Muestra las distintas vistas que existen en la interfaz de usuario de la aplicación móvil

Estas tres son las vistas que existen en la interfaz de usuario del móvil, todas ellas heredan

de la clase UIViewController. La clase UIViewController proporciona la infraestructura

para la gestión de las vistas de sus aplicaciones iOS. Un view controller gestiona un

conjunto de vistas que componen una parte de la interfaz de usuario de la aplicación. Es




60

responsable de la carga y la eliminación de esas vistas, la gestión de interacciones con esas

vistas, y de la coordinación de las respuestas de estas.

Posteriormente se describirán los elementos que contiene cada una de las tres vistas:

1. La primera vista que es la que sale arriba en la figura anterior, esta compuesta de

una UIView en la que se representa ese fondo azul, y esta view contiene un

UITextFied (donde el usuario debe introducir la IP que se muestra en la interfaz de

ordenador) además de un UIButton que te lleva a la siguiente pantalla al presionar

sobre él.

2. La segunda vista tiene 3 componentes, una UIView en la que se representa lo que

está viendo la cámara en tiempo real, una UILabel que le recuerda al usuario que

antes de presionar sobre Start debe ver el ajedrez completo, y un botón que hace

que se muestre la siguiente vista y empiece todo el proceso de calibración al

presionarlo.

3. Por último tenemos la tercera vista, que al igual que la anterior tiene una UIView

que representa lo que esta viendo la cámara, pero además tiene otra UIView, cuya

clase se ha denominado DrawView, encima de la de la cámara, en la que se

representan los rectángulos verdes, azules y rojos cuando corresponde. El código

que se muestra a continuación es el utilizado para pintar estos rectángulos: 4.

override func drawRect(rect: CGRect) { // the context is basically the canvas you are about to draw in let context = UIGraphicsGetCurrentContext() //we tell it we are about to begin a path CGContextBeginPath(context) if(drawGreen){ //create the rectangle var first = true for corner in cornersG{




61

if(first){ CGContextMoveToPoint(context, CGFloat(corner.x), CGFloat(corner.y))//punto inicio first = false }else{ CGContextAddLineToPoint(context, CGFloat(corner.x), CGFloat(corner.y)) } } CGContextAddLineToPoint(context, CGFloat(cornersG[0].x), CGFloat(cornersG[0].y)) // set the thickness of the line and the color CGContextSetLineWidth(context, 2) CGContextSetRGBStrokeColor(context, 72/255, 252/255, 23/255, 1) //stroke the line CGContextStrokePath(context) }

Para poder dibujar estos rectángulos, se sobrescribe el método drawRect() que es el

que se utiliza para dibujar en una UIView. Para empezar hay que llamar al método

UIGraphicsGetCurrentContext() que te devuelve el canvas donde vas a pintar,

posteriormente vas añadiendo las líneas que quieres pintar, eliges el grosor y color

con el que lo vas a pintar y por último le dices que lo represente.

4.3 CASOS DE USO

A continuación se ofrecerá un análisis en profundidad del desarrollo de la solución y sus

distintos casos de uso.

Se han definido una serie de casos de uso para la aplicación de ordenador y la de móvil.

Dichos casos de uso serán clave para determinar los datos necesarios y la tipología de los

mismos, para el funcionamiento completo de la solución.

La solución a desarrollar involucra únicamente a un actor principal, que en este caso se

trata del presentador. El presentador es el usuario final de la aplicación desarrollada, es el




62

principal actor para quien está diseñada la aplicación, con la que interactuará usando un

puntero láser.

4.3.1 DIAGRAMA DE CASOS DE USO

A continuación se muestra el diagrama de casos de uso tanto para la aplicación de

ordenador como para la aplicación móvil:

Figura 23. Casos de uso aplicación móvil

De la aplicación de ordenador tan sólo se muestran los casos de uso para las nuevas

funcionalidades que han sido añadidas:




63

Figura 24. Casos de uso aplicación de ordenador

4.3.2 DESCRIPCIÓN DE LOS CASOS DE USOS

A continuación se describirán los distintos casos de uso que tiene la aplicación de móvil y

los nuevos casos de uso de la aplicación de ordenador:

Aplicación móvil:

Especificación del caso de uso: Introducir IP

Descripción Este caso de uso permite crear un socket

entre el ordenador y el móvil

Actor Presentador

Precondición -------------------

Flujo primario Si se cumple el flujo primario, se creará un

socket entre el ordenador y el móvil.




64

Flujo secundario El usuario ha introducido una IP errónea y

no se podrá crear la conexión

Post condición Se mostrará la cámara para que el usuario

pueda empezar la calibración

Tabla 4. Primer caso de uso aplicación móvil

Especificación del caso de uso: Iniciar calibración

Descripción Este caso de uso permite completar la

calibración para que el usuario pueda

empezar a usar la aplicación

Actor Presentador

Precondición Que la cámara del móvil pueda ver todo el

tablero de ajedrez mostrado por el

ordenador

Flujo primario Se calibrará la aplicación y se mostrará un

rectángulo verde alrededor de la pantalla de

proyección

Flujo secundario La cámara no veía todo el ajedrez y habrá

que reiniciar la calibración

Post condición El usuario podrá pintar y usar BlipApp

normalmente

Tabla 5. Segundo caso de uso aplicación móvil




65

Aplicación de ordenador:

Especificación del caso de uso: Nueva diapositiva

Descripción Este caso de uso permite crear una nueva

diapositiva en la presentación

Actor Presentador

Precondición Que el usuario apunte con el láser al botón

de nueva diapositiva durante 1 segundo

Flujo primario Si se cumple el flujo primario, se añadirá a

la presentación una nueva diapositiva

Flujo secundario No se añadirá a la presentación una nueva

diapositiva

Post condición El presentador podrá dibujar en la nueva

diapositiva

Tabla 6. Primer caso de uso aplicación de ordenador

Especificación del caso de uso: Parar de pintar

Descripción Este caso de uso permite que el láser deje

de pintar

Actor Presentador


de parar de pintar durante 1 segundo




66

Flujo primario Si se cumple el flujo primario, el botón

cambiará y se modificará una variable que

indica si la aplicación tiene que pintar

Flujo secundario El láser seguirá pintando al apuntarlo a las

diapositivas

Post condición El presentador no podrá pintar con el láser

Tabla 7. Segundo caso de uso aplicación de ordenador

Especificación del caso de uso: Cambio de color

Descripción Este caso de uso permite cambiar el color

de pintado del láser.

Actor Presentador


de color durante el tiempo necesario hasta

que aparezca el color que busca

Flujo primario Si se cumple el flujo primario, se

modificará el color de pintado

Flujo secundario El color se mantendrá

Post condición El color con el que se representarán los

trazados del láser será el elegido por el

presentador.

Tabla 8. Tercer caso de uso aplicación de ordenador




67

Especificación del caso de uso: Pantalla completa

Descripción Este caso de uso permite volver a poner la

presentación en pantalla completa, con la

interfaz de BlipApp delante

Actor Presentador

Precondición -------------------

Flujo primario Si se cumple el flujo primario, se pondrá la

presentación en pantalla completa

Flujo secundario No se pondrá la presentación en pantalla

completa

Post condición El presentador podrá seguir con la

presentación de manera normal

Tabla 9. Cuarto caso de uso aplicación de ordenador




68



ANÁLISIS DE RESULTADOS

69

Capítulo 5. ANÁLISIS DE RESULTADOS

En este capítulo se destacan los resultados más relevantes que se han obtenido en la

realización del proyecto.

• Detección del puntero láser: Gracias a un algoritmo muy rápido de análisis de

fotogramas, se ha conseguido detectar la posición del puntero láser en tiempo real y

con una precisión muy elevada.

• Calibración: Se ha conseguido que el móvil detecte correctamente la posición de la

pantalla en la que se están proyectando las diapositivas y detecte el láser por brillo.

• Evitar problemas de brillo: Gracias a la utilización del algoritmo de clustering

DBSCAN, se solucionó el problema de los brillos que pueden existir en la escena al

calibrar la imagen, consiguiendo con ello que la aplicación siga funcionando casi a

la perfección.

• Conexión entre ambas aplicaciones: Se ha creado una conexión por Wi-Fi entre

ambos dispositivos consiguiendo que intercambien información fácilmente.

• Nuevas funcionalidades: Se han añadido ciertas funcionalidades a la interfaz de la

aplicación de ordenador, consiguiendo con ello mejorar la interactividad de usuario

con su presentación.



ANÁLISIS DE RESULTADOS

70



CONCLUSIONES Y TRABAJOS FUTUROS

71

Capítulo 6. CONCLUSIONES Y TRABAJOS FUTUROS

6.1 CONCLUSIONES

La realización del presente proyecto ha permitido el desarrollo de una solución innovadora

que mejora la interactividad de cualquier presentación de diapositivas. La realización de

todo este proceso de trabajo ha conducido a un profundo conocimiento sobre diversas áreas

tecnológicas. Por un lado, el desarrollo de la aplicación móvil ha permitido aumentar el

grado de conocimiento sobre iOS y en especial el lenguaje de desarrollo Swift (al ser la

primera vez que utilizaba este lenguaje) y también por otro lado mejorar los conocimientos

sobre Java y JFC/Swing.

BlipApp es un una aplicación bastante revolucionaria que ayuda a controlar e interactuar

con la presentación mediante un puntero láser, mejorando la manera en la que se realizan

las presentaciones hoy en día. Facilitará con esto el estudio del material a los alumnos y

mejorará la atención de los espectadores.

BlipApp tiene algunos competidores, sin embargo, los que tienen las mismas

funcionalidades son mucho más caros.

El prototipo creado funciona bastante bien, sin embargo, todavía tiene bastante trabajo por

delante de refinamiento y mejora de funcionalidades.

A continuación se muestra una imagen donde se puede ver toda la aplicación funcionando

en conjunto:




72

Figura 25. Imagen de BlipApp en funcionamiento

6.2 TRABAJOS FUTUROS

Nuestra visión es la de ser capaces crear pizarras digitales que son portátiles, “pizarras

virtuales” con las mismas funciones que las digitales, pero sin la necesidad de una

instalación previa de ningún tipo de hardware. Consiguiendo con esto presentaciones

interactivas que captaran la atención del usuario.

Para conseguir la precisión que puede tener una pizarra digital táctil, no podemos usar un

láser, ya que con un láser se pueden resaltar ciertos aspectos o dibujar una explicación de

algo simple, pero no se puede escribir una fórmula como harías con una tiza en una pizarra

clásica.

Con el objetivo de conseguir esta precisión, la idea es sustituir el láser por una especie de

bolígrafo pequeño que tenga una luz en el extremo trasero, de tal manera que se pueda usar

el sistema ya creado para detectar la posición, añadiendo una serie de correcciones por ser




73

un bolígrafo. Se necesita que el bolígrafo tenga una tamaño pequeño para que al escribir,

no se produzca el balanceo que ocurre al escribir con cualquier bolígrafo o lápiz normal.

Si además se le añade a esto el control del cursor, y que se puedan realizar los distintos

tipos de clicado que tiene cualquier ratón, se podrá llegar a conseguir una pizarra digital

que no necesite de un proyector especial o una Kinect.




74



BIBLIOGRAFÍA

75

Capítulo 7. BIBLIOGRAFÍA


https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programmi

ng_Language/

[2] Desarrollo en cascada.

https://es.wikipedia.org/wiki/Desarrollo_en_cascada

[3] Matteo Caldari “Camera capture on iOS”


[4] UIKit Framework reference

https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIKit_Framework

[5] Abu Lewis “Connecting iOS socket client to a ruby socket server”

http://abulewis.com/blog/connecting-ios-socket-client-to-a-ruby-socket-server-using-swift-

rubys-eventmachine-gem/

[6] JNA Oracle documentation

https://community.oracle.com/docs/DOC-982919#running

[7] Miguel Fernández “BlipApp: Pizarra virtual basada en dispositivo móvil (Sistema de

procesamiento y presentación de datos)”



[9] Davis Allie “Working with JSON in Swift”

http://code.tutsplus.com/tutorials/working-with-json-in-swift--cms-25335



BIBLIOGRAFÍA

76

[10] Apple documentation “Building a basic UI”

https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsS

wift/Lesson2.html#//apple_ref/doc/uid/TP40015214-CH5-SW1

BLIPAPP: PIZARRA VIRTUAL BASADA EN DISPOSITIVO MÓVIL ... · BLIPAPP: PIZARRA VIRTUAL BASADA EN...

Documents

Transcript of BLIPAPP: PIZARRA VIRTUAL BASADA EN DISPOSITIVO MÓVIL ... · BLIPAPP: PIZARRA VIRTUAL BASADA EN...