Planificación Jerárquica y Detección de Poses para el Desarrollo de

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
jcpulido@inf.uc3m.es
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]]