Universidad Carlos III de Madrid Escuela Politécnica Superior Máster en Ciencia y Tecnologı́a Informática Inteligencia Artificial Planning and Learning Group Planificación Jerárquica y Detección de Poses para el Desarrollo de Terapias de Rehabilitación con Robots Sociales Trabajo de Fin de Máster por José Carlos Pulido Pascual 22 de septiembre de 2014 Tutor: Dr. Fernando Fernández Rebollo i TRABAJO DE FIN DE MÁSTER PLANIFICACIÓN JERÁRQUICA Y DETECCIÓN DE POSES PARA EL DESARROLLO DE TERAPIAS DE REHABILITACIÓN CON ROBOTS SOCIALES Autor: JOSÉ CARLOS PULIDO PASCUAL Tutor: FERNANDO FERNÁNDEZ REBOLLO TRIBUNAL Presidente: FUENSANTA MEDINA DOMÍNGUEZ Secretario: SERGIO PASTRANA PORTILLO Vocal: JOSÉ ANTONIO IGLESIAS MARTÍNEZ Tras el acto de defensa y lectura el dı́a .... de Septiembre de 2014 en la Escuela Politécnica Superior de la Universidad Carlos III de Madrid (Leganés), el tribunal le otorga la siguiente CALIFICACIÓN: ii Email [email protected] Teléfono +34 91 624 5981 Dirección Universidad Carlos III de Madrid Escuela Politécnica Superior Avda. de la Universidad, 30 - Lab. 2.1.B16 28911 Leganés (Madrid) - SPAIN Por favor, cita este trabajo como: José Carlos Pulido: Planificación Jerárquica y detección de poses para el desarrollo de terapias de rehabilitación con robots sociales, Master thesis, Universidad Carlos III de Madrid, 2014. iii Muy especialmente quiero agradecer ... al grupo PLG por su hospitalidad, a Fernando por su confianza, a mis padres por su apoyo y cariño, y a José Carlos por ser un pilar firme en mi vida. iv v Abstract The traditional methods of rehabilitation require continuous attention of therapists during the therapy sessions. This is a hard and expensive task in terms of time and effort. Even in many cases, the therapeutic objectives cannot be achieved due to the overwork or the difficulty of planning sessions according to the medical criteria. For this purpose, a wide line of research is opened in order to investigate new ways of rehabilitation, such as the field of social robotics. All of these approaches pursue the same hypothesis: the therapeutic interaction provided by a social robot will help patients to get completely engaged with the rehabilitation treatment program. Furthermore, these innovative methods will improve the time of the patient’s recovery and reduce the overall socio-economic costs. This work belongs to a previous research phase of the Therapist project [Calderita et al., 2013]. The ultimate goal is to develop a cognitive architecture that provides a robot with enough autonomy to carry out an upper limb rehabilitation therapy for patients with physical impairments, such as Cerebral Palsy and Obstetric Brachial Plexus Palsy patients. The development of the proposed architecture is a joint work with José Carlos González and the author of this manuscript. In particular, this work aims to solve four problems experienced in previous stages of the Therapist project which are related to the planning and execution of the therapy. The first point is about the automatic generation of the therapy sessions according to a set of therapeutic objectives that is addressed using a hierarchical planning decomposition approach. The second part develops a classical planning domain to deal with the control of the execution of the therapy sessions. The last part of this work proposes a relational learning model to infer the position of the patient during the rehabilitation training. Keywords Physical Rehabilitation, Social Assistive Robotics, Hierarchical Task Network, HTN, Classical Planning, PDDL, Relational Learning, Cognitive Architecture. vi Resumen Los métodos tradicionales de rehabilitación requieren atención continua por parte de los terapeutas durante la ejecución de las sesiones de terapia. Esto resulta una tarea muy costosa en términos de tiempo y esfuerzo. En muchos casos, los objetivos terapéuticos no pueden ser alcanzados debido a la sobrecarga de trabajo o la dificultad de planificar sesiones de acuerdo a ciertos criterios médicos. Para este propósito, se han abierto numerosas lineas para investigar nuevas formas de rehabilitación, como en el campo de la robótica social. Todas estas aproximaciones persiguen la misma hipótesis: la interacción que provee un robot social en la terapia, aumentarı́a el nivel de compromiso de los pacientes con el programa de rehabilitación. Además, estos métodos innovadores, mejorarı́an el tiempo de recuperación del paciente y reducirı́an los costes socio-económicos. Este trabajo se sitúa en una fase previa de investigación del proyecto Therapist [Calderita et al., 2013]. El objetivo final es desarrollar una arquitectura cognitiva que dote al robot de autonomı́a para llevar a cabo una terapia de rehabilitación para disfunciones motrices, como ocurre en pacientes con Parálisis Cerebral o con Parálisis Braquial Obstétrica. El desarrollo de la arquitectura propuesta es en colaboración con José Carlos González. Los objetivos especı́ficos de este trabajo tratan de resolver cuatro problemas experimentados en fases previas del proyecto Therapist que están relacionados con la planificación y ejecución de la terapia. El primer punto trata el problema de la generación automática de sesiones de terapia de acuerdo a un conjunto de objetivos terapéuticos y para ello propone un modelo de planificación jerárquica. La segunda parte diseña un dominio de planificación clásica para ocuparse del control de la ejecución de las sesiones de terapia. La última parte del trabajo propone un modelo basado en aprendizaje relacional para inferir la posición del paciente durante el proceso de rehabilitación. Palabras clave Rehabilitación Fı́sica, Robots sociales de asistencia, Red jerárquica de Tareas, HTN, Planificación Clásica, PDDL, Aprendizaje Relacional, Arquitectura Cognitiva. Índice general 1. Introducción 1 1.1. Contexto del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Objetivos del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Estado de la cuestión 11 2.1. Robótica social de asistencia . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Planificación Automática . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.1. Hierarchical Task Network (HTN) . . . . . . . . . . . . . . . . . 16 2.2.2. PELEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3. Sistemas de apoyo a decisiones clı́nicas . . . . . . . . . . . . . . . . . . 20 2.4. Sistemas de reconocimiento de posturas . . . . . . . . . . . . . . . . . . 21 3. Arquitectura NAOTherapist 25 3.1. Diseñador de terapias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.1. Requisitos del modelo y restricciones . . . . . . . . . . . . . . . 31 3.1.2. Aproximación basada en HTN . . . . . . . . . . . . . . . . . . . 34 3.1.2.1. Problema de planificación . . . . . . . . . . . . . . . . 35 vii ÍNDICE GENERAL viii 3.1.2.2. Dominio de planificación . . . . . . . . . . . . . . . . . 36 3.1.2.3. Estrategia de planificación . . . . . . . . . . . . . . . . 41 3.1.3. Interfaz de configuración . . . . . . . . . . . . . . . . . . . . . . 41 3.2. Planificación de las sesiones . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2.1. Generación del problema . . . . . . . . . . . . . . . . . . . . . . 44 3.2.2. Dominio de planificación de sesiones . . . . . . . . . . . . . . . 45 3.3. Reconocimiento de posturas . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.1. Interfaz de captura de datos . . . . . . . . . . . . . . . . . . . . 49 3.3.2. Construcción del modelo relacional . . . . . . . . . . . . . . . . 51 3.3.3. Fase de aprendizaje . . . . . . . . . . . . . . . . . . . . . . . . . 57 4. Análisis experimental 59 4.1. Generador automático de terapias . . . . . . . . . . . . . . . . . . . . . 59 4.1.1. Escalabilidad del problema . . . . . . . . . . . . . . . . . . . . . 60 4.1.2. Distribución de los ejercicios . . . . . . . . . . . . . . . . . . . . 62 4.1.3. Distribución de la intensidad y dificultad . . . . . . . . . . . . . 63 4.2. Reconocimiento de posturas . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2.1. Experimento con 5 posturas . . . . . . . . . . . . . . . . . . . . 64 4.2.2. Experimento con 4 gestos . . . . . . . . . . . . . . . . . . . . . 67 4.2.3. Experimento con 5 posturas y 4 gestos . . . . . . . . . . . . . . 69 5. Discusión 72 5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.1.1. Generación automática de terapias . . . . . . . . . . . . . . . . 72 5.1.2. Planificación de las sesiones . . . . . . . . . . . . . . . . . . . . 74 ÍNDICE GENERAL ix 5.1.3. Reconocimiento de posturas . . . . . . . . . . . . . . . . . . . . 75 5.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Bibliografı́a 79 A. 88 A.1. Árbol relacional generado por TILDE . . . . . . . . . . . . . . . . . . . 88 x ÍNDICE GENERAL Índice de figuras 1.1. Lesión en el plexo braquial. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Robot Ursus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Protocolo terapéutico del HUVR. . . . . . . . . . . . . . . . . . . . . . 8 2.1. Taxonomı́a de los robots asistentes en terápias de rehabilitación. . . . . 13 2.2. Mundo de los bloques. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Red Jerárquica de Tareas (HTN). . . . . . . . . . . . . . . . . . . . . . 17 2.4. Arquitectura PELEA de dos niveles. . . . . . . . . . . . . . . . . . . . 19 3.1. Arquitectura NAOTherapist . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Distribución de trabajo de la arquitectura NAOTherapist. . . . . . . . 28 3.3. Distribución de la intensidad y dificultad a lo largo de la sesión. . . . . 33 3.4. Proceso de planificación de terapias . . . . . . . . . . . . . . . . . . . . 34 3.5. Esquema del modelo jerárquico (HTN) . . . . . . . . . . . . . . . . . . 35 3.6. Código JSHOP2 que incluye ejercicios. . . . . . . . . . . . . . . . . . . 38 3.7. Interfaz para la configuración de la generación de terapias. . . . . . . . 42 3.8. Caso de uso para la planificación de las sesiones. . . . . . . . . . . . . . 43 3.9. Sistema de reconocimiento de posturas. . . . . . . . . . . . . . . . . . . 50 xi xii ÍNDICE DE FIGURAS 3.10. Interfaz para la adquisición de ejemplos de entrenamiento. . . . . . . . 51 3.11. Percepción de la articulación. . . . . . . . . . . . . . . . . . . . . . . . 52 3.12. Distancia entre articulaciones. . . . . . . . . . . . . . . . . . . . . . . . 53 3.13. Representación de la distancia a la cámara con tres planos. . . . . . . . 54 3.14. Balance articular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.15. Rotación de los hombros vista desde arriba. . . . . . . . . . . . . . . . 56 4.1. Evaluación de la escalabilidad. . . . . . . . . . . . . . . . . . . . . . . . 61 4.2. Distribución de la intensidad y dificultad. . . . . . . . . . . . . . . . . . 63 5.1. Usuario realizando el caso de uso con el robot NAO. . . . . . . . . . . . 75 Índice de tablas 3.1. Ejemplo de modelo de ejercicio. . . . . . . . . . . . . . . . . . . . . . . 32 4.1. Tiempo de planificación. . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.2. Distribución de los ejercicios. . . . . . . . . . . . . . . . . . . . . . . . . 62 4.3. Resultados con 5 posturas y 162 ejemplos de entrenamiento. . . . . . . 65 4.4. Resultados con 5 posturas y 40 ejemplos de test. . . . . . . . . . . . . . 66 4.5. Resultados con 4 gestos y 192 ejemplos de entrenamiento. . . . . . . . . 67 4.6. Resultados con 4 gestos y 48 ejemplos de test. . . . . . . . . . . . . . . 68 4.7. Resultados con 5 posturas y 4 gestos y 354 ejemplos de entrenamiento. 70 4.8. Resultados con 5 posturas y 4 gestos y 88 ejemplos de test. . . . . . . . 71 xiii xiv ÍNDICE DE TABLAS Capı́tulo 1 Introducción La robótica social es un campo en constante crecimiento cuyo propósito es utilizar robots para cubrir determinadas necesidades sociales. Este término representa a todas aquellas plataformas robóticas que proveen un servicio o asistencia a personas de forma interactiva [Feil-Seifer and Mataric, 2005]. En los últimos diez años se han desarrollado numerosas aplicaciones que han ofrecido muy buenos resultados y han permitido abrir nuevas lı́neas de investigación en torno a diferentes dominios de rehabilitación tanto fı́sica como cognitiva. Por ejemplo, sobre la demencia en ancianos, el autismo, la deficiencia motriz o la parálisis cerebral hay estudios punteros que han demostrado un mayor compromiso del paciente con la terapia [Feil-Seifer and Mataric, 2011]. El principal reto reside en el desarrollo de técnicas y dispositivos que garanticen la evolución del paciente y ofrezcan soporte a los profesionales relacionados con el sector de la rehabilitación. Esto permitirı́a reducir el coste de las sesiones de terapia y el esfuerzo que supone para los terapeutas. Por otro lado, se debe hacer hincapié en el diseño, apariencia, capacidad de interacción y autonomı́a del robot. Considerar todo este conjunto de variables hacen que el proceso de desarrollo de estas plataformas sea lento y las arquitecturas de control sean distribuidas y muy complejas [Tapus et al., 2007]. Este trabajo se sitúa en el marco de la rehabilitación infantil de pacientes con deficiencia motriz en las extremidades superiores producida por un daño cerebral o 1 2 CAPÍTULO 1. INTRODUCCIÓN nervioso. El objetivo es desarrollar una arquitectura que permita controlar un robot humanoide para que lleve a cabo las sesiones de rehabilitación adoptando el rol del terapeuta y ofrecer soporte al médico especialista para evaluar la evolución del paciente. La arquitectura intenta cubrir las necesidades y problemas encontrados en una fase anterior del proyecto [Suárez Mejı́as et al., 2013] donde la plataforma robótica ejecutaba una secuencia de ejercicios preprogramados. Este trabajo entra en la segunda fase de investigación del proyecto ahora llamado Therapist [Calderita et al., 2013] y pretende dotar al robot de suficiente autonomı́a de modo que sea capaz de planificar las sesiones de terapia y reaccionar ante situaciones inesperadas. Al mismo tiempo debe garantizar que el paciente cumple con los objetivos terapéuticos establecidos por los especialistas. El resto de la introducción se extiende de la siguiente manera: El punto 1.1 ofrece una descripción de las afecciones y caracterı́sticas de los pacientes que son beneficiarios de esta terapia. El punto 1.2 explica la importancia y los beneficios de resolver el problema. El último apartado (1.3) presenta la propuesta y objetivos concretos de este trabajo. 1.1. Contexto del problema Therapist es un proyecto del Plan Nacional de Investigación (TIN2012-38079) en el que trabajan varios grupos de investigación de diferentes universidades españolas entre los que se encuentran el grupo de Ingenierı́a de Sistemas Integrados de la Universidad de Málaga1 , el laboratorio de robótica de la Universidad de Extremadura, Multimedia & Multimodal Processing de la Universidad de Jaén y el grupo de Planificación y Aprendizaje de la Universidad Carlos III de Madrid. Además, este proyecto cuenta con el apoyo de un grupo experto de rehabilitadores y terapeutas del Hospital Universitario Virgen del Rocı́o de Sevilla (HUVR) que ofrecen soporte durante el desarrollo del trabajo y posibilitan la evaluación de la plataforma robótica con usuarios reales. 1 www.therapist.uma.es - Ultimo acceso el 07/09/2014 1.1. CONTEXTO DEL PROBLEMA 3 Los pacientes que participan en el proyecto Therapist son menores con edades comprendidas entre los 3 y los 14 años que padecen Parálisis Cerebral Infantil o Parálisis Braquial Obstétrica con alteraciones motrices en las extremidades superiores. Esta sección ofrece información sobre estas enfermedades, los problemas funcionales que acontecen a los que las sufren y los beneficios de hacer terapia de rehabilitación. Parálisis Braquial Obstétrica (PBO) es una debilidad o pérdida de movimiento de las extremidades superiores producida cuando el conjunto de nervios alrededor del hombro son dañados durante el parto [Gilbert and Whitaker, 1991]. Este grupo de nervios se denomina plexo braquial como podemos ver en la figura 1.1. Este tipo de complicación se ha reducido a lo largo de los años debido a los avances en medicina y tecnologı́a durante el proceso de alumbramiento. Aun ası́, 1,5 de cada 1000 nacimientos presentan este tipo de lesión y requieren rehabilitación fı́sica. Otras causas comunes que dan lugar a daños en el plexo braquial son debidas a accidentes de tráfico o infecciones. En todos estos casos se requiere hacer terapia de rehabilitación para recuperar de parcialmente o en su totalidad la movilidad de las extremidades superiores afectadas [Chuang et al., 1993]. Parálisis Cerebral Infantil (PCI) es el término que enmarca el grupo de afecciones no progresivas relacionadas generalmente con la incapacidad de controlar completamente las funciones motoras [Bax et al., 2005] [Krägeloh-Mann and Cans, 2009]. No entra dentro de las enfermedades raras ya que es bastante común en la población. Las causas de estas lesiones en niños suelen darse por complicaciones durante el periodo de embarazo, en el parto o en la época post-natal. Aunque también pueden darse por algún tipo de infección o accidente. El 60 % de los niños con deficiencia motora se clasifican bajo el marco de parálisis cerebral. De cada 1000 nacimientos se dan 2 o 3 casos que presentan esta sintomatologı́a y se estima que 650.000 familias europeas tienen al cargo un niño o adulto con parálisis cerebral [Castelli, 2011]. Estos trastornos motrices están directamente relacionados con las extremidades superiores e inferiores y se manifiestan limitando al paciente en la habilidad de andar o en tareas de manipulación. 4 CAPÍTULO 1. INTRODUCCIÓN Figura 1.1: Lesión en el plexo braquial. Esto compromete la autonomı́a del paciente en tareas cotidianas tales como vestirse, alimentarse o desplazarse [Dickinson et al., 2007]. No existe cura conocida para los pacientes con PCI que deben convivir toda su vida con esta enfermedad. La mayorı́a de las capacidades deben ser mejoradas a través de terapia de rehabilitación. Un tratamiento bien desarrollado puede mejorar la habilidad para caminar, agarrar objetos, reducir la rigidez de los músculos e incluso prevenir las posibles malformaciones [Reid, 2002]. 1.2. MOTIVACIÓN 1.2. 5 Motivación Como se ha expuesto anteriormente, la calidad de la terapia y el compromiso del paciente son factores clave en la recuperación de la movilidad de las extremidades afectadas. Los pacientes de este proyecto son niños que requieren mucha más atención por parte de los profesionales para evitar distracciones y aprovechar al máximo el tiempo que disponen para cada sesión. Las terapias suelen ser largas y consisten en continuas repeticiones de movimientos que necesitan realizar para ejercitar las articulaciones. El entrenamiento resulta tan rutinario que suele conducir a la pérdida de interés y dejadez por parte del paciente. Esta situación se intenta solucionar invirtiendo gran dedicación por parte del personal cualificado. A pesar de dicho esfuerzo, muchas veces no se logran alcanzar todos los objetivos de la terapia [Calderita et al., 2013]. La pérdida de motivación y compromiso por continuar con el tratamiento puede bloquear la recuperación y afectar a la calidad de vida del paciente. Esta situación también afecta negativamente al sector profesional que derrocha un gran esfuerzo en supervisar todo el procedimiento terapéutico y al mismo tiempo supone un coste económico muy alto. Los beneficios que aporta la robótica a este tipo de tratamientos resultan bastante significativos. La participación activa de los robots en las sesiones de rehabilitación descarga el trabajo del terapeuta. Estos sistemas proveen herramientas que facilitan la supervisión y monitorización de las sesiones de terapia [Matarić et al., 2007]. Se abre toda una lı́nea de investigación alrededor del estudio de los aspectos beneficiosos de usar este tipo de técnicas [Drużbicki et al., 2013] [Ros et al., 2011] [Borggraefe et al., 2010] e incluso proponen nuevos modelos de comportamiento con el fin de mejorar la interacción del robot con los pacientes [Nalin et al., 2012]. En los últimos años, se han desarrollado nuevos dispositivos de apoyo a la terapia de rehabilitación. Por ejemplo, dentro de los robots vestibles se encuentran los exoesqueletos que han sido probados en adultos con daños en la médula espinal dotándoles de mayor capacidad para moverse e incluso subir escaleras [Perry et al., 2007]. Sin embargo, estos dispositivos no están disponibles para niños. En su lugar, se dispone 6 CAPÍTULO 1. INTRODUCCIÓN de la tecnologı́a RMT (Robot-Mediated Therapy) implementada en dispositivos que se adaptan al cuerpo del paciente y guı́an sus articulaciones durante el proceso de rehabilitación [Castelli, 2011] [Garcia et al., 2011] [Meyer-Heim and van Hedel, 2013]. Otro punto de vista diferente es el de realizar terapia sin contacto fı́sico donde los protagonistas son robots sociales autónomos, teleoperados o pre-programados. El éxito de estos robots se basa en el vı́nculo que se crea entre el paciente y el robot, estimulando su motivación y enfocando el tratamiento a través de imitación y con mensajes de ánimo [Matarić et al., 2007]. En muchos casos se utilizan juegos y técnicas de virtualización y realidad aumentada con el fin de mejorar el entorno interactivo en el que se encuentra el paciente [McMurrough et al., 2012]. Figura 1.2: Robot Ursus. La primera aproximación del proyecto Therapist abordaba este problema de forma básica. Se construyó un robot humanoide con forma de oso de 140 cm de altura llamado Ursus (ver Figura 1.2) que interpretaba el rol de terapeuta en sesiones de rehabilitación para niños con PBO y PCI [Suárez Mejı́as et al., 2013]. Los cinco grados de libertad de sus brazos permitı́an que ejecutara cualquier postura. En la primera fase de cada sesión, el paciente debı́a imitar cada uno de los movimientos que mostraba el robot. Los ejercicios se realizaban sobre las extremidades afectadas siguiendo el método de 1.3. OBJETIVOS DEL TRABAJO 7 la terapia de restricción inducida [Winstein et al., 2003]. Durante la sesión de rehabilitación el sistema capturaba los movimientos del paciente con ayuda de una cámara RGBD PrimeSense que permitı́a monitorizar y estimar la trayectoria de sus extremidades. en el caso que el paciente no realizara correctamente los ejercicios se mostraba cómo corregirlos a través de teleoperación. En la segunda fase el robot proyectaba varios juegos de realidad aumentada que forzaban al paciente a realizar los movimientos que habı́a entrenado en la fase anterior. Después de la fase de evaluación con usuarios reales, los pacientes reconocieron que se habı́an divertido durante las sesiones y que la experiencia fue bastante agradable. Cabe destacar varios estudios que demuestran que la apariencia de los robots influye enormemente en la percepción y la capacidad para captar la atención del usuario [Stanton et al., 2008]. En este caso, el aspecto amigable de oso de peluche resultaba atractivo para los pacientes que evaluaron el sistema. Sin embargo, el sistema no tenı́a un grado de autonomı́a razonable y requerı́a gente especializada para teleoperar el robot. Esto generaba cierta decepción debido a la falta de interacción con el paciente. 1.3. Objetivos del trabajo Para poder entender los objetivos y el caso de uso de este trabajo es necesario conocer el protocolo terapéutico que lleva a cabo el área de rehabilitación del Hospital Universitario Virgen del Rocio (HUVR). Cada uno de los pasos del procedimiento de rehabilitación se pueden seguir en la figura 1.3. Se pueden identificar tres actores: Médico rehabilitador: realiza el diagnóstico clı́nico y posteriores evaluaciones del paciente durante el proceso de rehabilitación. Terapeuta: encargado de supervisar las sesiones de terapia con el paciente. Paciente: beneficiario de la terapia. 8 CAPÍTULO 1. INTRODUCCIÓN Historial del paciente Empezar terapia Diagnóstico Expectativas del paciente Evaluación primaria Rehabilitador Paciente Determinar objetivos Fase A Objetivos terapéuticos Restricciones Nº Sesiones Diseñar la terapia Fase B Sesiones planificadas Progreso del paciente Terapeuta Actualizar terapia Ejecutar sesiones Resultados Evaluación Terapia finalizada Img. source: Creative Can Figura 1.3: Protocolo terapéutico del HUVR. Cuando comienza la terapia, el médico rehabilitador realiza un primer diagnóstico al paciente de acuerdo a su historial clı́nico. Los resultados del diagnóstico junto con las expectativas de mejora que tenga el paciente sirven para determinar los objetivos terapéuticos y las restricciones propias del paciente. Por ejemplo, si la expectativa es poder ser autosuficiente a la hora de comer, el médico puede establecer un conjunto de objetivos terapéuticos relacionados con capacidades que al entrenarlas permitan llegar a cumplir este objetivo. Como se muestra en la fase A de la figura 1.3, los objetivos establecidos por el rehabilitador, las restricciones del paciente y el número de sesiones son las variables de entrada que permiten al terapeuta diseñar el plan de terapia completo. Planificar las sesiones de la terapia implica tener un listado de ejercicios que cumplen los objetivos establecidos. Esta planificación resulta una tarea larga y engorrosa y que en la mayor parte de las ocasiones se omite y los ejercicios se planifican sobre la marcha en cada una de las sesiones. La falta de planificación compromete la calidad de la terapia y no asegura que todos los objetivos terapéuticos se cumplan bajo los criterios clı́nicos establecidos. En la fase B de ejecución de las 1.3. OBJETIVOS DEL TRABAJO 9 sesiones, el médico rehabilitador puede hacer evaluaciones periódicas para determinar la evolución del paciente y en caso de que sea necesario, realizar una actualización de los objetivos terapéuticos o del número de sesiones. El objetivo final del proyecto es tener un caso de uso funcional compuesto por un robot que tome el rol de terapeuta en la ejecución de las sesiones y además sea capaz de diseñar un plan de terapia completo que satisfaga los objetivos establecidos por el médico rehabilitador. Para ello, se ha comenzado a desarrollar una arquitectura cognitiva que sea capaz de llevar a cabo este caso de uso. Concretamente, este trabajo se centra en desarrollar cuatro módulos de dicha arquitectura que dan solución a algunos de los problemas ya expuestos en este trabajo y detectados en la evaluación del robot Ursus. A modo resumen se enumeran a continuación los problemas que van a ser abordados y la solución que se propone para resolverlos: Problema 1: la planificación y diseño de la terapia completa resulta una tarea muy engorrosa para los terapeutas que en muchas ocasiones se descuida. • Propuesta: desarrollar una herramienta de soporte a la decisión que permita automatizar el proceso de generación de terapias a partir de una base de datos de ejercicios etiquetados. Se propone el uso de técnicas de planificación automática y más concretamente una aproximación jerárquica para la selección de los ejercicios más apropiados asegurando la variedad y el cumplimiento de los objetivos terapéuticos. Problema 2: la arquitectura de control de la primera etapa del proyecto no proveı́a de ningún grado de autonomı́a al robot y requerı́a una persona entrenada para teleoperarlo. • Propuesta: integrar un módulo deliberativo que lidere la ejecución del plan de terapia y sea capaz de tomar decisiones ante posibles situaciones. Se pretende hacer uso de una arquitectura que combina planificación y monitorización, de modo que el estado del mundo que reciba por los sensores se 10 CAPÍTULO 1. INTRODUCCIÓN procese para devolver la siguiente acción. Problema 3: la corrección de las posturas de los ejercicios se realizaba de forma teleoperada cuando se detectaba que el paciente no lo habı́a hecho correctamente. • Propuesta: automatizar este proceso a través de un componente que recoja los datos de las articulaciones del paciente, pueda comparar si la postura es correcta con respecto a la mostrada por el robot y realice una sugerencia sobre cómo puede corregirla. Problema 4: durante la evaluación de Ursus con pacientes reales, se detectó que podı́an darse situaciones en los que el paciente se distraı́a, se levantaba o marchaba. El sistema no era capaz de detectar estos eventos y la interacción resultaba decepcionante • Propuesta: implementar un modelo de reconocimiento de posturas corporales para determinar la posición del paciente. Se propone entrenar un modelo de aprendizaje relacional que permita predecir el estado del paciente a través de su lenguaje corporal. Estos son los cuatro puntos principales que aborda este trabajo. La siguiente sección trata sobre el estado de la cuestión. La sección tres detalla la arquitectura desarrollada y cada uno de los puntos que se han desarrollado. El cuarto apartado muestra los resultados obtenidos durante el análisis y evaluación de los experimentos y el documento finaliza con unas conclusiones y propuestas de trabajo futuro. Capı́tulo 2 Estado de la cuestión El estado de la cuestión comienza con un primer apartado 2.1 que explica, a través de una taxonomı́a, la panorámica actual de la robótica que provee un servicio o asistencia. La sección 2.2 describe la idea de la Planificación Automática y conceptos básicos para entender esta técnica, ası́ como un paradigma de planificación jerárquica y una arquitectura utilizada para monitorizar la ejecución de los planes. El punto 2.3 presenta un conjunto de sistemas de apoyo a la decisión que han sido desarrollados para dar soporte a profesionales del área de la medicina. El ultimo apartado 2.4 ofrece una visión general sobre los principales retos y técnicas que se utilizan para el reconocimiento de posturas. 2.1. Robótica social de asistencia Los robots sociales de asistencia son aquellos que proporcionan un servicio o soporte a personas a través de interacción, ya sea fı́sica o sin contacto. Se trata de una de las aplicaciones de la robótica que ha crecido mucho en la última década. Feil-Seifer y Mataric realizaron un estudio en 2005 que ofrece una clasificación de los diferentes tipos de robots sociales según sus caracterı́sticas, interacción social y objetivos primarios [Feil-Seifer and Mataric, 2005]. Con el objetivo de comprender los conceptos base 11 12 CAPÍTULO 2. ESTADO DE LA CUESTIÓN y la motivación de este trabajo, es necesario introducir la clasificación propuesta por los autores: Assistive Robotics (AR) cubre todos aquellos robots que proveen asistencia a personas con algún tipo de discapacidad. Entre las lı́neas más comunes de investigación se encuentran los exoesqueletos [Nef et al., 2007], ası́ como otros recursos que proporcionan mejoras en la movilidad de los pacientes [Dubowsky et al., 2000] [Lacey and Dawson-Howe, 1998]. Forman el grupo más antiguo ya que se llevan desarrollando desde hace más de 35 años con el objetivo de adaptarse cada vez más a las personas y cubrir sus necesidades [Burgar et al., 2000]. Socially Interactive Robotics (SIR) es un término introducido por Fong [Fong et al., 2003] que engloba a todos aquellos robots cuya principal tarea sea alguna forma de interacción social. Como ejemplos existen algunas plataformas que hacen funciones de mayordomo [Reiser et al., 2009] o incluso aquellas destinadas a la industria del entretenimiento. Socially Assistive Robotics (SAR) es el nuevo término que propusieron los autores Feil-Seifer y Mataric en su artı́culo. Se trata del grupo objetivo en el que se fundamentará este trabajo. Se define como la intersección entre las categorı́as AR y SIR. Incluye todos aquellos que proveen asistencia a través de interacción social sin contacto fı́sico. Es decir, son robots que adquieren el papel de entrenador, terapeuta o educador con el objetivo de conducir y supervisar la sesión para la que están diseñados [Suárez Mejı́as et al., 2013][Fasola and Mataric, 2010][Choe et al., 2013][Fridin et al., 2011]. La lı́nea de investigación de los SAR es la más reciente. Actualmente se distinguen numerosas plataformas que ejecutan tareas diferentes, de forma diferente y para objetivos diferentes [Matarić et al., 2007]. Por este motivo, es necesario establecer una taxonomı́a de clasificación dentro de este grupo en función de las caracterı́sticas de 2.2. PLANIFICACIÓN AUTOMÁTICA 13 Figura 2.1: Taxonomı́a de los robots asistentes en terápias de rehabilitación. cada plataforma robótica. Este trabajo se centrará más en la búsqueda de objetivos comunes que en la sofisticación de la interacción con el humano. Entre los individuos objetivo más comunes se encuentran los ancianos con problemas fı́sicos y cognitivos. Muchas plataformas tratan de ofrecer servicios de asistencia y rehabilitación a pacientes con demencia [Wada et al., 2005]. Estos servicios también se ofrecen a pacientes que sufren parálisis cerebral, discapacidades fı́sicas o cognitivas. El principal objetivo es mejorar la calidad de vida de los beneficiarios. Se pueden agrupar por edades, por enfermedad o necesidades, pero para cada caso se deben tener en cuenta ciertas consideraciones especı́ficas para poder incluir cada uno de los trabajos en su categorı́a correspondiente. 2.2. Planificación Automática La Planificación Automática (PA) es una rama de la Inteligencia Artificial que nace en los años setenta con el objetivo de resolver problemas complejos a través de planes formados por una secuencia de acciones [Ghallab et al., 2004]. A partir de un estado inicial, el algoritmo de planificación debe encontrar el conjunto de acciones aplicables que alcance el estado final objetivo o, de ahora en adelante, las metas. La 14 CAPÍTULO 2. ESTADO DE LA CUESTIÓN dificultad de estos problemas aparece cuando existen múltiples metas que interaccionan negativamente entre sı́, es decir, la secuencia de acciones necesaria para llegar a cada una de las metas modifica el estado de tal manera que genera conflicto con las acciones necesarias por las otras metas. Tı́picamente, cuando se desea resolver un problema con PA se utiliza un lenguaje de modelado que permita expresar el conocimiento del problema en un dominio de planificación. Por un lado, el dominio está formado por los predicados que definen el estado del mundo y todas las posibles acciones. Las acciones están formadas por un conjunto de precondiciones y efectos. Por otro lado, la definición del problema a resolver serı́a una instanciación del modelo donde se especifica cuál es el estado inicial y la meta o metas a alcanzar. Cuando el conjunto de predicados que conforman el estado del mundo hacen ciertas las precondiciones de las acciones, se dicen que éstas son aplicables. Al ejecutarse una acción, sus efectos aplican cambios (añadidos y borrados) en el estado del mundo. Por lo tanto, la tarea del planificador es buscar la secuencia de acciones aplicables que permitan ir del estado inicial a las metas. Se muestra un ejemplo sencillo en la figura 2.2 que representa el problema del mundo de los bloques en el que un brazo robótico realiza una serie de operaciones con los bloques. En este caso se define como estado inicial que el bloque A está sobre el bloque B y las metas o estado final que se desea alcanzar es el bloque B sobre el bloque A. Las acciones que podrı́an modelarse en este dominio serı́an: desapilar bloque, levantar bloque de la mesa, apilar bloque y dejar bloque sobre la mesa. El planificador debe, por lo tanto, encontrar la secuencia de acciones que permita llegar al estado final. En este caso es un problema que puede resolverse con facilidad, la solución serı́a: desapilar A de B, dejar A en la mesa, levantar B de la mesa y apilar B sobre A. A la hora de modelar el problema habrı́a que considerar que el brazo robótico es un recurso que solo permitirı́a coger un bloque al mismo tiempo, por lo que habrı́a que representar en el estado del mundo si el gancho se encuentra sujetando un bloque o no. Muchos autores desarrollan estrategias y algoritmos de búsqueda donde la moti- 2.2. PLANIFICACIÓN AUTOMÁTICA 15 A B B A Estado inicial Estado final Figura 2.2: Mundo de los bloques. vación es conseguir planificadores que sean capaces de resolver cualquier tipo de problema. En el momento en que se quiere generalizar, disminuye la capacidad de ajustar el comportamiento del planificador al problema que queremos resolver. Uno de los planificadores que ha obtenido mejores resultados y que fue ganador de las competiciones de planificación 1 del IPC-2008 y IPC-2011 es Lama [Richter et al., 2011]. Otros planificadores ofrecen mayor poder expresivo aceptando dominios con funciones y acciones con precondiciones numéricas como es el caso de MetricFF [Hoffmann et al., 2003]. Por ejemplo, el planificador CBP [Fuentetaja, 2011] permite asociar costes a cada una de las acciones, de modo que el algoritmo de planificación considere de entre todas las secuencias de acciones aplicables, cuál genera un plan con menor coste. Hay otras aproximaciones que utilizan estrategias de aprendizaje u otras técnicas para decidir cuál es el mejor conjunto de planificadores que resuelve el mayor número de problemas, son los denominados portfolios. Este año, en la competición de planificación IPC-2014, IBACOP es el portfolio ganador que obtuvo mejores resultados de entre todos los participantes [Cenamor et al., 2014]. 1 http://ipc.icaps-conference.org - Ultimo acceso el 07/09/2014 16 CAPÍTULO 2. ESTADO DE LA CUESTIÓN PDDL es uno de los lenguajes más utilizados para modelar problemas de planifi- cación automática. Se creó en 1990 con la idea de establecer una estandarización de los lenguajes de planificación [McDermott et al., 1998]. Basado, entre otros, en STRIPS y ADL. Está muy aceptado en la comunidad de planificación y se emplea en los dominios y problemas de la competición de planificación IPC. Las versiones más modernas como PDDL 3.1 ofrecen mayor expresividad para representar el conocimiento, permitiendo variables numéricas, preferencias, predicados derivados o restricciones temporales. Se trata de un modelo de representación muy plano. En dominios que presentan una naturaleza jerárquica hay otros paradigmas donde la descomposición de tareas ofrece más ventajas. 2.2.1. Hierarchical Task Network (HTN) La red jerárquica de tareas o más conocida en inglés como Hierarchical Task Network (HTN) es un paradigma de planificación automática con un enfoque completamente diferente respecto a STRIPS y PDDL. Se trata de establecer un modelo basado en una jerarquı́a de tareas compuestas y acciones primitivas [Erol et al., 1994a]. El algoritmo genera planes a partir de la descomposición de tareas en subtareas hasta alcanzar las acciones primitivas. Esta descomposición se realiza según el cumplimiento de cada una de las precondiciones de las tareas de la jerarquı́a. Esta técnica funciona muy bien cuando se tratan problemas que pueden descomponerse en tareas más sencillas y donde el problema pueda representarse como una jerarquı́a. Por ejemplo, una terapia se compone en sesiones donde éstas a su vez se pueden descomponer en fases, cada fase en ejercicios y cada ejercicio en una serie de movimientos. La figura 2.3 representa los elementos de una red jerárquica de tareas y las posibles relaciones que pueden darse entre ellos. En el árbol de la figura se produce una descomposición de tareas hasta llegar a los nodos hoja que son las acciones primitivas. Las relaciones entre tareas son de dos tipos: 2.2. PLANIFICACIÓN AUTOMÁTICA 17 Dependencia jerárquica: establece una relación de subdivisión de tareas. Dependencia de orden: una relación que representa un orden de ejecución entre tareas. Dependencia jerárquica Dependencia de orden Tarea compuesta Acción primitiva Figura 2.3: Red Jerárquica de Tareas (HTN). Las implicaciones de utilizar relaciones de orden a diferencia de una dependencia jerárquica es que con una relación de orden el algoritmo de búsqueda visita ambos nodos siguiendo dicho orden para comprobar si son ciertas sus precondiciones. En el caso de utilizar solamente una dependencia jerárquica se trata de un bifurcación o salto en el que se ejecutará aquella tarea cuyas precondiciones sean ciertas. Entre los planificadores más utilizados se encuentra SHOP2, desarrollado por la Universidad de Maryland y con gran poder expresivo ya que permite el uso de axiomas, computación simbólica y numérica, permite llamar a programas externos para algún tipo de operación o comparación especial y además soporta cuantificadores y efectos condicionales [Nau et al., 2003]. Por otro lado, se encuentra UMCP implementado en Lisp como uno de los planificadores más completos basado en HTN [Erol et al., 1994b]. En último lugar, destaca SIADEX como un planificador con soporte para restricciones 18 CAPÍTULO 2. ESTADO DE LA CUESTIÓN temporales que ha sido utilizado en aplicaciones médicas como guı́as clı́nicas o sistemas de apoyo a la decisión [Fdez-Olivares et al., 2006]. 2.2.2. PELEA Muchas de las arquitecturas para el control de robots utilizan modelos reactivos que emiten una respuesta ante la información recibida por los sensores. Estos sistemas tienen mayores dificultades para encontrar una buena solución cuando se desean resolver problemas que requieren una visión a largo plazo. Esto se resuelve utilizando modelos deliberativos con capacidad de planificar y replanificar a partir del estado del mundo. PELEA (Planning, Execution and Learning Architecture) es una arquitectura desarrollada por la Universidad Politécnicas de Valencia, Universidad de Granada y la Universidad Carlos III de Madrid 2 y que integra planificación, monitorización, repla- nificación, ejecución y aprendizaje [Alcázar et al., 2010]. Se trata de una arquitectura genérica independiente del paradigma de planificación y del robot que se desee utilizar. Permite la monitorización de la ejecución del plan, lo que significa que interacciona con la información del exterior de modo que si no recibe el estado esperado, ejecuta un proceso de replanificación. La arquitectura PELEA está desarrollada en Java y dividida en módulos que intercambian la información en lenguaje XML. En la figura 2.4 podemos ver cada uno de los componentes que conforman la versión de dos niveles de PELEA. Como elementos externos se encuentran los ficheros del dominio y problema con el estado inicial a planificar. Por otro lado, se encuentra el planificador que se va a utilizar, por ejemplo MetriFF o Fast Downward. Los módulos internos de la arquitectura son: Execution: es el módulo que se comunica con el exterior. Recibe información de los sensores, el dominio y el problema y devuelve la siguiente acción a ejecutar. 2 http://www.plg.inf.uc3m.es/pelea - Ultimo acceso el 07/09/2014 2.2. PLANIFICACIÓN AUTOMÁTICA 19 Monitoring: está encargado de monitorizar la ejecución del plan. Se encarga de comprobar que el estado de bajo nivel se corresponde con el esperado y comunica al Decision support de aquellos predicados que sean relevantes. En caso de no llegar a un estado esperado se comenzarı́a un proceso de replanificación. Decision support: se trata del módulo que comunica con el planificador. Está encargado de decidir qué predicados son relevantes y deben ser monitorizados. En el caso de recibir un estado no deseado, el proceso de replanificación genera un nuevo problema a partir del estado actual y llama nuevamente al planificador. LowToHigh: Se encarga de traducir la información de los sensores a alto nivel. Low-level planner: Transforma las acciones de alto nivel en un conjunto de acciones interpretables en bajo nivel. actionB plan Decision support stateA Monitoring stateB Execution Execute action infoMonitoring Planner MetricFF FastDownward … LowToHigh Low-level planner domain problem Figura 2.4: Arquitectura PELEA de dos niveles. 20 CAPÍTULO 2. ESTADO DE LA CUESTIÓN La arquitectura PELEA ha sido utilizada por alumnos de la Universidad Carlos III de Madrid para sus trabajos de fin de grado3 . Se han desarrollado numerosas aplicaciones como bots que juegan a videojuegos, generación de acciones paralelas para controlar a dos robots, esquivar obstáculos, robots que cogen objetos, etc. También se ha integrado en un proyecto en desarrollo financiado por el Centro de Desarrollo Tecnológica Industrial (CDTI) llamado Interconecta Adapta4 . En este proyecto, un robot llamado Gualzru intenta capturar la atención de personas que se encuentran paseando por un aeropuerto o centro comercial con el objetivo de promocionarle un producto adaptado a su edad y género. Es un proyecto ambicioso en el que además se tratan temas de interacción con el humano e integración. La arquitectura de control está compuesta por un módulo deliberativo gobernado por PELEA [Manso et al., 2014]. 2.3. Sistemas de apoyo a decisiones clı́nicas Los Sistemas de Apoyo a Decisiones Clı́nicas (SADC) o en inglés Clinical Decision Support Systems (CDSS) han sido desarrollados durante décadas para facilitar numerosas tareas a los profesionales médicos. Por ejemplo, algunos ayudan a implementar guı́as clı́nicas a través de modelos computacionales que se adaptan al problema a resolver [Peleg, 2013]. En el caso de las terapias de rehabilitación, puede ocurrir que el protocolo o procedimiento que trata a un paciente no resulte del todo claro o no se pueda generalizar y a la hora de modelar la metodologı́a del tratamiento depende directamente de un conjunto de objetivos clı́nicos que el paciente debe cumplir. En este caso, las guı́as clı́nicas solo pueden ofrecer algunas recomendaciones sobre qué opciones puede tener el paciente, pero es tarea del especialista determinar la el procedimiento óptimo de forma que maximice la mejora del paciente, como por ejemplo acorde a una escala de evaluación clı́nica. Esto sigue siendo una tarea bastante compleja y que no 3 4 http://www.plg.inf.uc3m.es/pelea/demonstration.php - Ultimo acceso el 07/09/2014 http://www.innterconectaadapta.es - Ultimo acceso el 07/09/2014 2.4. SISTEMAS DE RECONOCIMIENTO DE POSTURAS 21 siempre garantiza alcanzar los objetivos clı́nicos. En el caso de los pacientes con PBO y PCI, el Hospital Vigen del Rocio utiliza la métrica de la escala GAS (Goal Attainment Scale) para determinar la mejora del paciente en base a unos valores de mejora estimados [Turner-Stokes, 2009]. Algunos trabajos abordan la generación automática de tratamientos terapéuticos. Por ejemplo, los autores presentan un sistema que diseña tratamientos para pacientes que padecen cáncer [Ahmed et al., 2010]. El sistema es capaz de determinar la geometrı́a y la intensidad de la radiación para optimizar la distribución de las dosis. Otros trabajos utilizan planificación automática para generar los escenarios de un brazo robótico que ayuda a pacientes discapacitados [Morignot et al., 2010]. Otras aproximaciones utilizan algoritmos de planificación para generar planes completos de terapias oncológicas [Fdez-Olivares et al., 2011; González-Ferrer et al., 2013]. Además utilizan herramientas que facilitan la traducción de las guı́as clı́nicas de la enfermedad de Hodgkin a modelos computacionales y consideran restricciones temporales que facilitan la planificación a los médicos especializados. Otras técnicas como la programación lineal entera mixta (MILP) se utiliza para determinar las citas de los pacientes en un hospital de rehabilitación [Schimmelpfeng et al., 2012]. Sin embargo, ninguno de los trabajos del estado del arte trata de generar automáticamente el conjunto de especı́fico ejercicios que conformarı́a una sesión del plan completo de terapias acorde al cumplimiento de unos objetivos terapéuticos. Este es uno de los principales objetivos que trata este trabajo y que formará parte de la arquitectura. 2.4. Sistemas de reconocimiento de posturas El estudio del movimiento humano nace en la antigüedad desde el punto de vista médico con la idea de determinar anomalı́as en el sistema neuromuscular y en el esqueleto. Esta actividad recibe el nombre de Quinesiologı́a (‘kı́nēsis’ – movimiento, ‘logos’ – estudio). Desde el punto de vista mecánico y fisiológico, aparece la perspec- 22 CAPÍTULO 2. ESTADO DE LA CUESTIÓN tiva psicológica. La idea principal es evaluar diferentes comportamientos y posturas para poder determinar el estado general de la persona. El lenguaje corporal en muchas ocasiones delata nuestra aceptación o desacuerdo cuando realizamos una actividad, por lo que resulta muy interesante ser capaz de leerlo. El reconocimiento de posturas y gestos se trata de una lı́nea de investigación muy frecuentada en la actualidad [Mitra and Acharya, 2007]. Los sistemas que realizan estas implementaciones requieren de una cámara o sensor que capture información visual del individuo a analizar. En los últimos años se han desarrollado nuevos sensores que ofrecen además información de profundidad [Foix et al., 2011]. Esta caracterı́stica los hace más resistentes a entornos que generen ruido a la hora de capturar los datos. El sensor de Microsoft Kinect, además de ofrecer información de profundidad, provee de un conjunto de librerı́as que forman un esqueleto de 20 puntos relativos a las articulaciones del sujeto. Este modelo de esqueleto es muy ligero de computar de modo que se puede hacer captura de datos y reconocimiento en tiempo real. Por estas caracterı́sticas y su bajo coste, este sensor es muy utilizado en investigación en el área de automática e inteligencia artificial. La interacción entre humano y robot es un punto principal en el desarrollo de plataformas robóticas de asistencia. El uso de técnicas de inteligencia artificial puede ayudar a mejorar la calidad de esta interacción [Fong et al., 2003]. Se busca una capacidad adaptativa que sea capaz de adecuar la experiencia de la interacción ante casi cualquier situación. Al igual que los seres humanos un robot debe aprender qué es una postura y qué significa cada gesto. [Gonzalez-Pacheco et al., 2013] se encuentran muy cerca de este propósito. Proponen una arquitectura interactiva que permite a un robot aprender a partir de la experiencia. La plataforma robótica está equipada con un sensor KINECT y un módulo de reconocimiento de voz. De este modo, un humano puede enseñar una postura al robot y decirle mediante voz cómo debe etiquetarla. El sistema aprende a partir de información: RGB-D (colores y profundidad) y la etiqueta correspondiente al 2.4. SISTEMAS DE RECONOCIMIENTO DE POSTURAS 23 ejemplo mostrado. Durante la fase de entrenamiento, el sistema aprende un modelo basado en atributo valor con ayuda de la herramienta de aprendizaje WEKA [Hall et al., 2009]. A partir del modelo aprendido, el robot es capaz de clasificar cualquier postura anteriormente aprendida y transmitirle el resultado por voz al usuario. El sistema distingue entre las tres posturas de las siguientes configuraciones: a) girado a la izquierda, derecha o de frente, b) mirando a la izquierda, derecha o de frente, c) señalando a la izquierda, derecha o de frente. Para las tres configuraciones se ha entrenado con 150 ejemplos y la precisión media obtenida ha sido: a) 99,1 %, b) 72,7 % y c) 79,5 % con cuatro tipos diferentes de algoritmos de aprendizaje (J48, Naive Bayes, Random Forests y SMO). Los resultados obtenidos son bastante aceptables. Sin embargo, este sistema de aprendizaje requiere 150 ejemplos para clasificar entre tres clases diferentes. En el caso que se extienda el número de clases o se transforme a multiclase, el número de ejemplos va a tener que ser mayor. Al ser un sistema que no tiene ningún conocimiento inicial sobre las posturas, los usuarios son los que deben generar el conjunto de ejemplos. Por lo tanto, es razonable explorar otras alternativas de aprendizaje que con poca cantidad de ejemplos sean capaces de clasificar con una precisión razonable. Hay otros trabajos que se centran en garantizar la seguridad de los humanos durante la interacción con robots industriales. Estos sistemas tratan de estimar la posición de las distintas partes del cuerpo con cámaras que funcionan mediante el tiempo de vuelo de pulsos de luz emitidos y proveen también de imagen de profundidad. La motivación que hay detrás de estos trabajos es construir un modelo 3D del cuerpo humano donde aunque se tenga una visual parcial del individuo, el sistema sea capaz de estimar la parte no visible [Graf et al., 2010]. A partir de ahı́, poder hacer un reconocimiento sobre qué acciones va a realizar o cuál es su situación. Por ejemplo, la interacción con brazos robóticos industriales puede llegar a ser peligrosa para el humano si no hay un sensor que estime y valore la peligrosidad de las acciones del humano con respecto al estado actual del robot y viceversa [Puls et al., 2012]. Otra técnica de aprendizaje muy común que se utiliza para dominios de agentes 24 CAPÍTULO 2. ESTADO DE LA CUESTIÓN exploradores es el aprendizaje por demostración. [Argall et al., 2009] presentan una recopilación de trabajos que utilizan esta técnica haciendo hincapié en cómo los robots capturan los datos y cómo aprenden una polı́tica en función de los ejemplos obtenidos. Por otro lado, existen otros trabajos que intentan aprender conceptos sobre el entorno que les rodea [Mahadevan et al., 1998] tales como obstáculos, puerta o determinados objetos que antes no conocı́an. Capı́tulo 3 Arquitectura NAOTherapist Este capı́tulo es la sección principal del documento donde se explica la estructura general de la arquitectura propuesta y se detallan los módulos que constituyen este trabajo. NAOTherapist es una arquitectura ad hoc basada en planificación y aprendizaje. Es un prototipo inicial destinado al control de un robot NAO1 para supervisión y ejecución de sesiones de terapias de rehabilitación de las extremidades superiores. Se pretende hacer una prueba de concepto que demuestre que las técnicas empleadas son adecuadas para elevar su uso a pacientes reales. Además, en futuras versiones de la arquitectura, se quiere establecer una abstracción que permita generalizar su uso a otros problemas de similares caracterı́sticas. Para la interconexión de los componentes de la arquitectura se sigue la filosofı́a de Robocomp [Manso et al., 2010], que provee un entorno de desarrollo, herramientas y reutilización de componentes destinados al control de plataformas robóticas. La comunicación entre los módulos de la arquitectura se realiza a través del software Ice de ZeroC2 que utiliza conexión TCP/IP. Se trata de un método de comunicación independiente del lenguaje que facilita la comunicación entre componentes independientes a través de sus respectivas interfaces. 1 2 http://www.aldebaran.com - Ultimo acceso el 07/09/2014 http://www.zeroc.com - Ultimo acceso el 07/09/2014 25 26 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST La figura 3.1 muestra el esquema de la arquitectura NAOTherapist, donde se han reutilizado dos componentes Robocomp desarrollados en fases anteriores del proyecto Therapist: WinKinectComp y PELEAComp. El primero de ellos está instalado en un ordenador Windows conectado directamente al sensor Kinect. Proporciona una interfaz que devuelve las caracterı́sticas antropomórficas del humano a través de su esqueleto y puntos de la cara en tiempo real. Toda esta información se recoge desde el módulo de Visión que interpreta esta información para razonar y sacar conclusiones sobre la postura o estado del paciente. El segundo componente reutilizado, PELEAComp, se trata de la arquitectura Pelea de dos niveles explicada en el estado de la cuestión (sección 2.2.2) con una interfaz Ice que permite la comunicación con el resto de componentes. La arquitectura distingue tres niveles de planificación: Planificación de alto nivel. Formado por el módulo que diseña las terapias, se trata de una fase offline que planifica el conjunto de ejercicios que se van a ejecutar a partir de los parámetros clı́nicos establecidos en la interfaz de configuración de la terapia (figura 3.7). En este nivel se han desarrollado dos aproximaciones completamente diferentes: la primera basada en planificación clásica y la que propone este trabajo con una visión jerárquica del problema de generación de terapias. Planificación de nivel medio. Se realiza una traducción de la salida del diseñador de terapias en el modulo generador del problema para construir el problema PDDL a resolver en el nivel medio de planificación. El problema se construye a partir del conjunto de poses que contienen los ejercicios planificados. El módulo PELEAComp es el encargado de planificar y monitorizar la ejecución de los ejercicios atendiendo a la información que le llegue de los sensores y aquellos eventos que puedan suponer un proceso de replanificación. Planificación de bajo nivel. La siguiente acción a ejecutar es recibida por el módulo ejecutivo de la arquitectura deliberativa PELEA. El ejecutivo realiza una 27 Diseñador Terapias Interfaz de configuración HTN Clásico Planificación: alto nivel Plan de terapia Aprendizaje Nuevos ejercicios Generador problema Base datos XML Problema PDDL PELEAComp Visión Reconocimiento posturas Metric-FF Planificación: nivel medio Acciones Reconocimiento expresiones Ejecutivo Instrucciones Características antropomórficas Sistema diálogo WinKinectComp Sensor Kinect Robot NAO Planificación: bajo nivel Figura 3.1: Arquitectura NAOTherapist 28 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST traducción de la acción de nivel medio a instrucciones de bajo nivel del robot. En este punto, el software interno realiza un proceso de planificación para estimar, por ejemplo, las trayectorias de sus articulaciones. Puesto que se trata de una arquitectura cuyo desarrollo está formado por dos personas, se adjunta la tabla 3.2 para especificar los puntos que se han trabajado, la carga de trabajo que ha llevado cada uno de los desarrolladores y las secciones correspondientes a cada documento. Diseño arquitectura Base de conocimiento Diseñador de terapias Interfaz gráfica Definición del modelo Clásico HTN PELEA Dominio Generador problema Ejecutivo Integración PELEAComp Integración NAO Integración con visión Visión Verificación de poses Aprend. de posturas Aprend. de exp. faciales González 50% 50% Pulido 50% 50% Secciones G3/P3 G3/P3 30% 50% 100% 0% 70% 50% 0% 100% G 3.1.1.1 / P 3.1.3 G 3.1.2 / P 3.1.1 G 3.1 P 3.1.2 0% 0% 100% 100% P 3.2.2 P 3.2.1 100% 100% 100% 0% 0% 0% G 3.2 G 3.2 G 3.2.1 20% 0% 100% 80% 100% 0% P 3.3 P 3.3 G 3.3 Figura 3.2: Distribución de trabajo de cada componente de la arquitectura NAOTherapist. La columna de las secciones representa con una G las secciones de la memoria de José Carlos González y con una P las que se encuentran en este trabajo. 3.1. DISEÑADOR DE TERAPIAS 29 Este trabajo se centra en resolver el problema de la generación automática de terapias como alto nivel de planificación (sección 3.1) y su conexión con un dominio de nivel medio que ejecute los ejercicios planificados y controle la rehabilitación ante los posibles eventos exógenos que puedan darse durante la sesión (sección 3.2). Además, este trabajo propone un módulo de reconocimiento de posturas basado en aprendizaje relacional que permite estimar la postura del paciente y un control para verificar que los ejercicios se realizan correctamente (sección 3.3). 3.1. Diseñador de terapias El modelo que se explica a continuación ha sido presentado en el Workshop KEPS de la conferencia ICAPS 2014 en Portsmouth (New Hampshire) [Pulido et al., 2014]. Las consideraciones clı́nicas de este apartado han sido evaluadas y aprobadas por el Hospital Universitario Virgen del Rocio (HUVR) para el proyecto Therapist. Una terapia de rehabilitación generalmente se lleva a cabo a partir de un conjunto de objetivos que el médico rehabilitador establece para el paciente en base a su movilidad, fuerza y flexibilidad. El cumplimiento de estos objetivos durante las sesiones de rehabilitación garantiza una evolución positiva del paciente. Como se explicó en el protocolo terapéutico del HUVR (Figura 1.3), los terapeutas son los encargados de transformar manualmente estos objetivos en un plan completo de terapia de ejercicios de acuerdo al tiempo que dura cada sesión. Resulta muy complicado encontrar una combinación que sea capaz de respetar el programa cumpliendo el nivel esperado de los objetivos sin que tenga un impacto negativo en los pacientes. En este apartado se propone un método basado en Planificación Automática para la generación automática de planes de terapia para pacientes con Parálisis Braquial Obstétrica (PBO) y Parálisis Cerebral Infantil (PCI) que requieren rehabilitación en las extremidades superiores. Este diseñador de terapias se plantea como una herramienta de apoyo a la decisión clı́nica para facilitar a los terapeutas la planificación de la terapia 30 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST asegurando el cumplimiento de los objetivos clı́nicos y se desea hacer una integración en la arquitectura como una primera capa de planificación de alto nivel que diseñe el conjunto de ejercicios que ejecutará el robot en cada una de las sesiones. Un plan de terapia está compuesto por sesiones y cada sesión está formada por diferentes ejercicios. Las sesiones se organizan de la siguiente manera: los ejercicios iniciales sirven como calentamiento, los más intensos deben realizarse en la parte central de la sesión y habrı́a una última fase con ejercicios de enfriamiento. La evolución del paciente se determina utilizando la escala GAS [Turner-Stokes, 2009]. De acuerdo a los resultados, el médico rehabilitador puede cambiar alguna de las caracterı́sticas de la terapia, como por ejemplo el nivel o prioridad con la que se quiere trabajar alguno de los objetivos. El médico rehabilitador determina el número de sesiones que debe realizar y algunas restricciones acorde a su historial clı́nico para evitar ciertos ejercicios que puedan producir lesiones al paciente. Los rehabilitadores del hospital establecen también unos niveles o prioridades que representan cuánto se debe entrenar cada uno de los objetivos. El HUVR considera cinco objetivos que tratan la rehabilitación de miembros superiores: Estimulación de actividades bimanuales: realizar ejercicios que impliquen las dos extremidades. Estimulación de actividades unimanuales finas: entrenar la movilidad de los de los músculos pequeños. Estimulación de actividades unimanuales gruesas: ejercitar la movilidad del miembro superior (mano, codo y hombro) Estimular posiciones y movimientos determinados con miembro superior: ejercitar determinados movimientos que los pacientes no pueden hacer, movimientos más extremos. 3.1. DISEÑADOR DE TERAPIAS 31 Mejorar la colocación espacial de los brazos: conseguir movimientos más amplios y precisos en todos los planos articulares. Otro de los factores importantes en el desarrollo de la terapia es que los ejercicios se distribuyan de forma variada y evitar que se repitan en la misma sesión. Esta caracterı́stica resulta muy enriquecedora para el paciente y de cara a su compromiso con la terapia. 3.1.1. Requisitos del modelo y restricciones Encontrar una plan de ejercicios para cada sesión, teniendo en cuenta todo el conjunto de requisitos clı́nicos, es una tarea de búsqueda que puede ser resuelta mediante Planificación Automática. Se hace uso de una base de datos de ejercicios etiquetados que permiten el cumplimiento de los objetivos del paciente. Para conseguir mayor flexibilidad a la hora de seleccionar los ejercicios, se evalúa la contribución o el nivel de adecuación de cada ejercicio con respecto a cada uno de los cinco objetivos terapéuticos definidos anteriormente. Además, de cara a establecer prioridades sobre qué objetivos debe entrenar un paciente en cada sesión, se establecen cinco valores acumulados (uno para cada objetivo) que se denominan TOCLs (Therapeutic Objectives Cumulative Levels). Se dará mayor valor a aquellos objetivos que se deseen entrenar más tiempo y menor valor o incluso cero en el caso que se quieran entrenar muy poco o nada. Por lo tanto, el objetivo de la tarea de búsqueda será evaluar qué combinación de ejercicios contribuyen con sus valores de adecuación de tal manera que alcancen los TOCLs establecidos. Es decir, la suma de los valores de adecuación de los ejercicios planificados deben alcanzar los respectivos TOCLs para cada una de las sesiones. 32 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST Los ejercicios tienen los siguientes atributos: Nivel de adecuación para cada uno de los cinco objetivos terapéuticos. Los valores se mueven de 0 a 3, dando el mayor valor a aquellos ejercicios que más contribuyan a los objetivos. Duración del ejercicio representada en minutos. Intensidad del ejercicio. A mayor intensidad, los ejercicios serán más duros. Dificultad para cada paciente. Se trata de un valor que tiene cada paciente asociado por cada ejercicio. Grupo de ejercicios relacionado con la capacidad que entrena el paciente. En el ejemplo que se muestra en la tabla 3.1, vemos que se trata de un ejercicio que contribuye a los objetivos unimanuales finas y colocación espacial. Pertenece al grupo de coordinación, tiene una duración de 3 minutos, es de intensidad media y para el paciente en cuestión es de elevada dificultad. Niveles de adecuación Bimanual Unimanual fina Unimanual gruesa Posiciones y movimientos Colocación espacial Resto de atributos 0 +3 0 0 +2 Duración Intensidad Dificultad Grupo de ejercicio 3 min. Media Alta “Coordinación” Tabla 3.1: Ejemplo de modelo de ejercicio. El tiempo de una sesión está acotado entre un mı́nimo y un máximo. Según se muestra en la figura 3.3, la distribución deseada de intensidad y dificultad de los ejercicios sigue una gausiana a lo largo de las tres fases de la sesión: calentamiento, entrenamiento y enfriamiento. 3.1. DISEÑADOR DE TERAPIAS 33 Intensidad Dificultad Calentamiento: 20% Entrenamiento: 60% Enfriamiento: 20% Figura 3.3: Distribución de la intensidad y dificultad a lo largo de la sesión. Respecto a las restricciones de variedad, un ejercicio no puede repetirse en una misma sesión y la distribución entre sesiones de los ejercicios debe ser tan variada como sea posible. También se deben evitar posibles ciclos entre las secuencias de ejercicios planificadas. En el caso de que las condiciones del paciente lo requieran, el modelo debe permitir restringir determinados grupos de ejercicios que puedan suponer algún tipo de lesión. Estas restricciones se deben poder configurar en el modelo por el médico rehabilitador. En el caso de que las restricciones sean tan fuertes que no exista ninguna combinación de ejercicios que alcance los objetivos, el modelo debe ofrecer la posibilidad de sugerir nuevos ejercicios. Es decir, si no hay ejercicios disponibles en la base de datos o no existe ninguna combinación aplicable, el planificador puede sugerir aprender nuevos ejercicios con los que pueda encontrar un plan de terapia. Las caracterı́sticas del ejercicio sugerido debe permitir alcanzar los objetivos terapéuticos con el tiempo de sesión establecido. Los terapeutas podrán enseñar al sistema nuevos ejercicios que añadir a la base de conocimiento. Esta nueva funcionalidad admite la posibilidad de que no haya ningún tipo de conocimiento previo almacenado, de modo que se puedan ir añadiendo los nuevos ejercicios sugeridos por el planificador y aprendidos a través del terapeuta. La figura 3.4 recoge todos los conceptos del modelo presentado. A modo resumen, hay un conjunto de ejercicios almacenados en la base de conocimiento, donde la di- 34 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST ficultad y la intensidad de los mismos viene representada por el color azul para los ejercicios más duros y el verde los ejercicios más suaves. Se representan dos sesiones ya planificadas, donde se ven perfectamente las tres fases de calentamiento, entrenamiento y enfriamiento comenzando y terminando con ejercicios más suaves y los más fuertes en el centro de la sesión. La tercera sesión se encuentra en proceso de planificación, donde el planificador debe elegir cual de todas las posibilidades es la más adecuada de acuerdo a las restricciones del problema y la alcanzabilidad de las metas. Por lo tanto, podrá seleccionar uno de los ejercicios disponibles o en su lugar sugerir uno nuevo. Ejercicios almacenados E3 E7 E2 Sesiones planificadas … S1 S2 S3 E5 E9 E1 TOCLs Restricciones E6 E4 E0 E8 … E9 E7 E8 E1 E0 E2 E6 E5 E0 E3 E4 E3 E5 E6 E8 E1 Sugerir un nuevo L0 ejercicio E9 E1 E5 Alcanzar los TOCLs Figura 3.4: Proceso de planificación de terapias 3.1.2. Aproximación basada en HTN La generación automática de terapias es un problema que puede ser resuelto de una forma jerárquica. La cúspide de la jerarquı́a estarı́a liderada por una tarea que representase la totalidad de la terapia. Una terapia se descompondrı́a en sesiones, cada sesión estarı́a dividida en fases y cada fase en un conjunto de ejercicio. Como se muestra 3.1. DISEÑADOR DE TERAPIAS 35 en la figura 3.5, la estructura de la sesión viene dada las relaciones jerárquicas o de orden representadas por la descomposición HTN. Esta aproximación pretende ofrecer un modelo más fácilmente extensible y configurable, donde el conocimiento experto pueda ser incluido en cualquier momento. Para la tarea de modelado se ha utilizado el lenguaje HTN de SHOP2 [Nau et al., 2003] y para la experimentación y depuración su versión en java JSHOP2. generate-therapy new therapy new session fill-warmup-exercises add exercise learn exercise generate-session generate-exercises fill-training-exercises add exercise learn exercise finish therapy finish session fill-cooldown-exercises add exercise learn exercise Figura 3.5: Esquema del modelo jerárquico (HTN) 3.1.2.1. Problema de planificación Metas de planificación. Siguiendo la figura 3.5, la meta de la red jerárquica es la descomposición de la tarea generate-therapy. Esta tarea general está formada por tres argumentos: número de sesiones a planificar, duración de la sesión y el identificador del paciente. El algoritmo del planificador comienza un proce- 36 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST so de descomposición de la tarea hasta llegar al conjunto de acciones primitivas que completen el plan de ejercicios que alcancen los TOCLs establecidos. Estos TOCLs son modelados como predicados numéricos en la descripción del problema. Además, con el propósito de hacer un problema más fácilmente configurable se añaden un conjunto de parámetros que permiten ajustar qué ejercicios son considerados como fuertes o suaves o cuál debe ser la duración de cada fase (calentamiento, entrenamiento, enfriamiento). Ejercicios almacenados El conjunto de ejercicios se ha extraı́do del programa DEDOS (Aula de Pedagogı́a Terapéutica. CEIP Guadalquivir) proporcionado por el HUVR. Es posible que un ejercicio satisfaga más de una meta al mismo tiempo, por ello resulta interesante identificar cuánto aporta cada uno de los ejercicios a cada una de las metas. Estos ejercicios se representan según las especificaciones descritas en el modelo. A continuación se puede ver cómo se ha modelado un ejercicio concreto. En el ejemplo aparecen los atributos que se han definido para el ejercicio e0 : duración, intensidad, dificultad, grupo del ejercicio y niveles de adecuación. (exercise e0) (e-duration e0 1.3) (e-intensity e0 60) (e-difficulty e0 70) (e-group e0 g_train_muscles_joints) (adqcy-bimanual e0 1) (adqcy-fine-unimanual e0 0) (adqcy-coarse-unimanual e0 1) (adqcy-arm-positioning e0 2) (adqcy-hand-positioning e0 0) 3.1.2.2. Dominio de planificación El dominio HTN de planificación está estructurado según la figura 3.5, donde un conjunto de ejercicios es generado para un número de sesiones. Este comporta- 3.1. DISEÑADOR DE TERAPIAS 37 miento es modelado como una tarea recursiva (generate-session) (ver el código a continuación) que recibe el número actual de sesión y el número total de sesiones a planificar como parámetros. La variable ?csn sirve como identificador de la sesión en el dominio y es incrementado para generar futuras sesiones: (:method (generate-session ?csn ?tsn) ;main ((call <= ?csn ?tsn)) ((!new-session ?csn ?tsn) (generate-exercises ?csn) (generate-session (call + ?csn 1) ?tsn)) ;stop ((call > ?csn ?tsn)) nil ) Cada sesión está dividida en tres fases que han sido modeladas como tareas de bajo nivel: fill-warmup-exercises, fill-training-exercises, fill-cooldown-exercises). El sistema debe distinguir cuál de los ejercicios es apropiado para cada fase de acuerdo a sus caracterı́sticas o decidir si debe sugerir uno nuevo en tiempo de planificación. • Axiomas. Los axiomas permiten inferir nuevos predicados de la evaluación de una expresión lógica (razonamiento abductivo). Se han definido axiomas en el modelo para controlar los intervalos de tiempo entre fases y evaluar qué ejercicios son más apropiados para cada fase de acuerdo a los atributos de intesidad y dificultad. Por ejemplo, (cooldown-time) y (cooldownexercise), en la figura 3.6, son llamadas a estos axiomas. Las expectativas con respecto a las variables de intensidad y dificultad a lo largo de las tres fases es que siga, como hemos explicado anteriormente, una distribución gausiana. El uso de axiomas en el dominio de planificación ayuda y simplifica el modelado de este requisito. 38 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST Task definition Precondition 1 Method 1 ;; Receives the session number and patient id (:method (fill-cooldown-exercises ?pid ?csn) (:sort-by ?ht > ((adqcy-bimanual ?e ?et1) (current-bimanual ?csn ?ct1a)(TOCL-bimanual ?t1bl) ... ;; Rest of objectives (e-used ?e ?n-used) (t-session-number ?tsn) (assign ?ht (call Heuristic ?et1 ?et2 ?et3 ?et4 ?et5 ?ct1a ?ct2a ?ct3a ?ct4a ?ct5a ?t1bl ?t2bl ?t3bl ?t4bl ?t5bl ?n-used ?tsn)) ... Method 2 (cooldown-time ?cst ?minST ?maxST) (not (hard-exercise ?e)) (cooldown-exercise ?e ?minST ?maxST) (not (used ?e ?csn)))) ((!include-db-ex ?e cool-down ...) Actions and task calls (fill-cooldown-exercises ?csn)) (:sort-by ?ht > ((bimanual-cfg ?et1) (current-bimanual ?csn ?ct1a) (TOCL-bimanual ?t1bl) ... ;; Rest of objectives (cooldown-time ?cst ?minST ?maxST) (cdw-limit ?cl) (suggested-exercises-counter ?exId) (assign ?dif (call - ?cl ?cst)) (cooldown-exercise ?e ?minST ?maxST) (e-used ?e ?n-used) (t-session-number ?tsn) Precondition 2 Phase control Heuristic function Method 3 (assign ?ht (call Heuristic ?et1 ?et2 ?et3 ?et4 ?et5 ?ct1a ?ct2a ?ct3a ?ct4a ?ct5a ?t1bl ?t2bl ?t3bl ?t4bl ?t5bl ?dcfg ?dif)) ((!suggest-nw-ex ?e cool-down ...) Actions and task calls (fill-cooldown-exercises ?csn)) Precondition 3 ((current-session-time ?csn ?cst) (session-max-time ?csn ?maxST) (call <= ?cst ?maxST) (current-acc t1 ?csn ?ct1a) (TOCL t1 ?t1bl) (call >= ?ct1a ?t1bl) ... Actions and task calls ((!finish-session ?csn))) Reaching TOCLs 2 Figura 3.6: Código JSHOP2 de la tarea que incluye nuevos ejercicios en la fase de enfriamiento (cool-down). • Tareas y métodos. Los métodos son utilizados para refinar a través de la descomposición en tareas de más alto a más bajo nivel hasta llegar a las acciones primitivas. Estos métodos tienen precondiciones que el estado del mundo debe cumplir para que puedan ser aplicables. En este modelo se utilizan cinco tareas: 1. (generate-therapy) tiene un único método con una precondición vacı́a 3.1. DISEÑADOR DE TERAPIAS 39 que aplica una descomposición de orden total para llamar a la tarea de bajo nivel (generate-session). 2. (generate-session) está modelado como una tarea recursiva que tiene un método para llamar a la tarea de bajo nivel (generate-exercises) y un valor vacı́o nulo “nil” que hace que se detenga una vez ha planificado todas las sesiones. 3. (generate-exercises) tiene un método único con precondición vacı́a que ejecuta una secuencia de tareas de bajo nivel de orden total (una por cada fase). 4. (fill-phase-exercises) está formado por trés métodos según vemos en la figura 3.6: ◦ Método 1: verifica a través de los axiomas que se encuentra en la fase correcta en función de la duración acumulada por los ejercicios planificados hasta ese momento y si el ejercicio elegido es adecuado para incluirlo. Además de considerar sus valores de adecuación, implica que no exista una restricción propia del paciente que impida utilizar dicho ejercicio. En caso que cumpla las precondiciones ejecuta la acción primitiva (!include-db-ex) que incluye el ejercicio a la sesión. ◦ Método 2: si no hay ningún ejercicio disponible que ejecutar en el primer método, el algoritmo visita el segundo método para calcular qué combinación de atributos es la más adecuada para sugerir un nuevo ejercicio al terapeuta que asegure el cumplimiento del plan de terapia. ◦ Método 3: el tercer método de la tarea (fill-cooldown-exercises) verifica si el conjunto de ejercicios planificados hasta ese momento alcanza los TOCLs establecidos por el rehabilitador y además se ha cumplido el tiempo de sesión establecido. En caso afirmativo, da por 40 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST finalizada la planificación de la sesión y continúa con el resto de la terapia. Para determinar la contribución o adecuación de un ejercicio para ser incluido en la sesión o también determinar qué caracterı́sticas deberı́a tener un nuevo ejercicio sugerido, se ha diseñado una función heurı́stica (ecuación 3.1) que permite seleccionar el ejercicio óptimo en función del valor heurı́stico calculado (?ht). En el caso del primer método, se calcula el valor heurı́stico de todos los ejercicios que hay almacenados. En el caso del segundo método, se utiliza la función heurı́stica sobre toda la combinación de valores que pueden tomar sus atributos del ejercicio a sugerir. Para ambos casos se aplica una función heurı́stica sort-by que ordena los valores permitiendo seleccionar aquel que haya obtenido el mejor valor. La función heurı́stica se aplica a todos los ejercicios y por cada uno de los objetivos. Se divide en dos sumandos, donde la primera parte se relaciona con la contribución del ejercicio a los objetivos terapéuticos (TOCLs). Se calcula para cada objetivo con la inversa de la diferencia entre el TOCL objetivo y el valor acumulado si se incluyera el ejercicio evaluado. A este primer sumando se le resta una penalización (segundo sumando) que se calcula con el número de veces que se ha utilizado dicho ejercicio partido del número total de sesiones de la terapia. De este modo, enfrentamos la contribución de los ejercicios con respecto a garantizar la variedad. nobjectives htex = X i=1 ( 1 extimes used − ) di + 1 numsessions 2 (3.1) • Acciones primitivas Se utilizan acciones vacı́as para delimitar el comienzo y fin de las sesiones y la terapia (ver figura 3.5). La acción que incluye un ejercicio almacenado, 3.1. DISEÑADOR DE TERAPIAS 41 actualiza el tiempo actual de la sesión (añadiendo la duración del ejercicio) y el nivel actual acumulado de los objetivos terapéuticos (añadiendo los valores de adecuación del objetivo a las metas) en dicha sesión. Además actualiza el estado del ejercicio a “utilizado” vinculado con el número de sesión, de modo que no pueda ser incluido de nuevo en la misma sesión. La acción primitiva que sugiere o aprende un ejercicio incluye en el estado del mundo un nuevo ejercicio con la combinación de atributos que ha sido planificada. 3.1.2.3. Estrategia de planificación La estrategia de planificación del modelo jerárquico persigue un diseño parametrizado que ofrezca una configuración flexible a los rehabilitadores. Por otro lado, con el objetivo de cumplir los objetivos clı́nicos y respetar las restricciones de variedad, este modelo propone el uso de una función que dirija la selección de ejercicios. En primer lugar el algoritmo ejecuta una descomposición de tareas de bajo nivel y la selección de ejercicios almacenados, la distribución y variedad, y la combinación de atributos sugeridos para el nuevo ejercicio son tres tareas guiadas por la función heurı́stica propuesta. El modelo permite hacer búsqueda a lo largo de la terapia para resolver posibles interacciones entre sesiones. Es decir, la capacidad de backtracking entre sesiones no está perdida ya que al tratarse de un modelo recursivo, esta propiedad queda preservada sin necesidad de intervención de ningún programa externo. 3.1.3. Interfaz de configuración Para la configuración de los parámetros de la terapia a generar se ha diseñado una interfaz que facilite esta tarea como se muestra en la figura 3.7. Un desplegable permite seleccionar el paciente que va a realizar la terapia entre los que haya en la base de datos. En ese instante, carga las restricciones por defecto del paciente 42 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST seleccionado y permite añadir otras nuevas. Los objetivos terapéuticos se pueden introducir a través de valores fijos establecidos en los intervalos (low, high, very high) o bien manualmente en el cuadro de texto. Para terminar de configurar la terapia, se deberá introducir las restricciones de duración de la sesión y el número total de sesiones a planificar. Figura 3.7: Interfaz para la configuración de la generación de terapias. 3.2. Planificación de las sesiones Para la ejecución de las sesiones planificadas, este trabajo propone una versión simplificada del caso de uso enfocado exclusivamente en el entrenamiento y monitorización de los ejercicios. El objetivo es que el robot sea capaz de efectuar el caso de uso completo representado en la figura 3.8. Otras acciones como acercarse 3.2. PLANIFICACIÓN DE LAS SESIONES 43 al paciente o acompañarle hasta la zona de entrenamiento, serán abordadas en el futuro. Robot en zona de demostración identificarPaciente Paciente identificado saludarPaciente Paciente saludado comenzarEntrenamiento Paciente en zona de entrenamiento introducirEjercicio Pose corregida continuarPose Ejecutando pose ejecutarPose Ejercitando ejercicio empezarEjercicio verificarPose corregirPose Paciente preparado ejecutarPose continuarPose Pose verificada finalizarPose Pose finalizada finalizarEjercicio Ejercicio finalizado introducirEjercicio finalizarEntrenamiento Sesión terminada finalizarSesión Paciente despedido despedirPaciente Entrenamiento finalizado Figura 3.8: Caso de uso para la planificación de las sesiones. El robot se encuentra esperando en la sala de rehabilitación, preparado para recibir a los pacientes. Cuando el paciente accede a la sala, el robot le identifica y le saluda. El paciente se sitúa a uno o dos metros del robot en la zona de entrenamiento. Los ejercicios están compuestos por una secuencia de poses. En función de los tipos de ejercicios asignados, el paciente deberá mantener cada una de las poses un tiempo determinado o ir cambiando de pose más rápidamente. Será el robot el que le indique qué debe hacer en cada momento. Cuando el robot introduzca un ejercicio, empezará con la ejecución de las poses. Para cada pose, se debe verificar la postura del paciente con respecto a la que le está mostrando el robot. En caso de que sea incorrecta, deberá corregirla hasta que se haya finalizado el tiempo de la pose. Se irán ejecutando secuencialmente el resto de poses que 44 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST conformen el ejercicio que está entrenando. Una vez haya terminado todas los ejercicios, se dará por finalizado el entrenamiento y el robot se despedirá del paciente. A lo largo del entrenamiento, el robot deberá dar una respuesta ante posibles situaciones inesperadas, como que el paciente se levante, que pierda la atención o que se vaya de la sala. Por otro lado, cuando se ejecuten acciones de corrección de una pose o introducción de nuevos ejercicios, es conveniente enviar mensajes de ánimo al paciente y felicitarle cuando lo esté haciendo correctamente. 3.2.1. Generación del problema El módulo generador del problema es un software intermedio que conecta la salida del planificador de alto nivel con el nivel medio de planificación (ver Figura 3.1). La secuencia de ejercicios planificada en el diseñador de terapias se interpreta por el generador del problema. Accede a la base de conocimiento de ejercicios con el identificador de cada ejercicio planificado para extraer la secuencia de poses necesaria para la planificación de la sesión. A continuación, realiza una traducción con la información de todas las poses y construye el problema de planificación en lenguaje PDDL de acuerdo al dominio que se explica en la próxima sección (3.2.2). Para modelar la posición que ocupan los ejercicios y las poses en la sesión se han utilizado valores numéricos. Como en el siguiente código de ejemplo, el ejercicio e18 está constituido por un total de 10 poses, (= (pose-number e18) 10). La pose p id0 está formada por por la postura del brazo izquierdo p0 y la del brazo derecho p4, (pose postures p id0 p0 p4). Se añade al modelo el instante de tiempo t1 en el que se ejecuta la pose (pose timestamp p id0 t1). La pose p id0 ocupa la posición cero en el ejercicio e18, (= (p-position p id0) 0). (= (e-position e18) 0) (mode_required e18 stand_up) (pose_exercise p_id0 e18) 3.2. PLANIFICACIÓN DE LAS SESIONES 45 (pose_postures p_id0 p0 p4) (pose_timestamp p_id0 t1) (= (p-position p_id0) 0) (pose_exercise p_id1 e18) (pose_postures p_id1 p4 p0) (pose_timestamp p_id1 t2) (= (p-position p_id1) 1) (= (pose-number e18) 2) Se establece como meta del problema que el paciente haya finalizado la sesión. El paciente en este caso tiene el identificador pt1 : (:goal (finished-session NAO pt1)) 3.2.2. Dominio de planificación de sesiones Se trata de un dominio PDDL basado en fluents (funciones y valores numéricos) para representar los bucles que suceden al ejecutar todos los ejercicios y sus respectivas poses como se muestra en el caso de uso (ver figura 3.8) A continuación se muestra un ejemplo simplificado de plan resultante. En el ejemplo se ejecutan dos ejercicios E22 y E20 con dos poses cada uno. La secuencia de acciones sigue el caso de uso, desde que identifica, saluda y comienza el entrenamiento hasta que finaliza todos los ejercicios, se despide y termina la sesión. Este plan está formado por 22 acciones, aunque la longitud de los planes con los que se trabaja es de más de 500 acciones. Estas acciones son monitorizadas una a una por PELEA, para verificar que los efectos de las acciones (el estado esperado) corresponde con el que recibe del exterior a través de los sensores. La acción número 17 (CORRECT-POSE) del ejemplo se ejecuta al detectar que el paciente no está haciendo la pose P ID03 correctamente. 46 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST 0: DETECT-PATIENT NAO PT1 1: IDENTIFY-PATIENT NAO PT1 2: GREET-PATIENT NAO PT1 3: START-TRAINING NAO LOC_TRAINING PT1 LOC_SHOW 4: INTRODUCE-EXERCISE E22 NAO PT1 5: START-EXERCISE E22 NAO PT1 STAND_UP 6: EXECUTE-POSE P_ID0 E22 P8 P6 T1 NAO PT1 STAND_UP 7: FINISH-POSE P_ID0 E22 P8 P6 T1 NAO PT1 8: EXECUTE-POSE P_ID1 E22 P6 P8 T2 NAO PT1 STAND_UP 9: FINISH-POSE P_ID1 E22 P6 P8 T2 NAO PT1 10: FINISH-EXERCISE E22 NAO PT1 11: INTRODUCE-EXERCISE E20 NAO PT1 12: SIT-DOWN E20 NAO PT1 STAND_UP SIT_DOWN 13: START-EXERCISE E20 NAO PT1 SIT_DOWN 14: EXECUTE-POSE P_ID2 E20 P4 P0 T1 NAO PT1 SIT_DOWN 15: FINISH-POSE P_ID2 E20 P4 P0 T1 NAO PT1 16: EXECUTE-POSE P_ID3 E20 P1 P0 T2 NAO PT1 SIT_DOWN 17: CORRECT-POSE P_ID3 E20 P1 P0 T2 NAO PT1 SIT_DOWN 18: FINISH-POSE P_ID3 E20 P1 P0 T2 NAO PT1 19: FINISH-EXERCISE E20 NAO PT1 20: FINISH-TRAINING NAO PT1 21: SAY-GOOD-BYE NAO PT1 22: FINISH-SESSION NAO PT1 Las acciones de este dominio podrı́an clasificarse en dos grupos: aquellas que están destinadas a la ejecución del caso de uso y las acciones modeladas para tratar situaciones inesperadas o eventos exógenos. Se define evento exógeno como una situación que no está prevista en la ejecución normal del caso de uso. Por ejemplo, el paciente se levanta y se marcha. Las acciones que dan forma a este dominio son: • detect-patient: sirve para confirmar que el paciente se encuentra detectado durante la sesión. Si el sensor dejara de detectar al paciente, enviarı́a un estado que no corresponderı́a con el esperado. La replanificación harı́a que esta acción se ejecutara antes de continuar con el entrenamiento. 3.2. PLANIFICACIÓN DE LAS SESIONES 47 • identify-patient: esta acción se ejecuta una vez se ha detectado al paciente y antes de saludarle para cargar su perfil y comenzar la rehabilitación. • greet-patient: saludar al paciente implica haberle identificado previamente, esta acción se realizará una sola vez al principio de la sesión. • start-training : esta acción se ejecuta tras determinar que el paciente se encuentra en el área de entrenamiento, el robot en el área de demostración y el paciente ha sido previamente saludado. A partir de ese instante, se considera que la sesión ha comenzado. • introduce-exercise: introducir el ejercicio implica dar detalles sobre lo que se va a ejercitar y cómo. Es necesario que el paciente tenga esta información antes de empezar a ejecutarlo. • stand-up y sit-down: cuando el ejercicio haya sido introducido, el sistema determina si el ejercicio debe hacerse de pie o sentado. En caso que ambos estén sentados y el ejercicio se realice de pie, el robot dará la orden de levantarse y viceversa. • start-exercise: cuando el paciente y el robot se encuentren en la posición que requiera el ejercicio, se empieza con el ejercicio. • execute-pose: esta acción ejecuta las acciones en el orden establecido por el problema y asume que el paciente la realiza de forma correcta. Entre sus parámetros, devuelve la postura de ambos brazos y el instante en el que se ejecuta. • correct-pose: la acción que corrige la pose se ejecuta cuando la información del estado que llega por los sensores indica que la pose no se realiza de forma correcta. PELEA inicia un proceso de replanificación y corrige la pose antes de continuar con la siguiente. • finish-pose: es una acción de control que incrementa el contador de poses de cada ejercicio y determina que la pose ha finalizado para poder dar paso a la siguiente. 48 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST • finish-exercise: al igual que finish-pose, se utiliza para establecer que el ejercicio se ha terminado y se puede ejecutar el siguiente. • finish-training : esta acción comprueba que todos los ejercicios de la sesión han sido ejecutados y da por finalizado el entrenamiento. • say-good-bye: cuando se ha finalizado el entrenamiento, el robot se despide del paciente y le anima a seguir con la rehabilitación. • finish-session: cuando el robot se despide del paciente se ejecuta la última acción que da por finalizada la sesión y por lo tanto, la última acción del plan. El resto de acciones del dominio, se han modelado para gestionar posibles situaciones inesperadas que requieren una respuesta del modelo deliberativo para mejorar la autonomı́a e interacción con el paciente. Las acciones que se muestran a continuación se ejecutan cuando llegan determinados eventos exógenos que modifican el estado del mundo durante la sesión. Esto quiere decir, que si por ejemplo el robot va a comenzar un ejercicio, pero se detecta que el paciente ha perdido la atención o se ha levantado, se produce un proceso de replanificación para manejar esta situación con alguna de las siguientes acciones: • claim-stand-up y claim-sit-down: estas acciones se dan cuando se detecta que el paciente ha modificado su posición. En el caso que el robot esté sentado y el paciente se haya levantado, ejecutará una acción para que le invite a sentarse de nuevo y viceversa. • claim-attention: durante la sesión, se asume que el paciente está siempre atento. Sin embargo, los sensores pueden detectar su nivel de atención y en caso que sea necesario se ejecutará una acción que capte de nuevo su interés. • pause-session: esta acción se ha modelado para que se ejecute en el caso que ocurra una situación de emergencia o inmanejable por el robot y que necesite reclamar la participación del terapeuta. 3.3. RECONOCIMIENTO DE POSTURAS 49 • resume-session: en el caso que se resuelva la situación de emergencia, se podrá continuar con el proceso de rehabilitación. • cancel-session: el entrenamiento se cancelará cuando la situación de emergencia no pueda ser resuelta por el terapeuta y requiera finalizar la sesión. 3.3. Reconocimiento de posturas Este apartado propone un modelo de aprendizaje relacional para la identificación de gestos y posturas corporales. Se utiliza el sensor Kinect de Microsoft que ofrece un conjunto de librerı́as y herramientas para facilitar la captura de datos relevantes a las articulaciones del cuerpo humano. Como se muestra en la figura 3.9, una persona se sitúa frente al sensor, el cual interpreta la información de profundidad de la escena y superpone un esqueleto sobre el individuo. Se construyen los predicados para el modelo relacional con los datos capturados relativos a cada una de las articulaciones del esqueleto generado. Una vez se ha generado y etiquetado el conjunto de ejemplos de entrenamiento, se introduce en el software de aprendizaje TILDE [Blockeel and De Raedt, 1998]. Se evalúan los resultados obtenidos, en calidad de precisión, error y matriz de confusión. Finalmente, se obtiene un modelo preparado para la fase de explotación en un sistema como soporte a la interacción. 3.3.1. Interfaz de captura de datos Un ejemplo de entrenamiento está formado por un conjunto de predicados que representan la posición del esqueleto. Con el objetivo de facilitar la adquisición y etiquetado de estos ejemplos, se ha modificado la interfaz básica de Skeleton Basics y se han añadido nuevos controles en la parte inferior de la ventana (ver figura 3.10). De derecha a izquierda, aparecen nueve botones que etiquetan cada una de las posiciones contempladas en este modelo. Cuando se presiona uno de 50 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST Kinect SDK + Captura de datos + Generación de predicados TILDE Top-down Induction of Logical Decision Trees (C45) Modelo Relacional Sistema de reconocimiento de posturas. Figura 3.9: Sistema de reconocimiento de posturas. estos botones se captura una instantánea del esqueleto sobre la cual se construye un ejemplo de entrenamiento etiquetado y se guarda a fichero. Si el cuadro “NoArms” está activado, se generan ejemplos de entrenamiento sin considerar las articulaciones superiores. Esta caracterı́stica resulta muy útil cuando quieres clasificar posturas donde las articulaciones introduzcan demasiado ruido (ej. de pie, sentado). Los botones “Del Files” y “Cl” sirven para controlar los ficheros generados y la impresión por consola del programa. El modo sentado se activa al marcar “Seated Mode” donde únicamente se representan las extremidades superiores, el pecho y la cabeza. El software implementado en el SDK de la Kinect permite configurar la salida de los ficheros con los ejemplos de entrenamiento. Se permite al usuario configurar los predicados con los que desea experimentar con el objetivo de comparar cuáles aportan más o menos al modelo de aprendizaje. 3.3. RECONOCIMIENTO DE POSTURAS 51 Figura 3.10: Interfaz para la adquisición de ejemplos de entrenamiento. 3.3.2. Construcción del modelo relacional La idea principal es encontrar qué tipo de relaciones pueden darse entre las distintas articulaciones del cuerpo humano. Se trata de una tarea muy importante que condiciona el éxito o fracaso del modelo relacional. La primera dificultad que se encuentra es que los datos recogidos por la Kinect de cada articulación son sus coordenadas numéricas X,Y,Z y para construir nuestro conjunto de ejemplos necesitamos transformar esos valores continuos en predicados que representen relaciones discretas. La generación de determinados predicados puede requerir cálculos previos de distancias, ángulos o rotaciones y posteriormente una discretización de estos valores. En los siguientes puntos se detallan los 5 tipos de 52 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST predicados generados en este trabajo y que van a representar la forma de nuestro conjunto de ejemplos. • Percepción de la articulación Se consideran dos predicados, el primero de ellos hace referencia al estado sobre la percepción del sensor Kinect para cada una de las articulaciones. No requiere ningún cálculo adicional puesto que el entorno de desarrollo devuelve el estado de cada articulación. En la figura 3.11 la articulación ElbowLeft(X,Y,Z) se muestra en color verde puesto que su estado es visible para el sensor. Por otro lado, ShoulderLeft(X,Y,Z) aparece representado de color amarillo ya que la articulación se encuentra oculta y el sistema hace una estimación sobre su posición. Figura 3.11: Percepción de la articulación. Por lo tanto se consideran dos tipos de predicados, uno para cuando la articulación está visible y otra para cuando se infiere su posición: ◦ state traked(joint) ◦ inferred(joint) 3.3. RECONOCIMIENTO DE POSTURAS 53 • Distancia entre articulaciones Este predicado se calcula a partir de la distancia entre todas las articulaciones. El resultado se normaliza con respecto al tamaño de la cabeza que es algo que no varı́a y se mantiene estable (distancia de la cabeza al pecho). Se calcula la distancia euclı́dea entre todos los pares de articulaciones posibles (ver figura 3.12). Se normalizan los valores entre 0 y 1 y se discretizan para formar los predicados en una escala de cinco valores. Para cada par de articulaciones hay un atributo que relaciona su distancia: ◦ distance very near(joint,joint) ◦ distance near(joint,joint) ◦ distance middle(joint,joint) ◦ distance far(joint,joint) ◦ distance very far(joint,joint) Figura 3.12: Distancia entre articulaciones. 54 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST • Distancia a la cámara Para la construcción de predicados en función de la distancia de la cámara, hay que tener en cuenta que entre ejemplo y ejemplo no se guarda ninguna referencia de distancia, de modo que los valores discretos que se establezcan deben guardar una relación que no se pierda cuando varı́e la distancia con respecto a la cámara en cada captura. Figura 3.13: Representación de la distancia a la cámara con tres planos. En primer lugar se han calculado todas las distancias de las articulaciones con respecto a la cámara utilizando la distancia euclı́dea. Con el objetivo de tener una relación de distancia con respecto a la cámara se han considerado tres planos distintos en función de la cercanı́a al cuerpo de la persona (ver figura 3.13): el plano frontal define la región por delante del cuerpo, el plano medio es la región a la altura del tronco y el plano trasero representa aquello que se encuentre por detrás del cuerpo. Para la construcción de las tres regiones, se considera la distancia de los hombros como distancia entre el plano frontal y trasero, dejando la región interior para el plano medio. Con todas las distancias de las articulaciones calculadas sobre la cámara se establece una discretización en función de en qué plano se encuentren. Los predicados considerados son: 3.3. RECONOCIMIENTO DE POSTURAS 55 ◦ front plane(joint) ◦ middle plane(joint) ◦ back plane(joint) • Balance articular El balance articular se refiere a la medición de la medida de flexión y extensión de cada una de las articulaciones. Para la generación de estos predicados se ha calculado el ángulo que forma cada articulación con respecto a sus articulaciones adyacentes. Figura 3.14: Balance articular. Por ejemplo, en la figura 3.14 vemos que el ángulo que forma “ElbowLeft” con respecto a “WristLeft” y “ShoulderLeft” se considerarı́a como ((flexionado)). Para ellos se han calculado los dos vectores con respecto a la articulación origen y se ha aplicado la fórmula del coseno para calcular el ángulo que forman. Se discretizan los valores en una escala de tres valores y se generan los siguientes predicados: ◦ angle flexion(joint) ◦ angle middle(joint) ◦ angle extension(joint) 56 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST • Relación de simetrı́a articular En estos predicados se busca una relación entre los pares de articulaciones simétricas con respecto a la profundidad. Es decir, se pretende comparar si cada par de articulación está a la misma altura o una está por detrás de otra. Se han considerado los siguientes pares: ◦ Hombro izquierdo – Hombro derecho ◦ Codo izquierdo – Codo derecho ◦ Mano izquierda – Mano derecha ◦ Cadera izquierda – Cadera derecha ◦ Rodilla izquierda – Rodilla derecha ◦ Pie izquierdo – Pie derecho. Figura 3.15: Rotación de los hombros vista desde arriba. En la figura 3.15 se muestran dos posturas diferentes. El primer esqueleto representa a un individuo de frente y el segundo se encuentra girado hacia izquierda. Del mismo modo se muestran dos representaciones desde arriba con estas dos 3.3. RECONOCIMIENTO DE POSTURAS 57 posiciones. Calcular la relación de profundidad entre las dos articulaciones es análogo a calcular la rotación sobre el vector que une las mismas. En la imagen vista desde arriba se muestra un punto rojo que representa el ángulo que se ha calculado para determinar la rotación y por lo tanto relación de profundidad de las dos articulaciones. Finalmente el valor obtenido se discretiza para determinar si una articulación está detrás de la otra o a la misma altura. • depth behind(joint,joint) • depth same(joint,joint) 3.3.3. Fase de aprendizaje Para llevar a cabo el aprendizaje del sistema se han capturado un total de 354 ejemplos de entre 9 clases diferentes. Donde se han elegido algunas posturas y gestos que puedan ser conflictivas entre sı́, debido a la similitud de la pose. Se consideran: • 5 Posturas ◦ Stand up: de pie frente a la cámara. ◦ Sit down: sentado frente a la cámara. ◦ Turn Right: de pie mostrando el perfil izquierdo a la cámara. ◦ Turn Left: de pie mostrando el perfil derecho a la cámara. ◦ Squating: de cuclillas frente a la cámara. • 4 Gestos ◦ Waving: de pie saludando a la cámara. ◦ Pointing: de pie señalando a distintos puntos. ◦ Cross arms: de pie cruzado de brazos. ◦ Bored: sentado con la cabeza apoyada en la cara. 58 CAPÍTULO 3. ARQUITECTURA NAOTHERAPIST Los ejemplos se han capturado desde distintas posiciones con respecto a la cámara (lejos, cerca, a los lados) con el objetivo de hacer un sistema más robusto y evitar en la medida de lo posible el overfitting sobre los ejemplos. Con el objetivo de evitar también el sobreajuste a las posturas y gestos de una única persona, han sido tres personas diferentes las que han ayudado a completar este conjunto de ejemplos. La fase de aprendizaje se ha llevado a cabo con el software ACE y el algoritmo TILDE. Capı́tulo 4 Análisis experimental Los experimentos se han desarrollado con un ordenador con las siguientes caracR CoreTM i3-3220 CPU @ 3.30GHz × 4. Ubuntu 13.04 64bits, 8 terı́sticas: Intel GB de RAM. El objetivo de la experimentación es determinar los beneficios y debilidades de los dos modelos planteados en este trabajo. Por un lado, se pretende hacer una evaluación del generador automático de terapias en términos de escalabilidad del problema, variedad de los ejercicios y distribución de la intensidad y dificultad a lo largo de las sesiones. Por otro lado, el modelo relacional propuesto para el reconocimiento de poses es evaluado con ejemplos de tres individuos diferentes y con poses que puedan resultar conflictivas a la hora de hacer predicciones. La planificación y monitorización de las sesiones es una tarea que se evalúa sobre la arquitectura completa. El proceso de planificación y replanificación funciona correctamente y es capaz de ejecutar el caso de uso completo. Esto se puede ver en los vı́deos publicados en el canal: https://www.youtube.com/user/NAOTherapist 4.1. Generador automático de terapias Para el modelo jerárquico, se ha utilizado el software JSHOP2 [Nau et al., 2003] que provee una interfaz que facilita la ejecución de experimentos. 59 60 CAPÍTULO 4. ANÁLISIS EXPERIMENTAL 4.1.1. Escalabilidad del problema Como recordatorio, la generación automática de terapias tiene dos objetivos principales: alcanzar los valores meta establecidos por los rehabilitadores (TOCLs) y conseguir que los ejercicios se distribuyan de forma variada. Como restricción adicional está la duración, el plan de ejercicios no puede superar los lı́mites establecidos en la sesión. El tiempo que se tarda en generar un plan es muy dependiente de los parámetros que se establezcan en el problema. Es decir, un problema con unos TOCLs muy altos con respecto a la contribución total de los ejercicios y con un tiempo muy ajustado, resultará mucho más costoso que con unos parámetros más relajados. Sin embargo, esto resulta ser una ventaja para evaluar el modelo y más concretamente, la estrategia de búsqueda. Esta aproximación jerárquica implementa una función heurı́stica para la selección de los ejercicios más adecuados y además penaliza aquellos que se hayan repetido más veces. En este experimento se pretende escalar el problema aumentando el número de sesiones para ver cómo se comporta la función heurı́stica respecto a una polı́tica circular que escoja los ejercicios menos repetidos. Ambas estrategias deberán resolver el problema con los TOCLs establecidos. El primer experimento se realiza con unos TOCLs medios de modo que el problema es más relajado. En la figura 4.1, el eje X representa el número de sesiones y el eje Y el tiempo en segundos. Tanto la estrategia circular como la función heurı́stica, a pesar de incrementar el número de sesiones, no presentan una separación grande. Por lo tanto, el ahorro de tiempo no es muy elevado con un número pequeño de sesiones. Para forzar a que la búsqueda sea más complicada, en el segundo experimento se aumentan los TOCLs. Los resultados se pueden ver en la tabla 4.1. El tiempo en planificar dos sesiones es igual en ambas estrategias. Con cuatro sesiones se diferencia bastante y la polı́tica circular se ve afectada. En el caso de 6 sesiones o más, la función heurı́stica obtiene unos resultados muy superiores sobre una 4.1. GENERADOR AUTOMÁTICO DE TERAPIAS 61 polı́tica simple circular. Esto quiere decir que la contribución de los ejercicios a los TOCLs como criterio de selección del ejercicio funciona mucho mejor que cualquier estrategia a ciegas. Por lo que valida el uso de la función heurı́stica sobre dejar que sea el algoritmo del planificador el que haga esta selección. 35 30 25 20 15 10 5 0 5 10 20 F. Heuristica 50 100 Politica circular Figura 4.1: Evaluación de la escalabilidad del problema con TOCLs medios enfrentando una polı́tica circular con la función heurı́stica propuesta. El eje X representa el número de sesiones y el eje Y el tiempo en segundos. 2 4 6 10 F. Heurística 1,01 1,48 2,75 2,65 Política circular 1,02 8,65 > 1800 > 1800 Sesiones 20 50 70 100 6,46 18,08 240,06 764,07 > 1800 > 1800 > 1800 > 1800 Tabla 4.1: Tiempo de planificación (segundos) enfrentando una polı́tica circular con la función heurı́stica propuesta en un problema con TOCLs muy altos. 62 CAPÍTULO 4. ANÁLISIS EXPERIMENTAL 4.1.2. Distribución de los ejercicios El siguiente experimento tiene como objetivo mostrar la distribución de 15 sesiones de planificación con 70 ejercicios en la base de conocimiento con una duración de 25 a 30 minutos por sesión. En la tabla 4.2, se representan en diferentes colores las tres fases de las que se compone una sesión (calentamiento, entrenamiento y enfriamiento). Según se puede observar, la penalización por la repetición de los ejercicios que viene reflejada en la función heurı́stica permite que haya variedad entre sesiones y evita los ciclos. El modelo, además, impide que se repitan ejercicios en una misma sesión o en la misma posición que última ocurrencia. En este caso, puesto que hay suficientes ejercicios, no se requiere de acciones que sugieran nuevos ejercicios, de modo que el planificador es capaz de encontrar un plan de ejercicios variado que alcanza los objetivos terapéuticos establecidos (TOCLs). Ejercicios S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 e18 e12 e19 e18 e6 e26 e18 e12 e26 e18 e22 e12 e19 e28 e18 e19 e6 e22 e19 e12 e27 e19 e6 e27 e19 e18 e6 e22 e12 e19 e25 e22 e28 e26 e18 e28 e26 e18 e28 e26 e25 e22 e26 e6 e25 e26 e18 e25 e27 e19 e25 e27 e19 e25 e27 e26 e18 e27 e19 e26 e1 e0 e31 e28 e25 e2 e28 e25 e1 e28 e2 e0 e1 e20 e5 e11 e29 e2 e1 e31 e0 e2 e31 e5 e1 e11 e29 e17 e30 e8 e31 e30 e10 e17 e5 e20 e11 e0 e21 e17 e31 e30 e31 e11 e29 e29 e31 e16 e20 e7 e31 e21 e8 e31 e11 e29 e31 e20 e8 e30 e30 e8 e7 e21 e8 e16 e20 e7 e29 e8 e30 e13 e21 e14 e31 e17 e13 e8 e24 e13 e3 e16 e14 e30 e3 e20 e8 e5 e13 e21 e3 e14 e13 e4 e14 e10 e4 e13 e16 e10 e21 e14 e0 e7 e20 e10 e11 e14 e3 e10 e4 e3 e16 e17 e16 e24 e17 e4 e3 e10 e16 e17 e11 e10 e3 e17 e10 e3 e7 e13 e23 e7 e3 e16 e4 e4 e3 e9 e16 e4 e11 e5 e10 e12 e14 e19 e9 e10 e9 e22 e7 e9 e15 e23 e9 e15 e22 e9 e6 e7 e27 e15 e9 e15 e9 e9 e15 e12 e22 e15 e6 e9 e15 e9 e12 e28 e25 e15 e22 e15 e15 e6 e27 e9 e22 e12 e15 e6 e22 e15 e6 e23 Tabla 4.2: Representa la distribución de los ejercicios a lo largo de 15 sesiones para el mismo paciente y con los mismos objetivos. Los colores de las celdas representan las diferentes fases de la sesión: el verde se relaciona con fase de calentamiento, las amarillas para el entrenamiento y el color azul es la fase de enfriamiento. 4.1. GENERADOR AUTOMÁTICO DE TERAPIAS 4.1.3. 63 Distribución de la intensidad y dificultad Con el objetivo de evaluar la distribución de la intensidad y dificultad, se construye un problema con 72 ejercicios. Este experimento se lleva a cabo con la siguiente configuración: 30 sesiones de 25 a 30 minutos, el 20 % del tiempo total de la sesión se asigna a la fase de calentamiento y enfriamiento, mientras que el 60 % restante es para la fase de entrenamiento. Aquellos ejercicios con una intensidad y dificultad entre 0 y 30 se considerarán como suaves, mientras que los que superen este intervalo se consideran como fuertes. Los efectos de la distribución de la intensidad y dificultad sobre el plan resultante vienen reflejados en la figura 4.2, donde se puede ver que estas variables se aproximan a una distribución gausiana deseada a lo largo de las tres fases. 50 40 Intensidad 30 Dificultad 20 10 0 1 2 3 4 5 6 7 8 9 10 11 Figura 4.2: Representa los valores medios de la intensidad y dificultad de los ejercicios para 30 sesiones generadas. A lo largo de las tres fases (calentamiento, entrenamiento y enfriamiento) el progreso de las dos variables queda representado por esta distribución gausiana. 64 CAPÍTULO 4. ANÁLISIS EXPERIMENTAL 4.2. Reconocimiento de posturas La fase de evaluación del modelo basado en aprendizaje relacional se divide en tres experimentos. El primero de ellos entrena un modelo centrado en cinco posturas, en segundo lugar se propone un modelo basado en cuatro gestos y para terminar se hace una prueba de concepto prediciendo las nueve clases (posturas y gestos). En los resultados de cada experimento se muestran dos matrices de confusión y los valores de precisión y error asociados al aprendizaje y al test. Los puntos principales que se quieren demostrar en la experimentación son: 1. Si existen relaciones entre los predicados que permitan predecir las clases. 2. Si el sistema es resistente y alcanza una precisión razonable. 3. Qué predicados no aportan nada al modelo resultante. 4. Qué posturas tienen mayor dificultad para ser clasificadas y por qué. 5. Qué información útil se puede sacar del árbol generado. 6. Si hay un modelo que prediga las nueve clases al mismo tiempo. 4.2.1. Experimento con 5 posturas En esta primera fase se entrena el modelo para predecir 5 posturas corporales: stand up (de pie), sit down (sentado), turn right (girado a la derecha), turn left (girado a la izquierda), squating (de cuclillas). Según se muestra en la tabla 4.3, la precisión respecto a la fase de entrenamiento es del 93,75 % con 162 ejemplos. La matriz de confusión muestra que casi todos los ejemplos se encuentran en la diagonal. La fase de test (tabla 4.4) obtiene una precisión del 87,5 % y la distribución de los ejemplos en la matriz de confusión se parece mucho a la de entrenamiento, por lo que no se produce sobreajuste. En ambas fases vemos que existen pequeñas dificultades al distinguir entre estar 4.2. RECONOCIMIENTO DE POSTURAS REAL/PRED Stand_up Stand_up 31 Sit_down Sit_down 21 Turn_Right 1 65 Turn_Right Turn_Left 2 1 Squating 34 7 28 32 33 35 Turn_Left 35 Squating 31 22 34 36 32 32 39 162 Entrenamiento Stand_up Sit_down Turn_Right Turn_Left Squating True-Positives 0.911 0.75 0.969 1 1 False-Positives 0 0.007 0.015 0.007 0.053 (Entrenamiento) 93.75% Precisión Error 0.0197 Coeficiente de Cramer 0.92 Tabla 4.3: Matriz de confusión y resultados con 5 posturas y 162 ejemplos de entrenamiento. sentado (sit down) y estar de cuclillas (squating). Según los resultados de entrenamiento y test se han clasificado algunos ejemplos de sit down como squating. Las posiciones de cuclillas y sentado tienen las rodillas flexionadas y la distancia general entre las articulaciones es menor, por lo que ciertamente habrá bastantes predicados comunes a ambas. El árbol generado nos permite extraer conclusiones acerca del patrón relacional encontrado. La relación de profundidad, las distancias entre articulaciones y los planos generados son los predicados más relevantes para la predicción de estas clases. En primer lugar intenta determinar si las articulaciones izquierdas están por detrás de las derechas, en caso que ası́ sea se clasifica como turn left. En caso contrario, evalúa la distancia entre articulacio- 2013/14 Aprendizaje de Posturas 66 CAPÍTULO 4. ANÁLISIS EXPERIMENTAL REAL/PRED Stand_up Stand_up 7 Sit_down Turn_Right Turn_Left Squating 7 8 Sit_down 5 13 7 Turn_Right 7 5 Turn_Left 5 Squating 7 8 7 5 8 8 13 40 Test Stand_up Sit_down Turn_Right Turn_Left Squating True-Positives 1 0.61 1 1 1 False-Positives 0 0 0 0 0.156 (Test) 87.5% Precisión Error 0.0522 Coeficiente de Cramer 0.92 Tabla 4.4: Matriz de confusión y resultados con 5 posturas y 40 ejemplos de test. nes. Si no hay distancia lejana se clasifica como squatting (las articulaciones están muy juntas en cuclillas). En caso contrario, se evalúa la situación sobre los planos. El modelo clasifica como sit down cuando hay partes que salen del plano medio (piernas por delante). Si por el contrario, las articulaciones se encuentran en el plano medio, determina si está de pie o girado a la izquierda en función de si los pares simétricos de articulaciones están a la misma profundidad (de frente). 4.2. RECONOCIMIENTO DE POSTURAS 4.2.2. 67 Experimento con 4 gestos El segundo experimento pretende hacer una predicción sobre 4 gestos diferentes: waving (saludando), pointing (señalando), cross arms (cruzado de brazos), bored (sentado y aburrido). REAL/PRED Waving Pointing Cross_arms Waving 46 1 2 Pointing 3 45 Bored 49 3 51 Cross_arms 46 1 47 Bored 2 43 45 50 47 192 49 46 Entrenamiento Waving Pointing Cross_arms Bored True-Positives 0.938 0.882 0.97 0.95 False-Positives 0.02 0.007 0.027 0.027 (Entrenamiento) 93.7% Precisión Error 0.0174 Coeficiente de Cramer 0.918 Tabla 4.5: Matriz de confusión y resultados con 4 gestos y 192 ejemplos de entrenamiento. La clasificación de gestos ha obtenido también muy buenos resultados. En la tabla 4.5, la precisión para el conjunto de entrenamiento es de 93,7 % con 192 ejemplos y de 87,5 % con 48 ejemplos en la tabla 4.6 de test. Las distribuciones Curso 2013/14 Aprendizaje de Posturas 68 CAPÍTULO 4. ANÁLISIS EXPERIMENTAL REAL/PRED Waving Pointing Cross_arms Bored Waving 8 1 1 1 Pointing 2 7 9 12 Cross_arms Bored 10 11 8 13 1 13 15 15 17 48 Test Waving Pointing Cross_arms Bored True-Positives 0.72 0.7 0.92 1 False-Positives 0.054 0.025 0.028 0.06 (Test) 87.5% Precisión Error 0.0477 Coeficiente de Cramer 0.83 Tabla 4.6: Matriz de confusión y resultados con 4 gestos y 48 ejemplos de test. de las dos matrices de confusión son muy parecidas y los falsos positivos son bastante bajos. Por los resultados de test vemos que no se produce sobreajuste sobre el entrenamiento. Tampoco se aprecia ningún caso especial en el que dos clases se confundan entre sı́. En general son resultados bastante uniformes. El árbol generado por el modelo se complica más que en el caso anterior. En este experimento, para poder clasificar si está aburrido o si los brazos están cruzados aparece por primera vez el predicado que mide la flexión y extensión de las articulaciones. Este predicado junto con la distancia sobre los planos sirve para determinar si está o no señalando. 4.2. RECONOCIMIENTO DE POSTURAS 4.2.3. 69 Experimento con 5 posturas y 4 gestos El último experimento hace una predicción sobre las 9 clases (gestos y posturas). Se quiere comprobar si el sistema es capaz de encontrar un árbol válido que clasifique posturas y gestos donde existe mucho solapamiento. Es decir, distinguir entre std up (estar de pie), waving (saludando), pointing (señalando) y cr arms (cruzado de brazos) no es algo trivial puesto que en todas ellas el sujeto está de pie frente al sensor y lo único que puede cambiar es la posición de los brazos. Del mismo modo ocurre con los ejemplos para s down, squating y bored donde el humano se encuentra sentado o agachado (la distancia entre articulaciones es mucho menor) y en el caso de bored sólo cambia que la cabeza se apoya en una de las manos. No existe mucha diferencia entre la información que se puede extraer de las posturas y los gestos. Además, muchos gestos ya contemplan la propia postura. La idea es evaluar la resistencia del modelo predictivo y ası́ poder determinar si el sistema es capaz de determinar patrones menos evidentes entre todo el conjunto de ejemplos. Para el experimento se han utilizado 354 ejemplos para entrenamiento y 88 ejemplos para validación y se ha obtenido una precisión del 86,7 % y 78,4 %, tablas 4.7 y 4.8 respectivamente. Ambas matrices mantienen una distribución muy parecida. Los falsos positivos se concentran sobre todo cuando intenta distinguir entre waving y pointing puesto que es complicado determinar si el sujeto está señalando o levantando la mano para saludar. Por otro lado, bored y s down generan confusión puesto que ambos ejemplos se toman sentado, la única diferencia es que aburrido se representa con el cabeza apoyada sobre el brazo. En ninguno de los experimentos se ha encontrado un patrón relacional para el predicado relativo a cómo percibe la articulación (state tracked o inferred ), lo que lleva a pensar que no aporte nada al modelo (ver árbol generado en Apendice A.1). Por otro lado, la precisión se ha visto afectada al unificar las 9 clases y además vemos que el coeficiente de Cramer también se ha reducido. La relación por lo 2013/14 Aprendizaje de Posturas 70 CAPÍTULO 4. ANÁLISIS EXPERIMENTAL REAL/PRED Std_up Std_up 30 S_down 2 T_Right 1 S_down T_Right T_Left Squating Waving Pointing Cr_arms Bored 2 1 33 27 29 27 T_Left 1 2 1 3 1 36 1 35 31 27 Squating 6 4 31 36 5 2 45 Pointing 4 40 2 46 Cr_arms 1 49 50 Waving 1 1 Bored 4 34 Entrenamiento 31 1 30 27 28 45 52 54 42 47 53 354 Std_up S_down T_Right T_Left Squating Waving Pointing Cross_arms Bored True-Positives 0.9 0.75 0.82 0.87 0.87 0.8 0.86 0.98 0.89 False-Positives 0.012 0.012 0.003 0 0.003 0.029 0.0389 0.0164 0.035 (Entrenamiento) 86.7% Precisión Error 0.018 Coeficiente de Cramer 0.862 Tabla 4.7: Resultados con 5 posturas y 4 gestos y 354 ejemplos de entrenamiento. tanto entre las clases ha disminuido con lo que resulta más complicado encontrar un árbol que minimice ese error. Sin embargo el sistema se ha comportado de forma favorable a pesar de las similitudes entre clases y que han sido tres personas diferentes de las que se han tomado los ejemplos. También hay que tener en cuenta que el sensor Kinect hace estimaciones sobre la posición cuando deja de detectar una articulación. Muchas veces la estimación no es buena o realista y produce bastante ruido en el conjunto de ejemplos. A pesar de todo ello, la precisión sobre los conjuntos de test de todos los experimentos no ha bajado del 78 % y en los dos primeros ha llegado hasta casi el 90 %. 4.2. RECONOCIMIENTO DE POSTURAS 71 2013/14 Aprendizaje de Posturas REAL/PRED Std_up Std_up 8 S_down 1 S_down T_Right T_Left Squating Waving Pointing Cr_arms Bored 8 2 1 4 T_Right 1 1 6 T_Left 5 5 1 1 7 Squating 1 9 2 9 11 2 1 15 Pointing 2 10 1 14 Cr_arms 1 9 10 Waving 1 1 Bored 1 10 Test 2 5 6 9 15 13 12 12 13 16 88 Std_up S_down T_Right T_Left Squating Waving Pointing Cross_arms Bored True-Positives 1 0.4 0.8 0.66 0.7 0.73 0.71 0.9 0.92 False-Positives 0.025 0 0.012 0 0.02 0.054 0.04 0.038 0.053 (Entrenamiento) 78.4% Precisión Error 0.0438 Coeficiente de Cramer 0.772 Tabla 4.8: Resultados con 5 posturas y 4 gestos y 88 ejemplos de test. Capı́tulo 5 Discusión 5.1. Conclusiones Este trabajo resuelve varios problemas relacionados directamente con la arquitectura NAOTherapist propuesta. El primero de los objetivos es la generación automática de terapias que se sitúa en el alto nivel de planificación. Se ha desarrollado un programa intermedio que comunica ambos niveles de planificación. Para el módulo deliberativo PELEA, se ha modelado un dominio que se ajusta al caso de uso propuesto y reacciona ante determinados eventos que puedan suceder durante la sesión. En último lugar, se ha desarrollado una primera versión de un modelo relacional para el aprendizaje de posturas corporales para estimar la postura del paciente y verificar que los ejercicios se realizan correctamente. A continuación se desglosan las conclusiones especı́ficas que se han obtenido para cada uno de los módulos desarrollados. 5.1.1. Generación automática de terapias Se ha diseñado un módulo basado en planificación jerárquica para abordar la generación automática de terapias de rehabilitación motora para los miembros 72 5.1. CONCLUSIONES 73 superiores en pacientes con PBO y PCI. El modelo trata de encontrar una secuencia de ejercicios que, a partir de las condiciones del paciente y las restricciones temporales, alcance los objetivos terapéuticos establecidos por el médico rehabilitador. Este trabajo propone el uso del paradigma de planificación HTN que plantea el problema desde una perspectiva jerárquica y diseña un modelo piramidal. Al tratarse de un problema de naturaleza jerárquica, se prevé que la descomposición de tareas garantiza muy buenos resultados. Respecto a la naturaleza del dominio, cabe destacar que los axiomas mejoran la capacidad de configuración del modelo. Además, la búsqueda entre sesiones es una propiedad preservada gracias a la forma recursiva en la que se generan las sesiones. No se necesita ningún software externo que llame iterativamente al planificador cada vez que quiera planificar una nueva sesión. Experimentalmente se ha demostrado que el problema se hace más complejo cuando se ajustan al lı́mite los objetivos terapéuticos (TOCLs) en el tiempo de sesión establecido. De igual modo, la interacción entre las sesiones hacen que la complejidad del problema escale cuando se incrementa el número de sesiones. Sin embargo, se ha demostrado que la función heurı́stica diseñada para la selección de ejercicios obtiene unos resultados excepcionalmente buenos sobre una estrategia circular. Ambas garantizan la variedad de los ejercicios, pero la función heurı́stica considera la contribución de los ejercicios a los TOCLs, por lo que reduce notablemente el tiempo de planificación. Esta diferenciación destaca cuando los objetivos se sitúan muy altos de modo que el número de combinaciones que debe hacer una estrategia ciega explota. Por otra parte, los ejercicios se distribuyen de forma variada a lo largo de las sesiones, se evitan los ciclos e impide repeticiones en una misma sesión. Otro experimento demuestra que la distribución de la intensidad y dificultad de los ejercicios planificados sigue una gausiana a lo largo de la sesión. Esto permite que los ejercicios más suaves se hagan en las fases de calentamiento y enfriamiento y 74 CAPÍTULO 5. DISCUSIÓN los fuertes en la fase de entrenamiento, tal y como se define en la fase de requisitos del modelo. También tiene la capacidad de sugerir nuevos ejercicios en el caso que no haya suficientes disponibles. La función heurı́stica permite seleccionar la mejor combinación de atributos para el nuevo ejercicio y que además garantiza un plan válido que alcance los TOCLs del problema. 5.1.2. Planificación de las sesiones Uno de los objetivos de este trabajo es utilizar un módulo deliberativo que controle la ejecución de las sesiones. Para ello, se ha propuesto la arquitectura PELEA que permite la planificación, monitorización y ejecución de los planes de terapia. Este trabajo desarrolla un dominio que sigue las pautas del caso de uso propuesto y construye un problema a partir de sesiones planificadas por el generador automático de terapias. Cada vez que se ejecuta una acción, PELEA actualiza el estado esperado y lo compara con el que recibe de los sensores, en caso que no coincidan, comienza un proceso de replanificación. El dominio diseñado, maneja este tipo de situaciones y aquellas que vengan dadas por eventos exógenos como por ejemplo que el paciente se haya levantado, que pierda la atención o incluso que se marche de la sala. Desde el punto de vista experimental, el dominio se ha evaluado con PELEA y sobre la arquitectura completa. El objetivo es que el robot realice el caso de uso completo y las acciones enviadas por el planificador sean consecuentes en todo momento con respecto a los eventos que puedan suceder. La figura 5.1 muestra a un usuario imitando la pose del robot NAO. Además, estos experimentos han sido filmados y publicados en el canal de youtube: https://www.youtube.com/user/NAOTherapist 5.1. CONCLUSIONES 75 Figura 5.1: Usuario realizando el caso de uso con el robot NAO. 5.1.3. Reconocimiento de posturas Este trabajo propone una primera aproximación de un sistema de reconocimiento de gestos y posturas corporales. El sistema cuenta con un sensor Kinect para la adquisición de ejemplos. A partir del esqueleto generado sobre el cuerpo de la persona, se pueden obtener las coordenadas en el espacio tridimensional de cada articulación. Se ha diseñado un modelo relacional de predicados con información discretizada a partir de los valores continuos que provee la Kinect. Se ha realizado un proceso de captura y etiquetado de ejemplos (3 personas distintas) con ayuda de la interfaz desarrollada. Finalmente se han ejecutado tres experimentos con el algoritmo de TILDE para evaluar la precisión y resistencia del modelo a la hora de predecir diferentes tipos y número de clases. Volviendo a los puntos clave a determinar en los experimentos podemos concluir que: 1. La interpretación de los árboles generados demuestra que existen patrones que relacionan diferentes predicados. 76 CAPÍTULO 5. DISCUSIÓN 2. Los valores de precisión obtenidos en los experimentos se sitúan en torno al 85 % aportando muy pocos falsos positivos. El modelo es bastante resistente a ejemplos con nuevas personas y a clases muy similares donde las posturas y gestos comparten muchos predicados. 3. Los predicados state tracked y inferred no aportan nada a los modelos resultantes. 4. Se ha detectado que hay posturas y gestos muy parecidos (ej. sentado y cuclillas o saludar y señalar) que dificultan la tarea de predicción. 5. Los árboles contienen información sobre el patrón relacional que ha detectado el modelo y que puede ser utilizado posteriormente en una fase de explotación. 6. El último experimento obtiene un modelo que predice las nueve clases juntas y obtiene una precisión de 78.4 % sobre el conjunto de test. Aunque los resultados de los experimentos son bastante buenos, este modelo se sitúa en una primera iteración de la fase de aprendizaje. El objetivo es mejorar poco a poco el sistema y refinar los predicados para conseguir robustez y versatilidad para reconocer casi cualquier tipo de postura o gesto sin ningún tipo de restricción. 5.2. Trabajo futuro A lo largo del documento se han propuesto numerosas ideas para mejorar los resultados de este proyecto. Desde una perspectiva global, la arquitectura se encuentra en sus primeras fases de diseño. Actualmente se trata de un desarrollo ad hoc al problema presentado. Un robot NAO que sea capaz de llevar a cabo terapias de rehabilitación motoras. Sin embargo, en un futuro se pretende hacer una generalización de la arquitectura cognitiva, de modo que sea independien- 5.2. TRABAJO FUTURO 77 te de la plataforma robótica con la que trabaje, independiente del lenguaje de planificación y sea capaz de abordar problemas de similares caracterı́sticas. Más concretamente, el módulo de generación de terapias se encuentra en una primera fase experimental. En el artı́culo publicado [Pulido et al., 2014], se establecen unas conclusiones cualitativas sobre la experiencia de modelado y diferencias con respecto a la otra técnica empleada. Aunque este trabajo presenta experimentación cuantitativa, se quiere profundizar en esta tarea, para extraer conclusiones y optar a posibles mejoras en el modelo o en el algoritmo de planificación. Otra de las posibles mejoras serı́a tener una representación temporal del problema. La idea serı́a modelar las restricciones temporales que tienen las sesiones e intentar resolver el problema con planificadores que soporten estas caracterı́sticas como es el caso de Shiadex [Fdez-Olivares et al., 2006]. Por otro lado, los objetivos de la terapia podrı́an variar tras una evaluación del paciente. Para controlar esta situación, se podrı́an implementar métodos de replanificación jerárquica en caso que estos datos sufran algún tipo de modificación. La verificación de las poses se ha solucionado de forma ágil para permitir la ejecución del caso de uso y poder probar el sistema. En esta primera aproximación se toman los datos del las articulaciones de las extremidades superiores del paciente y se calculan sus ángulos correspondientes. Acto seguido se realiza una transformación de los datos de la Kinect a los datos del NAO [Alfaro Ballesteros, 2012]. De esta forma se unifican los ángulos para poder ser comparados mediante una función de distancia. Esta primera aproximación permite determinar si la pose que mantiene el paciente es o no correcta. Sin embargo, se propone extender el modelo relacional para el reconocimiento de posturas y ası́ poder predecir si el paciente está realizando correctamente un ejercicio. El objetivo último de este proyecto es llevar a cabo la ejecución de las sesiones con pacientes reales que puedan evaluar el sistema. Una vez se tenga una arquitectura madura, se podrán abrir nuevos objetivos en vı́as de ampliar el nivel 78 CAPÍTULO 5. DISCUSIÓN de autonomı́a, mejorar la interacción o incluso nuevos requisitos que mejoren la calidad de la terapia robótica. Bibliografı́a [Ahmed et al., 2010] Ahmed, S., Gozbasi, O., Savelsbergh, M. W. P., Crocker, I., Fox, T., and Schreibmann, E. (2010). An automated intensity- modulated radiation therapy planning system. INFORMS Journal on Computing, 22(4):568–583. (Cited on page 21) [Alcázar et al., 2010] Alcázar, V., Madrid, I., Guzmán, C., Prior, D., Borrajo, D., Castillo, L., and Onaindı́a, E. (2010). Pelea: Planning, learning and execution architecture. In In Proceedings of the 28th Workshop of the UK Planning and Scheduling Special Interest Group (PlanSIG’10), Brescia-Italy. (Cited on page 18) [Alfaro Ballesteros, 2012] Alfaro Ballesteros, S. (2012). Sistema de teleoperación mediante una interfaz natural de usuario. (Cited on page 77) [Argall et al., 2009] Argall, B. D., Chernova, S., Veloso, M., and Browning, B. (2009). A survey of robot learning from demonstration. Robotics and autonomous systems, 57(5):469–483. (Cited on page 24) [Bax et al., 2005] Bax, M., Goldstein, M., Rosenbaum, P., Leviton, A., Paneth, N., Dan, B., Jacobsson, B., and Damiano, D. (2005). Proposed definition and classification of cerebral palsy, april 2005. Developmental Medicine & Child Neurology, 47(08):571–576. (Cited on page 3) [Blockeel and De Raedt, 1998] Blockeel, H. and De Raedt, L. (1998). Top-down induction of first-order logical decision trees. Artificial intelligence, 101(1):285– 297. (Cited on page 49) 79 80 Bibliografı́a [Borggraefe et al., 2010] Borggraefe, I., Kiwull, L., Schaefer, J. S., Koerte, I., Blaschek, A., Meyer-Heim, A., and Heinen, F. (2010). Sustainability of motor performance after robotic-assisted treadmill therapy in children: an open, nonrandomized baseline-treatment study. Eur J Phys Rehabil Med. (Cited on page 5) [Burgar et al., 2000] Burgar, C. G., Lum, P. S., Shor, P. C., and Van der Loos, H. M. (2000). Development of robots for rehabilitation therapy: the palo alto va/stanford experience. Journal of rehabilitation research and development, 37(6):663–674. (Cited on page 12) [Calderita et al., 2013] Calderita, L., Bustos, P., Suárez Mejı́as, C., Fernández, F., and Bandera, A. (2013). Therapist: Towards an autonomous socially interactive robot for motor and neurorehabilitation therapies for children. In Pervasive Computing Technologies for Healthcare (PervasiveHealth), 2013 7th International Conference on, pages 374–377. (Cited on page v, vi, 2 und 5) [Castelli, 2011] Castelli, E. (2011). Robotic movement therapy in cerebral palsy. Developmental Medicine & Child Neurology, 53(6):481–481. (Cited on page 3 und 6) [Cenamor et al., 2014] Cenamor, I., de la Rosa, T., and Fernández, F. (2014). Ibacop and ibacop2 planner. (Cited on page 15) [Choe et al., 2013] Choe, Y.-k., Jung, H.-T., Baird, J., and Grupen, R. A. (2013). Multidisciplinary stroke rehabilitation delivered by a humanoid robot: Interaction between speech and physical therapies. Aphasiology, 27(3):252–270. (Cited on page 12) [Chuang et al., 1993] Chuang, D. C.-C., Epstein, M. D., Yeh, M.-C., and Wei, F.C. (1993). Functional restoration of elbow flexion in brachial plexus injuries: results in 167 patients (excluding obstetric brachial plexus injury). The Journal of hand surgery, 18(2):285–291. (Cited on page 3) [Dickinson et al., 2007] Dickinson, H. O., Parkinson, K. N., Ravens-Sieberer, U., Schirripa, G., Thyen, U., Arnaud, C., Beckung, E., Fauconnier, J., McManus, Bibliografı́a 81 V., Michelsen, S. I., et al. (2007). Self-reported quality of life of 8–12-year-old children with cerebral palsy: a cross-sectional european study. The Lancet, 369(9580):2171–2178. (Cited on page 4) [Drużbicki et al., 2013] Drużbicki, M., Rusek, W., Snela, S., Dudek, J., Szczepanik, M., Zak, E., Durmala, J., Czernuszenko, A., Bonikowski, M., and Sobota, G. (2013). Functional effects of robotic-assisted locomotor treadmill thearapy in children with cerebral palsy. J Rehabil Med. (Cited on page 5) [Dubowsky et al., 2000] Dubowsky, S., Genot, F., Godding, S., Kozono, H., Skwersky, A., Yu, H., and Yu, L. S. (2000). Pamm-a robotic aid to the elderly for mobility assistance and monitoring: a “helping-hand” for the elderly. In Robotics and Automation, 2000. Proceedings. ICRA’00. IEEE International Conference on, volume 1, pages 570–576. IEEE. (Cited on page 12) [Erol et al., 1994a] Erol, K., Hendler, J., and Nau, D. S. (1994a). HTN planning: Complexity and expressivity. In AAAI, volume 94, pages 1123–1128. (Cited on page 16) [Erol et al., 1994b] Erol, K., Hendler, J. A., and Nau, D. S. (1994b). Umcp: A sound and complete procedure for hierarchical task-network planning. In AIPS, volume 94, pages 249–254. (Cited on page 17) [Fasola and Mataric, 2010] Fasola, J. and Mataric, M. (2010). Robot exercise instructor: A socially assistive robot system to monitor and encourage physical exercise for the elderly. In RO-MAN, 2010 IEEE, pages 416–421. (Cited on page 12) [Fdez-Olivares et al., 2006] Fdez-Olivares, J., Castillo, L., Garcıa-Pérez, O., and Palao, F. (2006). Bringing users and planning technology together. experiences in siadex. In Proc ICAPS, pages 11–20. (Cited on page 18 und 77) [Fdez-Olivares et al., 2011] Fdez-Olivares, J., Castillo, L. A., Cózar, J. A., and Garcı́a-Pérez, Ó. (2011). Supporting clinical processes and decisions by hierarchical planning and scheduling. Computational Intelligence, 27(1):103–122. 82 Bibliografı́a (Cited on page 21) [Feil-Seifer and Mataric, 2005] Feil-Seifer, D. and Mataric, M. J. (2005). Defining socially assistive robotics. In Rehabilitation Robotics, 2005. ICORR 2005. 9th International Conference on, pages 465–468. IEEE. (Cited on page 1 und 11) [Feil-Seifer and Mataric, 2011] Feil-Seifer, D. and Mataric, M. J. (2011). Socially assistive robotics. Robotics & Automation Magazine, IEEE, 18(1):24–31. (Cited on page 1) [Foix et al., 2011] Foix, S., Alenya, G., and Torras, C. (2011). Lock-in time-offlight (tof) cameras: A survey. Sensors Journal, IEEE, 11(9):1917–1926. (Cited on page 22) [Fong et al., 2003] Fong, T., Nourbakhsh, I., and Dautenhahn, K. (2003). A survey of socially interactive robots. Robotics and autonomous systems, 42(3):143–166. (Cited on page 12 und 22) [Fridin et al., 2011] Fridin, M., Bar-Haim, S., and Belokopytov, M. (2011). Robotics agent coacher for cp motor function (rac cp fun). In Robotics for Neurology and Rehabilitation, IROS International Conference on Intelligent Robots and Systems. (Cited on page 12) [Fuentetaja, 2011] Fuentetaja, R. (2011). The cbp planner. The, pages 21–24. (Cited on page 15) [Garcia et al., 2011] Garcia, N., Sabater-Navarro, J. M., Gugliemeli, E., and Casals, A. (2011). Trends in rehabilitation robotics. Medical and Biological Engineering and Computing, 49(10):1089–1091. (Cited on page 6) [Ghallab et al., 2004] Ghallab, M., Nau, D., and Traverso, P. (2004). Automated planning: theory & practice. Elsevier. (Cited on page 13) [Gilbert and Whitaker, 1991] Gilbert, A. and Whitaker, I. (1991). Obstetrical brachial plexus lesions. Journal of Hand Surgery (British and European Volume), 16(5):489–491. (Cited on page 3) Bibliografı́a 83 [González-Ferrer et al., 2013] González-Ferrer, A., Ten Teije, A., Fdez-Olivares, J., and Milian, K. (2013). Automated generation of patient-tailored electronic care pathways by translating computer-interpretable guidelines into hierarchical task networks. Artificial Intelligence in Medicine, 57(2):91–109. (Cited on page 21) [Gonzalez-Pacheco et al., 2013] Gonzalez-Pacheco, V., Malfaz, M., Fernandez, F., and Salichs, M. A. (2013). Teaching human poses interactively to a social robot. Sensors, 13(9):12406–12430. (Cited on page 22) [Graf et al., 2010] Graf, J., Dittrich, F., and Wörn, H. (2010). High performance optical flow serves bayesian filtering for safe human-robot cooperation. In Robotics (ISR), 2010 41st International Symposium on and 2010 6th German Conference on Robotics (ROBOTIK), pages 1–8. VDE. (Cited on page 23) [Hall et al., 2009] Hall, M., Frank, E., Holmes, G., Pfahringer, B., Reutemann, P., and Witten, I. H. (2009). The weka data mining software: an update. ACM SIGKDD explorations newsletter, 11(1):10–18. (Cited on page 23) [Hoffmann et al., 2003] Hoffmann, J. et al. (2003). The metric-ff planning system: Translating ”ignoring delete lists” to numeric state variables. J. Artif. Intell. Res.(JAIR), 20:291–341. (Cited on page 15) [Krägeloh-Mann and Cans, 2009] Krägeloh-Mann, I. and Cans, C. (2009). Cerebral palsy update. Brain and development, 31(7):537–544. (Cited on page 3) [Lacey and Dawson-Howe, 1998] Lacey, G. and Dawson-Howe, K. M. (1998). The application of robotics to a mobility aid for the elderly blind. Robotics and Autonomous Systems, 23(4):245–252. (Cited on page 12) [Mahadevan et al., 1998] Mahadevan, S., Theocharous, G., and Khaleeli, N. (1998). Rapid concept learning for mobile robots. Autonomous robots, 5(34):239–251. (Cited on page 24) [Manso et al., 2010] Manso, L., Bachiller, P., Bustos, P., Núñez, P., Cintas, R., and Calderita, L. (2010). Robocomp: a tool-based robotics framework. In 84 Bibliografı́a Simulation, Modeling, and Programming for Autonomous Robots, pages 251– 262. Springer. (Cited on page 25) [Manso et al., 2014] Manso, L. J., Calderita, L. V., Bustos, P., Garcı́a, J., Muñoz, M. M., Rebollo, F. F., Garcés, A. R., and Bandera, A. (2014). A generalpurpose architecture to control mobile robots. In XV Workshop of physical agents: book of proceedings, WAF 2014, June 12th and 13th, 2014 León, Spain, pages 105–116. (Cited on page 20) [Matarić et al., 2007] Matarić, M. J., Eriksson, J., Feil-Seifer, D. J., and Winstein, C. J. (2007). Socially assistive robotics for post-stroke rehabilitation. Journal of NeuroEngineering and Rehabilitation, 4(5). (Cited on page 5, 6 und 12) [McDermott et al., 1998] McDermott, D., Ghallab, M., Howe, A., Knoblock, C., Ram, A., Veloso, M., Weld, D., and Wilkins, D. (1998). Pddl-the planning domain definition language. (Cited on page 16) [McMurrough et al., 2012] McMurrough, C., Ferdous, S., Papangelis, A., Boisselle, A., and Heracleia, F. M. (2012). A survey of assistive devices for cerebral palsy patients. In Proceedings of the 5th International Conference on PErvasive Technologies Related to Assistive Environments, PETRA ’12, pages 17:1–17:8, New York, NY, USA. ACM. (Cited on page 6) [Meyer-Heim and van Hedel, 2013] Meyer-Heim, A. and van Hedel, H. J. (2013). Robot-assisted and computer-enhanced therapies for children with cerebral palsy: current state and clinical implementation. In Seminars in pediatric neurology, volume 20, pages 139–145. Elsevier. (Cited on page 6) [Mitra and Acharya, 2007] Mitra, S. and Acharya, T. (2007). Gesture recognition: A survey. Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on, 37(3):311–324. (Cited on page 22) [Morignot et al., 2010] Morignot, P., Soury, M., Leroux, C., Vorobieva, H., and Hède, P. (2010). Generating scenarios for a mobile robot with an arm: Case Bibliografı́a 85 study: Assistance for handicapped persons. In Proceedings of 11th International Conference on Control Automation Robotics & Vision (ICARCV), pages 976–981. IEEE. (Cited on page 21) [Nalin et al., 2012] Nalin, M., Baroni, I., and Sanna, A. (2012). A Motivational Robot Companion for Children in Therapeutic Setting. In IROS 2012. (Cited on page 5) [Nau et al., 2003] Nau, D. S., Au, T.-C., Ilghami, O., Kuter, U., Murdock, J. W., Wu, D., and Yaman, F. (2003). SHOP2: An HTN planning system. J. Artif. Intell. Res.(JAIR), 20:379–404. (Cited on page 17, 35 und 59) [Nef et al., 2007] Nef, T., Mihelj, M., Kiefer, G., Perndl, C., Muller, R., and Riener, R. (2007). Armin-exoskeleton for arm therapy in stroke patients. In Rehabilitation Robotics, 2007. ICORR 2007. IEEE 10th International Conference on, pages 68–74. IEEE. (Cited on page 12) [Peleg, 2013] Peleg, M. (2013). Computer-interpretable clinical guidelines: A methodological review. Journal of Biomedical Informatics, 46(4):744–763. (Cited on page 20) [Perry et al., 2007] Perry, J. C., Rosen, J., and Burns, S. (2007). Upper-limb powered exoskeleton design. Mechatronics, IEEE/ASME Transactions on, 12(4):408–417. (Cited on page 5) [Pulido et al., 2014] Pulido, J. C., González, J. C., González-Ferrer, A., Garcı́a, J., Fernández, F., Bandera, A., Bustos, P., and Suárez, C. (2014). Goaldirected generation of exercise sets for upper-limb rehabilitation. In Proceedings of Knowledge Engineering for Planning and Scheduling workshop (KEPS), ICAPS conference, pages 38–45. (Cited on page 29 und 77) [Puls et al., 2012] Puls, S., Graf, J., and Wörn, H. (2012). Cognitive robotics in industrial environments. Human Machine Interaction–Getting Closer, pages 213–234. (Cited on page 23) 86 Bibliografı́a [Reid, 2002] Reid, D. T. (2002). Benefits of a virtual play rehabilitation environment for children with cerebral palsy on perceptions of self-efficacy: a pilot study. Developmental Neurorehabilitation, 5(3):141–148. (Cited on page 4) [Reiser et al., 2009] Reiser, U., Connette, C., Fischer, J., Kubacki, J., Bubeck, A., Weisshardt, F., Jacobs, T., Parlitz, C., Hagele, M., and Verl, A. (2009). Care-o-bot x00ae; 3 - creating a product vision for service robot applications by integrating design and technology. In Intelligent Robots and Systems, 2009. IROS 2009. IEEE/RSJ International Conference on, pages 1992–1998. (Cited on page 12) [Richter et al., 2011] Richter, S., Westphal, M., and Helmert, M. (2011). Lama 2008 and 2011. The 2011 International Planning Competition, page 50. (Cited on page 15) [Ros et al., 2011] Ros, R., Nalin, M., Wood, R., Baxter, P., Looije, R., Demiris, Y., Belpaeme, T., Giusti, A., and Pozzi, C. (2011). Child-robot interaction in the wild: advice to the aspiring experimenter. In Bourlard, H., Huang, T. S., Vidal, E., Gatica-Perez, D., Morency, L.-P., and Sebe, N., editors, ICMI, pages 335–342. ACM. (Cited on page 5) [Schimmelpfeng et al., 2012] Schimmelpfeng, K., Helber, S., and Kasper, S. (2012). Decision support for rehabilitation hospital scheduling. OR spectrum, 34(2):461–489. (Cited on page 21) [Stanton et al., 2008] Stanton, C. M., Kahn, P. H., Severson, R. L., Ruckert, J. H., and Gill, B. T. (2008). Robotic animals might aid in the social development of children with autism. In Human-Robot Interaction (HRI), 2008 3rd ACM/IEEE International Conference on, pages 271–278. IEEE. (Cited on page 7) [Suárez Mejı́as et al., 2013] Suárez Mejı́as, C., Echevarrı́a, C., Nuñez, P., Manso, L., Bustos, P., Leal, S., and Parra, C. (2013). Ursus: A robotic assistant for training of children with motor impairments. In Pons, J. L., Torricelli, D., and Bibliografı́a 87 Pajaro, M., editors, Converging Clinical and Engineering Research on Neurorehabilitation, volume 1 of Biosystems Biorobotics, pages 249–253. Springer Berlin Heidelberg. (Cited on page 2, 6 und 12) [Tapus et al., 2007] Tapus, A., Maja, M., Scassellatti, B., et al. (2007). The grand challenges in socially assistive robotics. IEEE Robotics and Automation Magazine, 14(1). (Cited on page 1) [Turner-Stokes, 2009] Turner-Stokes, L. (2009). Goal attainment scaling (GAS) in rehabilitation: a practical guide. Clinical rehabilitation, 23(4):362–70. (Cited on page 21 und 30) [Wada et al., 2005] Wada, K., Shibata, T., Saito, T., Sakamoto, K., and Tanie, K. (2005). Psychological and social effects of one year robot assisted activity on elderly people at a health service facility for the aged. In Robotics and Automation, 2005. ICRA 2005. Proceedings of the 2005 IEEE International Conference on, pages 2785–2790. (Cited on page 13) [Winstein et al., 2003] Winstein, C. J., Miller, J. P., Blanton, S., Taub, E., Uswatte, G., Morris, D., Nichols, D., and Wolf, S. (2003). Methods for a multisite randomized trial to investigate the effect of constraint-induced movement therapy in improving upper extremity function among adults recovering from a cerebrovascular stroke. Neurorehabilitation and Neural Repair, 17(3):137–152. (Cited on page 7) Apéndice A A.1. Árbol relacional generado por TILDE Árbol generado por TILDE con 5 posturas y 4 gestos angle_flexion(-A) ? +--yes: distance_middle(A, -B) ? | +--yes: middle_plane(B) ? | | +--yes: front_plane(A) ? | | | +--yes: depth_same(A, -C) ? | | | | +--yes: [cross_arms] 49.0 [[s_up:0.0, s_dw:0.0, right:0.0, left:0.0, sqt:0.0, wvg:2.0, pntg:0.0, c_arms:47.0, bored:0.0]] | | | | | | | | +--no: depth_same(B, -D) ? +--yes: [wvg] 5.0 [[s_up:0.0, s_dw:0.0, right:0.0, left:0.0, sqt:0.0, wvg:4.0, pntg:0.0, c_arms:1.0, bored:0.0]] | | | | +--no: [c_arms] 5.0 [[s_up:0.0, s_dw:0.0, right:1.0, left:0.0, sqt:0.0, wvg:0.0, pntg:2.0, c_arms:2.0, bored:0.0]] | | | | | | +--no: distance_far(A, -E) ? +--yes: [wvg] 31.0 [[s_up:0.0, s_dw:0.0, right:1.0, left:1.0, sqt:0.0, wvg:25.0, pntg:4.0, c_arms:0.0, bored:0.0]] | | | +--no: [pntg] 5.0 [[s_up:0.0, s_dw:0.0, right:1.0, left:0.0, | | | | +--no: fronplane(A) ? +--yes: [bored] 18.0 [[s_up:0.0, s_dw:0.0, right:1.0, left:0.0, sqt:0.0, wvg:0.0, pntg:3.0, c_arms:0.0, bored:1.0]] sqt:0.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:17.0]] | | +--no: depth_same(-F, B) ? 88 A.1. ÁRBOL RELACIONAL GENERADO POR TILDE | | +--yes: distance_very_near(F, -G) ? | | | 89 +--yes: [s_dw] 25.0 [[s_up:0.0, s_dw:22.0, right:0.0, left:0.0, sqt:0.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:3.0]] | | | | | | +--no: distance_near(A, F) ? +--yes: [bored] 12.0 [[s_up:0.0, s_dw:2.0, right:0.0, left:0.0, sqt:0.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:10.0]] | | | | | | +--no: depth_same(-H, A) ? +--yes: [s_dw] 6.0 [[s_up:0.0, s_dw:5.0, right:0.0, left:0.0, sqt:0.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:1.0]] | | | +--no: [bored] 5.0 [[s_up:0.0, s_dw:2.0, right:0.0, left:0.0, sqt:0.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:3.0]] | | +--no: [bored] 6.0 [[s_up:0.0, s_dw:0.0, right:0.0, left:0.0, sqt:0.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:6.0]] | +--no: depth_same(-I, A) ? | +--yes: distance_middle(-J, I) ? | | +--yes: [bored] 7.0 [[s_up:0.0, s_dw:2.0, right:0.0, left:0.0, sqt:2.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:3.0]] | | +--no: [sqt] 28.0 [[s_up:0.0, s_dw:1.0, right:0.0, left:0.0, sqt:27.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:0.0]] | +--no: [bored] 5.0 [[s_up:0.0, s_dw:0.0, right:0.0, left:0.0, sqt:2.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:3.0]] +--no: depth_behind(-K, -L) ? +--yes: distance_very_far(-M, L) ? | +--yes: depth_same(-N, -O) ? | | +--yes: [pntg] 7.0 [[s_up:0.0, s_dw:0.0, right:0.0, left:3.0, sqt:0.0, wvg:0.0, pntg:4.0, c_arms:0.0, bored:0.0]] | | +--no: | +--no: [left] 27.0 [[s_up:0.0, s_dw:0.0, right:0.0, left:27.0, sqt:0.0, wvg:0.0, pntg:0.0, c_arms:0.0, bored:0.0]] [pntg] 11.0 [[s_up:1.0, s_dw:0.0, right:0.0, left:0.0, sqt:0.0, wvg:1.0, pntg:9.0, c_arms:0.0, bored:0.0]] +--no: back_plane(-P) ? +--yes: [right] 30.0 [[s_up:0.0, s_dw:0.0, right:29.0, left:0.0, sqt:0.0, wvg:1.0, pntg:0.0, c_arms:0.0, bored:0.0]] +--no: fronplane(-Q) ? +--yes: distance_far(Q, -R) ? | +--yes: [pntg] 29.0 [[s_up:0.0, s_dw:0.0, right:1.0, left:0.0, sqt:0.0, wvg:4.0, pntg:24.0, c_arms:0.0, bored:0.0]] 90 APÉNDICE A. | +--no: [s_up] 34.0 [[s_up:30.0, s_dw:2.0, right:1.0, left:0.0, sqt:0.0, wvg:1.0, pntg:0.0, c_arms:0.0, bored:0.0]] +--no: [wvg] 9.0 [[s_up:2.0, s_dw:0.0, right:0.0, left:0.0, sqt:0.0, wvg:7.0, pntg:0.0, c_arms:0.0, bored:0.0]]