Interfaz inmersiva para misiones robóticas basada en realidad virtual

Texto completo

(1)Elena Peña Tapia. INTERFAZ INMERSIVA PARA MISIONES ROBÓTICAS BASADA EN REALIDAD VIRTUAL. JULIO 2017. TRABAJO FIN DE GRADO PARA LA OBTENCIÓN DEL TÍTULO DE GRADUADO EN INGENIERÍA EN TECNOLOGÍAS INDUSTRIALES. Elena Peña Tapia DIRECTOR DEL TRABAJO FIN DE GRADO:. Antonio Barrientos/ J.J. Roldán.

(2) INTERFAZ INMERSIVA PARA MISIONES ROBÓTICAS BASADA EN REALIDAD VIRTUAL. Elena Peña Tapia Departamento de Automática, Ingenierı́a Electrónica e Informática Industrial Escuela Técnica Superior de Ingenieros Industriales - UPM. Trabajo de Fin de Grado Dirigido por Antonio Barrientos y Juan Jesús Roldán Junio 2017.

(3) ii. ETSII UPM.

(4) Agradecimientos. Es difı́cil decidir por dónde empezar a agradecer a todas las personas que han hecho posible este trabajo, ası́ que me remontaré al inicio de los tiempos. Gracias Mamá, por estar conmigo siempre, por escucharme, ayudarme y velar hasta el final por mis intereses. Gracias Papá y Pedro, por vuestra mamelguez intrı́nseca y apoyo incondicional. Gracias a toda mi familia (abuelos, tı́os, primos...) por ser la mejor familia que uno pudiera pedir. Saltando al terreno de la ETSII, gracias Juanje, máximo exponente del movimiento cotutor-amigo-surcador de deadlines. Siempre ayuda estar con alguien que confı́a más en ti que tú mismo. Gracias Antonio por escuchar siempre a tus alumnos, por tu ejemplo intachable y tus marrones continuos. Gracias a todos los chicos del RobCib por dejarme invadir la sala de reuniones con las gafas: gracias Andrés, por tu casi-cotutorı́a; Mario por tus aportaciones con el brazo (robótico); y todos los demás (Pablo, Silvia, Jorge, David) por vuestras tertulias, vuestras crı́ticas constructivas y por hacerme retomar la costumbre del tupper. Ah!, y gracias Javi, por tus siempre útiles consejillos. Gracias también a todos los buenos profesores que he tenido a lo largo del grado, y a mis amigos, compañeros de clase y compañeros de TFG. No puedo dejar el terreno de la ETSII sin dar las gracias a los únicos, los inigualables DisSolutions. Porque sin ellos la escuela no tendrı́a sentido. No sé si es porque aquı́ todo se magnifica (como en GH), pero habéis marcado un antes y un después de conoceros, ahı́ lo dejo..

(5) “Rien dans la vie n’est à craindre, tout doit être compris. C’est maintenant le moment de comprendre davantage, afin de craindre moins.” Marie Curie (No hay que temer nada en la vida, solo hay que comprender. Ahora es el momento de entender más para poder temer menos.).

(6) Resumen Los avances en tecnologı́as inmersivas han dado lugar a nuevas herramientas de realidad virtual con un inmenso potencial para la mejora de interfaces robóticas. En concreto, se han detectado dos ámbitos en los que el uso de realidad virtual puede resultar especialmente beneficioso. Por un lado, se encuentran las misiones multi-robot, que suponen un gran reto a los operadores en lo referente a carga de trabajo y conciencia de la situación (situational awareness). Los operadores de estas misiones deben ser capaces de recibir los datos de los robots, extraer la información relevante, procesarla, tomar decisiones y generar los comandos adecuados en el menor tiempo posible. En estos casos, es común que lleguen a saturarse o pasen por alto aspectos claves para el desarrollo de la misión. Las interfaces de realidad virtual pueden ayudar en este sentido, dado que su alto nivel de inmersión favorece la asimilación de información del entorno de forma natural, provocando ası́ una mejora de la conciencia de la situación respecto a la experimentada con interfaces convencionales. Por otro lado, el ámbito de la teleoperación de robots con actuadores complejos también supone un nicho interesante para esta tecnologı́a. La realidad virtual posee la capacidad de transportar al operador al espacio de trabajo, le proporciona información sobre las tareas a realizar y le permite comandar los robots de forma intuitiva y precisa. Es por estos motivos que en este trabajo se ha decidido desarrollar y probar dos interfaces de realidad virtual: una interfaz de monitorización de misiones multi-UAV y otra de teleoperación de un brazo robótico manipulador de 6 grados de libertad. En ambos casos se ha seguido la arquitectura del sistema presentado en la figura 1. Los robots funcionan bajo ROS (Robot Operating System), lo que permite su control y toma de datos a través de un ordenador con sistema operativo Linux. Este ordenador se ha conectado a través de sockets TCP/IP a un segundo terminal con Windows, en el que se encuentra el software de diseño de videojuegos Unity y su plugin especı́fico Steam VR, que facilita la conexión con las gafas de realidad virtual HTC Vive..

(7) Figura 1: Arquitectura del sistema. La interfaz de monitorización reproduce el escenario de una serie de misiones de extinción de incendios y seguimiento de intrusos efectuadas en 2016 en la Universidad de Luxemburgo. En las misiones intervienen dos UAVs y un robot terrestre, cuya telemetrı́a y comandos se registraron de forma detallada para su posterior reproducción. La interfaz permite seguir el desarrollo de la misión a través de su conexión con ROS. La información relevante se muestra de forma visual y auditiva (figura 2), con la aparición dinámica de fuegos y enemigos, el movimiento realista de los UAVs y una serie de elementos adicionales que aportan datos sobre el estado de la misión en cada momento. La interfaz incluye un modo denominado predictivo, en el que se integra información extraı́da de una serie de redes neuronales en forma de dos variables: relevancia y riesgo. Este modo trata de realizar funciones que normalmente son ejecutadas por operador, relevando ası́ parte de las tareas y reduciendo la carga de trabajo. Además, se incorpora la herramienta de teletransporte para el movimiento dentro del escenario de la misión. Los efectos de la realidad virtual y la componente predictiva se han medido en un conjunto de experimentos efectuados sobre 24 operadores, comparando la interfaz de realidad virtual (predictiva y no predictiva) con una interfaz convencional (también en modo predictivo y no predictivo). En dichas pruebas, se asignaron 2 interfaces de las 4 posibles a cada operador para la monitorización de 8 misiones distintas, de forma que no se repitie-.

(8) Figura 2: Interfaz de monitorización. ra ningún conjunto interfaz-misión-(orden de uso) en los 24 experimentos. La carga de trabajo y conciencia de situación fueron evaluados mediante cuestionarios SAGAT y NASA-TLX, con un total de 20 preguntas sobre la misión en cada interfaz, más una asignación de nivel de cada una de las 6 variables que determinan la carga de trabajo (exigencia mental, fı́sica y temporal, esfuerzo, rendimiento y frustración). El análisis de los resultados permite afirmar con un nivel de significancia del 95 % que las interfaces de realidad virtual superan a las convencionales en conciencia de la situación, rendimiento y esfuerzo. Además, resultan mejores en el resto de campos, aunque no se puede afirmar que la diferencia sea significativa. Por otra parte, la segunda interfaz permite tanto la monitorización del brazo robótico Kinova Jaco2 (estado de las articulaciones, localización del efector, acciones sobre su entorno...) como el comandado del mismo (mediante el envı́o de metas al efector moviendo una esfera de comandado), figura 3. Además, se ha abordado con éxito la conexión bilateral entre ROS y Unity mediante la herramienta RosBridge, mejorando los códigos existen-.

(9) tes y aportando nuevos tipos de mensajes que se pueden intercambiar. Las primeras pruebas con operadores muestran las cualidades de esta interfaz: la transmisión de información espacial, el sistema de comandado intuitivo y la operación en condiciones de seguridad.. Figura 3: Muestra de la interfaz de comandado. En resumen, el proyecto parte de dos objetivos principales: el desarrollo de una interfaz de monitorización para misiones multi-robot y una interfaz de control para un robot manipulador. En el proceso para alcanzar dichos objetivos se han diseñado escenarios, implementado modelos y creado interacciones en realidad virtual con Unity; desarrollado distintos modos de comunicación entre Unity y ROS; creado un modo de comandado para el brazo robótico en realidad virtual; y diseñado y realizado un conjunto de experimentos y pruebas para la evaluación de las interfaces. Ası́, se ha conseguido aportar al estado del arte con interfaces inmersivas.

(10) de nueva generación fuera del área de la robótica industrial. En la interfaz de monitorización se logran unir componentes multimodales y predictivos, mientras que en la de comandado se consigue una interacción con el robot real más allá del entorno de simulación. Estos avances han abierto una gran cantidad de lı́neas de investigación dentro del grupo, como el desarrollo de interfaces de teleoperación que integren información del entorno obtenida con cámaras 3D, muestren las trayectorias planificadas o muestren el brazo robótico montado sobre un robot móvil. Finalmente, este trabajo se ha llevado a cabo bajo una beca de colaboración en el Departamento de Automática. Los avances realizados han permitido una aportación significativa en tres publicaciones y la participación en eventos como las jornadas de puertas abiertas de la ETSII.. 0.1.. Palabras Clave. Robótica, Interfaz de Operador, Realidad Virtual, Robot Manipulador, Multirobot, Inmersión, Predicción, Carga de Trabajo, Conciencia de la Situación (Situational awareness), Inteligencia Artificial.. 0.2.. Códigos UNESCO. 1203 CIENCIA DE LOS ORDENADORES 1203.04 INTELIGENCIA ARTIFICIAL 1203.09 DISEÑO CON AYUDA DEL ORDENADOR 1203.17 INFORMÁTICA 1203.21 SISTEMAS DE NAVEGACIÓN Y TELEMETRÍA DEL ESPACIO 1203.23 LENGUAJES DE PROGRAMACIÓN 1203.26 SIMULACIÓN 1209 ESTADÍSTICA 1209.03 ANÁLISIS DE DATOS 1209.05 ANALISIS Y DISEÑO DE EXPERIMENTOS. 3311 TECNOLOGÍA DE LA INSTRUMENTACIÓN 3311.15 TÉCNICAS DE MANIPULACIÓN A DISTANCIA.

(11) Abstract. Recent developments in immersive technologies have lead to new virtual reality tools with an extraordinary potential for robotic interface improvement. In particular, there are two fields where the use of virtual reality can be especially beneficial. The first field of interest is multi-robot missions, which provides operators with a great deal of challenges in terms of workload and situational awareness. In these kind of missions, operators must be able to receive data from the robots, extract relevant information, process it correctly, make decisions based on it and generate commands for the robots as soon as possible. Therefore, it is fairly common for them to get overwhelmed or miss important pieces of information. Virtual reality interfaces provide a high level of immersion, which facilitates the comprehension of key facts about the mission. This increases the operator’s situational awareness in a natural, effortless manner. The second field that stands out is robot teleoperation, particularly when complex actuators are involved. Virtual reality is able to immerse an operator into the robot’s workspace, providing information about the tasks and allowing for an intuitive and precise control of the robot’s movements. In light of the above mentioned, this project was targeted towards the design and implementation of two virtual reality interfaces: a monitoring interface for multi-UAV missions, and a teleoperation interface for a 6-degrees-offreedom robotic arm. In both cases, the system architecture followed the diagram shown in figure 4. All robots functioned within a ROS (Robot Operating System) framework, which allowed for their control using a computer with Linux. This computer was connected through TCP/IP sockets to a Windows terminal with Unity and Steam VR, a Unity plugin that enabled connections with an HTC Vive headset. The monitoring interface reproduced the scenario from a series of enemytracking/ fire-extinguishing missions carried out in 2016 at the University of.

(12) Figura 4: System architecture. Luxembourg. These missions involved two UAVs and an UGV, whose telemetry and commands were thoroughly registered for future reproductions. Said interface allowed the user to follow the missions with relevant information shown visually and aurally (figure 5). Fires and enemies appeared dynamically, UAVs moved realistically and there was a series of additional elements that provided relevant information about the mission state at all times. The interface included a predictive mode, which integrated information extracted from neural networks in the form of two variables: risk and relevance. Furthermore, movement within the mission’s scene was allowed through a teleporting mechanism. The effects of virtual reality and the predictive component were measured in a series of experiments involving 24 operators, who compared one virtual reality interface (predictive or not predictive) with a conventional one (predictive or not predictive). In each experiment two interfaces were assigned to each operator for monitoring two of the eight possible missions. Mission and interface assignment was carried out so that no combination interfacemission was repeated for any operator. Situational awareness and operator workload were measured through NASA-TLX and SAGAT questionnaires, with 20 questions about every mission and an evaluation of each of the 6 variables that determine workload (mental, physical and temporal demand, effort, performance and frustration). An analysis of the results concluded.

(13) Figura 5: Monitoring interface. with a level of significance of 95 % that virtual reality interfaces improve conventional ones in terms of situational awareness, performance and effort. Moreover, they show better results in the remaining field, although a significant difference cannot be stated. As for the second interface, it allows both monitoring the Kinova Jaco2 robotic arm (joint state, effector position, actions in its environment....) and teleoperationg it ( sending final effector goals through a commanding sphere) figure 6. Furthermore, a bilateral connection between Unity and ROS has been successfully achieved through the RosBridge tool. Existing codes have been improved, and new types of messages have been added to the package. User trials have shown the advantages of this interface: how spatial information is transmitted, how intuitive the commanding system is and how it allows the operator to work in a perfectly safe environment. In summary, the project was conceived with two main targets: the development of a multi-robot monitoring interface and the development of a teleoperation interface for a robotic manipulator. Throughout the process.

(14) Figura 6: Teleoperation interface. of reaching said objectives, a series of environments have been designed, robot models have been implemented and virtual reality animations and interactions have been created; different modes of Unity-ROS communication have been developed; a virtual reality robot arm commanding method has been found; and a set of experiments and trials have taken place for interface evaluation. This has allowed for a number of contributions to the state of the art away from the beaten path of virtual reality in industrial robotics. The monitoring interface unites multimodal and predictive elements, while the commanding interface enables a real human-robot interaction. This progress has lead to new research lines in the department such as the development of teleoperation interfaces that integrate environmental information obtained through a 3D camera and show the robot’s area of manipulability, or its planned.

(15) trajectories. To conclude, this work has taken place under a fellowship in the Deparment of Automation of ETSII UPM. Throughout the research made for this project, a significant contribution to three papers has been made, and it has allowed participation in events such as the ETSII open day.. 0.3.. Keywords. Robotics, Operator Interface, Virtual Reality, Robotic Manipulator, Multirobot, Immersion, Prediction, Workload, Situational Awareness, Artificial Intelligence.. 0.4.. UNESCO Codes. 1203 COMPUTER SCIENCE 1203.04 ARTIFICIAL INTELLIGENCE 1203.09 COMPUTER-ASSISTED DESIGN 1203.17 INFORMATICS 1203.21 NAVIGATION AND SPACE TELEMETRY SYSTEMS 1203.23 PROGRAMMING LANGUAGES 1203.26 SIMULATION. 1209 STATISTICS 1209.03 DATA ANALYSIS 1209.05 DESIGN AND ANALYSIS OF EXPERIMENTS. 3311 INSTRUMENTATION TECHNOLOGY 3311.15 TELECHIRIC TECHNIQUES.

(16) Índice general 0.1. Palabras Clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 0.2. Códigos UNESCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 0.3. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii 0.4. UNESCO Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Índice de figuras. XVII. Índice de tablas. XXI. 1. Introducción. 1. 1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Marco de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.3.1. Objetivos Generales . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.3.2. Objetivos Especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.4. Estructura de la Memoria . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 2. Estado del arte. 5. 2.1. Estudio de Interfaces para Monitorización y Teleoperación de Robots . .. 5. 2.1.1. Interfaces Convencionales . . . . . . . . . . . . . . . . . . . . . .. 5. 2.1.2. Interfaces Multimodales . . . . . . . . . . . . . . . . . . . . . . .. 8. 2.1.3. Interfaces Adaptativas . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.1.4. Interfaces Inmersivas . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 2.2. Estudio de Recursos para implementación de Realidad Virtual . . . . .. 15. 2.3. Estudio de Recursos de Comandado . . . . . . . . . . . . . . . . . . . .. 17. 2.4. Aportaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18. 3. Herramientas de Desarrollo 3.1. Herramientas Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . .. Elena Peña Tapia. 19 20. xiii.

(17) ÍNDICE GENERAL. 3.1.1. Robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jaco2. 20. . . . . . . . . . . . . . . . . . . . .. 20. 3.1.2. Gafas HTC Vive . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22. 3.2. Herramientas Software . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 3.2.1. ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 3.2.1.1. RosBags . . . . . . . . . . . . . . . . . . . . . . . . . .. 25. 3.2.2. Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 25. 3.2.2.1. Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 3.2.2.2. Plugin de Steam VR . . . . . . . . . . . . . . . . . . . .. 27. 3.3. Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27. 3.1.1.1. Brazo Kinova. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 28. 3.3.2. RosBridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 3.3.1. Nodo Original. 4. Desarrollo. 31. 4.1. Proceso de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31. 4.1.1. Familiarización con herramientas . . . . . . . . . . . . . . . . . .. 31. 4.1.1.1. Teletransporte . . . . . . . . . . . . . . . . . . . . . . .. 31. 4.1.2. Monitorización . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33. 4.1.2.1. Definición de las misiones . . . . . . . . . . . . . . . . .. 33. 4.1.2.2. Creación de la interfaz . . . . . . . . . . . . . . . . . . .. 35. 4.1.2.3. Componente predictiva . . . . . . . . . . . . . . . . . .. 38. 4.1.3. Comandado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42. 4.1.3.1. Interfaz para el Jaco2 . . . . . . . . . . . . . . . . . . .. 43. 4.2. Funcionamiento de las interfaces . . . . . . . . . . . . . . . . . . . . . .. 47. 4.2.1. Monitorización . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 47. 4.2.2. Comandado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 48. 5. Experimentación y Pruebas. 51. 5.1. Monitorización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 51. 5.2. Comandado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 56. 6. Resultados. 59. 6.1. Monitorización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59. 6.1.1. Carga de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . .. 60. 6.1.2. Conciencia de la Situación . . . . . . . . . . . . . . . . . . . . . .. 61. 6.1.3. Evaluación de los usuarios . . . . . . . . . . . . . . . . . . . . . .. 63. 6.2. Comandado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 64. xiv. ETSII UPM.

(18) ÍNDICE GENERAL. 7. Conclusiones y trabajos futuros 7.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. Lı́neas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3. Impacto ambiental, económico y social . . . . . . . . . . . . . . . . . . .. 65 65 66 67. 8. Planificación y presupuesto 8.1. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1. Costes directos . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1.1. Recursos humanos . . . . . . . . . . . . . . . . . . . 8.1.1.2. Recursos materiales . . . . . . . . . . . . . . . . . . 8.1.1.3. Recursos informáticos . . . . . . . . . . . . . . . . . 8.1.2. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3. Coste total del proyecto . . . . . . . . . . . . . . . . . . . . . 8.2. Estructura de Descomposición del Proyecto y Diagrama de GANTT. 69 69 69 70 71 72 72 72 73. . . . . . . . .. . . . . . . . .. Bibliografı́a. 77. Elena Peña Tapia. xv.

(19) ÍNDICE GENERAL. xvi. ETSII UPM.

(20) Índice de figuras 1. 2. 3. 4. 5. 6.. Arquitectura del sistema . . . . . . . Interfaz de monitorización . . . . . . Muestra de la interfaz de comandado System architecture . . . . . . . . . Monitoring interface . . . . . . . . . Teleoperation interface . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. iv v vi ix x xi. Ejemplo de puesto de control con interfaz convencional . . . . . . . . . . Guante de realimentación háptica . . . . . . . . . . . . . . . . . . . . . . Contribución de la predicción a interfaces multirrobot. . . . . . . . . . . Interfaz de realidad virtual para entrenamiento de operarios. Visión global del entorno virtual (izq.) y visión en primera persona (der.). Muestra del uso de la interfaz (abajo) . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Sistema de cirugı́a robotizada con RA y guiado por movimientos de manos 2.6. Gafas de realidad mixta Microsoft Hololens . . . . . . . . . . . . . . . . 2.7. Extremos en sistemas de RV. Izq: sistema con gafas mas base móvil de 6 g.d.l. Dch: entorno “inmersivo” con proyección de vı́deos en las 6 caras del cubo [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6 9 11. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8.. . . . . . . . .. 19 21 22 23 24 25 26 27. 4.1. Capturas del juego desarrollado en RV . . . . . . . . . . . . . . . . . . .. 32. 2.1. 2.2. 2.3. 2.4.. Arquitectura del sistema . . . . . . . . . . . . . . . . . Imagen del Jaco2 . . . . . . . . . . . . . . . . . . . . . Elementos del sistema HTC Vive . . . . . . . . . . . . Ilustración del funcionamiento del sistema lighthouse . Diagrama de los mandos Vive (developer.viveport.com) Diagrama de los elementos básicos de ROS . . . . . . Ejemplos de posibles Assets de Unity . . . . . . . . . . Recordatorio de la arquitectura del sistema . . . . . .. Elena Peña Tapia. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 13 14 15. 16. xvii.

(21) ÍNDICE DE FIGURAS. 4.2. Diferentes mecanismos de teletransporte . . . . . . . . . . . . . . . . . .. 33. 4.3. Teletransporte en la interfaz de monitorización . . . . . . . . . . . . . .. 34. 4.4. Misiones multi-robot llevadas a cabo en Luxemburgo en 2016 y recreadas virtualmente en Madrid en 2017. . . . . . . . . . . . . . . . . . . . . . .. 35. 4.5. Escenario inicial vs real en RV . . . . . . . . . . . . . . . . . . . . . . .. 36. 4.6. Escenario mejorado en RV . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 4.7. Objetos que forman parte de la interfaz . . . . . . . . . . . . . . . . . .. 37. 4.8. Criterios de evaluación para relevancia y riesgo . . . . . . . . . . . . . .. 39. 4.9. Errores de predicción de redes neuronales . . . . . . . . . . . . . . . . .. 40. 4.10. (arriba) Evaluación del operador vs. predicción de la red neuronal (RN). (abajo) Errores de cada RN y medias de cada error. . . . . . . . . . . .. 41. 4.11. Interfaz de RV con componentes predictivos integrados . . . . . . . . . .. 42. 4.12. Ejemplo de utilidad de piezas auxiliares . . . . . . . . . . . . . . . . . .. 44. 4.13. Diferenciación de las 13 piezas del brazo . . . . . . . . . . . . . . . . . .. 45. 4.14. Esquema de comunicaciones del robot con el entorno Unity. . . . . . . .. 45. 4.15. Muestra del escenario final del brazo . . . . . . . . . . . . . . . . . . . .. 46. 4.16. Muestra de los pasos previos 3 y 5. . . . . . . . . . . . . . . . . . . . . .. 47. 4.17. Indicadores en los mandos tras el lanzamiento de la interfaz. . . . . . . .. 48. 5.1. Sujeto llevando a cabo los experimentos . . . . . . . . . . . . . . . . . .. 52. 5.2. NASA-TLX: Muestra del cuestionario utilizado . . . . . . . . . . . . . .. 54. 5.3. SAGAT: Un modelo de cuestionario . . . . . . . . . . . . . . . . . . . .. 55. 5.4. Izquierda, posiciones sucesivas del brazo en Unity. Derecha, evolución vista en Rviz (ROS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 57. 5.5. (1) Posición inicial, envı́o de meta con esfera de comandado.(2) Posición final, se alcanza la esfera de comandado. . . . . . . . . . . . . . . . . . .. 58. 6.1. Diagrama de cajas de las 4 interfaces por separado: IC, ICP, IRV, IRVP. 61. 6.2. Diagrama de cajas de las 4 interfaces en 2 grupos: Convencionales (IC+ICP), Realidad Virtual (IRV+IRVP) . . . . . . . . . . . . . . . . . . . . . . . 61 6.3. Diagrama de cajas de las 4 interfaces por separado (izq.) y los dos bloques de interfaces (der.). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63. 7.1. Ejemplo de cómo quedarı́a el brazo montado sobre el robot Summit . .. 67. 8.1. Costes directos totales . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 70. 8.2. Evolución del coste laboral por hora en el sector industrial, fuente: http://www.ine.es/jaxiT3/Tabla.htm?t=11219. . . . . . . . . . . . . . .. 70. xviii. ETSII UPM.

(22) ÍNDICE DE FIGURAS. 8.3. Coste de recursos humanos . . . . . . . . 8.4. Coste de recursos materiales amortizables 8.5. Coste de recursos materiales consumibles 8.6. Coste de recursos informáticos . . . . . . 8.7. Costes indirectos totales . . . . . . . . . . 8.8. Coste total del proyecto . . . . . . . . . . 8.9. EDP . . . . . . . . . . . . . . . . . . . . . 8.10. Diagrama de GANTT del trabajo . . . . .. Elena Peña Tapia. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 71 71 71 72 72 73 74 75. xix.

(23) ÍNDICE DE FIGURAS. xx. ETSII UPM.

(24) Índice de tablas. 2.1. Problemas asociados a interfaces convencionales . . . . . . . . . . . . . .. 7. 2.2. Problemas asociados a factores humanos en misiones multirrobot . . . .. 8. 2.3. Recopilación de interacciones multimodales . . . . . . . . . . . . . . . .. 10. 2.4. Estudio de gafas de RV . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. 6.1. Resumen de resultados de los experimentos . . . . . . . . . . . . . . . .. 59. 6.2. Comparación de las 4 interfaces (diferencias significativas en negrita). .. 62. 6.3. Resultados SAGAT (diferencias significativas en negrita). . . . . . . . .. 64. Elena Peña Tapia. xxi.

(25) ÍNDICE DE TABLAS. Siglas y Acrónimos API: Application Programming Interface (Interfaz de Programación de Aplicaciones) ANOVA: ANalysis Of VAriance (Análisis de la Varianza) EDP: Estructura de Descomposición del Proyecto GRV: Gravity Referred View (Vista Referenciada con Gravedad) IAI: Interfaz Adaptativa Inteligente IC: Interfaz Convencional ICP: Interfaz Convencional Predictiva IP (dirección): Internet Protocol (Protocolo de Internet) IRV: Interfaz de Realidad Virtual IRV: Interfaz de Realidad Virtual Predictiva HMD: Head Mounted Display (Display en forma de casco) LED: Light-Emitting Diode (Diodo Emisor de Luz) NASA-TLX: NASA Task Load Index (Índice de Carga de Tareas) OMPL: Open Motion Planning Library (Librerı́a Abierta de Planificación de Movimientos) RA: Realidad Aumentada RM: Realidad Mixta RN: Red Neuronal ROS: Robot Operating System (Sistema Operativo de Robots) RV: Realidad Virtual SAGAT: Situational Awareness Global Assessment Technique (Técnica Global de Evaluación de la Conciencia de la Situación) SGI: Silicon Graphics International TCP/IP: Transmission Control Protocol/Internet Protocol (Protocolo de Control de Transmisión por Internet) TFG: Trabajo de Fin de Grado UAV: Unmanned Air Vehicle (Vehı́culo Aéreo No Tripulado) UGV: Unmanned Ground Vehicle (Vehı́culo Terrestre No Tripulado) URDF: Unified Robot Description Format (Formato Unificado de Descripción de Robots) XML: Extensible Markup Language (Lenguaje de Marcas Extensible). xxii. ETSII UPM.

(26) Capı́tulo 1. Introducción 1.1.. Motivación. Los 50 de Fukushima. Con este nombre se conoce a un grupo de trabajadores de la central nuclear de TESCO, en Japón. Cuando un tsunami asoló la costa japonesa en 2011, se produjo el fallo de múltiples reactores, poniendo en peligro la integridad de la zona. A pesar de conocer los elevados niveles de radiación que los rodearı́an, Los 50 de Fukushima se quedaron en la central para intentar mitigar los daños. El grupo se componı́a fundamentalmente de ingenieros y trabajadores cualificados, los únicos con conocimientos para responder ante el desastre. Estas personas decidieron renunciar a sus vidas pero, en la actualidad, no son tratados como héroes. Además de las consecuencias negativas sobre su salud, deben enfrentarse al rechazo y aislamiento social de las poblaciones que rodean la central. En estas situaciones inesperadas y peligrosas, el uso de robots como sustitutos de los operadores humanos presenta una solución ideal, aunque no exenta de retos. A pesar de que gran parte de los robots móviles son semi-autónomos, todavı́a existen entornos y situaciones que requieren la interveción de operadores humanos. Entre otras condiciones, la operación de robots a distancia requiere una interfaz que proporcione la información adecuada en la medida adecuada, que sea intuitiva y que reproduzca de una forma fiel la información obtenida del entorno. En concreto, lograr desarrollar una interfaz user friendly, sencilla, universal y con una curva de aprendizaje reducida presentarı́a enormes ventajas, por la gran cantidad de aplicaciones que se podrı́a extraer de ella. La reciente aparición en el mercado de las gafas de realidad virtual abre un universo de posibilidades para la mejora de estas interfaces, al proporcionar un entorno inmersivo. Elena Peña Tapia. 1.

(27) 1. INTRODUCCIÓN. y rico que ayuda al usuario a comprender mejor la situación real. La intención de este TFG es explorar estas posibilidades, mediante el desarrollo de interfaces que permitan la monitorización y comandado de misiones con uno o más robots de distintos tipos.. 1.2.. Marco de Desarrollo. Este proyecto se ha realizado dentro del departamento de Automática de la Escuela Técnica Superior de Ingenieros Industriales de la UPM. En concreto, dentro del grupo de Robótica y Cibernética (RobCib) del Centro de Automática y Robótica (CAR) formado por la UPM y el CSIC. El TFG se enmarca dentro del proyecto PRIC (Protección Robotizada de Infraestructuras Crı́ticas), financiado por el Ministerio de Economı́a y Competitividad del Gobierno de España. Además, sirve de apoyo a la tesis doctoral ’Multi-UAV Coordination and Control Interface’, que forma parte del proyecto SAVIER (’Situational Awareness VIrtual EnviRonment’) de Airbus Defence & Space, en colaboración con 5 universidades españolas.. 1.3.. Objetivos. Con el fin de organizar el trabajo, se ha procedido a su descomposición en objetivos, que pueden ser de carácter general o especı́fico. A continuación se verá una breve descripción de las metas a cumplir a lo largo del desarrollo del proyecto.. 1.3.1.. Objetivos Generales. Este TFG tiene el objetivo principal de investigar y evaluar las mejoras que puede implicar el uso de interfaces de realidad virtual para el control y monitorización de misiones robóticas. Esto se realizará mediante la creación y prueba de dos interfaces en Unity: 1. Interfaz de monitorización de misiones multi-UAV 2. Interfaz de control de un brazo robótico manipulador. 1.3.2.. Objetivos Especı́ficos. A un nivel más detallado, se pueden establecer los siguientes objetivos especı́ficos: Diseño de escenarios para misiones robóticas en Unity. 2. ETSII UPM.

(28) 1.4 Estructura de la Memoria. Implementación de modelos de robots en Unity Creación de animaciones e interacciones en realidad virtual Manejo de los robots y gestión de su información en el entorno ROS Exploración y desarrollo de comunicaciones entre ROS y Unity Diseño de modos efectivos de visualización de la información Desarrollo de modos de comandado para el brazo robótico manipulador Diseño y realización de experimentos para evaluación de las interfaces. 1.4.. Estructura de la Memoria. La memoria se estructura de la siguiente manera: El capı́tulo 1 corresponde a la introducción. El capı́tulo 2 presenta una recopilación actualizada del estado del arte, en la que se analizan y comparan los avances actuales en el terreno de las interfaces y la realidad virtual, y se extraen los aspectos en los que se pueden mejorar. En el capı́tulo 3 se introducen las herramientas que se han empleado en el trabajo, mostrando sus caracterı́sticas principales y su papel en el sistema general. A continuación, se procede a la explicación en el capı́tulo 4 de los elementos clave que intervienen en el desarrollo de las dos interfaces de este TFG, ası́ como los aspectos relevantes de su funcionamiento. El capı́tulo 5 muestra los experimentos y pruebas efectuados con ambas interfaces, y en el se analizan los resultados de los mismos. Finalmente, en los capı́tulos 6 y 7 se recopilan las conclusiones del trabajo y los aspectos que atañen a su planificación.. Elena Peña Tapia. 3.

(29) 1. INTRODUCCIÓN. 4. ETSII UPM.

(30) Capı́tulo 2. Estado del arte 2.1.. Estudio de Interfaces para Monitorización y Teleoperación de Robots. Las interfaces son uno de los elementos fundamentales de las misiones robóticas, especialmente de las misiones multirrobot. Su influencia abarca los ámbitos de recepción de información y transmisión de comandos. En este capı́tulo se ha realizado un estudio comparativo de interfaces existentes en la literatura actual separándolas en cuatro categorı́as fundamentales: interfaces convencionales (2.1.1), multimodales (2.1.2), adaptativas (2.1.3), e inmersivas (2.1.4). La idea de este estudio es localizar los aspectos más relevantes para el desarrollo de interfaces de monitorización y control de robots, ası́ como las debilidades existentes en interfaces actuales. Ası́, se dispondrá de una cantidad de información suficiente para cumplir el objetivo fundamental de este trabajo, el desarrollo de una interfaz inmersiva con realidad virtual.. 2.1.1.. Interfaces Convencionales. En la actualidad existen numerosos medios de control para la teleoperación de robots, desde dispositivos móviles como tablets o smartphones [2] hasta paneles de control con joysticks, volantes e incluso pedales. Las estaciones de control tı́picas incluyen los siguientes elementos [3]: 1. Información sensorial de los robots 2. Órdenes y comandos mandados a los robots 3. Estado actual de los robots (baterı́a, posibles fallos del sistema...). Elena Peña Tapia. 5.

(31) 2. ESTADO DEL ARTE. 4. Estado actual de las tareas 5. Mapas y elementos para la navegación La imagen 2.1 muestra un ejemplo de interfaz de telecontrol portátil con los 5 elementos mencionados anteriormente. Como se puede observar, estas interfaces pueden llegar a resultar bastante complejas y aparatosas. Además, cabe destacar que el diseño de las interfaces depende del tipo de robot, y en la actualidad es complicado encontrar desarrollos funcionales para múltiples robots heterogéneos.. Figura 2.1: Ejemplo de puesto de control con interfaz convencional. El rendimiento en misiones que requieren el telecontrol de robots suele estar comprometido por una serie de problemas asociados tanto a factores tecnológicos como a factores humanos. En muchos casos, la teleoperación se convierte en una tarea difı́cil, porque el procesamiento de los estı́mulos percibidos se encuentra desacoplado del entorno fı́sico, causando problemas como una percepción incorrecta de la escala misión [4]. Otras dificultades asociadas a factores técnicos se encuentran clasificadas en la tabla 2.1, en la que se muestran las principales tareas afectadas por cada problema y posibles soluciones de acuerdo con [3]. Se puede observar que gran parte de estos problemas se pueden solucionar implementando una interfaz inmersiva en realidad virtual como la propuesta en este trabajo. En el caso concreto de misiones multirrobot, se suele recurrir mayoritariamente a un control por supervisión en lugar de teleoperación. En estos casos, suelen prevalecer los problemas asociados a factores humanos como el exceso de carga de trabajo o la falta de conciencia de la situación (situational awareness) [6], términos que se definirán más adelante en este apartado. La tabla 2.2 muestra una recolección de problemas asociados. 6. ETSII UPM.

(32) 2.1 Estudio de Interfaces para Monitorización y Teleoperación de Robots. Cuadro 2.1: Problemas asociados a interfaces convencionales. Problema. Tareas afectadas. Soluciones propuestas. Campo visual limitado. Detección, guiado. Cámaras 360/ multicámara + interfaz inmersiva. Falta de Orientación. Navegación, guiado. Uso conjunto de mapas fijos y relativos al robot, GRV (vista referenciada con gravedad [5]). Percepción contextual incorrecta. Telemanipulación. Múltiples cámaras y pantallas, visión exocéntrica y egocéntrica. Percepción de profundidad incorrecta. Guiado y telemanipulación. Realidad Virtual. Imagen de vı́deo degradada. Percepción de entorno. Interfaces con elevados fps. Periodo de latencia. Percepción de entorno. Interfaces predictivas. a factores humanos, con sus consecuencias y un posible método de detección. La carga de trabajo se puede definir como la cantidad de trabajo a realizar por un operador en un tiempo determinado, tratada de forma subjetiva desde el punto de vista de la experiencia del operador [7]. Sin embargo, un estudio completo de la carga de trabajo suele tener en cuenta una gran cantidad de factores ( carga de estı́mulos, esfuerzo del operador, rendimiento en la tarea, etc) [8] desde el punto de vista de esfuerzo fı́sico y mental [9]. En tests como el NASA-TLX, se suelen determinar 6 variables relativas a la carga de trabajo: exigencia mental, fı́sica, temporal, esfuerzo, rendimiento y frustración. Por su parte, la conciencia de la situación se puede definir en tres niveles. El primer nivel corresponde a la percepción de elementos del entorno en un contexto espacial y temporal; el segundo nivel corresponde a la comprensión de su significado; y el tercero consiste en ser capaz de proyectar su estado hacia el futuro [10]. Esto quiere decir que los operadores, además de ser conscientes en todo momento de las posiciones de los robots, deben conocer su razón de ser en el contexto de la misión y su potencial de evolución en el futuro. Las consecuencias de niveles inadecuados de carga de trabajo y conciencia de la situación, como se puede ver en la tabla 2.2, son fundamentalmente errores e ineficiencias. El papel de las nuevas interfaces es clave para solucionar estos problemas. Las. Elena Peña Tapia. 7.

(33) 2. ESTADO DEL ARTE. Cuadro 2.2: Problemas asociados a factores humanos en misiones multirrobot. Problema. Consecuencia. Detección. Exceso de carga de trabajo. Ineficiencia errores. y. Examen psicológico. Tests (NASA-TLX). Falta de conciencia de situación. Ineficiencia errores. y. Examen de acciones y rendimiento. Tests (SAGAT). Estrés y ansiedad. Errores. Variables fisiológicas (frecuencia cardiaca, sudoración...). Tests (NASA-TLX). Falta/exceso de confianza. Errores. Estudio de reacciones. Encuesta. posibles mejoras son diversas, desde la selección de la información más relevante en cada momento hasta la adición de nuevos tipos de interacciones, como pueden ser las interacciones multimodales o la realidad virtual.. 2.1.2.. Interfaces Multimodales. El concepto de interacción humano-robot multimodal hace referencia a la ’interacción con el entorno fı́sico y virtual a través de modos de comunicación naturales’ [11], es decir, aquellos que implican los cinco sentidos humanos (vista, oı́do, olfato, gusto y tacto) [12]. En otras palabras, la interacción multimodal permite una comunicación más cómoda con los sistemas automatizados a través de interfaces de usuario. En el ámbito de las interfaces para monitorización y control de uno o más robots, la multimodalidad permite la resolución de algunos de los problemas más habituales que suelen surgir: un campo visual limitado, una percepción de profundidad degradada, problemas de orientación, etc [3]. Las mejoras asociadas a interfaces multimodales tienen lugar a dos niveles. Por un lado, permiten aumentar el rendimiento de los operadores complementando la información visual o dirigiendo la atención del usuario hacia variables clave de la misión. Por ejemplo, la adición de información auditiva produce un aumento de la conciencia de situación en operadores, según [13]. En concreto, la adición de sonidos puede trans-. 8. ETSII UPM.

(34) 2.1 Estudio de Interfaces para Monitorización y Teleoperación de Robots. mitir la localización o la velocidad de los robots, llamar la atención sobre alarmas o destacar eventos de la misión. En entornos ruidosos el uso de interacciones táctiles o hápticas puede relevar la función del audio [14]. La realimentación háptica también puede resultar útil en la teleoperación de robots manipuladores o quirúrgicos, dado que la transmisión de fuerzas ficticias ayuda a mejorar la inmersión y percepción del entorno. En la literatura existen diversas implementaciones de este tipo de interacción, como la mostrada en la figura 2.2 [15].. Figura 2.2: Guante de realimentación háptica. A nivel de comandado, los comandos multimodales como el uso de voz, tacto y gestos se están implementando con la idea de alcanzar interacciones simples, rápidas y naturales entre operadores y robots [16]. Existen numerosos ejemplos de comandado de misiones multi-robot mediante comandos de voz [17], gestos manuales [18], o combinaciones de gestos faciales y de manos [19]. La tabla 2.3 recopila las interacciones multimodales más relevantes de acuerdo con [3], y muestra ejemplos de su implementación presentes en la literatura actual.. 2.1.3.. Interfaces Adaptativas. El objetivo de las interfaces adaptativas es proporcionar la información necesaria para la toma de decisiones dentro del contexto de una misión de forma que la velocidad, precisión, grado de comprensión coordinación y carga de trabajo de los operadores se vea mejorada [38]. Con tal fin, se recurre a la integración de algoritmos de minerı́a de datos y machine learning. Estos algoritmos son capaces de relevar al operador en determinadas tareas, como la detección de información relevante, y de esta manera. Elena Peña Tapia. 9.

(35) 2. ESTADO DEL ARTE. Cuadro 2.3: Recopilación de interacciones multimodales. Interacción. Aporte. Ejemplo (ref.). Uso de audio. Buen complemento de feedback visual, llamada de atención ante alertas, aumenta percepción de entorno y puede reducir carga de trabajo.. [20], [22]. [21],. Feedback táctil. Llamada de atención efectiva, útil para dar información sobre orientación, posición y velocidad, especialmente eficaz en ambientes ruidosos con largos periodos de vigilancia.. [23], [25]. [24],. Input háptico. Útil para proporcionar información sobre fuerzas, ideal para tareas de manipulación.. [26], [27]. Input auditivo + háptico. Más práctico que emplear interacciones de forma independiente. Compendia las ventajas de ambas.. [28], [30]. Comandos de voz. Útil en entornos móviles o cuando las manos del operador se encuentran ocupadas. Se pueden condensar varios comandos en uno. Aligera carga de trabajo.. [31], [32]. Comandos gestuales. Fáciles de usar, gran rango de movimientos en el campo visual de la cámara.. [33], [34]. Comandos gestuales + voz. Gran rango de interacciones naturales. Puede resultar difı́cil de procesar.. [35], [37]. [29],. [36],. dotar al operador de nuevos recursos para la toma de decisiones [39]. Las interfaces adaptativas inteligentes (IAIs) requieren el uso de distintos tipos de modelos para tratar la información de las misones, aplicando los algoritmos mencionados. Estos modelos abarcan desde el comportamiento de los operadores hasta el de los robots, pasando por el tipo de tareas o las interacciones del entorno. Existen en la literatura una serie de directrices que determinan cómo debe ser el diseño de una interfaz adaptativa [40]. Además, también se encuentran determinados los cuatro pasos que rigen el proceso de adaptación: 1. Adquisición de conocimientos (¿Qué está pasando?) 2. Atención (¿Qué adaptación va a ocurrir?) 3. Razonamiento (¿Por qué es necesaria?). 10. ETSII UPM.

(36) 2.1 Estudio de Interfaces para Monitorización y Teleoperación de Robots. 4. Toma de decisiones (¿Cómo va a tener lugar?) En el caso concreto de las misiones multi-robot, ya se ha visto que presentan una serie de retos particulares a los operadores. Sobre todo, destacan los problemas asociados a la carga de trabajo y la conciencia de la situación. La figura 2.3 muestra como un operador, cuando usa una interfaz convencional, debe recibir los datos, extraer la información relevante, tomar decisiones, generar los comandos adecuados y mandarlos a los robots. Una posible solución a este exceso de tareas consiste en delegar parte de las funciones en la propia interfaz.. Figura 2.3: Contribución de la predicción a interfaces multirrobot.. Un trabajo relacionado se puede encontrar en [41], donde se busca proporcionar a los robots habilidades propias de los humanos para percibir, entender y evitar riesgos durante sus misiones. Para ello, el autor estudia la percepción, cognición y reacción tı́pica humana frente a riesgos y desarrolla un marco de trabajo para aplicar estos conceptos a flotas de robots aéreos. La cantidad de datos generados en una misión multi-robot depende del número y complejidad de los robots y las tareas involucradas. Esta información en bruto incluye los estados de los robots (posición, orientación, velocidad, baterı́a...) y las cargas de pago (medidas de los sensores, imágenes de las cámaras, estado de los actuadores...). Cuando el número de datos es excesivo, es posible que los operadores no se vean capaces de procesar toda la información para extraer las partes más relevantes. Por ello, es posible. Elena Peña Tapia. 11.

(37) 2. ESTADO DEL ARTE. que cierta información pase inadvertida, como por ejemplo qué tarea es más crı́tica, qué robot requiere más atención o qué situación lleva asociado un mayor riesgo. Una posible solución a esta cuestión es lograr que la información importante se determine automáticamente a partir de los datos brutos extraı́dos de la misión, generando ası́ una interfaz adaptiva. Por ejemplo, se puede realizar una simplificación del problema, que logra extraer de todas las variables implicadas tres variables fundamentales: tarea, relevancia y riesgo en todo momento [42, 43]. De este modo, el operador solo necesita prestar atención a tres factores, reduciendo ası́ su carga de trabajo.. 2.1.4.. Interfaces Inmersivas. El propósito de las interfaces inmersivas es introducir virtualmente al operador en el escenario de la misión. Con este fin, se emplean múltiples tecnlogı́as como cámaras 3D, gafas de realidad aumentada o gafas de realidad virtual. Mediante una reproducción rica y detallada del escenario, se pretende conseguir una mejora de la conciencia de la situación del operador. Existen tres tipos fundamentales de tecnologı́as inmersivas: la realidad virtual (RV), la realidad aumentada (RA) y la realidad mixta (RM); siendo la última la más reciente y una combinación de las dos anteriores. La realidad virtual muestra escenarios sintetizados digitalmente con elementos interactivos. Las interfaces RV suelen integrar dentro del mundo virtual representaciones de elementos reales como robots, objetivos, trayectorias, amenazas.... El nivel de inmersión ha ido creciendo con la evolución de las tecnologı́as, partiendo de interfaces basadas en pantallas y elementos multimodales ([44],[45], [46], [47], [48], [49], [50] ), hasta llegar a las interfaces que comienzan a emerger usando gafas de realidad virtual ([51],[52]). Las figuras de la imagen 2.4 muestran un ejemplo de interfaz de realidad virtual para entrenamiento de operarios en la programación de robots de manufactura [52]. En el artı́culo de Ruiz et al. [53], se comparan diferentes tipos de displays en el contexto de misiones multi-UAV. Los experimentos demuestran que el uso de gafas de realidad virtual efectivamente mejora el conocimiento espacial de los operadores, aunque esta mejora tiene lugar en detrimento de la cantidad de carga de trabajo, que se ve aumentada. En lo referente a la teleoperación en realidad virtual, cabe destacar el ámbito de la robótica espacial, donde no se contempla la opción de un control de los robots in situ. Ası́, todos los avances en este área dependen de las tecnologı́as de teleoperación, que se enfrentan a importantes retos como la superación de retardos en las comunicaciones [54]. Las interfaces de realidad aumentada superponen sobre imágenes de vı́deo del en-. 12. ETSII UPM.

(38) 2.1 Estudio de Interfaces para Monitorización y Teleoperación de Robots. Figura 2.4: Interfaz de realidad virtual para entrenamiento de operarios. Visión global del entorno virtual (izq.) y visión en primera persona (der.). Muestra del uso de la interfaz (abajo). torno real elementos originados virtualmente. Estos elementos suelen incluir información relevante sobre las misiones en curso: posición en mapas, elevación del terreno, obstáculos en el camino, rutas a seguir u objetivos que se persiguen [55]. La mayor parte de las interfaces de RA desarrolladas se han aplicado a programación de robots manipuladores ([56], [57]) y cirugı́as robotizadas ([58], ver figura 2.5). No obstante, es posible encontrar en la literatura experimentos que muestran el potencial de la realidad aumentada en el contexto de las misiones robóticas. En [59] se utiliza una interfaz de RA para analizar misiones multirrobot; y el experimento de [60] compara el rendimiento de los operadores encontrando objetivos con interfaces convencionales y de RA. Los participantes encontraron un mayor número de objetivos con el segundo tipo de interfaz. Otros trabajos incluyen relieves en 3D, mapas donde aparecen las imágenes de vı́deo captadas por los diferentes robots o interfaces dibujan las trayectorias de los robots ([61],[62]). Finalmente, la realidad mixta combina elementos de RA y RV creando nuevos escenarios donde los usuarios pueden interactuar con objetos tanto reales como virtuales. Hasta la fecha, todavı́a son escasos los ejemplos de uso de realidad mixta en interfaces, existiendo unos pocos casos en el terreno de la programación de robots industriales [63],. Elena Peña Tapia. 13.

(39) 2. ESTADO DEL ARTE. Figura 2.5: Sistema de cirugı́a robotizada con RA y guiado por movimientos de manos. dado que se trata de una evolución natural de la RA. Aún ası́, la RM posee un enorme potencial para aplicaciones en el terreno de la robótica [64], gracias a la aparición de herramientas como las gafas Microsoft Hololens, mostradas en la figura 2.6.. 14. ETSII UPM.

(40) 2.2 Estudio de Recursos para implementación de Realidad Virtual. Figura 2.6: Gafas de realidad mixta Microsoft Hololens. 2.2.. Estudio de Recursos para implementación de Realidad Virtual. El reciente desarrollo de sistemas de inmersión a lo largo de las últimas décadas ha ampliado los recursos existentes para la mejora del rendimiento en misiones robóticas. Los primeros intentos de desarrollo de una estructura basada en realidad virtual se encontraban obstáculos como la falta de hardware especializado y la falta de estandarización de sistemas de seguimiento, motores de juego, etc. Los primeros sistemas de RV como VE [65] y Flow VR [66] se encontraban atados a sistemas hardware y librerı́as especı́ficas (por ejemplo, hardware SGI o librerı́as OpenGL). El soporte para los sistemas de seguimiento y otros inputs estaba limitado, y era complicado manejar distintas tecnologı́as de RV (todavı́a no estaba extendido el concepto de gafas de realidad virtual) con distintas estructuras de representación digital (rendering structures) [1]. La imagen 2.7 muestra algunos de los retos que se han encontrado al intentar desarrollar un estandar efectivo para software y middleware en RV. La imagen de la izquierda muestra un sistema de realidad virtual basado en gafas (HMD) que utiliza una base móvil para aportar sensación de movimiento paralelamente al vı́deo que se muestra en la pantalla de las gafas. Aunque existen herramientas como rviz de ROS que permiten mostrar simulaciones del moviminto del robot en distintos entornos, rviz carece de la infraestructura necesaria para integrar con facilidad seguimiento del usuario, bases móviles y demás. Es por este motivo que, a nivel de software/middleware se ha optado por el diseño de interfaces inmersivas aprovechando las caracterı́sticas que prestan los motores de diseño de videojuegos. Programas como Ogre [67] o Unity [68], gracias a la utilización de plugins y librerı́as externas, permiten la inclusión de múltiples pantallas, sistemas de. Elena Peña Tapia. 15.

(41) 2. ESTADO DEL ARTE. Figura 2.7: Extremos en sistemas de RV. Izq: sistema con gafas mas base móvil de 6 g.d.l. Dch: entorno “inmersivo” con proyección de vı́deos en las 6 caras del cubo [1].. seguimiento, motores de fı́sica, generación de audio, bases móviles.... Este software suele proporcional herramientas de edición y programación de scrcipts y otros mecanismos que permiten extender la infraestructura básica del motor de juego. Por otro lado, a nivel de hardware se ha producido un avance considerable gracias al ”boom”de los sistemas de visualización de realidad virtual. El abanico de gafas de realidad virtual presente en el mercado es amplio [69], y se puede dividir en dos categorı́as principales: móviles y dedicadas. La tabla 2.4 muestra una clasificación de las gafas de realidad virtual más populares. Cuadro 2.4: Estudio de gafas de RV. Nombre. Tipo. Hardware Necesario. Sony PlayStation VR HTC Vive Oculus Rift Google Daydream View Samsung Gear VR Homido VR FreeFly VR Google Cardboard. Dedicada Dedicada Dedicada Móvil Móvil Móvil Móvil Móvil. PlayStation 4 PC PC Teléfono compatible con Daydream Últimos modelos Samsung Galaxy Teléfonos Android e iOS Teléfonos Android e iOS Teléfonos Android e iOS. Los sistemas móviles son de bajo coste, y se limitan a dividir la pantalla de un teléfono móvil con la ayuda de lentes para crear dos imágenes que, al superponerse,. 16. ETSII UPM.

(42) 2.3 Estudio de Recursos de Comandado. dan la sensación de estar en 3 dimensiones. Si bien se están comenzando a fabricar teléfonos móviles exclusivamente diseñados para la visualización en RV, todavı́a no es posible encontrar ningún sistema de este tipo con el rendimiento mı́nimo requerido para el diseño de interfaces robóticas realistas. Entre otros motivos, presentan un reducido campo de visión (por la mala calidad de las lentes); una baja persistencia (no son robustos ante movimientos rápidos de cabeza), un seguimiento de cabeza deficiente (dado que aprovechan los giróscopos integrados en el propio teléfono) y carecen de seguimiento posicional o controles. Por ello, el diseño actual se limita al uso de sistemas de RV dedicada. Como el PlayStation VR se encuentra anclado al uso de la consola PlayStation 4, al final las opciones restantes actuales son las gafas Oculus Rift y HTC Vive. Aunque sus prestaciones son altamente similares, las HTC Vive poseen en este momento el modelo más moderno, y ofrecen ventajas como la posibilidad de movimiento libre dentro del entorno de trabajo.. 2.3.. Estudio de Recursos de Comandado. Los recursos de comandado en misiones para uno o varios robots también han sufrido una evolución paralela a la de las interfaces. Por un lado, podemos encontrar los recursos clásicos, empleados desde el inicio de la aparición de robots teleoperados: paneles de control con interruptores, pulsadores y joysticks. Además, cabe incluir dentro de esta sección el aprovechamiento de mandos comerciales de consolas como la Playstation o la Xbox, junto con los recursos asociados a la teleoperación mediante el uso de ordenadores: teclado y ratón. Por otro lado, con los avances de la tecnologı́a se han ido incluyendo novedosos recursos como displays táctiles, guantes que realizan un seguimiento de las manos del operador, sistemas de seguimiento de la mirada (particularmente usado para personas con discapacidad) [70], sistemas de reconocimiento de comandos de voz o sistemas de reconocimiento de gestos entre otros muchos. En cuanto al comandado en realidad virtual, existe la limitación que causa el bloqueo del campo visual del operador con las gafas. Esto implica que la utilización de recursos clásicos como un teclado y un ratón se complica al no poder ver la representación de dichos elementos en el mundo virtual. Esta limitación se encuentra compensada con los controles incluidos en sistemas como el Oculus Rift o las HTC Vive, que permiten una integración absoluta con el mundo virtual, dado que los mandos se ven de igual manera dentro y fuera de la RV.. Elena Peña Tapia. 17.

(43) 2. ESTADO DEL ARTE. Otras alternativas potenciales pasarı́an por el uso de movimientos de cabeza, detectados por el sistema de seguimiento virtual, o la inclusión en el mundo virtual de una cámara que proporcione un apoyo visual para manejar elementos del mundo fı́sico. La selección del recurso de más apropiado depende también del nivel de comandado requerido: en un comandado a bajo nivel conviene utilizar elementos que permiten la máxima maniobrabilidad e interactividad, en este caso, el uso de movimientos de cabeza, manos o comandos de voz podrı́a resultar apropiado. Un comandado a medio nivel, como el envı́o de waypoints, requiere de recursos que permitan el acceso a puntos lejanos; mientras que un comandado a alto nivel, como el envı́o de tareas, se beneficiarı́a de la interacción con elementos virtuales tales como menús o botones.. 2.4.. Aportaciones. Una vez estudiadas las interfaces existentes en el estado del arte, se pueden definir qué aportaciones implica este trabajo según los objetivos establecidos: Se crearán dos interfaces inmersivas de nueva generación (usando gafas de RV) fuera del ámbito de la programación de robots industriales. Se unirán elementos inmersivos y multimodales en una interfaz de monitorización, que también puede incluir componentes adaptativos. Se manipulará un robot real con una interfaz de realidad virtual, superando las interfaces de monitorización / simulación empleadas hasta la fecha.. 18. ETSII UPM.

(44) Capı́tulo 3. Herramientas de Desarrollo La figura 3.1 muestra una visión general del sistema implementado para el desarrollo de las interfaces en realidad virtual. Con tal fin, se han empleado diversas herramientas hardware y software. A nivel hardware, se encuentran los robots a monitorizar/controlar, las gafas HTC Vive y los dos ordenadores involucrados. En cuanto al software, ha sido necesario manejar de forma simultánea dos ordenadores con diferentes sistemas operativos: uno en Linux con ROS (Robot Operating System), y otro en Windows con Unity3D y el plugin de Steam VR. En este capı́tulo se explicarán en detalle las herramientas mencionadas y las comunicaciones entre las mismas, que aparecen representadas en forma de flechas. Figura 3.1: Arquitectura del sistema. Elena Peña Tapia. 19.

(45) 3. HERRAMIENTAS DE DESARROLLO. 3.1. 3.1.1.. Herramientas Hardware Robots. Durante el desarrollo del proyecto se ha trabajado con tres modelos robots diferentes: un brazo manipulador (Kinova Jaco2 3.1.1.1), un robot móvil terrestre (KUKA Youbot) y una pareja de UAVs Parrot AR.Drone 2.0. El primero se ha implementado directamente en la realidad virtual, mientras que los tres últimos se han implementado de forma indirecta. El conjunto de misiones que empleaban los tres robots se llevó a cabo el abril de 2016 en Luxemburgo, todos los datos relevantes se grabaron en Rosbags, y a la hora de implementar la realidad virtual se utilizaron los datos de los Rosbags para reproductir las misiones reales (ver 3.2.1.1). Por ello, no se entrará en una descripción detallada de sus caracterı́sticas en este apartado, aunque sı́ se hablará de los nodos y tópicos de ROS utilizados en apartados siguientes.. 3.1.1.1.. Brazo Kinova Jaco2. El robot manipulador Jaco2 , fabricado por Kinova Robotics, posee 6 grados de libertad más un efector final formado por tres dedos articulados (figura 3.2), lo que lo dota de una gran maniobrabilidad. Puede soportar cargas de hasta 1,6 kg y su alcance es de 900mm. Este robot permite control de fuerza, lo que lo hace seguro para el trabajo en colaboración con personas. La base es de aluminio extruido, y las diferentes partes articuladas son de fibra de carbono. El robot se puede controlar a través de una conexión USB o Ethernet a un ordenador, aunque también posee un controlador embebido. En el ordenador se puede ejecutar la planificación de trayectorias junto a otras tareas de alto nivel; mientras que el controlador embebido se encarga de ejecutar el control articular y, cuando sea necesaria, la cinemática inversa. Para la planificación de movimientos se utiliza el software de planificación móvil MoveIt!. Este software integra la Open Motion Planning Library(OMPL) [71], una librerı́a de código abierto que implementa aloritmos de planificación basados en muestreo: PRM, RRT, EST, SBL, KPIECE, SyCLOP, etc. Las funcionalidades de este software incluyen, entre otras, comprobación de colisiones y percepción 3D. En concreto, para realizar el control de Jaco2 en el contexto de este TFG, se utilizó el algoritmo de planificación autónomo RRT-connect (RRT indica Rapidly Exploring Random Trees) previamente desarrollado [72]. El planificador funciona elaborando un árbol de exploración de la siguiente forma:. 20. ETSII UPM.

(46) 3.1 Herramientas Hardware. Figura 3.2: Imagen del Jaco2. 1. Se obtiene un estado aleatorio qr en el espacio articular. 2. Se busca el estado más cercano a qr entre los estados previos, y se denota como qc. 3. Se tienen en cuentra las capacidades cinemáticas del robot para encontrar un estado válido qm que surge de expandir qc en dirección a qr. 4. Se añade qm al árbol de exploración. Para configurar el robot en MoveIt! se emplea un fichero United Robot Description Format (URDF), que representa en lenguaje XML el modelo del robot, sus sensores y su entorno. A partir del URDF, MoveIt! posee toda la información necesaria para planificar los movimientos. Para la generación de URDF se parte de un fichero básico proporcionado por el fabricante, al que se añaden posibles sensores adicionales junto con la descripción del entorno. Una vez realizada la configuracion inicial, MoveIt! se comunica con el driver del brazo para obtener la posicion de cada articulación y demás parametros necesarios para conocer es estado actual del robot. La configuración final y la posicion del robot puede ser enviada a MoveIt! mediante una interfaz de control, o a través de un mensaje de. Elena Peña Tapia. 21.

(47) 3. HERRAMIENTAS DE DESARROLLO. ROS. Una vez recibida la meta, se realiza la planificación y se obtiene la trayectoria de cada articulacion, que es enviada de vuelta al driver del robot, encargado de comunicarse con el brazo y controlarlo.. 3.1.2.. Gafas HTC Vive. Las gafas de realidad virtual HTC Vive fueron originalmente concebidas con fines recreativos, pero su versatilidad ha promovido la aparición de nuevas aplicaciones más allá de los videojuegos. El sistema HTC Vive ofrece experiencias de realidad virtual adaptadas al espacio de una habitación (modo roomscale) o restringidas a un usuario sentado (modo seated). Los elementos principales del sistema se pueden observar en la figura 3.3. Las gafas per se reciben el nombre de HMD (Head Mounted Display). El HMD contiene dos pantallas, una por ojo, que muestran imágenes en alta resolución (1080x1200) con un ratio de refresco de 90 Hz. Una salida de audio permite la conexión de auriculares para aumentar el nivel de inmersión en el entorno virtual, gracias a la localización espacial del sonido.. Figura 3.3: Elementos del sistema HTC Vive. El sistema de seguimiento de usuario utiliza dos estaciones base llamadas lighthouses (faros en inglés) emisoras de luz, y un gran número de fotosensores colocados alrededor del HMD y los mandos. Las estaciones base son relativamente sencillas, con una serie de diodos LED estacionarios y una pareja de emisores de rayos láser. El funcionamiento del sistema es el siguiente: los diodos emiten aproximadamente 6 pulsaciones por segundo. Cada vez que una pulsación LED tiene lugar, se inicia una cuenta que termina cuando. 22. ETSII UPM.

(48) 3.1 Herramientas Hardware. algún fotosensor interrumpe un rayo láser. De esta manera, relacionando la posición del sensor con el momento de la detección del rayo, es posible calcular de forma precisa la posición relativa respecto a las estaciones base, como muestra la figura 3.4. Esta sencilla técnica ofrece una precisión sub-milimétrica en la localización y una latencia del sistema inferior a 22 ms [73]. Esta última propiedad resulta muy interesante, dado que el periodo de latencia es uno de los factores principales que causan mareos y malestar asociado a la realidad virtual [74].. Figura 3.4: Ilustración del funcionamiento del sistema lighthouse. Además del sistema de posicionamiento óptico, las HTC Vive contienen sensores adicionales como giróscopos, acelerómetros e incluso una cámara frontal que permite la detección de obstáculos en el área de trabajo. Las HTC Vive incluyen una pareja de mandos con trackpads, gatillos y botones laterales que permiten interactuar de forma sencilla e intuitiva con los objetos en realidad virtual. Un diagrama de los principales componentes del mando se puede observar en la figura 3.5. Además de los botones, los mandos ofrecen la posibilidad de implementar realimentación háptica como parte de una intereacción multimodal.. Elena Peña Tapia. 23.

(49) 3. HERRAMIENTAS DE DESARROLLO. Figura 3.5: Diagrama de los mandos Vive (developer.viveport.com). 3.2. 3.2.1.. Herramientas Software ROS. ROS (Robot Operating System) [75] es un framework flexible que permite el desarrollo de software para robots. Se trata de una colección de herramientas, librerı́as y convenciones que pretenden simplificar la tarea de crear software robusto que abarque una amplia variedad de plataformas. En la última década ROS se ha convertido en el middleware más ultilizado para el desarollo de sistemas autónomos. Aunque se ha llegado a implementar ROS en distintas plataformas hardware, el soporte principal se encuentra en Ubuntu, con el uso de librerı́as de software en C++ y Python. Hay una serie de razones por las que ROS se ha posicionado como una plataforma de middleware estandarizada [1]: 1. No se encuentra asociado a ningún hardware especı́fico ni modo de comunicación (aunque suele utilizar TCP/IP). 2. Su software permite un desarrollo modular, gracias a la comunicación independiente con distintos agentes. 3. Ofrece soporte para una gran cantidad de robots y sensores 4. Se puede encontrar un gran número de librerı́as y herramientas de software ya desarrolladas para las aplicaciones robóticas más comunes. Dentro de ROS, el control de robots se modela como una colección de procesos ası́ncronos (nodos) que se comunica mediante mensajes dentro de los conocidos como tópicos. La imagen 3.6 muestra un esquema general del funcionamiento de ROS.. 24. ETSII UPM.

(50) 3.2 Herramientas Software. Figura 3.6: Diagrama de los elementos básicos de ROS. 3.2.1.1.. RosBags. El paquete RosBag contiene una serie de herramientas que permiten grabar los mensajes mandados dentro de distintos tópicos para poder reproducirlos en cualquier momento. Su alto rendimiento evita la pérdida de sincronismo de los mensajes, y por tanto se consigue que la reproducción sea una copia exacta de la misión original. La herramienta se maneja mediante la lı́nea de comandos de Linux ası́ como a través de APIs codificadas en C++/python que permiten leer y escribir bags.. 3.2.2.. Unity. Unity es un motor de desarrollo de videojuegos creado por Unity Technologies válido para un gran número de plataformas. Los juegos se desarrollan a partir de scripts, programados en Visual Studio o su propio editor (Mono Develop). Las principales ventajas de Unity para el desarrollo de sistemas inmersivos de monitorización/teleoperación son las siguientes: 1. Soporte multiplataforma 2. Ofrece diversas opciones de programación (C#, Javascript....) 3. Existen plugins para uso de hardware especı́fico como Steam VR o MiddleVR 4. Posee un gran número de librerı́as propias y assets que facilitan el desarrollo En Unity, la unidad básica de software es el GameObject. Un GameObject encapsula el diseño visual de un objeto y lo enlaza con el motor de juego, junto con la lógica de interacción, animación, control de frames, etc. Unity, como la mayorı́a de programas de. Elena Peña Tapia. 25.

(51) 3. HERRAMIENTAS DE DESARROLLO. desarrollo de juegos, funciona a través de frames, por lo que la necesidad de refrescar el display visual es crı́tica y determina la totalidad de la infraestructura de software. Este modelo puede provocar dificultades cuando se intenta manejar en conjunción con sistemas de control de robots como ROS. No obstante, su ya mencionada flexibilidad mantiene a Unity como una de las mejores alternativas para el desarrollo de trabajos con realidad virtual.. 3.2.2.1.. Assets. En Unity, un Asset constituye la representación de cualquier elemento del proyecto. Un Asset puede proceder de un archivo creado fuera de Unity (modelo 3D, archivo de audio, imagen...) o puede haber sido generado dentro del propio programa (una animación, una textura renderizada...). La figura 3.7 muestra algunos de los archivos que se pueden importar como Assets.. Figura 3.7: Ejemplos de posibles Assets de Unity. Como ya se ha mencionado, una de las mayores ventajas que proporciona Unity es la comunidad de desarrolladores que se encuentra detrás, que con herramientas como la Asset Store permiten la descarga de paquetes de Assets ya configurados, que permiten el ahorro de una gran cantidad de tiempo y trabajo con muy buenos resultados.. 26. ETSII UPM.

(52) 3.3 Comunicación. 3.2.2.2.. Plugin de Steam VR. El plugin de Steam VR para Unity se encuentra disponible de manera gratuita en la Asset Store, y proporciona todas las herramientas necesarias para el manejo de las principales gafas de realidad virtual, incluidas las HTC Vive. Este plugin gestiona la conexión entre el hardware de las gafas y Unity de modo que el desarrollador solo tiene que centrarse en el aspecto software de su aplicación. Además, incluye una serie de paquetes que facilitan un modo Debug en 2D, para evitar la dependencia de las gafas; ası́ como las interacciones básicas con el mundo virtual. Cabe destacar que en la actualidad el plugin de Steam VR solo es compatible con el sistema operativo Windows.. 3.3.. Comunicación. Si se recuerda la arquitectura del sistema (figura 3.8), se observa que se requiere el uso de 2 ordenadores con sistemas operativos diferentes, uno en Linux con ROS y otro en Windows con Unity y Steam VR. Uno de los aspectos clave de este trabajo es el de la comunicación de estos dos ordenadores. En un principio, durante el desarrollo de la interfaz de monitorización, se optó por la creación de un nodo de comunicación servidor-cliente usando el protocolo TCP/IP (apartado 3.3.1). Sin embargo, este nodo resultaba poco eficiente para el desarrollo de la interfaz de comandado, que requerı́a una corriente de mensajes bidireccional con el menor retardo posible, y que además manejaba mensajes más complejos. La alternativa a la que se recurrió en este segundo caso fue el aprovechamiento del paquete RosBridge, explicado en el apartado 3.3.2.. Figura 3.8: Recordatorio de la arquitectura del sistema. Elena Peña Tapia. 27.