Spanish
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA DE TELECOMUNICACIÓN
GRADO EN INGENIERÍA DE ROBÓTICA SOFTWARE
TRABAJO FIN DE GRADO
CONSTRUCCIÓN Y DESPLIEGUE DEL ROBOT REACHY SIMPLIFICADO
Autor: Alberto Delgado del Cerro
Tutor: José Miguel Guerrero Hernández
Curso académico 2021/2022
Desde la primera aparición del término "robot" en la obra Rossum's Universal Robots, los humanos han imaginado máquinas con las que interactuar. A lo largo de la historia se han creado multitud de robots humanoides que permitan una interacción cómoda con personas, desde el precario Elektro de Joseph Barnett hasta la innovadora Sophia, creada por la compañía Hanson Robotics.
Este proyecto pretende crear una versión simplificada del robot Reachy, un robot humanoide de acceso libre de la empresa Pollen Robotics creado precisamente para interactuar con personas. Esta versión utilizará ROS (Robot Operating System) para controlar las funciones y una Raspberry Pi como procesador, por lo que su coste será mucho menor que el del proyecto original.
La realización de este proyecto se fundamenta en tres partes principales: movimiento, visión e interacción con el humano, que se desarrollarán de forma separada para unirse finalmente obteniendo un robot que pueda realizar las tres tareas de forma coordinada.
Como resultado de este trabajo, se ha obtenido un robot funcional fabricado desde cero, diseñando e imprimiendo en 3D las piezas oportunas, y programando los comportamientos y las acciones necesarias para interactuar con una persona de distintas formas.
En conclusión, pese a los problemas producidos por la incompatibilidad del hardware, se ha creado un robot con una autonomía elevada, modular y que se puede modificar fácilmente, ya sea para añadir o eliminar funcionalidades.
El diccionario de Oxford define la robótica como la técnica que se utiliza en el diseño y la construcción de robots y aparatos que realizan operaciones o trabajos, generalmente en instalaciones industriales y en sustitución de la mano de obra humana.
A pesar de esto, el término robot ha evolucionado desde su creación, pasando de ser usado en instalaciones industriales hasta a llegar a abarcar desde asistentes de comunicación hasta máquinas de forma humanoide capaces de moverse e interactuar con su entorno mejor que la gran mayoría de las personas.
Figura 1 Video demostración de movimiento del robot Atlas.
( https://www.youtube.com/watch?v=tF4DML7FIWk )
En la actualidad se está viviendo el auge de los robots domésticos. En contraste con los industriales, estos robots son más ligeros, más pequeños y menos potentes, lo que les permite compartir espacio con personas sin suponer un peligro para estas. Dentro de estos robots domésticos encontramos aquellos que ayudan en tareas domésticas como aspiradoras automáticas, que usan un mapa de la casa para limpiar de la manera más eficiente posible, o robots que dosifican la comida de las mascotas y las entretienen para hacer su día a día más llevadero. También se incluyen en los robots domésticos los que se comunican de forma directa con las personas, como los asistentes de voz o robots educativos. Estos últimos, que existen para interactuar con humanos de la forma más natural posible, se conocen como robots sociales.
La robótica social se puede definir como la ciencia que usa un robot autónomo que interactúa y se comunica con humanos u otros agentes físicos autónomos siguiendo comportamientos sociales y reglas asociadas a su función.
Actualmente estos robots son cada vez más comunes, existen desde campos educativos como los robots Nao o Pepper de la empresa SoftBank Robotics hasta mascotas como la foca Paro, pero todos ellos tienen un problema en común: sus precios. El más barato de estos tres robots cuesta alrededor de unos 6.000 dólares, y el más caro unos 44.000, incluso el proyecto de Reachy, que es abierto y permite imprimir tus partes, cuenta con un presupuesto estimado de unos 2.000 dólares contando solo los materiales.
Pepper es un robot humanoide que mide aproximadamente 1 metro y 20 centímetros de altura. Debido a su diseño atractivo y dinámico, este robot se ha usado en distintos establecimientos de cara al público como hoteles o centros comerciales, y es capaz de interactuar con las personas gracias a su nivel de interacción y los sensores con los que cuenta, como la cámara que se encuentra en su frente o la pantalla táctil de su pecho.
Pepper ha sido usado en diversos experimentos, especialmente relacionados con la enseñanza, como Pepper Learns Together with Children: Development of an Educational Application(Fumihide Tanaka, 2008),la interacción con personas con autismo, como Sugar, Salt & Pepper -- Humanoid robotics for autism (Cristina Gena, 2018)y como guía en diversos escenarios Enabling a Pepper Robot to provide Automated and Interactive Tours of a Robotics Laboratory(Gavin Suddrey, 2018).
Gracias a su capacidad de habla es capaz de dar conferencias o clases en hasta 15 idiomas, y sus brazos y la tableta de su pecho permiten que sea interactivo, atrayendo a visitantes a los lugares en los que se encuentra.
También puede usarse como herramienta educativa a diferentes niveles, pues se puede programar usando Choregraphe (una programación que se realiza usando bloques sencillos e intuitivos), Python o C++ (lenguajes de programación clásicos basados en texto y más potentes)
A pesar de su fama, el robot Pepper cesó su fabricación (Infobae, 2021) en el año 2021 debido a sus bajas ventas y su alto coste (44000$).
Figura 2 Imagen del robot Pepper.
NAO fue el primer robot creado por SoftBank__Robotic (Revista de robots, 2020)en el año 2004, y actualizado en los años 2006, 2011, 2012 2014 y 2018. Este robot humanoide se ha usado en diversos ámbitos, desde la educación (gracias a la facilidad de programarlo usando métodos visuales como NaoQi), hasta en residencias de ancianos, donde el robot humanoide se usaba para entretener y dar compañía a los residentes.
Este robot sustituyo en 2007 a Aibo, el perro robot de Sony como plataforma estándar para la Robocup, un proyecto fundado en 1997 para promover la investigación sobre inteligencia artificial usando competiciones entre robots autónomos. En esta competición se usan 6 de estos robots en dos equipos para jugar partidos futbol de forma autónoma.
También se ha usado en residencias de ancianos y hospitales para ayudar a niños con autismo ya que, debido a su forma y su interactividad, permite comunicarse a pacientes que no son capaces de hacerlo con personas.
Figura 3 Imagen del robot Nao (izq.) y el robot Aibo (der.).
A pesar de haber sido creado en parte como robot educativo, su precio lo excluye de la mayoría de los centros en los que podría usarse, por lo que se ve relegado a su uso en universidades o centros privados.
Debido a su tamaño y su aspecto, Nao se ha usado en diversos experimentos relacionados con la educación de niños como Humanoid Robot NAO Interacting with Autistic Children of ModeratelyImpaired Intelligence to Augment Communication Skills (Syamimi Shamsuddina, 2012) o Using Prosodic Entrainment to Improve Robot-Assisted Foreign Language Learning in School-Aged Children (Sungjin Lee, 2011).
Estos estudios aprovechan el aspecto divertido de Nao y sus formas de interacción para crear vínculos con niños clasificados dentro del espectro autista y así obtener una forma de comunicarse con ellos. De esta forma se obtiene un método de ayuda y una vía de comunicación con niños que no son capaces de relacionarse de forma normal.
Ajustándose a la definición, existen también otro tipo de robots sociales: los asistentes de voz. Son programas (CEF Marketing XXI, 2022) de software basados en la inteligencia artificial capaces de reconocer el lenguaje hablado y responder a comandos de voz para ejecutar una serie de tareas como controlar luces, responder preguntas, realizar listas, etc. de modo que posibilitan a los usuarios interactuar con diferentes plataformas y hardware mediante la voz.
Al contrario que el resto de los robots sociales, el problema de los asistentes de voz no es su precio, sino su forma. La mayoría de estos asistentes de voz utilizan un smartphone como hardware, por lo que su coste es casi nulo, y otros utilizan altavoces inteligentes en los que la presencia de un asistente virtual es más un añadido que un elemento principal. En ambos casos los problemas son el mismo, una forma poco o nada interactiva y un entorno demasiado cerrado como para investigar.
Figura 4 Asistente de voz Google nest mini.
Este documento se dividirá en 4 bloques principales que a su vez se dividirán en subsecciones para dar información de la forma más clara posible. Estos bloques serán:
- Objetivos y metodología , que se centrará en explicar los objetivos de este trabajo, la metodología que se seguirá para conseguirlos y el plan de trabajo, que especifica los pasos necesarios para seguir la metodología.
- Diseño de Reachy , en el que se explicará cómo se han diseñado las piezas necesarias para adaptar el modelo de Reachy a una versión simplificada, el hardware elegido para hacerlo funcionar y el software utilizado para controlar y coordinar las diferentes funciones de Reachy.
- Implementación de Reachy, donde seexplicará cómo se ha realizado la integración de todos los comportamientos y funcionalidades de Reachy, así como un manual de usuario que muestre como interactuar con Reachy.
El objetivo principal de este trabajo es recrear una primera versión del robot Reachy con capacidades limitadas y un presupuesto asequible. Para ello se investigarán las posibles alternativas para los motores, así como los controladores y el resto de las piezas. Para que el proyecto sea realmente asequible, se usará como procesador una Raspberry pi 4 con 4 gigas de RAM, con Ubuntu como sistema operativo y el middleware ROS, ambos de acceso libre.
Figura 5 Robot Reachy completo.
En este proyecto se recreará el cuello y la cabeza de Reachy, ambos simplificados para obtener un funcionamiento similar al original y con publicación en código abierto, tanto los nodos de ROS como los archivos para la impresión 3D. Este robot deberá ser capaz de obedecer a las órdenes de una persona y mantener una conversación básica con esta, moviéndose para mirarle cuando hable y respondiendo de forma física y verbal.
Para realizar este trabajo se va a utilizar el desarrollo por etapas(Mena, González, & Galván, 1999), un modelo usado generalmente en la ingeniería de software pero que en este caso se aplicará también al hardware, como en la impresión 3D.
Este modelo de desarrollo se caracteriza por mostrar al cliente el software en diferentes estados sucesivos de desarrollo, y consta de cinco fases:
- Fase de evaluación de conceptos.
- Fase de planificación y especificación del producto.
- Fase de desarrollo.
- Fase de pruebas y evaluación.
- Fase de lanzamiento.
Figura 6 Representación esquemática del desarrollo por etapas.(Mena, González, & Galván, 1999)
Esta metodología se ha usado de forma concurrente en los distintos apartados del proyecto, de forma que, ante la aparición de problemas como el retraso en el envío del controlador de los motores, se ha podido seguir avanzando en otros frentes del proyecto como el análisis visual o la impresión de piezas.
Se ha elegido esta metodología debido en parte a su flexibilidad, al contrario que otros métodos como SCRUM, el desarrollo por etapas no utiliza un marco de tiempo para marcar las diferentes fases de un proyecto, por lo que el inicio y finalización de estas vienen dados únicamente por las especificaciones. Esto es especialmente importante en este proyecto debido a los retrasos en los envíos de piezas y los problemas de compatibilidad. De haber usado la metodología SCRUM que utiliza periodos de tiempo llamados sprints para planear el desarrollo de un producto, los retrasos en los envíos de piezas habrían causado problemas en el desarrollo que se han evitado usando el desarrollo por etapas concurrente.
Para seguir el desarrollo explicado en el apartado anterior se ha dividido el proyecto en seis partes diferenciadas: Elección de software, visión artificial, comunicación, movimiento, impresión 3D y coordinación de comportamientos. Cada una de estas partes pasará por las cinco etapas del desarrollo elegido.
-
Elección de hardware: Búsqueda de diferentes motores compatibles con el proyecto y sus controladores, elección de cámaras y procesadores.
-
Elección de software: Valoración de distintos programas para controlar a Reachy, como Ubuntu, ROS o ROS2 y sus versiones.
-
Visión artificial: Proposición de diferentes modos de uso de las cámaras, seguimiento de objetos, selección de objetos según especificaciones… y elección de qué elementos se usarán y cuáles se descartarán.
-
Dialogo: Elección del programa usado para realizar la comunicación verbal.
-
Movimiento: Valoración del movimiento, sus modos y si son factibles teniendo en cuenta las limitaciones de presupuesto.
-
Impresión 3D: Elección de qué piezas del modelo de Reachy usar, cuáles modificar y cuáles crear desde cero.
-
Coordinación de comportamientos: Valoración de tipos de comunicación posibles entre los diferentes comportamientos.
-
Elección de hardware: Elección del modelo de motores, controlador y cámara que se usará en el proyecto.
-
Elección de software: Elección del sistema operativo y versión de ROS que se usará.
Visión artificial: Planificación de cómo hacer funcionar la visión, que programas usar y cómo implementar las funcionalidades.
- Dialogo: Valoración de formas de comunicación, así como los comandos que obedecerá Reachy y su reacción ante estos.
- Movimiento: Elección y diseño del modo de movimiento usando un cuello simplificado en lugar del cuello órbita original.
- Impresión 3D: Montaje de las piezas en un modelo 3D de Reachy y comprobación de las tolerancias, para elegir qué piezas modificar y cuáles crear desde cero.
- Coordinación de comportamientos: Elección de uso de mensajes en topics de ROS como forma de comunicación y los mensajes que se usarán.
- Elección de hardware: Coordinación de cableado y diferentes componentes eléctricos, así como configuración de los motores.
- Elección de software: Configuración e instalación de ROS y Ubuntu.
Visión artificial: Realización de pruebas para comprobar que los algoritmos funcionan correctamente y ajuste de parámetros como los límites necesarios para los filtros de color si es que las pruebas fallan. Tras esto se evaluará si la detección es lo suficientemente rígida para dar por terminado el desarrollo.
- Dialogo: Programación de los comandos y sus reacciones.
- Movimiento: Programación del movimiento de los motores y sus combinaciones para hacer a Reachy lo más expresivo posible.
- Impresión 3D: Modificación y creación de las piezas necesarias usando programas de modelado como Blender o freeCAD.
- Coordinación de comportamientos: Programación de la comunicación de los distintos nodos así como los mensajes y parámetros que se usarán.
-
Elección de hardware: Pruebas de distintas configuraciones de los motores variando la velocidad y el torque.
-
Elección de software: Pruebas de funcionamiento tanto en Ubuntu como en Ubuntu server.
-
Visión artificial:
-
Dialogo: Prueba de diálogo con distintas voces y evaluación de su funcionamiento.
-
Movimiento: Pruebas de movimiento como la velocidad de movimiento de los motores y cómo esta afecta al resto de elementos, o la potencia de los motores que deben ser capaz de mover toda la cabeza.
-
Impresión 3D: Impresión de las piezas, comprobación de las tolerancias y realización de los cambios necesarios para que el robot funcione correctamente.
-
Coordinación de comportamientos: Pruebas de comunicación, como velocidad de reacción o los campos que se necesitan entre mensajes.
-
Elección de hardware: Se da por acabado el desarrollo de esta parte de Reachy.
-
Elección de software: Se da por acabado el desarrollo de esta parte de Reachy.
-
Visión artificial: Se da por acabado el desarrollo de esta parte de Reachy.
-
Dialogo: Se da por acabado el desarrollo de esta parte de Reachy.
-
Movimiento: Se da por acabado el desarrollo de esta parte de Reachy.
-
Impresión 3D: Se da por acabado el desarrollo y montaje del resto de los elementos para obtener a Reachy completo.
-
Coordinación de comportamientos: Se da por acabado el desarrollo de Reachy.
La descripción del trabajo se realizará en cuatro partes, el sistema operativo, el diálogo, la visión y el movimiento.
Al comenzar el proyecto se pensaba usar las últimas versiones de los programas y el sistema operativo, Ubuntu 20.04 y ROS 2 Foxy Fitzroy, pero tras diversos problemas que se explicarán a continuación se ha decidido usar ROS Noetic Ninjemys en lugar de ROS 2.
ROS o Robot Operating System es un middleware de código abierto formado por un conjunto de bibliotecas de software y herramientas que ayudan a crear aplicaciones robóticas. Desde controladores hasta algoritmos de última generación y con potentes herramientas de desarrollo, ROS contiene todo lo necesario para crear proyectos de robótica. Actualmente se divide en 2 ramas: ROS y ROS 2, que se desarrollan de forma paralela en diferentes distribuciones.
ROS funciona usando procesos llamados nodos. Cada nodo realiza una tarea distinta: por ejemplo, un nodo podría leer la hora del día del ordenador, mientras que otro podría recibir la hora y comunicarla por voz. Para permitir la comunicación asíncrona entre nodos se usan _ topics _, canales en los que los nodos publican información si su propósito es dar información a otros, o a los que se suscriben si van a leer cierta información y procesarla, estos topics tienen nombre como /hora o /sector, que se utilizan para identificarlos, suscribirse y publicar. Cada nodo puede ser a la vez suscriptor de uno o más nodos y publicar en uno o varios nodos, y pueden usar distintos mensajes: como int64 si solo se quiere publicar un número, o string si se quiere publicar una palabra, una frase o mensajes propios con varios parámetros para usos más específicos.
Existe también otra forma de comunicación entre nodos: los servicios. Estos permiten una comunicación síncrona entre nodos usando dos mensajes: uno de solicitud , que pide ciertos datos, y uno de respuesta , que los envía. Al ser una comunicación síncrona, cuando un nodo usa un servicio pidiendo una solicitud, se bloquea hasta recibir una respuesta.
La intención inicial era usar la versión LTS (Long Term Support) más moderna de ROS 2, Foxy Fitzroy, por las ventajas que ofrece ROS2, como su mayor seguridad o la mejora de las comunicaciones entre nodos. Lamentablemente, debido a la novedad de ROS 2, este no cuenta con tantos complementos como ROS por lo que trabajar con él para recrear comportamientos más específicos como el habla es más complicado.
Debido a la velocidad de desarrollo de ROS 2, las implementaciones existentes de determinadas funcionalidades no son compatibles con las versiones actuales. Por el contrario, la estabilidad en las bases de ROS permite el uso de implementaciones a pesar de no haber sido diseñadas para la versión más moderna.
Tras elegir esta distribución, se comenzaron a investigar formas de implementar las funciones necesarias para el proyecto: diálogo, movimiento de los motores y visión artificial.
Existen códigos creados que permiten el uso de la cámara por USB (flynneva, 2022) y el control de los motores. Al contrario que con el soporte para la visión artificial, el soporte del diálogo es escaso. Existen opciones, como Jaco (DANBER, 2022) , que se ejecutan por completo en la maquina anfitriona, pero debido a las limitaciones de potencia y almacenamiento del procesador elegido, se ha preferido usar una implementación que funcione en la nube. En este caso se podría usar la implementación de lex-ros2 (mike-moore-az, 2022) que se vale de los AWS (Amazon Web Services) de Amazon para procesar el dialogo y enviar una respuesta.
A pesar del del potencial de la implementación usando el AWS de Amazon, han surgido problemas como su incompatibilidad con la distribución de ROS 2 Foxy Fitzroy, pues solo es compatible con una versión anterior de ROS 2 (Dashing Diademata, cuya EOL (End Of Life) fue en mayo de 2022). Además, esta versión solo es compatible con Ubuntu 18.
Por esta razón, y dado que el objetivo del proyecto no contempla la migración de código de terceros a distintas versiones, se ha decidido utilizar ROS Noetic Ninjemys que, si bien no es tan moderno como ROS 2, se mantendrá en activo hasta 2025 y funciona con Ubuntu 20.04.
El diálogo es la forma principal de interactuar con Reachy: permite comunicarse con él, darle órdenes o ayudarle cuando no sepa qué hacer. Para integrar esta función se ha utilizado Dialogflow, una API (Application Programming Interface) de Google que es capaz de entender el lenguaje natural y que provee infraestructura para recrear conversaciones y construir diálogos con el fin de interactuar con el usuario de manera fluida.
Para integrar esta API en ROS se ha usado la implementación de Inteligent Robotics Lab (fmrico, 2021)para la detección del habla y Festival para controlar el sonido y traducir el texto a sonido (text to speech). Se usan el nodo Reachy_speech de creación propia y el launcher gb_dialog_services_soundplay de gb_dialog.
El nodo Reachy_speech publica en el nodo action qué acción se ha pedido por voz.
Figura 7 Esquema de funcionamiento de DialogFlow.
Toda la comunicación hablada se realizará en inglés, pues la detección de frases en ese idioma es mucho más robusta que en español. Las frases para interactuar con Reachy pueden variar ligeramente y aun así se puede interactuar correctamente con él. Por ejemplo, para pedirle que te siga se pueden usar frases como: Follow me, ¿Can you follow me? o Follow a person.
Para la visión se ha usado la cámara web Logitech modelo brio ultra HD pro con una resolución de 4k y con conexión por USB. Se ha utilizado este modelo por ser el más accesible a la hora de realizar el trabajo, pero es sustituible por cualquier otra webcam a color siempre que tenga una resolución mayor o igual a 480 por 640, pues es la resolución utilizada por el programa de captura de imágenes, ya que ofrece suficientes detalles como para poder detectar caras y diferentes objetos usando imágenes que son lo suficientemente ligeras como para que un procesador poco potente pueda realizar la detección en tiempo real sin problemas.
En un principio al usar ROS2 se iba a usar el controlador implementado en ros-drivers, pero tras cambiar de versión se ha usado la implementación oficial de ROS (ROS.org, 2022).
La detección visual se realiza usando dos nodos:
usb_cam camera_publisher , que captura las imágenes de la cámara usando los parámetros adecuados dependiendo de la configuración de y el modelo de la cámara y las publica en el topic /usb_cam/image_raw.
usb_cam camera_subscriber que se suscribe al topic /usb_cam/image_raw para obtener las imágenes de la cámara y al topic /action, en el que el nodo_ Reachy_speech _publica las diferentes acciones que se han comunicado a Reachy de forma verbal. Con esta información el nodo procesa las imágenes de acuerdo a lo que se le ha pedido a Reachy y tras esto envía los mensajes necesarios al controlador de los motores publicando en el topic /motor_msg.
Figura 8 Esquema de comunicación de los topics relacionados con la visión artificial.
De esta forma usb_cam camera_subscriber recibe la información de qué debe hacer, analiza las imágenes y usando un mapa de 9 sectores, con 3 columnas en el eje X y 3 filas en el eje Y, detecta en cual de estos sectores se encuentra el objetivo a seguir y lo comunica usando un mensaje MotorMsg publicado el topic /motor_msg. Este mensaje, que contiene tanto el sector como las coordenadas del objeto a seguir, será leído por el controlador de los motores. Dependiendo del mensaje que reciba desde el diálogo, este nodo podrá realizar diferentes acciones, como:
Para realizar el seguimiento de caras se ha usado la función faceCascade.detectMultiScale de openCV, que proporciona las coordenadas de todas las caras que se detectan en pantalla. Tras esto se realiza un filtrado de los datos para eliminar caras que sean demasiado pequeñas o grandes y así evitar errores, y se elige seguir a la persona que se encuentre más cerca del robot. Si dos personas se encuentran a la misma distancia se sigue a la primera que se ha detectado.
Una vez se tienen las coordenadas de la persona, se saca el sector en el que se encuentra y se publica un mensaje en /motor_msg con la información necesaria.
Figura 9 Visualización de división en sectores y reconocimiento de cara.
Figura 10 Detección de caras antes (izq.) y después del filtrado (der.).
Para realizar el seguimiento de objetos se han usado inicialmente cubos de distintos colores. Para detectarlos se utiliza primero un filtro de color. El color que se filtra es el elegido en el diálogo, que viene en el parámetro data del mensaje ActionMsg. Si no se especifica ningún color, se seguirá al cubo verde.
Tras realizar el filtro de color se detectan los contornos y se filtran para eliminar los que son demasiado pequeños, como errores que se pueden detectar en las sombras, o demasiado grandes como una pared. De esta forma nos quedamos solo con el contorno que es más probable que pertenezca a un cubo, y si hay dos cubos iguales se sigue al que esté más cerca.
Por defecto, se seguirá a una persona si se pide tan solo seguir a algo. Si se activa el "modo seguir cubo" sin especificar un color se seguirá al cubo verde. Tras esto, si se pide, por ejemplo, seguir al cubo rojo, seguir a una persona, y finalmente seguir a un cubo sin especificar el color, se seguirá al último color que se haya pedido, en este caso al cubo rojo.
En caso usar el "modo de seguimiento", si Reachy no encuentra ningún objetivo girará la cabeza buscando un objetivo, si tras esto no se detecta ningún objeto o persona a quien seguir, se "apagará", colocándose en posición de reposo hasta que alguien interactúe con él de nuevo.
Figura 11 Imagen con cubo amarillo detectado (izq.) y filtro de color(der.).
Figura 12 Imagen con cubo azul detectado (izq.) y filtro de color(der.).
Figura 13 Video demostración del filtro de color
( https://www.youtube.com/watch?v=KngwEZfFcAk ).
Una vez conseguida esta aproximación, se ha pasado a usar esferas en vez de cubos, pues debido a su forma son más fáciles de detectar. Para detectar esferas se ha comenzado usando un filtro de color al igual que con los cubos pero se ha cambiado el meto de selección del objeto a seguir. En lugar de elegir el objeto más grande dentro de ciertos límites se ha seleccionado el objeto con más probabilidades de ser un círculo (pues la cámara sólo funciona en dos dimensiones) dentro de los objetos del color seleccionado que se han detectado.
Para detectar los círculos en una imagen se usará la función HoughCircles() de openCv, que detecta todos los posibles circules de una imagen que se le pasa como parámetro.
Figura 14 detección de círculos en fotograma sin procesar.
La selección de color se ha realizado aplicando una máscara de color a la imagen que se le pasa a la función HoughCircles() (OpenCV, 2022), de forma que recibe una imagen con un fondo negro en la que solo los elementos del color seleccionado aparece en escala de grises.
Figura 15 detección de círculos sin contexto.
Tras realizar pruebas se ha llegado a la conclusión de que este método no es efectivo, pues al detectar los círculos la función necesita contexto para ver la forma completa de cada objeto en contraste con las que le rodean, por lo que se ha procesado la imagen para obtener un margen alrededor de cada objeto. Este procesamiento utiliza un algoritmo
De esta forma el algoritmo de detección de esferas sigue los siguientes pasos:
- Se transforma la imagen del espacio de color RGB (Red, Green, Blue) a HSV ( Hue, saturation, Value), al realizar este cambios cada píxel de la imagen pasa de tener 3 valores que indican la intensidad de los colores rojo verde y azul a tener 3 valores que marcan el tono, la saturación y el valor. Este cambio facilita el procesamiento de la imagen al ordenador.
Figura 16 Espacio de color RGB (izq.) y HSV (der.).
- Tras esto, se le aplica un filtro la imagen, obteniendo una nueva imagen en el que los objetos del color deseado aparecen representados en blanco y el resto de imagen es un fondo negro.
Figura 17 Imagen tras el filtro de color.
- Una vez obtenida la imagen en blanco y negro, se modifica detectando cada píxel blanco y seleccionando los 25 pixeles que le rodean, creando así un área a su alrededor y eliminando errores de ruido dentro del objeto que puedan aparecer por diferencias en la iluminación.
Figura 18 Imagen con áreas agrandadas
- En cuarto lugar se crea una copia de la imagen original en escala de grises, y se le aplica como máscara la imagen anterior, de esta se obtendrá una nueva imagen en la que los objetos del color seleccionado y sus alrededores se verán en escala de grises mientras que el resto de la imagen será un fondo negro.
Figura 19 Imagen en escala de grises una vez aplicada la máscara.
- Una vez obtenida esta imagen, se le pasará a la función Houghcircles() de OpenCV, que detectará los círculos en la imagen y obtendrá una lista con las coordenadas y el radio de cada uno.
Figura 20 Detección de círculos en la imagen procesada (izq.) e imagen usada por Houghcircles() (der.).
- Por último, se observa esa lista y, si se han detectado varias esferas o círculos se selecciona el que más confianza tenga.
Figura 21 video demostración de seguimiento de esferas
( https://youtu.be/ctNB9VVMps4 ).
Para permitir que el robot se mueva se han usado dos tipos de motores: dos servomotores Dynamixel AX18-A (análogo al modelo AX12 de la misma compañía, pero más moderno) para el movimiento del cuello, y dos Dynamixel XL-320 para el movimiento de las antenas.
Figura 22 Dynamixel AX18 (izq.) y XL-320 (der.).
Estos servomotores funcionan usando 3 pines: Voltaje, tierra y un pin de datos, que usa una comunicación asíncrona Duplex Serial, por lo que será necesario un controlador externo para traducir los datos. En este caso se ha usado el adaptador U2D2 y su set de PCB, junto con una fuente de alimentación de 12 voltios y 5 amperios.
Para controlar los motores usando ROS se ha usado la implementación de Dynamixel (ROS.org, 2022) y un programa que se encuentra en dynamixel_sdk_examplesmotor_controller que se suscribe al topic /motor_msg. De esta forma el programa lee los mensajes del topic que le dicen dónde debe moverse, sin importar si está siguiendo a una persona o a un cubo.
Se ha usado además la aplicación Dynamixel Wizard 2.0 para configurar el identificador y la velocidad de movimiento de los motores, limitándola a 200 revoluciones por minuto para evitar que el exceso de velocidad dañe el cuello del robot debido a la inercia producida por el peso de la cabeza.
Figura 23 Interfaz de la aplicación Dynamixel Wizard 2.0.
Para mover los motores se debe lanzar dynamixel_sdk_examples read_write_node, quelee lo publicado en el topic /set_position y mueve los motores de forma acorde. Este mensaje debe contener:
- El ID del motor, en este caso 1 para el motor del eje X y 2 para el motor del eje Y
- La posición del motor, un numero ente 0 y 1000 que indica al motor en que posición colocarse, por defecto ambos se encuentran en la posición 500.
Este programa también permite usar el servicio get_position (ID) que nos da la posición del motor con el ID especificado.
Para el seguimiento, el programa toma la posición actual de ambos motores. Si el objetivo está a su derecha o a su izquierda (sectores 1 y 3 en el eje X) se publican posiciones que cambian gradualmente en el motor con ID 1 hasta que el objetivo esté en el sector central. De forma similar, si el objetivo está en los sectores 1 o 3 del eje Y, se publican posiciones para el motor con ID 2 hasta centrarlo.
Para el resto de las acciones se comprueba el campo motor_action y dependiendo del mensaje se toman diferentes acciones. Por ejemplo, si la acción es negar se mueve el motor con ID 1 hacia un lado y hacia el otro para simular que está negando con la cabeza, si el mensaje es asentir se mueve el motor con ID 2 hacia arriba y hacia abajo.
Figura 24 Prototipo de la cabeza para probar el seguimiento.
Figura 25 Video demostración de movimiento.
( https://www.youtube.com/watch?v=5C3LvWXiNrA )
Tras implementar este movimiento se ha modificado para conseguir que sea más fluido, añadiendo en primera instancia un sistema que en lugar de usar sectores fijos calcula la distancia entre el objeto a seguir y el centro de la imagen para moverla cabeza más o menos en función de esta, de esta forma utiliza "pasos" de distintas longitudes, por ejemplo, suponiendo que Reachy se encuentra en su posición por defecto mirando hacia el frente (con ambos motores en la posición 500), si el objeto se encuentra cerca del centro de la imagen, se moverá el motor de la posición 500 a la 515, si el objeto detectado se encuentra en el borde dela imagen, se moverá de la posición 500 a la 550, evitando así dar varios "pasos" cortos hasta llegar a la posición.
Figura 26 Movimiento con pasos
( https://www.youtube.com/watch?v=kKibM0StSPY )
Se ha implementado por último un controlador proporcional derivativo (PD) (Item glossar, 2020) para obtener un movimiento más fluido. Este tipo de controladores forman parte de los sistemas de control de bucle cerrado y está formado por dos elementos: P y D.
D es el componente diferencial que responde a la velocidad en la que el error de control cambia, su valor es multiplicado por el coeficiente de acción-derivada KD y sumado al componente P que actúa proporcionalmente al error. En el caso de Reachy, el error sería la distancia entre el objeto buscado y el centro de la imagen.
Figura 27 Sistema de control PD. (carakenio73)
Figura 28 Movimiento de Reachy usando PD
( https://www.youtube.com/watch?v=hdlo5-FL8v4 )
Al contrario que los motores del cuello que usan 12 voltios, los servomotores de las antenas requieren solo 7, por lo que se ha intentado de diversas formas adaptar el controlador de los motores para poder usar ambos modelos.
Desgraciadamente, tras intentar usar un regulador de voltaje, una resistencia variable y un circuito divisor de tensión, no se ha conseguido mover los motores de las antenas, por lo que se han sustituido por motores Dynamixel AX12. Debido al mayor tamaño de estos motores respecto a los XL-320, se ha tenido que modificar la cabeza de Reachy para hacer posible la sujeción de estos motores y el movimiento de las antenas.
Figura 29 Demostracion de movimiento de las antenas
( https://www.youtube.com/watch?v=5C3LvWXiNrA&t=25s )
A pesar de partir de la base del modelo de Reachy creado por Pollen robotics (Lapeyre), ha sido necesario realizar modificaciones debido a la simplificación del proyecto.
Para la impresión 3D de las piezas se ha usado la impresora modelo Sigma D25 de la empresa BCN3D y un desarrollo en espiral. Este desarrollo consiste, en este caso, en imprimir piezas pequeñas para comprobar que encajan, y tras esto ir modificándolas si fuera necesario para imprimir piezas cada vez más grandes una vez es seguro que las tolerancias son correctas. Se han producido varias iteraciones de cada pieza, pero solo se han incluido en el documento las finales.
Figura 30 Impresora 3D Sigma D25.
Figura 31 Pieza completa (izq.) y primera parte impresa (der.).
Para la modificación de piezas o creación de piezas nuevas se han usado los programas Blender y FreeCAD, ambos gratuitos. Las piezas que se han impreso para este proyecto se pueden dividir en:
En este caso, en vez de usar imanes y rodamientos para unir las antenas a la cabeza se usará una pieza modelada en 3D que cree una conexión fija entre los motores y la pieza que sujeta la antena.
Figura 32 Primeras iteraciones de la pieza (izq.) y pieza que sujeta la antena (der.).
También ha sido necesario modificar la interfaz que une el motor a la antena para adaptarlo a los motores AX-12.
Figura 33 Interfaz motor-antena final.
La cara original de Reachy está creada para sujetar dos cámaras que actúan de ojos, los motores de las antenas y un sistema de procesamiento. En este caso se ha usado una sola cámara, por lo que se ha modificado la parte frontal de la cabeza para usar la webcam adecuada.
Figura 34 Diferentes prototipos de la cara de Reachy.
Tras modificar la parte frontal, se ha optado por un diseño parecido al original de Reachy pero cambiando el tamaño y la posición de los ojos para adatarlo al hardware usado y a la forma de sujeción, se ha retocado también el interior para eliminar los soportes para cámaras existentes, y se ha añadido un soporte para la cámara web usada.
Figura 35 Parte posterior de la cara modificada para el uso de una sola cámara.
Figura 36 Parte delantera de la cabeza de Reachy impresa en 3D.
Se ha modificado también la parte trasera de la cabeza para usar los motores Dynamixel AX-12, eliminando los soportes de los motores, pues los Dynamixel AX12 pueden atornillarse directamente a la pieza. Se han modificado a su vez los agujeros de las antenas y los soportes de estas para permitir el movimiento tras haber cambiado la posición de los motores.
Figura 37 Parte trasera de la cabeza.
Figura 38 Pieza trasera de la cabeza impresa con motores.
El cuello original de Reachy utiliza un mecanismo creado por Pollen robotics llamado Orbita, que usa tres articulaciones y tres motores para dotar a Reachy de un movimiento fluido y expresivo con 3 grados de libertad.
Para simplificar este mecanismo se ha usado un sistema con dos motores y dos articulaciones simples, en la base del cuello se encuentra un motor, que gira de lado a lado, y sobre este se ha montado otro motor que se mueve de arriba abajo y sobre el que se encuentra el resto de la cabeza, permitiendo así que la cabeza de nuestro Reachy simplificado se mueva en dos direcciones., de esta forma es capaz seguir a un objeto que se mueva frente a él.
Figura 39 Orbita joint (izq.) y cuello modificado (der.).
Figura 40 Cuello modificado impreso.
También se ha adaptado el cuello que conecta con la cabeza permitiendo así imprimir en una sola pieza la conexión de los motores a la cabeza.
Figura 41 Conexión modificada (azul) y original (blanco).
Figura 42 Conexión de la cabeza y el cuello modificada impresa.
Tras diseñar todas las piezas, se puede observar en Blender una simulación del robot Reachy, y una vez impresas todas las piezas, el montaje completo del robot.
Figura 43 Estructura de Reachy completa.
Figura 44 Reachy completo
Debido que parte del objetivo de este proyecto era obtener un robot con capacidades parecidas al original usando un presupuesto mucho menor, se han usado distintas piezas y materiales a lo largo del trabajo que han disminuido los costes de forma considerable, desde el cambio del diseño del cuello que permite usar motores más baratos y un sistema de movimiento mucho más simple que utiliza 4 piezas en lugar de las más de 60 del cuello orbita, hasta el modo de sujeción de las antenas usando piezas fijas en lugar de imanes. Así, el prepuesto usando las piezas finales queda de la siguiente forma:
| Componente | Modelo | Precio | Otras opciones |
|---|---|---|---|
| Procesador | Raspberry pi 4 4 gb | 80 € | Desde procesadores específicos como la ASUS Tinker Board hasta un ordenador. |
| Altavoz | Altavoz USB con microfono | 20 € | Cualquier altavoz con entrada de mini Jack o USB. |
| Cámara | Logitech brio ultra HD pro | 375€ | Cualquier webcam con una resolución mayor a 480. |
| Motores | Dynamixel AX18/AX 12 | 135€ * 2 65€ * 2 | Cualquier motor con especificaciones similares y compatible con ROS. |
| Controlador | DYNAMIXEL Starter Set | 120€ | Dependiente de los motores escogidos. |
Respecto a la impresión 3D, en el proyecto se ha usado una impresora modelo Sigma D25 de la empresa BCN3D con un precio de unos 3500€, pero se podría haber usado igualmente cualquier otra impresora con una área de impresión mayor de al menos 20*20*15 centímetros.
Para realizar la implementación de Reachy se han usado dos topics principales que permiten la comunicación entre los 3 procesos más importantes: el diálogo, la visión y el movimiento. Para publicar en esos topics se usan dos mensajes distintos: ActionMsg y MotorMsg.
El nodo principal es Reachy_speech, que usando DialogFlow y el controlador de sonido ubicado engb_dialog_services_soundplay.launch interpreta las ordenes de voz, responde si es necesario y publica un mensaje del tipo ActionMsg en el topic /action. Este mensaje se compone de:
- int64 mode, que determina el comportamiento, seguir persona, seguir cubo, o hablar.
- string action, que se utiliza para especificar ciertas acciones, como negar o asentir con la cabeza, o pensar antes de hablar.
- string data, utilizado para dar información adicional, por ejemplo el color del cubo que se debe seguir.
Para poder detectar objetos y personas se utilizan los nodos camera_publisher y camera_subscriber. El primero toma las imágenes de la cámara y las publica en el topic /usb_cam/image_raw, el segundo se suscribe a este topic y al topic /action. Con la información de los dos topics camera_subscriber procesa la imagen conforme a lo que pide el mensaje de action y publica un mensaje MotorMsg en el topic _/_motor_msg. Este mensaje está formado por:
- int64 x_sector, que indica el sector en el eje x en el que se encuentra el objeto buscado.
- int64 y_sector, que indica el sector en el eje y en el que se encuentra el objeto buscado.
- int64 x, la coordenada en el eje x.
- int64 y, la coordenada en el eje y.
- string motor_action, un campo usando para dar órdenes a los motores fuera del seguimiento. De esta manera Reachy puede asentir, despertarse o alegrarse.
Por último, el nodo motor_controller se suscribe al topic _/_motor_msg y utiliza los servicios set_position y get_position para controlar y calcular la posición de los motores respectivamente. Este nodo lee el mensaje y activa el control de movimiento siguiendo a un objeto o realizando las acciones necesarias dependiendo del campo motor_action del mensaje.
Para poder comprobar el funcionamiento del robot se usarán los launcher de gb_dialog Reachy_launch.launch, que lanza los nodos que controlan todos los comportamientos de Reachy, y gb_dialog_services_soundplay.launch, que permitirá el uso de sonido.
Una vez lanzados los nodos necesarios, los principales comandos usados son:
Hello, que funciona como "botón de encendido", activando a Reachy y moviéndolo a la posición inicial, con ambos motores perpendiculares entre ellos.
Follow the COLOR cube, donde COLOR puede ser green, yellow, blue o red, y activa el modo de seguimiento del cubo del color que se especifique.
Follow me, que activa el modo de seguimiento de una persona.
What time is it?, que hace que Reachy nos diga la hora.
On your left/right, que sirven para ayudar a Reachy en caso de que se pierda. Tras usar este comando, Reachy se moverá hacia el lado correspondiente y seguirá buscando a su objetivo.
Tell me a joke, que hace que Reachy piense en una broma y la cuente.
Tell me a fact, que hace que Reachy cuente un dato interesante.
Goodbye, que "apaga" a Reachy, haciendo que mire hacia abajo imitando que duerme.
I am sad/happy, que hace que Reachy empatice y lo muestre moviendo las antenas.
Existen también otras frases que permiten interactuar con Reachy. Por ejemplo, es capaz de responder a diferentes preguntas como: Where are you?, How are you? o Are you a robot?, a la que responde afirmando o negando con la cabeza.
Tras realizar diversos experimentos variando parámetros como el iluminación, la pronunciación del inglés, o la calidad de conexión a internet se ha llegado a la conclusión de que los factores que más afectan al rendimiento de Reachy son:
- El ruido de fondo, la existencia de otras conversaciones en el entorno puede confundir a Reachy haciendo que no entienda los comandos que le llegan o que se equivoque y ejecute una acción que no se le ha pedido. El ruido blanco como el generado por obras o ventiladores también puede saturar el micrófono y generar interferencias en la comunicación.
- Las deferentes pronunciaciones del ingles afectan a Reachy de forma moderada, gracias al uso de la base de datos de Google es capaz de entender la mayoría de las pronunciaciones.
- La calidad de la iluminación, especialmente dependiente del tono de la luz, usando luz blanca se obtienen mejores resultados que con luces más calidad, pues estas cambian el color percibido por la cámara.
- La calidad de la conexión a internet es el factor más limitante en el uso de Reachy, debido al uso de los servidores de Google una conexión lenta puede llevar a que Reachy reaccione de forma lenta, y una conexión de mala calidad puede hacer que se pierdan los mensajes, haciendo que Reachy no reaccione de forma adecuada a los comandos o que los confunda.
La conclusión que se ha sacado del proyecto es que, a pesar de las dificultades, trabajar con hardware es gratificante. Si bien existen partes complicadas, como que dos motores que se encuentran listados como compatibles con el mismo protocolo de comunicación no funcionen con el mismo controlador porque usan voltajes distintos, vale la pena por ver el código materializarse de forma física.
Elegí este trabajo de fin de grado a pesar de la dificultad por lo mismo que elegí está carrera: la posibilidad de crear un robot desde cero, y a pesar de las dificultades y las concesiones que se han tenido que hacer a lo largo del proyecto, considero que ambas decisiones han sido las correctas.
Este trabajo ha requerido multitud de competencias tanto aprendidas en la carrera como aprendidas por cuenta propia. Han sido necesarios todos los conocimientos de ROS y ROS2 de la asignatura de Arquitectura de computadores para coordinar el comportamiento del robot usando diferentes nodos que tengan un uso claro, así como saber qué versión de ROS usar y cuando cambiar; las habilidades obtenidas en Modelado y simulación de robots y Mecatrónica para poder modificar e imprimir las piezas, sabiendo qué programa usar en cada momento; también ha sido necesaria la asignatura de Visión Artificial para poder procesar las imágenes capturadas por la cámara y detectar los objetivos a seguir. Se han usado también otros muchos conocimientos como los aprendidos en Física para evitar freír los motores o cómo usar una Raspberry, aprendido en Sensores y actuadores.
También he aprendido haciendo este proyecto, que el hardware no es tan fácil como parece, se requiere bastante información para ser capaces de montar un robot que funcione, qué modelos de motor son compatibles con qué controladores, la potencia necesaria para realizar ciertas acciones y cómo estas limitan al resto del robot, o a buscar información y comprobar que no solo sea fiable sino que esté actualizada y funcional con las versiones necesarias de otros
Este trabajo sería fácilmente expandible. Debido al modularidad del proyecto se podría rediseñar el cuello para usar el mecanismo Orbita comprando un solo motor más, sin ser necesario volver a imprimir la cabeza ni modificar los comportamientos de ciertos nodos. Podría ampliarse el robot fabricando uno o dos brazos robóticos que en conjunción con la cámara y el micrófono permitan coger y dejar objetos donde se especifique, o incluso conectar a Reachy a un asistente personal y convertirlo en una especie de secretario que tome notas y ayude en una oficina.
También se podría trabajar en un futuro mejorando el hardware existente, usando dos cámaras distintas para obtener una visión en estéreo y así poder calcular la profundidad o usando una cámara RGBD que utilice sistemas de visión con profundidad para obtener una nube de puntos a la vez que una imagen. Otra opción sería cambiar el procesador a una Jetson nano, lo que permitiría aumentar la capacidad de cómputo y el uso de algoritmos de visión más sofisticados como el reconocimiento de caras individuales, pero aumentaría el presupuesto del proyecto considerablemente.
Figura 45 Proyecto de Reachy de Robotics CoLab
( https://hackaday.io/project/176596-reachy-open-source-humanoid-robot )
Toda la documentación así como el código y las piezas están dispones en https://github.com/Alberto-D/Reachy-TFG .
carakenio73. (s.f.). Controlador PD – Proporcional Diferencial – Sistemas de control. Obtenido de https://dademuch.com/2019/05/22/controlador-pd-proporcional-diferencial-sistemas-de-control/
CEF Marketing XXI. (2022). Asistentes virtuales de voz.
Cristina Gena, C. M. (2018). Sugar, Salt & Pepper -- Humanoid robotics for autism.
DANBER. (2022). Jaco-Master. Obtenido de https://gitlab.com/Jaco-Assistant/Jaco-Master
flynneva. (2022). _ros-drivers / usb_cam._Obtenido de https://github.com/ros-drivers/usb\_cam/tree/ros2
fmrico. (2021). IntelligentRoboticsLabs / gb_dialog. Obtenido de https://github.com/IntelligentRoboticsLabs/gb\_dialog
Fumihide Tanaka, K. I. (2008). Pepper Learns Together with Children: Development of an Educational Application.
Gavin Suddrey, A. J. (2018). Enabling a Pepper Robot to provide Automated and Interactive Tours of a Robotics Laboratory.
Infobae. (1 de julio de 2021). Se suspendió la producción del famoso robot Pepper. Infobae.
Item glossar. (2020). Controlador PD. Obtenido de https://glossar.item24.com/es/indice-de-glosario/articulo/item//controlador-pd-1.html
Lapeyre, M. (s.f.). 2020. Obtenido de https://cad.onshape.com/documents/5a9e7c88f6e1068df540bf7a/w/a0a08cc5a2a1d3ad8b96785c/e/a661d6a7df21bf59ff5454f5
Mena, A. A., González, F. J., & Galván, R. S. (1999). DESARROLLO POR ETAPAS: UNA NUEVA GENERACIÓN DE PROCESOS DE DESARROLLO.
mike-moore-az. (2022). _aws-robotics / lex_ros2._Obtenido de https://github.com/aws-robotics/lex-ros2
OpenCV. (2022). HoughCircles(). Obtenido de https://docs.opencv.org/3.4/dd/d1a/group\_\_imgproc\_\_feature.html#ga47849c3be0d0406ad3ca45db65a25d2d
Revista de robots. (11 de agosto de 2020). ROBOT NAO PARA EMPRESA Y EDUCACIÓN. Revista de robots.
ROS.org. (2022). dynamixel. Obtenido de http://wiki.ros.org/dynamixel
ROS.org. (2022). usb_cam Package Summary. Obtenido de http://wiki.ros.org/usb\_cam
Sungjin Lee, H. N. (2011). Using Prosodic Entrainment to Improve Robot-Assisted Foreign Language Learning in School-Aged Children.
Syamimi Shamsuddina, b. H. (2012). Humanoid Robot NAO Interacting with Autistic Children of ModeratelyImpaired Intelligence to Augment Communication Skills.
1Discover Reachy, a robotic platform based on AI – Reachy by Pollen Robotics, an open-source programmable humanoid robot. (s/f). Pollen-robotics.com. Recuperado el 7 de septiembre de 2022, de https://www.pollen-robotics.com/reachy/
2 About: Nao (robot). (s/f). DBpedia. Recuperado el 12 de abril de 2022, de https://dbpedia.org/page/Nao_(robot)