Teleoperación del robot Pepper con métodos de realidad virtual - Grado en Ingeniería Robótica Trabajo Fin de Grado
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Escuela
Politécnica
Superior
Teleoperación del robot
Pepper con métodos
de realidad virtual
Grado en Ingeniería Robótica
Trabajo Fin de Grado
Autor:
Ángel Rodríguez Quevedo
Tutor/es:
Miguel Ángel Cazorla Quevedo
Francisco Gómez Donoso
Mayo 2021
Teleoperación del robot Pepper con
métodos de realidad virtual
Autor
Ángel Rodríguez Quevedo
Tutor/es
Miguel Ángel Cazorla Quevedo
Departamento de Ciencia de la Computación e Inteligencia Artificial
Francisco Gómez Donoso
Departamento de Ciencia de la Computación e Inteligencia Artificial
Grado en Ingeniería Robótica
Escuela
Politécnica
Superior
ALICANTE, Mayo 2021
Preámbulo
La motivación de este trabajo se basa en el aprendizaje de nuevas técnicas de programación
y del uso de dispositivos tecnológicos, relacionados con la realidad virtual y visión 3D como
es el caso de las gafas de realidad virtual y controladores Oculus Quest 2, y relacionados
con la robótica, en general, como el robot Pepper. También, cabe destacar la importancia de
desarrollar este TFG relacionándolo con la visión artificial ya que es un apartado que tiene
mucho auge y futuro en el mundo de la robótica y que personalmente, me fascina.
De esta forma, la motivación personal para el desarrollo de este trabajo ha sido:
• Profundizar en el uso de ROS.
• Mejorar el nivel del lenguaje de programación Python.
• Aprender a controlar el robot Pepper.
• Emplear técnicas de visión artificial y realidad virtual en el proyecto.
• Aprender y mejorar en el uso de nuevos lenguajes de programación como C#.
• Aprender a programar en Unity.
• Realizar una comunicación entre varias plataformas de manera exitosa.
Concretamente, los objetivos se podrían resumir en los siguientes:
• Integrar y programar diferentes dispositivos para lograr un sistema capaz de ser tele-
operado en el que se comuniquen varias plataformas al mismo tiempo sin problemas
usando:
– Robot Pepper.
– Gafas de realidad virtual y controladores Oculus Quest 2.
• Desarrollar un sistema de teleoperación o pantalla del operador sencilla, intuitiva e
inmersiva que, mediante realidad virtual, permita proporcionar información al usuario.
Agradecimientos Personalmente, este trabajo me ha ayudado a ver el desarrollo que he hecho en el transcurso del grado. Durante este tiempo, se han tenido que afrontar muchos momentos difíciles que, junto con mi familia y amigos más cercanos, se han vencido. En muchas ocasiones, el estado anímico de una persona es vital para el desarrollo de su trabajo y en este aspecto sé que mis seres más queridos han estado para apoyarme y ayudarme a seguir. Es por ello, que les dedico este trabajo. Quiero hacer mención especial a mi familia que han tenido que soportar todos los momentos duros y muchas noches largas para seguir aprendiendo y poder llegar hasta dónde he llegado en el presente. Este apoyo siempre lo tendré presente. De la misma forma, estimo oportuno destacar aquellas personas que me han apoyado desde que era muy pequeño y que actualmente no pueden estar entre nosotros, pero sé que seguirán dándome fuerza y espero que este trabajo les haya enorgullecido. En adición, quiero mencionar a los compañeros de mi grado ya que hemos formado una pequeña familia en la que nos hemos apoyado mutuamente en el transcurso del grado. También, les quiero dedicar este proyecto a mis tutores, Miguel Ángel Cazorla Quevedo y Francisco Gómez Donoso, que gracias a su ayuda, su tiempo y su forma de ser me han apoyado en todo momento y me han ayudado a realizar este proyecto disfrutando y aprendiendo de él y de ellos. Además, gracias a ellos, he podido disfrutar de herramientas, como las gafas de realidad virtual Oculus Quest 2 o el robot Pepper, las cuales no podía haber tenido acceso. Además, se han realizado una serie de experimentos en los que se han ofrecido voluntarios varias personas (Miguel Ángel Cazorla, Gonzalo Ferrando, Carlos Torrá, Iván Torá, Alberto García, Andrés Plaza, Miguel Rodríguez, Alejandra Miralles, Eduardo Torres y Rafael Villar), sin las cuales estas pruebas no se habrían podido cumplir. Les agradezco enormemente a todos, ya que sin ellos, este trabajo no habría sido posible.
Si tú sabes lo que vales,
ve y consigue lo que mereces,
pero tendrás que aguantar los golpes.
Rocky Balboa (Sylvester Stallone).
La razón por la que las personas fracasan realmente
no es porque pusieron sus metas muy altas y no llegaron,
sino porque las pusieron muy bajas y las alcanzaron.
Jordan Belfort.
ix
Índice general
1 Introducción 1
2 Estado del arte 5
3 Objetivos y motivación 11
4 Metodología 13
4.1 Gafas de realidad virtual y controladores Oculus Quest 2 . . . . . . . . . . . 13
4.2 Robot Pepper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Unity/Unity Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6 OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7 PyTorch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.8 TensorFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.9 Keras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.10 CUDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.11 Anaconda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.12 Pipelines de detección de manos . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.12.1 Pipeline I2L-MeshNet: Image-to-Lixel Prediction Network for Accurate
3D Human Pose and Mesh Estimation from a Single RGB Image . . . 19
4.12.2 Pipeline 3D Hand Shape and Pose Estimation from a Single RGB Image 19
4.12.3 Pipeline ColorHandPose3D network . . . . . . . . . . . . . . . . . . . 20
4.13 ARToolKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.14 ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.15 WSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.16 Gazebo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.17 XLaunch/Xming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.18 Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.19 Códigos QR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.20 Choreographe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.21 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.22 Caffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Desarrollo 27
5.1 Aproximación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Gafas de realidad virtual y controladores Oculus Quest 2 . . . . . . . . . . . 29
5.2.1 Primeros pasos y puesta en marcha de las Oculus Quest 2 . . . . . . . 29
xixii Índice general
5.3 Servidor web y ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1 Lectura de imágenes con ImageGrabber.cs . . . . . . . . . . . . . . . . 32
5.4 ROS y el movimiento del robot en Gazebo . . . . . . . . . . . . . . . . . . . . 33
5.4.1 Movimiento del robot en Gazebo . . . . . . . . . . . . . . . . . . . . . 33
5.4.2 Instalación de ROS, Gazebo y Turtlebot en Windows . . . . . . . . . 33
5.4.3 Instalación de ROS, Gazebo y Turtlebot en Ubuntu . . . . . . . . . . 36
5.5 ROS y el movimiento del Turtlebot con los controladores de Oculus Quest 2 . 37
5.6 Unity/Unity Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6.1 Configuración de Unity/Unity Hub y carga de la aplicación . . . . . . 37
5.6.2 Pantalla del operador . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.3 Representación de imágenes tomadas de la cámara del PC en Unity/U-
nity Hub en tiempo real . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6.4 Obtención de la imagen de la cámara del robot . . . . . . . . . . . . . 39
5.6.5 Representación del movimiento del robot Pepper en Unity/Unity Hub
de forma simulada con el teclado . . . . . . . . . . . . . . . . . . . . . 40
5.6.6 Detección de QR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.6.7 Movimiento del robot . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.7 Robot Pepper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.7.1 Instalación de prerrequisitos y paquetes . . . . . . . . . . . . . . . . . 41
5.7.2 Preparación para el manejo físico del robot Pepper . . . . . . . . . . . 43
5.7.3 Instalación de Docker y preparación del entorno . . . . . . . . . . . . 43
5.7.3.1 Pasos para instalar Docker y preparación del entorno para el
manejo del robot Pepper . . . . . . . . . . . . . . . . . . . . 43
5.7.4 Recomendaciones Choreographe . . . . . . . . . . . . . . . . . . . . . 44
5.7.5 Primeras pruebas con el robot Pepper . . . . . . . . . . . . . . . . . . 45
5.7.6 Ejemplo de visualización en RViz . . . . . . . . . . . . . . . . . . . . . 47
5.7.7 Visualización de la cámara del robot Pepper . . . . . . . . . . . . . . . 47
5.7.8 Primeros movimientos del robot Pepper . . . . . . . . . . . . . . . . . 48
5.8 Ejecución de la aplicación en las gafas de realidad virtual . . . . . . . . . . . 48
5.9 Detección facial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Experimentación 55
6.1 Experimentos sobre los tiempos de respuesta de cada proceso . . . . . . . . . 55
6.2 Experimentos en la detección QR . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.1 Detección QR con la cámara del PC . . . . . . . . . . . . . . . . . . . 57
6.2.2 ROS y la detección de los QR en Gazebo . . . . . . . . . . . . . . . . 59
6.2.3 ROS y la detección de los QR con el robot Pepper . . . . . . . . . . . 60
6.3 Experimentos sobre el movimiento del robot . . . . . . . . . . . . . . . . . . . 61
6.3.1 Movimiento del robot Pepper . . . . . . . . . . . . . . . . . . . . . . . 61
6.3.2 Movimiento del robot simulado en Gazebo . . . . . . . . . . . . . . . . 62
6.4 Experimentos relacionados con detección facial . . . . . . . . . . . . . . . . . 67
6.4.1 Detección facial con la cámara del ordenador . . . . . . . . . . . . . . 67
6.4.2 Detección facial con fotografías . . . . . . . . . . . . . . . . . . . . . . 70
7 Conclusiones 73Índice general xiii Bibliografía 75 Lista de Acrónimos y Abreviaturas 79
Índice de figuras
1.1 Descripción de la interacción de los elementos en la teleoperación. Fuente:
(Madueño, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Robot Da Vinci teleoperado. Fuente: (Investors, 2019) . . . . . . . . . . . . . 5
2.2 Representación del sistema inteligente del Instituto de Tecnología de Massa-
chusetts (MIT) en la realidad y virtualmente. Fuente: (Oliver, 2017) . . . . . 6
2.3 Modelo T controlado por el operador con realidad virtual. Fuente: (Polo, 2020) 7
2.4 Robot Tactical Robotic System (TAROS). Fuente: (Kot y Petr, 2018) . . . . 7
2.5 Representación esquemática del contenido de la estación virtual del operador.
Fuente: (Kot y Petr, 2018) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Imagen que verá el operador en la estación virtual. Fuente: (Kot y Petr, 2018) 9
4.1 Gafas de realidad virtual y controladores Oculus Quest 2. Fuente: (Oculus,
2021b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Sensorización del robot Pepper. Fuente: (JAVIERBUHIGAS, 2018) . . . . . . 14
4.3 Pantalla del operador recién abierto el programa Unity/Unity Hub. . . . . . . 15
4.4 Funcionamiento de I2L-MeshNet. Fuente: (mks0601, 2021) . . . . . . . . . . . 19
4.5 Funcionamiento de 3D Hand Shape and Pose Estimation. Fuente: (geliuhao,
2019) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Funcionamiento de ColorHandPose3D network. Fuente: (zimmermc, 2017) . . 20
4.7 Resultados con el pipeline 3D Hand Shape and Pose Estimation from a Single
RGB Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.8 Estructura Publication-Subscription. Fuente: (Sugata y cols., 2017) . . . . . . 22
4.9 Ejemplo de código Quick Response code (QR). . . . . . . . . . . . . . . . . . 24
5.1 Esquema representativo sobre el funcionamiento del proyecto. . . . . . . . . . 27
5.2 Set up del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Baile con el robot en el primer videojuego de first steps. Fuente: (realovirtual,
2019) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 Descripción esquemática de todas las interacciones del servidor web en la apli-
cación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5 Ejemplo de salida de la prueba del movimiento del Turtlebot con las teclas del
teclado en Gazebo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.6 Imagen que refleja lo que aprecia el operador en esta prueba. . . . . . . . . . 38
5.7 Pantalla del operador resultante. . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.8 Panel en el que se aprecia el movimiento del robot en la pantalla del operador. 40
5.9 Salida de la verificación de la instalación. Fuente: (ykoga, 2016a) . . . . . . . 44
5.10 Programa Choreographe con los botones de vida (marcado en rojo) y desper-
tarse (marcado en azul). Fuente: (sunzhida, 2017) . . . . . . . . . . . . . . . . 45
xvxvi Índice de figuras
5.11 Salida de los primeros comandos de inicio con el robot Pepper. Fuente: (ykoga,
2016a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.12 Nodos del robot Pepper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.13 Salida de RViz. Fuente: (ykoga, 2016a) . . . . . . . . . . . . . . . . . . . . . . 47
5.14 Salida de la prueba de visualización de la cámara desde el robot Pepper. . . . 48
5.15 Ubicación de Oculus Link en las gafas de realidad virtual. . . . . . . . . . . . 50
5.16 Algunos resultados de la detección facial. . . . . . . . . . . . . . . . . . . . . 51
5.17 Composición del modelo de Caffe empleado durante el entrenamiento y durante
el test. Fuente: (Figueroa Quintero, 2020) . . . . . . . . . . . . . . . . . . . . 53
6.1 Gráfica con los tiempos de ejecución de todos los programas. . . . . . . . . . 56
6.2 Gráfica con los tiempos de ejecución de todos los programas con la modificación. 57
6.3 Tipos de posiciones durante la prueba de detección del QR. . . . . . . . . . . 58
6.4 Mundo de Gazebo con los QR insertados. . . . . . . . . . . . . . . . . . . . . 60
6.5 Diferentes resultados del experimento. . . . . . . . . . . . . . . . . . . . . . . 68
6.6 Diferentes resultados erróneos llamativos del experimento. . . . . . . . . . . . 72Índice de tablas
6.1 Resultados de cada una de las pruebas realizadas en este experimento. . . . . 58
6.2 Resultados de cada una de las pruebas realizadas en este experimento. . . . . 69
6.3 Resultados de cada una de las pruebas realizadas en este experimento. . . . . 71
6.4 Resultados de cada una de las pruebas realizadas en este experimento elimi-
nando las imágenes más conflictivas. . . . . . . . . . . . . . . . . . . . . . . . 71
xvii1 Introducción
Para entender los temas centrales de este proyecto, se ha de definir primeramente la tele-
operación y la realidad virtual.
La teleoperación es un conjunto de tecnologías que comprenden la operación o gobierno a
distancia de un dispositivo por un ser humano. Por tanto, teleoperar es la acción que realiza
un ser humano de operar o gobernar a distancia un dispositivo; mientras que un sistema de
teleoperación será aquel que permita teleoperar un dispositivo, que se denominará dispositivo
teleoperado.
La realidad virtual es una situación o circunstancia que se da cuando un ser humano
tiene la sensación de encontrarse en un lugar distinto de dónde físicamente está gracias a la
información generada exclusivamente por un computador. El entorno que se genera, y en el
que el operador se encuentra inmerso se denomina entorno virtual, y la situación de estar en
él, también se conoce como presencia virtual.
Cabe mencionar que con la unión de ambos nace un nuevo concepto: la telepresencia
que es una situación o circunstancia que se da cuando un ser humano tiene la sensación
de encontrarse físicamente en el lugar remoto. La telepresencia se consigue realimentando
coherentemente al ser humano con suficiente cantidad de información sobre el entorno remoto.
Por tanto, aprovechando tecnologías de realidad virtual como las gafas 3D, se puede man-
tener una situación de telepresencia e interactuar con los elementos de la escena mediante
teleoperación.
Consecuentemente, la teleoperación debería significar que se puede ver de forma remota
a través de los ojos y manipular las extremidades de nuestra robótica sin limitación. Para
lograrlo se emplean unos elementos que son esenciales:
• Sistema maestro: elemento que se encarga de controlar el proceso haciendo uso de
diferentes tecnologías de comunicación para enviar la información al sistema esclavo, es
decir, se trataría del operador humano situado en el entorno o zona local controlando
el proceso.
• Sistema esclavo: elemento que se encarga de recibir la información desde el sistema
maestro gracias a los elementos de procesamiento de los que dispone. Se sitúa en el
entorno o zona remota y dispone de una realimentación local para aportar cierta auto-
nomía en el momento de llevar a cabo la tarea.
• Barreras: elemento que separa ambos entornos o zonas, remoto y local, debido a am-
bientes peligrosos, escalas muy grandes o pequeñas, distancia o que el usuario no pueda
alcanzar o interactuar directamente con el entorno. Son la principal causa del empleo
de la teleoperación.
Estos tres elementos interactúan entre sí en la teleoperación. Esto se puede observar en la
Figura 1.1.
12 Introducción
Figura 1.1: Descripción de la interacción de los elementos en la teleoperación. Fuente: (Madueño,
2013)
En este sentido, la teleoperación es el control electrónico remoto de una máquina y junto a
la capacidad First Person View (FPV) se espera que juegue un papel importante en el futuro
de la automatización y el control tecnológico.
La capacidad FPV permite al operador, colocándose un casco de realidad virtual previa-
mente, asumir el control de una máquina, viendo con los ”ojos” y manipulando las ”extremi-
dades”. Las ventajas tienen implicaciones en numerosas aplicaciones, ya sea entrenamiento y
despliegue militar, minería e inspección industrial o desempeño laboral repetitivo. En lugar de
enviar humanos a entornos hostiles, inaccesibles o peligrosos, se podrá enviar robots, mientras
el operador permanece a una distancia segura. Básicamente, la capacidad FPV permite el
despliegue de una máquina en circunstancias fuera del alcance de la línea de visión humana.
Por ello, el uso de la realidad virtual en la teleoperación hace que se disponga de un sistema
inmersivo, realista e intuitivo para que al operador le resulte sencillo enviar las órdenes y
controlar al esclavo simulando que dicha persona se encuentre en el entorno del esclavo.
En consecuencia, la finalidad de este proyecto es la de poder disponer de un sistema inmer-
sivo, interactivo e intuitivo (pantalla del operador) que la persona pueda manejar de forma
sencilla, sin complicaciones, con la misión de controlar el robot Pepper que estará situado en
otro lugar distante al operador (entorno remoto) y así poder llevar a cabo tareas sin necesidad
de que este se localice en el mismo lugar que el robot. Además, Pepper puede reconocer QR
para realizar una cierta actividad en dicha zona remota.
De esta forma, el usuario podrá realizar tareas desde cualquier sitio pudiendo observar lo
que ve el robot y moviéndose como lo haría si él estuviera en el lugar del Pepper. Así, se
evitan los posibles problemas causados por las barreras por las que se impone la teleoperación
(entornos peligrosos, distancia, escalas grandes o pequeñas...) y, además, el operador puede
tener una visión mucho más realista que la que podría obtener sin el uso de las gafas de
realidad virtual ya que se le sitúa en un entorno inmersivo e intuitivo en el que se puede
teleoperar el robot disponiendo de una mayor concentración en la tarea y sabiendo en cada
momento lo que se puede realizar.
Concluyendo, en el Capítulo 2 se explicarán varios ejemplos de proyectos con objetivos
similares a este trabajo. En el Capítulo 3, se presentarán cada uno de los objetivos propuestos
y alcanzados. Luego, en el Capítulo 4, se trata la metodología empleada con cada uno de
los materiales usados para llevar a cabo el proyecto. Posteriormente, en el Capítulo 5, se
expone la forma de usar cada una de las herramientas expuestas en la sección previa y se
explica el proyecto de forma detallada. Más tarde, en el Capítulo 6, se añaden cada uno de los
experimentos y pruebas realizadas para completar el trabajo de forma exitosa. Seguidamente,3 en el Capítulo 7, se introducirán una serie de conclusiones sobre el trabajo y se plantearán algunas ideas de futuro que se han pensado llevar a cabo teniendo en cuenta el estado final del proyecto. Para finalizar, se mostrará la bibliografía con los enlaces empleados como ayuda para completar el trabajo.
2 Estado del arte
Actualmente, los robots son entidades que se utilizan cada vez más, tanto para ampliar
los sentidos humanos como para realizar tareas particulares que implican repetición, mani-
pulación, precisión. En el primer caso, la amplia gama de sensores disponibles actualmente
permite que un robot recopile varios tipos de datos ambientales. Dependiendo de la aplica-
ción, dichos datos se pueden procesar internamente para lograr una autonomía completa o,
en caso de que se requiera una intervención humana, los datos observados se pueden analizar
fuera de línea (robots para imágenes médicas) o en tiempo real (robots para manipulaciones
quirúrgicas como el robot Da Vinci, de la Figura 2.1). Una característica interesante de los
robots con acceso en tiempo real es la gestión remota por parte de los operadores lo que
lleva al concepto de telerobótica. Este es el caso cuando se deben explorar sitios inaccesibles
o peligrosos, para evitar situaciones que pongan en peligro la vida de los seres humanos (si-
tios subterráneos, submarinos o espaciales, edificios con temperatura o concentración de gas
excesivas). Además, si se consideran los enfoques cognitivos para el diseño de una interfaz in-
teligente entre hombres y máquinas, se le aporta un realismo mayor al operador que controla
al robot.
Figura 2.1: Robot Da Vinci teleoperado. Fuente: (Investors, 2019)
Cualquier tarea de teleoperación es más efectiva cuando se logra un grado aceptable de
inmersión. En caso contrario, los operadores tienen una percepción distorsionada del mundo
distante, comprometiendo potencialmente la tarea con artefactos. La investigación se ha cen-
trado en hacer que la teleoperación evolucione hacia la telepresencia, donde el usuario ya no
es consciente del entorno local y se proyecta por completo en la ubicación lejana. Para que
esta proyección sea factible, la inmersión es la característica clave.
En resonancia, existen multitud de proyectos e investigaciones que incluyen la realidad
virtual en la teleoperación de robots. Algunos de ellos se describirán a continuación, ya que
56 Estado del arte
comparten objetivos con este trabajo.
Primeramente, los investigadores del Computer Science and Artificial Intelligence Lab
(CSAIL) del MIT, utilizando uno de los robots Baxter de Rethink Robotics, un dispositivo
Virtual Reality (VR) y, seguramente, también el clásico Mobile Suit Gundam Wing, crearon
un inteligente sistema de sensor display montado en la cabeza que coloca a los operadores
humanos en la cabeza del robot que están controlando.
El sistema inteligente del MIT integra al usuario en una sala de control de realidad virtual
con múltiples pantallas de sensores, lo que permite al usuario ver todo lo que el robot está
viendo en un momento dado, como se puede observar en la Figura 2.2.
Figura 2.2: Representación del sistema inteligente del MIT en la realidad y virtualmente. Fuente:
(Oliver, 2017)
Para ejecutar tareas, el humano emplea gestos, recogidos a través de unos controles manua-
les, que son reflejados por el robot. Los controles accesibles por el usuario humano aparecen
virtualmente, en lugar de ser controles físicos. Esto permite cambiar dependiendo de lo que
el robot tiene que llevar a cabo en un momento dado.
El trabajo que se ha realizado es muy parecido al ejemplo anteriormente mencionado.
Sin embargo, la pantalla del operador del anterior dispone de demasiada información para
controlar el robot. De esta manera, el usuario puede confundir los controles y necesita tiempo
para acostumbrarse a ellos y poder realizar la teleoperación adecuadamente. En el trabajo
hecho, la pantalla del operador muestra la información relevante únicamente y la manera de
controlar el robot es muy sencilla.
En segundo lugar, la empresa japonesa Telexistence, desde septiembre de 2020, ha co-
menzado a probar en tiendas de conveniencia un robot apilador de estantes que puede ser
controlado por un humano a través de la realidad virtual.7
Este robot, el Modelo T (Figura 2.3), usa dos brazos articulados y manos complejas para
poder coger artículos de diversos tamaños, pero no tiene ningún tipo de inteligencia, está
controlado directamente por un ser humano mediante una configuración de realidad virtual
estándar desde cualquier lugar del mundo que tenga conexión a Internet.
Figura 2.3: Modelo T controlado por el operador con realidad virtual. Fuente: (Polo, 2020)
Las articulaciones del robot tienen 22 grados de libertad, y la conexión de vídeo entre el
robot y el operador humano tiene una latencia de 50 milisegundos, lo que significa que desde
que el usuario realiza una acción hasta que el robot la imita, el tiempo es prácticamente
imperceptible. No obstante, tiene un problema fundamental: el ritmo de trabajo, ya que la
precisión y la velocidad se han de seguir trabajando e investigando en busca de una mejoría.
Esto no ocurre en el proyecto que se ha realizado debido a que se puede controlar el robot
Pepper a una velocidad buena sin perder un buen ritmo de trabajo.
Por último, se encuentra TAROS (Figura 2.4) que es un sistema móvil robótico no tripula-
do desarrollado en cooperación con universidades checas en el marco del Centro de Robótica
Avanzada de Campo. El robot fue diseñado para combate y apoyo logístico de fuerzas meca-
nizadas, de reconocimiento y especiales en un entorno operativo complejo y arriesgado.
El robot se puede adaptar modularmente a los requisitos reales de la unidad militar y
uno de los módulos básicos tiene un brazo manipulador con cinco grados de libertad y pinza
universal y contiene cámaras montadas cerca de la pinza. Además, el operador controla el
brazo mediante el sistema de control avanzado con realidad virtual.
Figura 2.4: Robot TAROS. Fuente: (Kot y Petr, 2018)8 Estado del arte
La interfaz gráfica del sistema de control está diseñada como una innovadora estación de
operador virtual. El sistema se ejecuta en una estación de operador física y el usuario lleva un
dispositivo de visualización montado en la cabeza (Head-Mounted Display (HMD)), Oculus
Rift, que crea la impresión de estar en un espacio virtual, la estación del operador virtual,
representada por el sistema de control.
Todo ello, permite crear una estación del operador mejor de lo que sería físicamente, en
especial, en condiciones de campo. Dicha estación podría contener una o varias pantallas pla-
nas pequeñas, pudiendo constar de varias pantallas muy grandes e incluso mostrar imágenes
de estereovisión.
El contenido de la estación del operador virtual es observado por el operador desde dos
cámaras virtuales ubicadas en el espacio 3D. Estas dos cámaras no corresponden a ninguna
cámara física real del robot, sus parámetros ópticos están configurados exactamente para los
requisitos de Oculus Rift y su rotación. También, se ve afectado por los movimientos de la
cabeza del operador por medio de los sensores de seguimiento Oculus Rift. De esta manera,
el operador puede mirar libremente a su alrededor en el espacio virtual.
La sala virtual (Figuras 2.5 y 2.6) contiene varios planos grandes que simulan monitores de
computadora colocados delante y ligeramente alrededor del operador. Cada pantalla tiene las
imágenes de algunas cámaras físicas asignadas. El plano más grande muestra imágenes de las
cámaras de estereovisión localizadas en el brazo cerca de la pinza. Los planos ligeramente más
pequeños a su alrededor muestran imágenes de la cámara de conducción principal ubicada en
el chasis del robot, imágenes de una cámara de termovisión o cámara de visión nocturna y
otros datos importantes (lecturas de sensores, iconos de estado, iconos de advertencia, etc.).
Los iconos importantes también se pueden representar directamente sobre las imágenes de la
cámara.
Figura 2.5: Representación esquemática del contenido de la estación virtual del operador. Fuente:
(Kot y Petr, 2018)
También, para darle más realismo al sistema de realidad virtual, se representa un pequeño
modelo 3D que refleja la posición real del brazo manipulador del robot real.9
Figura 2.6: Imagen que verá el operador en la estación virtual. Fuente: (Kot y Petr, 2018)
Todo ello, puede provocar que el operario disponga de demasiada información que no le
permita realizar su objetivo si no tiene mucha experiencia con dicha aplicación, como ocurría
en el primer ejemplo expuesto ya que se desea una interfaz clara, intuitiva, sencilla y que
represente únicamente la información que sea de utilidad al usuario como se ha realizado en
el trabajo.3 Objetivos y motivación
La motivación en el desarrollo de este proyecto consiste en la solución a los posibles pro-
blemas que se pueden dar en el trabajo de la persona en algunos lugares o la imposibilidad
de realizarlo ya sea por ambientes peligrosos, escalas muy grandes o pequeñas, distancia o
que el usuario no pueda alcanzar o interactuar directamente con el entorno.
Existen varios casos en los que la distancia es un factor importante. Por ejemplo: en el
campo de la medicina, si hay una operación que la tiene que realizar un cirujano específico
debido a diferentes factores y este cirujano no puede desplazarse al lugar del paciente porque
la urgencia del estado de este es grave y no le da tiempo, la mejor solución sería operar en el
momento con un robot (conocido como Da Vinci), que permite ser controlado por el cirujano
en un lugar distinto al que se está tratando al paciente.
Hay otros casos en los que los entornos peligrosos imposibilitan la realización de la tarea
o la dificultan mucho. Esto se podría solucionar teleoperando un robot como ocurre en la
desactivación de bombas o en situaciones de rescate.
Sin embargo, hay veces que los operarios no pueden tener una sensación de realismo como
si verdaderamente estuvieran en el lugar del robot. Esto impide que se concentren en la
realización de la tarea o que no se sientan tan cómodos como podrían. La solución a ello
consiste en incluir las gafas de realidad virtual en la teleoperación.
Por tanto, para solucionar estos problemas se incluye la teleoperación del robot Pepper, el
cual es controlado por el usuario y como se pretende que el robot sustituya al usuario para
que este pueda realizar la tarea de la forma más realista, intuitiva, simple y eficaz posible,
evitando todas las dificultades previamente mencionadas, se incluyen las gafas de realidad
virtual con sus controladores para manejarlo. De esta manera, se consigue tener un mayor
realismo en la teleoperación y es la forma más idónea para que el operador sienta que en
realidad es él quién está haciendo la tarea y no el robot; así, le da una mayor comodidad y
concentración.
Consecuentemente, los objetivos de este proyecto se pueden resumir en los siguientes:
• Evitar los problemas de distancia, entornos peligrosos, escalas grandes o pequeñas y de
alcance por parte del usuario.
– Solucionado con la teleoperación del robot Pepper.
• Hacer que el operario disponga de una mayor comodidad y realismo en el momento de
realizar la teleoperación.
– Solucionado con la inclusión de las gafas de realidad virtual junto con sus contro-
ladores.
• Integración de un sistema de gafas de realidad virtual con un robot real.
– Logrado usando las gafas de realidad virtual Oculus Quest 2 junto con el robot
Pepper.
114 Metodología
En este proyecto se ha empleado el uso de diferentes elementos, dispositivos, programas,
software… que se describirán brevemente a continuación:
4.1 Gafas de realidad virtual y controladores Oculus Quest 2
El uso de las gafas de realidad virtual Oculus Quest 2 con sus controladores son primordiales
para este proyecto ya que sin ellas los conceptos de inmersión y realidad virtual no se logran
de una forma tan notoria.
Figura 4.1: Gafas de realidad virtual y controladores Oculus Quest 2. Fuente: (Oculus, 2021b)
Estas gafas (Figura 4.1) incorporan un panel único Liquid Cristal Display (LCD) por el que
su portador puede observar la imagen que se desea mostrar, lleva unos altavoces integrados
para obtener un mayor realismo y se pueden conectar al ordenador para cargar aplicaciones
desde este a las propias gafas.
Además, también tienen unas cámaras que permiten captar su entorno y las propias manos
del usuario que sin el uso de los controladores puede disfrutar de la experiencia de realidad
virtual.
Este dispositivo logra la inmersión del operador en el mundo virtual diseñado en Unity, en
este caso, pero también puede lanzar una serie de juegos de forma autónoma de manera que
el usuario disfrute de una experiencia totalmente diferente a los videojuegos de consola o PC.
Con esta experiencia se consigue que el usuario pueda “vivir” los videojuegos como si fueran
reales.
4.2 Robot Pepper
Pepper es un robot humanoide fabricado por SoftBank Robotics de 120 centímetros, pro-
gramable y diseñado para interactuar con personas. Su tecnología le permite detectar tanto el
lenguaje verbal como el no verbal, la posición de la cabeza y el tono de voz, para reconocer el
1314 Metodología
estado emocional e individualizar cada interacción. Esto provoca un sentimiento de empatía
y una conexión entre robot-cliente que favorecen una comunicación eficaz.
A través de sus sensores, cámara en 3D y sus cuatro micrófonos, el humanoide se comu-
nica de forma fluida, presenta movimientos muy flexibles, imitando los gestos humanos, y
se desplaza en cualquier dirección hasta 3 km/h. Acompaña todas sus intervenciones con un
elaborado lenguaje corporal totalmente programable para intensificar sus discursos e inter-
acciones.
En este caso, el robot Pepper tiene una función primordial en el proyecto ya que se va
a simular que el portador de las gafas sea el propio Pepper por lo que sin este humanoide,
el experimento carece de sentido. Se usará la cámara delantera situada en su cabeza para
poder observar lo que está viendo el Pepper en tiempo real. Sin embargo, aunque no se usen
todos ellos en este proyecto, el robot dispone de múltiples sensores, inerciales (acelerómetro
y giroscopio), láseres y sónares para calcular distancias y profundidad; botones en la pantalla
y bumpers; sensores táctiles en la cabeza y las dos manos. Respecto a los actuadores, son las
articulaciones del propio robot (Figura 4.2). Se pueden encontrar más especificaciones en su
documentación oficial: (Softbank Robotiks, 2021b).
Figura 4.2: Sensorización del robot Pepper. Fuente: (JAVIERBUHIGAS, 2018)4.3. Unity/Unity Hub 15
4.3 Unity/Unity Hub
Unity es un motor de desarrollo o motor de juegos. El término motor de videojuego hace
referencia a un software el cual tiene una serie de rutinas de programación que permiten el
diseño, la creación y el funcionamiento de un entorno interactivo.
Unity es una herramienta que permite crear videojuegos para diversas plataformas, median-
te un editor visual y programación vía scripting, y pudiendo conseguir resultados totalmente
profesionales.
A su vez, Unity Hub es una herramienta para la gestión de proyectos Unity. Además, se
pueden gestionar múltiples instalaciones del editor Unity junto con sus componentes, crear
nuevos proyectos y abrir proyectos existentes. La herramienta Unity Hub se puede usar para:
• Administrar la cuenta de Unity y licencias de editor.
• Crear un proyecto, asociar una versión predeterminada del editor Unity con el proyecto
y administrar la instalación de varias versiones del editor.
• Iniciar diferentes versiones de Unity desde la vista de un proyecto.
• Ejecutar dos versiones de Unity al mismo tiempo.
• Añadir componentes a las instalaciones existentes del Editor. Cuando se descarga una
versión del Editor a través de Unity Hub, se puede buscar y agregar componentes adi-
cionales (como compatibilidad con plataformas específicas, Visual Studio, documentos
sin conexión y activos estándar) durante la instalación inicial o después.
Para obtener más información acerca de esta herramienta, se puede acceder a su documen-
tación oficial: (Unity, 2021).
Ambos se han usado en este proyecto para poder generar la pantalla del operador con
la que el usuario interactúa. Esta pantalla, si no se ejecuta ningún programa, inicialmente,
abriendo Unity únicamente, se muestra como aparece en la Figura 4.3.
Figura 4.3: Pantalla del operador recién abierto el programa Unity/Unity Hub.16 Metodología 4.4 C# C# es un lenguaje de programación diseñado por la compañía Microsoft y está orientado a objetos que es una rama de la informática la cual se usan los objetos y las interacciones de estos para diseñar aplicaciones y programas informáticos. Cabe destacar que un objeto en programación es una entidad que combina el estado (datos del objeto), comportamiento o método (define qué operaciones puede hacer el objeto) e identidad (factor diferenciador de los otros objetos). Para disponer de más información acerca de C#, se puede acceder a un blog acerca de la documentación sobre este lenguaje de programación hecho por Microsoft: (Microsoft, 2021). En este lenguaje se han realizado muchos de los programas creados. 4.5 Python Python es un lenguaje de programación interpretado cuya filosofía hace hincapié en la legibilidad de su código. Se trata de un lenguaje de programación multiparadigma, ya que soporta parcialmente la orientación a objetos, programación imperativa y, en menor medida, programación funcional. Es un lenguaje interpretado, dinámico y multiplataforma. Para obtener más información sobre Python, se puede acceder a su documentación oficial: (Python, 2021). En este lenguaje se han realizado algunos de los programas creados. 4.6 OpenCV Open Source Computer Vision (OpenCV) es una librería software open-source de visión artificial y machine learning. Provee una infraestructura para aplicaciones de visión artificial, está escrito en C++, tiene interfaces en C++, C, Python, Java y MATLAB y funciona en Windows, Linux, Android y Mac Os. La librería tiene más de 2500 algoritmos, que incluye algoritmos de machine learning y de visión artificial para usar. Estos algoritmos permiten identificar objetos, caras, clasificar acciones humanas en vídeo, hacer seguimiento de movimientos de objetos, extraer modelos 3D, encontrar imágenes similares, eliminar ojos rojos, seguir el movimiento de los ojos, reconocer escenarios… Para disponer de más información sobre esta herramienta, se puede acceder a su documen- tación oficial: (OpenCV, 2021). Esta biblioteca se ha empleado para la detección de los QR gracias a la cámara delantera del robot Pepper. Además, se ha empleado su uso en la detección de los diferentes pipelines de detección de manos y en la identificación facial. 4.7 PyTorch PyTorch es una biblioteca de aprendizaje automático de código abierto basada en la bi- blioteca de Torch, utilizado para aplicaciones que implementan funcionalidades como visión artificial y procesamiento de lenguaje natural, principalmente desarrollado por el Facebook
4.8. TensorFlow 17
Artificial Intelligence Research (FAIR). Es un software libre y de código abierto liberado bajo
la Licencia Modificada de BSD.
PyTorch proporciona dos características de alto nivel:
• Computación de tensores con una aceleración fuerte a través de unidades de procesa-
mientos gráficos (GPU).
• Redes neuronales profundas construidas en un sistema de Diferenciación Automática
de Bases de Datos.
Para acceder a más información sobre PyTorch, se puede acceder a su documentación
oficial: (PyTorch, 2021).
En este caso, PyTorch se ha empleado en las instalaciones de los pipelines de detección de
manos.
4.8 TensorFlow
TensorFlow es una biblioteca de código abierto para aprendizaje automático a través de un
rango de tareas, y desarrollado por Google para satisfacer sus necesidades de sistemas capaces
de construir y entrenar redes neuronales para detectar y descifrar patrones y correlaciones,
análogos al aprendizaje y razonamiento usados por los humanos.
Para disponer de más información sobre esta herramienta, se puede acceder a su documen-
tación oficial: (Keras, 2021a).
En este caso, TensorFlow se ha empleado en las instalaciones de los pipelines de detección
de manos.
4.9 Keras
Keras es una biblioteca de código abierto (con licencia MIT) escrita en Python. Es una
biblioteca que funciona a nivel de modelo: proporciona bloques modulares sobre los que se
pueden desarrollar modelos complejos de aprendizaje profundo. A diferencia de los frame-
works, este software de código abierto no se utiliza para operaciones sencillas de bajo nivel,
sino que emplea las bibliotecas de los frameworks de aprendizaje automático vinculadas, que
en cierto modo actúan como un motor de backend para Keras. Las capas de la red neuronal
que se quieren configurar se relacionan entre sí de acuerdo con el principio modular, sin que
el usuario de Keras tenga que comprender o controlar directamente el propio backend del
framework elegido.
Para más información sobre Keras, se puede acceder a su documentación oficial: (Keras,
2021b).
En este caso, Keras se ha empleado en las instalaciones de los pipelines de detección de
manos.
4.10 CUDA
Compute Unified Device Architecture (CUDA) hace referencia a una plataforma de compu-
tación en paralelo incluyendo un compilador y un conjunto de herramientas de desarrollo18 Metodología creadas por nVidia que permiten a los programadores usar una variación del lenguaje de programación C para codificar algoritmos en GPU de nVidia. Además, usando wrappers se puede usar Python, Fortran y Java en vez de C o C++. CUDA intenta explotar las ventajas de las GPU frente a las CPU de propósito general utilizando el paralelismo que ofrecen sus múltiples núcleos, que permiten el lanzamiento de un alto número de hilos simultáneos. Por ello, si una aplicación está diseñada utilizando numerosos hilos que realizan tareas independientes (que es lo que hacen las GPU al procesar gráficos), una GPU podrá ofrecer un gran rendimiento. Para obtener más información sobre esta plataforma de computación, se puede acceder a su documentación oficial: (NVIDIA, 2021). En este caso, CUDA se ha empleado en las instalaciones de los pipelines de detección de manos. 4.11 Anaconda Anaconda es un programa de Python que contiene los paquetes más utilizados en temas de ingeniería, matemáticas o ciencia, como pueden ser Matplotlib, SciPy y NumPy. Cuenta con versiones para los tres sistemas operativos más importantes: Mac Os, Windows y Linux. Anaconda funciona como un completo gestor de paquetes que dispone de más de setecientos de ellos en código abierto. Anaconda ofrece una gran cantidad de funciones que permiten desarrollar aplicaciones de una forma sencilla, rápida y eficiente. Es gratis para uso personal y comercial en las versiones de 32 y 64 bits, y se puede instalar junto a otras distribuciones o versiones de Python sin el menor problema. Posee una interfaz gráfica de usuario muy sencilla, pero con un gran potencial. Para más información sobre Anaconda, se puede acceder a su documentación oficial: (Anacon- da, 2021). En este caso, Anaconda se ha empleado en las instalaciones de los pipelines de detección de manos. 4.12 Pipelines de detección de manos En primer lugar, se probó a realizar un pipeline en el que se reconociera la mano para poder interactuar con los objetos virtuales generados por ordenador. Consecuentemente, se pensó en realizar el proyecto en un soporte de Linux e instalando TensorFlow, Keras y Python. Tras varios errores de instalación como el caso en el que se solventó el error No se pudo bloquear /var/lib/dpkg/lock – open (11: Recurso no disponible temporalmente) durante la instalación de Tensorflow, se decidió realizar la instalación mediante entornos virtuales. No obstante, se encontraron otros pipelines mejores que necesitaban otras especificaciones diferentes a las dadas previamente por lo que el trabajo se encaminó en el intento de hacer funcionar dichos pipelines.
4.12. Pipelines de detección de manos 19
4.12.1 Pipeline I2L-MeshNet: Image-to-Lixel Prediction Network for Accurate
3D Human Pose and Mesh Estimation from a Single RGB Image
El primero de ellos se llama I2L-MeshNet: Image-to-Lixel Prediction Network for Accurate
3D Human Pose and Mesh Estimation from a Single RGB Image, que permitía obtener el
modelo 3D del cuerpo de las personas y también el de la manos, como se puede apreciar en
la Figura 4.4.
Figura 4.4: Funcionamiento de I2L-MeshNet. Fuente: (mks0601, 2021)
Sin embargo, no se pudo poner en marcha debido a sus especificaciones: Pytorch, Python
y CUDA. Algunos de los problemas que se solventaron fueron: la compatibilidad de las ver-
siones entre Pytorch, Python y CUDA, la descarga del contextlib2 adecuado para el pip, la
equivocación en la instalación para realizarlo con pip3 en lugar de pip2.
Tras estos errores y al apreciar que no se podía llevarlo a cabo de esta forma, se probó a
instalarlo con entornos virtuales, usando Anaconda y utilizando CUDA con CPU.
Tras observar que no funcionaba de esta forma tampoco y que se necesitaba CUDA con
GPU y consecuentemente Linux de forma nativa, se decidió desechar este pipeline ya que
tras realizar una partición de disco e instalar Linux para disponer de él de forma nativa, no
se obtuvo ningún resultado concluyente.
4.12.2 Pipeline 3D Hand Shape and Pose Estimation from a Single RGB Image
El segundo pipeline encontrado se denomina 3D Hand Shape and Pose Estimation from
a Single RGB Image y permite obtener el modelo y esqueleto de la mano, pero al tener las
mismas especificaciones que el primero no funcionó ya que se tiene que pasar la posición XYZ
del root joint que no se conoce si no se obtiene con una cámara de depth o similar por lo que
también se desechó.
Algunos de los resultados de este pipeline se pueden observar en la Figura 4.520 Metodología
Figura 4.5: Funcionamiento de 3D Hand Shape and Pose Estimation. Fuente: (geliuhao, 2019)
4.12.3 Pipeline ColorHandPose3D network
El último pipeline que se investigó fue el que se desechó por su mala precisión, llamado
ColorHandPose3D network. Este pipeline permitía obtener el esqueleto de la mano como se
puede apreciar en la Figura 4.6
Figura 4.6: Funcionamiento de ColorHandPose3D network. Fuente: (zimmermc, 2017)
Los prerrequisitos para ponerlo en marcha son: Python, TensorFlow (CUDA) y Ubuntu
Xenial. Esta vez al disponer de Linux de forma nativa con la partición, no dio problemas de
instalación aprovechando CUDA con GPU, pero degradando previamente la versión que se
tenía de TensorFlow.
No obstante, tras varios errores como la necesidad de instalar pillow usando entornos
virtuales y Anaconda, se obtuvo el resultado esperado y se pudo observar la mala precisión
de este método.
Los resultados se pueden observar en la Figura 4.7.4.13. ARToolKit 21
Figura 4.7: Resultados con el pipeline 3D Hand Shape and Pose Estimation from a Single RGB
Image.
Como se ha comentado previamente y como se puede apreciar en los diferentes resultados
expuestos con anterioridad, este método no tiene una buena precisión sobre la que apoyarse
para realizar este proyecto.
4.13 ARToolKit
ARToolKit es una biblioteca que permite la creación de aplicaciones de realidad aumentada,
en las que se sobrepone imágenes virtuales al mundo real. Para ello, utiliza las capacidades
de seguimiento de vídeo, con el fin de calcular, en tiempo real, la posición de la cámara y
la orientación relativa a la posición de los marcadores físicos. Una vez que la posición de
la cámara real se sabe, la cámara virtual se pueden colocar en el mismo punto y modelos
3D son sobrepuestos exactamente sobre el marcador real. Así, ARToolKit resuelve dos de
los principales problemas en la realidad aumentada: el seguimiento de punto de vista y la
interacción con el objeto virtual.
Para obtener más información sobre ARToolKit, se puede acceder a su documentación
oficial: (Lab, 2021).
En este caso, se trató de instalar ARToolKit en Linux para obtener un software parecido a
Vuforia en el que se pueda trabajar de forma libre con la realidad virtual y aumentada. Esto
se hizo paralelamente a las pruebas de los pipelines de detección de manos.
Sin embargo, la instalación ocasionó muchos problemas y errores. Algunos se consiguieron
solventar como en el caso de que cuando se hacía un make, saltaba un error que no encontraba
glib.h ya que no había sido instalado correctamente.
No obstante, ocurrieron otros errores que por ser un software desactualizado y anticuado22 Metodología
no se pudo llevar a cabo y hacerlo funcionar por lo que se desechó la idea de trabajar con
este programa.
4.14 ROS
El Robot Operating System (ROS) no es realmente un sistema operativo sino un framework
y un set de herramientas, las cuales proveen la funcionalidad de un sistema operativo en un
grupo heterogéneo de ordenadores.
La característica clave de ROS es la manera en cómo se ejecuta el software y cómo se
comunica, ya que permite diseñar software complejo sin saber cómo funciona cierto hardware.
ROS proporciona una manera de conectar una red de procesos (nodos) con el eje central. Los
nodos se pueden ejecutar en dispositivos múltiples y se conectan a ese eje en varias maneras.
Existen tres formas de comunicación en ROS: mediante topics, servicios o acciones.
En los topics, el nodo publicador (“Publisher”) publica de forma constante los datos que
se desean enviar y el nodo suscriptor (“Subscriber”) recoge esos datos y los utiliza en su
código. En cambio, los servicios, pese a que el funcionamiento es muy similar al de los topics,
tienen una diferencia clave, y es que, cuando envía los datos al suscriptor, necesita que este
le devuelva un resultado como feedback para poder continuar el programa, en otras palabras,
es una estructura síncrona. Por último, las acciones, que son iguales a los servicios, pero
estas son asíncronas, lo que permite enviar los datos y seguir con el programa del publicador
mientras que el suscriptor ejecuta el suyo y, una vez acabe, enviarle la respuesta al publicador.
Por ello, se selecciona usar los topics en este proyecto porque no se necesita una respuesta
por parte del suscriptor a los datos que se envían desde el publicador. Así, el suscriptor,
posteriormente, procesaría la información y ejecutaría el programa. Además, la opción de
usar los servicios no es válida ya que se desea tener una comunicación en tiempo real y con
los servicios, al tener que esperar la respuesta para seguir ejecutando, son poco prácticos en
este sentido.
De esta forma, en la comunicación mediante topics se podrían distinguir 5 elementos clave
en ROS, como se puede observar en la Figura 4.8:
Figura 4.8: Estructura Publication-Subscription. Fuente: (Sugata y cols., 2017)
• Node (nodo): ejecutable utilizado por ROS para comunicarse con otros nodos.4.15. WSL 23
• Msg (mensaje): archivo de texto simple para especificar la estructura de datos de un
mensaje.
• Topic: bus con nombre en el que los nodos intercambian mensajes, es decir, pueden
publicar mensajes en este bus o canal y pueden suscribirse a este para recibirlos.
• Subscriber (suscriptor): nodo especial que se encarga de recibir los mensajes de un
topic concreto.
• Publisher (publicador): nodo especial que se encarga de enviar los mensajes a un
topic concreto.
Para más información acerca de ROS, se puede acceder a su documentación oficial: (ROS,
2021).
En este caso, ROS se usa para simular el robot Pepper y obtener una representación del
movimiento de este con el uso de Gazebo. Además, se usa también para mover el robot Pepper
en la realidad.
4.15 WSL
Windows Subsystem for Linux (WSL) es una capa de compatibilidad desarrollada por
Microsoft para correr ejecutables de Linux (en formato ELF) nativamente en Windows 10 y
Windows Server 2019.
Para obtener más información sobre WSL, se puede acceder a un blog acerca de la docu-
mentación sobre esta capa de compatibilidad desarrollada por Microsoft: (Microsoft, 2020).
En este caso se ha empleado el uso de WSL para disponer de Linux en Windows y poder
tener tanto Unity como ROS en el mismo sistema operativo.
4.16 Gazebo
Gazebo es un simulador de entornos 3D que posibilita evaluar el comportamiento de un
robot en un mundo virtual. Permite, entre muchas otras opciones, diseñar robots de forma
personalizada, crear mundos virtuales usando sencillas herramientas Computer-Aided Design
(CAD) e importar modelos ya creados.
Además, es posible sincronizarlo con ROS de forma que los robots emulados publiquen la
información de sus sensores en nodos, así como implementar una lógica y un control que dé
órdenes al robot.
Para obtener más información acerca de Gazebo, se puede acceder a su documentación
oficial: (Gazebo, 2021).
En el caso del proyecto, Gazebo se usa como simulador para poder observar cómo se
interactúa con el robot que simula el Pepper y ver sus movimientos.
4.17 XLaunch/Xming
Xming es un servicio de aplicaciones gráficas para Windows. Esto significa que accediendo
de forma remota a un sistema Linux, por ejemplo a través de un cliente SSH, podremosTambién puede leer
