Aplicación basada en imágenes RGBD para obtención de medidas de ajuste para ciclistas

Aplicación basada en imágenes RGBD para obtención de medidas de ajuste para ciclistas Proyecto Fin de Carrera Daniel Arbelo Cabrera Tutor: José Javier Lorenzo Navarro Tutor: Modesto Fernando Castrillón Santana Las Palmas de Gran Canaria, julio de 2017 2 Agradecimientos Quiz´as la parte m´as personal y menos importante de la memoria. Tengo tanta gente a la que agradecer haber llegado hasta este punto que no s´e por d´onde empezar. Por supuesto estar´ıa mal no mentar primero a mis tutores: Javier con su infinita paciencia y buen humor y Modesto, que siempre ha encontrado gracioso que sea de Teror. Por otro lado me sentir´ıa mal si no agradeciese a los compa˜neros que han estado siempre ah´ı: Aitor, Alberto (al que siempre me referir´e como mi “esposa”), a esa pareja inseparable Mayca y Edu, Yazaida (no te deber´ıa decir cu´ando leo), a David por ser mi pato de goma personal y a Geco, aunque a ´el no tengo claro por qu´e, pero gracias Geco. Y a ti Ale, porque somos idiotas y lo dejamos todo para el final. Tambi´en agradecer a Fer y a Cris, que pese a no ser parte de la carrera han mostrado siempre su apoyo y han intentado (con escaso efecto) que mi proyecto tenga un aspecto visual m´as agradable. Me gustar´ıa agradecer a Pedro Mar´ın por el inter´es que ha mostrado con mi proyecto y la ayuda que ha prestado al mismo (siempre he bromeado que ´el es co-tutor). A mi primo y a la gente que entrena conmigo, que siempre me han mirado como un loco cuando hablo de mi proyecto, pero que me escuchasen me ayudaba. Por ´ultimo, y especialmente, a mi familia: mis padres y mi hermana, que me han apoyado en todo momento y, de forma que no entiendo, a´un no me han matado. 3 4 ´ Indice general 1. Introducci´on 13 1.1. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . 13 2. Estado del arte 15 2.1. M´etodos de longitud de piernas . . . . . . . . . . . . . . . . . 15 2.2. M´etodos basados en el ´angulo de la rodilla . . . . . . . . . . . 18 2.2.1. BikeFastFit ....................... 18 2.2.2. BikeFit by STT Systems . . . . . . . . . . . . . . . . . 19 2.3. Que desea aportar este proyecto . . . . . . . . . . . . . . . . . 21 3. Recursos 23 3.1. Recursos Hardware . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.1. C´amara Kinect . . . . . . . . . . . . . . . . . . . . . . 23 3.1.2. Estaciones de trabajo . . . . . . . . . . . . . . . . . . . 28 3.2. Software.............................. 28 3.2.1. Biblioteca OpenCV . . . . . . . . . . . . . . . . . . . . 29 5 6´ INDICE GENERAL 3.2.2. Visual Studio . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.3. CMake........................... 31 3.2.4. Unity ........................... 32 3.2.5. StarUML ......................... 32 3.2.6. Irfanview ......................... 33 3.2.7. LaTex ........................... 33 4. Planificaci´on 35 4.1. Metodolog´ıa............................ 35 4.2. Temporizaci´on........................... 35 4.3. Coste del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 36 4.4. Modelo de casos de uso . . . . . . . . . . . . . . . . . . . . . . 38 4.4.1. Identificaci´on de actores . . . . . . . . . . . . . . . . . 38 4.4.2. Diagramas de casos de uso . . . . . . . . . . . . . . . . 39 5. Desarrollo e implementaci´on 41 5.1. Recopilaci´on de secuencias de test . . . . . . . . . . . . . . . . 41 5.2. Segmentaci´on de las im´agenes . . . . . . . . . . . . . . . . . . 47 5.3. Detecci´on de las marcas visuales . . . . . . . . . . . . . . . . . 48 5.4. Ajuste de las marcas . . . . . . . . . . . . . . . . . . . . . . . 54 5.5. Obtenci´on de medidas . . . . . . . . . . . . . . . . . . . . . . 57 5.6. Dise˜no e implementaci´on de las interfaces . . . . . . . . . . . . 59 ´ INDICE GENERAL 7 5.6.1. Interfaz procesado . . . . . . . . . . . . . . . . . . . . 60 5.6.2. Interfaz de grabaci´on . . . . . . . . . . . . . . . . . . . 65 6. Pruebas 67 6.1. Carga de im´agenes . . . . . . . . . . . . . . . . . . . . . . . . 67 6.2. Aplicado de filtros y b´usqueda de marcas . . . . . . . . . . . . 68 6.3. Prueba de ´angulos . . . . . . . . . . . . . . . . . . . . . . . . 69 6.4. Obtenci´on de combinatoria . . . . . . . . . . . . . . . . . . . . 69 6.5. Pruebafinal............................ 70 7. Trabajo futuro y conclusiones 71 7.1. Posiblesmejoras.......................... 72 7.1.1. Unificaci´on de las interfaces . . . . . . . . . . . . . . . 72 7.1.2. Mejora del dise˜no de la interfaz . . . . . . . . . . . . . 72 7.1.3. Obtenci´on de m´as valores . . . . . . . . . . . . . . . . 73 7.1.4. Emisi´on de informes . . . . . . . . . . . . . . . . . . . 73 7.2. Conclusiones............................ 73 A. Casos de uso 79 B. Uso de la herramienta de grabaci´on 83 C. Uso de la herramienta de detecci´on y procesado 89 8´ INDICE GENERAL ´ Indice de figuras 2.1. Toma de medidas del m´etodo Lemond. Fuente ResearhGate . 17 2.2. App Bike Fit Fast. Im´agenes tomadas de la web oficial. . . . . 19 2.3. BikeFit by STT. Distribuci´on del espacio. . . . . . . . . . . . 20 3.1. C´amara Kinect de Microsoft. Imagen tomada de[Wikipedia] . 24 3.2. Dise˜no interno C´amara Kinect de Microsoft. Imagen tomada de[MSDN]............................. 25 3.3. Dise˜no interno C´amara Kinect de Microsoft. Imagen tomada de[MSDN]............................. 26 3.4. Comparativa de Kinect v1 frente a v2. Fuente [Zugara.com] . . 27 3.5. Logo de la biblioteca OpenCV . . . . . . . . . . . . . . . . . . 30 3.6. Logo de Visual Studio 2013 . . . . . . . . . . . . . . . . . . . 31 3.7. LogodeCMake.......................... 31 3.8. Logo de Unity. Fuente [Wikipedia] . . . . . . . . . . . . . . . . 33 4.1. Representaci´on del modelo en espiral. Fuente [Wikipedia] . . . 36 4.2. Representaci´on de la temporizaci´on del proyecto. . . . . . . . 37 9 16 CAP´ ITULO 2. ESTADO DEL ARTE Cuadro 2.1: Tabla m´etodo Greg Lemond Entrepierna Distancia Entrepierna Distancia Entrepierna Distancia 55 48.565 71 62.693 87 76.821 56 49.448 72 63,576 88 77.704 57 50.331 73 64,459 89 78.587 58 51,214 74 65.342 90 79.47 59 52,097 75 66.225 91 80.353 60 52.98 76 66.225 92 81.236 61 53.863 77 67.108 93 82.119 62 54.746 78 67.991 94 83.002 63 55.629 79 68.874 95 83.885 64 56.512 80 69.757 96 84.768 65 57.395 81 70.64 97 85.651 66 58.278 82 71.523 98 86.534 67 59.161 83 72.406 99 87.417 68 60.044 84 73.289 100 88.3 69 60.927 85 74.172 101 89.183 70 61.81 86 75.938 102 90.066 la posici´on en altura sea dos dedos por debajo de la cadera y que la distancia entre manillar y sill´ın sea suficiente como para que quepa tu mano y tu antebrazo entre ambos. Es evidente que este m´etodo es poco fiable y quiz´as sea solamente v´alido para uso ocasional de la bicicleta, aquellas personas que deseen dedicarse de un modo m´as profesional o que vayan a darle un uso con una intensidad media-alta necesitan un m´etodo m´as fiable. Dentro de los m´etodos que podr´ıamos considerar tradicionales, hay una peque˜na variedad que se centran en determinar la altura en base a la altura de las extremidades inferiores[1]. Dentro de este subgrupo se encuentra el m´etodo Hamley y Thomas en el cual se determina que la altura del asiento viene determinada tras medir la altura de la entrepierna y multiplicar dicho valor por un factor 1.09. Tambi´en forma parte de este subconjunto el m´etodo Greg LeMond (en honor al c´elebre ciclista), bastante similar al anteriormente descrito y que en este caso se basa en medir la longitud de las piernas, desde la entrepierna al suelo tal y como se ve en la figura 2.1. A continuaci´on se multiplicar´a este valor por un factor de 0.883 como muestra la tabla 2.1. Este m´etodo est´a basado en la experiencia emp´ırica del corredor, e implica cierto nivel de riesgo lesivo en las rodillas ya que el ´angulo de flexi´on de la articulaci´on ser´a mayor. 2.1. M´ ETODOS DE LONGITUD DE PIERNAS 17 Figura 2.1: Toma de medidas del m´etodo Lemond. Fuente ResearhGate 18 CAP´ ITULO 2. ESTADO DEL ARTE El m´etodo del tal´on uno de los m´as comunes y simples, cuando el ciclista est´a sentado sobre el sill´ın, la rodilla debe extenderse y con el tal´on en el pedal, la biela debe estar alineada con el tubo del sill´ın. El m´etodo de la longitud trocant´erica se basa en la distancia del hueso m´as prominente de la cadera (el troc´anter mayor) con respecto al suelo, se establece una relaci´on 1:1. 2.2. M´etodos basados en el ´angulo de la rodilla Los m´etodos basados en ´angulos son la base sobre la que se sustentan la mayor´ıa de las aplicaciones de biomec´anica para ciclistas, todos parten del m´etodos de Holmes, que se basa en ubicar la altura del sill´ın con el ciclista su pie en el punto muerto inferior (enti´endase a las 6 en un reloj), estableciendo un rango de 25 a 35 grados. Un ´angulo mayor de 35o, facilitar´a la ocurrencia de lesiones con dolor anterior de rodilla y un ´angulo menor a 25o facilitar´a la ocurrencia del S´ındrome de fricci´on de la banda iliotibial y la tendinitis bicipital. Dentro de este tipo subconjunto de m´etodos se encuentran las aplicaciones de biomec´anica que usan la tecnolog´ıa para obtener la informaci´on necesaria para que cada ciclista tenga una pedalada ´optima. A continuaci´on analizaremos algunas de las disponibles. 2.2.1. Bike Fast Fit Se trata de una aplicaci´on disponible en exclusiva de la App Store para IPhone e IPad que permite el c´alculo de los ´angulos entre articulaciones. Para ello, tal y c´omo se puede apreciar en la figura 2.2 se necesita grabar un v´ıdeo del ciclista en un rodillo mientras con unas marcas adhesivas en en los puntos cr´ıticos para la medici´on. El seguimiento de los puntos no es autom´atico, es necesario que el experto, tras grabar la sesi´on, una las articulaciones usando las marcas como gu´ıa visual para hacerlo de forma correcta. 2.2. M´ ETODOS BASADOS EN EL ´ ANGULO DE LA RODILLA 19 Figura 2.2: App Bike Fit Fast. Im´agenes tomadas de la web oficial. Entre sus aspectos interesantes presenta la capacidad de crear informes con todas las mediciones que se han obtenido durante la sesi´on y adem´as permite compartir esta informaci´on mediante correo electr´onico y aplicaciones en la nube como Apple Icloud, Dropbox y Google Drive. Presenta la comodidad de que solamente necesita un dispositivo m´ovil de la marca Apple y un tr´ıpode para estar completamente operativo. La aplicaci´on tiene un coste de 5,49 euros, siendo bastante asequible, sin embargo habr´ıa que a˜nadirle el coste del dispositivo m´ovil que var´ıan entre 400 y 1,000 euros (dependiendo del modelo y capacidad de almacenamiento elegidas). 2.2.2. BikeFit by STT Systems Destacada como una de las aplicaciones m´as completas del mercado viene amparada por la marca deportiva BH, BikeFit es, en este momento, una de los puntos de referencias en relaci´on con los estudios de biomec´anica en bicicleta. En el mercado desde finales del 2016 tiene un funcionamiento similar al ya presentado: un ciclista sobre un rodillo est´atico pedalea mientras se hace la grabaci´on del video para posteriormente hacer la identificaci´on y seguimiento de las marcas que, en este caso, se tratan de luces leds captadas con una c´amara de alta velocidad. Tras la grabaci´on de la sesi´on, el experto en biomec´anica podr´a ajustar la identificaci´on de las marcas para una mayor precisi´on de las mediciones. Ofrece una gran variedad de datos, no solo los ´angulos que forman las 20 CAP´ ITULO 2. ESTADO DEL ARTE Figura 2.3: BikeFit by STT. Distribuci´on del espacio. articulaciones y va indicando en cada fotograma si los valores son ´optimos o no. El programa posee una base de datos con los distintos modelos de cuadros de bicicletas de la marca BH clasificadas por tipos (carretera, monta˜na, triatl´on, etc) y tama˜no del cuadro, con esto consiguen unas mediciones a´un m´as precisas. El programa ofrece consejos autom´aticos cuando se encuentra alg´un valor que est´a de los par´ametros adecuados. Adem´as una vez acabada la sesi´on permite emitir un informe con todos los datos adquiridos, para posterior consulta. Uno de sus puntos negativos tal y como se puede apreciar en la figura 2.3, est´a el espacio necesario para el despliegue del equipo de biomec´anica usado. Se recomiendan al menos cinco metros cuadrados de espacio para usar de forma eficiente el sistema. Por otro lado nos encontramos ante un sistema que, para peque˜nas empresas, puede resultar caro: aparte del ordenador personal y del tr´ıpode, requiere la adquisici´on de una c´amara de alta velocidad cuyo precio suele ser de varios miles de euros. 2.3. QUE DESEA APORTAR ESTE PROYECTO 21 2.3. Que desea aportar este proyecto Tras ver las distintas posibles elecciones que existen en el mercado es interesante valorar que puede aportar el proyecto que se quiere desarrollar. Ante los m´etodos de longitud de piernas el primer paso es automatizar el proceso y el segundo, quiz´as m´as importante, dotarlo de una mayor precisi´on. Pese a que estos m´etodos tienen una tasa de efectividad aceptable no son ideales para un deportista que entrene de forma regular o intensiva. Por otro lado aplicaciones como Bike Fast Fit carecen de una detecci´on autom´atica de las marcas, objetivo a cumplir en el desarrollo de esta aplicaci´on. Frente a herramientas como BikeFit by STT Systems se ofrece, lo primero, una herramienta asequible y lo segundo una mayor facilidad de uso. Adem´as ninguna de estas herramientas ofrece una representaci´on del movimiento del deportista en un modelo 3D. La aplicaci´on a desarrollar tratar´a de alcanzar esta meta y as´ı tener una caracter´ıstica ´unica y diferenciadora. 22 CAP´ ITULO 2. ESTADO DEL ARTE Cap´ıtulo 3 Recursos En este apartado se describen los recursos utilizados para el desarrollo del proyecto, este abarca tanto la parte f´ısica (hardware) como la parte digital (software). 3.1. Recursos Hardware 3.1.1. C´amara Kinect Como se ha descrito con anterioridad el recurso que se decidi´o usar para la obtenci´on de im´agenes fue la c´amara/sensor de profundidad Kinect de Microsoft. Una de las principales razones de la elecci´on de este dispositivo de grabaci´on frente a otros es que, probablemente, sea el m´as extendido entre todos los modelos RGB-D del mercado, contando con una comunidad activa a d´ıa de hoy, a su vez dispone de una abundante cantidad de tutoriales y gu´ıas de uso, por lo que facilita su aprendizaje y la posibilidad de obtener resultados satisfactorios en un plazo de tiempo bastante reducido. Como se puede apreciar en las figura 3.1 y 3.2, este dispositivo posee una c´amara RGB, un sensor de profundidad y un micr´ofono multi-array bidireccional que, en uni´on, permite la captura de im´agenes y movimientos de 23 24 CAP´ ITULO 3. RECURSOS Figura 3.1: C´amara Kinect de Microsoft. Imagen tomada de[Wikipedia] los cuerpos en tres dimensiones y tambi´en concede la posibilidad de realizar reconocimiento facial y de comando de voz. Tal y c´omo se ve en la figura 3.3 en condiciones ´optimas (seg´un el fabricante) la lente tiene un ´angulo de visi´on (FOV) de 58ogrados horizontales y 45overticales. Adem´as es posible aumentar el ´angulo de FOV en 27o(tanto hacia arriba como hacia abajo) gracias a un pivote que incorpora la c´amara. Durante el transcurso del proyecto Microsoft termin´o el desarrollo de la segunda versi´on de la c´amara Kinect, dise˜nada para su nueva consola Xbox One. El salto tecnol´ogico entre ambas versiones del hardware, la adquisici´on de un modelo de la 2.0 junto al estado intermedio de desarrollo del proyecto conllev´o la valoraci´on de adaptar el trabajo llevado a cabo hasta ese momento al nuevo modelo de c´amara. Como se puede ver en la Figura 3.4 la segunda iteraci´on de la c´amara es bastante m´as potente: las im´agenes en RGB ahora est´an disponibles en alta definici´on, las im´agenes en profundidad pasan de una resoluci´on de 320x240 a 512x424, y lo que es m´as importante, adem´as ahora tenemos la posibilidad de capturar im´agenes en el espectro infrarrojo. En general la revisi´on del hardware mejora en todos los aspectos: Aumento del FoV horizontal. Antes ten´ıamos 57oahora 70. Aumento del FoV vertical, antes de 43 ahora hasta 60. Aumenta la detecci´on de articulaciones de hasta 26, frente a 20. 3.1. RECURSOS HARDWARE 25 Figura 3.2: Dise˜no interno C´amara Kinect de Microsoft. Imagen tomada de[MSDN] Es capaz de reconocer hasta 6 personas a la vez (antes 2). Reconocimiento de gestos faciales y de las manos. En contraposici´on tiene un aumento de requisitos: El primer modelo era compatible con USB 2.0, el nuevo requiere de forma obligatoria 3.0 Solamente es compatible con Windows 8 en adelante, la versi´on original pod´ıa usarse con Windows 7 en adelante. Su coste de venta al p´ublico a d´ıa de hoy no es comparable, el primer modelo se encuentra descatalogado. Sin embargo, si miramos su precio de venta original se puede apreciar que para su uso en ordenador es exactamente el mismo: 200 euros en total. En ambos casos trae el adaptador necesario para usarlo en ordenador. Uno de los puntos m´as importantes a la hora de comparar ambas c´amaras es la manera que tienen de calcular la profundidad. El modelo original emite 32 CAP´ ITULO 3. RECURSOS 3.2.4. Unity La herramienta Unity consiste en un motor de videojuegos multiplataforma (disponible en sistemas operativos Windows, Linux y OS X) que a su vez tambi´en dispone de opci´on de compilaci´on multiplataforma (incluyendo consolas y dispositivos m´oviles). Para el desarrollo del proyecto se ha usado la versi´on 5.5 disponible desde marzo del 2015. Unity posee un tipo de licencia denominada Unity Personal que posee todas las prestaciones del motor original con la ´unica restricci´on de compilar con una pantalla inicial con el logo de Unity y la leyenda Made with Unity. En caso de que dicha aplicaci´on tenga destino comercial existe un tope de 100.000 d´olares, tras lo cual se deber´a o adquirir una licencia Pro o tener una subscripci´on a la Plus. Teniendo en cuenta la naturaleza docente sin ´animo de lucro del proyecto, Unity se ajustaba perfectamente a las necesidades del mismo. Para programar en Unity se usa como lenguaje de programaci´on C# y tiene compatibilidadad con programas de dise˜no tales como Blender, 3ds Max, Maya, etc. Por otro lado permite elegir Visual Studio como el editor de c´odigo de los proyectos desarrollados en esta plataforma. Unity adem´as ofrece una tienda de recursos online denominada Unity Asset Store, en la que se puede acceder a contenido diverso para los diferentes proyectos, entre otros componentes se pueden encontrar: modelos 3D, materiales, texturas, sistemas de part´ıculas, tutoriales, etc. Hay que destacar que los paquetes en dicho recurso pueden ser tanto de pago como gratuitos y est´an sujetos a la licencia de uso de Unity. 3.2.5. StarUML Los diagramas elaborados en las etapas de an´alisis y dise˜no del proyecto han sido elaboradas en el lenguaje UML, para ello se ha hecho uso de la herramienta StarUML. StarUML es una herramienta de software libre de edici´on UML, es compatible con la mayor´ıa de los tipos especificados en el diagrama de UML 2.0 y fue desarrollada en Delphi. 3.2. SOFTWARE 33 Figura 3.8: Logo de Unity. Fuente [Wikipedia] 3.2.6. Irfanview Irfanview es un programa de edici´on de im´agenes gratuito para el uso privado no comercial, ha sido la herramienta b´asica para la edici´on de im´agenes en este proyecto y para la memoria del mismo. 3.2.7. LaTex Para el desarrollo de este documento se ha utilizado como herramienta LaTex, que es un sistema de composici´on de textos, orientado a la creaci´on de documentos escritos que presenten una alta calidad tipogr´afica. El editor usado para dicha tarea es la herramienta en l´ınea Overleaf, entre sus ventajas podemos encontrar que no necesita ser instalada y que permite ver en tiempo real el resultado del texto escrito. Se trata de un software libre bajo licencia LPPL (Licencia P´ublica del Proyecto LaTeX). 34 CAP´ ITULO 3. RECURSOS Cap´ıtulo 4 Planificaci´on 4.1. Metodolog´ıa La metodolog´ıa desde el punto de vista de la ingenier´ıa del software escogida para desarrollar el proyecto ha sido el Modelo Evolutivo en Espiral tal y como est´a definida en Boehm, 1988[4]. Este modelo tiene especial cuidado con el riesgo que aparece a la hora de desarrollar software. En un punto inicial se determinan las posibles rutas de desarrollo y se opta por aquella que tiene un riesgo m´as aceptable, y se continua repitiendo este patr´on en un ciclo en espiral tal y como se ve en la figura 4.1. La principal raz´on de aplicar esta metodolog´ıa al proyecto se encuentra en que una gran parte importante del desarrollo se centra en la prueba de herramientas e implementaci´on de t´ecnicas. Debido a esto es necesario que las primeras tareas sean refinadas a medida que el proyecto evoluciona, escogiendo aquellas que impliquen un menor riesgo para el proyecto. 4.2. Temporizaci´on Tal y como se explic´o en la secci´on 1.2 el proyecto se divide en varias partes. Para su correcto desarrollo se ha tratado de llevar a cabo una distribuci´on correcta del tiempo a emplear en cada tarea que compone el total del 35 36 CAP´ ITULO 4. PLANIFICACI ´ ON Figura 4.1: Representaci´on del modelo en espiral. Fuente [Wikipedia] proyecto. Tal y como se puede comprobar en la figura 4.2, dentro del desarrollo del proyecto la mayor parte del mismo se ha dedicado a la que podr´ıamos denominar etapa de desarrollo. En esta etapa estar´ıa contenido tanto el procesado de las im´agenes como el desarrollo y dise˜no de la interfaz. Si se quiere ahondar m´as en la etapa de desarrollo podemos observar la figura 4.3 donde se puede apreciar que casi el 70 % est´a exclusivamente dedicado a la detecci´on de las marcas as´ı como dise˜no e implementaci´on de la interfaz. Tareas como la segmentaci´on y el an´alisis de la postura han tenido un menor impacto en la etapa de desarrollo. 4.3. Coste del proyecto Dentro del desarrollo de cada proyecto hay que tener en cuenta el coste que este puede suponer tanto en materiales como software. Siguiendo la propuesta del proyecto se ha tratado usar la mayor cantidad de software libre posible (y en los casos que no fuese posible: licencias gratuitas con limitaciones), gracias a esta mentalidad se ha conseguido un coste 0 en en referencia al software. Centr´andonos en el hardware, ha sido posible que el material para la captura de movimientos fuese cedido por parte del departamento de Ciencias de la Computaci´on e Inteligencia Artifcial de la Universidad de las Palmas de Gran Canaria. Pese a todo, el coste oficial del sensor Kinect v2 es de 150 euros siendo necesario un conector especial con coste de 50 euros para poder 4.3. COSTE DEL PROYECTO 37 Figura 4.2: Representaci´on de la temporizaci´on del proyecto. Figura 4.3: Representaci´on de la temporizaci´on de la etapa de desarrollo. 38 CAP´ ITULO 4. PLANIFICACI ´ ON Cuadro 4.1: Lista de actores Actor Tipo Definici´on Experto en biomec´anica Principal Usuario experto que hace uso de la aplicaci´on. Tiene acceso completo a todas las caracter´ısticas de la misma. usarlo en ordenadores. Aunque en fases tempranas del proyecto se us´o el modelo original de Kinect a d´ıa de hoy est´a descatalogado y no se tienen precios oficiales del mismo. Para que todo funcione correctamente es necesario un equipo personal con Windows 8.1 en adelante (ya sea de escritorio o port´atil) que tenga al menos un puerto USB. 3.0, habiendo tanta variedad de modelos disponibles en el mercado se ha decidido usar un valor medio entre diferentes modelos que cumplan estos requisitos, aproximadamente 500 euros. 4.4. Modelo de casos de uso Es importante tener claro los casos de uso de nuestro proyecto, siendo el primer paso identificar los actores que ser´an parte de ellos y enumerar uno a uno los casos asociados a cada actor. Posteriormente se mostrar´an diagramas de caso de uso individuales en los que se detallar´a de forma visual cada caso asociado a su actor. En el Anexo I se detallar´an cada caso de uso en concreto. 4.4.1. Identificaci´on de actores Los actores son todos los seres que interactuan con el sistema, pero a su vez, es externo al mismo. En nuestro caso, tal y como se indica en la tabla 4.1, en conjunto de actores se limita ´unicamente al experto que hace uso de la aplicaci´on desarrollada, podr´ıa tenerse la idea equivocada de que el deportista que es grabado puede ser un actor tambi´en, pero en ning´un caso har´a uso de la herramienta. Como se puede apreciar en el cuadro ??. A continuaci´on se enumerar´an las relaciones entre el actor (experto en 4.4. MODELO DE CASOS DE USO 39 Cuadro 4.2: Relaci´on actor-acciones Actor Acci´on Descripci´on Experto en biomec´anica Elegir ruta grabaci´on El usuario puede elegir la ruta en la que quiere guardar la sesi´on que va a grabar. Comenzar la grabaci´on Se empieza a grabar la sesi´on de im´agenes a procesar Parar la grabaci´on Se para la grabaci´on de im´agenes a procesar Comprobar ruta de procesado El experto comprueba que la ruta de im´agenes para procesar es correcta Comenzar procesado Una vez comprobada la ruta, empieza el procesado de im´agenes Avanzar fotograma El experto puede elegir avanzar el fotograma actual biomec´anica) y las acciones que tiene asociadas. Cuadro 4.2 4.4.2. Diagramas de casos de uso Ya identificado el ´unico actor de nuestro modelo podemos identificar los casos de uso (tabla 4.2 y as´ı elaborar el diagrama correspondiente, en el que se presenta cada uno de los casos de uso a desarrollar. En la figura 4.4 40 CAP´ ITULO 4. PLANIFICACI ´ ON Figura 4.4: Diagrama de los casos de uso Cap´ıtulo 5 Desarrollo e implementaci´on Esta secci´on del documento se centrar´a en lo que concierne al desarrollo e implementaci´on del sistema. Para que el seguimiento del mismo sea m´as simple se ha decidido dividirlo en las diferentes tareas que conforman el desarrollo y que se comentar´an de forma separada. Esta divisi´on se corresponde a la vista en la Figura 5.1. Por otro lado se deber´ıa resaltar que el proceso de desarrollo e implementaci´on ha sufrido, para casi todas sus tareas, dos puntos cr´ıticos en los que los requisitos de los mismos han podido cambiar. Por otro lado a la hora de implementar las interfaces hubo un tercer punto cr´ıtico que acab´o afectando tambi´en al ajuste de marcas. Los hitos en concreto son: 1. Grabaci´on y procesado im´agenes Kinect v1 2. Grabaci´on y procesado im´agenes Kinect v2 3. Adaptar el proyecto como DLL[5]. Exclusivo de las interfaces y ajuste de marcas. 5.1. Recopilaci´on de secuencias de test La captura de im´agenes es la base sobre la que se sustenta el resto de las tareas, es l´ogico que sin una disposici´on de las mismas no podemos hacer 41 48 CAP´ ITULO 5. DESARROLLO E IMPLEMENTACI ´ ON Figura 5.7: Tipos de umbralizado. Fuente API de OpenCV ahora las marcas van a devolver un valor de distancia 0 tal y como se puede apreciar en la figura 5.9 5.3. Detecci´on de las marcas visuales El objetivo de este punto del procesado consiste en la detecci´on de las marcas visuales, para ello se plantearon diversas posibilidades a la hora de seleccionar el tipo de marca que se emplear´ıa. Inicialmente se valoraron tres posibilidades distintas: C´odigos QR, una se˜nal b´asica o marcas de colores. Cada una de las posibilidades representa alg´un tipo de ventaja. Se puede ver un ejemplo de cada tipo de marca en la figura 5.10 Los c´odigos QR. A cada c´odigo QR se le pod´ıa asignar una posici´on concreta dentro del esqueleto humano, una vez detectados y transformado el c´odigo en la informaci´on que contiene evitar´ıa la futura necesidad de encontrar a qu´e posici´on del cuerpo humano corresponde cada punto detectado. Se˜nal b´asica. Una se˜nal b´asica permitir´ıa una f´acil detecci´on haciendo una b´usqueda por texturas, al ser una imagen poco com´un la tasa de 5.3. DETECCI ´ ON DE LAS MARCAS VISUALES 49 Figura 5.8: Ejemplo de aplicar el umbralizado. aciertos ser´ıa, en teor´ıa, elevada. Marca de colores. Sencilla de usar, detectar colores es uno de los puntos b´asicos en el procesado de im´agenes. La decisi´on al final de cu´al elegir vino determinada por un factor externo: la resoluci´on de la c´amara. Aunque lo ideal hubiese sido elegir como elementos de diferenciaci´on los c´odigos QR o las se˜nales b´asicas se tuvo que optar por las marcas de colores, la calidad de la imagen obtenida no permit´ıa hacer el seguimiento e identificaci´on del c´odigo QR a la distancia que se encontraba la c´amara del sujeto que estaba siendo grabado, y de forma similar ocurr´ıa con la se˜nal a comparar con una textura simple. Por tanto se empez´o a trabajar sobre marcas de colores, para ello se modific´o el procedimiento de obtenci´on de profundidad, ahora a la vez que obten´ıa la profundidad que el usuario seleccionaba, se extra´ıan los valores RGB de ese punto por separado y al igual que en el caso anterior, se calculaba la media de cada componente en el espectro de color. Con estos valores se aplicar´ıa la funci´on inRange de OpenCV [6], que realizar´ıa un umbralizado (tal y como se hizo para segmentar la profundidad), 50 CAP´ ITULO 5. DESARROLLO E IMPLEMENTACI ´ ON Figura 5.9: Profundidad 2.0, se aprecia que la zona de las marcas da valor 0. Figura 5.10: Ejemplo de las marcas valoradas. 5.3. DETECCI ´ ON DE LAS MARCAS VISUALES 51 pero en este caso en base a las medias de las componentes roja, verde y azul. Para ello, y al igual que se hizo con threeshold se dar´ıa un margen de error a la funci´on. inRange ( ImagenFuent , Scalar (MediaR−15, MediaG−15, MediaB−15) , Scalar (MediaR+15, MediaG+15, MediaB+15) , ImagenDest ) ; En condiciones ideales esta soluci´on hubiese sido perfecta, sin embargo los resultados no fueron satisfactorios, un elemento externo no se hab´ıa tenido en cuenta y afectaba en gran medida a la calidad del resultado entre fotogramas: la luz ambiente. Esto implicaba que algunos fotogramas la detecci´on fuese perfecta y en otros (que se distanciaban en d´ecimas de segundo) los resultados fuesen inaceptables, con detecciones incorrectas. La soluci´on se encontr´o cambiando el espectro de colores de la imagen: se transform´o la imagen original RGB al espectro HSV[7]. Este modelo creado en 1978 por Alvy Ray Smith consiste en una transformaci´on no lineal del espacio de color RGB en las componentes de Matiz, Saturaci´on y Valor o Brillo (Hue, Saturation y Value respectivamente). En este modelo el matiz se representa por una regi´on circular, una regi´on triangular separada, puede ser usada para representar la saturaci´on y el valor del color. La representaci´on de este modelo puede verse en la figura 5.11. Con este nuevo modelo se volvi´o a modificar el procedimiento en donde se extra´ıa la media de profundidad de las marcas y la media de las componentes RGB, para que ahora fuese la media de los componentes Matiz y Saturaci´on la que se obtuviese ignorando los valores de brillo. A continuaci´on se decidi´o volver a umbralizar usando la funci´on inRange usando la media (m´as un ligero margen de error) tanto del Matiz como de la Saturaci´on y dejando todo el espectro de Brillo disponible con la intenci´on de paliar el efecto ejercido por la luz externa en las marcas de colores. inRange ( ImagenFuent , Scalar (MediaH−15, MediaS−15, 0) , Scalar (MediaH+15, MediaS+15, 255) , ImagenDest ) ; En este caso usando de base a la figura 5.12, se puede apreciar que los resultado de la figura 5.13 fueron satisfactorios. Para llegar a ese punto se 52 CAP´ ITULO 5. DESARROLLO E IMPLEMENTACI ´ ON Figura 5.11: Tri´angulo representativo del modelo HSV. [Fuente Wikipedia] us´o la funci´on findContours de OpenCV que permite la b´usqueda de contornos en una imagen, una vez encontrado los contornos se realiza una tarea de eliminaci´on de ruido mediante los procesos de dilataci´on y erosi´on[8] (transformaciones morfol´ogica b´asicas). findContours ( ) // busca l o s contornos erode ( imagen )// d i l a t e ( imagen ) La detecci´on de marcas con la primera versi´on de la c´amara kinect hab´ıa finalizado en este punto, y a esta altura del proyecto fue cuando se obtuvo la versi´on 2.0 del receptor de im´agenes. En la primera prueba de del nuevo modelo se apreci´o que este hardware simplificar´ıa mucho la detecci´on de im´agenes: las marcas de colores ser´ıan sustituidas por trozos de tela reflectante. Con la detecci´on de im´agenes en infrarrojo los valores de dichas marcas en ese espectro de luz ser´ıa m´aximo (a nivel computacional 255) simplificando la b´usqueda y aumentando la tasa de aciertos. Debido a que el receptor de profundidad es el mismo que el de infrarrojos esto conllevar´ıa un problema: aquellos valores que en el espectro infrarrojo fuesen m´aximos ser´ıan nulos en profundidad. La soluci´on para recalcular la 5.3. DETECCI ´ ON DE LAS MARCAS VISUALES 53 Figura 5.12: Imagen base en espectro HSV. Figura 5.13: Ejemplo de detecci´on de marcas tras el procesado HSV. 54 CAP´ ITULO 5. DESARROLLO E IMPLEMENTACI ´ ON Figura 5.14: Resultado de la detecci´on de marcas con Kinect v2. profundidad de cada punto fue sencilla: findContours ( ) // busca l o s contornos moments () // Obtener centro de contornos d i l a t e ( imagen ) erode ( imagen )// Media del centro t ras la transformacion Utilizando la funci´on Moments es posible obtener el momento central de cada contorno, si se transforma la imagen dilat´andola y luego erosion´andola se puede obtener una aproximaci´on de la profundidad que se ten´ıa el borde del contorno. 5.4. Ajuste de las marcas Con las marcas ya obtenidas el siguiente paso era ajustarlas para obtener las medidas. Es importante resaltar que las im´agenes de color y las de 5.4. AJUSTE DE LAS MARCAS 55 profundidad no est´an alineadas en ambos modelos de c´amara. Para la primera versi´on la biblioteca OpenNI hab´ıa solventado el problema rellenando la matriz de la imagen de profundidad por el marco con valores 0 (negro) ajust´andola con su pareja RGB. Sin embargo, llegados a este punto el proyecto estaba enfocado directamente a la versi´on 2.0 de la c´amara. La kinect 2.0 trae entre sus funciones una tabla con las equivalencias entre el desfase de im´agenes, sin embargo el problema reside en que solamente se puede obtener dicho valor durante tiempo de grabaci´on, y no en modo offline. Este podr´ıa haber sido un problema que podr´ıa haber consumido m´as tiempo del deseado, sin embargo ya se hab´ıa hecho la propuesta de animar un modelo en 3D con los datos obtenidos, as´ı que para el ajuste de marcas usar la imagen infrarroja con los contornos se adecuaba a la perfecci´on al problema. Una vez obtenidos los contornos el siguiente punto era ordenarlos, para ello se decidi´o que era requisito indispensable que la primera imagen cumpliese unos requisitos: la posici´on de inicial del paciente grabado deb´ıa tener los puntos ordenados de la siguiente manera (en orden descendente): Hombro Codo Mu˜neca Cadera Rodilla Tobillo La figura 5.14 muestra el filtrado de una imagen en infrarrojo en la posici´on inicial requerida. Una vez cumplido este requisito se pueden ordenar y unir los puntos de la imagen inicial , y adelant´andonos a la secci´on 5.5, obtener los ´angulos de la imagen inicial. Tal y como muestra la figura 5.15 El siguiente paso era determinar cu´al era el mejor m´etodo de predicci´on para mantener los puntos ordenados entre fotogramas. Surgieron dos opciones: 56 CAP´ ITULO 5. DESARROLLO E IMPLEMENTACI ´ ON Figura 5.15: Conexi´on correcta de las articulaciones. 5.5. OBTENCI ´ ON DE MEDIDAS 57 Buscar la distancia m´ınima entre los puntos de un fotograma y otro. Para ello se hac´ıa un c´alculo entre los puntos de un fotograma y el siguiente, y se asignaban en funci´on de la diferencia m´ınima de movimiento en el espacio de la imagen. Los resultados tuvieron una tasa de acierto bastante baja demostrando que el m´etodo no era deseable. B´usqueda de puntos por variaci´on entre ´angulos. En lugar de buscar la diferencia de los puntos en el espacio se filtr´o buscando la diferencia m´ınima total que formaban los ´angulos del fotograma anterior y la combinatoria de todos los puntos del siguiente fotograma. Este m´etodo dio resultados satisfactorios. Para ello se realiz´o un procedimiento que calculase la combinatoria posible de todos los puntos obtenidos y los almacenase en una matriz. Una vez calculadas todas las posibilidades se buscar´ıa aquella combinaci´on que al sumar la diferencia de cada componente diese un valor m´ınimo: A=α1, ... , α4T(5.1) B=   β1,1... β1,4 . . .... βn,1βn,4   (5.2) Bi=β(i,1) β(i,4)T(5.3) argmini= A−B−i 1(5.4) Tal y como se aprecia en la figura 5.16 los resultados fueron m´as que correctos. 5.5. Obtenci´on de medidas Dentro de este apartado se habla de la adquisici´on de las medidas necesarias para el diagn´ostico del experto. En realidad, este punto del desarrollo 64 CAP´ ITULO 5. DESARROLLO E IMPLEMENTACI ´ ON Figura 5.20: Segunda escena: procesado y animaci´on. encontraron varios exploradores de archivos, sin embargo todos eran de pago con precios que oscilaban entre los 10 y 40 euros. Al no tener fin comercial este proyecto se descart´o esta opci´on. 3. Escribir la ruta en una pesta˜na de entrada. Se habilit´o un campo de escritura en la que el usuario pod´ıa escribir una ruta dentro de su equipo. Para que el sistema fuese m´as robusto se hizo que comprobase que la ruta exist´ıa y que al menos contuviese las tres carpetas obligatorias con cada tipo de imagen. Mientras no se cumplan estas condiciones el bot´on para cambiar de escena permanecer´a inactivo. Para la escena de procesado se coloc´o el modelo en 3D y a su lado una tabla que mostraba los ´angulos para los siguientes casos: Fotograma actual Valor m´ınimo entre todos los fotogramas Valor m´aximo entre todos los fotogramas Para cada fotograma se ir´ıan comparando los valores con los obtenidos anteriormente, en caso de que alguno superase el m´aximo o el m´ınimo el valor 5.6. DISE ˜ NO E IMPLEMENTACI ´ ON DE LAS INTERFACES 65 se actualizar´ıa. Una vez procesados todos los fotogramas el programa vuelve a la escena inicial. Adem´as en todo momento se va mostrando una miniatura de las im´agenes en RGB y la segmentaci´on de las marcas del fotograma que se est´a analizando, para completar la informaci´on visual ya dada. Por ´ultimo se decidi´o a˜nadir un bot´on que permitiese salir de la escena de procesado y volviese a la de inicio en caso de que el experto lo requiriese. El funcionamiento de este interfaz se ve con mayor detalle en el Ap´endice C. 5.6.2. Interfaz de grabaci´on Para la interfaz de grabaci´on se decidi´o utilizar un dise˜no sencillo y minimalista, consistiendo en 3 botones que dar´an toda la funcionalidad que necesita el usuario tal y como se muestra en la Figura 5.21. Cabe destacar que desde la versi´on 2012 de Visual Studio Microsoft ha dejado parcialmente abandonado el dise˜no de interfaces en el lenguaje C++ y centr´andose y potenci´andolo en C#. Aprovechando el conocimiento adquirido para la creaci´on del proyecto en Unity se decidi´o que tambi´en se exportar´ıa el c´odigo de grabaci´on como una DLL a un proyecto de C# A cada bot´on se le ha asignado una acci´on distinta Ruta. Abre un explorador de archivos y permite seleccionar la carpeta donde se almacenan las im´agenes. Grabar. Invoca a la DLL para la grabaci´on, si no se ha seleccionado ninguna ruta no permite su activaci´on. Si el flujo de ejecuci´on es correcto pasar´a por par´ametro la direcci´on en la que se quieren almacenar las im´agenes y el programa de captura crea tres carpetas (Infra, color, prof) en donde se almacenan las im´agenes. Adem´as cambia el mensaje de estado indicando que se est´a grabando. Parar. En caso de estar activo el proceso de grabaci´on lo acaba y cambia el mensaje de estado indicando que ha finalizado el proceso. El funcionamiento de la interfaz se ver´a con mayor detalle en el Ap´endice B. 66 CAP´ ITULO 5. DESARROLLO E IMPLEMENTACI ´ ON Figura 5.21: Aspecto del interfaz de grabaci´on. Cap´ıtulo 6 Pruebas En esta fase se trata de someter a evaluaci´on la aplicaci´on, verificando su correcto funcionamiento y estabilidad, buscando posibles fallos de implementenaci´on y comprobando su usabilidad a la vez de si cumple los requisitos definidos en la frase previa del an´alisis. Debido a la naturaleza iterativa de este desarrollo, la fase de pruebas no se ha fijado para el final del mismo, durante el transcurso de cada una de las etapas de implementaci´on se aseguraba la correcta funcionalidad del proyecto en su conjunto, hasta llegar al punto final d´onde se comprobaba que el conjunto completo funcionaba en armon´ıa. A´un as´ı, ciertos elementos del desarrollo tuvieron su espacio personal dedicado a las pruebas d´onde se somet´ıan a una serie de tests que comprobaban su fiabilidad y correcto funcionamiento. 6.1. Carga de im´agenes Durante gran parte del proceso se us´o ´unicamente una pareja de im´agenes en RGB y profundidad para ir aplicando las t´ecnicas desarrolladas, siendo un punto de inflexi´on la necesidad de la carga de todo el conjunto de im´agenes para comprobar que, de forma secuencial, el c´odigo desarrollado funcionaba correctamente. A´un pareciendo un asunto trivial esta funci´on de ayuda tuvo 67 68 CAP´ ITULO 6. PRUEBAS tres aproximaciones distintas, cada una mejorando con respecto a la anterior: Lectura de rutas desde un fichero. La primera carga de im´agenes funcionaba leyendo la ruta en la que estaban contenidas las im´agenes desde un fichero de texto. Cada vez que se encontraba un salto de l´ınea se asum´ıa que la ruta era esa y se cargaba la imagen mediante funciones de OpenCV. Como primera aproximaci´on no era mala idea pero pronto se busc´o una soluci´on alternativa, escribir en ficheros de texto la ruta de cada imagen era engorroso y realizar un script que llevase a cabo esta funci´on consumir´ıa m´as tiempo del deseado, adem´as este sistema era especialmente sensible a problemas con caracteres ocultos. Uso de la librer´ıa dirent.h Esta librer´ıa dise˜nada para sistemas UNIX permite la b´usqueda y carga de archivos. Este encabezado no existe en IDE Visual Studio, fue necesario introducirlo a mano. Con esta librer´ıa se realiz´o un peque˜no programa con el que se comprobaba que se obten´ıan las direcciones de los elementos almacenados en una carpeta de forma correcta. Uso de funciones nativas de C#. Con el cambio de C++ a C# se consigui´o una mayor funcionalidad, ahora no se depend´ıa de encabezados externos para la b´usqueda y carga de las rutas, era el propio lenguaje el que proporcionaba dicha funcionalidad. 6.2. Aplicado de filtros y b´usqueda de marcas Una vez resuelto el problema de la carga de im´agenes se desarroll´o una peque˜na prueba que aplicaba los valores de umbralizados obtenidos de una la imagen de muestra al subconjunto completo de im´agenes. Obtener valor defiltrado() Mientas haya imagenes a p l i c a r va lo re s ; fin Una vez comprobada que la segmentaci´on se aplicaba de forma correcta se realiz´o sobre este mismo conjunto de prueba un testeo de b´usqueda de marcas. 6.3. PRUEBA DE ´ ANGULOS 69 Figura 6.1: Eje de coordenadas usado para las pruebas. 6.3. Prueba de ´angulos Para verificar el c´alculo correcto de los ´angulos se desarroll´o una funci´on de testeo que cargaba la imagen de un eje de coordenadas (Figura 6.1), y sobre dicho eje de forma iterativa y aleatoria seleccionaba tres puntos en el espacio y obten´ıa el valor que conformaban dichos puntos. En este punto se comprob´o el correcto funcionamiento para casos especiales: ´angulos de 0, 90, 180 grados. Los resultados fueron satisfactorios. 6.4. Obtenci´on de combinatoria Tal y como se explicaba en el punto 5.4 la forma de encontrar la correspondencia usada entre los puntos de los distintos fotogramas consist´ıa en calcular la menor diferencia entre la sumatoria entre ´angulos. Para ello era necesario asegurarse que el procedimiento de combinatoria funcionase de for- 70 CAP´ ITULO 6. PRUEBAS ma correcta, para ello se realiz´o un peque˜no test que ante una entrada con distintos valores realizaba el proceso combinatorio y lo volcaba en un fichero de texto. 6.5. Prueba final Para la prueba final se realiz´o una prueba de caja blanca, que se centra en los detalles procedimentales del software, para ello se escogen distintos valores de entrada para examinar cada uno de los posibles flujos de ejecuci´on del programa y cerciorarse de que se devuelven los valores de salida adecuados. Por tanto, una vez verificada la correcta ejecuci´on de todas las partes que conformaban el desarrollo del proyecto se decidi´o aplicar la totalidad del mismo a varios subconjuntos de im´agenes. El esquema seguido ser´ıa el siguiente 1. Obtenci´on y carga de im´agenes. 2. Segmentaci´on en profundidad. 3. B´usqueda e identificaci´on de marcas. 4. C´alculo de ´angulos y ordenaci´on de marcas. 5. Aplicaci´on de los datos obtenidos al modelo 3D. Se verific´o que la correcta comprobaci´on de los distintos m´odulos de la aplicaci´on implic´o un resultado satisfactorio en el conjunto global del mismo. Cap´ıtulo 7 Trabajo futuro y conclusiones Como se ha visto el objetivo de este proyecto era montar un sistema de detecci´on de marcas bas´andose en im´agenes RGB-D para obtener las medidas de ajuste personalizadas en bicicletas. Tal y como se ha podido comprobar durante el desarrollo de este documento se han encontrando diversas dificultades que, dentro del rango de posibilidades, se han tratado de solventar. Resaltar que se han cumplido los objetivos b´asicos del proyecto: Captura de im´agenes Segmentaci´on de las im´agenes Detecci´on de marcas visuales Ajuste del esqueleto Obtenci´on de medidas A su vez se han cumplido otros objetivos no propuestos inicialmente pero que, durante el desarrollo del proyecto, han surgido y se tomaron en consideraci´on: Uso de nuevas tecnolog´ıas: Kinect 2.0 Interfaz en Unity con animaci´on de modelo 3D 71 72 CAP´ ITULO 7. TRABAJO FUTURO Y CONCLUSIONES 7.1. Posibles mejoras Una vez finalizado el proyecto se ha analizado el trabajo realizado y aunque en general el resultado ha sido satisfactorio (hay que recordar que nos encontramos ante un proyecto de fin de carrera con unos objetivos delimitados y no ante una aplicaci´on comercial) no hay duda que hay margen de mejora, esto abre varias l´ıneas de trabajo futuro dentro del mismo proyecto. 7.1.1. Unificaci´on de las interfaces Debido a los problemas de compatibilidad entre los equipos y la tecnolog´ıa se ha tenido que dividir el programa en dos. El primero realiza la captura de im´agenes y el segundo su procesado. Esta situaci´on no es deseable y una de las principales l´ıneas de trabajo deber´ıa centrarse en encontrar un equipo que cumpliese los requisitos de la c´amara y a su vez no sufriese las incompatibilidades de Visual Studio y OpenCV. Esto mejorar´ıa la experiencia de usuario, facilitando el uso de la aplicaci´on y haciendo que sea m´as c´omodo. Adem´as dentro de esta unificaci´on se encontrar´ıan englobados dos puntos que se hab´ıan discutido como trabajo futuro pero se descartaron con el paso del tiempo: Ejecuci´on en tiempo real. Tener las dos aplicaciones en el mismo ordenador permitir´ıa la ejecuci´on en tiempo real de la aplicaci´on. Esto implica que, a la vez que se obtienen las im´agenes se vayan viendo los resultados en pantalla. Integraci´on im´agenes en el interfaz de Unity. Aunque se ha conseguido mostrar las im´agenes en tiempo de ejecuci´on sin molestar en la interfaz principal, lo ideal ser´ıa que estuviesen integradas en el mismo interfaz y no como una ventana emergente. 7.1.2. Mejora del dise˜no de la interfaz Ambas interfaces, aunque son solventes e intuitivos, carecen de un dise˜no profesional deseado. Aunque no estaba como objetivo que el aspecto de las 7.2. CONCLUSIONES 73 aplicaciones fuese comercial, ser´ıa deseable que se asemejase al aspecto de una lo m´as posible (aunque no sea el objetivo poner a la venta la aplicaci´on). Para cumplir este objetivo lo ideal ser´ıa contar con la ayuda de un dise˜nador profesional que indicase las pautas m´ınimas y necesarias que hicieren que la experiencia de usuario fuese lo m´as agradable posible a la vista. 7.1.3. Obtenci´on de m´as valores Ser´ıa deseable poder obtener m´as valores para mejorar la precisi´on del diagn´ostico biom´etrico, en este caso el problema reside m´as en la falta de conocimientos sobre qu´e datos se requieren m´as que la implementaci´on de dichas funciones. Para ello lo ideal ser´ıa contar con la asistencia de un experto en la materia que asesorase sobre qu´e datos son necesarios, cuales ser´ıan deseables y, en caso de que la situaci´on se diese, cuales de los disponibles no son necesarios y se puede prescindir de ellos. 7.1.4. Emisi´on de informes Tal y como hacen ya otras aplicaciones ser´ıa ideal almacenar informaci´on y emitir informes para que el paciente y el experto los tengas disponibles en cualquier momento y no solamente en el de ejecuci´on de la aplicaci´on. De forma idealizada se tendr´ıa una base de datos de cada cliente con cada sesi´on pudiendo observar las sesiones pasadas para tener referencias de los diferentes estudios y los valores ya obtenidos previamente. 7.2. Conclusiones En este proyecto se ha tratado de dise˜nar y desarrollar una herramienta que mediante la captura de im´agenes RGB-D permitiese una medici´on precisa de los ´angulos que forman las articulaciones de un ciclista para un correcto posicionamiento del sill´ın. Llegados a este punto se puede decir que se ha cumplido el objetivo creando una aplicaci´on funcional con un grado de 80 AP´ ENDICE A. CASOS DE USO Cuadro A.1: Identificador: 001 Nombre Indicar ruta de grabaci´on Actor principal Experto en Biomec´anica Descripci´on El usuario indica la ruta en la que desea almacenar las im´agenes Flujo normal 1.El usuario pulsar´a sobre el bot´on ruta 2.En el explorador de archivo elegir´a la ruta deseada 3.Se mostrar´a una ventana emergente con la ruta 4.Aparecer´a la ruta indicada en el programa Flujo alternativo Notas Cuadro A.2: Identificador: 002 Nombre Comenzar grabaci´on Actor principal Experto en Biomec´anica Descripci´on El usuario comenzar´a la sesi´on de grabaci´on Flujo normal 1.El usuario pulsar´a sobre el bot´on de empezara grabar 2.Se crear´an 3 carpetas en la ruta indicada que contendr´an las imagenes RGB, Profundidad e Infrarrojo. 3.Saldr´an tres ventanas emergentes mostrando las capturas 4.Cambiar´a el mensaje del estado de la c´amara Flujo alternativo 1a. Si el usuario no ha elegido ruta saldr´a un mensaje impidiendo la grabaci´on 1b. Si la c´amara no est´a funcional no comenzar´a la grabaci´on Notas Cuadro A.3: Identificador: 003 Nombre Parar grabaci´on Actor principal Experto en Biomec´anica Descripci´on El usuario parar´a la sesi´on de grabaci´on Flujo normal 1.El experto pulsar´a el bot´on de parar o la tecla de acceso r´apido “q”. 2. Las ventanas emergentes se cerrar´an. 3.El estado de la grabaci´on cambiar´a a parado. Flujo alternativo Notas 81 Cuadro A.4: Identificador: 004 Nombre Comprobar ruta de grabaci´on Actor principal Experto en Biomec´anica Descripci´on El experto indicar´a la ruta donde se encuentran las im´agenes a procesar Flujo normal 1.El usuario escribir´a la ruta de las im´agenes 2.Pulsar´a en el bot´on de comprobar 3.Se activar´a el bot´on de iniciar el procesado Flujo alternativo 2a. Si la ruta es incorrecta no permitir´a continuar 2b.Si la ruta no contiene las 3 carpetas no permitir´a continuar 2c.Si las carpetas no contienen el tipo de im´agenes requerido no permitir´a continuar Notas Cuadro A.5: Identificador: 005 Nombre Comenzar procesado Actor principal Experto en Biomec´anica Descripci´on El experto iniciar´a el procesado de im´agenes Flujo normal 1. El experto pulsar´a sobre el bot´on de comenzar 2.La pantalla cambiar´a a la de procesado. Flujo alternativo Notas Mientras no se obtenga una ruta correcta no se podr´a avanzar de esta pantalla 82 AP´ ENDICE A. CASOS DE USO Cuadro A.6: Identificador: 006 Nombre Avanzar fotograma Actor principal Experto en Biomec´anica Descripci´on El usuario ir´a avanzando uno a uno cada fotograma para su procesado Flujo normal 1.El usuario apretar´a la barra espaciadora para cambiar de fotograma 2.A cada fotograma saldr´a una ventana emergente con las im´agenes procesadas 3.Se animar´a el modelo 3D en cada fotograma 4.Para cada fotograma se dar´an los datos obtenidos 5.Al llegar al ´ultimo fotograma se volver´a a la pantalla de carga de im´agenes. Flujo alternativo 1a.Si alguno de los fotogramas no es v´alido se volver´a a la pantalla inicial de carga de im´agenes Notas Cuadro A.7: Identificador: 007 Nombre Parar procesado Actor principal Experto en Biomec´anica Descripci´on El usuario ir´a avanzando uno a uno cada fotograma para su procesado Flujo normal 1.El usuario apretar´a la el bot´on de parar ejecuci´on 2.La ejecuci´on se detendr´a y la aplicaci´on volver´a a la pantalla inicial Flujo alternativo Ap´endice B Uso de la herramienta de grabaci´on A continuaci´on se detallar´an las acciones que se le pueden llevar a cabo con la herramienta de grabaci´on, teniendo detalle en todos los posibles casos. Una vez se haya ejecutado la aplicaci´on se obtendr´a una vista como la de la figura B.1. En este punto habr´a 3 botones para el usuario: Ruta Grabar Parar Es requisito indispensable que el usuario elija una ruta para poder empezar a grabar, en caso de que que se trate de realizar la acci´on se lanzar´a una ventana emergente instando a que, por favor, se escoja d´onde se desea almacenar las im´agenes antes de empezar con el proceso. Tal y como se puede ver en la figura B.2 Por otro lado, si se trata de de parar una grabaci´on mientras ´esta no haya empezado todav´ıa se lanzar´a otra ventana emergente indicando que antes de poder parar una grabaci´on se debe empezar primero el proceso. Por tanto la ´unica opci´on que queda al usuario es pulsar sobre el bot´on de 83 84 AP´ ENDICE B. USO DE LA HERRAMIENTA DE GRABACI ´ ON Figura B.1: Estado inicial de la interfaz de grabaci´on. Figura B.2: Mensaje de error al intentar iniciar la grabaci´on sin una ruta. 85 Ruta, al hacerlo se abrir´a un explorador de archivos que permitir´a al usuario navegar por las carpetas de su equipo personal, indicando d´onde prefiere almacenar las im´agenes. Este explorador adem´as permite crear carpetas en la ruta seleccionada tal y c´omo muestra la Figura B.3. Al hacerlo se mostrar´a un mensaje de que la elecci´on ha sido un ´exito y junto al bot´on de grabar se mostrar´a la ruta elegida por el usuario. Figura B.4 Ahora el usuario tiene la opci´on de empezar una sesi´on, al darle al bot´on de grabar saldr´an tres ventanas emergentes mostrando la grabaci´on en profundidad (imagen tono azulado), infrarrojo (escala de grises), y la de RGB. Aunque la imagen a color tiene una resoluci´on de alta definici´on (1920x1080) se ha decidido reescalarla a la mitad de su tama˜no a la hora de mostrarla por pantalla, permitiendo ver todas las im´agenes a la vez, junto a la interfaz. Figura B.5: Si durante la grabaci´on pulsamos el bot´on de parar o la tecla especial “q”se parar´a la ejecuci´on y volveremos al mismo estado que la figura B.1 86 AP´ ENDICE B. USO DE LA HERRAMIENTA DE GRABACI ´ ON Figura B.3: Explorador de archivos. Figura B.4: Estado tras elegir la ruta. 87 Figura B.5: Estado durante la grabaci´on. 88 AP´ ENDICE B. USO DE LA HERRAMIENTA DE GRABACI ´ ON Ap´endice C Uso de la herramienta de detecci´on y procesado A continuaci´on se proceder´a a detallar como hacer uso de la herramienta de detecci´on y procesado de im´agenes. Para que la aplicaci´on funcione es requisito necesario que la carpeta de SizeYourBike est´e en la misma ubicaci´on que el ejecutable. Figura C.1 Tal y como se puede apreciar en la figura C.2 la escena principal del programa consta de dos botones y un cuadro de texto. En el cuadro de texto se debe introducir la ruta donde se contengan las carpetas con las im´agenes (obligatoriamente tienen por nombre: color, Infra, prof). Una vez introducida una ruta se puede pulsar el bot´on para comprobar dicha ruta. En caso de que Figura C.1: Ejecutable y carpeta del proyecto. 89