N° tesis: 1
PROYECTO FIN DE CARRERA
Presentado a
LA UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
Para obtener el título de
INGENIERO ELECTRÓNICO
por
Cristian Hernán Muñoz García
CONTROL DE ESTABILIDAD DE UN BÍPEDO APLICADO A LA
PLATAFORMA NAO
Sustentado el 28 de Julio de 2015 frente al jurado: Composición del jurado
- Asesor: José Fernando Jiménez Vargas, Profesor Asociado, Universidad de Los Andes
Mario Ricardo Arbulú Saavedra, Profesor Asociado, Universidad de la Sabana
- Jurados : Alain Gauthier Sellier, Profesor Emérito, Universidad de Los Andes
- Invitados : Ana María Aranguren Aranguren Martha Cecilia García Mahecha Carlos Humberto Muñoz Bohórquez
Contenido
1. INTRODUCCIÓN ... 3
2. OBJETIVOS ... 4
2.1. Objetivo General... 4
2.2. Objetivos Específicos ... 4
2.3. Alcance y productos finales ... 5
3. DESCRIPCIÓN DE LA PROBLEMÁTICA Y JUSTIFICACIÓN DEL TRABAJO ... 5
4. MARCO TEÓRICO, CONCEPTUAL E HISTÓRICO ... 5
4.1. Marco Teórico ... 5
4.2. Marco Conceptual ... 6
4.3. Marco Histórico ... 6
5. DEFINICIÓN Y ESPECIFICACIÓN DEL TRABAJO ... 7
5.1. Definición ... 7
5.2. Especificaciones ... 7
6. METODOLOGÍA DEL TRABAJO ... 8
6.1. Plan de trabajo ... 8
6.2. Búsqueda de información ... 10
6.3. Alternativas de desarrollo ... 11
7. TRABAJO REALIZADO ... 13
7.1. Descripción del Resultado Final ... 20
7.2. Trabajo computacional ... 20
8. VALIDACIÓN DEL TRABAJO ... 23
8.1. Metodología de prueba ... 23
8.2. Validación de los resultados del trabajo ... 24
8.3. Evaluación del plan de trabajo ... 29
9. DISCUSIÓN ... 29
10. CONCLUSIONES ... 30
11. AGRADECIMIENTOS ... 333
12. REFERENCIAS ... 34
13. APENDICES ... 36
1.
INTRODUCCIÓN
Dentro del desarrollo y avance en robótica humanoide se encuentra el estudio de la estabilidad de bípedos. Esto se debe a que controlar la estabilidad del bípedo deriva en una marcha exitosa junto con un comportamiento más parecido al de un humano y evita riesgos de daño por caídas.
La plataforma robótica NAO desarrollada por Aldebaran Robotics [1] sobre la cual se realizará este trabajo será modelada como dos péndulos invertidos simples de dos dimensiones cada uno, como paso previo a un péndulo invertido de 3 dimensiones el cual se implementa en el análisis de marcha. Análisis que no se realizará en este trabajo.
El robot NAO, cuya imagen se puede ver en la Figura 1 es un humanoide de 58 cm de altura, pesa 5.2 kg y tiene 25 grados de libertad (algunas versiones tienen 21 grados de libertad) distribuidos en piernas, brazos, pelvis, cabeza y manos. Para este trabajo será de interés los 2 grados de libertar existentes en los tobillos.
El robot NAO cuenta con una CPU Intel ATOM de 1,6 GHz ubicada en la cabeza y que ejecuta un kernel Linux y da soporte al middleware NAOqi, propiedad de Aldebaran Robotics.
Figura 1. Robot Humanoide NAO [2]
NAO cuenta con sistemas inerciales los cuales hacen que cuando caiga detenga su marcha y sus brazos actúen a modo de cubrir pecho y cabeza en la caída. Sin embargo esta no es la acción que comúnmente haría un humano al sentir una perturbación en su marcha; el humano intentaría buscar un punto de apoyo que lo haga más estable. Por
esta razón se busca obtener una respuesta más parecida a la realizada por el ser humano.
Para ello es necesario analizar la acción más básica pero primordial a la hora de estar de pie: mantenerse en equilibrio apoyado únicamente en la superficie de un pie.
2.
OBJETIVOS
2.1. Objetivo General
El objetivo principal de este proyecto de grado es realizar el algoritmo de control de estabilidad del robot NAO mediante la aplicación de técnicas correspondientes al escenario en el cual el robot NAO, apoyado únicamente en un solo pie, patee un balón.
2.2. Objetivos Específicos
2.2.1 Descripción del mundo y posición del centro de masa:
Al encontrarse la zona de apoyo reducida a la base de un pie (equilibrio en una sola pierna) el bípedo simula un péndulo invertido en 3 dimensiones. Para este estudio el robot se modelará como 2 péndulos invertidos simples de 2 dimensiones cada uno.
El primer péndulo invertido (barra rígida de masa despreciable con el CoM del robot de forma puntual al final de la barra) para la vista lateral del bípedo, es decir, ejes X-Z. El segundo péndulo corresponde a la vista frontal (ejes Y-Z) del NAO.
2.2.2 Investigar y aplicar técnicas de estabilidad en un bípedo:
Para lograr la estabilidad de un bípedo es necesario conocer y aplicar uno de los siguientes criterios: ZMP (Zero Moment Point) [3], CWC (Contact Wrench Cone) [4], FRI (Foot Rotation Indicator) [5].
2.2.3 Adquirir y analizar la información dada por los sensores inerciales del bípedo:
El robot NAO cuenta con sensores inerciales los cuales brindan información sobre velocidades angulares, aceleraciones y orientaciones. Esta información será utilizada para identificar el modelo del péndulo invertido que represente al robot en el escenario descrito.
La acción de control sobre cada uno de los péndulos invertidos se realizará mediante un controlador PID [6]. Para utilizar este controlador se necesita que la planta (Péndulo Invertido) sea lineal [7].
2.3. Alcance y productos finales
El alcance de este proyecto es la realización e implementación del código del controlador sobre el robot, el cual se encarga de corregir la inestabilidad del robot al estar apoyado en la superficie de un pie. Este código será realizado en el lenguaje Python [8] de programación y probado en el simulador Webots [9].
3.
DESCRIPCIÓN DE LA PROBLEMÁTICA Y JUSTIFICACIÓN DEL TRABAJO
Cada año se lleva a cabo la competencia Robocup [10], la cual busca promover la robótica y la investigación en inteligencia artificial. Esta competencia tiene varios eventos: rescate, en el hogar, en el trabajo, fútbol. Es en esta última categoría en la cual se usan a los robots NAO en la liga de plataforma estándar.
En los partidos de esta liga es usual ver como los robots tras patear el balón caen debido a una falta de equilibrio y al efecto que sobre el robot genera el impacto con el balón estando en un solo pie de apoyo. El objetivo de este proyecto es corregir dicho inconveniente pues cada caída pone en riesgo la integridad del robot. Para esto se van a diseñar controladores PID los cuales a partir del error entre la orientación actual de la unidad inercial del robot y la orientación de referencia determinen la velocidad que deben tomar los motores del tobillo de la pierna de apoyo para corregir la inestabilidad debida a la patada.
4.
MARCO TEÓRICO, CONCEPTUAL E HISTÓRICO
4.1. Marco Teórico
Para desarrollar el presente trabajo se modeló teóricamente al robot NAO, apoyado en un solo pie, como dos péndulos invertidos simples cuya masa se es igual a la masa del robot y se representa como una esfera al final de una barra rígida de masa despreciable.
Experimentalmente se usó el simulador Webots para simular el comportamiento del robot pateando el balón, de esta simulación se obtuvo la información de ángulo y velocidad angular en la unidad inercial. Estos datos permitieron la identificación del modelo representativo del caso de estudio mediante técnicas de minimización de error y máxima similitud entre los mismos. Estas técnicas de aplicaron con la herramienta System Identification Toolbox [11] de MATLAB [12].
Una vez obtenidos los modelos teóricos y experimentales se hizo un diseño de controladores PID usando El Lugar Geométrico de las Raíces.
4.2. Marco Conceptual
Para este proyecto se necesitó conocer sobre controladores PID, los cuales tienen un efecto proporcional, integrativo y derivativo sobre el error del sistema en lazo cerrado.
Este controlador se sintonizó con base en lugar geométrico de las raíces para ubicar los polos y ceros del sistema de modo que cumplan con las restricciones de tiempo de establecimiento y de sobre pico porcentual, buscando siempre que el sistema sea estable. Esto se logró con la herramienta SISO Design Tool [13] de MATLAB.
4.3. Marco Histórico
Para el desarrollo de este proyecto se consideraron tanto antecedentes internos como antecedentes externos a la Universidad de Los Andes, institución ante la cual se presenta el mismo.
a) Antecedentes internos
Actualmente se han realizado trabajos de investigación y proyectos de grados sobre robots tipo delta en cuanto a definición de trayectorias para definir los límites dinámicos del robot [14] y programación de los mismos [15], a pesar de que son robot tipo delta y no bípedos tienen una trayectoria definida, y esto es uno de los métodos de cálculo del set point del bípedo: generación de trayectorias; otro de los métodos de cálculo de set point es el modelaje de péndulo invertido, sobre el cual se han hecho estudios de control [16] incluyendo el modelo de doble péndulo invertido, similar al modelo de un bípedo donde existen dos péndulos, uno seguido del otro.
También se han realizado trabajos sobre toma de decisiones óptimas que permitan a un robot móvil llegar a un destino determinado en un ambiente desconocido evitando choques con obstáculos lo cual es útil en cuanto a detección del ambiente. En cuanto a robótica humanoide se han hecho proyectos sobre desarrollo de prótesis para piernas amputadas y sensores en la rodilla para corregir el movimiento de la misma [17]
b) Antecedentes Externos
Se han hecho trabajos en robótica humanoide en general así como en la plataforma NAO específicamente. En la actualidad existen plataformas famosas como la ASIMO de Honda [18]. También existen los robots de la serie HRP y en el robot RH-1 trabajos sobre control de caminata [19]. Este último se modelo inicialmente como un péndulo invertido estático, modelo aplicable también para este proyecto. También se han realizado trabajos generales sobre la arquitectura de control de un robot humanoide [3], [20].
Específicamente en la plataforma NAO se han realizado trabajos sobre control robusto con feedback aplicado a la marcha del bípedo [21], así mismo existen trabajos generales sobre la locomoción del NAO [22] y trabajos más avanzados sobre optimización y uso de técnicas de inteligencia artificial [23].
Por su parte, en la Universidad de la Sabana y bajo la guía del Doctor en Ingeniería Eléctrica, Electrónica e Informática Mario Arbulú (co-asesor de este proyecto) se han realizado estudios en Control Geométrico de Planos, detección y observación de objetos y movimiento. Adicionalmente esta institución educativa cuenta con un grupo de estudiantes y profesores (incluyendo al Doctor Arbulú) los cuales trabajan áreas de visión, coordinación entre varios robots NAO, posicionamiento, y control de cuya parte me encargo yo y hace parte este proyecto, para una futura participación en la Robocup.
5.
DEFINICION Y ESPECIFICACION DEL TRABAJO
5.1. Definición
El desarrollo del presente proyecto está enfocado en la realización de un controlador y su posterior programación en Python, este controlador busca corregir la perturbación que sobre el robot tiene la acción de patear un balón de fútbol como ocurre en la Robocup, este será el caso de estudio.
Debido a los altos costos del robot (Ver Apéndice 1) se trabajará con el simulador Webots previamente a la implementación del algoritmo del controlador en el robot físico, de esta forma evitando costos por posibles daños en el robot NAO.
5.2. Especificaciones
Las principales restricciones de este proyecto son el tiempo y el acceso al robot y a los simuladores. Al iniciar este proyecto se tuvo acceso a los 4 robots NAO de la Universidad de la Sabana, sin embargo fue necesario enviar los robots a mantenimiento a la ciudad de Boston en los Estados Unidos de América, lugar donde el fabricante tiene oficinas. En cuanto a los simuladores existen licencias gratuitas disponibles por ciertos periodos de tiempo, Choreographe (de poco uso en este proyecto) permite su uso gratuito durante 90 días, y Webots (simulador principal del proyecto) brinda una licencia gratuita durante 30 días. Como se puede notar, es de suma importancia una buena distribución del tiempo.
El uso de un simulador previo a la experimentación con el robot físico hace que se eviten riesgos de caídas y daños lo cual es primordial al ser un robot costoso, más de $8.000 USD. Sin embargo, el simulador no logra una completa semejanza con la realidad debido a factores como la fricción del suelo, el estado y rendimiento de la batería del robot, y la inercia del robot.
Una restricción clave es el tiempo de muestreo con el cual opere el controlador ya que este debe ser discretizado con un periodo no menor a 0.05s para no afectar el funcionamiento de la computadora interna del robot NAO.
El robot NAO cuenta con sensores inerciales que permiten obtener las aceleraciones, velocidades angulares y las orientaciones del mismo. Estos datos serán usados para el desarrollo de este proyecto. El robot NAO, en su programación, cuenta con un método que mueve todo el cuerpo si es necesario para lograr el equilibrio, es decir, si el robot va a mover una pierna y eso afecta el equilibrio el resto de articulaciones se moverán de modo que el equilibrio se mantenga. Al ser este método algo natural del robot es necesario aislar el efecto del impacto de la patada al balón sobre el robot.
Ya que para este proyecto el robot se encuentra apoyado únicamente en un pie es necesario obtener la posición del centro de masa y la longitud de cada uno de los péndulos invertidos simples.
6.
METODOLOGÍA DEL TRABAJO
Lo primero que se debe hacer, antes de probar con los simuladores y con el robot físico, es un análisis teórico. Este análisis busca determinar a partir de cada parte del robot, cada masa y la posición de las mismas la posición del centro de masa del robot NAO. Dentro del análisis teórico es necesario obtener el modelo del péndulo invertido y posteriormente diseñar el controlador a implementar.
Paralelamente fue necesario aprender a programar en Python y aprender el funcionamiento del robot. Con propósito de comparación es necesario el uso de simuladores. En estos simuladores se busca recrear la acción de patear el balón por parte del robot, con esto y tomando datos se realizará la identificación de un modelo más real y aproximado que el modelo teórico. Una vez obtenido este modelo se realizará el controlador que posteriormente será programado en el robot usando el lenguaje Python.
6.1. Plan de trabajo
Antes de poder tener acceso al robot y a los simuladores se realizaron las siguientes actividades:
• Obtención de la información técnica del robot para un análisis de masas y posiciones.
• Dimensionamiento de péndulos los invertidos.
• Análisis de cuerpo libre junto con la obtención de la función de transferencia teórica para los péndulos invertidos.
• Diseño y simulación del controlador para la función de transferencia teórica. • Análisis de resultados.
Estas actividades para el análisis teórico se realizarán en el orden listado, igualmente el siguiente diagrama muestra el procedimiento a seguir para el análisis y desarrollo
teórico del proyecto. El análisis de cuerpo libre fue realizado en compañía del co-asesor de este proyecto.
Diagrama 1. Procedimiento, Análisis y Desarrollo Teórico.
En cuanto al análisis experimental las siguientes actividades fueron realizadas con base en simulaciones y programación:
• Acercamiento y aprendizaje simuladores Choreographe y Webots, y lenguaje de programación Python.
• Obtención y estudio del código de programación correspondiente al robot pateando.
• Aislamiento de la acción de patada y obtención de los datos de la unidad inercial. • Identificación del modelo de la perturbación debida al impacto del robot con el
balón.
• Diseño, simulación y programación del controlador para el modelo identificado. • Análisis de resultados.
Estas actividades se ven en más claridad y en secuencia en el Diagrama 2. Estas actividades se realizaron bajo la supervisión del Doctor Arbulú, con reuniones y revisiones de avance diarias. Para el tema de identificación se realizaron también reuniones y consultas con el Doctor Fernando Jiménez, asesor de este proyecto.
Diagrama 2. Procedimiento, Análisis y Desarrollo Experimental. Obtención
Información Técnica
Dimensionam iento de Péndulos Invertidos
Análsisi de cuerpo libre y
obtención Función de Transferencia
Simulación y Diseño Controlador
Análisis de Resultados
Acercamiento y aprendizaje simuladores y
lenguaje Python
Obtención código de patada
Aislamiento acción de
patada y obención de
datos
Identificació n modelo de perturbación
Diseño, simulación y programación
controlador
Análisis de resultados
Finalmente se realizará una comparación entre los dos resultados obtenidos previamente para determinar cuál es el controlador más adecuado y más óptimo para el caso de estudio de este proyecto. Esto es:
Diagrama 3. Fase final del desarrollo del proyecto.
En el desarrollo de este proyecto se realizó un informe de avance presentado a la Universidad de los Andes, aprobado y revisado por los Doctores Arbulú y Jiménez. Adicionalmente y por requerimiento de la Universidad de los Andes se hizo una exposición del proyecto, en la cual se incluyeron la descripción del problema junto con su justificación, un diseño previo de un controlador y un análisis de resultados.
6.2. Búsqueda de información
Para el desarrollo de este proyecto la información de consulta se enfocó en el funcionamiento y la programación del robot NAO, a esta documentación se puede acceder mediante la página de la comunidad de Aldebaran Robotics [24].
De esta documentación se obtuvo información técnica sobre la masa de cada parte del robot y la posición de la misma con respeto a un punto “o,R” relativo al punto llamado Torso [25], [26]. Esta información fue útil para obtener físicamente la posición del Centro de Masa (CoM) del robot mediante una relación entre posición de cada masa y la masa total del robot.
También se encontró, en la sección de programación [27] un ejemplo en Python correspondiente a la acción de la patada. Dicho ejemplo se encuentra en el Apéndice 2
Teoría
Experimentación
Diseño
Final
de este documento. Sobre este código ha sido necesario hacer modificaciones a fin de aislar la patada del robot, hacer toma de datos y finalmente programar el controlador.
Ya que este ejemplo es en Python y sobre este lenguaje de programación no recibí preparación académica previa fue de suma importancia aprender con la ayuda del Doctor Arbulú y de estudiantes de Ingeniería Informática de la Universidad de la Sabana, quienes tienen experiencia en el uso del robot NAO y en programación de Python.
Para el desarrollo de los controladores fue muy importante saber sobre Sistemas de Control, tipos de controladores y métodos de sintonización; conocimiento adquirido en el curso “Análisis de Sistemas de Control” de la Universidad de los Andes, conocimiento complementado por los asesor y co-asesor de este proyecto y por estudiantes de maestría y de pregrado de Ingeniería Electrónica de dicha universidad.
6.3. Alternativas de desarrollo
Al momento de realizar este trabajo se consideraron dos alternativas para la obtención del modelo a controlar:
A. Alternativa Teórica
Esta alternativa se basa en considerar el péndulo invertido teórico de longitud fija, masa puntual al final de una barra de masa despreciable, tal como se muestra en la Figura 2.
Figura 2. Péndulo Invertido Simple [19]
Este modelo es válido debido a que en el caso de estudio el robot se encuentra apoyado únicamente en un pie, lo cual lo hace comportarse como un péndulo invertido. La ventaja que este modelo tiene, como se comprobó con la ayuda del Dr. Arbulú realizando un análisis de cuerpo libre es que no hay una dependencia de la masa. Esto se mostrará más adelante en el numeral 7 de este proyecto.
Una desventaja que presenta este modelo es omitir el efecto que las masas de las demás partes del cuerpo puedan tener en la estabilidad del mismo. A nivel de programación existe un método para corregir esto.
Otra desventaja y muy importante es considerar el robot como un cuerpo completamente rígido sin articulaciones. Se busca controlar el ángulo del péndulo (dado por la unidad inercial) pero el actuador que se mueve es el tobillo, también se generan ángulos en la rodilla y la cadera del robot.
Finalmente y para el caso de estudio es importante aclarar que teóricamente se modela todo el péndulo invertido, no se considera únicamente la perturbación ocasionada por el impacto con el balón al momento de patearlo. Esto sí se puede hacer experimentalmente.
B. Alternativa Experimental
Esta alternativa consiste en, mediante simulación, obtener la función de transferencia representativa del modelo mediante el uso de herramientas de técnicas de identificación con los datos correspondientes a la perturbación generada por el impacto del robot con el balón, es decir, se puede aislar el efecto del impacto de los dos cuerpos. Esto claramente es una ventaja frente al análisis teórico.
Otra ventaja es la capacidad de –mediante programación- reducir el efecto que las demás partes del robot puedan tener a la hora de patear. Esto hace que el robot se aproxime a un modelo más teórico de un péndulo invertido.
La mayor ventaja que esta alternativa puede brindar es un modelo más aproximado a la realidad del robot, sin embargo la forma de identificación del mismo en MATLAB es una desventaja por sus múltiples opciones de modelo deseado (un polo, 2, 3 polos, un cero, más de un cero, retraso)
Identification System Toolbox [11] de MATLAB es una herramienta que permite la identificación de un modelo de proceso mediante el uso de un vector de entrada y un vector de salida, ambos en el tiempo. Este sistema aunque es útil presenta una desventaja al dar múltiples opciones de diseño del modelo, para saber cuál es mejor se debería analizar cada uno de los posibles modelos y analizar los controladores correspondientes.
Una desventaja de obtener la función de transferencia a través de los datos obtenidos de una simulación es que el robot NAO virtual no se comporta exactamente igual que el robot físico pues el simulador no es capaz de simular en su totalidad el entorno al cual se encuentra expuesto el humanoide.
Adicionalmente los datos de cada simulación son diferentes, así que el modelo puede variar entre simulación y simulación, lo cual no ocurre con un modelo teórico.
Una vez obtenido el modelo (tanto teórico como experimental) y diseñados los controladores se presenta un problema con respecto al efecto que el controlador tiene sobre el modelo adquirido: la orientación del tobillo no es el mismo del torso, así que si se desea que el torso vaya en una dirección hasta alcanzar la orientación de referencia se debe considerar que el tobillo se moverá en un ángulo diferente al planeado lo cual pone en riesgo el robot. Esto fue algo evidenciado al momento de realizar las simulaciones en este proyecto. El tobillo no se debe mover a una orientación deseada, se debe mover la orientación determinada por el error.
Finalmente se optó por el modelo obtenido experimentalmente con la estructura de una función de transferencia de un polo ya que al igual que el modelo teórico es de orden 1. Esta elección se basó en que es un modelo correspondiente a la perturbación y no al funcionamiento normal del robot pues este es planeado y la perturbación no lo es.
Este modelo se implementará en el siguiente lazo de control:
Figura 3. Sistema de lazo cerrado en Simulink [28].
En este modelo de lazo cerrado el controlador toma un error en grados y entrega una señal en radianes por segundo [rad/s] al robot para corregir orientación del robot NAO.
7.
TRABAJO REALIZADO
Una vez obtenida la documentación relacionada a las masas del robot se procedió a obtener la posición del CoM de todo el humanoide. El robot se compone de las siguientes partes:
numP1(s)
denP1(s) Transfer Fcn Step
Salida
-K-Kp
-K-Ki 1 s Integrator
PARTE CANTIDAD MASA (kg)
Cabeza 1 0.60533
Cuello 1 0.06442
Torso 1 1.0496
Hombros 2 0.07504
Bíceps 2 0.15777
Codos 2 0.06483
Antebrazos 2 0.07761
Manos 2 0.18533
Pelvis 2 0.06981
Caderas 2 0.13053
Muslos 2 0.38968
Tibias 2 0.29142
Tobillos 2 0.13416
Pies 2 0.16184
Tabla 1. Masas del robot NAO. Cantidad = 2 indica que una parte es derecha y otra izquierda: Mano Izquierda/ Mano derecha.
Con estas masa y la información sobre la posición de cada CoM con respecto a un punto llamado (o,R) relativo al punto llamado Torso se usó la siguiente ecuación para determinar la posición del CoM total del robot NAO en cada uno de los ejes. Hay que aclarar que en esta ecuación la distancia en el eje Z es con respecto al suelo y no al Torso. En los ejes X y Y las distancias son con respecto al Torso, siendo este (0,0) en su punto (o,R).
𝑋𝐶𝑜𝑀 𝑡𝑜𝑡𝑎𝑙 =∑ 𝑚𝑖 ∗ 𝑋𝐶𝑜𝑀 𝑖
𝑚𝑡𝑜𝑡𝑎𝑙 (1)
Siendo la masa total del humanoide 5.1954 kg, la ecuación (1) hace una relación entre la distancia del centro de masa de cada parte con respecto a un punto ubicado en el suelo (0, 0, 0) y la masa correspondiente. Esta ecuación es válida para las 3 coordenadas del sistema. A continuación se presenta la tabla indicando la posición en cada coordenada de los centros de masa individuales.
PARTE X CoM (m) Y CoM (m) Z CoM (m)
Cabeza -0.0011 0 0.5122
Cuello -1 e-05 0 0.4322
Torso -0.0041 0 0.3765
Hombros 1.4 e-04 ±0.0714 0.4347
Bíceps 0.0033 ±0.1036 0.4085
Codos -1.4 e-04 ±0.1130 0.3555
Antebrazos 7.6 e-04 ±0.1158 0.3025
Manos 0.0031 ±0.1121 0.2378
Pelvis -0.0078 ±0.0389 0.2747
Caderas -0.0155 ±0.0503 0.2429
Muslos 0.0014 ±0.0522 0.1944
Tibias 0.00453 ±0.0523 0.0987
Tobillos 4.5 e-04 ±0.0503 0.0520
Pies 0.0254 ±0.0533 0.0128
Tabla 2. Posiciones del centro de masa de cada parte del robot.
Para las partes que tienen cantidad 2 (ver Tabla 1) se presentan en positivo los datos de la coordenada Y positiva (lado izquierdo del humanoide) y negativo hacia la derecha; por cuestiones de simetría estas partes no afectarán la ecuación pues se cancelarán entre sí en la coordenada Y.
Usando los valores de las tablas 1 y 2 en la Ecuación (1) se obtuvo las posiciones del centro de masa del robot NAO para los 3 ejes de coordenadas:
𝐶𝑜𝑀𝑋 𝑡𝑜𝑡𝑎𝑙 = 8.1235 ∗ 10−4 𝑚
𝐶𝑜𝑀𝑌 𝑡𝑜𝑡𝑎𝑙 = 0 𝑚
𝐶𝑜𝑀𝑍 𝑡𝑜𝑡𝑎𝑙 = 0.2767 𝑚
Para la longitud de los péndulos invertidos se usa como punto inicial el CoM de uno de los pies y como punto final los CoM totales. Obtenemos así:
𝑙𝑓𝑟𝑜𝑛𝑡𝑎𝑙 = 0.2817𝑚
El análisis de cuerpo libre realizado se presenta a continuación:
Figura 4. Diagrama de cuerpo libre.
Sobre la masa puntual sólo tienen efecto la gravedad y la aceleración. En dirección de la barra del péndulo las fuerzas están en equilibrio, el péndulo no se alarga ni se contrae. Finalmente se tiene la siguiente ecuación:
∑ 𝐹 = 𝑚𝑎 = 𝑚𝑙𝛼 = 𝑚𝑙𝜔 𝑠 = 𝑚𝑔 𝑠𝑖𝑛𝜃 (2)
Linealizando y despejando se tiene
𝐻𝑡𝑒𝑜(𝑠) = 𝜃
𝜔 =
𝑙
𝑔 𝑠 (3)
El modelo teórico del robot NAO tratado como péndulo invertido depende únicamente de la longitud del mismo y de la gravedad.
Para el análisis experimental, sobre el cual se optó por continuar en este proyecto debido a una mayor aproximación con la realidad, se modificó el ejemplo obtenido del robot NAO pateando. Estas modificaciones serán explicadas a detalle en la sección 7.2 de este documento. Con estas modificaciones se buscó: modificar el comportamiento del robot, obtener información por parte de la unidad inercial del humanoide, identificar y aislar los datos correspondientes a la perturbación para obtener la función de transferencia a controlar. Una vez obtenida esta función se diseñó y programó el controlador en MATLAB y Python respectivamente.
Diagrama 4. Procedimiento experimental desarrollado.
Finalmente se hizo nuevamente una obtención de resultados y un análisis de los mismos con su comparación frente a los obtenidos antes de la implementación del controlador.
Los datos obtenidos se tomaron a lo largo de la patada, cada 0.05s para un total de 80 datos equivalentes a 4s, los cuales se encuentran en el Apéndice 3, analizando el recorrido de la patada se identificó que el impacto con el balón ocurre en el instante de tiempo 2.2s (dato 44), creando una perturbación de 0.45s (tiempo final de 2.65s, dato 53). A continuación se presenta la tabla con los datos de la perturbación para la orientación lateral con sus respectivos tiempos y velocidades.
Tiempo (s) Wy (rad/s) Theta Y(°)
2,2 -0,00096 -2,16789
2,25 -0,00863 -2,21636
2,3 -0,00909 -2,21636
2,35 -0,01068 -2,24595
2,4 -0,01068 -2,24595
2,45 -0,00387 -2,28708
2,5 -0,00387 -2,28708
Modificación código original
• Reducción movimiento a una patada • Creación método de obtención de datos • Sincronización patada y obtención datos
Función de transferencia
• Análisis de datos y aislamiento de perturbación • Identificación función de transferencia
Controlador
• Diseño controlador por lugar geométrico de las raices y simulación del mismo
• Programación y controlador
Resultados
• Obtención resultados y comparación con los resultados sin controlador
2,55 -0,00022 -2,29581
2,6 0,000202 -2,29565
2,65 -0,00252 -2,29999
Tabla 3. Velocidades angulares y orientación lateral en el tiempo para la unidad inercial del robot NAO.
Las siguientes figuras corresponden a los datos completos de los las orientaciones coronal y sagital para el movimiento de la patada, primero sin el balón (Apéndice 4) y luego con el balón (Apéndice 3).
Figura 5. Orientación Coronal del robot NAO sin patear el balón.
Figura 6. Orientación Sagital del robot NAO sin patear el balón.
-8,5 -8,25 -8, -7,75 -7,5 -7,25 -7,
0.05 0.3 0.55 0.8 1.05 1.3 1.55 1.8 2.05 2.3 2.55 2.8 3.05 3.3 3.55 3.8
Á
ng
ul
o
(°
)
Tiempo (s)
Theta X sin balón
-3,125 -2,5 -1,875 -1,25 -0,625 0,
0.05 0.3 0.55 0.8 1.05 1.3 1.55 1.8 2.05 2.3 2.55 2.8 3.05 3.3 3.55 3.8
Á
ng
ul
o
(°
)
Tiempo (s)
Theta Y sin balón
Las figuras 5 y 6 muestran el comportamiento normal del robot al momento de dar una patada en el aire con la pierna derecha.
Figura 7. Orientación Coronal del robot NAO pateando el balón.
Figura 8. Orientación Sagital del robot NAO pateando el balón.
Las figuras 7 y 8 muestran un comportamiento similar al de las figuras 5 y 6. Los datos varían con cada simulación realizada. Entre los instantes de tiempo 2.2s y 2.65s se puede ver una perturbación en la orientación sagital del bípedo, la cual se debe al efecto del impacto con el balón y corresponde a los datos de la Tabla 3. A continuación se muestra dicha perturbación gráficamente.
-8,4 -8,2 -8, -7,8 -7,6 -7,4 -7,2
0.05 0.3 0.55 0.8 1.05 1.3 1.55 1.8 2.05 2.3 2.55 2.8 3.05 3.3 3.55 3.8
Á
ng
ul
o
(°
)
Tiempo (s)
Theta X con balón
-3,125 -2,5 -1,875 -1,25 -0,625 0,
0.05 0.3 0.55 0.8 1.05 1.3 1.55 1.8 2.05 2.3 2.55 2.8 3.05 3.3 3.55 3.8
Á
ng
ul
o
(°
)
Tiempo (s)
Theta Y con balón
Figura 9. Perturbación en la orientación sagital del humanoide con respeto al tiempo.
Cómo se tomaron estos datos y cómo se usaron para determinar la función de transferencia del robot será explicado más adelante.
7.1. Descripción del Resultado Final
Para el desarrollo de este proyecto se planearon las siguientes tareas:
• Modelo teórico.
• Aprendizaje lenguaje de programación Python. • Simulación y modificación código-ejemplo de patada. • Implementación código toma de datos.
• Identificación modelo del robot NAO.
• Diseño controladores y posterior programación. • Pruebas finales.
A lo largo del desarrollo del proyecto se realizaron simulaciones para evaluar el comportamiento del robot según las modificaciones del código. Esto permitió ver la importancia de la relación entre la orientación del torso y la orientación del tobillo a mover.
7.2. Trabajo computacional
Para este proyecto lo primero que se hizo a nivel computacional fue instalar Pydev [29], un plugin de Python para Eclipse [30] esto permite programar en Python desde el programa Eclipse. Una vez instalado este plugin se procedió a ejecutar el programa de ejemplo de la patada [27] encontrado en la página de Aldebaran Robotics. Se usa Python pues es el lenguaje de programación sobre el cual se basan los códigos y programaciones del robot NAO, el lenguaje C++ es también válido pero a un nivel más profundo de programación.
-2,325 -2,25 -2,175 -2,1
2.2 2.25 2.3 2.35 2.4 2.45 2.5 2.55 2.6 2.65
Á
ng
ul
o
(°
)
Tiempo (s)
Este código (ver Apéndice 2) hace que el robot se ponga de pie, se incline hacia la izquierda y patee con la pierna derecha, luego se endereza el robot y repite el mismo procedimiento pero con inclinación hacia el lado derecho y pateando con la pierna izquierda. Esta patada está programada mediante un “Path” o camino descrito al inicio del código (método “computePath”). El método main del código utiliza este Path para realizar el movimiento del pie.
Ya que el robot NAO no puede patear dos veces el balón sin moverse de su punto inicial se limitará el código a una sola patada, la dada por el pie derecho. Esto se puede lograr ya sea borrando la codificación correspondiente o documentándola (volviéndola comentarios), esta segunda alternativa se logra escribiendo tres comillas al inicio y tres comillas al final del código a documentar. En este caso la segunda patada se ve así:
# Com go to LLeg
'''supportLeg = "RLeg" duration = 2.0
motionProxy.wbGoToBalance(supportLeg, duration)
# RLeg is free stateName = "Free" supportLeg = "LLeg"
motionProxy.wbFootState(stateName, supportLeg)
effector = "LLeg"
path = computePath(motionProxy, effector, frame)
motionProxy.transformInterpolations(effector, frame, path, axisMask, times)'''
El código se encuentra limitado ahora a una única patada. El código utiliza un método llamado “Whole Body Balancer” [31] el cual se activa de la siguiente forma:
# Activate Whole Body Balancer
isEnabled = True
motionProxy.wbEnable(isEnabled)
Este código hace que el robot se mueva buscando equilibrio, es decir, si al mover una pierna existe la posibilidad de pérdida del equilibrio se moverán más partes del robot (brazos, piernas, rodillas, torso) para mantener el equilibrio de todo el robot. Este método se ve en funcionamiento al moverse el torso del robot cuando este da la patada.
Para un análisis del efecto de la perturbación fue necesario deshabilitar dicho método justo antes de dar la patada y volver a habilitarlo después de esta, es decir:
isEnabled = False
motionProxy.wbEnable(isEnabled)
motionProxy.post.transformInterpolations(effector, frame, path, axisMask, times)
isEnabled = True
motionProxy.wbEnable(isEnabled)
Como se puede ver, adicionalmente se modificó el método de transformación de interpolaciones el cual da la patada. Se adicionó “.post” para que este método se ejecute al tiempo que el nuevo método “datos”.
Este método datos (Apéndice 5) recibe la dirección IP y el puerto del robot. En este método se ejecuta un ciclo 80 veces, tomando así 80 datos de aceleraciones, velocidades y orientación en la unidad inercial. Estos datos son los mencionados previamente.
Con los datos de la Tabla 3 se procedió a realizar la identificación del modelo de la planta mediante técnicas de minimización de error y de máxima similitud. Para esto se utilizó la herramienta System Identificacion Toolbox de Matlab, se tomó como entrada la velocidad angular y como salida la orientación. La función obtenida es la siguiente:
𝐺(𝑠) = 2225
𝑠 + 4.485 (4)
A partir de la función de transferencia de la ecuación (4) se diseñó el controlador usando la teoría del lugar geométrico de las raíces. Esta sintonización se realizó en la herramienta SISOTOOL; se consideraron como criterios de diseño un sobre pico del 5% y un tiempo de establecimiento menor a 0.05s.
El controlador resultante es del tipo PI y su ecuación es:
𝐶(𝑠) =100.45
𝑠 + 1.0045 (5)
Siendo el modelo en lazo cerrado el de la Figura 3, se utiliza una entrada escalón de -0.15° a 0° en un tiempo de 0.35s correspondiente a la perturbación del sistema.
El controlador obtenido se implementó en la programación, en este caso en el ciclo de toma de datos. Para los datos del número 43 al 52 se activó el controlador, se tomó el valor de la orientación en el dato 42 como referencia. El código diseñado usa la aproximación rectangular de la Riemann [32] para la integral del error. Este código presentado en la Figura 6 toma el error y obtiene la velocidad que se debe mandar al pivote del péndulo, en este caso el tobillo del robot, de forma normalizada, es decir, entre 0.0 y 1.0, el ángulo enviado al tobillo no es el ángulo deseado debido a que la orientación del tobillo no es la misma orientación de la unidad inercial, así que se debe establecer la relación entre el ángulo del tobillo y el ángulo que se desea corregir.
Figura 11. Implementación del controlador.
En el Apéndice 6 se encuentra un diagrama explicando el funcionamiento del controlador dentro de la toma de datos.
8.
VALIDACIÓN DEL TRABAJO
8.1. Metodología de prueba
A lo largo de este proyecto se realizaron varias pruebas para ver el comportamiento del robot NAO. Estas pruebas se realizaron con Python y el simulador Webots para su
visualización. La primera prueba que se hizo fue con el código sin modificar. Posteriormente se limitó la acción a una sola patada.
Una vez diseñado el código para la toma de datos se realizó una simulación pero los datos se tomaban después de que el robot se moviera, por lo cual todos los datos eran bajos, por esto la importancia del “.post” explicado en el numeral 7.2 de este documento. Corregido este problema y diseñado y programado el controlador se realizaron pruebas para verificar dicha programación.
Con cada prueba los datos cambian, por lo tanto la velocidad máxima sobre la cual se normaliza la velocidad dada por el controlador es distinta; al realizar varias pruebas se optó por una velocidad de 7 rad/s como velocidad máxima ya que esta no es alcanzada por el controlador pero sí es cercana (se tuvieron datos como 6.3 rad/s).
Fue importante realizar varias pruebas de simulación debido a fallas que se presentan en el simulador Webots, incluyendo una diferencia entre el comportamiento del robot en el simulador frente al comportamiento esperado. Por lo tanto antes de realizar una nueva simulación se reestableció la simulación a su estado original. Esta simulación se hizo cargando en Webots el ejemplo de Aldebaran: Robocup. El balón se movió a las coordenadas en X=0.14 y Z=0.08. Esto último posiciona el balón frente al pie derecho del humanoide.
8.2. Validación de los resultados del trabajo
Antes de implementar el controlador en Python se simuló este en Simulink, obteniendo la siguiente gráfica del sistema de lazo cerrado.
El sistema de lazo cerrado con el controlador implementado se muestra en la Figura 12 y presenta un sobre pico de 0.5% y un tiempo de establecimiento de 0.008s con un criterio del 0.3%.
La señal de control obtenida tiene un valor máximo de 0.15rad/s y es la siguiente:
Figura 13. Señal de control obtenida en Simulink.
Figura 14. NAO pateando el balón.
Los resultados anteriormente presentados corresponden al modelo presentado en la ecuación (4) y al controlador de la ecuación (5). Se realizó otra identificación con diferentes datos obtenidos para tener la siguiente función de transferencia:
𝐻(𝑠) = 6265
𝑠 + 21.58 (6)
Para este modelo se obtuvo el siguiente controlador usando el lugar geométrico de las raíces como método de sintonización.
𝑍(𝑠) = 0.06811413 +7.3241
𝑠 (7)
En simulink se obtuvo la siguiente simulación para los modelos de planta y controlador de las ecuaciones (6) y (7) respectivamente:
Figura 15. Respuesta en lazo cerrado segundo modelo.
La Figura 15 muestra un sobre pico del 1.5% y un tiempo de establización de 0.015 segundos con un criterio del 1%. La acción de control mostrada en la Figura 16 tiene un valor máximo de 0.01rad/s. La Tabla 4 muestra distintas acciones de control obtenidas para este segundo modelo.
DATOS 1 (rad/s)
DATOS 2 (rad/s)
DATOS 3 (rad/s)
DATOS 4 (rad/s)
0,008937 0,002513 0 0,011542
0,039713 0,015688 0,013284 0,030468
0,076394 0,038965 0,035787 0,054759
0,118601 0,060386 0,064849 0,082458
0,164608 0,092978 0,092604 0,112275
0,212412 0,132232 0,125332 0,143486
0,264193 0,170167 0,159754 0,174677
0,316733 0,218242 0,194856 0,20569
0,369116 0,264726 0,230099 0,236376
0,420711 0,313852 0,265294 0,267262
Figura 16. Acción de control segundo modelo.
En Webots se obtuvieron los resultados para cada modelo:
Figura 17. Orientación sagital del robot NAO para el primer modelo.
-3, -2,4 -1,8 -1,2 -0,6 0,
0.05 0.3 0.55 0.8 1.05 1.3 1.55 1.8 2.05 2.3 2.55 2.8 3.05 3.3 3.55 3.8
Á
ng
ul
o
(°
)
Tiempo (s)
Theta Y
Figura 18. Acción de control del primer modelo.
Figura 19. Sistema en lazo cerrado segundo modelo.
Figura 20. Acción de control segundo modelo.
0, 1, 2, 3, 4,
2.2 2.25 2.3 2.35 2.4 2.45 2.5 2.55 2.6 2.65
V
el
oc
ida
d
(r
ad
/s
)
Tiempo (s)
Acción de control
-3, -2,4 -1,8 -1,2 -0,6 0,
0.05 0.3 0.55 0.8 1.05 1.3 1.55 1.8 2.05 2.3 2.55 2.8 3.05 3.3 3.55 3.8
Á
ng
ul
o
(°
)
Tiempo (s)
Theta Y segundo modelo
0, 0,125 0,25 0,375 0,5
2.2 2.25 2.3 2.35 2.4 2.45 2.5 2.55 2.6 2.65
V
el
oc
ida
d
(r
ad
/s
)
Tiempo (s)
El principal resultado y objetivo final de este proyecto es el código del controlador, el cual fue presentado en la Figura 11. Este código es parte del ciclo de toma de datos y se basa en tomar como referencia el ángulo justo antes del impacto, después calcular el error con base en esa referencia, realizar la acción de control con el error calculado realizando la aproximación de Riemann[32] en cada dato, y finalmente mandar la velocidad obtenida y normalizada junto con el ángulo a mover al tobillo.
8.3. Evaluación del plan de trabajo
Originalmente se planteó analizar los dos péndulos invertidos en los cuales se modela el robot, sin embargo debido a que el impacto es frontal y afecta principalmente a la orientación sagital del robot, se optó por realizar únicamente el control sobre el péndulo invertido lateral como una primera etapa del proyecto. Aunque no se cumplió con todo lo planeado, se obtuvo un conocimiento en el manejo y programación del robot NAO.
9.
DISCUSIÓN
Inicialmente se planeó realizar el control para los dos péndulos invertidos, sin embargo debido a que el impacto del robot con el balón es frontal se limitó esta primera etapa del proyecto a trabajar el péndulo lateral. Este trabajo está limitado al robot apoyado únicamente en un pie. El trabajo que no se realizó y que se había planeado originalmente debe realizarse para un óptimo desempeño del robot en el caso de estudio.
El trabajo a desarrollar en un futuro próximo es diseñar e implementar el controlador del péndulo invertido frontal, hacer que los dos controladores actúen todo el tiempo que el robot esté apoyado únicamente en un pie, haciendo distinción de cuál es el pie de apoyo y de este modo el control estaría aplicado a la acción de caminar, sin embargo se debe considerar que si los dos pies están apoyados en la superficie el control deja de actuar.
El método diseñado contempla una velocidad máxima constante, esto se debe a que la velocidad máxima obtenida de la simulación se obtiene al finalizar el tiempo en el cual debe actuar el controlador, lo cual hace imposible su aplicación. Esto también se trabajará en un futuro usando técnicas de predicción de error para determinar desde un principio cual es esta velocidad.
No se realizó un análisis teórico debido a dificultades con la función de transferencia teórica obtenida, MATLAB siempre mostró error argumentando que el número de polos del sistema debe ser mayor o igual al número de ceros del mismo. En este caso el sistema tiene un cero en el origen pero no tiene polos. Igualmente el simulador permitió obtener un modelo más aproximado al real así que se optó continuar con este modelo experimental.
El próximo trabajo a realizar será implementar este código en el robot físico una vez esté solucionada la cuestión de la velocidad.
10.
CONCLUSIONES
Las herramientas Simulink y SISOTOOL facilitaron el cálculo y simulaciones al igual que el diseño del controlador. Permitieron diseñar el controlador mediante el lugar geométrico de las raíces y probar su eficiencia antes de la implementación del algoritmo del controlador.
Se implementó un controlador PI debido principalmente a los resultados obtenidos tras su implementación: buen tiempo de establecimiento, bajo sobre pico porcentual.
Coordinar bien el funcionamiento del controlador es primordial para corregir las perturbaciones y efectos no deseados sea al momento de patear, de mantener el equilibrio en un pie o, para un trabajo futuro, caminar.
Este trabajo es de utilidad y aplicación en todo bípedo que cuente con una unidad inercial y tenga lo posibilidad de hacer movimientos en el tobillo en los movimientos Pitch y Roll [33].
Para realizar este proyecto fue necesario bloquear el movimiento natural del torso, así que se debe ver si esto se puede evitar pues cuando el controlador se implemente a lo largo de la marcha se presentaría un inconveniente.
Es de suma importancia realizar el trabajo en el simulador antes de realizarlo con el robot físico pues se pueden presentar daños por errores en los algoritmos. Igualmente el robot virtual tiene un comportamiento diferente al del robot real, así que se debe hacer un nuevo análisis con este último.
El modelo obtenido por identificación varía debido a que los datos no son los mismos entre simulaciones, por lo tanto se deben tomar datos aproximados y de alta frecuencia, también tomar más datos pues el momento de la perturbación varía entre simulaciones.
No existe un único modelo del robot pues depende de la cantidad de datos y los valores de datos que se tomen. El modelo más completo sería el que surja a partir de todos los datos obtenidos y representaría el movimiento del robot apoyado en un solo pie, no la perturbación debida al impacto.
Al momento de realizar pruebas en el robot NAO real se debe considerar que la eficiencia del controlador y del código de la patada está sujeta a la temperatura de los motores y al nivel de batería que se tenga. Cuando los motores están calientes o no hay casi batería, el robot NAO alerta de estas condiciones y deja de moverse para evitar daños por desgaste.
Los resultados dependen del controlador implementado y del momento en que este se ejecute: para el primer controlador el sistema se mantuvo estable en el valor de referencia pero con un retraso frente al momento de ejecución del controlador. El segundo modelo suprime la perturbación y mantiene el comportamiento obtenido cuando no se hace contacto con el balón.
Debido a variaciones en la señal de controlador obtenida del simulador Webots es necesario realizar varios experimentos para ver cuál es la velocidad máxima obtenida y programar con base en esa. Pero puede ocurrir que en una simulación la señal de control supere la velocidad máxima programada así que se debe hacer un condicional para mantener entre 0.0 y 1.0 la relación entre la velocidad de la señal de control y la velocidad máxima programada.
Al momento de poner el robot a caminar es necesario rediseñar el controlador pues no se mantendría un valor constante de referencia durante toda la marcha. Tocaría hacer en este caso una planeación de trayectoria, con esto la referencia cambiaría a lo largo del tiempo y el controlador actuaría en función de esa referencia.
Para un trabajo futuro se sugiere buscar como calcular previamente la velocidad máxima, ya sea con técnicas de predicción de error o con una regresión lineal como opción básica aunque como se ve gráficamente esta no es del todo aplicable. Si se hace actuar al control desde el momento en que el robot queda apoyado en un solo pie tocaría con datos previos hacer un análisis estadístico para las primeras velocidades máximas y posteriormente aplicar la técnica elegida.
El éxito de este proyecto significaría una reducción en el daño causado al robot NAO debido a caídas inesperadas, de este modo se generaría un aumento del tiempo de funcionamiento del robot, una reducción en costos de mantenimiento y con una distribución del algoritmo los usuarios de NAO en todo el mundo lo podrían implementar.
Para este proyecto se tuvo un modelo teórico y un modelo experimental obtenido mediante técnicas de identificación. El modelo teórico representa todo el comportamiento del péndulo mientras que el modelo identificado representa la perturbación del péndulo dada por el impacto con el balón. Para el caso de estudio de este proyecto se debe tomar el modelo identificado.
Los resultados dependen del modelo y del controlador desarrollado, con lo que se concluye de este trabajo que se deben explorar algoritmos de control más robustos. Teóricamente el modelo siempre es el mismo.
El modelo teórico omite el efecto de las masas de cada parte del cuerpo del robot NAO que existe sobre la estabilidad del mismo. Teóricamente el robot es un cuerpo rígido de
masa puntual al final de este. En la realidad la posición de cada parte del cuerpo del robot NAO modifica la posición del CoM del mismo.
Para el desarrollo de este proyecto la mejor alternativa es la experimental pues se contempla únicamente la perturbación y no todo el comportamiento del péndulo invertido, se puede igualmente programar y mejorar el comportamiento del robot antes de diseñar el controlador e implementarlo. Esto no se puede hacer con la alternativa teórica.
Identification System Toolbox [11] de MATLAB es una herramienta que permite la identificación de un modelo de proceso mediante el uso de un vector de entrada y un vector de salida, ambos en el tiempo. Este sistema aunque es útil presenta una desventaja al dar múltiples opciones de diseño del modelo, para saber cuál es mejor se debería analizar cada uno de los posibles modelos y mirar los controladores correspondientes.
Al momento de trabajar con el robot real se debe realizar nuevamente una identificación para obtener el modelo a trabajar. Se debe analizar previamente el comportamiento del robot NAO real para que esta identificación corresponda a escenario deseado.
Se consideró al robot como simétrico en el análisis de CoM, sin embargo en la realidad esto no ocurre. A nivel de simulación se deben considerar también las inercias y momentos del robot. Estos efectos hacen que entre simulaciones los datos sean diferentes, al igual que el instante en el que ocurre el impacto con el balón varía.
La fidelidad de los datos depende en gran medida del correcto funcionamiento del simulador, si este falla los datos no corresponderán al escenario deseado. Un error en el comportamiento del robot al momento de la simulación hace que los datos no correspondan al comportamiento esperado. Una caída o la falta de movimiento quedan registradas en los datos, haciendo que estos no sirvan para la identificación.
Existe una diferencia entre el tiempo de toma de los datos y el tiempo de escritura de estos, por lo cual no son datos en tiempo real. Python tarda 0.01 segundos en escribir los datos en un documento de Excel, así que los datos escritos están retrasados frente a su instante de captura. De igual modo Python tiene un retraso al enviar los datos al robot.
La acción de control tiene un tiempo de muestreo diferente al tiempo de toma de los datos. Esto puede generar inconsistencias entre la señal de control y la respuesta en lazo cerrado. Los datos de la retroalimentación se toman con un tiempo de muestreo establecido, sin embargo la salida del controlador lleva otro tiempo de muestreo, así que la corrección del sistema no ocurre al tiempo con los datos tomados, esto hace que el control no sea del todo eficiente. Como se pudo ver en la Figura 17 hay una
estabilización retrasada frente al instante en el que ocurre la perturbación y se activa el controlador.
Webots es un simulador muy útil para trabajar con varios robots en varios escenarios, como es el caso del robot NAO en la cancha de football, escenario usado para este proyecto. Sin embargo este simulador presenta fallas en su funcionamiento: no todas las veces simula correctamente.
El algoritmo diseñado está limitado a una velocidad máxima establecida para la normalización de la señal de control, lo cual hace que no sea una señal de control del todo eficiente. Se puede obtener la velocidad máxima en cada ejecución del controlador, sin embargo esta velocidad se obtiene una vez se haya efectuado la acción de control haciendo que no se pueda utilizar en el código, es decir, la velocidad máxima se obtiene una vez obtenido el vector de la acción de control con lo cual el controlador ya deja de actuar.
Para mejorar a futuro este proyecto se debe determinar estadísticamente y usando técnicas de predicción de error la velocidad angular máxima que entregará el controlador, sin embargo esto no es del todo aplicable si se trabaja con la totalidad de los datos como ocurre al momento de controlar la marcha. En este caso se deben implementar técnicas de generación de trayectorias.
11.
AGRADECIMIENTOS
Quiero agradecer por su apoyo, amistad, aprecio y enseñanzas a todas las personas que me han acompañado a lo largo de mi formación académica, personas que me han enseñado mucho, que han compartido momentos especiales conmigo, que me han apoyado y ayudado siempre.
A mis padres les doy las gracias por apoyarme y darme la oportunidad de haber estudiado en la Universidad de los Andes. A Ana María Aranguren Aranguren, mi novia, te agradezco por tantas risas, tanto amor, tanto apoyo así no sepas del tema siempre me has escuchado y has compartido mis alegrías y emociones, también me has dado fuerzas para seguir adelante; amor, gracias por hacerme porras. A mi familia, mis hermanos por acompañarme. Gustavo, ya no estás con nosotros pero siempre estarás en mi corazón, te amo y te extraño muchísimo hermano. Gracias.
A mis asesores Fernando Jiménez y Mario Arbulú les doy las gracias por creer en mí y apoyar mi proyecto. Fernando, gracias por tus enseñanzas, por ayudarnos a Mario y a mí con nuestras dudas, por guiarme en este proyecto. Mario, gracias por compartir tantas cosas conmigo, enseñarme tanto y permitirme trabajar contigo en la Universidad de La Sabana, eres más que un asesor, más que un profesor.
Agradezco a mis amigos de los Andes por acompañarme a lo largo de mi vida universitaria. Eduardo Venegas, Jose Camargo, Alejandro Sánchez desde primer
semestre me han apoyado, ayudado y acompañado; Marcela Blanco, Jorge Mendieta, Alejandro Becerra, Paula Álvarez, Ricardo Rodríguez, Camila Koschmieder.
Agradezco a Andrés Mauricio Sierra y Nicanor Quijano por enseñarme Control por primera vez. A Andrés Villamil y muy especialmente a Daniel Penagos por toda tu ayuda a lo largo de este proyecto. Siempre que lo he necesitado me has ayudado con todo lo que he necesitado y con todas las dudas que he tenido.
De la Universidad de La Sabana quiero agradecer a Andrés Carrera y Antonio Cuervo por ayudarme y estar pendiente de mí, por darme un lugar para realizar mi proyecto. A Felipe Moscoso, Jenny Robayo, Hazan Pérez, Miguel Valcárcel, Sergio Iregui y Johan Ayala por hacerme sentir como uno más de ustedes en el Laboratorio Lux y por ayudarme a entender y manejar a NAO.
12.
REFERENCIAS
[1] Aldebaran Robotics. En: http://www.aldebaran.com/en
[2] Robot NAO. En: https://www.aldebaran.com/en/humanoid-robot/nao-robot
[3] D. Kaynov. Open motion control architecture for humanoid robots. Tesis Doctoral. Universidad Carlos III de Madrid. Leganés. Octubre 2008.
[4] S. Caron, Q. Pham, Y. Nakamura. Satability of Surface Contacts for Humanoid Robots: Closed-Form Formulae of the Contact Wrench Cone for Rectangular Support Areas. Cornell University Library. eprint arXiv:1501.04719. 01/2015.
[5] Postural Stability of Biped Robots and the Foot-Rotation Indicator (FRI) Point. The International Journal of Robotics Research. June 1999 18: 523-533.
[6] Universidad Nacional de Tucumán, Centro Ing, Roberto Herrera. Métodos de
Sintonización de Controladores PID. En:
http://www.herrera.unt.edu.ar/controldeprocesos/Tema_4/Tp4a.pdf
[7] R. Dorf. Sistemas Modernos de Control. Teoría y Práctica. Addison – Weesley Iberoamericana. 2da Edición en Español. 1989. pp 33 – 36.
[8] Lenguaje de programación Python. En: https://www.python.org/
[9] Simulador Webots de Cyberbotics. En: https://www.cyberbotics.com/overview
[10] Robocup 2015. En: http://www.robocup2015.org/
[11] Herramienta System Identification Toolbox de MathWorks. En:
http://www.mathworks.com/products/sysid/
[12] MATLAB de MathWorks. En: http://www.mathworks.com/products/matlab/
[13] Herramienta SISO Design Tool de MathWorks. En:
http://www.mathworks.com/help/control/getstart/siso-design-tool.html
[14] S. Grass. Formulación de trayectorias para definir los límites dinámicos de un robot tipo delta. Universidad de los Andes. Bogotá, 2012.
[15] A. Romero. Puesta a punto y desarrollo de un sistema de programación para un robot tipo delta. Universidad de los Andes. Bogotá, 2012.
[16] J. Betancur. Weighted controller for an inverted pendulum: a replicator dynamics approach. Universidad de los Andes. Bogotá, 2010.
[17] J. Barragán. ROBOT USABLE COMO APOYO EN LA REHABILITACIÓN DE RODILLA. Universidad de los Andes. Bogotá, 2013.
[18] Y. Sakagami, R. Watanabe, C. Aoyama, S. Matsunaga, N. Higaki, and K. Fujimura. "Intelligent ASIMO: System overview and integration”, IEEE Intelligent Robots and Systems, Ginebra, Suiza, 2002
[19] C. Monje, E. Liceaga-Castro, M. Arbulú, D. Kaynov, P. Staraverov, P. Pierro, C. Pérez, L. Pabón, C. Balaguer. Control de la caminata del Robot Humanoide RH-1.XXIX Jornadas de Automática. Tarragona. España. Septiembre, 2008.
[20] M. Muñoz, J. Simó, J. Blanes, J. Coronel, M. Albero. ARQUITECTURA DE CONTROL PARA ROBOT HUMANOIDE. Instituto de Automática e Informática Industrial, Universidad Politécnica de Valencia. Valencia, España.
[21] J. Alcazar. Robust Feedback Control of Omnidirectional Biped Gait on the Nao Humanoid Robot. Facultad de Informática, Universidad de Murcia. 2014.
[22] S. Fernández. Locomoción bípeda del robot humanoide Nao. Noviembre, 2009. [23] J. Bueno. Optimización y modelado del movimiento de un robot bípedo NAO usando técnicas de IA. Junio, 2012.
[24] Documentación de Aldebaran Robotics. En:
https://community.aldebaran.com/en/resources/documents
[25] NAO – Technical overview: Masses. En: http://doc.aldebaran.com/2-1/family/robots/masses_robot.html
[26] NAO – Technical overview: Links. En: http://doc.aldebaran.com/2-1/family/robots/links_robot.html
[27] NAOqi Developer guide – Programming – Python SDK – Python Examples – Motion – Whole body motion: Kick. En: http://doc.aldebaran.com/2-1/dev/python/examples/motion/whole_body.html#python-example-motion-wholebody [28] SIMULINK de MathWorks. En: http://www.mathworks.com/products/simulink/
[29] Plugin Pydev para Eclipse. En: http://www.pydev.org/
[30] Eclipse. En: https://eclipse.org/
[31] Whole Body Control. En: http://doc.aldebaran.com/1-14/naoqi/motion/control-wholebody.html?highlight=whole%20body
[32] A. Huerta, J. Sarrate, A. Rodríguez-Ferran. Métodos numéricos: introducción, aplicaciones y programación. Universidad Politécnica de Catalunya, 2009. pp 182-184. [33] A. Takanishi, Y. Ogura, K. Itoh. Some Issues in Humanoid Robot Design. Waseda University. Tokyo, Japón. Robotics Research, Springer Tracts in Advanced Robotics. Volumen 28, 2007. pp 357-372.
Control de Estabilidad de un bípedo aplicado a la plataforma NAO
36
13.
APENDICES
• APÉNDICE 1: Cotización robot NAO.
Page 1 / 2
Price Information Aldebaran Robotics Inc.
Date: 10/07/2014 155 Federal Street, Suite 1702,
Expiration Date: 10/30/2014 Boston, MA 02110, United State
Your contact: Cedric
Vaudel
[email protected] +16179630398
Billing Details :
UNIVERSIDAD DE LOS ANDES Fernando JIMENEZ School of Engineering ML-747 Carrera 1E-18-A10 Bogotá
Colombia
Shipping Details :
UNIVERSIDAD DE LOS ANDES
Fernando JIMENEZ School of Engineering ML-747 Carrera 1E-18-A-10
Bogotá
Colombia
Products
Product Reference Description Unit Price Quantit
y
Total Price
NAOH25050601B NAO Evolution Blue USD 7.990,00 1 USD 7.990,00
Shipping and other fees: USD 354,00 Total Excl. Taxes: USD 8.344,00
Tax: 0%
1.1.
Grand Total: USD 8.344,00
Software
SW-MSB Choregraphe Software –1 key 1 session $260
SW-MSB-15 Choregraphe Software –1 key 15 sessions $2,850
SW-MSB-30 $3,300
SW-MSB-SITE Choregraphe Software –1 key unlimited session for 1 site $4,200
SW-WEB-1 Webots for NAO –Single License $150
WEB-ASK0 ASK NAO (Autism Solution for Kids) $2,000
WEB-ASK1 ASK NAO - Additional License per site $500
Product Code Description Price (excl. shipping and taxes)
Robots
NAOH25050501R NAO Evolution Red* $7,990
NAOH25050601B NAO Evolution Blue* $7,990
NAO-SOCCP $39,990
NAO-CARDEV NAO Evolution Car Bundle $9,990
Curriculum
Digital & Hard copy
Incl. tablet
NAO-CURC2 $600 $900
NAO-CURC3 NAO CS Introduction to Robotics –Grade 9-12 $600 $900 NAO-CURC4 NAO STEM Olympics –Grade 9-12 (includes Depth Sensor and Games Accessories) $900 $1,200
NAO-CURC5 NAO STEM Robotic Idol –Grade 9-12 $600 $900
• APÉNDICE 2: Código ejemplo de la patada en Python [28].
# -*- encoding: UTF-8 -*- ''' Whole Body Motion: kick '''
''' This example is only compatible with NAO ''' import argparse
import motion import time import almath
from naoqi import ALProxy
def computePath(proxy, effector, frame):
dx = 0.05 # translation axis X (meters) dz = 0.05 # translation axis Z (meters) dwy = 5.0*almath.TO_RAD # rotation axis Y (radian) useSensorValues = False
path = [] currentTf = [] try:
currentTf = proxy.getTransform(effector, frame, useSensorValues)
except Exception, errorMsg: print str(errorMsg)
print "This example is not allowed on this robot." exit()
# 1
targetTf = almath.Transform(currentTf) targetTf *= almath.Transform(-dx, 0.0, dz) targetTf *= almath.Transform().fromRotY(dwy) path.append(list(targetTf.toVector()))
# 2
targetTf = almath.Transform(currentTf) targetTf *= almath.Transform(dx, 0.0, dz)
path.append(list(targetTf.toVector())) # 3
path.append(currentTf) return path
def main(robotIP, PORT=9559):
''' Example of a whole body kick
Warning: Needs a PoseInit before executing
Whole body balancer must be inactivated at the end of the script
'''
motionProxy = ALProxy("ALMotion", robotIP, PORT)
postureProxy = ALProxy("ALRobotPosture", robotIP, PORT) # Wake up robot
motionProxy.wakeUp()
# Send robot to Stand Init
postureProxy.goToPosture("StandInit", 0.5) # Activate Whole Body Balancer
isEnabled = True
motionProxy.wbEnable(isEnabled) # Legs are constrained fixed stateName = "Fixed"
supportLeg = "Legs"
motionProxy.wbFootState(stateName, supportLeg) # Constraint Balance Motion
isEnable = True supportLeg = "Legs"
motionProxy.wbEnableBalanceConstraint(isEnable, supportLeg) # Com go to LLeg
supportLeg = "LLeg" duration = 2.0
motionProxy.wbGoToBalance(supportLeg, duration) # RLeg is free
stateName = "Free" supportLeg = "RLeg"
motionProxy.wbFootState(stateName, supportLeg) # RLeg is optimized
effector = "RLeg" axisMask = 63
frame = motion.FRAME_WORLD # Motion of the RLeg
times = [2.0, 2.7, 4.5]
